draft-ietf-netlmm-nohost-ps-02.txt   draft-ietf-netlmm-nohost-ps-03.txt 
Internet Draft J. Kempf, Editor Internet Draft J. Kempf, Editor
Document: draft-ietf-netlmm-nohost-ps-02.txt Document: draft-ietf-netlmm-nohost-ps-03.txt
Expires: December, 2006 June, 2006 Expires: December, 2006 June, 2006
Problem Statement for Network-based IP Local Mobility Problem Statement for Network-based IP Local Mobility
(draft-ietf-netlmm-nohost-ps-02.txt) (draft-ietf-netlmm-nohost-ps-03.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 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Marco Liebsch all contributed major effort to this document. Their Marco Liebsch all contributed major effort to this document. Their
names are not included in the authors' section due to the RFC names are not included in the authors' section due to the RFC
Editor's limit of 5 names. 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 IANA Considerations......................................9 5.0 IANA Considerations......................................8
6.0 Security Considerations..................................9 6.0 Security Considerations..................................8
7.0 Acknowledgements........................................10 7.0 References...............................................9
8.0 Author Information......................................10 8.0 Acknowledgements.........................................9
9.0 Informative References...................................9 9.0 Author's Addresses.......................................9
10.0 IPR Statements..........................................11 10.0 IPR Statements..........................................10
11.0 Disclaimer of Validity..................................11 11.0 Disclaimer of Validity..................................11
12.0 Copyright Notice........................................11 12.0 Copyright Notice........................................11
1.0 Introduction 1.0 Introduction
Localized mobility management has been the topic of much work in Localized mobility management has been the topic of much work in
the IETF. The experimental protocols developed from previous work, the IETF. The experimental protocols developed from previous work,
namely FMIPv6 [1] namely FMIPv6 [1] and HMIPv6 [2], involve host-based solutions that
and HMIPv6 [2], involve host-based solutions that require host require host involvement at the IP layer similar to or in addition
involvement at the IP layer similar to or in addition to that to that required by Mobile IPv6 [3] for global mobility management.
required by Mobile IPv6 [3] for global mobility management.
However, recent developments in the IETF and the WLAN However, recent developments in the IETF and the 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. Firstly, new IETF work on look at localized mobility management.
global mobility management protocols that are not Mobile IPv6, such
as HIP [4] and Mobike [5], suggests that future wireless IP nodes Firstly, new IETF work on global mobility management protocols that
may support a more diverse set of global mobility protocols. While are not Mobile IPv6, such as HIP [4] and Mobike [5], suggests that
it is possible that existing localized mobility management future wireless IP nodes may support a more diverse set of global
protocols could be used with HIP and Mobike, it would require mobility protocols. While it is possible that existing localized
additional effort to implement and deploy these localized mobility mobility management protocols could be used with HIP and Mobike,
management protocols in an non-Mobile IPv6 mobile environment. some would require additional effort to implement and deploy in a
non-Mobile IPv6 mobile environment.
Secondly, the success in the WLAN infrastructure market of WLAN Secondly, 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. Then problems with existing or proposed IETF localized desirable. Then problems with existing or proposed IETF localized
skipping to change at page 3, line 8 skipping to change at page 3, line 8
be the primary focal points for a network-based localized mobility be the primary focal points for a network-based localized mobility
management, so the language in this document reflects that focus. management, so the language in this document reflects that focus.
However, the conclusions of this document apply equally to IPv4 and However, the conclusions of this document apply equally to IPv4 and
wired links where nodes are disconnecting and reconnecting. 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 addition of some new and revised terminology [7], with the addition of some new and revised terminology
given here: given here:
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.
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, although the area of network topology over which the that, although the area of network topology over which the
mobile node moves may be restricted, the actual geographic mobile node moves may be restricted, the actual geographic
area could be quite large, depending on the mapping between area could be quite large, depending on the mapping between
the network 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 any IP Localized Mobility Management is a generic term for any IP
protocol that maintains the IP connectivity and reachability protocol that maintains the IP connectivity and reachability
of a mobile node when it moves, and whose signalling is of a mobile node for purposes of maintaining session
confined to an access network. continuitity when the mobile node moves, and whose signaling
is confined to an 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 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 by the mobile node to change the global, end-to-end used by the mobile node to change the global, end-to-end
routing of packets when movement causes a topology change routing of packets for purposes of maintaining session
and thus invalidates a global unicast address on the local continuity when movement causes a topology change and thus
IP link currently in active use by the mobile node. This invalidates a global unicast address of the mobile node.
protocol could be Mobile IP [1][13] but it could also be HIP This protocol could be Mobile IP [1][13] but it could also
[4] or Mobike [5] (Note: although Mobike is not considered a be HIP [4] or Mobike [5].
mobility management protocol in general, for purposes of
this document, it will be so considered because it manages
the address map and routing between a fixed VPN endpoint
address and a changing local address).
Global Mobility Anchor Point 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 address and a mapping between the permanent permanent address and a mapping between the permanent
address and the local temporary address where the mobile address and the local temporary address where the mobile
node happens to be currently located. The Global Mobility node happens to be currently located. The Global Mobility
Anchor Point may be used for purposes of rendezvous and Anchor Point may be used for purposes of rendezvous and
possibly traffic forwarding. For Mobile IP [1][13], this is possibly traffic forwarding.
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 Intra-Link Mobility is mobility between wireless access
points within an IP Link. Typically, this kind of mobility points within a link. Typically, this kind of mobility only
only involves Layer 2 mechanisms, so Intra-Link Mobility is involves Layer 2 mechanisms, so Intra-Link Mobility is often
often called Layer 2 mobility. No IP link configuration is called Layer 2 mobility. No IP subnet configuration is
required upon movement since the link does not change, but required upon movement since the link does not change, but
some IP signaling may be required for the mobile node to some IP signaling may be required for the mobile node to
confirm whether or not the change of wireless access point confirm whether or not the change of wireless access point
also resulted in a change of IP link. If the IP link also resulted in the previous access routers becoming
consists of a single access point/router combination, then unreachable. If the link is served by a single access
this type of mobility is typically absent. See Figure 1. 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 The local mobility problem is restricted to providing IP mobility
mobility management for mobile nodes within an access network. management for mobile nodes within an access network. The access
The access network gateways function as aggregation routers. In network gateways function as aggregation routers. In this case,
this case, there is no specialized routing protocol (e.g. GTP, there is no specialized routing protocol (e.g. GTP, Cellular IP,
Cellular IP, Hawaii, etc.) and the routers form a standard IP Hawaii, etc.) and the routers form a standard IP routed network
routed network (e.g. OSPF, IS-IS, RIP, etc.). This is (e.g. OSPF, IS-IS, RIP, etc.). This is illustrated in Figure 1,
illustrated in Figure 1, where the access network gateway where the access network gateway routers are designated as "ANG".
routers are designated as "ANG". Transitions between service Transitions between service providers in separate autonomous
providers in separate autonomous systems or across broader systems or across broader topological "boundaries" within the same
topological "boundaries" within the same service provider are service provider are excluded.
excluded.
Figure 1 depicts the scope of local mobility in comparison to Figure 1 depicts the scope of local mobility in comparison to
global mobility. The Access Network Gateways (ANGs) GA1 and GB1 global mobility. The Access Network Gateways (ANGs) GA1 and GB1 are
are gateways to their access networks. The Access Routers (ARs) gateways to their access networks. The Access Routers (ARs) RA1 and
RA1 and RA2 are in access network A, RB1 is in access network RA2 are in access network A, RB1 is in access network B. Note that
B. Note that it is possible to have additional aggregation it is possible to have additional aggregation routers between ANG
routers between ANG GA1 and ANG GB1 and the access routers if GA1 and ANG GB1 and the access routers if the access network is
the access network is large. Access Points (APs) PA1 through large. Access Points (APs) PA1 through PA3 are in access network A,
PA3 are in access network A, PB1 and PB2 are in access network PB1 and PB2 are in access network B. Other ANGs, ARs, and APs are
B. Other ANGs, ARs, and APs are also possible, and other also possible, and other routers can separate the ARs from the
routers can separate the ARs from the ANGs. The figure implies ANGs. The figure implies a star topology for the access network
a star topology for the access network deployment, and the star deployment, and the star topology is the primary one of interest
topology is the primary one of interest since it is quite since it is quite common, but the problems discussed here are
common, but the problems discussed here are equally relevant to equally relevant to ring or mesh topologies in which ARs are
ring or mesh topologies in which ARs are directly connected directly connected through some part of the network.
through some part of the network.
As shown in the figure, a global mobility protocol may be necessary
when a mobile node (MN) moves between two access networks. Exactly
what the scope of the access networks is depends on deployment
considerations. Mobility between two APs under the same AR
constitutes intra-link, or Layer 2, mobility, and is typically
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
lies local mobility. Local mobility occurs when a mobile node moves
between two APs connected to two different ARs.
Global mobility protocols allow a mobile node to maintain
reachability when the MN's globally routable IP address changes. It
does this by updating the address mapping between the permanent
address and temporary local address at the global mobility anchor
point, or even end to end by changing the temporary local address
directly at the node with which the mobile node is corresponding. A
global mobility management protocol can therefore be used between
ARs for handling local mobility. However, there are three well-
known problems involved in using a global mobility protocol for
every movement between ARs. Briefly, they are:
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 39 skipping to change at page 5, line 39
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
|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
when a mobile node (MN) moves between two access networks. Exactly
what the scope of the access networks is depends on deployment
considerations. Mobility between two APs under the same AR
constitutes intra-link, or Layer 2, mobility, and is typically
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
lies local mobility. Local mobility occurs when a mobile node moves
between two APs connected to two different ARs.
Global mobility protocols allow a mobile node to maintain
reachability when the MN's globally routable IP address changes. It
does this by updating the address mapping between the permanent
address and temporary local address at the global mobility anchor
point, or even end to end by changing the temporary local address
directly at the node with which the mobile node is corresponding. A
global mobility management protocol can therefore be used between
ARs for handling local mobility. However, there are three well-
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 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 this time, packets continue to be routed to the old During this time, packets continue to be routed to the old
temporary local address and are essentially dropped. temporary 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 IP link to another can be quite mobile node moves from one last hop link to another can be
extensive, including all the signaling required to configure an quite extensive, including all the signaling required to
IP address on the new link and global mobility protocol configure an IP address on the new link and global mobility
signaling back into the network for changing the permanent to protocol signaling back into the network for changing the
temporary local address mapping. The signaling volume may permanent to temporary local address mapping. The signaling
negatively impact wireless bandwidth usage and real time volume may negatively impact wireless bandwidth usage and real
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 to correspondents and potentially to eavesdroppers. An location to correspondents and potentially to eavesdroppers. An
attacker that can assemble a mapping between subnet prefixes in attacker that can assemble a mapping between subnet prefixes in
the mobile node's access network and geographical locations can the mobile node's access network and geographical locations can
determine exactly where the mobile node is located. This can determine exactly where the mobile node is located. This can
expose the mobile node's user to threats on their location expose the mobile node's user to threats on their location
privacy. A more detailed discussion of location privacy for privacy. A more detailed discussion of location privacy for
Mobile IPv6 can be found in [12]. Mobile IPv6 can be found in [12].
These problems suggest that a protocol to localize the management These problems suggest that a protocol to localize the management
of topologically small movements is preferable to using a global of topologically small movements is preferable to using a global
mobility management protocol on each IP link move. In addition to mobility management protocol on each movement to a new link. In
these problems, localized mobility management can provide a measure addition to these problems, localized mobility management can
of local control, so mobility management can be tuned for provide a measure of local control, so mobility management can be
specialized local conditions. Note also that if localized mobility tuned for specialized local conditions. Note also that if localized
management is provided, it is not strictly required for a mobile mobility management is provided, it is not strictly required for a
node to support a global mobility management protocol since mobile node to support a global mobility management protocol since
movement within a restricted IP access network can still movement within a restricted IP access network can still
be accommodated. Without such support, however, a mobile node be accommodated. Without such support, however, a mobile node
experiences a disruption in its traffic when it moves beyond the experiences a disruption in its traffic when it moves beyond the
border of the localized mobility management domain. 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 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 is a large campus wireless LAN deployment. Having a attractive is a large campus wireless LAN deployment. Having a
single broadcast domain for all WLAN access points doesn't scale single broadcast domain for all WLAN access points doesn't scale
very well. Also, sometimes parts of the campus cannot be covered very well. Also, sometimes parts of the campus cannot be covered
by one VLAN for other reasons (e.g., some links are other than by one VLAN for other reasons (e.g., some links are other than
802.3). 802.3).
In this case, the campus is divided into separate IP links each In this case, the campus is divided into separate last hop links
served by one or more access routers. This kind of deployment is each served by one or more access routers. This kind of deployment
served today by wireless LAN switches that co-ordinate IP mobility is served today by wireless LAN switches that co-ordinate IP
between them, effectively providing localized mobility management mobility between them, effectively providing localized mobility
at the link layer. Since the protocols are proprietary and not management at the link layer. Since the protocols are proprietary
interoperable, any deployments that require IP mobility necessarily and not interoperable, any deployments that require IP mobility
require switches from the same vendor. 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 Next generation cellular protocols such as 802.16e [8] and Super
3G/3.9G [9] have the potential to run IP deeper into the access 3G/3.9G [9] 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
skipping to change at page 7, line 31 skipping to change at page 7, line 10
not replace Layer 2 mobility (where available) but rather not replace Layer 2 mobility (where available) but rather
complements it. A standardized, interoperable localized mobility complements it. A standardized, interoperable localized mobility
management protocol for IP can remove the dependence on IP layer management protocol for IP can remove the dependence on IP layer
localized mobility protocols that are specialized to specific link 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 protocols. The expected benefit is a reduction in maintenance cost
and deployment complexity. See [6] for a more detailed discussion and deployment complexity. See [6] for a more detailed discussion
of the goals for a network-based localized mobility management of the goals for a network-based localized mobility management
protocol. protocol.
3.3 Picocellular Network with Small But Node-Dense IP 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 and Bluetooth, are designed for low existing protocols, such as UWB and Bluetooth, are designed for low
transmit power, short range operation. For such protocols, 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 IP links", wireless sensors and do not necessarily imply "pico subnets", wireless sensors and other
other advanced applications may end up making such picocellular advanced applications may end up making such picocellular type
type networks node-dense, requiring subnets that cover small networks node-dense, requiring subnets that cover small
geographical areas, such as a single room. The ability to aggregate geographical areas, such as a single room. The ability to aggregate
many subnets under a localized mobility management scheme can help many subnets under a localized mobility management scheme can help
reduce the amount of IP signaling required on IP link movement. reduce the amount of IP signaling required on link movement.
4.0 Problems with Existing Solutions 4.0 Problems with Existing Solutions
Existing solutions for localized mobility management fall into Existing solutions for localized mobility management fall into
three classes: three classes:
1) Interoperable IP level protocols that require changes to the 1) Interoperable IP level protocols that require changes to the
mobile node's IP stack and handle localized mobility management mobile node's IP stack and handle localized mobility management
as a service provided to 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 2) Link specific or proprietary protocols that handle localized
skipping to change at page 10, line 19 skipping to change at page 9, line 45
[11] Bluetooth SIG, "Specification of the Bluetooth System", [11] Bluetooth SIG, "Specification of the Bluetooth System",
November, 2004, available at http://www.bluetooth.com. November, 2004, available at http://www.bluetooth.com.
[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", Internet Draft, work in progress.
[13] Perkins, C., editor, " IP Mobility Support for IPv4", RFC [13] Perkins, C., editor, " IP Mobility Support for IPv4", RFC
3220, August, 2002. 3220, August, 2002.
8.0 Acknowledgements 8.0 Acknowledgements
The authors would like to acknowledge the following for The authors would like to acknowledge the following for
particularly diligent reviewing: Pekka Savola, Vijay Devarapalli, particularly diligent reviewing: Vijay Devarapalli, Peter McCann,
Gabriel Montenegro, Peter McCann, and Vidya Narayanan. Gabriel Montenegro, Vidya Narayanan, Pekka Savola, and Fred
Templin.
9.0 Author's Addresses 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
 End of changes. 21 change blocks. 
128 lines changed or deleted 109 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/