RE: [RPRWG] CRC check in each node?
David,
Good summary and comments on this discussion.
I think there still may be some confusion on the two CRC's if we were
to decide on a separate header CRC. Here are my views:
1) Agreed.
2,3) A frame with a corrupted header CRC is non-routable and must be
discarded immediately. The header contents include source/destination
addresses and TTL counter. Hence the header CRC can be regenerated at
each node for the new TTL value. There is no need to "update" the CRC is
such a way that errors are propagated since an error unconditionally causes
the frame to be discarded at the first node to detect the error.
A frame with a corrupted payload CRC is still routable and is forwarded to
the destination. Thereby the destination can log the error. Also, one
important point is that since the payload CRC is never regenerated by
intermediate nodes there is no risk that internal failure in a node causes
corruption of payload data for which a new valid CRC is generated. That kind
of failure is very hard to trace.
4) All nodes must check for a valid header CRC before forwarding the frame.
Since the header is only a few bytes this does not mean that a lot of
buffering is required and a cut-through mode of operation can still be used.
Stomping or not is really a error logging question. In my mind it would be
OK for a node to corrupt a payload CRC in a specific way to tell the world
that this error is already logged, but never to regenerate a new good CRC.
Regards,
Fredrik
> -----Original Message-----
> From: David V. James [mailto:dvj@xxxxxxxxxxxx]
> Sent: Monday, June 25, 2001 9:08 PM
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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
> >
>