[16NG] Re: multicast and IPv6 over ETHCS

[Alexandru Petrescu <[e-mail]>]

Hi Jihoon, thanks for your comments.

Jihoon Lee wrote:
> 2007/1/16, Alexandru Petrescu <[e-mail] 
> <mailto:[e-mail]>>:
>      > 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.
> 
>  
> I agree with you on the clarification of the requirements/assumptions 
> related to MS's UL multicasting.
>  
> In particular, however,  I think (2) and (3) above are not required in 
> ETHCS. They should be upper layer or upper management function (that is, 
> 802.3 bridge function) comparing to the ETHCS layer (Here I assume that 
> ETHCS differs from 802.3 Ethernet bridge). Since ETHCS is a part of IEEE 
> 802.16, it basically supports packet classification (matching 802.16 
> CID) and header suppression only, which we should not touch. Therefore, 
> "In the 802.16 context, the Ethernet Convergence Sublayer must..."  may 
> be inappropriate.

I think (2) wasn't clear.  I think mapping between link-layer multicast 
addresses and IPv6 link-local addresses is mainly done by the IPv6 
stack, not by the link layer.  That mapping should happen, because it's 
the IPv6 stack building the MAC headers.  I think I can rewrite that to 
say that the IPv6 stack does the mapping, would this be ok?

I agree we should not touch ETHCS packet classiffication.

But I think (3 - offer the capability of joining and leaving IPv6 
link-local multicast addresses) is in the scope below the IPv6 stack.

> Regarding others' comments, I think you don't have to specify this on 
> 802.16 CS layer. There should be multiple choices to implement this. 
> However, I think it's worth mentioning what (+ where) should be done. 

Maybe.  But if it's done, these methods should be 'MAY' and in Appendix 
I believe.

> Although, the draft-ietf-16ng-ip-over-ethernet-over-802.16 says: 
> "Multicast is not enabled in the uplink but must be realized by an 
> entity on top the IEEE 802.16 MAC sending packets received on a unicast 
> uplink downstream on a multicast channel.", it's too simple and 
> general to describe uplink multicast transmission of IPv6 packets over 
> ETHCS.

I agree it's too simple, and doesn't cover all that 802.16 MACs can do.

> For example, you may describe what should be done based on the network 
> model:
> (the followings may depend on the network model which the draft refers.
>  
> Assumption: IPv6 ND messages cannot be transmitted to other MSs served 
> by the same BS without any additional supporting function.
>  
> 1) 802.16 BS support a local multicast function. (How? keep this open. 
> Where? Inside BS. maybe a function implemented over ETHCS.) This 
> supposes IEEE 802.16 BS relays the IPv6 ND messages before delivering 
> them to a bridge or an AR.
> 2) There is a bridge between BSs and ARs. Firstly, the bridge relays 
> (multicasts) IPv6 ND messages except for the source MS. 
> Then, it delivers to AR. (How? keep this open. Where? bridge and AR in 
> case of utilizing VLAN ).
> 3) There is GRE tunnel between a MS and an AR. The AR relays IPv6 ND 
> messages to other MSs except for the source MS. (How? keep this 
> open. Where? AR).
> 4) ...

Sounds as a good plan, as an example of implementing link-layer 
multicast.  But I strongly suggest it to contain 'MAY' statements 
everywhere and have it entirely in appendix, as an example of potential 
implementation of link-layer multicast.  This is very good for easing 
readers and understand what the authors tried to say.

> I could not find any flaw in the following text. But, I'm not sure there 
> is another message in IPv6 which is not mentioned in the last paragraph.

You're right.  There are at least DHCP Discovers that are sent to 
link-local multicast addresses (and thus link-layer multicast 
addresses).  There may be many others I don't know, or currently under 
development in other WGs.  I could reformulate to be clear that that 
list is not exhaustive.

But I would like to get first clear agreement from draft's authors 
whether it makes sense to include this text, and where in the draft. 
Once I know that I can finely tune it better to WG members' acceptance.

Alex

>  
> 
>      >
>      > 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng