RE: [RPRWG] CRC check in each node?
Clarification request: the inverted, correct CRC would be a new CRC produced from the errored data?
> -----Original Message-----
> From: Robin Olsson [mailto:robino@xxxxxxxxxxx]
> Sent: Friday, June 29, 2001 3:36 PM
> To: Angela T. Faber
> Cc: ieee 802.17 list
> Subject: Re: [RPRWG] CRC check in each node?
>
>
>
> Hi Angela.
>
> Consider the links A -> B -> C -> D -> E
>
> A sources a packet with correct CRC. If you detect an error
> in node B, you will count the error in node B (for fault
> location purposes), and insert the correct CRC inverted. Node
> C will then either see that 1) the CRC is inverted, that
> means there is no errors on the incoming link to C or 2) the
> CRC is not inverted neither correct, that means that the
> error occured on Node Cs inbound link (C insertes the correct
> CRC inverted and node D and E may also be able to detect
> errors on the inbound link). Regardless, the end-point E is
> still able to see that the packet is errored, hence keep
> statistics per flow/customer if required.
>
> Using a bit instead of the CRC inverted is more complicated
> to implement (since where will you put it) and does not yield
> the same level of coverage, since the packet can only be a
> part of erreror detection on one link (i.e., the first link
> with an error).
>
> If the error occur in the header the packet is discarded and
> the error information is lost and can not be realted to any
> specific flow. However, since the header will be a percentage
> of the average packet size, the number of errored packets can
> be approximated with being proportinal to the number of
> detected error packets. If more precise bit-error rates are
> required, some other mechanism is probably required since the
> packet size is variable.
>
> Robin
>
> "Angela T. Faber" wrote:
>
> > 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
> > > ---------------------------------------
> > >
> > >
>
> --
> ---------------------------------------
> Robin Olsson
> Vitesse Semiconductors, Denmark
> Phone: +45 4596 9659
> fax: +45 4596 9699
> ---------------------------------------
>
>