Opened 13 years ago

Closed 13 years ago

Last modified 12 years ago

#47 closed defect (fixed)

Editoral Changes for the PS draft from Gab Montenegro

Reported by: kempf@… Owned by: kempf@…
Priority: minor Milestone:
Component: nohost-ps Severity:
Keywords: PS draft Cc: netlmm@…


  1. Kempf, Editor

Internet Draft K. Leung Document: draft-ietf-netlmm-nohost-ps-00.txt P. Roberts

  1. Nishida
  1. Giaretta
    1. Liebsch

Too many authors, see

Expires: August, 2006 Feburary, 2006

*February* (sp)



In this document, the well-known problem of localized mobility management for IP link handover is given a fresh look.

Suggest a simpler more active phrasing: This document examines the problem of localized mobility management for IP link handover.


1.0 Introduction

Localized mobility management has been the topic of much work in the IETF

I'd finish the sentence here and delete the entire next line.

for some time, and it may seem as if little remains to be said on the topic. The experimental protocols developed from previous work, namely FMIPv6 [1] and HMIPv6[2], involve host-based solutions that mimic to a greater or

Don't think "mimicing" is the issue. The issue is reducing involvement from L3 at the host, L2 involvement being fine.

lesser extent the approach taken by Mobile IPv6 [3] for global mobility management. However, recent developments in the IETF and the WLAN infrastructure market suggest that it may be time to take a fresh look at localized mobility management. Firstly, new IETF work on global mobility management protocols that are not Mobile IPv6, such as HIP [4] and Mobike [5], suggests that future wireless IP nodes may support a more diverse set of global mobility protocols. Secondly, the success in the WLAN

Don't think this about global mob protocols is relevant. What is more relevant is running w/out any such global mob protocols (this is by far the most common).

infrastructure market of WLAN switches, which perform localized mobility management without any host stack involvement, suggests a possible design paradigm that could be used to accommodate other global mobility management options on the mobile node while reducing host stack software complexity and expanding the range of mobile nodes that could be accommodated.

Sounds like the concept is new, but it is already apparent in 3gpp's gtp and perhaps in some modes of operation of cdma2k (the host *stack* not being involved in mobility management).

This document briefly describes the local mobility problem and a few scenarios where localized mobility management would be desirable. Then, it describes the two most serious problems with existing protocols: the

existing *IETF* protocols...

requirement for host stack support, and the complex security interactions required between the mobile node and the access network. More detailed requirements and gap analysis for existing protocols can be found in [6].

1.1 Terminology

Mobility terminology in this draft follows that in RFC 3753 [7], with the addition of some new and revised terminology given here:

IP Link

hopefully, this does not depart from IPv6 def of a link. should contrast with that definition and point out what if any differences there are. hopefully none. hopefully this just adds more detail about an example implementation of such IP links.

A set of routers, mobile nodes, and wireless access points that share link broadcast capability or its functional equivalent. This definition covers one or multiple access points under one or several access routers. In the past, such a set has been called a subnet, but this term is not strictly correct for IPv6, since multiple subnet prefixes can be assigned to an IP link in IPv6.

Access Network (revised)

An Access Network consists of following three components: wireless or other access points, access routers, access network gateways which form the boundary to other networks and may shield other networks from the specialized routing protocols (if any) run in the Access Network; and (optionally) other internal access network routers which may also be needed in some cases to achieve a specialized routing protocol.

Local Mobility (revised)

Kempf, et. al. Expires August 2006 [Page 2]

Internet Draft Problem Statement for IP Local Mobility Feburary, 2006

Local Mobility is mobility over a restricted area of the network

is this equal to the access network?

topology. Note that, although the area of network topology over which the mobile node moves may be restricted, the actual geographic area could be quite large, depending on the mapping between the network topology and the wireless coverage area.

Localized Mobility Management

Localized Mobility Management is a generic term for protocols dealing with IP mobility management confined within the access network.

seems like the answer to above is YES, then use this term above for clarity/consistency

Localized mobility management signaling is not routed outside the access network, although a handover may trigger Global Mobility Management signaling. Localized mobility management protocols exploit the locality of movement by confining movement related changes to the access network.

Global Mobility Protocol

