1、American National StandardDeveloped byINCITS Technical Reportfor Information Technology Fibre Channel Device Attach (FC-DA)INCITS TR-36-2004INCITS TR-36-2004INCITS TR-36-2004INCITS Technical Reportfor Information Technology Fibre Channel Device Attach (FC-DA)AbstractThis technical report selects and
2、 restricts logical options from the Fibre Channel Framing and Signaling,Fibre Channel Protocol for SCSI, Fibre Channel Arbitrated Loop, Fibre Channel Generic Services, andFibre Channel Single Byte Command Set standards. The intent of this technical report is to facilitate in-teroperablity between de
3、vices whether they are connected in a loop or Fabric topology.Approval of an American National Standard requires review by ANSI that therequirements for due process, consensus, and other criteria for approval havebeen met by the standards developer.Consensus is established when, in the judgement of
4、the ANSI Board ofStandards Review, substantial agreement has been reached by directly andmaterially affected interests. Substantial agreement means much more thana simple majority, but not necessarily unanimity. Consensus requires that allviews and objections be considered, and that a concerted effo
5、rt be madetowards their resolution.The use of American National Standards is completely voluntary; theirexistence does not in any respect preclude anyone, whether he has approvedthe standards or not, from manufacturing, marketing, purchasing, or usingproducts, processes, or procedures not conforming
6、 to the standards.The American National Standards Institute does not develop standards andwill in no circumstances give an interpretation of any American NationalStandard. Moreover, no person shall have the right or authority to issue aninterpretation of an American National Standard in the name of
7、the AmericanNational Standards Institute. Requests for interpretations should beaddressed to the secretariat or sponsor whose name appears on the titlepage of this standard.CAUTION NOTICE: This American National Standard may be revised orwithdrawn at any time. The procedures of the American National
8、 StandardsInstitute require that action be taken periodically to reaffirm, revise, orwithdraw this standard. Purchasers of American National Standards mayreceive current information on all standards by calling or writing the AmericanNational Standards Institute.American National StandardPublished by
9、American National Standards Institute, Inc.25 West 43rd Street, New York, NY 10036Copyright 2003 by Information Technology Industry Council (ITI)All rights reserved.No part of this publication may be reproduced in anyform, in an electronic retrieval system or otherwise,without prior written permissi
10、on of ITI, 1250 Eye Street NW, Washington, DC 20005. Printed in the United States of AmericaiContentsPageForeword v1 Introduction and scope. 12 Normative reference 32.1 Overview . 32.2 Approved references 32.3 References under development. 33 Definitions and conventions. 43.1 Overview 43.2 Definitio
11、ns 43.3 Editorial conventions 63.4 Abbreviations and acronyms 73.5 Symbols . 73.6 Keywords . 73.7 Applicability and use of this technical report 83.8 Feature Set table terms, definitions, and abbreviations. 93.8.1 Overview 93.9 Feature testing compliance 103.10 Timing Constraints. 104 End device mod
12、el 104.1 Loop behaviors 114.1.1 Loop initialization . 114.1.2 Post initialization 134.1.3 Receipt of CLS in response to OPN 144.1.4 No response to OPN 144.1.5 Broadcast and multicast. 154.1.6 NL_Port operation 154.2 Public Loop and Private Loop behavior . 154.2.1 Overview 154.2.2 Public NL_Port and
13、Private NL_Port behavior. 164.2.3 Public and Private device addressing 174.3 Nx_Port initialization 194.4 Nx_Port node and port naming 224.5 NL_Port login validation. 224.6 Nx_Port login . 234.6.1 Class of service support. 234.6.2 Class of service support for FLOGI and PLOGI. 234.6.3 FLOGI parameter
14、s. 244.6.4 PLOGI parameters. 25iiPage4.6.5 Nx_Port Class 2 Service Parameters (PLOGI) 274.6.6 Nx_Port Class 2 Service Parameters (FLOGI) 284.6.7 Nx_Port Class 3 Service Parameters (PLOGI) 304.6.8 Nx_Port Class 3 Service Parameters (FLOGI) 314.7 FC-AL-2 features for NL_Ports 324.8 Other Nx_Port FC-FS
15、-2 and FC-LS features. 354.9 Nx_Port Link Services . 374.9.1 Basic Link Services 374.9.2 Extended Link Service requests 384.9.3 Extended Link Service replies . 404.9.4 Link Error Status Block (LESB) support requirements. 414.10 Well-known address usage by Nx_Ports . 414.11 FC-CT Common Request suppo
16、rt . 434.12 Nx_Port Name Server query support. 434.13 N_Port_ID Virtualization 444.13.1 Overview 444.13.2 N_Port_ID Virtualization acquisition procedure . 454.13.3 Buffer-to-buffer flow control management . 504.14 CS_CTL/Priority header field usage 504.14.1 Overview 504.14.2 Priority 514.14.3 CS_CTL
17、 . 514.15 Logout procedure. 514.16 Nx_Port management and discovery. 524.16.1 Overview 524.16.2 End devices . 524.17 Fabric event notification. 535 FC-4 specific behavior . 545.1 FCP Nx_Port behavior. 545.1.1 Device binding . 545.1.2 Registered state change notification 545.1.3 FCP Nx_Port Common Se
18、rvice Parameters for PLOGI 545.1.4 FCP Class 2 and Class 3 Service parameters for FLOGI . 545.1.5 FCP Class 2 Service Parameters for PLOGI - Sequential-access devices . 555.1.6 FCP Class 3 Service Parameters for PLOGI. 555.1.7 FCP usage of F_CTL Abort Sequence Condition bits . 555.1.8 FCP usage of P
19、rocess Login parameters 575.1.9 FCP Extended Link Services . 585.1.10 FC-4 Link Service Requests and Responses for FCP. 585.1.11 FCP_RSP payload fields . 585.1.12 FC-AL-2 requirements for FCP 595.1.13 FCP device discovery 595.1.14 FCP Private NL_Port Exchange authentication. 605.2 FC-SB-3 N_Port beh
20、avior 61iiiPage5.2.1 FC-SB-3 Extended Link Services. 615.2.2 FC-SB-3 Class of Service support . 615.2.3 FC-SB-3 Class Service Parameters support 615.3 IP Nx_Port behavior. 62AnnexA Discovery and Management: Examples equivalent to the phrase “it is strongly recommended”.3.7 Applicability and use of t
21、his technical reportThis technical report specifies which features shall be used (i.e., required) and which features shallnot be used (i.e., prohibited) by interoperating compliant Fibre Channel implementations. Use ofsome features is optional (i.e., allowed). The use of such functions is either neg
22、otiated in a fixed andstandard manner or the availability of the functions for use shall be determined in a standard manner.The relationship between use as specified in this technical report and support as implemented by aproduct is subtle. If this technical report specifies that a feature shall be
23、used, then a compliant imple-mentation shall support it. In some cases, this technical report is asymmetric: to ensure interoperabil-ity when an optional feature is used, this technical report requires support for the infrastructurerequired to use the feature without specifying that the feature be u
24、sed to conform to this technical re-port.The requirements of this technical report are a proper subset of the various relevant standards. Thistechnical report prohibits use of many features and options in these standards. Use of prohibited fea-tures may prevent interoperability with Fibre Channel de
25、vices complying to this technical report. Thistechnical report does not prohibit implementation of features, only their use. Functions that are man-datory in the appropriate base standard are assumed to be implemented. Implementations may sup-port features whose use is prohibited by this technical r
26、eport and such prohibited features may berequired for compliance with the relevant standards or other technical reports.INCITS TR-36-20048In the event of conflicts between this technical report and other technical reports, the resolution ofthose conflicts is beyond the scope of this technical report
27、.3.8 Feature Set table terms, definitions, and abbreviations3.8.1 OverviewFeatures in this technical report are summarized in the form of Feature Set tables. These tables indi-cate whether the feature is Required, Prohibited, Invocable, or Allowed for compliance with this tech-nical report; or wheth
28、er a parameter is Required to be a particular value for compliance with thistechnical report. Features or parameters that are not listed do not affect interoperability of Public orPrivate NL_Ports.In several tables within this technical report, there are references to notes associated with the table
29、.These notes are normative and are mandatory requirements of this technical report.3.8.1.1 Feature Set table terms and definitionsTerms and definitions are used to define usage of reference features or options provided by the appli-cable standards are described in table 2.Table 2 Feature Set table t
30、erms and definitionsTerm DefinitionProhibitedA feature that shall not be used between Fibre Channel devices compliant with this technical report. An implementation may use the feature to communicate with non-compliant implementations. This technical report does not prohibit the implementation of fea
31、tures, only their use between Fibre Channel devices com-pliant with this technical report. Use of a prohibited feature may prevent interop-erability with Fibre Channel devices complying to this technical report.RequiredA feature or parameter value that shall be used between all Fibre Channel devices
32、 compliant with this technical report. Fibre Channel devices compliant with this technical report are required to implement the feature. An implementa-tion may use the feature to communicate with non-compliant implementations. If a Fibre Channel device does not implement a required feature that devi
33、ce may not be interoperable with Fibre Channel devices complying to this technical report.AllowedA feature or parameter value that may be used between Fibre Channel devices compliant with this technical report. Fibre Channel devices compliant with this technical report are not required to implement
34、the feature, but if they do, the fea-ture shall be implemented as described in the applicable standard. The potential user of a feature may determine if the recipient supports that feature via a Required discovery process or a minimal response by the recipient.InvocableA feature or parameter that is
35、 required to be implemented by a device to which a request may be sent, but it is not required to be used by a requesting device.INCITS TR-36-200493.8.1.2 Feature Set table abbreviationsTable 3 contains the key of table abbreviations used within this technical report.3.9 Feature testing complianceWh
36、ile not a compliance vehicle in itself, this technical report should be used as the basis for compli-ance testing. As such, the relationship for the definitions of Prohibited, Required, Allowed, and Invo-cable (see 3.8) to compliance testing is described in table 4.3.10 Timing ConstraintsAll timings
37、 defined in this technical report limit the amount of time a device takes to accomplish atask. These timings shall be measured on an unloaded system. A heavily loaded system may exhibittimings in excess of those specified. The term unloaded means that system activity is induced only indirect invocat
38、ion of the feature under test.Table 3 Feature Set table key abbreviationsKey DefinitionPProhibitedRRequiredAAllowedIInvocableXThis parameter has no required value; any value is allowed.-This parameter or feature is not meaningful.Table 4 Feature testing compliance relationship to definitions Term De
39、finitionProhibitedA feature that is not allowed to be used in a compliant implementation. A compli-ance test shall only verify that the prohibited feature is not requested by a device. A compliance test shall not generate a request for the prohibited feature, since if it does so, the response is out
40、side the scope of this technical report.RequiredA feature that is required to be implemented by a compliant device. A compliance test is allowed to verify that the feature is correctly requested, and responded to as specified in this technical report or other referenced standards and technical repor
41、ts.AllowedIf a device claims to implement the feature, the feature may be tested. If tested, the feature shall conform to the discovery mechanism and function as specified in this technical report and other referenced standards and technical reports. If a device claims to not implement a feature, th
42、e feature shall not be tested.InvocableA feature that is required to be implemented by a device to which a request may be directed, but it is not required to be used by a requesting device. A compli-ance test is allowed to verify that the request is correctly responded to as speci-fied in this techn
43、ical report or other referenced standards and technical reports.INCITS TR-36-2004104 End device model4.1 Loop behaviors4.1.1 Loop initialization4.1.1.1 Power-on behaviorDuring power-on, after the transmitter has been enabled and 200 microseconds of valid Fibre Chan-nel signal at or above FC-PI minim
44、um amplitude levels has been driven by the transmitter, anNL_Port that is not executing Speed Negotiation shall not disrupt the operation of the loop for morethan 95 milliseconds and shall begin forwarding transmission words or begin initialization within 95milliseconds.NOTE 1 The delay of 200 micro
45、seconds and the enforcement of limits on disruption recognizes that: a)many NL_Ports by design, disrupt during power-up; and b) most hubs isolate an attached NL_Port until it haspresented at least 200 microseconds of FC-PI-compliant signal. The expectation is that any disruption causedby an NL_Port
46、at power-up is harmless until after it has presented 200 microseconds of valid signal, becauseuntil then it is isolated from the loop by its hub.FC-FS-2 specifies the disruption of a loop that may result from attaching to it an NL_Port configuredto execute Speed Negotiation. An NL_Port that is execu
47、ting Speed Negotiation disrupts up to threetimes over a period not exceeding t_disrupt2. No period of disruption exceeds t_disrupt1. See FC-FS-2 for definitions and derivations of t_disrupt1 and t_disrupt2.4.1.1.2 Loop failureAn NL_Port shall not issue a LIP for loop failure based on loss of synchro
48、nization before the loss ofsynchronization exceeds R_T_TOV.4.1.1.3 Initialization at power-onNL_Ports shall request only one loop initialization at power up, unless the NL_Port attempts to enterOLD-PORT state, after which only one additional loop initialization may be requested.An NL_Port that is ex
49、ecuting Speed Negotiation may disrupt the loop causing the loop to initializemore than once, however, having completed Speed Negotiation as evidenced by the NL_Port origi-nating or passing through LISM frames, such an NL_Port is subject to the limits of this subclause.4.1.1.4 NL_Port time-out during initializationIt may be necessary for an NL_Port to request loop initialization multiple times. An NL_Port operatingin compliance with FC-AL may repeatedly request initialization using the following rules:1. if loop initialization has not completed within 2 seconds;2. the second time
