RE: [RPRWG] CRC check in each node?
I agree with you totally.
However, even if CRC errored packets are allowed to pass through a system to
their final destination, each station should be keeping track of the number
of Rx CRC errors it sees on a per physical link basis. This would be the
way to do problem determination; dropping or forwarding the packet doesn't
really buy you much in the area of problem determination. Correlating
errors to physical links is what you really need.
Ray Zeisz
LVL7 Systems
http://www.LVL7.com
(919) 865-2735
-----Original Message-----
From: Pankaj K Jha [mailto:pkj@xxxxxxxxxxx]
Sent: Friday, June 22, 2001 10:46 AM
To: Devendra Tripathi
Cc: Ray Zeisz; 'Denton Gentry'; stds-802-17@xxxxxxxx
Subject: 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.
> >