Re: [RPRWG] CRC check in each node?
Mike, you bring up an interesting point. However, we must remember that
802.1d is talking about transferring a packet across domains, from one LAN
to another. While we may get some information from seeing what they do, I
would be slow to draw any conclusions as to what should or should not be
done within a single domain LAN, MAN or WAN, based on what is done when we
cross domains.
If we look within a single LAN, certainly 802.3, 802.5, and FDDI have no
capability of prematurely removing a frame with a CRC error from a LAN, nor
can any of the wireless protocols.
Best regards,
Robert D. Love
Chair, Resilient Packet Ring Alliance
President, LAN Connect Consultants
7105 Leveret Circle Raleigh, NC 27615
Phone: 919 848-6773 Mobile: 919 810-7816
email: rdlove@xxxxxxxx Fax: 208 978-1187
----- Original Message -----
From: "Mike Takefman" <tak@xxxxxxxxx>
To: "ieee 802.17 list" <stds-802-17@xxxxxxxx>
Sent: Monday, June 25, 2001 9:47 PM
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