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

["Jihoon Lee" <jhlee at mmlab.snu.ac.kr>]

Hi Alex,

 

> More specifically, we can define it as being packets addressed to any
> link-layer address prefixed by 33:33 (see the post-scriptum why).

 

Sure. I agree. To support IPv6 transparently over ETHCS over 802.16, multicasting (or broadcasting) packets in both directions of which MAC addresses are 33:33:x:x:x:x is sufficient.

 

> I think we need to identify what are the means to avoid flooding.
 

I'm sorry, I don't know what you're referring to. Anyway, I presume that you mean that flooding (i.e., broadcast) is inefficient in terms of bandwidth usage comparing to multicast. Am I correct? 

 

As Gabriel said before, it's about efficiency. IMHO, supporting either multicast or broadcast (just flood 33:33:x:x:x:x packets)  should be fine.

 

> Otherwise, you seem to say we need to discuss the problem of lack of
> flooding function in 802.16.  What do you mean?
 

I just pointed out there was no uplink broadcast as well as multicast in 802.16 PMP(point-to-multipoint) mode.

 

Best regards,

Brandon
 

2007/1/19, Alexandru Petrescu <alexandru.petrescu at motorola.com>:

Hi Jihoon,

Jihoon Lee wrote:
>
> Hi Alex,
>
> My comments inline.
>
> Best regards, Jihoon
>
> 2007/1/18, Alexandru Petrescu <alexandru.petrescu at motorola.com
> <mailto: alexandru.petrescu at motorola.com> >:
>
> Jihoon Lee wrote:
>> Gabriel,
>>
>>> Notice that if a link layer simply floods all multicast packets
>>> (essentially  using broadcast), things work fine.
>>
>> Let's focus on the main issue. As I know, we started to discuss
>> this problem, because of the lack of flooding function (surely
>> including multicast) between MSs (uplink) in 802.16 MAC layer. So,
>> we're trying to discuss this problem regarding IPv6overETHCS.
>
> I think for IPv6, 'flooding' means sending to the link-layer
> multicast address 33:33::1.  Do you agree?
>
>
> Yes, I do.
>
>
> Do you think there's another link-layer multicast address that does
> this flooding?
>
>
> No, I don't

I think thus we can define *IPv6 flooding* as being IPv6 packets sent
over ETHCS (or over the bridge 'device' in the system deploying the
ETHCS for transmitting Ethernet frames over IEEE802.16), and addressed
to the link-layer address 33:33:0:0:0:1.

More specifically, we can define it as being packets addressed to any
link-layer address prefixed by 33:33 (see the post-scriptum why).

I think we have that definition ok.  I think we need to identify what
are the means to avoid flooding.

Otherwise, you seem to say we need to discuss the problem of lack of
flooding function in 802.16.  What do you mean?

Alex

PS: many other link-layer link-local addresses are candidates of being
flooded.

There may be questions about whether 33:33:0:0:0:2 (not 1) can be target
of an IPv6 multicast link-local flood.

The way to build a link-layer multicast address from an IPv6 multicast
address is specified in rfc2464 sec 7.  If the IPv6 link-local multicast
address is ff02::1 then the link-layer multicast address is
33:33:0:0:0:1.  RFC4291 (addr arch) says that there can be several IPv6
multicast addresses interface-local or link-local: ff01::1 and ff02::1
(all-nodes); and ff01::2 and ff02::2 (all-routers).

Thus one is tempted to think packets sent 33:33:0:0:0:2 (not 1) -
all-routers -  is a potential target for flooding too.

Correspondingly, if we use MLDv2, then floods can happen to 33:33::16
(:16 !) too, flooding all MLDv2-capable nodes.

Floods could happen to 33:33:ff:xx:xx:xx too, the solicited-node address.

Floods could happen to 33:33::1:1 too (flood all NTP servers, relevant
if IEEE 802.16 decides to use NTP in the future, instead of current TIME).

Floods could happen to 33:33::1:2 (all-dhcp-relays-servers) and to
33:33::1:3 (all-dhcp-servers), too.

http://www.iana.org/assignments/ipv6-multicast-addresses lists all
multicast addresses out of which one could derive 33:33 multicast
addresses potential targets for flooding.  One could find some orthodox
protocols such as DVMRP, OSPF or other less orthodox names such as ST,
UPnP or Mobile-Agents.

This would reduce our definition of flooding as being addressed to
33:33::1 link-layer address to wider definition of flooding being
packets addressed to _any_ link-layer address prefixed by 33:33.

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