Subject: [mobile-ip] FMIPv6 protocol changes

From: Rajeev Koodli <[email-masked]>
Date: Mon, 16 Jun 2003 15:22:15 -0700

Hello folks,

after talking to many of you about the remaining
steps needed to progress the draft, and re-reading
the draft, I have come up with the following.

- clarify FBU transmission from the new link.
Specifically, it would be useful to have FBU
sent with NCoA as source IP address so that
issues surrounding ingress filtering etc could
be avoided to begin with. And, packet
forwarding could ensue for topologically
consistent address for packets tunneled from
the previous router.

- role of Three Party Handover. It would be
better to keep the scope of the draft to simple
scenarios and fall back to base Mobile IP during
error cases. I am proposing that Section 4.6, which
specifies TPH using L2 signaling, be deprecated.
This text might be useful in a separate document
that _could_ specify further optimizations to
FMIPv6, if such thing is seen as useful in the future.

- role of L2-optimized handover, i.e., Section 4.5.
It has always been an issue to address L2-L3 interaction
to improve performance. What if we focus (back!) merely on
IP protocol specification and leave the "vertical integration"
out, perhaps to some other time and place ? I think this
would impart substantial simplification to the protocol
behavior. At the same time, some illustrative text on
L2 triggers causing protocol invocation would be needed.
Any takers ?

- text specifying securing FBU. Multiple mechanisms
could be used to establish security association between
the MN and its AR. I heard Anonymous DH (from Erik)
during last IETF. Perhaps we should specify that, along
with its short-comings, for the case when nothing else is
available ? Please note I am not suggesting we solicit
proposals to solve this issue; we have concluded that
discussion.

Comments ?

-Rajeev

---

From: "Youn-Hee Han" <[email-masked]>
Date: Tue, 17 Jun 2003 10:16:02 +0900

I have one question for crarifying some techincal points.

> consistent address for packets tunneled from

If MN sends FBU with NCoA as source IP address 
from the new link, IMO, at the point of time, the NCoA
is not guaranteed its uniqueness. Do you think there is 
no problem although such a non-confirmed one is used as 
source IP address?

- Youn-Hee

---

From: "James Kempf" <[email-masked]>
Date: Tue, 17 Jun 2003 11:20:51 -0700

Rajeev,

I support these changes. Now that the protocol is going to
experimental, there is no reason to try to cover all cases, and I
think the protocol can be made simplier by focusing on what it does
well, namely supporting both predictive and reactive mobile controlled
handover, and dropping the rest. Other forms of handover can be
supported by other protocols in other experimental specifications,
possibly including components from FMIP.

In that vein, I would suggest an additional change: dropping tighly
coupling unsolicited PrxyRtAdv with handover in support of network
controlled handover. The problem is that if the handover is truely
network controlled (i.e. the mobile has no say in when it moves at
Layer 2) having predictive information doesn't help accelerate the FBU
because the mobile can't control keeping the old link stable long
enough to make sure that the FBU/FBack sequence is sent and received
without error. We've done lots of experimental work on this, both for
FMIPv4 and FMIPv6, on a variety of wireless protocols (cellular, WLAN,
emulation).

The other aspect of network controlled handover is that the wireless
Layer 2 protocols that support network controlled handover are
cellular protocols, and these protocols have little or no interest in
FMIP. 3GPP has GTP/GPRS and 3GPP2 has stretchy PPP for fast handover.
While one could argue that "future protocols may need support", right
now, it is hard to know exactly what sort of support they will need
because they don't exist. The FMIP design has benefited enormously
from focussing on 802.11 and what can be done with an existing
protocol. When the time comes, better to revise the spec when it goes
to PS or write another one with support for network controlled
handover than to introduce something speculative that may or may not
work.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 17 Jun 2003 12:06:00 -0700

> no problem although such a non-confirmed one is used as

I will be providing the text on this, hopefully soon.

-Rajeev