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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 13 Sep 2001 10:44:06 +0200

Rajeev, 

Is there any scenario in FMIPv4 or FMIPv6 that does not
rely on triggers? I don't think BETH is unique here. 

Hesham

> > As agreed upon in London, unless there are any further changes needed,
> > I'd like to move forward with Gopal on incorporating the draft
> > into the body of draft-ietf-mobileip-fast-mipv6-02.txt.
> >
> 
> I have some concerns with this. As I understand, please correct me if I am
> wrong, BETH
> relies on link-layer triggers to establish the bi-directional tunnel. The
> link-layer triggers are
> 
> - not standarized. Who will do the standardization ?
> - not implemented (I guess since there is no standard). Any comments ?
> 
> Given this dependence, having BETH as a part of FMIPv6 raises the following
> issues
> 
> - how can we implement FMIPv6 with BETH ?
> - how can we test inter-operability ?
> 
> So, I feel that FMIPv6 should contain enough specification that can become a
> standard without depending on link-layer trigger standardization to succeed. We
> are keen on moving FMIPv6 along, and would welcome new ideas that would improve
> the protocol. However, items that would require standardization of their own
> should perhaps be part of a separate document, and (still) be recognized in the
> FMIPv6 specification.
> 
> Comments ?
> 
> 
> Regards,
> 
> -Rajeev
> 
> 
> 
> 
> >
> >                 jak

---

From: James Kempf <[email-masked]>
Date: Thu, 13 Sep 2001 16:22:41 -0700 (PDT)

Hi Rajeev,

