Subject: Common Encapsulation: CRC at beginning of frame?

From: "Harmon, Robert" <[email-masked]>
Date: Wed, 13 Jun 2001 17:19:54 -0400

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.

---

From: Charles Monia <[email-masked]>
Date: Wed, 13 Jun 2001 16:22:47 -0700

Hi Robert:

The CRC you refer to only covers the encapsulation header, not the FC Frame,
which is covered by its own, separately computed FC CRC. 

According to section 2.1 on pp 6::

"CRC (word 6): When the CRCV Flag bit is zero, the CRC field SHALL contain
zero. When the CRCV Flag bit is one, the CRC field SHALL contain a CRC for
words 0 to 5 of the FC Encapsulation Header computed using the polynomial,
initial value, and bit order defined for Fibre Channel[3]."

Charles

---

From: Robert Snively <[email-masked]>
Date: Thu, 14 Jun 2001 16:20:11 -0700

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

>  From: Douglas Otis [mailto:[email-masked]]
>  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
>  >

---

From: "Franco Travostino" <[email-masked]>
Date: Fri, 15 Jun 2001 09:33:23 -0400

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