Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1]

Alex,

Inline:

On 1/12/07 1:16 PM, "ext Alexandru Petrescu"
<alexandru.petrescu@motorola.com> wrote:

> Basavaraj Patil wrote:
>> Alex,
>> 
>> 
>> On 1/12/07 12:07 PM, "ext Alexandru Petrescu"
>> <alexandru.petrescu@motorola.com> wrote:
>> 
>>> Basavaraj Patil wrote:
>>>> Hi Alex,
>>>> 
>>>> On 1/12/07 5:06 AM, "ext Alexandru Petrescu"
>>>> <alexandru.petrescu@motorola.com> wrote:

>>> Let's then discuss the RS method for quick movement detection.
>>> 
>>> Do you agree that (1) an SS can't multicast an RS because 802.16e
>>> IPv6CS doesn't support ul multicast?  and that (2) there's no means
>>>  for SS to unicast the RS because it doesn't know the BS's
>>> link-local address because no message in the network entry
>>> procedure delivers BS's link-local address?
>> 
>> Why do you need UL multicast capability in order to send the RS?
> 
> Because a multicasted RS is sent to a multicast address, and that is
> uplink towards BS.

When the MS sends the RS to the all-routers multicast address, the 802.16
sends this packet as it does any other IPv6 packet via the transport
connection  that has been established previously on the uplink. The host at
the IPcv6 layer does not need to know the BS' link-local address or even its
existence in this case. The RS that is carried via the transport connection
is delivered to the BS which forwards it to the AR (via an L2 tunnel if
required) and note that the BS does not even look at the IPv6 packet. It
simply forwards the payload coming on a specific CID to an L2 tunnel which
results in the RS now arriving at an AR.
If you are thinking that the MAC in the host will convert the all-routers
multicast destination address to a BS' link local address or any such thing,
then you are mistaken. It does not work that way.

> 
>> Once the IPv6 link has been established between the MS and the AR (a
>>  PtP link BTW in the context of this I-D), the MS can send an RS to
>> the all-routers multicast address.
> 
> The AR to be part of that all-routers multicast address it must have
> joined that group (MUST in 2461 6.2.2).  How does AR join a multicast
> group at 802.16 MAC level?

It does not join the multicast group at the .16 MAC level.

> 
> Is it by sending an MLD report?  An MCA-REQ/RSP telling all SSs?  Is it
> by configuring a implicit filtering rule in its database?  Is it by not
> joining that group at all and assuming that on that ptp link it will see
> all peer's packets?

On the PtP link it will see all the peers packets.

> 
>> I don't see any problem with the MS sending an RS at all once the
>> IPv6 link is up (implying a PtP connection between the MS and AR).
> 
> Well, I've configured something similar: "multicast" RS/RA over tunnel
> ptp interfaces.  It works.  Doesn't mean it's conforming or agreed.

So you agree that it works.  Good.

-Raj

> 
> Alex
> 

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