ANSI INCITS TR-41-2006 INCITS Technical Report for Information Technology C Fibre Channel C Avionics Environment C Anonymous Subscriber Messaging (FC-AE-ASM).pdf

1、American National StandardDeveloped byINCITS Technical Reportfor Information Technology Fibre Channel Avionics Environment Anonymous Subscriber Messaging(FC-AE-ASM)INCITS TR-41-2006INCITS TR-41-2006Reaffirmed as INCITS/TR-41-2006 (R2016)INCITS TR-41-2006INCITS Technical Reportfor Information Technol

2、ogy Fibre Channel Avionics Envrionment Anonymous Subscriber Messaging(FC-AE-ASM)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-

3、ASM Upper Level Protocol. Any device comply-ing with this report should interoperate with other devices that comply with this technical report. The FC-AE-ASM ULP was first defined in the FC-AE Technical Report, INCITS TR-31-2002. This is the first up-date to FC-AE-ASM as a standalone document.Publis

4、hed byAmerican 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 p

5、ermission of 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 Coun

6、cil (ITI), 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

7、 Technical 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, orinappr

8、opriate to 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 syst

9、ems.When the 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 m

10、ay be required 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 Technica

11、l Report and 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

12、 made or implied that licenses are not required toavoid infringement in the use of this Technical Report.Contents Foreword .iiiIntroduction .ix1. Scope 1 2. References2 2.1 Overview2 2.2 Approved references .2 2.3 References under development 2 3. Definitions and conventions 3 3.1 Overview3 3.2 Defi

13、nitions3 3.2.1 Anonymous Subscriber Messaging (ASM).3 3.3 Editorial conventions .3 3.3.1 Overview .3 3.3.2 Binary notation4 3.3.3 Hexadecimal notation .4 3.4 Abbreviations and acronyms .4 3.5 Applicability and use of this document 4 4. FC-AE-ASM Features .6 4.1 Overview6 4.2 FC-AE-ASM Protocol.6 4.2

14、.1 Overview .6 4.2.2 ASM Header .6 4.3 FC-AE-ASM Profile8 4.3.1 Overview .8 4.3.2 Priority.10 4.3.3 Extended Link Services 10 4.3.4 Fabric Login/Logout 10 4.3.5 N_Port Login/Logout.10 i 4.3.6 Topology Support11 Tables Table 1. Summary of Implementation and Use of Features .4 Table 2. FC-AE-ASM Heade

15、r Format .7 Table 3. Definition of the L field.7 Table 4. FC-FS-2 and FC-AL-2 Features for FC-AE-ASM .8 ii iiiForeword (This foreword is not part of American National Standard INCITS TR-41-2006.)The original Fibre Channel Avionics Environment (FC-AE) Technical Report, INCITSTR-31-2002, is a set of p

16、rotocols 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 profiles de-fined in FC-AE to be updated independently. The Fibre Channel Anonymous Sub-s

17、criber Messaging (FC-AE-ASM) Technical Report is the first update to FC-AE-ASMsince FC-AE was released. This technical report is recommended for new designsbut does not obsolete 4.1 of INCITS TR-31-2002.This technical report was developed by Technical Committee T11 of AccreditedStandards Committee I

18、NCITS during 2004-2005. The final approval process startedin 2005.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,

19、 DC 20005-3922.This technical report was processed and approved 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 its approval. At the time it

20、 approved this technical report, INCITS had thefollowing members: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 Cusc

21、hieri (Alt.)EMC Corporation Gary Robinson Farance, Inc. Frank Farance GS1 US Frank SharkeyJames Chronowski (Alt.)Mary Wilson (Alt.)Hewlett-Packard Company. Karen Higginbottom Steve Mills (Alt.)Scott Jameson (Alt.)IBM Corporation Ronald F. Silletti IEEE . Judith Gorman Terry DeCourcelle (Alt.)Robert

22、Pritchard (Alt.)Jodie Haasz (Alt.)Bob Labelle (Alt.)Intel Philip Wennblom Dave Thewlis (Alt.)Jesse Walker (Alt.)Grace Wei (Alt.)Lexmark International . Don Wright Dwight Lewis (Alt.)Paul Menard (Alt.)Microsoft Corporation . Isabelle Valet-Harper Don Stanwyck (Alt.)Mike Ksar (Alt.)Jim Hughes (Alt.)iv

23、Organization Represented Name of RepresentativeNational Institute of Standards equivalent to the phrase “it is strongly recommended”. The term “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 applicabl

24、e shall be set as required by the appropriate technical report. If a field or a control bit in a frame is specified as not meaningful, 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 tabl

25、e labeled “Notes”. These notes are NORMATIVE and shall be considered requirements of this document. In the event of conflict between the text, tables, and figures in this document, the following precedence shall be used: tables (highest), text and figures (lowest). 3 INCITS TR-41-2006 3.3.2 Binary n

26、otation 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, 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 r

27、epresented as 00000000 11111111 10011000 11111010b. 3.3.3 Hexadecimal notation Hexadecimal notation may be used to represent some fields. When this is done, 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 00000

28、000 11111111 10011000 11111010b is shown in hexadecimal format as hex 00 FF 98 FA. 3.4 Abbreviations and acronyms Abbreviations and acronyms applicable to this technical report are listed below. Abbreviations and acronyms for commonly used terms defined in referenced standards are not listed here. F

29、C-AE-ASM The mnemonic used to define the FC-AE ASM profile ASM Anonymous Subscriber Messaging 3.5 Applicability and use of this document The usual definitions of the following words do not apply! Please read these definitions carefully! Required: If a feature or parameter value is Required, it means

30、 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. Each Required feature will include a note that describes the condition(s) in which the feature must

31、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. Invocable is different than Required in that an implementation may use the feature if needed, but is not

32、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 implementations. Compliant implementations are not required to implement the feature. Typically, the potenti

33、al 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 compliant implementations. This document does not Prohibit the implementation of features, only their us

34、e between compliant implementations. However, interoperability is not guaranteed if prohibited features are used. Table 1 - summarizes the above definitions. Table 1 - Summary of Implementation and Use of Features Term Implementation Use 4 INCITS TR-41-2006 Term Implementation Use Required Shall Sha

35、ll 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, Invocable, or Allowed for compliance with thi

36、s 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-ASM devices. The following legend is used for table entries in these clauses: R Required I Invocable A Allowed

37、 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 5 INCITS TR-41-2006 4. FC-AE-ASM Features 4.1 Overview This technical report is a protocol and profile document. It lists features descr

38、ibed in the Fibre Channel Framing and Signaling-2 (FC-FS-2) 3, Fibre Channel Link Services (FC-LS) 4 and Fibre Channel Arbitrated Loop-2 (FC-AL-2 ) 1 standards and indicates whether the features are Required, Prohibited, Allowed, or Invocable. This FC-AE-ASM profile follows the FC-FS-2 and FC-AL-2 s

39、tandards in its definition of the services necessary to support deterministic, secure, low-latency and low overhead communication elements of a mission-critical avionics system. FC-AE-ASM objects must be easily mapped to other physical transports. Therefore, according to that philosophy no FC-AE-ASM

40、 objects may be mapped to Fibre Channel unique framing fields without also appearing in the appropriate FC-AE-ASM header field (i.e., all FC-AE-ASM objects are mapped into the payload). 4.2 FC-AE-ASM Protocol 4.2.1 Overview Every message in FC-AE-ASM is originated in a single Sequence unidirectional

41、 Exchange. The recipient may be expecting the message to arrive at a predetermined rate and does not know where the message is physically originating, only that it will arrive. Therefore, all messages shall use the Unsolicited Data Information Category (Routing Bits hex 0 and Information Category he

42、x 4). A single message originating from multiple sources shall only be a single frame Sequence from each source. Multiple frame messages shall only come from a single source. Multiple frame sequences shall be reassembled based on Message ID and relative offset. The Relative Offset of the first frame

43、 of each sequence shall be set to 0. Relative Offset shall include the sum of all previous payloads in the sequence. The ASM Header shall be removed on all Frames before reassembly occurs. All devices complying with this protocol shall support the following F_CTL options: Bit 17 Priority Enable Prio

44、rity Enable shall be asserted on each frame of an ASM Sequence when Priority is required Bit 3 Relative Offset Present Relative Offset Present shall be set to 1b on all frames of each ASM Sequence. DF_CTL shall be set to hex 00 (ASM Frames Only) and the Type code shall be set to hex 49 on each frame

45、. ELS Sequences are not considered ASM Sequences. ELS Sequences shall conform to the rules specified in FC-FS-2 3 and FC-LS 4. 4.2.2 ASM Header The first four words (or 16 bytes) of the Payload of each FC-AE-ASM Frame are reserved for the FC-AE-ASM header. In multi-frame sequences, all frames shall

46、contain a copy of the FC-AE-ASM header. The format of the FC-AE-ASM header is specified in Table 2 -. The ASM Header shall have the same content in each frame in a multi-frame Sequence. 6 INCITS TR-41-2006 Table 2 - FC-AE-ASM Header Format Bytes 0 1 2 3 0-3 Message ID 4-7 Reserved - Security 8-11 Re

47、served12-15 L Priority Message Payload Length (Bytes) Bytes 0 through 3 are the Message ID field. The Message ID field contains a 32-bit pattern that uniquely identifies the message within each system. No other information is required, other than the message ID, for a recipient to properly interpret

48、 a message. The Message ID values of hex 00 00 00 00 and hex FF FF FF FF are reserved. The action to be taken if either of these values is received is beyond the scope of this technical report. Bytes 4 through 7 are reserved for implementation-dependent security information. When not used to carry security information, this field shall be set to hex 00 00 00 00. Bytes 8 through 11 are reserved, and shall be set to hex 00 00 00 00. Byte 12 contains an optional routing priority and message length modifier. The L field of byte 12 shall modify the meaning of hex 00 00 00 in the Message P