Subject: RE: [mobile-ip] Draft on Mobile IP Architecture and Reorg

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Fri, 28 Feb 2003 06:09:11 +0100

> Local route repair is not a panacea for all possible situations. For
  > example, two geographically adjacent access routers are 
  > separated with
  > several hops away and with considerable delay. In this 
  > situation, local
  > route will experience performance degrade, while regional 
  > mobility will
  > achieve better performance.
  > 
  > From above we can conclude that these two solutions both 
  > have their own
  > locks that they are good at openning. For regional 
  > mobility, it happens well
  > before the packet arrives the destination link and is 
  > suitable for the
  > situation I stated above. For local route repair, it takes 
  > effect immdiately
  > after the packet arrives the destination link and is 
  > suitable for the
  > situation that previous and next access routers are not far 
  > in topology from
  > each other.
  > 
  > Therefore, I think there is need for regional mobility. The 
  > point is how to
  > combine regional and local more efficiently, and with low 
  > cost and less
  > complexity.

=> Amen... Please take a look at the appendix of HMIPv6
and please let the WG know whether there are better ways
of combining the two mechanisms. I'd love to get some 
feedback from anyone in the WG about this appendix. We got
many comments on HMIPv6, but never on the combination of 
the two mechanisms. 
While you're at it, you might also be able to read:
http://www.ietf.org/internet-drafts/draft-elmalki-mobileip-bicasting-v6-02.txt

It's pretty clear how it fits into this overall picture.

Hesham

---

From: "James Kempf" <[email-masked]>
Date: Fri, 28 Feb 2003 09:38:30 -0800

Hesham,

The draft is arguing that there is a separation between local and global routing
architecture for Mobile IP and that this separation should be reflected in the
organization of the WGs to do the protocol work. In normal IP routing, OSPF is
not used to advertise the default router to hosts, nor is it used on the
Internet backbone. There are separate working groups that do these protocols.
These protocols are separate and different and they are that way because there
is a natural architectural separation. The same applies to Mobile IP. Combining
these together in one working group has in practice been a disaster, IMHO.
Neither HMIP nor FMIP (and especially FMIPv4 even though it is complete!) has
made any progress in the last year and a half because the Mobile IP working
group has been concentrating on the base MIPv6 spec, which is fundamentally
about the global routing change (with a few minor tweaks to RFC 2461 thrown in).

About using HMIP for optimizing handover. I had a look at Appendix A of
draft-ietf-mobileip-hmipv6-07.txt. The mechanism proposed there requires address
preconfiguration, a particular deployment design, and a particular use of FMIP
HI/HAck signaling, as defined in the current
draft-ietf-mobileip-fast-mipv6-05.txt, but otherwise does not propose any direct
signaling between the MAP and the AR or MN that could be interepreted as mixing
together the local and global concerns regarding the handover routing change,
i.e. changes to RFC 2461. So I do not believe that this invalidates the
contention in draft-kempf-mobileip-arch-00.txt, about having a working group to
concentrate on the local link protocol. Such a protocol could include
preconfiguration. The actual protocol for HMIP could be done in the global group
or in a separate "regionalized mobility management" group, and the spec could
include something like Appendix A that describes how to use the RFC 2461++
protocol to do optimized handover (in the same way that
draft-ietf-mobileip-ipv6-20.txt recommends upping the router advertisement rate
from RFC 2461) for those that want to use HMIP for handover optimization, or the
use of HMIP for optimized handover could be in a separate draft. For myself, I
believe HMIP is too valuable for location privacy to squander on handover
optimization, but reasonable people can differ.

My larger concern is with FMIP, CARD in Seamoby, and the collection of
optimizations to RFC 2461 that have been kicking around the IPv6 working group.
There has been some sentiment expressed that there should be no "dependency"
between these protocols. In fact, they are intimately linked architecturally, as
Pekka and I outlined in our draft, and not designing them that way would result
in a mess, IMHO. In addition, some of the current features of FMIP mix global
MIP signaling into the local link protocol in a way that, again, I believe is
architecturally inapproprate. One of the beauties of the base MIPv6 design is
that it reflects the natural architectural separation in the protocol, and I
think it would be a mistake to do a remix.

