[16NG] Re: multicast and IPv6 over ETHCS

"Jihoon Lee" <jhlee@mmlab.snu.ac.kr> Tue, 16 January 2007 00:11 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6bvU-00085O-38; Mon, 15 Jan 2007 19:11:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6bvT-00085J-CZ for 16ng@ietf.org; Mon, 15 Jan 2007 19:11:43 -0500
Received: from an-out-0708.google.com ([209.85.132.241]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6bvS-0004Kc-UH for 16ng@ietf.org; Mon, 15 Jan 2007 19:11:43 -0500
Received: by an-out-0708.google.com with SMTP id d30so487603and for <16ng@ietf.org>; Mon, 15 Jan 2007 16:11:42 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ndhH4dh9gsNBtmIIiAnjwciHVVwZaTUdeYsevsY3PNIyVQbEFmTVNJYbZJWfdrFDMC52O1PZWGmI9sKm2SnsW6q3XQwCR6xfn8UFllD/Fv8KFaELXBO+5MiVBGm3F5SfTG8Dh+ECyGnO9jclj+K57BuGmwzDe2YrR8VhSkK9F5I=
Received: by 10.65.188.4 with SMTP id q4mr6685118qbp.1168906302147; Mon, 15 Jan 2007 16:11:42 -0800 (PST)
Received: by 10.65.225.19 with HTTP; Mon, 15 Jan 2007 16:11:42 -0800 (PST)
Message-ID: <fa31afde0701151611o73352694j69dd2e994b31636e@mail.gmail.com>
Date: Tue, 16 Jan 2007 09:11:42 +0900
From: "Jihoon Lee" <jhlee@mmlab.snu.ac.kr>
To: "Alexandru Petrescu" <alexandru.petrescu@motorola.com>
In-Reply-To: <45AB7268.7020609@motorola.com>
MIME-Version: 1.0
References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A54ED7.9020203@motorola.com> <45A67293.6030504@motorola.com> <fa31afde0701111703x9beb44axd1c8d9ff9a537983@mail.gmail.com> <45A76EC4.7070304@motorola.com> <fa31afde0701130744r2e8486b6rd1a291f938a57785@mail.gmail.com> <45AB7268.7020609@motorola.com>
X-Google-Sender-Auth: 171f5d877fd8fa93
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac
Cc: v6ops@ops.ietf.org, 16ng@ietf.org
Subject: [16NG] Re: multicast and IPv6 over ETHCS
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0131461756=="
Errors-To: 16ng-bounces@ietf.org

Hi Alex,
I agree with that.

Thanks,
Jihoon




2007/1/15, Alexandru Petrescu <alexandru.petrescu@motorola.com>om>:
>
> 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 <alexandru.petrescu@motorola.com
> > <mailto:alexandru.petrescu@motorola.com>>:
> >
> > 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
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng