RE: FCIP: draft-weber-fcip-encaps-00.txt

["Douglas Otis" <dotis@sanlight.net>]

Srini,

If SCTP structures within TCP is employed, then you benefit from an Adler-32
frame check and have a mechanism for retrying the failed frame.  The FCIP
Enhancement does not describe any technique for recovering a bad frame found
by a digest error. SCTP already has the mechanism in place for this type of
recovery even if placed on top of TCP.  The other benefit is byte stuffing
is not needed.  To encapsulate within TCP, simply create a pseudo-frame and
allow the SCTP structures to conform to this pseudo-frame placed at fixed
intervals rather than at the real Ethernet frame.  If SCTP is used directly,
the real Ethernet frame can be used.

Doug


> Ralph,
>
> Some comments on the recent "FCIP Frame Encapsulation Enhancement
> Proposals"
>
> Section 3.2:
>
> Timeout suggestion is a good is well taken. Timeout extensions that
> have been suggested in the proposal to deal with keeping TCP retransmit
> timeouts within the E_D_TOV and R_A_TOV requirements is a good one.
>
> Section 2:
>
> Currently we have four different mechanisms to protect the data
> integrity .
> They are ...
>
> 1. Data Link layer (either Ether Framer or the HDLC framer) has CRC/FCS
> protection, Which is reasonably strong protection against data corruption.
> 2. TCP checksum provides an end to end data integrity check against the
> corruptions in both TCP payload (FCIP header and FC payload) and
> TCP header.
> 3. FCIP header (as proposed in the Enhancement draft) has both length and
> inverse length information to detect corruption in the FCIP length.
> 4. An additional paranoid check can be done against SOF and EOF fields to
> verify the data integrity in case of length field being a suspect.
>
> The recent document suggests inserting delimiters and data stuffing to
> provide additional check for the FCIP boundaries/length. In the instances
> where  delimiter gets corrupted, the only protection we have is FCIP
> checksum, which is no different from TCP checksum.
>
> The point of having additional delimiters doesn't make any additional
> guarantee against the data corruption other than complicating the FCIP
> implementations, whether it be a software or an hardware implementation.
>
> Section 5:
> An additional checksum (as proposed) in the FCIP layer is a redundant
> checksum. If need be, a checksum can be made only for the FCIP header (4
> bytes of length, 8 bytes of timestamp).
>
> -- Srini
>
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Ralph Weber
> > Sent: Thursday, February 15, 2001 5:49 AM
> > To: IPS Reflector
> > Subject: FCIP: draft-weber-fcip-encaps-00.txt
> >
> >
> > An internet draft titled " FCIP Frame Encapsulation Enhancement
> > Proposals" is available at:
> >
> > http://www.ietf.org/internet-drafts/draft-weber-fcip-encaps-00.txt
> >
> > The abstract is as follows:
> >
> >    This draft is for consideration by the FCIP team in the IPS working
> >    group.  Improvements to Fibre Channel Over TCP/IP (FCIP) [2] frame
> >    encapsulation mechanisms are proposed.  The objectives of the
> >    improvements are two fold: increasing the reliability of Fibre
> >    Channel frame detection, and assisting with the handling of Fibre
> >    Channel E_D_TOV and R_A_TOV time-out processing.
> >
> > Since the ID was submitted a technical error was discovered in
> > section 3.2, Time Stamp, it says that the integer word in the
> > time stamp is "the time in seconds relative to the epoch,
> > 00:00:00 January 1,1990."  This is a transcription from the
> > T11 proposal on which the usage of this time format is based
> > (01-052v0).
> >
> > However, 01-052v0 is based on SNTP (RFC 2030) and RFC 2030 says
> > that the base epoch is "00:00:00 January 1,1900", that is 1900
> > not 1990.
> >
> > I have been informed that 01-052v0 did not intend to revise
> > RFC 2030 and that the encapsulation proposal should use 1900
> > not 1990.
> >
> > FYI
> >
> > Ralph Weber
> > representing
> > Brocade Communications
> >
> >
> >
>
>