01-238v4 fc-ae profile v2 4 - 012602...

Copies of this document may be purchased from: TR-NCITS.xxx-200x Global Engineering, 15 Inverness Way East, T11/Project 2009-DT/Rev2.2Englewood, CO 80112-5704 Phone: (800) 854-7179 or (303) 793-2181 Fax: (303) 792-2192 T11/01-238v6

NCITS working draft proposed Technical Report

January 17, 2002

Secretariat: Information Technology Industry Council NOTE: This is a working draft American National Standard of Accredited Standards Committee NCITS. As such this is not a completed standard. The T11 Technical Committee or anyone else may modify this document as a result of comments received anytime, or during a future public review and its eventual approval as a Standard. Use of the information contained herein is at your own risk. Permission is granted to members of NCITS, its technical committees, and their associated task groups to reproduce this document for the purposes of NCITS standardization activities without further permission, provided this notice is included. All other rights are reserved. Any duplication of this document for commercial or for-profit use is strictly Prohibited. POINTS OF CONTACT: Kumar Malvalli (T11 Chairman) Brocade Communications 1901 Guadalupe Parkway San Jose, CA 95131 Phone: (408) 487-8156 Fax: (408) 524-8601 E-Mail: [email protected]

Ed Grivna (T11 Vice Chairman) Cypress Semiconductor 2401 East 86th Street Bloomington, MN 55425 (612) 851-5046 Fax: (612) 851-5087 E-Mail: [email protected]

Craig Carlson (TG T11.3 Chairman) Qlogic 6321 Bury Drive Eden Prairie, MN 55346 (952) 932-4064 Fax: (952) 932-4037 E-Mail: [email protected]

Michael S. Foster (FC-AE Chairman) Boeing P.O. Box 3999, M/S 5X-34 Seattle, WA 98124 (253) 931-2613 Fax: (253) 931-6585 E-Mail: [email protected]

FIBRE CHANNEL

AVIONICS ENVIRONMENT (FC-AE)

REV 2.4

Release Notes for Version 2.0 Draft release for Letter Ballot comments.

TR-NCITS.xxx-200x Avionics Environment Profiles Rev 2.4 January 17, 2002

ANSI® TR-NCITS.xxx-200x

draft proposed NCITS Technical Report

Fibre Channel – Avionics Environment (FC-AE)

Secretariat Information Technology Industry Council

Approved , 200x American National Standards Institute, Inc.

Abstract

This report selects and restricts logical options from the Fibre Channel Framing and Signaling, Fibre Channel Arbitrated Loop, Fibre Channel Switch, and Fibre Channel Generic Services standards, such that any device complying with this report should interoperate. This report addresses requirements for switches and loops to support real time avionics applications.

NCITS Technical Report Series

This Technical Report is one in a series produced by the American National Standards Committee, NCITS, Information Technology. The secretariat for NCITS is held by the Information Technology Industry Council (ITI), 1250 Eye Street, NW Suite 200, Washington DC 20005.

As a by-product of the standards development process and the resources of knowledge devoted to it, NCITS from time to time produces Technical Reports. Such Technical Reports are not standards, nor are they intended to be used as such.


NCITS Technical Reports are produced in some cases to disseminate the technical and logical concepts reflected in standards already published or under development. In other cases, they derive from studies in areas where it is found premature to develop a rigorous standard due to the existence of a number of viable options, the choice of which depends on the user’s particular requirements. These Technical Reports, thus, provide guidelines, the use of which can result in greater consistency and coherence of information processing systems.

When the draft Technical Report is completed, the Technical Committee approval process is the same as for a draft standard. Processing by NCITS is also similar to that for a draft standard.

PATENT STATEMENT

CAUTION: The developers of this Technical Report have requested that holder’s of patents that may be required for the implementation of the Technical Report, 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 Technical Report.

As of the date of publication of this Technical Report and following calls for the identification of patents that may be required for the implementation of the Technical Report, no such claims have been made. No further patent search is conducted by the developer or the publisher in respect to any Technical Report it processes. No representation is made or implied that licenses are not required to avoid infringement in the use of this Technical Report.

Published by American National Standards Institute 11 W. 42nd Street, New York, New York 10036 Copyright © 200x 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


Please read the definitions of Required, Invocable, Allowed, and Prohibited in clause 3.4

v

Contents 1. Introduction ....................................................................................................................................1 2. Normative References .....................................................................................................................1

2.1 Approved references ..................................................................................................................2 2.2 References under development ..................................................................................................2 2.3 Other references ........................................................................................................................2

3. Definitions and conventions .............................................................................................................3 3.1 Definitions .................................................................................................................................3

3.1.1 Implicit LIP ..........................................................................................................................3 3.1.2 Anonymous Subscriber Messaging (ASM).............................................................................3 3.1.3 Fibre Channel Lightweight Protocol (FCLP)...........................................................................3 3.1.4 Remote Direct Memory Access (RDMA)................................................................................3 3.1.5 Network Controller (NC).......................................................................................................3 3.1.6 Network Terminal (NT) .........................................................................................................3 3.1.7 Command Frame.................................................................................................................3 3.1.8 Data Frames .......................................................................................................................3 3.1.9 Status Frame.......................................................................................................................3 3.1.10 Bus Identifier (B_ID)...........................................................................................................3 3.1.11 Others ...............................................................................................................................3

3.2 Editorial conventions ..................................................................................................................4 3.2.1 Binary notation ....................................................................................................................4 3.2.2 Hexadecimal notation ..........................................................................................................4

3.3 Abbreviations and acronyms.......................................................................................................4 3.3.1 Acronyms and abbreviations ................................................................................................4

3.4 Applicability and use of this document .........................................................................................5 4. Profiles ...........................................................................................................................................7

4.1 Scope .......................................................................................................................................7 4.2 Anonymous Subscriber Messaging (ASM) ...................................................................................7

4.2.1 ASM Basic Services.............................................................................................................7 4.2.1.1 Link Protocols..............................................................................................................12 4.2.1.2 Arbitrated Loop............................................................................................................12 4.2.1.3 Addressing ..................................................................................................................14 4.2.1.4 Class 1 .......................................................................................................................14 4.2.1.5 Class 2 .......................................................................................................................14 4.2.1.6 Class 3 .......................................................................................................................14 4.2.1.7 Class 4 .......................................................................................................................14 4.2.1.8 Class 6 .......................................................................................................................14



vi

4.2.1.9 Priority ........................................................................................................................15 4.2.1.10 TYPE Field ................................................................................................................15 4.2.1.11 R_CTL Field..............................................................................................................15 4.2.1.12 F_CTL ......................................................................................................................15 4.2.1.13 SEQ_ID ....................................................................................................................15 4.2.1.14 DF_CTL ....................................................................................................................15 4.2.1.15 X_ID Interlock............................................................................................................15 4.2.1.16 Basic Link Services ....................................................................................................15 4.2.1.17 Extended Link Services ..............................................................................................15 4.2.1.18 Fabric Login ..............................................................................................................16 4.2.1.19 N_Port Login/Logout ..................................................................................................16 4.2.1.20 Hunt Groups ..............................................................................................................16 4.2.1.21 Clock Synchronization................................................................................................16

4.2.2 ASM Structure and Concepts .............................................................................................16 4.2.2.1 Payload Structure........................................................................................................16

4.3 MIL-STD-1553.........................................................................................................................18 4.3.1 Scope ...............................................................................................................................18

4.3.1.1 Introduction .................................................................................................................18 18181818181818181818181818181818184.3.1.2 Mapping legacy 1553 applications to FC-AE-1553

..............................................................................................................................................19 4.3.2 FC-AE-1553 ULP Features ................................................................................................20

4.3.2.1 Information Units .........................................................................................................20 4.3.2.2 Exchange (Message) Formats......................................................................................23

4.3.3 MIL-STD-1553 ULP Profile .................................................................................................28 4.3.4 MIL-STD-1553 ULP Mapping to FC-AE-1553 ......................................................................32

4.3.4.1 MIL-STD-1553 Command Word Mapping to FC-AE-1553....................................32323232 4.3.4.2 R_CTL: .......................................................................................................................32 4.3.4.3 Destination Identifier (D_ID) .........................................................................................33 4.3.4.4 Source Identifier (S_ID)................................................................................................33 4.3.4.5 TYPE Field..................................................................................................................33 4.3.4.6 NT-to-NT.....................................................................................................................33 4.3.4.7 NC Monitor for NT-to-NT Transfers ...............................................................................33 4.3.4.8 T/R* ............................................................................................................................33 4.3.4.9 Transmitting or Receiving NT Address for NT-to-NT Transfers........................................33 4.3.4.10 Subaddress / Mode....................................................................................................34 4.3.4.11 Data Word Count / Mode Code ...................................................................................34 4.3.4.12 1553 Bus Select Enable .............................................................................................34



vii

4.3.4.13 1553 Bus B/A*...........................................................................................................35 4.3.4.14 RT Address for MIL-STD-1553 RT..............................................................................35 4.3.4.15 FC-AE-1553 Mode Codes ..........................................................................................35 4.3.4.16 MIL-STD-1553B Status Word Mapping to FC-AE-1553 ................................................37 4.3.4.17 MIL-STD-1553 RT Addresses .....................................................................................39 4.3.4.18 No Response by MIL-STD-1553 RT (bit 6 of Status Frame Header Word 9) ..................39 4.3.4.19 1553 RT Format Error (bit 5 of Status Frame Header Word 9) ......................................40

4.3.5 FC-FS and FC-AL-2 Features for FC-AE-1553 ....................................................................40 4040404.3.5.1 Fabric-Specific Features .............................................................................................44

4.3.5.2 Arbitrated Loop-Specific Features .................................................................................45 4.3.5.3 N_Port Login ...............................................................................................................46 4.3.5.4 FC-FS Header Fields ...................................................................................................47 4.3.5.5 Fabric Reject/Fabric Busy ............................................................................................48 4.3.5.6 Port Reject/Port Busy...................................................................................................48 4.3.5.7 Basic Link Services ......................................................................................................48 4.3.5.8 Extended Link Services ................................................................................................48 4.3.5.9 Well Known Address Support .......................................................................................49

4.4 Virtual Interface (VI) .................................................................................................................50 4.4.1 FC-VI Features for FC-AE-VI..............................................................................................50

4.4.1.1 Connection Models ......................................................................................................51 4.4.1.2 Transfer Models ..........................................................................................................51 4.4.1.3 FCVI_Attributes ...........................................................................................................51 4.4.1.4 FCVI_Addressing ........................................................................................................52

4.4.2 FC-FS and FC-AL2 Features for FC-AE-VI..........................................................................52 4.4.2.1 Link Protocols..............................................................................................................58 4.4.2.2 Arbitrated Loop............................................................................................................58 4.4.2.3 Fabric Login ................................................................................................................59 4.4.2.4 N_Port Login ...............................................................................................................60 4.4.2.5 Fabric Reject/Fabric Busy ............................................................................................61 4.4.2.6 Port Reject/Port Busy...................................................................................................61 4.4.2.7 Well Known Address Support .......................................................................................61 4.4.2.8 Basic Link Services ......................................................................................................62 4.4.2.9 Extended Link Services ................................................................................................62

4.5 Fibre Channel Lightweight Protocol (FCLP)...............................................................................63 4.5.1 FC-AE-FCLP Command Primitives .....................................................................................63

4.5.1.1 Setup Channel Command ............................................................................................63 4.5.1.2 Setup Channel Acknowledgement ................................................................................64



viii

4.5.1.3 Send Data Command ..................................................................................................64 4.5.1.4 Close Channel Command ............................................................................................65 4.5.1.5 Return APIDs Command ..............................................................................................65

4.5.2 FCP Features for FC-AE-FCLP ..........................................................................................65 4.5.2.1 Process Login Service Parameters ...............................................................................67 4.5.2.2 Process Login Service Response Parameters ...............................................................67 4.5.2.3 FCP Command IU .......................................................................................................68 4.5.2.4 FCP Transfer Ready IU................................................................................................68 4.5.2.5 FCP Data IU................................................................................................................68 4.5.2.6 FCP Response IU........................................................................................................68

4.5.3 FC-FS and FC-AL2 Features for FC-AE-FCLP ....................................................................69 4.5.3.1 Link Protocols..............................................................................................................74 4.5.3.2 Arbitrated Loop............................................................................................................74 4.5.3.3 Fabric Login ................................................................................................................75 4.5.3.4 N_Port Login ...............................................................................................................75 4.5.3.5 Well Known Address Support .......................................................................................76 4.5.3.6 Basic Link Services ......................................................................................................76 4.5.3.7 Extended Link Services ................................................................................................76

4.6 Remote Direct Memory Access (RDMA)....................................................................................77 4.6.1 RDMA Enhancement to FCP ..............................................................................................77 4.6.2 FCP Features for FC-AE-RDMA .........................................................................................77

4.6.2.1 Process Login Service Parameters ...............................................................................79 4.6.2.2 FCP Command IU .......................................................................................................80 4.6.2.3 FCP Transfer Ready IU................................................................................................80 4.6.2.4 FCP Data IU................................................................................................................80 4.6.2.5 FCP Response IU........................................................................................................80

4.6.3 FC-FS and FC-AL2 Features for FC-AE-RDMA ...................................................................82 4.6.3.1 Link Protocols..............................................................................................................88 4.6.3.2 Arbitrated Loop............................................................................................................88 4.6.3.3 Fabric Login ................................................................................................................89 4.6.3.4 N_Port Login ...............................................................................................................90 4.6.3.5 Fabric Reject/Fabric Busy ............................................................................................91 4.6.3.6 Port Reject/Port Busy...................................................................................................91 4.6.3.7 Well Known Address Support .......................................................................................91 4.6.3.8 Basic Link Services ......................................................................................................91 4.6.3.9 Extended Link Services ................................................................................................91

Annex A ...........................................................................................................................................93



ix

Bridging from FC-AE-1553 Networks to MIL-STD-1553 Buses ......................................................... 9393 Figures Figure 1 ASM Header Format ............................................................................................................17 Figure 2. Network Controller To Network Terminal .............................................................................23 Figure 3. Network Terminal-to-Network Controller ...............................................................................23 Figure 4 NT to NT Transfers .............................................................................................................24 Figure 5. Mode Command without Data Word.....................................................................................25 Figure 6. Transmit Mode Command with Data Word ..........................................................................25 Figure 7. Receive Mode Command with Data Word ............................................................................26 Figure 8. Controller to Multiple Remote Terminals...............................................................................26 Figure 9. Network Terminal to Multiple Network Terminals..................................................................27 Figure 10. Transmit Mode Command without Data Word to Multiple Network Terminals ........................27 Figure 11. Receive Mode Command with Data Word to Multiple Network Terminals.............................28 Figure A.19. FC-AE-1553 Network to MIL-STD-1553 Bus Bridge ........................................................93 Tables Table 1 Summary of Implementation and Use of Features .....................................................................5 Table 3 FC-FS and FC-AL-2 Features for FC-AE-ASM..........................................................................7 Table 5. Terminology Equivalents between MIL-STD-1553 and FC-AE-1553 ........................................18 Table 6. Comparison of MIL-STD-1553 and FC-AE-1553 Command Field Sizes...................................19 Table 7. Information Units Initiated from the Network Controller to Network Terminal ............................20 Table 8. Information Units Initiated from the Network Terminal............................................................22 Table 9. MIL-STD-1553B Notice 2 Profile for FC-AE-1553 ..................................................................28 Table 10. FC-AE-1553 Command Frame Header................................................................................32 Table 11. FC-AE-1553 Status Frame Header.....................................................................................38 Table 12. FC-FS Features for FC-AE-1553.........................................................................................40 Table 20 FCLP Command Codes ......................................................................................................63 Table 21 FCP Features for FC-AE-FCLP ............................................................................................65 Table 22 FC-FS and FC-AL2 Features for FC-AE-FCLP......................................................................69 Table 23 RDMA Parameter Field Usage – Command IU .....................................................................77 Table 24 FCP Features for FC-AE-RDMA ..........................................................................................78 Table 25 FC-FS and FC-AL2 Features for FC-AE-RDMA ....................................................................82



1

Draft proposed NCITS Technical Report TR-NCITS.xxx-200x

Draft proposed NCITS Technical Report for Information Technology

Fibre Channel – Avionics Environment (FC-AE)

1. Introduction

The Fibre Channel Avionics Environment profiles (FC-AE) are a group of profiles which specify Fibre Channel options for devices connected by fabric and/or loop Fibre Channel topologies which are pertinent to their use in the commercial and military aerospace industries. The primary areas of interest include avionic command, control, instrumentation, simulation, signal processing, and sensor/video data distribution. These application areas are characterized by a variety of requirements, among them a need for high reliability, fault tolerance, and deterministic behavior to support real-time control/response. This report is intended to serve as an implementation guide whose primary objective is to maximize the likelihood of interoperability between conforming implementations. This report prohibits or requires features that are optional, and prohibits the use of some non-optional features in the referenced ANSI standards. A second objective of this Technical Report is to simplify implementations and their associated docu-mentation, testing, and support requirements. This means that there will be some optional features, which are not mutually exclusive but are still prohibited or required solely for the purpose of this simplification. This Technical Report does not define internal characteristics of conformant implementations. This Technical Report incorporates features from the standards described below. Where needed, changes have been proposed to the appropriate NCITS technical committees to ensure this Technical Report remains a strict subset of ANSI standards.

2. Normative References

