Subject: [mobile-ip] Fastv6: Issue 2: Deferring new CoA configuration

From: Rajeev Koodli <[email-masked]>
Date: Mon, 16 Sep 2002 18:37:29 -0700

Issue: Should a Fastv6 MN be required to have the
option of deferring its new CoA configuration until
a "convenient" time ?

Background: In version 04, a MN can defer new CoA
configuration until it finds, for instance, suitable
radio resources (See Section 3.5.2). This would mean
that the MN would be required to suppress RS and
Router Advertisement every time it changes access routers
until a convenient time. This also means the previous CoA
would potentially have to be supported across a series of
access routers for arbitrary periods of time.

The proposal is to remove this restriction on new CoA
configuration.

Please respond
- YES if you agree to remove the restriction
    of deferring new CoA
- NO otherwise. Indicate a brief reason

Thanks,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Tue, 17 Sep 2002 10:22:02 -0700

> The proposal is to remove this restriction on new CoA

Hmmm. I rather view the restriction as the opposite, namely *requiring* the MN
to *always* obtain a CoA immediately.

As a philosophical aside: why is it that those who support "mobile control"
always balk at letting the mobile node determine when it should configure a new
CoA? Why not let the MN decide *that* too? To me, this is the ultimate in mobile
control.

> - NO otherwise. Indicate a brief reason

YES. Because I believe that if we are to support mobile control, then we should
allow the mobile to control when it applies for its care of address.

The configuration of a new care of address will require a considerable amount of
time, especially if route optimization is required with correspondents. The
mobile node is really the only entity that can know whether it will have enough
time on the new access router to complete this lengthy and time consuming
process. Therefore, I think we should let the mobile decide. If it doesn't have
time, for example, because it will be moving to a new access router soon, then
it should defer obtaining the care of address.

Also, the mobile may find that the link layer has moved it to a router that it
doesn't like. Maybe the QoS isn't good, or there is too much congestion. If the
mobile is forced to apply for a new care of address, then it will *have* to use
that router, even though it doesn't like it. I think the mobile should have the
option of forgoing getting a new care of address on the new router and switching
immediately to another one it likes better, and not be forced by the
specification to get a care of address on a router it doesn't like.

            jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 17 Sep 2002 11:10:40 -0700

Hello Jim,

Something you said caught my eye:

> CoA? Why not let the MN decide *that* too? To me, this is the ultimate in mobile

Surely you don't wish to enact the "ultimate" in mobile control!
If we all had those, then we would use that ultimate control
to arrogate as much network service as we could possibly take,
actually making things worse for everyone compared to a more
controlled scenario.  This "might" be at the cost of requiring
more unscalable stuff in the network -- even turning network
domains into flat addressing domains without aggregation.

Problems with unrestricted use of arbitrary care-of addresses
could include:
1. More tunneling than necessary, introducing additional
   latencies and network load.
2. Topological incorrectness which disseminates out into
   the network.  Mobile IPv6 avoids this problem by shielding
   the home address from the visited network.
One might say that the unrestricted maintenance of stale
care-of addresses is "non-Internet" style technology, since
it defeats efficient routing and aggregation.

Of course everything needs to be balanced.  In this case,
the balance has to be struck between smooth performance and
tunnel maintenance.  My remembrance from old fast-handover
design team discussions was that we carefully considered
this balance, and allowed tunneling to old care-of addresses
for as long as needed for smooth handovers.  Past that point,
the benefit is questionable and the penalty is clear.

> it should defer obtaining the care of address.

...

These are things that should be happening during the acquisition
process.  I don't remember discussion that said one had to cause
the mobile to discontinue use of the old care-of address prematurely.
I thought the sense of the discussion was to find an algorithm by
which the smoothest possible transfer could be made.

>> - NO otherwise. Indicate a brief reason

My vote is to have a deterministic algorithm by which the care-of
address is updated by protocol, and during which the old care-of
address is still useful for tunneling to the mobile node at its
new point of attachment.  I'm not sure whether that's YES or NO!

Regards,
Charlie P.

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 17 Sep 2002 12:10:46 -0700

Hello Charlie,

> new point of attachment.  I'm not sure whether that's YES or NO!

