Subject: RE: [mobile-ip] I-D ACTION:draft-mccann-mobileip-80211fh-01.txt

From: "Karim El-Malki (EAB)" <[email-masked]>
Date: Thu, 7 Nov 2002 15:19:41 +0100

We need a default mechanism in FMIPv6, otherwise the draft can't
be implemented and can't fulfill the low latency purpose. RtSolPr is
simple enough for this purpose. If later people want to augment FMIPv6
with Seamoby CARD when it is done since it improves FMIPv6 then no
problems. I'm not against this, but I'm not in favour now of making
FMIPv6 depend or wait on other specs.

 > 
 > > The spec correctly has a default way
 > > to do movement detection and uses PrRtAdv to do that (in 
 > addition to L2
 > > triggers). The MN doesn't have to send the F-BU 
 > immediately, it could send
 > > it after moving. I wonder why it would need to do this 
 > rather than updating
 > > the HA or local HA (i.e. MAP which is likely to be as 
 > close as the old AR)
 > > but let's put this aside for the moment.
 > 
 > Because if the HA is on the other side of the ocean and the 
 > operator chooses not
 > to deploy a MAP, then it will take upwards of 160 ms to 
 > complete. If it is on
 > the other side of the continent, it might take 50-60 ms to complete.
 > 
 > Deploying a MAP is the operator's choice, and some operators 
 > won't want to do
 > it.

Following this logic, Fast Handoffs is also an operator's choice
and some operators may not want it. That leaves us with nothing.
Instead I think we should talk about the solutions that are available.
The MAP (simple local HA) is a solution which can't be discarded
like that since it is valid for the above scenario.

 > 
 > > Simplicity is good, but you can't cut down beyond a 
 > certain point otherwise
 > > the document becomes incomplete. In fact, IMO adding the 
 > tunnel-based handover
 > > made it much more complex than what Rajeev had earlier.
 > 
 > The tunnel has been there since the first draft. The 
 > difference is that it
 > initially ran to the mobile node, the new draft allows it to 
 > run just to the
 > access router, and provides for 3 way handover in case the 
 > mobile must move
 > quickly before RR completes.

The original solution had the tunnel terminated in the MN.
Terminating the tunnel in the MN would have made it straightforward
to set up the tunnel only when both F-BU and HACK had been received.
Although it isn't clear, I imagine the tunnel is instead set up upon
HACK and traffic forwarding is performed after F-BU. So I'm in favour
of changing things back the way they were, since the idea is to
anticipate the handoff and the use of nCoA not to enable the use
of PCoA at the new AR. It seems like a different problem to me.

 > 
 > >Also, 802.11 is a good starting point but I thought we agreed
 > > that the basic FMIPv6 spec would not be based only on 
 > 802.11 requirements,
 > > otherwise we'll have to do a new FMIPv6 spec per 
 > link-layer. I don't want to
 > > get into the discussion of which other link-layers there 
 > may be, since there
 > > won't be any link-layer which provides triggers if there's 
 > no IP protocol
 > > like FMIPv6 requiring them. It would just get us nowhere. 
 > So I'm in favour of
 > > not hacking the basic FMIPv6 spec to pieces and let the 
 > implementers finish
 > > the job they have started. There are people who are 
 > implementing it.
 > >
 > >
 > 
 > The point is to complete a *standard* that is implementable 
 > using existing link
 > layers.
 > 
 > If the intent is to do something experimental, then the 
 > draft should become an
 > experimental RFC.

So if it is implementable with current link-layers is that ok?
I hadn't heard of such a requirement before, I thought it was enough
if the WG saw a need for this protocol (within the WG charter) which
would lead to implementations and interops. Anyway, since people are
working on this I'd leave them time to finish before jumping to
conclusions on the draft being experimental.

Rgds
/Karim

---

From: Pete McCann <[email-masked]>
Date: Thu, 7 Nov 2002 11:12:26 -0600

Hi, Karim,

 > of PCoA at the new AR. It seems like a different problem to me.

I would hope we keep this functionality.  It seems important to be
able to defer CoA establishment to keep it off the critical handover
path.

-Pete

---

From: Greg Daley <[email-masked]>
Date: Fri, 08 Nov 2002 12:03:33 +1100

Hi Pete,

