FC PH 3 - 9.1

Copies of this document may be purchased from:
Global Engineering, 15 Inverness Way East,

Englewood, CO 80112-5704
Phone: (800) 854-7179 or (303) 792-2181 Fax: (303) 792-2192
dpANS X3.xxx-199x
X3T11/Project 1119D/Rev 9.1
FIBRE CHANNEL
PHYSICAL AND SIGNALLING
INTERFACE - 3 (FC-PH-3)
REV 9.1
working draft proposed

American National Standard
for Information Systems
October 15, 1996
Secretariat:
Information Technology Industry Council
ABSTRACT: This standard describes the enhancement to the ANSI X3.230, Fibre Channel Physical and
Signalling Interface (FC-PH) and to the ANSI X3.297, Fibre Channel Physical and Signalling Interface - 2
(FC-PH-2) and is an addendum to both these documents.
NOTE:
This is a draft proposed American National Standard of Accredited Standards Committee X3. As
such, this is not a completed standard. The X3T11 Technical Committee may modify this document
as a result of comments received during public review and its approval as a standard.
POINTS OF CONTACT:
Roger Cummings (X3T11 Chairman)
Distributed Processing Technology
140 Candace Drive
Maitland, FL 32751
(407) 830-5522 x348 Fax: (407) 260-5366
E-Mail:cummings_roger@dpt.com
I. Dal Allan
(Fibre Channel Working Group Chairman)
ENDL
14426 Black Walnut Court
Saratoga, CA 95070
(408) 867-6630
Fax: (408) 867-2115
E-Mail: dal_allan@mcimail.com
Carl Zeitler (X3T11 Vice Chairman)

IBM Corporation - AWD, MS 9440
11400 Burnet Road, Austin, TX 78758
(512) 838-1797 Fax: (512) 838-1852
E-Mail: zeitler@ausvm6.vnet.ibm.com
Bryan Cook (Editor)
IBM Corporation, MS P323
522 South Road, Poughkeepsie, NY 12601
(914) 435-7914 Fax: (914) 432-9417
E-Mail: bryan_cook@vnet.ibm.com
Changed from Revision 9.0:
Revised Clauses 7, 9, and Annex F as a result of the X3T11 Letter Ballot.
Changed BER definition in 5.1 to reflect FC-PH-2.
ANSI
dpANS X3.xxx-199x
draft proposed American National Standard
for Information Technology

Fibre Channel Physical and Signalling Interface - 3
(FC-PH-3)
Secretariat
Information Technology Industry Council
Approved
,199
American National Standards Institute, Inc.
Abstract
This standard describes the enhancement to the ANSI X3.230, Fibre Channel Physical and Signalling Interface (FC-PH) and to the ANSI X3.297, Fibre Channel Physical and Signalling Interface - 2 (FC-PH-2)
and is an addendum to both these documents.
iii
American
National
Standard
Approval of an American National Standard requires verification by ANSI that the

requirements for due process, consensus, and other criteria for approval have
been met by the standards developer.
Consensus is established when, in the judgement of the ANSI Board of Standards
Review, substantial agreement has been reached by directly and materially
affected interests. Substantial agreement means much more than a simple
majority, but not necessarily unanimity. Consensus requires that all views and
objections be considered, and that a concerted effort be made towards their
resolution.
The use of American National Standards is completely voluntary; their existence
does not in any respect preclude anyone, whether he has approved the standards
or not, from manufacturing, marketing, purchasing, or using products, processes,
or procedures not conforming to the standards.
The American National Standards Institute does not develop standards and will in
no circumstances give interpretation on any American National Standard.
Moreover, no person shall have the right or authority to issue an interpretation of
an American National Standard in the name of the American National Standards
Institute. Requests for interpretations should be addressed to the secretariat or
sponsor whose name appears on the title page of this standard.
CAUTION NOTICE: This American National Standard may be revised or
withdrawn at any time. The procedures of the American National Standards
Institute require that action be taken periodically to reaffirm, revise, or withdraw this
standard. Purchasers of American National Standards may receive current
information on all standards by calling or writing the American National Standards
Institute.
Published by
American National Standards Institute

11 W. 42nd Street, New York, New York 10036
Copyright 199x by American National Standards Institute

All rights reserved
No part of this publication may be reproduced in any
form, in an electronic retrieval system or otherwise,
without prior written permission of the publisher.
Printed in the United States of America

INSERT CODE HERE
iv
Contents
Page
Foreword
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction
1 Scope
xviii
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Normative References
. . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Approved references
xix
1
1
. . . . . . . . . . . . . . . . . . . . . . . . .
2.2 References uder development . . . . . . . . . . . . . . . . . . . . .
3 Definitions and conventions
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 FC-4 Region . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Profile
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Editorial conventions . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Abbreviations, acronyms and symbols
. . . . . . . . . . . . . . . .
3.3.1 Acronyms and other abbreviations
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
4.16 FC-4 Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 FC-0 functional characteristics . . . . . . . . . . . . . . . . . . . . . . .
3.1 Definitions
4 Structure and concepts
5.1 General Characteristics
. . . . . . . . . . . . . . . . . . . . . . . .
6 Optical fibre interface specification . . . . . . . . . . . . . . . . . . . . .
Electrical cable interface specification . . . . . . . . . . . . . . . . . . .

7.1 Electrical data links
. . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Reference locations
. . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.1 Intercabinet references
. . . . . . . . . . . . . . . . . . . . . .
7.2.2 Intracabinet references
. . . . . . . . . . . . . . . . . . . . . .
7.3 75 W unbalanced data links
. . . . . . . . . . . . . . . . . . . . . .
7.3.1 ECL compatible driver characteristics . . . . . . . . . . . . . . .
7.3.2 ECL compatible receiver characteristics
7.3.3 Unbalanced cable characteristics
. . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
10
7.3.4 Unbalanced cable connectors . . . . . . . . . . . . . . . . . .
11
7.3.4.1 Intercabinet connectors for unbalanced cable
. . . . . . .
11
7.3.4.2 Style-1 unbalanced cable connector
. . . . . . . . . . . .
11
. . . . . . . . . . . .
11
7.3.4.4 Intracabinet connectors for unbalanced cable
. . . . . . .
11
. . . . . . . . . . . . . . . . . . . . . .
11
7.4.1 ECL compatible driver characteristics . . . . . . . . . . . . . .
11
7.4 150W balanced data links
Page
7.4.2 ECL compatible receiver characteristics . . . . . . . . . . . . .
12
7.4.3 Balanced cable characteristics
. . . . . . . . . . . . . . . . .
12
. . . . . . . . . . . . . . . . . . .
13
7.4.4 Balanced cable connectors
7.4.4.1 Intercabinet connectors for balanced cable
. . . . . . . . .
13
7.4.4.2 Style-1 balanced cable connector . . . . . . . . . . . . . .
13
7.4.4.3 Style-2 balanced cable connector . . . . . . . . . . . . . .
13
7.4.4.3.1 Style-2 plug
. . . . . . . . . . . . . . . . . . . . . . .
14
7.4.4.3.2 Style-2 receptacle . . . . . . . . . . . . . . . . . . . .
14
7.4.4.4 Optional intercabinet connector pins
. . . . . . . . . . . .
14
7.4.4.5 Intracabinet connectors for balanced cable
. . . . . . . . .
15
7.4.4.6 Intracabinet connectors for balanced cable
. . . . . . . . .
15
8 Optical fibre cable plant specification . . . . . . . . . . . . . . . . . . .
16
9 Electrical cable plant specification
. . . . . . . . . . . . . . . . . . . .
17
. . . . . . . . . . . . . . . . . . . . . . .
17
9.1 Unbalanced cable plant
9.1.1 LV (long-video) cable plant specification

9.1.1.1 LV-type
9.1.1.2 Shielding
. . . . . . . . . . . .
17
. . . . . . . . . . . . . . . . . . . . . . . . . . .
17
. . . . . . . . . . . . . . . . . . . . . . . . . .
17
9.1.2 TV (video) cable plant specification

9.1.2.1 TV-type
9.1.2.2 Shielding
. . . . . . . . . . . . . . .
17
. . . . . . . . . . . . . . . . . . . . . . . . . . .
18
. . . . . . . . . . . . . . . . . . . . . . . . . .
18
9.1.3 MI (miniature) cable plant specification

9.1.3.1 MI-type
9.1.3.2 Shielding
. . . . . . . . . . . . .
18
. . . . . . . . . . . . . . . . . . . . . . . . . . .
18
. . . . . . . . . . . . . . . . . . . . . . . . . .
18
9.1.4 Unbalanced cable interoperability
. . . . . . . . . . . . . . . .
18
9.2 Balanced cable plant . . . . . . . . . . . . . . . . . . . . . . . . .
18
9.2.1 TP (shielded twisted pair) cable plant specification
. . . . . . .
18
. . . . . . . . . . . . . . . . . . . . . . . . . . .
18
. . . . . . . . . . . . . . . . . . . . . . . . . .
19
9.2.2 TW cable plant specification . . . . . . . . . . . . . . . . . . .
19
9.2.1.1 TP-type
9.2.1.2 Shielding
9.2.2.1 TW-type
9.2.2.2 Shielding
. . . . . . . . . . . . . . . . . . . . . . . . . . .
19
. . . . . . . . . . . . . . . . . . . . . . . . . .
19
9.2.3 Balanced cable interoperability
. . . . . . . . . . . . . . . . .
20
. . . . . . . . . . . . . . . .
21
. . . . . . . . . . . . . . . . . . . .
21
10 Optical interface connector specification

11 FC-1 8B/10B Transmission Code
vi
Page
12 FC-1 receiver and transmitter description
. . . . . . . . . . . . . . .
21
13 Loopback mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
14 Diagnostic mode
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
15 Transmitter safety . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
16 Ordered sets
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
17 Frame formats
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
18 Frame_Header
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
18.3 Address identifiers
. . . . . . . . . . . . . . . . . . . . . . . . .
18.4 Data Structure (TYPE)
22
. . . . . . . . . . . . . . . . . . . . . . .
22
18.5 Frame Control (F_CTL)
. . . . . . . . . . . . . . . . . . . . . .
22
18.6 Sequence_ID (SEQ_ID)
. . . . . . . . . . . . . . . . . . . . . .
26
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
18.7 DF_CTL
18.9 Word 4, Bits 31-16
. . . . . . . . . . . . . . . . . . . . . . . . .
18.9.1 Originator Exchange_ID (OX_ID)
26
. . . . . . . . . . . . . . .
26
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
19.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
19.2 Expiration_Security_Header
. . . . . . . . . . . . . . . . . . . .
28
. . . . . . . . . . . . . . . . . . . . . . . . . .
28
18.9.2 Priority
19 Optional headers
19.3 Network_Header
19.3.1 D_NAA or S_NAA
. . . . . . . . . . . . . . . . . . . . . . .
19.3.2.5 CCITT 60-bit address
28
. . . . . . . . . . . . . . . . . . .
29
19.4 Association Header . . . . . . . . . . . . . . . . . . . . . . . . .
29
20 Data frames and responses

20.3 Link_Control
. . . . . . . . . . . . . . . . . . . . . .
30
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
20.3.3.2 N_Port Busy (P_BSY)
. . . . . . . . . . . . . . . . . . .
30
. . . . . . . . . . . . . . . . . .
30
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
20.3.3.3 Reject (P_RJT, F_RJT)

21 Link Services
21.1.1 Default Login values
. . . . . . . . . . . . . . . . . . . . . .
21.2 Basic Link Service commands
. . . . . . . . . . . . . . . . . . .
21.2.7 Dedicated Connection Preempted (PRMT)

21.3 Extended Link Services
31
31
. . . . . . . . . .
32
. . . . . . . . . . . . . . . . . . . . . .
32
21.4 Extended Link Service requests
. . . . . . . . . . . . . . . . . .
34
21.4.13 Read Timeout Value (RTV) . . . . . . . . . . . . . . . . . .
34
21.5 Extended Link Service reply Sequences
. . . . . . . . . . . . . .
34
vii
Page
21.5.2 Link Service Reject (LS_RJT)
. . . . . . . . . . . . . . . . .
21.20 Report Node Capabilities Information (RNC)

22 Classes of Service
. . . . . . . . . . .
35
. . . . . . . . . . . . . . . . . . . . . . . . . . .
40
22.6 Class 6 - Uni-Directional Dedicated Connection
. . . . . . . . . .
40
. . . . . . . . . . . . . . . . . . . . . . . .
40
. . . . . . . . . . . . . . . . . . . . . . . . . .
40
22.6.1 Class 6 function

22.6.2 Class 6 rules
34
22.6.3 Class 6 delimiters
. . . . . . . . . . . . . . . . . . . . . . .
41
22.6.4 Class 6 frame size
. . . . . . . . . . . . . . . . . . . . . . .
41
22.6.5 Class 6 flow control . . . . . . . . . . . . . . . . . . . . . . .
41
22.6.6 Stacked Connect-requests
. . . . . . . . . . . . . . . . . . .
42
. . . . . . . . . . . . . . . . . . . . .
43
23.1 Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
23.2 Applicability
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
23.3 Fabric Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
23 Login and Service Parameters
23.3.1 Explicit Fabric Login
. . . . . . . . . . . . . . . . . . . . . .
43
23.3.2 Responses to Fabric Login . . . . . . . . . . . . . . . . . . .
44
23.3.2.1 FLOGI with S_ID = 0 or 0000yy
. . . . . . . . . . . . . .
44
23.6 N_Port Service Parameters . . . . . . . . . . . . . . . . . . . . .
45
23.6.1 N_Port Common Service Parameters
. . . . . . . . . . . . .
46
23.6.2 N_Port Common Service parameters - Fabric Login . . . . . .
48
23.6.2.1 FC-PH-3 version
. . . . . . . . . . . . . . . . . . . . . .
23.6.2.2 Buffer-to-buffer credit

23.6.2.3 Common features
. . . . . . . . . . . . . . . . . . .
48
. . . . . . . . . . . . . . . . . . . . .
48
23.6.2.4 Buffer-to-buffer Data_Field size
. . . . . . . . . . . . . .
23.6.3 N_Port Common Service Parameters - N_Port Login

48
. . . . . . . . . . . . . . . . . . . . . .
49
. . . . . . . . . . . . . . . . . . .
49
. . . . . . . . . . . . . . . . . . . . .
49
. . . . . . . . . . . . . .
49
. . . . . . . . . . . . . . .
49
. . . . . . . . . . . . . . . .
49
23.6.3.7 Point-to-point E_D_TOV value . . . . . . . . . . . . . . .
49
23.6.3.5 Total Concurrent Sequences

23.6.3.6 Relative Offset by category
23.6.6 N_Port Class Service Parameters
. . . . . . . . . . . . . . .
23.6.7 N_Port Class Service Parameters - Fabric Login
viii
48
. . . . .

48
. . . . . . .
50
52
Page
23.6.7.1 Class Validity (V)
. . . . . . . . . . . . . . . . . . . . .
52
. . . . . . . . . . . . . . . . . . . . . .
52
23.6.7.3 Initiator control . . . . . . . . . . . . . . . . . . . . . . .
52
23.6.7.4 Recipient control . . . . . . . . . . . . . . . . . . . . . .
52
23.6.7.5 Receive Data_Field Size
. . . . . . . . . . . . . . . . .
52
. . . . . . . . . . . . . . . . . .
52
. . . . . . . . . . . . . . . . .
52
23.6.7.8 Open Sequences per Exchange . . . . . . . . . . . . . .
52
23.6.7.2 Service Options
23.6.7.6 Concurrent Sequences

23.6.7.7 N_Port End-to-end Credit
23.6.8 N_Port Class Service Parameters - N_Port Login
. . . . . . .
52
. . . . . . . . . . . . . . . . . . . . .
52
. . . . . . . . . . . . . . . . . . . . . .
52
53
23.6.8.4 Recipient control . . . . . . . . . . . . . . . . . . . . . .
53
. . . . . . . . . . . . . . . . .
53
. . . . . . . . . . . . . . . . . .
53
. . . . . . . . . . . . . . . . .
54
23.6.8.8 Open Sequences per Exchange . . . . . . . . . . . . . .
54
23.6.8.9 Class 6 Multicast RX_ID . . . . . . . . . . . . . . . . . .
54


23.6.9 Vendor Version Level
. . . . . . . . . . . . . . . . . . . . .
54
23.6.10 Services Availability
. . . . . . . . . . . . . . . . . . . . .
54
. . . . . . . . . . . . . . . . . . . .
54
23.7 F_Port Service Parameters
23.7.1 F_Port Common Service Parameters
. . . . . . . . . . . . .
54
23.7.1.1 FC-PH-3 version . . . . . . . . . . . . . . . . . . . . . .
54
23.7.1.2 Buffer-to-buffer (F_Port) Credit
. . . . . . . . . . . . . .
54
. . . . . . . . . . . . . . . . . . . . .
54
. . . . . . . . . . . . . .
55
23.7.1.5 E_D_TOV
. . . . . . . . . . . . . . . . . . . . . . . . .
55
23.7.1.6 R_A_TOV
. . . . . . . . . . . . . . . . . . . . . . . . .
55
23.7.2 F_Port Name . . . . . . . . . . . . . . . . . . . . . . . . . .
55
23.7.3 Fabric Name
55
. . . . . . . . . . . . . . . . . . . . . . . . . .
23.7.4 F_Port Class service Parameters
. . . . . . . . . . . . . . .
55
. . . . . . . . . . . . . . . . . . . . . . .
55
. . . . . . . . . . . . . . . . . . . . . .
55
55
23.7.4.1 Class Validity

ix
Page
23.7.4.4 Recipient control
. . . . . . . . . . . . . . . . . . . . . .
55
23.7.4.5 Receive Data_Field Size . . . . . . . . . . . . . . . . . .
56
. . . . . . . . . . . . . . . . . .
56
. . . . . . . . . . . . . . . . .
56
23.7.4.8 Open Sequences per Exchange

23.7.4.9 C_R_TOV
. . . . . . . . . . . . . .
56
. . . . . . . . . . . . . . . . . . . . . . . . .
56
23.7.5 Vendor Version Level

23.7.6 Services Availability
. . . . . . . . . . . . . . . . . . . . .
56
. . . . . . . . . . . . . . . . . . . . . .
56
23.8 Procedure to estimate end-to-end Credit
. . . . . . . . . . . . . .
24 Exchange, Sequence, and sequence count management

24.3 Summary rules
57
. . . . . . .
58
. . . . . . . . . . . . . . . . . . . . . . . . . . .
58
24.3.1 Exchange management
. . . . . . . . . . . . . . . . . . . .
58
24.3.7 Normal ACK processing
. . . . . . . . . . . . . . . . . . . .
58
24.3.11 Sequence errors - Class 3
. . . . . . . . . . . . . . . . . .
24.3.11.1 Rules common to all Discard policies
58
. . . . . . . . . .
58
. . . . . . . . .
58
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
24.8.1 Exchange Status Block . . . . . . . . . . . . . . . . . . . . .
58
24.8.2 Sequence Status Block . . . . . . . . . . . . . . . . . . . . .
59
24.3.11.2 Process with infinite buffers Error Policy

24.8 Status blocks
25 Association Header management and usage
. . . . . . . . . . . . . .
60
26 Flow control management . . . . . . . . . . . . . . . . . . . . . . . .
60
27 Segmentation and reassembly
. . . . . . . . . . . . . . . . . . . . .
60
. . . . . . . . . . . . . . . . . . . . . . . .
61
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
28.4 Connect/disconnect rules . . . . . . . . . . . . . . . . . . . . . .
61
28 Connection management
28.1 Introduction
28.4.1 Connect-request rules
. . . . . . . . . . . . . . . . . . . . .
61
28.4.1.1 Source of connect-request . . . . . . . . . . . . . . . . .
61
28.5 Establishing a Connection
. . . . . . . . . . . . . . . . . . . . .
61
28.5.4 Destination of a connect-request . . . . . . . . . . . . . . . .
61
28.9 Connection Preemption . . . . . . . . . . . . . . . . . . . . . . .
61
28.9.1 Applicability . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
28.9.2 Topology Model
. . . . . . . . . . . . . . . . . . . . . . . .
61
28.9.3 Rules for Preemption . . . . . . . . . . . . . . . . . . . . . .
61
28.9.3.1 Preemptor (P)
. . . . . . . . . . . . . . . . . . . . . . .
62
Page
28.9.3.2 Preempted Source (PS)
. . . . . . . . . . . . . . . . . .
28.9.3.3 Preempted Destination(s)(PD)
. . . . . . . . . . . . . .
63
. . . . . . . . . . . . .
63
. . . . . . . . . . . . . . . . . . . . . . .
63
28.9.3.4 Preemption Destination(s) (PnD)

28.9.4 Connection Rules
62
28.9.5 Remove Connection Rules
. . . . . . . . . . . . . . . . . .
63
28.10 Establishing a Connection Using Preemption . . . . . . . . . . .
63
28.10.1 Connection Initiator
. . . . . . . . . . . . . . . . . . . . . .
63
28.10.2 Preemption Destination . . . . . . . . . . . . . . . . . . . .
65
29 Error detection and recovery
. . . . . . . . . . . . . . . . . . . . . .
66
29.2.1.2 E_D_TOV
. . . . . . . . . . . . . . . . . . . . . . . . .
66
29.6 Exchange integrity
. . . . . . . . . . . . . . . . . . . . . . . . .
66
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
31.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
31.2 Class 6 Multicast
68
30 Hunt Group
31 Multicast
. . . . . . . . . . . . . . . . . . . . . . . . . .
31.2.1 Class 6 Multicast Routing
. . . . . . . . . . . . . . . . . . .
68
31.2.2 Class 6 Multicast Rules
. . . . . . . . . . . . . . . . . . . .
68
31.2.3 Class 6 Multicast Server
. . . . . . . . . . . . . . . . . . . .
69
. . . . . . . . . . . . . . . . . . .
69
. . . . . . . . . . . . . . . . . . . . . . . . . .
69
31.2.4 Class 6 Multicast recovery

31.3 Class 3 Multicast
31.3.1 Registration and De-registration
. . . . . . . . . . . . . . . .
69
31.3.2 Multicast Routing . . . . . . . . . . . . . . . . . . . . . . . .
69
31.3.3 Class 3 Multicast rules
. . . . . . . . . . . . . . . . . . . . .
70
31.4 Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
31.5 Moviecast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
31.6 Other
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
32 Aliases
33 Dedicated Simplex
. . . . . . . . . . . . . . . . . . . . . . . . . . .
72
34 Class 4- Fractional
. . . . . . . . . . . . . . . . . . . . . . . . . . .
72
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
35 Camp-On
36 Stacked Connect Request
. . . . . . . . . . . . . . . . . . . . . . .
72
. . . . . . . . . . . . . . . . . . . . . . . .
72
. . . . . . . . . . . . . . . . . . . . . . . . . . .
72
37 Buffered Class 1 Service

38 Data Compression
39 Clock synchronization service
. . . . . . . . . . . . . . . . . . . . .
73
xi
Page
39.1 Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
39.1.1 Applicability . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
39.1.2 Function
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
39.2 Communications Model . . . . . . . . . . . . . . . . . . . . . . .
73
39.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
39.3.1 Server Rules
. . . . . . . . . . . . . . . . . . . . . . . . . .
74
39.3.2 Client Rules
. . . . . . . . . . . . . . . . . . . . . . . . . .
74
39.4 Clock Synchronization Control
. . . . . . . . . . . . . . . . . . .
75
39.4.1 Use of FC-PH Constructs
. . . . . . . . . . . . . . . . . . .
75
. . . . . . . . . . . . . . . . . . . . . . . .
75
39.4.1.1 Login/Logout
39.4.1.1.1 Initiator Capability
. . . . . . . . . . . . . . . . . . .
75
. . . . . . . . . . . . . . . . . .
75
. . . . . . . . . . . . . . . . . . . . . . . . .
75
39.4.1.3 Information Units . . . . . . . . . . . . . . . . . . . . . .
75
39.4.1.4 Common Required FC Parameters
. . . . . . . . . . . .
75
39.4.1.5 Common Optional FC Parameters . . . . . . . . . . . . .
76
39.4.1.6 CT_HDR
76
39.4.1.1.2 Recipient Capability

39.4.1.2 Exchanges
. . . . . . . . . . . . . . . . . . . . . . . . . .
39.4.2 Clock Control Request
. . . . . . . . . . . . . . . . . . . . .
39.4.3 Clock Control Link Service
76
. . . . . . . . . . . . . . . . . . .
76
39.4.3.1 Clock Control (CSS_CC) . . . . . . . . . . . . . . . . . .
77
39.5 Synchronize Clock Request
. . . . . . . . . . . . . . . . . . . .
77
39.5.1 Primitive Signal Service
. . . . . . . . . . . . . . . . . . . .
77
. . . . . . . . . . . . . . . . . . . . . . . . . . .
77
39.5.1.1 Terms
39.5.1.2 Synchronize Clock Request
. . . . . . . . . . . . . . . .
78
. . . . . . . . . . . . . . . . .
78
39.5.1.4 Primitive Signal Insertion . . . . . . . . . . . . . . . . . .
78
39.5.1.3 Synchronize Clock Accept
39.5.2 ELS Service
. . . . . . . . . . . . . . . . . . . . . . . . . .
39.5.2.1 Synchronize Clock Link Service
78
. . . . . . . . . . . . . .
78
. . . . . . . . . . . . . . .
78
40 Data Encryption
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
40.1 Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
39.5.2.2 Synchronize Clock (CSS_SC)
40.2 N_Port Login
40.2.1 Initiator Capability

40.2.2 Recipient Capability
xii
. . . . . . . . . . . . . . . . . . . . . . .
80
. . . . . . . . . . . . . . . . . . . . . .
80
Page
40.2.3 F_CTL
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
40.3 Applicability . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
40.4 Decryption
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
AA
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
AB
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
AC
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
AD
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Annexes
100
xiii
Page
AE
xiv
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
102
Page
Tables
1
FC-0 physical links for electrical cable classes
. . . . . . . . . . . . . .
FC-0 physical links for electrical cable classes (continued)
Eye diagram mask at point-S
. . . . . . . . . . . . . . . . . . . . . .
10
Eye diagram mask at point-R
. . . . . . . . . . . . . . . . . . . . .
10
Optional intercabinet contact uses
. . . . . . .
6
7
. . . . . . . . . . . . . . . . . . .
15
LV-style cable plant
. . . . . . . . . . . . . . . . . . . . . . . . . . .
17
TV-style cable plant
. . . . . . . . . . . . . . . . . . . . . . . . . . .
17
MI-style cable plant
. . . . . . . . . . . . . . . . . . . . . . . . . . .
18
TP-style cable plant
. . . . . . . . . . . . . . . . . . . . . . . . . . .
19
. . . . . . . . . . . . . . . . . . . . . . . . . .
19
10
TW-style cable plant
11
Well-known Address identifiers
12
Type codes - FC-4 (Device_Data and Link_Data)
13
. . . . . . . . . . . . . . . . . . . .
22
. . . . . . . . . .
22
(Page 1 of 2) - F_CTL field
. . . . . . . . . . . . . . . . . . . . . .
23
14
(Page 2 of 2) - F_CTL field
. . . . . . . . . . . . . . . . . . . . . .
24
15
Data encryption status
. . . . . . . . . . . . . . . . . . . . . . . .
25
16
DF_CTL bit definition
. . . . . . . . . . . . . . . . . . . . . . . . .
26
17
Priority/Preemption enabled
18
Priority/Preemption not enabled
19
NAA identifiers
20
Association_Header Validity bits (Bits 63-56)
21
P_BSY Reason Codes
22
P_RJT or F_RJT Reason Codes
23
Basic Link Service Commands
24
Extended Link Service Commands
. . . . . . . . . . . . . . . . . .
32
25
Extended Link Service Commands
. . . . . . . . . . . . . . . . . .
33
26
RTV Payload
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
27
RTV Accept Payload
28
LS_RJT reason code explanation
29
RNC/ACC Payload
30
Capability Entry
31
Document Identifiers
32
Responses to FLOGI frame (S_ID = 0 or 0000yy) - Fabric Login
33
N_Port Common Service Parameter Applicability
. . . . . . . . . . . . . . . . . . . . . .
26
. . . . . . . . . . . . . . . . . . . .
26
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
. . . . . . . . . . . .
29
. . . . . . . . . . . . . . . . . . . . . . . .
30
. . . . . . . . . . . . . . . . . . .
30
. . . . . . . . . . . . . . . . . . . .
31
. . . . . . . . . . . . . . . . . . . . . . . . .
34
. . . . . . . . . . . . . . . . . . .
35
. . . . . . . . . . . . . . . . . . . . . . . . . .
36
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
. . . . . . . . . . . . . . . . . . . . . . . . .
38
. . .
44
. . . . . . . . . . .
47
xv
Page
34
FC-PH-3 Version
35
N_Port Class Service Parameter Applicability
. . . . . . . . . . . . .
50
36
N_Port Class Service Parameter Applicability
. . . . . . . . . . . . .
51
37
Exchange Status Block
. . . . . . . . . . . . . . . . . . . . . . . .
59
38
Sequence Status Block
. . . . . . . . . . . . . . . . . . . . . . . .
59
39
Responses to Preemption Requests
40
CSS_CC Payload
41
CSS_CC Accept Payload
42
Data Character Translation
43
CSS_SC Payload
44
CSS_SC Accept Payload
xvi
. . . . . . . . . . . . . . . . . . . . . . . . . . .
48
. . . . . . . . . . . . . . . . .
64
. . . . . . . . . . . . . . . . . . . . . . . . . . .
77
. . . . . . . . . . . . . . . . . . . . . . .
77
. . . . . . . . . . . . . . . . . . . . . .
78
. . . . . . . . . . . . . . . . . . . . . . . . . . .
78
. . . . . . . . . . . . . . . . . . . . . . .
79
Page
Figures
1
Document relationship
. . . . . . . . . . . . . . . . . . . . . . . . .
xx
Fabric Regions
FC-4 Regions
FC-0 with 75W unbalanced cable
. . . . . . . . . . . . . . . . . . . .
Unbalanced transmitter test circuit
. . . . . . . . . . . . . . . . . . . .
Eye diagram mask at point-S
. . . . . . . . . . . . . . . . . . . . . .
10
Eye diagram mask at point-R
. . . . . . . . . . . . . . . . . . . . .
10
FC-0 with 150W balanced cable link
Balanced transmitter test circuit
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
12
. . . . . . . . . . . . . . . . . . . .
12
10
Style-1 balanced connector pin assignments
. . . . . . . . . . . . .
12
11
Style-2 plug
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
12
Style-2 receptacle
13
Style-2 balanced connector receptacle pin locations
14
Balanced cable wiring
15
Optional headers order
16
Association_Header
17
FLOGI, PLOGI, or ACC Payload
18
N_Port Common Service Parameters - Fabric Login
. . . . . . . . .
48
19
N_Port Common Service Parameters - N_Port Login
. . . . . . . . .
49
20
N_Port Class Service Parameters - Fabric Login
. . . . . . . . . . .
52
21
N_Port Class Service Parameters - N_Port Login
. . . . . . . . . .
53
22
F_Port Common Service Parameters - Fabric Login
. . . . . . . . .
54
23
F_Port Class Service Parameters - Fabric Login
. . . . . . . . . . .
55
24
Class 6 Multicast Routing
. . . . . . . . . . . . . . . . . . . . . . .
68
25
. . . . . . . . . . . . . . . . . . . . . . .
70
26
Clock Synchronization Model
27
. . . . . . . . . . . . . . . . . . . . . . . . . . .
14
. . . . . . . . .
15
. . . . . . . . . . . . . . . . . . . . . . . . .
19
. . . . . . . . . . . . . . . . . . . . . . . .
28
. . . . . . . . . . . . . . . . . . . . . . . . . .
29
. . . . . . . . . . . . . . . . . . .
45
. . . . . . . . . . . . . . . . . . . . .
73
Real Time Loop Topology
. . . . . . . . . . . . . . . . . . . . . . .
91
28
Real Time Protocol Stack
. . . . . . . . . . . . . . . . . . . . . . .
92
29
Failure Detect and Re-routing
30
TDM Window
. . . . . . . . . . . . . . . . . . . . .
92
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
xvii
Foreword
(This Foreword is not part of dpANS X3.xxx-199x.)
This Fibre Channel, Physical and Signalling Interface - 3 standard (FC-PH-3) describes the enhancements to the ANSI X3.230 FC-PH and X3.297 FC-PH-2 and
is an addendum to both these documents.
This standard was developed by Task Group X3T11 of Accredited Standards
Committee X3 during 1995-6. The standards approval process started in 1996.
This standard includes annexes, which are informative, and are not considered
part of the standard.
Requests for interpretation, suggestions for improvement or addenda, or defect
reports are welcome. They should be sent to the X3 Secretariat, Information
Technology Industry Council, 1250 Eye Street, NW, Suite 200, Washington, DC
20005.
NOTE: The developers of this standard have requested that holders of patents that may be
required for the implementation of the standard, disclose such patents to the publisher.
However neither the developers nor the publisher have undertaken a patent search in order
to identify which if any patents may apply to this standard. No position is taken with respect
to the validity of any claim or any patent rights that may have been disclosed. Details may
be obtained from the publisher concerning any statement of patents and willingness to
grant a license on a nondiscriminatory basis and with reasonable terms and conditions to
applicants desiring to obtain such a license.
This standard was processed and approved for submittal to ANSI by Accredited
Standard Committee on Information Processing Systems, X3. Committee approval of the standard does not necessarily imply that all committee members voted
for approval. At the time it approved this standard, the X3 Committee had the following members:
TBD, Chair
TBD, Vice-Chair
TBD, Secretary
Organization Represented
Name of Representative
TBD ............................................................................................. TBD
TBD
Task Group X3T11 on Device Level Interfaces, which developed this standard,
had the following participants:
Roger Cummings, Chair
Carl Zeitler, Vice-Chair
Bryan Cook, FC-PH-3 Technical Editor
xviii
Introduction
Introduction
A set of advanced capabilities to FC-PH and FC-PH-2 are provided in FC-PH-3 to
support some sophisticated application requirements.The advanced capabilities
include features such as:
Class 3 process policy
Time distribution and clock synchronization
E_D_TOV resolution enhancement
Addition of new Extended Link Services:
Report Node Capability information
Expanded copper media variants
Class 6 service (Uni-directional Dedicated Connection)
Priority and Preemption capabilities
and others
These capabilities are accomplished by defining FC-3 Common Services, and
enriching and complementing FC-2 Signaling protocol and FC-0 physical media
and transceivers defined in FC-PH and FC-PH-2:
FC-3 defines a set of services which are common across multiple ports of a
node.
FC-2 enhancements include E_D_TOV resolution refinements, Process error
policy extensions, especially for Class 3, Time distribution, Clock synchronization, new Extended Link Service commands, and others.
FC-0 enhancements define new variants for the copper media
Figure shows the relationship of this American National Standard (the highlighted
rectangle) with other Fibre Channel standards and draft proposed standards. FCPH-3 specifies the enhanced functions added to FC-PH, FC-PH-2. FC-FG and
FC-SW are related to Fabric requirements. FC-AL specifies the arbitrated loop topology. FC-GS is related to Fibre Channel Services requirements. FC-IG provides
some implementation guidance. FC-SB; ANSI X3.254, FC-FP; FC-LE; FC-ATM;
IPI-3 Disk revision; IPI-3 Tape revision and SCSI-FCP are FC-4 standards.
xix
FC-SB
Mapping to Single Byte
Command Code Sets
FC-LE
Link
Encapsulation
IPI-3 Disk
Revision to
IPI-3 Disk Std.
Other
FC upper-layer
protocols
FC-FP
Mapping to HIPPI
Framing Protocol
FC-ATM
Mapping of
ATM/AAL5
IPI-3 Tape
Revision to
IPI-3 Tape Std.
SCSI-FCP
SCSI-3 Fibre
Channel Protocol
FC-PH-3
Fibre Channel Physical
and Signalling Interface - 3
FC-PH-2 (ANSI X3.xxx)
and Signalling Interface - 2
FC-PH (ANSI X3.230)
and Signalling Interface
FC-IG
Fibre Channel
Implementation Guide
FC-AL
Arbitrated Loop
FC-SW
Switch Topology
FC-FG
Fabric Generic requirements
FC-GS
Generic Services
Document relationship
xx
dpANS X3.xxx-199x
draft proposed AMERICAN NATIONAL STANDARD
draft proposed American National Standard