Let's just agree to disagree on whether HMIP is good for handover optimization
or not and get on with trying to figure out how to achieve this reorg so that
the result is set up for success. Having just two working groups, one for IPv6
and one for IPv4, is, in my opinion, not likely to result in success.

            jak

PS: As to why I believe HMIP is more valuable for location privacy, the Japanese
regulatory authorities require location privacy for mobile phones, in the sense
that the owner of the phone must give permission for someone to obtain location
information about the phone. In IPv6, the location can be inferred from the
subnet prefix if the network is engineered with the usual mapping between
hierarchical routing topology and geography. For UMTS/GPRS systems, the GGSN
hides the location of the mobile terminal, and it will also do that for IPv6. It
can hand out IPv6 addresses at random without any mapping to geography because
hierarchical routing is not used below the GGSN. But for standard MIPv6 based
networks, HMIP is the only currently known way we have of being able to satisfy
this regulatory requirement. Therefore, wearing my Japanese service provider
hat, I would have to oppose any effort to tie HMIP more tightly to handover and
thereby preclude its use for location privacy, which is why I would like to see
Appendix A moved to a separate draft.

----- Original Message -----
From: "Hesham Soliman (EAB)" <[email-masked]>
To: "'Xiaoming Wang'" <[email-masked]>; "James Kempf"
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, February 27, 2003 9:09 PM
Subject: RE: [mobile-ip] Draft on Mobile IP Architecture and Reorg

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 28 Feb 2003 14:14:04 -0800

Hello Jim,

it is interesting reading, but I have several
comments.

- the separation based on global routing vs local
   routing is general. If you move from your home
   network to a new network, you would be some
   'n' IP hops away from your home network. Similarly,
    if you move from an access router to another, you
    would be some 'm' IP hops away from your previous
    point of attachment. So, I don't understand the distinction.

    However, a key question is whether you have a security
    association with your router. If you do, I don't see why you
    could not use it regardless of where you are.

    Another key issue is whether the MN is in charge of
    receiving its packets. If the control is in the hands of
    the MN, which is BTW the only model where we have
    some experience, then the MN has to ultimately
    authorize traffic redirection, regardless of how you characterize
   it (such as local routing repair, forwarding from previous address etc.)
    This means even if you are restricting MN's signaling to its current
    AR, which may then do signaling with the previous AR, the
     previous AR still needs authorization from the MN to redirect
     traffic.

     If you don't believe that the MN needs to be in charge of
     traffic redirection, that is a new model that needs a separate
     discussion (and not at the expense of current model in use).
     Some previous efforts on micromobility appear to have
     had this principle (i.e., the burden of mobility is on the network
     serving the MN) in mind.

- No matter what you call a node, some minimal funcitonality is
    needed to support mobility (at the Home Agent or AR). The node
    has to be able to defend the address on the link for a node that is
    off-link, and be able to tunnel packets meant for the address it is
    defending. In the mobile ip evolved model, it is the MN which informs
    the node to carry out those functions. I think that is a common
    denominator and perhaps an important principle; others can correct
    me here.

- It appears to me that many of the reservations, for instance
   against FMIPv6, are protocol issues in nature. For instance,
   sending FBU from the new link with previous CoA as source
   address. I think we have had some good discussion on topics
   such as this in the mobile-ip working group, and the draft
   reflects that thinking. Of course the draft revision is an
   iterative process and I fully expect that to continue. I don't see the
   need for a new working group when the current group is
   more than qualified to progress the draft.

- The dependency argument. When a protocol can be devised to
    be self-sufficient, it should not be cast as bad thing. How the
    protocol fits in an "overall solution" is a function of what that
   "overall solution" is, and is certainly not single-valued. I don't think
    we ought to define a vertically integrated system according to _a_
    notion of architecture.
    Having said that, the overarching goal should be to allow protocols
    to complement each other as much as possible. Specifically, with
    FMIPv6, I would like to do that. Who would like to offer solution
    for securing the FBU ?

