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

From: Ralph Weber <[email-masked]>
Date: Thu, 15 Feb 2001 07:48:58 -0600

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

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 15 Feb 2001 15:29:47 -0800

Ralph,

As an alternative to byte stuffing, creating a pseudo-frame within TCP would
be an alternative.  Here is an example of using SCTP within TCP using a
fixed interval alignment of a pseudo-frame allowing frame recovery where
padding is inserted should the pseudo-frame be smaller than the predefined
interval.  This interval could be negotiated at 4096 or 8192 as example.  If
used within SCTP, the real Ethernet frame becomes the interval.  The SCTP
Data Chunk would contain the FCIP Header and FC frame.  Digest error
handling and acknowledgement would be done at the pseudo-frame using the
SCTP SACK chunk.  Encapsulating FCIP within SCTP within TCP has advantages
with the addition of all the interesting features of SCTP such as
multi-homing, session recovery, anti-spoofing, defined negotiations, and
years of effort creating a well defined transport.  By using Adler-32 over
the entire frame, much of the repeated values can be removed from your
specifications as well.

Constructing the pseudo-frame should represent little additional overhead
than that required to process byte stuffing.  You could require all FC
frames to be contained within a single pseudo-frame, but if SCTP is actually
used, constructing the FC frame should be an additional step.   Once SCTP is
used directly, the additional secondary overhead to process digest errors is
removed and FC related data becomes aligned with the Ethernet frame.
Something you should consider in any transport, is the handshake to allow
error recovery.  SCTP covers those questions as well as adds many
interesting advantages.  FCIP is but one of the many possible encapsulation
possible with SCTP.  SCTP can be placed on TCP (less flow control), UDP, and
of course as SCTP itself.  The general purpose structure of SCTP allows
interesting opportunities for encapsulation including the encapsulation of
the entire network connection between machines as example.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+---------------+---------------+---------------+
  0|    Rev        |   Reserved    |    Pseudo-Frame Word Length   |
   +---------------+---------------+---------------+---------------+
  4|                         Validation Tag                        |
   +---------------+---------------+---------------+---------------+
  8|                       Checksum (Adler32)                      |
   +---------------+---------------+---------------+---------------+

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 12|   Type = 0    | Reserved|U|B|E|       Chunk Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 16|                              TSN                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 20|      Stream Identifier S      |   Stream Sequence Number n    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 24|             Payload Protocol Identifier (IANA FCIP Op)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 28|  VER. |HDR Len|                    Reserved                   |
   +-------+-------+---------------------------+-------------------+
 32|                         Time Integer                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 36|                         Time Fraction                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 40\                                                               \
   /                 FC encapsulation (seq n of Stream S)          /
   \                                                               \

Doug

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Ralph Weber
> Sent: Thursday, February 15, 2001 5:49 AM
> To: IPS Reflector
> Subject: FCIP: draft-weber-fcip-encaps-00.txt
>
>

---

From: "Sriram Rupanagunta" <[email-masked]>
Date: Fri, 16 Feb 2001 15:17:14 -0600

Few comments on the new proposal for FCIP changes:

- Section 3.2: It is not entirely clear how the FCIP devices would
synchronize
clocks across the IP network. There is mention of using NTP or SNTP - would
that mean they operate independent of Fibre channel time services, operating
as a IP service ? I would imagine this to be the case, but not sure if this
is mentioned clearly enough.

- Section 3.2: The mention of time stamps for time out error recovery
needs to be more specific, IMO. It says that "if too much time elapses,
the FC frame should be dropped", which is not precise. I believe it should
specify how it relates to the two FC timeouts.

- Section 5.1: The reason for additional checksum is not clear enough.
If this is solely for the purpose of re-synchronization, would it
justify the additional overhead for every FCIP frame ?

- Both the original ID and this proposal leave out the part about
aborted TCP connections, but talk about re-synchronization during data
transfer phase, in the face of packet loss, congestion etc.
I would imagine the re-sync to be more critical "after" a connection
is reset, since there is data in transit and in the receiver queue.
Do the authors believe that the new proposal would be sufficient
to address the TCP connection resets ?

Regards,
Sriram

---

From: Ralph Weber <[email-masked]>
Date: Sat, 17 Feb 2001 06:28:25 -0600

Douglas,

Even though there are worked examples of your proposal,
it involves more knowledge of TCP/IP than I am willing
to undertake.

Thanks.

Ralph...

---

From: "Srini V.Raman" <[email-masked]>
Date: Thu, 22 Feb 2001 21:12:32 -0800

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

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 23 Feb 2001 08:03:56 -0800

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