RE: [RPRWG] CRC check in each node?
Mike,
I tend to prefer including the ttl within the CRC protection,
because:
1) On IEEE Std 1596, we excluded portions for the packet
for supposive "simplicity" reasons. It actually created
more problems than it solved, particularly in trying
to explain how this works (your CRC computation is now
nonstandard, or the ttl would have to follow the CRC,
which has alignment problems).
2) Each node should minimally check its CRC anyway, so
that errors can be localized to the link on which they
occurred. So, complexity of the CRC can't really be
skipped anyway.
As per the argument of wasting bandwidth on CRC corrupted
packets, I think its a bit of a bogus argument. The error
rates are usually so small that this effect is minimal,
from an engineering perspective.
Also, mandating immediate stripping of packets with bad
CRCs mandates store-and-forward implementations, which
(from my perspective) just add unnecessary latency.
Lower latency cut-through connections have to let the bad packet
through, because they haven't checked the CRC before
the first part has gone out. I don't believe such
implementations should be banned due to the concern
of unnecessary bandwidth consumption by infrequently
generated bad CRCs.
DVJ
** ADDRESS CHANGED FOR 2001 **
David V. James, PhD
Chief Architect, Lara Networks
110 Nortech Parkway
San Jose, CA 95134
Cell: +1.408.449.8266
Work: +1.408.942.2010
Fax: +1.408.942.2099
Work: davidj@xxxxxxxxxxxxxxxx
Home&Work: dvj@xxxxxxxxxxxx
-----Original Message-----
From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
[mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Mike Takefman
Sent: Thursday, June 21, 2001 6:05 PM
To: Raj Sharma
Cc: 'Angela T. Faber'; ieee 802.17 list
Subject: Re: [RPRWG] CRC check in each node?
Raj,
It is not clear to me that the ttl has to be within the packet, and
protected by the crc. There are successful implementations that
have the ttl protected outside of the packet. There are advantages
to doing this in terms of the complexity of the implementation.
I do come down on the camp of removing the packet from the ring
once there is corruption. There is no reason to waste BW with
a packet that will be dropped once it is received.
I would be interested to know if there are any Ethernet MAC/
Switch chips sets that do not drop CRC errored packets
when received or any that do it selectively. I would be interested
in understanding the mechanism for differentiating drop behaviour
to understand if it belongs in the transit path.
cheers,
mike
Raj Sharma wrote:
> Angela,
>
> This is an intesting question and is sort of the tip of an iceberg
> (pardon the cliché - I feel the answer to this question is loaded)
>
> There are fundamentally 2 issues here. Misrouting of packets due
> to errors and corruption of the payload.
>
> IMHO, packets whose headers are corrupted must be discarded
> in order to prevent misrouting. The question is whether the misrouting
> prevention is limited between RPR MACs or to the ultimate destination
> entity connected to a RPR MAC. I am assuming that a RPR MAC has
> multiple clients.
>
> Certain services require persistent delivery of frames. Such services
> will make their won decision on what to do with corrupted frames.
> For these services it may require that corrupted frames be still delivered
> to the specific MAC client.
>
> Now, it maybe of significant value in debugging networks and from
> an operational perspective to know over which span on the ring the
> frame got corrupted. Hence CRC recomputation at every node may
> have some value from an operational perspective. Also, since the TTL
> field is part of the frame CRC recomputation cannot be avoided at least
for
> the header.
>
> raj
>
>
>
> -----Original Message-----
> From: Angela T. Faber [mailto:afaber@xxxxxxxxxxxxx]
> Sent: Thursday, June 21, 2001 12:44 PM
> To: ieee 802.17 list
> Subject: [RPRWG] CRC check in each node?
>
> Folks
>
> One question regarding CRC check: are we assuming CRC will be checked
at every node (as the frame is
> forwarded) or it will be checked only at the destination/source node?
> My initial thought on this is that, if we don't do it at every node,
than how do we remove the frame from ring if the
> source and destination addresses are corrupted? On the other hand I
assume that if every node checks it, more
> time is spent with forwarding it....
>
> Any insights are welcomed.
> Thanks!
>
> Angela
>