Douglas Otis INTERNET-DRAFT SANlight (Expires February 21, 2001) FC over SCTP/IP (FC/SCTP/IP) 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 Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This specification incorporates an encapsulation scheme for Fibre- Channel (FC) using SCTP. The essential advantages for using SCTP compared to TCP as it relates to FC are as follows: - Headers contained within one frame. - Objects aligned at 32-bit boundaries. - Out of sequence frame processing. - Standard authentication. - Independent streams under common control. - Session restart. - Improved error detection. - Prevention of blind spoofing and denial of service attacks. - Standard Heartbeat and multi-homing. (optional) The principle focus of this document is to provide an implementation of SCTP as an encapsulation with network related management required for FC traffic. As FC traffic is predominately related to storage, functions in this area effect storage as well as a possible means of direct IP access. Stream filtering to block non-storage related Internet Draft, 22-Aug-00 FC/SCTP/IP [Page 2] traffic is an example of a storage specific function covered. Normative References: RFC 826, Ethernet Address Resolution Protocol(ARP) RFC 792, Internet Control Message Protocol (ICMP) RFC 2132, DHCP Options and BOOTP Vendor Extensions (DHCP-BOOTP) RFC 2589, Lightweight Directory Access Protocol (LDAPv3) RFC 1157, Simple Network Management Protocol (SNMP) RFC 1907, Management Information Base for SNMP (SNMPv2-MIB) RFC "wip", Stream Control Transmission Protocol (SCTP) RFC "wip", LDAP structures for FC/SCTP/IP (LDAP/FC) Definitions Fibre-Channel (FC) Frames are encapsulated as Data Payload chunks within the SCTP protocol. See FC Frame Format for a definition of the FC delimiter encoding. The Payload Protocol Identifier is TBD. All Payload Data types will be sent Unordered. Stream Management Stream 0 is reserved as a control stream that exchanges configuration structures to assign FC port and attributes to streams. These structures are as follows: TBD Authentication Management Authentication management is facilitated with LDAP/FC. Agents implementing FC/SCTP/IP are intended to use LDAP to obtain the required information for establishing communications. These structures extend into stream management attributes in some cases. Advisory Devices implementing FC/SCTP/IP will also implement ARP, ICMP and optionally DHCP-BOOTP, and SNMP. FC Frame Format: The exact size of each frame varies depending on the size of the variable fields. The size of the variable field ranges from 0 to 2112-bytes as shown in the FC Frame Format in Fig. 1 resulting in the minimum size FC Frame of 36 bytes and the maximum size FC frame of 2148 bytes. Internet Draft, 22-Aug-00 FC/SCTP/IP [Page 3] +------+--------+-----------+----//-------+------+------+ | SOF |Frame |Optional | Frame | CRC | EOF | | (4B) |Header |Header | Payload | (4B) | (4B) | | |(24B) |<----------------------->| | | | | | Data Field = (0-2112B) | | | +------+--------+-----------+----//-------+------+------+ Fig. 1 FC Frame Format SOF and EOF Delimiters: On a FC link, SOF and EOF are called Ordered Sets and are sent as special out-of-band words constructed from the 10-bit comma character (K28.5) followed by 3 additional 10-bit data characters. On a non-Fibre Channel link the Start of Frame (SOF) and End of Frame (EOF) delimiters are both byte-encoded and 4-bytes long. On a FC link the SOF delimiter serves to identify the beginning of a frame and prepares the receiver for frame reception. The SOF contains information about the frame's Class of Service, position within a sequence, and in some cases, connection status. The EOF delimiter identifies the end of the frame and the final frame of a sequence. In addition, it serves to force the running disparity to negative. The EOF is used to end the connection in connection-oriented classes of service. It is therefore important to preserve the information conveyed by the delimiters across the IP-based network, so that the receiving FCIP device can correctly construct the FC frame in its original SOF and EOF format before forwarding it to its ultimate FC destination on the FC link. Start of Frame (SOF) and End of Frame (EOF) byte- encoding are defined in Annex A. Although, the SOF and EOF codes are 32-bits, the format makes use of a single-byte to represent each FC Ordered Set. Frame Header: The Frame Header is 24-bytes long and has several fields that are associated with the identification and control of the payload. Current FC Standards allow up to 3 Optional Header fields [4]: - Network_Header (16-bytes) - Association_Header (32-bytes) - Device_Header (up to 64-bytes). Frame Payload: The FC Frame Payload is transparent to the FCIP device. An FC application level payload is called an Information Unit at the FC-4 Level. This is mapped into the Frame Payload of the FC Frame. A Internet Draft, 22-Aug-00 FC/SCTP/IP [Page 4] large Information Unit is segmented using a structure consisting of FC Sequences. Typically, a Sequence consists of more than one FC frame. FCIP does not maintain any state information regarding the relationship of frames within a FC Sequence. CRC: The CRC is 4-bytes long and uses the same 32-bit polynomial used in FDDI and is specified in ANSI X3.139 Fiber Distributed Data Interface. When FC frames are encapsulated into IP packets, the CRC is untouched. APPENDIX A: Fibre Channel EOF and SOF Encoding A.1 Ordered Sets On a FC link, Ordered Sets (OS) are sent as special out-of-band words constructed of the 10-bit comma character (K28.5) followed by 3 additional 10-bit data characters. The Ordered Sets defined by FC include the Frame Delimiter, Start of Frame (SOF) and End of Frame (EOF), and other Primitive Signals. When FC frames are encapsulated in an IP packet, the Byte-encoded frame format is used. The Byte-encoded frame format uses 32-bit OS Code Words to represent valid FC frame delimiter. This format uses a single-byte OS Code to represent each FC Ordered Set. FC Over IP makes use of the OS Codes defined in Annex A of [7] for the frame delimiters. SOF and EOF codes defined in the figures (see below) in this Annex are inserted into the FC frame. Primitive Signals and Primitive Sequences are stripped at the FCIP boundary. The frame delimiters are identified by their position. An encapsulated Byte-encoded frame must use the corresponding 32-bit OS Code Word as the first and last words in the encapsulated PDU. FC frame delimiters shall be encoded in the format shown in Table below. Internet Draft, 22-Aug-00 FC/SCTP/IP [Page 5] Table 1. Frame Delimiter Format +---+---------------+---------------+---------------+-------------- + |Wrd| <31:24> | <23:16> | <15:08> | <07:00> | +---+---------------+---------------+---------------+-------------- + |0 | OS Code | Reserved | +---+---------------+---------------+---------------+-------------- + A.2 Encoded FC Frame Delimiters The SOF OS-codes are a single byte encoding of the SOF Ordered Set. The first word in an encapsulated Byte-encoded FC frame shall map the SOF Ordered Set to the corresponding 32-bit OS Code Word. The EOF OS-codes are a single byte encoding of the EOF Ordered Set. The last word in an encapsulated Byte-encoded FC frame shall map the EOF Ordered Set to the corresponding 32-bit OS Code Word. +-----------------+----------------+ | OS-Code | Delimiter Name | | (hex) | | +-----------------+----------------+ | 0x28 | SOFf | +-----------------+----------------+ | 0x3F | SOFc1 | +-----------------+----------------+ | 0x2F | SOFi1 | +-----------------+----------------+ | 0x37 | SOFn1 | +-----------------+----------------+ | 0x3D | SOFc2 | +-----------------+----------------+ | 0x2D | SOFi2 | +-----------------+----------------+ | 0x35 | SOFn2 | +-----------------+----------------+ | 0x3E | SOFc3 | +-----------------+----------------+ | 0x2E | SOFi3 | +-----------------+----------------+ | 0x36 | SOFn3 | +-----------------+----------------+ | 0x39 | SOFc4 | +-----------------+----------------+ | 0x29 | SOFi4 | +-----------------+----------------+ Internet Draft, 22-Aug-00 FC/SCTP/IP [Page 6] | 0x31 | SOFn4 | +-----------------+----------------+ | 0x38 | SOFcf | +-----------------+----------------+ | 0x30 | SOFnf | +-----------------+----------------+ | 0x41 | EOFn | +-----------------+----------------+ | 0x42 | EOFt | +-----------------+----------------+ | 0x46 | EOFdt | +-----------------+----------------+ | 0x44 | EOFrt | +-----------------+----------------+ | 0x49 | EOFni | +-----------------+----------------+ | 0x4E | EOFdti | +-----------------+----------------+ | 0x4F | EOFrti | +-----------------+----------------+ | 0x50 | EOFa | +-----------------+----------------+ Author's Address: Douglas Otis SANlight Inc. 160 Saratoga Ave, #46 Santa Clara, CA 95051 Tel: (408) 260-1400 x2001 dotis@sanlight.net Full Copyright Statement Copyright (C) The Internet Society (2000). 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.