Subject: RE: [mobile-ip] New BETH Draft

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Sat, 15 Sep 2001 10:47:04 -0500

Hello Rajeev/James/Alper:
Sorry for jumping in the middle.
Please find my inline response.
regards,
ajoy 

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Friday, September 14, 2001 7:34 PM
To: James Kempf
Cc: [email-masked]
Subject: Re: [mobile-ip] New BETH Draft

Hello James,

I am seeking some clarifications below (at the end) regarding when a MN sends
RtSol and what does it do with RtAdv on the new AR. Your responses are
appreciated. I also have some comments below.

Regards,

-Rajeev

James Kempf wrote:

>
> If the MN is doing BETH and it moves to a router where there is no
> BETH, the MN may be delaying L3 handover and so it will wait for
> the RtADv. If the old AR can tell it beforehand that it will move
> to a new AR without BETH, the MN can begin FMIPv6 handover (if
> the new AR supports FMIPv6) or it can know to stop doing BETH
> and do RtSol on the new router.

I guess my point was there is no reason for the MN to wait for RtAdv in any
case. For instance, the Linux IPv6 MN that we have has the hook to send out a
RtSol as soon as an interface becomes enabled (i.e., when the MN undergoes
AP handover). One could call this type of a hook an L2 trigger and that is
implementation-specific.

ajoy-> I do not think the example of Linux Mobile/IP is appropriate here.
I do not think if Linux does some way, we should write the spec according to 
that. Here we are talking about enabling Voice over IP for wireless user,
which will require different treatment from the way Mobile/IP was 
implemented for purely non-real time data traffic. 

>
>
> > A MN can detect a new link being made
> >available and react to it by sending the RtSol. An AR, which could be
> >connected via an AP, may not be able to get a trigger from the AP without
> >support from a variety of link types connecting the AP with the AR.  I
> >think this is an issue to be addressed when relying on link-layer triggers.
> >When we speak of a trigger between the MN and AR, it is really two
> >triggers: between MN and AP and AP and AR.
>
> That is for a particular implementation which happens to be common
> right now for a particular radio protocol. It is by no means the
> common to all radio protocols, and even in the protocol for
> which it is currently common, it is likely to change.
>

Well, the other scenario you are referring to is not common either, right ? In
fact, I would argue that having an integrated AR-AP device would be a special
case for which we have limited experience currently. Today, both WLAN and
cellular have this model: there is a separate link between the AP and an AR.
I would guess that such a model would continue to exist.

-> I do not think getting link layer trigger at AR is difficult in case of 
existing cellular network. In fact such work is in progress in 
3GPP2. I am positive this can be done in 3GPP,
provided 3GPP decides to use Mobile/IP. 

>
> >Practical deployments, at least
> >today, realize the AP-AR link by a variety of means. It is non-trivial to
> >come up with a trigger for each of the possible link types connecting AP
> >and AR. Or, may be not. I am open to hear arguments. When an AP and AR are
> >"integrated", perhaps this issue is less relevant.
> >
>
> Agree, though I think it might be more straightforward than you think
> to come up with triggers. I think they are already there in CDMA,
> for example.
>

Ok. Would it be possible to clearly specify what a link-layer trigger
constitues (e.g., it could actually span more than one link type) and some
examples ?

>
> >I also have a question: what would be the response of a MN which is within
> >a BETH session when it gets a link-layer trigger ? Would it be required not
> >to send a RtSol ?
> >
>
> The MN would only be required to send a RtSol if it had been informed
> ahead of time on the old AR that it was moving out of a BETH
> coverage area. This is why I proposed adding a code to the PrxyRtAdv,
> so that the old AR could do this. Otherwise, the optimization
> of BETH provided by lack of any L3 MIP signalling would be invalidated.

So, it is requirement for the MN *not* to send a RtSol if it was moving into a
BETH router then ? For this to happen, the MN must be informed a priori by old
AR that the MN is moving into a BETH router as you point out. That means
sending ProxyRtAdv with appripriate code is a necessity for BETH ? If yes, this
is not a corner case anymore.

-> I think this is a corner case. Could you please provide any realistic example where 
MN can move from BETH capable AR to nonBETH capable AR in same technology ? I am having hard time
to imagine any scenario where we need seamless handover from one AR to other without
any prior agreement between neighboring ARS. Please note that this argument can be
made for any access protocol. For example, please find a few:

What happens when MN moves from AR which supports PPP to the 
AR which does not support PPP ? What happens if PPP unaware MN
tries to connect to non-PPP aware AR ? ....

Regards,

-Rajeev

>                 jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 18 Sep 2001 16:18:12 -0700

Hello Ajoy,

> implemented for purely non-real time data traffic.

Well, going by your own argument, writing a spec based on your favorite application is also not
appropriate, I guess.. The point of bringing up the example above was a *link-layer* trigger could
be implemented, potentially in any civilized OS, to solicit router advertisements.

> provided 3GPP decides to use Mobile/IP.

Ok. What do you have to say about the link between the AP and the AR ? What link type is used there
? If I choose to use ethernet, I have to figure out how to send a trigger to the AR in response to
the trigger from the MN, right ?

> made for any access protocol. For example, please find a few:

The point here is that the MN needs to know what type of an AR it is moving into. Even if you have
the same technology on the two routers, does that constitute a binding requirement that the target
AR is also a BETH AR ? What if it belongs to a different operator ? Furthermore, after being
informed about the target AR, the MN has to abstain from sending out Router Solicitations as soon as
the new link is established. This is a requirement on the MNs to implement.

I don't have any problem with optimizations. Their implications, however, have to be clearly defined
and made known.

Regards,

-Rajeev