for Information Technology
Fibre Channel
Physical and Signalling Protocol - 3 (FC-PH-3)
Scope
FC-PH-3 describes the enhancement to the

ANSI X3.230, FC-PH and to the ANSI X3.xxx,
FC-PH-2 and is an addendum to the FC-PH
and FC-PH-2 documents.
Normative References
The following standards contain provisions

which, through reference in this text, constitute
pro visio ns of th is s tan da rd. At th e time of
publication, the editions indicated were valid. All
standards are subject to revision, and parties to
agreements based on this standard are encouraged to investigate the possibility of applying the
most recent editions of the standards listed below.
Copies of the following documents can be obtained from ANSI: Approved ANSI standards, approved and draft international and regional
standards (ISO, IEC, CEN/CENELEC, ITUT),
an d a pp ro ved a nd dra ft for eign stan d ard s
(including BSI, JIS, and DIN). For further information, contact ANSI Customer Service Department at 212-642-4900 (phone), 212-302-1286
(fax) or via the World Wide Web at http://www.ansi.org.
2.1
Approved references
ANSI X3.230-1994, Fibre Channel Physical and

Signalling Interface (FC-PH)
This document is an extension to the FC-PH

and FC-PH-2 standards and describes a set of
advanced capabilities beyond both FC-PH and
FC-PH-2 to support more advanced and specialized applications.
X3.702D-199x - High Performance Parallel Interface Framing Protocol (HIPPI-FP)

2.2
References uder development
At the time of publication, the following referenced standards were still under development. For information on the current status of
the documents, or regarding availability, contact the relevant standards body or other organization as indicated.2
ANSI X3.xxx-199x, Fibre Channel Physical and
Signalling Protocol - 2 (FC-PH-2)
ANSI X3.xxx-199x, Fibre Channel-Fabric Requirements (FC-FG)
ANSI X3.xxx-199x, Fibre Channel-Arbitrated
Loop (FC-AL)
ANSI X3.xxx-199x, Fibre Channel-Switch Topology (FC-SW)
ANSI X3.xxx-199x, Fibre Channel-SBCC Mapping Protocol (FC-SB)
ANSI X3.xxx-199x, Fibre Channel-Link Encapsulation (FC-LE)
ANSI X3T10/995D, SCSI-3 Primary Commands

ANSI X3.131-199x - Small Computer System Interface (SCSI-2)
X3.132-1990 - Intelligent Peripheral Interface
(IPI-3)
2.
For information about obtaining copies of

these documents or more information on the
current status of these documents, contact
the X3 Secretariat at: http://www.x3.org or
202-626-5738.
1
dpANS X3.xxx-199x
Definitions and conventions
For F C-PH -3 , the follo wing de fin itions,

conventions, abbreviations, acronyms, and
symbols apply, in addition to those defined in
X3.230-1994 (FC-PH) and X3.xxx-1995 (FC-PH2).
3.1
Definitions
3.1.1
FC-4 Region
A set of N_Ports connected either point-to-point

or to a common Fabric, such that any N_Port in
the set can successfully complete the N_Port Login procedure with all other N_Ports in the set
and successfully maintain an Exchange for a
particular FC-4.
3.1.2
Profile
An interoperability specification that provides implementation guidelines for systems maufacturers, system integrator s, component
manufacturers, and users seeking to design and
select interoperable Fibre Channel peripherals,
hosts, and components. A Profile specifies particular settings for various Fibre Channel physical, link-level, and upper-level protocol options to
enhance interoperability.
3.2
Editorial conventions
En h a n c e me n t s t o co n v e n t io n s d e fi n e d i n
X3.230-1994 (FC-PH) and X3.xxx-1995 (FC-PH2) are specified.
3.3
Abbreviations, acronyms and symbols
Abbreviations, acronyms and symbols applicable

to this standard are listed. Definitions of several
of these items are included in 3.1 The index at
the back of the document is an aid to help locate
these terms in the body of the document.
3.3.1
Acronyms and other abbreviations
NTP
Network Time Protocol
REQCS
Request Clock Synchronization
RNC
Report Node Capability
P_AS
Process_Associator
O_AS
Operation_Associator
dpANS X3.xxx-199x
Structure and concepts
This clause provides an overview of the structure, concepts, and mechanisms used in FCPH-3 and is intended for informational purposes only.
4.16
FC-4 Regions
FC-FG defines a Region as a section of a SubFabric such that all the N_Ports in that Region
operate at the same data rate and the same
Class of Service. Additionally, the N_Ports within the Region share the same Regional Service
Parameters, e.g., address assignment mode,
in-order frame delivery. Essentially, this means
that all N_Ports within a Region are able to successfully perform the PLOGI procedure with
each other. Figure 110 illustrates a set of N_
Ports across 2 Regions: N_Ports A, B, C, and D
are in Region 1 because they all support Class
1 at 1 Gbit/second. N_Ports D, E, and F are in
Region 2 because they all support Class 2 at 1
Gbit/second. Note that N_Port D is in both Regions.
However, just because a pair of N_Ports can
execute a PLOGI-ACC with each other does
not guarantee that they can successfully perform an FC-4 Exchange. For example, N_Port
B that requires an Initial Process_Associator is
not capable of communicating with N_Port A
that does not support the Initial Process_Associator.
Region 2
Region 1
N_Port A
Class 1
1 GB/sec
P_AS not supported
N_Port D
Class 1 & 2
1 GB/sec
P_AS Supported
N_Port E
Class 2
1 GB/sec
P_AS not supported
N_Port B
Class 1
1 GB/sec
P_AS Required
N_Port C
Class 1
1 GB/sec
P_AS Supported
N_Port F
Class 2
1 GB/sec
P_AS not supported
Figure 110 Fabric Regions
dpANS X3.xxx-199x
Therefore, the term FC-4 Region is used to define a set of N_Ports within a Fabric Region
which can successfully communicate via FC-4
Exchanges. That is, all their PLOGI Service Parameters are such that they can successfully
originate an Exchange for the purpose of supporting an FC-4 protocol. Figure 111 illustrates
the same set of N_Ports, now in 3 FC-4 Regions: N_Ports A, C, and D are in Region 1 because they all support Class 1 at 1 Gbit/second
and they all will not use the Initial Process Associator, as determined by PLOGI. N_Ports D,
E, and F are in Region 2 because they all support Class 2 at 1 GBit/second and they all will
not use the Initial Process Associator, as determined by PLOGI. N_Ports B, C, and D are in
Region 3 because they all support Class 1 at 1
Gbit/second and they all will use the Initial Process Associator, as determined by PLOGI.
Region 2
Region 1
N_Port A
Class 1
1 GB/sec
P_AS not supported
N_Port D
Class 1 & 2
N_Port E
Class 2
1 GB/sec
P_AS Supported
1 GB/sec
P_AS not supported
N_Port B
N_Port C
N_Port F
Class 1
1 GB/sec
P_AS Required
Class 1
1 GB/sec
P_AS Supported
Class 2
1 GB/sec
P_AS not supported
Region 3
Figure 111 FC-4 Regions
dpANS X3.xxx-199x
FC-0 functional characteristics
The third unordered list item in 5.1 is replaced

as described.
5.1
General Characteristics
FC-0 has the following general characteristics:
No change from FC-PH.
No change from FC-PH-2.
The FC-2 protocol is designed to operate

across connections having a BER detected at
the receiving node of 10 -12 . It shall be the
combined responsibility of the component
vendors and the system integrator to ensure
that this level of service is provided in a given
Fibre Channel installation.
Optical fibre interface specification
No enhancements from X3.230-1994 (FC-PH)

or x3.xxx-1995 (FC-PH-2).
dpANS X3.xxx-199x
7 Electrical cable interface specification

This clause defines the interfaces of the serial
electrical signal at the interconnect receptacles.
Each conforming electrical FC attachment shall
be compatible with this serial electrical interface
to allow interoperability within an FC environment. All Fibre Channel links described in this
clause shall operate within the BER objective
(10-12). The parameters specified in this clause
support meeting that requirement under all conditions including the minimum input and output
amplitude levels. The corresponding cable plant
specifications are described in clause 9.
The link distance capability specified in table 10
is based on insuring interoperability across multiple vendors supplying the technologies (both
link transceivers and cable plants) under the tolerance limits specified in the document. Links
Table 10 FC-0 physical links for electrical cable classes
FC-0
Units
100-LV-EL-S
100-TV-EL-S
100-MI-EL-S
100-TP-EL-S
100-TW-EL-S
Data Rate
Nominal Bit Rate
Tolerance
MB/s.
MBaud
ppm
100
1 062,5
100
50
531,25
100
25
265,625
100
12,5
132,812 5
100
meters
meters
meters
meters
meters
0-24
0-20
0-5.6
0-11
0-13
0-33
0-28
0-7.6
0-16
0-18
0-47
0-40
0-11
0-22
0-26
0-67
0-56
0-16
0-32
0-37
meters
meters
meters
meters
meters
0-59
0-50
0-14
0-28
0-33
0-84
0-71
0-19
0-40
0-46
0-100
0-100
0-28
0-57
0-66
0-100
0-100
0-42
0-80
0-93
(nom.)
(nom.)
(nom.)
(nom.)
(nom.)
75
75
75
150
150
75
75
75
150
150
75
75
75
150
150
75
75
75
150
150
ps
ps
100
800
200
1000
400
1200
800
1400
7515
15030
7515
15030
7515
15030
7515
15030
755
15010
755
15010
755
15010
755
15010
Operating Distance
Intracabinet
LV
TV
MI
TP
TW
Intercabinet
LV
TV
MI
TP
TW
Cable Impedance
LV
TV
MI
TP
TW
Link Impedance @ S
TDR Rise Time
Exception Window
Through Connection
Unbalanced
Balanced
Cable
Unbalanced
Balanced
50-LV-EL-S
50-TV-EL-S
50-MI-EL-S
50-TP-EL-S
50-TW-EL-S
25-LV-EL-S
25-TV-EL-S
25-MI-EL-S
25-TP-EL-S
25-TW-EL-S
12-LV-EL-S
12-TV-EL-S
12-MI-EL-S
12-TP-EL-S
12-TW-EL-S
dpANS X3.xxx-199x
Table 10 FC-0 physical links for electrical cable classes (continued)
100-LV-EL-S
100-TV-EL-S
100-MI-EL-S
100-TP-EL-S
100-TW-EL-S
50-LV-EL-S
50-TV-EL-S
50-MI-EL-S
50-TP-EL-S
50-TW-EL-S
25-LV-EL-S
25-TV-EL-S
25-MI-EL-S
25-TP-EL-S
25-TW-EL-S
FC-0
Units
Transmitter (S)
Output characteristics at the cable connector

(when transmitting any primitive signal or sequence)
Type
Amplitude
Intracabinet
Max
Min
Intercabinet
Max
Min
Deterministic Jitter
Random Jitter
Rise/Fall Time 20-80%
maximum
minimum
Imbalance
Skew
Receiver (R)
Minimum Sensitivity
Input Impedance @ R
TDR Rise Time
Exception Window
Through Connection
Unbalanced Inputs
Balanced Input
At Termination
Unbalanced Inputs
Balanced Inputs
Differential Skew
12-LV-EL-S
12-TV-EL-S
12-MI-EL-S
12-TP-EL-S
12-TW-EL-S
ECL/PECL
ECL/PECL
ECL/PECL
ECL/PECL
mV(p-p)
mV(p-p)
1600
600
1600
600
1600
600
1600
600
mV(p-p)
mV(p-p)
%(p-p)
%(p-p)
2000
1100
10
12
2000
1100
10
12
2000
1100
10
8
2000
1100
10
8
ps
ps
385
100
772
200
1540
400
3020
800
ps
25
50
100
200
Input characteristics at the cable connector

(when receiving any primitive signal or sequence)
mV(p-p)
400
400
400
400
ps
ps
100
800
200
1000
400
1200
800
1400
7515
15030
7515
15030
7515
15030
7515
15030
ps
755
15010
200
755
15010
400
755
15010
800
755
15010
1600
operating at these maximum distances may require some form of equalization in the cable
plant to meet all link requirements. Greater link
distances may be obtained by specifically engineering a link based on knowledge of the technology characteristics and the conditions under
which the link is installed and operated. However, such link distance extensions are outside the
scope of this standard.
The user needs to take care that their use conditions at least conform to the specified signal
conditions of the document
7.1
Electrical data links
The electrical data link definitions apply to all

styles of unbalanced cable (the 75 LV, TV, and
MI style coax), and balanced cable (the 150
TP and TW cables). The electrical characteristics of these links are defined in tables 10, 11,
and 12, and in figures 29 and 30.
The operating distance limits listed in table 10
are based on the minimum launch amplitude,
delivered to a receiver requiring the minimum input amplitude, through a cable having the loss
characteristics listed in clause 9.
dpANS X3.xxx-199x
b
TY
BNC
75
COAX
TX
TRANSMIT
NETWORK
RX
TNC
RECEIVE
NETWORK
RY
Figure 27 FC-0 with 75 unbalanced cable

NOTE All specifications, unless specifically listed
otherwise, are based on differential measurements.
NOTE All times indicated for TDR measurements are recorded times. Recorded times are
twice the transit time of the TDR signal.
NOTE The transmit imbalance skew and receiver differential skew are the maximum allowed time
difference (on both low-to-high and high-to low
transitions) between the true and complement signals. This time difference is measured at the midway point on the signal swing of the true and
complement signals. These are single ended measurements.
NOTE The transmitter imbalance skew measurement is only valid for balanced driver configurations. It defines the maximum timing difference, as
measured at point-S, of the true and complement
signals generated by the balanced media driver.
The differential skew specification at the receiver
consists of this same measurement made at pointR. The receiver skew requirement assumes a
combined maximum transmitter and maximum cable skew.
NOTE The link impedance measurement identifies the impedance mismatches present in the cable plant when terminated in its characteristic
impedance. This measurement includes mated
connectors at both ends of the cable (points S/S
and R/R) and any intermediate connectors or
splices between these locations. The link termination shall match that shown in figures 28 and 32.
NOTE The exception window used with specific
impedance measurements identifies the maximum
time period during which the measured impedance
is allowed to exceed the listed impedance tolerance.
NOTE The maximum excursion within the exception window at points-S and -R shall not exceed 33% of the nominal cable impedance.
NOTE The link impedance at point-S, for the cable, shall be recorded 4,0 ns following the reference location determined by an open connector
between point-S and S.
NOTE The input impedance at point-R, for the

termination, shall be recorded 4,0 ns following the
reference location determined by an open connector between point-R and R
NOTE The transmitter amplitude maximum
specification identifies the maximum p-p signal
that can be delivered into a resistive load matching
that shown in figures 28 and 32.
NOTE The transmitter amplitude minimum specification identifies the minimum allowed p-p eye
amplitude opening that can be delivered into a resistive load matching that shown in figures 28 and
32.
NOTE The transmitter jitter specifications are
presently under review and may change in a future
release of this standard.
NOTE The receiver sensitivity identifies the minimum p-p eye amplitude at point-R to meet the
BER objective.
NOTE The maximum operable distance for a
specific link type is calculated by dividing the loss
per meter at the half-Baud frequency (listed in
clause 9), into the available link-loss budget. This
loss budget is calculated as 20log(output_amplitude/min_input_amplitude) for a specific link implementation.
All styles of unbalanced (coaxial) cables are interoperable; i.e., electrically compatible with minor impact on link-length capability when
intermixed. The balanced (TP and TW) cables
are also interoperable. Interoperability implies
that the transmitter and receiver level specifications, as measured in figures 27 and 31, and defined in tables 10, 11, and 12, are preserved with
the trade-off being distance capability in an intermixed system. Other electrically compatible,
interoperable unbalanced or balanced cables
may be used to achieve goals of longer distance, higher data rate, or lower cost as desired
in the system implementation, provided that
they are connector, impedance, and propagation mode compatible.
dpANS X3.xxx-199x
The balanced cables are incompatible with unbalanced cables in terms of characteristic impedance, mode of connection to the transceiver,
and other electrical and mechanical parameters.
Different connectors are specified for balanced
and unbalanced cables to avoid user mixing.
Schematics in the diagrams in this clause are for
illustration only and do not represent the only
feasible implementation. The links described in
this clause shall be applied only to homogenous
ground applications such as between devices
within a cabinet or rack, or between cabinets interconnected by a common ground return or
ground plane. This restriction minimizes safety
and interference concerns caused by any voltage differences that could otherwise exist between equipment grounds.
The recommended interface to electrical transmission media is via transformer coupling for intercabinet connections and via capacitive
coupling for intracabinet connections.
7.2
Reference locations
All interface specifications are only valid at the

point of entry and exit from the equipment.
These points are identified as point-S, -S, -R,
and -R in all related tables and figures. This assumes that all measurements are made after a
mated connector pair, relative to the source or
destination.
7.2.1
Intercabinet references
The reference points for all connections between cabinets are those points-S, -S,- R, and R where the cabinet Faraday shield transitions
between the cabinet and the cable shield. If sections of transmission line exist within the Faraday shield, they are considered to be part of the
associated transmit or receive network, and not
part of the cable plant.
7.2.2
Intracabinet references
The reference points for all connections within a

cabinet are those points-S, -S, -R, and -R
where the serial data signal passes through its
first mateable connector.
7.3
7.3.1
tics
75 unbalanced data links

ECL compatible driver characteris-
TX
TY
TRANSMIT
NETWORK
75 1%
Figure 28 Unbalanced transmitter test

circuit
ic (ECL), as mea sured at point-b. Fo r all
intercabinet links, the output driver shall be AC
coupled to the cable through a transmission network, and have output levels, measured at the
input to the cable (point-S), as listed in table 11,
when terminated as shown in figure 28. For all
intracabinet links the driver my be either AC or
DC-coupled to the media.
The mask of the transmitter eye diagram is given in figure 29. The normalized transmitter outp ut timing and diffe ren tial amp litu de
requirements are specified in tables 10 and 11.
The Y1 and Y2 amplitudes in table 11 are set to
allow signal overshoot of 10% and undershoot
of 20%, relative to the amplitudes determined to
be a logic 1 and 0.
NOTE The normalized 1 is that amplitude determined to be the average amplitude when driving a
logic 1. The normalized 0 is that amplitude determined to be the average amplitude when driving a
logic 0.
7.3.2
tics
ECL compatible receiver characteris-
The receiver shall be AC-coupled to the media

through a receive network located between
points-R and -c as shown in figure 27. The receive network shall terminate the link by an
equivalent impedance of 75.
An optional equalizer network, when present in
a link, shall exist and operate as part of the cable
plant. It shall be used to correct for frequency
selective attenuation loss of the transmitted signal, as well as timing variations due to the differences in propagation delay time between higher
and lower frequency components. An equalizer
should need no adjustment. A more detailed discussion of an equalizer is found in Annex F.
The output driver is assumed to have output levels approximating those of Emitter Coupled Log9
dpANS X3.xxx-199x
Table 11 Eye diagram mask at point-S
Normalized
Time
Normalized
Amplitude
X1
X2
Y1
Y2
132,818 5
0,09
0,29
0,2
0,1
300 mV
800 mV
550 mV
1000 mV
265,625
0,09
0,29
0,2
0,1
300 mV
800 mV
550 mV
1000 mV
531,25
0,11
0,30
0,2
0,1
300 mV
800 mV
550 mV
1000 mV
1 062,5
0,11
0,30
0,2
0,1
300 mV
800 mV
550 mV
1000 mV
Bit rate
(MBaud)
Intracabinet
Differential Amplitude
A (minimum) B (maximum) A (minimum) B (maximum)
The receiver shall operate within the BER objective (10-12) when an unbalanced data link is driven by a transmitter meeting the requirements
defined in tables 10, 11, and figure 29, and a signal is delivered to the receiver meeting the eye
diagram requirements specified in table 12 and
figure 30.
The unbalanced data link characteristics of
maximum path penalty and input impedance of
the receiver are specified in table 10.
The mask of the receiver eye diagram is given in
figure 30. The receiver input is specified in table
12.
NOTE The receiver (at point-c) must accommodate 10% of a bit period more total jitter than that
listed in table 12. This 10% jitter allocation is to allow for any external EMI induced events.
NOTE The minimum input amplitude to the receiver listed in table 12 is a worst case specification across all e nvironmental cond itions.
Restricted environments may allow operation at
lower minimum differential voltages, allowing significantly longer operating distances.
0.5
0V
Y1
-A
0
-B
0
1-x2 1-x1 1
Normalized Time
Figure 29 Eye diagram mask at point-S
x1 x2
X1
132,818 5 0,30
X2
Y1
Y2
0,6
200 mV
1000 mV
265,625
0,30
0,6
200 mV
1000 mV
531,25
0,30
0,6
200 mV
1000 mV
1 062,5
0,30
0,6
200 mV
1000 mV
7.3.3
Unbalanced cable characteristics
The 75 unbalanced data links may be interconnected using any specified unbalanced cable depending on the performance and distance
required for a specific application.
The cable shield(s) shall be grounded through
the bulkhead connectors on both the transmitter
and receiver ends as shown in figure 27.
1-Y1
Normalized Amplitude
Bit rate
(MBaud)
Y2
-Y2
10
Table 12 Eye diagram mask at point-R
1+Y2
Intercabinet
Y1
0
-Y1
-Y2
0
1
x2 1-x1
x1
Normalized Time
Figure 30 Eye diagram mask at point-R
dpANS X3.xxx-199x
7.3.4
Unbalanced cable connectors
7.3 .4.1 Intercabinet connec tors for

unbalanced cable
Connections between cabinets require the use
of shielded cable assemblies, terminated in polarized shielded connectors. All unbalanced cable types shall be connected using either style-1
or style-2 unbalanced connectors.
Standard cable assembles shall have either
proper varieties of style-1 connectors at both
ends of the cable, or style-2 connectors at both
ends of the cable. Cables may also be constructed with both a style-1 and style-2 connector for use in mixed installations or to adapt from
one style to the other.
The cable connector shall be the plug or male
connector while the bulkhead connector shall be
the receptacle or female connector.
The style-1 connectors for unbalanced cable
shall be industry standard 75 BNC and TNC
type connectors, as shown in figure 27. The
electrical performance of the 75 BNC and TNC
connectors shall be compatible with video style
connectors specified by IEC 169-8 and IEC 16917.
The mechanical compatibility for BNC type (bayonet lock coupling) connectors is defined by IEC
169-8. The mechanical compatibility for TNC
type (threaded coupling) connectors is defined
by IEC 169-17. Primary use of unbalanced cables are for interconnection of cabinets.
These two connector types (BNC and TNC) are
specified to provide polarization to prevent the
incorrect connection of transmitter-to-transmitter or receiver-to-receiver. The end of such a cable, connected to an unbalanced transmitter,
shall be implemented with a male BNC-type
connector and the receiving end shall be implemented with a male TNC-type connector. The
transmitter and receiver shall be implemented
using female BNC and TNC type connectors respectively.
Should a case occur where, through a cabling
error or the incorrect use of in-line splices or other adapters, two transmitters or receivers are directly connected, no damage shall occur to any
transmitter, receiver, or other link component in
the system. The link shall be able to withstand
such an invalid connection without component

failure or degradation for an indefinite period of
time.
The style-2 connectors for unbalanced cable
shall be industry standard 50 SMA. The electrical performance of the 50 SMA connectors
shall be compatible with IEC 169-15.
The mechanical compatibility for SMA-type connectors is defined by IEC 169-15. Primary use of
unbalanced cables are for interconnection of
cabinets.
Both ends of such a cable shall be implemented
with a male SMA-type connector. The transmitter and receiver shall be implemented using female SMA-type connectors.
error or the incorrect use of in-line splices or other adapters, two transmitters or receivers are directly connected, no damage shall occur to any
transmitter, receiver, or other link component in
the system. The link shall be able to withstand
such an invalid connection without component
failure or degradation for an indefinite period of
time.
7.3.4.4 Intracabinet connectors for
unbalanced cable
Connections within a cabinet do not normally require the same level of shielding as connections
external to a cabinet. For these internal connections an alternate connector may be used that
interfaces with industry standard headers with
0,64 mm (0,025 in) square posts on 2,54 mm
(0,100 in) center spacing. Due to size constraints this connector is only intended to be
used with the miniature coaxial cable.
These connectors are generally not entirely
shielded and leakage of RFI may occur. A
shielded cabinet and/or other RF leakage control techniques such as ferrite beads or lossy
tubing are recommended for compliance with
EMC standards, even with double shielded cables (refer to Annex F).
7.4
7.4.1
tics
150 balanced data links

ECL compatible driver characteris-
The output driver is assumed to have Emitter

Coupled Logic (ECL) output levels, as mea11
dpANS X3.xxx-199x
b
SHIELDED
BALANCED PAIR
ZO=150
TX
RX
RECEIVE
TRANSMIT
NETWORK
TY
NETWORK
RY
Figure 31 FC-0 with 150 balanced cable link

sured at point-b. For all intercabinet links, the
output driver shall be AC-coupled to the media
through a transmission network, and have complementary outputs with outputs levels, measured at the input to the media (point-S) as listed
in tables 10 and 11, when terminated as shown
in figure 32. For all intracabinet links the driver
may be either AC- or DC-coupled to the media.
Measurements are to be made using an oscilloscope whose bandwidth including probes is at
least 1,8 times the Baud rate.
The mask of the transmitter eye diagram is given in figure 29. The transmitter output is specified in tables10 and 11.
7.4.2
tics
ECL compatible receiver characteris-
The receiver shall be AC-coupled to the media

through a receiver network located between
points-R and -c as shown in figure 31. The receive network shall terminate the link by an
equivalent impedance of 150.
An optional equalizer network, when present in
a link, shall exist as part of the cable plant. It
shall be used to correct for timing variations due
to the differences in propagation delay time beb
TY
TRANSMIT
NETWORK
The balanced data link characteristics of maximum path penalty and input impedance of the
receiver are specified in table 10.
The mask of the receiver eye diagram is given in
figure 30. The receiver input is specified in table
12.
NOTE The receiver (at point-c) must accommodate 10% of a bit time more total jitter than that listed in table 12. This10% jitter allocation is to allow
for any external EMI induced events.
7.4.3
Balanced cable characteristics
The 150 balanced links may be interconnected using either TP or TW cable, depending on
the performance, distance, or application required for a specific link.
5
1 = Transmit +
9
+
TRANSMIT
75 1%
Figure 32 Balanced transmitter test circuit
12
The receiver shall operate within the BER objective (10-12) when a balanced data link is driven
by a transmitter meeting the requirements defined in tables 10, 11, and figure 29, and a signal
is delivered to the receiver meeting the eye diagram requirements in table 12 and figure 30.
S
75 1%
TX
tween higher and lower frequency components,

as well as frequency selective attenuation loss
of the transmitted signal. An equalizer should
need no adjustment. A more detailed discussion
of the equalizer is found in Annex F.
6 = Transmit 5 = Receive +
9 = Receive Shell = Cable Shield
Figure 33 Style-1 balanced

connector pin assignments
dpANS X3.xxx-199x
Cable shield(s) shall be grounded through the
bulkhead connector shell(s) on both the transmitter and receiver ends as shown in figure 31.
7.4.4
Balanced cable connectors
7.4.4 .1 Interc abinet c onne ctors for

balanced cable
Connections between cabinets require the use
of shielded cable assemblies, terminated in polarized shielded connectors. Both the TP and
TW cable types shall be connected using either
the style-1 or style-2 balanced cable connectors.
Standard cable assemblies shall have either
style-1 connectors at both ends of the cable, or
style-2 connectors at both ends of the cable.
Cables may also be constructed with both a
style-1 and style-2 connector for use in mixed
connector installations or to adapt from one
style to the other.
The cable connector shall be the plug or male
connector while the bulkhead connector shall
be the receptacle or female connector.
7.4.4.2 Style-1 balanced cable connector
The style-1 connector for balanced cables is
the 9-pin shielded D-subminiature connector
conforming to IEC 807-3. The plug (male) half
of the connector shall be mounted on the cable.
One connector is required to connect both
transmitting and receiving shielded pairs at one

node. The connector pin assignments are
shown in figure 33. Unused pin positions within
the connector body are reserved.
The electrical conformance and mechanical
compatibility for D-subminiature type connectors is defined by IEC 807-3.
error or the incorrect use of in-line splices or
other adapters, two transmitters or receivers
are directly connected, no damage shall occur
to any transmitter, receiver, or other link component in the system. The link shall be able to
withstand such an invalid connection without
component failure or degradation for an indefinite period of time.
7.4.4.3 Style-2 balanced cable connector
The style-2 connector for balanced cables is dimensionally defined by figures 34 and 35. The
connector pin assignments are shown in figure
36.
error or the incorrect use of in-line splices or
other adapters, two transmitters or receivers
are directly connected, no damage shall occur
to any transmitter, receiver, or other link component in the system. The link shall be able to
withstand such an invalid connection without
Figure 34 Style-2 plug
13
dpANS X3.xxx-199x
Figure 35 Style-2 receptacle

component failure or degradation for an indefinite period of time.
7.4.4.3.1 Style-2 plug
The plug (male) half of the connector shall be
mounted on the cable. One connector is required to connect both the transmitting and the
receiving shielded pairs at one node. The style2 plug is dimensionally defined in figure 34.
7.4.4.3.2 Style-2 receptacle
The style-2 receptacle is dimensionally defined
in figure 35. This connector mates with both
transmit and receive balanced pairs. Unused pin
14
positions within the connector body are reserved. The connector contains eight pin locations plus an external shield. Pin locations 1, 3,
6, and 8 shall be populated in the connector
body.
7.4.4.4 Optional intercabinet connector pins
Both styles of intercabinet connectors may be
populated with additional contacts to support
additional functions. The presence of such contacts in the connector assemblies does not imply support for additional functions.
The suggested use for these additional contacts
or contact locations is listed in table 12 .
dpANS X3.xxx-199x
Table 13 Optional intercabinet contact
uses
Pin Number
Contact Name
Style 1 Style 2
Power supply,
nominal +5VDC
Module fault detect
Mechanical key
Output disable
Signal ground/+5VDC return
tions an alternate connector may be used that

interfaces with industry standard headers with
0,64 mm (0,025 in) square posts on 2,54 mm
(0,100 in) center spacing. Due to size constraints this connector may not assemble well
with all variations of balanced cable.
These connectors are generally not entirely
shielded and leakage of RFI may occur. A
shielded cabinet and/or other RF leakage control techniques such as ferrite beads or lossy
tubing are recommended for compliance with
EMC standards, even with double shielded cables (refer to Annex F).
7.4.4 .5 Intrac abinet c onne ctors for

balanced cable
Connections within a cabinet do not normally
require the same level of shielding as connections external to a cabinet. For these internal
connections an alternate connector may be
used that interfaces with industry standard
headers with 0,64 mm (0,025 in) square posts
on 2,54 mm (0,100 in) center spacing. Due to
size constraints this connector is only intended
to be used with TW cable.
These connectors are not entirely shielded and
leakage of RFI may occur. A shielded cabinet
and/or other RF leakage control techniques
such as ferrite beads or lossy tubing is recommended for compliance with EMC standards,
even with double shielded balanced cables (refer to Annex F).
7.4.4 .6 Intrac abinet c onne ctors for
balanced cable
Connections within a cabinet do not normally require the same level of shielding as connections
external to a cabinet. For these internal connec-
1 = Transmit +
1
2
3
4
5
6
7
8
3 = Transmit 6 = Receive 8 = Receive +

Shell = Cable Shield
Figure 36 Style-2 balanced connector

receptacle pin locations
15
dpANS X3.xxx-199x
Optical fibre cable plant specification
No enhancements from X3.230-1994 (FC-PH) or x3.xxx-1995 (FC-PH-2).
16
dpANS X3.xxx-199x
Electrical cable plant specification
This clause defines the link requirements for a

Fibre Channel electrical cable plant.
9.1
Unbalanced cable plant
The unbalanced cables listed in this clause are

not the only such cables that may be used to
create such links. Usage of other cables are
permitted to meet specific cost, performance, or
other implementation specific criteria.
When using such cables it is the implementers
responsibility to insure that all impedance, attenuation (loss), jitter, and shielding are within
the operating limits of the link type and data
rate being implemented.
9.1.1
tion
LV (long-video) cable plant specifica-
This subclause specifies a LV-style cable plant

which is capable of communication at data
rates specified in table 15. The cable plant is
generally insensitive to data rate and therefore
any installed portions of the cable plant may be
used at any data rate.
formation identifying the specific designed operational characteristics of the cable assembly.
NOTE The Baudrate/2 equivalent frequency for
any specific data rate (referenced in tables in this
clause) is the frequency of the square wave produced when continuously transmitting a D21.5
transmission character.
9.1.1.1 LV-type
The cable shall conform to RG 6/U-type coaxial
cable specifications.
9.1.1.2 Shielding
The cable assembly shall provide a transfer impedance through the shield(s) of less than 100m/m from DC through the Baudrate/2 equivalent frequency.
9.1.2
TV (video) cable plant specification
This subclause specifies a TV-style cable plant

Table 14 LV-style cable plant

FC-0
100- 502512Unit LVLVLVLVEL-S EL-S EL-S EL-S
Subclause
7.3
7.3
7.3
dB/
0,25
conn
0,25
0,25
FC-0
Unit
7.3
Attenuation
(nom.)
at
dB/
Baudrate/2
0,148 0,105 0,074 0,052
m
equivalent
frequency
Connector
Related
Loss
Table 15 TV-style cable plant
0,25
Impedance
75
75
75
75
Impedance
Tolerance
For those cables containing embedded equalization circuits, the operation of the cable may
be both data rate and length specific. All cables
containing such circuits shall be marked with in-
Subclause
1225100- 50TVTVTVTVEL-S EL-S EL-S EL-S

7.3
7.3
7.3
7.3
Attenuation
(nom.)
at
dB/
Baudrate/2
0,176 0,124 0,088 0,062
m
equivalent
frequency
Connector
Related
Loss
dB/
0,25
conn
0,25
0,25
0,25
Impedance
75
75
75
75
Impedance
Tolerance
containing such circuits shall be marked with in-
17
dpANS X3.xxx-199x
formation identifying the specific designed operational characteristics of the cable assembly.
m/m from DC through the Baudrate/2 equivalent frequency.
9.1.2.1 TV-type
9.1.4
The cable shall conform to RG 59/U-type coaxial cable specifications.
A specific goal of the unbalanced cable plant is

to allow interoperability with restricted lengths
of all styles of unbalanced cable. This requires
that all cables be connector compatible. Such
compatibility may be achieved with either special cables or adapters.
9.1.2.2 Shielding
The cable assembly shall provide a transfer impedance through the shield(s) of less than 100m/m from DC through the Baudrate/2 equivalent frequency.
9.1.3
tion
MI (miniature) cable plant specifica-
This subclause specifies a MI-style cable plant

When unbalanced cable types are mixed, it is

the users responsibility to validate that the
lengths of cable used do not distort the signal
beyond the received signal specifications in 7.3.
At transmission rates of 531 MBaud or greater,
particular attention must be given to the transition between cable segments. No more than
four connection points should be present from
the ECL transmitter to the receiver of the data
link.
9.2
Table 16 MI-style cable plant

FC-0
100- 502512Unit MIMIMIMIEL-S EL-S EL-S EL-S
Subclause
7.3
Attenuation
(nom.)
at
dB/
Baudrate/2
m
equivalent
frequency
Connector
Related
Loss
0,62
dB/
0,25
conn
7.3
0,46
0,25
7.3
0,31
0,25
7.3
0,21
0,25
Impedance
75
75
75
75
Impedance
Tolerance
9.1.3.1 MI-type
The cable shall conform to RG 179B/U type coaxial cable specifications.
9.1.3.2 Shielding
The cable assembly shall provide a transfer impedance through the shield(s) of less than 100-
18
Unbalanced cable interoperability
Balanced cable plant
The balanced cables listed in this clause are

not the only such cables that may be used to
create such links. Usage of other cables are
permitted to meet specific cost, performance, or
other implementation specific criteria.
When using such cables it is the implementers
responsibility to insure that all impedance, attenuation (loss), jitter, skew, balance, and
shielding are within the operating limits of the
link type and data rate being implemented.
9.2.1 TP (shielded twisted pair) cable plant
specification
This subclause specifies a TP-style cable plant
rates specified in table 17.
Because of the differential skew requirement, it
is expected to be difficult to obtain cable of this
type meeting all requirements of 100-TP-EL-S
and 50-TP-EL-S. This cable may be used for
distances shorter than the maximum length,
providing that the differential skew at the end of
the cable does not exceed the specified limit.
9.2.1.1 TP-type
The cable shall conform to IEC 1156-1. One cable contains two individually shielded twisted
dpANS X3.xxx-199x
Table 18 TW-style cable plant
Table 17 TP-style cable plant

1225100- 50TPTPTPUnit TPEL-S EL-S EL-S EL-S
FC-0
7.4
XRE
F
Subclause
7.4
XRE
F
7.4
XRE
F
7.4
XRE
F
Attenuation
(nom.)
at
dB/
Baudrate/2e
0,310 0,220 0,155 0,110
m
quivalent
frequency
Connector
Related
Loss
dB/
0,25
conn
0,25
0,25
0,25
Impedance
150
150
150
150
Impedance
Tolerance
10
10
10
10
Differential
Skew
ps
175
350
700
1400
pairs. Of these two pairs, one is used as the

transmitting medium, with the other used as the
receiving medium.
The shielded twisted pair cable, when used in
full duplex links, shall be wired in a crossover
fashion as shown in figure 37, with each pair
being attached to the transmit contacts at one
end of the cable and the receive contacts at the
other end.
9.2.1.2 Shielding
The cable assembly shall provide a transfer impedance through the shield(s) of less than 100m/m from DC through the bit-rate fundamental frequency.
9.2.2
TW cable plant specification
This subclause specifies a TW-style cable plant

rates specified in table 18.
T+
TR+
RShield
FC-0
Unit
Subclause
Attenuation
(nom.)
at
Baudrate/2e
quivalent
frequency
Connector
Related
Loss
100- 502512TW- TW- TW- TWEL-S EL-S EL-S EL-S

7.4
dB/
m
7.4
7.4
7.4
0,266 0,189 0,133 0,094
dB/
0,25
conn
0,25
0,25
0,25
Impedance
150
150
150
150
Impedance
Tolerance
10
10
10
10
Differential
Skew
ps
175
350
700
1400
containing such circuits shall be marked with information identifying the specific designed operational characteristics of the cable assembly.
9.2.2.1 TW-type
The cable shall have a nominal differential impedance of 150. It shall consist of two parallel
conductors, separated by a dielectric spacer,
with an overall shield
TW-style cable may be used in either full duplex
or simplex links. When configured in a full duplex link, the cable shall consist of two individually shielded balanced pairs in a common or
joined outer insulating jacket, or two orthogonal
balanced pairs with common shields and an
overall insulating jacket. These two pairs shall
be wired in a crossover fashion as shown in figure 37, with each pair being attached to the
transmit contacts at one end of the cable and
the receive contacts at the other end.
T+
T-
9.2.2.2 Shielding
R+
RShield
The cable assembly shall provide a transfer impedance through the shield(s) of less than 100m/m from DC through the bit-rate fundamental frequency.
Figure 37 Balanced cable wiring
19
dpANS X3.xxx-199x
9.2.3
Balanced cable interoperability
A specific goal of the balanced cable plant is to

allow interoperability with restricted lengths of
all styles of balanced cable. This requires that
all cables be connector compatible. Such compatibility may be achieved with either special
cables or adapters.
When balanced cable types are mixed, it is the
users responsibility to validate that the lengths
of cable used do not distort the signal beyond
the received signal specifications in 7.4
20
dpANS X3.xxx-199x
10
Optical interface connector specification
11
FC-1 8B/10B Transmission Code
12
FC-1 receiver and transmitter description
13
Loopback mode
14
Diagnostic mode
15
Transmitter safety
16
Ordered sets
17
Frame formats
21
dpANS X3.xxx-199x
18
Frame_Header
Enhancements to FC-PH and FC-PH-2 are

specified.
18.3
Address identifiers
Additional values specified in FC-PH-3 are

shown in table 33.
Table 33 Well-known Address identifiers
Table 36 Type codes - FC-4 (Device_Data

and Link_Data)
Encoded Value
Wd 2, bits 31-24
Description
0000 0000 to
0010 1111
Specified in FC-PH
Table 36
Specified in FC-PH-2
Table 36
Hex value
Description
0011 0000 to
0011 0011
FFFFF0 to
FFFFF4
Reserved
0011 0100 to
0011 1111
Reserved
Multicast Server
0100 0000 to
0100 0111
Specified in FC-PH
Table 36
0100 1000 to
0100 1111
Reserved for FC-AE
0101 0000 to
0101 1111
Reserved
0110 0000 to
1111 1111
Specified in FC-PH
Table 36
FFFFF5
( see 31.2.3)
FFFFF6
Clock Synchronization Server

(see FC-PH-3)
FFFFF7
Security Key Distribution Server

(see FC-GS-2)
FFFFF8 to
FFFFFF
Specified in FC-PH-2 Table 33
18.4
Data Structure (TYPE)
Additional values specified in FC-PH-3 are

shown in table 36.
22
18.5
Frame Control (F_CTL)
The Frame Control (F_CTL) field (Word 2, Bits

23-0) is a three byte field that contains control
information relating to the frame content. The
following subclause describes the valid uses of
F_CTL bits. If an error in bit usage is detected,
a reject frame (P_RJT) shall be transmitted in
response with an appropriate reason code (see
20.3.3.3) for Class 1 and 2. The format of the
F_CTL field is defined in table 37.
dpANS X3.xxx-199x
Table 37 (Page 1 of 2) - F_CTL field
Control Field
Word 2,
Bits
Description
Ref.
Exchange/Sequence Control
Exchange Context
23
0 = Originator of Exchange
1 = Responder of Exchange
FC-PH
Sequence Context
22
0 = Originator of Sequence
1 = Responder of Sequence
FC-PH
First_Sequence
21
0 = Sequence other than first of Exchange

1 = First Sequence of Exchange
FC-PH
Last_Sequence
20
0 = Sequence other than last of Exchange

1 = Last Sequence of Exchange
FC-PH
End_Sequence
19
0 = Data frame other than last of Sequence

1 = Last Data frame of Sequence
FC-PH
End_Connection (Class 1) or
Deactivate Class 4 circuit
18
0 = Originator of Exchange
1 = Responder of Exchange
Reserved
17
Sequence Initiative
16
0 = hold Sequence Initiative

1 = Transfer Sequence Initiative
FC-PH
X_ID reassigned
15
0 = X_ID assignment retained

1 = X_ID reassigned
FC-PH
Invalidate X_ID
14
0 = X_ID assignment retained

1 = Invalidate X_ID
FC-PH
ACK_Form
13-12
00 = No Assistance provided
01 = ACK_1 required
10 = ACK_N required
11 = ACK_0 required
FC-PH-2
Data Compression
11
0 = Uncompressed frame payload

1 = Compressed frame payload
FC-PH-2
Data Encryption
10
0 = Unencrypted frame payload

1 = Encrypted frame payload
FC-PH-3
Retransmitted Sequence
Unidirectional Transmit (Class 1)

or
Remove Class 4 circuit (Class 4)
23
FC-PH-2
FC-PH-3
0 = Original Sequence transmission

1 = Sequence retransmission
FC-PH
0 = Bidirectional transmission (Class 1)

1 =Unidirectional transmission (Class 1)
8
FC-PH-2
0 = Retain or deactivate circuit (Class 4)
1 = Remove circuit (Class 4)
dpANS X3.xxx-199x
Table 37 (Page 2 of 2) - F_CTL field
Control Field
Description
Ref.
7-6
Last Data Frame - Sequence Initiator

00 = No information
01 = Sequence to follow - immediately
01 = Sequence to follow - soon
01 = Sequence to follow - delayed
Abort Sequence Condition
5-4
ACK Frame - Sequence Recipient:

00 = Continue Sequence
01 = Abort Sequence, perform ABTS
10 = Stop Sequence
11 = Immediate Sequence retransmission
requested
FC-PH and
Data frame (1st of Exchange) - Sequence
FC-PH-3
Initiator:
00 = Abort, Discard multiple Sequences
01 = Abort, Discard a single Sequence
10 = Process policy with infinite buffers
11 = Discard multiple Sequences with
immediaet retransmission
Relative Offset present
0 = Parameter field not meaningful

1 = Parameter field - Relative Offset
FC-PH
Exchange reassembly
Reserved for Exchange reassembly
FC-PH
End of Data field - bytes of fill

00 = 0 bytes of fill
01 = 1 byte of fill (last byte of Data fieldl
10 = 2 bytes of fill (last 2 bytes of Data field)
11 = 3 bytes of fill (last 3 bytes of Data field)
FC-PH
Continue Sequence Condition
Fill Data Bytes
24
Word
2, Bits
1-0
FC-PH
dpANS X3.xxx-199x
Bit 10 - Data Encryption Status
Data encryption status bit (F_CTL bit 10) is
used by the Sequence Initiator to indicate to the
Sequence Recipient that the Information Category to which the payload in the frame belongs
is encrypted. The bit is meaningful in all Data
frames of the Information Category to which the
Data frames belong. The bit is not meaningful
on ACK, BSY, or RJT frames.
By resetting Data encryption status bit =
0, the Sequence Initiator is indicating that the
payload in the frame belonging to the Information Category is not encrypted.
By setting Data encrypted status bit = 1,
the Sequence Initiator is indicating that the
payload in the frame belonging to the Information Category is encrypted.
Table 36C Data encryption status
Word 2, F_CTL Bit 10
Encode
Meaning
Unencrypted frame
Payload
Encrypted frame
Payload
Bits 5-4 - Abort Sequence Condition

The following details changes to Process Policy
with Infinite Buffers.
The Abort Sequence Condition bits shall

be set to a value by the Sequence Initiator on the first Data frame of an Exchange
to indicate that the Originator is requiring
a specific error policy for this Exch an ge . Fo r C lasse s 1, 2 , a nd 4 , the
Abort Sequence Condition bits shall not
be meaningful on other Data frames within an Exchange. For Class 3 process policy support, the Abort Sequence
Condition bits shall be set to 1 0 on each
data frame with the sequence to indicate
tha t th e origina to r is re qu iring pr oce ss
policy to be used for the sequence. The
error policy passed in the first frame of
the sequence of the first Sequence of an
Exchange shall be the error policy supported by b oth N_Ports participa ting in
the Exchange. Add itio nally, for Class 3
operation the error policy passed in the
first received frame of the sequence shall

be the error policy supported by both N_
Ports participating in the Exchange (see
29.6.1.1)
0 0 = Abort, Discard multiple Sequences
0 1 = Abort, Discard a single Sequence
1 0 = Process policy with infinite buffers
1 1 = Discard multiple Sequences with
immediate retransmission
In the Abort, Discard multiple Sequences
E r r o r P o lic y , t h e S e q u e n c e R e c i p ie n t
shall de live r Se que nces to the FC-4 o r
upper level in the order transmitted under
the condition that the previous Sequence,
if any, was also deliverable. I f a S equence is determined to be non-deliverable, all subsequent Sequences shall be
d is ca rd e d u ntil the ABTS p ro to co l h a s
been completed. The Abort, Discard multiple Sequences Error Policy shall be supported in Class 1, 2, 3, or 4.
In the Abort, Discard a single Sequence
Error Policy, the Sequence Recipient may
deliver Sequences to the FC-4 or upper
level in the order that received Sequences are completed by the Sequence Recipient without regard to the deliverability of
any previous Sequences. The Abort, Discard a single Sequence Error Policy shall
be supported in Class 1, 2, 3, or 4.
In the Process policy with infinite buffers,
frames shall be delivered to the FC-4 or
upper level in the order transmitted. Process policy with infinite buffers shall only
b e a llo w e d in C la s s 1 a n d C la ss 3 . In
Class 1, Process policy with infinite buffers shall use ACK_0 (see 20.3.2.2).
Bit 3- Relative Offset present
When bit 3 is set to zero on a Data frame,
the Para mete r Fie ld is not me an in gful.
Th at is, it may be set by th e Se quence
Initiator, but it shall be ignored by the Sequ en ce Re cip ie nt. W h en bit 3 is set to
one in a Data frame, the Parameter Field
contains the Realtive Offset for the Payload of the frame. Bit 3 is only meanigful
on Data frames of a Sequence and shall
be ignored on ACK and Link_Response
25
dpANS X3.xxx-199x
frames. Bit 3 is not meaningful on Basic
Link_Data frames.
NOTE When bit 3 is set to 0 on a Data frame, although the Sequence Recipient ignores the value
in the Parameter Field, it may pass it to an upper
level.
18.6
Sequence_ID (SEQ_ID)
18.7
DF_CTL
Data_Field Control (DF_CTL) is a one byte field

(Word 3, bits 23-16) that specifies the presence
of optional headers at the beginning of the
Data_Field for Device_Data or Video_Data
frames. DF_CTL bits are not meaningful on
Link_Control or Basic Link Service frames.
Control bit usage is shown in table 40.
Table 40 DF_CTL bit definition
Word 3,
Bits(s)
Optional header
23
Reserved for Extended Frame_

Header
22
Reclaimed
from
Expiration_
Security_Header and Reserved
21
0 = No Network_Header
1 = Network_Header
20
0 = No Association_Header
1 = Association_Header
19-18
Reserved
17-16
0
0
1
1
0 = No Device_Header
1 = 16 byte Device_Header
The Optional Headers shall be positioned in the

Data Field in the order specified with the bit 23
header as the first header in the Data Field, the
bit 22 header as the second header in the Data
Field, and so forth, in a left to right manner corresponding to bits 23, 22, 21, and so forth as
shown in figure 47.
If either bit 17 or 16 is set to one, then a Device
Header is present. The size of the Device
Header is specified by the encoded value of bits
17 and 16 as shown.
If an Optional Header is not present as indicated by the appropriate bit in DF_CTL, no space
shall be allocated for the Header in the Data
26
Field of the frame. Therefore, for example, if

bits 23 and 22 are zero and bit 21 is one, the
first data byte of the Data Field contains the first
byte of the Network_Header.
See clause 19 for a discussion on Optional
Headers.
18.9
Word 4, Bits 31-16
Word 4, Bits 31-16 shall identify the Exchange_

ID assigned by the Originator of the Exchange
and, if enabled, the Priority that may be used by
the Fabric to establish connections for all classes of service.
When Priority is enabled, Word 4, Bits 31-24
shall specify the Priority and Word 4, Bits 23-16
shall specify the Originator Exchange_ID (OX_
ID). When Priority is not enabled, Word 4, Bits
31-16 shall specify the Originator Exchange_ID
(OX_ID). Priority is valid for all Classes of service except Class 3 and is enabled via Login
(see 23.6.7.2). See table 160 and table 161 for
illustrations of this field.
NOTE When priority is enabled, the number of
available Exchanges is reduced to 254.
Table 160 Priority/Preemption enabled

Bit(s)
31
Field
0 = No Preemption
1 = Preemption
30-24
Priority
23-16
OX_ID
Table 161 Priority/Preemption not

enabled
Bit(s)
31-16
18.9.1
Field
OX_ID
Originator Exchange_ID (OX_ID)
The Originator Exchange_ID is a two byte field

(Word 4, Bits 31-16) that shall identify the
Exchange_ID assigned by the Originator of the
Exchange and if enabled, the priority that may
be used by the Fabric to establish connections
for all classes of service and a preemption flag
dpANS X3.xxx-199x
to indicate that an SOFc1 is a preemption request. If priority is enabled the priority shall be
7 bits (Word 4, Bits 30-24), the preemption request flag shall be 1 bit (Word 4, Bit 31), and
the Exchange_ID shall be one byte (Word 4,
Bits 2 3-16). If priority is not en abled the
Exchange_ID shall be two bytes (Word 4, Bits
31-16).
Each Exchange shall be assigned an identifier
unique to the Originator or Originator-Responder pair. If the Originator is enforcing uniqueness via the OX_ID mechanism, it shall assign
a unique value for OX_ID other than hex 'FFFF
('FF' if priority enabled) in the first Data frame
of the first Sequence of an Exchange. An OX_
ID of hex 'FFFF' ('FF') indicates that the OX_
ID is unassigned and that the Originator is
not enforcing uniqueness via the OX_ID mechanism. If an Originator uses the unassigned
value of hex 'FFFF' ('FF') to identify the Exchange, it shall have only one Exchange (OX_
ID= hex 'FFFF' ('FF')) with a given Responder.
An Originator Exchange Status Block associated with the OX_ID is used to track the progress
of a series of Sequences which comprises an
Exchange. See clause 24 for a discussion of
Sequences and Exchanges. See 24.8.1 for a
description of the Exchange Status Block.
NOTE If hex 'FFFF' ('FF' if priority enabled) is
used as the OX_ID throughout the Exchange,
then the Originator uses an alternate Sequence
tracking mechanism. If the OX_ID is unique, it
may be used as an index into a control block
structure which may be used in conjunction with
other constructs to track frames.
18.9.2
Priority
b) In Class 1, Priority is meaningful for a

dedicated connection. The Priority for a dedicated connection shall be established by the
priority value provided by the SOFc1 frame.
NOTE Changing Priority in a subsequent
frame of a Dedicated Connection will not affect
the Fabric. However, if the Responder N_Port
does not support Priority and is using an RX_ID
of hex FFFF, its ability to track the Exchange
will be destroyed. This is because it is using the
OX_ID to track the Exchange and it will consider
all of Word 4, bits 31-16 to be the OX_ID.
c) In Class 2, Priority is meaningful for an

Exchange. Priority shall be set by the Exchange Originator on the first frame of the
Exchange. Priority shall be modified by the
Exchange Originator only on an SOFi2 frame
and under the following conditions:
1) The Responder has indicated during
Login that it supports Priority, or the Responder has returned an RX_ID not equal
to hex FFFF, or
2) The Responder has indicated during
Login that it does not support Priority, the
Responder has returned an RX_ID of hex
FFFF, and the OX_ID has previously
been invalidated.
NOTE If the Responder is using an RX_ID not
equal to hex FFFF, it is tracking the Exchange
via the RX_ID and not the OX_ID. Therefore,
modification of Word 1, Bits 31-16 will not affect
it. Also, if the Responder supports Priority, it recognizes that the OX_ID is only Word 4, bits 2316.
Priority shall only be modified by the Exchange Responder on an SOFi2 frame.
If the Originator N_Port indicated during Login

that Priority is supported, the following rules
shall apply to the use of the Priority field:
d) In Class 3, Priority shall not be used.

That is, all of Word 4, bits 31-16 shall be considered the OX_ID.
NOTE If the Originator N_Port indicated during

Login that Priority is not supported, it cannot be
used because the Priority field does not exist (it
becomes an extension of the OX_ID field).
e) In Class 4, Priority is meaningful for a virtual circuit. Priority shall be established by

the priority value provided by the Quality of
Service Request frame.
a) A value of hex 00 shall indicate that no

Priority has been assigned to the frame. The
remaining values shall indicate, in ascending
order, the relative priority of the frame. That
is, a Priority of hex 23 shall be considered to
have a lower priority than a Priority of hex
57. The Fabric may use the Priority to resolve resource contention or to determine the
order in which to deliver frames.
NOTE Once a Virtual Circuit has been set up,

Priority is meaningless.
27
dpANS X3.xxx-199x
This clause describes the changes that are made

in FC-PH-3 to the FC-PH Optional headers.
the Data Field. If present, a Device_Header shall

be the next 16 bytes of the Data Field. If none of
the optional headers is present, no space in the
Data Field shall be reserved.
19.1
19.2
19
Optional headers
Introduction
Optional headers are defined within the Data

Field of a frame are:
Expiration_Security_Header
The Expiration_Security_Header defined in FCPH is reclaimed and its space is reserved for future use.
a) Reserved (reclaimed from Expiration_

Security_Header)
19.3
b)
Network_Header
This clause details the changes due to the reclamation of the CCITT NAA identifier.
c)
Association_Header
d)
Device_Header
NOTE The CCITT NAAs are reclaimed due to the

non-existence of a registration authority for these addresses.
The presence of optional headers is defined by

control bits in the DF_CTL field of the Frame_
Header. The sequential order of the optional
headers, Payload, and their sizes are indicated
in figure 47.
Start_of_Frame
Frame_Header
Reserved
Data
Field
(0 to
2112)
Network_Header
(optional)
Association_Header
(optional)
Device_Header
(optional)
Network_Header
4 bytes
24 bytes
16 bytes
16 bytes
32 bytes
NOTE Although this clause is referenced by 23.6.4

and 23.6.5, it is important to note that the usage of the
Network Header for network routing is very different
than the use of the same format to define N_Port and
node identification during Login. For example, the
Network Header may change as other NAA types are
defined, but this does not imply that these are valid for
use as identifiers during Login. Furthermore, one format or even value may be used in the Network Header for routing and a different format or value may be
used in the Login payload for identification.
19.3.1
D_NAA or S_NAA
Destination Network_Address_Authority (D_NAA)

or Source Network_Address_Authority (S_NAA)
field indicates the authority responsible for the administration of the network address (destination or
source) used. The Network_Address_Authority indicators are shown in table 45.
16 bytes
Table 41 NAA identifiers
Payload
Bits
4 bytes
CRC
EOF
4 bytes
Figure 47 Optional headers order

The first 16 bytes of the Data Field after the
Frame_Header have been reclaimed from the
Expiration_SecurityHeader and are reserved for
future use. If present, a Network_Header shall be
the next 16 bytes of the Data Field. If present, a
Association_Header shall be the next 16 bytes of
28
NAA
63 62 61 60
0000
ignored
0001
IEEE
0010
IEEE extended
0011
locally assigned
0100
IP
0101
Reserved
....
dpANS X3.xxx-199x
1011
Reserved
1100
Reclaimed from CCITT
1101
Reserved
1110
Reclaimed from CCITT
1111
Reserved
Table 45 Association_Header Validity

bits (Bits 63-56)
Bit
Description
31
Originator P_AS
0 = not meaningful
1 = meaningful
FC-PH
30
Responder P_AS
0 = not meaningful
1 = meaningful
FC-PH
29
Originator O_AS
0 = not meaningful
1 = meaningful
FC-PH
28
0
Responder O_AS
0 = not meaningful
1 = meaningful
FC-PH
27
to
25
Reserved
FC-PH-3
24
Multicast P_AS
0 = Unicast
1 = Mulitcast
FC-PH-3
19.3.2.5 CCITT 60-bit address

This FC-PH clause is deleted.
19.4
Association Header
The following changes to the Association Header are indicated in figure 52 and table 45.
bits
word
Ref
31-24
Validity
2316
15-8
7-0
Originator P_AS
(most significant 3 bytes)
Originator P_AS
(least significant 4 bytes)
Reserved
Responder P_AS
Responder P_AS
Originator O_AS
Originator O_AS
Responder O_AS
Responder O_AS
Figure 52 Association_Header
Bit 56 - Multicast Process_Associator

This bit set to one shall indicate that the
passed Process_Associator shall be processed as a multicast Process_Associator by the recipient N_Port. That is, the
N_ Port s hall pe rform an in tern al multica st ing of th e p a ylo a d o f th e re c eiv ed
frame to all images within the Multicast
Group specified by the Process_Associator. This bit set to zero shall indicate that
the passed Process_Associator shall be
processed as a unicast Process_Associator by the Recipient N_Port. That is, the
N_Port shall pass the payload of the received frame to the image specified b y
t h e P r o c e s s _ As s o c ia to r . S e e X3 . x x x 1995 (FC-PH-2), clause 31 for a description of Multicast support.
29
dpANS X3.xxx-199x
20
Data frames and responses
FC-PH-3 enhancements to Data frames and responses defined in FC-PH and FC-PH-2 are
specified.
20.3
Link_Control
A Link_Response frame (F_RJT) shall be sent

by the Fabric in reply to a Class 1 preemption
request frame if the fabric rejects the request,
or preemption is not enabled. To reject the preemption request the fabric shall send an F_RJT
link response frame with a Preemption Request Rejected or Preemption Not Enabled
reason code.
20.3.3.2 N_Port Busy (P_BSY)
Table 53 provides the enhanced Busy reason
codes based on FC-PH and FC-PH-2 table 53.
Table 53 P_BSY Reason Codes
Word 0, bits
27-24
Description
0000 0001
to
0001 0100
Specified in FC-PH
table 55
0001 0101
table 55
0001 0110
to
0001 1010
Specified in FC-PH
table 55
0001 1011
to
0001 1111
table 55
0010 0000
Preemption Request
Rejected
(see clause 28.9)
0010 0001
Premption Not
Enabled
(see clause 23)
By
Word 5, bits
23-16
Description
0010 0010
Multicast Error
(see clause 31)
0000 0001
Specified in FC-PH
table 53
0000 0011
Specified in FC-PH
table 53
0010 0011
Multicast Error
terminate
(see clause 31)
0000 0111
Partial Multicast Busy

(see Clause 31)
Others
Reserved
1111 1111
Specified in FC-PH
table 53
Others
Reserved
20.3.3.3 Reject (P_RJT, F_RJT)

Table 55 provides the enhanced Reject reason
codes based on FC-PH and FC-PH-2 table 55.
30
Table 55 P_RJT or F_RJT Reason Codes
NOTE The By column indicates that this Reason Code is set by the fabric (F) , N_Port (N), or
both (B).
dpANS X3.xxx-199x
21
Link Services
This clause describes the changes that are made in

