ANSI INCITS TR 40-2005 INCITS Technical Report for Information Technology C Fibre Channel C Avionics Environment C SCSI-3 Remote Direct Memory Access (FC-AE-RDMA).pdf

1、American National StandardDeveloped byINCITS Technical Reportfor Information Technology Fibre Channel Avionics Environment SCSI-3 Remote Direct Memory Access(FC-AE-RDMA)INCITS TR-40-2005 (R2010)INCITS TR-40-2005INCITS TR-40-2005 (R2010)INCITS Technical Reportfor Information Technology Fibre Channel

2、Avionics Envrionment SCSI-3 Remote Direct Memory Access(FC-AE-RDMA)SecretariatInformation Technology Industry CouncilAbstractThis technical report defines a set of features necessary to implement a real-time Fibre Channel network(switched fabric or arbitrated loop) supporting the FC-AE-RDMA Upper Le

3、vel Protocol. Any device com-plying with this report should interoperate with other devices that comply with the FC-AE-RDMA protocol.The FC-AE-RDMA ULP was first defined in the FC-AE Technical Report, INCITS TR-31-2002. This is thefirst update to FC-AE-RDMA as a standalone document.Published byAmeri

4、can National Standards Institute25 West 43rd Street, New York, New York 10036Copyright 2006 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 permission o

5、f the publisher.Printed in the United States of AmericaINCITS Technical Report SeriesThis Technical Report is one in a series produced by the International Committeefor Information Technology Standards (INCITS). The secretariat for INCITS is heldby the Information Technology Industry Council (ITI),

6、1250 Eye Street, NW, Suite200, Washington, DC 2005.As a by-product of the standards development process and the resources ofknowledge devoted to it, INCITS from time to time produces Technical Reports.Such Technical Reports are not standards, nor are they intended to be used assuch.INCITS Technical

7、Reports are produced in some cases to disseminate thetechnical and logical concepts reflected in standards already published or underdevelopment. In other cases, they derive from studies in areas where it is foundpremature to develop a standard due to a still changing technology, orinappropriate to

8、develop a rigorous standard due to the existence of a number ofviable options, the choice of which depends on the users particular requirements.These Technical Reports, thus, provide guidelines, the use of which can result ingreater consistency and coherence of information processing systems.When th

9、e draft Technical Report is completed, the Technical Committee approvalprocess is the same as for a draft standard. Processing by INCITS is also similarto that for a draft standard.PatentStatementCAUTION: The developers of this Technical Report have requested that holdersof patents that may be requi

10、red for the implementation of the standard, disclosesuch patents to the publisher. However, neither the developers nor the publisherhave undertaken a patent search in order to identify which, if any, patents mayapply to this Technical Report. As of the date of publication of this Technical Report an

11、d following calls for theidentification of patents that may be required for the implementation of theTechnical Report, no such claims have been made. No further patent search isconducted by the developer or the publisher in respect to any Technical Report itprocesses. No representation is made or im

12、plied that licenses are not required toavoid infringement in the use of this Technical Report.Contents ForewordiiiIntroduction viii1. Scope 1 2. Normative References 2 2.1 Overview2 2.2 Approved references .2 2.3 References under development 2 3. Definitions and conventions 3 3.1 Overview3 3.2 Defin

13、itions3 3.3 Editorial conventions .4 3.3.1 Overview.4 3.3.2 Binary notation4 3.3.3 Hexadecimal notation .4 3.4 Abbreviations and acronyms.5 3.5 Applicability and use of this document 6 4. FC-AE-RDMA Protocol .7 4.1 Introduction to FC-AE-RDMA7 4.2 Remote Direct Memory Access (RDMA) using FCP.7 4.2.1

14、FC-AE-RDMA Modifications to FCP.7 4.2.2 Logical Unit .7 4.2.3 FC-AE-RDMA Frame Header.8 4.2.4 FC-AE-RDMA Features8 4.2.4.1 Overview 8 4.2.4.2 Port Login Service Parameters 12 4.2.4.3 Process Login Service Parameters12 4.2.4.4 FCP_CMND IU.12 4.2.4.4.1 Overview12 4.2.4.4.2 Logical Unit Number (FCP_LUN

15、) 12 4.2.4.4.3 Control Field (FCP_CNTL) 12 4.2.4.4.4 Command Descriptor Block (FCP_CDB) 12 4.2.4.4.5 Data Length (FCP_DL)12 4.2.4.5 FCP_XFER_RDY IU 12 4.2.4.6 FCP_DATA IU13 4.2.4.7 FCP_RSP IU 13 Annex A.15 A.1 Introduction 15 A.2 FC-FS and FC-AL-2 Features for FC-AE-RDMA 15 A.2.1 Overview15 A.2.2 Li

