Internet DRAFT - draft-chau-fcip-ifcp-encap
draft-chau-fcip-ifcp-encap
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]
