idnits 2.17.1 draft-seite-dmm-dma-07.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 6, 2014) is 3725 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-17) exists of draft-ietf-dmm-requirements-14 == Outdated reference: A later version (-14) exists of draft-ietf-netext-logical-interface-support-08 == Outdated reference: A later version (-05) exists of draft-korhonen-dmm-prefix-properties-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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 10, 2014 JH. Lee 6 Telecom Bretagne 7 February 6, 2014 9 Distributed Mobility Anchoring 10 draft-seite-dmm-dma-07.txt 12 Abstract 14 Most existing IP mobility solutions are derived from Mobile IP 15 principles where a given mobility anchor maintains Mobile Nodes (MNs) 16 binding up-to-date. Data traffic is then encapsulated between the 17 mobility anchor and the MN or its Access Router. These approaches 18 are usually implemented on a centralised architectures where both MN 19 context and traffic encapsulation need to be processed at a central 20 network entity, i.e. the mobility anchor. However, one of the trend 21 in mobile network evolution is to "flatten" mobility architecture by 22 confining mobility support in the access network, e.g. at the access 23 routers level, keeping the rest of the network unaware of the 24 mobility events and their support. This document discusses the 25 deployment of legay Proxy Mobile IP approach in such a flat 26 architecture. The solution allows to dynamically distribute mobility 27 functions among access routers for an optimal routing management. 28 The goal is also to dynamically adapt the mobility support of the 29 MN's needs by applying traffic redirection only to MNs' flows when an 30 IP handover occurs. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 10, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Basics of Distributed Mobility Management . . . . . . . . . . 5 69 3.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.2. Considerations on Client based mobility management . . . . 6 71 3.3. Considerations on Network based mobility management . . . 8 72 4. Solution Overview for network based DMM . . . . . . . . . . . 8 73 4.1. Distributed and Dynamic Mobility Anchoring . . . . . . . . 8 74 4.2. Protocol sequence for handover management . . . . . . . . 11 75 4.3. Multiple Interfaces support . . . . . . . . . . . . . . . 12 76 5. Difference with Proxy Mobile IPv6 . . . . . . . . . . . . . . 14 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Terminology 87 Proxy Mobile IPv6 inherited terminology 89 The following terms used in this document are to be interpreted as 90 defined in the Proxy Mobile IPv6 specification [RFC5213]; Mobile 91 Node (MN), home Network Prefix (HNP), Mobile Node Identifier (MN- 92 Identifier), Proxy Binding Update (PBU), and Proxy Binding 93 Acknowledgement (PBA). 95 Mobility capable Access Router (MAR) 97 The Mobility capable Access Router is an access router which 98 provides mobility management functions. It has both mobility 99 anchoring and location update functional capabilities. A Mobility 100 capable Access Router can act as a Home or as a Visited Mobility 101 capable Access Router (respectively H-MAR and V-MAR). Any given 102 MAR could act both as H-MAR and V-MAR for a given mobile node 103 having different HNPs, either allocated by this MAR (H-MAR role) 104 or another MAR on which the mobile node was previously attached 105 (V-MAR role). 107 * H-MAR: it allocates HNP for mobile nodes. Similarly to 108 [RFC5213], the H-MAR is the topological anchor point for the 109 mobile node's home network prefix(es) it has allocated. The 110 H-MAR acts as a regular IPv6 router for HNPs it has allocated, 111 and when a mobile node has moved away and attached to a V-MAR, 112 the H-MAR is responsible for: tracking the mobile node location 113 (i.e. the V-MAR where the mobile node is currently attached), 114 and forwarding packets to the V-MAR where the mobile node is 115 attached. 116 * V-MAR: it manages the mobility-related signaling for a mobile 117 node, using a HNP allocated by a MAR previously visited by the 118 mobile node, that is attached to its access link. 120 2. Introduction 122 Most existing IP mobility solutions are derived from Mobile IP 123 [RFC3775] principles where a given mobility agent (e.g. the Home 124 Agent (HA) in Mobile IP or the Local Mobility Agent (LMA) in Proxy 125 Mobile IPv6 [RFC5213]) maintains Mobile Nodes (MNs) bindings. Data 126 traffic is then encapsulated between the MN or its Access Router 127 (e.g. the Mobile Access Gateway (MAG) in PMIPv6) and its mobility 128 agent. In other words, these approaches rely on a centralised 129 architecture where both MN mobility context and traffic encapsulation 130 features need to be maintained at a central network entity, the 131 mobility agent. Such centralised approach provides the ability to 132 route MN traffic whatever its localisation is, as well as to support 133 handovers when it moves from access router to access router; however, 134 when millions of MNs are communicating in a given cellular network, 135 such a centralised network entity may cause bottlenecks and single 136 point of failure issues, which requires costly network dimensioning 137 and engineering to be fixed. In addition, tunnelling encapsulations 138 impact the global network efficiency since they require the 139 maintenance of MN's specific contexts in each tunnel end nodes and 140 they incur delays in packet processing and transport functions. 141 Besides, centralized mobility management might not take into account 142 current network evolution where the trend is to cache and distribute 143 content (e.g. CDN architecture) closer to the end-user. As a 144 consequence, alternative mobility approaches are currently being 145 discussed and a potential solution is the distribution of mobility 146 anchors, as stated by requirement "REQ1" in 147 [I-D.ietf-dmm-requirements]. 149 Moreover, it is well established that a huge amount of mobile 150 communications are set up while the MN remains attached to the same 151 access router. For example, the user is being communicating at home, 152 in his office, at a cafe, etc. and the mobility support is thus not 153 required. Applying the aforementioned centralised principles leads 154 then to maintain user's mobility contexts, whereas the MN remains 155 motionless. So, to avoid such a waste of resources, mobility 156 management should come into play only when the mobile node changes 157 the point of attachment (i.e. performs a handover) and when it needs 158 the conservation of the current IP address. Actually, this is the 159 requirement "REQ2" from [I-D.ietf-dmm-requirements]. 161 The DMM working group has been chartered to address above issues by 162 exploring the distribution of mobility management functions and, for 163 the sake of pragmatism, it has been agreed to firstly focus on 164 existing mobility protocols. The goal of this document is to address 165 this concern and, thus, has no other ambition than to discuss the use 166 of legacy IP mobility protocols in distributed anchoring 167 architecture. Besides, it must be noted this document aims only to 168 meet basic [I-D.ietf-dmm-requirements] requirements, namely: 170 o confining the mobility support at the access routers level, 171 keeping the rest of the network unaware of mobility events and 172 their support (REQ1); 173 o dynamically adapting mobility support to each of the MN's needs by 174 applying traffic redirection only to MNs' flows that are already 175 established when an IP handover occurs (REQ2). 177 3. Basics of Distributed Mobility Management 179 3.1. Fundamentals 181 As stated in [I-D.ietf-dmm-requirements], mobility anchoring may be 182 distributed to multiple locations in the access network. For 183 example, mobility anchoring (MA) function could be co-located with 184 the access router (AR) as shown on Figure 1. This architecture 185 allows the traffic to be anchored closer to the mobile node and, for 186 example, to provide optimal mobility support to distributed content 187 (e.g. CDN based delivery architecture). 189 +------+ +------+ +------+ +------+ 190 |AR/MA | |AR/MA | |AR/MA | |AR/MA | 191 +------+ +------+ +------+ +------+ 192 | 193 ---- 194 | MN | 195 ---- 197 Figure 1: Distributed Mobility Management 199 Mobility management may be partially distributed, i.e. only the data 200 plane is distributed, or fully distributed, i.e. both the data plane 201 and control plane are distributed [I-D.yokota-dmm-scenario]. If 202 conceptual differences exist, these two approaches share common 203 fundamentals and it is possible to describe the generic behavior of a 204 DMM deployment. Note that the following focuses only on the two 205 first requirements of [I-D.ietf-dmm-requirements] (i.e. distribution 206 of mobile anchoring and dynamic mobility management) 208 In a standard IPv6 network without specific mobility support, any 209 host is able to set up communications flows using a global IPv6 210 address acquired with the support of its current access router 211 [RFC4862]. When the host moves from this access router to a new one, 212 its ongoing IP sessions cannot be maintained without leveraging on IP 213 mobility mechanisms. However, once attached to the new access 214 router, the host can again acquire a routable global IPv6 address to 215 be used for any new communication flow it sets up. Hence, a flow 216 based mobility support may be restricted to provide traffic 217 indirection to host's flows that are already ongoing during host's 218 handovers between access routers. Any new flow being set up uses the 219 new host's global address acquired on the new link available after 220 the handover. 222 When a multiple-interface host moves between access routers of 223 different access technologies, such a simple approach can also be 224 applied, considering that each network interface provides dynamically 225 global IPv6 addresses acquired on current access routers. 227 Hence, any given IP flow can be considered as implicitly anchored on 228 the current MN's access router when being set up. Meaning that, if 229 the MN moves across more than one access router and initiates IP 230 communications while being attached to different access routers, the 231 MN might be served simultaneously by more than one mobility anchor. 232 While the MN is attached to its initial access router, the IP flow is 233 delivered as for any standard IPv6 node. The anchoring function at 234 the access router is thus needed only to manage traffic indirection 235 if the MN moves to a new access router and for subsequent movements 236 while the IP flow remains active), maintaining the flow communication 237 until it ends up. 239 Any packet sent to the MNis routed in a standard way to the access 240 router anchoring the flow as the packet contains the destination IP 241 address issued from router prefix. Then, if the MN is currently 242 attached to the initial anchor access router, the incoming packet is 243 directly delivered over the access link. Otherwise, the anchoring 244 access router needs to redirect the packet to the current (or one of 245 the currents) MN's access router(s). 247 Any outgoing packet from the MN is sent over either the initial 248 anchor access router link or another access router link it is 249 currently using. In the first case, the packet can be routed in a 250 standard way, i.e., without requiring networks mobility support 251 functions. In the second case, we consider its redirection to the 252 initial flows' anchor router, but it may be noticed that direct 253 routing by the current access router may be also allowed (yet this 254 may lead to more stringent security and policy considerations). 256 3.2. Considerations on Client based mobility management 258 Actually, there is no issue to implement a basic DMM (as described in 259 previous section) with vanilla Mobile IP protocol, e.g. [RFC3775], 260 as long as the MN can manage simultaneously different bindings to 261 different Home Agents (HA), i.e. manage simultaneously more than one 262 tunnel to the mobile anchors. Basically, nothing prevent to 263 implement the HA functionalities in the access routers, so that any 264 given IP flow can be considered as implicitly anchored on the current 265 host's access router when set up. The anchoring function at the 266 access router is acting only to manage traffic indirection while the 267 host moves to a new access router. When the MN moves to a new access 268 router, the MN implicitly considers the previous access router as the 269 HA for IP addresses allocated by this access router. Then, the MN 270 can perform the binding update to the previous access router for IP 271 session initiated on it. So, MN's current traffic remains attached 272 to the previous access router which is responsible for forwarding the 273 IP flows to the MN. 275 Figure 2 illustrates the use of Mobile IP in a distributed 276 architecture. For example, let's consider an IP flow, flow#1, 277 initiated by the mobile node, MN, when attached to AR1. Flow#1 is 278 routed in a standard way as long as the MN remains attached to AR1. 279 If the MN moves to AR2, the MN proceeds to the binding update to AR1, 280 which plays the role of HA, so that flow#1 remains anchored to AR1. 281 The home address is the IP address obtained from AR1 and the Care-of- 282 Address is the IP address obtained from AR2. If MN starts a new IP 283 communication, flow#2, while attached to AR2; flow#2 is routed in a 284 standard way as long as the MN remains attached to AR2. In this 285 situation, applications can use either the Home Address or the Care- 286 of-Address and the IP stack is supposed to make the source address 287 selection depending on the need for mobility support; in the example 288 of Figure 2, the Home Address shall be used as the source address for 289 flow#1 and the Care-of-Addresses for flow#2. Then, if the MN moves 290 to another access router, flow#1 and flow#2 will be respectively 291 anchored to AR1/HA and AR2/HA. Mobile IP resources (mobility context 292 and tunneling in both ARx/HA and MN) are released after IP 293 communcation stopped. 295 +---+ +---+ 296 |CN1| |CN2| 297 +---+ +--,+ 298 _.- +----------. \ 299 ,' | `---'-. 300 ,-' |flow#1 \ `-. 301 ,' | ' `. 302 ( | IP Network \ 303 `. | ' ,' 304 `-. ; ,\' 305 \_ ; _.----' ' 306 - +----------'' | 307 | ' 308 +---:---+ +-------+ 309 | AR1`--|------------| AR2 | 310 | HA |------------|HA | 311 +-------+ +-------+ 312 flow#1 \\ \ flow#2 313 tunnelled \\ ' 314 +-----+ +--\--+ 315 | MN | ----move-------> | MN | 316 +-----+ +-----+ 318 Figure 2: Distributed Client Based Mobility 320 3.3. Considerations on Network based mobility management 322 It is also possible to go for DMM with Proxy Mobile IPv6 [RFC5213]. 323 For example, mobility functions, i.e. MAG and LMA, can be co-located 324 with the access routers. The anchoring behavior might be similar to 325 the client based solution; however there is an issue with the binding 326 update management. In a network based solution, the MN is not 327 supposed to participate to mobility signalling and the MAG is 328 expected to know the mobility anchor serving the MN. This problem 329 can be tricky in distributed mobility architecture because 1) the MN 330 can be served by more than one LMA (see fundamentals in Section 3.1) 331 and 2) the mobility anchor depends on point of attachment when the IP 332 communication has been initiated. There are basically two ways to 333 address the issue without modifying proxy mobile IP: 335 1. Involve the MN in the mobility management process: during the 336 attachment process to a new access router, the MN could 337 communicate its ongoing mobility sessions (i.e. list of current 338 HNP with associated mobility anchors) to the MAG. For example, 339 this information could be provided in a dedicated router 340 solicitation option. 341 2. Rely on centralized part of the control plane: when the MN 342 attaches to a new access router, the MAG function retrieves the 343 mobility sessions, for that MN, from a centralized database. 344 This database is expected to be updated each time a new prefix is 345 allocated to the MN, and also when the prefix is released. 347 Even if the first option does not introduce a new piece of protocol, 348 it can be seen as a violation of the basic of the network based 349 mobility approach where the MN must remain agnostic of the mobility 350 support. So, this document only goes for the second option. 352 4. Solution Overview for network based DMM 354 4.1. Distributed and Dynamic Mobility Anchoring 356 The basic idea is to distribute mobility traffic management with 357 dynamic user's traffic anchoring in access network nodes. The 358 solution relies on a very simple flat architecture outlined in 359 Figure 3 where the Mobility capable Access Router (MAR) supports both 360 traffic anchoring and MN's location management functionalities. The 361 architecture relies on a centralized database storing ongoing 362 mobility sessions for the MNs (see Section 4.2 for details). This 363 database stores the HNPs currently allocated to the MN and their 364 respective anchoring point. This database is typically the PMIPv6 365 policy store [RFC5213]. However, the detailed specification of the 366 interaction between MAGs and this database is currently out of the 367 scope of this document. 369 +------------+ 370 | session DB | 371 / +------------+ 372 +----------/--------|------\--+ 373 ( IP /Network | \ ) 374 +--------/----------|------- \+ 375 / | \ 376 +-------+ +-------+ + ------+ 377 | MAR1 |___| MAR2 |____| MAR3 | 378 +-------+ +-------+ +-------+ 379 | 380 +-----+ 381 | MN1 | 382 +-----+ 384 Figure 3: Architecture for Distributed Mobility Anchoring 386 Regular IPv6 routing applies when an IP communication is initiated. 387 For instance, if the mobile node (e.g. MN1), being attached to MAR1, 388 initiates a communication: flow#1; the traffic will be routed through 389 MAR1 without requiring any specific mobility operation. When MN1 390 moves away from MAR1 and attaches to MAR2, the traffic remains 391 anchored to MAR1 and is tunnelled between MAR1 and MAR2. MAR1 392 becomes the mobility anchor, for IP sessions initiated by MN1 when it 393 was attached to MAR1, and MAR2 plays the role of MAG for these 394 sessions. 396 Communications newly initiated, e.g. flow#2, while the mobile node is 397 attached to MAR2 will be routed in a standard way via MAR2. But, if 398 the mobile node moves away from MAR2 (e.g. attaches to MAR3), while 399 maintaining both flow#1 and flow#2, two mobility anchors come into 400 play: flow#1 and flow#2 will be respectively anchored in MAR1 and 401 MAR2. 403 Summarizing , it is proposed to dynamically locate mobility anchoring 404 depending on where the flow is initially created. Accordingly, 405 communications are expected to be initiated without requiring 406 mobility anchoring and tunnelling. Note that, even if a mobile node 407 is moving across several MARs, the tunnel endpoints are always on the 408 initial H-MAR and on the current V-MAR. In the case the mobile node 409 moves from MAR1 to MAR2 then to MAR3, a tunnel will be firstly 410 established between MAR1 and MAR2; then the tunnel will be moved 411 between MAR1 and MAR3. 413 However such architecture leads to new requirement on the HNP prefix 414 model. Actually, because the HNP is anchored to its mobility anchor 415 (i.e. H-MAR), a dynamic mobility anchoring requires that each MAR 416 must advertise different per-MN prefixes set. 418 _______ _______ 419 | | | | 420 | CN1 | | CN2 | 421 |_______| |_______| 422 '. Flow#2 . 423 Flow#1 ' '. | Flow#3 424 ' '...'''''''''''''.... . 425 ..''' '. '''.. 426 .' ' '.IP network . '. 427 : ' '. | : 428 '..' +-------+ . ..' 429 '''... | | ....''' 430 ' | MAR2 | \ . 431 MAR1 Forwarding Table ' | | \ | 432 +=====================+ ' | |'. \ . 433 HNP-1::/64 -> MAR3 ' +-------+\'. \ | 434 +-------+ \ '+ ------+ 435 | | \ | | 436 | MAR1 |-----------------| MAR3 | 437 | |'''''''''''''''''| | 438 | |-----------------| | 439 +-------+ +-------+ 440 ' ' | 441 Flow#1 ' . . Flow#3 442 ' ' | 443 +-----+ Flow#2 +-----+ 444 | MN1 | -----move-------> | MN1 | 445 +-----+ +-----+ 446 (single interface, IF1) 448 Figure 4: Distributed Mobility Anchoring 450 4.2. Protocol sequence for handover management 452 Handover management for a single interface mobile node is depicted on 453 Figure 5 where the mobile node, MN1, is assumed to move from MAR1 to 454 MAR2. 456 MN1 MAR2 MAR1 CN1 CN2 457 | | | | | 458 | | | | | 459 L2 Attach | | | | 460 | | | | | 461 (1) |----------------RS---------->| | | 462 | | | MAR1 allocates | 463 | | | and advertises HNP1 464 | | | MAR1 updates MN's 465 | | | mobility session 466 |<---------------RA-----------| up to the database 467 | | | | | 468 comm. to CN1 using HNP1 | | | 469 (2) |<----------------data-flow#1--------->| | 470 | | | | | 471 handover | | | | 472 to MA2 | | | | 473 (3) |-----RS----->| MAR2 allocates| | | 474 | | HNP2 for new communications | 475 | | and retrieve the anchoring point 476 | | from the centralized database | 477 | |----pBU------->| | | 478 | | | | | 479 | |<---pBA--------| | | 480 (4) |<---RA-------| | | | 481 | | | | | 482 handover | | | | 483 completed | | | | 484 | | | | | 485 (5) |<---flow#1 --|<===tunnel====>|------->| | 486 | | | | | 487 comm. to CN2 using HNP2 | | | 488 | | | | | 489 (6) |<-----------------data-flow#2----------------->| 490 | | | | | 491 | | | | | 493 Figure 5: Handover management with Distributed Mobility Anchoring 495 Following are the main steps of the handover management process: 497 1. The mobile node, MN1, attaches to MAR1 which is responsible for 498 allocating the MN-HNP, e.g. HNP1 for MN1. 499 2. Hence, the mobile node can initiate and maintain data transport 500 sessions (with CN1 in the picture), using IP addresses derived 501 from HNP1, in a standard way while it remains attached to MAR1, 502 i.e. mobility functions do not come into play. 503 3. The MN attaches to MAR2 which will thus acts as V-MAR for HNP1. 504 Firstly, MAR2 retrieves the ongoing MN's mobility sessions from 505 the centralized sessions database; here only one mobility session 506 is ongoing: (MN::HNP1,MAR1). Then MAR2 proceeds to location 507 update for HNP1 with MAR1, which plays the LMA role, i.e., PBU/ 508 PBA exchange between MAR2 and MAR1. MAR2 also allocates new 509 prefix (HNP2) for MN1; this prefix is meant to be used by 510 application flows initiated after the handover. 511 4. In response to MN's router solicitation, MAR2 is expected to 512 advertise both HNP1 and HNP2 to the MN, for respectively, the IP 513 communications initiated when the MN was attached to MAR1 and the 514 IP communications which will be initiated while attached to MAR2. 515 An IP address derived from HNP1 must not be used for new IP 516 communications; so, prefix HNP1 is announced as deprecated. The 517 MN could also make the prefix selection relying on prefix 518 properties [I-D.korhonen-dmm-prefix-properties] if supported. 519 5. MAR1, playing the LMA role for HNP1, encapsulates MN1's traffic 520 and tunnels it to the V-MAR, i.e. MAR2, where packets are 521 decapsulated and delivered to the MN. 522 6. The mobile node initiates and maintains new data transport 523 sessions, e.g. with CN2, using IP addresses derived from HNP2. 524 This traffic is routed in a standard way while the mobile node 525 remains attached to MAR2. 527 4.3. Multiple Interfaces support 529 The distribution of mobility functions can also apply in the context 530 of multiple-interfaces terminals. In such a case, any given IP flow 531 can be considered as implicitly anchored on the current host's access 532 router when set up. Until the host does not move from the initial 533 access router (H-MAR), the IP flow is delivered as for any standard 534 IPv6 node. The anchoring function at the H-MAR is thus managing 535 traffic indirection only if one, or several, IP flow(s) are moved to 536 another interface, and for subsequent movements while the initial 537 anchored flows remain active. This anchoring is performed on a per- 538 flow basis and each H-MAR needs to track all possible V-MARs for a 539 given host on the move. The H-MAR must also manage different tunnels 540 for a given mobile node providing that the node is multihomed and it 541 simultaneously processes different IP flows on its interfaces. 543 Lets consider a simple example to illustrate the dynamic per-flow 544 mobility anchoring. Figure 6 depicts the IP flow mobility management 545 for a mobile node with two interfaces. The IP data flows, Flow#1 and 546 Flow#2, have been initiated on if1. Thus, Flow#1 and Flow#2, using 547 respectively prefixes HNP1 and HNP2, are anchored to MAR1. Referring 548 to the picture, Flow#1 has not been moved; so Flow#1 is delivered in 549 a standard IPv6 way. Flow#2 has been transferred from If1 to If2, so 550 Flow#2 packets, corresponding to HNP2, are tunnelled from MAR1 to 551 MAR2. In other words, MAR1 and MAR2 are respectively the H-MAR 552 anchor and the V-MAR for flow#2. 554 _______ _______ 555 | | | | 556 | CN1 | | CN2 | 557 |_______| |_______| 558 ' . 559 Flow#1 ' | Flow#2 560 ' ...'''''''''''''.... . 561 ..''' '''.. 562 .' ' IP network . '. 563 : ' | : 564 '..' . ..' 565 '''.....................'|' 566 ' . 567 ' | 568 ' .- . - . - . - . - . - . 569 ' | 570 +-------+ Flow#2 + ------+ 571 | | tunneled | | 572 | MAR1 |-----------------| MAR2 | 573 |(H-MAR)| -.-.-.-.-.-.-.-.|(V-MAR)| 574 | |-----------------| | 575 +-------+ +----|--+ 576 ' . 577 Flow#1 ' | Flow#2 578 ' . 579 ' If1 +-----+ If2 | 580 ''''''''''| MN | - . - . 581 +-----+ 583 Figure 6: Distributed IF flow Mobility Anchoring 585 In case of the handover of an IP flow between interfaces, the mobile 586 node must rely on the logical interface support, as per 587 [I-D.ietf-netext-logical-interface-support]. 589 5. Difference with Proxy Mobile IPv6 591 The DMM solution that described in this document can be implemented 592 with current Proxy Mobile IPv6 protocol [RFC5213]; neither protocol 593 operations nor messages semantic are changed. The session database, 594 used in this document, is a remote policy store, as defined in 595 [RFC5213]. However, in [RFC5213], the mobile node's IPv6 home 596 network prefix(es) assigned to the mobile node is an optional field 597 of the policy store; now, with distribution of mobility anchors, this 598 field becomes mandatory. 600 So, the mandatory fields of the policy profile are now: 602 o The mobile node's identifier (MN-Identifier) 603 o The IPv6 address of the local mobility anchor (LMAA) 604 o The mobile node's IPv6 home network prefix(es) assigned to the 605 mobile node's connected interface. 607 6. Security Considerations 609 TBD. 611 7. IANA Considerations 613 This document has no actions for IANA. 615 8. Acknowledgements 617 The authors would also like to express their gratitude to Hidetoshi 618 Yokota, Telemaco Melia, Dapeng Liu, Anthony Chan, Julien Laganier, 619 Lucian Suciu and many others for having shared thoughts on the 620 concept of distributed mobility. 622 This document inherits from concepts introduced in [NTMS2008], co- 623 signed by Philippe Bertin, Servane Bonjour, Jean-Marie Bonnin, Karine 624 Guillouard. 626 9. References 627 9.1. Normative References 629 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 630 in IPv6", RFC 3775, June 2004. 632 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 633 Address Autoconfiguration", RFC 4862, September 2007. 635 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 636 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 638 9.2. Informative References 640 [I-D.ietf-dmm-requirements] 641 Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 642 "Requirements for Distributed Mobility Management", 643 draft-ietf-dmm-requirements-14 (work in progress), 644 February 2014. 646 [I-D.ietf-netext-logical-interface-support] 647 Melia, T. and S. Gundavelli, "Logical Interface Support 648 for multi-mode IP Hosts", 649 draft-ietf-netext-logical-interface-support-08 (work in 650 progress), October 2013. 652 [I-D.korhonen-dmm-prefix-properties] 653 Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. 654 Liu, "IPv6 Prefix Mobility Management Properties", 655 draft-korhonen-dmm-prefix-properties-03 (work in 656 progress), October 2012. 658 [I-D.yokota-dmm-scenario] 659 Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case 660 scenarios for Distributed Mobility Management", 661 draft-yokota-dmm-scenario-00 (work in progress), 662 October 2010. 664 [NTMS2008] 665 Bertin, P., "A Distributed Dynamic Mobility Management 666 Scheme designed for Flat IP Architectures.", NTMS'2008 , 667 November 2008. 669 Authors' Addresses 671 Pierrick Seite 672 France Telecom - Orange 673 4, rue du Clos Courtel, BP 91226 674 Cesson-Sevigne 35512 675 France 677 Email: pierrick.seite@orange.com 679 Philippe Bertin 680 France Telecom - Orange 681 4, rue du Clos Courtel, BP 91226 682 Cesson-Sevigne 35512 683 France 685 Email: philippe.bertin@orange.com 687 Jong-Hyouk Lee 688 Telecom Bretagne 689 2, rue de la Chataigneraie 690 Cesson-Sevigne 35512 691 France 693 Email: jh.lee@telecom-bretagne.eu