Re: [RPRWG] CRC check in each node?
Hi Igor and all
Yes, if there is no additional indication wether the error is already detected or not. Either by a seperate bit or by replacing the CRC with the correct value inverted. Note, that only errored CRCs will have their CRC value altered! A sane packet will keep it's original CRC calculation from the source. In my oppinion this will satisfy the requirement from a lot of people about not having end-to-end CRC coverage if the CRC is re-calculated in intermediate nodes.
Robin
igorz wrote:
> Robin,
>
> wouldn't the intentionally bad CRC mask off all of the subsequent errors?
>
> Igor
>
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Robin Olsson
> Sent: Tuesday, June 26, 2001 12:37 PM
> To: Mike Takefman
> Cc: ieee 802.17 list
> Subject: Re: [RPRWG] CRC check in each node?
>
> Hi Mike and all
>
> If we try and look away from how LAN and Ethernet is done today and just
> concentrate on what to be solved. The far easiest way to provide error
> statistics for a given flow is to not remove the packets. This will work
> even with different system vendors on the same ring. And I can not imagine
> that any carrier will not want the possibility to have error statistics per
> customer/SLA. This IS different from etehernet and LANs - there is no
> concept of carrier capabilities and isn't that one of the reasons for
> wanting RPR in the metro?
>
> I do not understand why anyone wants to remove the packets - for bandwidth
> optimization? I do not beleive that it is important to optimize bandwidth
> for the case of errored packets. I would rather optimize in order to avoid
> errored packets. Fault location? Can be solved differently (see below).
>
> Header error check:
> Needed for validation the control information used within RPR itself.
> Packets with errored headers are discarded, since we do not know what to do
> with them or what customer/SLA it belongs to.
>
> Payload error check:
> Only monitoring. Can be used for determing where errors are injected (fault
> location). Also needed to keep track of performance statistics on the
> interfaces. Can be accompanied with an error indication telling that this
> packet is already discovered to be in error further upstream. This would
> increase the fault location efficiency. Draw back is that it must be placed
> in 1) the header, meaning a need for store and forward or 2) in the end of
> the packets, do we share it with the CRC? or 3) a special faulty CRC value
> (e.g., the correct CRC inverted) to be inserted instead of the received
> value.
>
> I do not want to post an oppinion on store-and-forward as a concept, I just
> do not think that the argument for using it should be error location or
> packet discarding since error location that can be solved differently and
> discarding errored packets is not (in my view) a desired behaviour.
>
> Robin
>
> Mike Takefman wrote:
>
> > All,
> >
> > An interesting point from 802.1D 1998 is the following.
> >
> > "Note that the frame is completely received
> > before it is relayed as the Frame Check Sequence (FCS)
> > is to be calculated and the frame discarded if in
> > error."
> >
> > It strikes me that if an 802.1D bridge must not relay a packet
> > with a bad FCS, there is nothing wrong with removing it in
> > the transit path of the 802.17 MAC (assuming that it can be
> > done). We are not changing the operation that will
> > occur, just making it happen sooner.
> >
> > I did not see an example of guaranteeing deliverly of
> > a packet with "good" address and "bad" contents in current 802
> > networks. The FCS will alias bad address and bad contents and
> > since .1D specifies that packets with FCS errors will be removed
> > I do not understand how anything with an FCS error continues to
> > flow to an end station unless the LAN is a single segment.
> >
> > I would appreciate a pointer to the relevant part of the standard
> > that describes how to do this type of operation across multiple
> > segments.
> >
> > thanks,
> >
> > mike
--
---------------------------------------
Robin Olsson
Vitesse Semiconductors, Denmark
Phone: +45 4596 9659
fax: +45 4596 9699
---------------------------------------