I'm not so sure that tunneling is so tied to
address acquisition, if a CoA can be acquired
quickly.

If DAD is not being done (I don't like this idea)
or if an optimization technique is in place,
address acquisition needn't take siginificant time
on the new link (or may be acquired before
PrRtrAdv is sent, during anticipation).

Once the address is acquired, Address ownership
mechanisms can be completed quickly (RR??), or hidden
by tunnels (BET/HMIP/BU to oAR).  The acquisition
of the address needn't be the cause to keep the
tunnels.

Indeed, the tunnel decapsulated by the nAR is less
necessary if the address on the new link is
immediately valid.  You may as well tunnel to the MN.

Greg

---

From: "James Kempf" <[email-masked]>
Date: Fri, 8 Nov 2002 08:27:55 -0800

> address acquisition, if a CoA can be acquired

The CoA isn't valid until HA binding update RR completes.  And this depends on
network load, whether LMM is deployed, etc. Until the CoA is valid, the tunnel
can't be taken down.

So I think it is tied to CoA aquisition, and I don't think the latency of CoA
aquisition is entirely controlled by local conditions.

            jak

---

From: Pete McCann <[email-masked]>
Date: Fri, 8 Nov 2002 11:42:56 -0600

Hi, Greg,

Let me make this attempt at clarifying the issues, by listing the
steps that we have to go through:

1) Discovery of new ARs IP address
2) Obtaining a CoA from the new AR
3) Establishing a tunnel from old AR to new AR
4) Establishing packet forwarding state on the tunnel
5) Updating HA and CN bindings for the MN

Note that these may be done in a slightly different order according to
the scenario involved.  They could be done at different times and with
the use of different mechanisms.

A fast handover scheme will perform well if time-consuming operations
are moved off of the critical path between the time a need for
handover is detected and the time at which it actually occurs and IP
traffic can again be sent/received.  This can be accomplished by
moving steps well in advance of handover or by defering steps until
well after handover has completed.

Now, it seems like the current FMIPv6 munges together steps 1-3 and
they are all triggered by PrRtSol/Adv, and the draft assumes that all
of these things happen right around the time of handover.

I agree that if we have a mechanism for acquiring a CoA in advance, or
if we have some means of optimizing the CoA allocation, then there is
less of a need for supporting an new AR-terminated tunnel.  However,
because anticipation or optimization isn't always possible, I would
like to retain the mechanism that allows us to defer CoA configuration
until after handover.

-Pete

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 08 Nov 2002 10:02:51 -0800

Hello Pete,

> of these things happen right around the time of handover.

This is not entirely accurate. The MN needs the MAC address of the
new router to send packets immediately upon connecting to it. PrRtAdv
provides that, along with the new AR prefix information.
Of course the MN can do RS and receive an RA, and then send packets,
which it has to anyway when it cannot engage in signling on the previous
link. So, PrRtSol/PrRtAdv are available to get the new AR's MAC
address and configure a prospective new IP address. In the _meanwhile_,
support for Previous CoA is established. I don't see the latter being
serialized because of anticipation.

> like to retain the mechanism that allows us to defer CoA configuration

I agree to this. It is safer to terminate the tunnel at the new AR.

Regards,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 8 Nov 2002 10:28:59 -0800

Rajeev,

> serialized because of anticipation.

I think the point Pete is trying to make and that he makes well in his draft is
that this is difficult to not possible with current firmware on 802.11. We need
a way that will work if prehandover signaling isn't possible.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 08 Nov 2002 10:41:29 -0800

> a way that will work if prehandover signaling isn't possible.

There is no argument about the need for establishing routing support
subsequent to handover.

The point that Pete is making is valid to the same extent that there is
a need for AP - AR communication in the absence of IP messages.
So, there are possibilities which implementors can provide better
input on. We should not shut the door on them.

-Rajeev

---

From: Pete McCann <[email-masked]>
Date: Fri, 8 Nov 2002 14:01:28 -0600

Hi, Rajeev,

 > serialized because of anticipation.

I wasn't talking about support for Previous CoA (which I assume is
like the ingress filter "pinhole" that James has been talking about),
rather for the new CoA.  The PrRtSol/Adv is trying to provide AR
discovery, tunnel establishment, and new CoA configuration.  It is not
serializing anything; to the contrary, it is trying to do all three
simultaneously.  Because anticipation (and exchange of these messages
prior to handover) doesn't seem likely to me in an 802.11 deployment,
I would like to focus the draft on how to most rapidly re-establish
service at the new AR after an unanticipated handover has taken place.

 > I agree to this. It is safer to terminate the tunnel at the new AR.

Ok, good.

-Pete

---

From: Greg Daley <[email-masked]>
Date: Mon, 11 Nov 2002 12:08:22 +1100

Hi James,

there's no need for RR to the HA at all.

The MN has a security association with the HA, which
protects the binding signalling, and proves the identity
of the MN, and protects the binding addresses (in AH's case).

In this case, the real HA, and the oAR can each
work as a HA, forwarding packets to the MN's address
on the new access network, without having interference
from the nAR. This means that the nAR only requires
the ability to respond to HI (without setting up a tunnel)
and maybe act as a home agent in the future, if the
MN moves away.

This especially can be done, if the MN and oAR know the
address on the new link is validated (as advertised in
the HAck/PrRtrAdv(/CARD?)), or optimistic DAD is allowed.

All this complex decapsulation and caching behaviour in
access routers is possibly a premature optimization,
if address acquisition (which has to be improved anyway)
can be made to run faster.

When the tunnel is established (bidirectionally?)
the MN can do RR to the CN's if it likes
(or if this is necessary, we did talk about LMM before...).
This is where I see that the tunnel could be required.

Greg Daley

---

From: Greg Daley <[email-masked]>
Date: Tue, 12 Nov 2002 07:49:18 +1100

Hi Pete,

Sorry about the late reply,

I think that you're right about assumptions of what is to
occur when a FMIPv6 handover takes place.
I think that it's relatively simple to determine *if* the
address acquisition is an issue when the MN anticipates
the handover.

The MN can request the oAR/nAR *not* to set up a tunnel,
if the address is already valid. If the oAR/MN learn
that the address is  valid, you don't need 3/4,
and can replace it with a much simpler mechanism (MIPv6 BU?).

In the case where the MN doesn't anticipate the handover,
we shouldn't rely on FBU/FBACK, since we're already in
possession of an IP address in order to send the message
to the oAR, and the oAR wasn't previously aware of our movement.
This is the correct usage for BU to the oAR which
was removed from MIPv6 base draft (issue 72).

In the case where address acquisition optimizations aren't
allowed and we haven't anticipated the handover...
we don't know how often that will occur (so why optimize?).

Greg

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Nov 2002 14:29:39 -0800

> and can replace it with a much simpler mechanism (MIPv6 BU?).

This is too complicated. Just using the old address until the MN has completed
HA BU and RO is a lot simpler. Also, what about the packets lost when the MN is
doing RR and BU to CNs?

> we don't know how often that will occur (so why optimize?).

Disagree. This is an architectural confusion between changing the routing id to
node id mapping and changing the routing for an existing, allocated address.
These are two different cases and they should be handled separately.

Until the MN completes HA BU and RO, the new care of is not fully configured.

            jak

---

From: Pete McCann <[email-masked]>
Date: Mon, 11 Nov 2002 16:50:40 -0600

Hi, Greg,

 > address acquisition is an issue when the MN anticipates

Sure, if anticipation is possible in a given link environment.

 > and can replace it with a much simpler mechanism (MIPv6 BU?).

It seems like this is just a matter of which CoA to put in the BU.  If
the MN wants a tunnel terminated at nAR, it can put nARs address in
the BU.

 > was removed from MIPv6 base draft (issue 72).

Right, and we should support this, but I am also trying to cover the
case where no CoA was established yet.

 > we don't know how often that will occur (so why optimize?).

It doesn't seem that difficult to me to create a message that goes
from MN to nAR, where it is processed, and then forwarded to oAR,
where it creates packet forwarding/tunnel state, and returns a reply,
which is sent to MN via nAR.  The nAR can then insert host
routes/ingress pinholes as needed.  This is similar to MIPv4, but I
suppose it is a bit more complexity than is contained in the current
MIPv6 BU.

-Pete

---

From: Greg Daley <[email-masked]>
Date: Tue, 12 Nov 2002 10:38:06 +1100

Hi James,

It seems that you're assuming that what I'm asking
for is a complete elimination of tunnelling.

That's not what I'm talking about really.
I'm really discussing the current system which
overloads HI/HAck to set up a tunnel between ARs
which may not be necessary if the MN's address is
already valid (or we're optimistic that it is).

The MN may set up a bidirectional tunnel with the
oAR before it leaves the old access network, which points
to its address at the new access network.

This tunnel is under control of the MN and requires no
added function in the nAR. RR occurs using reverse
tunnelled packets from MN to oAR, which is an equivalent
function to the current BET function (albeit with
more overhead per packet on the access link).

The only packets lost are those discarded from the
output queue of the nAR while the MN is changing L2 links.
This may not even be an issue if there is a large enough
queue for non-neighbor resolved packets.

The issue is simple, if the MN requests certain function:
'don't make a tunnel to the nAR' in the PrRtrSol, then
the construction of the tunnel to the MN can be handled by
FBU or BU (whichever is semantically appropriate).

It could even be 'Make the tunnel to [XY]', but I'm
not sure that the PrRtrSol/HI should be the mechanism to
do this, unless the PrRtrSol/HI asks for this explicitly.

Greg

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 11 Nov 2002 21:30:02 -0800

> suppose it is a bit more complexity than is contained in the current

eFWD does that.

http://www.ietf.org/internet-drafts/draft-gwon-mobileip-efwd-fmipv6-00.txt

alper

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Nov 2002 00:32:27 -0800

> more overhead per packet on the access link).

Isn't the return address on the RR packets the new CoA? So it would not need to
go through the tunnel if the tunnel is set up between the routers. Much more
efficient.

> queue for non-neighbor resolved packets.

I don't think so. If the CN is sending packets at, say 20 ms interarrival time
and it takes 200 ms for a RR/BU to CN to complete as would be the case if, say,
the CN is in Japan and the MN in Minneapolis, then the MN will lose 10 packets
that are sent to the old CoA.

I think you are assuming that HMIP will always be in use. This is not the case.
Some carriers will deploy HMIP for other purposes (namely location privacy) and
others won't deploy it at all. FMIP can't depend on having HMIP deployed.

I agree, however, that if HMIP is deployed such that the LCoA update time is
less than the interarrival time, the need for the tunnel is less. But even then,
the LCoA update time will be variable, and a tunnel on the edge is much less
likely to run into problems with congestion IMHO.

> do this, unless the PrRtrSol/HI asks for this explicitly.

The tunnel is set up because the routing fails. Why should the MN be involved in
this if the routers themselves can figure it out? If a router fails behind the
last hop router, should the MN have to arrange for its routes to be changed? Of
course, if the MN finds out that its routing has failed and the new last hop
router doesn't know (such as with 802.11), then there should be some way for the
MN to tell the new last hop router, so that the tunnel can be set up.

            jak

---

From: Greg Daley <[email-masked]>
Date: Wed, 13 Nov 2002 09:15:29 +1100

Hi James,

Yes, sorry I lost my mind there yesterday.
The reverse tunnel is for continuity while you
do RR directly from the nAR's network.

The tunnel is from the oAR to the MN, which is likely(?)
to not have the same RTT as MN->CN/HA.
As you seem to indicate, the same could be done in a MAP,
but I'm not relyiing on that.  What I'm indicating is that
if the MN knows it is moving then it can use the F?BU
to the oAR to indicate that the handover is occurring.

The tunnelled packets arrive at the nAR, with a destination
address of the MN's new address.  Packets which are sent
down this tunnel do not get sent onto the link unless there
is a neighbor cache entry in the nAR for the MN's new CoA.

If the MN arrives (after performing L2 handover), it sends
an NA, and starts receiving traffic from the tunnel.  Some
packets may be discarded before this occurs, depending on
the NC queueing behaviour for packets with unresolved L2
addresses.

This is not dependent on the RTT to the CN or HA, rather
being similar to the handover smoothing mechanisms previously
in MIPv6. It is dependent on the L2 handover time, which is
important anyway for Real Time applications, since it
predetermines the jitter buffer size.

The reason to involve the MN in the tunnelling decisions is
to move all the complexity out to the devices which scale best
(MNs). The tunneling between two AR's is more complex than
this solution, because it requires special ingress filtering
and routing in what should be a very low cost device (the AR).

Also, since you mentioned it, if you don't want to have
psuedo-HA function at all in the ARs, you can put it in the
HMIPv6 MAP.  This will work regardless of whether the tunnel
terminates at the nAR or the MN (if the MAP is close enough).

Greg,
Who likes HMIPv6, but understands it's not for everyone.

---

From: Greg Daley <[email-masked]>
Date: Wed, 13 Nov 2002 09:15:29 +1100

Hi James,

Greg,

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Nov 2002 00:32:27 -0800

jak

---

From: Pete McCann <[email-masked]>
Date: Mon, 11 Nov 2002 16:50:40 -0600

Hi, Greg,

-Pete

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Nov 2002 00:51:34 -0800

> to not have the same RTT as MN->CN/HA.

Actually, its oAR to nAR. The nAR won't route the PCoA on the new link, so the
tunnel must terminate there.

> is a neighbor cache entry in the nAR for the MN's new CoA.

But if the MN moves without any prehandover signaling (as in 802.11) the new CoA
isn't available yet. For consistency, this case should be handled the same as
when there is a new CoA available through anticipated CoA configuration. That's
why the PCoA should be used for the tunnel.

> the NC queueing behaviour for packets with unresolved L2

NA is unnecessary and should be dropped. In the anticipated CoA configuration
case, there should be an invariant: either the MN has a valid, usable CoA when
it gets on the link or not. MN should never be "unsure" about new CoA status.

> and routing in what should be a very low cost device (the AR).

The ingress filtering will be required anyway. I think the AR is in the best
position to handle the tunnel, because the point of the tunnel is to fix up a
routing disruption. The MN hasn't yet (or can't in the case of no anticipated
CoA configuration) completed CoA establishment.

