idnits 2.17.1 draft-seite-dmm-dma-01.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 12, 2012) is 4306 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 13, 2013 July 12, 2012 7 Distributed Mobility Anchoring 8 draft-seite-dmm-dma-01.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 13, 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 implicitely considers the previous access router as 265 the HA for IP addresses allocated by this access router. Then, the 266 MN can perform the binding update to the previous access router for 267 IP session initiated on it. So, MN's current traffic remains 268 attached to the previous access router which is responsible for 269 forwarding the 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 remain 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 If MN starts a new IP communication, flow#2, while attached to AR2; 278 flow#2 is routed in a standard way as long as the MN remains attached 279 to AR2. Then, if the MN moves to another access router, flow#1 and 280 flow#2 will be respectively anchored to AR1/HA and AR2/HA. 282 +---+ +---+ 283 |CN1| |CN2| 284 +---+ +--,+ 285 _.- +----------. \ 286 ,' | `---'-. 287 ,-' |flow#1 \ `-. 288 ,' | ' `. 289 ( | IP Network \ 290 `. | ' ,' 291 `-. ; ,\' 292 \_ ; _.----' ' 293 - +----------'' | 294 | ' 295 +---:---+ +-------+ 296 | AR1`--|------------| AR2 | 297 | HA |------------|HA | 298 +-------+ +-------+ 299 flow#1 \\ \ flow#2 300 tunnelled \\ ' 301 +-----+ +--\--+ 302 | MN | ----move-------> | MN | 303 +-----+ +-----+ 305 Figure 2: Distributed Client Based Mobility 307 3.3. Considerations on Network based mobility management 309 It is also possible to go for DMM with Proxy Mobile IPv6 [RFC3775]. 310 For example, mobility functions, i.e. MAG and LMA, can be co-located 311 with the access routers. The anchoring behavior might be similar to 312 the client based solution, however there is an issue with the binding 313 update management. In a network based solution, the MN is not 314 supposed to participate to mobility signaling and the MAG is expected 315 to know the mobility anchor serving the MN. This problem can be 316 tricky in a distributed mobility architecture because 1) the MN can 317 be served by more than one LMA (see fundamentals in Section 3.1) and 318 2) the mobility anchor depends on point of attachment when the IP 319 communication has been initiated. There are basically two ways to 320 address the issue without modifying proxy mobile IP: 322 1. Involve the MN in the mobility management process: during the 323 attachment process to a new access router, the MN could 324 communicate its ongoing mobility sessions (i.e. list of current 325 HNP with associated mobility anchors) to the MAG. For example, 326 this information could be provided in a dedicated router 327 solicitation option. 328 2. Rely on centralized part of the control plane: when the MN 329 attaches to a new access router, the MAG function retrieve the 330 mobility sessions, for that MN, from a centralized database. 331 This database is expected to be updated each time a new prefix is 332 allocated to the MN, and also when the prefix is released. 334 Even if the first option does not introduce a new piece of protocol, 335 it can be seen as a violation of the basic of the network based 336 mobility approach where the MN must remain agnostic of the mobility 337 support. So, in the following, we will go for the second option. 339 4. Solution Overview for network based DMM 341 4.1. Dynamic Mobility Anchoring 343 The basic idea is to distribute mobility traffic management with 344 dynamic user's traffic anchoring in access network nodes. The 345 solution relies on a very simple flat architecture outlined in 346 Figure 3 where the Mobility capable Access Router (MAR) supports both 347 traffic anchoring and MN's location management functionalities. The 348 architecture relies on a centralized database storing ongoing 349 mobility sessions for the MNs (see Section 4.2 for details). This 350 database stores the HNPs currently allocated to the MN and their 351 respective anchoring point. This database could be an extension to 352 the policy store used in [RFC5213]; however, the detailed 353 specification of the interaction between MAGs and this database is 354 currenly out of the scope of this document. 356 +------------+ 357 | session DB | 358 / +------------+ 359 +----------/--------|------\--+ 360 ( IP /Network | \ ) 361 +--------/----------|------- \+ 362 / | \ 363 +-------+ +-------+ + ------+ 364 | MAR1 |___| MAR2 |____| MAR3 | 365 +-------+ +-------+ +-------+ 366 | 367 +-----+ 368 | MN1 | 369 +-----+ 371 Figure 3: Architecture for Distributed Mobility Anchoring 373 Regular IPv6 routing applies when an IP communication is initiated. 374 For instance, if the mobile node (e.g. MN1), being attached to MAR1, 375 initiates a communication with CN1, the traffic will be routed 376 through MAR1 without requiring any specific mobility operation. When 377 MN1 moves away from MAR1 and attaches to MAR3, the traffic remains 378 anchored to MAR1 and is tunneled between MAR1 and MAR3. MAR1 becomes 379 the mobility anchor, but only for traffic initiated by MN1 when it 380 was attached to MAR1. 382 Communications newly initiated, e.g. to CN2, while the mobile node is 383 attached to MAR3 will be routed in a standard way via MAR3. So, MAR3 384 is both the mobility anchor, i.e. the H-MAR, for traffic newly 385 initiated (i.e. when the mobile node is attached to MAR3) and the 386 V-MAR for traffic initiated while being attached to MAR1. If the 387 mobile node moves away from MAR3, while maintaining communications 388 with both CN1 and CN2, two mobility anchors come into play: the data 389 traffic will be anchored in MAR1 for communication with CN1 and in 390 MAR3 for communication with CN2. Summarizing , it is proposed to 391 locate mobility anchoring depending on where the flow is initially 392 created. Accordingly, communications are expected to be initiated 393 without requiring mobility anchoring and tunneling. 395 With this solution, even if a mobile node is moving across several 396 MARs, the tunnel endpoints are always on the initial H-MAR and on the 397 current V-MAR. In the case the mobile node moves from MAR1 to MAR2 398 then to MAR3, a tunnel will be firstly established between MAR1 and 399 MAR2 to forward HNP1; then a tunnel between MAR1 and MAR3 will be 400 established. 402 However such an architecture leads to new requirement on the HNP 403 prefix model. Actually, because the HNP is anchored to its mobility 404 anchor (i.e. H-MAR), a dynamic mobility anchoring requires that each 405 MAR must advertise different per-MN prefixes set. For example, if 406 MN1 is anchored to both MAR1 and MAR3, these two mobility capable 407 access routers would advertise respectively HNP1 and HNP3 for MN1. 409 _______ _______ 410 | | | | 411 | CN1 | | CN2 | 412 |_______| |_______| 413 '. Flow#2 . 414 Flow#1 ' '. | Flow#3 415 ' '...'''''''''''''.... . 416 ..''' '. '''.. 417 .' ' '.IP network . '. 418 : ' '. | : 419 '..' +-------+ . ..' 420 '''... | | ....''' 421 ' | MAR2 | \ . 422 MAR1 Forwarding Table ' | | \ | 423 +=====================+ ' | |'. \ . 424 HNP-1::/64 -> MAR3 ' +-------+\'. \ | 425 +-------+ \ '+ ------+ 426 | | \ | | 427 | MAR1 |-----------------| MAR3 | 428 | |'''''''''''''''''| | 429 | |-----------------| | 430 +-------+ +-------+ 431 ' ' | 432 Flow#1 ' . . Flow#3 433 ' ' | 434 +-----+ Flow#2 +-----+ 435 | MN1 | -----move-------> | MN1 | 436 +-----+ +-----+ 437 (single interface, IF1) 439 Figure 4: Distributed Mobility Anchoring 441 4.2. Protocol sequence for handover management 443 Handover management for a single interface mobile node is depicted on 444 Figure 5 where the mobile node, MN1, is assumed to move from MAR1 to 445 MAR2. 447 MN1 MAR2 MAR1 CN1 CN2 448 | | | | | 449 | | | | | 450 L2 Attach | | | | 451 | | | | | 452 (1) |----------------RS---------->| | | 453 | | | MAR1 allocates | 454 | | | and advertises HNP1 455 | | | MAR1 updates MN's 456 | | | mobility session 457 |<---------------RA-----------| up to the database 458 | | | | | 459 comm. to CN1 using HNP1 | | | 460 (2) |<----------------data-flow#1--------->| | 461 | | | | | 462 handover | | | | 463 to MA2 | | | | 464 (3) |-----RS----->| MAR2 allocates| | | 465 | | HNP2 for new communications | 466 | | and retrieve the anchoring point 467 | | from the centralized database | 468 | |----pBU------->| | | 469 | | | | | 470 | |<---pBA--------| | | 471 (4) |<---RA-------| | | | 472 | | | | | 473 handover | | | | 474 completed | | | | 475 | | | | | 476 (5) |<---flow#1 --|<===tunnel====>|------->| | 477 | | | | | 478 comm. to CN2 using HNP2 | | | 479 | | | | | 480 (6) |<-----------------data-flow#2----------------->| 481 | | | | | 482 | | | | | 484 Figure 5: Handover management with Distributed Mobility Anchoring 486 Following are the main steps of the handover management process: 488 1. The mobile node, MN1, attaches to MAR1 which is responsible for 489 allocating the MN-HNP, e.g. HNP1 for MN1. 490 2. Hence, the mobile node can initiate and maintain data transport 491 sessions (with CN1 in the picture), using IP addresses derived 492 from HNP1, in a standard way while it remains attached to MAR1, 493 i.e. mobility functions do not come into play. 494 3. The MN attaches to MAR2 which will thus acts as V-MAR for HNP1. 495 Fistly, MAR2 retrieves the ongoing MN's mobility sessions from 496 the centralized sessions database; here only one mobility session 497 is ongoing: (MN::HNP1,MAR1). Then MAR2 proceeds to location 498 update for HNP1 with MAR1, which plays the LMA role, i.e., PBU/ 499 PBA exchange between MAR2 and MAR1. MAR2 also allocates new 500 prefix (HNP2) for MN1; this prefix is meant to be used by 501 application flows initiated after the handover. 502 4. In response to MN's router solicitation, MAR2 is expected to 503 advertise both HNP1 and HNP2 to the MN, for respectively, the IP 504 communications initiated when the MN was attached to MAR1 and the 505 IP communications which will be initiated while attached to MAR2. 506 An IP address derived from HNP1 must not be used for new IP 507 communications; so, prefix HNP1 is announced as deprecated. The 508 MN could also make the prefix selection relying on prefix 509 properties [I-D.korhonen-dmm-prefix-properties] if supported. 510 5. MAR1, playing the LMA role for HNP1, encapsulates MN1's traffic 511 and tunnels it to the V-MAR, i.e. MAR2, where packets are 512 decapsulated and delivered to the MN. 513 6. The mobile node initiates and maintains new data transport 514 sessions, e.g. with CN2, using IP addresses derived from HNP2. 515 This traffic is routed in a standard way while the mobile node 516 remains attached to MAR2. 518 4.3. Multiple Interfaces support 520 The distribution of mobility functions can also apply in the context 521 of multiple-interfaces terminals. In such a case, any given IP flow 522 can be considered as implicitly anchored on the current host's access 523 router when set up. Until the host does not move from the initial 524 access router (H-MAR), the IP flow is delivered as for any standard 525 IPv6 node. The anchoring function at the H-MAR is thus managing 526 traffic indirection only if one, or several, IP flow(s) are moved to 527 another interface, and for subsequent movements while the initial 528 anchored flows remain active. This anchoring is performed on a per- 529 flow basis and each H-MAR needs to track all possible V-MARs for a 530 given host on the move. The H-MAR must also manage different tunnels 531 for a given mobile node providing that the node is multihomed and it 532 simultaneously processes different IP flows on its interfaces. 534 Lets consider a simple example to illustrate the dynamic per-flow 535 mobility anchoring. Figure 6 depicts the IP flow mobility management 536 for a mobile node with two interfaces. The IP data flows, Flow#1 and 537 Flow#2, have been initiated on if1. Thus, Flow#1 and Flow#2, using 538 respecively prefixes HNP1 and HNP2, are anchored to MAR1. Referring 539 to the picture, Flow#1 has not been moved; so Flow#1 is delivered in 540 a standard IPv6 way. Flow#2 has been transferred from If1 to If2, so 541 Flow#2 packets, corresponding to HNP2, are tunneled from MAR1 to 542 MAR2. In other words, MAR1 and MAR2 are respectively the H-MAR 543 anchor and the V-MAR for flow#2. 545 _______ _______ 546 | | | | 547 | CN1 | | CN2 | 548 |_______| |_______| 549 ' . 550 Flow#1 ' | Flow#2 551 ' ...'''''''''''''.... . 552 ..''' '''.. 553 .' ' IP network . '. 554 : ' | : 555 '..' . ..' 556 '''.....................'|' 557 ' . 558 ' | 559 ' .- . - . - . - . - . - . 560 ' | 561 +-------+ Flow#2 + ------+ 562 | | tunneled | | 563 | MAR1 |-----------------| MAR2 | 564 |(H-MAR)| -.-.-.-.-.-.-.-.|(V-MAR)| 565 | |-----------------| | 566 +-------+ +----|--+ 567 ' . 568 Flow#1 ' | Flow#2 569 ' . 570 ' If1 +-----+ If2 | 571 ''''''''''| MN | - . - . 572 +-----+ 574 Figure 6: Distributed IF flow Mobility Anchoring 576 In case of the handover of an IP flow between interfaces, the mobile 577 node must rely on the logical interface support, as per 578 [I-D.ietf-netext-logical-interface-support]. 580 5. Security Considerations 582 TBD. 584 6. IANA Considerations 586 This document has no actions for IANA. 588 7. Acknowledgements 590 The authors would also like to express their gratitude to Hidetoshi 591 Yokota, Telemaco Melia, Dapeng Liu, Anthony Chan, Julien Laganier, 592 Lucian Suciu and many others for having shared thoughts on the 593 concept of distributed mobility. 595 This document inherits from concepts introduced in [NTMS2008], co- 596 signed by Philippe Bertin, Servane Bonjour, Jean-Marie Bonnin, Karine 597 Guillouard. 599 8. References 601 8.1. Normative References 603 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 604 in IPv6", RFC 3775, June 2004. 606 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 607 Address Autoconfiguration", RFC 4862, September 2007. 609 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 610 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 612 8.2. Informative References 614 [I-D.ietf-dmm-requirements] 615 Chan, A., "Requirements of distributed mobility 616 management", draft-ietf-dmm-requirements-01 (work in 617 progress), July 2012. 619 [I-D.ietf-netext-logical-interface-support] 620 Melia, T. and S. Gundavelli, "Logical Interface Support 621 for multi-mode IP Hosts", 622 draft-ietf-netext-logical-interface-support-05 (work in 623 progress), April 2012. 625 [I-D.korhonen-dmm-prefix-properties] 626 Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. 627 Liu, "IPv6 Prefix Mobility Management Properties", 628 draft-korhonen-dmm-prefix-properties-02 (work in 629 progress), July 2012. 631 [I-D.yokota-dmm-scenario] 632 Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case 633 scenarios for Distributed Mobility Management", 634 draft-yokota-dmm-scenario-00 (work in progress), 635 October 2010. 637 [NTMS2008] 638 Bertin, P., "A Distributed Dynamic Mobility Management 639 Scheme designed for Flat IP Architectures.", NTMS'2008 , 640 November 2008. 642 Authors' Addresses 644 Pierrick Seite 645 France Telecom - Orange 646 4, rue du Clos Courtel, BP 91226 647 Cesson-Sevigne 35512 648 France 650 Email: pierrick.seite@orange.com 652 Philippe Bertin 653 France Telecom - Orange 654 4, rue du Clos Courtel, BP 91226 655 Cesson-Sevigne 35512 656 France 658 Email: philippe.bertin@orange.com