idnits 2.17.1 draft-ietf-dmm-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 593 has weird spacing: '...enarios for D...' == Line 606 has weird spacing: '...ference on Ne...' == Line 611 has weird spacing: '...orkshop on Se...' == Line 616 has weird spacing: '...agement in Mo...' == Line 619 has weird spacing: '...orkshop on Se...' == (2 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 7, 2012) is 4282 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-netext-pd-pmip' is defined on line 580, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-netext-pd-pmip-02 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Chan (Ed.) 3 Internet-Draft Huawei Technologies 4 Intended status: Informational July 7, 2012 5 Expires: January 8, 2013 7 Requirements of distributed mobility management 8 draft-ietf-dmm-requirements-00 10 Abstract 12 The traditional hierarchical structure of cellular networks has led 13 to deployment models which are heavily centralized. Mobility 14 management with centralized mobility anchoring in existing 15 hierarchical mobile networks is quite prone to suboptimal routing and 16 issues related to scalability. Centralized functions present a 17 single point of failure, and inevitably introduce longer delays and 18 higher signaling loads for network operations related to mobility 19 management. This document defines the requirements for distributed 20 mobility management for IPv6 deployment. The objectives are to match 21 the mobility deployment with the current trend in network evolution, 22 to improve scalability, to avoid single point of failure, to enable 23 transparency to upper layers only when needed, etc. The distributed 24 mobility management also needs to be compatible with existing network 25 deployments and end hosts, and be secured. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 8, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions used in this document . . . . . . . . . . . . . . 5 63 3. Centralized versus distributed mobility management . . . . . . 5 64 3.1. Centralized mobility management . . . . . . . . . . . . . 5 65 3.2. Distributed mobility management . . . . . . . . . . . . . 6 66 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1. Distributed deployment . . . . . . . . . . . . . . . . . . 8 68 4.2. Transparency to Upper Layers when needed . . . . . . . . . 9 69 4.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 10 70 4.4. Compatibility . . . . . . . . . . . . . . . . . . . . . . 10 71 4.5. Existing mobility protocols . . . . . . . . . . . . . . . 11 72 4.6. Security considerations . . . . . . . . . . . . . . . . . 11 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 7. Co-authors and Contributors . . . . . . . . . . . . . . . . . 12 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 In the past decade a fair number of mobility protocols have been 84 standardized. Although the protocols differ in terms of functions 85 and associated message format, we can identify a few key common 86 features: 88 presence of a centralized mobility anchor providing global 89 reachability and an always-on experience; 91 extensions to optimize handover performance while users roam 92 across wireless cells; 94 extensions to enable the use of heterogeneous wireless interfaces 95 for multi-mode terminals (e.g. cellular phones). 97 The presence of the centralized mobility anchor allows a mobile 98 device to be reachable when it is not connected to its home domain. 99 The anchor point, among other tasks, ensures reachability of 100 forwarding of packets destined to or sent from the mobile device. 101 Most of the deployed architectures today have a small number of 102 centralized anchors managing the traffic of millions of mobile 103 subscribers. Compared with a distributed approach, a centralized 104 approach is likely to have several issues or limitations affecting 105 performance and scalability, which require costly network 106 dimensioning and engineering to resolve. 108 To optimize handovers from the perspective of mobile nodes, the base 109 protocols have been extended to efficiently handle packet forwarding 110 between the previous and new points of attachment. These extensions 111 are necessary when applications impose stringent requirements in 112 terms of delay. Notions of localization and distribution of local 113 agents have been introduced to reduce signaling overhead. 114 Unfortunately today we witness difficulties in getting such protocols 115 deployed, often leading to sub-optimal choices. 117 Moreover, the availability of multi-mode devices and the possibility 118 of using several network interfaces simultaneously have motivated the 119 development of more new protocol extensions. Deployment is further 120 complicated with so many extensions. 122 Mobile users are, more than ever, consuming Internet content; such 123 traffic imposes new requirements on mobile core networks for data 124 traffic delivery. When the traffic demand exceeds available 125 capacity, service providers need to implement new strategies such as 126 selective traffic offload (e.g. 3GPP work items LIPA/SIPTO) through 127 alternative access networks (e.g. WLAN). Moreover, the localization 128 of content providers closer to the Mobile/Fixed Internet Service 129 Providers network requires taking into account local Content Delivery 130 Networks (CDNs) while providing mobility services. 132 When demand exceeds capacity, both offloading and CDN techniques 133 could benefit from the development of mobile architectures with fewer 134 levels of routing hierarchy introduced into the data path by the 135 mobility management system. This trend in network flattening is 136 reinforced by a shift in users traffic behavior, aimed at increasing 137 direct communications among peers in the same geographical area. 138 Distributed mobility management in a truly flat mobile architecture 139 would anchor the traffic closer to the point of attachment of the 140 user and overcome the suboptimal routing issues of a centralized 141 mobility scheme. 143 While deploying [Paper-Locating.User] today's mobile networks, 144 service providers face new challenges. More often than not, mobile 145 devices remain attached to the same point of attachment. Specific IP 146 mobility management support is not required for applications that 147 launch and complete while the mobile device is connected to the same 148 point of attachment. However, the mobility support has been designed 149 to be always on and to maintain the context for each mobile 150 subscriber as long as they are connected to the network. This can 151 result in a waste of resources and ever-increasing costs for the 152 service provider. Infrequent mobility and intelligence of many 153 applications suggest that mobility can be provided dynamically, thus 154 simplifying the context maintained in the different nodes of the 155 mobile network. 157 The proposed charter will address two complementary aspects of 158 mobility management procedures: the distribution of mobility anchors 159 to achieve a more flat design and the dynamic activation/deactivation 160 of mobility protocol support as an enabler to distributed mobility 161 management. The former has the goal of positioning mobility anchors 162 (HA, LMA) closer to the user; ideally, these mobility agents could be 163 collocated with the first hop router. The latter, facilitated by the 164 distribution of mobility anchors, aims at identifying when mobility 165 must be activated and identifying sessions that do not impose 166 mobility management -- thus reducing the amount of state information 167 to be maintained in the various mobility agents of the mobile 168 network. The key idea is that dynamic mobility management relaxes 169 some constraints while also repositioning mobility anchors; it avoids 170 the establishment of non optimal tunnels between two topologically 171 distant anchors. 173 This document describes the motivations of distributed mobility 174 management in Section 1. Section 3 compares distributed mobility 175 management with centralized mobility management. The requirements to 176 address these problems are given in Section 4. 178 The problem statement and the use cases [I-D.yokota-dmm-scenario] can 179 be found in the following review paper: [Paper- 180 Distributed.Mobility.Review]. 182 2. Conventions used in this document 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 3. Centralized versus distributed mobility management 190 Mobility management functions may be implemented at different layers 191 of the network protocol stack. At the IP (network) layer, they may 192 reside in the network or in the mobile node. In particular, a 193 network-based solution resides in the network only. It therefore 194 enables mobility for existing hosts and network applications which 195 are already in deployment but lack mobility support. 197 At the IP layer, a mobility management protocol to achieve session 198 continuity is typically based on the principle of distinguishing 199 between identifier and routing address and maintaining a mapping 200 between them. With Mobile IP, the home address serves as an 201 identifier of the device whereas the care-of-address takes the role 202 of routing address, and the binding between them is maintained at the 203 mobility anchor, i.e., the home agent. If packets can be 204 continuously delivered to a mobile device at its home address, then 205 all sessions using that home address can be preserved even though the 206 routing or care-of address changes. 208 The next two subsections explain centralized and distributed mobility 209 management functions in the network. 211 3.1. Centralized mobility management 213 With centralized mobility management, the mapping information between 214 the stable node identifier and the changing IP address of a mobile 215 node (MN) is kept at a centralized mobility anchor. Packets destined 216 to an MN are routed via this anchor. In other words, such mobility 217 management systems are centralized in both the control plane and the 218 data plane. 220 Many existing mobility management deployments make use of centralized 221 mobility anchoring in a hierarchical network architecture, as shown 222 in Figure 1. Examples of such centralized mobility anchors are the 223 home agent (HA) and local mobility anchor (LMA) in Mobile IPv6 225 [RFC6275] and Proxy Mobile IPv6 [RFC5213], respectively. Current 226 mobile networks such as the Third Generation Partnership Project 227 (3GPP) UMTS networks, CDMA networks, and 3GPP Evolved Packet System 228 (EPS) networks also employ centralized mobility management, with 229 Gateway GPRS Support Node (GGSN) and Serving GPRS Support Node (SGSN) 230 in the 3GPP UMTS hierarchical network and with Packet data network 231 Gateway (P-GW) and Serving Gateway (S-GW) in the 3GPP EPS network. 233 UMTS 3GPP SAE MIP/PMIP 234 +------+ +------+ +------+ 235 | GGSN | | P-GW | |HA/LMA| 236 +------+ +------+ +------+ 237 /\ /\ /\ 238 / \ / \ / \ 239 / \ / \ / \ 240 / \ / \ / \ 241 / \ / \ / \ 242 +------+ +------+ +------+ +------+ +------+ +------+ 243 | SGSN | | SGSN | | S-GW | | S-GW | |FA/MAG| |FA/MAG| 244 +------+ +------+ +------+ +------+ +------+ +------+ 246 Figure 1. Centralized mobility management. 248 3.2. Distributed mobility management 250 Mobility management functions may also be distributed to multiple 251 locations in different networks as shown in Figure 2, so that a 252 mobile node in any of these networks may be served by a closeby 253 mobility function (MF). 255 +------+ +------+ +------+ +------+ 256 | MF | | MF | | MF | | MF | 257 +------+ +------+ +------+ +------+ 258 | 259 ---- 260 | MN | 261 ---- 263 Figure 2. Distributed mobility management. 265 Mobility management may be partially distributed, i.e., only the data 266 plane is distributed, or fully distributed where both the data plane 267 and control plane are distributed. These different approaches are 268 described in detail in [I-D.yokota-dmm-scenario]. 270 [Paper-New.Perspective] discusses some initial steps towards a clear 271 definition of what mobility management may be, to assist in better 272 developing distributed architecture. [Paper- 273 Characterization.Mobility.Management] analyses current mobility 274 solutions and proposes an initial decoupling of mobility management 275 into well-defined functional blocks, identifying their interactions, 276 as well as a potential grouping, which later can assist in deriving 277 more flexible mobility management architectures. According to the 278 split functional blocks, this paper proposes three ways into which 279 mobility management functional blocks can be groups, as an initial 280 way to consider a better distribution: location and handover 281 management, control and data plane, user and access perspective. 283 A distributed mobility management scheme is proposed in [Paper- 284 Distributed.Dynamic.Mobility] for future flat IP architecture 285 consisting of access nodes. The benefits of this design over 286 centralized mobility management are also verified through simulations 287 in [Paper-Distributed.Centralized.Mobility]. 289 Before designing new mobility management protocols for a future flat 290 IP architecture, one should first ask whether the existing mobility 291 management protocols that have already been deployed for the 292 hierarchical mobile networks can be extended to serve the flat IP 293 architecture. MIPv4 has already been deployed in 3GPP2 networks, and 294 PMIPv6 has already been adopted in WiMAX Forum and in 3GPP standards. 295 Using MIP or PMIP for both centralized and distributed architectures 296 would ease the migration of the current mobile networks towards a 297 flat architecture. It has therefore been proposed to adapt MIP or 298 PMIPv6 to achieve distributed mobility management by using a 299 distributed mobility anchor architecture. 301 In [Paper-Migrating.Home.Agents], the HA functionality is copied to 302 many locations. The HoA of all MNs are anycast addresses, so that a 303 packet destined to the HoA from any corresponding node (CN) from any 304 network can be routed via the nearest copy of the HA. In addition, 305 distributing the function of HA using a distributed hash table 306 structure is proposed in [Paper-Distributed.Mobility.SAE]. A lookup 307 query to the hash table will retrieve the location information of an 308 MN is stored. 310 In [Paper-Distributed.Mobility.PMIP], only the mobility routing (MR) 311 function is duplicated and distributed in many locations. The 312 location information for any MN that has moved to a visited network 313 is still centralized and kept at a location management (LM) function 314 in the home network of the MN. The LM function at different networks 315 constitutes a distributed database system of all the MNs that belong 316 to any of these networks and have moved to a visited network. The 317 location information is maintained in the form of a hierarchy: the LM 318 at the home network, the CoA of the MR of the visited network, and 319 then the CoA to reach the MN in the visited network. The LM in the 320 home network keeps a binding of the HoA of the MN to the CoA of the 321 MR of the visited network. The MR keeps the binding of the HoA of 322 the MN to the CoA of the MN in the case of MIP, or the proxy-CoA of 323 the Mobile Access Gateway (MAG) serving the MN in the case of PMIP. 325 [I-D.jikim-dmm-pmip] discusses two distributed mobility control 326 schemes using the PMIP protocol: Signal-driven PMIP (S-PMIP) and 327 Signal-driven Distributed PMIP (SD-PMIP). S-PMIP is a partially 328 distributed scheme, in which the control plane (using a Proxy Binding 329 Query to get the Proxy-CoA of the MN) is separate from the data 330 plane, and the optimized data path is directly between the CN and the 331 MN. SD-PMIP is a fully distributed scheme, in which the Proxy 332 Binding Update is not performed, and instead each MAG will multicast 333 a Proxy Binding Query message to all of the MAGs in its local PMIP 334 domain to retrieve the Proxy-CoA of the MN. 336 4. Requirements 338 After reviewing the problems and limitations of centralized 339 deployment in Section 4, this section states the requirements as 340 follows: 342 4.1. Distributed deployment 344 REQ1: Distributed deployment 346 IP mobility, network access and routing solutions provided by 347 DMM MUST enable a distributed deployment of mobility 348 management of IP sessions so that the traffic can be routed in 349 an optimal manner without traversing centrally deployed 350 mobility anchors. 352 Motivation: The motivations of this requirement are to match 353 mobility deployment with current trend in network evolution: 354 more cost and resource effective to cache and distribute 355 contents when combining distributed anchors with caching 356 systems (e.g., CDN); improve scalability; avoid single point 357 of failure; mitigate threats being focused on a centrally 358 deployed anchor, e.g., home agent and local mobility anchor. 360 This requirement addresses the following problems PS1, PS2, PS3, and 361 PS4. 363 PS1: Non-optimal routes 365 Routing via a centralized anchor often results in a longer 366 route, and the problem is especially manifested when accessing 367 a local or cache server of a Content Delivery Network (CDN). 369 PS2: Non-optimality in Evolved Network Architecture 371 The centralized mobility management can become non-optimal as a 372 network architecture evolves and becomes more flattened. 374 PS3: Low scalability of centralized route and mobility context 375 maintenance 377 Setting up such special routes and maintaining the mobility 378 context for each MN is more difficult to scale in a centralized 379 design with a large number of MNs. Distributing the route 380 maintenance function and the mobility context maintenance 381 function among different networks can be more scalable. 383 PS4: Single point of failure and attack 385 Centralized anchoring may be more vulnerable to single point of 386 failure and attack than a distributed system. 388 4.2. Transparency to Upper Layers when needed 390 REQ2: Transparency to Upper Layers when needed 392 The DMM solutions MUST provide transparency above the IP layer 393 when needed. Such transparency is needed, when the mobile 394 hosts or entire mobile networks [RFC3963] change their point 395 of attachment to the Internet, for the application flows that 396 cannot cope with a change of IP address. Otherwise the 397 support to maintain a stable home IP address or prefix during 398 handover may be declined. 400 Motivation: The motivation of this requirement is to enable 401 more efficient use of network resources and more efficient 402 routing by not maintaining a stable IP home IP address when 403 there is no such need. 405 This requirement addresses the problems PS5 as well as the other 406 related problem O-PS1. 408 PS5: Wasting resources to support mobile nodes not needing mobility 409 support 411 IP mobility support is not always required. For example, some 412 applications do not need a stable IP address during handover, 413 i.e., IP session continuity. Sometimes, the entire application 414 session runs while the terminal does not change the point of 415 attachment. In these situations that do not require IP 416 mobility support, network resources are wasted when mobility 417 context is set up. 419 O-PS1: Mobility signaling overhead with peer-to-peer communication 421 Wasting resources when mobility signaling (e.g., maintenance 422 of the tunnel, keep alive, etc.) is not turned off for peer- 423 to-peer communication. 425 4.3. IPv6 deployment 427 REQ3: IPv6 deployment 429 The DMM solutions SHOULD target IPv6 as primary deployment and 430 SHOULD NOT be tailored specifically to support IPv4, in 431 particular in situations where private IPv4 addresses and/or 432 NATs are used. 434 Motivation: The motivation for this requirement is to be 435 inline with the general orientation of IETF. Moreover, DMM 436 deployment is foreseen in mid-term/long-term, hopefully in an 437 IPv6 world. It is also unnecessarily complex to solve this 438 problem for IPv4, as we will not be able to use some of the 439 IPv6-specific features/tools. 441 4.4. Compatibility 443 REQ4: Compatibility 445 The DMM solution SHOULD be able to work between trusted 446 administrative domains when allowed by the security measures 447 deployed between these domains. Furthermore, the DMM solution 448 MUST be able to co-exist with existing network deployment and 449 end hosts so that the existing deployment can continue to be 450 supported. For example, depending on the environment in which 451 dmm is deployed, the dmm solutions may need to be compatible 452 with other existing mobility protocols that are deployed in 453 that environment or may need to be interoperable with the 454 network or the mobile hosts/routers that do not support the 455 dmm enabling protocol. 457 Motivation: The motivation of this requirement is to allow 458 inter-domain operation if desired and to preserve backwards 459 compatibility so that the existing networks and hosts are not 460 affected and do not break. 462 This requirement addresses the following other related problem O-PS2. 464 O-PS2: Complicated deployment with too many variants and extensions 465 of MIP Deployment is complicated with many variants and 466 extensions of MIP. When introducing new functions which may 467 add to the complicity, existing solutions are more vulnerable 468 to break. 470 4.5. Existing mobility protocols 472 REQ5: Existing mobility protocols 474 A DMM solution SHOULD first consider reusing and extending the 475 existing mobility protocols before specifying new protocols. 477 Motivation: The purpose is to reuse the existing protocols 478 first before considering new protocols. 480 4.6. Security considerations 482 REQ6: Security considerations 484 The protocol solutions for DMM MUST consider security, for 485 example authentication and authorization mechanisms that allow 486 a legitimate mobile host/router to access to the DMM service, 487 protection of signaling messages of the protocol solutions in 488 terms of authentication, data integrity, and data 489 confidentiality, opti-in or opt-out data confidentiality to 490 signaling messages depending on network environments or user 491 requirements. 493 Motivation and problem statement: Mutual authentication and 494 authorization between a mobile host/router and an access 495 router providing the DMM service to the mobile host/router are 496 required to prevent potential attacks in the access network of 497 the DMM service. Otherwise, various attacks such as 498 impersonation, denial of service, man-in-the-middle attacks, 499 etc. are present to obtain illegitimate access or to collapse 500 the DMM service. 502 Signaling messages are subject to various attacks since these 503 messages carry context of a mobile host/router. For instance, 504 a malicious node can forge and send a number of signaling 505 messages to redirect traffic to a specific node. 506 Consequently, the specific node is under a denial of service 507 attack, whereas other nodes are not receiving their traffic. 508 As signaling messages travel over the Internet, the end-to-end 509 security is required. 511 5. Security Considerations 513 Distributed mobility management (DMM) requires two kinds of security 514 considerations: 1) access network security that only allows a 515 legitimate mobile host/router to access the DMM service; 2) end-to- 516 end security that protects signaling messages for the DMM service. 517 Access network security is required between the mobile host/router 518 and the access network providing the DMM service. End-to-end 519 security is required between nodes that participate in the DMM 520 protocol. 522 It is necessary to provide sufficient defense against possible 523 security attacks, or to adopt existing security mechanisms and 524 protocols to provide sufficient security protections. For instance, 525 EAP based authentication can be used for access network security, 526 while IPsec can be used for end-to-end security. 528 6. IANA Considerations 530 None 532 7. Co-authors and Contributors 534 This problem statement document is a joint effort among the following 535 participants. Each individual has made significant contributions to 536 this work. 538 Dapeng Liu: liudapeng@chinamobile.com 540 Pierrick Seite: pierrick.seite@orange-ftgroup.com 542 Hidetoshi Yokota: yokota@kddilabs.jp 544 Charles E. Perkins: charliep@computer.org 546 Melia Telemaco: telemaco.melia@alcatel-lucent.com 548 Elena Demaria: elena.demaria@telecomitalia.it 549 Peter McCann: Peter.McCann@huawei.com 551 Tricci So: tso@zteusa.com 553 Jong-Hyouk Lee: jh.lee@telecom-bretagne.eu 555 Jouni Korhonen: jouni.korhonen@nsn.com 557 Wen Luo: luo.wen@zte.com.cn 559 Carlos J. Bernardos: cjbc@it.uc3m.es 561 Marco Liebsch: Marco.Liebsch@neclab.eu 563 Georgios Karagian: karagian@cs.utwente.nl 565 Julien Laganier: jlaganier@juniper.net 567 Wassim Michel Haddad: Wassam.Haddad@ericsson.com 569 Seok Joo Koh: sjkoh@knu.ac.kr 571 8. References 573 8.1. Normative References 575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, March 1997. 578 8.2. Informative References 580 [I-D.ietf-netext-pd-pmip] 581 Zhou, X., Korhonen, J., Williams, C., Gundavelli, S., and 582 C. Bernardos, "Prefix Delegation for Proxy Mobile IPv6", 583 draft-ietf-netext-pd-pmip-02 (work in progress), 584 March 2012. 586 [I-D.jikim-dmm-pmip] 587 Kim, J., Koh, S., Jung, H., and Y. Han, "Use of Proxy 588 Mobile IPv6 for Distributed Mobility Control", 589 draft-jikim-dmm-pmip-00 (work in progress), March 2012. 591 [I-D.yokota-dmm-scenario] 592 Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case 593 scenarios for Distributed Mobility Management", 594 draft-yokota-dmm-scenario-00 (work in progress), 595 October 2010. 597 [Paper-Distributed.Centralized.Mobility] 598 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 599 or Centralized Mobility", Proceedings of Global 600 Communications Conference (GlobeCom), December 2009. 602 [Paper-Distributed.Dynamic.Mobility] 603 Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed 604 Dynamic Mobility Management Scheme Designed for Flat IP 605 Architectures", Proceedings of 3rd International 606 Conference on New Technologies, Mobility and Security 607 (NTMS), 2008. 609 [Paper-Distributed.Mobility.PMIP] 610 Chan, H., "Proxy Mobile IP with Distributed Mobility 611 Anchors", Proceedings of GlobeCom Workshop on Seamless 612 Wireless Mobility, December 2010. 614 [Paper-Distributed.Mobility.Review] 615 Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, 616 "Distributed and Dynamic Mobility Management in Mobile 617 Internet: Current Approaches and Issues, Journal of 618 Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.", 619 Proceedings of GlobeCom Workshop on Seamless Wireless 620 Mobility, February 2011. 622 [Paper-Distributed.Mobility.SAE] 623 Fisher, M., Anderson, F., Kopsel, A., Schafer, G., and M. 624 Schlager, "A Distributed IP Mobility Approach for 3G SAE", 625 Proceedings of the 19th International Symposium on 626 Personal, Indoor and Mobile Radio Communications (PIMRC), 627 2008. 629 [Paper-Locating.User] 630 Kirby, G., "Locating the User", Communication 631 International, 1995. 633 [Paper-Migrating.Home.Agents] 634 Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home 635 Agents Towards Internet-scale Mobility Deployments", 636 Proceedings of the ACM 2nd CoNEXT Conference on Future 637 Networking Technologies, December 2006. 639 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 640 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 641 RFC 3963, January 2005. 643 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 644 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 646 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 647 in IPv6", RFC 6275, July 2011. 649 Author's Address 651 H Anthony Chan (editor) 652 Huawei Technologies 653 5340 Legacy Dr. Building 3, Plano, TX 75024, USA 654 Email: h.a.chan@ieee.org 655 - 656 Dapeng Liu 657 China Mobile 658 Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China 659 Email: liudapeng@chinamobile.com 660 - 661 Pierrick Seite 662 France Telecom - Orange 663 4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France 664 Email: pierrick.seite@orange-ftgroup.com 665 - 666 Hidetoshi Yokota 667 KDDI Lab 668 2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan 669 Email: yokota@kddilabs.jp 670 - 671 Charles E. Perkins 672 Huawei Technologies 673 Email: charliep@computer.org 674 - 675 Jouni Korhonen 676 Nokia Siemens Networks 677 Email: jouni.korhonen@nsn.com 678 - 679 Melia Telemaco 680 Alcatel-Lucent Bell Labs 681 Email: telemaco.melia@alcatel-lucent.com 682 - 683 Elena Demaria 684 Telecom Italia 685 via G. Reiss Romoli, 274, TORINO, 10148, Italy 686 Email: elena.demaria@telecomitalia.it 687 - 688 Jong-Hyouk Lee 689 RSM Department, Telecom Bretagne 690 Cesson-Sevigne, 35512, France 691 Email: jh.lee@telecom-bretagne.eu 692 - 693 Tricci So 694 ZTE 695 Email: tso@zteusa.com 696 - 697 Carlos J. Bernardos 698 Universidad Carlos III de Madrid 699 Av. Universidad, 30, Leganes, Madrid 28911, Spain 700 Email: cjbc@it.uc3m.es 701 - 702 Peter McCann 703 Huawei Technologies 704 Email: PeterMcCann@huawei.com 705 - 706 Seok Joo Koh 707 Kyungpook National University, Korea 708 Email: sjkoh@knu.ac.kr 709 - 710 Wen Luo 711 ZTE 712 No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China 713 Email: luo.wen@zte.com.cn 714 - 715 Marco Liebsch 716 NEC Laboratories Europe 717 Email: liebsch@neclab.eu 718 -