Subject: RE: [mobile-ip] BETH comments and questions

From: James Kempf <[email-masked]>
Date: Fri, 3 Aug 2001 10:16:09 -0700 (PDT)

Hi Alper,

Replies included.

>My scenario, and question, is what should "a" MN do after it detects the
>movement at L2? Should it wait in the expectation that ARs are performing
>BETH in between and MN will start receiving packet sent to oldCoA? Since
>there's no L3 signalling between ARs and the MN, MN cannot know that. Or,
>should it attempt stock MIPv6 handoff (DAD, newCoA, which will delay
>transmission from MN).
>
>

Tunneling under the old CoA between old AR and new AR is handled even under the 
stock FMIPv6 algorithm as a corner case. In BETH, the
difference is that when the MN detects it has moved,
it can either begin the process of establishing a new CoA using
the standard FMIPv6 algorithm, or it can wait until its real time
stream is complete, or until it moves again. The decision is
up to the MN. The tunnel should not be a corner case, but rather the norm. The 
ARs should always set up the tunnel for network initiated handover (this is,
incidentally, how low latency MIPv4 does it), and it is up to the MN as to 
whether and when it should establish a new CoA (this is not currenly
in low latency MIPv4 but we will add it if the WG agrees). If it has a real time
stream going, it can wait, if not, it can go forward with the CoA change.

For the mobile initiated case, it is completely different. Because
the MN is signalling over the air to control the handover, the algorithm 
presumes enough radio bandwidth (or a completely separate signalling channel) so
the MIP signalling doesn't interfere with real time streams. In
that case, the AR is warned sufficiently ahead of time by the
RqstPrxyAdv that the MN will be handling the handover, and so
it should not initiate the tunnel.

>The end2end L3 signalling between MN and oldCoA reveals what's going on.
>F-BU, F-Back, ProxyRtAdv are all new signals that indicate what's going on.
>At any time both sides know what's going on, and can choose to fail it or
>proceed.
>

If FMIPv6 is modified as I've described above, then there should
be no interference. Whether or not mobile initiated/controlled
or network initiated/controlled handover is done is a policy question
that probably will be determined by the amount of radio bandwidth
available or the availability of a signalling channel for IP related
signalling. This will have to be established beforehand. There
is no need, in the network initiated/controlled case, for any
signalling from the MN until it decides it wants a new CoA.

>The problem for BETH would be, at the time MN attaches to "a" new L2
>(newAR),
>how is it going to be notified of this information? Can't wait for a L3
>message, as BETH relies on non-existence of such a message.
>

See above.

>Let me try to explain my example (it wasn't clear, I admit).
>
>MN has interface1, attached to oldAR. It also has another interface,
>interface2.

Does interface2 have a global IP address and CoA or not?

>While oldAR and newAR decides to perform BETH for interface1, MN might
>decide
>to do a "forwarding from previous care-of address" between oldAR and
>thirdAR.

??? where does thirdAR come into this? I guess I'm still not getting
this example, sorry. Maybe we can talk about it in person in London?

>Since MN doesn't know BETH is happening, it's very well possible that it
>does
>its own thing. So, I think we should define what happens if oldAR is in the
>middle of BETH and it receives a BU from MN.
>

I'm not clear what you mean by "in the middle of BETH." As I stated
above, BETH is just extending what is a corner case in the FMIPv6
draft to be the norm. MN knows when the L2 handover completes on 
L2 via the Link Up trigger. At that point, it can start the process
of establishing a new CoA on the new AR if it wants, or not. This
isn't any different from the case in standard FMIPv6 where none
of the signaling for establishing a new CoA goes through the old
AR and all of it goes through the new AR. 

>> The signal should be the BACK from the HA and any CNs, because it
>> is only at
>> that point when the new CoA can really be used. The ARs tear down
>> the tunnel at this point, though they may keep it up for some
>> configurable time period in order to assure that any laggard packets
>> get to the MN. The draft should be more precise about this.
>
>
>Is this based on newAR sniffing the traffic and seeing a Back sent to MN?
>

It would have to track the BACK. As for sniffing, BU/BACK are
destination options and I thought that routers were allowed
to process destination options? 

>I agree with you on when to configure the CoA. But in BETH, somebody
>is doing a L3-ish handoff on behalf of MN, and MN doesn't even know this.
>

It is no different than the corner case of standard FMIPv6 in which the
MN does no new CoA establishment signalling on old AR and all of it
on new AR. This is a real possibility in the standard FMIPv6 algorithm,
if movement into the coverage area of the new AR is too fast.
There is no L3-ish handover occuring, everything is happening at
L2 and the ARs are fixing things up at L3 to make sure the MN's traffic
gets to it (this is, after all, what routers are supposed to do).
The L3 handover occurs after the MN is on new AR, if MN so chooses.

I'm adhering to the following definitions here:

	L2 handover - a change in link connectivity from one
	radio access point to another as a consequence of mobile
	node movement between radio coverage areas.
	
	L3 handover - a change in mobile IP care-of address as
	a consequence of mobile node movement between one
	subnet and another.

>F-NA can be replaced by a L2 trigger. Maybe we should clarify this better
>in FMIPv6. The information needed for neighbor cache is already
>in HI message. All newAR needs is an indication of arrival.
>

I think the draft needs to clarify this. There are a couple places
in the draft that state that the F-NA is the gate. If that's the
case, then I agree that the handover times in Appendix A may
need to be modified.

>Once MN has a tunnel from oldAR to newCoA, it doesn't have to wait for
>BU/BACk from CN/HA. Packets sent to oldCoA will be tunneled. MN can
>use newCoA as its source address in the outgoing traffic.
>

So the only way this is different from BETH is that the MN uses
its old CoA to send outgoing traffic, saving the 
signalling traffic over the radio channel for establishing the new CoA.
And the routers maintain the tunnel until the MN is ready to
change CoA.

>But this BAck arrival happens at the MN, right? Not at newAR. So,
>how does newAR know this? Sniffing on the network?
>

BU and BACK are destination options, aren't routers allowed to
process destination options? If they can, then they can note
them as the packets go by.

		jak

---

From: Alper Yegin <[email-masked]>
Date: Fri, 3 Aug 2001 18:46:31 -0700 (PDT)

Jim,

Let me rephrase my questions/concerns..

- During a real-time communication, if your MN detects that it has attached to a 
new L2, what does it do? It'd hope that oldAR and newAR are doing BETH and MN 
would do nothing, as I understand. But, what if the newAR is not BETH capable, 
or BETH has failed for some reason. The only way to figure this out is to wait, 
I think. There seems to be no other way, because there's no L3 signalling 
between MN and newAR. And this wait will effect the handoff time, if newAR is 
not doing BETH.

- BU/Back are destination options. Therefore they are only processed by the
destinations, MN/CN/HA. If routers want to take a peek on them, they can do so. 
But, designing the protocol based on sniffing packets on the wire makes me 
worried. One thing, it's not guaranteed that this packet will go through this 
router, as there can be more than one on the link. Secondly, if one day this 
packet is encrypted, or a new flavor of BU/BAck is used, this won't work.

As far as what kind of L? handover this is, I agree this is more like a L2 
handover (at least as far as MN is concerned).

We should clarify the use of L2 triggers in FMIPv6.

alper

> them as the packets go by.

alper

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Sat, 4 Aug 2001 18:07:44 -0500

Hello Alper:

Sorry for jumping in the middle of discussion. 
Please find my inline response.

regards,
ajoy  

During a real-time communication, if your MN detects that it has attached to a new L2, what does it do? It'd hope that oldAR and newAR are doing BETH and MN would do nothing, as I understand. But, what if the newAR is not BETH capable, or BETH has failed for some reason. The only way to figure this out is to wait, I think. There seems to be no other way, because there's no L3 signaling between MN and newAR. And this wait will effect the handoff time, if newAR is not doing BETH.

ajoy: If BETH is deployed in particular access technology, it is assumed that neighboring routers will be BETH capable. Neighboring routers have to understand same protocol to support fast handover. For example, if neighboring routers do not support same protocol, we cannot support context transfer, the MN has to negotiate context. This is true for any protocol in general. If BETH fails due to any reason, MN will detect service disruption because real time traffic flow will stop. MN can use this information as a trigger to acquire new COA. If you do not support BETH in low data rate channel, the service of user will be affected every time MN moves from one AR to other. Which one you will choose ?

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]]
Sent: Friday, August 03, 2001 8:47 PM
To: [email-masked]
Subject: RE: [mobile-ip] BETH comments and questions

Jim,

alper

alper

---

From: James Kempf <[email-masked]>
Date: Sun, 5 Aug 2001 16:44:09 +0-100

Hi Alper,

>between MN and newAR. And this wait will effect the handoff time, if newAR is 

