SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: FCIP: A question about framing



    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
    >
    
    


Home

Last updated: Tue Sep 04 01:06:32 2001
6315 messages in chronological order