>thanks for your comments. I guess was not clear enough in separating the 
concerns
>regarding link-layer triggers. I suppose you can identify two kinds. First, in
>response to an existing L2 event, one could generate a trigger internally to 
effect
>a L3 action. For instance, an implementation may generate Proxy Router 
Solicitation
>in response to scanning and detecting a new AP that the MN wishes to connect 
to.
>This is internal to a host, such as a MN, and I guess this is what Pat was
>referring to. Second, a new Layer 2 trigger (message ?) between two different
>entities (such as a MN and an AR) could also be defined. But, this would 
perhaps
>require standardization. This latter form of a trigger is perhaps needed to
>indicate, e.g.,  that a MN has moved away from an AR. [In shared media, are 
there
>link triggers available to indicate termination of link connectivity ?  Also, 
in
>dedicated links, an AP may know that a MN has terminated link connectivity, but 
a
>new trigger is still needed between the AP and the AR (in the general) case to
>indicate to the AR of the MN's movement]
>
>So, my concern is regarding those kinds that require standardization. Would it 
be
>possible to clearly identify those triggers that are implementation-specific 
and
>those that require standardization ? If BETH has only implementation-specific
>triggers, that would be fine.  However, it has to be clearly identified and 
stated.
>It must also identify what triggers need standardization of their own, if any.
>
>Hope this is clearer.
>

I think this depends on the particular radio protocol and how it
is implemented. In CDMA protocols, the MIP AR will probably
see the trigger as a platform specific API event, since the APs
are basically hidden by the RAN protocol. In 802.11 systems where
the AR and AP are in the same box, this will likely be true as
well. These kinds of systems are not very common today for 802.11.

So the main issue is when there are bridging APs and a wired subnet
between the AP and AR which is not opaque at L3 like a CDMA RAN is.
This is the common deployment situation with 802.11 today,
maybe Bluetooth as well? In that case, some standardization of a protocol 
between the AP and AR to allow the AP to transfer trigger information 
to the AR would be appropriate.

One possibility is to look at extensions to the IEEE IAPP (InterAccess
Point Protocol) for 802.11 (I think it is designated 802.11/f). 
Bernard Aboba recently published a draft that does something similar
for context transfer of RADIUS context (draft-aboba-802-context-01.txt).
Bernard used  an extensiblity feature of 802.11, perhaps we could do
the same. If not, we should start talking with IEEE about what we need.
The standard is not yet finished, last I heard, so there is time.

		jak

---

From: James Kempf <[email-masked]>
Date: Thu, 13 Sep 2001 13:23:43 -0700 (PDT)

Hi Raj,

>During the design team discussions we recognized the need for L2
>triggers and the importance of those which makes fast handoffs
>possible. However we agreed to keep working on the L3 details and
>take an abstract view of the L2 dependencies and triggers. We
>expected that this work would be taken up at some time in the
>future either in the MIP WG or elsewhere. 
>I think what Rajeev is questioning is the validity of the solution from
>an implementation perspective. To truly make the fast handoff solution
>interoperable we need to define a set of triggers (to<->from) the lower
>layers. I think the manyfolks draft is a good start in this direction. 
>The abstractness of L2s on the fast handoff solution cannot be ignored
>for too long. We can stick our heads in the sand and pretend that it 
>does not cause any impacts to the L3 solution. But when you start 
>dealing with implementing the spec you are bound to run into these
>issues.
>

Agree!

We're working on some  "proof of concept" for L2 triggers and 
low latency MIPv4, and ultimately I'd like to extend the work
to FMIPv6. Hopefully that will flush out some issues. But there is definitely 
the need to work with some real L2 protocols and see  what can
be done about supporting the kind of triggers needed for
high performance MIP handover.

		jak
		
>However I see no reason for not including BETH in the current FMIPv6
>draft. I think the BETH solution should be added as another way of 
>accomplishing fast handoffs. But the spec is incomplete without there
>existing ways and means to interact with the lower layers. 
>I think the sooner we tackle this problem, the faster we can get some
>real implementations that can interoperate.
>

---

From: Alper Yegin <[email-masked]>
Date: Thu, 13 Sep 2001 16:02:56 -0700 (PDT)

> rely on triggers? I don't think BETH is unique here. 

Hesham,

We should still distinguish among different triggers though. For example FMIPv6 
can operate even if the only triggers available are on the Mobile Node. On some 
links, such as WLAN, some of the AR side triggers might not exist, e.g. LINK 
DOWN. And this effects the availability of BETH to those networks.

FMIPv6's reliance on the L2 triggers is less than that of BETH.

But of course, as James said, one should use BETH only if they have support for 
these triggers.. If they don't, they can't. That simple.

alper

> > should perhaps be part of a separate document, and (still) be recognized in 
the

alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 13 Sep 2001 16:46:19 -0700 (PDT)

Hi Jim,

Right before the last IETF we had discussed how handoff would work when nAR 
doesn't support the BETH protocol.

I think you have added section 2.5.3 Failure of BET Handover to address this 
issue, right?

I have a question on how this works:

	If the candidate cannot support BETH, then the current AR
	should initiate FMIPv6 handover if the candidate supports it, or, if
	the candidate AR does not support FMIPv6, simply allow the MN to do
	movement detection according to the original Johnson and Perkins
	algorithm.
	
If the nAR doesn't support neither BETH nor FMIPv6, then how is MN supposed to 
detect this and proceed with a stock handoff? 

I think it would be useful to have a section that describes MN behavior, 
especially under these different cases.

Cheers,

alper

---

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Thu, 13 Sep 2001 13:42:02 -0500

Hi James,

-Basavaraj

> Responses in line.
> As you know, there is a draft ongoing that is working toward defining
> abstract triggers.  These naturally need to be implemented 
> for specific
> link layers, but the whole point of making them abstract is to 
> remove the fast handoff specification from dependence on a specific
> link layer. Naturally, it is up to specific groups that control
> link layer specifications to work toward standardizing the triggers
> for their link layers. As Pat pointed out in his response, a 
> system vendor
> may choose to implement the triggers as events on a 
> particular platform
> instead, in which case, there would be no interoperability 
> implications.
> 
> As Hesham has pointed out, the current FMIPv6 spec has an 
> implicit dependence
> on link layer triggers. How would an AR know to send a PrxyRtAdv or an
> MN to send a SolPrxyRtAdv without some kind of information from the
> link layer that a handover was pending? The BETH spec has made these
> dependencies explicit, and has used the abstract trigger 
> formulation to
> make them independent of a particular link layer. In the low latency
> MIPv4 spec, this approach was taken from the beginning. From 
> an engineering
> standpoint, IMHO making the need for triggers explicit and outlining
> how they might work seems more likely to result in successful 
> implementations.
> It does not mean that every link layer must support all the triggers,
> nor that every link layer must support BETH. It is possible that some
> link layers won't have the proper kinds of triggers, in fact, some
> may not even be able to support the base FMIPv6 spec for that reason.
> If the need for triggers is called out in the spec, an implementor
> can make a quicker decision about whether or not their link layer
> and system platform supports the right ones, and, if not, work with
> the right standardization bodies and their system vendor to assure
> that the link layer triggers are available.
> 
> So, I guess I don't see a real problem. There seemed to be strong
> concensus in London for including BETH in the base spec at this
> point, I think we should move forward with it.
> 
> 		jak
>

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 14 Sep 2001 16:08:11 +0200

> DOWN. And this effects the availability of BETH to those networks.
	=> Of course, the triggers are in the MN or the AR depending on the 
	type of radio that you have. But they are all triggers based on L2
	events. So I guess we're saying the same thing. FMIPv4/6 relies 
	on these triggers for all scenarios. Network initiation or MN initiation
	is independant.

> FMIPv6's reliance on the L2 triggers is less than that of BETH.
	=> It is actually a third scenario in FMIPv6, the reliance on 
	triggers is identical to the case where the AR sends Pr_rtradv
	I don't see why you say that. The difference here is that the MN
	doesn't know, which is something we can debate, but anyhow
	this is not the issue on this thread. 

> these triggers.. If they don't, they can't. That simple.
	=> Exactly, but it's the same scenario for the case where the 
	AR sends an unsolicited Pr_rtr_adv. I don't see the difference.

	Hesham

---

From: James Kempf <[email-masked]>
Date: Fri, 14 Sep 2001 09:19:23 -0700 (PDT)

Hi Alper,

>I think you have added section 2.5.3 Failure of BET Handover to address this 

Yes, that's correct. 

>detect this and proceed with a stock handoff? 

Good question, but this isn't specifically an issue with BETH. What
happens if the current AR supports stock FMIPv6 and the new AR
doesn't? This issue isn't covered in the FMIPv6 draft.

>especially under these different cases.

Agree.

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

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.

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

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

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.

		jak

---

From: Alper Yegin <[email-masked]>
Date: Fri, 14 Sep 2001 11:26:56 -0700 (PDT)

Hesham,

I was comparing FMIPv6 and under what minimal L2 signals it can work, vs BETH 
and its L2 signal requirements. But thinking BETH as one of the cases under 
FMIPv6 umbrella, I agree with your points.

alper

> X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to 
[email-masked] using -f
> To: "[email-masked]'" <[email-masked]>
> Subject: RE: [mobile-ip] New BETH Draft
> MIME-Version: 1.0
> List-Archive: <http://playground.sun.com/mobile-ip/>
> List-Owner: <mailto:[email-masked]>
> List-Subscribe: <mailto:[email-masked]?body=subscribe>
> List-Unsubscribe: 
<mailto:[email-masked]?body=unsubscribe> Alper, 
> > > > standard without depending on link-layer trigger standardization to 
succeed. 
> > We
> > > > should perhaps be part of a separate document, and (still) be recognized 
in 

alper

---

From: James Kempf <[email-masked]>
Date: Fri, 14 Sep 2001 12:08:35 -0700 (PDT)

Hi Raj,

I guess my original  email wasn't very clear, sorry. Responses below.

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

Agree. The issue here is that, if the MN doesn't know that it is
being handed off to an AR that can't do FMIPv6 and can't do 
BETH, it may try to optimize by doing BETH, and then it won't
solicit. That prompted the suggestion to inform the MN prior
to movement, via the standard FMIPv6 PrxyRtAdv, that it was
about to move into a nonFMIPv6, nonBETH coverage area, if that
fact is known  in advance of the handover.

>>If the nAR uses an L2 trigger rather 
>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.
>

Even if the MN is using BETH, at some point, it must solicit a RtAdv
or PrxyRtAdv and initiate L3 handover, so that it can get a new
CoA. If the MN gets an L2 trigger prior to or after handover, it
can use that to gate when to begin L3 handover, just as in FMIPv6
and standard MIPv6. If the MN does not get an L2 trigger, it will
simply solicit whenever its real time stream is done.

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

Agree in general, but I think you can warn the MN if the old AR knows what's
coming.

>And trying to synchronize your L2 and L3 handoffs via
>triggers etc. is not exactly the easiest thing done.
>

Well, the goal of the triggers is to provide timely and accurate
L2 sequencing information from L2 to L3, so as to optimize L3 handover.
If they don't achieve that, then they are of no use.

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

The oAR may know that a handover is coming, and it may even know
where, or, as you say, it may not. If it knows, it could potentially
send a PrxyRtAdv to the MN. Also, the MN may know that the handover
is coming.

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

Agree. This is the worst case.

>>This would allow a MN that is using either
>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. 
>

If the MN is doing BETH, then it will be supressing solicitation of
RtAdv in order to conserve radio bandwidth, so it would have
to wait for the nAR to send a RtAdv instead of soliciting. Maybe
not all that bad, but if the oAR knows where the MN is going,
it could tell the MN ahead of time to solicit.

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

Please see draft-ietf-seamoby-CARdiscovery-issues-00.txt. Seamoby
is working on a protocol to allow ARs to advertise their capabilities.
One such might be whether or not they support FMIPv6 and BETH. 
	
>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.
>

The CAR discovery draft outlines two possible ways an AR can discover
the capabilites, one that involves exchanging information over the
wired backbone and one that involves exchanging information via the MN.
The oAR can discover the capabilities of the nAR without the MN's 
involvement and inform the MN prior to handover.

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

Agree. The only point I'm trying to make is that, as with the entire
rest of FMIPv6, if the oAR has information about the capabilities of the AR 
where the MN is going, it is possible to optimize handover. It need not
depend on CAR discovery, the information could be statically configured,
but that is an example.

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

Not entirely sure what your point is here, since the L2 triggers are
just presenting sequencing information and parameters to L3, which
then uses them for optimizing handover. Of course, if the L2 information
is not there, it is not possible to do the optimization. This
is like any other optimization problem. Or am I missing something?

		jak

---

From: Alper Yegin <[email-masked]>
Date: Fri, 14 Sep 2001 11:26:56 -0700 (PDT)

Hesham,

alper

succeed. 
in 

alper

---

From: James Kempf <[email-masked]>
Date: Fri, 14 Sep 2001 09:19:23 -0700 (PDT)

Hi Alper,

Yes, that's correct. 

Agree.

	

		jak

---

From: Alper Yegin <[email-masked]>
Date: Fri, 14 Sep 2001 14:31:01 -0700 (PDT)

Hi Jim,

> doesn't? This issue isn't covered in the FMIPv6 draft.

PrRtAdv can indicate this. I am not sure if we have clarified this in the draft 
(therefore CC'ing the editor). Two-way communication between MN and the ARs help 
here. So, I don't see an issue for FMIPv6 here.

> when the RtAdv is received. 

But it's not standard that AR will send an RA as soon as a MN attaches. And this 
can't be accomplished by a requirement by BETH, because at least this AR is not 
supporting BETH.

I don't think you can rely on nAR sending RA or not sending to figure out BETH 
support on ARs.

Also, for any new message between the MN and the AR, I think you are diverging 
from your goal of zero latency, which relies on no-L3 traffic.

Note that FMIPv6 can get away without any L3 signalling on the new link. As both 
MN and nAR know each other's L2 identity, L2 attachment signal is enough get 
traffic going.

> Note that performance here may not be particularly 

> the same kind of disruptions in the real time stream will occur.

Actually I'm comparing FMIPv6 and BETH based on the same set of L2 triggers that 
BETH requires. BETH requires triggers on nAR to indicate arrival of MN. And in 
this case, FMIPv6 doesn't need any L3 signaling. (again, this wasn't clear in 
the FMIPv6 draft...note to the editor)

> for movement detection, according to its ability to receive

But again this L3 message on old (current) link will defeat the purpose of BETH, 
right? 

> a 128 (New attachment point unknown), indicating the MN is basically

Jim, my understanding is that the value of BETH comes from lack of L3 signalling 
on the air. You had a table in the version 1 that showed the latencies involved. 
I think the problem of BETH being partially deployed (not all routers are 
expected to deploy any particular method) yet handoffs should be still as fast 
can be fixed by using L3 messages. And I think this defeats the purpose.

What do you think?

alper

---

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

Hi Alper,

I've embedded responses below, but before I go to them, let's make
sure we are talking about the same thing. What we are talking about
is the following;

1) The MN is doing BETH supported by the network.

