FCIP iFCP encapsulation proposal

[Vi Chau <vchau@gadzoox.com>]

Dear Colleagues,

   I sent out a draft to propose a common encapsulation scheme for
FCIP and iFCP last week; I am afraid I have missed the cut-off time
for new drafts. Here is a summary of the draft to help stimulate
discussion at the upcoming IETF meeting:

   The proposed encapsulation scheme allows easy integration of FCIP
and iFCP headers; it provides header integrity which was lacking in
the current FCIP draft. This scheme also provides integrity to the
extended headr and FC SOF and EOF codes in the payload (as the FC
CRC does not cover SOF and EOF.) A time stamp helps solve FC timeout
issues. Fianlly, the header CRC can be used to help with framing.

   The draft proposes that FCIP/iFCP encapsulation include a header,
header CRC, extended header(s) for new functions, the payload (which
is an entire FC frame), and a 32-bit CRC that covers the entire
FCIP/iFCP frame. The FCIP/iFCP frame is shown in the diagram below.


                +---------------------------------+
                |        Header (12 bytes)        |
                +---------------------------------+
                |       Header CRC (4 Bytes)      |
                +---------------------------------+
                |    Extended Header (N Bytes)    |
                +---------------------------------+
                |  FC SOF (4 Bytes) (FCIP Only)   |
                +---------------------------------+
                |   FC Frame Header (24 bytes)    |
                +---------------------------------+
                |   FC Frame Payload (M Bytes)    |
                +---------------------------------+
                |     FC Frame CRC (4 Bytes)      |
                +---------------------------------+
                |  FC EOF (4 Bytes) (FCIP Only)   |
                +---------------------------------+
                |      Frame CRC (4 Bytes)        |
                +---------------------------------+

The header has the following format:

 |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)                  |
 +----------------------------------------------------------------+


Protocol Number field differentiates FCIP from iFCP. Each encapsulated
protocol may have its own version number. There is currently only one
flag defined: if the flag is set to 1,  an extended header is present.
The Frame Length field contains the number of 32-bit words in the frame
including the header, payload, and trailer. The time stamp follows the
format defined by SNTP-2 (RFC 2030). The first 3 words of this frame
structure is covered by a 32-bit CRC placed immediately after the time
stamp.

The extended header has the following format:

 |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                      |
 +----------------------------------------------------------------+

The Type field indicates the kind of information carried in this
etended header. There is currently only one flag defined; if the flag
is set to one, another extended header follows this one. The extended
header length field carries the number of 32-bit words in this extended
header, including the first word.

The header CRC not only provides assurance of header 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 state machine 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.


Regards,

Vi Chau