The following standards contain provisions, which through reference in the text, constitute provisions of this Technical Report. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Technical Report 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), and approved foreign standards (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.

Additional availability contact information is provided below as needed.



2

2.1 Approved references

[1] ANSI X3.230 – 1994, Information Technology – Fibre Channel Physical and Signaling Interface (FC-PH)

[2] ANSI X3.297 – 1997, Information Technology – Fibre Channel Physical and Signaling Interface – 2 (FC-PH-2)

[3] ANSI X3.303 – 1998, Information Technology – Fibre Channel – Physical and Signaling Interface – 3 (FC-PH-3)

[4] ANSI X3.272 – 1996, Information Technology – Fibre Channel Arbitrated Loop (FC-AL)

[5] NCITS.332 - 1999, Information Technology – Fibre Channel Arbitrated Loop - 2 (FC-AL-2)

[6] ANSI X3.289 – 1996, Information Technology – Fibre Channel Fabric Generic (FC-FG)

[7] NCITS 348, Information Technology – Fibre Channel Generic Services - 3 (FC-GS-3)

[8] ANSI X3.269 – 1996, Information Technology – Fibre Channel Protocol for SCSI (FCP)

[9] MIL-STD-1553B Military Standard, Digital Time Division Command/Response Multiplex Data Bus Notice 2, 8 September 1986

2.2 References under development

At the time of publication, the following referenced standards were still under development. For infor-mation on the current status of the document, or regarding availability, contact the relevant standards body or other organization as indicated.

NOTE - For more information on the current status of a document, contact NCITS at the address listed in the front. To obtain copies of this document, contact Global Engineering at the address listed in the front, or NCITS.

[10] NCITS X3.xxx – 200x, Fibre Channel – Framing and Signaling Interface (FC-FS), T11/Project 1331D/Rev 1.2

[11] NCITS X3.xxx – 200x, Fibre Channel – Virtual Interface (FC-VI), T11/Project 1332D/Rev 1.84

2.3 Other references



3

3. Definitions and conventions

For FC-AE, the following definitions, conventions, abbreviations, acronyms, and symbols apply.

3.1 Definitions

The following definitions apply to this standard; words used that are defined in referenced standards shall use that definition; and, words not defined here or in the referenced standards shall have the standard technical English meaning.

3.1.1 Implicit LIP

A method of defining and specifying the AL_PA and optional Position Map of L_Ports by means other than the explicit use of the Loop Initialization Procedure defined in FC-AL-2 [5]. Specific methods of implicit LIP are not defined in this Technical Report.

3.1.2 Anonymous Subscriber Messaging (ASM)

A deterministic, secure, low-latency communication protocol derived only from FC-FS constructs. The Type code is hex ’49’.

3.1.3 Fibre Channel Lightweight Protocol (FCLP)

A low-latency, low overhead communication protocol based on FCP. FCLP uses the standard FCP protocol mapping with vendor-specific command codes. See <4.5>

3.1.4 Remote Direct Memory Access (RDMA)

A low-latency, low overhead communication protocol based on FCP. RDMA has certain enhancements over FCP intended for low latency, real-time applications. See <4.6>.

3.1.5 Network Controller (NC)

A Fibre Channel Node that transmits FC-AE-1553 Command Frames (akin to a Bus Controller or BC in MIL-STD-1553).

3.1.6 Network Terminal (NT)

A Fibre Channel Node that responds to commands issued by the Network Controller (NC) using FC-AE-1553 protocol. (akin to the Remote Terminal or RT in MIL-STD-1553)

3.1.7 Command Frame

A FC-AE-1553 Fibre Channel frame that is always the first frame of any FC-AE-1553 exchange and is always issued by a Network Controller (NC). Command Frames always have the Information Category bits in the R_CTL field set to 0110’b

3.1.8 Data Frames

A FC-AE-1553 Fibre Channel frame that is sent by either an NT or NC. Data Frames always have the Information Category bits in the R_CTL field set to 0100’b

3.1.9 Status Frame

A FC-AE-1553 Fibre Channel frame that is always the first frame transmitted by an FC-AE-1553 NT. Status Frames always have the Information Category bits in the R_CTL field set to 0111’b

3.1.10 Bus Identifier (B_ID)

A 7-bit FC-AE-1553 address field that is used to define a group of up to 31 Remote Terminals that function as a legacy MIL-STD-1553 bus

3.1.11 Others



4

3.2 Editorial conventions

In this Technical Report, a number of conditions, mechanisms, sequences, parameters, events, states, or similar terms that do not have their normal English meaning are printed with the following conventions:

2. The first letter of each word in uppercase and the rest lowercase (e.g., Exchange, Class, etc.). 3. A term consisting of multiple words, with the first letter of each word in uppercase and the rest

lowercase, and each word separated from the other by an underscore (_) character. A word may consist of an acronym or abbreviation, which would be printed in uppercase. (e.g., NL_Port, Transfer_Length, etc.).

All terms and words not conforming to the conventions noted above have the normal technical English meanings. Numbered items in this Technical Report do not represent any priority. Any priority is explicitly indicated. In all of the figures, tables, and text of this standard, the most significant bit of a binary quantity is shown on the left side. Exceptions to this convention are indicated in the appropriate sections. The term “shall” is used to indicate a mandatory rule. If such a rule is not followed, the results are un-predictable unless indicated otherwise. The fields or control bits that are not applicable shall be set as required by the appropriate standard. 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 table labelled “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, tables, and figures.

3.2.1 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 fol lowed by the letter b. For example, a four-byte field containing a binary value may be represented as ‘00000000 11111111 10011000 11111010’b.

3.2.2 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 ‘00000000 11111111 10011000 11111010’b is shown in hexadecimal format as hex ’00 FF 98 FA’.

3.3 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 (e.g., LIP is defined in FC-AL).

3.3.1 Acronyms and abbreviations

ASM Anonymous Subscriber Messaging FCLP Fibre Channel Lightweight Protocol RDMA Remote Direct Memory Access FC-AE-1553 The mnemonic used to define the FC-AE 1553 profile



5

FC-AE-ASM The mnemonic used to define the FC-AE AMS profile FC-AE-FCLP The mnemonic used to define the FC-AE FCLP profile FC-AE-RDMA The mnemonic used to define the FC-AE RDMA profile FC-AE-VI The mnemonic used to define the FC-AE VI profile NC NC1 – NC7 NT NT1 – NT8 NT_ID NT_SA

3.4 Applicability and use of this document

Since the nature of this document is a profile, 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 that it shall be used between compliant implementations. Compliant implementations are required to implement the feature. An implementation may use the feature or other features to communicate with non-compliant implementations. 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 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 invoke the feature if needed, but is not required to invoke 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 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 implemen-tations. An implementation may use the feature to communicate with non-compliant implementations. This document does not prohibit the implementation of features, only their use between compliant im-plementations. 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

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 standards specific to the op-erations described in the clause. These tables indicate whether the feature is Required, Prohibited, Invocable, or Allowed for compliance with this report; or whether a parameter is Required to be a par-



6

ticular value for compliance with this report. Features or parameters that are not listed do not affect the interoperability of FC-AE devices.

The following legend is used for table entries in these 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



7

4. Profiles

4.1 Scope

This clause defines five profiles each of which defines a set of interoperable features necessary to implement a real-time Fibre Channel network supporting one or more Upper Level Protocols (ULPs) and topologies. The tables in each profile list features described in the Fibre Channel Framing and Signaling standard (FC-FS) and Fibre Channel Arbitrated Loop standard (FC-AL-2), specific to the operation of N_Ports, F_Ports, and fabric controllers. These tables indicate whether the feature is Required, Prohibited, Allowed, or Invocable for compliance with a specific profile.

Profiles defined in this technical report are: Anonymous Subscriber Messaging (ASM, clause 4.2), MIL-STD-1553 Upper Layer Protocol (clause 4.3), Virtual Interface (VI, clause 4.4), Fibre Channel Lightweight Protocol (FCLP, clause 4.5) and Remote Direct Memory Access (RDMA, clause 4.6). Each profile enables the implementation of an interoperable network capable of supporting the requirements of differing avionics systems, with some amount of overlap.

4.2 Anonymous Subscriber Messaging (ASM)

This FC-AE profile follows the FC-FS and FC-AL-2 standards in its definition of the services necessary to support deterministic, secure, low-latency communication between processors, sensors, instrumentation, and displays in mission-critical avionics applications. The mnemonic used to define this profile shall be FC-AE-ASM.

4.2.1 ASM Basic Services

Table 3 is a profile of the FC—FS and FC-AL-2 standards for fabric and arbitrated loop topologies. Devices that are compliant with FC-AE-ASM must comply with the mandatory features defined in FC-FS and FC-AL-2, unless noted herein. Table 3 identifies optional features that represent potential interoperability concerns and indicates whether they are Required, Invocable, Allowed, or Prohibited for FC-AE-ASM compliance. Features that are not listed do not affect interoperability of FC-AE-ASM devices. In addition to interoperability concerns, this profile addresses certain features that are needed in order to achieve the performance necessary for real-time mission critical systems. More information is provided after the table. Items that are clearly defined in FC-FS or FC-AL-2 are not restated here. In many cases, the features specified in Table 3 have Login Parameters associated with them. For features that are Required or Invocable, the corresponding login parameters shall indicate that the feature is supported. For features that are Prohibited, the corresponding login parameters may indicate that the feature is supported, even though the feature will not be used by compliant implementations. For features that are Allowed, the corresponding login parameters shall reflect whether or not the feature is supported by the implementation.

Table 3 FC-FS and FC-AL-2 Features for FC-AE-ASM

ASM Features Nx_Port Fx_Port Notes

Link Protocols

Link Initialization R R

Online to Offline to Online A A



8


Link Failure R R

Link Reset R R

Loop Port State Machine (LPSM) A A

Loop Protocols

Loop Initialization I I

Loop Port Bypass I I

Loop Port Enable I I

Loop Port Bypass Circuit A A Optional circuit

Loop Port Positional Mapping I I

Dynamic Half-Duplex A A

Broadcast Open Replicate – OPN(fr) I I

Old Port State I I

Request Old Port State - REQ(Old-Port) I I

Addressing

Alias Addressing A A

Others A A

Well Known Addresses

Fabric Controller - R An N_Port cannot be a Fabric Controller Per FC Standard

Time Server A A

Clock Synchronization Server I R

Class 1 A A

Stacked connect-requests A A

Acknowledgements



9


ACK_0 I I

ACK_1 A A

Preempt flag I I

Priority

127 Levels (7-Bits) A A

2 Levels (1-Bit) I I

Class 2 I I

Acknowledgements

ACK_0 I I

ACK_1 A A

BB_Credit minimum of 2 R R

Preempt flag I I

Priority



Class 3 I I

BB_Credit minimum of 2 R R

Class 3 single cast I I

Class 3 multicast A A

Class 3 broadcast I I

Preempt flag I I

Priority





10


Class 4 A A

Acknowledgements

ACK_0 I I

ACK_1 A A

Class 6 A A

Stacked connect-requests A A

Acknowledgements

ACK_0 I I

ACK_1 A A

Preempt flag A A

Priority



Intermix A A

TYPE field

TYPE Code hex ‘49’ R R

R_CTL

Routing Bits set to hex ‘0’ R A

Information Category set to hex ‘4’ R A

F_CTL

Priority Enable I I

X_ID reassigned A A

Invalidate X_ID A A

ACK_Form



11


No ACK Assist I -

ACK_0 I -

ACK_1 A -

Unidirectional Transmit (Class 1) or Remove Class 4 circuit (Class 4)

A A

Relative Offset Present, bit 3 is True I I

SEQ_ID

Streamed Sequences (Class 3) A A

Streamed Sequences (Class 2) A A

DF_CTL

DF_CTL has Hex value of ‘00’ R R

Parameter Field

Use of Relative Offset I I

X_ID Interlock A A

Basic Link Services

PRMT I I

Others A A

Basic Link Services in Unidirectional Connections

BA_ACC, BA_RJT A A

Extended Link Services

CSR I I

Others A A

Fabric Login

Explicit Login A A



12


Implicit Login I I

N_Port Login/Logout

Explicit Login A A

Implicit Login I I

Exchange Management

P_RJT if no Exchange resources available A -

Termination of Connection by Connection Initiator if no additional Sequences queued for transmission

A A

Hunt Groups A A

Clock Synchronization

ELS Signal Service I I

Primitive Signal Service A A

4.2.1.1 Link Protocols

Support of basic Link Initialization described in FC-FS is required and will be used at power up or upon re-initialization. Link Failure and Link Reset protocols must be implemented, and will be used as needed. Online-to-Offline protocol is Allowed but not required because typically an Offline state is not needed in avionics systems. The equipment will operate until power is removed.

4.2.1.2 Arbitrated Loop

This profile was written primarily for switched fabrics, which may include attached loops. Although there is no inherent restriction on the use of a Private loop with the FC-AE-ASM profile that topology is not addressed specifically. The Loop Port State Machine (LPSM) is Allowed. If the LPSM is implemented, then the port is an NL_Port or an FL_Port. Otherwise, the port is an N_Port or an F_Port. The items indented under LPSM are only applicable if the LPSM is implemented. Loop Initialization Protocol is Invocable (but not Required) because this enables the System Designer to implement a system using “Implicit LIP”. LIP must be implemented to insure interoperability with devices that only support “Explicit LIP”. If Implicit LIP is used it is up to the System Designer to figure out how to provide all the necessary information to the nodes. All NL_Ports shall support loop initialization if a loop master capable NL_Port becomes active on the loop. All NL_Ports shall support positional mapping and the use of Loop Initialization Report Position (LIRP) and Loop Initialization Loop Position (LILP) frames.



13

NOTE - In the interest of achieving faster start-up times, the use of Implicit LIP and Login are encouraged. If explicit LIP is used, it can be speeded up by not doing Loop Port Positional Mapping. Loop Port Positional Mapping is Allowed, but is generally not needed for embedded avionics systems.

NOTE - The use of a centralized hub may be desirable, depending on the number of nodes involved. A Hub provides a centralized location for wire routing and the ability to isolate faulty nodes or wiring without affecting the rest of the loop.

Loop Port Bypass and Loop Port Enable Primitive Sequences, which control access to the loop, are Invocable. The optional Bypass circuit is Allowed. Dynamic Half Duplex is Allowed and encouraged because it improves bandwidth utilization. Broadcast Open Replicate is Invocable. The capability to operate in OLD_PORT state is desirable in order for a 2-node pair to operate in point-to-point mode as opposed to operating as a 2-node loop. There are two ways to enter OLD_PORT state: 1) one node in the pair doesn’t support LPSM, or 2) both nodes support LPSM but OLD_PORT state is requested. The ability to request Old Port state is Invocable.



14

4.2.1.3 Addressing

All devices complying with this profile shall also reserve the well-known addresses defined in FC-FS: Devices complying with this profile may support Alias addressing.. This profile supports non-standard forms of alias address assignment.

4.2.1.4 Class 1

Class 1 service is Allowed. The following qualifications on Class 1 shall apply: § Connection request frames may be stacked.

§ ACK_0 acknowledge protocol shall be supported (Invocable). ACK_1 protocol may be used.

§ Connect request frames may be offered to the fabric with an associated priority.

§ Connect request frames may be preempt request frames as defined by FC-FS.

Support for Class 1 shall be negotiated at login.

4.2.1.5 Class 2

Class 2 service is Invocable. The following qualifications on Class 2 service shall apply: § All devices shall be required to support, as a minimum, a login BB_Credit of 2.

§ ACK 0 is Invocable, ACK 1 is Allowed.

§ Class 2 frames may be preempt request frames as defined by FC-FS.

§ Class 2 frames may be offered to the fabric with an associated priority.

4.2.1.6 Class 3

Class 3 service is Invocable. The following qualifications on Class 3 service shall apply: § All devices shall be required to support, as a minimum, a login BB_Credit of 2.

§ Class 3 singlecast is Invocable, multicast is Allowed, and broadcast is Invocable.

§ Class 3 frames may be preempt request frames as defined by FC-FS.

§ Class 3 frames may be offered to the fabric with an associated priority.

4.2.1.7 Class 4

Class 4 service is Allowed.

The following qualifications on Class 4 service shall apply: § ACK 0 is Invocable.

§ ACK 1 is Allowed.


4.2.1.8 Class 6

Class 6 services is Allowed. The following qualifications on Class 6 shall apply: § Connection request frames may be stacked.

§ ACK_0 acknowledge protocol shall be supported (Invocable). ACK_1 protocol may be used.

§ Connect request frames may be preempt request frames as defined by FC-FS.




15

4.2.1.9 Priority

For classes of service where priority is implemented priority shall be a 7-bit value placed in header Word 1, bits 30:24 (CS_CTL). All fabrics shall route frames in order of their priority, highest priority first when bit 17 in the F_CTL field is asserted. Priority proceeds in descending order from 127 as the highest level to 0 as the lowest. If implementing 2 priority levels only, priority level 1 (Word 1= 1) shall be the high priority and priority level 0 (Word 1 = 0) shall be the low priority. Frames where priority is not enabled (F_CTL field bit-17 not asserted) shall be treated as frames having a priority level of 0.

4.2.1.10 TYPE Field

Devices complying with this profile shall utilize TYPE code hex ‘49’.

4.2.1.11 R_CTL Field

Devices complying with this profile shall use hex ‘0’ (FC-4 Device Data) for the routing bits and hex ‘4’ (unsolicited data) for the information category fields. No other values in the R_CTL field shall be supported except as necessary for “Link Control” frames.

4.2.1.12 F_CTL

All devices complying with this profile shall support the following F_CTL options:

§ Bit 17 Priority Enable – Priority Enable may be asserted on any frame.

§ Bit 16 Sequence Initiative – Sequence Initiative transfer on the last Sequence of an Exchange shall be supported for ELS operations.

§ Bit 14 Invalidate X_ID – X_ID invalidation is Allowed and shall be negotiated at login.

§ Bits 13-12 ACK_Form – ACK 0 is Invocable and will be the default. ACK 1 is Allowed. No ACK Assistance is Invocable

§ Bits 5-4 Abort Sequence Condition –per FC-FS.

§ Bit 3 Relative Offset Present – is Invocable. The Parameter field shall hold the relative running offset of the data being transferred. The sequence recipient shall indicate support for relative offset, but is not required to use it to manage sequence order.

4.2.1.13 SEQ_ID

N_Ports complying with this profile are Allowed to used streamed Sequences for Class 3 and Class 2 Exchanges.

4.2.1.14 DF_CTL

All devices complying with this profile shall support DF_CTL value hex '00'.

4.2.1.15 X_ID Interlock

N_Ports complying with this profile may support X_ID interlock. Use of X_ID Interlock shall be negotiated at N_Port login.

4.2.1.16 Basic Link Services

The PRMT basic link service shall be supported (Invocable). All other basic link services are Allowed.

4.2.1.17 Extended Link Services

Clock Sync Request is Invocable. The Nx_Port is the Initiator. Note that CSR can be directed to the Clock Sync Server or the Fabric Controller. All other ELS commands are Allowed, but devices that receive requests for ELSs not supported shall return LS_RJT with the reason code “Invalid Command Code”.



16

4.2.1.18 Fabric Login

All devices shall support implicit Fabric login and may include the capability to be initialized by an entity outside the bounds of the Fibre Channel standards. The specific login mechanization is defined by the specific system interface requirements. All devices complying with this profile may also support Explicit Fabric login.

4.2.1.19 N_Port Login/Logout

All devices complying with this profile shall support implicit N_Port login/logout and may include the capability to be initialized by an entity outside the bounds of the Fibre Channel standards. The specific login mechanization is defined by the specific system interface requirements. All devices complying with this profile may also support Explicit N_Port login/logout.

4.2.1.20 Hunt Groups

Use of Hunt Groups is Allowed.

4.2.1.21 Clock Synchronization

All devices complying with this profile shall support Extended Link Service Clock Synchronization and may support the Primitive Signal method of Clock Synchronization as defined in FC-FS. In addition, each port shall manage its clock update process to prevent the appearance of negative elapsed time (e.g., by not updating a clock value which is less than the current clock value).

4.2.2 ASM Structure and Concepts

Every message in ASM is pushed. 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 are “unsolicited data” in type.

4.2.2.1 Payload Structure

The first four words (or 16 bytes) of every Fibre Channel Frame Payload are reserved for the ASM header. In multi-frame sequences, all frames shall contain a copy of the ASM header. The format of the ASM header is illustrated in Figure 1.

The first word in the payload is the “Message ID.” The Message ID values of hex ’00 00 00 00’ and hex ’FF FF FF FF’ are reserved. • NOTE - The Message ID contains a 32-bit pattern that uniquely identifies the message within the host

system. No other information is required, other than the message ID, for a receiving application to properly interpret the message. Message IDs may be mapped to both the D_ID of the delivery frame as well as to the first word of the Payload.



17

Figure 1 ASM Header Format

Bytes 4 through 7 are reserved for project unique 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 message transmission and routing priority. Details of the implementation of priority are system and network layer specific. Some network implementation may not provide priority message delivery, or may limit available priority levels. When implemented, 0 shall be the highest priority and 127 the lowest.

Bytes 13, 14 and 15 shall contain the total number of bytes of information in the payload (less ASM header) contained in the entire message (including multi-frame messages) associated with the Message ID.

• NOTE - FC-AE-ASM protocol objects must be easily mapped to other physical transports. Therefore, according to that philosophy no ASM protocol objects may be mapped to Fibre Channel unique framing fields without also appearing in the appropriate ASM header field (i.e., all ASM protocol objects are mapped into the payload).

Message ID

0 1 2 3Byte

Reserved - Security

Reserved

PriorityMessage Payload Length

(bytes)

Reserved



18

4.3 MIL-STD-1553

4.3.1 Scope

This clause describes an FC-4 mapping layer intended to provide a deterministic command/response protocol for use in real-time flight critical and mission critical avionics applications. One of the primary motivations for this ULP mapping is to enable the leveraging of existing system designs, hardware, and software written for MIL-STD-1553 avionics networks. The mnemonic for this ULP is FC-AE-1553. This clause includes a description of the differences between MIL-STD-1553 and FC-AE-1553, information relating to mapping and bridging from legacy 1553 devices, a profile delineating the required and optional FC-AE-1553 features, the actual mapping from the FC-AE-1553 ULP to Fibre Channel FC-FS, and a profile section specifying the required, optional and prohibited FC-FS Fibre Channel features. The ULP mapping includes constructs for bridging between FC-AE-1553 Fibre Channel networks and MIL-STD-1553 buses. Informative Annex A includes additional information regarding Fibre Channel-to-MIL-STD-1553 bridges.

4.3.1.1 Introduction

Some of the key FC-AE-1553 elements are the Network Controller or NC, the Network Terminal or NT, the Fibre Channel network itself and in cases where legacy MIL-STD-1553 data buses are connected to the network, FC-AE-1553 to MIL-STD-1553 bridges, MIL-STD-1553 buses, and MIL-STD-1553 RT devices. There may be one or multiple active network controllers on an FC-AE-1553 network. One of the main functions of the network controllers is to provide the scheduling of all FC-AE-1553 transmissions on the network. FC-AE-1553 defines a command/response protocol. The network terminal (NT) consists of a Fibre Channel interface located inside a subsystem or sensor connected to a Fibre Channel network. The NTs primary function is to perform data transfers between the subsystem and the Fibre Channel network as directed by the network controller(s). While FC-AE-1553 is based largely on MIL-STD-1553B Notice 2 constructs, it includes extensions that provide capability beyond standard MIL-STD-1553. These extensions include the ability to allow for a substantially larger maximum number of terminals (224), increased word counts (232 32-bit words), and a larger subaddress space (232). FC-AE-1553 also takes full advantage of the network topology offered by Fibre Channel (as opposed to MIL-STD-1553’s bus topology), allowing simultaneous data traffic across the network and multiple network controller entities. This mapping also supports the aggregation of multiple MIL-STD-1553 buses into a common FC-AE-1553 network, while maintaining an equivalent functionality of individual MIL-STD-1553 buses. Table 5 provides a comparison between terminology used in MIL-STD-1553 and FC-AE-1553.

Table 5. Terminology Equivalents between MIL-STD-1553 and FC-AE-1553

MIL-STD-1553 FC-AE-1553 Bus Controller (BC) Network Controller (NC) Remote Terminal (RT) Network Terminal (NT) RT Address Network Terminal ID (NT_ID) RT Subaddress NT Subaddress (NT_SA) MIL-STD-1553 Message FC-AE-1553 Exchange Command Word Command Sequence or Command Frame Status Word Status Sequence or Status Frame

Unless otherwise stated, all references to words for FC-AE-1553 are for 32-bit words, not 16-bit words. However, for FC-AE-1553 exchanges that are bridged to MIL-STD-1553 messages, there are specific references to 16-bit words transmitted over MIL-STD-1553 buses.



19

4.3.1.2 Mapping legacy 1553 applications to FC-AE-1553

A fundamental purpose of the FC-AE-1553 mapping is to enable interoperability for interfacing legacy MIL-STD-1553 remote terminals to a Fibre Channel network. The FC-AE-1553 protocol supports the mapping of legacy MIL-STD-1553 command words to Fibre Channel header fields. The use of the Fibre Channel header fields in FC-AE-1553 applications supports larger RT address and subaddress spaces, and message sizes than MIL-STD-1553. These differences are summarized in Table 6.

Table 6. Comparison of MIL-STD-1553 and FC-AE-1553 Command Field Sizes

MIL-STD-1553 FC-AE-1553 RT Address 5 bits NT Address (D_ID / S_ID) 24 bits Subaddress 5 bits NT Subaddress (NT_SA) 32 bits Word Count/Mode Code 5 bits Word Count (WC) 32 bits

While FC-AE-1553 applications will be able to leverage the increased command field sizes, the following provisions accommodate the mapping of legacy MIL-STD-1553 applications to FC-AE-1553.

(1) RT Address: Any port on a FC-AE-1553 network may operate as a Network Controller (NC; akin to a MIL-STD-1553 Bus Controller or BC), a Network Terminal (NT; akin to a MIL-STD-1553 Remote Terminal or RT), or both. For command frames transmitted by network controllers, the 24-bit Fibre Channel D_ID or NT Address field performs the function of the MIL-STD-1553 5-bit RT address field, while the Fibre Channel S_ID field is used to specify an NT address for the network controller. For status frames transmitted by network terminals, the 24-bit S_ID field provides acknowledgement by indicating the terminal’s “NT Address”, while the value of the D_ID field is the port address of the destination NC or, for an NT-to-NT transfer exchange, the destination NT.

FC-AE-1553 includes provisions to support bridging to existing MIL-STD-1553 (1 MHz) RTs. To enable this type of bridging, the FC-AE-1553 command frame and status frame headers include fields to indicate the 5-bit RT address of a MIL-STD-1553 RT connected to a Fibre Channel-to-1553 bridge, along with a bit to indicate whether or not this field is active for a particular exchange.

FC-AE-1553 supports multiple options for implementing broadcast and multicast:

(i) All FC-AE-1553 NTs shall recognize the Fibre Channel well known broadcast address of ‘FF FF FF’.

(ii) All FC-AE-1553 NTs on an arbitrated loop shall recognize the broadcast replicate AL_PA address of ‘FF’.

(iii) To support broadcast functionality for RTs on a bridged MIL-STD-1553 bus, the NC may specify a value of ‘1F’, the MIL-STD-1553 broadcast address, for the 5-bit MIL-STD-1553 RT address field.

(iv) FC-AE-1553 Network Terminals on a fabric may respond to arbitrary alias addresses.

(v) FC-AE-1553 Network Terminals on an arbitrated loop may support selective replicate.

(2) RT Subaddress: FC-AE-1553 command frames shall use words 6 through 9 following the Fibre Channel Header as a ULP-specific header extension. MIL-STD-1553 subaddresses map to the lower five bits of word #7 of the FC-AE-1553 command frame as shown in Table 10. For FC-AE-1553 command frames to bridged MIL-STD-1553 RTs, the 5-bit MIL-STD-1553 subaddress field shall be right-justified within the FC-AE-1553 32-bit subaddress field, with the upper 27 bits set to ‘0’. The FC-AE-1553 subaddress values of either ’00 00 00 00’ or ‘FF FF FF FF’ shall specify a mode code exchange (akin to ‘00’ and ‘1F’ in the MIL-STD-1553 subaddress field).



20

(3) Word Count / Mode Code: The Fibre Channel Parameter field in FC-AE-1553 command frames shall be used as the FC-AE-1553 word count field (akin to the MIL-STD-1553 word count field) and shall specify the number of 32-bit data words in a sequence. A word count field of ’00 00 00 01’ specifies one 32-bit data word, ’00 00 00 02’ specifies two 32-bit data words, …. ‘FF FF FF FF’ specifies 232 –1 data words, and a word count field of ’00 00 00 00’ shall be used to specify 232 32-bit data words.

The MIL-STD-1553 word count/mode code field maps to the lower five bits of the FC-AE-1553 word count/mode code field (refer to word #8 in Table 10). Word count values as used in MIL-STD-1553 indicate a count of 16 bit words shall be adjusted for FC-AE-1553 to indicate a count of 32- bit words as follows:

(i) In order to transmit an even number of MIL-STD-1553 16-bit data words, the MIL-STD-1553 word count value shall be right shifted by one bit (divided by two) and mapped to the lower four bits of the FC-AE-1553 word count/mode code field, and a value of 0 shall be assigned to the Fill Bytes bits in the F_CTL field. Note that a Word Count field of ’00 00 00 10’ indicates an exchange with sixteen 32-bit data words = thirty-two 16-bit data words. (ii) In order to transmit an odd number of MIL-STD-1553 16-bit data words, the MIL-STD-1553 word count value shall be right shifted by one bit (eliminating the LSB), then incremented by one and mapped to the lower four bits of the FC-AE-1553 word count/mode code field, with a value of 2 shall be assigned to the Fill Bytes bits in the F_CTL field. For FC-AE-1553 mode code exchanges with an associated data word, the value of the Fill Bytes bits in the F_CTL field shall be 2.

For mode code commands, the values of the lower five bits shall be equal to those for the respective MIL-STD-1553 mode code, while the upper 27 bits of the FC-AE-1553 Word Count/Mode Code field shall have values of ‘0’. For all FC-AE-1553 frames, the Parameter Field, word 5 in the Fibre Channel header, may be used to specify relative offset.

4.3.2 FC-AE-1553 ULP Features

4.3.2.1 Information Units

This section details the FC-AE-1553 Information Units. Table 7 defines Information Units (IUs) transmitted from the FC-AE-1553 Network Controller to the Network Terminals. Table 8 defines the Information Units initiated from the Network Terminals to the Network Controller or to other Network Terminals.

Table 7. Information Units Initiated from the Network Controller to Network Terminal

IU FC-AE-1553 Primitive CAT Content F/M/L SI

NC1 - NC-to-NT Transfer (single-frame sequence: command + up to 512 data words max) - NT-to-NC Command - Mode Code Command, to single NT Command (with or without data word)

6 FC-AE-1553 Command, or FC-AE-1553 Command + Data

F T

NC2 - NC-to-NT Transfer (first frame of multi-frame sequence: command, plus up to 512 data words max) - Receive command for NT-to-NT or NT-to-multiple NTs transfer

6 FC-AE-1553 Command + Data, or FC-AE Command

F H

NC3 Data frames after first (command + data) frame, but prior to last data frame for

4 Data F H



21


controller-to-NT transfer NC4 Last frame of data words for controller-to-

NT transfer 4 Data F T

NC5 - Transmit command frame for NT-to-NT transfer - Transmit command frame for NT-to-multiple NTs transfer

6 FC-AE-1553 Command

M T

NC6 - Controller-to-Multiple NTs Transfer (single frame sequence: command + 512 data words max) - Controller-to-Multiple NTs Transfer (first frame of multi-frame sequence: command plus 512 data words max) - Mode command or mode command + data to multiple NTs

6 FC-AE-1553 Command, or FC-AE-1553 Command + Data

F/L H

NC7 Data frames after first (command + data) frame for controller-to-multiple NTs transfer

4 Data F/L H

NOTE: IU = Information Unit; CAT = Information Category; F/M/L = sequence position within exchange, where F = first, M = middle, and L = last; SI = Sequence Initiative (H = hold, T = transfer)



22

Table 8. Information Units Initiated from the Network Terminal


NT1 - Response to NC-to-NT transfer (Status Frame

- Response to NT-to-NC Transfer (single-frame sequence: status + 512 data words max)

- Response to NT-to-Multiple NTs Transfer (single-frame sequence: status + 512 data words max)

- Response to receive command for NT-to-NT transfer (status)

- Response to NC-to-single NT mode command, with or without data

7 FC-AE-1553 Status, or FC-AE-1553 Status + Data

L T

NT2 - Response to NT-to-NC Transfer (first frame of multi-frame sequence: status, plus 512 data words max)

- Response to transmit command for NT-to-Multiple NTs Transfer (first frame of multi-frame sequence: status, plus 1024 data words)

- Response to transmit command for NT-to-NT transfer (to Network Controller): status. - Response to transmit command for NT-to-Multiple NTs transfer (to Network Controller): status.

7 FC-AE-1553 Status + Data

L H

NT3 - Data frames after first (status + data) frame, but prior to last data frame for NT-to-controller transfer - Data frames after first (status + data) frame, but prior to last data frame for NT-to-multiple NTs transfer

1 Data L H

NT4 - Last data frames for NT-to-NC transfer - Last data frame for NT-to-multiple NTs transfer

1 Data L T

NT5 - Response to transmit command for NT-to-NT Transfer (single-frame sequence: status + 512 data words max)


M T

NT6 - Response to transmit command (to receiving NT) for NT-to-NT transfer (first frame of multi -frame sequence: status, plus 512 data words)


M H

NT7 - Data frames after first (status + data) frame, but prior to last data frame for NT-to-NT transfer

1 Data M H

NT8 - Last data frame for NT-to-NT transfer 1 Data M T NOTE: IU = Information Unit Type; CAT = Information Category; F/M/L = sequence position within exchange, where F = first, M = middle, and L = last; SI = Sequence Initiative (H = hold, T = transfer)



23

4.3.2.2 Exchange (Message) Formats

This section describes the MIL-STD-1553B message formats as they are mapped to FC-AE-1553 exchanges.

4.3.2.2.1 Network Controller to Remote Terminal Transfers

The NC shall initiate a Remote Terminal receive command followed by the specified number of data words. The NT shall respond after the data sequence is validated with a status frame back to the network controller. See Figure 2.

Network Controller Network Terminal

Figure 2. Network Controller To Network Terminal

4.3.2.2.2 Remote Terminal to Network Controller Transfers

The NC shall send a transmit command frame to the NT. The NT shall (after command verification) transmit a status frame and data words back to the Network Controller. Figure 3 illustrates this exchange format. Network Controller Network Terminal

Figure 3. Network Terminal-to-Network Controller

Status Word + Data Words: NT1, or

NT2 + NT4, or NT2 + NT3 +NT4

Transmit Command Word:

NC1

Status Word: RT1

Receive Command + Data Words:

NC1, or NC2 + NC4, or

NC2 + NC3 + NC4



24

4.3.2.2.3 Network Terminal to Network Terminal Transfers

There are two different variations for this exchange. For one variation, NTB‘s transmission is received only by NTA, but not by the NC. For the other variation, the NC monitors the data transmission from NTB to NTA. For a specific exchange, the NC specifies which variation is used by means of the NC Monitor bit, bit 25 of word 6 of the FC-AE-1553 Command Frame (Refer to Table 10). If the NC Monitor bit is logic ‘0’, Variation 0 shall be used; if the NC Monitor bit is logic ‘1’, Variation 1 shall be used.

For both variations, the NC shall initiate the exchange by issuing a receive command frame to NTA followed by a transmit command frame to NTB. Following these two sequences, the two different variations shall proceed as follows:

Variation 0 – NC doesn’t monitor NT B‘s data transmission: For this variation, NTB responds by transmitting a status frame to the Network Controller. NTB then sends status followed by data to NTA. After validation, NTA shall respond by transmitting a status frame to the NC.

Variation 1 – NC monitors NT B‘s data transmission: This variation is only applicable when using Fibre Channel Class 3 service on a loop or fabric, or Class 6 service on a fabric. For this variation, it is necessary for NTB to multicast its transmission to a multicast group consisting of NTA and the NC. On a fabric, this requires the prior establishment of a multicast alias group. For a loop, NTB shall transmit selective replicate ordered sets to NTA and the NC prior to transmitting status and data. In either case, NTB transmits status followed by data to NTA and the NC. After validation, NTA shall respond by transmitting a status frame to the NC.

Figure 4 illustrates both variations of the NT-to-NT exchange format. NT B (Transmitting NT) Network Controller NT A (Receiving NT)

Figure 4 NT to NT Transfers

Receive Command Word:

NC2

Transmit Command Word: NC5

Status + Data Words: NT5, or

NT6 + NT8, or NT6 + NT7 + NT8

Status Word: NT1

Status to Network Controller

(Variation 0 only): NT6

(Variation 1 only)



25

4.3.2.2.4 Mode Command Without Data Word Transfers

The NC shall issue a transmit mode command frame to the NT using a mode code specified in section 4.3.4.15. The NT shall respond after command reception with a status frame. Figure 5 illustrates this exchange.


Figure 5. Mode Command without Data Word

4.3.2.2.5 Transmit Mode Command With Data Word Transfers

The NC shall issue a transmit mode command frame to the NT using a mode code specified in section 4.3.4.15. The NT shall respond after command reception with a status frame including a single 16-bit data word. Figure 6 illustrates this exchange. Network Controller Network Terminal

Figure 6. Transmit Mode Command with Data Word

Status Word: NT1

Transmit Mode Command Word:

NC1

Status Word + Data Word:

NT1

Transmit Mode Command Word:

NC1



26

4.3.2.2.6 Mode Command (Receive) With Data Word Transfers

The NC shall issue a receive mode command frame containing a single data word to the NT using a mode code specified in section 4.3.4.15. After command frame reception, the NT shall respond with a status frame. Figure 7 illustrates this exchange.


Figure 7. Receive Mode Command with Data Word

4.3.2.2.7 Network Controller to Multiple Network Terminals transfers

The NC shall initiate a Network Terminal receive command to the broadcast address, followed by the specified number of data words. See Figure 8. Network Controller Network Terminal

Figure 8. Controller to Multiple Remote Terminals

Status Frame NT1

Receive Mode Command Word +

Data Word:

NC1

Broadcast Receive Command Word +

Data:

NC6, or NC6 + NC7



27

4.3.2.2.8 Network Terminal to Multiple Network Terminal Transfers

The NC shall issue a receive command frame to the broadcast address, followed a transmit command frame to a specific NT. The transmitting NT shall transmit a status frame followed by the requested number of data words to the broadcast address. The status and data are received by all NTs on the network as well as by the NC. Figure 9 illustrates the NT-to-multiple NTs exchange format. Transmitting NT Network Controller Receiving NTs

Figure 9. Network Terminal to Multiple Network Terminals

4.3.2.2.9 Broadcast Mode Command Without Data Word Transfers

The NC shall issue a transmit mode command frame to the broadcast address ‘FF FF FF’ (or, on a loop, to the AL_PA broadcast replicate address ‘FF’) using a mode code specified in section 4.3.4.15. Figure 10 illustrates this exchange. Network Controller Network Terminals

Figure 10. Transmit Mode Command without Data Word to Multiple Network Terminals

Receive Command

Word:

NC2

Transmit Command

Word: NC5

Broadcast Transmit Mode Code Command:

NC6

Status + Data Words to Receiving Multiple NTs: NT6, or NT6 + NT7



28

4.3.2.2.10 Mode Command (Receive) with Data Word Transfers

The NC shall issue a receive mode command frame containing a single data word to the NT using a mode code as specified in section 4.3.4.15. Figure 11 illustrates this exchange. Network Controller NTs

Figure 11. Receive Mode Command with Data Word to Multiple Network Terminals

4.3.3 MIL-STD-1553 ULP Profile

Table 9 lists the set of MIL-STD-1553B Notice 2 features relevant to the FC-AE-1553 Upper Level Protocol. This table indicates whether the feature is Required, Prohibited, Allowed, or Invocable for compliance with this profile. Features that are not listed do not affect the interoperability of FC-AE-1553 devices.

Table 9. MIL-STD-1553B Notice 2 Profile for FC-AE-1553

Feature Nx_Port Fx_Port Notes

Command Fame

NT Address R -- D_ID, S_ID fields.

T/R* bit R --

Subaddress R --

Word Count/Mode Code R --

NTs are not required to implement all combinations of T/R, subaddress, and word count/mode code.

Status Frame

Message Error R --

Instrumentation R -- Always ‘0’.

Service Request A --

Reserved Status Frame Bits R -- Always ‘0’.

Broadcast Command Received I --

Busy A --

Subsystem Flag A --

Dynamic Network Acceptance A --

Broadcast Receive Mode Code Command

+ Data Word:

NC6



29


Terminal Flag A --

Exchange Formats (NC)

NC-to-NT Transfer I --

NT-to-NC Transfer I --

NT-to-NT Transfer I --

Mode Code, no data I --

NC-to- Multiple NTs I --

NT-to- Multiple NTs I --

Receive Mode Code, with data I --

Transmit Mode Code, with data I --

Mode Code, no data to Multiple NTs I --

Receive Mode Code, with data

to Multiple NTs

I --

Exchange Formats (NT)

NC-to-NT Transfer I --

NT-to-NC Trans fer I --

NT-to-NT Transfer I --

Mode Code, no data I --

NC-to-Multiple NTs A --

NT-to- Multiple NTs A --

Receive Mode Code, with data A --

Transmit Mode Code, with data A --

Mode Code, no data to multiple NTs A --

Receive Mode Code, with data

to Multiple NTs

A --

Mode Codes (NC)

Dynamic network control – Non-

broadcast

A --

Dynamic network control – Broadcast P --

Synchronize (without data word) – Non-

broadcast

I --

Synchronize (without data word) –

Broadcast

I --

Transmit status frame – Non-broadcast I --

Transmit status frame – Broadcast P --

Initiate self-test – Non-broadcast I --

Initiate self-test – Broadcast I --

Transmitter shutdown – Non-broadcast I --



30


Transmitter shutdown – Broadcast I --

Override transmitter shutdown – Non-

broadcast

I --

Override transmitter shutdown –

Broadcast

I --

Inhibit terminal flag – Non-broadcast I --

Inhibit terminal flag – Broadcast I --

Override inhibit terminal flag – Non-

broadcast

I --

Override inhibit terminal flag –

Broadcast

I --

Reset remote terminal – Non-broadcast I --

Reset remote terminal – Broadcast I --

Transmit vector word – Non-broadcast I --

Transmit vector word – Broadcast P --

Synchronize (with data word) – Non-

broadcast

I --

Synchronize (with data word) –

Broadcast

I --

Transmit last command frame – Non-

broadcast

I --

Transmit last command frame –

Broadcast

P --

Transmit BIT word – Non-broadcast I --

Transmit BIT word – Broadcast P --

Selected transmitter shutdown – Non-

broadcast

I --

Selected transmitter shutdown –

Broadcast

I --

Override selected transmitter

Shutdown - Non-broadcast

I --


Shutdown - Broadcast

I --

Mode Codes (NT)

Dynamic network control – Non-

broadcast

A --

Dynamic network control – Broadcast P --

Synchronize (without data word) – Non-

broadcast

A --



31


Synchronize (without data word) –

Broadcast

A --

Transmit status frame – Non-broadcast I --

Transmit status frame – Broadcast P --

Initiate self-test – Non-broadcast A --

Initiate self-test – Broadcast A --

Transmitter shutdown – Non-broadcast I --

Transmitter shutdown – Broadcast I --

Override transmitter shutdown – Non-

broadcast

I --

Override transmitter shutdown –

Broadcast

I --

Inhibit terminal flag – Non-broadcast A --

Inhibit terminal flag – Broadcast A --

Override inhibit terminal flag – Non-

broadcast

A --

Override inhibit terminal flag –

Broadcast

A --

Reset remote terminal – Non-broadcast I --

Reset remote terminal – Broadcast I --

Transmit vector word – Non-broadcast A --

Transmit vector word – Broadcast P --

Synchronize (with data word) – Non-

broadcast

A --

Synchronize (with data word) –

Broadcast

A --

Transmit last command frame – Non-

broadcast

A --

Transmit last command frame –

Broadcast

P --

Transmit BIT word – Non-broadcast A --

Transmit BIT word – Broadcast P --

Selected transmitter shutdown – Non-

broadcast

A --

Selected transmitter shutdown –

Broadcast

A --


Shutdown - Non-broadcast

A --



32



Shutdown – Broadcast

A --

4.3.4 MIL-STD-1553 ULP Mapping to FC-AE-1553

4.3.4.1 MIL-STD-1553 Command Word Mapping to FC-AE-1553

Every FC-AE-1553 exchange is initated by a network controller’s transmission of a command frame or pair of command frames. FC-AE-1553 command headers are included only in the first frame of an exchange or, for the case of an NT-to-NT transfer, in the first two frames of an exchange. For these frames, the MIL-STD-1553 command word frames are mapped to the Fibre Channel Header and to the device_header consisting of words 6 through 9 of the frame, which are normally the first four words of payload. The Command Frame header is illustrated in Table 10. All FC-AE-1553 frames may use word 5 in the header (Parameter) as a relative offset field. For exchanges in which the network controller transmits data, the network controller may send data words in the payload of the Command Frame, starting at word #10. If such an exchange has more than 512 data words, the NC shall also transmit a single-frame or multi-frame data sequence following the command frame (command sequence). Alternatively, the network controller may transmit no data words in its NC-to-NT command frame. In this case, it shall transmit data words in a single-frame or multi-frame data sequence following the Command Frame sequence. Data Frame headers shall follow the format in Table 10 for words 0 through 5.

Table 10. FC-AE-1553 Command Frame Header

Bits Word

31 – 24

23 – 16

15 – 8

7 - 0

0 R_CTL Destination ID (NT Address)

1 CS_CTL Source ID (NC Address)

2 TYPE F_CTL

3 SEQ_ID DF_CTL SEQ_CNT

4 OX_ID RX_ID

5 Parameter

6

Reserved (5)

NT

-to-NT

T

ransfer (1)

NC

Monitor

NT

-to-NT

Transfer (1)

T/R* (1)

Transmitting or Receiving NT Address for NT-to-NT transfers

7 Subaddress/Mode

8 Data Word Count/Mode Code

9 Bridge to Tx

or Rx 1553

RT

for NT-

to-NT

T

ransfer (1) (1)

1553 BUS_ID for Tx or Rx RT for NT-to-

NT Transfer (7)

Reserved

(3)

RT Address for Tx or Rx MIL-

STD-1553 RT for NT-to-NT

Transfer (5)

Bridge to

Dest. 1553 R

T (1)

1553 BUS_ID

for Destination RT (7)

Reserved

(1)

1553 Bus

Select

Enable (1)

1553 Bus

B/A

* (1)

RT Address for Destination MIL-STD-

1553 RT (5)

4.3.4.2 R_CTL:

The R_CTL field is divided into two sub-fields, the Routing Bits and Information Category bits.



33

4.3.4.2.1 Routing Bits:

The routing bits of the R_CTL field shall be hex ‘0’ for all frames conveying FC-AE-1553 command, status, or data. For Extended Link_Data, Basic Link_Data, and Link_Control frames, the routing bits shall be hex ‘2’, ‘8’, and ‘C’ respectively.

4.3.4.2.2 Information Category Bits:

The information category bits of the R_CTL field shall be set in accordance with Table 7 or Table 8.

4.3.4.3 Destination Identifier (D_ID)

Destination Identifier (D_ID) field contains the Network Terminal (NT) address of the recipient for each frame. Each Fibre Channel port that is functioning as an FC-AE-1553 NT shall recognize frames with a D_ID of its native N_Port identifier and the alias address of hex ‘FF FF FF’, to be used with the broadcast option. Similarly, an NC shall recognize both its native N_Port identifier and the broadcast address of hex ‘FF FF FF’.

4.3.4.4 Source Identifier (S_ID)

Source Identifier (S_ID) shall indicate the address identifier of the source N*_Port. Every NT and NC shall have a unique S_ID.

4.3.4.5 TYPE Field

The TYPE field shall be hex ‘48’ for all FC-AE-1553 frames transferred in compliance with this profile. Other ULPs may run concurrently through the same port with FC-AE-1553.

4.3.4.6 NT-to-NT

The NT-to-NT bit shall be mapped to bit 26 of word 6 of the FC-AE-1553 Command Frame (Refer to Table 10). This bit shall be logic ‘1’ to initiate NT-to-NT or NT-to-Multiple NTs transfer exchanges, and logic ‘0’ to initiate all other exchanges.

4.3.4.7 NC Monitor for NT-to-NT Transfers

The NC Monitor bit shall be mapped to bit 25 of word 6 of the FC-AE-1553 Command Frame (Refer to Table 10). For an NT-to-NT transfer, if this bit is logic ‘0’, then Variation 0 of the NT-to-NT transfer format shall be used. In this format, the NC does not monitor the data transmission by the transmitting NT. For an NT-to-NT transfer, if this bit is logic ‘1’, then Variation 1 of the NT-to-NT transfer format shall be used. In this format, the transmitting NT establishes a multicast group consisting of the NC and the receiving NT, allowing the NC to monitor the data transmission by the transmitting NT. On a fabric topology, this entails the use of an alias group. On a loop, this involves the use of the selective replicate function. This bit shall be logic ‘0’ for all exchange formats other than NT-to-NT transfers.

4.3.4.8 T/R*

The T/R* bit, which is mapped to bit 24 of word 6 of the FC-AE-1553 Command Frame header (refer to Table 10), is used to indicate the direction of data transfer, with respect to the NT or multiple NTs. This bit shall be set to logic ‘0’ for to initiate exchanges in which the NT or multiple NTs will receive data, and logic 1’ to initiate message sequences in which the NT will transmit data.

4.3.4.9 Transmitting or Receiving NT Address for NT-to-NT Transfers.

The two command frames that initiate NT-to-NT or NT-to-multiple NTs transfers require an additional NT address to indicate to the transmitting NT the address of the receiving NT, and likewise to indicate to the receiving NT the address of the transmitting NT. This address shall be mapped to the lower 24 bits of word 6 of the two FC-AE-1553 Command Frames used to initiate NT-to-NT or NT-to-multiple NT transfers. For the first (receive) command frame of an NT-to-NT or NT-to-broadcast transfer, this field shall contain the 24-bit NT address of the transmitting NT. For the second (transmit) command frame for an NT-to-NT or NT-to-broadcast transfer, this field shall cont ain the 24-bit NT address of the receiving NT.



34

This command frame field shall only be used for NT-to-NT transfer or NT-to-multiple NTs transfer exchanges, and for all other exchange formats, the value of this field shall be ’00 00 00’.

4.3.4.10 Subaddress / Mode

Subaddress/Mode is mapped to word command frame 7, which is normally the second word of Fibre Channel data payload. A Subaddress value of hex ’00 00 00 00’ or ‘FF FF FF FF’ indicates that the FC-AE-1553 Data Word Count/Mode Code field is to be interpreted as a mode code, rather than a data word count. A subaddress value between ’00 00 00 01’ and ‘FF FF FF FE’ shall be interpreted by the NT as a non-mode code subaddress.

For mapping of legacy 1553 applications, non-mode code MIL-STD-1553 subaddresses map to the lower five bits of word #7 of the FC-AE-1553 command frame, the Subaddress/Mode word (field). In this case, the upper 27 bits of the FC-AE-1553 subaddress field shall all have values of ‘0’, with the 5-bit legacy subaddress field being right -justified within the FC-AE-1553 32-bit subaddress field. For “native” FC-AE-1553 applications, the full 32-bit subaddress field shall be used.

4.3.4.11 Data Word Count / Mode Code

The MIL-STD-1553 Data Word Count/Mode Code field is mapped to Fibre Channel Header word 8, which is normally the first word of the Fibre Channel payload. MIL-STD-1553B specifies 5 bits for this function, allowing a transfer of a maximum of 32 16-bit words to be transmitted or received by an RT. FC-AE-1553 allocates 32 bits for this function, enabling data transfers exceeding 4 billion 32-bit words for a single FC-AE-1553 exchange.

The content of this field is controlled by the Subaddress/Mode field. If the value of the Subaddress/Mode field is ’00 00 00 00’ or ‘FF FF FF FF’, this field contains a Mode Code as defined in clause 4.3.4.15. Otherwise, this field contains a Data Word Count, which is an unsigned integer value which indicates the number of 32-bit data words in the IU corresponding to this Frame. That is, a word count field of ’00 00 00 01’ specifies one 32-bit data word, ’00 00 00 02’ specifies two 32-bit data words, …. ‘FF FF FF FF’ specifies 232 –1 data words, and a word count field of ’00 00 00 00’ specifies 232 data words.

For legacy MIL-STD-1553 applications, the 1553 word count/mode code field maps to the lower five (5) bits of the FC-AE-1553 word count/mode code (Parameter) field (i.e., this value is right-justified). For such applications, the maximum value of the FC-AE-1553 word count field shall be ’00 00 00 10’, which specifies 16 32-bit data words = 32 16-bit data words. For legacy MIL-STD-1553 applications, the upper 27 bits of the FC-AE-1553 word count/mode code field shall all have values of ‘0’. To enable a Fibre Channel-to-1553 bridge to transmit an odd number of MIL-STD-1553 16-bit data words, the value of the FC-AE-1553 word count field shall be formulated by right shifting the MIL-STD-1553 word count value by one bit (eliminating the LSB), then incremented by one; in addition, a value of 2 shall be assigned to the Fill Bytes bits in the F_CTL field. Fill Bytes values of 1 and 3 in the F_CTL field shall not be used for FC-AE-1553 command, status, or data frames. For “native” FC-AE-1553 applications, the full 32-bit word count field shall be used. For all mode code exchanges involving the mode codes defined by paragraphs 4.3.4.15.1 through 4.3.4.15.15, the upper 27 bits of the FC-AE-1553 word count/mode code field shall have values of ‘0’. For these mode code exchanges, the values of the lower five bits shall be equal to those for the respective MIL-STD-1553 mode code, as detailed in paragraphs 4.3.4.15.1 through 4.3.4.15.15. For any vendor-specific or user-specific mode codes created that are not defined by these paragraphs, the full 32-bit mode code field may be used.

4.3.4.12 1553 Bus Select Enable

Bit 6 of command frame header word #9 is only used for exchanges involving Fibre Channel-to-1553 bridges to MIL-STD-1553 RTs (i.e., bit 15 of header word #9 must be logic ‘1’). If 1553 Bus Select Enable is logic ‘1’, then the MIL-STD-1553 bus (A or B) for the current exchange (1553 message) shall be specified by means of the value of bit 5 of word #9, 1553 Bus B/A*. If 1553 Bus Select Enable is logic ‘0’,



35

then the selection of the MIL-STD-1553 bus (A or B) for the current exchange shall be specified by either the Fibre Channel-to-1553 bridge or the MIL-STD-1553 bus controller within the bridge. For non-bridged exchanges, this bit shall be logic ‘0’.

4.3.4.13 1553 Bus B/A*

Bit 5 of command frame header word #9 shall only be used for exchanges involving Fibre Channel-to-1553 bridges to MIL-STD-1553 RTs (i.e., bit 15 of header word #9 must be logic ‘1’). If bit 6 of header word #9, 1553 Bus Select Enable, is logic ‘1’, this bit shall be used to specify which 1553 bus shall be used for the specific exchange (1553 message). In this case, logic ‘0’ shall designate 1553 bus A, logic ‘1’ shall designate 1553 bus B. For non-bridged exchanges or for bridged exchanges where 1553 Bus Select Enable is logic ‘0’, this bit shall be logic ‘0’.

4.3.4.14 RT Address for MIL-STD-1553 RT

To enable FC-AE-1553 network controllers to communicate across Fibre Channel-to-1553 bridges to MIL-STD-1553 RTs, word #9 of the FC-AE-1553 command frame header provides MIL-STD-1553 RT addressing information for use by the bridges. If the destination NT for an exchange includes a Fibre Channel-to-1553 bridge, then Bridge to Destination RT, bit 15 of NC command frame header word 9, shall be logic ‘1’. In this case, bits 4-0 of this word shall contain the RT address of the destination RT. Bits 14-8 are an optional 7-bit BUS_ID field that may be used to identify the specific MIL-STD-1553 bus that the destination RT is on; if not used, bits 14-8 shall be logic ‘0’. For the case where the destination NT is not bridging to a MIL-STD-1553 RT, bit 15 shall be logic ‘0’ and bits 14-8 and 4-0 shall not be used. To support NT-to-NT and NT-to-multiple NTs transfer exchanges involving a Fibre Channel-to-1553 bridge(s), command frame header word #9 includes a provision for additional 1553 RT addressing information. If the transmitting NT comprises part of a Fibre Channel-to-1553 bridge, then header word 9 of the NT command frame sent to the receiving NT shall include the RT address of the transmitting MIL-STD-1553 RT in bits 20-16 of header word #9; in addition, bit 31, Bridge to Tx or Rx RT for NT-to-NT Transfer, shall be logic ‘1’. Likewise, if the receiving NT comprises part of a Fibre Channel-to-1553 bridge, then header word 9 of the NT command frame sent to the transmitting NT shall include the RT address of the receiving MIL-STD-1553 RT in bits 20-16 of header word 9; in addition, bit 31, Bridge to Tx or Rx RT for NT-to-NT Transfer, shall be logic ‘1’. In either case, bits 30-24 are an optional 7-bit BUS_ID field that may be used to identify the specific MIL-STD-1553 bus that the transmitting or receiving RT is on; if not used, bits 30-24 shall be logic ‘0’. For the command frame for an exchange format other than an NT-to-NT or NT-to-multiple NTs transfer, for the command frame to the receiving NT in an NT-to-NT or NT-to-multiple NTs transfer exchange in which the transmitting NT does not include an FC-to-1553 bridge, or for the command frame to the transmitting NT in an NT-to-NT or NT-to-multiple NTs transfer exchange in which the receiving NT(s) does not include an FC-to-1553 bridge, bit 31, Bridge to Tx or Rx RT for NT-to-NT Transfer, shall be logic ‘0’ and bits 30-24 and 20-16 shall not be used.

4.3.4.15 FC-AE-1553 Mode Codes

FC-AE-1553 provides for the equivalent network control functions that are available using MIL-STD-1553 mode codes. FC-AE-1553 mode codes provide network management capability. The determination of whether the command frame contains a mode code command is accomplished by decoding the subaddress/mode field. If the value of this field is ’00 00 00 00’ or ’FF FF FF FF’, this indicates that the exchange is a mode code and that the Word Count/Mode Code field contains the mode code type. The defined FC-AE-1553 mode codes are described in the following sub-paragraphs. FC-AE-1553 implementers may create vendor-specific or system-specific mode functions for code values not defined in the sub-paragraphs below.

4.3.4.15.1 Dynamic Network Control hex ’00 00 00 00’

FC-AE-1553 Dynamic Network Control replaces the MIL-STD-1553B Dynamic Bus Control function. The NC shall issue a transmit command to an NT capable of performing the FC-AE-1553 network (loop and/or fabric) control function. This NT shall respond with a status frame. The Network Control functions being performed by the specific NC initiating the exchange passes to the accepting NT upon completion of the



36

transmission of the status frame by the NT indicating acceptance of the Network Control function. If the NT rejects taking control of the network, the offering NC retains control of the network.

4.3.4.15.2 Synchronize (without data word) hex ’00 00 00 01’

This mode code command shall cause the NT to synchronize (e.g., to reset the internal timer, to start a sequence, etc.). The NT shall complete the exchange by transmitting its status frame.

4.3.4.15.3 Transmit Status frame hex ’00 00 00 02’

This mode code command shall cause the NT to transmit the status frame associated with the last valid command frame preceding this command. This mode code command shall not alter the NTs status frame.

4.3.4.15.4 Initiate Self-Test hex ’00 00 00 03’

This mode code command shall be used to initiate self-test within the receiving NT. The NT shall transmit a status frame on completion.

4.3.4.15.5 Transmitter Shutdown hex ’00 00 00 04’

This mode code command may be used with dual redundant systems, and shall cause the NT to disable FC-AE-1553 frame transmissions for the alternate redundant port. The NT shall respond with a status frame on the port where the command was received prior to shutdown. While shut down, the NT shall not respond to command frames on the effected port. This mode code command may be used to completely disable a redundant port for purposes of power management. Systems that make use of triple, quad, or higher redundancy levels shall use the Selected transmitter shutdown and override mode code commands to shut down and re-enable redundant channels.

4.3.4.15.6 Override Transmitter shutdown hex ’00 00 00 05’

This mode code command, which may be used with dual redundant systems, shall cause the NT to re-enable frame transmissions on the NT’s alternate port which was previously shut down. The NT shall transmit a status frame in response to this command.

4.3.4.15.7 Inhibit Terminal Flag (T/F) hex ’00 00 00 06’

This mode code command shall cause the NT to cause the Terminal flag bit in its status frame to logic ‘0’ until an Override inhibit terminal flag mode command has been received. The NT shall transmit a status frame in response to this command.

4.3.4.15.8 Override Inhibit Terminal Flag hex ’00 00 00 07’

This mode code command shall cause the NT to override the inhibit Terminal flag bit in the status frame. This will re-enable the NT’s Terminal flag status frame bit to become set to logic ‘1’ following a failure of its internal self-test. The NT shall respond with a status frame.

4.3.4.15.9 Reset the Terminal hex ’00 00 00 08’

This mode code command shall be used to reset an NT to a power-up initialized state. In this state, all status frame bits shall be reset to logic ‘0’, the Terminal flag bit will not be inhibited, and none of the NT’s transmitters shall be in a shut down state. The NT shall transmit a status frame in response to this command and then reset. This mode code is not a network initialization command.

4.3.4.15.10 Transmit Vector Word hex ’00 00 00 10’

This mode code command shall cause the NT to transmit a status frame that includes a 16-bit data word containing service request information.

4.3.4.15.11 Synchronize (with data word) hex ’00 00 00 11’

This mode code command shall cause the NT to receive the 16-bit synchronization word in the command frame. The data word shall contain synchronization information for the NT. After receiving the command and data, the NT shall transmit the status frame.



37

4.3.4.15.12 Transmit Last Command Frame hex ’00 00 00 12’

This mode code command shall cause the NT to transmit its status frame that includes the 10-word header (refer to Table 10) of the last command received in the payload of the status frame. This mode command shall not alter the state of the NT’s status frame. In the case of a Transmit last command frame mode code exchange bridged through an NT to a MIL-STD-1553 RT, the “last command frame” transmitted to the NC shall be the for the last exchange except for a Transmit status or Transmit last command frame mode code exchange that was received by the bridge for the addressed MIL-STD-1553 RT. Note that in general, this is not the last exchange received by the NT, which may have been a non-bridged exchange or an exchange to a different bridged MIL-STD-1553 RT. Therefore, in order to implement the Transmit last command mode code, it is necessary for the 10-word command frame headers corresponding to the last exchanges directed to the individual connected MIL-STD-1553 RTs to be stored in the bridge.

4.3.4.15.13 Transmit Built In Test (BIT) Word hex ’00 00 00 13’

This mode code command shall cause the NT to transmit its status frame followed by a single 16-bit data word containing the NT BIT data. This function is intended to supplement the available bits in the status frame when the NT hardware is sufficiently complex to warrant its use. The data word, containing the NT BIT data, shall not be altered by reception of a transmit last command or a transmit status frame mode code. This function shall not be used to convey BIT data from the associated subsystem(s).

4.3.4.15.14 Selected Transmitter Shutdown hex ’00 00 00 14’

This mode code command may be used with multi-redundant systems, and shall cause the NT to disable FC-AE-1553 frame transmissions for a specified redundant port. The NT shall respond with a status frame after this command prior to the shutdown of the effected port. While shut down, the specified port shall not respond to command frames. This mode code command may be used to completely disable a redundant channel for power management purposes.

4.3.4.15.15 Override Selected Transmitter Shutdown hex ’00 00 00 15’

This mode code command shall cause the NT to re-enable the transmitter on a specified redundant port that had previously been shut down. The transmitter that is to be enabled shall be identified in the 16-bit data word following the command. The NT shall respond with a status frame.

4.3.4.16 MIL-STD-1553B Status Word Mapping to FC-AE-1553

Table 11 shows the translation from MIL-STD-1553 status word to word 6 of the FC-AE-1553 status frame header. The FC-AE-1553 status frame header includes a 4-word device_header beyond the standard Fibre Channel header. The status frame is always sent in the first frame of a response to a command frame, and either may or may not include data words. The status frame bits map directly to the lower 11 bits of status header word 6 as shown in. The upper 21 bits are reserved, and shall be transmitted with each bit set to logic ‘0’. Word 7 is used to support NT-to-NT transfer exchanges involving Fibre Channel-to-1553 bridge(s).



38

Table 11. FC-AE-1553 Status Frame Header

Bits Word

31 – 24

23 – 16

15 – 8

7 - 0

0 R_CTL Destination ID (NC or NT Address)

1 CS_CTL Source ID (Local NT Address)

2 TYPE F_CTL

3 SEQ_ID DF_CTL SEQ_CNT

4 OX_ID RX_ID

5 Parameter

6

Reserved (21)

10: Message E

rror

9: Instrumentation

8: Service

7: Reserved (3

bits)

4: Broadcast C

md.

Rcvd.

3: Busy

2: Subsystem

Flag

1:Dynam

ic N

etwork C

trl.

0: Terminal Flag

7 Reserved

8 Reserved

9 Bridge for

Rx R

T for

NT

-to-NT

Transfer (1)

1553 BUS_ID for Rx RT for NT-to-NT

Transfer (7)

Reserved

(3)

RT Address for Rx MIL-

STD-1553 RT for NT-to-NT Transfer (5)

Bridge for

Source 1553

RT

(1)

1553 BUS_ID for Source RT

(7)

Reserved

(1)

No

Response

by 1553 RT

(1)

1553 RT

Form

at Error

(1)

RT Address for Source MIL-

STD-1553 RT (5)

4.3.4.16.1 Message Error Bit, bit 10

If the Message Error bit is a logic ‘1’, this indicates that either: (1) the combination of T/R* bit, Subaddress, and Word Count/Mode Code fields for the current exchange has been illegalized (i.e., not implemented) by the NT; or (2) for the response to a Transmit status or Transmit last command mode code exchange (but no other exchange types), that the previous exchange was illegal or that there was an error in the data portion (but not in the command portion) of the previous received exchange. In all other circumstances, this bit shall be logic ‘0’.

4.3.4.16.2 Instrumentation Bit, bit 9

The value of this bit shall always be logic ‘0’.

4.3.4.16.3 Service Request Bit, bit 8

The use and implementation of the Service Request Bit is optional. A Service Request Bit that is set to a value of logic ‘1’, shall indicate the need for the Network Controller to take specific predefined actions relative to either the NT or the associated subsystem. A Service Request Bit that is set to a logic ‘0’, shall indicate that either that the feature is not implemented by the NT, or the absence of a service request.

4.3.4.16.4 Broadcast Command Received Bit, bit 4

This bit shall be logic ‘0’ in all status frames except for a Transmit status mode code or Transmit last command mode code status frames. When the Broadcast Command Received bit is set to a logic ‘1’, this indicates that the most recently received valid command (other than these two mode codes) was a broadcast exchange. For these two mode codes, when this bit is logic ‘0’, this indicates that the most recently received valid command was not a broadcast exchange.



39

4.3.4.16.5 Busy Bit, bit 3

The use and implementation of the Busy Bit is optional. When the Busy Bit is set to a logic 1 this indicates that the NT or subsystem was unable to move data to or from the subsystem in compliance to the controller command frame. If not implemented, this bit shall always be logic ‘0’.

4.3.4.16.6 Subsystem Flag Bit, bit 2

The use and implementation of the Subsystem Flag Bit is optional and may be used to indicate a subsystem fault condition. A logic ‘1’ indicates a fault and a logic ‘0’ indicates no fault. If the Subsystem Flag Bit is not implemented, it shall be a logic ‘0’.

4.3.4.16.7 Dynamic Network Control Acceptance Bit, bit 1

The use and implementation of the Dynamic Network Control Acceptance Bit is optional and is used to indicate the acceptance or rejection of an offer to take control of the FC-AE-1553 network (see paragraph 4.3.4.15.1). This bit shall only be set to a logic ‘1’ to indicate that the NT has accepted the Network Controller function in response to a Dynamic Network Control mode command. For all other status frames, this bit shall be set to a logic ‘0’.

4.3.4.16.8 Terminal Flag Bit, bit 0

The use and implementation of the Terminal Flag Bit is optional. The Terminal Flag Bit may be used to indicate the presence of an NT fault condition. A logic ‘1’ shall indicate a fault condition. If not used, this bit shall be a logic ‘0’.

4.3.4.17 MIL-STD-1553 RT Addresses

Word 9 of the status frame header provides support for bridging to MIL-STD-1553 RTs. This provides an end-to-end acknowledgement to the NC that the correct MIL-STD-1553 RT received and responded to a particular exchange. In addition, for NT-to-NT and NT-to-multiple RTs transfers, there is an additional RT address field to enable routing by a FC-to-1553 bridge in the receiving NT to the receiving MIL-STD-1553 RT. For an NT embedded in a Fibre Channel-to-1553 bridge, bit 15 shall be logic ‘1’ and bits 4-0 shall represent the RT address of the MIL-STD-1553 RT that’s the source of the status frame. This provides an end-to-end acknowledgement from the MIL-STD-1553 RT back to the Fibre Channel NC. Bits 14-8 are an optional BUS_ID field that may be used to identify the specific MIL-STD-1553 bus that the RT is on; if not used, bits 14-8 shall be logic ‘0’. For an NT that is not embedded in a Fibre Channel-to-1553 bridge, bit 5 shall be logic ‘0’ and bits 14-8 and 4-0 shall not be used. To support NT-to-NT and NT-to-multiple NTs transfer exchanges involving Fibre Channel-to-1553 bridge(s), status frame header word 9 includes a provision for additional 1553 RT addressing information. If the receiving NT(s) for such an exchange includes a Fibre Channel-to-1553 bridge, then header word 9 of the NT status frame(s) sent by the transmitting NT to the receiving NT and the NC shall include the RT address of the receiving MIL-STD-1553 RT in bits 20-16 of header word 9; in addition, bit 31, Bridge to Rx RT for NT-to-NT Transfer, shall be logic ‘1’. Bits 30-24 are an optional BUS_ID field that may be used to identify the specific MIL-STD-1553 bus that the receiving RT is on; if not used, bits 30-24 shall be logic ‘0’. For the status frame(s) sent by the transmitting NT in an NT-to-NT or NT-to-multiple NTs transfer exchange in which the receiving NT(s) does not include an FC-to-1553 bridge, bit 31, Bridge to Rx RT for NT-to-NT Transfer shall be logic ‘0’ and bits 30-24 and 20-16 shall not be used. Also, for status frame header word 9 for all exchange formats other than NT-to-NT or NT-to-multiple RT transfers, bit 31 shall be logic ‘0’, and bits 30-24 and 20-16 shall not be used.

4.3.4.18 No Response by MIL-STD-1553 RT (bit 6 of Status Frame Header Word 9)

For an NT connected to a MIL-STD-1553 RT by means of a 1553-to-Fibre Channel bridge, this bit shall be logic ‘1’ if the RT does not respond within the time specified by MIL-STD-1553B; i.e., the 1553 BC in



40

the bridge must wait a minimum of 14 µs to determine that an RT has not responded. If this bit is logic ‘1’, the NT shall not transmit any data words. If the 1553 RT responds in time, this bit shall have a value of ‘0’. For all exchanges not involving a 1553-to-Fibre Channel bridge and a 1553 RT, the value of this bit shall be logic ‘0’.

4.3.4.19 1553 RT Format Error (bit 5 of Status Frame Header Word 9)

For an NT connected to a MIL-STD-1553 RT by means of a 1553-to-Fibre Channel bridge, this bit shall be logic ‘1’ if the RT responds within the required time, but its response does not meet the validity criteria specified by MIL-STD-1553B (i.e., correct RT address, word count, validity of all words, etc.). If this bit is logic ‘1’, the NT shall not transmit any data words. If the 1553 RT response is valid or the RT does not respond in time, this bit shall have a value of ‘0’. For all exchanges not involving a 1553-to-Fibre Channel bridge and a 1553 RT, the value of this bit shall be logic ‘0’.

4.3.5 FC-FS and FC-AL-2 Features for FC-AE-1553

Table 12 is a profile of the FC-FS and FC-AL-2 standards for arbitrated loop and fabric topologies. Devices that are compliant with FC-AE-1553 must comply with the mandatory features and implement the invocable features defined in FC-FS, unless noted herein. Table 12 identifies features that represent potential interoperability concerns and indicates whether they are Required, Invocable, Allowed, or Prohibited for FC-AE-1553 compliance. Features that are not listed do not affect interoperability of FC-AE-1553 devices. In addition to interoperability concerns, this profile addresses certain features that are needed in order to achieve the performance necessary for real-time avionics systems.

Table 12. FC-FS Features for FC-AE-1553

Feature Nx_Port Fx_Port Comment

Link Protocols Link Initialization R R Online-to-Offline to Online A A Link Failure R R Link Reset R R

Arbitrated Loop Characteristics


Loop Tenancy: Implementation -selectable maximum number of frame to the same destination

A A

Preferred Hard Addressing I A FC-AL Alternate Flow Control R A BB_Credit Minimum > 1 I -- Bypass Elements in Bypassed State at Power-up

A A

Open Broadcast Replicate I A Open Selective Replicate I A Loop Initialization I I Loop Port Enable A A Loop Port Bypass Circuit A A Loop Port Positional Mapping

A A

Dynamic Half-Duplex A A Old Port State A A Request Old Port State REQ (Old-Port) I I

Applicable only for NL_ports or FL_ports

Alias Addressing R R Sequential Delivery



41


Operation with Fabrics that do not guarantee sequential delivery

A --

Operation with Fabrics that guarantee sequential delivery

R --

TYPE Code = 01001000 R 256-byte Minimum Frame Size R R

Intermix Transmission of Class 2 Sequences during Dedicated Connections

A A

Transmission of Class 3 Sequences during Dedicated Connections

A A

Capability to receive Intermixed Class 2 or Class 3 frames during reception of Class 1 Sequence

A A

R_CTL Field R_CTL Routing Bits set to Hex “0” (FC-4 Device Data Frame)

R --

R_CTL Information category types Type 0 P -- Type 1 I -- Solicited data frame, transmitted by

NTs. Type 2 P -- Type 3 P -- Type 4 I -- Unsolicited data frame, sent by NC Type 5 P -- Type 6 I -- Command frame, plus first frame of

(unsolicited) data, transmitted by NCs. Type 7 I -- Status frame, plus first frame of

(solicited) data, transmitted by NTs. Type 8 P -- Type 9 P -- Concurrent Sequences > 16 R -

BB_Credit Minimum > 1 R R Descending order BB_Credit R R

N_Port EE_Credit > 2 (Classes 1, 2, 4, 6)

I -

Max BB Receive Data Field Size > 2048 I - Open Sequences per Exchange > 1 P -- Use of Parameter Field as Relative Offset

A --

Optional Headers Network Header P -- Device Header R -- For FC-AE-1553 command frames

(reference Table 10) and status frames (reference Table 11), the four words following the 6-word Fibre Channel header are the FC-AE-1553 device_header. There is no device header for FC-AE-1553 data frames.

Association Header P --



42


Initial Process Associator = ’00’b R --

Extended Link Services Clock Sync – Server A A Clock Sync – Client I I

Fabric Login Explicit Login I I

Implicit Login I I Implicit login is encouraged. F_Port Login -- Common Service Login Parameters

Registered A A Non-Registered A A BB_Credit > 1 R R E_D_TOV Resolution = 0 -- R 1 ms. Multicast A A Broadcast I I Hunt Group P P FLOGI Payload Length = 0 R R min R_A_TOV < 100ms I I min c < 50ms I I R_T_TOV value = 100 µs I I

N_Port Login Explicit Login I -- Implicit Login I -- Implicit login is encouraged.

Port Name Format Registered A -- Non-Registered A --

N_Port Login – Common Service Parameters BB_Credit > 1 R - Max BB Receive Data Field Size > 2048 I - Continuously Increasing Relative Offset A - Random Relative Offset A - (Continuously Increasing) SEQ_CNT R - Alternate BB_Credit Management P - PLOGI Payload Length = 0 R - Total Concurrent Sequences > 16 I - Relative Offset by Information Category A -

Class-Specific Login Parameters Class 1 A A

Stacked connect-requests A A Buffered Class 1 -- A ACK_0 I -- ACK_1 A -- Preempt Enable Flag A A Recipient X_ID Interlock A - Priority I I

Class 2 A A ACK_0 I -- ACK_1 A -- Priority I I Recipient X_ID Interlock A -- ACK Generation Assistance A --



43


N_Port EE_Credit = 2 R -- Open Sequences per Exchange = 1 R --

Class 3 I I Class 3 single cast R A Class 3 multicast A A Class 3 broadcast I I Open Broadcast Replicate I A Only applicable for loop ports Selective Broadcast Replicate A A Only applicable for loop ports Alias addressing A A Priority I I

Class 4 A A ACK_0 I -- ACK_1 A --

Class 6 A A Stacked connect-requests -- R Buffered Class 1 -- A ACK_0 I -- ACK_1 A -- Preempt Enable Flag A A Priority I R Fabric Reject Reason Codes

hex ’01’ Invalid D_ID A A hex ’03’ N_Port not available, temporarily A A hex ’04’ N_Port not available, permanently

A A

hex ’05’ Class of service not supported A A hex ’16’ Login required A A Others A A

Fabric Busy Codes hex ‘1’ Fabric is Busy I A Hex ‘3’ D_ID busy with a Class 1 connection

-- P

Port Reject Frames I -- Port Busy Frames I -- Well Known Address Support

Hex ’FF FF FF’ (Broadcast) I I Hex ’FF FF FE’ (F_Port Server) -- I Hex ’FF FF FD’ (Fabric Controller) -- I Hex ’FF FF FC’ (Directory/Name Server) A A Hex ‘FF FF FB’ (Time Server) A A Hex ‘FF FF FA’ (Management Server) A A Hex ’FF FF F8’ (Alias Server) A A Hex ’FF FF F6’ (Clock Sync Server) A A Implicit N_Port login R - Multicast capable I I Hunt Groups A A

Basic Link Services BA_ACC I -- BA_RJT I -- ABTS I -- RMC A A



44


PRMT A A Extended Link Services

CSR I I CSU I I FARP-REQ A A FARP-REPLY A A FDISC A A PDISC A -- FLOGI I I LOGO I I PDISC A A PLOGI A A RLS A A RSCN A A SCR A A Others A A

4.3.5.1 Fabric-Specific Features

4.3.5.1.1 Description

This section describes the Fibre Channel fabric-specific features used in FC-AE-1553.

4.3.5.1.2 Login / Logout

All devices complying with FC-AE-1553 profile may support Explicit Fabric login/logout (F_LOGI). All devices complying with this profile shall support implicit Fabric login/logout and may include the capability to be initialized by an entity outside the bounds of the Fibre Channel standards. The specific login mechanization shall be defined by the specific system interface requirements. If explicit login is used, the S_ID of the Nodes shall be hex ’00 00 00’ prior to login.

4.3.5.1.2.1 Fabric Login – Common Service Parameters

BB_Credit shall be at least 1.

The Max BB Receive Data Field Size shall be at least 2048 bytes.

Alternate BB_Credit Management is required for operation on Arbitrated Loops. Alternate BB_Credit Management shall not be used in non-loop topologies.

Time-out values may be determined by the system designer. The minimum E_D_TOV and minimum R_A_TOV values shown in Table 12 are provided as recommended values for real-time avionics systems. The short R_T_TOV value is Invocable.

Extended length Fabric login payloads is prohibited.

The use of Hunt Groups is allowed.

4.3.5.1.2.2 Fabric Login – Class Specific Service Parameters

Class 3 shall be supported. Login is valid for Class 3 regardless of which Class of Service is used for FLOGI. Sequential Delivery shall be Invocable for fabrics and Allowed for nodes. Support for the Preference function is Invocable for both F*_ports and N*_ports . The fabric will route frames with the Preference bit set ahead of frames without the bit set.

Clock Synchronization using the ELS method is Invocable for both fabrics and nodes. In order to reduce complexity of compliant nodes, the Clock Sync Server is required to be within the fabric in this profile.



45

4.3.5.1.3 Link Protocols.

All N_Port and fabric devices complying with this profile shall support and utilize the Link Initialization, Link Reset, and Link Failure protocols. In addition, they may support the Online-to-Offline protocol and shall correctly respond when connected to another N_Port or F_Port that initiates this protocol. 4.3.5.1.4 Basic Link Services

All devices complying with this profile shall support the Basic Link Services as defined in FC-FS.

4.3.5.1.5 Broadcast Support

For Class 3, all devices shall support the well-known broadcast address of hex ‘FF FF FF’. Class 6 Service is allowed.

4.3.5.1.6 Camp-on

The use of camp-on by devices complying with this profile is prohibited.

4.3.5.2 Arbitrated Loop-Specific Features

4.3.5.2.1 Description:

This section will describe the Fibre Channel Arbitrated Loop features used in FC-AE-1553.

4.3.5.2.2 Loop Port State Machine (LPSM):

The Loop Port State Machine (LPSM) is Allowed. If the LPSM is implemented, then the port is an NL_Port or an FL_Port. Otherwise, the port is an N_Port or an F_Port. The items indented under LPSM are only applicable if the LPSM is implemented. Loop Initialization Protocol is Invocable (but not Required) because this enables the System Designer to implement a system using “Implicit LIP”. LIP must be implemented to insure interoperability with devices that only support “Explicit LIP”. If Implicit LIP is used it is up to the System Designer to figure out how to provide all the necessary information to the nodes.

• NOTE - In the interest of achieving faster start-up times, the use of Implicit LIP and Login are encouraged. If explicit LIP is used, it may be accelerated by skipping Loop Port Positional Mapping. Loop Port Positional Mapping is allowed, but is generally not needed for embedded avionics systems.

• NOTE - The use of a centralized hub may be desirable, depending on the number of nodes involved. A Hub provides a centralized location for wire routing and the ability to isolate faulty nodes or wiring without affecting the rest of the loop.

4.3.5.2.3 Loop Port Bypass:

Loop port bypass, the optional bypass circuit, and Loop Port Enable primitive sequences, which control access to the loop, are allowed.

4.3.5.2.4 Receive Buffers:

All nodes shall support a minimum of two receive buffers of 2048 bytes of Fibre Channel payload.

4.3.5.2.5 Broadcast Support:

All L_Ports shall support open broadcast replicate.

4.3.5.2.6 Multicast Support:

All L_Ports shall support open selective replicate.

4.3.5.2.7 AL_PA Addressing:

All ports shall use preferred hard addressing.



46

4.3.5.2.8 Dynamic Half Duplex:

The use of Dynamic Half Duplex is Allowed by devices complying with FC-AE-1553 profile.

4.3.5.2.9 Credit Management:

Alternate BB_Credit Management is required. All ports shall log in with a BB_Credit value of at least 1.

4.3.5.2.10 Loop Tenancies:

The maximum number of frames that each port may transmit to the same destination may be made selectable for each implementation. After this maximum number of frames has been transmitted, the port must then relinquish the loop. All ports shall implement and use loop fairness. • NOTE - Dynamic Half Duplex, Login BB_Credit, and Loop Tenancy are only some of the parameters

that affect loop performance. Other parameters that should be considered include:

o whether to allow outstanding R_RDYs when the loop circuit is closed (referred to as “unbalanced” BB_Credit),

o the amount of data to be transferred during each loop tenancy, o the arbitration time, o the round trip time, and the time required to empty the buffers.

4.3.5.2.11 OLD_PORT State:

The capability to operate in OLD_PORT state is desirable in order for a 2-node pair to operate in point-to-point mode as opposed to operating as a 2-node loop. There are two ways to enter OLD_PORT state: (1) one node in the pair doesn’t support LPSM, or (2) both nodes support LPSM but OLD_PORT state is requested. The ability to request Old Port state is Invocable.

4.3.5.3 N_Port Login

All devices complying with FC-AE-1553 profile may support Explicit N_Port login/logout. All devices complying with this profile shall support Implicit N_Port login/logout and may include the capability to be initialized by an entity outside the bounds of the Fibre Channel standards. The specific login mechanization shall be defined by the specific system interface requirements.

4.3.5.3.1 Classes of Service Supported:

Class 3 service shall be supported. Classes 1, 2, 4, and 6 service are allowed.

4.3.5.3.2 N_Port Login – Common Service Parameters

As in FLOGI, BB_Credit shall be at least 1 and the Max BB Receive Data Field Size must be at least 2048 bytes, which includes the Device Header. In N_Port Login, these parameters only apply to point-to-point topologies.

Continuously Increasing Relative Offset and Sequence Count are allowed.

Total Concurrent Sequences must be at least 16.

The use of relative offset, including random relative offset, may be used. If relative offset is used, Network Controllers shall not include any data words in their command frame transmission, and NTs shall not include any data words in their status frame transmission. FC-AE-1553 requires the use of broadcast and allows the use of multicast.

Continuously increasing sequence count is required.

Extended length Port login payloads shall not be used.

4.3.5.3.3 N_Port Login – Class 1 Service Parameters

Class 1 service is allowed. If used, the use of priority is invocable, with preemption allowed. ACK_0 acknowledgement is invocable and encouraged, while ACK_1 is allowed.



47

The use of stacked connect requests and buffered Class 1 are allowed. Recipient X_ID interlock is allowed.


Class 2 service is allowed. If used, priority is invocable for both N*_Ports and F*_Ports. If used, initiators and recipients must be capable of supporting ACK 0 as an Initiator or Recipient, which will be negotiated at Login. However, it should be understood that if both N_Ports specify support for ACK 0, ACK 0 must always be used.

ACK Generation Assistance is Allowed. ACK Generation Assistance merely indicates that the ACK Form bits will be set accordingly in F_CTL by the Initiator.

N_Port EE_Credit must be at least 2 at login. Having at least 2 Credits allows frames to be received and processed simultaneously from each node.

Another performance oriented parameter is Open Sequences per Exchange. The minimum requirement is one, but performance could be improved if it were greater than 1.


Class 3 service is must be supported. Since acknowledgement is provided at the ULP level, Class 3 is well suited for FC-AE-1553. Login is valid for Class 3 regardless of which Class of Service is used for N_Port Login.

Singlecast is required; broadcast, including open broadcast replicate for loops, is invocable; and multicast, including selective replicate for loops, is allowed. For Class 3, priority is invocable, and alias addressing is allowed.


Class 4 service is allowed. If used, ACK_0 is encouraged and invocable, while ACK_1 is allowed.


Class 6 service is allowed. If used, stacked connect requests must be supported by the fabric, while buffered Class 1 is allowed. ACK_0 is encouraged and invocable, while ACK_1 is allowed. Priority is required for N*_Ports and F*_Ports, and preemption is invocable for N*_Ports and required by F*_Ports.

4.3.5.4 FC-FS Header Fields

4.3.5.4.1 Frame Control (F_CTL)

All devices complying with this profile shall support the following F_CTL options:

Bit 17 Priority Enable – Priority Enable may be asserted on all Class 1, 2, 3, and 6 frames for fabric operation. Priority Enable shall not be used for private loop operation.

Bit 16 Sequence Initiative – Sequence Initiative transfer on the last Sequence of an Exchange shall be supported. Sequence Initiative transferred shall be ‘1’ (transfer) for Network Controller IU types NC1, NC4, and NC5 (refer to Table 7), and NT IU types NT1, NT4, NT5, and NT8 (refer to Table 8). Sequence Initiative transferred shall be ‘0’ (hold) for Network Controller IU types NC2, NC3, NC6, and NC7 (refer to Table 7), and NT IU types NT2, NT3, NT6, and NT7 (refer to Table 8). Bit 15 X_ID Reassignment – X_ID reassignment is obsolete. Bit 14 Invalidate X_ID – X_ID invalidation is obsolete. Bits 13-12 ACK_Form – ACK_N is obsolete. ACK_0 shall be the default and ACK_1 is allowed.



48

Bits 7-6 - Continue Sequence Condition – These bits should have a value of ‘00’b for all sequences. Bits 5-4 Abort Sequence Condition – A value of ‘01’b; Abort, Discard a single Sequence, shall be supported.

Bit 3 Relative Offset Present – is Allowable. For all FC-AE-1553 frames, if this bit is ‘1’, the Parameter field shall hold the relative running offset of the data being transferred. The sequence recipient shall indicate support for relative offset, but is not required to use it to manage sequence order. If relative offset is used, Network Controllers shall not include any data words in their command frame transmission, and NTs shall not include any data words in their status frame transmission.

4.3.5.4.2 Sequence Identifier (SEQ_ID)

SEQ_ID shall be used to uniquely identify a sequence within an FC-AE-1553 exchange. The rules governing the use of SEQ_ID shall conform to FC-FS guidelines.

4.3.5.4.3 Data Field Control (DF_CTL)

For all FC-AE-1553 frames, DF_CTL field bits 23-18 shall all be ‘0’. For FC-AE-1553 command and status frames, DF_CTL field bits 17-16 shall be ‘01’, indicating a 16-byte device_header. For FC-AE-1553 data frames, DF_CTL field bits 23-18 shall be ‘00’, indicating no device_header.

4.3.5.4.4 X_ID Interlock

X_ID interlock as defined in FC-FS may be used for Class 1 and Class 2 operation. Use of X_ID Interlock shall be negotiated at N_Port login.

4.3.5.4.5 Sequence Count (SEQ_CNT)

SEQ_CNT shall be used as specified in FC-FS for counting and ordering frames within a sequence. SEQ_CNT shall be monotonically increasing.

4.3.5.4.6 Originator Exchange Identifier (OX_ID)

OX_ID shall be used by the exchange originator as specified in FC-FS.

4.3.5.4.7 Responder Exchange Identifier (RX_ID)

Responder Exchange Identifier (RX_ID) shall be used by the responder in an Exchange as specified in FC-FS.

4.3.5.5 Fabric Reject/Fabric Busy

Fabric Reject frames are Invocable with the Reason Codes listed in the Table 12. Certain Reason Codes are required to be supported. Others are allowed, within the bounds of what is applicable for Class 2.

Fabric Busy frames are Allowed.

4.3.5.6 Port Reject/Port Busy

Port Reject and Port Busy frames are Invocable as an Initiator and as a Recipient. Reason codes are left to the System Designer, but must fall within the bounds of what is applicable for Class 2.


Support for the Abort Sequence Protocol is Invocable by N*_Ports.


Clock Sync Request is Invocable. The N*_Port is the initiator. Note that CSR can be directed to the Clock Sync Server or the Fabric Controller.



49

Clock Sync Update is Invocable. In this profile, The N*_Port is always the recipient since the server is in the fabric. The Clock Sync Server may use Multicast for transmitting CSU. N*_Ports shall be able to receive the Multicast alias address if used.

Support for FARP is allowed, even though it will not likely be used by devices following this profile.

Explicit fabric login, port login, and logout are all invocable.

RLS is Invocable. All N*_Ports and Fx_Ports must contain a Link Error Status Block and be able to reply to an RLS command. Only certain nodes must be capable of sending an RLS command.

RSCN is Invocable. N*_Ports must be capable of sending a State Change Notification to the Fabric Controller. The Fabric Controller would then issue an RSCN to all registered N*_Ports. The Fabric Controller may use Multicast for transmitting the RSCN. N*_Ports must be able to receive the Multicast alias address if used.

SCR is Invocable, but only nodes responsible for error detection will be required to register with the Fabric Controller for state change notification.

Other ELS commands are allowed, but devices that receive requests for ELSs not supported will return LS_RJT with reason code “Invalid Command Code”.

4.3.5.9 Well Known Address Support

Use of the broadcast well known address is invocable.

Name Server is Allowed. However, the use of pre-defined addresses is recommended which eliminates the need for the Name Server.

Alias Server is Allowed. Pre-defined look-up tables are recommended which eliminates the need for an Alias Server.

The Clock Sync Server, supporting the ELS method, is Invocable in the fabric. The Clock Sync Server is logged in implicitly.

The F_Port server is Invocable for Explicit Fabric Login and certain ELS commands.

The Fabric Controller is Invocable for certain ELS commands.

Since this profile does not allow extended length Login payloads, the presence of any server must be discovered through some other means.



50

4.4 Virtual Interface (VI)

This FC-AE profile follows the FC-VI and FC-FS standards in its definition of the services necessary to support low-latency, low overhead communication between elements of a mission-critical avionics system. The mnemonic used to define this profile shall be FC-AE-VI.

4.4.1 FC-VI Features for FC-AE-VI

Error! Reference source not found. is a profile of the FC-VI standard for arbitrated loop and fabric topologies. Devices that are compliant with FC-AE-VI must comply with the mandatory features defined in FC-VI. identifies optional features that represent potential interoperability concerns and indicates whether they are Required, Invocable, Allowed, or Prohibited for FC-AE-VI compliance.

Table 11 FC-VI Features for FC-AE-VI

FC-VI Features Nx_Port Fx_Port Notes

Connection Models

Client -Server I -

Peer-to-Peer I -

Transfer Models

Send I - Required in FC-VI

Sending Immediate Data I -

RDMA read I -

RDMA write I - Required in FC-VI

Sending Immediate Data I -

FCVI_Attributes

FCVI_RELIABILITY_LVL

FC-VI unreliable delivery, x’01’ I - Required in VI

FC-VI reliable delivery, x’02’ I -

FC-VI reliable reception, x’03’ A -

FCVI_MAX_TRANS_SIZE > 256kBytes I -

FCVI_QOS

FCVI_PREF I I

FCVI_MAX_BANDWIDTH ≠ 0 P -



51

FC-VI Features Nx_Port Fx_Port Notes

FCVI_MIN_BANDWIDTH ≠ 0 P -

FCVI_MAX_DELAY ≠ 0 P -

FCVI_PIPELINE_DEPTH > 0 A - Only applies to Reliable mode

FCVI_Addressing

Name Server A

FARP I

other I Pre-defined Addresses

4.4.1.1 Connection Models

FC-AE-VI compliant nodes shall support both the Client-Server and the Peer-to-Peer connection models. Since the use of a particular connection model is application dependent, these connection models are Invocable, instead of being Required.

4.4.1.2 Transfer Models

FC-AE-VI compliant nodes shall support all three data transfer models -- Send, RDMA read, and RDMA write. In addition, the sending and receiving of immediate data shall be supported for the Send and RDMA write transfer models. Since the use of a particular connection model is application dependent, these transfer models are Invocable, instead of being Required.

4.4.1.3 FCVI_Attributes

FC-AE-VI compliant nodes shall support reliability levels of Unreliable Delivery and Reliable Delivery. Since the use of a particular reliability level is application dependent, these reliability levels are Invocable, instead of being Required.

The Reliable Reception reliability level is Allowed. The VI Architecture requires that the reliability levels of the endpoints match in order for a connection to be made. Mismatching reliability levels are discovered either implicitly or explicitly (during the connection setup process).

The maximum message size supported by FC-AE-VI compliant nodes shall be no less than 256 KBytes.

FC-AE-VI compliant nodes shall support the setting of the FCVI_PREF attribute to any value allowed by the FC-VI standard.

The FCVI_MAX_BANDWIDTH, FCVI_MIN_BANDWIDTH, and FCVI_MAX_DELAY attributes shall be set to zero by compliant nodes.

Baseline FC-AE-VI compliant nodes may set the FCVI_PIPELINE_DEPTH attribute to zero which means that only one message can be open at a time. For performance reasons, System Designers may need to require nodes to support a greater Pipeline Depth and therefore larger values are Allowed.



52

4.4.1.4 FCVI_Addressing

FC-AE-VI compliant nodes shall support FARP, but the use of pre-defined addresses is Invocable and recommended. Avionics implementations are well-defined and configurations change infrequently. The use of pre-defined addresses also eliminates the time spent performing FARP or accessing the Name Server, not to mention reducing complexity and cost in the nodes and the fabric.

• NOTE - There are several techniques defined for Address Resolution. FC-VI requires all implementations to be capable of initiating a FARP-REQ and responding to a received FARP -REQ with a FARP -REPLY. If an FC-VI Port is attached to a Fabric that supports a Name Server, the Name Server should be used in lieu of FARP. Finally, “alternative methods” for address resolution are Allowed as long as FARP is supported. See reference [13]

4.4.2 FC-FS and FC-AL2 Features for FC-AE-VI

Table x is a profile of the FC-FS and FC-AL2 standards primarily for arbitrated loop and fabric topologies. Devices that are compliant with FC-AE-VI must comply with the mandatory features defined in FC-FS and FC-AL2, unless noted herein. identifies optional features that represent potential interoperability concerns and indicates whether they are Required, Invocable, Allowed, or Prohibited for FC-AE-VI compliance. Features that are not listed do not affect interoperability of FC-AE-VI devices. In addition to interoperability concerns, this profile addresses certain features that are needed in order to achieve the performance necessary for real-time avionics systems. More information is provided after the table.

Items that are clearly defined in FC-VI are not restated here. For example, requirements for R_CTL and the Type code in the Header and the use of the optional Device Header are defined in FC-VI.

In many cases, these features shown in have Login Parameters associated with them. For features that are Required or Invocable, the corresponding login parameters shall indicate that the feature is supported. For features that are Prohibited, the corresponding login parameters may indicate that the feature is supported, even though the feature will not be used by compliant implementations. For features that are Allowed, the corresponding login parameters shall reflect whether or not the feature is supported by the implementation.

FC-FS/FC-AL2 Features Nx_Port Fx_Port Notes

Link Protocols


Online to Offline A A

Link Failure R R

Link Reset R R


Loop Protocols






53


Loop Port Bypass Circuit A A

Hard Addressing I I

Loop Port Position Mapping A A


Login BB_Credit > 1 I I

Programmable Loop Tenancy A A

Broadcast Open Replicate – OPN(fr) I I Needed for FARP

Old Port State I I


Fabric Login

Explicit Login I I

S_ID = hex ’00 00 00’ R I

Implicit Login A A

Node/Fabric Name Format

Registered A A

Non-Registered A A

Fabric Login – Common Service Parameters

BB_Credit > 2 R R

Max BB Receive Data Field Size > 2048 I I Includes Device Header

E_D_TOV Resolution = 0 - R 1 ms

Alternate BB_Credit Management P P In non-loop topologies

Multicast P P Not used in FC-VI

Broadcast I I Needed for FARP

Hunt Group P P Not used in FC-VI



54


FLOGI Payload Length = 0 R R 116 bytes

min R_A_TOV < 100ms I I

min E_D_TOV < 50ms I I

R_T_TOV Value I I < 1ms

Fabric Login – Class Specific Service Parameters

Class of Service

Class 1 P P

Class 2 I I

Class 3 I I

Class 4 P P

Class 6 P P

Sequential Delivery A I

Priority P P Not used in FC-VI

Preference I I

Clock Sync Primitive Capable P P

Clock Sync ELS Capable I I Server is in the fabric

N_Port Login

Explicit Login I -

Implicit Login A -

Port Name Format

Registered A -

Non-Registered A -

N_Port Login – Common Service Parameters

BB_Credit > 2 R - point-to-point

Max BB Receive Data Field Size > 2048 I -



55


Continuously Increasing Relative Offset R - Required by FC-VI

Random Relative Offset P -

(Continuously Increasing)SEQ_CNT R - Required by FC-VI

Alternate BB_Credit Management P - In point-to-point case

PLOGI Payload Length = 0 R - 116 bytes

Total Concurrent Sequences > 16 I -

Relative Offset by Information Category R - per FC-VI


N_Port Login – Class Specific Service Parameters

Class of Service

Class 1 P P

Class 2 I I

Class 3 I I

Class 4 P P

Class 6 P P

N_Port Login – Class 2 Service Parameters


Priority P - Not used in FC-VI

Preference I -

Initial Process Associator = ’00’b R - Process Associators not used in FC-VI

Recipient X_ID Interlock P -

ACK 0 Initiator/Recipient Capable I -

ACK Generation Assistance A -

Initiator Clock Sync ELS Capable P - Server is in the fabric



56


fabric

Recipient Clock Sync ELS Capable A -

Concurrent Sequences > 16 R -

N_Port EE_Credit > 2 I -

Open Sequences per Exchange > 1 I -



Priority bit P - Not used in FC-VI

Preference I -

Initial Process Associator = ’00’b R - Process Associators not used in FC-VI


Recipient Clock Sync ELS Capable I -



Fabric Reject Reason Codes

hex ’01’ Invalid D_ID I I

hex ’03’ N_Port not available, temporarily I A

hex ’04’ N_Port not available, permanently I I

hex ’05’ Class of service not supported I I

hex ’16’ Login required I I

Others I A Within the bounds of Class 2

Fabric Busy Reason Codes

hex ’1’ Fabric is Busy I A



57


hex ’3’ D_ID busy with a Class 1 connection - P

Port Reject Frames I - Reason codes not specified

Port Busy Frames I - Reason codes not specified

Well Known Address Support

hex ’FF FF FF’ (Broadcast) I I Required for FARP

hex ’FF FF FE’ (F_Port Server) - I

hex ’FF FF FD’ (Fabric Controller) - I

Multicast capable I I For RSCN

hex ’FF FF FC’ (Directory/Name Server) A A

hex ’FF FF F8’ (Alias Server) A A Prefer pre-defined addresses

hex ’FF FF F6’ (Clock Sync Server) P I

Implicit N_Port login R -

Multicast capable I I For CSU

Others P -

Class of Service to/from WKA

Class 3 I I

Class 2 P P

others P P

Basic Link Services

BA_ACC I -

BA_RJT I -

ABTS I -

Others P P



58



CSR I I To the Clock Sync Server only

CSU I I

FARP-REQ I I Support required in FC-VI

FARP-REPLY I I Support required in FC-VI

FDISC A A

FLOGI I I

LOGO I -

PDISC A -

PLOGI I -

RLS I I

RSCN I I

SCR I I

Others A A


Support of basic Link Initialization described in FC-FS is required and will be used at power up or upon re-initialization. Link Failure and Link Reset protocols must be implemented, and will be used as needed. Online-to-Offline protocol is Allowed but not required because typically an Offline state is not needed in avionics systems. The equipment will operate until power is removed.


This profile was written primarily for switched fabrics, which may include attached loops. Although there is no inherent restriction on the use of a Private loop with the FC-AE-VI profile that topology is not addressed specifically.

The Loop Port State Machine (LPSM) is Allowed. If the LPSM is implemented, then the port is an NL_Port or an FL_Port. Otherwise, the port is an N_Port or an F_Port. The items indented under LPSM are only applicable if the LPSM is implemented.

Loop Initialization Protocol is Invocable (but not Required) because this enables the System Designer to implement a system using Implicit LIP in order to achieve faster start-up times. Implicit LIP must be implemented in such a way to insure interoperability with devices that only support “Explicit LIP”. If



59

Implicit LIP is used it is up to the System Designer to figure out how to provide all the necessary information to the nodes, such as AL_PA assignments.

If Explicit LIP is used, Loop Initialization Hard Addressing (LIHA) is Invocable during AL_PA Assignment.

• NOTE - Hard Addressing is desirable in avionics networks because every node gets the same address every time the loop is initialized.

If Explicit LIP is used, it can be speeded up by not doing Loop Port Position Mapping. Loop Port Position Mapping is Allowed, but is generally not needed for embedded avionics systems.


Loop Port Bypass and Loop Port Enable Primitive Sequences, which control access to the loop, are Invocable. The optional Bypass circuit is Allowed.

Dynamic Half Duplex is Allowed and encouraged because it improves bandwidth utilization.

Specifying Login BB_Credit > 1 is Invocable. Login BB_Credit is used to set the available BB_Credit every time the loop circuit is opened. If login BB_Credit is > 1, and the transmitting port remembers the value, the transmitting port doesn’t have to wait for an R_RDY to begin sending frames. Programmable Loop Tenancy is Allowed. This feature gives the system designer the ability to set the maximum Loop Tenancy of a loop port in firmware/hardware if desired. Alternatively, the loop tenancy may be controlled in software. • NOTE - Dynamic Half Duplex, Login BB_Credit, and Loop Tenancy are only some of the parameters



o the amount of data to be transferred during each loop tenancy, o the arbitration time, o the round trip time, and o the time required to empty the buffers.

Broadcast Open Replicate is Invocable because compliant FC-VI devices shall support FARP.

The capability to operate in OLD_PORT state is desirable in order for a 2-node pair to operate in point-to-point mode as opposed to operating as a 2-node loop. There are two ways to enter OLD_PORT state: 1) one node in the pair doesn’t support LPSM, or 2) both nodes support LPSM but OLD_PORT state is requested. The ability to request Old Port state is Invocable.


Explicit Fabric Login is Invocable (but not Required) because this enables the System Designer to implement a system using Implicit Login. Explicit Fabric Login will normally be used. If Implicit Login is used it is up to the System Designer to figure out how to provide all the necessary information to the fabric and the attached nodes.

• NOTE - If Loops are not present, it is highly desirable to disable the attempt to perform LIP at initialization, if possible in order to achieve faster start-up times.

The S_ID of the Nodes shall be hex ’00 00 00’ at login. This will reduce the complexity of the Nx_Ports.

Either Registered or Non-registered names are Allowed. The only requirement is that all names in the system must be unique.



60

4.4.2.3.1 Fabric Login – Common Service Parameters

BB_Credit shall be at least 2 in order to allow data frames to be received and processed simultaneously by N_Ports and F_Ports.

The Max BB Receive Data Field Size must be at least 2048 bytes, which includes a Device Header that is either 16 or 32 bytes.

Alternate BB_Credit Management is required in Arbitrated Loops, but will not be used in non-loop topologies.

Time-out values are determined by the System Designer. The Minimum E_D_TOV and Minimum R_A_TOV values shown are provided as guidelines for real-time avionics systems. The short R_T_TOV Value, which enables quicker detection of Loss Of Sync, is Invocable. For the purposes of this profile, the short R_T_TOV value shall be less than or equal to 1 msec with a goal of achieving 100us in the future. This is a deviation from FC-FS which specifies that the short value will be 100us.