2) It comes to an AR that must hand it over to a new AR without support
for either FMIPv6 or BETH.

3) The current AR does not know that the next AR doesn't support
FMIPv6 nor BETH, so it cannot send a PrxyRtAdv to the MN, which
would trigger the MN to stop doing BETH and solicit a RtAdv on
the new AR.

4) As a consequence, the MN gets onto the new AR and must wait
until a RtAdv shows up from it.

Right? If so, IMHO, as I mentioned in the draft, this is likely to
be a corner case and the result of misconfiguration or lack
of use of CAR discovery, and so not very common. But it should
be covered.

Now, on to your comments.

>I don't think you can rely on nAR sending RA or not sending to figure out BETH 

MIPv6 isn't RFC yet. If we need to, we can ask Charlie to stick some words in it
about the AR optimizing RtAdv similar to the words about the MN optimizing
movement detection on pg. 80, and we probably should, not just for
FMIPv6.

>from your goal of zero latency, which relies on no-L3 traffic.

See discussion above. This is a corner case. When it happens, it
means the MN must terminate BET handover and start doing
standard MIPv6 handover (i.e. it cannot even do FMIPv6 handover).

>MN and nAR know each other's L2 identity, L2 attachment signal is enough get 

OK.

>the FMIPv6 draft...note to the editor)

The role of L2 triggers in FMIPv6 does need some clarification.

>But again this L3 message on old (current) link will defeat the purpose of 
BETH, 

Right, but there's no choice. The next AR can't do BETH anyway.

>can be fixed by using L3 messages. And I think this defeats the purpose.

As I mentioned above, we are talking about a particular corner case
when the MN runs off of the BETH coverage area. All bets are off
about performance. If the MN can't do BETH and it can't do stock
FMIPv6, it gets the same performance as standard MIPv6 handover.

		jak

---

From: Alper Yegin <[email-masked]>
Date: Mon, 17 Sep 2001 14:08:27 -0700 (PDT)

Ajoy,

Just a quick response to your point below...

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

Two same-technology wireless networks, which are physically adjacent to each 
other, doesn't have to necessarily deploy same mobility protocols. (speaking of 
IPv6) minimum requirement is to deploy an IPv6 access routers, and everything 
should work. Additionally, any combination of FMIPv6/BETH protocols can be 
deployed on each. 

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

Yes, for *ultimate* performance, deploying the same mobility technology on both 
sides (oAR and nAR) is a must. BUT, if any of the protocols, such as BETH as 
defined in draft v02, makes the performance of handoff to non-BETH networks 
slower than before, then this is a problem we should solve. The ideal is not to 
degrade such performance.

> Please note that this argument can be
> made for any access protocol. For example, please find a few:

A MN which supports base-MIPv6/FMIPv6/BETH should be able to hop around ARs that 
support any of these protocols. And ideally the performance shouldn't be no 
worse than pure base-MIPv6 protocol's.

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

alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 17 Sep 2001 14:24:30 -0700 (PDT)

Hi James,

> of use of CAR discovery, and so not very common. But it should

Reading this, I understand you are proposing adding a PrRtAdv to the protocol. 
This should be sent prior to MN detaching from old link. And it can indicate 
whether the Mn is going to handoff to a BETH supporting AR or not. Right? If so, 
this should help.

