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

RE: [RPRWG] CRC check in each node?

Title:
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

Robert Castellano
Jedai Broadband Networks
rc@xxxxxxxxx <mailto:rc@xxxxxxxxx>
(732) 758-9900 x236



-----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
>