|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: FCIP: A question about framingMilan, 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 |