idnits 2.17.1 draft-cui-netext-sma-pmipv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (October 18, 2009) is 5302 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-02) exists of draft-larsson-mext-flow-distribution-rules-01 == Outdated reference: A later version (-02) exists of draft-jeyatharan-netext-multihoming-ps-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NETEXT Working Group Y. Cui 2 Internet Draft H. Wang 3 Intended status: Standard Track T. Ma 4 Expires: April 2010 Tsinghua University 5 October 18, 2009 7 Simultaneous Multi-Access for PMIPv6 based on Single HNP Model 8 draft-cui-netext-sma-pmipv6-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with 13 the provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on April 18, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license- 42 info). Please review these documents carefully, as they describe 43 your rights and restrictions with respect to this document. 45 Abstract 47 Simultaneous Multi-Access (SMA), originally designed for MIPv6, 48 expects to be ported to PMIPv6 to achieve flow binding. However, 49 there are a lot of problems to adapt SMA to PMIPv6 due to 50 different mechanisms of two mobility management protocol. This 51 document analyzes issues of SMA and different multihoming 52 scenarios in PMIPv6. A PMIPv6 system which allows a MN to share 53 HNP across its interfaces is proposed and a SMA solution is 54 designed for the modified PMIPv6 system. The solution supports 55 flow-based routing and address-based routing simultaneously. 57 Table of Contents 59 1. Introduction...................................................3 60 2. Terminology....................................................3 61 3. Overview.......................................................3 62 3.1. Issues of SMA Support in PMIPv6...........................3 63 3.2. Multihoming Scenarios of PMIPv6...........................5 64 3.2.1. Multiple HNP Model...................................5 65 3.2.2. Single HNP Model.....................................6 66 4. PMIPv6 based on Single HNP Model...............................6 67 4.1. HNP Allocation and Address Configuration..................6 68 4.2. Routing of LMA and MAG....................................7 69 5. SMA Operations.................................................8 70 5.1. Registration of Routing Rules.............................8 71 5.2. Data Transmission.........................................9 72 5.2.1. Sending Packet from MN..............................10 73 5.2.2. Sending Packet to MN................................10 74 5.3. Vertical Handoff.........................................11 75 6. Conclusion....................................................13 76 7. Security Considerations.......................................13 77 8. IANA Considerations...........................................13 78 9. References....................................................13 79 9.1. Normative References.....................................13 80 9.2. Informative References...................................13 81 10. Acknowledgments..............................................14 83 1. Introduction 85 Proxy Mobile IPv6 (PMIPv6) [1] allows a multihoming mobile node to 86 connect to a PMIPv6 domain via multiple interfaces simultaneously. 87 With several paths available, flows could be bind to different 88 path to achieve load-balance, high aggregated bandwidth and flow 89 mobility. Simultaneous Multi-Access (SMA) [2], which is proposed 90 to takes these advantages of multihoming in MIPv6, could be 91 adapted to PMIPv6 to enable flow bindings. However, because of the 92 fact that MN uses different Home Network Prefixes (HNPs) on 93 different interfaces rather than a unique Home Address of MN in 94 MIPv6, additional mechanism such as Primary Prefix is introduced 95 into PMIPv6 to ensure packets can be routed to MN via a proper 96 path [3]. 98 As for the PMIPv6 specification, assigning different HNPs for 99 different interfaces of one MN is regarded as lack of simultaneous 100 usage support and therefore is difficult to provide flow binding 101 support [4]. Besides this proposal, sharing the same HNPs across 102 multiple interfaces of one MN in PMIPv6 is proposed as a solution 103 for multihoming (different MNs are still assigned different HNPs). 104 This model is able to provide convenience for some multihoming 105 application, including flow-based routing [5]. 107 This document describes a SMA solution for PMIPv6 based on Single 108 HNP Model. In the rest of the document, the issues of SMA support 109 in PMIPv6 and the advantages of sharing HNPs across interfaces are 110 analyzed. Based on the modified PMIPv6 system, a SMA solution is 111 proposed to support both address-based routing and flow-based 112 routing. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 117 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 118 in this document are to be interpreted as described in RFC-2119. 120 3. Overview 122 3.1. Issues of SMA Support in PMIPv6 124 SMA, originally designed for MIPv6, aims to take advantages of 125 multihoming. Its primary idea is to use policies to bind flow to a 126 specified path based on different characteristics of multiple 127 available paths (such as bandwidth, QoS, cost, etc.). In another 128 word, MIPv6 system equipped with SMA function performs flow-based 129 routing; both inbound packets and outbound packets are directed to 130 a specified interface by either HA or MN according to policies. 132 In MIPv6, each MN has a unique Home Address (HoA) which is always 133 used as the source address of outbound packet and the destination 134 address of inbound packet. Without regard to route optimization, 135 tunnels from HA to MN ensures that packets can be routed to either 136 MN or CN properly no matter which interface MN uses to transmit 137 packets. Therefore, there is little difficulty in performing SMA 138 in MIPv6. 140 However, the situation is quite different in PMIPv6. First of 141 all, unlike the unique HoA in MIPv6, MN is assigned different HNPs 142 for each interface in PMIPv6 and consequently addresses of 143 interfaces are different from each other. When communicating with 144 CN, MN use the address on the outgoing physical interface so it 145 could lead to troubles to bind an existing flow, which is usually 146 identified by the source and destination addresses, to another 147 interface. Flow-based routing might cause conflict with address- 148 based routing for the address of bound interface might not match 149 with the address of the flow. 151 Second, additional mechanism is necessary to guarantee the 152 validity of routing. Tunnels are built from LMA to MAGs rather 153 than MN in PMIPv6. Therefore, even if LMA is able to perform flow- 154 based routing to select a proper MAG to forward packets to, 155 additional mechanisms are necessary to introduced to MAGs to 156 ensure they are able to relay packets to MN. Take the scenario in 157 Figure 1 as an example. MAG2 should have the information about 158 HNP1 so as to forward Flow1 to MN via IF2. Otherwise, MAG2 cannot 159 find a route match the destination of the packet; even if MAG2 is 160 able to perform flow-based routing, it has to recognize which MN 161 the flow belongs to by matching the destination address of the 162 flow. 164 Third, MN has to be extended to support SMA in PMIPv6. PMIPv6 is 165 designed as a network-based mobility management protocol so that 166 MN needs no extension to get mobility support in a PMIPv6 domain. 167 However, to enable SMA function, MN has to be modified to support 168 the generation and transmission of routing rules as well as flow 169 binding operation. Moreover, owing to the above-mentioned two 170 issues, existing proposal involves MN in mobility management to 171 request Primary Prefix and to update Binding ID [3]. 173 In short, flow-based routing of SMA relies on address-based 174 routing because only address information of a packet can be used 175 to identify the corresponding MN. With regard to PMIPv6, since 176 there is no direct tunnel from LMA to MN, HNP allocation and 177 conventional address-based routing of PMIPv6 should coordinate 178 with SMA mechanism to achieve flow binding. Moreover, extension to 179 MN is also necessary to make full use of multihoming. 181 +----+ 182 | CN | 183 +----+ 184 | 185 +-------+ 186 | LMA | Flow1 -> IF2 187 +-------+ 188 / \ ----+ Flow1 189 / \ | Src Addr: CN 190 / \ | Dst Addr: HNP1 191 / \ v 192 +------+ +------+ 193 | MAG1 | | MAG2 | 194 +------+ +------+ 195 \ / 196 \ / 197 \ / 198 +-----------+ 199 IF1: HNP1 | IF1 | IF2 | IF2: HNP2 200 +-----+-----+ 201 | MN | 202 +-----------+ 204 Figure 1 Routing Problem of SMA in PMIPv6 206 3.2. Multihoming Scenarios of PMIPv6 208 Different scenarios of multihoming in PMIPv6 can be divided into 209 two categories according to their HNP model. One is multiple HNP 210 model that assign unique HNP to each interface; the other is 211 single HNP model that assign the same HNP across interfaces of one 212 MN. 214 3.2.1. Multiple HNP Model 216 PMIPv6, defined in [1], use this model to assign HNP for MN. In 217 this model, each interface is assigned a unique HNP so a 218 multihoming MN always gets multiple HNPs; each binding tied to an 219 interface of MN is considered as a separate mobility session; 220 multiple interfaces are able to connect to PMIPv6 domain 221 simultaneously and transmit data independently. However, some 222 advanced multihoming application meets troubles in this model, 223 including HNP allocation in vertical handoff, lack of simultaneous 224 usage support [4], aforementioned SMA issues, etc. 226 3.2.2. Single HNP Model 228 In this model, a HNP is shared across different interfaces one MN. 229 There are several forms for this model. One is to assign unique 230 HNP to a MN and configure address for every interface of MN; 231 another one is to allow some HNPs to be shared across different 232 interfaces belonging to a MN; a third one is to configure the same 233 address on every interface of a MN to emulate HoA of MIPv6. 235 Despite varieties of this model, the primary feature of it is that 236 the address of an interface has prefix in common with others and 237 thus different MAGs are able to add general routing table entry 238 for different interface addresses of one MN. 240 However, this model causes problems for routing of LMA and MAG. As 241 for conventional PMIPv6, prefix-based routing of LMA and MAG works 242 well to forward packet for multihoming MN because prefixes of 243 multiple interfaces are different from each other but this no 244 longer work in Single HNP Model for prefix matching comes to 245 ambiguous result. On the other hand, address-based routing is an 246 alternative to prefix-based routing but it leads to troubles that 247 are similar to problems of Multiple HNP Model. Yet, with the 248 combination of prefix-based routing and address-based routing, 249 Single HNP Model is able to provide a valid platform for SMA 250 support, which will be described in the following sections. 252 4. PMIPv6 based on Single HNP Model 254 This section describes a modified PMIPv6 system based on Single 255 HNP Model. The PMIPv6 system SHOULD support multihoming and be 256 able to forward a packet to a proper interface of MN based on the 257 destination address. Moreover, it SHOULD support SMA function with 258 the aid of routing rules management and flow-based routing 259 extension. 261 4.1. HNP Allocation and Address Configuration 263 The system is based on Single HNP Model so the same HNP is 264 assigned to different interfaces of one MN. Yet, different HNPs 265 MAY be assigned to different interfaces as that of conventional 266 PMIPv6. However, for interfaces that are preparing for SMA usage, 267 shared HNP SHOULD be assigned to them. 269 Receiving HNP, MN SHOULD configure different addresses for 270 different interfaces even if they share the same HNP. Although 271 configuring the same address on different address emulates the HoA 272 of MIPv6 to some degree, duplicated IPv6 global addresses on 273 different physical interfaces might result in troubles such as 274 address collision and some systems does not allow such operation. 275 However, using the same prefix to configure different addresses is 276 well supported so this approach is feasible. 278 4.2. Routing of LMA and MAG 280 LMA SHOULD add address-based routing table entries for each access 281 interface that connects to the PMIPv6 domain. MAG SHOULD add both 282 address-based and prefix-based routing table entries for each 283 access interface that connects to the MAG itself. 285 Address-based routing table entries of LMA and MAG ensure that 286 packets can be routed to the interface with the destination 287 address. The longest prefix matching of address-based routing make 288 address-based entries selected to get the outgoing interface and 289 next hop for each packet. On the other hand, prefix-based entries 290 of MAG are used for simultaneous usage support and will come into 291 handy in SMA function. 293 To set up address-based entries, LMA and MAG SHOULD be aware of 294 the addresses of access interface, which is different from 295 original PMIPv6 for the prefix is enough to identify a routing 296 path in Multiple HNP Model. This can be achieved by using Neighbor 297 Discovery of IPv6. Since MN will send Neighbor Advertisement after 298 configuring address on an interface, MAG can get the address of 299 the access interface by receiving such messages. After that, MAG 300 SHOULD inform LMA of the address. Thus, additional signaling is 301 required to support address-based routing in Single HNP Model. 302 Figure 2 shows the extended signaling call flow of MN attachment, 303 in which extra PBU and PBA are added to transmit the address of 304 access interface. 306 +-----+ +-----+ +-----+ 307 | MN | | MAG | | LMA | 308 +-----+ +-----+ +-----+ 309 | | | 310 MN Attached | | 311 | | | 312 | MN Attached Event from MN/Network | 313 | (Acquire MN-Id and Profile) | 314 | | | 315 |--- Rtr Sol --------->| | 316 | | | 317 | |--- PBU ------------->| 318 | | | 319 | | Accept PBU 320 | | (Allocate HNP, Setup BCE & Tunnel) 321 | | | 322 | |<------------- PBA ---| 323 | | | 324 | Accept PBA | 325 | (Set Up Tunnel) | 326 | | | 327 | |==== Bi-Dir Tunnel ===| 328 | | | 329 |<--------- Rtr Adv ---| | 330 | | | 331 IP Address | | 332 Configuration | | 333 | | | 334 |----- Neigh Adv ----->| | 335 | Accept NA | 336 | (Set Up Routing) | 337 | | | 338 | |--- PBU ------------->| 339 | | (Carrying address) | 340 | | | 341 | | Accept PBU 342 | | (Set Up Routing) 343 | | | 344 | |<------------- PBA ---| 345 | | | 347 Figure 2 MN Attachment - Extended Signaling Call Flow 349 5. SMA Operations 351 5.1. Registration of Routing Rules 353 A Routing Rule is a rule which specifies that traffic with certain 354 characteristic is to be handled in a certain manner. Its main 355 application is to bind a flow to a certain path. A Path Identifier 356 (PID) is used to identify a path between a multihoming MN and its 357 peers [2]. For MIPv6, the PID is identical to the Binding 358 Identifier (BID) [6]. In PMIPv6, there is no BID for bindings but 359 a Link-layer Identifier (LL-ID) is generated for each access 360 interface and it can be used to identify a path. 362 Routing Rules can be generated by either MN or LMA and should be 363 transmitted to the other side by generator. The transmission of 364 Routing Rules can be achieved by extended ICMP messages and 365 mobility signaling defined in [3]. At LMA, Routing Rules are 366 stored in the Binding Cache Entry for the LL-ID. 368 5.2. Data Transmission 370 This section will explain how traffic is sent from and to a MN 371 based on SMA function. Figure 3 shows a PMIPv6 multihoming 372 scenario with the following assumptions: 374 o MN has two active interfaces; IF1 connects to MAG1 and IF2 375 connects to MAG2. 377 o IF1 and IF2 share the same HNP but they have respective 378 addresses (ADDR1 and ADDR2). 380 o Both MAG1 and MAG2 have set up address-based and prefix-based 381 routing table entries for corresponding access interface. 383 o LMA has set up address-based routing table entries for IF1 and 384 IF2. 386 o A set of Routing Rules with associated LL-IDs have been created 387 and transmitted. They are stored in both MN and LMA. 389 List of Routing Rules: 391 Flow A <--> LL-ID1 393 Flow B <--> LL-ID2 395 o MN is communicating with a CN. 397 +----+ Binding Cache: 398 | CN | ============== 399 +----+ MN-ID, HNP, LL-ID1, 400 | Flow A <--> LL-ID1; 401 | MN-ID, HNP, LL-ID2, 402 | Flow B <--> LL-ID2; 403 | 404 +-------+ LMA RT (Routing Table): 405 | LMA | ================== 406 +-------+ ADDR1 -> MAG1 407 / \ ADDR2 -> MAG2 408 / \ 409 / \ 410 / \ 411 MAG1 RT: +------+ +------+ MAG2 RT: 412 ======== | MAG1 | | MAG2 | ======== 413 ADDR1 -> MN +------+ +------+ ADDR2 -> MN 414 HNP -> MN \ / HNP -> MN 415 \ / 416 \ / 417 +-----------+ 418 IF1: HNP1, ADDR1 | IF1 | IF2 | IF2: HNP, ADDR2 419 +-----+-----+ 420 | MN | 421 +-----------+ Routing Rules: 422 ============== 423 Flow A <--> LL-ID1 424 Flow B <--> LL-ID2 426 Figure 3 Scenario of SMA in PMIPv6 428 5.2.1. Sending Packet from MN 430 When MN sends a packet to CN, it will match the packet with 431 Routing Rules. If the packet matches one of the Routing Rules, the 432 outgoing interface is selected according to the LL-ID in the 433 Routing Rule. Otherwise, MN just looks up into routing table to 434 get the outgoing interface by address-based routing. With the 435 outgoing interface, MN transmits the packet on that interface. The 436 MAG receiving the packet tunnels the packet to LMA. LMA 437 decapsulates the packet and routes it towards CN. 439 5.2.2. Sending Packet to MN 441 When LMA receives a packet from CN, it will search the Binding 442 Cache for entries with HNP matches the destination address of the 443 packet. Then it will check whether the packet matches one of the 444 Routing Rules belong to those Binding Cache entries. 446 If the packet matches one of the Routing Rules, the tunnel 447 interface identifier of the corresponding binding cache is 448 selected and LMA will use that tunnel to forward packet towards 449 MAG. When MAG receive the packet, it decapsulates the packet and 450 performs address-based routing to forward the packet to MN. If the 451 address of access interface connecting to the MAG is not the same 452 as the destination address of the packet, MAG can still route it 453 based on the prefix-based routing table entry for ADDR1 and ADDR2 454 share the same prefix; if the two addresses are the same, MAG will 455 route it based on the address-based entry: issues mentioned in 456 Section 3.1 no longer troubles. 458 Otherwise, if none of the Routing Rules is matched, LMA and MAG 459 will just perform address-based routing. The address-based routing 460 table entries set up in the registration procedure are enough to 461 help to route the packet to MN. 463 However, a problem arises when MN receives the packet. Although 464 network side manages to route the packet to one of the interfaces 465 of MN, MN has to be able to receive a packet aiming at one 466 interface from another interface. Otherwise, when the destination 467 address of the packet does not match the address of receiving 468 interface, the packet would be discarded. Yet, weak End System 469 Model, defined in [7] and supported by most of current systems, 470 allows MN to do so. Therefore, MN is able to receive the packet as 471 long as network side forwards the packet properly. 473 5.3. Vertical Handoff 475 In SMA, moving flows across running interfaces could be achieved 476 by changing routing rules but it cannot handle the condition where 477 an interface disconnect from the network. For example, MN in 478 Figure 3 starts a flow on IF1 with ADDR1. If IF1 disconnect from 479 the network, the address configured on it is also gone. Thus, MN 480 cannot receive the existing flow any longer even if network side 481 route the flow to IF2. To solve the problem, additional mechanism 482 is need to perform vertical handoff, i.e. the handoff between 483 different interfaces. 485 Both network side and MN are involved in vertical handoff. First, 486 network side SHOULD be aware of the handoff event so as to launch 487 a new proxy registration and modify routing entries. Second, MN 488 SHOULD be able to configure ADDR1 on IF2 to receive the existing 489 flow. 491 As for the network side, although Handoff Indicator Option is 492 defined in PMIPv6 [1] to implement such a handoff, no mechanism is 493 designed for MAG to detect handoff event so it cannot set the 494 value of the option properly. This document suggests that MN 495 notify MAG of handoff event since only MN itself is aware of 496 whether it would like to perform a handoff to move existing flow 497 to IF2 or it just want to terminate IF1 as well as the flow on it. 498 The notification could be done by sending an extended RS, just 499 like that defined in [8], via IF2. After receiving the request, 500 MAG2 will perform a new registration for ADDR1. Since IF1 and IF2 501 shares the same HNP, MAG and HNP just need to change their 502 address-based routing entries as well as update binding cache and 503 binding update list. When MN receives RA, it SHOULD be configure 504 ADDR1 on IF2 so address configuration mechanism of MN need to be 505 modified to meet such requirement. How to extend MN to support 506 extended RS and the modified address configuration mechanism is 507 out of scope of this document. Figure 4 shows the signaling call 508 flow of vertical handoff. Notice that since LMA has already got 509 ADDR1 and it could inform MAG2 of ADDR1 in PBA, it is not 510 necessary for MAG2 to get the address by listening for Neighbor 511 Advertisement. 513 +-----+ +-----+ +-----+ 514 | MN | | MAG | | LMA | 515 +-----+ +-----+ +-----+ 516 | | | 517 Launch V. Handoff | | 518 | | | 519 | | | 520 |--Extended Rtr Sol -->| | 521 | (V. Handoff Req.) | | 522 | |--- PBU ------------->| 523 | | | 524 | | Accept PBU 525 | | | 526 | | | 527 | |<------------- PBA ---| 528 | | (Carrying Address) | 529 | | | 530 | Accept PBA | 531 | | | 532 |<--------- Rtr Adv ---| | 533 | | | 534 IP Address | | 535 Configuration | | 536 | | | 538 Figure 4 Vertical Handoff - Signaling Call Flow 540 After the handoff operation, LMA and MAG are able to forward the 541 existing flow to IF2 and MN is also able to receive the flow via 542 IF2 for ADDR1 is configured on MN again. 544 6. Conclusion 546 This document describes a SMA solution for PMIPv6 based on Single 547 HNP Model. The protocol performs flow-based routing based on 548 Routing Rules to bind both inbound and outbound flow to a 549 specified path while it performs address-based routing for packets 550 that do not match any Routing Rules. Extra mobility signaling call 551 is added to set up address-based routing. Both LMA and MAG are 552 extended to be able to generate Routing Rules, transmit them and 553 route packets according to them; however, the extension on MN is 554 limited to SMA function and mobility management is still done by 555 network side, which follows the idea of PMIPv6. 557 7. Security Considerations 559 This document does not introduce any new security concerns on top 560 of what is described in Security Considerations section of [1]. 562 8. IANA Considerations 564 This document does not request any assignments from IANA. 566 9. References 568 9.1. Normative References 570 [1] K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, "Proxy 571 Mobile IPv6", RFC5213, August 2008. 573 9.2. Informative References 575 [2] C. Larsson, M. Eriksson, K. Mitsuya, K. Tasaka and R. Kuntz, 576 "Flow Distribution Rule Language for Multi-Access Nodes", 577 draft-larsson-mext-flow-distribution-rules-01, July 2008. 579 [3] C. Larsson, M. Eriksson and P. Arvidsson, "Simultaneous 580 Multi-Access and Flow Mobility Support for PMIPv6", draft- 581 larsson-netext-pmipv6-sma-flow-mobility-00, March 2009. 583 [4] M. Jeyatharan, C. Ng, V. Devarapalli and J. Hirano, 584 "Multiple Interfaced Mobile Nodes in NetLMM", draft- 585 jeyatharan-netlmm-multi-interface-ps-03, October 2008. 587 [5] M. Jeyatharan and C. Ng, "Multihoming Problem Statement in 588 NetLMM", draft-jeyatharan-netext-multihoming-ps-01, March 589 2009. 591 [6] M. Eriksson, C. Larsson and R. Kuntz, "Mobile IPv6 Flow 592 Routing over Multiple Care-of Addresses", draft-eriksson- 593 mext-mipv6-routing-rules-00, June 2008. 595 [7] R. Braden, "Requirements for Internet Hosts -- Communication 596 Layers", RFC 1122, October 1989. 598 [8] T. Savolainen, D. Premec, "Inter-technology handover in 599 PMIPv6 domain", draft-savolainen-netext-intertech-handover- 600 00, July 2009. 602 10. Acknowledgments 604 The authors would like to thank Conny Larsson for his advice and 605 the discussion on the topic. 607 This document was prepared using 2-Word-v2.0.template.dot. 609 Authors' Addresses 611 Yong Cui 612 Tsinghua University 613 Tsinghua University FIT Building 4-104 614 Beijing 100084 615 P.R.China 617 Email: cuiyong@tsinghua.edu.cn 619 Hongyi Wang 620 Tsinghua University 621 Tsinghua University FIT Building 4-103 622 Beijing 100084 623 P.R.China 625 Email: whynpc@gmail.com 627 Tianze Ma 628 Tsinghua University 629 Tsinghua University FIT Building 4-104 630 Beijing 100084 631 P.R.China 633 Email: frank0208@gmail.com