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

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

Hi Qiang,

Let me add on a few more words. As you know, normally ETH switches and IP
routers don't forward multicast/broadcast packets back to their source port.
It's based on assumption that local multicast has already done locally in
the network which is connected to the source port.

Let's say an multicast packet sent by an 802.16 MS is delivered to an ETH
bridge or IP access router. It will be forwarded to other ETH/IP interfaces
(ports), but may not be forwarded to its source interface. However, there
may be other MSs which have never receive the packets, since the source
interface is actually connected to an 802.16 link layer. As I understood,
the question starts from here; why doesn't 802.16 link layer support uplink
multicast/broadcast? Then, which entity could handle this?. Anyway it has to
be specified.

There must be various feasible solutions. Regarding per-MS(service flow) IP
tunnel, the tunnel end point may differentiate the source MS. I'm not sure
that there has ever been a firm resolution made. Whatever the
solution made, it should be transparent to IP/ETH layer. Moreover, the
link-layer performance in terms of air bandwith efficiency is also
important.

Best regards,
Jihoon


2007/1/14, Qiang Zhang <[e-mail]>:
>
>
> Hi All,
>
> Physical layer UL/DL multicast or multiPackets should not be confused with
> the access network multicast which can go across multiple cells managed by
> one ASN, I think there should be no restriction for the design to
> incorporate the IP or Eth level multicast initiated from  the ASN after
> receiving a IP multicast packet from the MS, am confused why can't the ASN
> also broadcast/multicast back to the same cell the MS is residing if you can
> clarify
>
> Qiang
>
>  On 1/13/07, Jihoon Lee <[e-mail]> 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.16backhaul (WiMAX ASN) may multicast/broadcast at ETH or IP layer.)
> >
> > I agree that the document needs to specify how to deal with this
> > problem.
> >
> > Best regards,
> > Jihoon
> >
> >
> > 2007/1/12, Alexandru Petrescu <[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