draft-ietf-netlmm-nohost-ps-05.txt   rfc4830.txt 
Internet Draft J. Kempf, Editor Network Working Group J. Kempf, Ed.
Document: draft-ietf-netlmm-nohost-ps-05.txt September, 2006 Request for Comments: 4830 DoCoMo USA Labs
Expires: March, 2007 Problem Statement for Network-Based Localized
Mobility Management (NETLMM)
Problem Statement for Network-based Localized Mobility Management
(draft-ietf-netlmm-nohost-ps-05.txt)
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six This memo provides information for the Internet community. It does
months and may be updated, replaced, or obsoleted by other not specify an Internet standard of any kind. Distribution of this
documents at any time. It is inappropriate to use Internet-Drafts memo is unlimited.
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/1id-abstracts.html.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The IETF Trust (2007).
http://www.ietf.org/shadow.html.
Abstract Abstract
Localized mobility management is a well understood concept in the Localized mobility management is a well-understood concept in the
IETF with a number of solutions already available. This document IETF, with a number of solutions already available. This document
looks at the principal shortcomings of the existing solutions, all looks at the principal shortcomings of the existing solutions, all of
of which involve the host in mobility management, and makes a case which involve the host in mobility management, and makes a case for
for network-based local mobility management. network-based local mobility management.
Contributors
Gerardo Giaretta, Kent Leung, Katsutoshi Nishida, Phil Roberts, and
Marco Liebsch all contributed major effort to this document. Their
names are not included in the authors' section due to the RFC
Editor's limit of 5 names.
Table of Contents Table of Contents
1.0 Introduction............................................2 1. Introduction ....................................................2
2.0 The Local Mobility Problem..............................4 1.1. Terminology ................................................3
3.0 Scenarios for Localized Mobility Management.............6 2. The Local Mobility Problem ......................................4
4.0 Problems with Existing Solutions........................7 3. Scenarios for Localized Mobility Management .....................7
5.0 Advantages of Network-based Localized Mobility 3.1. Large Campus ...............................................7
Management..............................................8 3.2. Advanced Cellular Network ..................................7
6.0 IANA Considerations.....................................9 3.3. Picocellular Network with Small But Node-Dense Last
7.0 Security Considerations.................................9 Hop Links ..................................................8
8.0 References..............................................9 4. Problems with Existing Solutions ................................8
9.0 Acknowledgements.......................................10 5. Advantages of Network-based Localized Mobility Management .......9
10.0 Author's Addresses.....................................10 6. Security Considerations ........................................10
11.0 IPR Statements.........................................11 7. Informative References .........................................10
12.0 Disclaimer of Validity.................................12 8. Acknowledgements ...............................................11
13.0 Copyright Notice.......................................12 9. Contributors ...................................................12
1.0 Introduction 1. Introduction
Localized mobility management has been the topic of much work in Localized mobility management has been the topic of much work in the
the IETF. The experimental protocols developed from previous work, IETF. The experimental protocols developed from previous works,
namely FMIPv6 [13] and HMIPv6 [18], involve host-based solutions namely Fast-Handovers for Mobile IPv6 (FMIPv6) [13] and Hierarchical
that require host involvement at the IP layer similar to or in Mobile IPv6 (HMIPv6) [18], involve host-based solutions that require
addition to that required by Mobile IPv6 [10] for global mobility host involvement at the IP layer similar to, or in addition to, that
management. However, recent developments in the IETF and the WLAN required by Mobile IPv6 [10] for global mobility management.
However, recent developments in the IETF and the Wireless LAN (WLAN)
infrastructure market suggest that it may be time to take a fresh infrastructure market suggest that it may be time to take a fresh
look at localized mobility management. look at localized mobility management.
Firstly, new IETF work on global mobility management protocols that First, new IETF work on global mobility management protocols that are
are not Mobile IPv6, such as HIP [16] and MOBIKE [4], suggests that not Mobile IPv6, such as Host Identity Protocol (HIP) [16] and IKEv2
future wireless IP nodes may support a more diverse set of global Mobility and Multihoming (MOBIKE) [4], suggests that future wireless
mobility protocols. While it is possible that existing localized IP nodes may support a more diverse set of global mobility protocols.
mobility management protocols could be used with HIP and MOBIKE, While it is possible that existing localized mobility management
some would require additional effort to implement, deploy, or in protocols could be used with HIP and MOBIKE, some would require
some cases even to specify in a non-Mobile IPv6 mobile environment. additional effort to implement, deploy, or in some cases, even
specify in a non-Mobile IPv6 mobile environment.
Secondly, the success in the WLAN infrastructure market of WLAN Second, the success in the WLAN infrastructure market of WLAN
switches, which perform localized management without any host stack switches, which perform localized management without any host stack
involvement, suggests a possible paradigm that could be used to involvement, suggests a possible paradigm that could be used to
accommodate other global mobility options on the mobile node while accommodate other global mobility options on the mobile node while
reducing host stack software complexity expanding the range of reducing host stack software complexity, expanding the range of
mobile nodes that could be accommodated. mobile nodes that could be accommodated.
This document briefly describes the general local mobility problem This document briefly describes the general local mobility problem
and scenarios where localized mobility management would be and scenarios where localized mobility management would be desirable.
desirable. Then problems with existing or proposed IETF localized Then problems with existing or proposed IETF localized mobility
mobility management protocols are briefly discussed. The network- management protocols are briefly discussed. The network-based
based mobility management architecture and a short description of mobility management architecture and a short description of how it
how it solves these problems is presented. A more detailed solves these problems are presented. A more detailed discussion of
discussion of goals for a network-based, localized mobility goals for a network-based, localized mobility management protocol and
management protocol and gap analysis for existing protocols can be gap analysis for existing protocols can be found in [11]. Note that
found in [11]. Note that IPv6 and wireless links are considered to IPv6 and wireless links are considered to be the initial scope for a
be the initial scope for a network-based localized mobility network-based localized mobility management, so the language in this
management, so the language in this document reflects that scope. document reflects that scope. However, the conclusions of this
However, the conclusions of this document apply equally to IPv4 and document apply equally to IPv4 and wired links, where nodes are
wired links where nodes are disconnecting and reconnecting. disconnecting and reconnecting.
1.1 Terminology 1.1. Terminology
Mobility terminology in this draft follows that in RFC 3753
[7], with the addition of some new and revised terminology Mobility terminology in this document follows that in RFC 3753 [14],
given here: with the addition of some new and revised terminology given here:
WLAN Switch WLAN Switch
A Wireless LAN (WLAN) switch is an Ethernet [8]switch - that A WLAN switch is a multiport bridge Ethernet [8] switch that
is a multiport bridge that connects network segments but connects network segments but also allows a physical and logical
allows a physical and logical star topology - which also star topology, which runs a protocol to control a collection of
runs a protocol to control a collection of 802.11 [6] access 802.11 [6] access points. The access point control protocol
points. The access point control protocol allows the switch allows the switch to perform radio resource management functions
to perform radio resource management functions such as power such as power control and terminal load balancing between the
control and terminal load balancing between the access access points. Most WLAN switches also support a proprietary
points. Most WLAN switches also support a proprietary protocol for inter-subnet IP mobility, usually involving some kind
protocol for inter-subnet IP mobility, usually involving of inter-switch IP tunnel, which provides session continuity when
some kind of inter-switch IP tunnel, which provides session a terminal moves between subnets.
continuity when a terminal moves between subnets.
Access Network Access Network
An access network is a collection of fixed and mobile An access network is a collection of fixed and mobile network
network components allowing access to the Internet all components allowing access to the Internet all belonging to a
belonging to a single operational domain. It may consist of single operational domain. It may consist of multiple air
multiple air interface technologies (for example 802.16e interface technologies (for example, 802.16e [7], Universal Mobile
[5], UMTS [1], etc.) interconnected with multiple types of Telecommunications System (UMTS) [1], etc.) interconnected with
backhaul interconnections (such as SONET [9], metro Ethernet multiple types of backhaul interconnections (such as Synchronous
[15] [8], etc.). Optical Network (SONET) [9], metro Ethernet [15] [8], etc.).
Local Mobility (revised) Local Mobility (revised)
Local Mobility is mobility over an access network. Note Local Mobility is mobility over an access network. Note that
that, although the area of network topology over which the although the area of network topology over which the mobile node
mobile node moves may be restricted, the actual geographic moves may be restricted, the actual geographic area could be quite
area could be quite large, depending on the mapping between large, depending on the mapping between the network topology and
the network topology and the wireless coverage area. the wireless coverage area.
Localized Mobility Management Localized Mobility Management
Localized Mobility Management is a generic term for any Localized Mobility Management is a generic term for any protocol
protocol that maintains the IP connectivity and reachability that maintains the IP connectivity and reachability of a mobile
of a mobile node for purposes of maintaining session node for purposes of maintaining session continuity when the
continuitity when the mobile node moves, and whose signaling mobile node moves, and whose signaling is confined to an access
is confined to an access network. network.
Localized Mobility Management Protocol Localized Mobility Management Protocol
A protocol that supports localized mobility management. A protocol that supports localized mobility management.
Global Mobility Management Protocol Global Mobility Management Protocol
A Global Mobility Management Protocol is a mobility protocol A Global Mobility Management Protocol is a mobility protocol used
used by the mobile node to change the global, end-to-end by the mobile node to change the global, end-to-end routing of
routing of packets for purposes of maintaining session packets for purposes of maintaining session continuity when
continuity when movement causes a topology change and thus movement causes a topology change, thus invalidating a global
invalidates a global unicast address of the mobile node. unicast address of the mobile node. This protocol could be Mobile
This protocol could be Mobile IP [10][17] but it could also IP [10] [17], but it could also be HIP [16] or MOBIKE [4].
be HIP [14] or MOBIKE [4].
Global Mobility Anchor Point Global Mobility Anchor Point
A node in the network where the mobile node maintains a A node in the network where the mobile node maintains a permanent
permanent address and a mapping between the permanent address and a mapping between the permanent address and the local
address and the local temporary address where the mobile temporary address where the mobile node happens to be currently
node happens to be currently located. The Global Mobility located. The Global Mobility Anchor Point may be used for
Anchor Point may be used for purposes of rendezvous and purposes of rendezvous and possibly traffic forwarding.
possibly traffic forwarding.
Intra-Link Mobility Intra-Link Mobility
Intra-Link Mobility is mobility between wireless access Intra-Link Mobility is mobility between wireless access points
points within a link. Typically, this kind of mobility only within a link. Typically, this kind of mobility only involves
involves Layer 2 mechanisms, so Intra-Link Mobility is often Layer 2 mechanisms, so Intra-Link Mobility is often called Layer 2
called Layer 2 mobility. No IP subnet configuration is mobility. No IP subnet configuration is required upon movement
required upon movement since the link does not change, but since the link does not change, but some IP signaling may be
some IP signaling may be required for the mobile node to required for the mobile node to confirm whether or not the change
confirm whether or not the change of wireless access point of wireless access point also resulted in the previous access
also resulted in the previous access routers becoming routers becoming unreachable. If the link is served by a single
unreachable. If the link is served by a single access access point/router combination, then this type of mobility is
point/router combination, then this type of mobility typically absent. See Figure 1.
is typically absent. See Figure 1.
2.0 The Local Mobility Problem 2. The Local Mobility Problem
The local mobility problem is restricted to providing IP mobility The local mobility problem is restricted to providing IP mobility
management for mobile nodes within an access network. The access management for mobile nodes within an access network. The access
network gateways function as aggregation routers. In this case, network gateways function as aggregation routers. In this case,
there is no specialized routing protocol (e.g. GTP, Cellular IP, there is no specialized routing protocol (e.g., Generic Tunneling
Hawaii, etc.) and the routers form a standard IP routed network Protocol (GTP), Cellular IP, Hawaii, etc.) and the routers form a
(e.g. OSPF, IS-IS, RIP, etc.). This is illustrated in Figure 1, standard IP routed network (e.g., OSPF, Intermediate System to
where the access network gateway routers are designated as "ANG". Intermediate System (IS-IS), RIP, etc.). This is illustrated in
Transitions between service providers in separate autonomous Figure 1, where the access network gateway routers are designated as
systems or across broader topological "boundaries" within the same "ANG". Transitions between service providers in separate autonomous
service provider are excluded. systems, or across broader, topological "boundaries" within the same
service provider, are excluded.
Figure 1 depicts the scope of local mobility in comparison to Figure 1 depicts the scope of local mobility in comparison to global
global mobility. The Access Network Gateways (ANGs) GA1 and GB1 are mobility. The Access Network Gateways (ANGs), GA1 and GB1, are
gateways to their access networks. The Access Routers (ARs) RA1 and gateways to their access networks. The Access Routers (ARs), RA1 and
RA2 are in access network A, RB1 is in access network B. Note that RA2, are in access network A; RB1 is in access network B. Note that
it is possible to have additional aggregation routers between ANG it is possible to have additional aggregation routers between ANG GA1
GA1 and ANG GB1 and the access routers if the access network is and ANG GB1, and the access routers if the access network is large.
large. Access Points (APs) PA1 through PA3 are in access network A, Access Points (APs) PA1 through PA3 are in access network A; PB1 and
PB1 and PB2 are in access network B. Other ANGs, ARs, and APs are PB2 are in access network B. Other ANGs, ARs, and APs are also
also possible, and other routers can separate the ARs from the possible, and other routers can separate the ARs from the ANGs. The
ANGs. The figure implies a star topology for the access network figure implies a star topology for the access network deployment, and
deployment, and the star topology is the primary one of interest the star topology is the primary interest since it is quite common,
since it is quite common, but the problems discussed here are but the problems discussed here are equally relevant to ring or mesh
equally relevant to ring or mesh topologies in which ARs are topologies in which ARs are directly connected through some part of
directly connected through some part of the network. the network.
Access Network A Access Network B Access Network A Access Network B
+-------+ +-------+ +-------+ +-------+
|ANG GA1| (other ANGs) |ANG GB1| (other ANGs) |ANG GA1| (other ANGs) |ANG GB1| (other ANGs)
+-------+ +-------+ +-------+ +-------+
@ @ @ @ @ @
@ @ @ @ @ @
@ @ @ (other routers) @ @ @ (other routers)
@ @ @ @ @ @
skipping to change at page 5, line 40 skipping to change at page 6, line 4
------ ------ ------ ------ ------ ------ ------ ------ ------ ------
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
|MN|----->|MN|----->|MN|-------->|MN| |MN|----->|MN|----->|MN|-------->|MN|
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
Intra-link Local Global Intra-link Local Global
(Layer 2) Mobility Mobility (Layer 2) Mobility Mobility
Mobility Mobility
Figure 1. Scope of Local and Global Mobility Management Figure 1. Scope of Local and Global Mobility Management
As shown in the figure, a global mobility protocol may be necessary As shown in the figure, a global mobility protocol may be necessary
when a mobile node (MN) moves between two access networks. Exactly when a mobile node (MN) moves between two access networks. Exactly
what the scope of the access networks is depends on deployment what the scope of the access networks is depends on deployment
considerations. Mobility between two APs under the same AR considerations. Mobility between two APs under the same AR
constitutes intra-link, or Layer 2, mobility, and is typically constitutes intra-link (or Layer 2) mobility, and is typically
handled by Layer 2 mobility protocols (if there is only one AP/cell handled by Layer 2 mobility protocols (if there is only one AP/cell
per AR, then intra-link mobility may be lacking). Between these two per AR, then intra-link mobility may be lacking). Between these two
lies local mobility. Local mobility occurs when a mobile node moves lies local mobility. Local mobility occurs when a mobile node moves
between two APs connected to two different ARs. between two APs connected to two different ARs.
Global mobility protocols allow a mobile node to maintain Global mobility protocols allow a mobile node to maintain
reachability when the MN's globally routable IP address changes. It reachability when the MN's globally routable IP address changes. It
does this by updating the address mapping between the permanent does this by updating the address mapping between the permanent
address and temporary local address at the global mobility anchor address and temporary local address at the global mobility anchor
point, or even end to end by changing the temporary local address point, or even end to end by changing the temporary local address
directly at the node with which the mobile node is corresponding. A directly at the node with which the mobile node is corresponding. A
global mobility management protocol can therefore be used between global mobility management protocol can therefore be used between ARs
ARs for handling local mobility. However, there are three well- for handling local mobility. However, there are three well-known
known problems involved in using a global mobility protocol for problems involved in using a global mobility protocol for every
every movement between ARs. Briefly, they are: movement between ARs. Briefly, they are:
1) Update latency. If the global mobility anchor point and/or 1) Update latency. If the global mobility anchor point and/or
correspondent node (for route optimized traffic) is at some correspondent node (for route-optimized traffic) is at some
distance from the mobile node's access network, the global distance from the mobile node's access network, the global
mobility update may require a considerable amount of time. mobility update may require a considerable amount of time. During
During this time, packets continue to be routed to the old this time, packets continue to be routed to the old temporary
temporary local address and are essentially dropped. local address and are essentially dropped.
2) Signaling overhead. The amount of signaling required when a 2) Signaling overhead. The amount of signaling required when a
mobile node moves from one last hop link to another can be mobile node moves from one last-hop link to another can be quite
quite extensive, including all the signaling required to extensive, including all the signaling required to configure an IP
configure an IP address on the new link and global mobility address on the new link and global mobility protocol signaling
protocol signaling back into the network for changing the back into the network for changing the permanent to temporary
permanent to temporary local address mapping. The signaling local address mapping. The signaling volume may negatively impact
volume may negatively impact wireless bandwidth usage and real wireless bandwidth usage and real-time service performance.
time service performance.
3) Location privacy. The change in temporary local address as the 3) Location privacy. The change in temporary local address as the
mobile node moves exposes the mobile node's topological mobile node moves exposes the mobile node's topological location
location to correspondents and potentially to eavesdroppers. An to correspondents and potentially to eavesdroppers. An attacker
attacker that can assemble a mapping between subnet prefixes in that can assemble a mapping between subnet prefixes in the mobile
the mobile node's access network and geographical locations can node's access network and geographical locations can determine
determine exactly where the mobile node is located. This can exactly where the mobile node is located. This can expose the
expose the mobile node's user to threats on their location mobile node's user to threats on their location privacy. A more
privacy. A more detailed discussion of location privacy for detailed discussion of location privacy for Mobile IPv6 can be
Mobile IPv6 can be found in [12]. found in [12].
These problems suggest that a protocol to localize the management These problems suggest that a protocol to localize the management of
of topologically small movements is preferable to using a global topologically small movements is preferable to using a global
mobility management protocol on each movement to a new link. In mobility management protocol on each movement to a new link. In
addition to these problems, localized mobility management can addition to these problems, localized mobility management can provide
provide a measure of local control, so mobility management can be a measure of local control, so mobility management can be tuned for
tuned for specialized local conditions. Note also that if localized specialized local conditions. Note also that if localized mobility
mobility management is provided, it is not strictly required for a management is provided, it is not strictly required for a mobile node
mobile node to support a global mobility management protocol since to support a global mobility management protocol since movement
movement within a restricted IP access network can still within a restricted IP access network can still be accommodated.
be accommodated. Without such support, however, a mobile node Without such support, however, a mobile node experiences a disruption
experiences a disruption in its traffic when it moves beyond the in its traffic when it moves beyond the border of the localized
border of the localized mobility management domain. mobility management domain.
3.0 Scenarios for Localized Mobility Management 3. Scenarios for Localized Mobility Management
There are a variety of scenarios in which localized mobility There are a variety of scenarios in which localized mobility
management is useful. management is useful.
3.1 Large Campus 3.1. Large Campus
One scenario where localized mobility management would be One scenario where localized mobility management would be attractive
attractive is a campus wireless LAN deployment, in which the is a campus WLAN deployment, in which the geographical span of the
geographical span of the campus, distribution of buildings, campus, distribution of buildings, availability of wiring in
availability of wiring in buildings, etc. preclude deploying all buildings, etc. preclude deploying all WLAN access points as part of
WLAN access points as part of the same IP subnet. WLAN Layer 2 the same IP subnet. WLAN Layer 2 mobility could not be used across
mobility could not be used across the entire campus. the entire campus.
In this case, the campus is divided into separate last hop links In this case, the campus is divided into separate last-hop links,
each served by one or more access routers. This kind of deployment each served by one or more access routers. This kind of deployment
is served today by wireless LAN switches that co-ordinate IP is served today by WLAN switches that coordinate IP mobility between
mobility between them, effectively providing localized mobility them, effectively providing localized mobility management at the link
management at the link layer. Since the protocols are proprietary layer. Since the protocols are proprietary and not interoperable,
and not interoperable, any deployments that require IP mobility any deployments that require IP mobility necessarily require switches
necessarily require switches from the same vendor. from the same vendor.
3.2 Advanced Cellular Network 3.2. Advanced Cellular Network
Next generation cellular protocols such as 802.16e [5] and Super Next-generation cellular protocols, such as 802.16e [7] and Super
3G/3.9G [2] have the potential to run IP deeper into the access 3G/3.9G [2], have the potential to run IP deeper into the access
network than the current 3G cellular protocols, similar to today's network than the current 3G cellular protocols, similar to today's
WLAN networks. This means that the access network can become a WLAN networks. This means that the access network can become a
routed IP network. Interoperable localized mobility management can routed IP network. Interoperable localized mobility management can
unify local mobility across a diverse set of wireless protocols all unify local mobility across a diverse set of wireless protocols all
served by IP, including advanced cellular, WLAN, and personal area served by IP, including advanced cellular, WLAN, and personal area
wireless technologies such as UltraWide Band (UWB) [5] and wireless technologies such as UltraWide Band (UWB) [5] and Bluetooth
Bluetooth [3]. Localized mobility management at the IP layer does [3]. Localized mobility management at the IP layer does not replace
not replace Layer 2 mobility (where available) but rather Layer 2 mobility (where available) but rather complements it. A
complements it. A standardized, interoperable localized mobility standardized, interoperable localized mobility management protocol
management protocol for IP can remove the dependence on IP layer for IP can remove the dependence on IP-layer localized mobility
localized mobility protocols that are specialized to specific link protocols that are specialized to specific link technologies or
technologies or proprietary, which is the situation with today's 3G proprietary, which is the situation with today's 3G protocols. The
protocols. The expected benefit is a reduction in maintenance cost expected benefit is a reduction in maintenance cost and deployment
and deployment complexity. See [11] for a more detailed discussion complexity. See [11] for a more detailed discussion of the goals for
of the goals for a network-based localized mobility management a network-based localized mobility management protocol.
protocol.
3.3 Picocellular Network with Small But Node-Dense Last Hop Links 3.3. Picocellular Network with Small But Node-Dense Last-Hop Links
Future radio link protocols at very high frequencies may be Future radio link protocols at very high frequencies may be
constrained to very short, line of sight operation. Even some constrained to very short, line-of-sight operation. Even some
existing protocols, such as UWB [5] and Bluetooth [3], are designed existing protocols, such as UWB [5] and Bluetooth [3], are designed
for low transmit power, short range operation. For such protocols, for low transmit power, short-range operation. For such protocols,
extremely small picocells become more practical. Although picocells extremely small picocells become more practical. Although picocells
do not necessarily imply "pico subnets", wireless sensors and other do not necessarily imply "pico subnets", wireless sensors and other
advanced applications may end up making such picocellular type advanced applications may end up making such picocellular type
networks node-dense, requiring subnets that cover small networks node-dense, requiring subnets that cover small geographical
geographical areas, such as a single room. The ability to aggregate areas, such as a single room. The ability to aggregate many subnets
many subnets under a localized mobility management scheme can help under a localized mobility management scheme can help reduce the
reduce the amount of IP signaling required on link movement. amount of IP signaling required on link movement.
4.0 Problems with Existing Solutions 4. Problems with Existing Solutions
Existing solutions for localized mobility management fall into Existing solutions for localized mobility management fall into two
three classes: 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 mobile node by the access network.
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 mobile node by the access network,
2) Link specific or proprietary protocols that handle localized 2) Link specific or proprietary protocols that handle localized
mobility for any mobile node but only for a specific type of mobility for any mobile node but only for a specific type of link
link layer, for example, 802.11 [6]. layer, for example, 802.11 [6].
The dedicated localized mobility management IETF protocols for The dedicated localized mobility management IETF protocols for
Solution 1 are not yet widely deployed, but work continues on Solution 1 are not yet widely deployed, but work continues on
standardization. Some Mobile IPv4 deployments use localized standardization. Some Mobile IPv4 deployments use localized mobility
mobility management. For Solution 1, the following are specific management. For Solution 1, the following are specific problems:
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 independent of the lack of
widespread Mobile IPv4 deployment, since it is much easier to
deploy and use the network.
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 independent of the
lack of widespread Mobile IPv4 deployment, since it is much
easier to deploy and use the network.
2) Future mobile nodes may choose other global mobility management 2) Future mobile nodes may choose other global mobility management
protocols, such as HIP or MOBIKE. The existing localized protocols, such as HIP or MOBIKE. The existing localized mobility
mobility management solutions all depend on Mobile IP or management solutions all depend on Mobile IP or derivatives.
derivatives.
3) Existing localized mobility management solutions do not support 3) Existing localized mobility management solutions do not support
both IPv4 and IPv6. both IPv4 and IPv6.
4) Existing host-based localized mobility management solutions 4) Existing host-based localized mobility management solutions
require setting up additional security associations with network require setting up additional security associations with network
elements in the access domain. elements in the access domain.
Market acceptance of WLAN switches has been very large, so Solution Market acceptance of WLAN switches has been very large, so Solution 2
2 is widely deployed and continuing to grow. Solution 2 has the is widely deployed and continuing to grow. Solution 2 has the
following problems: following problems:
1) Existing solutions only support WLAN networks with Ethernet 1) Existing solutions only support WLAN networks with Ethernet
backhaul and therefore are not available for advanced cellular backhaul and therefore are not available for advanced cellular
networks or picocellular protocols, or other types of wired networks or picocellular protocols, or other types of wired
backhaul. backhaul.
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 particularly
when multiple kinds of link technologies are used in the
backbone.
5.0 Advantages of Network-based Localized Mobility Management 2) Each WLAN switch vendor has its own proprietary protocol that does
not interoperate with other vendors' equipment.
3) Because the solutions are based on Layer 2 routing, they may not
scale up to a metropolitan area or local province, particularly
when multiple kinds of link technologies are used in the backbone.
5. Advantages of Network-based Localized Mobility Management
Having an interoperable, standardized localized mobility management Having an interoperable, standardized localized mobility management
protocol that is scalable to topologically large networks, but protocol that is scalable to topologically large networks, but
requires no host stack involvement for localized mobility requires no host stack involvement for localized mobility management
management is a highly desirable solution. The advantages that this is a highly desirable solution. The advantages that this solution
solution has over the Solutions 1 and 2 above are as follows: has over Solutions 1 and 2 above are as follows:
1) Compared with Solution 1, a network-based solution requires no 1) Compared with Solution 1, a network-based solution requires no
localized mobility management support on the mobile node and is localized mobility management support on the mobile node and is
independent of global mobility management protocol, so it can independent of global mobility management protocol, so it can be
be used with any or none of the existing global mobility used with any or none of the existing global mobility management
management protocols. The result is a more modular mobility protocols. The result is a more modular mobility management
management architecture that better accommodates changing architecture that better accommodates changing technology and
technology and market requirements. market requirements.
2) Compared with Solution 2, an IP level network-based localized
mobility management solution works for link protocols other
than Ethernet, and for wide area networks.
Reference [11] discusses a reference architecture for a network-
based, localized mobility protocol and goals the protocol design.
6.0 IANA Considerations 2) Compared with Solution 2, an IP-level network-based localized
mobility management solution works for link protocols other than
Ethernet, and for wide area networks.
There are no IANA considerations in this document. RFC 4831 [11] discusses a reference architecture for a network-
based, localized mobility protocol and the goals of the protocol
design.
7.0 Security Considerations 6. Security Considerations
Localized mobility management has certain security considerations, Localized mobility management has certain security considerations,
one of which - need for access network to mobile node security - one of which -- the need for security from access network to mobile
was touched on in this document. Host-based localized mobility node -- was discussed in this document. Host-based localized
management protocols have all the security problems involved with mobility management protocols have all the security problems involved
providing a service to a host. Network-based localized mobility with providing a service to a host. Network-based localized mobility
management requires security among network elements equivalent to management requires security among network elements that is
what is needed for routing information security, and security equivalent to what is needed for routing information security, and
between the host and network equivalent to what is needed for security between the host and network that is equivalent to what is
network access, but no more. A more complete discussion of the needed for network access, but no more. A more complete discussion
security goals for network-based localized mobility management can of the security goals for network-based localized mobility management
be found in [11]. can be found in [11].
8.0 References 7. Informative References
8.1 Informative References [1] 3GPP, "UTRAN Iu interface: General aspects and principles", 3GPP
TS 25.410, 2002,
http://www.3gpp.org/ftp/Specs/html-info/25410.htm.
[1] 3GPP, "UTRAN Iu interface: General aspects and principles",
3GPP TS 25.410, 2002.
[2] 3GPP, "3GPP System Architecture Evolution: Report on Technical [2] 3GPP, "3GPP System Architecture Evolution: Report on Technical
Options and Conclusions", TR 23.882, 2005, Options and Conclusions", TR 23.882, 2005,
http://www.3gpp.org/ftp/Specs/html-info/23882.htm. http://www.3gpp.org/ftp/Specs/html-info/23882.htm.
[3] Bluetooth SIG, "Specification of the Bluetooth System", [3] Bluetooth SIG, "Specification of the Bluetooth System",
November, 2004, available at http://www.bluetooth.com. November, 2004, available at http://www.bluetooth.com.
[4] Eronen, P., editor, "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June, 2006. [4] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",
[5] http://www.ieee802.org/15/pub/TG3a.htm RFC 4555, June 2006.
[5] IEEE 802.15 WPAN High Rate Alternative PHY Task Group 3a (TG3a),
http://www.ieee802.org/15/pub/TG3a.html.
[6] IEEE, "Wireless LAN Medium Access Control (MAC)and Physical [6] IEEE, "Wireless LAN Medium Access Control (MAC)and Physical
Layer (PHY) specifications", IEEE Std. 802.11, 1999. Layer (PHY) specifications", IEEE Std. 802.11, 1999.
[7] IEEE, "Amendment to IEEE Standard for Local and Metropolitan [7] IEEE, "Amendment to IEEE Standard for Local and Metropolitan
Area Networks - Part 16: Air Interface for Fixed Broadband Area Networks - Part 16: Air Interface for Fixed Broadband
Wireless Access Systems- Physical and Medium Access Control Wireless Access Systems- Physical and Medium Access Control
Layers for Combined Fixed and Mobile Operation in Licensed Layers for Combined Fixed and Mobile Operation in Licensed
Bands", IEEE Std. 802.16e-2005, 2005. Bands", IEEE Std. 802.16e-2005, 2005.
[8] IEEE, "Carrier sense multiple access with collision detection [8] IEEE, "Carrier sense multiple access with collision detection
(CSMA/CD) access method and physical layer specifications", (CSMA/CD) access method and physical layer specifications", IEEE
IEEE Std. 802.3-2005, 2005. Std. 802.3-2005, 2005.
[9] ITU-T, "Architecture of Transport Networks Based on the [9] ITU-T, "Architecture of Transport Networks Based on the
Synchronous Digital Hierarchy (SDH)", ITU-T G.803, March, Synchronous Digital Hierarchy (SDH)", ITU-T G.803, March, 2000.
2000.
[10] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in [10] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6," RFC 3775. IPv6", RFC 3775, June 2004.
[11] Kempf, J., editor, "Goals for Network-based Localized Mobility
Management", Internet Draft, work in progress. [11] Kempf, J., Ed., "Goals for Network-Based Localized Mobility
Management (NETLMM)", RFC 4831, April 2007.
[12] Koodli, R., "IP Address Location Privacy and Mobile IPv6: [12] Koodli, R., "IP Address Location Privacy and Mobile IPv6:
Problem Statement", Internet Draft, work in progress. Problem Statement", Work in Progress, February 2007.
[13] Koodli, R., editor, "Fast Handovers for Mobile IPv6," RFC
4068, July, 2005. [13] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July
[14] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC 2005.
3753, June, 2004.
[14] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
3753, June 2004.
[15] Metro Ethernet Forum, " Metro Ethernet Network Architecture [15] Metro Ethernet Forum, " Metro Ethernet Network Architecture
Framework - Part 1: Generic Framework", MEF 4, May, 2004. Framework - Part 1: Generic Framework", MEF 4, May, 2004.
[16] Moskowitz, R., and Nikander, P., "Host Identity Protocol (HIP)
Architecture", RFC 4423, May, 2006.
[17] Perkins, C., editor, "IP Mobility Support for IPv4", RFC 3220,
August, 2002.
[18] Soliman, H., Castelluccia, C., El Malki, K., and Bellier. L.,
"Hierarchical Mobile IPv6 Mobility Management," RFC 4140,
August, 2005.
9.0 Acknowledgements [16] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP)
Architecture", RFC 4423, May 2006.
The authors would like to acknowledge the following for [17] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
particularly diligent reviewing: Vijay Devarapalli, Peter McCann, 2002.
Gabriel Montenegro, Vidya Narayanan, Pekka Savola, and Fred
Templin.
10.0 Author's Addresses [18] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC
4140, August 2005.
James Kempf 8. Acknowledgements
DoCoMo USA Labs
181 Metro Drive, Suite 300 The authors would like to acknowledge the following for particularly
San Jose, CA 95110 diligent reviewing: Vijay Devarapalli, Peter McCann, Gabriel
USA Montenegro, Vidya Narayanan, Pekka Savola, and Fred Templin.
Phone: +1 408 451 4711
Email: kempf@docomolabs-usa.com 9. Contributors
Kent Leung Kent Leung
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
EMail: kleung@cisco.com EMail: kleung@cisco.com
Phil Roberts Phil Roberts
Motorola Labs Motorola Labs
Schaumberg, IL Schaumberg, IL
USA USA
Email: phil.roberts@motorola.com EMail: phil.roberts@motorola.com
Katsutoshi Nishida Katsutoshi Nishida
NTT DoCoMo Inc. NTT DoCoMo Inc.
3-5 Hikarino-oka, Yokosuka-shi 3-5 Hikarino-oka, Yokosuka-shi
Kanagawa, Kanagawa,
Japan Japan
Phone: +81 46 840 3545 Phone: +81 46 840 3545
Email: nishidak@nttdocomo.co.jp EMail: nishidak@nttdocomo.co.jp
Gerardo Giaretta Gerardo Giaretta
Telecom Italia Lab Telecom Italia Lab
via G. Reiss Romoli, 274 via G. Reiss Romoli, 274
10148 Torino 10148 Torino
Italy Italy
Phone: +39 011 2286904 Phone: +39 011 2286904
Email: gerardo.giaretta@tilab.com EMail: gerardo.giaretta@tilab.com
Marco Liebsch Marco Liebsch
NEC Network Laboratories NEC Network Laboratories
Kurfuersten-Anlage 36 Kurfuersten-Anlage 36
69115 Heidelberg 69115 Heidelberg
Germany Germany
Phone: +49 6221-90511-46 Phone: +49 6221-90511-46
Email: marco.liebsch@ccrle.nec.de EMail: marco.liebsch@ccrle.nec.de
11.0 IPR Statements Editor's Address
James Kempf
DoCoMo USA Labs
181 Metro Drive, Suite 300
San Jose, CA 95110
USA
Phone: +1 408 451 4711
EMail: kempf@docomolabs-usa.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such this document or the extent to which any license under such rights
rights might or might not be available; nor does it represent that might or might not be available; nor does it represent that it has
it has made any independent effort to identify any such rights. made any independent effort to identify any such rights. Information
Information on the procedures with respect to rights in RFC on the procedures with respect to rights in RFC documents can be
documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
12.0 Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
13.0 Copyright Notice Acknowledgement
Copyright (C) The Internet Society (2006). This document is Funding for the RFC Editor function is currently provided by the
subject to the rights, licenses and restrictions contained in BCP Internet Society.
78, and except as set forth therein, the authors retain all their
rights.
 End of changes. 87 change blocks. 
355 lines changed or deleted 352 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/