Re: [RPRWG] CRC check in each node?
In Ethernet recomputation of CRC depends on what you are doing with the packet.
When doing L2 bridging, the L2 port manager software usually programs the MAC to
not re-compute CRC on output (so CRC is checked on input, but not recomputed on
output)..
This is because none of the packet contents change. Recomputing CRC on output
will hide any errors that happened in the payload while it was sitting inside
the system or while the bytes were rolling out. In a chain of L2 bridges you'd
never know which bridge caused corruption (if you even detect it - note that
even the end node may not know the packet is in error).
CRC is recomputed in L3 case when the header bytes change, or now in MPLS when
label and TTL values change.
I think RPR MAC should preserve payload integrity and provide its own little CRC
to accommodate changes in TTL and other parameters, and leave payload CRC intact
from source to destination.
In RPR, systems would program the MAC to recompute CRC when they do L3 stuff. In
normal L2 case, MAC will update TTL, etc. and recompute its own CRC and leave
payload CRC alone.
Leaving payload CRC unchanged to prevent system errors is increasingly more
important with large payload sizes.
-Pankaj
Devendra Tripathi wrote:
> Hi,
>
> It may be worth not moving away from Ethernet philosphy, unless required. In
> Ethernet, as we know, we re-compute CRC on each node. Ofcourse like
> Ethernet, one may always want to have flexibility of disabling CRC
> generation (this can be left as implementation issue also)
>
> Regards,
> Devendra Tripathi
> CoVisible Solutions Inc.
> (formerly VidyaWeb, Inc)
> Pune, India
> Tel: +91-20-433-1362
>
> > -----Original Message-----
> > From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> > [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Ray Zeisz
> > Sent: Friday, June 22, 2001 4:23 AM
> > To: 'Denton Gentry'
> > Cc: 'stds-802-17@xxxxxxxx'
> > Subject: RE: [RPRWG] CRC check in each node?
> >
> >
> >
> > I absolutely agree. If at all possible we should not regenerate
> > the user's
> > data packet CRC (assuming the MAC encapsulates Ethernet frames) unless
> > necessary. If the packet is sitting in non-parity or ECC memory awaiting
> > transmission and the CRC is regenerated at each node there is a lot of
> > opportunity for undetected (or late, i.e. the entire FTP file transfer has
> > to be completed) error.
> >
> > It would be optimal for any encapsulation or header that .17 puts on a
> > packet to not effect the user CRC.
> >
> > Ray Zeisz
> >
> > LVL7 Systems
> > http://www.LVL7.com
> > (919) 865-2735
> >
> >
> >
> >
> > -----Original Message-----
> > From: Denton Gentry [mailto:denny@xxxxxxxxxxxxxxxxxx]
> > Sent: Thursday, June 21, 2001 10:57 PM
> > To: stds-802-17@xxxxxxxx
> > Subject: Re: [RPRWG] CRC check in each node?
> >
> >
> >
> > I'd prefer the TTL not be included in the same CRC used over the
> > user data. If a packet traverses N nodes on the ring, there would
> > be N places where failing hardware could result in undetected data
> > corruption of the user's data.
> > If the CRC is left intact all the way across the ring, there are only
> > two places where the packet could be corrupted undetected (the source
> > and the destination).
> >
> > As for whether to strip bad packets at each node: never optimize
> > for errors. I don't think increased efficiency in handling bad
> > packets is worth added complexity in the MAC.
> >