Re: [RPRWG] CRC check in each node?
Robin
Maybe I am missing something from your email below. If we change the value
of the CRC (or add a bit to indicate it) to say that the error was already
accounted for in the node that first detected it, how about other errors
that may occur in this packet downstream from the node that changed the CRC?
Only packets with "correct" CRC would then be able to detect those errors?
Angela
----- Original Message -----
From: "Robin Olsson" <robino@xxxxxxxxxxx>
To: "igorz" <igorz@xxxxxxxxxx>
Cc: "ieee 802.17 list" <stds-802-17@xxxxxxxx>
Sent: Wednesday, June 27, 2001 3:13 PM
Subject: 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
> ---------------------------------------
>
>