idnits 2.17.1 draft-perkins-dmm-matrix-04.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 -- The document date (July 13, 2012) is 4305 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 6317' is mentioned on line 460, but not defined == Unused Reference: 'RFC4423' is defined on line 572, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-lisp-23 ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) -- No information found for draft-chan-netext-distributed-lma - is the name correct? -- No information found for draft-wakikawa-mext-global-haha-spec - is the name correct? == Outdated reference: A later version (-02) exists of draft-liu-dmm-pmip-based-approach-01 == Outdated reference: A later version (-02) exists of draft-liebsch-mext-dmm-nat-phl-00 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IPv6 Extensions (mext) C. Perkins 3 Internet-Draft Tellabs 4 Intended status: Informational Dapeng. Liu 5 Expires: January 13, 2013 China Mobile 6 W. Luo 7 ZTE 8 July 13, 2012 10 DMM Comparison Matrix 11 draft-perkins-dmm-matrix-04 13 Abstract 15 Distributed Mobility Management (DMM) is proposed as a way to enable 16 scalable growth of mobile core networks so that network service 17 providers can meet new requirements for performance and reduced 18 operational expenditures. This requires reconsideration of existing 19 approaches within the IETF and elsewhere in order to determine which 20 if any such approaches may be used as part of a DMM solution. 22 Status of This Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 2, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Current Practice of DMM . . . . . . . . . . . . . . . . . . . 4 58 3. Matrix Comparing Existing Approaches for DMM . . . . . . . . . 5 59 4. Explanations for Matrix Entries . . . . . . . . . . . . . . . 6 60 4.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 6 61 4.2. Source address selection refinements . . . . . . . . . . . 7 62 4.3. Dynamically allocated home agent . . . . . . . . . . . . . 8 63 4.4. Binding updates to CN even without HA . . . . . . . . . . 9 64 4.5. Transport protocol Mobility . . . . . . . . . . . . . . . 9 65 4.6. Local anchor . . . . . . . . . . . . . . . . . . . . . . . 10 66 4.7. HIP/LISP . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 4.8. Distributed anchor with direct tunnel . . . . . . . . . . 11 68 4.9. Per-Host Locators Mechanism . . . . . . . . . . . . . . . 12 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 73 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 74 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 The goal of this document is to identify and compare known existing 79 approaches for Distributed Mobility Management (DMM). 80 Characterizations of each of the various methods selected for 81 comparison are provided in a matrix form according to whether or not 82 they meet certain criteria. 84 Efforts within the IETF have been launched to find improved mobility 85 management by decentralizing some or all of the traditional functions 86 associated with mobility, including handovers, location management, 87 identification, and so on. 89 The following abbreviations appear in this document: 91 MN: mobile node 93 HA: home agent 95 CN: correspondent node 97 FQDN: Fully Qualified Domain Name 99 The following approaches to mobility management are characterized: 101 Route optimization (RO): MN supplies Binding Updates directly to 102 CN.[RFC3775] 104 Source address selection refinements (SAddrSel): MN picks source 105 address appropriate for current point of attachment when launching 106 an application. 108 Dynamically allocated home agent (DynHA): Mobility anchor for MN 109 is allocated on demand. 111 Binding updates to CN even without HA (CN-wo-HA): Similar to RO, 112 but does not require protocol signaling with home agent. 114 Transport protocol (Trans-Mob) : MN modifies transport (e.g., TCP, 115 SCTP, DCCP, MPTCP) protocol parameters to change the IP address of 116 transport connection endpoint 118 Local anchor (Anchor-Mob): Local mobility anchor (e.g., MAP in 119 HMIP [RFC5380]) available for use by MN at its current point of 120 attachment. 122 Dynamic DNS (DynDNS): When MN gets a new address, DNS is updated 123 so that the MN's FQDN resolves to that new address. 125 Distributed anchor with direct tunnel (Dis-Anc): MN's current 126 anchor can be changed dynamically depends on current location of 127 MN (e.g. methods introduced in [I-D.chan-netext-distributed-lma], 128 [I-D.wakikawa-mext-global-haha-spec] and 129 [I-D.liu-dmm-pmip-based-approach]). Optimized routing is realized 130 by a direct tunnel between anchors of MN and its CN. 132 Per-Host Locators Mechanism (Host-Loc): By using identifier- 133 locator split mechanism to solve the routing above anchor level 134 and enable optimal routes to the mobile node's current mobility 135 anchor ([I-D.liebsch-mext-dmm-nat-phl]) 137 The approaches listed above will be characterized according to the 138 following criteria: 140 1. scalability: in # of nodes 142 2. specified?: whether there is a working group document specifying 143 the approach 145 3. IPadd continuity: provides stable IP address 147 4. backhaul friendly: reduces burden on backhaul 149 5. app friendly: apps do not require new code 151 6. server-friendly: server state minimized, servers do not require 152 new code 154 7. local routing: "local breakout" / "hairpinning" / local traffic 155 routed locally 157 8. low signaling: not too much signaling required 159 2. Current Practice of DMM 161 Currently, IETF has specified mobile IP and its variants for mobility 162 managment. Current mobile IP protocol could be deployed in a 163 distributed way to best meet the requirment of DMM. 165 Dynamic Anchoring approach: 167 Dynamic anchoring allows the application on the mobile node always 168 choose the closest anchor. The mobility anchors could be deployed in 169 a distributed way: for example, deploy the mobility anchors in the 170 access router level in an IP network or in the local gateway in 3GPP 171 LIPA/SIPTO network. 173 Both network based and client based mobile IP solution could use the 174 dynamic anchoring concept. There are common problems that need to be 175 considered for both network/client based distributed mobile IP 176 deployment. The problems include active session managment, source 177 address selection, CN initiate sessio etc. 179 Hierarchical mobile IP 181 Hierachical mobile IP was designed to reduce the signalling overhead 182 of mobile IP protocol by introducing regional mobility anchor. The 183 regional mobility anchor could also be deployed in a distributed way. 184 It shares the similar problems as mobile IP in terms of session 185 management, source address selection etc. 187 3. Matrix Comparing Existing Approaches for DMM 189 The following matrix rates the approaches described in the previous 190 section according to the characteristics listed. 192 RO SAddr DynHA CN Trans Anchor DynDNS HIP/ Dis- Host 193 Sel wo-HA Mob Mob Mob LISP Anc -LoC 195 scalability Y Y M Y Y M M Y Y Y 197 specified? Y N N N Y Y Y Y N N 199 IPadd Y N N Y Y Y N Y Y Y 200 continuity 202 backhaul Y Y Y Y Y M Y M Y Y 203 friendly 205 app Y N Y Y N Y M N/Y Y Y 206 friendly 208 server M Y Y Y N Y Y N/Y Y Y 209 friendly 211 local Y Y M Y Y N Y M M M 212 routing 214 low N Y M N N N N N M M 215 signaling 217 Table 1: Comparison Matrix [Legend: Y=Yes, N=No, M=Maybe] 219 4. Explanations for Matrix Entries 221 Most of the matrix entries are relatively self-evident. For 222 instance, "Trans Mob" (Transport-based Mobility) approaches are rated 223 as not "app friendly" because applications require changes in order 224 to make use of the approach. 226 For approaches that are identified generically, it may be ambiguous 227 whether or not they are properly specified in any working group 228 document. Here, such approaches are characterized as specified if 229 any particular approach in the generic family is specified. More 230 detail may be needed in the future, in which case more columns or a 231 new table may be needed. 233 4.1. Route Optimization 235 Mobile IPv6 supports route optimization and bi-directional tunneling. 236 Using route optimization, the mobile node can send mobility 237 signalling, and subsequently data packets, directly to the 238 correspondent node. The following aspects of route optimization are 239 characterized in the comparison matrix. 241 1. Scalability: Using route optimization, the signalling and data do 242 not have to be sent through the centralized mobility anchor. 243 Since the effect of route optimization is to reduce traffic 244 through the home network, scalability is improved. Moreover, 245 route optimization can reduce the effect of the home agent as a 246 single point of failure. 248 2. Specified: RFC 3775 specifies the route optimization mode of 249 MIPv6. 251 3. IP address continuity: In MIPv6 route optimization mode, the 252 mobile node still uses the same home address as the bi- 253 directional tunnel mode. RO mode supports IP address continuity. 255 4. backhaul friendly: In RO mode, the data can send directly to the 256 CN. Data do not need to send through centralized moblity anchor, 257 thence RO is backhaul friendly. 259 5. app friendly: RO mode does not require application changing, so 260 it is application friendly. 262 6. server-friendly: RO mode requires the server (i.e., CN) to also 263 support Mobile IP RO mode. In this sense, RO is not server 264 friendly. 266 7. local routing: In RO mode, the data is forwarded directly between 267 MN and CN, it thence can support local routing. 269 8. low signaling: MIPv6 RO mode use the return routability 270 procedure. which requires more signalling than MIPv6 bi- 271 directional tunnel mode. 273 4.2. Source address selection refinements 275 Source address selection refinements (SAddrSel): MN picks source 276 address appropriate for current point of attachment when launching an 277 application. 279 1. Scalability: Since the MN can pick a local source address, 280 packets to/from the MN do not have to traverse the home network, 281 improving scalability and reducing delay. 283 2. Specified: see [RFC3484] 285 3. IP address continuity: If the MN uses a local source address, IP 286 address continuity is likely to be violated when MN moves to a 287 new network where that address is no longer addressable. 289 4. backhaul friendly: Since packets do not have to traverse the home 290 network, this solution is more backhaul friendly. 292 5. app friendly: since applications are likely to require changes in 293 order to make the address selection, this solution is less app- 294 friendly. If source addresses are selected without involvement 295 of the application, this effect would be eliminated. 297 6. server-friendly: The source address selection by the application 298 does not involve the server. 300 7. local routing: Using a local source address enables local routing 301 for local services and communication partners. 303 8. low signaling: This solution does not impose any signaling 304 signaling requirement, unless the address selection algorithm 305 requires policy management by the operator. 307 4.3. Dynamically allocated home agent 309 Dynamically allocated home agent (DynHA): Mobility anchor for MN is 310 allocated on demand. 312 Scalability: If the network supports dynamically allocated home 313 agents, the mobile node can choose the nearest home agent. Other 314 mobile nodes can use different home agents. But when changing 315 location, home agent may not be able to change accordingly. The 316 mechanism for associating home agents to mobile nodes can vary, and 317 different algorithms have different scalability characteristics; some 318 may be more scalable than others. Method relying on anycast 319 addresses for home agents are among the more scalable approaches. 321 Specified: RFC 3775 specifies dynamic home agent address discovery 322 and dynamic home prefix discovery. But it does not support changing 323 home agent afterwards. If the MN selected a new home agent, it is 324 likely that existing communications through the previous home agent 325 would be disrupted. 327 IP address continuity: When mobile node changes location, it may 328 choose a new home agent, but home address would also need to change 329 accordingly, making IP address continuity unlikely. 331 backhaul friendly: The mobile node can choose the nearest home agent, 332 in this sense, it is backhaul friendly. 334 app friendly: application does not need to change to support 335 dynamically allocated home agent. So it is app friendly. 337 server-friendly: server does not need to change to support 338 dynamically allocated home agent, so it is server friendly. 340 Local routing: When mobile node selects the nearest home agent, it 341 can support local routing through that home agent. 343 Low signaling: Dynamic discovery and assignment of a home agent may 344 need additional signaling. 346 4.4. Binding updates to CN even without HA 348 Binding updates to CN even without HA (CN-wo-HA): Similar to route 349 optimization, but does not require protocol signaling with home 350 agent. 352 1. Scalability: yes, same as for route optimization. 354 2. Specified: Internet drafts exist, but no working group document. 356 3. IP address continuity: yes, same as for route optimization. 358 4. backhaul friendly: yes, same as for route optimization. 360 5. app friendly: yes, same as for route optimization. 362 6. server-friendly: no, same as for route optimization. 364 7. local routing: yes, same as for route optimization. 366 8. low signaling: no, same as for route optimization. 368 4.5. Transport protocol Mobility 370 Transport protocol (Trans-Mob): MN modifies transport (e.g., TCP, 371 SCTP, DCCP, MPTCP) protocol parameters to change the IP address of 372 transport connection endpoint. In many ways, such approaches 373 resemble CN-wo-HA except that the signaling occurs at a different 374 layer of the protocol stack (namely, at the transport layer instead 375 of the network layer). 377 1. Scalability: yes, same as for CN-wo-HA. 379 2. Specified: no, same as for CN-wo-HA. 381 3. IP address continuity: The point of such approaches is, 382 basically, to eliminate the need for IP address continuity. So, 383 while IP address continuity is not provided, this should not be 384 considered a demerit of transport mobility approaches. It would 385 be better to compare approaches based on "session continuity" 386 instead of "IP address continuity". 388 4. backhaul friendly: yes, same as for CN-wo-HA. 390 5. app friendly: yes (typically), same as for CN-wo-HA. 392 6. server-friendly: no, same as for CN-wo-HA. 394 7. local routing: yes, same as for CN-wo-HA. 396 8. low signaling: MIPv6 RO mode use the return routability 397 procedure. which requires more signalling than MIPv6 bi- 398 directional tunnel mode. 400 4.6. Local anchor 402 Local anchor (Anchor-Mob): Local mobility anchor (e.g., MAP in HMIP 403 [RFC5380]) available for use by MN at its current point of 404 attachment. 406 1. Scalability: The mobile node signals the nearest anchor. MNs in 407 other networks can use different anchors. Scalability is 408 improved because the signaling path between the mobile node and 409 its local anchor is shorter. Moreover, local mobility anchors 410 offload work from any remote mobility anchor such as the home 411 agent. 413 2. Specified: HMIP[RFC5380] 415 3. IP address continuity: In conjunction with Mobile IPv6 as a macro 416 mobility protocol, IP address continuity is enabled. 418 4. backhaul friendly: The mobile node can choose the nearest local 419 anchor; in this sense, it is backhaul friendly. 421 5. app friendly: application does not need to change to support 422 dynamically allocated home agent. So it is app friendly. 424 6. server-friendly: server does not need to change to support local 425 mobility anchor, so it is server friendly. 427 7. Local routing: Generally, the use of a local anchor does not 428 necessarily improve local routing; additional functionality would 429 need to be designed or included with the local anchor. 431 8. Low signaling: Additional signaling is required for the mobile 432 node to insert new bindings at the local anchor. 434 4.7. HIP/LISP 436 HIP: Host Identity Protocol(RFC 4423); LISP: Locator/ID Separation 437 Protocol. 439 1. Scalability: HIP/LISP are both location/indentification 440 separation protocol. Both HIP/LISP can support large scale 441 deployment in HIP/LISP domain. But when a node running HIP/LISP 442 needs to communicate with other hosts that are not located in the 443 HIP/LISP domain, another mechanism is needed. 445 2. HIP is specified in RFC 4423[RFC5380]. LISP is specified in 446 [I-D.ietf-lisp]. 448 3. IP address continuity: HIP/LISP both use host indentification for 449 addressing. The host can use a stable IP address for 450 identification and addressing, thence HIP/LISP can support IP 451 address continuity. 453 4. backhaul friendly: HIP/LISP both use routing address for packet 454 routing; there is no centralized anchor point in the data plane. 455 But for communication to other hosts which are not located in the 456 HIP/LISP domain, a gateway function is needed and the data 457 traffic is constrained to travel through the gateway. 459 5. app friendly: LISP does not require application modification. 460 HIP may require application modification [RFC 6317]. 462 6. server-friendly: For mobile nodes, HIP may require server 463 modifications; LISP does not require server modification. 465 7. Local routing: For communication within the HIP/LISP domain, HIP/ 466 LISP can support local routing since the routing is based on 467 routing prefix instead of host indentification and there is no 468 cent 470 8. ralized anchor point. 472 9. Low signaling: HIP/LISP need new signaling in the host/network to 473 support its function. 475 4.8. Distributed anchor with direct tunnel 477 1. Scalability: Mobile node's home network contains its first anchor 478 when MN is initialized. When MN moves to a visit network, it can 479 change its mobility anchor to a new anchor point which is located 480 in this visit network. The traffic will not go through mobile 481 node's home network when it is in visit network. No centralized 482 mobility anchor is needed and scalability is improved. Besides, 483 dynamically allocated mobility anchor mechanism can also be 484 applied when mobile node is initialized in its home network. 486 2. Specified: Internet drafts exist, but no working group document. 488 3. IP address continuity: All mechanisms introduced in 489 [I-D.chan-netext-distributed-lma], 490 [I-D.wakikawa-mext-global-haha-spec] and 491 [I-D.liu-dmm-pmip-based-approach] are claimed to support IP 492 address continuity. I.e. additional mechanisms are used to 493 guarantee that mobile node can keeps its HoA unchanged even its 494 mobility anchor is changed. 496 4. Backhaul friendly: Mobile node can change it mobility anchor to a 497 best anchor point (e.g. a nearest anchor point) and packets do 498 not have to traverse the home network, this solution is more 499 backhaul friendly. 501 5. App friendly: Does not require application changing. Socket of 502 application is always binded to mobile node's HoA, so it is 503 application friendly. 505 6. Server-friendly: Does not require server changing, so it is 506 server friendly. 508 7. Local routing: Packets from mobile node to its correspondent node 509 shall go though mobile node's current mobility anchor. If the 510 mobility anchor is mobile node's first router, then local routing 511 is supported. 513 8. Low signaling: Additional signaling is needed for supporting 514 location management approaches and handoff approaches. It can be 515 excepted that number of signaling may increase with growth of 516 mobile node's number. It depends on the specific design. 518 4.9. Per-Host Locators Mechanism 520 1. Scalability: As claimed in [I-D.liebsch-mext-dmm-nat-phl], mobile 521 node are supported to change its current mobility anchor, i.e. 522 when mobile node is not at home, packet will not go through its 523 home network which is similar with Dis-Anc. So it is Yes. 525 2. Specified: Internet drafts exist, but no working group document. 527 3. IP address continuity: Mobile node can keep its HoA unchanged, so 528 IP address continuity is guaranteed. How to guarantee limited 529 packet loss rate when mobile node changes its current anchor 530 point is not very clear now. 532 4. Backhaul friendly: Yes. The reason is same as Dis-Anc. 534 5. App friendly: Yes. The reason is same as Dis-Anc. 536 6. Server-friendly: Yes. The reason is same as Dis-Anc. 538 7. Local routing: Maybe. The reason is same as Dis-Anc. 540 8. Low signaling: The mechanism is based on NAT to guarantee per- 541 host locators. How to guarantee the synchronization of NAT 542 status is un-clear now. But it can be excepted that additional 543 signaling is necessary. 545 5. Security Considerations 547 This document does not have any security considerations. 549 6. IANA Considerations 551 This document does not have any IANA actions. 553 7. References 555 7.1. Normative References 557 [I-D.ietf-lisp] Farinacci, D., Fuller, V., 558 Meyer, D., and D. Lewis, 559 "Locator/ID Separation Protocol 560 (LISP)", draft-ietf-lisp-23 561 (work in progress), May 2012. 563 [RFC3484] Draves, R., "Default Address 564 Selection for Internet Protocol 565 version 6 (IPv6)", RFC 3484, 566 February 2003. 568 [RFC3775] Johnson, D., Perkins, C., and 569 J. Arkko, "Mobility Support in 570 IPv6", RFC 3775, June 2004. 572 [RFC4423] Moskowitz, R. and P. Nikander, 573 "Host Identity Protocol (HIP) 574 Architecture", RFC 4423, 575 May 2006. 577 [RFC5380] Soliman, H., Castelluccia, C., 578 ElMalki, K., and L. Bellier, 579 "Hierarchical Mobile IPv6 580 (HMIPv6) Mobility Management", 581 RFC 5380, October 2008. 583 7.2. Informative References 585 [I-D.chan-netext-distributed-lma] Chan, H., Xia, F., Xiang, J., 586 and H. Ahmed, "Distributed 587 Local Mobility Anchors", draft 588 -chan-netext-distributed-lma- 589 03, March 2010. 591 [I-D.wakikawa-mext-global-haha-spec] Wakikawa , R., Kuntz, R., Zhu, 592 Z., and L. Zhang, "Global HA to 593 HA Protocol Specification", dr 594 aft-wakikawa-mext-global-haha- 595 spec-02, September 2011. 597 [I-D.liu-dmm-pmip-based-approach] Liu, D., Song, J., and W. Luo, 598 "PMIP Based Distributed 599 Mobility Management Approach", 600 draft-liu-dmm-pmip-based- 601 approach-01, December 2011. 603 [I-D.liebsch-mext-dmm-nat-phl] Liebsch , M., "Per-Host 604 Locators for Distributed 605 Mobility Management", draft- 606 liebsch-mext-dmm-nat-phl-00, 607 October 2011. 609 Appendix A. Acknowledgements 611 This document has benefitted from discussions with the following 612 people, in no particular order: Seok Joo Koh, Jouni Korhonen, Julien 613 Laganier, Dapeng Liu, Telemaco Melia, Pierrick Seite 615 Authors' Addresses 617 Charles E. Perkins 618 Tellabs 620 Phone: +1-408-421-1172 621 EMail: charliep@computer.org 623 Dapeng Liu 624 China Mobile 626 Phone: +86-139-117-88933 627 EMail: liudapeng@chinamobile.com 629 Wen Luo 630 ZTE 632 Phone: 633 EMail: luo.wen@zte.com.cn