Extended length Fabric login payloads will not be used.

4.4.2.3.2 Fabric Login – Class Specific Service Parameters

Class 2 and 3 must be supported. Login is valid for Class 2 and 3 regardless of which Class of Service is used for FLOGI. Sequential Delivery is Invocable for fabrics and Allowed for nodes. Sequential Delivery simplifies re-assembly and error detection at the recipient node.

Support for the Preference function is Invocable for fabrics and nodes. The fabric will route frames with the Preference bit set ahead of frames without the bit set.

Clock Synchronization using the ELS Method is Invocable for both fabrics and nodes. In order to reduce complexity of compliant nodes, the Clock Sync Server is required to be within the fabric in this profile.


Similar to FLOGI, Explicit N_Port Login is Invocable (but not Required) because this enables the System Designer to implement a system using Implicit Login. Explicit N_Port Login will normally be used. If Implicit Login is used it is up to the System Designer to figure out how to provide all the necessary information to the nodes.


As in FLOGI, BB_Credit shall be at least 2.In N_Port Login, this only applies to point-to-point topologies. It is also used to set the Login BB_Credit for Loop devices operating on the same arbitrated loop, but that is specified in 4.4.2.2.

Max BB Receive Data Field Size must be at least 2048 bytes, which includes the Device Header.

