Subject: FCIP iFCP encapsulation proposal

From: Vi Chau <[email-masked]>
Date: Tue, 6 Mar 2001 17:08:43 -0800

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

---

From: Stephen Bailey <[email-masked]>
Date: Fri, 09 Mar 2001 10:42:09 -0500

> integrity provided by the CRCs in a synchronized stream.

Nonsense.

The original FCIP proposal that the receiver scan for an EOF/HDR/SOF
sandwich to recover synchronization has the same problem.  This
technique is fundamentally bogus.

Any time you're scanning user-controllable data (as in from the
completely uncontrolled, end application), you MUST assume absolute
worst case (to fool the sync algorithm) data.  In the worst case, the
probability of faking out your resynchronization heuristic is much
(!!!) greater than the probability of an integrity CRC giving you a
false positive acceptance check.

In other words, the user can pack the data stream with `cooked' data
patterns that are just waiting for a dropped frame and an attempt to
resynchronize.  If you assume that the shortest pattern required to
fool the resynchronization algorithm is n words (no longer than the
minimum well-formed PDU size), and TCP segmentation is effectively
random (*), the chance of your resynch algorithm getting spoofed
(resulting in the user getting some control of trusted `machinery') is
simply 1 in n.

You can fix this problem by using a shared `secret' (from the client)
between the two endpoints.  For example, if you put a 64-bit random
number that both endpoints know in the end/begin sandwich, THEN you
can talk about vanishingly small probabilities of the sandwich
discovery going wrong.

Personally, I think this running sync rediscovery is all makework
because it's still a far distant second (or third, if you like
periodic markers) to ensuring that each segment is sufficiently
self-describing (AKA framing).  A framing solves several other
problems, such as the digest failure problem currently being discussed
by Julian & Somesh.

Steph

* It isn't but, AGAIN, you must make WORST CASE assumptions, because,
with properly periodic or aperiodic patterns, the user can actually
encourage the segmentation algorithm to work in her favor.

---

From: [email-masked]
Date: Fri, 09 Mar 2001 11:53:59 -0800

Steph

I will not argue with your opinion of the value of running synch 
rediscovery, but I disagree with the observance that the chance of 
spoofing the resynch mechanism is a linear "one in n". Although not 
directly mentioned in the document, it is implied that the 
qualification for a CRC acceptance on the payload portion be 
restrained to assume only a payload length which exactly matches the 
length as defined in the length field of the tentative header. Certain 
reality checks on the other header fields would not be out of order 
either.

Lani

---

From: "Renato E. Maranon" <[email-masked]>
Date: Fri, 9 Mar 2001 11:26:52 -0800

I don't see a length field for the Sense Data or Response Data.  Would Sense
or Response Data be another segment (AHS)as part of the same PDU?  If it is
an AHS, would that be defined as a data segment (WN byte 0, Bit 7 = 0, WN
byte 1-3 = length of sense/response data)?

This question applies to Text Command and Text Response also.

Thanks,
Renato Maranon
Maranti Networks, Inc
920 Hillview Court
Milpitas, Ca 95035
Phone:  408-719-9600 x309
Fax:    408-719-9631
email:  [email-masked]
home:   www.marantinetworks.com