|
Bob
One question about the TTL: if the CRC Header does
not cover TTL field, how do we know if the TTL is valid? Should it not be
included in a CRC-header maybe because the probability of the TTL be
corrupted and still have a in-range (i.e., valid) value is very
low?
Thanks!
Angela
----- Original Message -----
Sent: Tuesday, June 26, 2001 12:17
PM
Subject: RE: [RPRWG] CRC check in each
node?
David,
See comments
to your email below.
A basic question is
whether RPR frames
with bad headers should
continue on the ring
until their TTL expires,
or should the packet
be stripped as soon as a
bad header is detected?
Even in a cut-through
implementation, the packet
header cannot be
regenerated on the next ring segment
until the TTL is
checked. If the
RPR frame supports
a header CRC this
CRC would likely follow
right after the TTL. It would
be
worth performing the
header CRC check and stripping
the packet if the header
is bad.
thanks,
bob
-----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.
rc - I agree header and
data payload should have separate
CRCs for the two
pro-reasons given. It also removes
the header dependency on
the tail end of the data packet which
is required for
cut-through implementations. The modified
CRC algorithm you mention
below could allow the packet
to begin regeneration on
the next ring segment, but do
we really want an errored
packet to circulate on the
ring until its TTL
expires? (see 2 below)
2) Can packets be modified (TTL changes) without losing
their
error coverage during the change?
YES:
Rather than strip the CRC and recompute the CRC,
a
differential CRC is computed
on the differential TTL
value,
(TTL-1)^TTL. This differential CRC is
then
EXOR'd with the value
received at the input, thereby
generating a revised transmit CRC without loss
of
converage. Nothing new, this
was discussed when
working on
IEEE Std 1596 Scalable Coherent
Interface
(I believe it source
was an IBM RAS (reliability,
availability, and support) guy, but I'm not sure.
rc - I guess it
depends on the strategy for dealing with
corrupted headers.
Should a packet with a corrupted
header be allowed to
continue on the ring or
should the header be
validated prior to regenerating
over the next ring
segment. If the header awaits completion
of the CRC check, then
the station can simultaneously
perform check on the
incoming header while generating
a new CRC based on the
outgoing header with modified
TTL.
3) Can packets with bad CRCs be discarded?
PRO:
Because their contents cannot be trusted, its fine
to
discard them. A bad header
can be discarded, since a
0
valued TTL would cause the same effect.
Discarding
of a bad data block
is OK, but only if the header
could
not be interpreted as a
valid packet in the absence of
its payload.
PRO: The only penalty for discarding them is the
loss of
error-logging diagnostic
information. However, is
separate
header and payload CRCs
are provided, the header will
usually (in a statistical sense) be preserved and
the
larger data payload will be
corrupted. Hence, error
logging
is still possible.
PRO: Error logging information, based on
corrupted data,
will itself
become untrustworthy.
PRO: Its easier for store-and-forward
implementations to
simply
discard corrupted packets, rather than
being
forced to "stomp" them, as
described in #4.
CON: There is some loss of error checking on
packet header
corruption.
ME: These corrupted packets should be
treated as effectively
discarded, where a packet stomping (see point #4)
has
the same architectural
effect as discarding the packet,
i.e. the packet error is not logged again.
rc - I agree with pro
1/pro 2. The error logging capability
in PRO3 is dependent on
where the error checking is
done, and the nature of
the payload at the place where
the checking is
done. For example, if the RPR header
provides enough
addressing information to deliver a packet
to a client
interface. The SLA checking could be done
at the client
interface. If the SLA checking is performed
downstream of the client
interface, where the client
requires certain portions
of the data frame to reliably
forward the packet, then
these subsequent headers
need to be protected by
their own 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.
I am an advocate of
stomping which allows RPR stations
to gather their own link
statistics while attempting to
deliver packets to aid
downstream performance monitoring
functions. The
stomping function is what I described in
the mail message that I
sent yesterday.
An alternative to
addressing the store-forward limitation could be
to set the payload CRC to
a specific error value, upon detection of a bad
CRC. This can be used to indicate to
subsequent
stations that the payload
error has already been detected and
accounted for. By using
the CRC field, moves the error indication to the
end of the packet and
addresses the head of the packet dependency
on receiving the entire
packet and validating CRC. This provides
a mechanism for providing
a user error indication, without
restricting 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
>
|