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

From: James Kempf <[email-masked]>
Date: Mon, 17 Sep 2001 13:36:00 -0700 (PDT)

Hi Rajeev,

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

OK, I'll see what I can do.

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

Right, and normally that would be the case. But the scenario is that
the MN is doing BETH, and in BETH the RtSol is suppressed since
the network is handling the handover. If network handover fails,
due to the MN running off the end of a BETH coverage area, then
unless there is a signal that the MN is running off the end, it
will just wait until the RtAdv occurs, because it doesn't know
to solicit.

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

But from the cellular viewpoint, the MN doesn't see the AP. It's the
stratified stack: the RAN protocol (even if it's all IP!) is hidden from
the MN's stack. So most cellular systems will appear as if the AP
and AR are integrated.

I think the only real AP/AR deployments that matter are WLAN: 802.11
primarily. Not sure about HiperLan or Bluetooth. 

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

There are some hypothetical examples in draft-manyfolks-l2-mobilereq-00.txt.
Perhaps we need to get a few from the CDMA world as more concrete examples?

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

Yes, that's correct. The whole *point* of BETH is to eliminate the
radio MIP signalling for L3 handover until either: a) the MN is prepared
to pay the cost (i.e. it slows down, there is no real time traffic, etc.),
or: b) The network can no longer support the tunnel. The latter
includes the case of the MN running off the edge of the BETH coverage
area.

>That means
>sending ProxyRtAdv with appripriate code is a necessity for BETH ?

It is a further optimization that I think would be helpful. If the
PrxyRtAdv with code is not sent, then the MN will simply wait
on the new AR until an unsolicited RtAdv shows up and then do
L3 handover (see below). The PrxyRtAdv optimizes this by allowing
the MN to proactively perform L3 handover rather than waiting.

>If yes, this
>is not a corner case anymore.
>

What I meant was that the MN running off the edge of the coverage
area and standard FMIPv6 is not implemented at the new AR.  I think
that most ARs will at least support FMIPv6. If the new AR does,
the old AR can simply send the PrxyRtAdv to the MN, and the MN will perform
a standard FMIPv6 handover (even if it was doing BETH in the
BETH coverage area).

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

Then it *must* begin the process of L3 handover, to establish a new 
CoA at the new AR. An unsolicited RtAdv is an indication from the
AR that it is no longer prepared to maintain the bidirectional edge
tunnel, and so the MN must establish a new CoA.

Does that make sense?

		jak

---

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

Hello James,

thanks for the reply. I would like to summarize this discussion.

1. the MN need not be aware that the ARs support BETH. When this is the case, the
MN waits for an RtAdv on a non-BETH router.

2. the MN may be made aware that the AR it is handing over to is a non-BETH
router. This could be done via an extension to PrRtAdv.

3. On a BETH AR, unsolicited Router Advertisements must be disabled, at least
until the BETH session is over.

I don't see how a MN can continue sending packets using it's old CoA if it does
not know that the new AR is a BETH AR. I mean it could send packets with old CoA,
but they are prone to be discarded due to ingress filtering by the new AR. In
other words, it *needs* to be informed about the BETH-ability of the new AR, one
way or the other.

In any case,  I see the following requirements.

R1. Due to 1), the MN is required not to send RtSol when it establishes a new
link.
R2. Due to 2), a L3 message over the air interface is needed.
R3. Due to 3), unsolicited router advertisements cannot be multicast to all-nodes
multicast address. They need to be sent only at the termination of a BETH session
to each MN.

To me R1 is undesirable. You would need this requirement in all the MNs.
R2 of course means bits spent over the air interface; however, this seems
inevitable.
I don't see issues with R3 other than defining new method to deliver RtAdvs.

Is this accurate ? If yes, could you add it to the current BETH proposal ?

Regards,

-Rajeev