idnits 2.17.00 (12 Aug 2021) /tmp/idnits41353/draft-liu-dmm-flows-distribution-and-handoff-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 27, 2013) is 3158 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2460' is defined on line 935, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 938, but no explicit reference was found in the text == Unused Reference: 'RFC5944' is defined on line 941, but no explicit reference was found in the text == Unused Reference: 'RFC5380' is defined on line 947, but no explicit reference was found in the text == Unused Reference: 'RFC5026' is defined on line 957, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Liu 2 Internet Draft Y. Wang 3 Intended status: Informational ICT, CAS 4 Expires: March 27, 2014 September 27, 2013 6 Distributed Mobility Management: Service Flows Distribution and 7 Handoff Technique based on MIPv6 8 draft-liu-dmm-flows-distribution-and-handoff-01 10 Abstract 12 This document has a normative description of the service flow 13 management technology based on mobile IPv6 (MIPv6). It makes the 14 upgrade of management model in MIPv6 from the entire node granularity 15 to the single service flow granularity. It proposes a distributed 16 mobility management solution, DMIPv6, which is compatible with MIPv6 17 and takes different mobility management strategies according to the 18 Correspondent Node's position, network conditions and service 19 requirements of different service flows so as to achieve the service 20 flow handoff and transmission path control. The standard also 21 provides route optimization mechanism between the Mobile Node and the 22 ordinary Correspondent Node that doesn't support mobile IPv6. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that other 31 groups may also distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on March 27, 2014. 46 Copyright Notice 48 Copyright (c) 2013 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. Introduction ................................................... 2 64 2. Conventions used in this document .............................. 3 65 2.1. Conventions used in this document ......................... 3 66 2.2. Terminology ............................................... 3 67 3. Basic Framework ................................................ 4 68 4. Message Types .................................................. 5 69 4.1. Messages Between MN and HA ................................ 6 70 4.2. Messages Between MN and CN ................................ 6 71 4.3. DHP Query Message ......................................... 6 72 4.4. DHoA Request/Response Message .............................13 73 4.5. DHP Binding Update/Confirmation Message ...................15 74 5. DMIPv6 Workflow ................................................17 75 5.1. The Processing Workflow of New Service Connection .........17 76 5.2. The Processing Workflow when MN Moves .....................20 77 6. Security Considerations ........................................21 78 7. IANA Considerations ............................................21 79 8. References .....................................................22 80 8.1. Normative References ......................................22 81 8.2. Informative References ....................................22 82 Authors' Addresses ................................................23 84 1. Introduction 86 This standard proposes a distributed mobility management protocol, 87 DMIPv6, which is compatible with the standard mobile IPv6 protocol. 88 DMIPv6 introduces Distributed Home-Proxy (DHP) and Distributed Home 89 Address (DHoA) for a Mobile Node (MN) while there are Home Agent (HA) 90 and Home-Of-Address (HoA) already. MN will use DMIPv6 proposed in 91 this document if the DHP and DHoA are available, otherwise the 92 standard mobile IPv6 is used. The deployment of the DMIPv6 could be 93 implemented step by step, with the compatibility to the existing 94 mobile IPv6. 96 What's more, compared to the standard mobile IPv6 in management 97 model,DMIPv6 could select different DHP for a MN's different service 98 flows.MN takes different management strategy for different service 99 flows according to network conditions and the actual requirements 100 during the move. The introduction of DHP not only reduces the home 101 network congestion and HA load, but also greatly reduces the possible 102 failures in home network and HA, and the bad impacts to the MN. 103 Besides, the MN could achieve optimized transmission path and 104 transmission delay even choosing bidirectional tunnel, because the 105 DHP is located close to the Correspondent Node (CN). For CN that is a 106 server, the introduction of DHP makes it possible for it to enhance 107 its mobility support for its clients without any updates of itself. 109 2. Conventions and Terminology 111 2.1. Conventions Used in This Document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC-2119 [RFC2119]. 117 2.2. Terminology 119 All general mobility-related terms and their acronyms used in this 120 document are to be interpreted as defined in the Mobility Support in 121 IPv6 specification [RFC6275] and in the Proxy mobile IPv6 122 specification [RFC5213]. These terms include mobile node (MN), 123 correspondent node (CN), home agent (HA), Care-of-Address (CoA), 124 Home-of-Address (HoA), Binding Update (BU), and Binding 125 Acknowledgement (BA). 127 In addition, this document uses the following terms: 129 Distributed Home-Proxy (DHP) is a router near CN, with the function 130 for an extension of the HA, which assigns distributed home address 131 for the MN, receives and forwards the packet between the MN and CN. 132 It plays a role in router optimization and handoff management on 133 service flow granularity. 135 Distributed Mobile IPv6 (DMIPv6) is a distributed network layer 136 mobility solution compatible with mobile IPv6, which would take 137 different mobility management strategies according to the CN's 138 position, network conditions and service requirements of different 139 service flows so as to achieve the service flow handoff and 140 transmission path control. And the standard will also provide route 141 optimization mechanism between the MN and the ordinary CN that 142 doesn't support mobile IPv6. 144 Distributed Home Address (DHoA) is a home address that MN gets from 145 the corresponding DHP for establishing a connection with CN so as to 146 achieve the service flow handoff and transmission path control. 148 3. Basic Framework 150 Distributed Mobile IPv6(DMIPv6), which is a distributed mobility 151 management architecture compatible with Mobile IPv6, introduces 152 Distributed Home-Proxy(DHP) to the existing Mobile IPv6 architecture. 153 In DMIPv6, DHP can be deployed in subdomain of each network. 155 DHP is implemented based on HA, and multiple DHPs independent of each 156 other can be deployed in the same domain. The DHP is deployed the 157 same style as the HA and general router. Under such condition, MN can 158 select one or more DHPs according to the state of DHP and service 159 demand. In general, one DHP is enough, but multiple DHPs can be 160 selected to backup or improve concurrent performance. Figure 1 shows 161 the basic architecture of DMIPv6: 163 +------------+ +---------------------+ 164 | +------+ | | +------+ +------+ | 165 | | HA | |/---+ | | DHP1 | | CN1 | | 166 | +------+ |\--+| | +------+ +------+ | 167 |Home Domain | || | Domain 1 | 168 +------------+ || +---------------------+ 169 || /\ 170 || || 171 || || 172 \/ \/ 173 +---------------------+ 174 | | 175 | IPv6 Network | 176 | | 177 +---------------------+ 178 /\ /\ 179 || || 180 || \/ 181 +--------------+ || +---------------------+ 182 | +------+ | || | +------+ +------+ | 183 | | MN | |/--+| | | DHP2 | | CN2 | | 184 | +------+ |\---+ | +------+ +------+ | 185 |Foreign Domain| | Domain 2 | 186 +--------------+ +---------------------+ 187 Figure 1 Architecture of Service Flow Distribution and Handoff 189 Management 191 As Figure 1, there exists multiple independent DHPs in the CN 192 network, and MN can selecte one of them as the proxy server. The 193 introduction of DHP greatly decreases the MN's dependence on HA, and 194 can also optimize the transmission path and transmission delay. 196 When MN moves to a new link, the DHP can act as a proxy and forward 197 the data for it. According to the deployment style and the available 198 equipment's support to DMIPv6, MN will perform DMPv6 if the DHP and 199 DHoA are available, otherwise the standard mobile IPv6 is used. 201 4. Message Types 203 In this standard, majority of equipments need to complete a series of 204 interactions to transmit information. The following messages are 205 extended from the standard ICMPv6 messages. All extension types of 206 the extended ICMP messages are different from those of standards 207 defined by international organizations like IETF. If collisions occur 208 in the future, values of corresponding message types should be 209 adjusted according to the actual situation. 211 4.1. Messages Between MN and HA 213 Messages between MN and HA include binding update message (BU) sent 214 when MN moves and binding acknowledgment messages (BA). This standard 215 is compatible with standard mobile IPv6 protocol. For detailed 216 information about the above messages, refer to the IETF RFC 6275. 218 4.2. Messages Between MN and CN 220 Messages between MN and CN include binding update message (BU) sent 221 when MN updates its CoA-address and binding acknowledgment messages 222 (BA). This standard is compatible with standard mobile IPv6 protocol. 223 For detailed information about the above messages, refer to the IETF 224 RFC 6275. 226 4.3. DHP Query Message 228 DHP query message is used by MN to perform the DHP query and 229 selection operations. This standard proposes 3 kinds of DHP query 230 method. Corresponding query methods are depicted as follow: 232 4.3.1. Dynamic DHP Discovery Query/Acknowledgement Message 234 In this method, DHP query messages are sent to corresponding network 235 to request response directly. This procedure is similar to "dynamic 236 home agent address discovery mechanism" in MIPv6. When adopt this 237 method, all DHPs in a common CN domain should maintain the status 238 information of other DHPs, i.e. every DHP maintains a list of 239 information about all DHPs in current domain. 241 When comes to specific operation, MN query the DNS to get the DHP 242 anycast address in the CN domain, and then send dynamic DHP discovery 243 query message to that anycast address. According to the routing 244 protocols, the topologically nearest DHP from the mobile node may 245 receive the request message and then respond to it. Status 246 information of all DHPs in the CN domain should be included in the 247 reply message. MN can perform the HP selection based on this state 248 information. This approach is the active query mode of MN. 250 4.3.1.1. DHP Query Message 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Type | Code | Checksum | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Flags | Reserved | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Figure 2 Dynamic DHP Discovery Query Message 262 o Source address: IPv6 address of the interface sending this message 264 o Destination address: anycast address of DHP in the CN domain 266 o Hop limit: 255 268 o Authentication Header: sender should contain this header field 269 when security association of IP authentication header present 270 between sender and receiver. 272 o ICMP fields: 274 Type 160 276 Code 0 278 Checksum ICMP checksum 280 Reserved Reserved for future use. The value must be initialized 281 to zero by the sender, and must be ignored by the receiver. 283 4.3.1.2. DHP Acknowledgement Message 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Type | Code | Checksum | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Flags | Reserved | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Reserved | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | DHP Address 1 | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Load | Process | CN-dist | Reserved | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | DHP Address 2 | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | DHP Status Info (same as above) | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | ... | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 3 Dynamic DHP Discovery Acknowledgement Message 307 o Source address: IPv6 address of the interface sending this message 309 o Destination address: IPv6 address of MN 311 o Hop limit: 255 313 o Authentication Header: sender should contain this header field 314 when security association of IP authentication header present 315 between sender and receiver. Source address: IPv6 address of the 316 interface sending this message 318 o ICMP fields: 320 Type 161 322 Code 0 324 Checksum ICMP checksum 326 Reserved Reserved for future use. The value must be initialized 327 to zero by the sender, and must be ignored by the receiver. 329 o Options: Sender must contain following options in the request 330 message: 332 DHP proxy server address: local IPv6 address of the sender. This 333 address should be a DHP network interface address. If there exists 334 more than one DHP in current network domain, information of all 335 DHPs should be sequentially contained in the options part. 337 DHP status information: the current DHP state information should 338 include load conditions, process capability, distance from CN and 339 so on. 341 4.3.2. Multicast Request DHP Query/Acknowledgement Message 343 Through this method, IP address and status information of DHP in the 344 CN domain can be obtained by sending multicast request message. This 345 method requires all DHPs from one CN domain form a multicast group, 346 then share a multicast address. 348 Firstly MN query the DNS to get the DHP multicast address in the CN 349 domain, and then send query message to that multicast address. Since 350 then, all DHPs in the multicast group will reply acknowledgement 351 message to the MN which also contains DHP address and other status 352 information. This also is a MN active query method. 354 4.3.2.1. DHP Query Message 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Type | Code | Checksum | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Flags | Reserved | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Reserved | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Figure 4 Multicast Request DHP Query Message 368 o Source address: IPv6 address of the interface sending this message 370 o Destination address: DHP multicast address in the CN domain 372 o Hop limit: 255 373 o Authentication Header: sender should contain this header field 374 when security association of IP authentication header present 375 between sender and receiver. 377 o ICMP fields: 379 Type 162 381 Code 0 383 Checksum ICMP checksum 385 Reserved Reserved for future use. The value must be initialized 386 to zero by the sender, and must be ignored by the receiver. 388 4.3.2.2. DHP Acknowledgement Message 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Type | Code | Checksum | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Flags | Reserved | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Reserved | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | DHP Address 1 | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Load | Process | CN-dist | Reserved | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | DHP Address 2 | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | DHP Status Info (same as above) | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | ... | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Figure 5 Multicast Request DHP Acknowledgement Message 412 o Source address: IPv6 address of the interface sending this message 414 o Destination address: IPv6 address of MN 416 o Hop limit: 255 417 o Authentication Header: sender should contain this header field 418 when security association of IP authentication header present 419 between sender and receiver. 421 o ICMP fields: 423 Type 163 425 Code 0 427 Checksum ICMP checksum 429 Reserved Reserved for future use. The value must be initialized 430 to zero by the sender, and must be ignored by the receiver. 432 o Options: Sender must contain following options in the request 433 message: 435 DHP proxy server address: local IPv6 address of the sender. 437 DHP status information: state information of this machine, 438 contains load conditions, process capability, distance from CN and 439 so on. 441 The distance here is as same as defined above. Depending on the 442 routing protocols, it may be the number of hops or delay in the 443 actual network topology. 445 4.3.3. Specific Server DHP Query/Response Message 447 The DHP selection can also use special DHP management server to 448 complete. In actual circumstances, we can set global DHP management 449 server to maintain all the DHP status information in the real-time 450 network. 452 MN can use DNS to query the DHP management server's address, and then 453 send the corresponding DHP query messages to the server, the server 454 sends the request a timely response. 456 In accordance with different handling ways of MN, these methods can 457 be divided into two categories: active and passive queries. 459 4.3.3.1. Active Query 461 In this way, the MN sends a request message to DHP management server, 462 the server will send all of the information to the MN terminal, for 463 MN itself to make a choice. It is called MN active query. 465 4.3.3.1.1. DHP query message 467 The DHP query message in this way is the same with the 468 corresponding query message in 4.3.1, the difference is that the 469 message type code is 164 and the destination address is DHP 470 management server address. 472 4.3.3.1.2. DHP Query Response Message 474 DHP query response message in this way is the same with the 475 corresponding query response message in 4.3.1, the difference is 476 that the message type code is 165 and the destination address is 477 DHP management server address. 479 4.3.3.2. Passive Query 481 Different from the above mentioned active query, in the passive way, 482 the MN sends a request message to the DHP information management 483 server, the request message further includes business type that MN 484 initiate currently and other relevant requirements of DHP ( including 485 the ability to handle, the size of the load, the routing hops 486 requests and so on. According to the requirements of MN, DHP 487 information management server complete DHP preferred choice for MN in 488 predetermined rules , then the selected DHP information response to 489 MN. The Message format is as below: 491 4.3.3.2.1. DHP Query Message 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Type | Code | Checksum | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Symbol | Reserved | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Reserved | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 |Business Types | processing capability | load | routing | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | other requirements (for extended use) | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 Figure 6 Specific Server DHP Query Message 509 o source address:IPv6 address of MN interface which send this 510 message 512 o destination address: DHP information management server address in 513 CN domain 515 o hop limit: 255 517 o authentication header: if exists Security Association of IP 518 authentication header between sending and receiving peer , the 519 sending peer should include this header field 521 o ICMP field: 523 type 164 525 code 0 527 checksum ICMP checksum. 529 retained this field is not used. The sender must initialize it to 530 0, the recipient must ignore it. 532 o Options: the sending node must contain the following options in 533 the request message sent: 535 MN business requirement description: include business type to be 536 initiated, processing capability, load requirements and the 537 routing request and so on, users can also make further needs 538 customization expansion according to the actual situation. 540 4.3.3.2.2. DHP Query Response Message 542 DHP query response message in this way is the same with the 543 corresponding query response message in 4.3.2, the difference is 544 that the message type code is 165 and the destination address is 545 DHP management server address. 547 In particular, the CN can act as a DHP management server if it makes 548 some upgrades and extensions. For example, the CN needs to be able to 549 receive the DHP routing announcements of its domain and record the 550 relevant information, while the normal CN doesn't have this feature. 552 4.4. DHoA Request/Response Message 554 After choosing DHP, MN needs to apply a specific DHoA from the 555 selected DHP, which is completed by sending a message of DHoA 556 application. Based on the domain prefix information and address 557 generation algorithm, DHP generate the corresponding DHoA address, 558 and then back the address information to the MN, message format is 559 shown in Figure 7 and figure 8. 561 4.4.1. DHoA Application Message 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Type | Code | Checksum | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Reserved | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Figure 7 DHoA Request Message 571 o source address:IPv6 address of MN interface which send this 572 message 574 o destination address: DHP information management server address in 575 CN domain 577 o hop limit: 255 579 o authentication header: if exists Security Association of IP 580 authentication header between sending and receiving peer , the 581 sending peer should include this header field 583 o ICMP field: 585 type 166 587 code 0 589 checksum ICMP checksum. 591 retained this field is not used. The sender must initialize it to 592 0, the recipient must ignore it 594 4.4.2. DHoA Request Response Message 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Type | Code | Checksum | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Reserved | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | DHoA | 604 +-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ 606 Figure 8 DHoA Request Response Message 608 o source address:IPv6 address of MN interface which send this 609 message 611 o destination address: DHP information management server address in 612 CN domain 614 o hop limit: 255 616 o authentication header: if exists Security Association of IP 617 authentication header between sending and receiving peer , the 618 sending peer should include this header field 620 o ICMP field: 622 type 167 624 code 0 626 checksum ICMP checksum. 628 retained this field is not used. The sender must initialize it to 629 0,the recipient must ignore it 631 The transmitting node must contain the following options in the 632 request message 634 DHoA address: distributed by DHP for MN 636 4.5. DHP Binding Update/Confirmation Message 638 In this standard, if the DHP service is enabled, then when MN moves, 639 we need to judge whether to continue the current business, then make 640 a DHP binding update for current CoA address. This binding update 641 message format is similar with the binding update message of BU in 642 MIPv6, but needs extend a byte to store the corresponding business 643 flow port number in its message extension headerto distinguish 644 different traffic flows. The message format is shown in Figure 9. 645 Binding update confirm message between DHP and MN is the same with BA 646 in MIPv6. The message format can be seen in IETF RFC6275. 648 0 1 2 3 649 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 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | | Sequence Number | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 |A|H|L|K| Retain | valid time | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | mobile option | 656 +-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Business flow attribute | | 659 +-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ 661 Figure 9 DHP Binding Update Message 663 o sequence number: same with the BU message regulations of standard 664 MIPv6 666 o standard of related bits: same with the BU message regulations of 667 standard MIPv6 669 o valid time: same with the BU message regulations of standard MIPv6 671 o retention 673 o mobile options: same with the BU message regulations of standard 674 MIPv6 676 o extension field 678 o The sending nodes contains the following options in the request 679 message: 681 Business flow attribute, business port number when initiating 682 business locally, used to identify a service flow between the host 683 and the corresponding DHP. 685 5. DMIPv6 Workflow 687 This standard provides a distributed MIPv6 compatible solution named 688 DMIPv6 which enables service flow distribution and handoff 689 management. We assume that MN has already moved to foreign network 690 from home network here, thus MN should has DHoA address and CoA 691 address, or HoA address and CoA address if the DMIPv6 is unavailable. 692 We introduce the main processing workflow of the technical proposal 693 in this standard, with 2 steps: the processing procedure of the new 694 service flows and the MN handoffs, which corresponds to the service 695 flow distribution and mobility handoff management. 697 5.1. The Processing Workflow of New Service Connection 699 It is the processing workflow in the DMIPv6 when there is a new 700 service connection between MN and CN. The detailed procedure is 701 introduced as follows, and the related message interaction diagram is 702 introduced in Figure 10. The detailed message format is showed in 703 Chapter 4. 705 5.1.1. The Decision of the Mobility Requirement of Service Flow 707 MN decides whether the service flow needs mobility support according 708 to the service type of the new connection request. The standard of 709 this decision can refer to the requirement of the MN itself and set 710 the decision rule in advance: 712 If MN decides that the service flow needs mobility support, then it 713 goes to section 5.1.2; or MN will use the old CoA address to 714 establish the connection with CN. 716 5.1.2. The Requirement Decision Started by the New Connection 718 Mobile nodes decides whether the new connection request is started by 719 the local MN, if it is then MN goes to section 5.1.3; or MN uses HoA 720 address to establish the connection with CN. 722 5.1.3. DHP Query 724 MN queries the DHP address and status of CN's network for its service 725 flow, and there are 4 ways to realize the DHP query, which can be 726 found in section 4.3. Figure 10 provides the message interaction 727 diagram for different ways of query. Figure 10(a) is for the query of 728 dynamic discovery and multicast request in section 4.3.1 and 4.3.2. 729 Figure 10(b) is for the query which introduces DHP management server 730 or uses CN in section 4.3.3 and 4.3.4. 732 5.1.4. DHP Selection 734 After the DHP query, MN needs to make the DHP selection. For the 735 active query introduced in section 4.3, MN will decide which DHP 736 serves itself according to different targets. The actual decision can 737 be made in MN in advance, such as the distance to CN, processing 738 ability, related workload information, etc. As for the passive query, 739 MN can directly achieve the DHP address and the corresponding 740 information. 742 Besides, during the process procedure of this standard, DHP always 743 knows MN's location information and must ensure to avoid MN's 744 information disclosure. As a result, the DHP selection introduces the 745 selection of DHP's security mechanism. Each DHP will make its 746 security warranty as one of the most important status information and 747 can provide hierarchical classification on occasion. As for the 748 active query in section 4.3, MN can decide to select which security 749 level of DHP to serve it; as for the passive query, MN needs the 750 related management server to make selection policy and directly 751 achieve the related information. It is preferred that these security 752 requirements are considered as an integral part of the DMM design. 754 5.1.5. DHoA Address Application 756 MN will send the corresponding address application message to the DHP 757 after deciding which DHP serves it. DHP can create the required DHoA 758 message according to the address creation algorithm and local prefix 759 information, and then inform the MN of this DHoA. At the same time, 760 it will bind the allocated DHoA with MN's current address. 762 5.1.6. Establishing the Communication Connection 764 MN uses the queried DHoA to establish the connection with CN, and at 765 the same time, DHP will save the information of DHoA and MN's 766 address. It maintains a mapping table of the DHoA, MN and a service 767 connection, and this mapping table is used for the management of 768 mobility handoff. 770 A notice is that, MN will use HoA to establish the connection with CN 771 if the DHP query is failed in DHP, which means no DHP is found to 772 serve the current MN. Later workflow is the same as that defined in 773 MIPv6. 775 5.1.7. Confirming the Communication Mode 777 MN needs to decide whether to use routing optimization mode or bi- 778 direction tunneling mode according to the situation how CN supports 779 the routing optimization. MN will use routing optimization mode for 780 the CN which supports routing optimization; or it will use the bi- 781 direction tunneling mode. After confirming the communication mode, MN 782 will start data transmission with CN. 784 +--+ +----+ +----+ +--+ 785 |MN| |DHP1| |DHP2| |CN| 786 +--+ +----+ +----+ +--+ 787 | | | | 788 [DHP Discovery] | | | 789 |DHP query/response message | | | 790 |<--------------------------->| | | 791 | | | | 792 | DHP query/response message | | 793 |<--------------------------------------------->| | 794 | | | | 795 [DHP select] | | | 796 |DHoA request/response message| | | 797 |<--------------------------->| | | 798 | | | | 799 [connection established] | | | 800 |DMIPv6 tunnel | data packets | 801 |=============================|<-------------------------------->| 803 (a) 805 +--+ +------------------------+ +----+ +--+ 806 |MN| |DHP management server/CN| |DHP | |CN| 807 +--+ +------------------------+ +----+ +--+ 808 | | | | 809 [DHP Discovery] | | | 810 |DHP query/response message | | | 811 |<--------------------------->| | | 812 | | | | 813 [DHP select] | | | 814 |DHoA request/response message| | | 815 |<--------------------------->| | | 816 | | | | 817 | DHP query/response message | | 818 |<--------------------------------------------->| | 819 | | | 820 [connection established] | | 821 |DMIPv6 tunnel | data packets | 822 |===============================================|<-------------->| 824 (b) 826 Figure 10 New Service Connect Message interaction 828 5.2. The Processing Workflow when MN Moves 830 In the communication between MN and CN, when MN moves, first need to 831 judge whether the DHP has been enabled. For the enabled DHP, to carry 832 on the following steps, otherwise according to the standard MIPv6 833 protocol to execute. 835 5.2.1. The Qos Conditions Identification of A New Access Network 837 MN According to the Qos condition of a new access network, business 838 priorities and the Qos requirement to judge whether the Qos 839 requirement has been satisfied and whether the business should be 840 continue. Specific we can achieve the condition of network interface, 841 topology-aware, business flow parameter estimation of available 842 bandwidth measurement, network packet loss rate and throughput to 843 implement the requirement. 845 5.2.2. Handoff Management 847 For the service streams need to continue communication, will perform 848 the following operations: 850 1. MN bind the CoA address and the port of the flow with the selected 851 DHP. 853 2. DHP Replies binding update confirmation. 855 3. DHP performs proxy functions, intercepts the packets of CN sent to 856 the MN existing home network, through the establishment of the 857 tunnel DHP sent the packets to the new access network of MN. 859 4. For the CN of supporting the route optimization function, MN binds 860 the new CoA address with CN, begin to communicate with CN until 861 the CN's reply has been accepted. For the CN of not supporting the 862 route optimization function, MN will carry on communication and 863 transmission by bidirectional tunnel. 865 For the service streams that don't need to continue communication and 866 Qos has no requirement. MN will stop the flow and will not bind the 867 new CoA address with DHP. 869 For different businesses, MN can take different interrupt. 870 Specifically, according to different transport layer protocols, and 871 its own characteristics MN will take different message exchange or 872 notification. 874 6. Security Considerations 876 This standard is compatible with MIPv6, in the meantime, DHP 877 equipments are added to it. Its basic procedures and messages 878 exchanging schemes are similar to MIPv6, which lead to similar 879 security issues like MIPv6's, including the security of dynamic DHP 880 discovery, addresses binding and tunnels setting up between MN, HA, 881 and CN. Detailed information in IETF RFC 6275. 883 This standard is compliant with standard MIPv6, which means MN still 884 has HoA in home domain. When MN is initiating a new connection with 885 DMIPv6, it will first apply for DHoA. According to MIPv6, MN's HoA is 886 permanent during in its travelling, so CN always knows its HoA. So CN 887 will see MN travel from home domain to network with same prefix like 888 DHoA. In addition, DHP is commonly in CN's domain and is close to CN, 889 so CN will identify that MN has already moved to place near itself. 890 In the whole process, CoA is hidden from CN, which avoid some 891 security risks to some extensions. 893 In the standard, DMIPv6 will be chosen when MN initates connection 894 first. So, if there are random or periodic pseudo-connections, the 895 process of DHP lookup and DHoA application will be triggered, which 896 will impose heavy burden on MN and DHP. In fact, it's likely that 897 from trojans and hackers' attacks. Under such circumstance, MN should 898 use secured authentication to limit the number of pseudo-connections, 899 and set bidirectional security mechanisms in DHP. 901 When DMIPv6 is turned on, DHP will always know MN's location, and can 902 send the information to third parties, while those requests for 903 location may be ill-intended. So, DHP needs to build enough security 904 mechanisms to guard MN's information. Whether DHP has security 905 mechanisms will be an important condition in MN's inqury to DHP. 906 Detailed information see 5.1.4. 908 7. IANA Considerations 910 This document proposes 4 DHP query methods, and 8 message types 911 totally for them: 913 o The Dynamic DHP Discovery Query Message, and the Dynamic DHP 914 Discovery Acknowledgement Message, described in Section 4.3.1 916 o The Multicast Request DHP Query Message, and the Multicast Request 917 DHP Acknowledgement Message, described in Section 4.3.2 919 o The Specific Server DHP Query Message, in Section 4.3.3.1.2 921 o The DHoA Request Message, in Section 4.4.1 923 o The DHoA Request Response Message, in Section 4.4.2 925 o The DHP Binding Update Message, in Section 4.5 927 8. References 929 8.1. Normative References 931 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 933 Requirement Levels", BCP 14, RFC 2119, March 1997. 935 [RFC2460] Deering, S., "Internet Protocol, Version 6 (IPv6) 936 Specification", RFC 2460, November 1997. 938 [RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless 939 Address Autoconfiguration", RFC 4862, September 2007. 941 [RFC5944] Perkins, Ed., C., "IP Mobility Support for IPv4, Revised", 942 RFC 5944, November 2010. 944 [RFC6275] Perkins, Ed., C., Johnson, D., and J. Arkko, "Mobility 945 Support in IPv6", RFC 6275, July 2011. 947 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, 948 "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", 949 RFC 5380, October 2008. 951 8.2. Informative References 953 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 955 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 957 [RFC5026] Giaretta, G. Kempf, J. and V. Devarapalli, "Mobile IPv6 958 Bootstrapping in Split Scenario", RFC 5026, Oct 2007. 960 [NTMS2008]Bertin, P., "A Distributed Dynamic Mobility Management 961 Scheme designed for Flat IP Architectures.", NTMS'2008, 962 November 2008. 964 [I-D. yokota-dmm-scenario] 965 Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case 966 scenarios for Distributed Mobility Management", draft- 967 yokota-dmm-scenario-00 (work in progress), October 2010. 969 Authors' Addresses 971 Min Liu 972 Institute of Computing Technology, Chinese Academy of Sciences, 973 No.6 Kexueyuan South Avenue, Zhongguancun, Beijing 100190, China 974 Email: liumin@ict.ac.cn 976 Yuwei Wang 977 Institute of Computing Technology, Chinese Academy of Sciences, 978 No.6 Kexueyuan South Avenue, Zhongguancun, Beijing 100190, China 979 Email: wangyuwei@ict.ac.cn