RE: Common Encapsulation: CRC at beginning of frame?

["Franco Travostino" <travos@nortelnetworks.com>]

Gee, how many qualitative, subjective, and implementation-specific
statements in this thread!
Fore one, Bob's notion of "simplifying", "very
efficient", and (implicitly) superior resiliency still fail to
convince me, until I read the outcome of the action item that Bob took
from the Nashua meeting, and which I hope will be addressed in formal
terms:

> Section 8.1 - Bob Snbively wants to
> add ability to do data-based resync
> -> Action: Bob will write the text to explain how to do this for
> serious 
> review. Will also rewrite the text to distinguish use of another 
> framing mechanism vs. the data scan. Resync should be optional, and 
> data scan must not be capable of misinterpreting what appears to 
> be a Fibre Channel frame in an FCIP data payload as an actual 
> frame.

-franco


At 07:20 PM 6/14/2001, Robert Snively wrote:
> Your "easier" and
> "more resilient" statements are implementation
> dependent.  Our work indicates that both of those are 
> incorrect
> statements for at least one very efficient implementation.
>
> Bob
>
> >  -----Original Message-----
> >  From: Douglas Otis
> [mailto:dotis@sanlight.net]
> >  Sent: Thursday, June 14, 2001 4:12 PM
> >  To: Robert Snively; Harmon, Robert; Ips (E-mail)
> >  Subject: RE: Common Encapsulation: CRC at beginning of
> frame?
> >  
> >  
> >  Robert,
> >  
> >  In understanding the difference between these two 
> >  approaches, iFCP could use
> >  the header CRC as framing confirmation together with the 
> >  timestamp in a more
> >  resilient manner than FCIP.  iFCP also includes the 
> >  Fibre-Channel frame
> >  designators within the header for easier processing.
> >  
> >  Doug
> >  
> >  > I assume you are speaking of the FCIP/iFCP common 
> >  encapsulation.  The
> >  > data CRC is actually at the end of the encapsulation
> frame.
> >  > The header CRC (proposed for use by iFCP only) is at the
> end of the
> >  > header.  The FCIP usage of the header exploits the
> combination of
> >  > TCP/IP protection, data frame verification, and data
> redundancy
> >  > to achieve error detection at a comparable level and does
> not use
> >  > the header CRC, simplifying the hardware and/or
> software
> >  > implementations significantly.
> >  >
> >  > Hope that is some help.
> >  >
> >  > Bob
> >  >
> >  > -----Original Message-----
> >  > From: Harmon, Robert
> [mailto:rharmon@entradanet.com]
> >  > Sent: Wednesday, June 13, 2001 2:20 PM
> >  > To: Ips (E-mail)
> >  > Subject: Common Encapsulation: CRC at beginning of
> frame?
> >  >
> >  >
> >  >
> >  >
> >  > Has there been any discussion of putting the
> >  > common encapsulation CRC at the end of the frame
> >  > rather than -near- the beginning?
> >  > Its possible to do CRC in H/W but to put it at the
> >  > beginning of the frame is 5 times harder than
> putting
> >  > it at the end.
> >  >
> >  
> >