Re: [RPRWG] CRC check in each node?
Ray
But if every node counts the same packet with the CRC corrupted, I think
that this is even worse for fault localization and correlation.. For
example, the second node that get the corrupted packet will say that there
may be a problem in the link, where the problem is really in the previous
link... No?
Angela
----- Original Message -----
From: "Ray Zeisz" <Zeisz@xxxxxxxx>
To: "'Pankaj K Jha'" <pkj@xxxxxxxxxxx>
Cc: <stds-802-17@xxxxxxxx>
Sent: Friday, June 22, 2001 11:51 AM
Subject: 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.
> > >