idnits 2.17.1 draft-ma-dmm-romip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 23, 2012) is 4444 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3775' is defined on line 729, but no explicit reference was found in the text == Unused Reference: 'I-D.chan-distributed-mobility-ps' is defined on line 748, but no explicit reference was found in the text == Unused Reference: 'RFC3588' is defined on line 757, but no explicit reference was found in the text == Unused Reference: 'RFC5779' is defined on line 760, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4140 (Obsoleted by RFC 5380) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Distributed Mobility Management(dmm) Zhengming Ma 3 Internet-Draft Xun Zhang 4 Intended status: Standards Track SUN YAT-SEN UNIVERSITY 5 Expires: August 26, 2012 February 23, 2012 7 A Route Optimization solution support for Distributed Mobility 8 Management 9 draft-ma-dmm-romip-00.txt 11 Abstract 13 The mobile users and their traffic demands are expected to be ever- 14 increasing in future years, and this growth will impose a limitation 15 for deploying current mobility management schemes that are 16 intrinsically centralized, e.g., Mobile IPv6 and Proxy MIPv6. This 17 evolution in user traffic demand can be tackled by a different 18 approach for IP mobility, called Distributed Mobility Management, 19 which is focusing on moving the mobility anchors from the core 20 network and pushing them closer to the users, at the edge of the 21 network. Following this idea, in our proposal, the central anchor is 22 being deployed in the access router of the mobile node(MN). That is, 23 the first elements that provide IP connectivity to a set of MNs are 24 also the mobility managers for those MNs. In the following, we will 25 call MAAR (Mobility anchor and Access Router). 27 This draft strictly abides by the three principles: 29 (1) The MN doesn't participate in any mobility-related signaling.MAAR 30 and AAA are responsible for managing IP mobility on behalf of the 31 host. 33 (2) The MN's movement is transparent to the communication node 34 (CN).The Home Address (HoA) and Care-of address (CoA) are not for 35 users but for specific sessions in this draft.A MN initiates a 36 session by using the MN's address assigned by a MAAR which the MN is 37 registered as the HoA for this session.The MN's address assigned by a 38 new MAAR which the MN moves to its access link as the CoA for the 39 session. 41 (3) The MN can directly forward packages to the CN and the packages 42 don't need to pass the home mobility anchor. It can reduce the heavy 43 burdens on home mobility anchor and maintain all the continuity of 44 the conversation. 46 Status of this Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on August 26, 2012. 63 Copyright Notice 65 Copyright (c) 2012 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 2. Conventions used in this document . . . . . . . . . . . . . . 5 82 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 83 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 84 3. MAAR Operation . . . . . . . . . . . . . . . . . . . . . . . . 6 85 3.1. Operation between MAAR and AAA . . . . . . . . . . . . . . 6 86 3.2. The assumptions about a session . . . . . . . . . . . . . 6 87 3.3. Binding list in MAAR . . . . . . . . . . . . . . . . . . . 7 88 3.4. Operation between MAARs . . . . . . . . . . . . . . . . . 7 89 4. Description of the solution . . . . . . . . . . . . . . . . . 8 90 5. Forwarding Considerations . . . . . . . . . . . . . . . . . . 10 91 5.1. Forwarding Packets Sent by the Mobile Node . . . . . . . . 10 92 5.2. Forwarding Packets to the Mobile Node . . . . . . . . . . 12 93 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 94 6.1. sDBU . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 6.2. sDBA . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 6.3. dDBU . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 6.4. dDBA . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 101 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 102 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 105 1. Introduction 107 Mobile IPv6 [RFC6275] requires client functionality in the IPv6 stack 108 of a mobile node. Exchange of signaling messages between the mobile 109 node and home agent enables the creation and maintenance of a binding 110 between the mobile node's home address and its care-of address. 111 Mobility as specified in requires the IP host to send IP mobility 112 management signaling messages to the home agent, which is located in 113 the network. 115 Proxy Mobile IPv6 [RFC5213] is a network-based mobility to solving 116 the IP mobility challenge. It is possible to support mobility for 117 IPv6 nodes without host involvement by extending Mobile IPv6 118 signaling messages between a network node and a home agent. In order 119 to facilitate such network-based mobility, the PMIPv6 protocol 120 defines a Mobile Access Gateway (MAG), which acts as a proxy for the 121 Mobile IPv6 signaling, and the Local Mobility Anchor (LMA) which acts 122 similar to a Home Agent. The LMA and the MAG establish a 123 bidirectional tunnel for forwarding all data traffic belonging to the 124 Mobile Nodes. 126 Both the Mobile IPv6 and Proxy Mobile IPv6 offer mobility support at 127 the cost of handling operations at a cardinal point, the mobility 128 anchor, and burdening it with data forwarding and control mechanisms 129 for a great amount of users. As stated in [I-D.chan-distributed- 130 mobility-ps], centralized mobility solutions are prone to several 131 problems and limitations: longer (sub-optimal) routing paths, 132 scalability problems, signaling overhead (and most likely a longer 133 associated handover latency), more complex network deployment, higher 134 vulnerability due to the existence of a potential single point of 135 failure, and lack of granularity on the mobility management service 136 (i.e., mobility is offered on a per-node basis, not being possible to 137 define finer granularity policies, as for example per-application). 139 In the paper "A Network-based Localized Mobility Solution for 140 Distributed Mobility Management" [Net-basedDMM], the authors describe 141 two approaches: one is fully distributed approach and another is 142 partially distributed approach. The main issue in the first one is 143 how a Mobility Anchor and Access Router (MAAR) can differentiate 144 between the first attachment to the network and subsequent handovers. 146 This document describes MAAR and AAA supporting for managing IP 147 mobility on behalf of the host. This solution not only can settle 148 the issue that mobility entities can differentiate between the first 149 attachment to the network and subsequent handovers, but also reduce 150 the heavy burdens on home mobility anchor. The MN can directly 151 forward packages to the CN. The packages don't need to pass the home 152 mobility anchor. This document strictly abides by the two 153 principles. The first one is that the MN's movement is transparent 154 to CN. Another one is the MN doesn't participate in any mobility- 155 related signaling. 157 2. Conventions used in this document 159 2.1. Requirements 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 162 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 163 this document are to be interpreted as described in [RFC2119]. 165 2.2. Terminology 167 The document also uses the terminology define in [RFC6275].The 168 following terminology is also used: 170 MAAR (Mobility anchor and Access Router). First hop routers where 171 the mobile nodes attach to. They can play the role of mobility 172 managers for the IPv6 prefixes they anchor, or can for the IPv6 173 addresses they anchor. In this draft, MAAR assigns the IPv6 address 174 for each currently registered MN. So that MAAR can performs mobility 175 management on behalf of a mobile node. Every MAAR is responsible for 176 detecting the mobile node's movements to and from the access link and 177 for initiating binding registrations. 179 AAA (Authentication, Authorization and Accounting ). AAA server 180 records the user's static and dynamic information. The dynamic 181 information includes the address information of MAAR which the MN is 182 registered right now. 184 DBU/DBA (Distributed BU/BA). A MAAR sends the DBU/DBA message to 185 another MAAR for establishing or updating corresponding binding list. 186 In this draft, we have two kinds of the DBU/DBA message. One is the 187 sDBU/sDBA message and another is the dDBU/dDBA message. 189 sDBU/sDBA. The MAAR attached by the MN currently to sends a sDBU 190 message to the MAAR attached by MN before the MN's movement. After 191 that, the MAAR attached by MN currently receives a sDBA message 192 including the address of CN's MAAR which the CN is currently attached 193 to. After that, the MAAR attached by the MN currently updates its 194 internal binding list. 196 dDBU/dDBA. The MAAR attached by the MN currently sends a dDBU 197 message to the MAAR attached by CN for refreshing the internal 198 binding list of the CN's MAAR which the CN is currently attached to. 199 After receiving the dDBU message, the CN's MAAR replies a dDBA 200 message to the MN's MAAR. 202 3. MAAR Operation 204 In this draft, the packages sent by the MN or the CN don't need to go 205 by the home mobility anchor. In this solution, both of MN and CN 206 move to the MAARs' access links and get the corresponding addresses 207 assigned by corresponding MAARs. For example, a user A (this user A 208 can be thought as a MN) attaches to the A_MAAR1's access link, and 209 establishes the first communication with a user B (this user B can be 210 thought as a CN). At same time, the user B attaches to the B_MAAR1's 211 access link. After that, both the user A and B move and respectively 212 attach to the A_MAAR2's access link and the B_MAAR2's access link. 213 In this solution, the packages sent by the MN or the CN don't need to 214 pass the A_MAAR1 and the B_MAAR1.This section describes the 215 operational details. 217 3.1. Operation between MAAR and AAA 219 MAAR MUST send a diameter request message to the AAA when detects the 220 MN's movement to its access link. After receiving the message, the 221 AAA checks the dynamic information by using the MN's ID. If the AAA 222 finds the address information of the MAAR which attached by the MN 223 before its movement, then the AAA sends a diameter response message 224 with the address of the MAAR attached by the MN before its movement. 225 If the AAA can't find this information, then the MAAR receives the 226 diameter response message with the zero address. After that, the 227 MAAR will differentiate between the first attachment to the network 228 and subsequent handovers. Sending out the diameter response message, 229 the AAA MUST update the dynamic information including the address 230 information of MAAR which the MN is currently attached to. 232 3.2. The assumptions about a session 234 The Home Address (HoA) and Care-of address (CoA) is not for users but 235 also for specific sessions. For a user initiating a session or 236 accepting a session, no matter how it moves, the HoA for the session 237 is unchanged, while the CoA for the session is changed. 239 The MN (the user A) initiates a session with the CN (the user B) by 240 using the address (A_HoA1) assigned by A_MAAR1 which the user A is 241 registered as the HoA for the session. The user B accepts this 242 session by using the address (B_HoA1) assigned by B_MAAR1 which the 243 user B is registered as the HoA for this session. 245 When the user A moves from its current access link, it associates to 246 a new MAAR (A_MAAR2) which delegates another IPv6 address (A_HoA2). 248 The A_HoA2 can be both thought as a CoA of the user A and a CoA of 249 the session. If the user A sends packages to the user B, the source 250 address must be A_HoA1, and the destination address must be 251 B_HoA1.The user A can initiate a new session with a new CN (for 252 example a user C) by using A_HoA2 which the user A can be registered 253 as the HoA for the new session. If the user A sends packages to the 254 user C, the source address must be A_HoA2. 256 When the user B moves from its current access link, it associates to 257 a new MAAR (B_MAAR2) which delegates another IPv6 address (B_HoA2). 258 The B_HoA2 can be both thought as a CoA of the user B and a CoA of 259 the session. If the user B sends packages to the user A, the source 260 address must be B_HoA1, and the destination address must be 261 A_HoA1.The user B can initiate a new session with a new MN (for 262 example a user D) by using the B_HoA2 which the user B can be 263 registered as the HoA for the new session. If the user B sends 264 packages to the user D, the source address must be B_HoA2. 266 3.3. Binding list in MAAR 268 Every MAAR must maintain two binding lists for each currently 269 registered mobile node. One is the internal binding list, and 270 another is the external binding list. The first one maintains a 271 binding of CN's HoA and the address of CN's MAAR. The CN's HoA is 272 the address which the CN accepting the session and registering as the 273 HoA of the session. The second one maintains a binding of MN's HoA 274 and MN's CoA. The MN's HoA is the address which the MN initiating 275 the session and registering as the HoA of the session. The MN's CoA 276 is assigned by the MAAR which the MN is currently attached to. The 277 external binding list is used to transmit packets to MN. The 278 internal binding list is used to transmit packets from MN. 280 For example, the A_MAAR2 of the user A stores two binding lists. One 281 is the internal binding list, and another is the external binding 282 list. The first list stores a binding of B_HoA1 and the address of 283 the MAAR attached by the user B currently. The second one stores a 284 binding of A_HoA1 and A_HoA2.The B_MAAR2 of the user B stores two 285 binding lists. One is the internal binding list, and another is the 286 external binding list. The first list stores a binding of A_HoA1 and 287 the address of the MAAR which the user A is currently attached to. 288 The second one stores a binding of B_HoA1 and B_HoA2. 290 3.4. Operation between MAARs 292 If the MAAR which the MN is currently attached to learns that the MN 293 is the handover attachment, the MAAR will send a sDBU message to the 294 MAAR attached by the MN before its movement. The address information 295 of the MAAR attached by the MN before its movement is included in the 296 diameter response message. At this time, the MAAR attached by the MN 297 before its movement has two binding lists. One is the internal 298 binding list, and another is the external binding list. After 299 receiving the sDBU message, the MAAR searches the internal binding 300 list by using the CN's HoA and gets the address of the MAAR which the 301 CN is currently attached to. After that, the MAAR attached by the MN 302 before its movement will send a sDBA message including the MN's HoA, 303 the CN's HoA and the address of the MAAR which the CN is currently 304 attached to. 306 If the MAAR which the MN is currently attached to receives the sDBA 307 message, the MAAR sends a dDBU message to the MAAR attached by the CN 308 currently including the address of the MAAR attached by the MN 309 currently. After receiving the dDBU message, the MAAR attached by 310 the CN currently refreshes the internal binding list. The MN's MAAR 311 and the CN's MAAR establish a bidirectional tunnel for forwarding all 312 data traffic belonging to the MN. 314 4. Description of the solution 316 The purpose of Distributed Mobility Management approaches is to 317 overcome the limitations of the traditional centralized mobility 318 management by bringing the mobility anchor closer to the MN. 319 Following this idea, in our proposal, the central anchor is moved to 320 the edge of the network, being deployed in the access router of the 321 mobile node. That is, the first elements that provide IP 322 connectivity to a set of MNs are also the mobility managers for those 323 MNs. In the following, we will call MAAR (Mobility anchor and Access 324 Router). 326 Upon the user A attaches to a MAAR, say A_MAAR1, the user A 327 establishes the first communication with the user B. At the same 328 time, the user B attaches to a MAAR, say B_MAAR1.After that, the user 329 A moves from its current access and is now attached to A_MAAR2. The 330 user B moves from its current access and is now attached to 331 B_MAAR2.A_HoA1 is the address of the user A assigned by A_MAAR1. 332 A_HoA2 is the address of the user A assigned by A_MAAR2. B_HoA1 is 333 the address of the user B assigned by B_MAAR1. B_HoA2 is the address 334 of the user B assigned by B_MAAR2.When the user A moves from its 335 current access, it associates to A_MAAR3 which delegates another IPv6 336 address (A_HoA3). Figure 1 illustrates this scenario. 338 +----------+ +----------+ +-------+ +-------+ +-------+ +-----+ 339 |The user A| |The user B| |A_MAAR2| |B_MAAR2| |A_MAAR3| | AAA | 340 +----------+ +----------+ +-------+ +-------+ +-------+ +-----+ 341 | | | | | | 342 |--------------1.RS(A_HoA1,B_HoA1)-------------->| | 343 | | | | |-2.request-->| 344 | | | | |<-3.response-| 345 |<-------------------4.RA(A_HoA3) ---------------| | 346 | | | | | | 347 | | |<-------5.sDBU -------| | 348 | | |------6. sDBA ------->| | 349 | | | |<-7.dDBU --| | 350 | | | |--8.dDBA ->| | 351 | | | | | | 353 Figure 1:Signaling of MN handover 355 (1) The user A sends a RS message to A_MAAR3 including A_HoA1 and 356 B_HoA1; 358 (2) A_MAAR3 sends a diameter request message to the AAA. 360 (3) The AAA searches the dynamic information by using the ID of the 361 user A for getting the address of A_MAAR2. Then the AAA sends a 362 diameter response message including the address of A_MAAR2, and 363 updates the dynamic information of the user A including the address 364 information of A_MAAR3 at same time. 366 (4) A_MAAR3 delegates another IPv6 address (A_HoA3) to the user A. At 367 the same time, A_MAAR3 establishes and maintains the external binding 368 list which stores a binding of A_HoA1 and A_HoA3.Then A_MAAR3 sends a 369 RA message to the user A including A_HoA3; 371 (5) A_MAAR3 sends a sDBU message to A_MAAR2 including B_HoA1; 373 (6) Now A_MAAR2 has two binding lists. One is the internal binding 374 list, and another is the external binding list. The first one 375 maintains a binding of B_HoA1 and the address of B_MAAR2.The second 376 one maintains a binding of A_HoA1 and A_HoA2. After receiving the 377 sDBU message, A_MAAR2 searches the internal binding list by using the 378 B_HoA1 for getting the address of B_MAAR2.Then A_MAAR2 sends a sDBA 379 message including B_HoA1 and the address of B_MAAR2.After that, 380 A_MAAR2 releases this two binding lists; 382 (7) After receiving the sDBA message, A_MAAR3 establishes and 383 maintains the internal binding list which maintains a binding of 384 B_HoA1 and the address of B_MAAR2. Then A_MAAR3 sends a dDBU message 385 to B_MAAR2 including the address of A_MAAR3 and A_HoA1; 387 (8) After receiving the dDBU message, B_MAAR2 replies a dDBA message 388 and updates the internal binding list which maintains a binding of 389 A_HoA1 and the address of A_MAAR2.After that, this list maintains a 390 binding of A_HoA1 and the address of A_MAAR3. 392 5. Forwarding Considerations 394 5.1. Forwarding Packets Sent by the Mobile Node 396 After receiving the packages sent by the MN, the MAAR will search the 397 internal binding list by using the destination address of the 398 packages for getting the address of the MAAR which the CN is 399 currently attached to. Then, the MAAR encapsulates the packages and 400 routes the packages to the corresponding MAAR attached by the CN 401 currently. 403 After receiving the packages, the corresponding MAAR will do three 404 things. Firstly, the corresponding MAAR will remove the tunnel head. 405 Secondly, the corresponding MAAR will check whether the destination 406 address of the packages is assigned by this corresponding MAAR or 407 not. If the destination address of the packages is assigned by this 408 corresponding MAAR, the corresponding MAAR will route the packages to 409 the corresponding CN directly. If the destination address of the 410 packages is not assigned by this corresponding MAAR, the 411 corresponding MAAR will search the external binding list by using the 412 destination address of the packages for getting the CoA of the 413 corresponding CN. Finally, the corresponding MAAR will route the 414 packages to the corresponding CN. Figure 2 illustrates the 415 transmission of data packets. 417 ________ ________ 418 |The user| |The user| 419 | B |----------move--------->| B | 420 |________| |________| 421 # * 422 # * 423 # * 424 +-------+ +-------+ 425 | | | | 426 |B_MAAR1| |B_MAAR2| 427 | | / | | 428 +-------+ / +-------+ 429 / # /| * | 430 / # / | * | 431 / # / | * | 432 / # / | * | 433 / # / | * | 434 / # / | * | 435 +-------+ +-------+ # / +-------+ 436 | | | | / | | 437 |A_MAAR1| |A_MAAR2| / |A_MAAR3| 438 | | | | | | 439 +-------+ +-------+ +-------+ 440 # * 441 # * 442 # * 443 ________ ________ ________ 444 |The user| |The user| |The user| 445 | A |-move->| A |---move--->| A | 446 |________| |________| |________| 448 Figure 2:The transmission of data packets 450 Upon the user A attaches to a MAAR, say A_MAAR1, the user A 451 establishes the first communication with the user B. At the same 452 time, the user B attaches to a MAAR, say B_MAAR1.After that, the user 453 A moves from its current access and is now attached to A_MAAR2. The 454 user B moves from its current access and is now attached to 455 B_MAAR2.A_HoA1 is the address of the user A assigned by A_MAAR1. 456 A_HoA2 is the address of the user A assigned by A_MAAR2. B_HoA1 is 457 the address of the user B assigned by B_MAAR1. B_HoA2 is the address 458 of the user B assigned by B_MAAR2.When the MN moves from its current 459 access link, it associates to A_MAAR3 which delegates another IPv6 460 address (A_HoA3). 462 At this time, the A_MAAR3 of the user A stores two binding lists. 463 One is the internal binding list, and another is the external binding 464 list. The first list maintains a binding of B_HoA1 and the address 465 of B_MAAR2. The second one maintains a binding of A_HoA1 and A_HoA3. 466 The B_MAAR2 of the user B stores two binding lists. One is the 467 internal binding list, and another is the external binding list. The 468 first list maintains a binding of A_HoA1 and the address of A_MAAR3. 469 The second one maintains a binding of B_HoA1 and B_HoA2. 471 If the user A sends the packages to the user B, the destination 472 address of the packages must be B_HoA1, and the source address of the 473 packages must be A_HoA1. A_MAAR3 receives the packages and then 474 searches the internal binding list by using the destination address 475 of the packages (B_HoA1) for getting the address of B_MAAR2. Then 476 A_MAAR3 encapsulates the packages and routes to B_MAAR2. The source 477 address of the tunnel header is the address of A_MAAR3, and the 478 destination address is the address of B_MAAR2.The format of the 479 tunneled packet is shown below: 481 IPv6 header (src= A_MAAR3's address, dst= B_MAAR2's address) /* 482 Tunnel Header */ 484 IPv6 header (src= A_HoA1, dst= B_ HoA1 ) /* Packet Header */ 486 Upper layer protocols /* Packet Content*/ 488 After receiving the packages, B_MAAR2 removes the tunnel head and 489 find the destination address of the packages (B_HoA1) is not assigned 490 by B_MAAR2.Then B_MAAR2 searches the external binding list by using 491 the destination address of the packages (B_HoA1) for getting the CoA 492 of the user B. Finally, B_MAAR2 gets a binding of B_HoA1 and B_HoA2 493 and routes the packages to the user B. 495 5.2. Forwarding Packets to the Mobile Node 497 After receiving the packages sent by the CN, the MAAR attached by the 498 CN will search the internal binding list by using the destination 499 address of the packages for getting the address of the MAAR which the 500 MN is currently attached to. Then, the MAAR encapsulates the 501 packages and routes the packages to the corresponding MAAR which the 502 MN is currently attached to. 504 After receiving the packages, the corresponding MAAR will do three 505 things. Firstly, the corresponding MAAR will remove the tunnel head. 506 Secondly, the corresponding MAAR will check whether the destination 507 address of the packages is assigned by this corresponding MAAR or 508 not. If the destination address of the packages is assigned by this 509 corresponding MAAR, the corresponding MAAR will route the packages to 510 the corresponding MN directly. If the destination address of the 511 packages is not assigned by this corresponding MAAR, the 512 corresponding MAAR will search the external binding list by using the 513 destination address of the packages for getting the CoA of the 514 corresponding MN. Finally, the corresponding MAAR will route the 515 packages to the corresponding MN. 517 As shown in figure 2, if the user B sends the packages to the user A, 518 the destination address of the packages must be A_HoA1, and the 519 source address of the packages must be B_HoA1.B_MAAR2 receives the 520 packages and then searches the internal binding list by using the 521 destination address of the packages (A_HoA1) for getting the address 522 of A_MAAR3. Then B_MAAR2 encapsulates the packages and routes to 523 A_MAAR3. The source address of the tunnel header is the address of 524 B_MAAR2, and the destination address is the address of A_MAAR3.The 525 format of the tunneled packet is shown below: 527 IPv6 header (src= B_MAAR2's address, dst= A_MAAR3's address) /* 528 Tunnel Header */ 530 IPv6 header (src= B_HoA1, dst= A_ HoA1 ) /* Packet Header */ 532 Upper layer protocols /* Packet Content*/ 534 After receiving the packages, A_MAAR3 removes the tunnel head and 535 find the destination address of the packages (A_HoA1) is not assigned 536 by A_MAAR3. Then A_MAAR3 searches the external binding list by using 537 the destination address of the packages (A_HoA1) for getting the CoA 538 of the user A. Finally, A_MAAR3 gets a binding of A_HoA1 and A_HoA3 539 and routes the packages to the user A. 541 6. Message Formats 543 This section defines extensions to the Mobile IPv6 [RFC6275] protocol 544 messages. 546 6.1. sDBU 548 0 1 2 3 549 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Sequence # | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 |A|H|L|K|M|R|D|E| Reserved | Lifetime | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | | 556 | Mobility Options | 557 | | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 Figure 3:sDBU 562 A Binding Update message that is sent by the MAAR attached by MN 563 currently to the MAAR attached by MN before the MN's movement is 564 referred to as the "sDBU" message. A new flag D and E are included 565 in the Binding Update message. The rest of the Binding Update 566 message format remains the same as defined in [RFC6275] and with the 567 additional (R) and (M) flags, as specified in [RFC3963] and 568 [RFC4140], respectively. 570 Distributed Flag (D) 572 If the D is set to 0, this message is the BU message in the 573 [RFC6275]. If the D is set to the value 1, this message is the 574 Distributed Binding Update message (DBU).The flag MUST be set to the 575 value of 1 in the draft. 577 A new Flag (E) 579 If the E is set to 0, this DBU message is the sDBU message. This 580 flag MUST be set to 0. 582 Mobility Options 584 The sDBU message is sent by the MAAR attached by the user A currently 585 to the MAAR attached by the user A before its movement including the 586 ID of the user A, A_HoA1 and B_HoA1. 588 6.2. sDBA 590 0 1 2 3 591 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Status |K|R|D|E|Reserved| 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Sequence # | Lifetime | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | | 598 | Mobility Options | 599 | | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 Figure 4:sDBA 604 A Binding Acknowledgement message that is sent by the MAAR attached 605 by MN before the MN's movement to the MAAR attached by MN currently 606 is referred to as the "sDBA" message. A new flag D and E are 607 included in the Binding Acknowledgement message. The rest of the 608 Binding Acknowledgement message format remains the same as defined in 609 [RFC6275] and with the additional (R) as specified in [RFC3963]. 611 Distributed Flag (D) 613 If the D is set to 0, this message is the BA message in the 614 [RFC6275]. If the D is set to the value 1, this message is the 615 Distributed Binding Acknowledgement message (DBA).The flag MUST be 616 set to the value of 1 in the draft. 618 A new Flag (E) 620 If the E is set to 0, this DBA message is the sDBA message. This 621 flag MUST be set to 0. 623 Mobility Options 625 The sDBA message is sent by the MAAR attached by the user A before 626 its movement to the MAAR attached by the user A currently including 627 A_HoA1,B_HoA1 and the address of the MAAR attached by the user B 628 currently. 630 6.3. dDBU 632 0 1 2 3 633 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Sequence # | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 |A|H|L|K|M|R|D|E| Reserved | Lifetime | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | | 640 | Mobility Options | 641 | | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Figure 5:dDBU 646 A Binding Update message that is sent by the MN's MAAR attached by 647 the MN currently to the CN's MAAR which the CN is currently attached 648 to is referred to as the "dDBU" message. A new flag D and E are 649 included in the Binding Update message. The rest of the Binding 650 Update message format remains the same as defined in [RFC6275] and 651 with the additional (R) and (M) flags, as specified in [RFC3963] and 652 [RFC4140], respectively. 654 Distributed Flag (D) 656 If the D is set to 0, this message is the BU message in the 657 [RFC6275]. If the D is set to the value 1, this message is the 658 Distributed Binding Update message (DBU).The flag MUST be set to the 659 value of 1 in the draft. 661 A new Flag (E) 663 If the E is set to the value of 1, this DBU message is the dDBU 664 message. This flag MUST be set to the value of 1. 666 Mobility Options 668 The dDBU message is sent by the MAAR attached by the user A currently 669 to the MAAR which the user B is currently attached to including 670 A_HoA1 and the address of the MAAR currently attached by the user A. 672 6.4. dDBA 674 0 1 2 3 675 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Status |K|R|D|E|Reserved| 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Sequence # | Lifetime | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | | 682 | Mobility Options | 683 | | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 Figure 6:dDBA 688 A Binding Acknowledgement message that is sent by the CN's MAAR 689 currently attached by the CN to the MN's MAAR which the MN is 690 currently attached to is referred to as the "dDBA" message. A new 691 flag D and E are included in the Binding Acknowledgement message. 692 The rest of the Binding Acknowledgement message format remains the 693 same as defined in [RFC6275] and with the additional (R) as specified 694 in [RFC3963]. 696 Distributed Flag (D) 698 If the D is set to 0, this message is the BA message in the 699 [RFC6275]. If the D is set to the value 1, this message is the 700 Distributed Binding Acknowledgement message (DBA).The flag MUST be 701 set to the value of 1 in the draft. 703 A new Flag (E) 705 If the E is set to the value of 1, this DBA message is the dDBA 706 message. This flag MUST be set to the value of 1. 708 Mobility Options 710 The dDBA message is sent by the MAAR currently attached by the user B 711 to the MAAR which the user A is currently attached to including 712 A_HoA1 and B_HoA1. 714 7. IANA Considerations 716 TBD. 718 8. Security Considerations 720 TBD. 722 9. References 724 9.1. Normative References 726 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 727 Requirement Levels", BCP 14, RFC 2119, March 1997. 729 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 730 in IPv6", RFC 3775, June 2004. 732 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 733 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 734 RFC 3963, January 2005. 736 [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 737 Bellier, "Hierarchical Mobile IPv6 Mobility Management 738 (HMIPv6)", RFC 4140, August 2005. 740 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 741 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 743 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 744 in IPv6", RFC 6275, July 2011. 746 9.2. Informative References 748 [I-D.chan-distributed-mobility-ps] 749 Chan, A., "Problem statement for distributed and dynamic 750 mobility management", October 2011. 752 [Net-basedDMM] 753 Giust, F., de la Oliva, A., Bernardos, CJ., and RP. 754 Ferreira Da Costa, "A Network-based Localized Mobility 755 Solution for Distributed Mobility Management", 2011. 757 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 758 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 760 [RFC5779] Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., 761 and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access 762 Gateway and Local Mobility Anchor Interaction with 763 Diameter Server", RFC 5779, February 2010. 765 Authors' Addresses 767 Zhengming Ma 768 SUN YAT-SEN UNIVERSITY 769 Department of Electronics and Engineering,daxuecheng,210 770 Zhongshan University,Guangzhou, 510006 771 P.R. China 773 Email: issmzm@mail.sysu.edu.cn 775 Xun Zhang 776 SUN YAT-SEN UNIVERSITY 777 Department of Electronics and Engineering,daxuecheng,210 778 Zhongshan University,Guangzhou, 510006 779 P.R. China 781 Email: zhangxunkuaile@yeah.net