idnits 2.17.1 draft-seite-dmm-dma-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 -- The document date (February 3, 2012) is 4466 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1122' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'RFC3484' is defined on line 515, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-netext-logical-interface-support-04 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Seite 3 Internet-Draft P. Bertin 4 Intended status: Informational France Telecom - Orange 5 Expires: August 6, 2012 February 3, 2012 7 Distributed Mobility Anchoring 8 draft-seite-dmm-dma-00.txt 10 Abstract 12 Most existing IP mobility solutions are derived from Mobile IP 13 principles where a given mobility anchor maintains Mobile Nodes (MNs) 14 binding up-to-date. Data traffic is then encapsulated between the 15 mobility anchor and the MN or its Access Router. These approaches 16 are usually implemented on a centralised architectures where both MN 17 context and traffic encapsulation need to be processed at a central 18 network entity, i.e. the mobility anchor. However, one of the trend 19 in mobile network evolution is to "flatten" mobility architecture by 20 confining mobility support in the access network, e.g. at the access 21 routers level, keeping the rest of the network unaware of the 22 mobility events and their support. This document discusses the 23 deployment of a Proxy Mobile IP approach in such a flat architecture. 24 The solution allows to dynamically distribute mobility functions 25 among access routers. The goal is also to dynamically adapt the 26 mobility support of the MN's needs by applying traffic redirection 27 only to MNs' flows when an IP handover occurs. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 6, 2012. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Basics of Dynamic Mobility Anchoring . . . . . . . . . . . . . 4 66 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. Dynamic Mobility Anchoring . . . . . . . . . . . . . . . . 6 68 4.2. Protocol sequence for handover management . . . . . . . . 8 69 4.3. Difference with Proxy Mobile IPv6 . . . . . . . . . . . . 10 70 4.4. Multiple Interfaces support . . . . . . . . . . . . . . . 11 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Terminology 81 Proxy Mobile IPv6 inherited terminology 83 The following terms used in this document are to be interpreted as 84 defined in the Proxy Mobile IPv6 specification [RFC5213]; Mobile 85 Node (MN), home Network Prefix (HNP), Mobile Node Identifier (MN- 86 Identifier), Proxy Binding Update (PBU), and Proxy Binding 87 Acknowledgement (PBA). 89 Mobility capable Access Router (MAR) 91 The Mobility capable Access Router is an access router which 92 provides mobility management functions. It has both mobility 93 anchoring and location update functional capabilities. A Mobility 94 capable Access Router can act as a Home or as a Visited Mobility 95 capable Access Router (respectively H-MAR and V-MAR). Any given 96 MAR could act both as H-MAR and V-MAR for a given mobile node 97 having different HNPs, either allocated by this MAR (H-MAR role) 98 or another MAR on which the mobile node was previously attached 99 (V-MAR role). 101 * H-MAR: it allocates HNP for mobile nodes. Similarly to 102 [RFC5213], the H-MAR is the topological anchor point for the 103 mobile node's home network prefix(es) it has allocated. The 104 H-MAR acts as a regular IPv6 router for HNPs it has allocated, 105 and when a mobile node has moved away and attached to a V-MAR, 106 the H-MAR is responsible for: tracking the mobile node location 107 (i.e. the V-MAR where the mobile node is currently attached), 108 and forwarding packets to the V-MAR where the mobile node is 109 attached. 110 * V-MAR: it manages the mobility-related signaling for a mobile 111 node, using a HNP allocated by a MAR previously visited by the 112 mobile node, that is attached to its access link. 114 2. Introduction 116 Most existing IP mobility solutions are derived from Mobile IP 117 [RFC3775] principles where a given mobility agent (e.g. the Home 118 Agent (HA) in Mobile IP or the Local Mobility Agent (LMA) in Proxy 119 Mobile IPv6 [RFC5213]) maintains Mobile Nodes (MNs) bindings. Data 120 traffic is then encapsulated between the MN or its Access Router 121 (e.g. the Mobile Access Gateway (MAG) in PMIPv6) and its mobility 122 agent. These approaches lead to the implementation of centralised 123 architectures where both MN context and traffic encapsulation need to 124 be maintained at a central network entity, the mobility agent. Thus, 125 when hundreds of thousands of MNs are communicating in a given 126 cellular network, such a centralised network entity causes well-known 127 bottlenecks and single point of failure issues, which requires costly 128 network dimensioning and engineering to be fixed. In addition, 129 tunnelling encapsulations impact the overall network efficiency since 130 they require the maintenance of MN's specific contexts in each tunnel 131 end nodes and they incur delays in packet processing and transport 132 functions. Such centralised approach provides the ability to route 133 MN traffic whatever its localisation is, as well as to support 134 handovers when it moves from access router to access router. 136 It is however well established that a huge amount of mobile 137 communications are set up while the user is not physically moving, 138 i.e. its MN stays in the same radio cell. For example, the user is 139 being communicating at home, in his office, at a cafe... Applying 140 the aforementioned centralised principles leads then to aggregate 141 user's contexts and traffic at a central node in the network for the 142 sake of mobility support whereas the MN remains motionless. As this 143 leads to the introduced scalability and performances issues, 144 alternative approaches may consider a way to better adapt mobility 145 support in the network to cope with MN's movements and its ongoing 146 traffic flows' requirements. Typically, one of the trend in the 147 evolution of mobile networks is to go on flat architecture with the 148 distribution of network functions, including mobility functions 149 [I-D.liu-distributed-mobility]. According to this principle, 150 [I-D.chan-netext-distributed-lma] proposes a deployment of Proxy 151 Mobile IPv6 in a flat architecture by splitting the location 152 management and routing functions of the LMA. 154 In this document, we propose a slightly different approach by 155 dynamically distributing mobility handling among terminals and access 156 routers. This document inherits from concepts introduced in 157 [NTMS2008]. The goal is twofold: 158 o dynamically adapting mobility support to each of the MN's needs by 159 applying traffic redirection only to MNs' flows that are already 160 established when an IP handover occurs; 161 o confining the mobility support at the access routers level, 162 keeping the rest of the network unaware of mobility events and 163 their support. 165 3. Basics of Dynamic Mobility Anchoring 167 In a standard IPv6 network without specific mobility support, any 168 host is able to set up communications flows using a global IPv6 169 address acquired with the support of its current access router 170 [RFC4862]. When the host moves from this access router to a new one, 171 its ongoing IP sessions cannot be maintained without leveraging on IP 172 mobility mechanisms. 174 However, once attached to the new access router, the host can again 175 acquire a routable global IPv6 address to be used for any new 176 communication flow it sets up. Hence, a flow based mobility support 177 may be restricted to provide traffic indirection to host's flows that 178 are already ongoing during host's handovers between access routers. 179 Any new flow being set up uses the new host's global address acquired 180 on the new link available after the handover. 182 When a multiple-interface host moves between access routers of 183 different access technologies, such a simple approach can also be 184 applied, considering that each network interface provides dynamically 185 global IPv6 addresses acquired on current access routers. Flows 186 mobility is then required only to support the necessary traffic 187 indirection from the access router on which the flow has been 188 initially set up to the access router the host is currently attached. 189 Such IP based indirection can even be made independent from access 190 technologies types, providing thus inherent inter-access mobility 191 facilities. 193 Hence, any given IP flow can be considered as implicitly anchored on 194 the current MN's access router when being set up. While the MN is 195 attached to its initial access router, the IP flow is delivered as 196 for any standard IPv6 node. The anchoring function at the access 197 router is thus needed only to manage traffic indirection if the MN 198 moves to a new access router (and for subsequent movements while the 199 IP flow remains active), maintaining the flow communication until it 200 ends up. 202 Any flow's incoming packet toward the MN is routed in a standard way 203 to the access router anchoring the flow as the packet contains the 204 destination IP address issued from router prefix. Then, if the MN is 205 currently attached to the initial anchor access router, the incoming 206 packet is directly delivered over the access link. Otherwise, the 207 anchoring access router needs to redirect the packet to the current 208 (or one of the currents) MN's access router(s). 210 Any flow's outgoing packet from the MN is sent over either the 211 initial anchor access router link or another access router link it is 212 currently using. In the first case, the packet can be routed in a 213 standard way, i.e., without requiring networks mobility support 214 functions. In the second case, we consider its redirection to the 215 initial flows' anchor router, but it may be noticed that direct 216 routing by the current access router may be also allowed (yet this 217 may lead to more stringent security and policy considerations). 219 4. Solution Overview 221 4.1. Dynamic Mobility Anchoring 223 The basic idea is to distribute mobility traffic management with 224 dynamic user's traffic anchoring in access network nodes. The 225 solution relies on a very simple flat architecture outlined in 226 Figure 1 where the Mobility capable Access Router (MAR) supports both 227 traffic anchoring and MN's location management functionalities. The 228 architecture relies on a centralized database storing ongoing 229 mobility sessions for the MNs (see Section 4.2 for details). This 230 database stores the HNPs currently allocated to the MN and their 231 respective anchoring point. This database could be an extension to 232 the policy store used in [RFC5213]. 234 +------------+ 235 | session DB | 236 / +------------+ 237 +----------/--------|------\--+ 238 ( IP /Network | \ ) 239 +--------/----------|------- \+ 240 / | \ 241 +-------+ +-------+ + ------+ 242 | MAR1 |___| MAR2 |____| MAR3 | 243 +-------+ +-------+ +-------+ 244 | 245 +-----+ 246 | MN1 | 247 +-----+ 249 Figure 1: Architecture for Distributed Mobility Anchoring 251 Regular IPv6 routing applies when an IP communication is initiated. 252 For instance, if the mobile node (e.g. MN1), being attached to MAR1, 253 initiates a communication with CN1, the traffic will be routed 254 through MAR1 without requiring any specific mobility operation. When 255 MN1 moves away from MAR1 and attaches to MAR3, the traffic remains 256 anchored to MAR1 and is tunneled between MAR1 and MAR3. MAR1 becomes 257 the mobility anchor, but only for traffic initiated by MN1 when it 258 was attached to MAR1. 260 Communications newly initiated, e.g. to CN2, while the mobile node is 261 attached to MAR3 will be routed in a standard way via MAR3. So, MAR3 262 is both the mobility anchor, i.e. the H-MAR, for traffic newly 263 initiated (i.e. when the mobile node is attached to MAR3) and the 264 V-MAR for traffic initiated while being attached to MAR1. If the 265 mobile node moves away from MAR3, while maintaining communications 266 with both CN1 and CN2, two mobility anchors come into play: the data 267 traffic will be anchored in MAR1 for communication with CN1 and in 268 MAR3 for communication with CN2. Summarizing , it is proposed to 269 locate mobility anchoring depending on where the flow is initially 270 created. Accordingly, communications are expected to be initiated 271 without requiring mobility anchoring and tunneling. 273 With this solution, even if a mobile node is moving across several 274 MARs, the tunnel endpoints are always on the initial H-MAR and on the 275 current V-MAR. In the case the mobile node moves from MAR1 to MAR2 276 then to MAR3, a tunnel will be firstly established between MAR1 and 277 MAR2 to forward HNP1; then a tunnel between MAR1 and MAR3 will be 278 established. 280 However such an architecture leads to new requirement on the HNP 281 prefix model. Actually, because the HNP is anchored to its mobility 282 anchor (i.e. H-MAR), a dynamic mobility anchoring requires that each 283 MAR must advertise different per-MN prefixes set. For example, if 284 MN1 is anchored to both MAR1 and MAR3, these two mobility capable 285 access routers would advertise respectively HNP1 and HNP3 for MN1. 287 _______ _______ 288 | | | | 289 | CN1 | | CN2 | 290 |_______| |_______| 291 '. Flow#2 . 292 Flow#1 ' '. | Flow#3 293 ' '...'''''''''''''.... . 294 ..''' '. '''.. 295 .' ' '.IP network . '. 296 : ' '. | : 297 '..' +-------+ . ..' 298 '''... | | ....''' 299 ' | MAR2 | \ . 300 MAR1 Forwarding Table ' | | \ | 301 +=====================+ ' | |'. \ . 302 HNP-1::/64 -> MAR3 ' +-------+\'. \ | 303 +-------+ \ '+ ------+ 304 | | \ | | 305 | MAR1 |-----------------| MAR3 | 306 | |'''''''''''''''''| | 307 | |-----------------| | 308 +-------+ +-------+ 309 ' ' | 310 Flow#1 ' . . Flow#3 311 ' ' | 312 +-----+ Flow#2 +-----+ 313 | MN1 | -----move-------> | MN1 | 314 +-----+ +-----+ 315 (single interface, IF1) 317 Figure 2: Distributed Mobility Anchoring 319 4.2. Protocol sequence for handover management 321 An example of handover management for a single interface mobile node 322 is depicted on Figure 3. The mobile node, MN1, is assumed to move 323 from MAR1 to MAR2. Following are the main steps of the handover 324 management process: 326 1. The mobile node, MN1, attaches to MAR1 which is responsible for 327 allocating the MN-HNP, e.g. HNP1 for MN1. 328 2. Hence, the mobile node can initiate and maintain data transport 329 sessions (with CN1 in the picture), using IP addresses derived 330 from HNP1, in a standard way while it remains attached to MAR1, 331 i.e. mobility functions do not come into play. 332 3. The MN handoffs to MAR2 which will thus acts as V-MAR for HNP1. 333 Fistly, MAR2 retrieves the ongoing MN's mobility sessions from 334 the centralized sessions database; here only one mobility session 335 is ongoing: (MN::NHP1,MAR1). Then MAR2 proceeds to location 336 update for HNP1 with MAR1 (H-MAR role), i.e., PBU/PBA exchange 337 between MAR2 and MAR1. 338 4. MAR2 also allocates new HNPs for MN1; these HNPs are meant to be 339 used by application flows initiated after the handoff. 340 5. MAR1, playing the H-MAR role for HNP1, encapsulates MN1's traffic 341 and tunnels it to the V-MAR, i.e. MAR2, where packets are 342 decapsulated and delivered to the MN. 343 6. The mobile node can initiate and maintain new data transport 344 sessions, e.g. with CN2, using IP addresses derived from HNP2. 345 This traffic is routed in a standard way while the mobile node 346 remains attached to MAR2. 348 MN1 MAR2 MAR1 CN1 CN2 349 | | | | | 350 | | | | | 351 L2 Attach | | | | 352 | | | | | 353 |----------------RS---------->| | | 354 | | | MAR1 allocates | 355 | | | and advertises HNP1 356 | | | MAR1 updates MN's 357 | | | mobility session 358 |<---------------RA-----------| up to the database 359 | | | | | 360 comm. to CN1 using HNP1 | | | 361 |<----------------data-flow#1--------->| | 362 | | | | | 363 handover | | | | 364 to MA2 | | | | 365 |-----RS----->| MAR2 allocates| | | 366 | | HNP2 for new communications | 367 | | and retrieve the anchoring point 368 | | from the centralized database | 369 | |----pBU------->| | | 370 | | | | | 371 | |<---pBA--------| | | 372 |<---RA-------| | | | 373 | | | | | 374 handover | | | | 375 completed | | | | 376 | | | | | 377 |<---flow#1 --|<===tunnel====>|------->| | 378 | | | | | 379 comm. to CN2 using HNP2 | | | 380 | | | | | 381 |<-----------------data-flow#2----------------->| 382 | | | | | 383 | | | | | 385 Figure 3: Handover management with Distributed Mobility Anchoring 387 4.3. Difference with Proxy Mobile IPv6 389 A V-MAR is required to advertise new per-MN HNP set for new IP 390 communications to be initiated, while Proxy Mobile IPv6 advertises 391 the same HNPs when roaming from MAG to MAG. So, while Proxy Mobile 392 IPv6 is based on the per-MN prefix model, this proposal leverages on 393 a per-MN and per-MAR prefix model. It is not required to statically 394 allocate different set of HNPs per MAR. Actually, at a given time, 395 only active MARs for an MN (i.e. access routers on which the mobile 396 node is currently attached to) need to share the per-MN HNPs set. 397 So, for the sake of scalability, per-MN HNPs should be dynamically 398 shared out among MN's active MARs. 400 Since each MAR anchors the IP traffic initiated when the mobile node 401 was attached to it, a mobile node may be served simultaneously by 402 more than one mobility anchor at the same time. 404 4.4. Multiple Interfaces support 406 The distribution of mobility functions can also apply in the context 407 of multiple-interfaces terminals. In such a case, any given IP flow 408 can be considered as implicitly anchored on the current host's access 409 router when set up. Until the host does not move from the initial 410 access router (H-MAR), the IP flow is delivered as for any standard 411 IPv6 node. The anchoring function at the H-MAR is thus managing 412 traffic indirection only if one, or several, IP flow(s) are moved to 413 another interface, and for subsequent movements while the initial 414 anchored flows remain active. This anchoring is performed on a per- 415 flow basis and each H-MAR needs to track all possible V-MARs for a 416 given host on the move. The H-MAR must also manage different tunnels 417 for a given mobile node providing that the node is multihomed and it 418 simultaneously processes different IP flows on its interfaces. 420 Lets consider a simple example to illustrate the dynamic per-flow 421 mobility anchoring. Figure 4 depicts the IP flow mobility management 422 for a mobile node with two interfaces. The IP data flows, Flow#1 and 423 Flow#2, have been initiated on if1. Thus, Flow#1 and Flow#2, using 424 respecively prefixes HNP1 and HNP2, are anchored to MAR1. Referring 425 to the picture, Flow#1 has not been moved; so Flow#1 is delivered in 426 a standard IPv6 way. Flow#2 has been transferred from If1 to If2, so 427 the the Flow#2 packets, corresponding to HNP2, are tunneled from MAR1 428 to MAR2. In other words, MAR1 and MAR2 are respectively the H-MAR 429 anchor and the V-MAR for flow#2. 431 _______ _______ 432 | | | | 433 | CN1 | | CN2 | 434 |_______| |_______| 435 ' . 436 Flow#1 ' | Flow#2 437 ' ...'''''''''''''.... . 438 ..''' '''.. 439 .' ' IP network . '. 440 : ' | : 441 '..' . ..' 442 '''.....................'|' 443 ' . 444 ' | 445 ' .- . - . - . - . - . - . 446 ' | 447 +-------+ Flow#2 + ------+ 448 | | tunneled | | 449 | MAR1 |-----------------| MAR2 | 450 |(H-MAR)| -.-.-.-.-.-.-.-.|(V-MAR)| 451 | |-----------------| | 452 +-------+ +----|--+ 453 ' . 454 Flow#1 ' | Flow#2 455 ' . 456 ' If1 +-----+ If2 | 457 ''''''''''| MN | - . - . 458 +-----+ 460 Figure 4: Distributed IF flow Mobility Anchoring 462 In case of the handover of an IP flow between interfaces, the mobile 463 node must rely on the logical interface support, as per 464 [I-D.ietf-netext-logical-interface-support]. 466 5. Security Considerations 468 TBD. 470 6. IANA Considerations 472 This document has no actions for IANA. 474 7. Acknowledgements 476 The authors would also like to express their gratitude to Hidetoshi 477 Yokota, Telemaco Melia, Dapeng Liu, Anthony Chan, Julien Laganier, 478 Lucian Suciu, Servane Bonjour, Karine Guillouard and many others for 479 having shared thoughts on the concept of distributed mobility. 481 8. References 483 8.1. Normative References 485 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 486 Address Autoconfiguration", RFC 4862, September 2007. 488 8.2. Informative References 490 [I-D.chan-netext-distributed-lma] 491 Chan, H., Xia, F., Xiang, J., and H. Ahmed, "Distributed 492 Local Mobility Anchors", 493 draft-chan-netext-distributed-lma-03 (work in progress), 494 March 2010. 496 [I-D.ietf-netext-logical-interface-support] 497 Melia, T. and S. Gundavelli, "Logical Interface Support 498 for multi-mode IP Hosts", 499 draft-ietf-netext-logical-interface-support-04 (work in 500 progress), October 2011. 502 [I-D.liu-distributed-mobility] 503 Liu, D., Cao, Z., Seite, P., and H. Chan, "Distributed 504 mobility management", draft-liu-distributed-mobility-02 505 (work in progress), July 2010. 507 [NTMS2008] 508 Bertin, P., "A Distributed Dynamic Mobility Management 509 Scheme designed for Flat IP Architectures.", NTMS'2008 , 510 November 2008. 512 [RFC1122] Braden, R., "Requirements for Internet Hosts - 513 Communication Layers", STD 3, RFC 1122, October 1989. 515 [RFC3484] Draves, R., "Default Address Selection for Internet 516 Protocol version 6 (IPv6)", RFC 3484, February 2003. 518 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 519 in IPv6", RFC 3775, June 2004. 521 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 522 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 524 Authors' Addresses 526 Pierrick Seite 527 France Telecom - Orange 528 4, rue du Clos Courtel, BP 91226 529 Cesson-Sevigne 35512 530 France 532 Email: pierrick.seite@orange.com 534 Philippe Bertin 535 France Telecom - Orange 536 4, rue du Clos Courtel, BP 91226 537 Cesson-Sevigne 35512 538 France 540 Email: philippe.bertin@orange.com