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

From: James Kempf <[email-masked]>
Date: Wed, 1 Aug 2001 10:04:40 -0700 (PDT)

Hi Alper,

Thanx for the review.

>
>As I understand, the approach BETH is taking is to eliminate the L3 signalling 
>over the air, therefore eliminate the associated latency. While this goal is 
>accomplished, I think this also creates some potential problems for the mobile 
>node. Taking mobile node out of the loop makes me uncomfortable, because:
>
>Mobile node is a passive player in this protocol. Since this protocol takes 
away 
>the signalling between the MN and the AR, MN cannot know when BETH takes place. 
>
 
This not strictly accurate. It takes out the signaling at L3. There is still
signaling at L2. The MN must know when it comes up on the new
link, and what the L2 address of its router is, otherwise it can't
get packets out.

>Imagine a mobile node that detects it's receiving new router advertisements 
with 
>a different prefix, and no longer hearing advertisements from oldAR. It also 
has 
>detected a L2 break-and-make recently. Mobile node will "discover" this 
>"movement", will attempt to unconfigure its oldCoA and configure a newCoA, and 
>send BUs around. This, of course, won't play well if there is a BETH going on 
in 
>parallel. 

I'm not sure I understand your example. Perhaps you have identified a problem 
here, but lacking more detail, I can't see it. If a situation
happens as you identify it, the MN can begin establishing a new CoA
at any time. As soon as the new AR detects that the MN has completed
this, it signals the old AR via a HRqst to tear down the tunnel. If
the MN succeeds in getting a new CoA on old AR, old AR simply doesn't
tunnel.

In general, BETH is not proposing to replace
or otherwise negate the existing handover mechanisms, just to augment
them. If the MN discovers a router, it is perfectly free to perform
a standard FMIPv6 handover, or even a stock Johnson and Perkins
handover if it so chooses. The mobile node is completely in control
of when it decides to begin the process of obtaining a new CoA. That,
in fact, is the key differentator between BETH and both the standard FMIPv6
and Johnson and Perkins algorithms. These algorithms leave the MN no
choice, it *must* obtain a new CoA regardless of whether the process
would interrupt a real time flow.

>Maybe ARs should advertise their BETH capability in advance. But, can mobile 
>node always count on BETH taking place, and supress other protocols (MIPv6, 
>FMIPv6) execution?
>

Well, this is a policy question and something that I don't think is
appropriate for the protocol draft. There maybe be some need in
particular situations to codify the interaction between BETH
and FMIPv6 more precisely if there is interference, if so, then we need to 
clarify it. We probably need to go through some protocol flows to
check this, similarly for the interaction between FMIPv6 and
the original Johnson and Perkins algorithm. BETH is no different than standard 
FMIPv6 or the original Johnson and Perkins algorithm in this regard. Should a 
router advertise if it is capable of FMIPv6 so that it can suppress MIPv6? 
If so, then perhaps we need some policy knobs that let a network
administrator configure what type of handover they want to support,
and a way to communicate that to the MN when it enters the network.

>Another case... Mobile node has two interfaces. It might just prefer to use 
>basic MIPv6 (forwarding from previous CoA) for handoff. oldAR and newAR might 
>decide the handover the mobile, while mobile might want to handover to thirdAR 
>using it's other interface. How does this play with ARs doing BETH between 
them? 

I'm not clear on exactly what you are proposing, but if I understand
you correctly, I think there are more open questions about how
a second interface would get used than BETH. For example, if an interface
is already configured with a global IPv6 address and a MIP CoA, then
there would need to be some process on the MN to cause that binding
to be transferred to the new interface. The global IPv6 address would
need to be transferred and there would need to be a new CoA on the
new interface (unless, of course, the new interface is on the same subnet).
The Neighbor Caches on the routers need to be updated, to reflect the
new binding between the CoA and L2 address. This is naturally going to require a 
certain amount of radio traffic, and so it is not appropriate for BETH handover 
to be used in this situation. BETH is only for extremely time critical handover, 
such as is involved in real time traffic. Before we start discussing
how to handle interaction between BETH and a MN with two interfaces,
I think we need a better understanding of how a MN with two interfaces
would perform a standard MIPv6 handover between them.

>Maybe oldAR and newAR should abort the operation as soon as they see mobile 
node 
>sending a BU? Mobile node *might* even choose to send this BU directly to HA or 
>CNs, if it doesn't care for forwarding from previous care-of address.
>

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.

>These two are potential problems due to mobile node not being in control, or at 
>least not informed. And I think "control" is more needed for multi-interfaced 
>mobiles.
>

As I mentioned, the MN is completely informed via L2 and is, in fact,
more in control than in FMIPv6. In BETH, the MN can choose to use
the standard FMIPv6 algorithm, where it gets to choose which
router it wants, etc. *And* it gets to choose when to  establish
a new CoA. With FMIPv6, it only gets the first.