FC-PH-3 for:
Receive_Data_Field Size = 128,
X_ID interlock required,
no X_ID reassignment,
E_D_TOV timer resolution enhancement.
ACK_1,
Default login values.
Discard multiple Sequences Error Policy,
Basic link service commands
Relative Offset not used,
Extended link services.
E_D_TOV Resolution = 0,
Report Node Capabilities information.
Other optionally supported features shall not

be used or required.
21.1.1
Default Login values
Prior to Login or following Logout, a default set of

Service Parameters apply:
Concurrent Sequences = 1,
Total Concurrent Sequences = 1,
End-to-end Credit = 1,
Buffer-to-buffer Credit = 1,
Following Login with the destination, an N_Port

sh all use th e Ser vic e P ar ame ter s o bta in e d
through Login.
21.2
Basic Link Service commands
Enhancements to FC-PH and FC-PH-2 is specified in table 57.
Table 57 Basic Link Service Commands

Word 0
Word 1
Routing
Category
Type
(bits 31-28) (bits 27-24) (bits 31-24)
Word 5
Description
Abbr.
Ref.
Parameter
Basic Link Service
1000
0000
No Operation
NOP
0001
Abort Sequence
ABTS
0010
Remove Connection
RMC
0011
Reserved
Basic Accept
BA_
ACC
0101
Basic Reject
BA_RJT
0110
Preempted
PRMT
0100
Others
0000 0000
N/A
Reserved
Specified
in FC-PH
table 57
Specified
in FC-PH-3
Specified
in FC-PH
table 57
31
dpANS X3.xxx-199x
21.2.7 Dedicated Connection Preempted
(PRMT)
The PRMT basic link service command shall indicate that the connection for which this N_Port
is participating has been preempted and no
longer exists. All sequences associated with
this connection have ended abnormally.
Protocol:
OX_ID: If priority is enabled (see clause 18 and

23) the upper byte of the OX_ID field shall be
equal to the upper byte of the OX_ID field in the
SOFc1 preemption request frame which triggered this preemption notification.
Payload: None
Reply Sequence: None
21.3
Connection Preempted Notification

No Reply frame
Extended Link Services
Table 61 summarizes FC-PH,FC-PH-2, and

FC-PH-3 Extended Link Service Requests and
Replies.
Format: FT_1
Addressing: The D_ID field shall designate the
N_Port to which this basic link service command is directed by the Fabric. The S_ID field
shall be equal to the S_ID field in the SOFc1
preemption request frame which triggered this
preemption notification.
Table 61 Extended Link Service Commands
Word 0
Routing
(bits 31-28)
Payload
Category
(bits 27-24)
Type
Description
Word 0
(bits 31-24)
Abbr.
Ref.
Extended Link Service Request
0010
32
0010
0000
0001
hex 03
N_Port Login
PLOGI
hex 04
F_Port Login
FLOGI
hex 05
Logout
LOGO
hex 06
Abort Exchange
ABTX
hex 07
Read Connection Status
RSC
hex 08
Read Exchange Status Block
RES
hex 09
Read Sequence Status Block
RSS
hex 0A
Request Sequence Initiative
RSI
hex 0B
Establish Streaming
ESTS
hex 0C
Estimate Credit
ESTC
hex 0D
Advise Credit
hex 0E
Read Time-out Value
RTV
hex 0F
Read Link Status
RLS
hex 10
Echo
ECHO
hex 11
Test
TEST
hex 12
Reinstate Recovery Qualifier
RRQ
Specified
in FC-PH
21.4 and
table 61
ADVC
Specified
in FC-PH-3
Specified
in FC-PH
21.4 and
table 61
dpANS X3.xxx-199x
Table 61 Extended Link Service Commands
Word 0
Payload
Type
Routing
Category
(bits 31-28) (bits 27-24)
Description
Word 0
(bits 31-24)
Abbr.
Ref.
Extended Link Service Request
0010
0010
0000 0001
hex 20
Process Login
PRLI
hex 21
Process Logout
PRLO
hex 22
State Change Notification
SCN
hex 23
Test Process Login State
TPLS
hex 24
Third Party Process Logout
TPRLO
hex 30
Get Alias_ID
GAID
hex 31
Fabric Activate Alias_ID
FACT
hex 32
Fabric Deactivate Alias_ID
FDACT
hex 33
N_Port Activate Alias_ID
NACT
hex 34
N_Port Deactivate Alias_ID
NDACT
hex 40
Quality of Service Request
QoSR
hex 41
Read Virtual Circuit Status
RVCS
hex 50
Discover N_Port Service Parm
PDISC
hex 51
Discover F_Port Service Parm
FDISC
hex 52
Discover Address
ADISC
hex 53
Report Node Capability
RNC
Others
Reserved
hex 01
Link Service Reject
hex 02
Accept
Others
Reserved
Specified
in FC-PH-2
table 61
FC-PH-3
Extended Link Service Reply
0010
33
0011
0000 0001
LS_RJT Specified
in FC-PH
ACC
21.4 and
table 61
dpANS X3.xxx-199x
21.4
Extended Link Service requests
This section contains modifications to Extended

Link Service requests defined in X3.230-1994
(FC-PH) and X3.297-1996 (FC-PH-2), along
with the definition of additional Extended Link
Services.
21.4.13
Accept Payload:
The format of the Accept Payload is
shown in table 162. Timeout values are
specified as a count of either 1 ms or 1
ns increments, depending on the setting
of Bit 26 in the Timeout Qualifier.
Read Timeout Value (RTV)
The RTV Link Service request Sequence requests an N_Port or F_Port (hex FFFFFE) to
return the Resource_Allocation_Timeout Value
(R_A_TOV) and the Error_Detect_Timeout Value (E_D_TOV) in the Accept reply Sequence.
This provides the N_Port transmitting the request with the information regarding these values from another N_Port or from the F_Port.
Usage of E_D_TOV and R_A_TOV is discussed in X3.230-1994 (FC-PH) 29.2.1.
Protocol:
Read Timeout Value (RTV) request Sequence
Accept (ACC) reply Sequence
Format: FT_1
Addressing: The S_ID field designates the
source N_Port requesting the timeout interval
values. The D_ID field designates the destination N_Port or F_Port to which the request is
being made.
Payload: The format of the Payload is shown in
table 162.
Table 162 RTV Payload

Item
hex 0E000000
Size Bytes
4
Reply Link Service Sequence:
Table 163 RTV Accept Payload

Item
hex 02000000
Resource_Allocation_Timeout Value
(R_A_TOV) (see 29.2.1)
Error_Detect_Timeout Value
(E_D_TOV) (see 29.2.1)
Timeout Qualifier
(see 23.6.3.7)
R_A_TOV: In a point-to-point topology, this value shall have the same resolution as E_D_
TOV, as indicated by the Timeout Qualifier.
NOTE In a point-to-point topology, R_A_TOV
must be twice E_D_TOV, which means it must
have the same resolution. In other topologies, R_
A_TOV will always be in 1 ms increments.
Timeout Qualifier:
Bits 31-27: Reserved
Bit 26: E_D_TOV Resolution
If Bit 26 is zero, the value specified in the E_D_
TOV field shall indicate a count of 1 ms increments. If Bit 26 is one, the value specified in the
E_D_TOV field shall indicate a count of 1 ns increments.
Bits 25-0: Reserved
21.5 Ex tende d Link Se rv ic e r eply
Sequences
21.5.2
Service Reject (LS_RJT)

signifies rejection of the RTV command
(see X3.230-1994 (FC-PH) 21.5.2)
Accept
signifies that the N_Port or F_Port has
transmitted the requested data.
34
Size Bytes
Link Service Reject (LS_RJT)
Table 91 summarizes FC-PH,FC-PH-2, and

FC-PH-3 LS_RJT reason codes.
dpANS X3.xxx-199x
Table 91 LS_RJT reason code explanation
Encoded Value
(Bits 15-8)
Description
Applicable Commands
hex 00
No additional explanation
ABTX, ADVC, ESTS, FLOGI, PLOGI,

LOGO, RCS, RES, RLS, RSS, RTV,
RSI, PRLI, PRLO, TPLS, TPRLO,
GAID, FACT, FDACT, NACT,
NDACT, QoSR, RVCS, PDISC,
FDISC, ADISC, RNC
hex 01
to
hex 2B
See FC-PH Table 91
See FC-PH Table 91
hex 2C
Request not supported
ADVC, ESTS, ESTC, PRLI, PRLO,

TPLS, TPRLO, GAID, FACT, FDACT,
NACT, NDACT, QoSR, RVCS,
PDISC, FDISC, ADISC, RNC
hex 2D
Invalid Payload Length
FLOGI, PLOGI
hex 30
to
hex 38x
See FC-PH-2 Table 91
hex 40
to
hex 42x
21.20 Report Node Capabilities Information

(RNC)
The RNC Link Service request Sequence provides
for the exchange of vendor identification, node capabilities, and other vendor unique information. This
link service may be used to query an N_Port to discover what document identifiers (and the associated
FC-4 protocols and profiles) it supports. Optionally
RNC may be used between two N_Ports to specify
which specific document(s) should be used to set operating parameters for these two N_Ports. RNC may
also be used to specify options or additional parameters specified by the referenced documents which
are not specified during N_Port Login.
Format: FT_1
Addressing: The S_ID field designates the
source N_Port requesting the capabilities information. The D_ID field designates the destination N_Port to which the request is being made.
Payload: The format of the Payload is shown in
table 164.
The RNC Link Service may be used anytime after N_

Port Login.
Protocol:
Report Node Capabilities Information (RNC) request Sequence
Accept (ACC) reply Sequence
35
dpANS X3.xxx-199x
Table 164 RNC/ACC Payload
Item
Size Bytes
hex 53 for RNC

hex 02 for ACC
Reserved
Payload Length
RNC Flags
Reserved
VU Information Length (VU_Len)
Vendor Identifier
Capability Entry(s)
Vendor Unique Information
0-128
Payload Length: Bytes 2-3 of Word 0 contain a

16-bit unsigned binary integer that specifies the
length of the RNC payload.
The minimum length of an RNC or RNC Accept
payload is 16 bytes. The maximum length shall
be limited to 256 bytes. The requesting N_Port
shall be responsible for ensuring payload length
does not exceed this limit. The maximum length
of the RNC Accept payload is not specified.
RNC Flags: Byte 0 of Word 1 contains an 8-bit
flag field which defines options applicable to all
Capability Entries in the RNC payload.
Bit 7: Select (S)
0 = Report all capabilities
1 = Select option requested
If the Select bit is zero, the RNC Accept
pa yloa d shall contain all Capability Entries the responding N_Port wishes to report.
If the Select bit is set to 1, the requesting
N_Port is specifying that the RNC Accept
payload contain only one Capability Entry. The Capability Entry specified in the
Accept payload shall be selected from the
list of capabilities given in the RNC payload. The Select bit also specifies that the
Low Revision and High Revision fields in
the RNC Accept payload shall be equal
for the capability being selected. If the responding node does not support any o f
36
th e c ap ab ilitie s liste d , it s ha ll re tu rn n
RNC Accept without any Capability Entries.
The act of selecting a specific capability
entry allows two nodes to agree upon a
set of specific operating parameters. The
selection may set or imply certain operating modes or parameters for a particular
p roto col, FC-4 , or o the r Fib re C ha nne l
characteristic as defined by the document
referenced in the capability entry. For example, if the capability entry refers to a
profile for a specific FCP implementation,
then selecting that capability entry may
specify class, process login parameters,
allowable SCSI commands, etc.
The RNC link service sh all no t re place
the normal parameter exchange (such as
process login). It does, however, provide
a mechanism for both nodes to anticipate
t h e p r e f e rr e d p a ra me t e r s o f th e o th e r
node.
If tw o N _Por ts sup po rt multip le FC -4s ,
p ro tocols, or for so me o ther reason re quire a selection of more than one capability entry, the RNC link service may be
used multiple times. (See Invalidate Previous bit below).
Bits 6-0: Reserved (r)
VU Information Length (VU_Len): Byte 3 of
word 1 contains an 8-bit unsigned binary integer that specifies the length of the Vendor
Unique Information field in bytes. Up to 128
bytes are supported.
Vendor Identifier: The Vendor Identifier field
contains eight bytes of ASCII data (code values
hex 20 through hex 7E) identifying the vendor
of the product. The data shall be left aligned
within this field. Any unused bytes are placed at
the end of the field (highest offset) and the unused bytes shall be filled with space characters
(hex 20). See X3T10/995D (SCSI-3 Primary
Commands) Annex C for an example of this formatting.
NOTE It is intended that this field provide a
unique vendor identification of the manufacturer of
the Fibre Channel device. In the absence of a formal registration procedure, X3T10 maintains a list
of vendor identification codes in use. Vendors are
dpANS X3.xxx-199x
requested to voluntarily submit their identification
codes to X3T10 to prevent duplication of codes.
Capability Entry: The Capability Entry field is

shown in table 165.
Table 165 Capability Entry

Item
Size Bytes
Flags: IEVVrrPP (bits)
Document Identifier
Low Revision
High Revision
Reserved
0 or 2
Extension Length (N)
0 or 2
Extension
0 or N
Flags: The Flags specify the type of entry as

well as other defining information for this entry.
se r vic e e xc h a ng e . Th e r e sp o n din g N_
Port shall clear any parameter or mode
settings associated with the invalidated
Capability Entry. The responding N_Port
shall select another Capability Entry from
th e se t o f e n trie s in th e R NC p a ylo ad .
(The Capability Entry with the Invalid bit
set is not a valid selection).
Bit 6 - Extended (E)
0 = No Extension
1 = Extended Format
If the Extended bit is 0, then the Capabilities Entry is exactly 4 bytes long.
If the Extended bit is 1, then the Capabilities En try is gre ater than 4 byte s lon g.
Byte 6 (offset from the beginning of this
capability entry) specifies the Extension
Length.
Bits 5-4 - Vendor Unique (V)
Bit 7 - Invalidate Previous (I)
00 = D ocume nt Iden tifie r is not ve ndo r

unique.
0 = Selectable Entry
01 = Document Identifier is vendor unique
1 = Invalidate Previous Selection
10 = Document Identifier is vendor unique

as d efine d b y vend or o f th e N_ Port receiving the payload.
Th is b it is on ly me a n in g fu l if th e R NC
Fla g s S e le ct b it is o n . F ur th e r mo r e , it
shall be set on the first Capability Entry in
the payload. It is used when the requesting N_Port wants to cancel the capability
entry selected with a previous RNC link
service request and have the responding
N_Port make a new selection.
When the RNC Flags Select bit is set to
1, and the first Capability Entry Flags Invalidate bit is set to 0, then the requesting
N_Port is specifying that the responding
N_Port shall select one of the Capability
Entries from the entries in the payload.
When the RNC Flags Select bit is set to 1
and the Invalidate bit is set to 1 in the first
Capability Entry, then the requesting N_
Port is indicating that this capability entry
shall be invalidated. All bytes in the Capability Entry marked with the Invalidate
bit shall match the values of a Capability
Entry selected during a previous RNC link
11 = reserved
Vendor unique Document Identifiers are
qualified by the 8-byte ASCII Vendor Identifier. Thus each vendor may use any identifier value, 0 through hex FF, for vendor
unique document identifiers.
When the Vendor Unique bits are set to
10 the N_Port sending the RNC or RNC
Accept must have previously obtained the
Ven do r Id entifie r o f the de stin ation N_
Port. This is inherent if sending an RNC
Accept. If sending an RNC then the information may have been obta ined from a
previous RNC/RNC Accept exchange or
some other method outside the scope of
this standard.
Bits 3-2 - Reserved (r)
Bits 1-0 - Preference (P)
Preference is a two bit value indicating
37
dpANS X3.xxx-199x
the level of support or performance relative to the other capabilities supported for
this FC-4. These may be used as an aid
in choosing a specific capability if multiple capabilities are supported. The Preference value ranges from 0 to 3.
or other information as defined by the referenced

document. This standard does not define the
meaning or content of the extension beyond the
Extension Length field.
Table 166 Document Identifiers
00 = Best
01
Profile or Standard Name
Identifier
Reserved
00
FC-LE
01
FC-SB
02
Document Identifier: If the V flags are 00 this

is a document Identifier as specified in table
166. If the V flag is not 00 then this is a vendor
unique Document Identifier.
IPI-3
03
SCSI-FCP
04
FC-FP
05
Low Revision: The Low Revision field represents the lowest revision of the specified document supported.
Reserved
10
11 = Worst
High Revision: The High Revision field represents the highest revision of the specified document supported.
06-0F
FC-GS
10
FC-FG
11
FC-SW
12
FC-AL
13
The revision fields shall represent a decimal revision between 0.0 (hex 00) and 25.5 (hex
FF). Changes to the revision number in increments smaller than 0.1 can not be represented
by RNC.
Reserved
FCSI Mixed Mode SCSI Profile
21
Extension Length: The Extension Length is a

16-bit unsigned binary integer that specifies the
number of additional bytes, including itself and
the precedin reserved field, present in the extended capability entry.
FCSI Class 2 SCSI Profile
22
FCSI IP Profile
23
FCSI IP Class 2 Profile
24
FC-PLDA - Private Loop Direct

Attach
25
FLA -Fabric Loop Attach Profile
26
The value of the Extension Length field shall be

a multiple of four. Each document which defines extensions shall ensure the length of the
extension allows four byte alignment.
NOTE For example, if the extension is 1 bytes,
the Extension Length is 8: 2 bytes for the reserved
field, 2 bytes for the Extension Length field, and 4
bytes allocated for the Extension, of which only 1
is used.
Extension: Capability Entry extensions may be

used to specify additional bit flags, parameters,
IBM/HP/Ancor
Deviations
14-1F
FC-PH
Reserved
4.2
20
27-FF
Vendor Unique Information: The format of the

Vendor Unique Information is defined by vendor or
profile specific documentation.
Reply Link Service Sequence:
Service Reject (LS_RJT)
signifies rejection of the RNC command
(see 21.5.2)
Accept
38
dpANS X3.xxx-199x
signifies that the destination N_Port has
transmitted the requested data.
- Accept Payload:
The format of the Accept Payload is
identical to the format of the RNC payload, except for the command code, and
is shown in table 164.
RNC Collision:
If an N_Port has transmitted an RNC Link Service request Sequence to an N_Port and receives an RNC Link Service request Sequence
from the same N_Port before the RNC Accept
Sequence then a collision has occurred. To
avoid ambiguity in the case the Select option
was used, N_Ports which implement RNC shall
detect RNC collisions. In the case of a collision
the N_Port shall compare N_Port_Names. If the
N_Port_Name of the sequence recipient is less
than the N_Port_Name of the sequence initiator, then the sequence recipient shall reply with
an LS_RJT, Reason Code = Logical busy.
39
dpANS X3.xxx-199x
22
Classes of Service
Enhancements to FC-PH and FC-PH2.

22.6 Class 6 - Uni-Directional Dedicated
Connection
Class 6 is a service which provides Dedicated
Connections for Reliable multicast (see clause
31) for a Fabric topology. A class 6 connection
is requested by an N_Port for one or more destination N_Ports. An acknowledgement is returned by the destination N_Ports to a multicast
server which returns an acknowledge to the
connection initiator, establishing a reliable multicast connection. In general, once a connection
is established, it shall be retained and guaranteed by the Fabric until the connection initiator
requests removal.
22.6.1
Class 6 function
A Class 6 connection is requested by an N_Port

to one or more destination N_Ports via transmission of a frame containing a SOFc1. A
Class 6 SOFc1 is identical to a Class 1 SOFc1.
The Fabric recognizes the multicast D_ID and
performs the Class 6 multicast function. The
Fabric establishes circuits between the requesting N_Port and the destination N_Ports. The
destination N_Ports each transmit an ACK, indicating acceptance, which are intercepted by the
multicast server. The multicast server, based
on the ACKs, RJTs, or BSYs received from the
destinations, transmits an ACK, a P_RJT, or a
P_BSY to the requesting N_Port indicating acceptance, rejection, or busy for the request.
The return of an ACK indicates the establishment of a multicast connection. The Fabric reta i n s t h e a llo c a te d c ir c u it s b e t w e e n th e
requesting N_Port and the destination N_Ports
until the connection initiator request the Dedicated Connection be removed.
Class 1 Delimiters, as specified in FC-PH
clause 22.1.3, are used to establish and remove the Dedicated Connection and to initiate
and terminate one or more sequences within
the Dedicated Connection.
Class 1 service parameters, as specified during
Login, shall be used to manage Class 6 connections.
40
22.6.2
Class 6 rules
The following rules apply to exclusive Class 6

Connections. See FC-PH 22.4 for additional
rules applicable to intermix. To provide a Class
6 Connection, the transmitting and receiving N_
Ports, Fabric, and multicast server shall obey
the following rules:
a) Except for some Link Service Protocols
(see FC-PH clause 21), an N_Port requesting
a Class 6 Connection is required to have previously logged in with the Fabric and the N_
Ports with which it intends to communicate,
either implicitly or explicitly. To Login explicitly, the requesting N_Port shall use Fabric
and N_Port Login protocols (see FC-PH
clause 23).
b) The Fabric is responsible for establishing
a Connection at the request of an N_Port and
retaining it until the requesting N_Port explicitly requests removal of the Connection or the
requesting N_Ports link participates in a primitive sequence protocol (see FC-PH clause
16.4). To establish or remove the Dedicated
Connection, the requesting N_Port shall use
the Class 1 Delimiters as specified in FC-PH
clause 22.1.3.
c) Afte r tran smittin g a Cla ss 6 /SOFc 1
frame, the N_Port requesting the Connection
shall not transmit additional frames to the
destination N_Ports until it receives, from the
multicast server, an ACK which shall establish the connection.
d) Once a Connection is established between multiple N_Ports, only the requesting
N_Port (Connection Initiator) shall send data
frames. Only the Connection Initiator shall
cause the connection to be terminated. All
frames shall contain S_ID and D_ID as appropriate (i.e. The D_ID shall be the multicast
address).
e) A destination N_Port shall acknowledge
delivery of every valid Data frame with an
ACK_1 or ACK_N, or the entire Sequence
with a single ACK_0 (see FC-PH clause
22.1.5).
f) The Sequence Initiator shall increment
the SEQ_CNT field of each successive frame
transmitted within a Sequence. The Fabric
shall guarantee delivery of the frames at the
dpANS X3.xxx-199x
receivers in the same order of transmission
within the Sequence (see FC-PH clause
24.3.6).
g) The Connection Initiator N_Port of an established Connection may originate multiple
Exchanges and initiate multiple Sequences
within that Connection. This N_Port shall assign a unique X_ID called OX_ID. The multicast server for the Exchange shall assign an
X_ID unique to the Responders called RX_
ID. The value of the RX_ID shall be negotiated during N_Port/Fabric login (see 23.6.8).
Thus, within a given Connection, the value of
OX_ID or RX_ID is unique to the respective
N_Port and multicast server. The Sequence
Initiator (Connection Initiator) shall assign a
SEQ_Qualifier, for each Sequence it initiates,
which is unique to the Sequence Initiator and
the respective Sequence Recipients.
k) The End-to-end Credit established during

the Login protocol by interchanging service
Parameters shall be honored (see FC-PH
clause 26.3). End-to-end credit shall be managed between Connection Initiator and the
multicast server. At the beginning of a Connection, the End-to-end Credit_Count is reinitialized to the value determined during Login.
A Class 6/SOFc1 frame shall share the Endto-end Credit with Class 2 frames (see FCPH clause 26.3).
l) The Fabric shall guarantee full bandwidth
availability to the connected N_Ports (see
FC-PH clause 3 and annex M).
m) Frames within a Sequence are tracked
on an Sequence_Qualifier and SEQ_CNT
basis (see FC-PH clause 18.1.1)
n)
Same as FC-PH Clause 22.1.2 item n.
h) Communicating N_Ports and the multicast server shall be responsible for end-toend flow control, without any fabric involvement. ACK frames are used to perform endto-end flow control (see clause 22.1.5). All
Class 6 frames, except Class 6/SOFc1, participate only in end-to-end flow control. A
Class 6/SOFc1 frame participates in both
end-to-end and buffer-to-buffer flow controls.
o) If an N_Port does not support Class 6

(i.e. does not support Class 1) and receives a
Class 6/SOFc1 frame, the N_Port shall issue
a P_RJT with a SOFn1 and EOFdt with a
reason code of Class not supported. If an F_
Port does not support Class 6 and receives a
Class 6/SOFc1 frame, the F_Port shall issue
an F_RJT with a SOFn1 and EOFdt with a
reason code of Class not supported.
i) The Fabric may reject a request for a

Class 6 Connection or issue a busy with a
valid reason code. After the Dedicated Connection is established, the Fabric shall not interfere with the Connection. The Fabric shall
issue a F_BSY to any Class 2 frame or discard any Class 3 frame, transmitted from a
third N_Port and destined to one of the N_
Ports engaged in the Connection (see FC-PH
clauses 20.3.3.1 and 20.3.3.3).
p)
j) The destination N_Ports specified in the

Class 6/SOFc1 frame may respond with a
busy or a reject with a valid reason code to
this frame. The multicast server shall interpret these responses and respond with an
ACK, busy, or a reject with a valid reason
code to the requesting N_Port (see section
on multicast server). Once the Dedicated
Connection is established, the destination N_
Ports shall not issue a busy but may issue a
reject (see FC-PH clauses 20.3.3.2 and
20.3.3.3).
Same as FC-PH Clause 22.1.2 item p.
q) The Connection Initiator shall send two

zero length payload frames as the last two
frames of a Sequence.
NOTE This simplifies the processing of an abort
on the last non-zero payload frame of a Sequence.
r) The effect of preemption of one destination N_Port on the remaining N_Ports is implementation-dependent.
22.6.3
Class 6 delimiters
Same as FC-PH Clause 22.1.3.

22.6.4
Class 6 frame size

22.6.5
Class 6 flow control
ACK frames are used to perform Class 6 endto-end flow control. ACK frames are started
with SOFn1. Destination N_Ports shall not ter-
41
dpANS X3.xxx-199x
minate Sequences or Connections. All ACK
frames shall end with EOFn.
All Class 6 frames shall follow end-to-end flow
control rules (see FC-PH clause 26.4.1). The
Class 6/SOFc1 frame shall follow both end-toend and buffer-to-buffer flow control rules (see
FC-PH clause 26.5.1).
22.6.6
Stacked Connect-requests
42
dpANS X3.xxx-199x
23
Login and Service Parameters
This clause describes the changes that are

made in FC-PH-3 to support:
the E_D_TOV timer resolution enhancement.
Priority/Preemption
Enhancements to FLOGI to expand the

payload.
23.1
erate according to R_RDY Primitive, ACK, and

Link_Response rules specified in clause 20.
Explicit Fabric Login is performed during the initialization process under the assumption that a
Fabric is present. The first explicit Login is directed to the Fabric using the well-known Fabric add r e s s ( i .e ., F _ P o r t a t h e x F F FF FE ) . I t is
mandatory for all Fabric types to support the explicit Login procedure. In its first attempt at explicit
Fabric Login, an N_Port shall set the following S_
ID:
Introduction
The Login procedure is a method by which an

N_Port establishes its operating environment
with a Fabric, if present, and other destination
N_Ports with which it communicates. Fabric Login and destination N_Port Login are both accomplished with a similar procedure using
different Destination_Identifiers (D_IDs) and
possibly different Source_Identifiers (S_IDs).
Login between an N_Port and the Fabric or between two N_Ports is long-lived. The number of
concurrent N_Ports with which an N_Port may
be logged in with is a function of the N_Port facilities available. There is no one to one relationship between Login and Class 1 Dedicated
Connections.
Explicit Login is accomplished using the Login
(FLOGI/PLOGI) Link Service Sequence within
a separate Exchange to transfer the Service
Parameters (contained in the Payload) of the
N_Port originating the Login Exchange. The
Accept (ACC) contains the Service Parameters
of the Responder (contained in the Payload).
Implicit Login is a method of defining and
specifying the Service Parameters of destination N_Ports by means other than the explicit
use of the Login Exchange. Specific methods of
implicit Login are not defined in FC-PH.
When Login is referred to throughout other sections of this document, either the explicit or implicit procedure is acceptable. Implicit Login is
assumed to provide the same functionality as
Explicit Login. Default Login values are specified in 21.1.1. Explicit Login replaces previous
Service Parameters and initializes end-to-end
or buffer-to-buffer credit, or both. The Login
procedure shall follow the Exchange and Sequence management rules as specified in
clause 24. Frames within a Sequence shall op-
Bits 23-0 equal to binary zeroes (denoted as

0), or
Bits 23-8 equal to binary zeroes and bits 7-0
equal to a model-dependent value (denoted as
0000yy).
If the N_Port receives an F_RJT with a reason
code of Invalid S_ID, it may use its last known native address identifier in the FLOGI Sequence as
its S_ID.
The remainder of 23.1 is unchanged from FC-PH.
23.2
Applicability

23.3
23.3.1
Fabric Login
Explicit Fabric Login
The explicit Fabric Login procedure shall require

transmission of a Login (FLOGI) Link Service Sequence within an Exchange with an assigned OX_
ID by an N_Port with a Destination Identifier (D_
ID) of the well-known F_Port address (FFFFFE)
and a Source Identifier (S_ID) of either 0 or
0000yy.
When S_ID = 0 is used, the F_Port shall either:
assign a Fabric unique N_Port Identifier to
the N_Port in the ACC reply Sequence, or
return an F_RJT with a reason code indicating Invalid S_ID, if the Fabric does not support
N_Port Identifier assignment. The N_Port shall
assign its native N_Port Identifier by another
method not defined in FC-PH and retry the FLOGI Sequence with an S_ID = X.
When S_ID = 0000yy is used, the F_Port shall either:
43
dpANS X3.xxx-199x
If the F_Port has rejected both S_ID = 0 or
0000yy and S_ID = X, the N_Port shall attempt
to reLogin with another value of X, or determine
a valid value of X by a method not defined in
FC-PH.
assign a Fabric unique N_Port Identifier

to the N_Port in the ACC reply Sequence by
setting bits 23-8 and validating bits 7-0, or
return an F_RJT with a reason code indicating Invalid S_ID, if the value in bits 7-0
does not allow a Fabric unique Identifier to be
generated. The N_Port shall assign a different value for yy and retry the FLOGI Sequence with an S_ID = X.
The remainder of 23.3.1 is unchanged from FCPH.
23.3.2
Responses to Fabric Login
23.3.2.1 FLOGI with S_ID = 0 or 0000yy
If S_ID = X is used, the F_Port shall either:
Table 94 describes the set of possible responses to Fabric Login with an S_ID = 0 or 0000yy
and a D_ID of hex FFFFFE. Further description of the response primitive or frame is found
in clause 20.
return an ACC reply Sequence with D_ID

= X (confirming identifier), or
return an F_RJT with a reason code indicating Invalid S_ID, if X is invalid.
Table 94 Responses to FLOGI frame (S_ID = 0 or 0000yy) - Fabric Login

Response/
Reply Seq
D_ID
S_ID
Indication
N_Port Action
N/A
N/A
Class 1 (SOFc1)
Class 2 or 3
successful frame delivery
to F_Port or N_Port
2. Last ACK
0 or
0000yy
FFFFFE
FL O G I Se q ue n ce h as
been received by N_Port or
F_Port
wait f or Reply Data

frame Sequence
3. ACC
X or
XXXXyy
FFFFFE
OX_ID = FLOGI OX_ID

If Co mmo n Se rv = F_
Port, Fabric Login complete
Perform destination N_
Port Login (23.4.2.1) (Fabric present)
4. ACC
0 or
0000yy
FFFFFE
OX_ID = FLOGI OX_ID

If Co mmo n Se rv = N_
Port, no Fabric present
Perform point-to-point
destination N_Port Login
(23.4.2.1)
5. F_BSY or
P_BSY
0 or
0000yy
FFFFFE
1. R_RDY
Busy
6. F_RJT or
P_RJT
0 or
0000yy
FFFFFE
reason code
Class not supported
Invalid S_ID
Other
wait for frame
retry later
FL O GI n e x t C l a s s
(S_ID = 0 or 000yy)
FLOGI with S_ID = X
or different yy
respond accordingly
7. FLOGI
FFFFFE
0 or
0000yy
Collision with other N_