Continuously Increasing Relative Offset and Sequence Count are required by FC-VI.

Total Concurrent Sequences must be > 16. This requirement is included for performance reasons rather than interoperability purposes.

FC-VI does not support the use of Multicast. However, Multicast may be used for certain ELS commands.


The E_D_TOV specified here is used for nodes in point-to-point topology and also between nodes on the same arbitrated loop. As in FLOGI, the value listed is a guideline for real-time avionics systems.


Class 2 must be supported. Login is valid for Class 2 and 3 regardless of which Class of Service is used for N_Port Login.



61

Initiators and Recipients must be capable of supporting ACK 0 as an Initiator or Recipient, which will be negotiated at Login. However, it should be understood that if both N_Ports specify support for ACK 0, ACK 0 must always be used.


Initiator Clock Sync ELS is Prohibited in the nodes. The Clock Sync server will be within the fabric in this profile.

Recipient Clock Sync ELS is Allowed in Class 2, however, the Clock Sync server is only required to operate in Class 3 in this profile.

Class 2 Concurrent Sequences must be > 16. This parameter is included for performance reasons rather than interoperability purposes.


Another performance oriented parameter is Open Sequences per Exchange. The minimum requirement is 1, but performance could be improved if it were greater than 1.



Initiator Clock Sync ELS is Prohibited in the nodes. The Clock Sync server will be within the fabric in this profile. Recipient Clock Sync ELS is Invocable in Class 3.

Class 3 Concurrent Sequences must be > 16. This requirement is included for performance reasons rather than interoperability purposes.

Another performance oriented parameter is Open Sequences per Exchange. The requirement is 1, but performance could be improved if it were greater than 1. This is particularly true in Class 3 because with no ACK frames, the initiator is supposed to wait R_A_TOV after transmitting a sequence to free up resources and begin another sequence,


Fabric Reject frames are Invocable with the Reason Codes listed in the Table. Certain Reason Codes are required to be supported. Others are Allowed, within the bounds of what is applicable for Class 2.

Fabric Busy frames are Allowed. Fabric Busy may not be used in small fabrics. Port Busy may be used instead. However, nodes must be able to accept F_BSY if one is sent by the fabric.




Broadcast is Invocable because it is needed for FARP. All FC-VI compliant devices must support the use of FARP.

Name Server is Allowed. FC-VI allows for alternative methods of address resolution. The use of pre-defined addresses is Allowed (and encouraged) which eliminates the need for the Name Server.

Alias Server is Allowed. However, since FC-VI does not have any provisions for Multicast or Hunt Groups, alias address usage will be limited to certain ELS commands. Pre-defined look-up tables are Allowed (and encouraged) which eliminates the need for an Alias Server.



62



The Fabric Controller is Invocable for certain ELS commands.

Since this profile does not allow extended length Login payloads, the presence of any server must be discovered through some other means. The Class of Service to/from Well Known Addresses is restricted to Class 3 in this profile. This simplifies the servers and to a lesser extent, the nodes.


Support for the Abort Sequence Protocol is Invocable by Nx_Ports.


Clock Sync Request is Invocable. The Nx_Port is the Initiator. CSR can be directed to the Clock Sync Server or the Fabric Controller. Support in the Clock Sync Server is Invocable. Support in the Fabric Controller is Allowed.

Clock Sync Update is Invocable. In this profile, The Nx_Port is always the Recipient since the server is in the fabric. The Clock Sync Server may use Multicast for transmitting CSU. Nx_Ports must be able to receive the Multicast alias address if used.

Support for FARP is Invocable by compliant nodes and fabrics, even though it will not likely be used by devices following this profile.

RLS is Invocable. All Nx_Ports and Fx_Ports must contain a Link Error Status Block and be able to reply to an RLS command. Only certain nodes must be capable of sending an RLS command.

RSCN is Invocable. Nx_Ports must be capable of sending a State Change Notification to the Fabric Controller. The Fabric Controller would then issue an RSCN to all registered Nx_Ports. The Fabric Controller may use Multicast for transmitting the RSCN. Nx_Ports must be able to receive the Multicast alias address if used.

SCR is Invocable, but only nodes responsible for error detection will be required to register with the Fabric Controller for state change notification.

Other ELS commands are Allowed, but devices that receive requests for ELSs not supported will return LS_RJT with reason code “Invalid LS_Command code” or “Command not supported”.



63

4.5 Fibre Channel Lightweight Protocol (FCLP)

This FC-AE profile follows the FCP and FC-FS standards in its definition of the services necessary to support low-latency, low overhead communication between elements of a mission-critical avionics system. The mnemonic used to define this profile shall be FC-AE-FCLP. The FC-AE-FCLP profile includes the following elements:

• The SCSI Application Programming Interface (API) • A profile of the SCSI API that prohibits, requires, or allows features of the API • A mapping of the SCSI API to Fibre Channel constructs. This is provided by reference to the

FCP standard • A profile of the FC-FS standard

There is another profile very similar in operation to FCLP. It is FC-AE-RDMA (Remote Direct Memory Access) described in 1.1. While they are similar, there are sufficient differences to warrant their own profile, especially in their use of the FCP_XFER_RDY IU and the Command Descriptor Block.

4.5.1 FC-AE-FCLP Command Primitives

FCLP allows nodes to transfer data much like other network protocols but eliminates the copying that is typically done. FCLP attains low latency and high throughput by having low CPU utilization on transfers and allowing very large data transfer sizes. In FCLP, an access point and a channel together specify the endpoint for communication. This could be considered analogous to a socket in Internet Protocol (IP). An access point is a collection of channels that are referenced by an access point identifier (APID). The APID can be used by the application to specify the type of data or the service provided and is analogous to a port number in IP. A channel designated by a channel number (chnum) is a virtual connection within an access point. Applications transmit and receive data over channels connected between two nodes. The implementation uses an application number (apnum) to keep track of each APID in use.

FCLP uses the standard FCP protocol mapping with vendor-specific command codes. The fields within the command descriptor blocks (CDB) have been defined specifically for FCLP use. Table 20 lists the command codes used:

Table 20 FCLP Command Codes

Command Code Definition hex ’E0’ Setup Channel hex ’E1’ Acknowledge channel setup hex ’E2’ Send Data hex ’E3’ Close Channel hex ’E4’ Return APIDs

4.5.1.1 Setup Channel Command

1. The initiator sends a setup channel command FCP_CMD frame with the CDB format as follows:

• cdb[0] contains 0xE0, which corresponds to FCLP_SETUP_CHAN_CMD.

• cdb[1] contains the local apnum on which the channel is being set up.

• cdb[2] through cdb[9] contain the WWN of the node sending the setup channel.

• cdb[10] through cdb[11] contain the APID of the remote node.

• cdb[12] contains the chnum of the channel that is being set up locally.

• cdb[13] through cdb[15] contain the 24 bit port ID of the remote node.



64

2. The target replies with a FCP_XFER_RDY frame and the initiator sends a FCP_DATA frame with the following data:

• data[2] through data[5] the local node’s maximum fragment size.

• data[6] through data[7] contain the APID of the local node.

• data[8] contains the access point number of the local node.

• data[9] contains the channel number of the local node.

• data[10] through data[11] contain the APID of the remote.

• data[12] through data[15] suggested buffer size for the channel.

3. The target replies with a FCP_RSP with status “good”.

4.5.1.2 Setup Channel Acknowledgement


• cdb[0] contains 0xE1, which corresponds to FCLP_SETUP_CHAN_ACK_CMD.

• cdb[1] contains the local apnum on which the channel is being set up.

• cdb[2] through cdb[9] contains the WWN of the node requesting the ACK.


• cdb[12] contains the chnum of the channel that is being set up locally.

• cdb[14] through cdb[15] contain the APID of the local node.

2. The target sends a FCP_DATA frame with the following data:

• data[2] through data[5] contains the remote node’s maximum fragment size.

• data[6] through data[7] contains the remote node APID.

• data[8] contains the remote node’s apnum corresponding to the remote APID.

• data[9] contains the remote node’s available channel number on the remote APID.

3. The target sends a FCP_RSP with status “good”.

4.5.1.3 Send Data Command

1. The initiator sends a send data command FCP_CMD frame with the CDB format as follows:

• cdb[0] contains 0xE2, which corresponds to FCLP_SEND_DATA_CMD.

• cdb[2] through cdb[5] contains the requests fragment size.

• cdb[6] contains the local apnum of the channel.

• cdb[7] contains the local chnum of the channel.

• cdb[8] contains the apnum corresponding to the APID of the remote node.

• cdb[9] contains the channel number on the APID of the remote node.


• cdb[12] through cdb[15] contain the TX buffer size passed to send.

2. The target replies with a FCP_XFER_RDY frame and the initiator sends FCP_DATA frame(s) with the data to be transferred.




65

4.5.1.4 Close Channel Command


• cdb[0] contains 0xE3, which corresponds to FCLP_CLOSE_CHAN_CMD.

• cdb[1] contains the remote apnum the channel is connected to.

• cdb[2] contains the remote chnum the channel is connected to.

• cdb[3] contains the local apnum of the channel.

• cdb[4] contains the local chnum of the channel.


4.5.1.5 Return APIDs Command

1. The initiator sends a return APIDs command FCP_CMD frame with the CDB format as follows:

• cdb[0] contains 0xE4, which corresponds to FCLP_RETURN_APIDS_CMD.

2. The target sends a FCP_DATA frame with the following data:

• 16 Words of data where each word specifies an active APID. Hex ‘FFFF’ is used to pad the data if less than 16 active APIDs exist.

3. The target sends a FCP_RSP with status “good”.

4.5.2 FCP Features for FC-AE-FCLP

Table 21 is the profile of FCP features for arbitrated loop and fabric topologies. Devices that are compliant with FC-AE-FCLP must comply with the mandatory features defined in FCP unless noted herein. Table 21 identifies optional features that represent potential interoperability concerns and indicates whether they are Required, Invocable, Allowed, or Prohibited for FC-AE-FCLP compliance.

Table 21 FCP Features for FC-AE-FCLP

FCP Features Nx_Port Fx_Port Notes

Process Login Service Parameters Page:

Type Code = 08h R -

PRLI Flags

Process Associator Validity Bits = 1 P -

Establish Image Pair R -

Service Parameters

Data Overlay Allowed P -

Initiator Function I -

Target Function I -

Command/Data Mixed Allowed P -



66


Data/Response Mixed Allowed P -

Read XFER_RDY Disabled R -

Write XFER_RDY Disabled P -

Process Login Service Parameter Response Page:

Type Code = 08h R -

PRLI Response Flags


Image Pair Established R -

Response Code = 0001b I - Request Executed

Service Parameter Response


Initiator Function I -

Target Function I -





FCP Command IU R -

FCP_LUN R -

FCP_CNTL

Byte 1, Task Codes

Simple_Q A -

HEAD_OF_Q A -

Others A -

Byte 2, Task Management Flags



67


Target Reset A -

Clear Task Set A -

Abort Task Set A -

LUN Reset A -

Others A -

FCP_DL R -

FCP_CDB Available for Protocol use R -

FCP Transfer Ready IU R - per FCP

FCP Data IU R - per FCP

FCP Response IU R - per FCP

4.5.2.1 Process Login Service Parameters

For Process Service Login Parameters features that are Required or Invocable, the login parameters shall indicate that the feature is supported. For features that are Prohibited, the login parameters may indicate that the feature is supported, even though the feature will not be used by compliant implementations. For features that are Allowed, the login parameters shall reflect whether or not the feature is supported by the implementation.

FC-AE-FCLP uses Type Code 08h as in FCP.

FC-AE-FCLP compliant devices do not use Process Associators so the Process Associator Validity bits cannot be set to 1.

The Establish Image Pair parameter is Required to be set indicating that the Process Login (PRLI) exchanges service parameters and establishes an image pair.

Target and Initiator Function bits are Invocable and shall be set as appropriate. At least one of these bits must be set.

In FCP-AE-FCLP Disabling Read XFER_RDY is Required and disabling Write XFER_RDY is Prohibited.

The login parameters Data Overlay Allowed, Command/Data Mixed Allowed, and Data/Response Mixed Allowed are Allowed to be set but usage of the features is Prohibited.

4.5.2.2 Process Login Service Response Parameters

For Process Login Service Response Parameters features that are Required or Invocable, the login parameters shall indicate that the feature is supported. For features that are Prohibited, the login parameters may indicate that the feature is supported, even though the feature will not be used by compliant implementations. For features that are Allowed, the login parameters shall reflect whether or not the feature is supported by the implementation.

PRLI Response Parameters are very similar to the PRLI Parameters.

FC-AE-FCLP uses Type Code 08h as in FCP.



68

FC-AE-FCLP compliant devices do not use Process Associators so the Process_Associator Validity bits cannot be set to 1.

The Image Pair Established parameter is Required to be set indicating that the Process Login has established an image pair.

A Response Code of 0001b is Invocable indicating the Request has been executed. Other Codes are Allowed, but this is the only code that results in a successful Process Login.

Target and Initiator Function bits are Invocable and shall be set as appropriate. At least one of these bits must be set.

In FCP-AE-FCLP, disabling Read XFER_RDY is Required and disabling Write XFER_RDY is Prohibited.

The login parameters Data Overlay Allowed, Command/Data Mixed Allowed, and Data/Response Mixed Allowed are Allowed to be set but usage of the features is Prohibited.

4.5.2.3 FCP Command IU

4.5.2.3.1 FCP_LUN

FCP_LUN is Required. In FC-AE-FCLP, the FCP Logical Unit Number (LUN) is used by the protocol. FCP_LUN_15 (first level) is used to send FC-AE-FCLP commands

4.5.2.3.2 FCP_CNTL

The FCP Control Field contains Task Codes and Task Management Flags. These are set in firmware and have no effect on the FCLP protocol and are therefore defined as Allowed.

4.5.2.3.3 FCP_DL

The FCP_DL field shall contain the number of data bytes in the FCP_DATA frames for the Setup Channel, Setup Channel Acknowledgement, and Send Data Command primitives.

4.5.2.3.4 Command Descriptor Block (CDB)

The CDB is used by FC-AE-FCLP. See 4.5.1. As in FCP, the CDB is not valid if any Task Management Flags are set.

4.5.2.4 FCP Transfer Ready IU

Transfer Ready IUs are used as defined in FCP.

4.5.2.5 FCP Data IU

Data IUs are used as defined in FCP.

4.5.2.6 FCP Response IU

Response IUs are used as defined in FCP.



69

4.5.3 FC-FS and FC-AL2 Features for FC-AE-FCLP

Table 22 is the profile of the FC-FS and FC-AL2 standards. Devices that are compliant with FC-AE-FCLP must comply with the mandatory features defined in FC-FS and FC-AL2, unless noted herein. Table 22 identifies optional features that represent potential interoperability concerns and indicates whether they are Required, Invocable, Allowed, or Prohibited for FC-AE-FCLP compliance. In addition to interoperability concerns, this profile addresses certain features that are needed in order to achieve the performance necessary for real-time avionics systems. More information is provided after the Table.

Items that are clearly defined in FCP are not restated here, such as R_CTL and the Type code in the Header.

In many cases, these features shown in Table 22 have Login Parameters associated with them. For features that are Required or Invocable, the corresponding login parameters shall indicate that the feature is supported. For features that are Prohibited, the corresponding login parameters may indicate that the feature is supported, even though the feature will not be used by compliant implementations. For features that are Allowed, the corresponding login parameters shall reflect whether or not the feature is supported by the implementation.

Table 22 FC-FS and FC-AL2 Features for FC-AE-FCLP


Link Protocols



Link Failure R R

Link Reset R R


Loop Protocols





Hard Addressing A A







70


Broadcast Open Replicate – OPN(fr) A A

Old Port State I I


Fabric Login

Explicit Login I I

S_ID = hex ’00 00 00’ R I

Implicit Login A A


Registered A A

Non-Registered A A


BB_Credit > 2 R R

Max BB Receive Data Field Size > 2048 I I


Multicast P P

Broadcast P P

Hunt Group P P



Class of Service

Class 1 P P

Class 2 A A

Class 3 I I

Class 4 P P

Class 6 P P



71



Clock Sync ELS Capable A A Server in the fabric

N_Port Login

Explicit Login I -

Implicit Login A -

Port Name Format

Registered A -

Non-Registered A -




Continuously Increasing Relative Offset I -


(Continuously Increasing)SEQ_CNT I -




Relative Offset by Information Category R - per FCP


Class of Service

Class 1 P P

Class 2 A A

Class 3 I I

Class 4 P P



72


Class 6 P P



Initial Process Associator = ’00’b R - Process Associators not used in FC-AE-FCLP











Initial Process Associator = ’00’b R - Process Associators not used in FC-AE-FCLP






hex ’FF FF FF’ (Broadcast) A A



73



hex ’FF FF FD’ (Fabric Controller) - A



hex ’FF FF F6’ (Clock Sync Server) P A

Others P -


Class 3 I I

Class 2 P P

others P P

Basic Link Services

BA_ACC I -

BA_RJT I -

ABTS I -

Others P P


FDISC A A

FLOGI I I

LOGO I -

PDISC A -

PLOGI I -

PRLI I -

PRLO I -

Others A A



74


Support of basic Link Initialization described in FC-FS is required and will be used at power up or upon re-initialization. Link Failure and Link Reset protocols must be implemented, and will be used as needed.

Online-to-Offline protocol is Allowed but not required because typically an Offline state is not needed in avionics systems. The equipment will operate until power is removed.


This profile was written primarily for switched fabrics which may include attached loops. Although there is no inherent restriction on the use of a Private loop with the FC-AE-FCLP profile that topology is not addressed specifically.


Loop Initialization Protocol is Invocable (but not Required) because this enables the System Designer to implement a system using Implicit LIP in order to achieve faster start-up times. Implicit LIP must be implemented in such a way to insure interoperability with devices that only support “Explicit LIP”. If Implicit LIP is used it is up to the System Designer to figure out how to provide all the necessary information to the nodes, such as AL_PA assignments.

If Explicit LIP is used, Loop Initialization Hard Addressing (LIHA) is Allowed during AL_PA Assignment.

• NOTE - Hard Addressing is desirable in avionics networks because every node gets the same address every time the loop is initialized.



Support for Loop Port Bypass and Loop Port Enable Primitive Sequences, which control access to the loop, is Invocable. Support for the optional Bypass circuit is Allowed.


Specifying Login BB_Credit > 1 is Invocable. Login BB_Credit is used to set the available BB_Credit every time the loop circuit is opened. If login BB_Credit is > 1, and the transmitting port remembers the value, the transmitting port doesn’t have to wait for an R_RDY to begin sending frames.

Programmable Loop Tenancy is Allowed. This feature gives the system designer the ability to set the maximum Loop Tenancy of a loop port in firmware/hardware if desired. Alternatively, the loop tenancy may be controlled in software. • NOTE - Dynamic Half Duplex, Login BB_Credit, and Loop Tenancy are only some of the parameters




Broadcast Open Replicate is Allowed.

The capability to operate in OLD_PORT state is desirable in order for a 2-node pair to operate in point-to-point mode as opposed to operating as a 2-node loop. There are two ways to enter OLD_PORT state: 1)



75

one node in the pair doesn’t support LPSM, or 2) both nodes support LPSM but OLD_PORT state is requested. The ability to request Old Port state is Invocable.








The Max BB Receive Data Field Size must be at least 2048 bytes.




Class 3 must be supported and Class 2 is Allowed.

Sequential Delivery is Invocable for fabrics and Allowed for nodes. Sequential Delivery simplifies re-assembly and error detection at the recipient node.

Clock Synchronization using the ELS Method is Allowed for both fabrics and nodes. In order to reduce complexity of compliant nodes, the Clock Sync Server would bein the fabric in this profile.




As in FLOGI, BB_Credit shall be at least 2. In N_Port Login, this applies to point-to-point topologies. It is also used to set the Login BB_Credit for Loop devices operating on the same arbitrated loop, but that is specified in 4.5.3.2.

Max BB Receive Data Field Size must be at least 2048 bytes.

Continuously Increasing Relative Offset is Invocable.





76


Class 2 is Allowed. Initiators and Recipients must be capable of supporting ACK 0 as an Initiator or Recipient, which will be negotiated at Login. However, it should be understood that if both N_Ports specify support for ACK 0, ACK 0 must always be used.








Open Sequences per Exchange must be > 1.


Broadcast is Allowed.

Name Server is Allowed, but the use of pre-defined addresses is Allowed (and encouraged) which eliminates the need for the Name Server.

Alias Server is Allowed. Pre-defined look-up tables are Allowed (and encouraged) which eliminates the need for an Alias Server.

The Clock Sync Server, supporting the ELS method, is Allowed in the fabric.



The Class of Service to/from Well Known Addresses is restricted to Class 3 in this profile. This simplifies the servers and to a lesser extent, the nodes.




