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

["Srini V.Raman" <srini@stargateip.com>]

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