IPS Working Group V. Chau INTERNET-DRAFT L. Brewer <draft-chau-fcip-ifcp-encap-00.txt> G. Hecht (Expires August, 2001) FCIP and iFCP Merged Frame Encapsulation Proposal 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 1. Abstract This draft is for consideration by the FCIP and iFCP design teams in the IPS working group. This proposal incorporates mechanisms that help merge the encapsulation for FCIP and iFCP and also resolve some issues such as framing, data integrity, timeouts, and future extension. 2. 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]. Chau, et al. [Page 1]
Internet-Draft FCIP and iFCP Merged Encapsulation February 2001 3. Introduction This proposed encapsulation method has been designed to merge FCIP and iFCP header structures. It accommodates the requirements of both FCIP [4] and iFCP [5] and resolve issues such as fibre channel fabric timeouts, data and header integrity, iFCP augmentation data carriage, and framing. Thos proposal also allows extension to include futire capailities. 4. Proposed Data Frame Structure Both FCIP and iFCP insert their information in the data stream by encapsulating the FC frame inside an FCIP/iFCP data frame. The following figures show the structure of the proposed data frames. Offset +---------------------------------+ | Header (12 bytes) | 0 +---------------------------------+ | Header CRC (4 Bytes) | 12 +---------------------------------+ | Extended Header (N Bytes) | 16 +---------------------------------+ | FC SOF (4 Bytes) (FCIP Only) | N+16 +---------------------------------+ | FC Frame Header (24 bytes) | N+20 +---------------------------------+ | FC Frame Payload (M Bytes) | N+44 +---------------------------------+ | FC Frame CRC (4 Bytes) | N+M+44 +---------------------------------+ | FC EOF (4 Bytes) (FCIP Only) | N+M+48 +---------------------------------+ | Frame CRC (4 Bytes) | N+M+52 +---------------------------------+ Fig. 1 FCIP Data Frame Structure The FCIP header contains information for FCIP devices to decode the data stream and an extension for future enhancements. This header is protected by a 32-bit cyclic code (CRC-32). The FC frame, starting from the SOF code through the EOF code follows the FCIP header. The FCIP device appends a 32-bit CRC at the end of the FC frame to end the FCIP data frame. This CRC trailer covers the entire FCIP data frame from the first work of the FCIP header through Chau, et al. [Page 2]
Internet-Draft FCIP and iFCP Merged Encapsulation February 2001 to the FC EOF code. 5. Proposed Header Structure |3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | |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 | +-------+-------+---------------+--------------------------------+ | P. N. | VER. | Flags | Frame length | +-------+-------+---------------+--------------------------------+ | Time Stamp (High order) | +----------------------------------------------------------------+ | Time Stamp (Low order) | +----------------------------------------------------------------+ | Header CRC | +----------------------------------------------------------------+ | Extended Header (optional) | +----------------------------------------------------------------+ Fig. 2 Proposed Header Format Protocol Number (bits 31-28+): This 4-bit field is used to identify the protocol using this encapsulation method. Value Protocol ----- -------- 0001 FCIP 0010 iFCP Values other than 0001 and 0010 are reserved. Version Number (bits 27-24) This 4-bit field shall be 0x1 to indicate the first version for both FCIP and iFCP. The version number may diverge in the future for the two protocols. Flags (bits 23-16): This field contains status flags that indicate the various Parameters for the header. Bits Flag Description ---- ---- ----------- Chau, et al. [Page 3]
Internet-Draft FCIP and iFCP Merged Encapsulation February 2001 16 Extended Header If bit is 1, an extended header is present in the extended header field 23-17 Reserved These flag bits are reserved for future use and shall be set to zero Frame Length: (bits 15-0) This 16-bit field contains the length of the entire FCIP/iFCP data frame including the header, the header CRC word, the extended header if it is present, the FC SOF word (FCIP only), the FC frame header, the entire FC frame payload, the FC CRC word, the FC EOF word (FCIP only), and the frame CRC word. This length is based on a unit of 32- bit word. All FC frames are 32-bit-word-aligned and the header shall always be defined to be word-aligned; therefore a 32-bit word length is acceptable. Time Stamp The time stamp enables FCIP/iFCP devices to enforce the FC RA_TOV timeout requirements by discarding timed out frames properly. The time stamp consists of two 32-bit words; this two-word format follows the latest version of SNTP [6]. Header CRC This 32-bit CRC protects only the fixed header. This 32-bit CRC word is always the last 32-bit word of the fixed header. The extended header, if it is present, always follows this header CRC word. 5.1 Extended Header The Extended Header allows the carriage of information other than what is necessary for the most basic data transfer. Examples of the use of the extended header are (1) the "augmentation data" for iFCP and (2) sequence number that the FCIP/iFCP device use to keep track of frame order. |3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | |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 | +---------------+---------------+--------------------------------+ | Type | Flags | Extended Header length | +---------------+---------------+--------------------------------+ | Extended Header Content | +----------------------------------------------------------------+ Chau, et al. [Page 4]
Internet-Draft FCIP and iFCP Merged Encapsulation February 2001 Fig. 3 Extended Header Format TYPE (bits 31-24): Extended header code indicates the type of information carried in the extended header. Flags (bits 23-16): This field contains status flags that indicate the various Parameters for the header. Bits Flag Description ---- ---- ----------- 16 More Extended If bit is 1, another extended header Header follows the current extended header field 23-17 Reserved These flag bits are reserved for future use and shall be set to zero Extended Header Length (bits 15-0): This length is the number of 32-bit words starting from the first extended header word (the word containing the "type" and Length" field). This length only includes the extended header and nothing else. 6. Issues resolved by this proposal 6.1. Merge FCIP and iFCP frame and header structures This proposal merges the frame and header structures of the FCIP and iFCP protocols and at the same time accommodates the current requirements of both protocols while allowing the ability to add future extensions. 6.2. Integrity of the Header and Data CRCs provide better data protection than the TCP-style checksum. Two CRCs are proposed here. The header CRC provides assurance that the information in the header is protected against corruption. This protection is essential for the operation of the FCIP devices so that both sides of an FCIP connection can communicate effectively. The additional CRC trailer covers the extended Chau, et al. [Page 5]
Internet-Draft FCIP and iFCP Merged Encapsulation February 2001 header(s) and the FC SOF and EOF words. 6.3. FCIP Framing and Synchronization This proposal incorporates two CRC words: one for the header, and one for the data frame which includes the header, extended header(s) and the payload. This method not only provides assurance of data integrity, but also allows an efficient method to re- synchronize to the data stream when frame synchronization is lost due to errors or other events. In the event of loss of synchronization, a hardware state machine (assumed to be present) which normally checks the FCIP/iFCP header CRC can be continuously enabled on the data stream which should provide for a "good CRC" compare when an FCIP/iFCP header arrives. There is a remote possibility that a false compare could occur from other data in the stream so it is necessary to continue to check the "tentative" FCIP/iFCP payload and CRC also before assuming a correct synchronization. If both CRC checks are good, this certification should be at least as good as the data integrity provided by the CRCs in a synchronized stream. The CRC in the FCIP/iFCP header is important to this method as it allows a fast and hardware efficient check for a "tentative" header. The CRCs take less space than delimiter schemes, allow synchronization using existing hardware state machines, and provide for addition integrity. 6.4. FC Timeouts The time stamp fields enable the FCIP/iFCP devices to compare the time an FC frame has "lived" inside the IP network against the RA_TOV value of the FC fabric. The FCIP/iFCP device must silently discard any FC frame that has not exited the IP network for longer than the RA_TOV value. 6.5. Future Extension The extended header mechanism enables FCIP devices to carry other information. The general format of the extended header is defined but no specific type of extended header has been defined. 7. References: Chau, et al. [Page 6]
Internet-Draft FCIP and iFCP Merged Encapsulation February 2001 [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] http://www.t11.org [4] Rajagopal, M., et al., "Fibre Channel over TCP/IP (FCIP)", draft-ietf-ips-fcovertcpip-01.txt November, 2000 [5] Monia, C., et al., "iFCP - A Protocol for Internet Fibre Channel Storage Networking", draft-ietf-ips-ifcp-00.txt February, 2001 [6] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6, and OSI", RFC 2030, October 1996 8. Authors' Addresses Vi Chau Gadzoox Networks, Inc. 16241 Laguna Canyon Road, Suite 100 Irvine, CA 92618 Phone: +1 949 789 4639 Fax: +1 949 453 1271 Email: vchau@gadzoox.com Lani Brewer Gadzoox Networks, Inc. 16241 Laguna Canyon Road, Suite 100 Irvine, CA 92618 Phone: +1 949 789 4636 Fax: +1 949 453 1271 Email: lani@gadzoox.com Gabriel Hecht Gadzoox Networks, Inc. 16241 Laguna Canyon Road, Suite 100 Irvine, CA 92618 Phone: +1 949 789 4642 Fax: +1 949 453 1271 Email: ghecht@gadzoox.com Chau, et al. [Page 7]
Internet-Draft FCIP and iFCP Merged Encapsulation February 2001 Full Copyright Statement Copyright (C) The Internet Society (1999). 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 DISCLAIM 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. [draft-chau-fcip-encap-00.txt] [This INTERNET DRAFT expires on August, 2001] Chau, et al. [Page 8]