The deterministic algorithm is to do Neighbor Discovery as
soon as a new link is detected or use anticipation whenever
possible. After that the MN would do Binding Update, and
when the packets start flowing into the new CoA, the old
tunnel should time out. The lifetime for the tunnel should
take these latencies into account.

I guess the vote is YES to require the MN to configure a
new CoA (while use of PCoA is simultaneously allowed) ?

Regards,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Tue, 17 Sep 2002 13:43:34 -0700

Hi Charlie,

>    latencies and network load.

As in any network deployment problem, the routers and the connections between
them need to be sized correctly for the expected load.

>    the home address from the visited network.

I don't understand this issue. On the wired side, the packets are coming out of
the subnet in the topologically correct place. Where is the topological
incorrectness? The HA is doing exactly the same thing for reverse tunneled
packets. On the wireless side, the access router is putting the packets out
exactly as the FA does in MIPv4. Since this is the last hop, the IP topology is
irrelevent.

> it defeats efficient routing and aggregation.

Disagree. The packets coming out of the tunnel end point will be properly
aggregated. If this sort of tunneling is considered "non-Internet", then why is
not the Home Agent considered similarly?

> the benefit is questionable and the penalty is clear.

We discussed the same issue in the FMIPv4 team and (partially) came to the
opposite conclusion. Also, one of the FMIPv6 team members joined me in writing
the BETH draft, which allowed open tunneling.

> which the smoothest possible transfer could be made.

I don't think there is an algorithm. It will depend on the mobile's traffic and
on the particular network configuration.

> new point of attachment.  I'm not sure whether that's YES or NO!

I don't think this can be made deterministic. I think it will depend on the
traffic mix, network configuration, etc. At best, I think it is a SHOULD, with a
MAY allowing the MN to decide based on movement pattern and traffic mix.

            jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 17 Sep 2002 14:38:51 -0700

Hello Jim,

> them need to be sized correctly for the expected load.

It would be nice if the protocols would decrease, rather than
increase, the expected load.

> I don't understand this issue.

1. Subnets are organized according to prefixes.

2. The old CoA does not conform to the prefix of the
   subnet where the mobile node resides.

This is the issue.

>                              On the wired side, the packets are coming out of

Hmmmm...  IP topology is irrelevant.  Hmmm...

Would you say that IP topology is irrelevant on an Ethernet?

Furthermore, one could say that the purpose of the FA is to
localize the damage caused by topological incorrectness.
Mobile IPv6 does one step better by localizing it _at
the mobile node_.

> not the Home Agent considered similarly?

Indeed, the function of the home agent is to introduce a
controlled bit of topological incorrectness.  This is to
be minimized, and managed in a way which is transparent to
the other nodes in the Internet.

I believe it can be proved that (given IP addressability
and mobility of some nodes) at least one point of
such incorrectness has to be tolerated, and even that
one point is sufficient except for certain performance
and scalability considerations.

It should be a goal to minimize the introduction of
extraneous points, and we can indeed do so.

> the BETH draft, which allowed open tunneling.

You didn't make any particular point here, anyway not
responsive to my point that the competing design goals
have to be balanced.  Or else I just missed it.
What was the technical conclusion you were referring
to that was "opposite"?

Is this whole discussion supposed to be about use of
care-of addresses, or a justification for BETH (which
I do not know intricate details about)...?

> on the particular network configuration.

It seems to me that the fast handover draft is an existence
proof for the algorithm.  If there are cases where it does
not work, then that should be discussed.

> MAY allowing the MN to decide based on movement pattern and traffic mix.

In our development, it was quite deterministic.

Claiming that the local topology depends on things other
than physical media is dodgy, it seems to me, and requires
a tall order of justification.

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 17 Sep 2002 16:30:11 -0700

> Mobile IPv6 does one step better by localizing it _at

If you are so concerned about topological correctness as a hard and fast
principle, then we should give up on the tunneling optimization entirely and
suffer the performance hit of packets getting dropped while the MN is doing BU
to HA, RR with all CNs, BU to all CNs, etc. etc.