But this is not in the draft yet, right? Also, would you send this message all 
the time, regadless of whether nAR is BETH capable or not. I'd recommend so.

So, now answering your above question: yes, I agree this is a misconfig given 
that now we have such a message to inform MN.

> movement detection on pg. 80, and we probably should, not just for

Yes, we can think about that too. But unless I misunderstood, we are already 
accomplishing this by sending a PrRtAdv. MN already knows by the time it 
attaches to new link.

> standard MIPv6 handover (i.e. it cannot even do FMIPv6 handover).

If you add PrRtAdv, then you are adding latency.

> Right, but there's no choice. The next AR can't do BETH anyway.

Same question as above: are we going to always send a PrRtAdv to MN, or not?

> FMIPv6, it gets the same performance as standard MIPv6 handover.

If MN thinks BETH is going on and if this is not the case, since MN would hold 
on to sending RS (BETH says so, right?), the performance would be worse than 
base-MIPv6. Because, if MN had known, then it could send an RS and expedite the 
process.

A solution, if I understand right, is to send a PrRtAdv from oAR to MN. But now 
this introduces L3 latency. Then I think we should take a look at the 
performance gains over FMIPv6 again.

I think we should also look at other cases: BETH-enabled MN doing handoff from 
one non-BETH-AR to another non-BETH-AR. BETH-enabled MN entering back into a 
BETH domain..

And on another case is: what if MN is not BETH-enabled? How does BETH-enabled 
ARs treat them..

I think these are missing in the draft.

alper

---

From: James Kempf <[email-masked]>
Date: Mon, 17 Sep 2001 15:21:06 -0700 (PDT)

Hi Alper,

>whether the Mn is going to handoff to a BETH supporting AR or not. Right? If 
so, 

What I am proposing is that if the old AR knows that the new AR does
not support FMIPv6, it sends a PrxyRtAdv with a new code indicating
that. This benefits *both* a BETH capable MN and one that is doing
standard FMIPv6. If the new AR does support FMIPv6, of course, it sends a 
PrxyRtAdv with one of the existing codes. If the new AR doesn't
know what the new AR supports, it sends a PrxyRtAdv with code 255.
And finally, if the new AR doesn't even know that a handover is
coming nor where, we are out of luck and the MN must wait til
it gets to the new AR to discover that fact, regardless of whether
FMIPv6 or BETH is used.

>the time, regadless of whether nAR is BETH capable or not. I'd recommend so.

No it is not in the draft, but I will fold it in when I incorporate the BETH 
draft into the FMIPv6 draft. The message only gets sent if the new AR
is not BETH capable, otherwise, it compromises the optimization of
radio link traffic.

OK.

>accomplishing this by sending a PrRtAdv. MN already knows by the time it 

But consider exactly the same case where the MN is doing FMIPv6 instead of BETH,
new AR is not capable of doing FMIPv6, and the MN gets no trigger
information indicating when handover has occured but the AR does.
Even if the MN gets the PrxyRtAdv, it may come with code 255 or the
new code, indicating the new AR is unknown or that it does standard MIPv6 
handover.  The MN must then wait until it receives the unsolicited RtAdv before 
it can begin L3 handover. If the new AR sends the unsolicited RtAdv immediately 
upon L2 handover, the MN will start L3 handover more quickly. 

>If you add PrRtAdv, then you are adding latency.

Right, but this is *only* when you run off the edge of a BETH coverage
area. At that point, you have very little choice, and taking the
hit of a known amount of radio traffic delay in place of an unknown amount
if the MN gets to the new AR and must wait for the RtAdv is probably
a good bet.

>Same question as above: are we going to always send a PrRtAdv to MN, or not?

The answer is no. Only when the MN runs off the edge of the BETH
coverage area.

>performance gains over FMIPv6 again.

I agree. If the old AR knows the new one doesn't support BETH or FMIPv6,
it should tell the MN via the PrxyRtAdv. If the new AR supports BETH,
the old AR should send nothing.

>one non-BETH-AR to another non-BETH-AR. 

If the MN gets a PrxyRtAdv, then it knows not to use BETH. 

>BETH-enabled MN entering back into a 
>BETH domain..
>

If the MN does not receive a PrxyRtAdv from the network and it
detects an L2 trigger for handover, then it knows the network
is handling the handover. Provided, of course, the MN knows
that the network supports FMIPv6/BETH.

But you bring up another, wider issue: how does an MN know that the
AR is capable of doing FMIPv6 or BETH in the first place? For example,
suppose the MN wants to do mobile initiated FMIPv6 handover. Does it
just send off the SolPrxyRtAdv without any indication whatsoever that
the AR can perform FMIPv6, or does the MN receive some indication
beforehand that the AR is FMIPv6 capable? Similarly for BETH.

>And on another case is: what if MN is not BETH-enabled? How does BETH-enabled 

Like FMIPv6. FMIPv6 is the fallback case, if that isn't available, then
standard MIPv6.

>I think these are missing in the draft.

I need to look through it. Perhaps I need to add a section or paragraph
about fall back positions, and something is probably needed in the
FMIPv6 base draft as well.

		jak

---

From: Alper Yegin <[email-masked]>
Date: Tue, 18 Sep 2001 16:24:27 -0700 (PDT)

Hi James,

> standard FMIPv6. If the new AR does support FMIPv6, of course, it sends a 

I think this already exists for FMIPv6. Checking the draft, code 128 of PrRtAdv 
can be used for this case as well.

> >> MIPv6 isn't RFC yet. If we need to, we can ask Charlie to stick some words 
in 
> >it

With FMIPv6, if MN knows the new AR is not going to help with handoff, then MN 
can send a RS as soon as it attaches to that link. I think this is the fastest 
thing that MN can do under this circumstance. (are there any L2s that doesn't 
provide an "attached" indication to mobile side?)

> if the MN gets to the new AR and must wait for the RtAdv is probably

OK, I see. This PrRtAdv is only sent when MN is leaving the BETH domain.

But then I guess you'd need another message to inform MN when it is entering a 
BETH domain. So that it doesn't attempt FMIPv6 or MIPv6, and leave the handoff 
to ARs.

> The answer is no. Only when the MN runs off the edge of the BETH

I'd have preferred "receipt of a message" as the indication of whether next AR 
support BETH or not. Not receiving a message means it does. This message might 
be lost due to some other reason. ..  Now MN is waiting for its traffic, and ARs 
are doing nothing.

> If the MN gets a PrxyRtAdv, then it knows not to use BETH. 

But these non-BETH-enabled ARs don't have to send PrRtAdv. They can be simple 
IPv6 routers. I think MN should keep a state. As soon as it receives a PrRtAdv 
from a BETH-enabled AR, it should declare it's leaving BETH-domain. But then, at 
some point, it should also be able to detect moving into a BETH-domain. Maybe 
another message for that?

> that the network supports FMIPv6/BETH.

But MN doesn't know that. It just attached to a new AR. I think this AR should 
send a message to MN indicating MN is entering a BETH domain.

> beforehand that the AR is FMIPv6 capable? Similarly for BETH.

With FMIPv6, the response to PrRtSol indicates the support it can get from the 
AR. If AR doesn't recognize this solicitaiton, MN gets no response. Therefore no 
FMIPv6.

> Like FMIPv6. FMIPv6 is the fallback case, if that isn't available, then

yes, but how does AR know that MN doesn't support BETH? There's no two-way 
exchange of information between two. 

alper

---

From: James Kempf <[email-masked]>
Date: Wed, 19 Sep 2001 10:43:27 -0700 (PDT)

Hi Alper,

>can be used for this case as well.

I had something different in mind, namely refining the notification
from "Access Point Not Known" to "Access Point Known, but Does Not
Support FMIPv6". If the MN gets an L2 trigger, it could send
a SolRtAdv right away, as described in draft-ietf-mobileip-ipv6-14.txt
pg. 80. If the MN doesn't know what the Access Point is, it needs
to wait for the RtAdv. If knows the AP, it can solicit the RtAdv. This could
result in faster CoA establishment (though, of course, not nearly
as fast as FMIPv6).

		jak

---

From: James Kempf <[email-masked]>
Date: Wed, 19 Sep 2001 11:39:30 -0700 (PDT)

>> BTW, what do you think about letting the AR tell the MN whether
>> it is entering a BETH coverage area? This would allow the MN to
>> start performing BETH optimization, just as informing it when
>> it is leaving the coverage area allows it to stop performing
>> the optimization? If the MN wasn't capable of performing the
>> optimization, it would simply continue to do FMIPv6 handover.
>>
>
>This could be useful. I guess the AR would advertise that it supports BETH, 
perhaps
>through solicited RtAdvs.
>

Yes, that is what I had thought. 

		jak

---

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Wed, 19 Sep 2001 15:20:40 -0500

James,

Here's a scenario on HOs that I would like to get your opinion on what
happens w.r.t BETH:

BETH is a network initiated HO and as such the MN is kept in the dark
about the change in AR. Once a HO decision has been made the oAR
creates a Bi-directional tunnel between the oAR and the nAR. The MN is
not consulted at all. 
There may be scenarios where the MN may be capable of handing off to
another network (via another i/f). The oAR that the MN is currently
attached to is not aware of this network/AR as it may not be in its
configuration or neighbor list. There may be a possibility that the
network may be in the process of performing a BET HO while the MN may
initiate a Mobile originated HO. While this may be considered to be a
race condition or a special case, the fast HO I-D should specify the
precedence that would exist in such cases. In this case I would think
that the BET HO would be abandoned and the Mobile originated HO
request would take prerogative.

Comments,

-Basavaraj

---

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Wed, 19 Sep 2001 15:32:28 -0500

>This could be useful. I guess the AR would advertise that it supports
>BETH, perhaps through solicited RtAdvs.
>

Any reason why solicited RtrAdvts and not the reguar rtradvts?

Would you advertise that the network you are in supports Fast HO  (as
per FMIPv6) or only indicate that the network supports BETH? The MN
may not really know if a BETH HO was initiated or was succesful. So
even if you indicated via the rtr-advt that it was in a BETH capable
domain, you may still want to allow the MN to go ahead with a
RtrSolicit if it gets L2 triggers about changes in AP. Maybe there
needs to be a way of damping the RtrSolicit (in the network) if a BETH
HO has already been done succesfully or is in the process? I just do
not think you should change the MNs behavior of reacting to L2
triggers (movement detection) just because it is in a BETH capable
domain. 

-Basavaraj

---

From: James Kempf <[email-masked]>
Date: Wed, 19 Sep 2001 15:29:10 -0700 (PDT)

Hi Raj,

>request would take prerogative.

I agree.

Specifically, when the MN decides to hand over to another interface,
it issues a SolPrxyRtAdv to the AR that is handling the active interface,
requesting handover to the AR handling the new interface. Upon
receipt of the SolPrxyRtAdv, the current AR proceeds to do
an FMIPv6 handoff to the new AR, issuing a standard FMIPv6 HI/HACK, and
sending the PrxyRtAdv to the MN. Upon receipt of the PrxyRtAdv, the
MN proceeds to configure its IP stack so that the home address is
on the new interface, then it does F-BU and F-NA, just like standard
FMIPv6, but now on the new interface. 

This procedure is exactly the same as for an FMIPv6 handover. The difference
w.r.t. BETH is that the old AR terminates the bidirectional tunnel
upon receipt of the F-BU. In additon, the procedure for a MN doing BETH would
be exactly the same should it handover to an AR that was not
BETH capable on the same interface, except in that case, the current AR would 
signal the MN to do FMIPv6 handover by sending it a PrxyRtAdv, rather
than having the MN signal it by doing the SolPrxyRtAdv.

I don't believe this case is mentioned in the spec,  but I can
add it.

		jak

---

From: James Kempf <[email-masked]>
Date: Wed, 19 Sep 2001 16:13:18 -0700 (PDT)

Hi Raj,

>Any reason why solicited RtrAdvts and not the reguar rtradvts?

Good point.

There's a bootstrapping issue here w.r.t. FMIPv6
in general. Suppose an MN is capable of doing mobile initiated
FMIPv6 handover, it comes up in a network, gets a RtAdv for its initial
AR. How does it know that it can issue a SolPrxyRtAdv when it
gets a trigger saying it is about to be handed over? Should it
just issue one, and, if the current AR doesn't respond, assume that
it can't do FMIPv6 handover in this coverage area? Obviously, if the handover is 
network initiated, the MN will receive a PrxyRtAdv and then it knows it can do 
an FMIPv6 handover if it is capable. If not, it will simply
ignore the PrxyRtAdv. Similarly, if the MN moves out of an FMIPv6
coverage area and back again, how does it know when it can restart
doing FMIPv6 handover?

A similar consideration holds for BETH. The MN may come up in a 
network that is BETH capable, it needs to know it can suppress
MIPv6 handover signalling if it's traffic pattern suggests to.
The MN may be handed over into a coverage area lacking BETH
support, then handed over again to a coverage area in which
BETH is supported. 

>triggers (movement detection) just because it is in a BETH capable

I think we need to advertise both BETH and FMIPv6. The MN has to know what the
capabilities are. I think there are basically two cases:

