idnits 2.17.1 draft-njedjou-globalmm-ps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 818. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 794. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 801. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 807. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 8 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 26 has weird spacing: '...The list of ...' == Line 141 has weird spacing: '... Making integ...' == Line 442 has weird spacing: '... update conse...' == Line 507 has weird spacing: '...agement proto...' == Line 630 has weird spacing: '...fferent mobil...' == (1 more instance...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2006) is 6548 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'MIPV4' is defined on line 741, but no explicit reference was found in the text == Unused Reference: 'MIPV6' is defined on line 744, but no explicit reference was found in the text == Unused Reference: 'TERM' is defined on line 747, but no explicit reference was found in the text == Unused Reference: 'HIP' is defined on line 750, but no explicit reference was found in the text == Unused Reference: 'NETLMM' is defined on line 753, but no explicit reference was found in the text == Unused Reference: 'NAH' is defined on line 757, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2002 (ref. 'MIPV4') (Obsoleted by RFC 3220) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. 'TERM') == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. 'HIP') == Outdated reference: A later version (-05) exists of draft-ietf-netlmm-nohost-ps-00 ** Downref: Normative reference to an Informational draft: draft-ietf-netlmm-nohost-ps (ref. 'NETLMM') -- Possible downref: Normative reference to a draft: ref. 'NAH' Summary: 13 errors (**), 0 flaws (~~), 18 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Eric Njedjou 3 Julien Riera 4 Internet Draft France Telecom 5 Expires November 2006 May 2006 7 Problem Statement for Global IP Mobility Management 8 draft-njedjou-globalmm-ps-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware have 14 been or will be disclosed, and any of which he or she becomes aware 15 will be disclosed, in accordance with Section 6 of BCP 79. 17 "Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference material 24 or to cite them other than a "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html" 32 This Internet-Draft will expire on November 2, 2006. 34 Copyright Notice 36 Copyright � The Internet Society (2006) 38 Abstract 40 This document discusses the problem of global IP mobility 41 management in a context where some mobile operators and service 42 providers are looking for adequate solutions to the inter-system 43 IP mobility problem. The document addresses the specific issue of 44 moving between IP access domains that use different mobility 45 management protocols and mechanisms. Indeed this type of movement 46 would be an important subset of global IP mobility scenarios. 48 Table of Contents 50 1. Introduction................................................2 51 2. Terminology.................................................4 52 3. Abbreviations...............................................6 53 4. Deployment scenarios considered.............................6 54 4.1. Movement between different access network systems 55 assisted with a third party provider......................7 56 4.2. Movement within an integrated access network provider.......8 57 5. Issues and problems with Existing global IP mobility 58 management (gmm)solutions................................10 59 5.1. Signaling volume over the radio............................10 60 5.2. Complexity of mobility management procedures...............11 61 5.3. Complexity of hosts........................................11 62 5.4. Network initiation of mobility.............................11 63 5.5. Terminal initiation of mobility............................12 64 5.6. Mobility between two heterogeneous mobility management 65 domains owned by a same operator.........................12 66 5.7. Inter-system mobility in other SDOs........................15 67 6. Security Considerations....................................15 68 7. Conclusion.................................................15 69 8. References.................................................16 70 9. Acknowledgments............................................16 71 10. Authors Addresses..........................................16 73 1. Introduction 75 Global mobility management protocols have been under design by the 76 IETF for the past fifteen years or so (assuming the creation of 77 the Mobile IP Working Group as a start). The basic goal pursued at 78 the time of starting that effort, was the ability to continue an 79 IP session when a host IP address had to change. The targeted IP 80 sessions were those involving a transport level connection. 82 No other motivation but to achieve session continuity has really 83 been taken into account so far in defining the existing solutions 84 for global IP mobility management. Effectively, the main goal has 85 always been to hide the IP address change from the transport level 86 as well as from the correspondent node perspective. In such a way, 87 a host would keep its transport connection opened and continue to 88 be reachable while moving. 90 The functions achieved were; 91 . Updating the network of the host IP configuration change 92 . Having a mobility anchor node perform the route update (upon 93 moving node alert) or notify correspondents that the moving 94 host care-of address had changed 96 . having a mapping on the host between a current and permanent 97 address to deliver packet to applications 98 Solutions as Mobile IP or HIP operate on that pattern. 100 Actually, global mobility management architectures and protocols 101 at IP layer have grown in more or less a parallel to those 102 designed in other SDOs as 3GPP where other considerations were 103 taken into account aside that of just continuing the session of a 104 user. Indeed 3GPP would be motivated by other considerations as 105 for example the need for the provider to control the selection of 106 the target access network of attachment. 107 And still, future global mobility systems will tend to marry 108 existing mechanisms from different standardization actors (IETF, 109 3GPP, IEEE802�) built with different purposes and motivations. 110 This tendency will grow even wider as services will move to be 111 all-IP based and access agnostic. 113 With the previous picture taking place, there is a growing feeling 114 that the match between these mobility mechanisms built in these 115 different SDOs is far from being perfect and suitable. This is 116 especially true when considering some market oriented requirements 117 as can have; 118 . Mobile operators owning several access networks of different 119 types that they want to make cooperate to provide their 120 users with global mobility 121 . Third parties operators that want to provide IP mobility to 122 customers, regardless of the operators to which these 123 customers are subscribed for the accesses. 125 Indeed the fact that an IP session handover has to be seamless 126 should not be the only motivation when solving the global mobility 127 problem. What appears as a simple movement actually involves a lot 128 of external factors. While ensuring seamless continuity for the 129 user, other objectives are to be fulfilled. Such objectives can be 130 as numerous as: 132 . Judiciously using the "newly" available radio capacity 133 (Wifi, Wimax�) to relieve cellular systems and provide 134 multimedia services; 135 . Guaranteeing service level for the users by helping them 136 determine the best system for the service they want to 137 access to; 138 . Optimizing the use of the radio resources (especially on 139 cellular), so as to dedicate the radio spectrum to serving 140 more data/voice by lowering the signaling overhead; 141 . Making integrated (and therefore already composite) 142 architectures less complex, as well as minimizing protocols 143 to render overall systems more scalable; 144 . Lowering requirements and constraints on hosts for an easier 145 support of inter-system mobility. 147 Some of the previous bullets points basically require that the 148 global mobility management system be network initiated/operated 149 while other could be met independently of the mobility operation 150 model. 151 Therefore an IP mobility solution designed to enable the previous 152 requirements should fit both terminal and network initiation and 153 operation schemes. So that any service provider would be free to 154 make the use of the solution they want, according to their 155 architectures and services. 157 Most of the listed requirements seem not to be in favor of the 158 global mobility management solutions as they exist today. The 159 remainder of this document is dedicated at developing the previous 160 statement. 162 2. Terminology 164 Terminology is an aspect of mobility management that is in 165 constant change, because of often evolving requirements. The 166 definitions pr�cised below are wanted consensual enough not to 167 confuse the reader. 169 Aggregate router 171 This is a specific router in an access network acting as its 172 border router on the core network side. 174 Care-of-address 176 In this document, a care-of-address refers to an IP address 177 temporarily acquired by a mobile host while visiting an IP access 178 network, irrespective of which global mobility management protocol 179 the host is running. Therefore, a host may have a care-of-address 180 without running MIP. Coming revisions of this document might 181 suggest an alternative expression to avoid ambiguity. 183 IP location update 185 This is a generic procedure whereby a host informs a mobility 186 anchor in the network or a correspondent located anywhere on the 187 internet that it has a new active care-of-address and therefore a 188 new IP location. This procedure is called registration in Mobile 189 IPv4 and re-association in HIP. 191 Comprehensive Mobility management 192 RFC 3753 defines local and global mobility management but the 193 notion of mobility management itself is not defined. For the 194 purposes of this document, comprehensive mobility management will 195 be defined as the process of performing and sequencing the 196 following actions; 197 . Collect information from terminal, Radio Access Points and 198 Resource Controllers to assess the need or opportunity for a 199 handover 200 . Choose a handover target, as a result of deciding the next 201 Radio Access Network and Point of attachment based on 202 collected information, QoS needs and other policies. 203 . Execute the handover on the terminal. This generally 204 consists in switching between radio links, preparing the IP 205 configuration over the new link and performing the IP 206 location update. 207 This definition does not make any assumption of which side between 208 the network and the terminal decides of the handoff target. 210 Global IP mobility management 212 IP Mobility management is said to be global in this document 213 whenever it involves a mobile host that is moving between IP 214 domains that use different mobility procedures and protocols. 215 Heterogeneous access networks would basically constitutes such IP 216 domains. These domains can be part of the same administrative 217 boundaries, eg an operator integrating several access networks 218 providers or belong to different network administrations. With 219 this definition an UMTS/WLAN IP service transition will be global, 220 as well as will be a movement between a NETLMM operated domain and 221 a 3GPP LTE domain. 223 Network global IP mobility management 225 A global mobility management initiated or operated by the network 227 Local IP mobility management 229 Mobility management is said to be local whenever it involves a 230 mobile host moving 231 . Within an IP domain using a single mobility management 232 procedure 233 . Between two IP domains that use the same mobility management 234 procedures and protocols. 235 With this definition, the movement of a host within a Wlan or 236 Wimax domain will be considered local. Indeed, in such domains, 237 a single IP mobility management protocol would basically be 238 used. Also will be considered local, a transition between two 239 NETLMM domains. 241 Mobility anchor 243 A mobility anchor is an IP node that either: 244 . Performs the forwarding and path update of IP packets 245 destined to the moving host 246 . notifies correspondents that the moving host care-of address 247 has changed 248 With this definition, a mobility anchor only participates to the 249 goal of making the moving host reachable. The Home Agent of MIP 250 and the Rendez-Server of HIP are examples of defined mobility 251 anchors. However this terminology does not necessarily relates to 252 these nodes. 254 Inter-System Mobility Agent 256 This is a function typically located either in an integrated 257 access operator network or in the terminal and that helps deciding 258 of the mobile host target system (step 2 of comprehensive mobility 259 management) based on several criteria. Such an agent is used in 260 this document to illustrate the global mobility management 261 problem. 262 Considerations associated with selection criteria are clearly out 263 of scope. 265 3. Abbreviations 267 gmm: global IP mobility management 268 NETLMM: network localized IP mobility management 269 LTE: Long Term Evolution of the radio access network currently 270 prepared by 3GPP 271 MIH: Media Independent Handover. This is a functionality of the 272 Draft IEEE 802.21 specification 273 IMS: IP Multimedia Subsytem of 3GPP 275 4. Deployment scenarios considered 277 As said earlier, global mobility refers to the movement performed 278 by a host as it changes its point of attachment from an IP domain 279 to another that has a different mobility procedure. 280 Such movements will either occur between two access networks of 281 different providers or also between two access networks owned by 282 the same service provider. The problem raised in this document 283 addresses both categories of movement. 285 4.1. Movement between different access network systems assisted 286 with a third party provider. 288 The following figure depicts a deployment model where a host is 289 moving between two access networks (as described previously) 290 operated by different providers. Such providers will usually not 291 cooperate for the purpose of comprehensive mobility management as 292 defined earlier, nor cooperate with a third party that will serve 293 the mobility between those access networks. Such a third party 294 will typically own the IP mobility anchor. 296 * * * 297 * * 298 +----------+ 299 * | Mobility | * 300 | Anchor | 301 * +----------+ * 302 * * * 303 * 304 * 305 * * * 306 * * 307 * Internet * 308 * * 309 * * * * * 310 * * 311 * * 312 * * 313 +-------+ +-------+ 314 |AggR A1| |AggR B1| 315 +-------+ +-------+ 316 AN A @ @ @ AN B 317 Provider A @ @ @ Provider B 318 @ @ @ 319 @ @ @ 320 +-----+ +-----+ +-----+ 321 |AR A1| |AR A2| |AR B1| 322 +-----+ +-----+ +-----+ 323 * * * * * 324 * * * * * 325 * * * * * 326 * * * * * 327 /\ /\ /\ /\ /\ 328 /AP\ /AP\ /AP\ /AP\ /AP\ 329 / A1 \ / A2 \ / A3 \ / B1 \ / B2 \ 330 ------ ------ ------ ------ ------ 331 | | 332 | | 333 | | 335 +--+ +--+ 336 |MN|----------------->|MN| 337 +--+ +--+ 339 Figure 1: example Deployment scenario for two access networks 340 owned by different providers 342 The terminal is in this case, the only entity in good position to 343 initiate the mobility management functions. Indeed it is the only 344 node capable of getting access networks information, necessary to 345 decide of the movement. Global mobility management solutions as 346 they are specified today (i.e basically host based) well apply to 347 this deployment model. However, as said earlier, the right 348 mobility architecture should be able to accommodate all deployment 349 models and mobility controls schemes. 351 4.2. Movement within an integrated access network provider 353 The following figure depicts a classical deployment scenario for 354 an operator that is owner of several access networks that it can 355 make cooperate, because of the need to ensure the goals and 356 requirements as listed in the introduction. 358 * * 359 * * 360 * * 361 * + ----------+ * 362 |Inter-System| 363 * | Mobility | * Operator network 364 | function | 365 + ----------+ 366 * * 367 +---------- + 368 * |IP Mobility| * 369 | Anchor | 370 * +---------- + * 372 * * 373 * * * * * 374 * * 375 * * 376 * * 377 +-------+ +-------+ 378 |AggR A1| |AggR B1| 379 +-------+ +-------+ 380 AN A @ @ @ AN B 381 @ @ @ 383 @ @ @ 384 @ @ @ 385 +-----+ +-----+ +-----+ 386 |AR A1| |AR A2| |AR B1| 387 +-----+ +-----+ +-----+ 388 * * * * * 389 * * * * * 390 * * * * * 391 * * * * * 392 /\ /\ /\ /\ /\ 393 /AP\ /AP\ /AP\ /AP\ /AP\ 394 / A1 \ / A2 \ / A3 \ / B1 \ / B2 \ 395 ------ ------ ------ ------ ------ 396 | | 397 | | 398 | | 399 +--+ +--+ 400 |MN|----------------->|MN| 401 +--+ +--+ 403 Figure 2: Deployment scenario for an integrated operator 405 4.2.1. Inter-System Mobility management 407 In such an integrated operator scenario, the network is in good 408 position to initiate mobility management. It is specifically able 409 to watch over the capacity of every system and monitor terminal 410 conditions so as to take the best decision for the user target. An 411 Inter-System Mobility function would basically perform this IP 412 handover preparation. 414 Specifications as the 802.21 draft would see the MIH Point of 415 Service into such a function (with a corresponding entity in the 416 terminal and radio access points). Note that this inter-system 417 mobility function can be co-located to the node acting as the IP 418 Mobility anchor. 419 However these considerations are informative only and out of scope 420 here. IP mobility is clearly the focus of this document. However 421 the authors intent is to make the point that IP mobility can not 422 be discussed regardless of the inter-system mobility architectures 423 that are likely to be deployed. 425 4.2.2. Knowledge of host care-of address change by the network 427 When a core network is able to federate the IP domains, 428 information can be easily exchanged between these domains and such 429 a core network, belonging to the provider. Therefore, the current 430 IP configuration of a host can be known in the provider home 431 network. 433 Effectively IP configuration assignment schemes of a provider 434 would be managed from within the provider home network. 436 On the event of a handover to another IP access domain of the 437 integrated provider, the target IP configuration of the host 438 (including the care-of-address to use) would be prepared in the 439 home network so that the host would not have to make any 440 notification back upon receiving that new configuration. 441 However a mobility anchor would still have to perform the routing 442 update consequently to the host changing its active IP 443 connectivity from one domain to another. 445 Therefore, the explicit IP location update as well as the 446 necessity to keep association states between hosts and mobility 447 anchor of existing global mobility solutions (Registration and REA 448 procedures of MIP or HIP) can be avoided in this model. The next 449 paragraph precisely describes the problem encountered when 450 resorting to such an explicit IP location update and association 451 with a IP mobility anchor. 453 It is to be made explicitly clear that any specific procedure by 454 which the network can be aware of the terminal new and old IP 455 configuration is not assumed. Every implementation of the 456 deployment model can figure out how they want to get the 457 information. 459 5. Issues and problems with Existing global IP mobility management 460 (gmm)solutions 462 This paragraph captures the reasons why classical gmm solutions 463 are problematic with regards to driving requirements as presented 464 in the introduction. 466 5.1. Signaling volume over the radio 468 Global IP mobility management solutions known to date do not 469 guarantee an efficient use of the radio capacity, especially with 470 the need to associate to a mobility anchor and perform frequent 471 explicit re-associations. 472 Terminals are required to support more and more control planes as 473 they are becoming convergent. A single terminal would have to 474 support, multiple radios, as well as multiple authentications 475 protocols, inter-system mobility, IMS� that all generate fair 476 amount of signaling. 478 Aside of IP session continuity, integrated mobility architecture 479 will also have to address such transitions as VoIP to circuit 480 switched voice. So will multi-systems terminals. This additional 481 type of session continuity requires specific mobility anchors that 482 are different from entities as Home Agents (that can only perform 483 the switch between two IP legs). Therefore, it is a strong 484 requirement that signaling overhead from hosts to these different 485 gateways do not grow as their number or type multiplies. 487 5.2. Complexity of mobility management procedures 489 As said in the introduction, simplifying architectures and hosts, 490 as well as minimizing the protocols is a requirement on the road 491 to rendering next generation mobility architectures more scalable. 493 Comprehensive mobility management procedures would basically 494 require that a mechanism exist to perform the steps as described 495 in section 2, basically collecting information to prepare a 496 handover, and indicating the target to the terminal. Solutions for 497 gmm do not provide these steps, which anyway they are not meant 498 for. The very problem is that they were not thought to be included 499 to the comprehensive procedures. 500 Therefore the gmm mechanisms would usually superpose to the 501 previous procedures to create complex state machines and heavy 502 message exchange flows between hosts and the network. 504 Also, usually the integrated architecture would already have 505 mobility management states for every activated link (UMTS, Wimax�) 506 on the terminal. To that, is superposed the global IP mobility 507 management protocol. This protocol superposition adds 508 sensitiveness to the overall stability of the architecture. In the 509 middle of that, the integrated architecture will necessarily have 510 to support inter-media convergence functions such as the MIH of 511 802.21. 513 5.3. Complexity of hosts 515 Lowering software support requirements on hosts would facilitate 516 early adoption of seamless mobility by reducing the time to market 517 for terminals to be IP mobility compatible. 518 This is already a requirement of NETLMM. However such a 519 requirement difficulty applies for scenarios where the host has to 520 move between domains operated by different administrations. 521 Another example of ongoing standard specification where the 522 principle to get rid of host support applied is the VCC (VoIP to 523 Circuit Switched) transition work item carried out in 3GPP. This 524 item is being addressed with no specific needed support on the 525 host but native IMS. 527 5.4. Network initiation of mobility 529 An integrated deployment model as presented in 3.2 has the ability 530 to facilitate network initiation of handovers. This brings 531 guarantee of service level to moving users. Indeed the integrated 532 provider can monitor the load of a base station before allowing a 533 user application to move to that point of attachment. Network 534 initiation also brings assurance that the capacity of the provider 535 is efficiently spread across the wireless domains. 537 Initiating an IP handover from the network requires that the re- 538 association procedure should be initiated by the network. Taking 539 the MIP example, a host would have to perform the registration 540 update just after receiving an indication from the network to 541 switch to a different system. Therefore, a specific requirement on 542 the MIP stack would be to trigger the registration update exchange 543 upon indication to switch between links. 545 Furthermore, as the existing gmm solutions as MIP let it totally 546 implementation dependant the set of events that trigger the IP 547 location update procedure, it is practically impossible for all 548 implementations to have the same state machine for triggering such 549 a re-association. 550 Therefore, implementations as would be wanted for network 551 initiation will have to be featured in a way to perform the re- 552 association procedure only after a network indication to do so. 553 Flexibility of standard implementation is often desired but can be 554 become cumbersome in such a case. 555 Many integrated operators are building roadmaps for deploying 556 seamless mobility for IP services with the requirements presented 557 at the beginning of the document. Because of the previously 558 identified problem of gmm solutions to date, such operators have 559 to make specific requests for quotations to smart devices vendors 560 to design implementations that fit their purposes. This burden 561 becomes considerable when deployment is considered at a large 562 scale. 564 5.5. Terminal initiation of mobility 566 For terminal initiated mobility scenarios, a similar problem is 567 present. Despite the fact that it would be an inter-system 568 mobility agent on the terminal that would decide to pass the 569 traffic to a different link, the gmm protocol still has to be able 570 to understand an order to do so. 572 5.6. Mobility between two heterogeneous mobility management domains 573 owned by a same operator 575 Two mobility management domains are said to be heterogeneous 576 whenever the protocols they run for mobility are different. 577 An alternative deployment scenario for an integrated provider 578 willing to offer global mobility would via the aggregation of 579 several heterogeneous mobility domains anchored to a unique core 580 network. 582 Effectively, a mobile operator could deploy WiMax in a hotzone and 583 LTE all around, with an IP mobility protocol (NETLMM for example) 584 inside the Wimax zone. 586 * * 587 * * 588 * * 589 * Operator's * 590 * Aggregation * 591 * Network * 592 * * 593 * * 594 * * * * 595 * * 596 * * 597 * * 598 * * * * 599 * * * * 600 * * * * 601 * MM Domain A * * MM Domain B * 602 * * * * 603 * IP based * * 3GPP based * 604 * * * * 605 AN A * * * * AN B 606 * * * * * 607 * * * * * 608 * * * * * 609 * * * * * 610 * * * * * 611 /\ /\ /\ /\ /\ 612 /AP\ /AP\ /AP\ /AP\ /AP\ 613 / A1 \ / A2 \ / A3 \ / B1 \ / B2 \ 614 ------ ------ ------ ------ ------ 615 | | 616 | | 617 | | 618 +--+ +--+ 619 |MN|------------------->|MN| 620 +--+ +--+ 622 Figure 4: Mobility between mobility management domains of a single 623 operator 625 As in the scenario of figure 2, the fact that both domains belong 626 to the same administration, make it possible the exchange of 627 information for mobility management within the network. 629 As different localized mobility management protocols would be used 630 in each access domain, a different mobility protocol will have to 631 be resorted to for the inter-domain transition. 633 Again for architecture scalability and host simplicity, it would 634 not be desirable to multiply such mobility protocols. Therefore, 635 solutions as NETLMM would certainly better be commoditized for 636 integrated architectures and made more compliant to global 637 mobility, so that the hosts and the network do not require any 638 additional mobility management protocol to achieve the inter- 639 mobility management domain movement. 640 Also if it eventually turns out that a host based solution as MIP 641 is used for the movement from a NETLMM to another mobility 642 management domain, and especially when these domains are owned by 643 the same operator, it will not have been very useful to bring new 644 solutions where the host is not involved. 646 It is to be made clear that in the case where access domains A and 647 B are operated by different administrations (eg. NETLMM domain 648 owned by operator A and LTE domain owned by operated B), the 649 moving host stands as the unique federation entity and would 650 therefore have to be more implicated in the global mobility 651 management. Domains owned by several operators will usually not 652 exchange mobility management information. 654 * * 655 * * 656 *third party* 657 * mobility * 658 * anchor * 659 * * 660 * Internet * 661 * * 662 * * * * 663 * * 664 * * 665 * * 666 * * * * 667 * * * * 668 * * * * 669 * MM Domain A * * MM Domain B * 670 * * * * 671 * IP based * * 3GPP based * 672 * * * * 673 AN A * * * * AN B 674 Provider A * * * * *Provider B 675 * * * * * 676 * * * * * 677 * * * * * 678 * * * * * 680 /\ /\ /\ /\ /\ 681 /AP\ /AP\ /AP\ /AP\ /AP\ 682 / A1 \ / A2 \ / A3 \ / B1 \ / B2 \ 683 ------ ------ ------ ------ ------ 684 | | 685 | | 686 | | 687 +--+ +--+ 688 |MN|------------------->|MN| 689 +--+ +--+ 691 Figure 5: Mobility between mobility management domains of 692 different access network providers 694 As a general observation it is worth reminding that it is making 695 more and more sense from the market perspective to work on 696 mobility management solutions meeting the requirement of both 697 terminal and network modes of mobility management 699 5.7. Inter-system mobility in other SDOs 701 3GPP is working on evolved inter-system architectures that could 702 require global IP mobility protocols for 3GPP to non-G3PP 703 mobility. Solutions meeting requirements presented in this 704 document would be particularly adapted to these new architectures. 705 Available gmm solutions may still work from a pure technical point 706 of view, but would not meet important requirements as system 707 scalability, host complexity, signaling volume reduction and many 708 others discussed earlier. 710 IEEE 802.21 is defining procedures for managing the transition of 711 a host across several media. For that purpose, a media independent 712 handover protocol will have to be supported in the mobility 713 architecture. Therefore the Internet mobility architecture is 714 definitely to be adapted to the constraints of inter-media 715 mobility scenarios that 802.21 is developing. 717 6. Security Considerations 719 Security issues linked with existing gmm solutions can not be said 720 to be an obstacle to deploying architectures with network global 721 mobility management. Therefore there is no security issue 722 identified as such. However design goals of a solution to address 723 the problem described here will have to state precise security 724 requirements. 726 7. Conclusion 727 This document has tried to illustrate the problem of performing IP 728 mobility with IETF already defined solutions. The context has been 729 confined to a specific family of deployment scenarios, deemed to 730 have the potential to grow wide enough to legitimate dedicated 731 solutions. 732 It turns out that most of the issues that have been gone through 733 were especially bad for network global mobility management. It can 734 be said that existing solutions were thought in a terminal centric 735 approach and as such match pretty well the needs of the types of 736 deployments scenarios that where the host would have to initiate 737 the mobility. 739 8. References 741 [MIPV4] "IP Mobility Support", C. Perkins (editor), RFC 2002, 742 October 1996. 744 [MIPV6] "Mobility Support in IPv6", D. Johnson, C. Perkins, and 745 Jari Arkko, RFC 3677, June 2004. 747 [TERM] "Mobility Related Terminology", J. Manner, M., RFC 3753 748 June 2004 750 [HIP] "Host Identity Protocol", P. Jokela (editor), draft-ietf- 751 hip-base-04, work in progress, October 2005 753 [NETLMM] "Problem Statement for IP Local Mobility", J. Kemps 754 (editor), draft-ietf-netlmm-nohost-ps-00.txt, work in progress, 755 February 2006 757 [NAH] "Motivation for Network Controlled Handoffs using IP 758 mobility between heterogeneous Wireless Access Networks", E. 759 Njedjou, P. Bertin, P. Reynolds, draft-njedjou-inter-an-handoffs- 760 00.txt, February 2003. 762 9. Acknowledgments 764 The authors would like to thank Karine Guillouard, Servane 765 Bonjour, Jean Christophe Rault from France Telecom for the 766 valuable inputs they had as reviewers of this document. 768 10. Authors Addresses 770 Eric Njedjou 771 France Telecom 772 4, rue du CLos Courtel 773 35512 Cesson S�vign� BP 91226 774 France 775 Phone: +33299124878 776 Email: eric.njedjou@france.telecom.com 777 Julien Riera 778 France Telecom 779 38/40, rue du G�n�ral Leclerc 780 92794 Issy Les Moulineaux Cedex 9 781 France 782 Phone: +33145298994 783 Email: julien.riera@francetelecom.com 785 Intellectual Property Statement 787 The IETF takes no position regarding the validity or scope of any 788 Intellectual Property Rights or other rights that might be claimed 789 to pertain to the implementation or use of the technology 790 described in this document or the extent to which any license 791 under such rights might or might not be available; nor does it 792 represent that it has made any independent effort to identify any 793 such rights. Information on the procedures with respect to rights 794 in RFC documents can be found in BCP 78 and BCP 79. 796 Copies of IPR disclosures made to the IETF Secretariat and any 797 assurances of licenses to be made available, or the result of an 798 attempt made to obtain a general license or permission for the use 799 of such proprietary rights by implementers or users of this 800 specification can be obtained from the IETF on-line IPR repository 801 at http://www.ietf.org/ipr. 803 The IETF invites any interested party to bring to its attention 804 any copyrights, patents or patent applications, or other 805 proprietary rights that may cover technology that may be required 806 to implement this standard. Please address the information to the 807 IETF at ietf-ipr@ietf.org. 809 Disclaimer of validity 811 This document and the information contained herein are provided on 812 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 813 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 814 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 815 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 816 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 817 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 818 PARTICULAR PURPOSE. 820 Copyright Statement 822 Copyright (C) The Internet Society (2006). This document is 823 subject to the rights, licenses and restrictions contained in BCP 824 78, and except as set forth therein, the authors retain all their 825 rights. 827 Acknowledgment 829 Funding for the RFC Editor function is currently provided by the 830 Internet Society.