Optimizations often have this effect, they end up violating some kind of higher
level principle. For example, interfunctional reorganization in compiler
optimization. From the point of view of the source code, this is a gross
violation of the functional structure, but it can make the code run much faster
and be completely invisible in the running code if carefully done. The key is
that the optimization is not be visible at higher layers. As far as I can see,
there are no negative side effects of this optimization visible at the transport
and application layers, can you see any? As for the routing, it is true that
there will be source routes hanging around longer, and this is a concern, but if
the specification requires that the MN change its care of address eventually,
they will go away.

> and scalability considerations.

And performance is exactly what is at issue here.

> extraneous points, and we can indeed do so.

Agree.

> What was the technical conclusion you were referring

By "opposite" I mean that we included the possibility of the MN hanging on the
its care of address until it decided to change it, rather than specifying that
the MN had to change it's care of address immediately upon movement.

I guess I am at a loss to understand why this is such an issue, since even _base
MIPv6 movement detection_ doesn't require (e.g. MUST) that the MN change it's
care of address when it detects that it has moved. Here is the relevent text
from Section 11.4.1:

   While a mobile node is away from home, it is important for the mobile
   node to quickly detect when its default router becomes unreachable.
   When this happens, the mobile node SHOULD switch to a new default
                                                           ^^^^^^^^
   router and potentially to a new primary care-of address.

All I'm asking for is that the fast handover spec provide the same kind of
support. That the MN SHOULD change its care of address when it detects that it
has moved, but it MAY continue using the care of address for a period of time,
to be determined by the MN in order to optimize some aspect of traffic,
movement, etc. During that time, of course, the network must support the MN by
keeping the tunnel active if possible. If not, it can send the MN a hint, like
an RA, indicating that the MN had better change soon or lose the tunnel.

            jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 17 Sep 2002 16:46:19 -0700

Hello Jim,

> to HA, RR with all CNs, BU to all CNs, etc. etc.

Don't throw the baby out with the bathwater.  In every note so
far, I have tried to stress the need for engineering balance
adhering to known design principles.  I'm not painting a black
and white picture, and I hope you'll step back from characterizing
my discussion in that way.

> the MN had to change it's care of address immediately upon movement.

I guess that the word "immediately" should be changed
to reflect whatever the protocol requirement is.
Does that word appear in the specification?

>    router and potentially to a new primary care-of address.

You are right, that the base specification has this language
from the very beginning.  As I remember, the idea was that the
mobile node could shoot itself in the foot if it wanted to.
Here we are talking about whether or not to insert longer-lasting
host routes into the network to which the mobile node wishes
to attach.

> movement, etc.

I think that the conditions for such continuance have to be
spelled in very precise detail, and that access routers might
consider old care-of addresses as cached entries which are
subject to purging after some agreed-upon time.

> During that time, of course, the network must support the MN by

This sounds to me like a deterministic mechanism that could be
worked out and compared to the existing solutions.

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 17 Sep 2002 17:56:15 -0700

Hi Charlie,

I think we may be beginning to converge.

> subject to purging after some agreed-upon time.

On the MN side,  I don't see any way to specify anything deterministic. I think
it should match the base Mobile IPv6 spec in this regard. On the network side,
see below.

> worked out and compared to the existing solutions.

On the network side, I think the following is needed:

1) The AR sends the MN an RA prior to the expiration of the tunnel if the AR
isn't willing to renew the tunnel due to policy or operational reasons. This is
a hint to the MN that it had better get its new CoA changed soon or risk losing
its traffic. The MN then responds by starting the CoA change. By "soon" I think
we need to provide some default value.

2) The AR can optionally renew the tunnel periodically, for some amount of time
specified by policy set at the discretion of the network operator. This is
necessary also for an MN that changes its CoA right away, if the RR and BU
messages take longer than expected, as might be the case in a particular
deployment situation. The default tunnel lifetime should be specified in the
spec, the current default looks OK, but I think this might be subject to a bit
more experimentation and maybe simulation to determine an optimal value
(ideally, the AR should rarely have to renew the tunnel for the default case).
The tunnel lifetime should also be configurable.

3)  I believe the MN sends out a Fast NA as the final signal that it is fully up
on the new link. If this is after all RR and BU to CN have completed, the AR can
use this as a signal to terminate the tunnel.

How does that sound?

            jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 18 Sep 2002 08:50:03 -0700

