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

["Riegel, Maximilian" <[e-mail]>]

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

-----Original Message-----
From: Alexandru Petrescu [mailto:[e-mail]] 
Sent: Monday, January 15, 2007 1:24 PM
To: Jihoon Lee
Cc: [e-mail]; [e-mail]
Subject: [16NG] Re: multicast and IPv6 over ETHCS

Hi Jihoon,

Jihoon Lee wrote:
> Hi Alex,
> 
> Sorry for my late response. Basically I agree with your opinion. An 
> IPv6 node requires a link local multicast address in order to perform
>  DAD, ND, and RA.
> 
> Contrary to our expectations, 802.16/16e don't support UL multicast 
> (which means an MS forwards data directly to other MSs in the same 
> cell).
> 
> (BTW, I think I need to clarify the UL multicast I mentioned. I 
> believe you already know this: the multicast/broadcast which is sent 
> by an MS  to other MSs in the same cell (BS) cannot be supported in 
> 802.16. However, other MSs in another cell (BS) may receive this 
> since the 802.16 backhaul (WiMAX ASN) may multicast/broadcast at ETH 
> or IP layer.)
> 
> I agree that the document needs to specify how to deal with this 
> problem.

Yes, I think the IPv6-over-ETHCS document should make clear the
assumption of IPv6 using link-layer multicast for IPv6.  I don't think
the IPv6-over-ETHCS document should solve the problem you mention above
between parenthesis (uplink mc, or mc between BSs) at link layer.

The IPv6-over-ETHCS document could list the behaviour of ETHCS it
expects.  Ie:

-when MS sends NS to a IP solicited-node multicast address the node who
  has joined group must receive it.
-when BS or AR advertises an RA to all-nodes multicast address then all
  SSs who have joined that group must receive it.
-mapping an IPv6 link-local multicast address should happen (eg sending
  a packet to IP dst ff02::1 should have the link-layer dst
  33:33:33:0:0:0:1).

The document IPv6-over-ETHCS should list what are the means for SS to
_join_ a link-layer multicast group.  There are few of them (send a
link-layer message, send a MLD message, establish a local filtering
rule, always receiving all packets, etc).

But I don't think the IPv6-over-ETHCS document should specify the
link-layer behaviour for an implementation of ETHCS link-layer
multicast.  Do you agree with this latter item?

Alex

> 
> Best regards, Jihoon
> 
> 
> 2007/1/12, Alexandru Petrescu <[e-mail] 
> <mailto:[e-mail]>>:
> 
> Hi Jihoon, thanks for reply,
> 
> Jihoon Lee wrote:
>> Hi Alex,
>> 
>> Let me jump into discussion. 1) 802.16/16e MAC has no capability to
>>  do uplink multicast. In DL, 802.16 provides multicast CIDs which 
>> is initiated by DSA messages. In UL, however, there is no way for 
>> an MS to access others' UL data fundamentally, in 802.16 PHY/MAC.
> 
> Ok.  For one, if the 802.16MAC is not capable to do bidirectional (or
>  normal) multicast then that is a big issue for IPv6-over-IPv6CS. 
> (and surprisingly, apparently the document IPv6-over-IPv6CS doesn't 
> seem to mention the word 'multicast'.)
> 
> The issue is that a SS running IPv6 needs to multicast a NA, from 
> time to time.  For DAD it needs to send a NS to a multicast address 
> too.
> 
>> In case of ETH over 802.16, the ETH(bridge) may cover this (an MS 
>> sends multicast data in UL, and then a bridge forwards it back). 
>> But, there is still a difficulty in multicasting data back except 
>> for the source MS.
> 
> You mean the bridge in BS?  I was thinking ETHCS in SS may offer a 
> multicast interface to the IP stack.
> 
> In both cases (bridge in BS or bridge in SS), I think it is not up to
>  this document to specify how the ETHCS transforms a asymmetric ul/dl
>  multicast feature into a symmetric one.  But it should be a goal for
>  ETHCS to offer such an interface to the IPv6 stack, otherwise the 
> IPv6 stack won't work.  What do you think?
> 
> Alex
> 
> 


_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng

_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng