RE: FCIP: Intent of standard in 6.6.2.2

[Robert Snively <rsnively@Brocade.COM>]

Barry,

The text is, I believe, clear in specifying the authors' intent.

The text says:

  Verification SHALL be accomplished by performing the following tests:

  a) Length field validation -- 63 < (Length * 4) < 2177 (f above);
  b) Comparison of Length field to its ones complement (f above); and
  c) At least 6 other of the 22 distinct tests listed above.

  Errors in FCIP Frame headers SHOULD be considered carefully, since
  some may be synchronization errors. For example, any failure of the
  Length field tests described above SHALL be handled as a
  synchronization error. Errors in FCIP Frames detected by the FCIP_DE
  that affect synchronization with the Encapsulated Frame Receiver
  Portal byte stream SHALL be handled as defined by section 6.6.2.3.

It is clear from this that, if the length field goes bad, you
absolutely cannot determine where the next frame is and synchronization
is lost.  6.6.2.3 tells you the requirements for recovering
synchronization or closing the TCP connection.  Annex A gives
you one example of a recovery algorithm meeting those requirements.
Others are possible.

The other fields that are tested give you confidence that everything
is still working right and reduce the probability of falsely 
indicating that a bad frame is good to infinitesimal values.  
Numbers for passing a bad frame for good once every million years 
on a worst case link are considered infinitesimal.  The selection
of which of these tests to use depends on the implementation and
architecture of the supporting firmware and hardware.  Some tests
may be impossible on some types of hardware.  While some
of these tests may mean that the frame needs to be discarded,
you SHOULD consider in a vendor specific manner (that does not
change interoperability) whether or not synchronization actually
failed. As an example, if the length is valid but the EOF and
CRC of the frame fail, and the header of the next frame fails some
of its tests, it is likely that you have lost synchronization.
However, if the length is valid, the EOF and CRC are valid, but
the SOF is invalid, you need to discard the frame because you
cannot define its class of service, but you have probably not 
lost synchronization.

It really doesn't matter too much which set of tests you use,
since they have the same effect.  Bad frames will disappear
from the link and be retried by ULP mechanisms.  Loss of
synchronization will be recovered after several frame losses or
cause the connection to close, depending on how lucky you are
and how lazy your implementation is.

Would you suggest any wording changes to reflect that
meaning?

Bob


> -----Original Message-----
> From: Barry Reinhold [mailto:bbrtrebia@mediaone.net]
> Sent: Thursday, September 06, 2001 11:23 AM
> To: ISCSI
> Subject: FCIP: Intent of standard in 6.6.2.2
> 
> 
> I would like to ensure that I am understanding the intent of 
> the standard
> correctly relative to clause 6.6.2.2 (draft 05).
> 
> Under the verification SHALL be accomplished....
> 
> item C "At least 6 other of the 21 distinct tests listed above."
> 
> This means that there SHALL be six other fields tested and 
> that if any one
> of them fail then sync. in the TCP stream shall not be 
> considered acquired.
> It also means that a frame with 15 fields in error could pass the
> verification test of some device and that device would still 
> be consider
> compliant. Anyone reading this differently?