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