I guess this is plenty for now. More later..

Regards,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 28 Feb 2003 16:34:27 -0800

>     point of attachment. So, I don't understand the distinction.

The issue is specifically what kinds of reachability information are required by
the node for routing? Nodes on the local link don't require reachability
information about nodes and routers other than those on the local link. Hence,
ND and RD. Routers in the local domain routing fabric require only require
reachability for other routers in the local domain routing fabric. Hence, the
IGP (OSPF or IS-IS). Border routers require information about other routers on
the Internet backbone. Hence, BGP.

The point the draft is trying to make is that mobility enhancements to IP should
separate out along these same natural architectural boundaries. Mobile IP in
draft-ietf-mobileip-ipv6-20.txt covers the Internet wide case, and also the
local domain case. RegReg and HMIP cover the local domain (regional) case
(though this isn't specifically called out in the draft). FMIP/CARD/ND
enhancements cover the local case. This probably wasn't made quite clear enough,
we should revise on the next round.

The "new" information for the local routing case brought to the table by
mobility is wireless reachability. CARD/FMIP provides this, and it should be
well intergrated into the local mobility protocol, since it is only of interest
to nodes on the local link. That is, it doesn't make sense for a node to have
wireless reachability information for a subnet somewhere on the other side of
the Internet because it can't get there. The "new" information for the global
routing case brought to the table by mobility is the home address to care of
address mapping. That is handled by standard Mobile IPv6.

>     could not use it regardless of where you are.

I'm assuming we are talking about IPsec security associations, yes? That is to
say, an entry in the node's and router's SPD and SAD.

The security assocation may only be valid for nodes on the local link. In
principle, there is no reason why a node needs to have any other kind of
security association with a random last hop router, or am I missing something?
If the router is a home agent, of course, it is a different situation. The
amount of effort needed to establish the security association with a home agent
might be quite different than that required for the last hop router, for
example.

>      previous AR still needs authorization from the MN to redirect

I'm not sure why you say that the MN is in charge of receiving its packets. What
happens if the last hop router goes down and it is the only router on the link?
It's a co-operative effort. I believe there is widespread confusion on the
application of the end to end principle to routing among people in the Mobile IP
community, please see draft-iab-e2e-futures-01.txt for a short discussion of how
end to end applies to mobility.

Furthermore, consider the case in a standard fixed IPv6 subnet which the node's
current last hop router goes down and there are other routers on the link. The
node doesn't have to "authorize" them to start routing packets. The routing
fabric detects the hole and packets start getting sent to another router on the
link. The new router sends the packets to the node and a Redirect, and the node
switches to the new router. Packets start showing up at the node without it
having to "authorize" routing by the local link router.

For the handover case, if the MN detects it has moved, it can communicate
(securely) with the new local router, and the local router can take care of
changing the routing, just as in the nonmobile case when a router fails. Routers
handle changes in the routing fabric just fine, as long as the security is there
between the MN and the first hop router, and between the two routers.

>      had this principle (i.e., the burden of mobility is on the network

It is not a new model. That is how the fixed, wired Internet works. The model of
the MN having to "authorize" redirection with a router not on its current subnet
is what is new, and that is what the draft is pointing out (though wordsmithing
is obviously necessary since this didn't seem to come across).

Furthermore, the draft has nothing whatsover to do with micromobility. There is
no proposal for a new routing algorithm in it. The MN uses standard Mobile IP,
changing its care of address when it changes subnets.

>     denominator and perhaps an important principle; others can correct

I still don't understand this aliasing of HA and AR. They are two different
things in my mind. HAs scale like servers, ARs scale like routers. There are
going to be thousands of ARs in DoCoMo's network, and I don't want to have to
pay the kinds of prices that are required for highly redundant, failover
devices. I want them to be cheap. On the other hand, I want my HAs to be highly
redundant and to failover so that my customers on the other side of the Internet
don't lose service should one machine go down. So I don't mind paying, but we
won't have many of them, just like we don't have many HLRs currently.

The functionality of defending an address offlink is just the IPv6 equivalent of
Proxy ARP, any router can do that. Similarly with tunneling. Just because these
two functionally very different nodes have these functions in common doesn't
mean the two nodes are structurally the same. My Windows laptop does telnet, and
so does the Cisco router in the routing closet, but they are not the same class
of device.

>    more than qualified to progress the draft.

The protocol discussions reflect the architectural concerns. This draft outlines
the architectural concerns.

>     we ought to define a vertically integrated system according to _a_

I think we need to have the protocol design reflect a coherent view of the
architecture. The MIPv6 spec reflects a coherent view of local/global routing
separation. That separation should be propagated into the local link routing
enhancements. The current FMIPv6 draft does _not_ reflect a coherent view of the
architecture, IMHO.

>     FMIPv6, I would like to do that. Who would like to offer solution

Here's my solution: get rid of it and use a Redirect between the MN and whatever
the current AR is. Use the SEND protocol (draft-ietf-send-ipsec-00.txt) to
secure the Redirect. Have the current AR inform the previous AR, if the link has
already switched, and the two ARs set up the tunnel. Use an interrouter IPsec
security association to secure the HI/HAck messages for the tunnel setup.

The MN finds out the new router address for the Redirect (i.e. wireless
reachability) from CARD/FMIP prehandover signaling, well in advance of the
handover, or from a cached RA on the access point (FRA). And those messages are
also secured with SEND.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 28 Feb 2003 18:02:02 -0800

> security association with a random last hop router, or am I missing something?

So, in principle, there is no reason _not_ have an SA for the router's
global address if an SA can be established at all in the first place, right ?

> might be quite different than that required for the last hop router, for

Agreed. However, I suppose we are referring to router - MN association.

> end to end applies to mobility.

For that matter, _any_ router on the end-to-end path can go down.
Are you extrapolating that BGP handles mobility ?

I think there needs to be a distinction between the robustness
of packet delivery (something a routing algorithm addresses) and
movement of a node.

> having to "authorize" routing by the local link router.

I think this is how packet delivery works and I suspect the host would expect the
router to provide robust packet delivery in the presence of faults. But I didn't
see that the
IP address of the host changed in the above description.
It resembles, if you don't mind me saying it,"router portability",
where an existing router gets replaced by a new one
and the host continues to receive packets. I don't see how the MN itself
exhibited "IP mobility", where the device actually changed subnets.
I would agree with you if you point out that there is re-numbering involved.

Is "robust packet delivery = mobility" ?

> between the MN and the first hop router, and between the two routers.

It's one thing for a router to keep forwarding packets in the
presence of faults without seeking authorization. It's something else
to re-direct packets without the MN's asking. If I am receiving a call,
I expect the call to be sent to me, despite the fact that the underlying
system is subject to faults. And, if the underlying system is capable of
that, I don't want that system to forward my calls elsewhere without
my permission.

> is obviously necessary since this didn't seem to come across).

Again, I think there is confusion between being able to deliver packets
in the presence of faults and who has the ultimate control in deciding
where the packets are sent.

> won't have many of them, just like we don't have many HLRs currently.

I didn't say that you necessarily need an HA on a router, even though that
might be likely in some scenarios.. I meant there is some minimum functionality
necessary on a router. This functionality is common to HA and AR. The rest
is deployment issue.

> so does the Cisco router in the routing closet, but they are not the same class

Agreed, and I didn't make reference to the structure of HA and AR.

> the architectural concerns.

The mobile ip working group is more than qualified for these
discussions. And, I believe we have had at least some of these
discussions.

> enhancements. The current FMIPv6 draft does _not_ reflect a coherent view of the

We can discuss architecture. There are many ways to envision
architecture. We can discuss protocols, and make them work within
a broad scope of generally agreed principles.
I don't see the need for another working group.

> handover, or from a cached RA on the access point (FRA). And those messages are

Good. I encourage you to bring it up as a solution and let the
folks on the list respond. In fact, let me start it by asking if the
SA is there between the MN and its AR, why couldn't that be
used by the MN from the new AR to send a message asking for
traffic re-direction ?

Regards,

-Rajeev