|
Angela, your question about assuring the validity
of the TTL field is a good one. First we must decide if this is a serious
enough issue to take measures to protect against. If we decide it is, then
there are various ways to deal with it. One way where we leave the TTL
field unprotected by a CRC, is to write the TTL field twice. If
the two fields are not identical when received, we can take that as an error
condition (and possibly equate that with a TTL expired condition). Other
solutions would create a TTL field that has valid values separated by a proper
hamming distance so that single bit errors, and burst errors cannot produce a
valid value. Other solutions exist but I am not advocating any particular
one.
Best regards,
Robert D. Love Chair, Resilient Packet Ring Alliance President, LAN
Connect Consultants 7105 Leveret Circle Raleigh, NC
27615 Phone: 919 848-6773 Mobile: 919
810-7816 email: rdlove@xxxxxxxx
Fax: 208 978-1187
----- Original Message -----
Sent: Friday, June 29, 2001 12:51
PM
Subject: Re: [RPRWG] CRC check in each
node?
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
>
|