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