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

From: Basavaraj Patil <[email-masked]>
Date: Fri, 12 Jan 2007 14:17:43 -0600

Alex,

Inline:

On 1/12/07 1:16 PM, "ext Alexandru Petrescu"
<[email-masked]> wrote:

> Basavaraj Patil wrote:
>> Alex,
>> 
>> 
>> On 1/12/07 12:07 PM, "ext Alexandru Petrescu"
>> <[email-masked]> wrote:
>> 
>>> Basavaraj Patil wrote:
>>>> Hi Alex,
>>>> 
>>>> On 1/12/07 5:06 AM, "ext Alexandru Petrescu"
>>>> <[email-masked]> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/16ng

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Jan 2007 22:19:56 +0100

Basavaraj Patil wrote:
>>>> 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?
>> 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.

Yes, I'm thinking the IP-multicasted RS should be addressed to a
link-layer multicast address.  The 802.16MAC does have 48bit MAC
addresses, so supposedly it has 48bit _multicast_ MAC addresses too.

>>> 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?
> 

Well, this is against, or over-riding, 2461 6.2.2.  That section says
the router must join.

>> 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?
> 

Yes.

>> Well, I've configured something similar: "multicast" RS/RA over
>> tunnel ptp interfaces.  It works.  Doesn't mean it's conforming or
>> agreed.
> 

Yes, I agree that it works and that it's not specified.

Alex