IPS Working Group R. Weber INTERNET-DRAFT Brocade <draft-ietf-ips-fcencapsulation-02.txt> (Expires February, 2002) M. Rajagopal Category: standards-track LightSand Communications F. Travostino Nortel Networks FC Frame Encapsulation V. Chau Gadzoox Networks M. O'Donnell McDATA C. Monia Nishan Systems M. Merhar Pirus Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as Reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on February 17, 2002. Rajagopal, et al. Standards Track [Page 1]
Internet-Draft FC Frame Encapsulation August, 2001 Abstract This is the ips (IP Storage) working group draft describing the common 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 Fibre Channel (FC) frames. This draft describes a frame header containing information mandated for encapsulating, transmitting, de-encapsulating, and calculating the transit times of FC frames. 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 RFC 2119 [2]. Table Of Contents 1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Encapsulation Concepts . . . . . . . . . . . . . . . . . . . . . 3 3. The FC Encapsulation Header . . . . . . . . . . . . . . . . . . 4 3.1 FC Encapsulation Header Format . . . . . . . . . . . . . . . . 4 3.2 FC Encapsulation Header Validation . . . . . . . . . . . . . . 6 3.2.1 Redundancy based FC Encapsulation Header validation . . . . . 6 3.2.2 CRC based FC Encapsulation Header validation . . . . . . . . 7 4. Measuring Fibre Channel frame transit time . . . . . . . . . . . 7 5. The FC frame . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1 FC frame content . . . . . . . . . . . . . . . . . . . . . . . 9 5.2 Bit and Byte Ordering . . . . . . . . . . . . . . . . . . . . . 9 5.3 FC SOF and EOF . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12 Annex A Protocol Requirements . . . . . . . . . . . . . . . . . . . . . 13 B IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 Rajagopal, et al. Standards Track [Page 2]
Internet-Draft FC Frame Encapsulation August, 2001 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. Use of these mechanisms in a protocol requires an additional document to specify the protocol-specific functionality and appropriate security considerations. Because security considerations for this encapsulation depend on how it is used by protocols, they are taken up in protocol-specific documents. 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), CRC coverage of the FC Payload for error detection. FC frames have several possible lengths. To facilitate transporting FC frames over 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 | +--------------------+-----+ Fig. 1 - FC frame Encapsulation The format and content of an FC frame is 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 an CRC for detection of transmission errors. Rajagopal, et al. Standards Track [Page 3]
Internet-Draft FC Frame Encapsulation August, 2001 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|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| +---------------+---------------+---------------+---------------+ 0| Protocol# | Version | -Protocol# | -Version | +---------------+---------------+---------------+---------------+ 1| | +----- Protocol Specific ----+ 2| | +-----------+-------------------+-----------+-------------------+ 3| Flags | Frame Length | -Flags | -Frame Length | +-----------+-------------------+-----------+-------------------+ 4| Time Stamp [integer] | +---------------------------------------------------------------+ 5| Time Stamp [fraction] | +---------------------------------------------------------------+ 6| CRC | +---------------------------------------------------------------+ Fig. 2 - FC Encapsulation Header Format The fields in the FC Encapsulation Header are defined as follows. Protocol (bits 31-24 in word 0): The Protocol# field SHALL contain a number that indicates which protocol is employing the FC Encapsulation. The values in the Protocol# field are assigned by IANA [6]. The following values are known to be in use: - FCIP -- TO BE ASSIGNED by IANA - iFCP -- TO BE ASSIGNED by IANA Version (bits 23-16 in word 0): The Version field SHALL contain 0x1 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# (bits 15-8 in word 0): The -Protocol# field contains the ones complement of the contents of the Protocol# field. FC Encapsulation receivers may compare the Protocol# and -Protocol# fields as an additional verification that an FC Encapsulation Header is being processed. Rajagopal, et al. Standards Track [Page 4]
Internet-Draft FC Frame Encapsulation August, 2001 -Version (bits 7-0 in word 0): The -Version field contains the ones complement of the contents of the Version field. FC Encapsulation receivers may compare the Version and -Version fields as an additional verification that an FC Encapsulation Header is being processed. Protocol Specific (words 1 and 2): The usage of these words differs based on the contents of the Protocol# field, i.e., the usage of this word is defined by the protocol that is employing this encapsulation. Flags (bits 31-26 in word 3): The Flags bits provide information about the usage of the FC Encapsulation Header as shown in figure 3. Note: Implementers are advised to consult the specifications of protocols that use this header to determine how each individual protocol uses the bits in the Flags field. |------------------------Bit--------------------------| | | | 31 30 29 28 27 26 | +--------------------------------------------+--------+ | Reserved | CRCV | +--------------------------------------------+--------+ Fig. 3 - Flags Field Format Reserved (Flags, bits 31-27 in word 3): These bits are reserved for use by future versions of the FC Encapsulation and SHALL be set to zero on send. Protocols employing this encapsulation 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. Protocols employing this encapsulation MUST NOT make use of the Reserved Flags bits in any fashion other than that described here. CRCV (CRC Valid Flag, bit 26 in word 3): A CRCV bit value of one indicates that the contents of the CRC field are valid. A CRCV bit value of zero indicates that CRC are invalid. Some protocols may always check the CRC without regard for the state of this bit. The value of the CRCV bit SHALL be constant for all FC Encapsulation Headers sent on a given TCP connection. Frame Length (bits 25-16 in word 3): 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). Rajagopal, et al. Standards Track [Page 5]
Internet-Draft FC Frame Encapsulation August, 2001 This length is based on a unit of 32-bit words. All FC frames are 32- bit-word-aligned and the FC Encapsulation Header SHALL always be word-aligned; therefore a 32-bit word length is acceptable. -Flags (bits 15-10 in word 3): The -Flags field contains the ones complement of the contents of the Flags field. FC Encapsulation receivers may compare the Flags and -Flags fields as an additional verification that an FC Encapsulation Header is being processed. -Frame Length (bits 9-0 in word 3): The -Frame Length field contains the ones complement of the contents of the Frame Length field. FC Encapsulation receivers may compare the Frame Length and -Frame Length fields as an additional verification that an FC Encapsulation Header is being processed. Time Stamp [integer] and Time Stamp [fraction] (words 4 and 5): The two Time Stamp contain time at which the FC Encapsulated frame was sent as known to the sender. The format of integer and fraction Time Stamp word values is specified in Simple Network Time Protocol (SNTP) Version 4 [7]. The contents of the Time Stamp [integer] and Time Stamp [fraction] words SHALL be set as described in section 4. CRC (word 6): 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 polynomial, initial value, and bit order defined for Fibre Channel [3]. 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. Validation of a header using redundancy may be accomplished using very simple logic (e.g., XORs and comparisons). Header validation based on redundancy also is a step wise process in that the first word is validated, then the second, then the third and so on. A Rajagopal, et al. Standards Track [Page 6]
Internet-Draft FC Frame Encapsulation August, 2001 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. Validation of a header using the CRC may be accomplished using a very straight forward algorithm, compute the CRC for all bytes preceding the CRC word and compare the results to the CRC word's contents. The number of comparisons required to perform CRC validation is exactly one and the method for computing the CRC is well known with proven implementations. 4. Measuring Fibre Channel frame transit time To comply with [3], a FC Fabric must specify and limit the lifetime of a frame. In an FC Fabric comprised of TCP-connected elements, one component of the frame's lifetime is the time required to traverse the TCP 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 TCP 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 [integer] and Time Stamp [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 protocol SHALL specify whether or not implementation support is required. 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 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 protocol specification MUST describe the synchronization and alignment procedure. Rajagopal, et al. Standards Track [Page 7]
Internet-Draft FC Frame Encapsulation August, 2001 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 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 protocol specification. The policy for processing frames while in the Unsynchronized state SHALL be defined by the protocol specification, including whether or not the entity may continue to send and receive frames from the IP network. If processing frames in the Unsynchronized state is permitted by the protocol specification, the entity SHALL: a) When de-encapsulating a frame, ignore the Time Stamp words; and b) When encapsulating a frame set the Time Stamp [integer] and Time Stamp [fraction] words to zero. When encapsulating a frame, an entity in the Synchronized state SHALL record the value of the time base in the Time Stamp [integer] and Time Stamp [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 [7]. 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 protocol specification; or b) If both Time Stamp words have a value of zero, the receiving entity SHALL process the de-encapsulated frame without computing the transit time. The disposition of the frame and any other actions by the recipient SHALL be defined by the protocol specification. Rajagopal, et al. Standards Track [Page 8]
Internet-Draft FC Frame Encapsulation August, 2001 5. The FC frame 5.1 FC frame content Figure 4 shows the structure of a general FC-2 frame format. +------------------+ | SOF | +------------------+ | FC frame content | +------------------+ | EOF | +------------------+ Fig. 4 - General FC-2 Frame Format 5.2 Bit and Byte Ordering FC frames are mapped to TCP using the big endian byte ordering, which corresponds to the standard network byte order or canonical form [8]. 5.3 FC SOF and EOF The FC frame content is composed of 8-bit bytes that can be translated directly for transmission over TCP. The SOF and EOF require 8b/10b special characters that cannot be translated directly to 8-bit bytes, encoded values are required. For this reason, the encapsulated FC frame SHALL have the format shown in figure 5. The redundancy of the SOF/EOF representation in the encapsulation format results from concerns that the information be protected from transmission errors. 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| +---------------+---------------+-------------------------------+ 0| SOF | SOF | -SOF | -SOF | +---------------+---------------+-------------------------------+ 1| | +----- FC frame content -----+ | | +---------------+---------------+-------------------------------+ n| EOF | EOF | -EOF | -EOF | +---------------+---------------+-------------------------------+ Fig. 5 - FC Frame Encapsulation Format Rajagopal, et al. Standards Track [Page 9]
Internet-Draft FC Frame Encapsulation August, 2001 SOF (bits 31-24 and bits 23-16 in word 0): The SOF fields contain the encoded SOF value selected from table 1. +-------+----------+ | FC | | | SOF | SOF Code | +-------+----------+ | SOFf | 0x28 | | SOFi2 | 0x2D | | SOFn2 | 0x35 | | SOFi3 | 0x2E | | SOFn3 | 0x36 | +-------+----------+ Table 1 Translation of FC SOF values to SOF field contents -SOF (bits 15-8 and 7-0 in word 0): The -SOF fields contain the one's complement of the value in the SOF fields. EOF (bits 31-24 and 23-16 in word n): The EOF fields contain the encoded EOF value selected from table 2. +-------+----------+ | FC | | | EOF | EOF Code | +-------+----------+ | EOFn | 0x41 | | EOFt | 0x42 | | EOFni | 0x49 | | EOFa | 0x50 | +-------+----------+ Table 2 Translation of FC EOF values to EOF field contents -EOF (bits 15-8 and 7-0 in word n): The -EOF fields contain the one's complement of the value in the EOF fields. 6. Security This document describes the encapsulation format only. Actual use of this format in a protocol requires an additional document to specify the protocol functionality and appropriate security considerations. Because security considerations for this encapsulation depend on how it is used by protocols, they SHALL be described in protocol- specific documents. Rajagopal, et al. Standards Track [Page 10]
Internet-Draft FC Frame Encapsulation August, 2001 7. 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), T11 Project 1331-D, Rev 1.2, February 16, 2001 (www.t11.org). [4] Fibre Channel Switch Fabric -2 (FC-SW-2), ANSI NCITS.355:200x, May 23, 2001 (www.t11.org). [5] Fibre Channel Physical Interfaces (FC-PI), ANSI NCITS.352:200x, August 18, 2000 (www.t11.org). [6] Reynolds, J. and Postel, J., "Assigned Numbers", RFC 1700, October, 1994. [7] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996. [8] Narten, T. and C. Burton, "A Caution on The Canonical Ordering of Link-Layer Addresses", RFC 2469, December 1998. 8. Authors' Addresses Ralph Weber Murali Rajagopal ENDL Texas LightSand Communications, Inc. representing Brocade Comm. 24411 Ridge Route Dr. Suite 102 PMB 178 Suite 135 18484 Preston Road Laguna Hills, CA 92653 Dallas, TX 75252 USA USA Phone: +1 949 837 1733 x101 Phone: +1 214 912 1373 Email: muralir@lightsand.com Email: roweber@acm.org Franco Travostino Vi Chau Technology Center Gadzoox Networks, Inc. Nortel Networks, Inc. 16241 Laguna Canyon Road 600 Technology Park Suite 100 Billerica, MA 01821 Irvine, CA 92618 USA USA Phone: +1 978 288 7708 Phone: +1 949 789 4639 Email: travos@nortelnetworks.com Fax: +1 949 453 1271 Email: vchau@gadzoox.com Rajagopal, et al. Standards Track [Page 11]
Internet-Draft FC Frame Encapsulation August, 2001 Michael E. O'Donnell Charles Monia McDATA Corporation Nishan Systems 310 Interlocken Parkway 3850 North First Street Broomfield, Co. 80021 San Jose, CA 95134 USA USA Phone: +1 303 460 4142 Phone: +1 408 519 3986 Fax: +1 303 465 4996 Email: cmonia@nishansystems.com Email: modonnell@mcdata.com Milan J. Merhar 43 Nagog Park Pirus Networks Acton, MA 01720 USA Phone: +1 978 206 9124 Email: Milan@pirus.com 9. Full Copyright Statement Copyright (C) The Internet Society (2001). 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. Rajagopal, et al. Standards Track [Page 12]
Internet-Draft FC Frame Encapsulation August, 2001 ANNEX A - Protocol Requirements This annex lists the requirements placed on the protocols that employ this encapsulation. The requirements listed here are suggested or described elsewhere in this document, but their collection in this annex serves to assist protocol authors in meeting all obligations placed upon them. Protocol Specific Data Protocols employing this encapsulation SHALL: - specify the IANA assigned number used in the Protocol# field - specify the contents of the Protocol Specific field CRC Protocols employing this encapsulation SHALL either: 1) Require a valid CRC to be sent and the CRCV Flag bit to be sent as one, or 2) Require the CRC field to be sent as zero and the CRCV Flag bit to be sent as zero. Protocols employing this encapsulation SHALL define the procedures and policies necessary for the detection of over age frames. The items to be specified and the choices available to a specification are as follows: a) The protocol requirements for measuring transit times. The 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 processing of frame traffic while in the Unsynchronized state. The specification MAY allow an entity in the Unsynchronized state to continue processing frame traffic. Rajagopal, et al. Standards Track [Page 13]
Internet-Draft FC Frame Encapsulation August, 2001 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. ANNEX B - IANA Considerations The Protocol# (Protocol Number, bits 31-24 in word 0 of the Encapsulation Header) field is an identifier number used to distinguish between the protocols that employ this encapsulation. Values used in the Protocol# field are to be assigned from a new, separate registry that is maintained by IANA in accordance with RFC 1700 [6]. All values in the Protocol# field are to be registered with and assigned by IANA with the following 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. Standards action on this RFC should be accompanied by IANA assignment of the following two Protocol# values: - Protocol# value 1 assigned to the FCIP (Fibre Channel Over TCP/ IP) protocol being developed in draft-ietf-ips-fcovertcpip-__.txt. - Protocol# value 2 assigned to the iFCP (A Protocol for Internet Fibre Channel Storage Networking) protocol being developed in draft-ietf-ips-ifcp-__.txt. Requests for assignments of Protocol# values must be accompanied by an RFC which describes how this encapsulation is employed. If the RFC is not on the standards-track (i.e., it is an informational or experimental RFC), it must be explicitly reviewed and approved by the IESG before the RFC is published and Protocol# value is assigned. It is requested that the ips working group chairs or the Transport Services area directors be notified when any new Protocol# value assignment is requested. Rajagopal, et al. Standards Track [Page 14]
