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