A Global Mobility Protocol is a mobility protocol used by the mobile node to change the global, end-to-end routing of packets when movement causes a topology change and thus invalidates a global unicast address on the local IP link currently in active use by the mobile node. The Global Mobility Protocol allows the mobile node to maintain a mapping between a permanent rendezvous or home address and a temporary care-of address for rendezvous with nodes that want to initiate a connection, and it may also provide direct routing through the rendezvous node and/or optimized routing directly between correspondent nodes and the local address. Typically, this protocol will be Mobile IPv6 [1] but it

typically mipv6? much more typical is *NO* global mob management protocol. when one is present, more typical today is mipv4.

could also be HIP [4] or Mobike [5] (Note: although Mobike is not considered a mobility management protocol in general, for purposes of this document, it will be so considered because it manages the address map and routing between a fixed VPN endpoint address and a changing local address).

Global Mobility Anchor Point

A node in the network where the mobile node has its fixed home address that maintains the mapping between the home address and care-of address for purposes of rendezvous and possibly traffic forwarding. For Mobile IPv6 [1], this is the home agent. For HIP [4], this is the rendezvous server. For Mobike [5], this is the VPN tunnel gateway in the home network.

The two sections above should treat e2e mobility management as a 1st class citizen. This is mob managment in the absence of a rendezvous, e.g., homeless Mobile IP, EMIPv6 (, rendezvous-less HIP, shim6 even.


2.0 The Local Mobility Problem

Kempf, et. al. Expires August 2006 [Page 3]

Internet Draft Problem Statement for IP Local Mobility Feburary, 2006

The local mobility problem is restricted to providing IP mobility management for mobile nodes within an access network. An access network consists of a group of access routers connected to wired or wireless access points on the downlink side and a wired IP core through one or more aggregation routers on the side that is routed toward the border router and the Internet. The aggregation routers function as an access network gateway, although in this

s/an s/gateway/gateways/

case, there is no specialized routing protocol and the routers function as a standard IP routed network. This is illustrated in Figure 1, where the aggregation routers are designated as "AggR". Transitions between service providers in separate autonomous systems or across broader topological "boundaries" within the same service provider are excluded.

This is important: limiting the scope. However, the requirements doc in section 3.1 seems to think that this is a requirement by citing Mobile IP's lack of handover between HAs as a limitation (section 3.1 in requirements draft).


Figure 1. Scope of Local and Global Mobility Management

As shown in the figure, a global mobility protocol is necessary when a mobile node (MN) moves between two access networks.

Not at all. Most devices today don't have such protocols and operate just fine. This is true even if one assumes that such a movement implies a change in IP address. This seems to be assumed, but must be spelled out. Actually, this seems to be the main issue: what is the implication of these movements to maintain whatever subnet/IP link model? What is this subnet model assumed?

Exactly what the scope of the access networks is depends on deployment considerations. Mobility between two access points under the same access router constitutes Intra- link mobility, and is typically handled by Layer 2 mobility protocols (if there is only one access point/cell per access router, then intra-link mobility may be lacking). Between these two lies local mobility. Local mobility occurs when a mobile node moves between two access points connected to two different access routers.

Hmmm... In WLANs, typically the APs are tied together via ethernet switches, not routers, right? If so, the above does not translate or apply to WLANs. And yet the WLAN case was cited as a primary motivation. This is confusing...

Global mobility protocols allow a mobile node to maintain reachability when a change between access routers occurs, by updating the address mapping between the home address and care-of address at the global mobility anchor point, or even end to end by changing the care-of address directly at the correspondent node. A global mobility management protocol can therefore be used between access routers for handling local mobility. However, there are three well-known problems involved in using a global mobility protocols for every transition between access routers. Briefly, they are:

1) Update latency. If the global mobility anchor point and/or

correspondent node (for route optimized traffic) is at some distance from the mobile node's access network, the global mobility update may require a considerable amount of time, during which time packets

s/time, during which/time. During this/


These problems suggest that a protocol to localize the management of topologically small movements is preferable to using a global mobility management protocol on each IP link move. In addition to these problems, localized mobility management can provide a measure of local control, so mobility management can be tuned for specialized local conditions. Note also that if localized mobility management is provided, it is not strictly required for a mobile node to support a global mobility management protocol

major understatement.

since movement within a restricted IP access network can still be

most apps are fine.


what follows is the list of applicable scenarios. it seems farfetched:

wireless protocols all served by IP, including advanced cellular, WLAN, and

advanced cellular? big maybe. WLAN? don't think so. PAN? seems a bit of a stretch, or at least the mobility requirements in PANs seem to be invoked without much research nor participation from that community. mentioning them seems more distracting than it's worth.


3.3 Picocellular Network with Small But Node-Dense IP Links

Future radio link protocols at very high frequencies may be constrained to very short, line of sight operation. Even some existing protocols, such as UWB and Bluetooth, are designed for low power, short range operation. For

UWB low power? not really. receiving is very power intensive due to all the DSP going on. perhaps you meant low *transmit* power.


4.0 Problems with Existing Solutions

Kempf, et. al. Expires August 2006 [Page 6]

Internet Draft Problem Statement for IP Local Mobility Feburary, 2006

Existing solutions for localized mobility management fall into three classes:

1) Interoperable IP level protocols that require changes to the mobile node's

IP stack and handle localized mobility management as a service provided to the host by the access network,

2) Link specific or proprietary protocols that handle localized mobility for

any mobile node but only for a specific type of link layer, namely 802.11 running on an 802.3 wired network backhaul.

3) Use of a standard IGP such as OSPF or IS-IS to distribute host routes, and

updating the host routes when the mobile node moves.

For Solution 1, the following are specific problems:

1) The host stack software requirement limits broad usage even if the

modifications are small. The success of WLAN switches indicates that network operators and users prefer no host stack software modifications. This preference is likely to be independent of the lack of widespread

s/likely to be

Mobile IPv4 deployment, since it is much easier to deploy and use the network.

2) Future mobile nodes may choose other global mobility management

protocols, such as HIP or Mobike. The existing localized mobility management solutions all depend on Mobile IP or derivatives.

3) Existing localized mobility management solutions do not support both IPv4

and IPv6.

4) Security for the existing localized mobility management solutions

requires complex security associations with network elements for no improvement in security over what is available if localized mobility management is not used. In addition to the additional signaling required to set up these security associations, provisioning a mobile node with credentials for roaming to all the access networks where the mobile node might end up may prove difficult, acting as a barrier to deployment.

Solution 2 has the following problems:

1) Existing solutions only support WLAN networks with Ethernet backhaul and

therefore are not available for advanced cellular networks or picocellular protocols, or other types of wired backhaul.

but should one single protocol apply throughout for all scenarios and technologies? advanced cellular is very different from PAN and from WLANs. I'm starting to think that each scenario may be better served by different protocols. Perhaps chose one (or two) that make real sense, but mentioning PANs and perhaps even WLANs seems distracting.

2) Each WLAN switch vendor has its own proprietary protocol that does not

interoperate with other vendor's equipment.

3) Because the solutions are based on layer 2 routing, they may not scale up

to a metropolitan area, or local province.

not an issue for WLANs.

Solution 3 has the following problems:

1) Each router in the localized mobility management domain is required to

maintain a host route table and to search the host route table for routing each packet, limiting the memory and processing power scalability.

2) After handover, until host routes propagate back along the current path

of traffic to the localized mobility management domain border, traffic packets for the mobile node are sent to the old router, causing the packets to drop. Since IGPs typically propagate routing updates through

Kempf, et. al. Expires August 2006 [Page 7]

Internet Draft Problem Statement for IP Local Mobility Feburary, 2006

flooding, the delay in host route propagation also limits the topological span of the localized mobility management domain.

3) Rapid movement by the mobile node faster than the rate at which flooding

can propagate host routes could lead to a cascading series of host route messages that never stabilize.

Having an interoperable, standardized localized mobility management protocol that is scalable to topologically large networks, but requires no host stack involvement for localized mobility management is a highly desirable solution.

for which scenario? PAN, WLAN, cellular?

Change History (3)

comment:1 Changed 13 years ago by kempf@…

  • Status changed from new to assigned

comment:2 Changed 13 years ago by kempf@…

  • Resolution set to fixed
  • Status changed from assigned to closed

I resolved these as best I could, but some of the comments seem to reflect the commentor's skepticism about the described scenerios. These scenerios are not intended to be normative but are just some examples.

comment:3 Changed 12 years ago by anonymous

  • Milestone milestone2 deleted

Milestone milestone2 deleted

Note: See TracTickets for help on using tickets.