>
>Regarding to FMIPv6 analysis (Appendix A.4)... Any traffic that takes place in 
>old-link can be categorized under "anticipation". They don't necessarily 
>introduce delay in the service, but they require so much anticipation. They 
have 
>to take place before L2 breaks.
>

Delay occurs when the radio link is used for anything other than
real time traffic, regardless if it occurs on the old link or the new.
On a 9.6 Kbps radio link (currently used for 2.5G cellular voice),
signalling traffic on the dedicated traffic channel will block any other 
traffic. Cellular protocols currently use the dedicated traffic
channel for IP signalling. One could imagine using the dedicated
signalling channel for IP signalling, and that would help to free the 
traffic channel since the IP signalling can go on in parallel, but
even then the signalling channels tend to be substantially slower
than the traffic channels (I think wCDMA uses 3 Kbps if I remember
correctly), so there is the potential that a MN could start the
process of obtaining a new CoA by anticipation and end up moving
to a new access router before it actually had the new CoA. BETH would
handle this smoothly, so I think there is a place for it even
if IP signalling traffic moves to a dedicated channel. Not to mention:
moving IP signalling traffic to a dedicated signalling channel would require
the 3Gs to actually modify their air interface, something difficult
and time consuming to do.

>And arrival of F-NA at the newAR can be substituted with L2 triggers, which 
BETH 
>already relies on.
>
>So, the L3 Handover Latency table in Appendix A.4 should be re-done IMO.
>
>

My understanding from reading the FMIPv6 draft is that the F-NA is
what triggers the process of Neighbor Cache update at new AR, DAD,
and all the other good but time consuming stuff involved in 
getting an IPv6 host up on a new subnet. Is that not so?

Note that these calculations do not consider the BU/BACK from
the HA nor from CNs. If you add those into the picture, you
get considerably more time until the new CoA can be used. In that sense, the 
calculations are very optimistic, and for all but the first scenario consider
that the MN will be using its old CoA on the new AR just like
in BETH (considered a corner case in the original FMIPv6).

>Draft says BET is torn down when "The MN begins the process of obtaining an 
nCoA 
>through nAR.". How does the newAR know that? Is is through newAR detecting that 
>MN is doing a DAD on a CoA?
>

As mentioned above, the tunnel should be kept up until all BU/BACK from
the HA and CNs have arrived, and perhaps even remain up for
a short period after to catch any laggard packets. It is only at
that point that the MN can begin to reliably send and receive packets on the new 
CoA.

>
>Draft says "The MN is in the best position to know when it can afford to pay 
the 
>latency cost of CoA establishment." I don't think obtaining a newCoA has a 
>latency cost. It can happen in parallel with on-going traffic using oldCoA.
>

Alper, everything that involves radio traffic not related specifically
to applications running on the MN has a latency cost and is pure overhead. 
Everything. At 9.6 Kbps, it takes 1.2 ms to send a byte. If the byte is in a
mobile IP packet, or a routing advertisement, or anything other
than a packet involved in the application, that is 1.2 ms that
is not available for sending application data. If the application
is a real time application, you can only get away with sending
overhead for an extremely short time before the user notices. The only way to 
get around this is to either do the signalling on a separate channel or
crank up the speed of the radio link (if you can, wCDMA allows
this, cdma2000 doesn't). That's why the 3G radio protocols have
separate signalling channels in the first place, unfortunately, we
don't get to use them.

I agree that we need to do some protocol flows to identify the interaction
between BETH, standard FMIPv6 and the original Johnson and Perkins algorithm.
These flows should identify whether there are any situations in which
there is need for some additional work to allow suppression or switchover,
or perhaps specification about what the ARs  and MN should or should not do
in particular windows. I don't think, however, that BETH is any different from 
the other two algorithms in this regard.

		jak

---

From: "Alper" <[email-masked]>
Date: Thu, 2 Aug 2001 22:56:22 -0700

Hi Jim,

My response inlined... (sorry, late)

> link, and what the L2 address of its router is, otherwise it can't

Yes, L2 signals are there. But those signals don't reveal whether
there's BETH going on between ARs or not. And I think MN should know
this (see below).

> the MN succeeds in getting a new CoA on old AR, old AR simply doesn't

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

> router advertise if it is capable of FMIPv6 so that it can

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.

> and a way to communicate that to the MN when it enters the network.

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.

> would perform a standard MIPv6 handover between them.

They can do "forwarding from previous care-of address" as specified in
MIPv6, I think.

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

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

> a new CoA. With FMIPv6, it only gets the first.

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.

> and time consuming to do.

OK, I see. Sending L3 signalling is blocking data transmission. I
understand.
This is the latency of transmiting the packet, not the latency for delivery.

> getting an IPv6 host up on a new subnet. Is that not so?

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.

> in BETH (considered a corner case in the original FMIPv6).

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.

> that point that the MN can begin to reliably send and receive

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

> to applications running on the MN has a latency cost and is pure

I see. It's my misunderstanding. This is the transmission latency, not
delivery. You are right.

> the other two algorithms in this regard.

alper