Re: [RPRWG] CRC check in each node?
Oops! My question was already answered.
Thanks anyway!
----- Original Message -----
From: "Robert Castellano" <rc@xxxxxxxxx>
To: "igorz" <igorz@xxxxxxxxxx>; "Robin Olsson" <robino@xxxxxxxxxxx>
Cc: "ieee 802.17 list" <stds-802-17@xxxxxxxx>
Sent: Tuesday, June 26, 2001 10:01 PM
Subject: RE: [RPRWG] CRC check in each node?
>
> Igor,
>
> The added benefit of using an inverted CRC as a flag for corrupted
> data frames is that if per chance the frame takes a subsequent
> hit on a downstream ring segment, the error can be uniquely logged
> for each segment in which the data portion is corrupted. While
> probability of a frame taking 2 error hits should be very, very
> low, it is readily accounted for using the inverted CRC.
>
> In this case, a modification to David's algorithm is :
>
> STOMP = ~checkCRC;
>
> switch (packetCRC) {
> case checkCRC : break; /* Good */
> case STOMP : break; /* Bad */
> default : errorCount++; /* Ugly */
> packetCRC = STOMP;
> }
>
>
> For a network with stations A, B, C, D, E, and a
> frame sourced from station A sent to station E:
>
> If the frame is corrupted on segment AB, the error
> is counted at B and the data CRC is set to STOMP1 by B.
> The frame is sent along segment BC.
>
> If there are no errors on segment BC, station C computes
> checkCRC and determines it equals STOMP1 value and
> does not update any error counters.
> The frame is sent along segment CD.
>
> If the frame is corrupted on segment CD, then the
> error is counted at D and the data CRC is set to STOMP2 by D.
> The frame is sent along segment DE.
>
> If there are no errors on segment DE, then E receives
> frame from the ring, computes checkCRC and determines
> it equals STOMP2 value and does not update any error counters.
>
>
> In this example, the frame was separately corrupted on segments
> AB and CD resulting in PM counter updates at B and D respectively.
> If the corruption occurred only once on the ring while traversing
> the AB segment, only the counter at B is incremented.
>
> As previously mentioned by others, this assumes the RPR frame
> contains separate header and data payload CRCs, and the header CRC
> remained intact through the entire transmission. The frame
> would have to be removed if the header CRC validation failed.
>
>
> Regards,
>
> Bob
>
>
>
> Robert Castellano
> Jedai Broadband Networks
> rc@xxxxxxxxx <mailto:rc@xxxxxxxxx>
> (732) 758-9900 x236
>
>
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of igorz
> Sent: Tuesday, June 26, 2001 2:16 PM
> To: Robin Olsson
> Cc: ieee 802.17 list
> Subject: RE: [RPRWG] CRC check in each node?
>
>
>
> 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
>
>