FCoverIP (FC/SCTP/IP)

["Douglas Otis" <dotis@sanlight.net>]

Here is an updated version so less is missing...
IPS Working Group                                    Douglas Otis
Networks INTERNET-DRAFT        			     SANlight
(Expires February 21, 2001)

		  FC over SCTP/IP (FC/SCTP/IP)
	       <draft-ietf-ips-fc-sctp-ip-00.txt>

     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.

     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:

     The Payload Protocol Identifier is TBD.

     All Payload Data types will be sent Unordered.

     Stream 0 is reserved as a control stream with TBD messages.
     TBD...

     Each FC port is designated a stream starting from 1.

     Each FC Frame is contained within a Payload Data chunk.

     Authentication Management is facilitated with LDAP/FC.

     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.

          +------+--------+-----------+----//-------+------+------+
          | 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- encodings 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
     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 Encodings

     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.


     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      |
     +-----------------+----------------+
     |      0x31       |     SOFn4      |
     +-----------------+----------------+
     |      0x38       |     SOFcf      |
     +-----------------+----------------+
     |      0x30       |     SOFnf      |
     +-----------------+----------------+
     |      0x41       |     EOFn       |
     +-----------------+----------------+
     |      0x42       |     EOFt       |
     +-----------------+----------------+
     |      0x46       |     EOFdt      |
     +-----------------+----------------+
     |      0x44       |     EOFrt      |
     +-----------------+----------------+
     |      0x49       |     EOFni      |
     +-----------------+----------------+
     |      0x4E       |     EOFdti     |
     +-----------------+----------------+
     |      0x4F       |     EOFrti     |
     +-----------------+----------------+
     |      0x50       |     EOFa       |
     +-----------------+----------------+
 
 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.

[END]