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

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Fri, 14 Sep 2001 12:56:30 -0500

>In the case of BETH, if nAR doesn't support BETH, then it will use
>the standard Johnson and Perkins algorithm, by which nAR will advertise
>a RtAdv when the MN is already on the new L2 and the MN will respond 
>when the RtAdv is received. Note that performance here may not be
>particularly fast if the RtAdv is periodically sent. 

The MN need not wait for the RtAdv. It can solicit it. So you can
improve performance to some extent that way.

>If the nAR uses an L2 trigger rather 
>than a timer to send the RtAdv, it can catch the MN as soon as L2
handover is 
>complete. If the MN receives an L2 trigger, of course, it may choose to
wait 
>until the nAR sends the RtAdv rather than soliciting if it has a real
time 
>stream, because it doesn't know, a priori, that the nAR doesn't support
>BETH. The stream may then get disrupted if the MN doesn't receive
>the RtAdv quickly enough.

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.

>In the case of FMIPv6, pretty much the same thing will happen, except
>if the MN gets an L2 trigger, it will start the process of L3 handover
>when it gets the L2 trigger rather than waiting. If the MN doesn't
>get an L2 trigger, and the nAR does timer-based route advertisement,
>the same kind of disruptions in the real time stream will occur.

The fallback of the FMIPv6 scheme in case of trigger failures etc. is
the standard Johnson/Perkins algorithm. There is not much you can
really do. And trying to synchronize your L2 and L3 handoffs via
triggers etc. is not exactly the easiest thing done.

>These cases assume that the oAR does nothing to inform the MN prior
>to the handover that a handover is coming up. 
>Performance would probably benefit by allowing the oAR to signal the MN
>when it is still on the oAR that a handover to a nonFMIPv6/nonBETH
>capable node is pending. 

Most cases the L2 HO will have already occured and the oAR will have
no means of telling the MN anything. 
If the MN sends a PrRtrSolicit to the oAR (assuming a Mob. Initiated
HO via some trigger in the MN) and the oAR has no knowledge
about the capabilities of the new AP/AR that the MN is indicating in
the PrRtrSolict, the oAR may not even be able to respond to the
solicit before the MN completes the L2 HO. 

>This would allow a MN that is using either
>algorithm to revert to the standard Johnson and Perkins algorithm
>for movement detection, according to its ability to receive
>an L2 trigger. If the MN receives an L2 trigger, it can send
>a SolRtAdv as soon as it is on the nAR, if not, it must wait
>until the RtAdv is sent from the nAR. 

The L2 movement detection (or change of AP) and it's use via triggers
to cause a RtrSolicit is something that the MN should do anyway to
proactively determine movement detection and the AR that it is
connected to. This is something that can be done with the MIPv6 spec
as is without having to do anything with FMIPv6. 

>A good place to add support for this would be the PrxyRtAdv. The 
>PrxyRtAdv currently has three codes, we could add one like:
>
>	2 - Handover to nonFMIPv6/nonBETH capable AR pending
>

If the MN is going to HO to an AP/AR that is not in the HO domain of
the oAR, it probably has no idea of the MNs intent to HO and is
incapable of sending the PrRtrAdv. It has to be Mobile initiated. 
Can you elaborate on a viable scenario where this message would be
required?
	
>This would be sent when the oAR has knowledge of the capabilities
>of the nAR, to allow MNs to optimize handover as much as possible.

The oAR can know the capabilities of the nAR only if the MN tells it via
the PrRtSolicit. Unless your triggers and timing are synchronized the
MN could be gone. However the spec may be able to use a NAK to the
PrRtSolicit to say no HOs are possible to the AR specified in the
PrRtrSolict. But I guess that's what you are suggesting.

>Of course, if nAR doesn't have such knowledge, it could send
>a 128 (New attachment point unknown), indicating the MN is basically
>on its own.

Exactly. Just keep it simple. I think we are saying the same thing to
some extent in this thread.

The point is how closely are you or can you synchronize your L2/L3 HOs
via triggers. It may be better to keep the solution relatively simple
and rely on the fallback algorithm.

>		jak
-Basavaraj

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 14 Sep 2001 15:07:35 -0700

Hello folks,

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

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 ?

Regards,

-Rajeev