Request for Comments: 3643 Brocade
Category: Standards Track M. Rajagopal
Broadcom Corporation
F. Travostino
Nortel Networks
M. O’Donnell
McDATA
C. Monia
Nishan Systems
M. Merhar
Sun Microsystems
December 2003
Fibre Channel (FC) Frame Encapsulation
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes the common Fibre Channel (FC) frame
encapsulation format and a procedure for the measurement and
calculation of frame transit time through the IP network. This
specification is intended for use by any IETF protocol that
encapsulates FC frames.
Table Of Contents
1. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Encapsulation Concepts . . . . . . . . . . . . . . . . . . . . 3
3. The FC Encapsulation Header. . . . . . . . . . . . . . . . . . 4
3.1. FC Encapsulation Header Format . . . . . . . . . . . . . 4
3.2. FC Encapsulation Header Validation . . . . . . . . . . . 7
3.2.1. Redundancy Based FC Encapsulation
Header Validation. . . . . . . . . . . . . . . . 7
3.2.2. CRC Based FC Encapsulation Header Validation . . 7
4. Measuring Fibre Channel Frame Transit Time . . . . . . . . . . 8
5. The FC Frame . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. FC Frame Content . . . . . . . . . . . . . . . . . . . . 10
5.2. Bit and Byte Ordering. . . . . . . . . . . . . . . . . . 10
5.3. FC SOF and EOF . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix
A Fibre Channel Bit and Byte Numbering Guidance . . . . . . . . . 15
B Encapsulating Protocol Requirements . . . . . . . . . . . . . . 15
C IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16
D Intellectual Property Rights Statement. . . . . . . . . . . . . 17
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 20
1. Scope
This document describes common mechanisms for the transport of Fibre
Channel frames over an IP network, including the encapsulation format
and a mechanism for enforcing the Fibre Channel frame lifetime
limits.
Warning to Readers Familiar With Fibre Channel: Both Fibre Channel
and IETF standards use the same byte transmission order. However, the
bit and byte numbering is different. See Appendix A for guidance.
The organization responsible for the Fibre Channel standards (INCITS
Technical Committee T11) has determined that some functions and modes
of operation are not interoperable to the degree required by the IETF
(see FC-MI [8]). This document includes applicable T11
interoperability determinations in the form of restrictions on the
use of this encapsulation mechanism.
Use of these mechanisms in an encapsulating protocol requires an
additional document to specify the encapsulating protocol specific
functionality and appropriate security considerations. Because
security considerations for this encapsulation depend on how it is
used by encapsulating protocols, they are taken up in encapsulating
protocol specific documents.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in BCP 14, RFC
2119 [2].
2. Encapsulation Concepts
The smallest unit of data transmission and routing in Fibre Channel
(FC) is the frame. FC frames include a Start Of Frame (SOF), End Of
Frame (EOF), and the contents of the Fibre Channel frame. The Fibre
Channel frame includes a Cyclic Redundancy Check (CRC) code that
provides error detection for the contents of the frame. FC frames
are variable length. To facilitate transporting FC frames over an IP
based transport such as TCP the native FC frame needs to be contained
in (encapsulated in) a slightly larger structure as shown in Figure
1.
+--------------------+
| Header |
+--------------------+-----+
| SOF | f |
+--------------------+ F r |
| FC frame content | C a |
+--------------------+ m |
| EOF | e |
+--------------------+-----+
Figure 1 - FC frame Encapsulation
The format and content of an FC frame are described in the FC
standards (e.g., FC-FS [3], FC-SW-2 [4], and FC-PI [5]). Of
importance to this encapsulation is the FC requirement that all
frames SHALL contain a CRC for detection of transmission errors.
3. The FC Encapsulation Header
3.1. FC Encapsulation Header Format
Figure 2 shows the format of the required FC Encapsulation Header.
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------+---------------+---------------+---------------+
0| Protocol# | Version | -Protocol# | -Version |
+---------------+---------------+---------------+---------------+
1| |
+----- Encapsulating Protocol Specific ----+
2| |
+-----------+-------------------+-----------+-------------------+
3| Flags | Frame Length | -Flags | -Frame Length |
+-----------+-------------------+-----------+-------------------+
4| Time Stamp [Seconds] |
+---------------------------------------------------------------+
5| Time Stamp [Seconds Fraction] |
+---------------------------------------------------------------+
6| CRC |
+---------------------------------------------------------------+
Figure 2 - FC Encapsulation Header Format
The fields in the FC Encapsulation Header are defined as follows.
Protocol#: The Protocol# field SHALL contain a number that indicates
which encapsulating protocol is employing the FC Encapsulation.
The values in the Protocol# field are assigned by IANA (see
Appendix C).
Version: The Version field SHALL contain 0x01 to indicate that this
version of the FC Encapsulation is being used. All other values
are reserved for future versions of the FC Encapsulation.
-Protocol#: The -Protocol# field SHALL contain the one’s complement
of the contents of the Protocol# field. FC Encapsulation
receivers SHOULD either validate the CRC or compare the Protocol#
and - Protocol# fields to verify that an FC Encapsulation Header
is being processed according to a policy defined by the
encapsulating protocol.
-Version: The -Version field SHALL contain the one’s complement of
the contents of the Version field. FC Encapsulation receivers
SHOULD either validate the CRC or compare the Version and -Version
fields to verify that an FC Encapsulation Header is being
processed according to a policy defined by the encapsulating
protocol.
Encapsulating Protocol Specific: The usage of these words differs
based on the contents of the Protocol# field, i.e., the usage of
these words is defined by the encapsulating protocol that is
employing this encapsulation.
Flags: The Flags bits provide information about the usage of the
FC Encapsulation Header as shown in Figure 3.
|------------------------Bit--------------------------|
| |
| 0 1 2 3 4 5 |
+--------------------------------------------+--------+
| Reserved | CRCV |
+--------------------------------------------+--------+
Figure 3 - Flags Field Format
Reserved Flags bits: These bits are reserved for use by future
versions of the FC Encapsulation and SHALL be set to zero on send.
Encapsulating protocols employing the encapsulation described in
this specification MAY require checking for zero on receive,
however doing so has the potential to create incompatibilities
with future versions of this encapsulation. Changes in the usage
of the Reserved Flags bits MUST be identified by changes in the
contents of the Version field. Encapsulating protocols employing
the encapsulation described in this specification MUST NOT make
use of the Reserved Flags bits in any fashion other than that
described in this specification.
CRCV (CRC Valid Flag): A CRCV bit value of one indicates that
the contents of the CRC field are valid. A CRCV bit value of zero
indicates that the contents of the CRC field are invalid. The
value of the CRCV bit SHALL be constant for all FC Encapsulation
Headers sent on a given connection.
Frame Length: The Frame Length field contains the length of the
entire FC Encapsulated frame including the FC Encapsulation Header
and the FC frame (including SOF and EOF words). This length is
based on a unit of 32-bit words. All FC frames are 32-bit-word-
aligned and the FC Encapsulation Header is always word-aligned;
therefore a32-bit word length is acceptable.
-Flags: The -Flags field SHALL contain the one’s complement of the
contents of the Flags field. FC Encapsulation receivers SHOULD
either validate the CRC or compare the Flags and -Flags fields to
verify that an FC Encapsulation Header is being processed
according to a policy defined by the encapsulating protocol.
-Frame Length: The -Frame Length field SHALL contain the one’s
complement of the contents of the Frame Length field. FC
Encapsulation receivers SHOULD either validate the CRC or compare
the Frame Length and -Frame Length fields to verify that an FC
Encapsulation Header is being processed according to a policy
defined by the encapsulating protocol.
Time Stamp [Seconds]: The Time Stamp [Seconds] field contains zero
or the number of seconds since 0 hour on 1 January 1900 at the
time the FC Encapsulated frame is place in the outgoing data
stream.
Time Stamp [Seconds Fraction]: The Time Stamp [Second Fraction]
field contains the fraction of the second at the time the FC
Encapsulated frame is place in the outgoing data stream. Non-
significant low order bits may be set to zero. Table 1 shows some
example Time Stamp [Seconds Fraction] values.
+------------+--------------------+
| | Time Stamp |
| Second | [Seconds Fraction] |
+------------+--------------------+
| n.50000... | 0x80000000 |
| n.25000... | 0x40000000 |
| n.12500... | 0x20000000 |
+------------+--------------------+
Table 1 Example Time Stamp [Seconds Fraction] values
Note that, since some time in 1968 (second 2,147,483,648) the most
significant bit (bit 0 of Time Stamp [Seconds]) has been set and that
the field will overflow some time in 2036 (second 4,294,967,296).
Should FCIP be in use in 2036, some external means will be necessary
to qualify time relative to 1900 and time relative to 2036 (and other
multiples of 136 years). There will exist a 200-picosecond interval,
henceforth ignored, every 136 years when the 64-bit field will be 0,
which by convention is interpreted as an invalid or unavailable
timestamp.
The Time Stamp [Seconds] and Time Stamp [Seconds Fraction] words
follow the in time format described in Simple Network Time Protocol
(SNTP) Version 4 [9]. The contents of the Time Stamp [Seconds] and
Time Stamp [Seconds Fraction] words SHALL be set as described in
section 4.
CRC: When the CRCV Flag bit is zero, the CRC field SHALL contain
zero. When the CRCV Flag bit is one, the CRC field SHALL contain a
CRC for words 0 to 5 of the FC Encapsulation Header computed using
the equations, polynomial, initial value, and bit order defined for
Fibre Channel in FC-FS [3]. Using this algorithm, the bit order of
the resulting CRC corresponds to that of FC-1 layer. The CRC
transmitted over the IP network shall correspond to the equivalent
value converted to FC-2 format as specified in FC-FS.
3.2. FC Encapsulation Header Validation
Two mechanisms are provided for validating an FC Encapsulation
Header:
- Redundancy based
- CRC based
The two mechanisms address the needs of two different design and
operating environments.
3.2.1. Redundancy Based FC Encapsulation Header Validation
Redundancy based validation of an FC Encapsulation Header relies on
duplicated and one’s complemented fields in the header.
Encapsulating protocols that use redundancy based validation SHOULD
define how receiving devices use one’s complement fields to verify
header validity.
Header validation based on redundancy is a stepwise process in that
the first word is validated, then the second, then the third and so
on. A decision that a candidate header is not valid may be reached
before the complete header is available.
3.2.2. CRC Based FC Encapsulation Header Validation
CRC based validation of an FC Encapsulation Header relies on a CRC
located in the last word of the header.
Header validation based on the CRC defined in section 3.1 requires
computing the CRC for all bytes preceding the CRC word, and comparing
the results to the CRC word’s contents.
4. Measuring Fibre Channel Frame Transit Time
To comply with FC-FS [3], an FC Fabric must specify and limit the
lifetime of a frame. In an FC Fabric comprised of IP-connected
elements, one component of the frame’s lifetime is the time required
to traverse the connection. To ensure that the total frame lifetime
remains within the limits required by the FC Fabric, the
encapsulation described in this specification contains provisions for
recording the departure time of an encapsulated frame injected into a
connection. If the encapsulated frame originator and recipient have
access to aligned and synchronized time bases, the transit time
through the IP network can then be computed.
When originating an encapsulated frame, an entity that does not
support transit time calculation SHALL always set the Time Stamp
[Seconds] and Time Stamp [Seconds Fraction] fields to zero. When
receiving an encapsulated frame, an entity that does not support
transit time calculation SHALL ignore the contents of the Time Stamp
words.
The encapsulating protocol SHALL specify whether or not
implementation support is required. The encapsulating protocol SHALL
specify those conditions under which a received encapsulated frame
MUST have its transit time checked before forwarding.
Encapsulating and de-encapsulating entities that support this feature
MUST have access to:
a) An internal time base having the stability and resolution
necessary to comply with the requirements of the encapsulating
protocol specification; and
b) A time base that is synchronized and aligned with the time base of
other entities to which encapsulated frames may be sent or
received. The encapsulating protocol specification MUST describe
the synchronization and alignment procedure.
With respect to its ability to measure and set transit time for
encapsulated frames exchanged with another device, an entity is
either in the Synchronized or Unsynchronized state. An entity is in
the Unsynchronized state upon power-up and transitions to the
Synchronized state once it has aligned its time base in accordance
with the applicable encapsulating protocol specification.
An entity MUST return to the Unsynchronized state if it is unable to
maintain synchronization of its time base as required by the
encapsulating protocol specification.
The policy for forwarding frames while in the Unsynchronized state
SHALL be defined by the encapsulating protocol specification.
If processing frames in the Unsynchronized state is permitted by the
encapsulating protocol specification, the entity SHALL:
a) When de-encapsulating a frame, ignore the Time Stamp words. For
example, if a calculated transit time exceeds a value that could
cause the frame to violate FC maximum time in transit limits, the
encapsulating protocol may specify that the frame is to be
discarded; and
b) When encapsulating a frame set the Time Stamp [Seconds] and Time
Stamp [Seconds Fraction] words to zero. For example, an
encapsulating protocol may specify that frames for which transit
time cannot be determined are never to be forwarded over FC.
When encapsulating a frame, an entity in the Synchronized state SHALL
record the value of the time base in the Time Stamp [Seconds] and
Time Stamp [Seconds Fraction] words in the encapsulation header.
When de-encapsulating a frame, an entity in the Synchronized state
SHALL:
a) Test the Time Stamp words to determine if they contain a time as
specified in [9]. If the time stamp is valid, the receiving
entity SHALL compute the transit time by calculating the
difference between its time base and the departure time recorded
in the frame header. The receiving entity SHALL process the
calculated transit time and the de-encapsulated frame in
accordance with the applicable encapsulating protocol
specification; or
b) If both Time Stamp words have a value of zero, the receiving
entity SHALL de-encapsulate the frame without computing the
transit time. The disposition of the frame and any other actions
by the recipient SHALL be defined by the encapsulating protocol
specification.
Note: For most purposes, communication between entities is possible
only while in the Synchronized state.
5. The FC Frame
5.1. FC Frame Content
NOTE: All uses of the words "character" or "characters" in this
section refer to 8bit/10bit link encoding wherein each 8 bit
"character" within a link frame is encoded as a 10 bit "character"
for link transmission. These words do not refer to ASCII, Unicode,
or any other form of text characters, although octets from such
characters will occur as 8 bit "characters" for this encoding. This
usage is employed here for consistency with the ANSI T11 standards
that specify Fibre Channel.
Figure 4 shows the structure of a general FC-2 frame format.
+------------------+
| SOF |
+------------------+
| FC frame content |
+------------------+
| EOF |
+------------------+
Figure 4 - General FC-2 Frame Format
As shown in Figure 4, the FC frame content is defined as the data
between the EOF and SOF delimiters (including the FC CRC) after
conversion from FC-1 to FC-2 format as specified by FC-FS [3].
When Fibre Channel devices convert the FC frame content to the FC-0
physical transport, an encoding is applied to the FC frame content
(e.g., 8b/10b encoding like that used in Gigbit Ethernet) for reasons
that include redundancy and low level timing synchronization between