Fibre Channel (FC) Frame Encapsulation
Extracted elements (27)
SOF and EOF are transmitted as four-byte sequences (SOF, SOF, -SOF, -SOF and EOF, EOF, -EOF, -EOF) because FC SOF/EOF use special 10b characters with no 8-bit equivalents; the redundancy is deliberate to protect this critical framing information from transmission errors over the IP network.
The Time Stamp format follows SNTP Version 4 (seconds since 1 January 1900, plus a fractional-seconds field). The 32-bit seconds counter will overflow in 2036; the document notes that external means will be required at that time to disambiguate epochs. A 64-bit all-zero timestamp is by convention treated as invalid or unavailable.
Two header validation mechanisms are provided — redundancy-based (one's complement fields, stepwise) and CRC-based (word 6 CRC over words 0-5) — to address the needs of different design and operating environments. Redundancy-based validation allows early rejection before the full header is available, while CRC-based provides stronger integrity assurance.
Both Fibre Channel and IETF standards use the same byte transmission order, but the bit and byte numbering conventions differ. Implementors must apply the guidance in Appendix A (using FC's descending bit numbering vs. IETF's ascending) to correctly map header fields between the two numbering systems.
FC-MI (ANSI INCITS/TR-30:2002) identifies certain SOF and EOF codes (e.g., SOFi1, SOFn1) as not interoperable to the degree required by the IETF. These codes are excluded from the SOF and EOF encoding tables in this specification and MUST NOT be used.
An entity that does not support transit time calculation SHALL always set both Time Stamp words to zero when encapsulating, and SHALL ignore Time Stamp words when de-encapsulating.
Encapsulating entities that support transit time measurement MUST have access to an internal time base with sufficient stability and resolution, and a time base synchronized with peer entities. The encapsulating protocol specification MUST describe the synchronization and alignment procedure.
Encapsulation receivers SHOULD validate SOF and EOF fields against their respective one's complement (-SOF and -EOF) fields, according to a policy defined by the encapsulating protocol.
FC Encapsulation receivers SHOULD either validate the CRC or compare the one's complement field pairs (Protocol#/-Protocol#, Version/-Version, Flags/-Flags, Frame Length/-Frame Length) to verify that an FC Encapsulation Header is being processed, according to a policy defined by the encapsulating protocol.
Reserved Flags bits SHALL be set to zero on send. Changes in the usage of reserved Flags bits MUST be identified by changes in the Version field. Encapsulating protocols MUST NOT use reserved Flags bits in any fashion other than described in this specification.
The CRCV bit value SHALL be constant for all FC Encapsulation Headers sent on a given connection, ensuring a consistent validation mode across the lifetime of a connection.
The encapsulating protocol SHALL specify whether transit time measurement implementation support is required, and SHALL specify the conditions under which a received frame MUST have its transit time checked before forwarding.
The Encapsulation Header, SOF, FC frame content, and EOF SHALL be mapped to the IP transport using big-endian (network) byte ordering.
When de-encapsulating a frame in the Synchronized state, if the Time Stamp words contain a valid time per SNTP the entity SHALL compute transit time as the difference between the current time base and the departure time recorded in the header, then process the result per the encapsulating protocol specification.
When encapsulating a frame in the Synchronized state, an entity SHALL record the current time base value in the Time Stamp [Seconds] and Time Stamp [Seconds Fraction] fields of the encapsulation header.
When in the Unsynchronized state and permitted to process frames, an entity SHALL ignore Time Stamp words on de-encapsulation and SHALL set both Time Stamp words to zero on encapsulation.
The CRC field (word 6, 32 bits) covers words 0-5 of the FC Encapsulation Header and is computed using the FC-FS polynomial, initial value, and bit order. When CRCV=0 the CRC field SHALL contain zero; when CRCV=1 it SHALL contain the computed CRC converted to FC-2 format.
The Flags field (6 bits in word 3) contains reserved bits (bits 0-4, SHALL be zero on send) and the CRCV bit (bit 5). CRCV=1 indicates the CRC field is valid; CRCV=0 indicates it is invalid. The CRCV bit value SHALL be constant for all FC Encapsulation Headers sent on a given connection.
The Frame Length field (10 bits) contains the total length of the FC Encapsulated frame including the header and the FC frame (with SOF and EOF), expressed in units of 32-bit words. The -Frame Length field contains its one's complement.
The Protocol# field (8 bits, word 0 bits 0-7) SHALL contain an IANA-assigned number identifying which encapsulating protocol is employing the FC Encapsulation. The -Protocol# field SHALL contain the one's complement of Protocol# for header validation.
The Time Stamp [Seconds] and Time Stamp [Seconds Fraction] fields (32 bits each, words 4-5) follow the SNTP Version 4 format, recording the departure time of the encapsulated frame. A value of zero in both fields indicates an invalid or unavailable timestamp. The 32-bit seconds field will overflow in 2036.
The Version field (8 bits) SHALL contain 0x01 to indicate the current FC Encapsulation version; all other values are reserved. The -Version field SHALL contain the one's complement of Version.
This document establishes the IANA FC Frame Encapsulation Protocol Number Registry. Values are assigned only for Standards Track RFCs approved by the IESG. Protocol# 0 is reserved until all others are assigned; values 240-255 are set aside for private use. Protocol# 1 is assigned to FCIP and Protocol# 2 to iFCP.
This document specifies only the encapsulation format; security considerations depend entirely on how the encapsulation is used by each encapsulating protocol. Security considerations SHALL be described in encapsulating-protocol-specific documents (e.g., FCIP or iFCP specifications), not here.
An entity is in either the Synchronized or Unsynchronized state with respect to transit time measurement. It enters Unsynchronized on power-up and transitions to Synchronized once the time base is aligned per the encapsulating protocol specification. It MUST return to Unsynchronized if it cannot maintain time base synchronization.
The encapsulated FC frame begins with a SOF word (SOF, SOF, -SOF, -SOF bytes), followed by FC frame content (always a multiple of four 8-bit bytes), and ends with an EOF word (EOF, EOF, -EOF, -EOF bytes). SOF and EOF values are encoded using 8-bit codes from defined tables (e.g., SOFf=0x28, EOFn=0x41), with one's complement redundancy for error protection.
The FC Encapsulation Header is a fixed 7-word (28-byte) structure containing: Protocol# (8-bit), Version (8-bit), -Protocol# (8-bit), -Version (8-bit) in word 0; two Encapsulating Protocol Specific words (words 1-2); Flags (6-bit) and Frame Length (10-bit) with their one's complements in word 3; Time Stamp [Seconds] (32-bit) in word 4; Time Stamp [Seconds Fraction] (32-bit) in word 5; and CRC (32-bit) in word 6.