RE: [rddp] Need some clarification on how to "locate the startoftheFPDU unambiguously"

[pat_thaler at agilent.com]

I agree as well. It would be best to add an explicit statement to that effect so we don't have to add "(if CRC checking is enabled)" after every statement about verifying CRC.

Pat

-----Original Message-----
From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org]On Behalf Of
Culley, Paul
Sent: Tuesday, 30 November, 2004 6:43 AM
To: Caitlin Bestler; Barry Reinhold; iwarp-tech at iol.unh.edu; RDDP
Subject: RE: [rddp] Need some clarification on how to "locate the
startoftheFPDU unambiguously"


I agree with Caitlin; when CRCs are not used, then the field is always
"valid", so you can proceed with FPDU decoding once you have
unambiguously found the start and have the whole FPDU.

Paul R. Culley
HP Fellow
281-514-5543
 

> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On 
> Behalf Of Caitlin Bestler
> Sent: Tuesday, November 30, 2004 8:07 AM
> To: Barry Reinhold; iwarp-tech at iol.unh.edu; RDDP
> Subject: RE: [rddp] Need some clarification on how to "locate 
> the start oftheFPDU unambiguously"
> 
> Keep in mind that "CRC suppression" does not eliminate the 
> field, only generating it and checking it. 
> 
> So my reading has always been that when CRCs are "suppressed" 
> that the CRC field is always "valid".
> 
> Given the scenarios identified for suppressing CRCs, when 
> there is equivalent protection from IPSEC or something else, 
> I think it is also clear that this was the intent.
> 
> > -----Original Message-----
> > From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] 
> On Behalf 
> > Of Barry Reinhold
> > Sent: Tuesday, November 30, 2004 4:49 AM
> > To: iwarp-tech at iol.unh.edu; RDDP
> > Subject: [rddp] Need some clarification on how to "locate 
> the start of 
> > theFPDU unambiguously"
> > 
> > If markers are being used is it mandatory to also be using CRCs?
> > This question arises out of the requirements of clause 5.4:
> > 
> > Clause 5.4 of MPA states the following:
> > 
> > ============
> > 
> > An MPA receiver MUST first verify the FPDU before passing the ULPDU
> >    to DDP.  To do this, the receiver MUST:
> > 
> > 
> >    *   locate the start of the FPDU unambiguously,
> > 
> > 
> >    *   verify its CRC (if CRC checking is enabled).
> > 
> > 
> >    If the above conditions are true, the MPA receiver 
> passes the ULPDU
> >    to DDP.
> > 
> > 
> >    To detect the start of the FPDU unambiguously one of the 
> following
> >    MUST be used:
> > 
> > 
> >    1:  In an ordered TCP stream, the ULPDU Length field in 
> the current
> >        FPDU when FPDU has a valid CRC, can be used to identify the
> >        beginning of the next FPDU.
> > 
> > 
> >    2:  For receivers that support out of order reception of 
> FPDUs (see
> >        section 5.1 MPA Markers on page 16) a Marker can 
> always be used
> >        to locate the beginning of an FPDU (in FPDUs with 
> valid CRCs).
> >        Since the location of the marker is known in the octet stream
> >        (sequence number space), the marker can always be found.
> > 
> > 
> >    3:  Having found an FPDU by means of a Marker, following 
> contiguous
> >        FPDUs can be found by using the ULPDU Lengths (from 
> FPDUs with
> >        valid CRCs) to establish the next FPDU boundary.
> > =======
> > 
> > If we have an out of order FPDU, and support markers, we 
> use the next 
> > available marker to recover stream sync. By item two above, this 
> > requires that we validate the FPDU which has the marker in 
> it with a 
> > CRC.
> > 
> > Hence it appears that an implementation planning on using 
> markers must 
> > also require that CRCs be supported. Is this the intent?
> > 
> >  
> > 
> > Barry Reinhold
> > Lamprey Networks
> > bbr at lampreynetworks.com
> > (603) 868-8411
> >  
> > 
> > 
> > 
> > 
> > _______________________________________________
> > rddp mailing list
> > rddp at ietf.org
> > https://www1.ietf.org/mailman/listinfo/rddp
> > 
> 
> _______________________________________________
> rddp mailing list
> rddp at ietf.org
> https://www1.ietf.org/mailman/listinfo/rddp
> 

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp