| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Ray, Mike, Raj, Angela:
There are two issues here:
1) If there is only one CRC that covers the ring header (DA) and the payload, then you don't
known if the error occurred in the header (un-routable packet) or in the payload.
If the TTL is also covered by the CRC then the only way TTL can remove packet
is because the DA is unknown to all the stations on the ring. This TTL is rather useless.
all error packets must be discarded.
This violate the Transparent Lan Service model. Error packet is delivered to the
customer for SLA reasons. Any packet discarded will have to be able to be validate
at the receive end. Keeping statistics on the ring becomes a big scaling problem.
This also prevents any of you out there who want to do transparent mapping.
2) in the cut through mode, error packet are delivered to its destination which may
decide to discard or not and keep stats accordingly.
In cut-through the header will have to processed for source removal, destination strip,
and TTL processing.
In either case, Adding a ring header error checking can be used to validate the correctly
of the header. If the packet is routable, forward it.
For store and forward mode, you can check if the packet CRC is correct and discard the packet depending on the
configuration of the MAC and the service the box is offering.
Recommendation:
Header error checking is valuable, there is an error floor rate for any transmission medium.
For all possible services that the ring can offer, and for RPR to be
payload agnostic then it shall not drop any error packet. Unless a header error is detected.
Un-routable packet is a given, there is not much one can do but to discard it!
Remove un-routable packet so it does not circulate on the ring forever.
Regards,
Harry
-----Original Message-----
From: Ray Zeisz [mailto:Zeisz@xxxxxxxx]
Sent: Friday, June 22, 2001 7:23 AM
To: 'Mike Takefman'; Raj Sharma
Cc: 'Angela T. Faber'; ieee 802.17 list
Subject: RE: [RPRWG] CRC check in each node?
There are plenty of Ethernet switches that operate in (gasp!) cut-through
mode. These switches propagate CRC errored frames because they switch from
one port to another after only receiving the MAC header. The original
Ethernet switch (Kalpana) operated this way...and received a lot of
criticism. From my perspective, it appears that most of the Ethernet switch
industry is moving away from this and not propagating CRC errors. This is
largely due to the fact that the industry is moving away from shared bus
architectures.
Today, most Ethernet MACs and Network Processors have control bits that
allow you to selectively receive or discard packets that are CRC errored,
too long or runt (too short).
I believe that Raj mentioned some services that require errored packets to
be delivered at the Orlando meeting. Maybe he could tell us more about
these and what the errored packets provide to the end station.
FYI: IBM has a patent for adaptively running in cut-through or
store-and-forward based on the bit error ratio over a period of time, on a
per link basis.
Ray Zeisz
LVL7 Systems
http://www.LVL7.com
(919) 865-2735
-----Original Message-----
From: Mike Takefman [mailto:tak@xxxxxxxxx]
Sent: Thursday, June 21, 2001 9: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
>