| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
-----Original Message-----
From:
owner-stds-802-17@xxxxxxxxxxxxxxxxxx
[mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On
Behalf Of David V. James
Sent: Tuesday, June 26, 2001 12:08 AM
To: ieee
802.17 list; OLSSON,FREDRIK (A-SantaClara,ex1)
Cc: David V. James;
dbg@xxxxxxxxxx
Subject: RE: [RPRWG] CRC check in each
node?
Fredrik (et al),
I don't agree that updating the TTL
counter implies a loss of
coverage in intermediate nodes. Let me address this
and some
other points simultaneously. Under some topics, I have listed
Pro
and Con arguments and personal preference.
1) Should the packet header
and data have separate CRCs?
PRO: The error is generally much
longer than the header,
so this
would more frequently allow
route-specific
logging of errors
(when the header is OK, but the
data is corrupt).
PRO: Its easier to modify the header, or
insert extended
headers, in
various stages of bridge-like routing.
CON: The packet is longer
by approximately 4 bytes.
ME: The header(s) and data
payload have separate CRCs.
4) Do packets have to be checked, to uncover their bad
CRCs,
before being forwarded?
NO: The
strategy at the receiver's CRC checking
hardware
is to compute the valid
CRC while the initial portion
of
the packet is passing through. When the CRC is
reached,
the following algorithm
is performed:
#define
CRC_STOMP 0X55555555 // A possible CRC_STOP
value
if (checkCRC!=packetCRC)
{
errorCount+= (packetCRC!=
checkCRC^STOMP);
packetCRC^= STOMP;
}
For those unfamiliar with "C", the CRC_STOMP value is
a
constant to be defined by this committee; the value
shown
is not necessarily the best value. If the
packet's
CRC is bad, but has not yet been "stomped", then an
error
count for that link is incremented. In any case, a
packet
with a bad CRC is always "stomped", by replacing the
"bad"
CRC with a particular bad CRC, namely the good CRC
exclusive-OR'd
with the STOMP value.
Now
while its possible for the "stomped" value to be generated
by a
coincidental transmission error, the chance of this is
quite
small, so that only a small number of errors (1 in 2**32)
would
be incorrectly logged.
Note that operations (2) and (4) are
logically independent
actions, so neither interferes with the
operation of the other.
An alternative to addressing the store-forward limitation could beto set the payload CRC to a specific error value, upon detection of a badCRC. This can be used to indicate to subsequentstations that the payload error has already been detected andaccounted for. By using the CRC field, moves the error indication to theend of the packet and addresses the head of the packet dependencyon receiving the entire packet and validating CRC. This providesa mechanism for providing a user error indication, withoutrestricting a "cut-through" implementation.
DVJ (David Vernon James)
-----Original
Message-----
From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
[mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On
Behalf Of OLSSON,FREDRIK
(A-SantaClara,ex1)
Sent: Friday, June 22, 2001
1:36 PM
To: ieee 802.17 list
Subject: RE: [RPRWG] CRC check in each
node?
My two cents worth:
As mentioned in a previous
email, I agree that it is preferable not to
regenerate the payload CRC at
intermediate nodes to allow a real end-to-end
protection of the
payload.
Then a separate CRC is required for the destination address and TTL
counter,
so non-routable frames can be discarded.
One Ethernet
encasulation protocol already defined with a separate header
CRC is GFP
(Generic Framing Procedure). It is pushed both in T1X1 and ITU-T.
I think it
deserves a second look at, and could maybe serve as a base with a
new RPR
header we define. The frame mapped version with a modified ring mode
header
may be close to what we need.
The latest GFP copy can be downloaded
at:
<ftp://ftp.t1.org/T1X1/X1.5/1x150243.doc> File name:
1x150243.doc
http://www.t1.org/filemgr/FileList.taf?Directory=t1x1%5Cx1.5
<http://www.t1.org/filemgr/FileList.taf?Directory=t1x1%5Cx1.5&ShowTitle=New%
20T1X1.5%20Files>
&ShowTitle=New%20T1X1.5%20Files
GFP as is would work fine for SONET
and OTN PHY's. To work with Ethernet
PHY's it may be possible to make the
frame "Ethernet-like" by just adding a
PA and SFD?
Regards,
Fredrik
Olsson
Agilent Technologies
-----Original Message-----
From:
Nader Vijeh [mailto:nader@xxxxxxxxxxxxxx]
Sent:
Friday, June 22, 2001 12:25 PM
To: ieee 802.17 list
Subject: RE: [RPRWG]
CRC check in each node?
I agree with Harry on not discarding packets
with bad CRC. Not only carriers
will not like this, but it also goes against
the fact that MAC is not
actually "receiving" packets in transit. Packet
discard due to CRC error is
defined as part of the "receive function" in the
802 MACs.
To answer Mike's question on Ethernet MACs, they all have a
"promiscuous"
mode that allows them to receive all packets on the media, this
mode is
normally used in bridges, allowing the bridge to make the decision
on
forwarding.
-----Original Message-----
From: Harry Peng [mailto:hpeng@xxxxxxxxxxxxxxxxxx]
Sent:
Friday, June 22, 2001 10:03 AM
To: ieee 802.17 list
Subject: RE: [RPRWG]
CRC check in each node?
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 <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 <http://www.LVL7.com>
(919)
865-2735
-----Original Message-----
From: Mike Takefman [
mailto:tak@xxxxxxxxx <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
<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
>