Douglas Otis
INTERNET-DRAFT SANlight
(Expires February 21, 2001)
FC over SCTP/IP (FC/SCTP/IP)
<draft-otis-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.
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.