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

[Douglas Otis <dotis@sanlight.net>]

Charles,

Should you use SCTP within TCP by replacing the SCTP port with a
pseudo-frame length, then conventions for SCTP allows for frame recovery
independent of the encapsulated FC frame.  SCTP even allows for setting
retries for this frame as well as providing an authorities SACK independent
of TCP.  With this scheme, you could take advantage of many benefits offered
by SCTP as well as eventually using SCTP directly.  The pseudo-frame would
then dictate memory overhead for frame reconstruction which will be required
as FC and Ethernet often have incompatible lengths.  The iFCP encapsulation
would sit within an SCTP data chunk.  Simply define a fixed length
pseudo-frame as part of a modified SCTP negotiation.

Doug

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