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

["Jihoon Lee" <[e-mail]>]

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 <[e-mail]>om>:
>
> Hi Jihoon,
>
> Jihoon Lee wrote:
> >
> > Hi Alex,
> >
> > My comments inline.
> >
> > Best regards, Jihoon
> >
> > 2007/1/18, Alexandru Petrescu <[e-mail]
> > <mailto:[e-mail]> >:
> >
> > 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng