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

From: James Kempf <[email-masked]>
Date: Fri, 14 Sep 2001 16:59:20 -0700 (PDT)

Hi Rajeev,

Again, as I mentioned in my email to Alper, the case we are discussing
here is one in which the MN runs off the end of the BETH coverage
area. The MN's current AR either knows that the new AR does not
support FMIPv6 or BETH, or it does not know what the new AR supports.
The latter case, IMHO, is a misconfiguration and should be corrected.

>> According to BETH the MN will not know if a handover is occuring in
>> the network at any time. So it would be too much to ask the MN to NOT
>> react to an L2 trigger by sending a RtAdv solict right away. The MN
>> has no idea if the ARs support BETH at any given time.
>>
>
>I agree with Raj that it would be easier for the MN to send a RtSol rather
>than for the AR to catch the MN.

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.

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

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

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

		jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 14 Sep 2001 17:33:43 -0700

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

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

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

> to come up with triggers. I think they are already there in CDMA,

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 ?

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

Also, what happens if the MN receives an unsolicited RtAdv on the new AR when
it is in a BETH session ?

Regards,

-Rajeev