RE: FCIP: A question about framing

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

Milan,

It would also be nice to understand how these byte codes were derived.  In
the draft I created, I suggested a simple algorithm.  I suspect something
similar was done, so it would be nice to understand how these codes were
created.  In addition to 4 bytes for 1 wasting space, it would also be nice
to combine both SOF and EOF into a single prefix.  For a state machine
dealing with SOF/EOF codes, having the EOF parameter in a known position
would be helpful.  The CRC does not include these frame markers so this
information can be treated separately.  A timestamp would also be helpful in
determining the freshness of an FC frame.  These times do not need to be
synchronized as each end-point could judge from the standpoint of the
earliest possible packet from the remote point.  I suspect these codes are
created using a translation chip off of the phy that do not see more than a
few bytes at a time.  The final encapsulation can combine SOF/EOF flags into
a prefix together with a timestamp and use less space than now proposed.  To
take advantage of the ability of RFC 2960 to combine multiple streams, I
also included B-B tokens and NOS, LRR, LR, and OLS primitive flags.  It
would seem to be an advantage to know if there is anything connected and if
it is awake.

 http://search.ietf.org/internet-drafts/draft-otis-fc-sctp-ip-01.txt

Doug


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