ANSI INCITS TR-41 AMD 1-2008 INCITS Technical Report for Information Technology C Fibre Channel C Avionics Environment C Anonymous Subscriber Messaging C Amendment 1 (FC-AE-ASM AM1.pdf

《ANSI INCITS TR-41 AMD 1-2008 INCITS Technical Report for Information Technology C Fibre Channel C Avionics Environment C Anonymous Subscriber Messaging C Amendment 1 (FC-AE-ASM AM1.pdf》由会员分享，可在线阅读，更多相关《ANSI INCITS TR-41 AMD 1-2008 INCITS Technical Report for Information Technology C Fibre Channel C Avionics Environment C Anonymous Subscriber Messaging C Amendment 1 (FC-AE-ASM AM1.pdf（25页珍藏版）》请在麦多课文档分享上搜索。

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

2、TR-41:2006/AM1-2008 (R2016)INCITS TR-41-2006/AM1-2008Amendment toINCITS TR-41-2006INCITS Technical Reportfor Information Technology Fibre Channel Avionics Environment Anonymous Subscriber Messaging Amendment 1(FC-AE-ASM/AM1)SecretariatInformation Technology Industry CouncilAbstractThis technical rep

3、ort defines a set of features necessary to implement a real-time Fibre Channel network(switched fabric or arbitrated loop) supporting the FC-AE-ASM/AM1 Upper Level Protocol. Any devicecomplying with this report should interoperate with other devices that comply with this technical report.The FC-AE-A

4、SM/AM1 was first defined in the FC-AE technical report, INCITS TR-31-2002. It was thenupdated in FC-AE-ASM technical report, INCITS TR-41-2006. This technical report is an update to FC-AE-ASM.Reaffirmed as INCITS/TR-41:2006/AM1-2008 (R2016)Published byAmerican National Standards Institute25 West 43r

5、d Street, New York, New York 10036Copyright 2008 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 of the publisher.Printed in the United State

6、s 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), 1250 Eye Street, NW, Suite200, Washington,

7、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 Reports are produced in some cases to disse

8、minate 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 develop a rigorous standard due to the exis

9、tence 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 the draft Technical Report is completed, the

10、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 required for the implementation of the standard,

11、 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 and following calls for theidentification of

12、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 implied that licenses are not required toavoi

13、d infringement in the use of this Technical Report.Reaffirmed as INCITS/TR-41:2006/AM1-2008 (R2016)Contents 1. 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 Definitions3 3.2.1 Anonymous Subscriber

14、 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/AM1 Features.6 4.1 Overview6 4.2 FC-AE-ASM/AM1 Protocol 6 4.2.1 Overview .6 4.2.2 ASM Hea

15、der .6 4.3 FC-AE-ASM/AM1 Profile .8 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.11 4.3.6 Topology Support11 i Reaffirmed as INCITS/TR-41:2006/AM1-2008 (R2016)INCITS TR-41-2006/AM1-2008 Tables Table 1. Summary of implement

16、ation and use of features .5 Table 2. Legend 5 Table 3. FC-AE-ASM/AM1 Header Format.7 Table 4. Definition of the L field.7 Table 5. FC-FS-2 and FC-AL-2 Features for FC-AE-ASM/AM1.8 ii Reaffirmed as INCITS/TR-41:2006/AM1-2008 (R2016)Foreword (This foreword is not part of American National Standard IN

17、CITS TR-41-2006/AM1-2008.)The original Fibre Channel 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 working group determ

18、ined that it was best to allow protocols and profilesdefined in FC-AE to be updated independently. The Fibre Channel Anonymous Sub-scriber Messaging (FC-AE-ASM) technical report, INCITS TR-41-2006, was the firstupdate to FC-AE-ASM since FC-AE was released. This technical report is an updateto INCITS

19、 TR-41-2006. This technical report is recommended for new designs butdoes not obsolete 4.1 of INCITS TR-31-2002 or INCITS TR-41-2006.This technical report amendment was developed by Technical Committee T11 of Ac-credited Standards Committee INCITS during 2007-2008. The final approval processstarted

20、in 2008.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 app

21、roved 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 approved this technical report, INCITS had thefollowing m

22、embers:Karen Higginbottom, ChairJennifer Garner, SecretaryOrganization Represented Name of RepresentativeAdobe Systems, Inc. Steve ZillesScott Foshee (Alt.)AIM Global, Inc. Dan MullenCharles Biss (Alt.)Apple Computer, Inc. Kwok LauHelene Workman (Alt.)David Singer (Alt.)Distributed Management Task F

23、orce . Tony DiCenzoElectronic Industries Alliance . Edward Mikoski, Jr.EMC Corporation Gary RobinsonFarance, Inc. Frank FaranceTimothy Schoechle (Alt.)Google Zaheda BhoratRobert Tai (Alt.)GS1 US Ray DelnickiFrank Sharkey (Alt.)James Chronowski (Alt.)Mary Wilson (Alt.)Hewlett-Packard Company. Karen H

24、igginbottomSteve Mills (Alt.)Scott Jameson (Alt.)IBM Corporation . Ronald F. SillettiRobert Weir (Alt.)IEEE . Judith GormanTerry DeCourcelle (Alt.)Bill Ash (Alt.)Jodi Haasz (Alt.)Bob Labelle (Alt.)Susan Tatiner (Alt.)iiiReaffirmed as INCITS/TR-41:2006/AM1-2008 (R2016)Organization Represented Name of

25、 RepresentativeIntel .Philip WennblomDave Thewlis (Alt.)Grace Wei (Alt.)Lexmark InternationalDon WrightDwight Lewis (Alt.)Paul Menard (Alt.)Microsoft CorporationJim HughesDave Welsh (Alt.)Isabelle Valet-Harper (Alt.)National Institute of Standards equivalent to the phrase “it is strongly recommended

26、”. 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 applicable shall be set as required by the appropriate technical report. In several tables within this document, there is a column on the ri

27、ght side of the table 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: text (highest), tables and figures (lowest). 3 Reaffirmed a

28、s INCITS/TR-41:2006/AM1-2008 (R2016)INCITS TR-41-2006/AM1-2008 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, the binary value is enclosed in single quotation marks followed by th

29、e 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 done, the value is enclosed in single quotation marks and preceded by th

30、e 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. 3.4 Abbreviations and acronyms Abbreviations and acronyms applicable to this technical report are listed below. Abbreviations and acronyms f

31、or commonly used terms defined in referenced standards are not listed here. FC-AE-ASM/AM1 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 defin

32、itions 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. Each Required featu

33、re will include a note that describes the condition(s) in which the feature must 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 t

34、han 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 implementations. Compliant

35、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 compliant implementatio

36、ns. This document does not Prohibit the implementation of features, only their use between compliant implementations. However, interoperability is not guaranteed if Prohibited features are used. A summary of the terms with respect to implementation and use of features is specified in Table 1. 4 Reaf

37、firmed as INCITS/TR-41:2006/AM1-2008 (R2016)INCITS TR-41-2006/AM1-2008 Table 1. Summary of implementation and use of features Term Implementation Use Required Shall Shall Invocable Shall May Allowed May May Prohibited May Shall Not The tables in clause 4 list features described in the various Fibre

38、Channel standards and technical reports. These tables indicate whether the features are Required, Prohibited, Invocable, 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

39、 do not affect the interoperability of FC-AE-ASM/AM1 devices. Table 2 gives the table entries used. Table 2. Legend 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

40、 meaningful 5 Reaffirmed as INCITS/TR-41:2006/AM1-2008 (R2016)INCITS TR-41-2006/AM1-2008 4. FC-AE-ASM/AM1 Features 4.1 Overview This technical report is a protocol and profile document. It lists features described in the Fibre Channel Framing and Signaling-2 (FC-FS-2), Fibre Channel Link Services (F

41、C-LS), and Fibre Channel Arbitrated Loop-2 (FC-AL-2) standards and indicates whether the features are Required, Prohibited, Allowed, or Invocable. This FC-AE-ASM/AM1 technical report follows the FC-FS-2 and FC-AL-2 standards in its definition of the services necessary to support deterministic, secur

42、e, low-latency and low overhead communication elements of a mission-critical avionics system. FC-AE-ASM/AM1 fields must be easily mapped to other physical transports. Therefore, in accordance with that philosophy no FC-AE-ASM/AM1 fields may be mapped to Fibre Channel unique framing fields without al

43、so appearing in the appropriate FC-AE-ASM/AM1 header field (i.e., all FC-AE-ASM/AM1 fields are mapped into the payload). 4.2 FC-AE-ASM/AM1 Protocol 4.2.1 Overview Every message in FC-AE-ASM/AM1 is originated in a single Sequence unidirectional Exchange. The recipient may be expecting the message to

44、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 (i.e., Routing Bits hex 0 and Information Category hex 4). A single message originating from multiple so

45、urces 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 of each sequence shall be set to 0. Relative Offse

46、t 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: (a) Bit 17 Priority Enable Priority Enable shall be asserted on each frame of

47、an ASM Sequence when Priority is required (b) 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. ELS Frames are not considered ASM Frames.

48、 ELS Frames shall conform to the rules specified in FC-FS-2 and FC-LS. 4.2.2 ASM Header The first four words of the Payload of each FC-AE-ASM/AM1 Frame are reserved for the FC-AE-ASM/AM1 header. In multi-frame Sequences, all Frames shall contain a copy of the FC-AE-ASM/AM1 header. The format of the

49、FC-AE-ASM/AM1 header is specified in Table 3. The ASM Header shall have the same content in each frame in a multi-frame Sequence. 6 Reaffirmed as INCITS/TR-41:2006/AM1-2008 (R2016)INCITS TR-41-2006/AM1-2008 Table 3. FC-AE-ASM/AM1 Header Format Bits Word (Bytes) 31 24 23 16 16 08 07 00 0 (0-3) Message ID 1 (4-7) Vendor Specific - Security 2 (8-11) Reserved 3 (12-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 uniquel