> terminates at the nAR or the MN (if the MAP is close enough).

Yes, but I want to use HMIP for location privacy. Don't care about optimized
handover with it. The two uses are conflicting. I'd like to keep optimized
handover as a router function.

            jak

---

From: Greg Daley <[email-masked]>
Date: Thu, 14 Nov 2002 11:14:57 +1100

Hi James,
This is getting long, but it's all pretty interesting.

(Replies inline)
Greg

> tunnel must terminate there.

I was actually proposing an alternative, where the tunnel
packets for the MN arrive at the PCoA (on the oAR), and are
tunnelled with Src:oAR,Dest:NCoA[Src:OrigSrc,Dest:PCoA] to
the MN's new location.

There would be a reverse tunnel from the MN to the oAR for outbound
packets:   Src:NCoA,Dest:oAR[Src:PcoA,Dest:OrigDest]

There is no problem routing this on the new access network.
This is equivalent to the nAR doing the work, at the cost of
packet overhead, and with the benefit of correct neighbor cache
entries on the MN ;)

> why the PCoA should be used for the tunnel.

It is available yet, if we're optimisitic.
What I'm saying is that if the MN can acquire an address
in almost no time (optimistic DAD or pre-handover signalling),
then there's little to be gained by having the tunnel terminate
in the nAR, rather than the MN.

> it gets on the link or not. MN should never be "unsure" about new CoA status.

I don't mind about getting the address in advance.
We know it won't be do-able with RFC 2462 DAD though.

The NA was just an idea to collect packets already waiting
in the nAR's ND Queue destined for the nCoA. Simply
responding to an NS is fine though (if you arrive on the
new link before packets arrive).

> CoA configuration) completed CoA establishment.

*Static* ingress filtering will be required anyway
( two rules:
in to internet:
       only allow packets with my prefix as source,
out to access net:
       only allow packets with my prefix as destination).

Tunnelling  requires a dynamic rules for each
MN it supports  (with timeouts &etc).

Routing disruption or not though, there's no reason why packets
cannot be reverse tunnelled to the oAR by the MN. The oAR doesn't
need the same RR or other address acquisition mechanisms, and
we're only slowed by DAD on the new link.

The proposal I had was speculative, but is very easy to
accomplish if the DAD Optimizations currently proposed
scale well.

> handover as a router function.
That sounds like another interesting discussion.
Should we talk about it later at or after IETF?