Re: FCIP: Comment 109

[Ralph Weber <ralphoweber@compuserve.com>]

Mallikarjun,

> ... - could you please comment on whether or not CRC protection 
> is available on FCIP headers and help me with a reference if so?

CRC protection is prohibited for FCIP headers as per following
two statements in 6.6.1:

  "The CRCV (CRC Valid) Flag SHALL be set to 0."
  "The CRC field SHALL be set to 0."

It is further worth noting that the error detection algorithms
described in 6.6.2.2 include no provisions for the use of CRCs
but do describe a through FCIP header validation mechanism
based on redundancy.

The recommendation that CRC be used for FCIP headers has been
considered and rejected in the past. The preference for
redundancy validation of FCIP headers is partially described 
in the FC Encapsulation draft section 3.2.1.

   "Header validation based on redundancy is a stepwise process 
   in that the first word is validated, then the second, then 
   the third and so on. A decision that a candidate header is 
   not valid may be reached before the complete header is 
   available."

It should be noted that the Fibre Channel requirements for usage
of its CRC are such that the usage of CRC by FCIP would constitute
the only requirement for CRC hardware in an FCIP device.

Interoperability concerns dictate that FCIP must either mandate
or prohibit use of CRC, so CRC usage is prohibited.

Thanks.

.Ralph

"Mallikarjun C." wrote:

>
> Ralph,
>
> > http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-01.pdf
> ....
> > Please review these comments resolutions to ensure that
> > the desired changes are described.
>
> Sorry for the delayed review, I have additional comments on wglc-01
> for Comment 109.
>
> Regards.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm@rose.hp.com
>
> >>Comment 109 Technical
> >> 6.6.1 FCIP Encapsulation of FC Frames
> >....
> >> The CRCV (CRC Valid) Flag SHALL be set to 0.
> >>
> >> The CRC field SHALL be set to 0.
> >I am surprised that the FCIP encapsulated header is never protected
> >by a CRC. The error detection section clearly acknowledges the
> >possibility that TCP checksum could be inadequate for certain
> >deployments - and even suggests checking the FC frame CRC (sort
> >of like a data digest) on reception at the Encapsulated Frame
> >Receiver Portal.
> >My recommendation is to require an FCIP Entity to employ the header
> >CRC if the SF that it receives asks for CRC - IOW, similar to iSCSI's
> >approach. So, I guess I am also advocating a new bit in the pFlags
> >field to announce this. When this CRC expectation is announced, the
> >FC CRC checking test in 6.6.2.2 should also be a mandatory test -from
> >the "semi-optional" list it is currently in.
> >Accepted with the following result
> >Add the following to the new section created in response to comment
> >44: "Note: Owing to the limited manner in which the FSF is used and
> >the requirement that the FSF be echoed without changes before a TCP
> >connection is allowed to carry user data, no error checking beyond
> >that provided by TCP is deemed necessary."
>
> Sorry, I missed the earlier discussion on this comment.
>
> My comment was for __all__ FCIP encapsulated headers on all FCIP
> Frames - not just for FSF.  The reference to FSF in my comment was
> to suggest how an "I want CRC" demand be communicated at the FCIP
> Link establishment time - i.e. the reference was a solution strawman.
>
> I probably missed something critical - could you please comment on
> whether or not CRC protection is available on FCIP headers and
> help me with a reference if so?