1) The MN comes up in the network and aquires an initial AR via SolRtAdv
or an unsolicited RtAdv from the AR. Or the MN moves into
a coverage area where FMIPv6 is not supported and it starts doing
standard MIPv6 handover, then it moves into an FMIPv6/BETH coverage
area again.

2) The MN is in an FMIPv6/BETH coverage area and the current AR
knows that it is about to be handed over into a coverage area
where the ARs support more or fewer handover possibilities, so
the current AR can signal the MN via the PrxyRtAdv.

I think 1) can be handled by indicating the handover capabilities
in the RtAdv, and 2) can be handled by indicating them in the PrxyRtAdv.

		jak

---

From: James Kempf <[email-masked]>
Date: Wed, 19 Sep 2001 16:14:11 -0700 (PDT)

Hi Raj,

>Thanks. That would be good. Just for clarification (in BETH) , I guess
>the time at which you start forwarding packets to the MN via the
>tunnel to the new AR is at the time when you get an L2 indication that
>the MN is no longer connected to the AP. I may have to reread the BETH
>spec to ensure that is the case.
>

Yes, that's the case. Please let me know if it is unclear.

		jak

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Thu, 20 Sep 2001 09:46:54 -0500

Hello Rajeev:
Thanx for reply. Please find my inline reply/clarfication.
regards,
ajoy 

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

Hello Ajoy,

Singh Ajoy-ASINGH1 wrote:

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

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.

ajoy-> Rajeev, we are not writing the spec based upon our favorite
application. We are trying 
to write spec which should also be implementatble in bandwidth constraint 
network. Currently there are more wireless networks which are limited by RF
bandwidth
than otherwise.  

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

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 ?

ajoy: The Ethernet may be used as transport, but AP and AR uses some
tunneling mechanism. The tunnel
setup/teardown can be used a trigger at the AR. 

>
> >
> > 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 signaling would be invalidated.
>
> sending ProxyRtAdv with appropriate code is a necessity for BETH ? If yes,
this
> -> 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:

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.

ajoy: I agree. Sometime it is possible to have different mobility protocols
deployed in
same technology. 

My point if some technology decides to deploy BETH, it is likely that they
are doing that 
to save over the air L3 message during handover. 
I don't have any problem with optimizations. Their implications, however,
have to be clearly defined
and made known.

ajoy: OK. Hopefully, your concerns are already addressed by James's proposed
change to BETH. 

Regards,

-Rajeev

---

From: Alper Yegin <[email-masked]>
Date: Thu, 20 Sep 2001 12:37:41 -0700 (PDT)

Jim,