16、nk Protocols 21 A.2.3 Arbitrated Loop 21 A.2.4 Fabric Login.22 A.2.4.1 Overview .22 A.2.4.2 Fabric Login Common Service Parameters .22 A.2.4.3 Fabric Login Class Specific Service Parameters.23 A.2.5 N_Port Login.23 A.2.5.1 Overview .23 i A.2.5.2 N_Port Login Common Service Parameters23 A.2.5.3 N_Por

17、t Login Class 2 Service Parameters 24 A.2.5.4 N_Port Login Class 3 Service Parameters 24 A.2.6 Fabric Reject/Fabric Busy 24 A.2.7 Port Reject/Port Busy .24 A.2.8 Well Known Address Support.25 A.2.9 Basic Link Services 25 A.2.10 Extended Link Services25 Figures Figure 1 FC-AE-RDMA Parameter Field Usa

18、ge FCP_CMND IU only.8 Tables Table 1 Summary of Implementation and Use of Features 6 Table 2 FC-AE-RDMA Features .9 Table A.1 FC-FS and FC-AL-2 Features for Example Avionics Network .15 ii iiiForeword (This foreword is not part of American National Standard INCITS TR-40-2005.)The original Fibre Chan

19、nel Avionics Environment (FC-AE) Technical Report, INCITSTR-31-2002, is a set of protocols and profiles that specify Fibre Channel options fordevices that could be used in commercial and military aerospace applications. TheFC-AE-2 task group determined that it was best to allow protocols and profile

20、s de-fined in FC-AE to be updated independently. The Fibre Channel - Avionics Environ-ment - SCSI-3 Remote Direct Memory Access (FC-AE-RDMA) Technical Report isthe first update to the FC-AE-RDMA protocol since FC-AE was released. This tech-nical report is recommended for new designs, but does not ob

21、solete clause 4.6 of INCITS TR-31-2002.This technical report was developed by Technical Committee T11 of AccreditedStandards Committee INCITS during 2004-2005. The final approval process startedin 2005.This technical report contains one annex, which is informative and is not part of thetechnical rep

22、ort.Requests for interpretation, suggestions for improvements or addenda, or defect re-ports are welcome. They should be sent to the INCITS Secretariat, Information Tech-nology Industry Council, 1250 Eye Street, NW, Suite 200, Washington, DC 20005-3922.This technical report was processed and approve

23、d for submittal to ANSI by the Inter-National Committee for Information Technology Standards (INCITS). Committee ap-proval of the technical report does not necessarily imply that all committee membersvoted for approval. At the time it approved this technical report, INCITS had the fol-lowing members

24、:Karen Higginbottom, ChairJennifer Garner, SecretaryOrganization Represented Name of RepresentativeAIM Global Dan Mullen Charles Biss (Alt.)Apple Computer, Inc. David Michael Electronic Industries Alliance Edward Mikoski, Jr. Henry Cuschieri (Alt.)EMC Corporation Gary Robinson Farance, Inc. Frank Fa

25、rance Hewlett-Packard Company. Karen Higginbottom Steve Mills (Alt.)Scott Jameson (Alt.)IBM Corporation Ronald F. Silletti IEEE . Judith Gorman Terry DeCourcelle (Alt.)Robert Pritchard (Alt.)Jodie Haasz (Alt.)Bob Labelle (Alt.)Intel Philip Wennblom Dave Thewlis (Alt.)Jesse Walker (Alt.)Lexmark Inter

26、national . Don Wright Dwight Lewis (Alt.)Paul Menard (Alt.)Microsoft Corporation . Isabelle Valet-Harper Don Stanwyck (Alt.)Mike Ksar (Alt.)Jim Hughes (Alt.)ivOrganization Represented Name of RepresentativeNational Institute of Standards equivalent to the phrase “it is strongly recommended”. The ter

27、m “may” is used to indicate flexibility of choice with no implied preference; equivalent to “may or may not”. The fields or control bits that are not applicable shall be set as required by the defining standard or technical report. If a field or a control bit in a frame is specified as not meaningfu

28、l, the entity that receives the frame shall not check that field or control bit. In several tables within this document, there is a column on the right side of the table labeled “Notes”. These notes are NORMATIVE and shall be considered requirements of this document. In the event of conflict between

29、 the text, tables, and figures in this document, the following precedence shall be used: tables (highest), text and figures (lowest). 3.3.2 Binary notation Binary notation may be used to represent some fields. Single bit fields are represented using the binary values 0 and 1. For multiple bit fields

30、, the binary value is enclosed in single quotation marks followed by the letter b. For example, a four-byte field containing a binary value may be represented as 00000000 11111111 10011000 11111010b. 3.3.3 Hexadecimal notation Hexadecimal notation may be used to represent some fields. When this is d

31、one, the value is enclosed in single quotation marks and preceded by the word hex. For example, a four-byte field containing a binary value of 00000000 11111111 10011000 11111010b is shown in hexadecimal format as hex 00 FF 98 FA. 4 INCITS TR-40-2005 3.4 Abbreviations and acronyms Abbreviations and