Port
8. LS_RJT
X or
XXXXyy
FFFFFE
Fabric present
reason code
re L o g in w it h a lte r e d
Service Parameters, use
D_ID of LS_RJT
error
perform ABTS after Sequence Timeout
9. None
44
See FC-PH
dpANS X3.xxx-199x
These responses are characterized by the following:
Response 1 is possible from an N_Port or
Fabric.
Response 2 is from a Fabric or an N_
Port. The D_ID and S_ID values (in the response to the FLOGI Sequence) correspond
to the values in the FLOGI fields, respectively, in the FLOGI Sequence (also for responses 5 and 6).
Connection associated with FLOGI shall be

removed by the normal method to remove a
Dedicated Connection in Class 1. See 23.6.4
for a description of N_Port_Names. See
23.4.2.3 for a description of point-to-point
destination N_Port Login.
Response 8 indicates that the Login request is being rejected for a reason specified
in the LS_RJT frame. The FLOGI request
may be retried if the appropriate corrective
action is taken.
Response 3 completes Fabric Login. The

N_Port S_ID is assigned as X or XXXXyy.
Response 9 indicates that a Link error

has occurred.
Response 4 indicates a point-to-point topology with another N_Port, which is determined by examining the Common Service
Parameter which specifies N_Port or F_Port.
Based on a comparison of Port_Names, either transmit PLOGI, or wait for PLOGI.
NOTE When an N_Port originates an Exchange

using an N_Port Identifier of unidentified (binary
zeroes or 0000yy), its N_Port Identifier may
change between transmitting a request Sequence
(Login) and receiving the reply Sequence (Accept).
Response 5 indicates that either the Fabric or N_Port is busy, retry later.
Response 6 indicates a Fabric or N_Port
reject. If Class is not supported, retry Login
with another Class with a numerically higher
value. If the reason code is Invalid S_ID, then
retry FLOGI with a different value of yy, or
with a value of X (see 23.3.2.2). For other reject reasons, the N_Port shall respond accordingly.
Response 7 indicates a point-to-point attachment and a collision with a FLOGI from
the attached N_Port. The N_Port shall respond with ACC. The Common Service Parameters shall contain the same information
as FLOGI, but shall indicate that an N_Port is
transmitting the Data. Port_Name and Node_
Name shall be included, but all Classes of
Service shall be indicated as invalid. The N_
Port shall compare the Port_Name received
to the Port_Name it transmitted. If this N_
Ports value is lower, it shall end this Exchange and wait for a PLOGI from the attached N_Port. In Class 1, if this N_Ports
value is lower, it shall become the Connection Recipient (see clause 28) for this Connection. In Class 1, if its value is higher, it
shall become the Connection Initiator for this
Connection. If its value is higher, it shall
transmit a PLOGI (see 23.4.2.3) as part of a
new Dedicated Connection. The Dedicated
23.6
N_Port Service Parameters
Figure 59 provides the payload format of the

FLOGI or PLOGI Extended Link Service commands and their respective ACC replies.
Item
Size
(Bytes)
LS_Command code
Common Service Parameters
16
Port Name
Node or Fabric Name
Class 1 Service Parameters
16
16
16
16
Vendor Version Level
16
Reserved
16
Services Availability (see note)
Reserved (see note)
116
Figure 59 FLOGI, PLOGI, or ACC

Payload
NOTE These fields are only present when the
Payload Length bit (see 23.6.2.3) is set to 1. When
the Payload Length bit is set to 0, these fields are
45
dpANS X3.xxx-199x
not present in the payload, i.e., the payload is 128
bytes long.
23.6.1
ters
N_Port Common Service Parame-
Table 98 provides a summary of N_Port Common Service Parameters based on x3.2301994 (FC-PH) table 98.
46
dpANS X3.xxx-199x
Table 98 N_Port Common Service Parameter Applicability

N_Port Login
Class
Service Parameter
Fabric Login
Class
Wd
Bits
Highest Version
31-24
Lowest Version
23-16
15-0
Continuously Increasing (C)
31
Random Relative Offset (O)
30
29
N_Port/F_Port
28
Alternate
BB_Credit
Management (see 26.5)
27
E_D_TOV Resolution (see 23.6)
26
Payload Length (see 23.6.2.3)
16
Buffer-to-Buffer
Receive Data field Size
11-0
N_Port
Total
Sequences
31-16
Relative Offset by Info Category
15-0
E_D_TOV (3) (4)
31-0
PTP
FC-PH Version
Buffer-to-Buffer Credit
Common Features
Concurrent
PTP PTP
Notes
1) y indicates yes, applicable
2) n indicates, not applicable
3) PTP indicates the applicability only to Point-to-Point.
4) R_A_TOV and E_D_TOV provided by the F_Port as Fabric Common Service Parameters
during Fabric Login are not shown in this table.
47
dpANS X3.xxx-199x
23.6.2 N_Port Common Service parameters - Fabric Login
Enhanced N_Port Common Service parameters used during Fabric Login are illustrated in
figure 61.

Word 1, bits 31-30
Reserved.
Word 1, bits 28 (N)
Specified in x3.230-1994 (FC-PH).
31
word
16
15
FC-PH / FC-PH-2 /
FC-PH-3 Version
Buffer-to-buffer
Credit (Pt to Pt)
HHHHHHHH LLLLLLLL
BBBBBBBBBBBBBBBB
31
15
Specified in x3.xxx-1995 (FC-PH-2).
16
Word 1, bits 26-17
Common
Features
Buffer-to-buffer
Rcv Data Field size
rrVN Arr r r r r r r r r P
r r r r F F F F FFFF FFFF
Word 1, bits 29, 27 (VA)
Reserved.
Word 1, bit 16- Payload Length (P)
31
Total Concurrent
Sequences
Reserved
rrrrrrrr rrrrrrrr
Relative Offset by
Info Category
Reserved
rrrrrrrr rrrrrrrr
1 = 256 bytes
31
Reserved
rrrrrrrr rrrrrrrr
Reserved
rrrrrrrr rrrrrrrr
Figure 60 N_Port Common Service

Parameters - Fabric Login
Table 99 specifies the hexadecimal values for
low and high FC-PH-3 version levels indicated
in word 0, bits 31-16 of N_Port Common Service parameters.
Table 99 FC-PH-3 Version

Hex value
Word 1, Bit 16 indicates the length of the

FLOGI payload. If Word 1 Bit 16 = 0, then
the payload shall be 128 bytes, the same
as specified in FC-PH-2. If Word 1 Bit 16
= 1, then the payload shall be 256 bytes.
Word 1, bits 15-0 Buffer-to-buffer
Receive Size (F)
T h e b u f f e r - t o - b uf f e r R e c e i v e D a t a _
Field Size is a binary value (bits 15-0)
w h ich s pe cifies the la rg est Da ta_ Field
Size for an FT_1 frame (17.4) that can be
received by the N_Port supplying the Service Parameters as a Sequence Recipient for:
a connect-request (SOFc1),
a Class 2 Data frame, or
a Class 3 Data frame.
Version level
00-09
See FC-PH Tables 99 or 100
0A-0F
Reserved
10
FC-PH-2
11-1F
Reserved
20
FC-PH-3
21-FF
Reserved

48
0 = 128 bytes
Values less than 256 or greater than 2 112 are

invalid. Values shall be a multiple of four bytes.
The buffer-to-buffer Receive Data_Field size is
specified by FC-2.
23.6.3 N_Port Common Service Parameters - N_Port Login
N_Port Common Service Parameters used during N_Port Login are shown in figure 61.
dpANS X3.xxx-199x
31
16
15
FC-PH / FC-PH-2
Version
Buffer-to-buffer
Credit (Pt to Pt)
HHHHHHHH LLLLLLLL
BBBBBBBBBBBBBBBB
31
15
word
0
16
Common
Features
Buffer-to-buffer
Rcv Data Field size
COVNAR r r r D r r r r r P
31
2
Total Concurrent
Sequences
rrrrrrrr TTTTTTTT
Relative Offset by
Info Category
DDDDDDDDDDDDDDD
31
E_D_TOV
3
(Pt-to-Pt)
tttttttt
tttttttt
tttttttt tttttttt
Figure 61 N_Port Common Service

Parameters - N_Port Login
Same as 23.6.2.1.

PLOGI payload. If Word 1 Bit 25 = 0, then
Receive Size (F)
The buffer-to-buffer Receive Data_
Field Size is a bin ary va lue (bits 15 -0 )
wh ich sp ec ifie s th e la rg e st D ata _ Fie ld
received by the N_Port supplying the Service Parameters as a Sequence Recipient for:

The buffer-to-buffer Receive Data_Field size is
specified by FC-2.

23.6.3.5 Total Concurrent Sequences
Word 1, bits 31- 28 (COVN)
Word 1, bit 27, 22 (AD)
Specified in x3.xxx -1995 (FC-PH-2).
Word 1, bit 26 - E_D_TOV Resolution (R)
0 = 1 ms
1 = 1 ns
Word 1, Bit 26 indicates the resolution of
the E_D_TOV timer. If Word 1 Bit 26 = 0,
then the timer shall be in increments of 1
ms. If Word 1 Bit 26 = 1, then the timer
shall be in increments of 1 ns.
Word 1,bits 25-23, 21-17
Reserved
Word 1, bit 16 - Payload Length (P)
0 = 128 bytes

23.6.3.6 Relative Offset by category
23.6.3.7 Point-to-point E_D_TOV value
Word 3 shall only be meaningful by an N_Port
in a point-to-point topology. In a topology other
than point-to-point, word 3 shall not be meaningful. When Word 1, Bit 26 = 0, the E_D_TOV
value shall be specified as a count of 1 ms increments. When Word 1, Bit 26 = 1, the E_D_
TOV value shall be specified as a count of 1 ns
increments. Therefore, based on the setting of
Word 1, Bit 26, a value of hex 0000000A specifies a time period of either 10 ms or 10 ns.
The E_D_TOV value in the Accept shall be
greater than or equal to the value in the PLOGI.
The E_D_TOV value in the Accept shall be the
value used by each N_Port. R_A_TOV shall be
a value twice the E_D_TOV value in a point-topoint topology.
1 = 256 bytes
49
dpANS X3.xxx-199x
23.6.6
N_Port Class Service Parameters
Table 98 provides a summary of N_Port Class Service Parameters based on FC-PH-2 table 101.
Table 101 N_Port Class Service Parameter Applicability

N_Port Login
Class
Service Parameter
Fabric Login
Class
Wd
Bits
1/6
1/6
31
Intermix Mode
30
Stacked Connect-Request
29-28
Sequential Delivery
27
Dedicate Simplex
26
Camp-On
25
Buffered Class 1
24
Priority (see 18.9.2)
23
X_ID Reassignment
15-14
Initial Responder Process_Associator
13-12
ACK_0 capable
11
ACK_N capable
10
ACK generation assistance
Data compression capable
Data compression History buffer size
7-6
Data encryption capable
Clock synchronization capable
FC-PH Version
Valid = 1
Service Options
Initiator Control
50
dpANS X3.xxx-199x
Table 101 N_Port Class Service Parameter Applicability
N_Port Login
Class
Service Parameter
Fabric Login
Class
Wd
Bits
1/6
1/6
ACK_0 capable
31
ACK_N capable
30
X_ID Interlock
29
Error Policy Supported
28-27
Categories per Sequence
25-24
Data compression capable
23
Data compression History buffer size
22-21
Data decryption capable
20
Clock synchronization capable
19
Reserved - Fabric specific
18-16
Receive Data Field Size
15-0
Concurrent Sequences
31-16
N_Port End-to-end Credit
14-0
Open Sequences per Exchange
31-16
Recipient Control
Notes
1) y indicates yes, applicable
2) n indicates, not applicable
See FC-PH or FC-PH-2 for all items without

cross-references.
51
dpANS X3.xxx-199x
23.6.7 N_Port Class Service Parameters Fabric Login
Figure 62 illustrates N_Port Class Service Parameters for Fabric Login, enhanced from
x3.230-1994 (FC-PH) and X3.xxx-1995 (FCPH-2).
31
word
16
15
Initiator Control
VISSQDCB PEEEEEEE
DDDDDDDD DDDDDDDD
31
15
Rcv Data Field size
CCCCCCCC CCCCCCCC
Neither supports
Fabric is capable of supporting.
N_Port support requested, Fabric does not support
N _Port requested, Fabr ic

agrees, Priority/Preemption is
enabled
31
15
Class 3
Word 0, bit 23 is reserved.
Word 0, Bit 22 - 16
16
Concurrent
Sequences
rrrrrrrr LLLLLLLL
31
Recipient Control
Service Options
16
N_Port F_Port
16
Open Sequences per

Exchange
rrrrrrrr xxxxxxxx
N_Port End-to_end
Credit
Reserved
23.6.7.3 Initiator control
0MMMMMMMMMMMMMMMM
This field is not meaningful during Fabric Login.
15
Reserved

rrrrrrrr
rrrrrrr
Figure 62 N_Port Class Service


No change from FC-PH or FC-PH-2

Word 0, Bit 30-24 (ISSQDCB)
Class 1, 2, 3, and 4
Word 0, Bit 23 - Priority/Preemption (P)
0 = Priority/Preemption not supported
1 = Priority/Preemption supported
See clause 18.9

23.6.8 N_Port Class Service Parameters N_Port Login
Figure 62a illustrates N_Port Class Service Parameters for N_Port Login, enhanced from
x3.230-1994 (FC-PH) and X3.xxx-1995 (FCPH-2).
Class 1, 2, and 4
When an N_Port performs Login with a Fabric,

it shall request support for Priority/Preemption
by specifying bit 23 = 1. If the Accept reply from
the Fabric specifies bit 23 = 1, then both the N_
Port and Fabric have agreed that Priority/Preemption is enabled.
The following set of values specifies the meaning of the combination of Word 0, bit 23:
52

Word 0, Bit 30-24 (ISSQDCB)
dpANS X3.xxx-199x
31
word
0
16
VISSQDCB PEEEEEEE
XXPPZNGC CCEDDDDD
31
15
16
Recipient Control
Word 0, Bit 5
= 0 Initiator does not have data encryption capability
Rcv Data Field size
= 1 Initiator has data encryption capability

Class 4
ZNXLLrSS
CCCEYrrr
31
16
Concurrent
Sequences
rrrrrrrr LLLLLLLL
31
Initiator Control
Service Options
15
r r r r NNNNNNNNNNNN
15
N_Port End-to_end
Credit
16
Open Sequences per

Exchange
rrrrrrrr xxxxxxxx
Same function as Class 1 and 2.
0MMMMMMMMMMMMMMMM
Word 0, bit 4 - Clock synchronization

capable (Y)
15
Class 1,2,3, and 4 (see 39.4.1)
Class 6 Multicast
RX_ID
xxxxxxxx xxxxxxxx
Figure 62a N_Port Class Service

Parameters - N_Port Login
Word 0, Bit 23 - Priority (P)
0 = Priority not supported
1 = Priority supported
See clause 18.9
Word 0, Bit 4
= 0 Initiator does not have clock synchronization capability
= 1 Initiator has clock synchronization capability
Word 1, bit 20 - Data decryption capable
(E)
Class 1, 2, and 4
Class 1,2, and 3 (see 40.2)
When an N_Port performs Login with another

N_Port, it shall indicate support for Priority by
specifying bit 23 = 1. The other N_Port indicates support for Priority by specifying bit 23 =
1 in the ACC sent as a reply. Support of Priority
as an Exchange Originator means that Word 4,
Bits 31-24 of the Frame Header shall specify
the desired Priority and Word 4, Bits 23-16 of
the Frame Header shall specify the OX_ID.
Support of Priority as an Exchange Responder
means that Word 4, Bits 31-24 of the Frame
Header shall be ignored and Word 4, Bits 23-16
of the Frame Header shall be interpreted as the
OX_ID.
Word 1, Bit 20
Class 3
Word 1, Bit 19
= 0 Recipie nt does not have clock synchronization capability
Word 0, Bit 22 - 16
Reserved
Word 0, bit 5 - Data encryption capable
(E)
Class 1,2, and 3 (see 40.2)
= 0 Recipient does not have data decryption capability

= 1 Recipient has data decryption capability
Class 4
Same function as Class 1 and 2.
Word 1, bit 19 - Clock synchronization
capable (Y)
Class 1,2,3, and 4 (see 39.4.1)
= 1 Recipient has clock synchronization

capability
No change from FC-PH or FC-PH-2.
53
dpANS X3.xxx-199x
Same as 23.6.2.1.
23.7.1.2 Buffer-to-buffer (F_Port) Credit
23.6.8.9 Class 6 Multicast RX_ID
When an N_Port performs Login with the Multicast Server, it shall specify the RX_ID value to
be used by the Multicast Server when acknowledging the Connection Initiator. Word 3, bits 150 shall be the RX_ID value used by the Muticast Server.
Word 1, bits 31-27
23.6.9
1 = 1 ns

23.6.10
Services Availability
F_Port Service Parameters
23.7.1
ters
Word 1, bit 26 - E_D_TOV Resolution (R)

0 = 1 ms
Word 1, Bit 26 indicates the resolution of

the E_D_TOV timer. If Word 1 Bit 26 = 0,
then the timer shall be in increments of 1
ms. If Word 1 Bit 26 = 1, then the timer
shall be in increments of 1 ns.
This field is reserved.

23.7
F_Port Common Service Parame-
Word 1, bits 25-24, 22 (MB, D)

Specified in x3.xxx-1995 (FC-PH-2).
Figure 67 illustrates F_Port Common Service

Parameters, enhanced from x3.230-1994 (FCPH) and X3.xxx-1995 (FC-PH-2).
Word 1, bit 23 - Hunt Group (H)

0 = Hunt Groups not supported.
1 = Hunt Groups supported.
31
word
16
15
FC-PH / FC-PH-2
Version
Buffer-to-buffer
Credit
HHHHHHHH LLLLLLLL
BBBBBBBBBBBBBBBB
31
15
16
Common
Features
Buffer-to-buffer
Rcv Data Field size
rrrN rRMB HDrr rrrr
15
Word 1, bit 16- Payload Length
31
16
Word 1, bits 21-17
R_A_TOV
tttttttt
31
0 = 128 bytes
tttttttt tttttttt ttttttt

16
15
1 = 256 bytes
0
E_D_TOV
tttttttt
tttttttt
tttttttt tttttttt
Figure 67 F_Port Common Service

54
Word 1, Bit 23 indicates whether or not

the Fabric supports Hunt Group routing. If
Word 1 Bit 23 = 0, then the Fabric shall
not support Hunt Group routing. If Word 1
Bit 23 = 1, then the Fabric shall support
Hunt Group routing.

ACC payload. If Word 1 Bit 25 = 0, then
dpANS X3.xxx-199x
31

Receive Size (F)
The buffer-to-buffer Receive Data_
Field Size is a bin ary va lue (bits 15-0 )
wh ich sp ec ifie s th e la rg es t D ata _Fie ld
received by the F_Port supplying the Service Parameters as a Sequence Recipient for:
16
VISSQDCB PEEEEEEE
Not Meaningful
31
1
16
15
Recipient Control
Reserved for Fabric
use
31
Not Meaningful
16
31
Rcv Data Field size
15
Concurrent
Sequences
Not Meaningful
tttttttt
Figure 67a F_Port Class Service

23.7.4.1 Class Validity
23.7.1.5 E_D_TOV
No enhancements to FC-PH or FC-PH-2
When Word 1, Bit 26 = 0, the E_D_TOV value

shall be specified as a count of 1 ms increments. When Word 1, Bit 26 = 1, the E_D_TOV
value shall be specified as a count of 1 ns increments. Therefore, based on the setting of
Word 1, Bit 26, a value of hex 0000000A specifies a time period of either 10 ms or 10 ns.

23.7.2
F_Port Name

23.7.3
Fabric Name
Service Options (E) shall specify Class of Service capabilities supported or required by the
Fabric supplying the Service Parameters. (FCPH)
Service options shall specify optional features
of a Class of Service supported by the N_Port
supplying the Service Parameters. (FC-PH-2)
Word 0, Bit 31-24 (VISSQDCB)
Word 0, Bit 23 - Priority (P)
Class 1, 2, and 4
23.7.4
0 = Priority/Preemption not supported
F_Port Class service Parameters
Figure 67a illustrates F_Port Class Service Parameters, enhanced from x3.230-1994 (FC-PH)
and X3.xxx-1995 (FC-PH-2).
CR_TOV
tttttttt tttttttt tttttttt

23.7.1.6 R_A_TOV
N_Port End-to_end
Credit
Not Meaningful
16 15
Initiator Control
15
Service Options
word
1 = Priority/Preemption supported
See clause 18.9
Class 3
55
dpANS X3.xxx-199x
this bit shall indicate that the Fabric does

not support routing to the well-known Key
Distribution Server address identifier.
Word 0, bit 7 - Alias Server

23.7.4.9 C_R_TOV
23.7.5
This field is reserved.

23.7.6
Services Availability
This field returns information regarding the Fabrics ability to route to the defined well-known
addresses.
When set to 1, this bit shall indicate that

the Fa bric supp orts ro utin g to the wellk n o w n A lia s S e r ve r a d d r e s s i d e n tif ie r
( hex FFFFF8) . Wh en s et to 0 , this bit
s ha ll in dica te th a t th e Fa br ic d o es n o t
supp ort routing to the well-known Alias
Server address identifier.
Word 0, bit 6 - Quality of Service
Facilitator
the Fa bric supp orts ro utin g to the wellknown Quality of Service Facilitator address identifier (hex FFFFF9). When set
to 0, this bit shall indicate that the Fabric
d o e s n o t s u p p o r t r o u t i n g t o t h e w e l lknown Quality of Service Facilitator address identifier.
Word 0, bits 31-11 - Reserved
Word 0, bit 5- Management Server
Word 0, bit 10 - Multicast Server

the Fa bric supp orts ro utin g to the wellknown Management Server address identifier (hex FFFFFA). When set to 0, this
bit shall indicate that the Fabric does not
suppo rt routin g to th e well-known Man agement Server address identifier.

the Fa bric suppo rts ro utin g to the wellknown Multicast Server address identifier (hex FFFFF5). When set to 0, this bit
support routing to the well-known Multicast Server address identifier.
Word 0, bit 9 - Clock Synchronization
Server
the Fa bric suppo rts ro utin g to the wellknown Clock Synchronization Server address identifier (hex FFFFF6). When set
to 0, this bit shall indicate that the Fabric
d o e s n o t s u p p o r t r o u t i n g t o t h e w e ll known Clock Synchronization Server address identifier.
Word 0, bit 8 - Security Key Distribution
Server
the Fa bric suppo rts ro utin g to the wellkno wn Key Distribution Server address
identifier (hex FFFFF7). When set to 0,
56
Word 0, bit 4- Time Server

the Fa bric supp orts ro utin g to the wellk n o w n Tim e S e r ve r a d d re ss id e n tif ie r
(h ex FFFFFB). W hen se t to 0, th is bit
supp ort routing to the well-kn own Time
Server address identifier.
Word 0, bit 3 - Directory Server
the Fa bric supp orts ro utin g to the wellknown Directory Server address identifier
(h ex FFFFFC). When se t to 0, this bit
support routing to the well-known Directory Server address identifier.
dpANS X3.xxx-199x
Word 0, bits 2-0 - Reserved
Words 1-7 - Reserved
23.8 Procedure to estimate end-to-end
Credit
57
dpANS X3.xxx-199x
2 4 E x c h a n ge , S e q ue nc e , a n d s e quence count management

Enhancements to FC-PH and FC-PH-2 are
specified.
24.3
Summary rules
24.3.1
Exchange management
i) In Process policy with infinite buffers under Class 1 operation, a Sequence is complete with regard to Data content if at least
the first and last Data frames were received
as valid frames without rejectable errors being detected. For Class 3 Process policy with
infinite buffers, a sequence is complete if a
frame of another sequence is received or E_
D_TOV expires before the last frame of the
current sequence is received.
24.3.7
Normal ACK processing
g) ACK_1 or ACK_N frames with an ACK_CNT

of 1, or an ACK_0 frame, shall be transmitted
during X_ID interlock, (see 25.3.1 and 24.5.4)
and in response to a connect-request (see
28.4.1).
24.3.11
Sequence errors - Class 3
Errors within a Sequence may only be detected

by the Sequence Recipient.
24.3.11.1 Rules common to all Discard
policies
NOTE The following is identical to FC-PH,
24.3.11.
In both Discard policies, the Sequence Recipient shall discard Sequences in the same manner as in Class 1 and 2 with the exception that
an ACK indication of Abort Sequence shall not
be transmitted. In discard policy, the Recipient
shall discard frames received after the point at
which the error is detected. Individual FC-4s or
upper levels may recover the entire Sequence
or only that portion after which the error is detected.
a) The types of errors that shall be detected
by an N_Port include:
detection of a missing frame based on
timeout, or
58
b) If a Recipient detects an internal error, it

shall abnormally terminate the Sequence,
post the appropriate status, and notify the
FC-4 or upper level. One or more Sequences
shall not be delivered based on single or multiple Sequence discard Error Policy.
detection of an internal malfunction.
c) If a Recipient detects a missing frame, it

shall abnormally terminate the Sequence,
post the appropriate status, and notify the
FC-4 or upper level. One or more Sequences
shall not be delivered based on single or multiple Sequence discard Error Policy.
d) In the Discard multiple Sequences Error
Policy in Class 3, the Sequence Recipient
shall not be required to utilize a timeout value
of R_A_TOV following detection of a missing
frame. Therefore, frames may be discarded
for an Exchange forever if other detection
mecha nisms are no t utilize d b y the Sequence Initiator.
e) Notification of the Sequence error condition to the Initiator is the responsibility of the
FC-4 or upper level.
24.3.11.2 Process with infinite buffers Error
Policy
In process Policy, the Recipient shall ignore errors detected on all frames, or timeout errors.
However, such errors shall be reported to an
upper level.
NOTE Ignoring an error on the first frame of a
Sequence or an Exchange may cause the frame to
be delivered to the wrong Recipient.
24.8
24.8.1
Status blocks
Exchange Status Block
An Exchange Status Block is a logical construct

used to associate the OX_ID, RX_ID, D_ID and
S_ID of an Exchange. The Status Block is used
throughout the Exchange to track the progress
of the Exchange and identify which N_Port
holds the initiative to transmit Sequences. The
Exchange Status Block shall continue to exist
even following X_ID Invalidation, since
the Operation_Associator is used to locate the
ESB (use of a Process_Associator may also be
required).
The Exchange Status Block shall record Exchange status information and Sequence Status for a number of Sequences received as a
dpANS X3.xxx-199x
Sequence Recipient. The Exchange Status
Block is supplied in the RES Link Services request. Equivalent information to track transmitted Sequences is required by the Sequence
Initiator fo r internal tracking of Exchange
progress but is not required to be supplied to
any other N_Port. The Sequence Status is
stored in the Exchange Status Block in the oldest to newest order. The oldest Sequence is
dropped out of the ESB when new Sequence
status is added
.
Table 103 Exchange Status Block
Item
Size Bytes
PRIORITY* (if enabled)

OX_ID/with priority enabled
24.8.2
Sequence Status Block
A Sequence Status Block is a logical construct

used to track the progress of a single Sequence
by an N_Port on a frame by frame basis. A Sequence Status Block shall be Opened and
maintained by the Sequence Recipient for each
Sequence received in order to support the RSS
Link Service request. Information equivalent to
an SSB is required for the Sequence Initiator to
track Sequence progress internally, but is not
required to be supplied to any other N_Port
.
Table 104 Sequence Status Block
1
2/1
Item
SizeBytes
SEQ_ID
reserved
Lowest SEQ_CNT
Highest SEQ_CNT
S_STAT
Error SEQ_CNT
Frame header Word 4, Bits 31-16
RX_ID
reserved
RX_ID
Originator address
identifier
(High order byte - reserved)
Responder Address Identifier

(High order byte - reserved
E_STAT
reserved
Service Parameters
Bits 20-0 - Reserved
112
Oldest Sequence Status (SSB

format- first 8 bytes)
Intermediate Sequence Status

(SSB format-first 8 bytes
X*8
Newest Sequence Status (SSB

format-first 8 bytes)
* MSB is Preemption Flag

E_STAT
Bit 31-22
Frame header Word 4, Bits 31-16: When priority is enabled, this field shall contain the current priority in the high order byte and the OX_
ID in the low order byte. When priority is not enabled, this field shall contain the OX_ID.
S_STAT
Bit 15-0

Bit 21- Priority Enabled
0 = Priority/Preemption not enabled
1 = Priority/Preemption enabled
Priority/Preemption enabled reflects the
condition set on login for Word 4, Bits 3116 of the frame header.
59
dpANS X3.xxx-199x
25
Association Header management and usage
No enhancements from FC-PH or FC-PH-2.
26
Flow control management
27
Segmentation and reassembly
60
dpANS X3.xxx-199x
28
Connection management
Enhancements to FC-PH as specified.

28.1
to by an ACK frame. A proper response frame

consists of:
Introduction
Preempting a Dedicated Connection

Interrupting and removing a Class 1 or Class 6
Dedicated Connection between N_Ports and
establishing a new Class 1 or Class 6 Dedicated Connection between an unconnected N_
Port and one or more of the previously connected N_Ports is Preemption. A preemption is initia ted b y a N_ Po rt s ou rcin g a Pr ee mp tio n
Connection Request frame (an SOFc1 with the
Preemption flag set, Word 4 bit 31) to the Fabric. The preempting N_Port then receives (1) a
reject link response frame (F_RJT) with either a
Preemption Request Rejected or a Preemption Not Enabled reason code, or (2) a connection acknowledge (ACK_1 or ACK_N) with an
SOFn1 having the appropriate S_ID and D_ID
fields of the preemption request frame. When
the ACK is received a dedicated connection
has been established. If an F_RJT is received
no connection has been established and the
preemption request process has ended.
NOTE Fabric resolution of a preemption request
may be based on the priority of the connection request (established when the connection request
was processed by the Fbric) and the priority of the
preemption request as provided to the Fabric in
Word 4, bits 30-24 of the preemption request
SOFc1 header. If priority is used for preemption request resolution, a preemption request will be rejected with a Preemption Request Rejected
reason code if the preemption request priority is
equal to or less than the connection being preempted.
Once a preemption request results in a Dedicated Connection all Dedicated Connection and
disconnection rules defined in FC-PH shall be
followed.
28.4
28.4.1
Connect/disconnect rules
Connect-request rules
An ACK_1, ACK_N, or ACK_0 frame with:
An SOFn1 delimiter
an S_ID of (B) and a D_ID of (A)
an EOFn or EOFt delimiter
28.5
28.5.4
Establishing a Connection
Destination of a connect-request
When N_Port(B) is not connected, but is available, and it receives a connect-request as the
destination N_Port, N_Port (B) transmits the
appropriate ACK frame (ACK_1, ACK_N, or
ACK_0) to N_Port (A) which is requesting the
connection. After the ACK frame has been
transmitted with SOFn1, a Dedicated Connection is established with N_Port (A) as the Connec tion Initiator and N_Port (B) as the
Connection Recipient. After a Connection has
been established, N_Port (B) may initiate Sequences with N_Port (A) using an SOFi1 delimiter.
If N_Port (B) is not connected, but is busy, and
it receives a connect-request as the destination
N_Port from N_Port (A), it respondes with P_
BSY with an EOFdt delimiter.
See 28.4.1 for the rules which a destination N_
Port of a connect-request shall follow.
28.9
Connection Preemption
The procedure for preempting a Dedicated

Connection is specified in this subclause.
28.9.1
Applicability
This preemption process applies only to Class

1 and Class 6 Service. Other preemption processes may be defined that apply to other connection oriented classes of service.
28.9.2
Topology Model
The following sections specify the rules governing the behavior of the source and destination
of the connect-request.
An N_Port that uses preemption shall have the

ability to be connected to another N_Port
through a Fabric.
28.4.1.1 Source of connect-request
28.9.3
d) A Dedicated Connection is established when

the connect-request frame has been responded
The following subsections specify the rules governing the behavior of the preemptor (P), pre-
Rules for Preemption
61
dpANS X3.xxx-199x
empted source (PS) or destination (PD), and

the preemption destination (PnD).
an S_ID of the PnD and a D_ID of

the P, and
28.9.3.1 Preemptor (P)

The following rules specify the procedure for
preempting a Dedicated Connection with respect to the Preemptor.
an S_ID of the P N_Port and a D_ID of

the PnD N_Port(s)
an EOFn or EOFt ending delimiter
b) The Data Field of the SOFc1 preemption

request frame shall be limited to the smaller
of
the maximum buffer-to-buffer Receive_
Data_Field size specified by the Fabric, or
the maximu m Receive_Data_Field
size specified by the destination N_Port.
c) After the P N_Port transmits the SOFc1
frame it shall wait for the response frame before transmitting another frame for this seq u e n c e . Ad d it io na l s e qu e n c e s fo r th is
connection shall not be initiated until the Dedicated Connection is established.
an ACK_1, ACK_N, or ACK_0 frame

with:
62
a F_BSY or F_RJT frame with:
an SOFn1 delimiter, and

the P, and
an EOFdt delimiter
g) After a Dedicated Connection is established, the P N_Port shall be the Connection

Initiator and the PnD(s) shall be the Connection Recipient(s).
h) After a Dedicated Connection is established (i.e., the ACK to the SOFc1 preempt ion reques t has been rec eiv ed), the
Connection Initiator may continue transmitting its initial Sequence and initiate other Sequences with SOFi1 up to the Connection
Recipients ability to support Concurrent Sequences.
28.9.3.2 Preempted Source (PS)
The following rules specify the procedure for a
preempted source. The PS is the connection
initiator N_Port for a Class 1 or Class 6 connection.
a)
d) A Dedicated Connection is established

when the SOFc1 frame has been responded
to by an ACK (ACK_1 or ACK_N) frame. A
proper response frame consists of:
an EOFdt delimiter
f) An alternate response frame is also possible from the Fabric F_Port:
the Unidirectional bit (F_CTL bit 8) shall

be set = 0 for bidirectional Connection, and
= 1 for a unidirectional Connection

the P, and
the E_C bit (F_CTL bit 18) shall be set

=0
the preemption flag bit (Word 4, bit 31)

shall be set = 1.
a P_BSY or P_RJT frame with:
An SOFc1 delimiter
a Data (Device_Data or Link_Data)

frame
an EOFn, or EOFt delimiter
e) An alternate response frame is also possible from the PnD N_Port:
a) An N_Port shall initiate a preemption request using a Data (Device_Data or Link_Data) frame directed to the desired destination
N_Port. The SOFc1 preemption request
frame shall be formed as follows:
If a basic link service frame consisting of:
an PRMT command with:
an SOFc1 delimiter, and
an S_ID of the P and a D_ID of the

PS, and
dpANS X3.xxx-199x
an EOFdt delimiter
is received by a connection initiator N_

Port, that N_Ports Dedicated Connection
has been removed. This PS N_Port should
notify its host that its Dedicated Connection has been preempted.
an ACK_1, ACK_N, or ACK_0 frame

with:
an S_ID of the PnD N_Port and a D_

ID of the P, and
28.9.3.3 Preempted Destination(s)(PD)

preempted destination. The PD is the connection recipient N_Port for a Class 1 or Class 6
connection.
a)
If a basic link service frame consisting of:
an PRMT command with:
an S_ID of the P and a D_ID of the

PD, and
an EOFdt delimiter
is received by a connection recipient N_

Port, that N_Ports Dedicated Connection
h a s b e e n r e mo v e d . Th i s P D N _ P o r t
should notify its host that its Dedicated
Connection has been preempted.
an EOFn, or EOFt delimiter
A dedicated connection is established with

the PS N_Port. The PnD N_Port(s) shall
be the Connection Recipient(s) and the PS
N_Port shall be the Connection Initiator.
d) If a PnD N_Port receives a preemption
request frame after it has transmitted a connection-request frame it should requeue its
own request for transmission at a later time
and respond with the proper response frame
to the PS N_port.
NOTE The preemption destination N_Port requeues its original connection-request because
the Fabric has discarded it. The PnD N_Port
needs to adjust its end-to-end Credit_CNT to account for the discarded connection-request.
If stacked connection-requests are being employed, the connection-request shall not be

requeued by the PnD N_Port.
28.9.3.4 Preemption Destination(s) (PnD)
28.9.4

preemption destination (PnD). A PnD is any N_
Port, connected or not, that is addressed by the
D_ID in a SOFc1 preemption request frame.
Once a connection is established as a result of

a preemption request, all rules specified in FCPH or FC-PH-2 for normal Class 1 or Class 6
connections shall be followed.
a) If an SOFc1 preemption request frame is

received by an N_Port not connected, and
this N_Port is busy, the N_Port shall respond
with P_BSY with an EOFdt delimiter as specified in FC-PH clause 28.4.1.1 item e.
b) If an SOFc1 preemption request frame is
received by an N_Port not connected, and
this N_Port rejects the preemption request,
the N_Port shall respond with a P_RJT with
an EOFdt delimiter as specified in FC-PH
clause 28.4.1.1 item e.
c) If an SOFc1 preemption request frame is
received by an N_Port previously connected
(i.e., connected prior to being preempted) or
not connected and not busy, this N_Port shall
respond with the proper response frame. A
proper response frame shall be:
28.9.5
Connection Rules
Remove Connection Rules
All rules Specified in FC-PH or FC-PH-2 to remove Class 1 or Class 6 connections shall be
followed.
28.10 Establishing a Connection Using
Preemption
A Dedicated Connection is established between a preemption requesting (Connection Initiator) N_Port and preemption destination(s)
(Connection Recipient(s)) N_Port(s) following
the successful completion of the Preemption
process specified in sub-clause 28.9.
28.10.1
Connection Initiator
When the FC-2 protocol layer receives a request from an FC-4 or upper level to initiate a
Class 1 or Class 6 sequence using preemption,
the N_Port shall attempt to establish a Class 1
63
dpANS X3.xxx-199x
Table 111A Responses to Preemption Requests

Event
SOF
D_ID
S_ID
Frame
EOF
1.
SOFc1
B, ...
Data
Frame
EOFn
- Transmit Preemption Request

- Wait for confirmation frame
2.
SOFn1
F_RJT
EOFdt
- Preemption Failed. Fabric Rejected

request.
3.
SOFn1
F_BSY
EOFdt
- Preemption Failed, Fabric Busy.
4.
SOFn1
P_BSY
EOFdt
- Busy N_Port, Connection Removed.
5.
SOFn1
P_RJT
EOFdt
- N_Port Rejected, Connection Removed.
6.
SOFn1
ACK_1/
ACK_N/
ACK_0
EOFn/
EOFdt
- Dedicated connection Established

- Continue Transmitting Sequence
- Sequence/Connection Ended.
Any
Connect
Request
Frame
EOFn
- Requeue Preemption Request

Associated with Event 1.
- Respond with SOFn1 on ACK_1, ACK_
N, ACK_0, or P_BSY.
7.
SOFc1
- Time-out, no response frame

- Perform Link Reset Protocol
(see FC-PH 16.6.5)
8.
9.
SOFn1
PS or
PD
PRMT
or Class 6 connection with the destination N_

Port(s) using an SOFc1 preemption request
frame (preemption flag set = 1) as part of a Sequence initiation.
The N_Port initiates a preemption request using
the rules defined in sub-clause 28.9
Table 111A defines event 1 as the preemption
request and events 2 through 8 as possible responses. Event 9 defines the response of the
preempted source or destination.
Event 1
A preemption Request is transmitted by N_Port
(A) with an SOFc1 delimiter with a destination
address of N_Port (B) and the preemption flag
set = 1 (word 4, bit 31).
Event 2
An F_RJT indicates that the Fabric is unable to
establish the Dedicated Connection or has re64
N_Port Action
EOFdt
- Dedicated Connection Preempted

- Notify Host, Preempted.
jected the request. A dedicated connection has

not been established. The reason code specifies the cause.
Event 3
An F_BSY indicates that the Fabric is busy and
was unable to service the preemption request.
A Dedicated connection has not been established.
Event 4
A P_BSY indicates that the destination N_Port
link facility is temporarily occupied with other
activities and is unable to accept the preemption request. Try again later.
Event 5
A P_RJT indicates that the destination N_Port
is unable to establish a Dedicated Connection.
The reason code specifies the cause.
dpANS X3.xxx-199x
Event 6
28.10.2
An ACK_1, ACK_N, or ACK_0 indicates that

the preemption request has been serviced and
a Dedicated connection has been established.
N_Port (A) is connected to N_Port (B).
If an SOFc1 preemption request frame is received by an N_Port previously connected (i.e.,

connected prior to being preempted), it shall
transmit the appropriate ACK frame (ACK_1 or
ACK_N) to the P N_Port. After the ACK frame
has been transmitted with the SOFn1, a Dedicated Connection is established with the P N_
Port as the Connection Initiator and this destination N_Port(s) as Connection Recipient(s).
After a Connection has been established, this
Destination N_Port may initiate Sequences with
the preemptor N_Port using an SOFi1 delimiter,
if the Connection is bi-directional (note: Class 6
dedicated connections are uni-directional).
a) N_Port (A) is the Connection Initiator and

N_Port (B) is the Connection Recipient.
b) N_Port (A) may continue transmitting the
Sequence initiated (EOFn), or the Sequence
which initiated the Connection may be complete (EOFt).
c) N_Port (A) may initiate other Sequences
with the same destination N_Port (B) up to
the maximum number of Sequences defined
by the Service Parameters obtained from (B)
during Login.
d) The connected N_Port (B) may initiate
Sequences using SOFi1 to start each Sequence when the Connection is bidirectional.
The number of active Sequences is limited by
the Service parameters provided by N_Port
(A) during Login.
Preemption Destination
When an un-connected N_Port receives a preemption request it shall respond normally for a
Class 1 connection request, as specified in FCPH 28.5.4.
Event 7
N_Port (A) shall requeue the SOFc1 sent to the
Fabric in Event 1 and may respond to the
SOFc1 received with and ACK_1, ACK_N,
ACK_0, or P_BSY. Once this connection is
completed N_Port (A) may re-send the SOFc1
preemption request frame to the Fabric.
Event 8
If a frame response is not received within the
time-out period (E_D_TOV), a link time-out
shall be detected and the Link Reset Protocol
shall be performed (see FC-PH 16.6.5)
See FC-PH 28.4.1 for the rules which a source
N_Port of a connect-request shall follow.
Event 9
When a connected source (i.e. Connection Initiator) or destination (connection recipient), receives a PRMT, the dedicated connection has
been preempted and no longer exists. The N_
Port should notify its host that the Sequence(s)
were abnormally terminated due to the connection being preempted.
65
dpANS X3.xxx-199x
29
Error detection and recovery
This clause describes the changes that are

made in FC-PH-3 to support the E_D_TOV timer resolution enhancement.
29.2.1.2 E_D_TOV
The following replaces the second paragraph of
this section in FC-PH.
When an N_Port performs N_Port Login in a
point-to-point topology, the Common Service
Parameters provided by each N_Port specify a
value for E_D_TOV. If the two values differ, the
longer time shall be used by each N_Port. An
N_Port may determine another N_Ports value
for E_D_TOV via the Read Timeout Value
(RTV) Link Service command (see 21.4.13).
Timeout values as specified in the Payload of
the Accept are counts of either 1 ms or 1 ns increments, depending on the resolution specified. Therefore, a value of hex 0000000A
specifies a time period of either 10 ms or 10 ns.
29.6
Exchange integrity
Process with infinite buffering

The Process with infinite buffering Error Policy
does not require that a Sequence be complete
or that any previous Sequences be deliverable.
Process policy allows an N_Port to utilize the
Data Field of invalid frames under certain restrictive conditions (see 17.8.1 and 17.8.2). The
Process with infinite buffering Error Policy is intended for applications such as a video frame
buffer in which loss of a single frame has minimal effect or no effect on the Sequence being
delivered. Frames shall be delivered to the FC4 or upper level in the same order as received.
The above shall also apply to Process with infinite buffering in Class 3.
66
dpANS X3.xxx-199x
30
Hunt Group
67
dpANS X3.xxx-199x
31
Multicast
Enhancements to FC-PH-2 as specified.

31.1
Introduction
Multicast provides a service based on Fabric

routing of Class 3 or Class 6 frames. For a multicast connection the Fabric routes frames from
a source N_Port to many destination N_Ports.
31.2
Class 6 Multicast
Class 6 multicast provides a reliable service

based on Fabric routing of Class 6 frames. A
Class 6 SOFc1 is identical to a Class 1 SOFc1.
The Fabric recognizes the multicast D_ID and
performs the Class 6 multicast function, i.e., it
causes the frame to be delivered to every destination in the Multicast Group. A Multicast
Group is the set of N_Ports to which a frame
being multicast is delivered. An N_Port becomes a member of a Class 6 Multicast Group
when a dedicated connection is established between it and another N_Port. An N_Port is no
longer a member of a Class 6 Multicast Group
when the multicast connection is dissolved.
NOTE A system implementation may provide
less than reliable multicast service by implementing a single Sequence with infinite credit.
31.2.1
N_Port
All routing of multicast frames is done by the

Fabric, based on the recognition that the D_ID
of the transmitted frame is a multicast address.
The exact frame that entered the Fabric is replicated to every destination N_Port indicated.
The Fabric shall not alter the frame header or
the frame contents in any manner during this
replication.
Figure 89a illustrates the multicast routing. N_
Port B, C, D and E are members of a Multicast
group. N_Port A is the message sender which
may or may not be a member of the group.
N_Port
Data
Fabric
N_Port
A
Ack
Multicast
Server
N_Port
N_Port
E
Figure 89a Class 6 Multicast Routing
31.2.2
Class 6 Multicast Rules
a) The Sequence Initiator of the Multicast

message shall follow the uniqueness rules for
OX_ID, SEQ_ID, and Sequence Count. The
Sequence Initiator shall be the Connection
Initiator for all multicast sequences. RX_ID
for the Sequence shall be set to an appropriate value (established during Login) by the
multicast server.
b) D_ID in all frames shall address the multicast alias of the multicast group. S_ID in all
frames shall be the N_Port Identifier of the
Sequence Initiator.
c) The Fabric shall not alter the frame in
any way. The Fabric shall simply replicate
each frame to every group member.
d) Sequence Initiative shall not be transfered.
e) All Class 6 multicast frames shall be
routed as uni-directional Dedicated Connections, regardless of the state of the Simplex
bit in the CS_CTL Field (word 1 bit 31).
68
dpANS X3.xxx-199x
f) If any Multicast Group member is not able
to receive frames for any reason the Multicast Server shall respond to the connection
request with a P_RJT.
g) Class 1 service parameters, as specified
during Login, shall be used to manage Class
6 multicast connections.
h) The effect of preemption of one destination N_Port on the remaining N_Ports in the
multicast group is implementation-dependent.
31.2.3
Class 6 Multicast Server
To provide a single consistant response to the

requesting N_Port, all destination N_Port responses shall be managed by a multicast server (at well known address FFFFF5). Based
upon the type of responses returned from the
destination N_Ports (i.e. ACK, P_RJT, or P_
BUSY), the multicast server shall return a single, ACK, busy, or reject (with a valid reason
code) frame to the requesting N_Port as follows:
a) Respond with an ACK only if all destinations respond with an ACK before E_D_TOV
has expired since the sending of the last multicast Data frame.
b) Respond with a busy, with a partial multicast busy reason code (20.3.3.2), if one or
more destinations respond with a busy.
c) Respond with a reject, with a multicast
error reason code (20.3.3.3), if one or more
destinations respond with a reject, or not all
destinations have responded with an ACK
within E_D_TOV.
d) Respond with a reject, with an EOFdt
delimiter and a multicast error terminate
reason code (20.3.3.3), if one or more destinations respond with an ACK, BSY, or RJT
frame with an EOFdt delimiter.
e) Respond with a Link Reset (LR) if one or
more destinations respond with a Link Reset,
or if one or more, but not all, destinations respond with a Link Reset Response (LRR).
f) Respond with a Link Reset Response
(LRR) only if all destinations respond with an
LRR.
Once a Class 6 connection is established, endto-end credit is managed between the Connection Initiator and the multicast server.
31.2.4
Class 6 Multicast recovery
If the multicast Connection Initiator receives

from the Multicast Server a BSY or RJT, the
Connection Initiator shall perform a Link Reset.
If a RJT with an EOFdt delimiter is received,
the Connection Initiator shall terminate the multicast connection.
31.3
Class 3 Multicast
Class 3 multicast provides a service based on

Fabric routing of Class 3 frames. When the
Fabric receives a Class 3 frame that is to be
multicast, it causes the frame to be delivered to
every destination in the Multicast Group. A Multicast Group is a list of N_Ports to which a
frame being multicast is delivered. A Multicast
Group is managed by the Alias Server, which
handles the registration of N_Ports into a Multicast Group, and the de-registration of N_Ports
from a Multicast Group. The Alias Server is not
involved in the routing of multicast frames.
Class 3 multicast routing is specified in 31.3.2
in more detail.
31.3.1
Registration and De-registration
The registration/de-registration by an N_Port as

a member of a Multicast Group with the Alias
Server is specified in clause 32. An N_Port may
register itself as a member of one or more Multicast Groups. An N_Port may register a list of
N_Ports as members of one or more Multicast
Groups. The third party authorization for registration or de-registration is outside the scope of
the document.
31.3.2
Multicast Routing
All routing of multicast frames is done by the

Fabric, based on a recognition that the D_ID of
the transmitted frame is an MG_ID Alias. The
exact frame that entered the Fabric is replicated
to every destination N_Port in the Multicast
Group associated with the MG_ID of the frame.
The Fabric shall not alter the frame header or
the frame contents in any manner during this
replication.
The Sequence Initiator performs no special
function to transmit a frame to be multicast
other than use a D_ID indicating the MG_ID
69
dpANS X3.xxx-199x
and the Multicast Group Service Parameters,
rather than the Login Service Parameters. For
example, the Receive Data Field Size for a multicast frame may be different than the Receive
Data Field Size for a unicast frame.
be the N_Port Identifier of the Sequence Initiator.

c) The Fabric shall not alter the frame in
any way.The Fabric shall simply replicate
each frame to every group member.
If the Sequence Recipient is a member of a

Multicast Group, it shall recognize the MG_ID
as an Alias and accept the frame.
d) Sequence Initiative shall not be transfered.
Class1, Class 2, and Class 4 frames with a

D_ID equal to an MG_ID shall be rejected by
the Fabric.
e) If any group member is not powered on

nor able to receive the frame for any other
reason, the Fabric Controller shall not retransmit the frames.
Figure 89b illustrates the multicast routing. N_

Port B, C, D, and E are members of a Multicast
Group. N_Port A is the message sender which
may not be a member of the group. If it is a
member, it may optionally receive the same
message (see FC-GS.).
N_Port
N_Port
C
N_Port
Fabric
A
N_Port
f) All multicast frames shall be routed in

Class 3.
31.4
Broadcast is considered a simplification of

mu ltic a st. N o e x plic it r e g ist ra tio n o r d e registration is required. Hex FFFFFF is the
Well-known address for Broadcast which may
be recognized by an N_Port.
NOTE .The Fabric may try to send to all possible
N_Ports. However, the Fabric may not be able to
deliver to all N_Ports for any number of reasons
such as Class mismatch and N_Port not powered
on.
The Broadcast Service Parameters shall be

defined. All N_Ports that support the Broadcast
shall support the Broadcast Service Parameters.
NOTE The Broadcast Service Parameters shall
be the least common denominator for all N_Ports.
Normally the Broadcast Service Parameters may
correspond to the default parameters.
31.5
N_Port
E
Figure 89b Class 3 Multicast Routing
31.3.3
Class 3 Multicast rules
a) The Sequence Initiator of the Multicast

message shall follow the uniqueness rules for
OX_ID, SEQ_ID, and Sequence Count. RX_
ID for the Sequence shall be set to hex
FFFF.
b) D_ID in all frames shall be the Alias for
the Multicast Group. S_ID in all frames shall
70
Broadcast
Moviecast
Moviecast is an inherent feature of Multicast.

An example for Class 3 Multicast: if a source
N_Port is multicasting a movie to an Alias
Group, another N_Port may join this Alias
Group in progress. That is, after the registration procedure is complete, the Fabric will start
routing frames to the new N_Port. This is possible with Class 3 Multicast since a multicast
group can be destination initiated. For a Class 6
Multicast the multicast group is source initiated
and does not provide the direct capability for an
N_Port to join a Multicast group in progress. If
intermix is supported an N_Port could request
inclusion in a multicast group using a Class 2 or
Class 3 frame, supporting an indirect destination initiated multicast group.
dpANS X3.xxx-199x
31.6
Other
Other forms of multicast are available in topology specific configurations. For examples, see
FC-AL for a description of Selective Replicate
to perform dynamic multicasting.
71
dpANS X3.xxx-199x
32
Aliases
33
Dedicated Simplex
34
Class 4- Fractional
35
Camp-On
36
Stacked Connect Request
37
Buffered Class 1 Service
38
Data Compression
72
dpANS X3.xxx-199x
39
Clock synchronization service
39.1
39.1.1
Introduction
Applicability
Conventional network technologies utilize clock

distribution protocols (e.g. Network Time Protocol) which synchronize the computers time-ofday clock. Such protocols typically provide
clock synchronization accuracies on the order
of a few millisecond with highly tuned versions
producing accuracies on the order of 50 microseconds.
The synchronization that naturally occurs between transmitters and receivers in a Fibre
Channel fabric offers a highly accurate reference for maintaining clock synchronization. If
all delays are accounted, accuracies on the order of a few nanosecond become practical. The
protocols defined in this clause allow clocks located within N_Ports to be synchronized to
nanosecond accuracies.
39.1.2
Function
Clock Synchronization over Fibre Channel is attained by having a Clock Synchronization Server exchange clock synchronization symbols
with Clients on a periodic basis determined by
its reference clock. (Clock synchronization symbols can be either primitive sequences or ELS.)
The Server can be either built into a fabric servicing multiple F_Ports or an independent node
servicing one or more N_Ports. The Client can
be either an N_Port or a F_Port (when synchronizing other sub-fabrics). Embedded within
each clock synchronization symbol is a delay
field (measured in clock ticks) for use in the calculation of the one-way propagation delay from
the Server ports transmitter to the Client ports
receiver.
NOTE The round-trip propagation delay is used
to compute the one-way propagation delay. For
best accuracies, the transmit and receive paths
between Servers port and the Client port must be
equal in length.
When all of the Clients are requested with the

Server, they will themselves be synchronized.
By tagging data with the current value of their
synchronization clock, one client can accurately
exchange time sensitive data with another client.
39.2
Communications Model
Figure 114 illustrates the clock synchronization