> result in faster CoA establishment (though, of course, not nearly

OK, having more explicit messages makes sense.

From other e-mails, I see you are positive on using a message to inform MN that 
it's entering a BETH domain. This helps too.

One more question remaining from my last message: what if MN doesn't support 
BETH?

With the current protocol specification, ARs don't know this, since there's no 
message sent from MN to AR. Maybe we should have one?

If ARs run BETH assuming MN supports it, this might cause problems with non-BETH 
mobiles:

- MN cannot correctly detect movement, because receiving its packet will imply 
it hasn't moved.
- I'd recommend ARs send an unsolicited unicast RA as soon as they detect a 
device attached. This saves bandwidth and latency, compared to MN soliciting or 
waiting for AR to send periodically. So, using a L2 technology that supports the 
trigger, my mobile node was going to wait for an unsolicited RA. But AR with 
BETH support wouldn't do that. So this causes some additional latency.

I think if both MN and ARs are fully aware of each other's capabilities before 
they take any actions, that'd be a more robust solution that can be extended and 
can fully interoperate with other scenarios.

alper

---

From: James Kempf <[email-masked]>
Date: Fri, 21 Sep 2001 16:44:07 -0700 (PDT)

Vijay,

>> 
>> You need to have a code for BETH for the router to tell the MN
>> that it is entering a BETH coverage area, and similarly
>> when it leaves. Why not do the same thing for FMIPv6?
>
>
>BETH needs it because the Mobile node is not involved when the
>OldAR descides to start forwarding packets to the NewAR. In
>FMIPv6, OldAR does not do this until it gets an indication
>from the MN. Therefore FMIPv6 does not need it....
>

The issue here is not when both the MN and the AR support FMIPv6,
it is when the MN doesn't but the AR does. If the AR doesn't know
that, then it could send a PrRtAdv which would be
ignored by the MN. Since not all radio spectrum is free, it 
seems appropriate to take reasonable measures to reduce the
amount of unneeded signalling over the air. I sometimes feel
like I am harping on this theme too much, but I believe the point bears
re-emphasizing: for some radio protocols, spectrum is very expensive.
I think it is entirely reonable to add such a code, since the
AR and the MN need to tell each other what their handover
capabilities are for BETH anyway. Adding an additional code
during the initial Router Advert Solicitation/Router Advert exchange
doesn't seem like such a big deal, if it saves an unneeded message
during every handover.

		jak

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 24 Sep 2001 08:55:32 +0200

James, 

I don't think we should advertise anything about FMIPv6
to the MN, or BETH for that matter. 
The whole mechanism works transparently andif one 
side is unaware of it then it will naturally fall through. 
If the MN sends Pr_rtr_sol an gets no reply then the 
Fast Handover will fail. If the AR sends Pr_adv and the 
MN doesn't understand it the handover will fail anyway. 

Also for MIPv6 if the MN sends a BU to oAR and it is not
capable then the BU will be dropped.

In BETH, there is no involvment from the MN anyway so 
no need to advertise. 

I understood BETH was designed for certain cases in which 
BW is expensive and getting some parallelism between the 
traffic and signalling was not possible. The last thing you 
need is yet another rtr_adv option which will not be necessary.

Hesham

> From:	James Kempf [SMTP:[email-masked]]
> Sent:	Thursday, 20 September 2001 1:13
> To:	[email-masked]; [email-masked]
> Cc:	[email-masked]; [email-masked]

---

From: James Kempf <[email-masked]>
Date: Mon, 24 Sep 2001 10:03:53 -0700 (PDT)

Hi Hesham,

>MN doesn't understand it the handover will fail anyway. 

I understand your concern, but consider the following situation.
A MN capable of doing BETH is currently traversing an area
in which there is no FMIPv6 coverage (and consequently no BETH).
The MN enters an area in which BETH coverage is available.

While the MN is in the no-coverage area, it will be using the
standard MIPv6 algorithm for handover (soliciting for RtAdv
or waiting until the AR sends them). How does it know
to transition to not soliciting and allowing the network
to perform the handover?

There are other examples for similar transitions.

>capable then the BU will be dropped.

I don't follow.

>In BETH, there is no involvment from the MN anyway so 

Sure, but the MN must know when to suppress sending SolRtPr
if the AR can handle the handover via BETH.

>need is yet another rtr_adv option which will not be necessary.

It isn't that expensive, just an additional 4 bytes. The RtAdv
is only sent to the MN once, when it enters the coverage area.
After that, the MN either uses FMIPv6 handover or BETH, if
these are supported. With the text I proposed be added to
Section 6.5 of the MIPv6 spec, the AR can limit advertising
the RtAdv to only when an MN appears rather than doing it periodically,
if the AR has that information available.

The other issue here w.r.t. FMIPv6 is that if the MN doesn't know
that the network isn't capable of doing FMIPv6, it could send out
a RtSolPr on every handover, only to have these ignored by the
AR. Similarly, if the AR doesn't know that the MN isn't capable
of doing FMIPv6, then the AR could send out a PrRtAdv on every
handover, only to have them ignored. Thus, by sending out an
additional 8 bytes (4 in the SolRtAdv and 4 in the RtAdv) when the MN 
enters the coverage area, you can save sizeof(PrRtAdv) bytes 
or sizeof(SolRtAdv) for every MN on every handover.

		jak

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 24 Sep 2001 19:36:03 +0200

Hi James, 

> to transition to not soliciting and allowing the network
	=> Why should it know or suppress rtr_sol ? My understanding 
	has been that the entire point of BETH was that some 
	link layers have certain timing restrictions and are not 
	flexible enough to allow for MIP to be integrated in their
	radio. But now it seems like you're adding something 
	else: suppresing rtr_sol. I don't think we need to do that. 

	We MUST distinguish between implementation issues
	and protocol issues. If I'm designing an IPv6 stack to 
	work in system foo, where foo has certain limitations 
	then I'll consider that in my design of the stack. BETH 
	has a narrow scope of use and is not designed to work
	in all cases so let's keep it that way. 

	Seriously let's not make things so unbeleivably complex that
	they become useless in practice. 

> >capable then the BU will be dropped.
	=> The aim was to say that you can't guarantee that every router
	will support all functions required. MIPv6 does not require 
	routers to add an option in the RA stating whether it will 
	accept BUs or not. The protocol is robust enough to handle
	that.

> if the AR can handle the handover via BETH.
	=> New requirement and is not relevant to mobility management. 
	We should not solve all problems within MIP. If the MN solicits
	and gets a new RA, normal MIPv6 will take place. 

> is only sent to the MN once, when it enters the coverage area.
	=> These are statements based on some architecture that you're
	thinking about. RAs in general can be sent as often as the 
	network administrator wants them to be. 4 bytes plus many other
	bytes will lead to fragmentation over slow links and unnecessary
	delays. I don't know why we need it, the protocol will still
	work very well.
	Anyway, I don't think you can have a 4 byte-long option in the RA. 
	I always get confused with the alignment requirements but I
	beleive it's 8n for RAs.

> handover, only to have them ignored. Thus, by sending out an> 
> additional 8 bytes (4 in the SolRtAdv and 4 in the RtAdv) when the MN > 
	=> The same analogy applies when a MN performs standard
	MIPv6 and send a BU (to anyone apart fron the HA) it may be accepted
	or dropped. So why is this any different ?? 

	Hesham

---

From: James Kempf <[email-masked]>
Date: Tue, 25 Sep 2001 10:51:06 -0700 (PDT)

Hesham,

>	else: suppresing rtr_sol. I don't think we need to do that. 

Hmm, well, let me try again. I think we both agree that one way a MN gets a 
RtAdv in standard MIPv6 is to send a SolRtAdv and that the MN could do this 
solicitation based on an L2 trigger, right?

Suppose the MN is moving in a coverage area in which the access
routers use the standard MIPv6 algorithm. In this coverage area,
the MN responds to the L2 trigger by sending SolRtAdv, receiving
a RtAdv in response. So you have these messages going out over
the air from the MN in response to its L2 handover.

Now, suppose the MN moves to a coverage area in which BETH is available.
Up until this point, the MN has been doing the SolRtAdv. How does
it know to stop doing the SolRtAdv and simply wait for the AR
to set up the tunnels? Can you give me a simple
explanation of how this would work without some kind of 
exchange between the MN and AR to let the MN know that things
have changed and it can now receive optimized service?

>	in all cases so let's keep it that way. 

I think it is an interoperability issue. You want to allow a BETH-capable
MN to operate optimally in an nonBETH network, and to transition. Also,
we are not just talking about BETH here. The same issues arise with
transitioning between an FMIPv6 and a standard MIPv6 (SMIPv6?) coverage area

>	they become useless in practice. 

I agree 100%. And if you can explain to me how to interoperably manage the
following transitions:

	FMIPv6 coverage <-> Standard MIPv6 coverage
	BETH coverage <-> Standard MIPv6 coverage
	
without adding having the MN and AR know what the other is capable of,
I'll be happy. Rajeev and I discussed this extensively on the list,
and having the MN and AR exchange this information seemed like the
right way to go, but I am certainly open to better suggestions if
you have one.

>	accept BUs or not. The protocol is robust enough to handle

Well, I consider this a bug in the MIPv6 spec. It must be possible
to suppress unnecessary on the air signalling when radio spectrum
is expensive. Service providers are not going to deploy MIPv6 if
they have to put up with gratuitous use of expensive spectrum, or
they are going to insist that vendors do something to allow
supressing it that may result in non-interoperable implementations. 
I haven't studied this issue closely enough to
make a recommendation about how to avoid it, however.

>> >In BETH, there is no involvment from the MN anyway so 

That's the whole point of what I'm trying to say. How is the
the MN told when to stop being involved in a transition situation?

>	and gets a new RA, normal MIPv6 will take place. 

Right, but if it doesn't have to solicit, or if it should use
a RtSolPr instead, then what? How does it know to use FMIPv6
or BETH instead of SMIPv6?

>	I always get confused with the alignment requirements but I

OK, without actually going through the numbers, I can see your argument
that the additional 8 bytes may outweigh the savings on the 
handover if the AR is advertising very frequently.

Another possibility is to use the ICMP code field. According to RFC
2463, the code is used to create "another level of granularity". 
Neither the RA or the SolRA specify any codes for RA and SolAR, 
so there would be no conflict if a code were used.
Alternatively, the bit field could be used. Both the RA and SolRA
have empty bit fields. SolRA has 4 bytes of Reserved, RA has
5 bits.

>	or dropped. So why is this any different ?? 

Like I said, that's a bug IMHO.

		jak

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 26 Sep 2001 02:41:50 +0200

> the air from the MN in response to its L2 handover.
	=> OK.

> to set up the tunnels? 
	=> Why should it know ?

> Can you give me a simple
	=> Actually I can't :) and I shouldn't. What is the outcome
	that you're trying to avoid ? If the MN solicits it gets an
	RA, if it finds out that it moved it will do standard MIPv6
	and overwrite BETH. What's the problem ?

	BTW BETH does not give optimised service, the packets
	are still going through oAR. Depending on the topology this 
	may not be optimal, e2e BUs are the most optimal.

> MN 
	=> There is no such thing as a BETH-capable MN. BETH relies
	on the fact that the MN is incapable ! 

> to operate optimally in an nonBETH network, and to transition. Also,
	=> Interoperability problems are problems that arise when two entities
	participating in a protocol have different understandings of the protocol
	parameters which results in communication failure. This is not at
	all the case here. No communication will fail.

> 	FMIPv6 coverage <-> Standard MIPv6 coverage
	=> The MN always uses standard MIPv6 unless something
	se happens. If a Pr_rtr_adv is received then it goes into FMIPv6
	mode. Otherwise it's standard MIPv6.

> 	BETH coverage <-> Standard MIPv6 coverage
	=> Even easier than the above, the MN ALWAYS operates
	in MIPv6 mode. BETH will still work until the MN receives 
	a rtr adv. Whether that is solicited or not is not important.
> 	
> without adding having the MN and AR know what the other is capable of,> 
	=> How about the above ?

> make a recommendation about how to avoid it, however.
	=> First of all this is a ND protocol. Second, as I tried to explain, 
	if you're optimising your implementation for a certain radio
	interface then please do it in your implementation. The protocol
	provides the general framework, optimisations like these
	are implementation dependant as long as  they don't break the 
	protocol. 
	We already have these issues in UMTS and are dealing with 
	it in the right places (configuration of routers and implementations 
	of routers and hosts).

> the MN told when to stop being involved in a transition situation?
	=> The MN can be involved after he handover not before. I thought
	that's the whole point behind BETH.

> or BETH instead of SMIPv6?
	=>You only use Pr_rtr_sol if you are soliciting BEFORE you 
	move. This is based on your L2 trigger that tells you you're
	about to move. Otherwise you use normal rtr solicitations.
	remember Pr_rtr_sol are TRIGGERED by L2 triggers.

	Hesham

---

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Tue, 25 Sep 2001 23:40:06 -0500

James,

Following this thread, I tend to agree with Hesham. I do not believe
it is required to advertise capabilities of FMIPv6 or BETH to the MN
via router advertisements. As has been discussed at length in this
thread the MN will know if the network supports fast HO when it
sends a ProxyRtrSolicit and receives an Advt as a response. And
similarly the network knows that an MN is capable of fast HO when
it receives the F-BU as a response to a ProxyRtrAdvt. So what do
you do when the network performs HOs via BETH? I think you should
allow the MN to still send a ProxyRtrSolct as a result of some L2
trigger on the MN but either ignore the message if the network is doing
a HO using BETH or send a NAK to the MN as a response to the
ProxyRtrSlct. I agree that this causes some additional signaling but
it keeps implementations simple (relatively) and also avoids having to
build new extensions or flags into router advts any more than we already
have.

-Basavaraj

---

From: James Kempf <[email-masked]>
Date: Wed, 26 Sep 2001 10:44:25 -0700 (PDT)

Hi Raj,

Thanx for the comments. Responses below.

>it receives the F-BU as a response to a ProxyRtrAdvt.

The issue here is the case where an FMIPv6 MN has transitioned
into an area where FMIPv6 is not available and only SMIPv6 is.
The MN will continue to send out ProxyRtrSolicits, or, will
do so at least once, presuming it gets clueful when the AR
doesn't reply and stops trying. I suppose one gratuitous
over the air message is OK. However, I would like to include
the following text in the FMIPv6 spec in large, glowing, neon
orange letters (:-)):

	If the MN does not receive a response to a ProxyRtrAdv,
	it MUST discontinue performing FMIPv6 handover,
	assume that the AR does not support FMIPv6, and
	revert to the standard MIPv6 handover algorithm.
	Similarly, if the AR does not receive a F-BU in
	response to a ProxyRtAdv, it MUST discontinue
	performing FMIPv6 handover, assume that the MN
	does not support FMIPv6, and revert to the standard
	MIPv6 handover algorithm

