RE: FCIP: A question about framing

["Murali Rajagopal" <muralir@lightsand.com>]

Doug:

These codes were derived from an early implementation of a Fibre Channel
Chip.
There is no algorithm involved as far as I know in creating these
byte-encoded
codes.

On the alignement point,I was refering FC standards which like to align on
word
boundaries. We picked these codes from FC-BB and would like to adhere to
similar
mapping the FC Frames both in IETF and FC-BB2. Beyound that there is no
other
reason to use 4-bytes.

Hope this historical commentary clears the reasons for 4-bytes of SOF/EOF.

-Murali

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Douglas Otis
Sent: Wednesday, November 01, 2000 5:34 PM
To: Murali Rajagopal; Merhar, Milan; ips@ece.cmu.edu
Subject: RE: FCIP: A question about framing


Murali,

I fully understand a need for alignment.  TCP however will not provide any
alignment!  With respect to the FC frame bytes, an encapsulation process
could easily move both SOF and EOF into a prefix to aid in processing these
bytes.  This prefix could include a timestamp as well.  Do you know the
algorithm for creating these byte codes?  For alignment, you should review
RFC 2960.

You can see an example at:
http://search.ietf.org/internet-drafts/draft-otis-fc-sctp-ip-01.txt

Doug

> Doug/Milan:
>
> Although there are 4 bytes specified, only a single byte is really used.
> The reason for using 4 bytes instead of one was word boundary alignement
> previously discussed in FC-BB T11 WG.
>
> Hope this helps.
>
> Murali Rajagopal
>
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Merhar, Milan
> Sent: Wednesday, November 01, 2000 10:11 AM
> To: ips@ece.cmu.edu
> Subject: FCIP: A question about framing
>
>
> I was pleased to see the new draft for FC over IP
> ( draft-ietf-ips-fcovertcpip-00.txt ) but something
> in it left me a bit puzzled.
>
> The encapsulation that is described envelops the
> entire FC frame, including its SOF and EOF delimiters,
> and then transports it over TCP.  The draft correctly
> points out that in FC the SOF and EOF sequences
> are encoded at the 8b10b level starting with a "comma"
> character, which is a reserved 10-bit code, which does not
> correspond to any 8 bit value.  But, it then says
> that SOF and EOF are encoded in TCP as 4 byte sequences.
>
> This is where I get confused.  Don't you then have to
> prohibit the appearance of the SOF and EOF sequences
> (which are now just a set of four regular bytes)
> in the normal payload stream, using a processing-intensive
> technique like escape sequence insertion, etc?
>
> The only other alternative that comes to mind is to use
> the presence of a valid CRC as a gate to on accepting an EOF
> sequence.  And that, I believe, is patented technology.
>
> - milan
>