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

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:
>> 
>>> Periodic RA is in widespread use for movement detection.  I do not
>>>  understand the opposition to use periodic RAs as allowed by
>>> rfc3775. What breaks if we use periodic RAs with a frequency higher
>>>  than 1/4s? (remark arguments of air interface gains are different
>>> on high-bandwidth links).
>> 
>> The fact is that sending periodic RAs on an air interface
>> irrespective of BW capacity is suboptimal. A host in Idle mode is not
>>  listening for periodic RAs. Listening for periodic RAs would prevent
>>  the host from transitioning to idle mode which has an adverse impact
>>  on battery life. 802.16 has defined paging and Idle mode support. In
>>  air-interfaces that do not support such capability, sending of very
>> frequent RAs is possible but IMO still not the most efficient usage
>> of the bandwidth. In licensed spectrum the optimization and
>> efficiency of the air interface is critical. Periodic RAs are
>> unavoidable at this time. The best that we can do without breaking
>> backward compatibility is to send it with large time intervals as the
>>  I-D suggests. Movement detection can be done be accomplished by
>> other means. If the host is only relying on RAs for movement
>> detection (at the IP layer), then it could just as well send a Rtr
>> solicitation. This is not prevented.
>> 
>> In Unlicensed spectrum you may have a bit more liberty about how the
>>  air-interface is used but even in those cases, optimizing it is a
>> better choice.
> 
> Raj, I understand a strong pushback from you about having periodic RAs
> with less than 4s.  I think it's not motivated.
> 
> 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?
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.

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).

-Raj

> 
> What do you think?
> 
> Alex
> 

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