protocol that occurs between the Server and
Client port in order for their respective clocks to
be synchronized. Periodically the Servers reference clock will generate a synchronization
event (t1). The synchronization event will cause
the exchange of clock synchronization request/accept symbols with one or more Clients.
(The period of the synchronization event is controlled by the Server.) Embedded within the
clock synchronization symbols is the necessary
data to compute the delays between the sender
and receiver.
Figure 114 Clock Synchronization Model
Server
Client
t1
t2
sync
_
(ser clock_re
ver_
dela quest
y)
t3
ept
_acc
k
c
o
l
_c
ay)
sync lient_del
(c
t5
t4
where (t3-t2) = (t5-t4)
The synchronization event (t 1) eventually results in the transmission of a clock synchronization request symbol to the Client port at time
(t2). Initially, the delay between the synchronization event and when the synchronization
event is actually sent (t2 - t1) is embedded into
the delay field of the synchronization symbol
(server_delay).
When the Client port receives a clock synchronization request symbol (t3), it sets its synchronization clock to the value embedded in the
delay field of the request symbol (t2 - t1). It then
initiates a clock synchronization accept symbol
to the Server (t 4). Embedded in the clock synchronization accept symbol (client_delay) is the
delay from when the request symbol was re73
dpANS X3.xxx-199x
ceived to when the clock synchronization accept
symbol is returned (t4 - t3).
When the Servers port receives the clock synchronization accept symbol from the Client port,
it takes the difference (t5 - t2) between when it
sent the clock synchronization symbol (t2) and
when it received the accept (t5). The Server then
computes the total propagation delay ((t5 - t4) (t3 - t2)) by subtracting the accept delay (t4 - t3)
from (t5 - t2). The one way propagation delay (t3
- t2) is then computed by dividing the total propagation time by two (assuming the transmit and
receive propagation delays are equal).
The above process is then repeated. On subsequent synchronization events, the Server adds
the one-way propagation delay (t3 - t2) to the delay between the synchronization event and req uest transmission (t 2 - t 1 ). The resu ltin g
embedded delay is the difference between the
Clients synchronization clock and Servers synchronization clock (t 3 - t 1 ). By setting its synchronization clock to the value embedded within
the clock synchronization request symbol (t 3 t1), the Clients clock will be synchronized to the
Servers clock.
NOTE From this point on, as long as the Servers
transmitter port is connected to the Clients receiver
port, the synchronization clocks in the client and
server should be synchronized.
39.3
Requirements
The Clock Synchronization Server shall have a

clock reference that operates at the speed of the
N_Ports being served. The Server shall provide
clock synchronization service to one or more Client Ports. Each Client/Server pair must operate
with common speeds and classes of service.
(The Clients themselves can operate at different
speeds and classes of service.) The Server
shall send a clock synchronization request symbol on a periodic basis to all Clients being
served. The Client port being synchronized shall
respond by returning a clock synchronization accept symbol.
Clients can determine the synchronization period by sending an Extended Link Service request
to the Server. The synchronization count (sync
count) in the Accept Payload (see 39.4.3.1) indicates the synchronization period. The synchronization count is measured in transceiver clock
ticks. Clients operating at different speeds will
have different synchronization counts.
74
The Server shall increment a 32-bit reference

clock register (reference_clock) at the rate of the
clock reference. The reference clock is used to
determine the synchronization period for all Clients (sync_count).
The Servers clock reference shall also be used
as a reference for all N_Port transmitters being
serviced. Each of these N_Ports shall have a
28-bit delay register (server(n)_delay) which increments at the rate of the ports transmitter.
The Server shall also have a 28-bit register for
each Client to save the computed propagation
delay (propagation(n)_delay).
The Clients shall have a set of registers including a 32-bit register for the synchronization clock
(client_clock) and a 28-bit register for Client delays (client_delay) both incremented at the rate
of the Client ports receiver. Clients shall also
have a 32-bit register with their synchronization
count (sync(n)_count).
39.3.1
Server Rules
The following statements illustrate the Servers

reference clock and synchronization clock logic:
if servers clock reference ticks then
reference_clock = reference_clock + 1
if reference_clock = sync_count then (t1)
server(n)_sync = true
server(n)_delay =0
if N_Port (n)s transmitter ticks
server(n)_delay = server(n)_delay + 1
The following logic statements illustrate the
clock synchronization protocol for a Server.
These statements shall apply for all (n) Clients:
if (server(n)_sync is true) and (port(n) is idle)
then (t2)
server(n)_sync = false
send_symbol (sc_request,
server(n)_delay + propagation(n)_delay)
server(n)_delay = 0
if receive_symbol (symbol, symbol_data) then
if (symbol = sc_accept) then (t5)
client_delay = symbol_data
propagation(n)_delay =
(server(n)_delay - client_delay)/2
39.3.2
Client Rules
The following statements illustrate the Clients

clock synchronization logic:
dpANS X3.xxx-199x
if clients receiver clock ticks then
client_clock = client_clock + 1
client_delay = client_delay + 1
if client_clock = sync(n)_count then
client_clock = 0
The following logic statements illustrate the
clock synchronization protocol for a Client:
if receive_symbol (symbol, symbol_data) then
if (symbol is sc_request) then (t3)
client_clock = symbol_data
client_delay = 0
client_sync = true
if (client_sync is true) and (port is idle) then (t4)
client_sync = false
send_symbol (sc_accept, client_delay)
39.4
Clock Synchronization Control
Servicing of a Client ports synchronization clock

is controlled through protocols containing a set
of request/reply IUs supported by the Server.
These requests and replies use FC-PH constructs as defined in the following sections.
39.4.1
Use of FC-PH Constructs
39.4.1.1 Login/Logout
Before performing any clock synchronization operations, a Client port shall perform F_Port Login followed by N_Port Login with the Clock
Synchronization Server. When the Client port
has no further operations pending, it shall perform N_Port Logout with the Server.
39.4.1.1.1 Initiator Capability
To the Initiator Control Flags (D) specified in FCPH 23.6.8.3, additional flags are specified in FCPH-2 (see 23.6.8.3).
The clock synchronozation capability is indicated by the Sequence Initiator (Clock Synchroniztion Server) during N_Port Login in word 0, bit 4
of N_Port Class service parameters under Initiator Control.
bit 19 of N_Port Class service parameters under

Recipient Control.
39.4.1.2 Exchanges
Clock synchronization Exchanges shall be used
in a bidirectional manner. That is, clock synchronization Service request IUs and accept IUs
shall be transferred on the same Exchange, via
the passing of Sequence initiative.
39.4.1.3 Information Units
The Information Unit construct defines the information transferred as a single Fibre Channel
Sequence for clock synchronization requests
and replies. A single Information Unit contains
either a clock synchronization request or a reply.
All communication occurs through the Exchange
of Information Units. This clause describes both
the data which are transparent to FC-PH-3 and
those control parameters which are required by
FC-PH-3.
39.4.1.4 Common Required FC Parameters
Class of Service
The Server shall support all Classes of Service
supported by the Fabric Region to which it is attached. See FC-SW for a discussion of Regions.
An Client port may communicate with the Server
using any desired Class.
If the Client port or the Servers port uses Class
3 to communicate, it shall provide the
Sequence_Tag on the FC_PH service interface.
Any Sequence_Tag provided on a given IU shall
not be reused on a subsequent IU associated
with the same Exchange until either of the following conditions exists:
R_A_TOV has expired since the Client
port or the Servers port has determined that
the IU has been transmitted by the FC-2.
The Client port or the Servers port receives a accept to the transmitted IU from the
receiver of the IU.
39.4.1.1.2 Recipient Capability

To the Recipient Control Flags (D) specified in
FC-PH 23.6.8.4, additional flags are specified in
FC-PH-2 (see 23.6.8.4).
R_CTL Routing Bits

Routing bits of the R_CTL field shall indicate
FC-4 Device Data.
The clock synchronozation capability is indicated by the Sequence Recipient (Clock Synchroniztion Server) during N_Port Login in word 0,
75
dpANS X3.xxx-199x
Information Category
39.4.1.6 CT_HDR
A ll R e qu e st I Us sh a ll s pe cify U ns olicite d
Control. All Accept IUs shall specify Solicited
Control.
The CT_HDR, as defined in FC-GS, shall be

supported by the Server. That is, all requests
and replies shall contain the CT_HDR. Following is a description of the usage of the various
CT_HDR fields.
Sequence Initiative
Sequence Initiative shall be transferred after the
transmission of the Request IU, to allow the return of the associated Reply IU (FS_ACC or FS_
RJT) on the same Exchange. If Sequence Initiative is not passed on the Request IU, The Recipient shall abort the Exchange.
Revision
This field shall be set to hex 01.
IN_ID
This field shall be ignored by the Server.
Destination ID (D_ID)
FCS_Type
This parameter shall identify the destination address identifier (hex FFFFF6 if the well known
address for the clock synchronization service is
being used) of the IU.
This field shall be set to hex F6.
Source ID (S_ID)
Application Information Unit
This parameter shall identify the source address

identifier of the IU.
This field shall contain the payload of the a single request or reply.
Type
39.4.2
All clock synchronization IUs shall specify the Fibre Channel Services TYPE (b0010 0000).
A clock synchronization Client (Sequence Initiator) shall transmit a clock synchronization Request to solicit the Server to perform a control
function. If the request is transmitted without the
transfer of Sequence Initiative, the responding
port shall abort the Exchange and not perform
the Request. The clock synchronization Protocol
is composed of a clock synchronization Request, followed by a reply, on the same Exchange.
Error Policy
All error policies, with the exception of Process
Policy, are permitted.
39.4.1.5 Common Optional FC Parameters
Expiration/Security Header
The use of this parameter is beyond the scope
of this document and is both implementation
and system dependent.
Network Header
Association Header
Device Header
The Device Header shall not be used.
76
Options
This field shall be set to hex 00.
Clock Control Request
The clock synchronization control request provides the means to enable and disable the clock
synchronization service to the Clock Synchronization Client. For the above Request, if an FS_
RJT is generated, it shall specify a Reason
Code of Unable to perform command request,
unless otherwise indicated. The Reason Code
Explanation shall indicate the specific reason for
the FS_RJT.
39.4.3
Clock Control Link Service
In order for the clock synchronization service to

be established, a Client port, as the Exchange
Originator, shall send a FC-4 link service request to the Server. The accept to the request
shall indicate the period at which the Clients
clock will be synchronized.
dpANS X3.xxx-199x
39.4.3.1 Clock Control (CSS_CC)
The clock control sequence shall be used by a
Client port to determine the clock synchronization services provided by the Server and to control the synchronization clock. The format of the
request payload is shown in table 167.
Table 167 CSS_CC Payload
Item
Size (Bytes)
hex 01000000
command
command: This field controls clock synchronization service to the Client. A value of zero (0)
indicates the Server shall disable clock synchronization off; a value of one (1) indicates that the
Server shall enable clock synchronization using
primitive sequences; a value of two (2) indicates
that the Server shall enable clock synchronization using ELS sequences; and a value of three
(3) indicates the Server shall report its current
state.
Fibre Channel service reject (FS_RJT) signifies
rejection of the CSS_CC command.
Fibre Channel service accept (FS_ACC) signifies the clock synchronization service has transmitted the clock synchronization information.
The format of the accept payload is shown in table 168.
Table 168 CSS_CC Accept Payload
Field
Size (Bytes)
hex 02000000
synchronization_count
state
capability
synchronization_count: This field is an integer

value which defines the number of synchronization clock ticks in millions (x10 6) between clock
synchronization request symbols.
two (2) indicates that clock synchronization is

enabled using ELS sequences.
capability: This field reports the clock synchronization capability of the Server. A value of zero
(0) indicates the Server supports primitive sequences; a value of one (2) indicates the Server
supports ELS primitive sequences; and a value
of three (3) indicates support for both.
39.5
Synchronize Clock Request
Either a series of Primitive Signals or ELS service can be used as clock synchronization symbols. Primitive Signals can only occur between
frames. Whether ELS or Primitive Signals are
being used, synchronize clock symbols must be
delayed if the Server or Client port is in the process of transmitting a frame.
NOTE Highest clock synchronization accuracies occur when clock synchronization primitives
are used with Class 1 service and a fabric based
Server w hose transmitters are referenced to a
common clock source.
39.5.1
Primitive Signal Service
Primitive Signals can be used to issue clock

synchronization requests and accepts. When
the Servers port is connected to the Client port
over a point-to-point connection, the use of
clock synchronization Primitive Signals can provide higher clock accuracies than are possible
with ELS sequences.
39.5.1.1 Terms
The clock synchronization signals for the clock
synchronization Primitive Signals consist of the
following ordered sets:
SYNx - K28.5, D31.3, CS_X, CS_X
SYNy - K28.5, D31.5, CS_Y, CS_Y
SYNz - K28.5, D31.6, CS_Z, CS_Z
The 14-bit value (hex) contained within a clock

synchronization signal (x, y, or z) is the concatenation of two 7-bit hexadecimal values (X and
X; Y and Y; Z and Z respectively). As defined
in Annex K of FC-AL, each 7-bit value has an
equivalent neutral disparity Data Character as illustrated in table 169.
state: This field reports the current clock synchronization state. A value of zero (0) indicates
clock synchronization is disabled; a value of one
(1) indicates that clock synchronization is enabled using primitive sequences; and a value of
77
dpANS X3.xxx-199x
Table 169 Data Character Translation
Value
Data
(hex) Character
Value
Data
(hex) Character
CS_X
CS_X
CS_Y
CS_Y
CS_Z
CS_Z
39.5.1.2 Synchronize Clock Request

The synchronize clock request sequence consists of the following primitive signals: (2) Idles;
(1) SYNx; (1) SYNy; and (2) Idles.
The concatenation of the binary data fields from
the synchronize clock signals (SYNx and SYNy)
produce a 28-bit field (xy) which contains the binary value of the Server ports server_delay
(see Figure 114).
39.5.1.3 Synchronize Clock Accept
The synchronize clock accept sequence consists of the following primitive signals: (2) Idles;
(1) SYNx; (1) SYNz; and (2) Idles.
The concatenation of the binary data fields from
the synchronize clock signals (SYNx and SYNz)
produce a 28-bit field (xz) which contains thebinary value of the Client ports client_delay (see
Figure 114).
Destination ID (D_ID)
This parameter shall identify the destination address identifier of the IU for the Client port being
synchronized.
Source ID (S_ID)
This parameter shall identify the source address
identifier of the IU (hex FFFFF6 if the well
known address for the clock synchronization
Server is being used).
The Server (Sequence Initiator) shall transmit a
clock synchronization Request to solicit a participating clock synchronization port to perform a
service function. If the request is transmitted
without the transfer of Sequence Initiative, the
responding port shall abort the Exchange and
not perform the Request. The clock synchronization Protocol is composed of a clock synchronization Request, followed by a reply, on the
same Exchange.
The Synchronize Clock request provides the
means for the Server to synchronize clock synchronization Clients. For the above Request, if
an FS_RJT is generated, it shall specify a Reason Code of Unable to perform command request, unless otherwise indicated. The Reason
Code Explanation shall indicate the specific reason for the FS_RJT.
39.5.2.1 Synchronize Clock Link Service
39.5.1.4 Primitive Signal Insertion

When sending a synchronize clock request symbol, the Server will use the synchronize clock request sequence to substitute the sequence of
idles that normally occurs between frames. Likewise when sending a synchronize clock accept
symbol, the Client port will use the synchronize
clock accept sequence to substitute the sequence of idles.
39.5.2
ELS Service
When using ELS service, The Server, as the Exchange Originator, shall issue Synchronize
Clock Requests with the use of FC_PH constructs. With the exception of the Source and
Destination identifiers described below, subclause 39.4.1 describes the use of FC_PH constructs.
78
The Server shall synchronize the Client ports

clock at a rate that is no greater than the indicated synchronization_count. Clock synchronization events are generated periodically by the
Server. The Client can anticipate the synchronization ELSs at a rate no greater than that indicated in the synchronization count.
39.5.2.2 Synchronize Clock (CSS_SC)
The synchronize clock command shall be issued
by the Server to synchronize the clock of the Client port. The format of the request payload is
shown in table 170.
Table 170 CSS_SC Payload
Item
Size (Bytes)
hex 03000000
server_delay
dpANS X3.xxx-199x
server_delay: The unsigned sum of: (1) the
number of clock ticks between when the clock
synchronization event occurred and when the
ELS is transmitted; (2) the number of clock ticks
for the one-way propagation delay from the
Server to the Client port.
Fibre Channel service reject (FS_RJT) signifies
rejection of the CSS_SC command.
Fibre Channel accept (FS_ACC) signals a reply
from the Client port being synchronized was
transmitted with synchronization information to
the clock synchronization Server. The format of
the accept payload is shown in table 171.
Table 171 CSS_SC Accept Payload
Field
Size (Bytes)
hex 04000000
client_delay
client_delay: The unsigned number of clock

ticks that occurred between when the Client port
received the clock synchronization request and
when the Client port transmitted the clock synchronization accept.
79
dpANS X3.xxx-199x
40
Data Encryption
This clause describes and formally defines the

data encryption method and format. The encryption algorithm should be designed for fast
bulk encryption. However, a specific algorithm
is beyond the scope of this document (see Annex A of FC-GS-2). FC-GS-2 (Security key distribution service) defines the mechanism by
which encryption keys with different lengths are
distributed. The encryption algorithm should be
a variable-key-size cipher function which suppors multiple key lengths if export versions of
products is required.
40.1
Introduction
The Data Encryption option can be invoked by

the initiator on a per Information Category basis
within a Sequence, immediately preceding segmentatio n to fra me Pa yload s. De cryp tion
should be performed immediately following Information Category reassembly.
40.2
N_Port Login
The Sequence Initiators capability to perform

data encryption and the Sequence Recipients
capability to perform decryption are determined
during N_Port login.
Only if both Sequence Initiator and the Sequence Recipient support the capability can
they perform the function.
40.2.1
Initiator Capability
40.2.3
F_CTL
Data encryption status of an Information Category shall be indicated by the Sequence Iniator
to the Sequence Recipient by means of F_CTL
bit 10 (see 18.5)
40.3
Applicability
Frame level encryption is applicable to all

Classes of service. Data encryption status (F_
CTL bit 10) is meaningful in all Data frames of
an Information Category.
NOTE F_CTL bit is defined to be meaningful in
all data frames to ensure that the Sequence Recipient recognizes encrypted data with RO usage and
out-of-order frame delivery.
40.4
Decryption
The Sequence Recipient shall decrypt data on

a per Information Category basis, using Information Category bits of R_CTL and the SEQ_
ID of the Sequence to which the Information
Category belongs.
Since the Data encryption is performed on a per
Information Category basis (not on frame by
frame basis), the RO shall not be used with
Data encryption. If the Sequence Recipient
uses RO and transmits compressed data, the
Sequence Recipient shall ignore the RO and
decrypt the data for the entire Information Category.
To the Initiator Control Flags (D) specified in

FC-PH-2 (see 23.6.8.3).
The data encryption capability is indicated by
the Sequence Initiator during N_Port Login in
word 0, bit 5 of N_Port Class service Parameters under Initiator Control.
40.2.2
Recipient Capability
To the Recipient Control Flags (D) specified in

FC-PH-2 (see 23.6.8.4).
The data encryption capability is indicated by
the Sequence Recipient during N_Port Login in
word 1, bit 20 of N_Port Class service Parameters under Recipient Control.
80
dpANS X3.xxx-199x
A
Annex A
(informative)
No enhancements to X3.230-1994 (FC-PH) annex A.
B
Annex B
(informative)
No enhancements to X3.230-1994 (FC-PH) annex B.
C
Annex C
(informative)
No enhancements to X3.230-1994 (FC-PH) annex C.
D
Annex D
(informative)
No enhancements to X3.230-1994 (FC-PH) annex D.
E
Annex E
(informative)
No enhancements to X3.230-1994 (FC-PH) annex E.
81
dpANS X3.xxx-199x
F
Annex F
(informative)
Electrical cable interface implementation examples
NOTE The cable descriptions listed in this annex replace the cable descriptions present in the equivalent annex in ANSI X3.230-1994. All other portions of the ANSI X3.230 annex remain in effect.
F.1
Example of LV (long-video) coaxial cable characteristics
This large diameter style of coax is capable of relativly long distance transmission due to its low attenuation. Electrical and mechanical characteristics of a cable meeting the requirements of LV links is
listed in table F.1. This cable is equivalent to a type-1694A version of RG-6/U.
Table F.1 Typical characteristics of LV-type coaxial cable
Category
Electrical
Impedance
see 9.1.1
Capacitance
53,1 pF/m nom.
Attenuation
see 9.1.1
Velocity
82%
Category
Conductor
Material
Bare Copper
Size
AWG 18
Construction
Solid
Outer diameter
1,02 mm nom.
Category
Dielectric
Material
Foam Polyethylene
Wall thickness
1,78 mm nom.
Dielectric constant
1,50 nom.
Outer diameter
4,57 mm nom.
Category
Shield
Material
Tin plated Cu braid
over foil
Coverage
Braid 95%
Foil 100%
Outer diameter
----------
Category
Jacket
Material
PVC
Colour
----------
Outer diameter
6,99 mm nom.
F.2
Wall thickness
----------
Example of plenum-rated LV (long-video) coaxial cable characteristics
This large diameter style of coax is capable of relativly long distance transmission due to its low attenuation. Electrical and mechanical characteristics of a cable meeting the requirements of plenum
rated LV links is listed in table F.1. This cable is equivalent to a type-1695A version of RG-6/U.
Table F.2 Typical characteristics of plenum rated LV-type coaxial cable
Category
Electrical
Impedance
see 9.1.1
Capacitance
53,1 pF/m nom.
Attenuation
see 9.1.1
Velocity
83%
Category
Conductor
Material
Bare Copper
Size
AWG 18
Construction
Solid
Outer diameter
1,02 mm nom.
Category
Dielectric
Material
Foamed Teflon
Wall thickness
1,65 mm nom.
Dielectric constant
1,50 nom.
Outer diameter
4,32 mm nom.
Category
Shield
Material
Tin plated Cu braid
over foil
Coverage
Braid 95%
Foil 100%
Outer diameter
----------
Category
Jacket
Material
Chloride-based or
Florocopolymer
Colour
----------
Outer diameter
5,94 mm nom.
Wall thickness
----------
82
dpANS X3.xxx-199x
F.3
Example of TV (video) coaxial cable characteristics
This intermediate diameter style of coax is capable of medium distance transmission due to its low attenuation. Electrical and mechanical characteristics of a cable meeting the requirements of TV-type
links is listed in table F.1. This cable is equivalent to a type-1505A version of RG-59/U.
Table F.3 Typical characteristics of TV-type coaxial cable
Category
Electrical
Impedance
see 9.1.2
Capacitance
53,1 pF/m nom.
Attenuation
see 9.1.2
Velocity
83%
Category
Conductor
Material
Bare Copper
Size
AWG 20
Construction
Solid
Outer diameter
0,81 mm nom.
Category
Dielectric
Material
Foam Polyethylene
Wall thickness
1,43 mm nom.
Dielectric constant
1,50 nom.
Outer diameter
3,68mm nom.
Category
Shield
Material
Tin plated Cu braid
over foil
Coverage
Braid 95%
Foil 100%
Outer diameter
----------
Category
Jacket
Material
PVC
Colour
----------
Outer diameter
5,97 mm nom.
F.4
Wall thickness
----------
Example of plenum-rated TV (video) coaxial cable characteristics
This intermediate diameter style of coax is capable of medium distance transmission due to its low attenuation. Electrical and mechanical characteristics of a cable meeting the requirements of plenum
rated LV-type links is listed in table F.1. This cable is equivalent to a type-1506A version of RG-59/U.
Table F.4 Typical characteristics of plenum rated TV-type coaxial cable
Category
Electrical
Impedance
see 9.1.2
Capacitance
52,8 pF/m nom.
Attenuation
see 9.1.2
Velocity
83%
Category
Conductor
Material
Bare Copper
Size
AWG 20
Construction
Solid
Outer diameter
0,81 mm nom.
Category
Dielectric
Material
Wall thickness
Foamed FEP Teflon 1,31 mm nom.
Dielectric constant
1,50 nom.
Outer diameter
3,68 mm nom.
Category
Shield
Material
Tin plated Cu braid
over foil
Coverage
Braid 95%
Foil 100%
Outer diameter
----------
Category
Jacket
Material
Chloride-based or
Florocopolymer
Colour
----------
Outer diameter
5,05 mm nom.
F.5
Wall thickness
----------
Example of plenum-rated MI (minitaure) coaxial cable characteristics
The attenuation of miniature coaxial cabe is significantly more lossy than either the LV or TV styles of
coax. Its usage is limited to short connections between pieves of equipment. Electrical and mechanical characteristics of a cable meeting the requirements of plenum rated MI-type links is listed in table
F.1. This cable is equivalent to a type-83264 version of RG-179.
83
dpANS X3.xxx-199x
Table F.5 Typical characteristics of plenum rated MI-type coaxial cable
Category
Electrical
Impedance
see 9.1.3
Capacitance
64,0 pF/m nom.
Attenuation
see 9.1.3
Velocity
69,5%
Category
Conductor
Material
Silver coated
Copper covered
Steel
Size
AWG 30
Construction
Stranded
Outer diameter
0,30 mm nom.
Category
Dielectric
Material
Teflon
Wall thickness
0,64 mm nom.
Dielectric constant
----------
Outer diameter
3,68 mm nom.
Category
Shield
Material
Silver coated
Cu braid
Coverage
Braid 95%
Outer diameter
----------
Category
Jacket
Material
Teflon
Colour
----------
Outer diameter
2,54 mm nom.
F.6
Wall thickness
----------
Example of STP cable characteristics
This cable should be compatable with existing Type-1A and Type-2A 150 STP cable. Electrical
and mechanical characteristics of a cable meeting the requirements of TP links is listed in table F.1.
This cable is equivalent to a type-9688 version of Type-1A STP.
Table F.6 Typical characteristics of TP-type cable
Category
Electrical
Impedance
see 9.2.1
Capacitance
27,9 pF/m nom.
Attenuation
see 9.2.1
Velocity
69,5%
Category
Conductor
Material
Bare Copper
Size
AWG 22
Construction
Solid
Outer diameter
0,65 mm nom.
Category
Dielectric
Material
Foamed
Polyethylene
Wall thickness
----------
Dielectric constant
----------
Outer diameter
----------
Category
Shield
Material
Metalized Foil with
tinned Cu braid
Coverage
Foil 100%
Braid 65%
Outer diameter
----------
Category
Jacket
Material
PVC
Colour
Black
Outer diameter
7.5mm x 10.9mm
nom.
Wall thickness
----------
84
dpANS X3.xxx-199x
F.7
Example of TW cable characteristics
This cable should be used in skew sensitive environments, or where overall cable size is a factor.
Electrical and mechanical characteristics of a cable meeting the requirements of TW-type links is listed in table F.1.
Table F.7 Typical characteristics of TW-type cable
Category
Electrical
Impedance
see 9.2.2
Capacitance
----------
Attenuation
see 9.2.2
Velocity
83%
Category
Conductor
Material
Tin or Silver plated
Copper
Size
22 AWG
Construction
Stranded or solid
Outer diameter
----------
Category
Dielectric
Material
various
Wall thickness
----------
Dielectric constant
----------
Outer diameter
----------
Category
Shield
Material
Metalized foil and
Cu braid
Coverage
Foil 100%
Braid 85%
Outer diameter
----------
Category
Jacket
Material
various
Colour
----------
Outer diameter
----------
Wall thickness
----------
85
dpANS X3.xxx-199x
G
Annex G
(informative)
No enhancements to X3.230-1994 (FC-PH) annex G.
H
Annex H
(informative)
No enhancements to X3.230-1994 (FC-PH) annex H.
I
Annex I
(informative)
No enhancements to X3.230-1994 (FC-PH) annex I.
J
Annex J
(informative)
No enhancements to X3.230-1994 (FC-PH) annex J.
Annex K
(informative)
No enhancements to X3.230-1994 (FC-PH) annex K.
L
Annex L
(informative)
No enhancements to X3.230-1994 (FC-PH) annex L.
M
Annex M
(informative)
No enhancements to X3.230-1994 (FC-PH) annex M.
N
Annex N
(informative)
No enhancements to X3.230-1994 (FC-PH) annex N.
O
Annex O
(informative)
No enhancements to X3.230-1994 (FC-PH) annex O.
P
Annex P
(informative)
No enhancements to X3.230-1994 (FC-PH) annex P.
86
dpANS X3.xxx-199x
Q
Annex Q
(informative)
No enhancements to X3.230-1994 (FC-PH) annex Q.
R
Annex R
(informative)
No enhancements to X3.230-1994 (FC-PH) annex R.
87
dpANS X3.xxx-199x
S
Annex S
(informative)
FC-PH Service Interface
This annex describes changes to the FLOGI
and PLOGI service interface.
S.2.3
FABRIC_LOGIN.request
This primitive is used to provide Fabric Login

parameters and to request a login with the Fabric, if necessary.
S.2.3.1 Semantics of the Primitive
FABRIC_LOGIN.request
(My_ID,
Local_N_Port,
My_Fabric_Service_Parameters)
My_ID will specify the S_ID to be used in the
Sequence that delivers the Fabric Login. See
23.3.1 for the usage of the S_ID in Fabric Login.
Local_N_Port will specify the local N_Port
which is to issue the FLOGI.
My_Fabric_Service_Parameters will optionally
specify the parameters to be used in the payload of the Fabric Login.
S.2.3.2 When Generated
A level above FC-PH will generate this primitive
to provide operating parameters to FC-PH and
to request a Fabric Login.
S.2.3.3 Effect of Receipt
If the N_Port specified by My_ID is not currently
logged into the Fabric, the receipt of this primitive will cause FC-PH to attempt Link Initialization (see 16.6.2) if the Link is not active and to
transmit a Fabric Login Sequence with Class as
specified by 23.3.3.
If the N_Port specified by My_ID is currently
logged into the Fabric, the receipt of this primitive will cause FC-PH to return the current Fabric Service Pa ra me ters, via the FABRIC_
LOGIN.confirmation. Link Initialization is not
performed and a Fabric Login Sequence is not
transmitted. However, the N_Port may issue an
FDISC ELS to obtain the most current Fabric
Login parameters.
S.2.4
FABRIC_LOGIN.indication

S.2.5
FABRIC_LOGIN.confirmation
This primitive will provide an appropriate response to the FABRIC_LOGIN.request primitive signifying the success of the primitive and,
if a Fabric is present, will provide the Service
Parameters returned by the Fabric.
S.2.5.1 Semantics of the Primitive
FABRIC_LOGIN.confirmation
(My_ID,
Local_N_Port,
Request_Status,
Reject_Reason,
Fabric_Status,
Other_Port_Fabric_Service_Parameters)
My_ID will reflect the D_ID returned in the Fabric Login Accept Frame.
Local_N_Port will indicate the local N_Port
which issued the FLOGI.
Request_Status will indicate status as one of
the following:
Successful - Fabric Login completed.
Unsuccessful - Sequence was not delivered completely due to reason other than reject.
Rejected_Request - The Request was not
sent by the Initiator due to the specified
Reject_Reason.
Rejected_by_Fabric - Reject frame received from Fabric.
Rejected_by_N_Port - Reject frame received from N_Port.
Rejected_by_Link_Services - Link Services Reject frame received from N_Port.
When the Request_Status is Rejected_Request, Rejected_by_Fabric, or Rejected_by_N_
88
dpANS X3.xxx-199x
Port, the Reject_Reason will indicate one of the
Reject reason codes given in Table 55.
The Fabric_Status will indicate status as one of
the following:
isolated - Link is not connected.
no_fabric - N_Port is connected point-topoint with another N_Port.
fabric - N_Port is connected to a Fabric.
Other_Port_Fabric_Service_Parameters will
optionally specify the parameters to be used for
the F_Port in the operation of a Fabric when a
Fabric is present as indicated by Fabric_Status,
or will optionally specify the parameters to be
used for the other N_Port when no_fabric is indicated by Fabric_Status.
S.2.5.2 When Generated
S.2.5.3
This primitive is generated upon
completion of a Fabric Login attempt.
The effect of receipt of this primitive by the FC4 entity is unspecified.
S.2.6
return the current N_Port Service Parameters

for the N_Port specified by Other_ID, via the N_
PORT_LOGIN.confirmation. An N_Port Login
Sequence is not transmitted, but a count of the
number of Login requests for the specified N_
Port pair is updated. However, the N_Port may
issue an a PDISC ELS to obtain the most current N_Port Login parameters.
S.2.14
N_PORT_LOGOUT.request
This primitive is used to request that a Login be

terminated with the specified N_Port.
Receipt of this primitive will cause FC-PH to
decrement the count of the number of Login requests for the specified N_Port pair.
If the count of Login requests for the specified
N_Port pair is not yet zero, FC-PH does not
generate a Logout Sequence.
If the count of Login requests for the specified
N_Port pair is now zero, receipt of this primitive
will also cause FC-PH to generate a Logout Sequence.
IMPLICIT_FABRIC_LOGIN.request

S.2.7
N_Port Login Primitive Flows

S.2.8
N_Port Login Service Parameters

S.2.9
N_PORT_LOGIN.request
This primitive is used to provide N_Port Login

parameters and to request a login with another
N_Port, if necessary.
If the N_Port specified by My_ID is not currently
logged into the N_Port specified by Other_ID,
the receipt of this primitive will cause FC-PH to
transmit an N_Port Login Sequence with a
Class as specified by 23.4.3. The count of the
number of Login requests for the specified N_
Port pair is set to 1.
If the N_Port specified by My_ID is currently
logged into the N_Port specified by Other_ID,
the receipt of this primitive will cause FC-PH to
89
dpANS X3.xxx-199x
T
Annex T
(informative)
No enhancements to X3.230-1994 (FC-PH) annex T.
U
Annex U
(informative)
No enhancements to X3.230-1994 (FC-PH) annex U.
V
Annex V
(informative)
No enhancements to X3.230-1994 (FC-PH) annex V.
W
Annex W
(informative)
No enhancements to X3.230-1994 (FC-PH) annex W.
X
Annex X
(informative)
No enhancements to X3.xxx-1995 (FC-PH-2) annex T.
Y
Annex Y
(informative)
No enhancements to X3.xxx-1995 (FC-PH-2) annex U.
Z
Annex Z
(informative)
No enhancements to X3.xxx-1995 (FC-PH-2) annex V.
AA
Annex AA
(informative)
No enhancements to X3.xxx-1995 (FC-PH-2) annex AA.
AB
Annex AB
(informative)
No enhancements to X3.xxx-1995 (FC-PH-2) annex AB.
90
dpANS X3.xxx-199x
AC
Annex AC
(Informative)
A Real Time Loop Based Fibre Channel Topology
AC.1
Scope
This annex describes a data distribution architecture based on the use of Fibre Channel constructs aimed at real time applications where a
known worst case amount of guaranteed bandwidth is needed. These applications include
the distribution of real time audio and video.
Though the architecture is loop based, it provides higher layer protocol support to act as a
crosspoint switch as well. The loop at each
node also provides a point to point interface
which makes the architecture expandable into a
mesh like structure. From a Fibre Channel perspective, with minimal exceptions noted herein,
the architecture design is compliant with FC-PH
rev 4.3. Compliance to FC-PH-3 is used to cover exceptions to FC-PH rev 4.3 necessary to
support real time operation. No primitives or
link services beyond those defined in FC-PH
rev 4.3 are necessary for its implementation. In
detail this annex defines the overall topology, a
new port type, the real time loop (RTL) port, the
specific Fibre Channel services which are used,
and the layers of protocol above Fibre Channel
needed to define the architecture.
1.0625 Gbps
Optical
RTL Port
Class 2/3
N_Port
Node N-1
RTL Port
Terminal N-1
266 Mbps
Coax
1.0625 Gbps
Optical
RTL Port
Class 2/3
N_Port
Node N
RTL Port
Terminal N
266 Mbps
Coax
1.0625 Gbps
Optical
RTL Port
Class 2/3
N_Port
Node N+1
RTL Port
Terminal N+1
266 Mbps
Coax
1.0625 Gbps
Optical
Figure 112 Real Time Loop Topology
91
dpANS X3.xxx-199x
AC.2
General Description
Application Interconnect
The distribution system is based on a ring topology. The ring structure consists of a set of
nodes tied together in a point to point configuration as shown in figure 112. Within each node
are two Real Time Loop (RTL) Ports which support Fibre Channel class 3 communications and
an N_Port which supports class 2 and 3 communication. The distribution protocol uses a
slotted or "register insertion" algorithm. The
point to point class 3 interconnects conform to
the ANSI X3.230 Fibre Channel standard.
Each RTL port communicates with its neighbor
RTL port using a full speed (1.0625 Gbaud) optical (100-M5-SL-I) bi-directional path to its
neighbor node which operates in a full duplex
mode.
The N_Port to Terminal interconnect shown in
figure 112 represents a full duplex point to point
known as a Local Node Interface. This link represents a quarter sp eed coaxial (265.625
Mbaud 25-TV-EL-S) access point to the ring's
data structures. Optics are optional at this interface.
As shown in figure 114, the Fibre Channel FC2
layer is a Time Division Multiplexed (TDM) win-
TDM Windowing
Fibre Channel Framing FC-2
Classes 2 and 3
Fibre Channel Signalling FC-1
Fibre Channel Physical FC-0
Full Speed Optical &
Quarter Speed Electrical
Figure 113 Real Time Protocol Stack
dowing protocol which provides for synchronous
data delivery. The system designer is given access to this protocol structure so that bandwidth
can be allocated based on application requirements. By programming these windows, the user
can allocate any amount of bandwidth to any type
of data, and to any network terminal. The loop architecture with the synchronous windowing technique built on top of Fibre Channel is here after
referred to as the Fibre Channel Real Time Loop
(FC-RTL) topology.
Interface
Hardware
Interface
Hardware
3
1
6
Interface
Hardware
10
Interface
Hardware
2
5
Interface
Hardware
Interface
Hardware
4
Interface
Hardware
4
Normal Data Flow
Loopback
Fault
Interface
Hardware
Loopback
8
3
Interface
Hardware
2
1
7
Interface
Hardware
Data Flow Under Fault Condition
Figure 114 Failure Detect and Re-routing
92
dpANS X3.xxx-199x
This layer also provides the FC-RTL with support for a counter-rotation feature. During normal error free operation, data flows primarily in
one direction with the return path used for flow
control. When an error occurs either through
the result of a link failure or the failure of a
node, neighboring nodes can autonomously detect the failure and reroute the data around the
error as shown in figure 114. In this way the
system provides recovery from single point failures without the need for expensive backup or
redundant rings.
In addition, the TDM layer provides support for
allocating bandwidth (that is not being used for
synchronous communications) for asynchronous non-real time control type traffic. The built
in asynchronous support is used for determining mastership, for system synchronization, and
for error recovery.
AC.2.1
Network Data Flow
Network data flow can be divided into synchronous and asynchronous traffic. The frame
based data structure for transmissions is shown
in figure 114.
Synchronous
Bandwidth
Type 1
Type 2
Asynchronous
Bandwidth
Type 3
62.5 us
nel frames. The minor frame size is programmable and represents the amount of bandwidth
that has been assigned to a particular data information type. Thus, if Type 1 was audio and
consisted of 2000 words, the bandwidth allocation for audio would be 2000 * 16 bits *16 KHz
or 512 Mbps.
AC.2.1.1 Synchronous Service
To provide for guaranteed data delivery, the
network provides a synchronous data frame
service. This may be viewed as a set of exchanges/sequences/frames which are initiated
by one node, designated as the Master node,
according to a predetermined rate schedule.
These frames are delivered to each node in
succession, and may be used by that node for
the purpose of encapsulating data. The receiving node may in effect, capture the frame, modify it, and retransmit it in the corresponding time
slot.
To provide for synchronous bandwidth allocation, each data source is allocated a number of
channels which it can use to insert information
onto the network. These channels are grouped
into a set of frame types which are distributed at
different rates. As an example, a data source
could be allocated 100 16 KHz channels and
100 50 Hz channels. This would be an allocation of 1,605,000 16 bit channels, or 25.68
Mbits/sec of network bandwidth to the data
source. The frame types, their sizes, and their
rates are all totally programmable. Maximum
frame rates and numbers of provided data
types are a function of RTL Port design.
AC.2.1.2 Asynchronous Service
Major Frame
Figure 115 TDM Window
In this example, the highest rate frame is 16
KHz, and a major frame is a 62.5 us window of
data. This window size is programmable with
the minimum size determined by RTL port design. Each window is broken down into synchronous and asynchronous bandwidth. The
window is then further broken down into minor
frame types. For example, Type 1 might be audio, Type 2 might be video, and Type 3 might
be control information. These minor frame
types consist of a number of 16 bit data words,
and are transmitted as one or more Fibre Chan-
Should applications not require 100% use of

the network's bandwidth for synchronous service, the remaining bandwidth can be used
asynchronously -- whenever it is available.
The asynchronous bandwidth is used only
when window space is available after synchronous bandwidth has been allocated. Asynchronous bandwidth can also be used at
initialization before synchronous frame transmissions have begun. Note that the network
design supports a configuration where the
amount of allocated synchronous bandwidth is
zero, and therefore allowing 100 % of the bandwidth to be allocated to asynchronous commun icatio ns . Th e syst em do es n ot s up p or t
93
dpANS X3.xxx-199x
multiple data types in the asynchronous mode.
The asynchronous mode is not an optional feature however, as it is required for system initialization and error recovery.
To prevent the transmitting node from capturing
the network for an extended time, the RTL port
shall be capable of implementing a fairness algorithm while in asynchronous mode. After a
prescribed number of successful frame transmissions, the node shall allow sufficient time to
permit at least any one of the other nodes on
the ring the opportunity to start a frame. In the
event of a collision, the node shall implement a
delay prior to any re-attempt to capture a transmit opportunity.
AC.2.2
Network Characteristics
AC.2.2.1 Master Node

Data distribution through the network is controlled by a "master node". Each node has the
capability of being the master, but only one
master is active at a time. Mastership establishment is done at network initialization time
through an arbitration algorithm. Upon power
up, after a node determines that it is functional,
it begins transmitting an asynchronous frame
which contains its network address. It continues this until it receives from its upstream node
an address which is greater than its own. If this
occurs, the master begins transmitting the highest address that it receives. When a node rec e i v e s i t s o w n a d d r e s s , it a s s u m e s t h e
mastership role and begins transmitting synchronous frames. Once a node obtains mastership, it retains the role until either it fails or the
system is shut down. The network provides automatic master failure detection and recovery to
a new master.
The master node is the synchronization point of
the network. It resynchronizes frames as they
pass through it. The master node is synchronized to an external clock which it uses to determine when to transmit a major frame. It also
houses a scheduler which it uses to determine
the minor frame types to include in each major
frame.
AC.2.2.2 Data Distribution Characteristics
Initially, the window is transmitted by the master
as nulls in each channel of each frame type. As
each terminal sees this null frame it can source
data into its pre-allocated channels as the
frame passes through its "local node". Once

the frame which was originated by the master is
received back by the master (after having traversed the ring), it is resynchronized by the
master. Any data received by the master is inserted into the next frame that it transmits.
Terminals which source data are also responsible for removing it from the network, otherwise
it would traverse the ring continuously. This is
done when the data source's local node receives back what it has transmitted.
A terminal is aware of which slots of a particular
data type have been allocated to it through the
use of a data structure known as an "access table". This access table simply consists of a single bit for each data word in each frame type.
The state of each bit determines whether or not
a node is to make a copy of the data word represented by the bit as it passes through the
node. This table is dynamically programmable,
and a copy of it is kept at each terminal and at
each terminal's local node. Management of
these tables is the primary means for creating a
crosspoint from a terminal source to a destination. For a terminal to obtain access to a particular channel, it simply makes a request to the
table manager (software that currently executes
on a CPU board in one of the terminals) who in
turn modifies the requesting terminal's access
table. These tables can reside in non-volatile
memory at power on, so that fixed connections
can be made as the network is initialized. The
tables are also accessible from the network itself so that they can be read or written to and
downloaded if necessary.
Class 3 Fibre Channel functionality is defined
as a datagram communication methodology
which operates in a "send and forget" manner.
This is a connectionless service which does not
provide reception acknowledgment or automatic retransmission in response to error detection.
This class is used in the ring portion of the system architecture because of the type of data it
has been designed to distribute -- high data
rate audio and video. Due to the nature of the
data itself, real time error recovery in terms of
data retransmission is not practical, and the
choice of class 3 (which does not provide this
service) keeps the interface circuitry complexity
to a minimum. Still, class 3 provides buffer to
buffer flow control so that data is not lost because of the lack of buffer space at the receiv-
94
dpANS X3.xxx-199x
er. The system provides inband signaling and
control distribution which requires more robust
acknowledgment and error recovery services.
Since this is not provided by Fibre Channel itself (in Class 3), it is handled in a upper level
protocol shown in figure 114.
Each network node also provides a point to
point Fibre Channel interconnect to a network
terminal as shown in figure 112. This point to
point interface provides Fibre Channel class 2
and 3 communication services. This interface
provides an access point to sources and destinations of network information. Class 2 services are offered here so that bridges to other
network structures such as LANs, SCSI drives,
ATM switches, etc are possible. Thus the ring
topology can be considered a local area network with bridges to other local or wide area
networks. The node then acts as a gateway between a Fibre Channel real time loop and a Fibre Channel point to point connection.
AC.2.2.3 Network Latency
The real time loop topology has been designed
to a top level system requirement of a 2 millisecond loop rotation time. Any data sourced to
the network will be received by any other terminal on the network within 2 ms, and the time
delta between the reception of the same data
for any two terminals is 2 ms. The network
guarantees this through its system design regardless of how much traffic is currently on the
network. Obviously, this latency is dependent
on the number of nodes on the network, and
this latency can be exceeded if enough nodes
are put onto the network. However simulations
of the interface hardware design have shown
that with a wormholing approach, a 128 byte Fibre Channel frame can be moved through a
node in less that 10 microseconds. With this
timing, the latency requirement above can be
achieved with a configuration of 2000 nodes.
These times are achievable, because, once the
system has been initialized, there is no software interaction required for data movement
from input RTL port to output RTL port through
the node.
AC.2.2.4 Sequence/Exchange Management
When a new window is scheduled on the loop,
it may consist of several data types, but will always consist of at least one data type (there are
no empty windows). Each window's worth of
each data type scheduled for that window can

consist of multiple Fibre Channel frames. This
series of Fibre Channel frames are packaged
into a Fibre Channel Exchange as defined in
FC-PH. Each data type within the window will
be given its own exchange. Thus multiple exchanges can be transmitted within a window.
However, only one exchange is open at any
one time. Within a particular exchange, only
one sequence is opened at a time. An RTL_
Port can only manage one exchange at a time.
Within this one open exchange, the RTL_Port
can manage multiple sequences of multiple
types of data. Only one sequence can be active at a time, and each frame within a sequence is always of the same type.
An RTL_Port is capable of transmitting and receiving up to 16 different types of information.
The transmitted type is identified in the "type"
field of the Fibre Channel header. An RTL_Port
also applies types to exchanges. A port supports up to four different exchange types, each
corresponding to a particular error policy as defined in FC_PH. Each frame transmitted within
an exchange of a particular type will be treated
with the error policy defined for the exchange.
Furthermore, because the RTL_Port is used in
a real time system, it uses the sequence type
within an exchange to decide what sequence
has transmission priority should a transmission
schedule overlap sequence transmission rates.
AC.2.2.5 Use of Flow Control
Since the RTL components of the architecture
use class 3 communication, only R_RDY primitives are available for flow control, and these
are used at each ring interconnect. Specifically, a RTL port transmits an RDY whenever a
buffer becomes available. This is used by the
source RTL port to maintain buffer to buffer
credit. When the RTL network is used in synchronous mode, all data types and sizes are
programmable as are the transmission rates of
each type. Since the frame rates and sizes can
be determined by the system designer ahead of
time, the RTL port buffer space can be designed to support the worst case transmission
scenario. Thus in this mode of operation a RTL
port can theoretically transmit without waiting
for RDYs to indicate buffer availability at the
destination. However, each RTL port supports
the transmission and reception of RDYs as de-
95
dpANS X3.xxx-199x
fined in FC-PH. This is done to support the
asynchronous mode of operation, error recovery situations, and to insure specification compliance and interoperability issues.
AC.2.2.6 Error Recovery
AC.2.2.7 Use of Discard Policy

The network design permits the use of Discard
Policy for synchronous and asynchronous
frames. The use of Discard Policy is as defined
in FC-PH rev 4.3.
AC.2.2.8 Use of Process Policy
The network design allows the use of process
policy for synchronous frames. It makes no attempt to process data within an invalid Fibre
Channel frame, but continues to process subsequent frames within the sequence of which
an invalid frame is a part. This permits the use
of most of an audio or video sequence in the
case where potentially only small portions are
lost.
This process policy is defined in FC-PH-3 and
is a modification to X3.230 in that it allows the
sequence to continue even if the first or last
frame of a sequence is lost. In this case, the
abort sequence bits in the frame header are
valid for each frame in the sequence, not just
the first.
Since the interface permits only one concurrent
sequence, it can detect that a sequence has
ended by the reception of another frame with a
different sequence ID. The interface also closes a sequence if E_D_TOV times out before
the reception of the last frame of a sequence or
the reception of a frame of another sequence.
AC.2.2.9 Acknowledgement
Since the loop interconnects communicate using class 3 services, no acknowledgment is provided by the Fibre C hannel interface
hardware. Where needed, mainly for in-band
control functions, acknowledgment is provided
by the Upper Layer Protocol (ULP). Acknowledgment is provided by the point to point interface using class 2 services.
AC.2.2.10 Wormholing
To decrease network latency, frames pass
through the two RTL_Ports within a node using
a "wormholing" algorithm. Received frames will

be retransmitted by the node without having
been fully received and validated. Both the receiving RTL_Port and the transmitting RTL_
Port are operational with respect to the optical
link simultaneously. Also, multiple nodes can
be processing a particular frame of data at the
same time. Note that this frame could be altered after it was initiated, so that when multiple
nodes are processing the same frame each
node may be working on a different payload.
AC.2.2.11 Frame Validation
With wormholing in effect for synchronous service, several nodes can be accessing data from
the same frame simultaneously. This means
that data is extracted by a node before the
frame has been validated, and thus invalid data
may be extracted. However, it is not the node
that uses the extracted data - it is the terminal.
It doesn't matter that the node has extracted
bad data as long as it is not sent to the local terminal. In order to prevent this from happening,
the node does not send data to its local terminal
until the received network frame has been validated.
Note also that wormholing causes a problem on
the insertion of data into a frame as well. As a
frame is traversing through a node, new data in
the node's insertion buffer (sourced by it's local
terminal) is put into the frame. This happens
before the frame is validated as well. Thus
good data can be put into an invalid frame.
This again is overcome since the destination
terminal will not ever see this data. Frames
which are determined to be invalid because of
an incorrect CRC or an invalid payload by a
node are terminated with an EOFi delimiter
upon retransmission. Although the downstream node may have extracted data from this
invalid frame due to the use of wormholing, it
will not transmit the data to its local terminal
when it sees the EOFi delimiter. The extracted
data, some of which might have been good data, is dropped by the node. Frames with an
EOFi end delimiter continue to be propagated
by the network nodes until the reach the master
node where they are removed.
Frames that are not correctly delimited are removed by the node which detects the incorrect
delimiter. These frames do not propagate back
to the master node.
96
dpANS X3.xxx-199x
AC.2.2.12 External Clocks
AC.2.2.15 Smoothing Algorithm
As the network was designed to support fully

