Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [RPRWG] CRC check in each node?






I would argue that span management should be a PHY layer function.

In typical LAN protocols, "span management" function is limited to CRC
computation at the MAC layer. (we could also argue that "link/unlink"
condition is also a span management function...)

In WAN protocols, span management functions are part of the PHY layer.
RPR is targetted at the WAN area; wouldn't it make sense to use a "WAN-ish"
approach?
Example:  SONET/SDH section & line overhead.

jld.

PS:  I understand that in order to leverage commercial Ethernet PHYs this
proposal is handicapped.
BTW,  _standard_ Gigabit Ethernet PHY layer is limited to 5km
(1000Base-LX)... might not be adequate as a PHY in the RPR context.







Raj Sharma <raj@xxxxxxxxxxxx>@majordomo.ieee.org on 06/21/2001 05:40:20 PM

Sent by:  owner-stds-802-17@xxxxxxxxxxxxxxxxxx


To:   "'Angela T. Faber'" <afaber@xxxxxxxxxxxxx>, "ieee 802.17 list"
      <stds-802-17@xxxxxxxx>
cc:

Subject:  RE: [RPRWG] CRC check in each node?



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