RE: [RPRWG] CRC check in each node?
At least for CRC error packets, I am doubtful if you can rely of source-dest
pair. I believe, it will be just used to find the reliability of node/link.
For that matter, it may be more informative to find out which node detected
the CRC error.
But this may be besides the main point.
Regards,
Devendra Tripathi
CoVisible Solutions Inc.
(formerly VidyaWeb, Inc)
Pune, India
Tel: +91-20-433-1362
> -----Original Message-----
> From: jeanlou.dupont@xxxxxxxxxxx [mailto:jeanlou.dupont@xxxxxxxxxxx]
> Sent: Tuesday, June 26, 2001 6:31 AM
> To: tripathi@xxxxxxxxxxxx
> Cc: tak@xxxxxxxxx; stds-802-17@xxxxxxxx
> Subject: RE: [RPRWG] CRC check in each node?
>
>
>
> I think that for the proponents of this mode of operation are more
> concerned about _where_ the statistics are accumulated than _how_ to
> retrieve them.
>
> lets say we need to correlate [source;destination] pairs within an
> "end-to-end" service context, you wouldn't want to accumulate the
> statistics in intermediate nodes.
>
> then again, some will argue that this correlation should be done at higher
> layers.
>
> jld.
>
>
>
>
>
>
>
> "Devendra Tripathi" <tripathi@xxxxxxxxxxxx> on 06/26/2001 09:38:03 PM
>
> To: <jeanlou.dupont@xxxxxxxxxxx>, <tak@xxxxxxxxx>
> cc: <stds-802-17@xxxxxxxx>
>
> Subject: RE: [RPRWG] CRC check in each node?
>
>
> Would it not be better to define MIB and do the same via SNMP ? Or we feel
> it as overhead, that way ?
>
> 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
> > jeanlou.dupont@xxxxxxxxxxx
> > Sent: Tuesday, June 26, 2001 5:47 AM
> > To: tak@xxxxxxxxx
> > Cc: stds-802-17@xxxxxxxx
> > Subject: Re: [RPRWG] CRC check in each node?
> >
> >
> >
> >
> > I think that one of the main reason for not discarding an errored
> > packet in
> > the transit path is to be able to implement some sort of "far-end error
> > monitoring" (SONET/SDH concept). This way, we wouldn't have to specify
> > another protocol to implement such function.
> >
> > jld.
> >
> >
> >
> >
> >
> >
> >
> > Mike Takefman <tak@xxxxxxxxx>@majordomo.ieee.org on 06/25/2001 09:47:14
> PM
> >
> > Sent by: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> >
> >
> > To: "ieee 802.17 list" <stds-802-17@xxxxxxxx>
> > cc:
> >
> > Subject: Re: [RPRWG] CRC check in each node?
> >
> >
> >
> > All,
> >
> > An interesting point from 802.1D 1998 is the following.
> >
> > "Note that the frame is completely received
> > before it is relayed as the Frame Check Sequence (FCS)
> > is to be calculated and the frame discarded if in
> > error."
> >
> > It strikes me that if an 802.1D bridge must not relay a packet
> > with a bad FCS, there is nothing wrong with removing it in
> > the transit path of the 802.17 MAC (assuming that it can be
> > done). We are not changing the operation that will
> > occur, just making it happen sooner.
> >
> > I did not see an example of guaranteeing deliverly of
> > a packet with "good" address and "bad" contents in current 802
> > networks. The FCS will alias bad address and bad contents and
> > since .1D specifies that packets with FCS errors will be removed
> > I do not understand how anything with an FCS error continues to
> > flow to an end station unless the LAN is a single segment.
> >
> > I would appreciate a pointer to the relevant part of the standard
> > that describes how to do this type of operation across multiple
> > segments.
> >
> > thanks,
> >
> > mike
> >
> >
> >
> >
>
>
>
>
>
>