32、acronyms applicable to this technical report are listed below. Abbreviations and acronyms for commonly used terms defined in referenced standards are not listed here. FC-AE-RDMA Fibre Channel - Avionics Environment SCSI-3 Remote Direct Memory Access, this technical report FCP Fibre Channel Protocol

33、for SCSI RDMA Remote Direct Memory Access IU Information Unit SCSI Small Computer System Interface (as defined by the SCSI-3 family of standards) ULP Upper Level Protocol 5 INCITS TR-40-2005 3.5 Applicability and use of this document The usual definitions of the following words do not apply! Please

34、read these definitions carefully! Required: If a feature or parameter value is Required, it means that it shall be used between compliant implementations. Compliant implementations are required to implement the feature. Interoperability is not guaranteed if Required features are not implemented. Eac

35、h Required feature will include a note that describes the condition(s) in which the feature shall be used. Invocable: If a feature or parameter value is Invocable, it means that it may be used between compliant implementations. Compliant implementations are required to implement the feature. Invocab

36、le is different from Required in that an implementation may use the feature if needed, but is not required to use it. No discovery process is necessary prior to use of an Invocable feature. Allowed: If a feature or parameter value is Allowed, it means that it may be used between compliant implementa

37、tions. Compliant implementations are not required to implement the feature. Typically, the potential user of an Allowed feature may determine if an implementation supports it via an Invocable discovery process. Prohibited: If a feature is Prohibited, it means that it shall not be used between compli

38、ant implemen-tations. This document does not Prohibit the implementation of features, only their use between compliant implementations. Interoperability is not guaranteed if Prohibited features are used. Table 1 summarizes the above definitions. Table 1 Summary of Implementation and Use of Features

39、Term Implementation Use Required Shall Shall Invocable Shall May Allowed May May Prohibited May Shall Not The tables in the following clauses list features described in the various Fibre Channel standards and technical reports. These tables indicate whether the features are Required, Prohibited, Inv

40、ocable, or Allowed for compliance with this report; or whether a parameter is Required to be a particular value for compliance with this report. Features or parameters that are not listed do not affect the interoperability of FC-AE-RDMA devices. The following legend is used for table entries in thes

41、e clauses: R Required I Invocable A Allowed P Prohibited n the parameter shall be set to this value X this parameter has no required value; any value is Allowed - this parameter or feature is not meaningful 6 INCITS TR-40-2005 4. FC-AE-RDMA Protocol 4.1 Introduction to FC-AE-RDMA This technical repo

42、rt defines an Upper Level Protocol (ULP), FC-AE-RDMA. FC-AE-RDMA is based on Fibre Channel Protocol for SCSI (FCP) 2. This clause lists features described in the FCP standard and indicates whether the features are Required, Prohibited, Allowed, or Invocable in FC-AE-RDMA. This clause also defines so

43、me new features for FC-AE-RDMA that are not defined in FCP. FC-AE-RDMA follows the FCP standard in its definition of the services necessary to support low-latency, low overhead communication between elements of a mission-critical avionics system. The key feature of FC-AE-RDMA is that it allows an In

44、itiator to read data from or write data to a remote Target memory in peer-to-peer mode (similar to SCSI-3 processor device type) with lower latency. All FC-AE-RDMA compliant devices shall be capable of operating as a Initiator and a Target. NOTE 1 There is another protocol similar in operation to FC

45、-AE-RDMA. It is the Fibre Channel Lightweight Protocol described in clause 4.5 of FC-AE 5. While they are similar, there are sufficient differences to warrant their own protocols, especially in their use of the FCP_XFER_RDY IU and the Command Descriptor Block. 4.2 Remote Direct Memory Access (RDMA)

46、using FCP 4.2.1 FC-AE-RDMA Modifications to FCP FC-AE-RDMA places certain restrictions on FCP in order to improve support for low latency, real-time applications. For example, the FCP_XFER_RDY IU is not used and data immediately follows the FCP_CMND IU. In FC-AE-RDMA, a Target shall predefine one or

47、 more regions of its local memory for RDMA use. An Initiator then reads or writes data directly into the Target memory. The contents of the FCP_CMND IU are not redefined, but usage of the Parameter field of the header is modified. The Parameter field in the FCP_CMND IU is used to indicate that the t

48、ransfer is FC-AE-RDMA and to specify the base address that the Target uses as a starting point for the read or write operation. NOTE 2 This protocol does not prohibit a target memory region from overlapping with any other target memory region. A system designer may choose to restrict memory region u

49、sage depending on the application. 4.2.2 Logical Unit Logical Units may be used to identify separate memory regions within a Target. The FCP_LUN field of the FCP_CMND IU is used to identify a specific Logical Unit for each Message. All Targets shall provide at least one RDMA memory region assigned to Logical Unit 0 (FCP_LUN = 0). Targets may optionally define additional memory regions assigned to Logical Units with FCP_LUN values of 1-255. The additional LUNs do not have to be contiguous. These Logical Units are designated in the LUN/Targ