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

RE: [RPRWG] CRC check in each node?




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