Hello Jim,

 
> it should match the base Mobile IPv6 spec in this regard. On the network side,

Whatever the mobile does has to coordinate with the access
routers timewise.  I'm imagining that, while it's getting
a new care-of address, it's allowed to use its old care-of
address to source packets.  While it's finishing the
binding update procedures, it's  a tunnel endpoint for a
tunnel from the old access router for packets sent to the
old care-of address.  This is a mechanism that has a
well-defined start point, process, and end point.
Timeouts apply, and should be dimensioned according
to analysis of base Mobile IPv6 protocol constants.
A binding update sent to the previous access router
for the old care-of address will have a lifetime request,
and that lifetime should be calculated by the mobile
node to conform with reasonable protocol needs.
That would be seconds, not minutes.

> we need to provide some default value.

If the tunnel is established by way of a Binding Update, then it
has a lifetime.  See above.  Furthermore, the Care-of Address
change ought to proceed immediately, regardless of the tunnel
lifetime.  For Mobile IP, this is the point of doing any work
at all on fast handovers.

> The tunnel lifetime should also be configurable.

I can interpret your suggestion here in a way that is
entirely do-able by way of Binding Updates for the
old care-of address with the new care-of address.
Experiments to find out the time requirement would be
good.

Furthermore, all of this would be much better with
Binding Updates included with data, and with renewal
verification of the care-of address only for return
routability-based security establishment.

> use this as a signal to terminate the tunnel.

Fast NA is related to the new care-of address, and not directly related
to return routability.  The tunnel lifetime can be handled independently
of considerations about care-of address acquisition.

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Wed, 18 Sep 2002 10:51:55 -0700

Charlie,

Hmm, maybe we are not converging after all.

> well-defined start point, process, and end point.

That's not how I envision it.

The way I see it, the MN may decide that it wants to keep the old care of
address for some longer time. Typical reasons might be:

- Pending intertechnology handover to a subnet supporting a different access
medium. Setting up the care of address on the new subnet may require more time
than doing the intertechnology handover.

- Rapid movement to another subnet, in which it does not have enough time on the
new access router to complete handover before moving to a third access router.

- An ongoing real time stream (example: voice call) over a low bandwidth link
that the in-band BU/RR signaling to the HA and the CN would disrupt.

Timing of care of address change is at the MN's discretion, and the spec should
provide support for policy that allows the network to support sending traffic to
the MN, while at the same time, tools for the network to provide hints that, as
you put it yesterday, the MN would be shooting itself in the foot if it didn't
start changing its care of address now.

> That would be seconds, not minutes.

I don't think one can generalize like this about how long it will take. It will
depend both on the MNs choice and on the network deployment and instantaneous
congestion conditions. If the MN has to retry RR, for example, it could easily
be much longer. The network operator needs the flexibility to configure the
tunnel lifetime as appropriate for the particular deployment.

> at all on fast handovers.

Like I said in the orginal email, there needs to be mechanism to renew the
tunnel periodically, if the network policy so specifies. This is a policy
decision that must be at the _network operator's_ discretion. The operator
should have the ability to configure the network so that the MN has maximum
freedom to choose when it wants to change its care of address. Simulataneously,
the spec should provide guidelines recommending that the MN change its care of
address immediately upon changing subnet as the generally most efficient course,
but not requiring it.

> routability-based security establishment.

I would have to see a specific suggestion for a signaling sequence.

We have implemented the design I described, which comes out of the 04 draft, and
the implementation works fine. The tunnel management including renewel isn't
difficult to implement, the hard part was getting the timing on the SolPrRtAdv,
PrRtAdv, FBU, FNA, etc. right, which is completely orthogonal to the tunnel
management. If the Layer 2 triggers are there, tunneling without any of the
prehandover signaling is by far the easiest and cheapest way to optimize
handover.

We did not look at larger system issues, and I suppose we could do a couple of
simulations to explore this, but I would like to avoid any repeat of the MANET
"dueling simulations" experience if possible. We had some success in MWIF by
establishing a baseline simulation upon which the contending parties agreed then
working on the contentious issues from there. We could try that if it looks like
there is interest.

> of considerations about care-of address acquisition.

