RFC 3643
Fibre Channel (FC) Frame Encapsulation
RFC 3643: Fibre Channel (FC) Frame Encapsulation 🎀
okay bestie, RFC 3643 is a Standards Track doc from the Network Working Group, dated December 2003. The authors are R. Weber (Brocade), M. Rajagopal (Broadcom Corporation), F. Travostino (Nortel Networks), M. O'Donnell (McDATA), C. Monia (Nishan Systems), and M. Merhar (Sun Microsystems) 🫶. It doesn't obsolete or update any other RFCs, since the title block doesn't list any. The whole point is getting Fibre Channel frames to travel over IP networks, so it's basically a crossover episode 🦋
Status of this Memo
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💖 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited ✨
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. 🌸
Abstract
okay so this doc describes the common Fibre Channel (FC) frame encapsulation format 📦 It also covers a procedure for measuring and calculating how long a frame takes to transit the IP network ⏱️ This spec is meant for any IETF protocol that encapsulates FC frames, so it's giving "everyone can use this" energy 🧚
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 . . . . . . . . . . . . . . . . . . . . . 201. Scope ✨
so this doc covers the common ways to transport Fibre Channel frames over an IP network 🌈 That includes 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) decided that some functions and modes of operation aren't interoperable to the degree the IETF requires (see FC-MI [8]). This doc includes the applicable T11 interoperability determinations, written as restrictions on how this encapsulation mechanism gets used 💅
Using these mechanisms in an encapsulating protocol needs an additional document. That doc specifies the encapsulating protocol's own functionality and its security considerations 🔐 Security depends on how the encapsulating protocols actually use this encapsulation, so those considerations live in the encapsulating protocol specific documents instead of here 🙈
Conventions used in this document
the BCP 14 key words in this doc are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 🫶 They're interpreted as described in BCP 14, RFC 2119 [2]. Keep those exact, bestie, they're load-bearing 💜
2. Encapsulation Concepts 🧚
okay so the smallest unit of data transmission and routing in Fibre Channel (FC) is the frame 🍓 An FC frame has a Start Of Frame (SOF), an End Of Frame (EOF), and the contents of the Fibre Channel frame. The contents include a Cyclic Redundancy Check (CRC) code, which provides error detection for the frame's contents 🔍 FC frames are variable length. To move FC frames over an IP based transport like TCP, the native FC frame gets encapsulated in a slightly larger structure, shown in Figure 1 below 🎀
+--------------------+
| Header |
+--------------------+-----+
| SOF | f |
+--------------------+ F r |
| FC frame content | C a |
+--------------------+ m |
| EOF | e |
+--------------------+-----+
Figure 1 - FC frame Encapsulationthe format and content of an FC frame are described in the FC standards (for example FC-FS [3], FC-SW-2 [4], and FC-PI [5]) 📚 The big thing for this encapsulation is that FC requires all frames to contain a CRC for detecting transmission errors, so this one is a must-have, no cap 😭 Just know that the rule is that all frames SHALL contain that CRC 💀
3. The FC Encapsulation Header ✨
3.1. FC Encapsulation Header Format 🎀
Okay bestie, here's the FC Encapsulation Header 💖 It's the header you absolutely need, and Figure 2 shows exactly how it's laid out:
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 FormatNow let's go through each field 🦋
Protocol#: This field SHALL contain a number that tells you which encapsulating protocol is using the FC Encapsulation. The values in Protocol# are assigned by IANA (see Appendix C) 🌸
Version: This field SHALL contain 0x01 to show that this version of the FC Encapsulation is in use. Every other value is reserved for future versions of the FC Encapsulation 💅
-Protocol#: This field SHALL contain the one's complement of whatever is in Protocol#. FC Encapsulation receivers SHOULD either validate the CRC or compare the Protocol# and -Protocol# fields, so they can check that the header is being handled according to a policy defined by the encapsulating protocol 🔥
-Version: This field SHALL contain the one's complement of whatever is in Version. FC Encapsulation receivers SHOULD either validate the CRC or compare the Version and -Version fields, so they can check that the header is being handled according to a policy defined by the encapsulating protocol ✨
Encapsulating Protocol Specific: The meaning of these words changes depending on what's in Protocol#. In other words, the encapsulating protocol that's using this encapsulation is the one that defines what they mean 🧚
Flags: The Flags bits tell you how the FC Encapsulation Header is being used, 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 future versions of the FC Encapsulation, and they SHALL be set to zero on send. Encapsulating protocols that use this encapsulation MAY require checking for zero on receive, but this has the potential to create incompatibilities with future versions of the encapsulation. Any change in how the Reserved Flags bits are used MUST be identified by a change in the contents of the Version field. Encapsulating protocols that use this encapsulation MUST NOT make use of the Reserved Flags bits in any way other than what's described in this specification. Don't go rogue with these, bestie 🙈
CRCV (CRC Valid Flag): A CRCV bit value of one means the contents of the CRC field are valid. A CRCV bit value of zero means they're invalid. The value of the CRCV bit SHALL stay constant for every FC Encapsulation Header sent on a given connection 🌈
Frame Length: This field holds the length of the entire FC Encapsulated frame. That includes the FC Encapsulation Header and the FC frame (including the SOF and EOF words). The length is measured in units of 32-bit words. All FC frames are 32-bit-word-aligned and the FC Encapsulation Header is always word-aligned, so a 32-bit word length is good enough 🦋
-Flags: This field SHALL contain the one's complement of whatever is in Flags. FC Encapsulation receivers SHOULD either validate the CRC or compare the Flags and -Flags fields, so they can check that the header is being handled according to a policy defined by the encapsulating protocol 💖
-Frame Length: This field SHALL contain the one's complement of whatever is in Frame Length. FC Encapsulation receivers SHOULD either validate the CRC or compare the Frame Length and -Frame Length fields, so they can check that the header is being handled according to a policy defined by the encapsulating protocol 🫶
Time Stamp [Seconds]: This field contains either zero or the number of seconds since 0 hour on 1 January 1900, measured at the moment the FC Encapsulated frame is placed in the outgoing data stream ⭐
Time Stamp [Seconds Fraction]: This field contains the fraction of the second at the moment the FC Encapsulated frame is placed 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
Okay, this part is kind of a plot twist 😭 Since some time in 1968 (second 2,147,483,648), the most significant bit (bit 0 of Time Stamp [Seconds]) has been set, and this field is going to overflow sometime in 2036 (second 4,294,967,296). If FCIP is still in use in 2036, some external means will be needed to tell time relative to 1900 apart from time relative to 2036 (and other multiples of 136 years). Also, every 136 years there's a 200-picosecond interval, which we're going to ignore, where the 64-bit field is 0. By convention, that's read as an invalid or unavailable timestamp 💀
The Time Stamp [Seconds] and Time Stamp [Seconds Fraction] words follow the 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. That CRC is computed using the equations, polynomial, initial value, and bit order defined for Fibre Channel in FC-FS [3]. With this algorithm, the bit order of the resulting CRC matches that of the 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 🦋
There are two mechanisms for validating an FC Encapsulation Header, and they're built for two different design and operating environments 💜
- Redundancy based
- CRC based
3.2.1. Redundancy Based FC Encapsulation Header Validation 🌸
Redundancy based validation relies on the duplicated, one's complemented fields in the header. The fields do the checking for each other 🫶
Encapsulating protocols that use redundancy based validation SHOULD define how receiving devices use the one's complement fields to verify that the header is valid.
Header validation based on redundancy is a stepwise process: 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. Fast rejects, iykyk ⚡
3.2.2. CRC Based FC Encapsulation Header Validation 💅
CRC based validation relies on a CRC that lives in the last word of the header 👑
Header validation based on the CRC defined in section 3.1 means computing the CRC for all the bytes that come before the CRC word, then comparing the result to the contents of the CRC word 🔥
4. Measuring Fibre Channel Frame Transit Time ⭐
okay so, FC-FS [3] says an FC Fabric has to specify and limit how long a frame is allowed to live 🕰️ and that's a whole big deal. when the fabric is made of IP-connected parts, one chunk of that frame's lifetime is just the time it spends crossing the connection. 💅 so this encapsulation has a built-in way to record the departure time of a frame as it goes into the connection. if the sender and receiver have aligned, synchronized time bases, they can work out the transit time through the IP network. iconic, honestly 🧚
when an entity originates an encapsulated frame and it doesn't support transit time calculation, it SHALL always set the Time Stamp [Seconds] and Time Stamp [Seconds Fraction] fields to zero. when that same kind of entity receives an encapsulated frame, it SHALL ignore the contents of the Time Stamp words. 🫶
the encapsulating protocol SHALL specify whether or not implementation support is required. it also SHALL specify the conditions under which a received encapsulated frame MUST have its transit time checked before forwarding. 🔥
entities that do support this feature MUST have access to two things:
- a) an internal time base with the stability and resolution needed to meet the requirements of the encapsulating protocol specification; and
- b) a time base that is synchronized and aligned with the time base of other entities that encapsulated frames may be sent to or received from. the encapsulating protocol specification MUST describe the synchronization and alignment procedure.
so an entity is either in the Synchronized state or the Unsynchronized state when it comes to measuring and setting transit time for frames it swaps with another device. it starts out Unsynchronized at power-up, and it moves to Synchronized once it has aligned its time base the way the encapsulating protocol spec says. 🌸
an entity MUST return to the Unsynchronized state if it can't keep its time base synchronized the way the encapsulating protocol specification requires. ⚠️
the policy for forwarding frames while in the Unsynchronized state SHALL be defined by the encapsulating protocol specification. 💖
if the encapsulating protocol spec allows processing frames while Unsynchronized, the entity SHALL do the following:
- a) when de-encapsulating a frame, ignore the Time Stamp words. for example, if a calculated transit time is so long that it could make the frame break FC's maximum time in transit limits, the encapsulating protocol may say the frame gets 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 say that frames whose transit time can't be figured out are never forwarded over FC.
when an entity in the Synchronized state encapsulates a frame, it SHALL record the value of its time base in the Time Stamp [Seconds] and Time Stamp [Seconds Fraction] words in the encapsulation header. ⏰
when an entity in the Synchronized state de-encapsulates a frame, it SHALL do one of these two things:
- a) test the Time Stamp words to see if they hold a time as specified in [9]. if the time stamp is valid, the receiving entity SHALL compute the transit time by taking the difference between its own time base and the departure time recorded in the frame header. the receiving entity SHALL then process the calculated transit time and the de-encapsulated frame in line with the applicable encapsulating protocol specification; or
- b) if both Time Stamp words are 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. 🎀
okay this part is a little nerdy, but it's important! the word "character" here means the 8bit/10bit link encoding thing. each 8 bit "character" in a link frame gets turned into a 10 bit "character" for transmission. it has nothing to do with ASCII or Unicode, even though octets from those characters can show up as 8 bit "characters." they used this wording so it lines up with the ANSI T11 standards for 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 Figure 4 shows, the FC frame content is the data between the EOF and SOF delimiters (including the FC CRC) after it's converted from FC-1 to FC-2 format, as FC-FS [3] specifies. 💅
when Fibre Channel devices turn the FC frame content into the FC-0 physical transport, they apply an encoding to it (like the 8b/10b encoding used in Gigabit Ethernet) for things like redundancy and low level timing synchronization between sender and receiver. apart from SOF and EOF [3], everything about FC frame content in this document is at the 8-bit byte level, before any of that encoding happens. 🧚
the 8-bit bytes in the FC frame content can be translated straight over to an IP network. the FC SOF and EOF are different though, because they use special 10b characters that have no 8b equivalent. so special byte placement and 8-bit character encodings are needed to represent SOF and EOF. 🦋
5.2. Bit and Byte Ordering
the Encapsulation Header, SOF, FC frame content (see section 5.1), and EOF all get mapped to TCP using big endian byte ordering, which matches the standard network byte order or canonical form [7]. 🌈
5.3. FC SOF and EOF
as section 5.1 explained, showing FC SOF and EOF in an IP network byte stream takes special formatting and 8-bit code definitions. so the encapsulated FC frame SHALL have the format shown in Figure 5. the redundancy in the SOF/EOF representation is there to protect the information from transmission errors. 🛡️
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| SOF | SOF | -SOF | -SOF |
+---------------+---------------+-------------------------------+
1| |
+----- FC frame content -----+
| |
+---------------+---------------+-------------------------------+
n| EOF | EOF | -EOF | -EOF |
+---------------+---------------+-------------------------------+
Figure 5 - FC Frame Encapsulation FormatNote: The number of 8-bit bytes in the FC frame content is always a multiple of four. 📏
SOF: the SOF fields hold the encoded SOF value picked from table 2.
+-------+------+-------+ +-------+------+-------+
| FC | SOF | | | FC | SOF | |
| SOF | Code | Class | | SOF | Code | Class |
+-------+------+-------+ +-------+------+-------+
| SOFf | 0x28 | F | | SOFi4 | 0x29 | 4 |
| SOFi2 | 0x2D | 2 | | SOFn4 | 0x31 | 4 |
| SOFn2 | 0x35 | 2 | | SOFc4 | 0x39 | 4 |
| SOFi3 | 0x2E | 3 | +-------+------+-------+
| SOFn3 | 0x36 | 3 |
+-------+------+-------+
Table 2 Translation of FC SOF values to SOF field contents-SOF: the -SOF fields hold the one's complement of the value in the SOF fields. encapsulation receivers SHOULD validate the SOF field according to a policy defined by the encapsulating protocol. 🔍
EOF: the EOF fields hold the encoded EOF value picked from table 3.
+-------+------+---------+ +--------+------+-------+
| FC | EOF | | | FC | EOF | |
| EOF | Code | Class | | EOF | Code | Class |
+-------+------+---------+ +--------+------+-------+
| EOFn | 0x41 | 2,3,4,F | | EOFdt | 0x46 | 4 |
| EOFt | 0x42 | 2,3,4,F | | EOFdti | 0x4E | 4 |
| EOFni | 0x49 | 2,3,4,F | | EOFrt | 0x44 | 4 |
| EOFa | 0x50 | 2,3,4,F | | EOFrti | 0x4F | 4 |
+-------+------+---------+ +--------+------+-------+
Table 3 Translation of FC EOF values to EOF field contents-EOF: the -EOF fields hold the one's complement of the value in the EOF fields. encapsulation receivers SHOULD validate the EOF field according to a policy defined by the encapsulating protocol. 🔍
Note: FC-BB-2 [6] lists SOF and EOF codes that aren't in table 2 or table 3 (for example, SOFi1 and SOFn1). however, FC-MI [8] says these codes aren't interoperable, so this specification doesn't list them. 🙅♀️
6. Security Considerations 🔐
okay, this part is SERIOUS bestie, so read it carefully 😭 this document only describes the encapsulation format. actually using this format in an encapsulating protocol needs another document that specifies that protocol's functionality and its appropriate security considerations. since the security considerations for this encapsulation depend on how encapsulating protocols use it, they SHALL be described in the encapsulating protocol specific documents. no skipping this, it's the whole ballgame 🛑💀
7. References 📚
7.1. Normative References
- [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [3] Fibre Channel Framing and Signaling (FC-FS), ANSI INCITS.373:2003, October 27, 2003. Note: Published T11 standards are available from the INCITS online store http://www.incits.org, or the ANSI online store, http://www.ansi.org.
- [4] Fibre Channel Switch Fabric -2 (FC-SW-2), ANSI NCITS.355:2001, December 12, 2002. Note: Published T11 standards are available from the INCITS online store http://www.incits.org, or the ANSI online store, http://www.ansi.org.
- [5] Fibre Channel Physical Interfaces (FC-PI), ANSI NCITS.352:2002, December 1, 2002. Note: Published T11 standards are available from the INCITS online store http://www.incits.org, or the ANSI online store, http://www.ansi.org.
- [6] Fibre Channel Backbone -2 (FC-BB-2), ANSI INCITS.372:2003, July 25, 2003. Note: Published T11 standards are available from the INCITS online store http://www.incits.org, or the ANSI online store, http://www.ansi.org.
- [7] Narten, T. and C. Burton, "A Caution on The Canonical Ordering of Link-Layer Addresses", RFC 2469, December 1998.
That's the end of the normative references for this part, babe 🎀 we're getting close to the finish line!
7.2. Informative References ✨
- [8] Fibre Channel Methodologies for Interconnects (FC-MI), ANSI INCITS/TR-30:2002, November 1, 2002. Note: Published T11 standards are available from the INCITS online store
http://www.incits.org, or the ANSI online store,http://www.ansi.org. - [9] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
- [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [11] Rajagopal, M., Rodriguez, E., Weber, R., "Fibre Channel Over TCP/IP (FCIP)", Work in Progress.
- [12] Monia, C., et. al., "iFCP - A Protocol for Internet Fibre Channel Storage Networking", Work in Progress.
8. Acknowledgements 🫶
okay bestie, big thank-you moment 💖 The authors shout out Mr. Vi Chau (vchau1@cox.net) for his work on the design team that built this document. Mr. Chau is no longer working in this technology, so we send him lots of love 🌸
The authors are also grateful to Dr. David Black, Mr. Mallikarjun Chadalapaka, and Mr. Robert Elliott for reviewing this spec. Reviewers are the unsung heroes fr fr 👑
Appendix A - Fibre Channel Bit and Byte Numbering Guidance 🎀
okay so this one is lowkey the tea ☕ Fibre Channel and IETF standards use the same byte transmission order. The bit and byte numbering is where they differ, and that's the whole drama 🙈
You can actually see the Fibre Channel numbering if you cut and paste the data structure heading from Figure 6 onto the top of Figure 2 and Figure 5. Iconic ✨
W|------------------------------Bit------------------------------|
o| |
r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 |
d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0|Figure 6 - Fibre Channel Data Structure Bit and Byte Numbering
The Fibre Channel bit numbering for the Flags field works the same way: cut and paste the heading from Figure 7 onto the top of Figure 3 💅
|------------------------Bit--------------------------|
| |
| 31 30 29 28 27 26 |Figure 7 - Fibre Channel Flags Bit Numbering
Appendix B - Encapsulating Protocol Requirements 📝
okay this appendix is the checklist for any protocol that wants to use this encapsulation 💅 Everything here is already said somewhere else in the doc, but gathering it all in one place helps encapsulating protocol authors hit every single obligation. No cap, it's a lifesaver 🧚
Encapsulating Protocol Specific Data
Encapsulating protocols using this encapsulation SHALL:
- specify the IANA assigned number used in the Protocol# field
- specify the contents of the Encapsulating Protocol Specific field
Encapsulating protocols using this encapsulation SHALL define the procedures and policies necessary for verifying that an FC Encapsulation Header is being processed. Non-negotiable, periodt 💖
Encapsulating protocols using this encapsulation SHALL define the procedures and policies necessary for the detection of over age frames. Here are the items to be specified and the choices available to an encapsulating protocol specification:
- a) The encapsulating protocol requirements for measuring transit times. The encapsulating protocol MAY allow implementation of transit time measurement to be optional.
- b) The requirements or guidelines for stability and resolution of the entity's time base.
- c) The procedure for synchronizing an entity's time base, including the criteria for entering the Synchronized and Unsynchronized states.
- d) The forwarding (or lack of forwarding) of frame traffic while in the Unsynchronized state. The specification MAY allow an entity in the Unsynchronized state to continue processing frame traffic.
- e) The procedure to be followed when frames are received that do not have a valid time stamp. The specification MAY allow such frames to be accepted by the entity.
- f) Requirements for setting and testing the transit time limit and the procedure to be followed when a received frame is discarded due to its transit time exceeding the limit. 🔥
Appendix C - IANA Considerations 🌈
okay so the Protocol# (Protocol Number) field is an identifier that tells apart the encapsulating protocols using this FC frame encapsulation 🦋 The values in that field get assigned from a new, separate registry that IANA maintains. Main character registry energy ✨
All Protocol# values are to be registered with and assigned by IANA, with these exceptions:
- Protocol# value 0 should not be assigned until after all other values have been assigned. ⭐
- Protocol# values 240-255 inclusive must be set aside for private use amongst cooperating systems. 🔒
Following the policies outlined in [10], Protocol# values not listed above are to be assigned only for Standards Track RFCs approved by the IESG. Strict, but make it make sense 💅
Besides creating the FC Frame Encapsulation Protocol Number Registry, the standards action of this RFC allocates these two values from the registry, and I'm obsessed:
- Protocol# value 1 assigned to the FCIP (Fibre Channel Over TCP/IP) encapsulating protocol [11]. 🩵
- Protocol# value 2 assigned to the iFCP (A Protocol for Internet Fibre Channel Storage Networking) encapsulating protocol [12]. 💜
Appendix D - Intellectual Property Rights Statement ⚖️
bestie, this is the legal bit, so I'm keeping it complete and close to the original 🫶
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication, any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Authors' Addresses 💌
Ralph Weber
ENDL Texas
representing Brocade Comm.
Suite 102 PMB 178
18484 Preston Road
Dallas, TX 75252
USA
Phone: +1 214 912 1373
EMail: roweber@ieee.org
Murali Rajagopal
Broadcom
16215 Alton Parkway
PO Box 57013
Irvine, CA 92619
USA
Phone: +1 949 450 8700
EMail: muralir@broadcom.com
Franco Travostino
Technology Center
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821
USA
Phone: +1 978 288 7708
EMail: travos@nortelnetworks.com
Michael E. O'Donnell
McDATA Corporation
4 McDATA Parkway
Broomfield, Co. 80021
USA
Phone +1 720 558 4142
Fax +1 720 558 8999
EMail: mike.o'donnell@mcdata.com
Charles Monia
EMail: cmonia@pacbell.net
Milan J. Merhar
Sun Microsystems
43 Nagog Park
Acton, MA 01720
USA
Phone: +1 978 206 9124
EMail: milan.merhar@sun.comFull Copyright Statement 📜
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 💜
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society, you're literally keeping the lights on ✨🌸
📦 where this page comes from
- ietf: rfc3643 2003-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms