< draft-ietf-netlmm-nohost-ps-04.txt   draft-ietf-netlmm-nohost-ps-05.txt >
Internet Draft J. Kempf, Editor Internet Draft J. Kempf, Editor
Document: draft-ietf-netlmm-nohost-ps-04.txt Document: draft-ietf-netlmm-nohost-ps-05.txt September, 2006
Expires: March, 2007
Expires: December, 2006 June, 2006
Problem Statement for Network-based Localized Mobility Management Problem Statement for Network-based Localized Mobility Management
(draft-ietf-netlmm-nohost-ps-04.txt) (draft-ietf-netlmm-nohost-ps-05.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 1, line 52 skipping to change at page 1, line 51
Contributors Contributors
Gerardo Giaretta, Kent Leung, Katsutoshi Nishida, Phil Roberts, and Gerardo Giaretta, Kent Leung, Katsutoshi Nishida, Phil Roberts, and
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..............................................8 5.0 Advantages of Network-based Localized Mobility
6.0 Security Considerations..........................................8 Management..............................................8
7.0 References.......................................................9
8.0 Acknowledgements.................................................9 6.0 IANA Considerations.....................................9
9.0 Author's Addresses...............................................9 7.0 Security Considerations.................................9
10.0 IPR Statements..................................................10 8.0 References..............................................9
11.0 Disclaimer of Validity..........................................11 9.0 Acknowledgements.......................................10
12.0 Copyright Notice................................................11 10.0 Author's Addresses.....................................10
11.0 IPR Statements.........................................11
12.0 Disclaimer of Validity.................................12
13.0 Copyright Notice.......................................12
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] and HMIPv6 [2], involve host-based solutions that namely FMIPv6 [13] and HMIPv6 [18], involve host-based solutions
require host involvement at the IP layer similar to or in addition that require host involvement at the IP layer similar to or in
to that required by Mobile IPv6 [3] for global mobility management. addition to that required by Mobile IPv6 [10] for global mobility
However, recent developments in the IETF and the WLAN management. 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. look at localized mobility management.
Firstly, new IETF work on global mobility management protocols that Firstly, new IETF work on global mobility management protocols that
are not Mobile IPv6, such as HIP [4] and MOBIKE [5], suggests that are not Mobile IPv6, such as HIP [16] and MOBIKE [4], suggests that
future wireless IP nodes may support a more diverse set of global future wireless IP nodes may support a more diverse set of global
mobility protocols. While it is possible that existing localized mobility protocols. While it is possible that existing localized
mobility management protocols could be used with HIP and MOBIKE, mobility management protocols could be used with HIP and MOBIKE,
some would require additional effort to implement, deploy, or in some would require additional effort to implement, deploy, or in
some cases even to specify in a non-Mobile IPv6 mobile environment. some cases even to specify 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
skipping to change at page 2, line 47 skipping to change at page 2, line 48
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
mobility management protocols are briefly discussed. The network- mobility management protocols are briefly discussed. The network-
based mobility management architecture and a short description of based mobility management architecture and a short description of
how it solves these problems is presented. A more detailed how it solves these problems is presented. A more detailed
discussion of goals for a network-based, localized mobility discussion of goals for a network-based, localized mobility
management protocol and gap analysis for existing protocols can be management protocol and gap analysis for existing protocols can be
found in [6]. Note that IPv6 and wireless links are considered to found in [11]. Note that IPv6 and wireless links are considered to
be the initial scope for a network-based localized mobility be the initial scope for a network-based localized mobility
management, so the language in this document reflects that scope. management, so the language in this document reflects that scope.
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:
WLAN Switch
A Wireless LAN (WLAN) switch is an Ethernet [8]switch - that
is a multiport bridge that connects network segments but
allows a physical and logical star topology - which also
runs a protocol to control a collection of 802.11 [6] access
points. The access point control protocol allows the switch
to perform radio resource management functions such as power
control and terminal load balancing between the access
points. Most WLAN switches also support a proprietary
protocol for inter-subnet IP mobility, usually involving
some kind of inter-switch IP tunnel, which provides session
continuity when a terminal moves between subnets.
Access Network
An access network is a collection of fixed and mobile
network components allowing access to the Internet all
belonging to a single operational domain. It may consist of
multiple air interface technologies (for example 802.16e
[5], UMTS [1], etc.) interconnected with multiple types of
backhaul interconnections (such as 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, 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 Localized Mobility Management is a generic term for any
protocol that maintains the IP connectivity and reachability protocol that maintains the IP connectivity and reachability
skipping to change at page 3, line 34 skipping to change at page 4, line 6
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 for purposes of maintaining session routing of packets for purposes of maintaining session
continuity when movement causes a topology change and thus continuity when movement causes a topology change and thus
invalidates a global unicast address of the mobile node. invalidates a global unicast address of the mobile node.
This protocol could be Mobile IP [1][13] but it could also This protocol could be Mobile IP [10][17] but it could also
be HIP [4] or MOBIKE [5]. 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 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. possibly traffic forwarding.
skipping to change at page 4, line 35 skipping to change at page 5, line 7
GA1 and ANG GB1 and the access routers if the access network is GA1 and ANG GB1 and the access routers if the access network is
large. Access Points (APs) PA1 through PA3 are in access network A, large. Access Points (APs) PA1 through PA3 are in access network A,
PB1 and PB2 are in access network B. Other ANGs, ARs, and APs are PB1 and PB2 are in access network B. Other ANGs, ARs, and APs are
also possible, and other routers can separate the ARs from the also possible, and other routers can separate the ARs from the
ANGs. The figure implies a star topology for the access network ANGs. The figure implies a star topology for the access network
deployment, and the star topology is the primary one of interest deployment, and the star topology is the primary one of interest
since it is quite common, but the problems discussed here are since it is quite common, but the problems discussed here are
equally relevant to ring or mesh topologies in which ARs are equally relevant to ring or mesh topologies in which ARs are
directly connected through some part of the network. directly connected 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 41
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
|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 last hop link to another can be mobile node moves from one last hop link to another can be
quite extensive, including all the signaling required to quite extensive, including all the signaling required to
configure an IP address on the new link and global mobility configure an IP address on the new link and global mobility
skipping to change at page 6, line 29 skipping to change at page 6, line 53
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 campus wireless LAN deployment, in which the
single broadcast domain for all WLAN access points doesn't scale geographical span of the campus, distribution of buildings,
very well. Also, sometimes parts of the campus cannot be covered availability of wiring in buildings, etc. preclude deploying all
by one VLAN for other reasons (e.g., some links are other than WLAN access points as part of the same IP subnet. WLAN Layer 2
802.3). mobility could not be used across 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 wireless LAN switches that co-ordinate IP
mobility between them, effectively providing localized mobility mobility between them, effectively providing localized mobility
management at the link layer. Since the protocols are proprietary management at the link layer. Since the protocols are proprietary
and not interoperable, any deployments that require IP mobility and not interoperable, any deployments that require IP mobility
necessarily 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 [5] and Super
3G/3.9G [9] 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) [10] and wireless technologies such as UltraWide Band (UWB) [5] and
Bluetooth [11]. Localized mobility management at the IP layer does Bluetooth [3]. Localized mobility management at the IP layer does
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 [11] 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 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 and Bluetooth, are designed for low existing protocols, such as UWB [5] and Bluetooth [3], are designed
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 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 link movement. reduce the amount of IP signaling required on link movement.
4.0 Problems with Existing Solutions 4.0 Problems with Existing Solutions
skipping to change at page 7, line 32 skipping to change at page 8, line 4
reduce the amount of IP signaling required on 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
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 layer, namely 802.11 running on an 802.3 wired network link layer, for example, 802.11 [6].
backhaul.
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 management. For Solution 1, the following are specific mobility management. For Solution 1, the following are specific
problems: problems:
1) The host stack software requirement limits broad usage even if 1) The host stack software requirement limits broad usage even if
the modifications are small. The success of WLAN switches the modifications are small. The success of WLAN switches
indicates that network operators and users prefer no host stack indicates that network operators and users prefer no host stack
skipping to change at page 8, line 16 skipping to change at page 8, line 42
2 is widely deployed and continuing to grow. Solution 2 has the 2 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 2) Each WLAN switch vendor has its own proprietary protocol that
does not interoperate with other vendor's equipment. does not interoperate with other vendor's equipment.
3) Because the solutions are based on layer 2 routing, they may not 3) Because the solutions are based on layer 2 routing, they may not
scale up to a metropolitan area, or local province. scale up to a metropolitan area, or local province particularly
when multiple kinds of link technologies are used in the
backbone.
Having an interoperable, standardized localized mobility management 5.0 Advantages of Network-based Localized Mobility Management
protocol that is scalable to topologically large networks, but
requires no host stack involvement for localized mobility
management is a highly desirable solution. Mobility routing anchor
points within the backbone network maintain a collection of routes
for individual mobile nodes. The routes point to the ARs 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 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.
The advantages that this solution has over the Solutions 1 and 2 Having an interoperable, standardized localized mobility management
above are as follows: protocol that is scalable to topologically large networks, but
requires no host stack involvement for localized mobility
management is a highly desirable solution. The advantages that this
solution has over the 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 used with any or none of the existing global mobility be used with any or none of the existing global mobility
management protocols. The result is a more modular mobility management protocols. The result is a more modular mobility
management architecture that better accommodates changing management architecture that better accommodates changing
technology and market requirements. technology and market requirements.
2) Compared with Solution 2, an IP level network-based localized 2) Compared with Solution 2, an IP level network-based localized
mobility management solution works for link protocols other mobility management solution works for link protocols other
than Ethernet, and for wide area networks. than Ethernet, and for wide area networks.
5.0 IANA Considerations Reference [11] discusses a reference architecture for a network-
based, localized mobility protocol and goals the protocol design.
6.0 IANA Considerations
There are no IANA considerations in this document. There are no IANA considerations in this document.
6.0 Security Considerations 7.0 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 - need for access network to mobile node security -
was touched on in this document. Host-based localized mobility was touched on in this document. Host-based localized mobility
management protocols have all the security problems involved with management protocols have all the security problems involved with
providing a service to a host. Network-based localized mobility providing a service to a host. Network-based localized mobility
management requires security among network elements equivalent to management requires security among network elements equivalent to
what is needed for routing information security, and security what is needed for routing information security, and security
between the host and network equivalent to what is needed for between the host and network equivalent to what is needed for
network access, but no more. A more complete discussion of the network access, but no more. A more complete discussion of the
security goals for network-based localized mobility management can security goals for network-based localized mobility management can
be found in [6]. be found in [11].
7.0 References 8.0 References
7.1 Informative References 8.1 Informative References
[1] Koodli, R., editor, "Fast Handovers for Mobile IPv6," RFC [1] 3GPP, "UTRAN Iu interface: General aspects and principles",
4068, July, 2005. 3GPP TS 25.410, 2002.
[2] Soliman, H., Castelluccia, C., El Malki, K., and Bellier. L., [2] 3GPP, "3GPP System Architecture Evolution: Report on Technical
"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, 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.
[10] http://www.ieee802.org/15/pub/TG3a.htm [3] 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.
[4] Eronen, P., editor, "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June, 2006.
[5] http://www.ieee802.org/15/pub/TG3a.htm
[6] IEEE, "Wireless LAN Medium Access Control (MAC)and Physical
Layer (PHY) specifications", IEEE Std. 802.11, 1999.
[7] IEEE, "Amendment to IEEE Standard for Local and Metropolitan
Area Networks - Part 16: Air Interface for Fixed Broadband
Wireless Access Systems- Physical and Medium Access Control
Layers for Combined Fixed and Mobile Operation in Licensed
Bands", IEEE Std. 802.16e-2005, 2005.
[8] IEEE, "Carrier sense multiple access with collision detection
(CSMA/CD) access method and physical layer specifications",
IEEE Std. 802.3-2005, 2005.
[9] ITU-T, "Architecture of Transport Networks Based on the
Synchronous Digital Hierarchy (SDH)", ITU-T G.803, March,
2000.
[10] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in
IPv6," RFC 3775.
[11] Kempf, J., editor, "Goals for Network-based Localized Mobility
Management", Internet Draft, work in progress.
[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] Koodli, R., editor, "Fast Handovers for Mobile IPv6," RFC
3220, August, 2002. 4068, July, 2005.
[14] Manner, J., and Kojo, M., "Mobility Related Terminology", RFC
3753, June, 2004.
[15] Metro Ethernet Forum, " Metro Ethernet Network Architecture
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.
8.0 Acknowledgements 9.0 Acknowledgements
The authors would like to acknowledge the following for The authors would like to acknowledge the following for
particularly diligent reviewing: Vijay Devarapalli, Peter McCann, particularly diligent reviewing: Vijay Devarapalli, Peter McCann,
Gabriel Montenegro, Vidya Narayanan, Pekka Savola, and Fred Gabriel Montenegro, Vidya Narayanan, Pekka Savola, and Fred
Templin. Templin.
9.0 Author's Addresses 10.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 47 skipping to change at page 11, line 32
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
10.0 IPR Statements 11.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 Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
skipping to change at page 11, line 18 skipping to change at page 12, line 5
of such proprietary rights by implementers or users of this of 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 http://www.ietf.org/ipr. 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 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 ietf-
ipr@ietf.org. ipr@ietf.org.
11.0 Disclaimer of Validity 12.0 Disclaimer of Validity
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
12.0 Copyright Notice 13.0 Copyright Notice
Copyright (C) The Internet Society (2006). This document is Copyright (C) The Internet Society (2006). This document is
subject to the rights, licenses and restrictions contained in BCP subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their 78, and except as set forth therein, the authors retain all their
rights. rights.
 End of changes. 35 change blocks. 
108 lines changed or deleted 146 lines changed or added

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