RE: [RPRWG] CRC check in each node?
Necdet,
Please see my responses below:
Nader
-------------------------------------------
< Nader,
< Please see my comments below.
< Thanks.
< Necdet
> Nader Vijeh wrote:
> One of the challenges we have in 802.17 is emulation of the "broadcast
> media", which is the basic assumption for most if not all of the 802 MACs.
> The act of "destination stripping" complicates this as the receive
function
> of 802 MACs is not the same as packet removal. 802.3,5, 11 ,etc. all
perform
> receive function without removing the packet. In other ring MACs (e.g.
> 802.5), the source MAC removes the packet with the assumption that all
other
> MACs have "seen" the packet.
>
> The challenge is to perform destination stripping without performing
> bridging (switching) function, as that will be outside the scope of the
> 802.17.
< We have passed an objective passed stating "The MAC shall support
destination
< removal for unicast packets during normal operation." , hence 802.17 MAC
shall
< perform destination stripping for unicast packets. The "emulation of the
< 'broadcast media' " though can be handled using multicast which does not
require
What I am highlighting here is that we can not propose a 3 port bridge as a
MAC.
< destination stripping. One way to implement bridging without violating the
< destination stripping objective is to use broadcast for learning and to
use
< unicast with encapsulation for the delivery of the bridged packets. There
will
< be a presentation on this in the July meeting.
I agree. We need to comply with 802.1D requirements.
>
>
> We can specify functions such as CRC checks and may be manipulating the
CRC
> filed or a bit in the header to indicate a bad packet, etc, as a MAC
> function. Specifying packets to be discarded or re-ordered or otherwise
> "received" and "re-transmitted", is harder to do in the context of an 802
> MAC. In other words, specific implementations may wish to buffer packets
in
> transit or not, without making that a requirement in the standard.
< I don't understand why it is difficult to specify packets to be discarded.
We
< may want to make it optional to drop or not to drop packets with CRC
errors,
< however, we should determine a default behavior for this decisions.
< We should definitely specify packets to be "received" (i.e., unicast) and
< "received and copied to transit path" (i.e., multi-cast) in the standards.
In
< fact
< we have already decided on the first one (unicast) and implied for the
second
< one (multicast) by passing objectives relating to them in the prior
meetings.
The MAC discards packets with CRC on the receive side, but not when packets
are
in transit. Discarding in the transit path will happen when TTL has reached
0.
Probability of an error in the TTL field multiple times is extremely
small. Therefore, even if the error is in the header and in the TTL field,
the
packet will be removed from the ring (after 256 nodes are traversed).
We do not need to add extra comlexity to avoid very small bandwidth wasted
due
to an error in the TTL field.
< I agree with you with respect to transit path implementation not being
part of
< the standard if we can show that this would not cause any
inter-operability
< problems.
>
>
> As for "fairness", if there is an "active" control mechanism, as covered
by
> multiple proposals, it is possible to regulate access to media without the
> need to perform packet switching at each node (station). After all, it is
> the main objective of the WG to devise a Media Access Protocol and not a
> packet switching technology.
< Can you please elaborate on what you mean with switching? I agree that
transit
< packets should not go to the switch fabric and switched back.
The transit path is logically an extension of the medium. If we specify a
"relay"
function in the transit path, then this will change the ordering of packets
in transit. Inserting packets, without creating multiple queues in transit
is less
complicated.
>
>
> The option to receive (drop) all packets and then re-queue them above the
> MAC and then re-transmit them, is an option when the MAC is operating in
> "promiscuous" mode.
>
< Can you please explain why this is needed?
If the MAC is operating in promiscuous mode, it receives and removes all
packets in
transit. Useful for interoperability with implementations that require
queuing of
packets in transit.
>
> Nader