It is *absolutely essential* that the spec be very clear about
this, so that implementations do not end up wasting expensive
radio network bandwidth by sending out gratuitous radio
traffic. It is by no means certain that implementors will do
the right thing given the current spec. I've seen cases where
even when the protocol spec explicitly specified measures to conserve
network bandwidth, implementations violated the spec in ways
that resulted in wasted bandwidth. Fortunately (or perhaps
unfortunately, since we have to put up with it on our network) it
was for a wired network protocol. Radio spectrum is too
expensive to waste.

Do you agree to this change? 

> So what do

We have had this conversation before, and I simply do not think it
is necessary to have the ProxyRtSolct every time the MN hands over.
For the price of a single notification when the MN enters a BETH
coverage area, you get performance that is strictly limited by
L2 handover. If you would rather not have the notification come
via a RtAdv, that is fine. The ProxyRtAdv will work just as well.
With a code in the PrxyRtAdv telling the MN
that it has entered the BETH coverage area, the MN can be notified to suppress
any over the air signaling. After that, the MN's handover is handled
by BETH. When the MN is about to transition out of a BETH coverage
area, it gets a ProxyRtAdv indicating that it should revert to
FMIPv6 or SMIPv6 handover. The ProxyRtAdv and SolProxyRtAdv already
have room for such a code, and it is used to notify the MN about
certain cases w.r.t. to the handover, this is just another one.

Do you see any issues with this?

		jak

---

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Fri, 28 Sep 2001 09:59:09 -0500

James,
Comments inline (prefixed BP>)

>	does not support FMIPv6, and revert to the standard

BP> The above text does provide some guidelines for implementations to
deal with no respones to ProxyRtr[Slct/Advt].  You may want to add that:
"A MN and an AR realize capabilities for fast handoff support only via
the
ProxyRtr[Advt/Slct] messages". 

>the right thing given the current spec. 

BP> You cannot prevent someone from building poor implementations :(
irrespective of how well the spec is written.

>I've seen cases where

BP> But you have to take into consideration spectrums that do not cost
and
are not exactly bandwidth limited as well. Optimizing the messaging
for networks where spectrum is at a premium is a good goal, but should
be used as ONE of the design criteria. 

>Do you agree to this change? 

BP> I agree. 

>Do you see any issues with this?

BP> I think I can live with that :) Hope to see the new revision of the
I-D soon.

-Basavaraj