In the first sentence, you say that NA is related to the new care of address
establishment, and in the last that there is no relationship between the new
care of address and the tunnel lifetime. The point of the tunnel is to allow the
MN to continue receiving packets until the new care of address is, in fact,
established, so there seems to me to be a quite intimate relationship between
establishing the care of address and the tunnel lifetime. Fully establishing the
care of address requires than RR and BUs to all CNs performing RO complete, else
those CNs will end up sending packets to the old subnet that get dropped.

            jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 18 Sep 2002 11:08:16 -0700

Hello Jim,

Unfortunately due to travel requirements, I can't
give this the attention it deserves.

However, I do have a question.  If your mechanism
doesn't care about care-of address management, then
why is it relevant to anything in the [mobile-ip]
working group?

Regards,
Charlie P.

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 18 Sep 2002 11:29:24 -0700

> it should match the base Mobile IPv6 spec in this regard. On the network side,

Sorry, but what should the MN do if it receives an RA ? In general,
what should it do with ND ?

> use this as a signal to terminate the tunnel.

FNA is used to confirm a NCoA as soon as a link is established. It has nothing
to do with RR or BU.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Wed, 18 Sep 2002 11:40:46 -0700

Hi Charlie,

> why is it relevant to anything in the [mobile-ip]

Can you point to something in my email that leads you to make this statement?

I believe the issue under discussion is, precisely, care of address management
and how to go about arranging for it after a fast handover. We seem to have two
very different conceptions about how that should be done.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 18 Sep 2002 15:21:02 -0700

James Kempf wrote:

> When the MN receives an RA, it should begin the process of changing its care of
> address. As for what should be done about ND, I believe that is currently under
> discussion in the IPv6 working group (and also here). There have been a number
> of proposals for either removing ND, deferring it, or optimizing it out.
> Whatever falls out of that discussion would be applicable.
>

OK. So, the MN processes RA, could even send a RS then. In other words,
behave like any other node. This is fine with me.

> Why? What depends on receiving an FNA? I thought the purpose of sending an FNA
> was to signal to the new AR when the care of address was fully configured on the
> link.
>

FNA is sent when the NCoA is not confirmed via an FBACK. So, imagine
a MN sends FBU, leaves link and sends FNA. The NAR then confirms NCoA,
which the MN can use to do RR and BU. So, FNA preceeds RR and BU.

BTW, I would like to make FNA an option in RS so that there is a cleaner
RS - RA (with NAACK option) correspondence.

-Rajeev

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 18 Sep 2002 20:53:36 -0700

Hello Jim,

I asked my question after some while trying to understand
what you want, in terms of what a Mobile-IP related protocol
could reasonably supply.

If the mobile wants to get a new address, it can
do that.

If it wants to register a new address by way of
Binding Update, it can also.

So far, no new protocol.

If it wants to make a tunnel to a tunnel endpoint
that IS NOT topologically correct, then that seems
qualitatively different than trying to make a tunnel
to a tunnel endpoint that IS topologically correct.
Since Mobile-IP deals with tunnels to topologically
correct endpoint addresses, the former goal seems
out of scope.

If it wants to do something related to care-of addresses
during handover, we can devise a streamlined mechanism
that deals with care-of addresses.  Your mobile nodes
don't have to use it, and then they can do the normal
thing whenever they are ready.

If a handover mechanism does not deal with care-of
address management, then I do not think it belongs
in the [mobile-ip] group.  Your messages seem to ask
for some way that the mobile node can do a fast
handover without initiating any process for getting a care-of
address.  I don't think that's work that belongs in this
group.  In fact, I thought that [seamoby] was created
just for the reason that people who wanted "micromobility"
solutions were looking for another home.

If it's not involved with getting a new care-of address
during handover, I don't see it as relevant to this effort.

I hope this reasoning explains my short question.

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Wed, 18 Sep 2002 13:58:13 -0700

jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 19 Sep 2002 08:44:55 -0700

Charlie,

Perhaps I am not communicating clearly, but I seem to have given you the wrong
impression about how I believe fast handover should work in the context of
Mobile IP.

I am not going to try to answer your email below, as I don't see any specific,
technical points that I can answer. However, I have some specific technical
comments relating to the current design and the disucssion that you, Rajeev, and
I have been having that I will be sending out, hopefully later today.

            jak