synchronous data distribution, carefully consideration is given to controlling jitter. The network
is designed to support the distribution of information such that the phase relationship of data
put onto the network and taken off of the network can be maintained. To support this the
master node (and its associated backup(s)) are
provided external master clocks which are used
to synchronize the delivery of windows. The
rate of these clocks is a system design parameter. However, for interoperability considerations a standard rate should be chosen. The
recommendation here is a 4.096 MHz clock. It
is further recommended that the clock source
be redundant.
With this network topology, there exists the

eventual certainty of clock mismatch due to
clock frequency skew and jitter. Since each
node transmitter is attempting to maintain the
FC-PH requisite number of six fill characters
between frames, the eventual accumulation of
clock difference between the receive and transmit clock domains a character (taken to be a fill)
will either have to be deleted or inserted. Each
node supports a smoothing algorithm to account for the difference in clock domains passing from node to node. Since each node uses a
clock that meets the frequency tolerances defined in FC-PH, only fractional clock differences
are accumulated on a frame to frame basis.
AC.2.2.13 Link Recovery

In the event that the communication channel
between two nodes fails, the RTL_Ports which
make up the link will continuously attempt to reestablish communication. In this failure scenario, the two nodes go into loopback and network
data flows in a counter-rotating manner. Still
the RTL_Ports which are now out of the loop
will use the link recovery mechanisms defined
in FC_PH to repair the loop. Should the link recovery be successful the two nodes will transition out of loopback mode and into normal
operation. Note that Login is performed before
the healed interconnect can support data flow.
AC.2.2.14 Real Time Support
The network design is intended to support real
time applications, and deterministic performance is necessary. With this intent in mind,
the propagation delay through a node in the
network is a fixed constant number of clock cycles at each node. Each node is expected to
maintain an internal clock to within the specified
tolerance limits specified for Fibre Channel data
transmission. As specified in FC-PH the transmitter is required to provide a minimum of six
clock cycles between frames. With a fixed
number of clock cycles per node (within the tolerances of the transmission clocks at each
node) the frames will maintain their relative time
positions. This fixed number of clock cycles is
a system design parameter. However, when interoperability is considered the number of clock
cycles should be standardized.
Each node provides enough elasticity buffering

to accommodate input data overflow/underflow
that occurs within the lifetime of a frame and will
attempt to recover the difference by adjusting
the perceived number of fills received.
AC.2.2.16 Frame Addressing
For synchronous frame services, each frame
transmitted by any node on the network always
contains the master's address as the S_ID and
the D_ID. These identification fields within the
Fibre Channel frame header can be modified
only by the master node. All other nodes simply pass them through. When the master node
receives a frame with its D_ID in the header
field, it removes the frame from the network.
Note that the payload within the frame is not
dropped, but is stored locally at the master
node. This payload will be inserted into the
next scheduled frame of the received type.
For asynchronous frames the S_ID field contains the address of the frame source (which
can be any node on the network). The D_ID is
the address of the desired destination. Again,
when the node sees its address in the D_ID
field of an asynchronous frame, it removes the
frame from the network. Since there is no rescheduling of the asynchronous frames, the
transmission ends upon frame removal by the
destination.
AC.2.2.17 In-Order Delivery
RTL_Ports use an in-order delivery scheme for
all synchronous and asynchronous transactions
throughout the network in a manner described
in FC-PH. All RTL_Ports logon to each other
97
dpANS X3.xxx-199x
with the in-order delivery parameter set to "required".
AC.2.2.18 Frame Size
Network frame sizes are system design parameters, and buffer space is a function of RTL_
Port design. However, as a minimum the network interface to each local node should provide 31 buffers each sized at a minimum of 512
bytes of data. The interface also should provide buffer space for 31 frame headers of 32
bytes each.
AC.3
AC.3.1
System Level Components

Node Description
As previously defined, a node consists of two

RTL_Ports and an N_Port. Each node also
provides its own power rather than obtaining
power from its local terminal. Autonomous
power allows the loop to maintain full functionality should a terminal fail.
AC.3.2
RTL_Port Functionality
At its optical interface with its upstream or

downstream Port, an RTL_Port operates as a
class 3 N_Port as defined in FC-PH. At its
backend parallel electrical interface an RTL_
Port communicates with a second RTL_Port
and the N_Port within the same node. As a
RTL_Port receives data from its upstream
neighbor, it uses its access table to determine
which parts of the payload (if any) to copy as
the frame passes through it. Copied data is
made available to the N_Port for transmission
to the local terminal. The receiving RTL_Port is
also responsible for validating the received
frame. Data is not transmitted to the local terminal by the N_Port until the received frame
has been validated. The receiving RTL_Port is
responsible for invalidating a frame in the manner defined in FC_PH should it detect an error.
The N_Port within the node is responsible for
building the new data to be retransmitted by the
node. It does so based on data received from
its local terminal via its point to point interface.
The local terminal has been told previously
where in each frame that it can originate data.
This knowledge is kept in the access table
housed within the local terminal. The N_Port
also knows where within each frame it has previously inserted data into the network. In its allocated frame locations where it is sourcing no
new data, the N_Port must insert nulls. This effectively removes data from the network that it
has previously sourced.
The second RTL_Port within the node is responsible for packaging the data generated by
the N_Port into a Fibre Channel frame and
transmitting it to its downstream neighbor. This
RTL Port is also responsible for generating the
CRC before transmission.
The backend interfaces of both RTL_Ports in
conjunction with the backend interface of the
N_Port act together to create a fabric like structure. These backend interfaces move data
from one N_Port to another N_Port. This might
be considered the primary responsibility of a Fibre Channel fabric. One major difference between this functionality and that of a fabric is
that data is that data may be modified as it
passes through the fabric. Since it is not a FC_
PH compliant fabric, it is really performing a
ULP function.
AC.3.3 RTL_Port/N_Port
Characteristics
Fibre
Channel
AC.3.3.1 Primitive Signals

All ports within a node support all FC-PH rev
4.3 primitive signals and requires the use of no
"vendor specific" primitives. Though the optical
network protocol uses class 3, each RTL_Port
is capable of receiving and transmitting frames
with delimiters for all classes (1 through 3).
However, the RTL_Port does not support class
1 and 2 applications. It will reject class 1 and 2
frames with the appropriate delimiters as required in FC-PH.
AC.3.3.2 Basic Link Services
Basic Link Services are handled by the microprocessor in the local node. These services
are all done using the asynchronous mode of
the interface. The local node at the network interface and the point to point interface to the
terminal supports all Basic Link Services as defined in FC-PH rev 4.3 except for the Remove
Connection service which is only used for class
1 connections.
AC.3.3.3 Extended Link Services
Extended Link Services are handled by the microprocessor in the local node as well. Like the
Basic Link Services, the Extended Link Servic-
98
dpANS X3.xxx-199x
es are done in the asynchronous mode. The
node supports Link Service Reject (LS_RJT),
Accept (ACC), N_Port login (PLOGI), F_Port login (FLOGI), logout (LOGO), Abort Exchange
(ABTX), Read Connection Status (RCS), Read
Exchange Status (RES), Read Sequence Status Block (RSS), Read Timeout Value (RTV),
Read Link Status (RLS), and ECHO.
Ports within the node do not support Link Service Busy (LS_BSY), Request Initiative (RSI),
Establish Streaming (ESTS), Estimate Credit
(ESTC), Advise Credit (ADVC), Test (TEST),
and Reinstate Recovery Qualifier (RRQ).
AC.3.3.4 Login/Logout
Each port within a node supports the explicit login and logout procedures defined in FC-PH rev
4.3. Login can be done at any time to reestablish parameters, and can be done with or without a preceding logout.
At a minimum the N_Ports used for the point to

point interface to the node must support ACK_
1.
AC.4
Fabrics
While the Real Time Loop is normally expected

to be a continuous ring of RTL ports connected
by point to point links, it is possible to place an
intervening fabric between two RTL ports. In
this case, in order to meet the real time requirements of the network, it is necessary for the
fabric to provide a dedicated, in order path with
a fixed path delay. If the fabric also supports
the other requirements for RTL such as the
Fairness algorithm, it may also route frames
from outside the ring onto the ring network or
route frames from the net elsewhere.
AC.3.3.5 Use of Credit

RTL_Port support the use of buffer to buffer
credit as defined in FC-PH to manage flow control. N_Port tied to the node's point to point interface use both buffer to buffer credit and end
to end credit
AC.3.3.6 Timers
Each port within a node provides the timers defined in FC-PH. E_D_TOV is used with a resolution of 1 ns.
AC.3.3.7 Sequence/Exchange Status
Each port within a node maintains both Sequence Status Blocks (SSB) and Exchange
Status Blocks (ESB) in accordance with FCPH. The only time where sequence initiative is
passed to to get SSBs and ESBs from a neighbor port to support error management.
AC.3.4
Point To Point Interface
At the point to point interface to its local terminal the node should provide the following programmable buffer space:
240 bytes
512 bytes
1056 bytes
2112 bytes
16 buffers
8 buffers
4 buffers
2 buffers
99
dpANS X3.xxx-199x
AD
Annex AD
(Informative)
Priority and Preemption
Real-time systems require interconnect networks that provide guaranteed bandwidth,

guaranteed in-order delivery, and guaranteed
latency. To meet these requirements, an interconnect network that resolves access contention using priority and preemption is desired.
A priority value in the Fibre Channel frame
header is defined (high 7 bits of the OX_ID
field, see FC-PH-3 clause 18) and can be used
by a Fabric to resolve contention between N_
Ports requesting a Dedicated Connection to a
single resource N_Port. A 7 bit field is defined
since this size enables efficient implementations of the Rate Monotonic Scheduling Algorithm.
Preemption in the context of a Fibre Channel
Fabric is the act of establishing a connection to
a resource or resources (if multicast is used)
that is/are already a part of a dedicated connection. The act of preempting an existing dedicated connection is completed ensuring that
complete frames are transmitted and received
with link integrity maintained.
A preemption is initiated when a preemption request frame (SOFc1 with preemption flag set =
1, defined in FC-PH-3 clause 18) is forwarded
to the Fabric by an unconnected N_Port. The
preemption request will result in (1) the preemption of an existing dedicated connection
and the establishment of a new dedicated connection between the preemption requesting N_
Port (the preemptor) and the desired destination(s) N_Port(s) (the preemption destination(s)), (2) the establishment of a dedicated
connection between the preemptor the preemption destination(s), (3) or rejection of the preemption request by the Fabric. In a real-time
application, rejection by the Fabric might be
due to a priority value that is too low.
The process for performing a preemption is as
follows:
Upon receipt of a request submitted by an FC-4
or other upper level protocol to initiate a con-
nection using preemption, the FC-2 protocol attempts to establish a connection using the
SOFc1, with the preemption flag set = 1, preemption request frame. In the following figure,
the preemptor P is sending a preemption request frame (SOFc1 with preemption flag set =
1) to the Fabric.
Fabric
A
SOFc1
If the Fabric denies the request the Fabric returns a F_RJT Link_Response frame with a
preempt request rejected reason code (FCPH-3 clause 20) to the preemptor with no other
effects on the Fabric. No connections are
changed if the Fabric rejects a preemption request.
Fabric
A
F_RJT
If the Fabric accepts the request, the Fabric terminates the connection(s) being preempted (A
to B) by initiating the Link Reset protocol (FCPH clause 16.6.5) to both the preempted connection initiator and recipient (A and B). Once
the Link Reset protocol is complete the Fabric
forwards an PRMT basic link service command
(FC-PH-3 clause 21.2) to both the preempted
connection initiator and recipient (A and B. N_
100
dpANS X3.xxx-199x
Ports A and B now know why they have abnormally terminated sequences that must be managed).
LR, F_PRMT
Fabric
B
F_PRMT ,LR
The sum of P_T_LR, R_T_LRR, and R_T_ID

should be equal to n times the class 1 connection setup latency. Where the class 1 connection setup latency is the time from when the
connection initiator forwared the SOFc1 to
when the connection recipient detects reception
of the SOFc1. The value of n is dependent on
the application environment. High performance
environments will want a small value of n (~1 or
2), other environments may be function with a
value much larger.
The Fabric then establishes a new connection

(P to B) by forwarding the SOFc1 preemption
request frame to the preemption destination
(B). The new dedicated connection is established when the preemptor (P) receives the acknowledge from the preemption destination N_
Port (B).
Preempt Connection
LR Transmitted
Timeout
Received LRR Received LR
LRR Received
Fabric
A
Transmit Idles
LR Received
Received Idles
Transmit LRR
SOFc1
B
Link Failure
Transmit LR
Active
ACK
Link Reset Protocol: The link reset protocol, as

defined in FC-PH clause 16.6.5 follows the process oulined in the preceeding figure when
used for preemption. The Timeout period is
sp ecified as the R_ T_ TO V value (FC-PH
clause 29.2.1.1) for detection of loss of synchronization (see FC-PH clause 12.1.1.2). To
guarentee timely progress through the preemption sequence the following delays should be
specified by the application layer profile.
P_T_LR, Preempt Connection state to
Transmit LR
R_T_LRR, Received LR to Transmit LRR
R_T_ID, Received LRR to Transmit Idles
Reasonable values for these event delays are
dependent on the application that is using preemption. A rule of thumb that could be useful
might be:
101
dpANS X3.xxx-199x
AE
Annex AE
(Informative)
Report Node Capabilities (RNC)
AE.1
Background
Much information about an N_Port can be determined from its login parameters and how it
responds to certain requests. For example the
login parameters may indicate that Class 1 and
Class 3 are not supported. A failed process login attempt may indicate an N_Port does not
support FCP. A time-out waiting for a response
may indicate an N_Port does not support FCLE (IP). Although ways exist to obtain much of
the information desired, some items can not be
determined without the use of vendor specific
fields. For example, an N_Port which can operate under both the Class 2 only and mixedmode (Class 1 and 2) variations of the FCSI
profiles does not have a standard method to indicate which is preferred (and likely to give the
best performance).
The RNC link service was designed to meet the
following goals:
Provide a standard way to discover what
protocols and standards an N_Port supports
(its capabilities).
Provide a method to select a specific capability from a list of supported capabilities.
Provide a method to indicate preference
or relative level of support of a specific capability (e.g. support of a profile) when multiple
capabilities are supported for a given protocol.
Provide a method to exchange and set
new and additional parameters not specified
during N_Port login.
Provide a standard method to select vendor unique operation modes or profiles.
AE.2
Operation Modes
The RNC link service may be used in two distinct modes:
Querying the capabilities of an N_Port
Setting specific operating modes or parameters

AE.2.1
Query Function
Using the RNC link service to query the N_

Ports capabilities may be accomplished by setting the RNC_Flags Select bit to 0. The requesting N_Port may, but is not required to,
supply Capability Entries in the RNC payload.
The Vendor Identifier must always be supplied.
The requesting N_Port must keep the length of
the RNC payload less than or equal to 256
bytes. This requirement relieves the responding
N_Port from dealing with an arbitrarily large,
unsolicited link service.
The responding N_Port, upon receiving an
RNC request with the Select bit 0, should respond with an RNC Accept payload which lists
all of the nodes capabilities it wishes to report.
No length restriction exists on the RNC Accept
because it is solicited. Also, there is a desire to
keep the responders requirements at a minimum. The responder may choose to vary the
capabilities reported based upon the Vendor
Identifier in the RNC request.
AE.2.2
Selection Function
The RNC link service is designed to allow either

the requesting or the responding N_Port to actually make the selection from the list of supported capabilities.
If the requesting N_Port wishes to allow the responding N_Port to make the selection, it sends
an RNC request with a list if the capabilities it
supports and the Select bit set to 1. The responding N_Port will choose one capability
from the list and include it in the response.
The requesting N_Port can make the selection
itself by first issuing an RNC with the Select bit
set to 0 (query). It then evaluates the list of capabilities in the RNC Accept and selects one.
Finally, it issues an RNC request with the Select bit set and the selected Capability Entry.
The responding N_Port will then be forced to
select the desired entry.
102
dpANS X3.xxx-199x
Of co urse th ere may be variations on the
above. A requesting N_Port may only support a
small set of capabilities (possibly only one). It
may choose not to query the capabilities of the
other node first, but issue an RNC with Select
set to 1 immediately.
Multiple Selections: There may be cases
when both N_Ports support two distinct protocols or classes of capabilities. For example two
N_Ports may communicate using both FCP and
FC-LE (IP) protocols. In this case the requesting N_Port should only list the FCP related capabilities in one RNC request. After the FCP
profile selection is made, the N_Port would then
issue a second RNC request with the Select bit
set and list profiles or capabilities associated
with the FC-LE (IP) protocol.
The RNC definition does not attempt to define
which documents support what protocols or in
any way group associated documents. It is assumed the N_Ports implementing the protocols
and various capabilities will handle the required
associations and distinctions.
Preference Bits: The Preference bits may be
used to aid the selection choice in the event
there are multiple capabilities listed. The two
bits provide a range of four values to rank the
relative preference of multiple capabilities. For
example an N_Port may support three profile
variations for FCP; FCSI SCSI with Class 2,
FCSI SCSI mixed mode, and a vendor unique
FCP profile. The node may wish to assign a
preference as follows:
00 (Best) - Vendor unique FCP
01 - FCSI SCSI mixed mode (protocol

chip may be designed for Class 1)
11 (Worst) - FCSI SCSI w/Class 2 (supported for interoperability reasons, but poor
performance)
Of course another N_Port may work best with
FCSI SCSI with Class 2. The idea is that an N_
Port may have hardware or software implementations which favor a certain operating mode.
The Preference bits allow that information (in a
limited way) to be exchanged with other N_
Ports.
Invalidate Bit: The Invalidate bit allows a
change in a previous selection. Unless the Invalidate bit is set, additional RNC requests with
the Select bit set to 1 are assumed to be selecting additional capabilities which are unrelated
(non-conflicting) with previously chosen capabilities.
To renegotiate a capability, the specific capability selected in the prior RNC request should
be included in the new RNC request as the first
Capability Entry with the Invalidate bit set to 1.
The capabilities the requesting N_Port wishes
the replacement selection to be made from
should follow the entry marked invalid.
Extensions: Extensions to a Capability Entry
allow option bits, parameters, or other information to be specified as a capability. The document referenced in the Capability Entry is
responsible for defining the meaning of all fields
in the extension except the Extension Length.
An example usage of extensions would be if a a
document defined a new feature which would
allow increased performance. The use of the
feature, however, may break older devices
which do not have the feature. An extension bit
or field in the RNC capability entry for that document could be used to indicate support.
The length of any extensions must be a multiple
of four bytes (including the extension length
field). This ensures that all capability entries
start on a 32 bit word boundary.
Vendor Unique Indication: Two bits of flags
are used to indicate vendor unique options. If
the Ca pability Entry is marked a s ve ndor
unique then the value assigned for the document identifier is determined by the vendor. No
attempt is made to coordinate vendor unique
document identifier values across vendors.
Thus, interpretation of a vendor unique document identifier must be in conjunction with the 8
byte ASCII Vendor Identifier in the RNC or RNC
Accept payload.
A value of 00 indicates the referenced document is not vendor unique.
A value of 01 indicates the referenced document is vendor unique. The vendor which defined the vendor unique document is the one
listed in the Vendor Identifier field of the current
RNC or RNC Accept payload.
A value of 10 indicates the referenced document is vendor unique, but it is defined by the
other N_Port. For example, if vendor A supports a unique profile y, then vendor As N_
103
dpANS X3.xxx-199x
Port would use a Vendor Unique flag value of
01 in the capability entry for profile y when it
sends an RNC request. If the request goes to
an N_Port made by vendor B, and the receiving N_Port is aware of and supports the profile
defined by vendor A, then vendor Bs N_Port
would indicate support for vendor As profile by
using a Vendor Unique flag value of 10 for the
capability entry for profile y, in the accept payload.
104
dpANS X3.xxx-199x
Index
A
OX_ID
ACC (Accept) 34
Address identifiers 22
Association_Header 29
P
Priority 22, 27??, 43, 52, 53??, 55
Process Policy 25, 66
Process_Associator 29
Profile 2, 36
C
Clock synchronization
73
D
Definitions
26
E
E_D_TOV 34
Resolution 31, 34, 43, 47, 49, 54, 66
Editorial conventions 2
Exchange management 58
Exchange Status Block 58
Extended Link Service commands
Read Timeout Value (RTV) 32, 34
Report
Vendor
Unique
Information
(RVU) 2, 33, 3539
F
F_CTL
Abort Sequence Condition
Fabric Login 88
FC-4 Region 2, 34
22
R_A_TOV 34
Read Timeout Value (RTV) 32, 34
Report Vendor Unique Information (RVU)
33, 3539
Request Clock Synchronization (REQCS)
78
S
Sequence 59
Sequence Status Block 59
Shielded twisted pair cable 18
T
Time Server 56
TV 17
TYPE 22, 82
V
Video cable
K
Key Distribution Server
22
L
Logout 89
Long video cable
17
M
Miniature coax cable
Multicast 29
18
N
N 89
N_Port Login
89
O
Optional headers
Association_Header
I-105
29
17
2,
2,
End of
Document
10/15/96

FC PH 3 - 9.1

Uploaded by

Copyright:

Available Formats

FC PH 3 - 9.1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FC PH 3 - 9.1

Uploaded by

Copyright:

Available Formats

Copies of this document may be purchased from:

Global Engineering, 15 Inverness Way East,

working draft proposed

Carl Zeitler (X3T11 Vice Chairman)

Changed from Revision 9.0:

Revised Clauses 7, 9, and Annex F as a result of the X3T11 Letter Ballot.

Changed BER definition in 5.1 to reflect FC-PH-2.

draft proposed American National Standard

for Information Technology

Information Technology Industry Council

American National Standards Institute, Inc.

Approval of an American National Standard requires verification by ANSI that the

American National Standards Institute

Copyright 199x by American National Standards Institute

Printed in the United States of America

2.1 Approved references

2.2 References uder development . . . . . . . . . . . . . . . . . . . . .

3 Definitions and conventions

3.1.1 FC-4 Region . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2 Editorial conventions . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3 Abbreviations, acronyms and symbols

3.3.1 Acronyms and other abbreviations

4.16 FC-4 Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 FC-0 functional characteristics . . . . . . . . . . . . . . . . . . . . . . .

4 Structure and concepts

5.1 General Characteristics

6 Optical fibre interface specification . . . . . . . . . . . . . . . . . . . . .

Electrical cable interface specification . . . . . . . . . . . . . . . . . . .

7.2 Reference locations

7.2.1 Intercabinet references

7.2.2 Intracabinet references

7.3 75 W unbalanced data links

7.3.1 ECL compatible driver characteristics . . . . . . . . . . . . . . .

7.3.2 ECL compatible receiver characteristics

7.3.3 Unbalanced cable characteristics

7.3.4 Unbalanced cable connectors . . . . . . . . . . . . . . . . . .

7.3.4.1 Intercabinet connectors for unbalanced cable

7.3.4.2 Style-1 unbalanced cable connector

7.3.4.3 Style-2 unbalanced cable connector

7.3.4.4 Intracabinet connectors for unbalanced cable

7.4.1 ECL compatible driver characteristics . . . . . . . . . . . . . .

7.4 150W balanced data links

7.4.2 ECL compatible receiver characteristics . . . . . . . . . . . . .

7.4.3 Balanced cable characteristics

7.4.4 Balanced cable connectors

7.4.4.1 Intercabinet connectors for balanced cable

7.4.4.2 Style-1 balanced cable connector . . . . . . . . . . . . . .

7.4.4.3 Style-2 balanced cable connector . . . . . . . . . . . . . .

7.4.4.3.1 Style-2 plug

7.4.4.3.2 Style-2 receptacle . . . . . . . . . . . . . . . . . . . .

7.4.4.4 Optional intercabinet connector pins

7.4.4.5 Intracabinet connectors for balanced cable

7.4.4.6 Intracabinet connectors for balanced cable

8 Optical fibre cable plant specification . . . . . . . . . . . . . . . . . . .

9 Electrical cable plant specification

9.1 Unbalanced cable plant

9.1.1 LV (long-video) cable plant specification

9.1.2 TV (video) cable plant specification

9.1.3 MI (miniature) cable plant specification