RE: [RPRWG] CRC check in each node?
Ray,
Unfortunately, we are back to the store-and-forward question. If
store-and-forward is not used, we'd have to put a trailer on the end of each
packet. If store-and-forward is used, then a bit in the header could
indicate the packet is already known to be errored.
An alternative to addressing the store-forward limitation could be
to set the payload CRC to a specific error value, upon detection of a bad
CRC.
This can be used to indicate to subsequent
stations that the payload error has already been detected and
accounted for. By using the CRC field, moves the error indication to the
end of the packet and addresses the head of the packet dependency
on receiving the entire packet and validating CRC. This provides
a mechanism for providing a user error indication, without
restricting a "cut-through" implementation.
I agree that if the RPR standard is going to support delivery
of data packets with bad user data CRC, then the RPR header
including TTL has to be protected by its own CRC/HEC. If the intent
is to deliver packets having bad user data CRC to the end customer,
there needs specific addressing information in the RPR packet header
to allow for this, beyond the RPR station address.
For example, equipment deployed by the service provider servicing multiple
customers,
that interfaces to an RPR network, needs to have addressing information that
specifies the RPR station, so the RPR station can strip the packet from
the ring. The header also needs to support addressing information
that allows the RPR station to deliver to the appropriate client interface.
If the final addressing information that is used to deliver the packet
to the customer data interface is protected by the same CRC that is
used to validate the customer data, then a bad CRC indication makes
the packet undeliverable.
regards,
Bob
Robert Castellano
Jedai Broadband Networks
(732) 758-9900
rc@xxxxxxxxx
-----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:26 PM
To: 'Angela T. Faber'
Cc: 'stds-802-17@xxxxxxxx'
Subject: RE: [RPRWG] CRC check in each node?
Ah, good point. 802.5 solves this by having a bit in the ending delimiter
that a station sets when it sees a bad CRC. The ending delimiter follow the
CRC in token ring.
Each station keeps two counters for CRC errors:
One counter is incremented when the error indicate bit is set,
the other counter is incremented when the error indicate bit is not set.
Note that 802.5 also had bits in the ending delimiter to indicate that a
frame had been "address recognized" meaning that someone on the ring matched
the DA, and "frame copied" meaning someone on the ring matched the DA and
copied the frame into its buffer successfully. Since we want spatial reuse,
these bits are not useful.
Unfortunately, we are back to the store-and-forward question. If
store-and-forward is not used, we'd have to put a trailer on the end of each
packet. If store-and-forward is used, then a bit in the header could
indicate the packet is already known to be errored.
Ray
P.S.
To be technically accurate for the true token ring folks out there: The
"line error" counter is incremented for CRC errors or differential
Manchester code violations.
Ray Zeisz
LVL7 Systems
http://www.LVL7.com
(919) 865-2735
-----Original Message-----
From: Angela T. Faber [mailto:afaber@xxxxxxxxxxxxx]
Sent: Friday, June 22, 2001 3:08 PM
To: Ray Zeisz
Cc: ieee 802.17 list
Subject: 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.
> > >