RE: FCIP: iFCP/FCIP Framing assists (was TCP/IP Framing Assists)

[Charles Monia <cmonia@NishanSystems.com>]

Hi David:

> The result could be three TCP framing approaches
> 	- SCTP-lite
> 	- Markers (iSCSI appendix)
> 	- Reserved value/word stuffing (weber draft)

The above layered approaches assume the framing mechanism and data
representations are totally othogonal. Using that criteria leads to a fourth
negotiable alternative:  ie. no TCP framing assist.

In that case, assuming: 

a) The header and FC frame each have their own error digests and
b) The header contains the information needed to extract the FC frame,

the approach is to validate the header and, if error-free, forward the
resulting de-encapsulated frame (with FC-generated CRC) to the FC fabric for
processing.  In this approach, of course, there's no fall-back in the event
of a header error.  So, in the case of iFCP, the response would be to
terminate the session.

Assuming the cross-section for such errors is small compared to that of the
typical FC payload, a seat-of-the-pants guess is that such occurrences
should be rare.

Of course, FCIP would probably negotiate some other TCP framing alternative.

Charles
> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Saturday, March 10, 2001 1:21 PM
> To: cmonia@nishansystems.com; Black_David@emc.com
> Cc: ips@ece.cmu.edu
> Subject: RE: TCP/IP Framing Assists
> 
> 
> Copying the list on a response to a question of general interest ...
> 
> Charles Monia writes:
> > At the last IPS WG, you said you felt there was a 
> possibility that the
> IETF
> > community might be persuaded to accept some sort of framing 
> assists for
> > TCP/IP (At the time, I characterized this as 'SCTP lite').
> > 
> > Has there been any progress on this front? This could 
> impact the outcome
> of
> > the common encapsulation effort.
> 
> It is still a definite possibility.  There has been progress, 
> but it's not
> exactly
> visible, yet.  As indicated in the IPS Agenda for 
> Minneapolis, work on this
> will be conducted through the tsvwg Working Group - I have not seen a
> Minneapolis Agenda for tsvwg, so I don't know if/when this 
> issue will be
> taken up.  I'll try to get an update (no discussion) on this 
> topic included
> in the initial 10 minutes of Agenda Bashing and Administrivia.
> 
> For the FCIP/iFCP common encapsulation, I would recommend separating
> framing from data representation, and adopting an approach 
> along the lines
> of
> that in Section 1.2.8 of the iSCSI draft in which framing 
> logically occurs
> between the block storage protocol and TCP.  In particular, this means
> that the 0xfcfcfcfc reserved value/word-stuffing approach in 
> Section 2 of
> the weber draft should be specified separately as a "shim" protocol 
> at this level if it is to be carried forward - this is the 
> right way to
> think
> about it in any case because any protocol headers at higher layers in
> the stack have to be word-stuffed if the reserved value sequence (4
> occurrences of the reserved value in the weber draft) occurs there.
> 
> The result could be three TCP framing approaches
> 	- SCTP-lite
> 	- Markers (iSCSI appendix)
> 	- Reserved value/word stuffing (weber draft)
> Each could be independently chosen/used by any of the IPS 
> block storage
> protocols, provided that suitable negotiation mechanisms are 
> specified to
> make sure that both sides of a connection understand exactly 
> what is being
> used in which direction.
> 
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>