[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [16NG] Re: multicast and IPv6 over ETHCS



Hi Max,

Let me try to understand this.  You suggest that it is the aim of the
draft to specify the link layer behaviour when forwarding IPv6 multicast
messages.  I suggest that no link-layer behaviour should be specified,
but the interface.  (a distinction akin to OO programming, but
may not be that obvious).  I think we  may be saying the same thing but
with different words.

So, in order to clarify whether we agree or not: do you agree with the
multicast text I've sent, see below?   Do you think that text has its
place in the draft?

Thanks,

Alex

Riegel, Maximilian wrote:
Hi Alex,

I do not agree with your proposal. It is the aim of the draft to specify the particular behavior of the link layer when forwarding IPv6 multicast messages.

The IPv6 solution does not relay on the multicast implementation in the ETH link layer, but specifies what should be provided in the ETH link layer to more efficiently handle IPv6 multicast messages over IEEE802.16.

Bye Max

[snipping the rest of thread and inserting the multicast for IPv6 on ETHCS proposal text]

Running IPv6 over an Ethernet link needs the support of link-layer multicast. In the 802.16 context, the Ethernet Convergence Sublayer (also known as the IEEE Std 802.3/Ethernet-specific part of the IEEE
802.16 Packet Convergence Sublayer) must (1) support multicast link-layer addresses (2) map IPv6 multicast addresses to link-layer addresses and vice-versa, (3) offer the capability of joining and leaving IPv6 link-local multicast groups and (4) send and receive IPv6 link-local multicast packets whose link-layer headers contain link-layer multicast addresses.


The following link-layer multicast addresses are recommended by RFCXXXX: 33:33:0:0:0:1, 2, 33:33:ff:XX:XX:XX, and others [fill].

The rules for mapping IPv6 link-local multicast addresses to link-layer multicast addresses are recommended by RFCxxxx and are the
following: - ff02::1 maps into 33:33:00:00:00:1 - and the others.



The IPv6 stack must join a certain link-local IPv6 multicast group before receiving packets addressed to that group. For example, before
receiving a Router Advertisement the stack MUST join the IPv6 link-local multicast address 'all-nodes'. When the IPv6 stack on the
Subscriber Station joins a certain IPv6 link-local multicast group
it MUST receive all packets addressed to that group. The join
operation can happen in several ways: sending a MLD REPORT (RFCxxx),
setting a local filtering rule, etc.


The IPv6 stack must be able to leave a certain IPv6 link-local multicast group. When the IPv6 stack leaves a group must no longer receive the IPv6 packets addressed to that group. Similarly to the joining operation the leaving operation can happen in several ways: sending a MLD REPORT, setting a local filtering rule, etc.

The following Neighbour Discovery messages are sent by a Subscriber Station to IPv6 link-local multicast addresses: Neighbour Advertisement, Neighbour Solicitation, Router Solicitation (RFCxxxx).
The following Neighbour Discovery messages are received by a Subscriber Station, addressed to IPv6 link-local multicast addresses:
Router Advertisement, Neighbour Advertisement, Neighbour Solicitation.

_______________________________________________ 16NG mailing list 16NG at ietf.org https://www1.ietf.org/mailman/listinfo/16ng