Similar to FLOGI and PLOGI, Process Login is Invocable (but not Required) because this enables the System Designer to implement a system using Implicit Login. Explicit Process Login will normally be used. If Implicit Login is used it is up to the System Designer to figure out how to provide all the necessary information to the nodes.

PRLO is Invocable. Process Logout can be done implicitly or explicitly.

Other ELS commands are Allowed.



77

4.6 Remote Direct Memory Access (RDMA)

This FC-AE profile follows the FCP and FC-FS standards in its definition of the services necessary to support low-latency, low overhead communication between elements of a mission-critical avionics system. The mnemonic used to define this profile shall be FC-AE-RDMA. The FC-AE-RDMA profile includes the following elements:

• The SCSI Application Programming Interface (API) • A profile of the SCSI API that prohibits, requires, or allows features of the API • A mapping of the SCSI API to Fibre Channel constructs. This is provided by reference to the

FCP standard and additional enhancements • A profile of the FC-FS and FC-AL2 standards

There is another profile very similar in operation to RDMA. It is FC-AE-FCLP (Fibre Channel Lightweight Protocol) described in 1.1. While they are similar, there are sufficient differences to warrant their own profile, especially in their use of the FCP_XFER_RDY IU and the Command Descriptor Block.

4.6.1 RDMA Enhancement to FCP

RDMA has certain enhancements over FCP intended for low latency, real-time applications. The FCP_XFER_RDY IU shall not be used and write data shall immediately follow the command. In RDMA, a target first registers a data buffer with the Application Programmer’s Interface. An initiator can then read or write data directly into that buffer. The contents of the FCP_CMND IU are not changed, but the paramenter field of the header is modified. The Parameter field (or Relative Offset) is used to indicate that the transfer is an RDMA, with or without target notification on completion, in bits 31-24. The buffer offset is contained in bits 23-0, as shown in table 23.

Table 23 RDMA Parameter Field Usage – Command IU

Code hex’A6’ = RDMA with Target Notification Code hex’A7’ = RDMA without Target Notification

For avionics applications, provisions should be made for multiple target buffers and limiting the range of the buffers in order to provide a memory protection scheme. The Data IUs and Status IUs are not changed in content or usage from FCP.

4.6.2 FCP Features for FC-AE-RDMA

Table x is the profile of FCP features for arbitrated loop and fabric topologies. Devices that are compliant with FC-AE-RDMA must comply with the mandatory features defined in FCP unless noted herein. Table x identifies optional features that represent potential interoperability concerns and indicates whether they are Required, Invocable, Allowed, or Prohibited for FC-AE-RDMA compliance.

Bit 31 24 23 0

CODE OFFSET

Fibre Channel Frame Header, Word 5



78

Table 24 FCP Features for FC-AE-RDMA


Process Login Service Parameters Page:

Type Code = 08h R -

PRLI Flags


Establish Image Pair R -

Service Parameters


Initiator Function R -

Target Function R -





Process Login Service Parameter Response Page:

Type Code = 08h R -

PRLI Response Flags


Image Pair Established R -

Response Code = 0001b I - Request Executed

Service Parameter Response


Initiator Function R -

Target Function R -




79





FCP Command IU R -

Header Word 5 Available for Protocol use R -

FCP_LUN I -

FCP_CNTL

Byte 1, Task Codes

Simple_Q I -

HEAD_OF_Q A -

others A -

Byte 2, Task Management Flags P -

FCP_DL I -

FCP_CDB -

FCP Transfer Ready IU P -

FCP Data IU R - per FCP

FCP Response IU R - per FCP

4.6.2.1 Process Login Service Parameters

FC-AE-RDMA ports perform Process Login (PRLI) as described in FCP. All FC-AE-RDMA ports shall be capable of operating as both RDMA Initiator and Target.

FC-AE-RDMA uses Type Code 08h as in FCP.

A port that acts as a PRLI originator shall send PRLI requests that contain exactly one Service Parameter Page, set the Type Code to 08h, and set the Establish Image Pair, Target Function, Initiator Function, and Read XFER_RDY Disabled parameters. An HSDN port that acts as PRLI originator shall not set the Data Overlay Allowed, Command/Data Mixed Allowed, and Data/Response Mixed Allowed, Write XFER_RDY Disabled, and Process Associator Valid parameters. A port that receives a PRLI with a type code other than 08h shall send a LS_RJT instead of a PRLI Accept. A port that receives a PRLI with unexpected values for payload length, Establish Image Pair, or Process Associator Valid, shall respond with an LS_RJT, or a PRLI Accept that does not set Image Pair Established, or a PRLI Accept with an Accept Response Code other than Request Executed (0001b). A



80

port that receives a PRLI with other unexpected values should respond with a PRLI Accept, and ignore the unexpected values. A port that receives a PRLI with acceptable parameters shall respond with a valid PRLI Accept to complete the process login. A valid PRLI Accept shall contain an Accept Response Code of Request Executed. Other parameters in a valid PRLI Accept shall be set the same as required for PRLI originators. A port that receives a PRLI Accept with unexpected parameter values should attempt to log out with the responder by sending a Process Logout command (PRLO).

4.6.2.2 FCP Command IU

In FCP Header Word 5 is defined to be 0. In FC-AE-RDMA compliant devices, Header Word 5 is used FC-AE-RDMA as described in 1.1.

4.6.2.2.1 FCP_LUN

FCP_LUN is Invocable. FC-AE-RDMA supports SCSI Level 1 peripheral addressing, which defines the first two bytes of the FCP_LUN field.

4.6.2.2.2 FCP_CNTL

The FCP Control Field contains Task Codes and Task Management Flags. The Task Code Simple_Q is Invocable. Head of Queue is Allowed and may be used in conjunction with the Priority or Preference field in the Header. Other Task Codes are Allowed.

Initiators shall not set Task Management Flags in transmitted Command IUs. If a Command IU is received with one or more Task Management Flags set, Targets shall maintain or automatically resume normal Target operation.

4.6.2.2.3 FCP_DL

The FCP_DL field shall contain the number of data bytes that will be transferred in the payload of the Data IUs.

4.6.2.2.4 Command Descriptor Block (CDB)

The CDB is not used in FC-AE-RDMA. It is available for use by the System Designer.

4.6.2.3 FCP Transfer Ready IU

Transfer Ready IUs are Prohibited in FCP-AE-RDMA.

4.6.2.4 FCP Data IU

Data IUs are used as defined in FCP. The RLTV_OFF value of the first Data IU of an exchange is zero, and subsequent Data IUs in the same exchange will use RLTV_OFF values to define the offset from the beginning of the first Data IU of the exchange.

4.6.2.5 FCP Response IU

Fields in the FCP_RSP IU are not redefined from the FCP definitions, however not all fields apply to FC-AE-RDMA transfers. FCP_RSP IUs shall be 24 bytes in length. FCP_SNS_LEN and FCP_RSP_LEN shall be zero. FC-AE-RDMA ports should utilize the FCP_RESID, FCP_RESID_UNDER, and FCP_RESID_OVER fields to report mismatches between FCP_DL and the number of bytes transferred in associated Data IUs. A SCSI Status Code of GOOD shall be used to indicate successful completion of the RDMA transfer.



81

SCSI Status Codes of BUSY and/or QUEUE FULL shall be used to indicate temporary Target resource limitations. These codes should be used when it is likely that simply reinitiating the transfer would be successful. Systems should be designed with sufficient performance to minimize the need for these codes during normal operation. Other SCSI Status Codes shall be used to report other conditions resulting in unsuccessful transfers, such as use of an offset or data length that is beyond a Target’s range limit, or attempting an RDMA Write into a write protected region.



82

4.6.3 FC-FS and FC-AL2 Features for FC-AE-RDMA

is the profile of the FC-FS and FC-AL2 standards primarily for arbitrated loop and fabric topologies. Devices that are compliant with FC-AE-RDMA must comply with the mandatory features defined in FC-FS and FC-AL2, unless noted herein. identifies optional features that represent potential interoperability concerns and indicates whether they are Required, Invocable, Allowed, or Prohibited for FC-AE-RDMA compliance. In addition to interoperability concerns, this profile addresses certain features that are needed in order to achieve the performance necessary for real-time avionics systems. More information is provided after the Table.

Items that are clearly defined in FCP are not restated here, such as R_CTL and the Type code in the Header.

In many cases, these features shown in have Login Parameters associated with them. For features that are Required or Invocable, the corresponding login parameters shall indicate that the feature is supported. For features that are Prohibited, the corresponding login parameters may indicate that the feature is supported, even though the feature will not be used by compliant implementations. For features that are Allowed, the corresponding login parameters shall reflect whether or not the feature is supported by the implementation.

Table 25 FC-FS and FC-AL2 Features for FC-AE-RDMA


Link Protocols



Link Failure R R

Link Reset R R


Loop Protocols





Hard Addressing I I






83



Broadcast Open Replicate – OPN(fr) A A

Old Port State I I


Fabric Login

Explicit Login I I

S_ID = hex ’00 00 00’ R I

Implicit Login A A


Registered A A

Non-Registered A A


BB_Credit > 2 R R

Max BB Receive Data Field Size > 2048 I I

E_D_TOV Resolution = 0 - R 1 ms


Multicast P P

Broadcast P P

Hunt Group P P


min R_A_TOV < 100ms I I


R_T_TOV Value I I < 1ms


Class of Service



84


Class 1 P P

Class 2 A A

Class 3 I I

Class 4 P P

Class 6 P P


Priority A I

Preference A I

Clock Sync Primitive Capable P P

Clock Sync ELS Capable I I Server is in the fabric

N_Port Login

Explicit Login I -

Implicit Login A -

Port Name Format

Registered A -

Non-Registered A -




Continuously Increasing Relative Offset I -


(Continuously Increasing)SEQ_CNT I -





85



Relative Offset by Information Category R - per FCP



Class of Service

Class 1 P P

Class 2 A A

Class 3 I I

Class 4 P P

Class 6 P P



Priority A I

Preference A I

Initial Process Associator = ’00’b R - Process Associators not used in FC-AE-RDMA











86




Priority bit A I

Preference A I

Initial Process Associator = ’00’b R - Process Associators not used in FC-AE-RDMA


Recipient Clock Sync ELS Capable I -



Fabric Reject Reason Codes

hex ’01’ Invalid D_ID I I

hex ’03’ N_Port not available, temporarily I A

hex ’04’ N_Port not available, permanently I I

hex ’05’ Class of service not supported I I

hex ’16’ Login required I I

Others I A Within the bounds of Class 2

Fabric Busy Reason Codes

hex ’1’ Fabric is Busy I A

hex ’3’ D_ID busy with a Class 1 connection - P

Port Reject Frames I - Reason codes not specified

Port Busy Frames I - Reason codes not specified




87


hex ’FF FF FF’ (Broadcast) A A


hex ’FF FF FD’ (Fabric Controller) - A



hex ’FF FF F6’ (Clock Sync Server) P I

Implicit N_Port login R -

Multicast capable I I For CSU

Others P -


Class 3 I I

Class 2 P P

others P P

Basic Link Services

BA_ACC I -

BA_RJT I -

ABTS I -

Others P P


CSR I I To the Clock Sync Server only

CSU I I

FDISC A A

FLOGI I I

LOGO I -



88


PDISC A -

PLOGI I -

PRLI I -

PRLO I -

RLS I I

Others A A


Support of basic Link Initialization described in FC-FS is required and will be used at power up or upon re-initialization. Link Failure and Link Reset protocols must be implemented, and will be used as needed.

Online-to-Offline protocol is Allowed but not required because typically an Offline state is not needed in avionics systems. The equipment will operate until power is removed.


This profile was written primarily for switched fabrics which may include attached loops. Although there is no inherent restriction on the use of a Private loop with the FC-AE-RDMA profile that topology is not addressed specifically.


Loop Initialization Protocol is Invocable (but not Required) because this enables the System Designer to implement a system using Implicit LIP in order to achieve faster start-up times. Implicit LIP must be implemented in such a way to insure interoperability with devices that only support “Explicit LIP”. If Implicit LIP is used it is up to the System Designer to figure out how to provide all the necessary information to the nodes, such as AL_PA assignments.

If Explicit LIP is used, Loop Initialization Hard Addressing (LIHA) is Invocable during AL_PA Assignment. • NOTE - Hard Addressing is desirable in avionics networks because every node gets the same

address every time the loop is initialized.



Support for Loop Port Bypass and Loop Port Enable Primitive Sequences, which control access to the loop, is Invocable. Support for the optional Bypass circuit is Allowed.


Specifying Login BB_Credit > 1 is Invocable. Login BB_Credit is used to set the available BB_Credit every time the loop circuit is opened. If login BB_Credit is > 1, and the transmitting port remembers the value, the transmitting port doesn’t have to wait for an R_RDY to begin sending frames.



89

Programmable Loop Tenancy is Allowed. This feature gives the system designer the ability to set the maximum Loop Tenancy of a loop port in firmware/hardware if desired. Alternatively, the loop tenancy may be controlled in software.

• NOTE - Dynamic Half Duplex, Login BB_Credit, and Loop Tenancy are only some of the parameters that affect loop performance. Other parameters that should be considered include:



Broadcast Open Replicate is Allowed.

The capability to operate in OLD_PORT state is desirable in order for a 2-node pair to operate in point-to-point mode as opposed to operating as a 2-node loop. There are two ways to enter OLD_PORT state: 1) one node in the pair doesn’t support LPSM, or 2) both nodes support LPSM but OLD_PORT state is requested. The ability to request Old Port state is Invocable.








The Max BB Receive Data Field Size must be at least 2048 bytes.


Time-out values are determined by the System Designer. The Minimum E_D_TOV and Minimum R_A_TOV values shown are provided as guidelines for real-time avionics systems. The short R_T_TOV Value, which enables quicker detection of Loss of Sync, is Invocable. For purposes of this profile, the short R_T_TOV value shall be <1ms with a goal of achieving 100us in the future. This is a deviation from FC-FS which specifies that the short value will be 100us.



Class 3 must be supported and Class 2 is Allowed.

Sequential Delivery is Invocable for fabrics and Allowed for nodes. Sequential Delivery simplifies re-assembly and error detection at the recipient node.



90

Support for Priority and Preference is Invocable for fabrics and Allowed for nodes. The fabric will route frames with the Priority or Preference bit set ahead of frames without the bit set. System Designers may require the use Priority or Preference for enhanced performance.

Clock Synchronization using the ELS Method is Invocable for both fabrics and nodes. In order to reduce complexity of compliant nodes, the Clock Sync Server is required to be within the fabric in this profile.




As in FLOGI, BB_Credit shall be at least 2. In N_Port Login, this applies to point-to-point topologies. It is also used to set the Login BB_Credit for Loop devices operating on the same arbitrated loop, but that is specified in 4.6.3.2.

Max BB Receive Data Field Size must be at least 2048 bytes.

Continuously Increasing Relative Offset is Invocable. Its usage is defined in FCP, except that the RLTV_OFF field is redefined for CMND IUs in FC-AE-RDMA.


FCP does not support the use of Multicast. However, Multicast may be used for certain ELS commands.


The E_D_TOV specified here is used for nodes in point-to-point topology and also between nodes on the same arbitrated loop. As in FLOGI, the value listed is a guideline for real-time avionics systems.


Class 2 is Allowed. Initiators and Recipients must be capable of supporting ACK 0 as an Initiator or Recipient, which will be negotiated at Login. However, it should be understood that if both N_Ports specify support for ACK 0, ACK 0 must always be used.



Recipient Clock Sync ELS is Allowed in Class 2, however, the Clock Sync server is only required to operate in Class 3 in this profile.








91


Recipient Clock Sync ELS is Invocable in Class 3.


Another performance oriented parameter is Open Sequences per Exchange. The minimum requirement is 1, but performance could be improved if it were greater than 1. This is particularly true in Class 3 because with no ACK frames, the initiator is supposed to wait R_A_TOV after transmitting a sequence to free up resources and begin another sequence,


Fabric Reject frames are Invocable with the Reason Codes listed in the Table. Certain Reason Codes are required to be supported. Others are Allowed, within the bounds of what is applicable for Class 2.

Fabric Busy frames are Allowed. Fabric Busy may not be used in small fabrics. Port Busy may be used instead. However, nodes must be able to accept F_BSY if one is sent by the fabric.




Broadcast is Allowed.

Name Server is Allowed, but the use of pre-defined addresses is Allowed (and encouraged) which eliminates the need for the Name Server.

Alias Server is Allowed. Pre-defined look-up tables are Allowed (and encouraged) which eliminates the need for an Alias Server.




The Class of Service to/from Well Known Addresses is restricted to Class 3 in this profile. This simplifies the servers and to a lesser extent, the nodes.




Clock Sync Request is Invocable. The Nx_Port is the Initiator. CSR can be directed to the Clock Sync Server or the Fabric Controller. Support in the Clock Sync Server is Invocable. Support in the Fabric Controller is Allowed.

Clock Sync Update is Invocable. In this profile, The Nx_Port is always the Recipient since the server is in the fabric. The Clock Sync Server may use Multicast for transmitting CSU. Nx_Ports must be able to receive the Multicast alias address if used.

Similar to FLOGI and PLOGI, Process Login is Invocable (but not Required) because this enables the System Designer to implement a system using Implicit Login. Explicit Process Login will normally be



92

used. If Implicit Login is used it is up to the System Designer to figure out how to provide all the necessary information to the nodes.

PRLO is Invocable. Process Logout can be done implicitly or explicitly.

RLS is Invocable. All Nx_Ports and Fx_Ports must contain a Link Error Status Block and be able to reply to an RLS command. Only certain nodes must be capable of sending an RLS command.

Other ELS commands are Allowed, but devices that receive requests for ELSs not supported will return LS_RJT with reason code “Invalid LS_Command code” or “Command not supported”.



93

Annex A

(Informative)

Bridging from FC-AE-1553 Networks to MIL-STD-1553 Buses

This informative annex describes a method for bridging from a Fibre Channel network using the FC-AE-1553 upper layer protocol to MIL-STD-1553 bus.

A.1 Bridging Between Legacy MIL-STD-1553 Buses and FC-AE-1553 Networks

Figure A.1 illustrates a method for bridging a MIL-STD-1553 bus with RT devices embedded in legacy systems to an FC-AE-1553 network.

Figure A.19. FC-AE-1553 Network to MIL-STD-1553 Bus Bridge

Referring to Figure 1, the design of a MIL-STD-1553-to-Fibre Channel bridge is independent of the specific characteristics of the legacy systems or their associated MIL-STD-1553 RTs. In operation, the bridge receives FC-AE-1553 command frames from the FC-AE-1553 network. The MIL-STD-1553 bus controller in the bridge converts the FC-AE-1553 command frame to a MIL-STD-1553 message segment (command frame or command frame plus data frames), which it then transmits to the RT over the legacy MIL-STD-1553 bus. After the RT responds with MIL-STD-1553 status (possibly with data), the bridge formulates a FC-AE-1553 status frame (and possibly a data frame), which it then transmits over the Fibre Channel network.

Legacy MIL-STD-1553 Bus FC-AE-1553

Fibre Channel Network

MIL-STD-1553-to-

Fibre Channel Bridge

MIL-STD- 1553 BC

Fibre Channel N_Port

or NL_Port

(NT)

Legacy System

MIL-STD-1553 RT

Legacy System

MIL-STD-1553 RT



94

A Fibre Channel network may include multiple Fibre Channel-to-1553 bridges, each of which connects to a different MIL-STD-1553 bus. While there may be multiple bridges connected to the same MIL-STD-1553 bus, at any given time there shall not be more than one active Fibre Channel-to-1553 bridge on the same 1553 bus. The bridge, which has a single Fibre Channel Port_ID, sends messages to individual MIL-STD-1553 RTs based on the 5-bit RT Address field in word 9 of the command frame header. If the value of this field is ‘1F’, the bridge shall transmit a broadcast command over the MIL-STD-1553 bus. To enable NT-to-RT, RT-to-NT, and RT-to-RT transfers through bridges, the FC-AE-1553 command frame includes a field which is used for the NT address of the receiving NT for the transmit command frame, or the NT address of the transmitting NT for the receive command frame. To extend this capability to enable MIL-STD-1553 RT-to-RT transfers, the command frame also includes a field for specifying the 5-bit RT address of the receiving or transmitting RT. The design of the bridge shall therefore enable MIL-STD-1553 RT-to-RT transfers over one MIL-STD-1553 bus, MIL-STD-1553 RT-to-RT transfers between two different MIL-STD-1553 buses over a Fibre Channel network, FC-AE-1553 NT to MIL-STD-1553 RT transfers, and MIL-STD-1553 RT to FC-AE-1553 NT transfers.

Note that the first case is the only one involving a true RT-to-RT transfer message over a MIL-STD-1553 bus. The other three cases will entail the bridge initiating either a BC-to-RT transfer message or an RT-to-BC transfer message over one (or two) MIL-STD-1553 bus(es).

01-238v4 fc-ae profile v2 4 - 012602...

Documents