As Ajoy pointed out, if the real time packet stream fails, the MN can
simply go ahead and establish its CoA. The point of BETH is to eliminate
L3 signalling so the radio link is free for real time traffic. If 
there is no real time traffic, then the MN can go ahead and get a new
CoA.

But the issue you bring up about a router not being BETH capable obviously
holds for FMIPv6 too. In that case, the MN learns that it can't do
FMIPv6 because it doesn't get a reply for RqstPrxyRtAdv, but by that
time it could already be on the new  AR. Though I dislike adding knobs
where they might not be needed (because they add complexity) perhaps
the admission control procedure needs to inform the MN about what
handover options it has. Better would be to simply make fast handover
a required part of MIPv6, to avoid having the situation where a 
router doesn't support it (in the long run).

>packet is encrypted, or a new flavor of BU/BAck is used, this won't work.

OK. Perhaps an explicit BU to the new AR when the new CoA is totally in
place is the right way to go. 

>We should clarify the use of L2 triggers in FMIPv6.

Yes, while I agree with trying to make it general, if there are abstract
L2 triggers, it should be possible to write the draft such that there
is no dependence on a specific L2. As it now is, there are implicit
assumptions about L3 obtaining handover sequencing information that
I think might make it difficult to implement by someone who was
not part of the initial design group. 

		jak

---

From: "alper" <[email-masked]>
Date: Mon, 6 Aug 2001 05:49:35 -0700

Hi Jim,

Please see my responses below with prefix "aey >".

----

Hi Alper,

aey > I think the key here is, how soon can the MN detect "real time
packet stream failed"? If BETH is not available, and until this detection
takes place, MN is not reachable. Only after this is detected, stock-MIPv6
can kick in. And this is even slower than doing stock-MIPv6 as soon as MN
attaches to new link. This is my main concern.

aey > Therefore by the time MN attaches to new link, it knows FMIPv6 didn't
work, and start stock-MIPv6 handoff immediately. In BETH case, MN needs to
wait until it detects BETH didn't work. So, FMIPv6, and even stock MIPv6,
works
faster than BETH in this case. And I think this is not a rare case, as not
all
the routers will support BETH.

aey > I'm not sure if we can expect all routers to support a specific
handoff mechanism, but having a L2 capability than can convey the
"L3 handoff mechanism" in the link-up trigger could be useful.

aey > Now we have the L2 requirements draft, I think we can re-work
the L2 wording in the FMIPv6 draft (Gopal, are you reading this? :)

                jak

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 6 Aug 2001 09:23:09 -0400

I think Alper makes a good point. We have a number of different handoff
mechanisms by now and the mobile node needs to know what is going on. IP
Layer handoffs, like MIPv6 do provide information about the network's
capabilities in the Router Advertisement and MIPv4 is using Foreign Agent
Adverts to do the same.

In the case of BETH where L2 triggers are used instead of IP messages the
information about what the network supports could also be part of the L2
triggers. e.g.: a BETH capable network could announce its capability in an
L2 trigger to the MN...This way during a handoff the IP layer in the MN will
know that it should not do anything since BETH is working...lack of such a
trigger would make the MN use traditional MIP mechanisms to handoff.

Thoughts?

George

-----Original Message-----
From: Sebastian Thalanany [mailto:[email-masked]]
Sent: Monday, August 06, 2001 2:01 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mobile-ip] BETH comments and questions

Hello Alper,
                      To achieve the BETH support for real-time traffic
streams,
the assumption is that the neighboring ARs are BETH capable. BETH capability
is
required to be installed via system engineering to support the handoff of
real-time traffic streams.
                      In the absence of BETH, the stock MIPv6 procedures are
applicable. In the case that BETH was only partially deployed, the impact on
the
handoff of real-time traffic streams would be less severe than if only the
stock
MIPv6 procedures were available. In the specific cases, where a handoff
occurred
from a BETH capable AR to a non-BETH capable AR, the additional latency
incurred
in the detection and switching to the stock MIPv6 procedures could be used
as a
trigger for network management to re-engineer the system for BETH
deployment.

Regards,
   Sebastian

alper wrote:

> [my mail server was down. I dont seem to receive these e-mails. following
> them from the mobile-ip archieve..]
>
> Hi Ajoy,
>
> I understand that the BETH should be deployed in a domain, therefore
> neighbor
> ARs in this domain will be BETH capable. But we cannot claim "all" the
> neighbor
> routers will be BETH capable, as the whole Internet is not a single
domain,
> and
> we don't expect every ARs to support BETH.
>
> Therefore, I cannot speculate how often but, MN will attach to
> BETH-incapable
> ARs.
>
> It's perfectly fine if handoff performance is better when BETH kicks in,
and
> the performance is as good as stock-MIPv6 whenever BETH is not available.
>
> But, I think performance of handoff is worse than stock-MIPv6 when MN does
a
> BETH-to-nonBETH handoff. First it has to wait and detect that BETH didn't
> work.
> Only after than it can start stock-MIPv6 handoff. I don't know how much
> delay
> this introduces as the draft doesn't outline the process in this case. So,
> how
> soon can we detect a real-time flow is cut?
>
> Also once the MN enters a non-BETH domain, it better "learn" that this is
a
> non-BETH domain, so it doesn't get hit at every handoff in this domain.
>
> alper
>
> Hello Alper:
>
> During a real-time communication, if your MN detects that it has attached
to
> a new L2, what does it do? It'd hope that oldAR and newAR are doing BETH
and
> MN would do nothing, as I understand. But, what if the newAR is not BETH
> capable, or BETH has failed for some reason. The only way to figure this
out
> is to wait, I think. There seems to be no other way, because there's no L3
> signaling between MN and newAR. And this wait will effect the handoff
time,
> if newAR is not doing BETH.
>
> ajoy: If BETH is deployed in particular access technology, it is assumed
> that
> neighboring routers will be BETH capable. Neighboring routers have to
> understand same protocol to support fast handover. For example, if
> neighboring routers do not support same protocol, we cannot support
context
> transfer, the MN has to negotiate context. This is true for any protocol
in
> general. If BETH fails due to any reason, MN will detect service
disruption
> because real time traffic flow will stop. MN can use this information as a
> trigger to acquire new COA. If you do not support BETH in low data rate
> channel, the service of user will be affected every time MN moves from one
> AR
> to other. Which one you will choose ?

---

From: James Kempf <[email-masked]>
Date: Mon, 6 Aug 2001 19:16:21 +0-100

Alper,

The AR can also send a RtAdv to the MN, rather than the MN waiting. This
would probably be quicker.

		jak

---

From: James Kempf <[email-masked]>
Date: Mon, 6 Aug 2001 19:20:23 +0-100

George, 

I think it would probably be better to have the network tell the MN during
admission rather than on each handover. More information == more radio
bandwidth to transmit it, regardless if its at L2 or L3. When the
MN falls off the edge of a trust domain and has to redo admission, then
it probably is facing a lengthy transaction anyway so there is no
harm in delaying it do obtain a CoA.

		jak

---

From: James Kempf <[email-masked]>
Date: Tue, 7 Aug 2001 00:12:50 -0700

Hi Alper,

As mentioned yesterday in the WG meeting, if the AR is not BETH-capable,
then it has a responsibility to inform the MN via a RtAdv that the
MN has moved, as soon as the L2 trigger is received. This is actually
better than the standard MIPv6 algorithm. If the router doesn't support
an L2 trigger, then either it uses the standard MIPv6 algorithm and
periodically sends out a RtAdv, or, as Ajoy mentioned, the MN detects
that its real time stream is interrupted and requests the RtAdv. 

In general, if the network operator wants to have high performance,
they must have equipment to support it, and must arrange for interoperation
with neighboring administrative domains so high performance handover can happen.
This is not any different from other areas, such as Diffsrv. A mobile node
that runs off the edge of a network of Diffsrv routers is going to
end up having its real time traffic slow down to best effort. There
is no way, in protocol design, to make poor network engineering impossible.

		jak

>routers will be BETH capable, as the whole Internet is not a single domain,
>and
>It's perfectly fine if handoff performance is better when BETH kicks in, and
>But, I think performance of handoff is worse than stock-MIPv6 when MN does a
>Also once the MN enters a non-BETH domain, it better "learn" that this is a
>During a real-time communication, if your MN detects that it has attached to
>a new L2, what does it do? It'd hope that oldAR and newAR are doing BETH and
>capable, or BETH has failed for some reason. The only way to figure this out
>signaling between MN and newAR. And this wait will effect the handoff time,
>neighboring routers do not support same protocol, we cannot support context
>transfer, the MN has to negotiate context. This is true for any protocol in
>general. If BETH fails due to any reason, MN will detect service disruption