draft-ietf-netlmm-nohost-ps-01.txt   draft-ietf-netlmm-nohost-ps-02.txt 
J. Kempf,Editor Internet Draft J. Kempf, Editor
Internet Draft K. Leung Document: draft-ietf-netlmm-nohost-ps-02.txt
Document: draft-ietf-netlmm-nohost-ps-01.txt P. Roberts
K. Nishida
G. Giaretta
M. Liebsch
Expires: October, 2006 April, 2006 Expires: December, 2006 June, 2006
Problem Statement for IP Local Mobility Problem Statement for Network-based IP Local Mobility
(draft-ietf-netlmm-nohost-ps-01.txt) (draft-ietf-netlmm-nohost-ps-02.txt)
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any 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 applicable patent or other IPR claims of which he or she is aware
or will be disclosed, and any of which he or she becomes aware will be have been or will be disclosed, and any of which he or she becomes
disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force Internet-Drafts are working documents of the Internet Engineering
(IETF), its areas, and its working groups. Note that other groups may also Task Force (IETF), its areas, and its working groups. Note that
distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and Internet-Drafts are draft documents valid for a maximum of six
may be updated, replaced, or obsoleted by other documents at any time. It is months and may be updated, replaced, or obsoleted by other
inappropriate to use Internet-Drafts as reference material or to cite them documents at any time. It is inappropriate to use Internet-Drafts
other than as "work in progress." as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/1id-abstracts.html.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
In this document, the well-known problem of localized mobility management Localized mobility management is a well understood concept in the
for IP link handover is given a fresh look. After a short discussion of the IETF with a number of solutions already available. This document
problem and a couple of scenarios, the principal shortcomings of existing looks at the principal shortcomings of the existing solutions, all
solutions are discussed. of which involve the host in mobility management, and makes a case
for 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.0 Introduction.............................................2
2.0 The Local Mobility Problem.......................................4 2.0 The Local Mobility Problem...............................4
3.0 Scenarios for Localized Mobility Management......................6 3.0 Scenarios for Localized Mobility Management..............6
4.0 Problems with Existing Solutions.................................7 4.0 Problems with Existing Solutions.........................7
5.0 Security Considerations..........................................9 5.0 IANA Considerations......................................9
6.0 Author Information...............................................9 6.0 Security Considerations..................................9
7.0 Informative References..........................................10 7.0 Acknowledgements........................................10
8.0 IPR Statements..................................................10 8.0 Author Information......................................10
9.0 Disclaimer of Validity..........................................11 9.0 Informative References...................................9
10.0 Copyright Notice................................................11 10.0 IPR Statements..........................................11
11.0 Disclaimer of Validity..................................11
12.0 Copyright Notice........................................11
1.0 Introduction 1.0 Introduction
Localized mobility management has been the topic of much work in the IETF Localized mobility management has been the topic of much work in
for some time, and it may seem as if little remains to be said on the topic. the IETF. The experimental protocols developed from previous work,
The experimental protocols developed from previous work, namely FMIPv6 [1] namely FMIPv6 [1]
and HMIPv6[2], involve host-based solutions that mimic to a greater or and HMIPv6 [2], involve host-based solutions that require host
lesser extent the approach taken by Mobile IPv6 [3] for global mobility 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 [3] for global mobility management.
infrastructure market suggest that it may be time to take a fresh look at However, recent developments in the IETF and the WLAN
localized mobility management. Firstly, new IETF work on global mobility infrastructure market suggest that it may be time to take a fresh
management protocols that are not Mobile IPv6, such as HIP [4] and Mobike look at localized mobility management. Firstly, new IETF work on
[5], suggests that future wireless IP nodes may support a more diverse set global mobility management protocols that are not Mobile IPv6, such
of global mobility protocols. Secondly, the success in the WLAN as HIP [4] and Mobike [5], suggests that future wireless IP nodes
infrastructure market of WLAN switches, which perform localized mobility may support a more diverse set of global mobility protocols. While
management without any host stack involvement, suggests a possible design it is possible that existing localized mobility management
paradigm that could be used to accommodate other global mobility management protocols could be used with HIP and Mobike, it would require
options on the mobile node while reducing host stack software complexity and additional effort to implement and deploy these localized mobility
expanding the range of mobile nodes that could be accommodated. management protocols in an non-Mobile IPv6 mobile environment.
Secondly, the success in the WLAN infrastructure market of WLAN
switches, which perform localized management without any host stack
involvement, suggests a possible paradigm that could be used to
accommodate other global mobility options on the mobile node while
reducing host stack software complexity expanding the range of
mobile nodes that could be accommodated.
This document briefly describes the local mobility problem and a few This document briefly describes the general local mobility problem
scenarios where localized mobility management would be desirable. Then, it and scenarios where localized mobility management would be
describes the two most serious problems with existing protocols: the desirable. Then problems with existing or proposed IETF localized
requirement for host stack support, and the complex security interactions mobility management protocols are briefly discussed. The network-
required between the mobile node and the access network. More detailed based mobility management architecture and a short description of
requirements and gap analysis for existing protocols can be found in [6]. how it solves these problems is presented. A more detailed
discussion of goals for a network-based, localized mobility
management protocol and gap analysis for existing protocols can be
found in [6]. Note that IPv6 and wireless links are considered to
be the primary focal points for a network-based localized mobility
management, so the language in this document reflects that focus.
However, the conclusions of this document apply equally to IPv4 and
wired links where nodes are disconnecting and reconnecting.
1.1 Terminology 1.1 Terminology
Mobility terminology in this draft follows that in RFC 3753
Mobility terminology in this draft follows that in RFC 3753 [7], with the [7], with the addition of some new and revised terminology
addition of some new and revised terminology given here: given here:
IP Link IP Link
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) A set of routers, mobile nodes, and wireless access points
An Access Network consists of following three components: wireless or that share link broadcast capability or its functional
other access points, access routers, access network gateways which form equivalent. This definition covers one or multiple access
the boundary to other networks and may shield other networks from the points under one or several access routers. In the past,
specialized routing protocols (if any) run in the Access Network; and such a set has been called a subnet, but this term is not
(optionally) other internal access network routers which may also be strictly correct for IPv6, since multiple subnet prefixes
needed in some cases to achieve a specialized routing protocol. can be assigned to an IP link in IPv6.
Local Mobility (revised) Local Mobility (revised)
Local Mobility is mobility over a restricted area of the network Local Mobility is mobility over an access network. Note
topology. Note that, although the area of network topology over which that, although the area of network topology over which the
the mobile node moves may be restricted, the actual geographic area mobile node moves may be restricted, the actual geographic
could be quite large, depending on the mapping between the network area could be quite large, depending on the mapping between
topology and the wireless coverage area. the network topology and the wireless coverage area.
Localized Mobility Management Localized Mobility Management
Localized Mobility Management is a generic term for protocols dealing
with IP mobility management confined within the access network. Localized Mobility Management is a generic term for any IP
Localized mobility management signaling is not routed outside the protocol that maintains the IP connectivity and reachability
access network, although a handover may trigger Global Mobility of a mobile node when it moves, and whose signalling is
Management signaling. Localized mobility management protocols exploit confined to an access network.
the locality of movement by confining movement related changes to the
access 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 Protocol Global Mobility Management 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 A Global Mobility Management Protocol is a mobility protocol
causes a topology change and thus invalidates a global unicast address used by the mobile node to change the global, end-to-end
on the local IP link currently in active use by the mobile node. The routing of packets when movement causes a topology change
Global Mobility Protocol may also allow the mobile node to maintain a and thus invalidates a global unicast address on the local
mapping between a permanent address and a temporary address on the IP link currently in active use by the mobile node. This
local network for rendezvous with nodes that want to initiate a protocol could be Mobile IP [1][13] but it could also be HIP
connection. Typically, this protocol will be Mobile IPv6 [1] but it [4] or Mobike [5] (Note: although Mobike is not considered a
could also be HIP [4] or Mobike [5] (Note: although Mobike is not mobility management protocol in general, for purposes of
considered a mobility management protocol in general, for purposes of this document, it will be so considered because it manages
this document, it will be so considered because it manages the address the address map and routing between a fixed VPN endpoint
map and routing between a fixed VPN endpoint address and a changing address and a changing local address).
local address).
Global Mobility Anchor Point Global Mobility Anchor Point
A node in the network where the mobile node maintains a permanent
address and a mapping between the permanent address and the local A node in the network where the mobile node maintains a
temporary address where the mobile node happens to be currently permanent address and a mapping between the permanent
located. The Global Mobility Anchor Point may be used for purposes of address and the local temporary address where the mobile
rendezvous and possibly traffic forwarding. For Mobile IPv6 [1], this node happens to be currently located. The Global Mobility
is the home agent. For HIP [4], this may be the rendezvous server. For Anchor Point may be used for purposes of rendezvous and
Mobike [5], this is the VPN tunnel gateway in the home network. possibly traffic forwarding. For Mobile IP [1][13], this is
the home agent. For HIP [4], this may be the rendezvous
server. For Mobike [5], this is the VPN gateway in the home
network. Some global mobility management protocols, such as
HIP, support end to end global mobility management without a
Global Mobility Anchor Point, at the risk of dropping a
connection if both sides are mobile and both move at the
same time.
Intra-Link Mobility Intra-Link Mobility
Intra-Link Mobility is mobility between wireless access points within
an IP Link. Typically, this kind of mobility only involves Layer 2 Intra-Link Mobility is mobility between wireless access
mechanisms, so Intra-Link Mobility is often called Layer 2 mobility. No points within an IP Link. Typically, this kind of mobility
IP link configuration is required upon movement since the link does not only involves Layer 2 mechanisms, so Intra-Link Mobility is
change, but some IP signaling may be required for the mobile node to often called Layer 2 mobility. No IP link configuration is
confirm whether or not the change of wireless access point also required upon movement since the link does not change, but
resulted in a change of IP link. If the IP link consists of a single some IP signaling may be required for the mobile node to
access point/router combination, then this type of mobility is confirm whether or not the change of wireless access point
typically absent. See Figure 1. also resulted in a change of IP link. If the IP link
consists of a single access point/router combination, then
this type of mobility is typically absent. See Figure 1.
2.0 The Local Mobility Problem 2.0 The Local Mobility Problem
The local mobility problem is restricted to providing IP mobility management The local mobility problem is restricted to providing IP
for mobile nodes within an access network. The access network aggregation mobility management for mobile nodes within an access network.
routers function as an access network gateway, although in this case, there The access network gateways function as aggregation routers. In
is no specialized routing protocol and the routers function as a standard IP this case, there is no specialized routing protocol (e.g. GTP,
routed network. This is illustrated in Figure 1, where the aggregation Cellular IP, Hawaii, etc.) and the routers form a standard IP
routers are designated as "AggR". Transitions between service providers in routed network (e.g. OSPF, IS-IS, RIP, etc.). This is
separate autonomous systems or across broader topological "boundaries" illustrated in Figure 1, where the access network gateway
within the same service provider are excluded. routers are designated as "ANG". Transitions between service
providers in separate autonomous systems or across broader
topological "boundaries" within the same service provider are
excluded.
Figure 1 depicts the scope of local mobility in comparison to global Figure 1 depicts the scope of local mobility in comparison to
mobility. The Aggregation Routers AggR A1 and B1 are gateways to the access global mobility. The Access Network Gateways (ANGs) GA1 and GB1
network. The Access Routers AR A1 and A2 are in Access Network A, B1 is in are gateways to their access networks. The Access Routers (ARs)
Access Network B. Note that it is possible to have additional aggregation RA1 and RA2 are in access network A, RB1 is in access network
routers between AggR A1 and AggR B1 and the access routers if the access B. Note that it is possible to have additional aggregation
network is large. Access Points AP A1 through A3 are in Access Network A, B1 routers between ANG GA1 and ANG GB1 and the access routers if
and B2 are in Access Network B. Other Aggregation Routers, Access Routers, the access network is large. Access Points (APs) PA1 through
and Access Points are also possible. The figure implies a star topology for PA3 are in access network A, PB1 and PB2 are in access network
the access network deployment, and the star topology is the primary one of B. Other ANGs, ARs, and APs are also possible, and other
interest since it is quite common, but the problems discussed here are routers can separate the ARs from the ANGs. The figure implies
equally relevant to ring or mesh topologies in which access routers are a star topology for the access network deployment, and the star
directly connected through some part of the network. topology is the primary one of interest since it is quite
common, but the problems discussed here are equally relevant to
ring or mesh topologies in which ARs are directly connected
through some part of the network.
Access Network A Access Network B Access Network A Access Network B
+-------+ +-------+ +-------+ +-------+
|AggR A1| (other AggRs) |AggR B1| (other AggRs) |ANG GA1| (other ANGs) |ANG GB1| (other ANGs)
+-------+ +-------+ +-------+ +-------+
@ @ @ @ @ @
@ @ @ @ @ @
@ @ @ (other routers)
@ @ @ @ @ @
@ @ @ @ @ @
@ @ @ @ @ @
@ @ @ +------+ +------+ +------+
+-----+ +-----+ +-----+ |AR RA1| |AR RA2|(other ARs) |AR RB1| (other ARs)
|AR A1| |AR A2|(other ARs) |AR B1| (other ARs) +------+ +------+ +------+
+-----+ +-----+ +-----+
* * * * * *
* * * * * * * * * *
* * * * * * * * * *
* * * * * * * * * *
* * * * * * * * * *
* * * (other APs) * * (other APs) * * * (other APs) * * (other APs)
/\ /\ /\ /\ /\ /\ /\ /\ /\ /\
/AP\ /AP\ /AP\ /AP\ /AP\ /AP\ /AP\ /AP\ /AP\ /AP\
/ A1 \ / A2 \ / A3 \ / B1 \ / B2 \ /PA1 \ /PA2 \ /PA3 \ /PB1 \ /PB2 \
------ ------ ------ ------ ------ ------ ------ ------ ------ ------
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
|MN|----->|MN|----->|MN|-------->|MN| |MN|----->|MN|----->|MN|-------->|MN|
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
Intra-link Local Global Intra-link Local Global
Mobility Mobility Mobility (Layer 2) 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 is necessary when a As shown in the figure, a global mobility protocol may be necessary
mobile node (MN) moves between two access networks. Exactly what the scope when a mobile node (MN) moves between two access networks. Exactly
of the access networks is depends on deployment considerations. Mobility what the scope of the access networks is depends on deployment
between two access points under the same access router constitutes Intra- considerations. Mobility between two APs under the same AR
link mobility, and is typically handled by Layer 2 mobility protocols (if constitutes intra-link, or Layer 2, mobility, and is typically
there is only one access point/cell per access router, then intra-link handled by Layer 2 mobility protocols (if there is only one AP/cell
mobility may be lacking). Between these two lies local mobility. Local per AR, then intra-link mobility may be lacking). Between these two
mobility occurs when a mobile node moves between two access points connected lies local mobility. Local mobility occurs when a mobile node moves
to two different access routers. between two APs connected to two different ARs.
Global mobility protocols allow a mobile node to maintain reachability when Global mobility protocols allow a mobile node to maintain
a change between access routers occurs, by updating the address mapping reachability when the MN's globally routable IP address changes. It
between the permanent address and temporary local address at the global does this by updating the address mapping between the permanent
mobility anchor point, or even end to end by changing the temporary local address and temporary local address at the global mobility anchor
address directly at the node with which the mobile node is corresponding. A point, or even end to end by changing the temporary local address
global mobility management protocol can therefore be used between access directly at the node with which the mobile node is corresponding. A
routers for handling local mobility. However, there are three well-known global mobility management protocol can therefore be used between
problems involved in using a global mobility protocols for every transition ARs for handling local mobility. However, there are three well-
between access routers. Briefly, they are: known problems involved in using a global mobility protocol for
every 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 distance correspondent node (for route optimized traffic) is at some
from the mobile node's access network, the global mobility update may distance from the mobile node's access network, the global
require a considerable amount of time, during which time packets mobility update may require a considerable amount of time.
continue to be routed to the old temporary local address and are During this time, packets continue to be routed to the old
essentially dropped. temporary local address and are essentially dropped.
2) Signaling overhead. The amount of signaling required when a mobile 2) Signaling overhead. The amount of signaling required when a
node moves from one IP link to another can be quite extensive, mobile node moves from one IP link to another can be quite
including all the signaling required to configure an IP address on the extensive, including all the signaling required to configure an
new link and global mobility protocol signaling back into the network IP address on the new link and global mobility protocol
for changing the permanent to temporary local address mapping. The signaling back into the network for changing the permanent to
signaling volume may negatively impact wireless bandwidth usage and temporary local address mapping. The signaling volume may
real time service performance. negatively impact wireless bandwidth usage and real time
3) Location privacy. The change in temporary local address as the mobile service performance.
node moves exposes the mobile node's topological location to 3) Location privacy. The change in temporary local address as the
correspondents and potentially to eavesdroppers. An attacker that can mobile node moves exposes the mobile node's topological
assemble a mapping between subnet prefixes in the mobile node's access location to correspondents and potentially to eavesdroppers. An
network and geographical locations can determine exactly where the attacker that can assemble a mapping between subnet prefixes in
mobile node is located. This can expose the mobile node's user to the mobile node's access network and geographical locations can
threats on their location privacy. determine exactly where the mobile node is located. This can
expose the mobile node's user to threats on their location
privacy. A more detailed discussion of location privacy for
Mobile IPv6 can be found in [12].
These problems suggest that a protocol to localize the management of These problems suggest that a protocol to localize the management
topologically small movements is preferable to using a global mobility of topologically small movements is preferable to using a global
management protocol on each IP link move. In addition to these problems, mobility management protocol on each IP link move. In addition to
localized mobility management can provide a measure of local control, so these problems, localized mobility management can provide a measure
mobility management can be tuned for specialized local conditions. Note also of local control, so mobility management can be tuned for
that if localized mobility management is provided, it is not strictly specialized local conditions. Note also that if localized mobility
required for a mobile node to support a global mobility management protocol management is provided, it is not strictly required for a mobile
since movement within a restricted IP access network can still be node to support a global mobility management protocol since
accommodated. Without such support, however, a mobile node experiences a movement within a restricted IP access network can still
disruption in its traffic when it moves beyond the border of the localized be accommodated. Without such support, however, a mobile node
mobility management domain. experiences a disruption in its traffic when it moves beyond the
border of the localized mobility management domain.
3.0 Scenarios for Localized Mobility Management 3.0 Scenarios for Localized Mobility Management
There are a variety of scenarios in which localized mobility management is There are a variety of scenarios in which localized mobility
attractive. management is useful.
3.1 Large Campus with Diverse Physical Interconnectivity 3.1 Large Campus
One scenario where localized mobility management would be attractive is for One scenario where localized mobility management would be
a campus wireless LAN deployment in which parts of the campus are connected attractive is a large campus wireless LAN deployment. Having a
by links that are other than 802.3 or in which it is not possible to cover single broadcast domain for all WLAN access points doesn't scale
the campus by one VLAN. In this case, the campus is divided into separate IP very well. Also, sometimes parts of the campus cannot be covered
links each served by one or more access routers. This kind of deployment is by one VLAN for other reasons (e.g., some links are other than
served today by wireless LAN switches that co-ordinate IP mobility between 802.3).
them, effectively providing localized mobility management at the link layer.
Since the protocols are proprietary and not interoperable, any deployments In this case, the campus is divided into separate IP links each
that require IP mobility necessarily require switches from the same vendor. served by one or more access routers. This kind of deployment is
served today by wireless LAN switches that co-ordinate IP mobility
between them, effectively providing localized mobility management
at the link layer. Since the protocols are proprietary and not
interoperable, any deployments that require IP mobility necessarily
require switches from the same vendor.
3.2 Advanced Cellular Network 3.2 Advanced Cellular Network
Next generation cellular protocols such as 802.16e [8] and Super 3G/3.9G [9] Next generation cellular protocols such as 802.16e [8] and Super
have the potential to run IP deeper into the access network than the current 3G/3.9G [9] have the potential to run IP deeper into the access
3G cellular protocols, similar to today's WLAN networks. This means that the network than the current 3G cellular protocols, similar to today's
access network can become a routed IP network. Interoperable localized WLAN networks. This means that the access network can become a
mobility management can unify local mobility across a diverse set of routed IP network. Interoperable localized mobility management can
wireless protocols all served by IP, including advanced cellular, WLAN, and unify local mobility across a diverse set of wireless protocols all
personal area wireless technologies such as UWB and Bluetooth. Localized served by IP, including advanced cellular, WLAN, and personal area
mobility management at the IP layer does not replace Layer 2 mobility (where wireless technologies such as UltraWide Band (UWB) [10] and
available) but rather complements it. A standardized, interoperable Bluetooth [11]. Localized mobility management at the IP layer does
localized mobility management protocol for IP can remove the dependence on not replace Layer 2 mobility (where available) but rather
IP layer localized mobility protocols that are specialized to specific link complements it. A standardized, interoperable localized mobility
management protocol for IP can remove the dependence on IP layer
localized mobility protocols that are specialized to specific link
technologies or proprietary, which is the situation with today's 3G technologies or proprietary, which is the situation with today's 3G
protocols. The expected benefit is a reduction in maintenance cost and protocols. The expected benefit is a reduction in maintenance cost
deployment complexity. See [6] for a more detailed discussion of the and deployment complexity. See [6] for a more detailed discussion
requirements for localized mobility management. of the goals for a network-based localized mobility management
protocol.
3.3 Picocellular Network with Small But Node-Dense IP Links 3.3 Picocellular Network with Small But Node-Dense IP Links
Future radio link protocols at very high frequencies may be constrained to Future radio link protocols at very high frequencies may be
very short, line of sight operation. Even some existing protocols, such as constrained to very short, line of sight operation. Even some
UWB and Bluetooth, are designed for low power, short range operation. For existing protocols, such as UWB and Bluetooth, are designed for low
such protocols, extremely small picocells become more practical. Although transmit power, short range operation. For such protocols,
picocells do not necessarily imply "pico IP links", wireless sensors and extremely small picocells become more practical. Although picocells
other advanced applications may end up making such picocellular type do not necessarily imply "pico IP links", wireless sensors and
networks node-dense, requiring subnets that cover small geographical areas, other advanced applications may end up making such picocellular
such as a single room. The ability to aggregate many subnets under a type networks node-dense, requiring subnets that cover small
localized mobility management scheme can help reduce the amount of IP geographical areas, such as a single room. The ability to aggregate
signaling required on IP link movement. many subnets under a localized mobility management scheme can help
reduce the amount of IP signaling required on IP link movement.
4.0 Problems with Existing Solutions 4.0 Problems with Existing Solutions
Existing solutions for localized mobility management fall into three Existing solutions for localized mobility management fall into
classes: three classes:
1) Interoperable IP level protocols that require changes to the mobile node's 1) Interoperable IP level protocols that require changes to the
IP stack and handle localized mobility management as a service provided to mobile node's IP stack and handle localized mobility management
the mobile node by the access network, as a service provided to the mobile node by the access network,
2) Link specific or proprietary protocols that handle localized mobility for 2) Link specific or proprietary protocols that handle localized
any mobile node but only for a specific type of link layer, namely 802.11 mobility for any mobile node but only for a specific type of
running on an 802.3 wired network backhaul. link layer, namely 802.11 running on an 802.3 wired network
3) Use of a standard IGP such as OSPF or IS-IS to distribute host routes, and backhaul.
updating the host routes when the mobile node moves.
For Solution 1, the following are specific problems: The dedicated localized mobility management IETF protocols for
Solution 1 are not yet widely deployed, but work continues on
standardization. Some Mobile IPv4 deployments use localized
mobility management. For Solution 1, the following are specific
problems:
1) The host stack software requirement limits broad usage even if the 1) The host stack software requirement limits broad usage even if
modifications are small. The success of WLAN switches indicates that the modifications are small. The success of WLAN switches
network operators and users prefer no host stack software modifications. indicates that network operators and users prefer no host stack
This preference is likely to be independent of the lack of widespread software modifications. This preference is independent of the
Mobile IPv4 deployment, since it is much easier to deploy and use the lack of widespread Mobile IPv4 deployment, since it is much
network. 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 mobility protocols, such as HIP or Mobike. The existing localized
management solutions all depend on Mobile IP or derivatives. mobility management solutions all depend on Mobile IP or
3) Existing localized mobility management solutions do not support both IPv4 derivatives.
and IPv6. 3) Existing localized mobility management solutions do not support
both IPv4 and IPv6.
4) Existing host-based localized mobility management solutions
require setting up additional security associations with network
elements in the access domain.
4) Security for the existing localized mobility management solutions Market acceptance of WLAN switches has been very large, so Solution
requires complex security associations with network elements for no 2 is widely deployed and continuing to grow. Solution 2 has the
improvement in security over what is available if localized mobility following problems:
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.
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.
1) Existing solutions only support WLAN networks with Ethernet backhaul and Having an interoperable, standardized localized mobility management
therefore are not available for advanced cellular networks or protocol that is scalable to topologically large networks, but
picocellular protocols, or other types of wired backhaul. requires no host stack involvement for localized mobility
2) Each WLAN switch vendor has its own proprietary protocol that does not management is a highly desirable solution. Mobility routing anchor
interoperate with other vendor's equipment. points within the backbone network maintain a collection of routes
3) Because the solutions are based on layer 2 routing, they may not scale up for individual mobile nodes. The routes point to the ARs on which
to a metropolitan area, or local province. mobile nodes currently are located. Packets for the mobile node are
routed to and from the mobile node through the mobility anchor
point. When a mobile node moves from one AR to another, the ARs
send a route update to the mobility anchor point. While some mobile
node involvement is necessary and expected for generic mobility
functions such as movement detection and to inform the AR about
mobile node movement, no specific mobile node to network protocol
will be required for localized mobility management itself.
Solution 3 has the following problems: The advantages that this solution has over the Solutions 1 and 2
above are as follows:
1) Each router in the localized mobility management domain is required to 1) Compared with Solution 1, a network-based solution requires no
maintain a host route table and to search the host route table for localized mobility management support on the mobile node and is
routing each packet, limiting the memory and processing power independent of global mobility management protocol, so it can
scalability. be used with any or none of the existing global mobility
2) After handover, until host routes propagate back along the current path management protocols. The result is a more modular mobility
of traffic to the localized mobility management domain border, traffic management architecture that better accommodates changing
packets for the mobile node are sent to the old router, causing the technology and market requirements.
packets to drop. Since IGPs typically propagate routing updates through 2) Compared with Solution 2, an IP level network-based localized
flooding, the delay in host route propagation also limits the topological mobility management solution works for link protocols other
span of the localized mobility management domain. than Ethernet, and for wide area networks.
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 5.0 IANA Considerations
that is scalable to topologically large networks, but requires no host stack
involvement for localized mobility management is a highly desirable
solution. Mobility routing anchor points within the backbone network
maintain a collection of routes for individual mobile nodes. The routes
point to the access routers on which mobile nodes currently are located.
Packets for the mobile node are routed to and from the mobile node through
the mobility anchor point. When a mobile node moves from one access router
to another, the access routers send a route update to the mobility anchor
point. While some mobile node involvement is necessary and expected for
generic mobility functions such as movement detection and to inform the
access router about mobile node movement, no specific mobile node to network
protocol will be required for localized mobility management itself.
The advantages that this solution has over the Solutions 1 through 3 above There are no IANA considerations in this document.
are as follows:
1) Compared with Solution 1, a network-based solution requires no localized 6.0 Security Considerations
mobility management support on the mobile node and is independent of
global mobility management protocol, so it can be used with any or none
of the existing global mobility management protocols. The result is a
more modular mobility management architecture that better accommodates
changing technology and 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.
3) Compared with Solution 3, the framework described above for network-based
localized mobility management only requires the involvement of the access
routers and the mobility anchor. All other routers within the localized
mobility management domain do not need to handle host routes, making the
architecture more scalable. In addition, because updating the routes
requires communication between only two routers, propagation of routes on
handover is likely to be much faster.
5.0 Security Considerations Localized mobility management has certain security considerations,
one of which - need for access network to mobile node security -
was touched on in this document. Host-based localized mobility
management protocols have all the security problems involved with
providing a service to a host. Network-based localized mobility
management requires security among network elements equivalent to
what is needed for routing information security, and security
between the host and network equivalent to what is needed for
network access, but no more. A more complete discussion of the
security goals for network-based localized mobility management can
be found in [6].
Localized mobility management has certain security considerations, one of 7.0 References
which - need for access network to mobile node security - was touched on in
this document. Existing localized mobility management solutions increase the
need for mobile node to access network signaling and provisioning of the
mobile node with credentials without increasing the security beyond what is
available if no localized mobility management solution is used. A more
complete discussion of the security requirements for localized mobility
management can be found in [6].
6.0 Author Information 7.1 Informative References
[1] Koodli, R., editor, "Fast Handovers for Mobile IPv6," RFC
4068, July, 2005.
[2] Soliman, H., editor, "Hierarchical Mobile IPv6 Mobility
Management," RFC 4140, August, 2005.
[3] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in
IPv6," RFC 3775.
[4] Moskowitz, R., and Nikander, P., "Host Identity Protocol (HIP)
Architecture", RFC 4423, May, 2006.
[5] Eronen, P., editor, "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", Internet Draft, work in progress.
[6] Kempf, J., editor, "Goals for Network-based Localized Mobility
Management", Internet Draft, work in progress.
[7] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC
3753, June, 2004.
[8] IEEE, "Air Interface for Mobile Broadband Wireless Access
Systems", 802.16e, 2005.
[9] 3GPP, "3GPP System Architecture Evolution: Report on Technical
Options and Conclusions", TR 23.882, 2005,
http://www.3gpp.org/ftp/Specs/html-info/23882.htm.
[10] http://www.ieee802.org/15/pub/TG3a.htm
[11] Bluetooth SIG, "Specification of the Bluetooth System",
November, 2004, available at http://www.bluetooth.com.
[12] Koodli, R., "IP Address Location Privacy and Mobile IPv6:
Problem Statement", Internet Draft, work in progress.
[13] Perkins, C., editor, " IP Mobility Support for IPv4", RFC
3220, August, 2002.
8.0 Acknowledgements
The authors would like to acknowledge the following for
particularly diligent reviewing: Pekka Savola, Vijay Devarapalli,
Gabriel Montenegro, Peter McCann, and Vidya Narayanan.
9.0 Author's Addresses
James Kempf James Kempf
DoCoMo USA Labs DoCoMo USA Labs
181 Metro Drive, Suite 300 181 Metro Drive, Suite 300
San Jose, CA 95110 San Jose, CA 95110
USA USA
Phone: +1 408 451 4711 Phone: +1 408 451 4711
Email: kempf@docomolabs-usa.com Email: kempf@docomolabs-usa.com
Kent Leung Kent Leung
skipping to change at page 10, line 22 skipping to change at page 11, line 16
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
7.0 Informative References 10.0 IPR Statements
[1] Koodli, R., editor, "Fast Handovers for Mobile IPv6," RFC 4068, July,
2005.
[2] Soliman, H., editor, "Hierarchical Mobile IPv6 Mobility Management,"
RFC 4140, August, 2005.
[3] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in IPv6,"
RFC 3775.
[4] Moskowitz, R., Nikander, P., Jokela, P., and Henderson, T., "Host
Identity Protocol", Internet Draft, work in progress.
[5] Kivinen, T., and Tschopfening, H., "Design of the MOBIKE Protocol",
Internet Draft, work in progress.
[6] Kempf, J., Leung, K., Roberts, P., Giaretta, G., Liebsch, M., and
Nishita, K.., "Requirements and Gap Analysis for Localized Mobility
Management", Internet Draft, work in progress.
[7] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC 3753,
June, 2004.
[8] IEEE, "Air Interface for Mobile Broadband Wireless Access Systems",
802.16e, 2005.
[9] 3GPP, "3GPP System Architecture Evolution: Report on Technical Options
and Conclusions", TR 23.882, 2005, http://www.3gpp.org/ftp/Specs/html-
info/23882.htm.
8.0 IPR Statements
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 to Intellectual Property Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in this to pertain to the implementation or use of the technology described
document or the extent to which any license under such rights might or might in this document or the extent to which any license under such
not be available; nor does it represent that it has made any independent rights might or might not be available; nor does it represent that
effort to identify any such rights. Information on the procedures with it has made any independent effort to identify any such rights.
respect to rights in RFC documents can be found in BCP 78 and BCP 79. Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of Copies of IPR disclosures made to the IETF Secretariat and any
licenses to be made available, or the result of an attempt made to obtain a assurances of licenses to be made available, or the result of an
general license or permission for the use of such proprietary rights by attempt made to obtain a general license or permission for the use
implementers or users of this specification can be obtained from the IETF of such proprietary rights by implementers or users of this
on-line IPR repository at http://www.ietf.org/ipr. specification can be obtained from the IETF on-line IPR repository
at 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 rights that copyrights, patents or patent applications, or other proprietary
may cover technology that may be required to implement this standard. rights that may cover technology that may be required to implement
Please address the information to the IETF at ietf-ipr@ietf.org. this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
9.0 Disclaimer of Validity 11.0 Disclaimer of Validity
This document and the information contained herein are provided on an "AS This document and the information contained herein are provided on
IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
FOR A PARTICULAR PURPOSE. ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
10.0 Copyright Notice 12.0 Copyright Notice
Copyright (C) The Internet Society (2006). This document is subject to the Copyright (C) The Internet Society (2006). This document is
rights, licenses and restrictions contained in BCP 78, and except as set subject to the rights, licenses and restrictions contained in BCP
forth therein, the authors retain all their rights. 78, and except as set forth therein, the authors retain all their
rights.
 End of changes. 61 change blocks. 
363 lines changed or deleted 413 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/