idnits 2.17.1 draft-ietf-monami6-multihoming-motivation-scenario-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 831. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 815. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 821. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2006) is 6644 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) ** Downref: Normative reference to an Informational RFC: RFC 3582 (ref. '1') == Outdated reference: A later version (-05) exists of draft-ietf-monami6-mipv6-analysis-00 ** Downref: Normative reference to an Informational draft: draft-ietf-monami6-mipv6-analysis (ref. '2') == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-05 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-multihoming-issues (ref. '3') -- Possible downref: Normative reference to a draft: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '5') -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 3775 (ref. '9') (Obsoleted by RFC 6275) Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Monami6 Working Group T. Ernst 3 Internet-Draft Keio University / WIDE 4 Expires: August 5, 2006 N. Montavont 5 GET/ENST-B 6 R. Wakikawa 7 Keio University 8 C. Ng 9 Panasonic Singapore Labs 10 K. Kuladinithi 11 University of Bremen 12 February 2006 14 Motivations and Scenarios for Using Multiple Interfaces and Global 15 Addresses 16 draft-ietf-monami6-multihoming-motivation-scenario-00 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 5, 2006. 43 Copyright Notice 45 Copyright (C) The Internet Society (2006). 47 Abstract 48 In this document, multihoming is investigated from a node point of 49 view, and not from a site point of view as the term "multihoming" is 50 commonly understood so far. The purpose of this document is to 51 explain the motivations for fixed and mobile nodes (hosts and 52 routers) using multiple interfaces and the scenarios where this may 53 end up using multiple global addresses on their interfaces. Such 54 multihoming configurations can bring a number of benefits once 55 appropriate support mechanisms are put in place. Interestingly, this 56 analysis is generic, i.e. motivations and benefits of node 57 multihoming apply to both fixed end nodes and mobile end nodes. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Scenarios and Motivations . . . . . . . . . . . . . . . . . . 6 66 3.1. Need for Ubiquitous Access to the Internet . . . . . . . . 6 67 3.2. Need to Redirect Established Sessions . . . . . . . . . . 6 68 3.3. Need to Set Up Preferences . . . . . . . . . . . . . . . . 6 69 3.4. Need to Select the Best Access Technology . . . . . . . . 7 70 3.5. Need to Dispatch Traffic over Distinct Paths . . . . . . . 8 71 3.6. Need for Reliability . . . . . . . . . . . . . . . . . . . 8 72 3.7. Need to Accelerate Transmission . . . . . . . . . . . . . 8 74 4. Goals and Benefits of Multihoming . . . . . . . . . . . . . . 10 75 4.1. Permanent and Ubiquitous Access . . . . . . . . . . . . . 11 76 4.2. Reliability . . . . . . . . . . . . . . . . . . . . . . . 11 77 4.3. Load Sharing . . . . . . . . . . . . . . . . . . . . . . . 11 78 4.4. Load Balancing/Flow Distribution . . . . . . . . . . . . . 11 79 4.5. Preference Settings . . . . . . . . . . . . . . . . . . . 11 80 4.6. Aggregate Bandwidth . . . . . . . . . . . . . . . . . . . 12 82 5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 5.1. Case 1: One Interface, Multiple Prefixes . . . . . . . . . 13 84 5.2. Case 2: Several Interfaces . . . . . . . . . . . . . . . . 14 86 6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 6.1. Address Selection . . . . . . . . . . . . . . 17 88 6.2. Failure Discovery and Recovery Delay . . . . . . . . . . . 17 89 6.3. Change of Traffic Characteristics . . . . . . . . . . . . 18 90 6.4. Address Change . . . . . . . . . . . . . . . . . . . . . . 18 92 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 100 Intellectual Property and Copyright Statements . . . . . . . . . . 24 102 1. Introduction 104 New equipments shipped on the market now often integrate several 105 access technologies (both wired and wireless). The main purpose of 106 this integration is to federate all means of communications in order 107 to access the Internet ubiquitously (from everywhere and at any time) 108 as no single technology can be expected to be deployed everywhere. 109 Flows may thus be redirected from one interface to the other 110 following the loss of connectivity or change of the network 111 conditions. Besides providing an Internet access of wide spread and 112 reach, integrating several access technologies also allow to increase 113 bandwidth availability or to select the the most appropriate 114 technology according to the type of flow or choices of the user, 115 since each network interface has different cost, performance, 116 bandwidth, access range, and reliability. 118 Once multiple accesses are offered, users may want to select the most 119 appropriate set of network interface(s) depending on the network 120 environment, particularly in wireless networks which are mutable and 121 less reliable than wired networks. Users may also want to select the 122 most appropriate interface per communication type or to combine a set 123 of interfaces to get sufficient bandwidth. 125 The purpose of this document is to emphasize the goals and benefits 126 of multihoming for fixed and mobile hosts and routers in a generic 127 fashion, i.e. without focusing on issues pertaining to hosts, or 128 routers, nor mobility. This document is indeed completing other 129 documents focusing on these latter issues: Issues pertaining to site 130 multihoming in fixed networks are discussed in [1]. Mobility issues 131 pertaining to mobile nodes and mobile networks are respectively 132 discussed in companion drafts [2] and [3]. Our document is targetted 133 to IPv6, although our analysis may be applicable to IPv4 as well. 134 The readers may refer to [4] for a description of the problem 135 specific to Mobile IPv4. 137 This document is organized as follows: first, the terms used in the 138 document are defined before illustrating the motivations by means of 139 some scenarios in Section 3. These scenarios are then used to 140 emphasize the goals and benefits of multihoming in Section 4. Next 141 follows in Section 5 an analysis of the achievable goals in two 142 multihoming configurations, i.e. when the node either has a single 143 interface or when it has multiple interfaces. Section 6 concludes 144 this document with a number of generic issues that will have to be 145 solved in order to effectively meet multihoming goals and benefits. 147 2. Terminology 149 This draft is based on the terminology defined in [5]. For the 150 purpose of clarity, we remind the definition of interface. Terms 151 related to multihoming are not known to be defined in existing IETF 152 RFCs. 154 Interface 156 A node's point of attachment to a link (as defined in [5]) 158 Multihomed Node 160 A node (either a host or a router) is multihomed when it has 161 several IPv6 addresses to choose between, i.e. in the following 162 cases when it is either: 164 * multi-prefixed: multiple prefixes are advertised on the link(s) 165 the node is attached to, or. 167 * multi-interfaced: the node has multiple interfaces to choose 168 between, on the same link or not. 170 3. Scenarios and Motivations 172 The following real-life scenarios highlight the motivations for 173 multihoming. Each scenario usually yields more than one of the goals 174 and benefits outlined in Section 4. All scenarios focus on wireless 175 technologies though no mobility management may be involved (one can 176 use wireless access at office). 178 3.1. Need for Ubiquitous Access to the Internet 180 Mona is just getting out of a meeting with customers in a building. 181 She calls her head office. This audio communication is initiated via 182 a private wireless local area network (WLAN) link realized over one 183 of the available WI-FI hot-spots in the building. This is going to 184 be a long call and she must attend another meeting a few minutes 185 drive from here. She walks to a taxi stand, and boards a taxi. The 186 audio communication is automatically transferred to the public 187 wireless metropolitan area network (WMAN) over the WIMAX network 188 deployed in the city, with no interruption of the communication. 190 This scenario illustrates the need for a mobile user to use multiple 191 types of access technologies in order to maintain ongoing 192 communications when a user is moving out of the coverage area of a 193 specific technology. 195 3.2. Need to Redirect Established Sessions 197 Oliver is on his way to work waiting at a train station. He uses 198 this opportunity and the presence of a WLAN hot-spot to download the 199 news from his favorite on-line news channel. While Oliver is 200 downloading the news, he receives a phone call over a wide area 201 cellular link. Oliver decides he wishes to initiate a video flow for 202 this communication. The bandwidth and traversal delay of the wide 203 area cellular link is not adequate for the video conference, so both 204 flows (video/audio) are transferred to the WLAN link provided by the 205 hot-spot. This transfer occurs transparently and without affecting 206 the other active flows. 208 This scenario illustrates the need for a nomadic user to dynamically 209 redirect flows from one type of access technology to another based on 210 some user preferences or traffic requirements. 212 3.3. Need to Set Up Preferences 214 Nami works at home for a publishing company. She has an in-house 215 network and get access to the Internet via ADSL, a public 802.11b 216 WLAN from the street and satellite. She has subscribed to the 217 cheapest ADSL service with limited uplink bandwidth. Also, the 218 satellite link she has access to is downlink only, but it is 219 extremely cheap for TV broadcasting. She has noticed the 802.11b 220 link is unreliable at some point in time during the day, so she 221 chooses to send requests and periodic refreshments for joining the TV 222 broadcasting via ADSL rather than 802.11b although it is free. On 223 the other hand, she has configured her network to use the 802.11b 224 link at night to publish web content comprising video. Once a week, 225 she communicates with overseas peer staff by videoconferencing. 226 Voice being the most important, she has configured her VoIP session 227 over ADSL. Video is sent at maximum rate when 802.11b is working 228 fine, otherwise the video is sent at lower rate. 230 This scenario illustrates the need in a fixed environment to 231 simultaneously use multiple access technologies and to select the 232 most appropriate one according to user preferences. No assumptions 233 are made whether flows need to be redirected or not from one access 234 technology to another. 236 3.4. Need to Select the Best Access Technology 238 Alice is a paramedic. Her ambulance is called at the scene of a car 239 accident. She initiates a communication to a hospital via a wide 240 area cellular link for the relay of low bit-rate live video from the 241 site of the crash to assess the severity of the accident. It is 242 identified that one of the passengers has suffered a severe head 243 injury. The paramedic decides to consult a specialist via video 244 conferencing. This session is initiated from the specialist via the 245 same wide area cellular link. Meanwhile, the paramedic requests for 246 the download of the patient medical records from the hospital 247 servers. The paramedic decides in mid-session that the wide area 248 cellular link is too slow for this download and transfers the 249 download to the ambulance satellite link. Even though this link 250 provides a significantly faster bit rate it has a longer traversal 251 delay and only down-link is available. For this, only the down- 252 stream of the download is transferred while up-stream proceeds over 253 the wide area cellular link. Connectivity with the ambulance is 254 managed over a WLAN link between the paramedic and the ambulance. 255 Even though the paramedic has performed a partial hand-off for the 256 transfer of the download down-stream to the satellite link, the 257 upstream and the video conferencing session remains on the wide area 258 cellular link. This serves best the time constraint requirements of 259 the real time communications. 261 This scenario illustrates the need in a mobile environment for both 262 ubiquitous access to the Internet using whatever available interface 263 and the need to dispatch flows to particular access media according 264 to traffic characteristics or preferences. The fact that the actual 265 connexion to the Internet is maintained via the ambulance to which 266 the paramedic is connected to via a WLAN link illustrates to need to 267 express preferences on the path to be taken from a remote computer 268 (i.e. a mobile router in the ambulance in this case). 270 3.5. Need to Dispatch Traffic over Distinct Paths 272 Max drives his car and constantly keeps some sort of Internet 273 connectivity through one of the available access technologies. His 274 car navigator downloads road information from the Internet and his 275 car-audio plays on-line audio streaming. When his car passes an area 276 where both high-data-rate WLAN and low-data rate cellular network are 277 available, it distributes load to the WLAN access and the cellular 278 network access. When his car passes an area where only a wide 279 coverage-range cellular network is available, the connection is 280 maintained via the cellular network. 282 This scenario illustrates the need to save traffic transiting in a 283 particular access network when there is a possibility to send data 284 over an alternative route. 286 3.6. Need for Reliability 288 Dr. Ingrid performs an operation via long-distance medical system. 289 She watches a patient in a battle field over the screen which 290 delivers real-time images of the patient. Sensors on her arms 291 deliver her operational actions and a robot performs the actual 292 operation in the battle field. Since the operation is critical, the 293 delivery of patient images and Dr. Ingrid's action is done by bi- 294 casting from/to multiple interfaces bound to a distinct technology or 295 distinct radio range. So in case packets are delayed or one of the 296 interface fails to maintain connectivity to the network, her distant 297 operation can be continued. 299 This scenario illustrates the need to use multiple access 300 technologies in order to improve reliability upon failure of one of 301 the access technologies. 303 3.7. Need to Accelerate Transmission 305 Roku is at the airport waiting to board the plane. She receives a 306 call from her husband. This audio communication is received via a 307 wireless local area network (WLAN) link realized over one of the 308 available hot-spots. She knows this is going to be a long flight and 309 wishes to catch up on some work. Roku uses a WLAN connection to 310 download the necessary data. However, there is not enough time and 311 she decides to accelerate the download. Her notebook is equipped 312 with an additional WLAN interface. She decides to use this 313 additional WLAN interface to connect to another access point, and 314 distribute the different download flows between the two wireless 315 interfaces. 317 This scenario illustrates the need to use multiple accesses to the 318 Internet in order to accelerate the amount of data that could be 319 transmitted over a period of time. 321 4. Goals and Benefits of Multihoming 323 The scenarios presented in the previous section are now used to 324 highlight the goals and benefits of node multihoming. The goals 325 cannot really be distinguished from the benefits, but there are 326 several situations where multihomed is either advisable or 327 beneficial. 329 Figure 1 summarizes which goal applies to the scenarios introduced in 330 Section 3. Note that all these goals and benefits apply to both 331 fixed end nodes and mobile end nodes, though the scenarios may either 332 focused on a fixed used (F), or nomadic usage (N), or a mobile usage 333 (M). Nomadic and mobile users are both on the move, while a fixed 334 user doesn't physically move. The difference between nomadic usages 335 and mobile usages is that sessions are not required to be maintained 336 when the access network is changed as a result of physical move 337 within the topology. No assumptions are made whether mobility 338 support mechanims may be useful or not in any of the fixed, nomadic 339 and mobile usages in order to maintain sessions. This is out of 340 scope of the present document. 342 +===================================+===========================+ 343 | | Scenarios | | 344 | +---+---+---+---+---+---+---+ 345 | Goals | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 346 +===================================+===+===+===+===+===+===+===+ 347 | Ubiquitous Access | o | | | o | o | | | 348 +-----------------------------------+---+---+---+---+---+---+---+ 349 | Flow Redirection | o | o | o | o | o | | | 350 +-----------------------------------+---+---+---+---+---+---+---+ 351 | Reliability | | | o | o | o | o | | 352 +-----------------------------------+---+---+---+---+---+---+---+ 353 | Load Sharing | | | | | o | | | 354 +-----------------------------------+---+---+---+---+---+---+---+ 355 | Load Balalancing | | | o | o | | | o | 356 +-----------------------------------+---+---+---+---+---+---+---+ 357 | Preference Settings | | o | o | o | | | | 358 +-----------------------------------+---+---+---+---+---+---+---+ 359 | Aggregate Bandwidth | | | | o | | | o | 360 +===================================+===+===+===+===+===+===+===+ 361 | Usage: F=Fixed N=Nomadic M=Mobile | M | N | F | M | M | F | N | 362 +===================================+===+===+===+===+===+===+===+ 364 Figure 1: Goals Applying to Each Scenario 366 4.1. Permanent and Ubiquitous Access 368 To provide an extended coverage area via distinct access 369 technologies. 371 Multiple interfaces bound to distinct technologies can be used to 372 ensure a permanent connectivity is offered, anywhere, anytime, with 373 anyone. 375 4.2. Reliability 377 To act upon failure at one point of attachment, i.e. the functions of 378 a system component (e.g. interface, access network) are assumed by 379 secondary system components when the primary component becomes 380 unavailable (e.g. failure). Connectivity is guaranteed as long as at 381 least one connection to the Internet is maintained. 383 A potential means is to duplicate network component, another is to 384 duplicate a particular flow simultaneously through different routes. 385 This minimizes packet loss typically for real-time communication and 386 burst traffic. It also minimizes delay of packet delivery caused by 387 congestion and achieves more reliable real-time communication than 388 single-casting. For mobile computing, bi-casting avoids dropping 389 packets when a mobile node changes its interface during communication 390 [6]. 392 4.3. Load Sharing 394 To spread network traffic load among several routes. This is 395 achieved when traffic load is distributed among different connections 396 between the node and the Internet [7]. 398 4.4. Load Balancing/Flow Distribution 400 To separate a flow between multiple points of attachment 401 (simultaneously active or not) of a node, usually chosing the less 402 loaded connection or according to preferences on the mapping between 403 flows and interfaces. 405 4.5. Preference Settings 407 This goal is to provide the user, the application or the ISP the 408 ability to choose the preferred transmission technology or access 409 network based on cost, efficiency, policies, bandwidth requirement, 410 delay, etc. 412 4.6. Aggregate Bandwidth 414 This goal is to provide the user or the application with more 415 bandwidth. 417 Bandwidth available to the user or the application may be limited by 418 the underlying technology (e.g. GSM has scarce bandwidth) or by some 419 policies (e.g. monthly rate paid by the user). Multiple interfaces 420 connected to different links or ISPs can increase the total bandwidth 421 available to the user or application. 423 5. Analysis 425 From the definition of a multihomed node it follows that a multihomed 426 node has several IPv6 addresses to choose between. In order to 427 expose the goals and benefits to manage multihomed nodes, we propose 428 to distinguish two main cases: either the node has only one 429 interface, or the node has several interfaces. In the former case, 430 the node is multihomed when multilpe prefixes are advertised on the 431 link the node is attached to. This distinction is important and 432 sometimes subtle but the implications are important. 434 5.1. Case 1: One Interface, Multiple Prefixes 436 The single-interfaced node is multihomed when several prefixes are 437 advertised on its interface. The node must therefore configure 438 several IPv6 addresses. 440 A typical example is a node with a 802.11b interface, connected to an 441 access point. The access point is connected trough an Ethernet link 442 to two access routers. Each access router is configured to advertise 443 distinct network prefixes by Router Advertisements on the link and 444 can be used as default router. Several reasons may lead to configure 445 two access routers on the same link: for instance, the access points 446 may be shared between different ISPs, or two access routers may be 447 used for redundancy or load sharing purposes. The node will then 448 build two global IPv6 addresses on its interface. 450 We now analyse which of the goals detailed in Section 4 can be met 451 with this configuration. 453 o Ubiquitous Access: NO 455 Ubiquitous access cannot be guaranteed when the node looses 456 Internet connectivity through its sole interface (e.g. the node is 457 going outside the coverage area of its access point). 459 o Reliability: MAYBE 461 In case of failure of one IPv6 prefix, one of the address of the 462 node will not be valid anymore. Another available address built 463 from other prefixes may allow the node to recover this sort of 464 failure. 466 Bi-casting can be performed to ensure the delivery of packets on 467 the node. To do so, more than one IPv6 address must be used 468 simultaneously for one flow. Bi-casting would allow the node to 469 seamlessly change the address used on the node. 471 o Load sharing: YES 473 Load Sharing can be performed in the network, according to the 474 address used by the node. The choice of the address used by the 475 node and the router selection can be influenced by the load 476 sharing rules. This mostly benefits the network side: if 477 different access routers or routes can be used to forward the 478 node's traffic, it will share the traffic load on the network. 480 o Load balancing/Flow Distribution: NO 482 Load balancing cannot be performed as the node has only one 483 interface. 485 o Preferences: YES 487 The source address can be chosen according to preferences set up 488 by the user, or according to preferences set up in the network 489 (such as with the default router preferences option introduced in 490 Router Advertisement [8], or by the ISP. 492 o Aggregated Bandwidth: MAYBE 494 With only one interface connected to a link, the node generally 495 will not be able to benefit from an increased aggregated bandwidth 496 with multiple prefixes. However, this benefit might be gained 497 indirectly. For instance, by alternating between different 498 addresses, the total throughput may be higher (eg. due to load 499 sharing). Also, some web and file transfer servers limit transfer 500 bandwidths based on the client's address. By using different 501 addresses to connect to the same server, the node may also see an 502 increase in file transfer rate. 504 5.2. Case 2: Several Interfaces 506 In this case, the node may use its multiple interfaces either 507 alternatively or simultaneously. If used simultaneously, the node 508 uses several IPv6 addresses at the same time (at least one address 509 per interface, or several if several prefixes are announced on the 510 link(s) it is connected to). If used alternatively, the node may 511 switch between its interfaces (e.g, one at a time), which is the case 512 described above in Section 5.1. In the paragraphs below, we assume 513 that multiple interfaces are used simultaneously. We also note that 514 multiple interfaces can be connected to the same link as well as to 515 different links. These configurations will imply different issues. 516 All these multihomed configurations may yield different benefits to 517 the node. 519 A typical example is a node with two interfaces, each one on a 520 different technology (e.g. a WLAN 802.11b interface and a 3GPP GPRS 521 interface), in order to benefit from a better coverage area and the 522 characteristics of each technology. 524 We now analyse how each of the goals listed in Section 4 can be met 525 with such multihomed configuration: 527 o Ubiquitous Access: MAYBE 529 It is easier to guarantee ubiquitous access when the node has 530 multiple interfaces since distinct technologies may be available 531 at a given time according to the location and administrative 532 policies. 534 o Reliability: YES 536 Two levels of redundancy can be seen in this case: either one 537 address of one interface is not valid anymore (e.g. because the 538 corresponding prefix is not advertised on the link), or the node 539 loses its internet connectivity through one interface. In the 540 former case, another IPv6 address available on the interface would 541 allow the node to switch addresses for on-going flows. In the 542 latter case, another connection to the internet through another 543 interface would allow it to redirect on-going flow from the 544 previous interface to the new one. In either cases the node needs 545 to change the IPv6 address for on-going sessions from the no 546 longer valid address to one of the address available on the target 547 interface. The redirection will trigger a decision process to 548 choose the best target interface to redirect the flow to. 550 Bi-casting might be used to ensure the packets delivery on the 551 node. It would also allow seamless redirection between two 552 addresses / interfaces with zero packets loss. Bi-casting can be 553 performed if several IPv6 addresses can be simultaneously used for 554 one flow. One entity between the CN (included) and the node 555 (excluded) must duplicate the traffic to the destination node. 557 o Load Sharing: YES 559 This benefit is mainly for the network side: if different access 560 routers or routes can be used to forward traffic going into and 561 out of the node, they can share the traffic load on the network. 562 If the node uses several addresses at the same time for its on- 563 going sessions, load sharing can be performed in the network. 564 This goal can be a parameter that helps the source address 565 selection. 567 o Load balancing/Flow Distribution: YES 569 Load balancing can be achieved on the node if several interfaces 570 are used simultaneously. Several interfaces can be used to spread 571 the traffic load on the node. This implies the choice of the IPv6 572 address to use for each flow and the ability to choose a different 573 address for each flow. 575 o Preferences: YES 577 Interface and address selection is required. The problem can be 578 seen exactly as in the first case (the node has only one 579 interface) if we consider that the interface preference is a 580 parameter for the address selection. Therefore in this case, the 581 interface selection/preference is a supplementary parameter in the 582 address selection algorithm. 584 o Aggregated Bandwidth: YES 586 With multiple interfaces connected to a link, the node generally 587 will be able to benefit from an increased aggregated bandwidth. 589 6. Issues 591 In this section, we attempt to list a number of generic issues that 592 will have to be solved in order to meet the multihoming goals. 594 Figure 2 summarizes which issues apply to each of the case detailed 595 in the previous section. The sign '+', '-' or '=' indicated is the 596 issue is more important, less important, or equally important to 597 solve for the case under consideration 599 +====================================+=====+=====+ 600 | | Cases | 601 | +-----+-----+ 602 | Issues | (1) | (2) | 603 +====================================+=====+=====+ 604 | Source Address Selection | o = | o = | 605 +------------------------------------+-----+-----+ 606 | Recovery Delay | o | o + | 607 +------------------------------------+-----+-----+ 608 | Change of e2e Path Characteristics | o - | o + | 609 +------------------------------------+-----+-----+ 610 | Address Change | o + | o + | 611 +====================================+=====+=====+ 613 Figure 2: Issues and their Importance for Each Case 615 6.1. Address Selection 617 The multihomed node has several addresses, which implies the 618 appropriate address must be chosen when an IPv6 communication is 619 established (e.g. when a TCP connection is opened). An address 620 selection mechanism is therefore needed. 622 The choice of the address can be influenced by many parameters: user 623 preferences, ingress filtering, preference flag in Router 624 Advertisement, destination prefix, type of interface, link 625 characteristics, etc. 627 6.2. Failure Discovery and Recovery Delay 629 A particular access to the Internet may become unavailable while it 630 is being used. The time needed for detecting an address has become 631 invalid and the time to redirect communications to one of its other 632 addresses is considered as critical. Efficient failure detection and 633 recovery mechanisms are therefore required. 635 Note that transport sessions with multihoming capabilies such as SCTP 636 may be able to continue easily since SCTP has built-in transmission 637 rate control mechanims to take into account the differences between 638 two paths. 640 6.3. Change of Traffic Characteristics 642 The change of path for a specific session (e.g. due to change of 643 interface) may cause changes on the end-to-end path characteristics 644 (higher delay, different PMTU, etc). This could have an impact on 645 upper layer protocols such as transport protocols (particularly TCP) 646 or applications that are sensitive to changes. 648 6.4. Address Change 650 In some situations, it will be necessary to divert some or all of the 651 sessions from one interface or prefix to another (e.g. due to loss of 652 network connection or the access router becoming unreachable - this 653 could be particularly frequent for mobile nodes). With no support 654 mechanism, an address change would cause on-going sessions using the 655 invalid former address to terminate, and to be restarted using the 656 new address. To avoid this, the node needs a recovery mechanism 657 allowing to redirect all current communications to one of its other 658 IPv6 addresses. 660 In the case of a mobile node changing its point of attachment using 661 the same interface, all flows must be redirected to the new location 662 in order to maintain sessions. A mobility management solution may be 663 required, such as Mobile IPv6 [9] for mobile hosts or NEMO Basic 664 Support [10] for mobile routers. Additional mechanisms may be needed 665 if the node was using several addresses on its old link, such as 666 which flow to redirect, which address must be associated with the new 667 address(es). The scalability of the operations involved in the 668 redirection of flows may also be an issue, if we consider that the 669 node had several addresses on the old link and several flows and/or 670 correspondents. Issues pertaining to Mobile IPv6 and NEMO Basic 671 Support are explained in companion drafts [2] and [3] respectively. 673 7. Conclusion 675 In this document we show the concrete need for multihoming at the 676 level of the end node. We emphasized the needs and goals of having 677 multiple interfaces at the communicating end node. Such interfaces 678 could be used as one as the replacement of the other (ubiquitous 679 access to the Internet, reliability) or simultaneously (load sharing, 680 load balancing/flow distribution, preference settings or aggregate 681 bandwidth). 683 Such goals are motivated for fixed nodes and mobile nodes, but the 684 needs prevail for mobile nodes (hosts and routers). Goals can only 685 be met once some issues are solved. Issues specific to mobile hosts 686 and mobile routers are investigated in documents of the MONAMI6 and 687 NEMO working groups at the IETF. 689 8. Contributors 691 This document is based on an earlier document to which Thomas Noel 692 (ULP, Strasbourg) and EunKyoung Paik (SNU, Seoul) also participated 693 in the addition to the authors listed in the present document. 695 9. Acknowledgments 697 We would like to thank all the people who have provided comments on 698 this draft, and also co-authors of earlier documents in which authors 699 of this present document have been engaged. As such, we would like 700 to thank Niko A. Fikouras, Hesham Soliman, Ken Nagami, and many 701 others. 703 10. References 705 [1] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 706 Multihoming Architectures", RFC 3582, August 2003. 708 [2] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. 709 Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 710 draft-ietf-monami6-mipv6-analysis-00 (work in progress), 711 February 2006. 713 [3] Ng, C., "Analysis of Multihoming in Network Mobility Support", 714 draft-ietf-nemo-multihoming-issues-05 (work in progress), 715 February 2006. 717 [4] Fikouras, N., "Mobile IPv4 Flow Mobility Problem Statement", 718 draft-nomad-mip4-flow-mobility-pb-00.txt (work in progress), 719 Feb 2004. 721 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", 722 RFC 3753, June 2004. 724 [6] Malki, K. and H. Soliman, "Simultaneous Bindings for Mobile 725 IPv6 Fast Handovers", draft-elmalki-mobileip-bicasting-v6-06 726 (work in progress), July 2005. 728 [7] Hinden, R. and D. Thaler, "IPv6 Host to Router Load Sharing", 729 draft-ietf-ipv6-host-load-sharing-04 (work in progress), 730 June 2005. 732 [8] Draves, R. and D. Thaler, "Default Router Preferences and More- 733 Specific Routes", RFC 4191, November 2005. 735 [9] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 736 IPv6", RFC 3775, June 2004. 738 [10] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 739 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 740 January 2005. 742 Authors' Addresses 744 Thierry Ernst 745 Keio University / WIDE 746 Jun Murai Lab., Keio University. 747 K-square Town Campus, 1488-8 Ogura, Saiwa-Ku 748 Kawasaki, Kanagawa 212-0054 749 Japan 751 Phone: +81-44-580-1600 752 Fax: +81-44-580-1437 753 Email: ernst@sfc.wide.ad.jp 754 URI: http://www.sfc.wide.ad.jp/~ernst/ 756 Nicolas Montavont 757 Ecole Nationale Superieure des telecommunications de Bretagne 758 2, rue de la chataigneraie 759 Cesson Sevigne 35576 760 France 762 Phone: (+33) 2 99 12 70 23 763 Email: nicolas.montavont@enst-bretagne.fr 764 URI: http://www-r2.u-strasbg.fr/~montavont/ 766 Ryuji Wakikawa 767 Keio University 768 Department of Environmental Information, Keio University. 769 5322 Endo 770 Fujisawa, Kanagawa 252-8520 771 Japan 773 Phone: +81-466-49-1100 774 Fax: +81-466-49-1395 775 Email: ryuji@sfc.wide.ad.jp 776 URI: http://www.wakikawa.net/ 777 Chan-Wah Ng 778 Panasonic Singapore Laboratories Pte Ltd 779 Blk 1022 Tai Seng Ave #06-3530 780 Tai Seng Industrial Estate 781 Singapore 534415 782 SG 784 Phone: +65 65505420 785 Email: chanwah.ng@sg.panasonic.com 787 Koojana Kuladinithi 788 University of Bremen 789 ComNets-ikom,University of Bremen. 790 Otto-Hahn-Allee NW 1 791 Bremen, Bremen 28359 792 Germany 794 Phone: +49-421-218-8264 795 Fax: +49-421-218-3601 796 Email: koo@comnets.uni-bremen.de 797 URI: http://www.comnets.uni-bremen.de/~koo/ 799 Intellectual Property Statement 801 The IETF takes no position regarding the validity or scope of any 802 Intellectual Property Rights or other rights that might be claimed to 803 pertain to the implementation or use of the technology described in 804 this document or the extent to which any license under such rights 805 might or might not be available; nor does it represent that it has 806 made any independent effort to identify any such rights. Information 807 on the procedures with respect to rights in RFC documents can be 808 found in BCP 78 and BCP 79. 810 Copies of IPR disclosures made to the IETF Secretariat and any 811 assurances of licenses to be made available, or the result of an 812 attempt made to obtain a general license or permission for the use of 813 such proprietary rights by implementers or users of this 814 specification can be obtained from the IETF on-line IPR repository at 815 http://www.ietf.org/ipr. 817 The IETF invites any interested party to bring to its attention any 818 copyrights, patents or patent applications, or other proprietary 819 rights that may cover technology that may be required to implement 820 this standard. Please address the information to the IETF at 821 ietf-ipr@ietf.org. 823 Disclaimer of Validity 825 This document and the information contained herein are provided on an 826 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 827 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 828 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 829 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 830 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 831 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 833 Copyright Statement 835 Copyright (C) The Internet Society (2006). This document is subject 836 to the rights, licenses and restrictions contained in BCP 78, and 837 except as set forth therein, the authors retain all their rights. 839 Acknowledgment 841 Funding for the RFC Editor function is currently provided by the 842 Internet Society.