idnits 2.17.1 draft-ietf-monami6-multihoming-motivation-scenario-02.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, updated by RFC 4748 on line 870. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 881. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 888. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 894. 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (July 12, 2007) is 6133 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 (-05) exists of draft-ietf-monami6-mipv6-analysis-03 == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-06 -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '10') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '11') (Obsoleted by RFC 6275) Summary: 3 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 INRIA 4 Expires: January 13, 2008 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 July 12, 2007 14 Motivations and Scenarios for Using Multiple Interfaces and Global 15 Addresses 16 draft-ietf-monami6-multihoming-motivation-scenario-02.txt 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 January 13, 2008. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2007). 47 Abstract 49 In this document, multihoming is investigated from an end-node point 50 of view, and not from a site point of view as the term "multihoming" 51 is commonly understood so far. The purpose of this document is to 52 explain the motivations for fixed and mobile nodes (hosts and 53 routers) using multiple interfaces and the scenarios where this may 54 end up using multiple global addresses on their interfaces. Such 55 multihoming configurations can bring a number of benefits once 56 appropriate support mechanisms are put in place. Interestingly, this 57 analysis is generic, i.e. motivations and benefits of node 58 multihoming apply to both fixed end nodes and mobile end nodes. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Scenarios and Motivations . . . . . . . . . . . . . . . . . . 6 67 3.1. Need for Ubiquitous Access to the Internet . . . . . . . . 6 68 3.2. Need to Redirect Established Sessions . . . . . . . . . . 6 69 3.3. Need to Set Up Preferences . . . . . . . . . . . . . . . . 6 70 3.4. Need to Select the Best Access Technology . . . . . . . . 7 71 3.5. Need to Dispatch Traffic over Distinct Paths . . . . . . . 8 72 3.6. Need for Reliability . . . . . . . . . . . . . . . . . . . 8 73 3.7. Need to Accelerate Transmission . . . . . . . . . . . . . 9 75 4. Goals and Benefits of Multihoming . . . . . . . . . . . . . . 10 76 4.1. Permanent and Ubiquitous Access . . . . . . . . . . . . . 11 77 4.2. Reliability . . . . . . . . . . . . . . . . . . . . . . . 11 78 4.3. Flow Redirection . . . . . . . . . . . . . . . . . . . . . 12 79 4.4. Load Sharing . . . . . . . . . . . . . . . . . . . . . . . 12 80 4.5. Load Balancing/Flow Distribution . . . . . . . . . . . . . 12 81 4.6. Preference Settings . . . . . . . . . . . . . . . . . . . 12 82 4.7. Aggregate Bandwidth . . . . . . . . . . . . . . . . . . . 12 84 5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 5.1. Case 1: One Interface, Multiple Prefixes . . . . . . . . . 13 86 5.2. Case 2: Several Interfaces . . . . . . . . . . . . . . . . 15 88 6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 6.1. Address Selection . . . . . . . . . . . . . . 18 90 6.2. Failure Discovery and Recovery Delay . . . . . . . . . . . 18 91 6.3. Change of Traffic Characteristics . . . . . . . . . . . . 19 92 6.4. Transparency . . . . . . . . . . . . . . . . . . . . . . . 19 94 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 98 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 100 10. Informative References . . . . . . . . . . . . . . . . . . . . 20 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 103 Intellectual Property and Copyright Statements . . . . . . . . . . 24 105 1. Introduction 107 New equipments shipped on the market now often integrate several 108 access technologies (both wired and wireless). The main purpose of 109 this integration is to federate all means of communications in order 110 to access the Internet ubiquitously (from everywhere and at any time) 111 as no single technology can be expected to be deployed everywhere. 112 Flows may thus be redirected from one interface to the other 113 following the loss of connectivity or change of the network 114 conditions. Besides providing an Internet access of wide spread and 115 reach, integrating several access technologies also allow to increase 116 bandwidth availability or to select the the most appropriate 117 technology according to the type of flow or choices of the user, 118 since each network interface has different cost, performance, 119 bandwidth, access range, and reliability. 121 Once multiple accesses are offered, users may want to select the most 122 appropriate set of network interface(s) depending on the network 123 environment, particularly in wireless networks which are mutable and 124 less reliable than wired networks. Users may also want to select the 125 most appropriate interface per communication type or to combine a set 126 of interfaces to get sufficient bandwidth. 128 The purpose of this document is to emphasize the goals and benefits 129 of multihoming for fixed and mobile hosts and routers in a generic 130 fashion, i.e. without focusing on issues pertaining to hosts, or 131 routers, nor mobility. This document is indeed completing other 132 documents focusing on these latter issues: Issues pertaining to site 133 multihoming in fixed networks are discussed in [1]. Mobility issues 134 pertaining to mobile nodes and mobile networks are respectively 135 discussed in companion drafts [2] and [3]. Our document is targetted 136 to IPv6, although our analysis may be applicable to IPv4 as well. 137 The readers may refer to [4] for a description of the problem 138 specific to Mobile IPv4. 140 This document is organized as follows: first, the terms used in the 141 document are defined before illustrating the motivations by means of 142 some scenarios in Section 3. These scenarios are then used to 143 emphasize the goals and benefits of multihoming in Section 4. Next 144 follows in Section 5 an analysis of the achievable goals in two 145 multihoming configurations, i.e. when the node either has a single 146 interface or when it has multiple interfaces. Section 6 concludes 147 this document with a number of generic issues that will have to be 148 solved in order to effectively meet multihoming goals and benefits. 150 2. Terminology 152 This draft is based on the terminology defined in [5]. For the 153 purpose of clarity, we remind the definition of interface. Terms 154 related to multihoming are not known to be defined in existing IETF 155 RFCs. 157 Interface 159 A node's point of attachment to a link (as defined in [5]) 161 Multihomed Node 163 A node (either a host or a router) is multihomed when it has 164 several IPv6 addresses to choose between, i.e. in the following 165 cases when it is either: 167 * multi-prefixed: multiple prefixes are advertised on the link(s) 168 the node is attached to, or. 170 * multi-interfaced: the node has multiple interfaces to choose 171 between, on the same link or not. 173 3. Scenarios and Motivations 175 The following real-life scenarios highlight the motivations for 176 multihoming. Each scenario usually yields more than one of the goals 177 and benefits outlined in Section 4. All scenarios focus on wireless 178 technologies though no mobility management may be involved (one can 179 use wireless access at office). 181 3.1. Need for Ubiquitous Access to the Internet 183 Mona is just getting out of a meeting with customers in a building. 184 She calls her head office. This audio communication is initiated via 185 a private wireless local area network (WLAN) link realized over one 186 of the available Wi-Fi hot-spots in the building. This is going to 187 be a long call and she must attend another meeting a few minutes 188 drive from here. She walks to a taxi stand, and boards a taxi. The 189 audio communication is automatically transferred to the public 190 wireless metropolitan area network (WMAN) over the Wi-Max 191 metropolitan network deployed, with no interruption of the 192 communication. 194 This scenario illustrates the need to use multiple types of access 195 technologies in order to maintain ongoing communications when a user 196 is moving out of the coverage area of a specific technology. 198 3.2. Need to Redirect Established Sessions 200 Oliver is in the passenger lounge waiting at his train. He uses this 201 opportunity and the presence of a WLAN hot-spot to download the news 202 from his favorite on-line news channel. While Oliver is downloading 203 the news, he receives a video call over his wide area 3G cellular 204 link. The bandwidth and traversal delay of the wide area cellular 205 link is not adequate for high quality video-conference, so both flows 206 (video/audio) are transferred to the WLAN link provided by the hot- 207 spot. This transfer occurs transparently and without affecting the 208 other active flows. 210 This scenario illustrates the need for a nomadic user to dynamically 211 redirect flows from one type of access technology to another based on 212 some user preferences or traffic requirements. 214 3.3. Need to Set Up Preferences 216 Nami works at home for a publishing company using her connection to 217 the Internet via a low-speed dial up connection, a public and 218 unrealiable 802.11b WLAN from the street and her 3G cellular phone. 219 Because the public WLAN is not secure, and the dial-up connection too 220 slow, she checks her company's email using her 3G phone even though 221 it is expensive. She uses the WLAN service for non-confidential 222 activities such as web-browsing and video-conferencing. The dial-up 223 connection is moslty used to transmit her completed work securely and 224 synchronizing her file system. 226 This scenario illustrates the need in a fixed environment to 227 simultaneously use multiple access technologies and to select the 228 most appropriate one according to user preferences. No assumptions 229 are made whether flows need to be redirected or not from one access 230 technology to another. These preferences can be dynamic (e.g. the 231 WLAN link is only used if the signal is good and there is no unusual 232 latency) or configured once for each application (e.g. applications 233 exchanging confidential data always over the most secure link). 235 3.4. Need to Select the Best Access Technology 237 Alice is a paramedic. Her ambulance is called to the scene of a car 238 accident. She initiates a communication to a hospital via a wide 239 area cellular link for the relay of low bit-rate live video from the 240 site of the crash to assess the severity of the accident. It is 241 identified that one of the passengers has suffered a severe head 242 injury. Alice decides to consult a specialist via video 243 conferencing. This session is initiated from the specialist via the 244 same wide area cellular link. Meanwhile, Alice requests for the 245 download of the patient medical records from the hospital servers. 246 The wide area cellular link is too slow for this download, so the 247 download is transfered to the ambulance satellite link. Even though 248 this link provides a significantly faster bit rate it has a longer 249 traversal delay and only down-link is available. For this, only the 250 down-stream of the download is transferred while up-stream proceeds 251 over the wide area cellular link. Connectivity between the parametic 252 and the ambulance is managed over a WLAN link. Even though Alice has 253 performed a partial hand-off for the transfer of the download down- 254 stream to the satellite link, the upstream and the video conferencing 255 session remains on the wide area cellular link. This serves best the 256 time constraint requirements of the real time communications. 258 This scenario illustrates the need in a mobile environment for both 259 ubiquitous access to the Internet using whatever available interface 260 and the need to dispatch flows to particular access media according 261 to traffic characteristics or preferences. It also illustrates that 262 flows can be directed to separate media downlink and uplink. The 263 fact that the actual connection to the Internet is maintained via the 264 ambulance to which the paramedic is connected to via a WLAN link 265 illustrates to need to express preferences on the path to be taken 266 from a remote computer (i.e. a mobile router in the ambulance in this 267 case). 269 3.5. Need to Dispatch Traffic over Distinct Paths 271 Max drives his car and constantly keeps some sort of Internet 272 connectivity through one of the many available access technologies 273 solely managed by a dedicated on-board unit (OBU). Data are further 274 transmitted to other on-board units. His car navigator downloads 275 road information from the Internet and his car-audio plays on-line 276 audio streaming while data collected by sensors is transmitted to the 277 car manufacturer (e.g. consumption, engine pressure) and safety data 278 is exchanged between surrounding vehicles (e.g. geographic position, 279 speed, brakes on/off, accident alerts). Toll bills are paid 280 automatically and displayed on his navigation screen, while road sign 281 transmit information (speed limitation, traffic lights). 283 When his car passes an area where only a wide coverage-range cellular 284 network is available, safety related sessions are maintained via the 285 cellular network whereas infotainment data is buffered and 286 transmitted over high data rate network access when one becomes 287 available. Toll bills and road sign data are transmitted over a 288 dedicated radio interface, whereas data exchanged between vehicles is 289 transmitted over a preferred media. Time-critical safety sessions 290 are always given priority. 292 This scenario illustrates the applicability of multihoming in road 293 transportation and emphasizes more particularly the need to save 294 traffic transiting in a particular access network when there is a 295 possibility to send data over an alternative route. The availability 296 of multiple access medium and the variety of on-board units 297 illustrates a NEMO [6] scenario as currently considered in the CALM 298 Architecture designed by ISO TC204 WG16 for Intelligent 299 Transportations Systems (ITS). The exchange of safety data 300 illustrates the ongoing work of the car-to-car communication 301 consortium (C2C-CC) 303 3.6. Need for Reliability 305 Ingrid, a doctor, performs an operation via long-distance medical 306 system. She watches a patient in a battle field over the screen 307 which delivers real-time images of the patient. Sensors on her arms 308 deliver her operational actions and a robot performs the actual 309 operation in the battle field. Since the operation is critical, the 310 delivery of patient images and Dr. Ingrid's action is done by bi- 311 casting from/to multiple interfaces bound to a distinct technology or 312 distinct radio range. So in case packets are delayed or one of the 313 interface fails to maintain connectivity to the network, her distant 314 operation can be continued. 316 This scenario illustrates the need to use multiple access 317 technologies in order to improve reliability upon failure of one of 318 the access technologies. 320 3.7. Need to Accelerate Transmission 322 Roku is at the airport waiting to board the plane. She receives a 323 call from her husband. This audio communication is received via a 324 WLAN link realized over one of the available hot-spots. She knows 325 this is going to be a long flight and wishes to catch up on some 326 work. Roku uses a WLAN connection to download the necessary data. 327 However, there is not enough time before boarding and she decides to 328 accelerate the download. Her notebook is equipped with an additional 329 WLAN interface. This additional WLAN interface is then used to 330 connect to another access point, and the different download flows are 331 distributed between the two wireless interfaces. 333 This scenario illustrates the need to use multiple accesses to the 334 Internet in order to accelerate the amount of data that could be 335 transmitted over a period of time. 337 4. Goals and Benefits of Multihoming 339 The scenarios presented in the previous section are now used to 340 highlight the goals and benefits of node multihoming. The goals 341 cannot really be distinguished from the benefits, but there are 342 several situations where multihomed is either advisable or 343 beneficial. These benefits and goals listed here are by no means 344 distinct and separate; most of them overlap with one another. It is 345 not the objective here to classify the benefits and goals into 346 different non-overlapping consituents. Instead the objective is to 347 list the possible benefits and goals different people have in mind 348 when deploying a multihomed node. 350 Figure 1 summarizes which goal applies to the scenarios introduced in 351 Section 3. Note that all these goals and benefits apply to both 352 fixed end nodes and mobile end nodes, though the scenarios may either 353 focus on a fixed used (F), or nomadic usage (N), or a mobile usage 354 (M). Nomadic and mobile users are both on the move, while a fixed 355 user doesn't physically move. The difference between nomadic usages 356 and mobile usages is that sessions are not required to be maintained 357 when the access network is changed as a result of physical move 358 within the topology. No assumptions are made whether mobility 359 support mechanims may be useful or not in any of the fixed, nomadic 360 and mobile usages in order to maintain sessions. This is out of 361 scope of the present document. 363 +===================================+===========================+ 364 | | Scenarios | | 365 | +---+---+---+---+---+---+---+ 366 | Goals | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 367 +===================================+===+===+===+===+===+===+===+ 368 | Ubiquitous Access | o | | | o | o | | | 369 +-----------------------------------+---+---+---+---+---+---+---+ 370 | Flow Redirection | o | o | o | o | o | | | 371 +-----------------------------------+---+---+---+---+---+---+---+ 372 | Reliability | | | o | o | o | o | | 373 +-----------------------------------+---+---+---+---+---+---+---+ 374 | Load Sharing | | | | | o | | | 375 +-----------------------------------+---+---+---+---+---+---+---+ 376 | Load Balancing | | | o | o | | | o | 377 +-----------------------------------+---+---+---+---+---+---+---+ 378 | Preference Settings | | o | o | o | | | | 379 +-----------------------------------+---+---+---+---+---+---+---+ 380 | Aggregate Bandwidth | | | | o | | | o | 381 +===================================+===+===+===+===+===+===+===+ 382 | Usage: F=Fixed N=Nomadic M=Mobile | M | N | F | M | M | F | N | 383 +===================================+===+===+===+===+===+===+===+ 385 Figure 1: Goals Applying to Each Scenario 387 4.1. Permanent and Ubiquitous Access 389 To provide an extended coverage area via distinct access 390 technologies. 392 Multiple interfaces bound to distinct technologies can be used to 393 ensure a permanent connectivity is offered, anywhere, anytime, with 394 anyone. 396 4.2. Reliability 398 To act upon failure at one point of attachment, i.e. the functions of 399 a system component (e.g. interface, access network) are assumed by 400 secondary system components when the primary component becomes 401 unavailable (e.g. failure). Connectivity is guaranteed as long as at 402 least one connection to the Internet is maintained. 404 A potential means is to duplicate network component, another is to 405 duplicate a particular flow simultaneously through different routes. 406 This minimizes packet loss typically for real-time communication and 407 burst traffic. It also minimizes delay of packet delivery caused by 408 congestion and achieves more reliable real-time communication than 409 single-casting. For mobile computing, bi-casting avoids dropping 410 packets when a mobile node changes its interface during communication 412 [7]. 414 4.3. Flow Redirection 416 To be able to redirect flows from one interface, or one address to 417 another one, without having to re-initiate the flow. This can be due 418 to preference changes or upon network failure. 420 4.4. Load Sharing 422 To spread network traffic load among several routes. This is 423 achieved when traffic load is distributed among different connections 424 between the node and the Internet [8]. 426 4.5. Load Balancing/Flow Distribution 428 To separate a flow between multiple points of attachment 429 (simultaneously active or not) of a node, usually chosing the less 430 loaded connection or according to preferences on the mapping between 431 flows and interfaces. 433 4.6. Preference Settings 435 This goal is to provide the user, the application or the ISP the 436 ability to choose the preferred transmission technology or access 437 network based on cost, efficiency, policies, bandwidth requirement, 438 delay, etc. 440 4.7. Aggregate Bandwidth 442 This goal is to provide the user or the application with more 443 bandwidth. 445 Bandwidth available to the user or the application may be limited by 446 the underlying technology (e.g. GSM has scarce bandwidth) or by some 447 policies (e.g. monthly rate paid by the user). Multiple interfaces 448 connected to different links or ISPs can increase the total bandwidth 449 available to the user or application. 451 5. Analysis 453 From the definition of a multihomed node it follows that a multihomed 454 node has several IPv6 addresses to choose between. In order to 455 expose the goals and benefits in managing multihomed nodes, we 456 propose to distinguish two main cases: either the node has only one 457 interface, or the node has several interfaces. In the former case, 458 the node is multihomed when multilpe prefixes are advertised on the 459 link the node is attached to. This distinction is important and 460 sometimes subtle but the implications are important. 462 5.1. Case 1: One Interface, Multiple Prefixes 464 The single-interfaced node is multihomed when several prefixes are 465 advertised on its interface. The node must therefore configure 466 several IPv6 addresses. 468 A typical example is a node with a 802.11b interface, connected to an 469 access point. The access point is connected trough an Ethernet link 470 to two access routers. Each access router is configured to advertise 471 distinct network prefixes by Router Advertisements on the link and 472 can be used as default router. Several reasons may lead to configure 473 two access routers on the same link: for instance, the access points 474 may be shared between different ISPs, or two access routers may be 475 used for redundancy or load sharing purposes. The node will then 476 build two global IPv6 addresses on its interface. 478 We now analyse which of the goals detailed in Section 4 can be met 479 with this configuration. 481 o Ubiquitous Access: NO 483 Ubiquitous access cannot be guaranteed when the node loses 484 Internet connectivity through its sole interface (e.g. the node is 485 going outside the coverage area of its access point). 487 o Flow redirection: YES 489 The node might need to redirect a flow from one address to another 490 for several reasons. For example, if one of the IPv6 prefix 491 becomes unavailable, flows using the address from this prefix 492 could be redirected to the address obtained on the other prefix. 494 o Reliability: MAYBE 495 In case of failure of one IPv6 prefix, one of the address of the 496 node will not be valid anymore. Another available address built 497 from other prefixes may allow the node to recover this sort of 498 failure. 500 Bi-casting can be performed to ensure the delivery of packets on 501 the node. To do so, more than one IPv6 address must be used 502 simultaneously for one flow. Bi-casting would allow the node to 503 seamlessly change the address used on the node. 505 o Load sharing: YES 507 Load Sharing can be performed in the network, according to the 508 address used by the node. The choice of the address used by the 509 node and the router selection can be influenced by load sharing 510 rules. This mostly benefits the network side: if different access 511 routers or routes can be used to forward the node's traffic, the 512 traffic load will be shared in the network. 514 o Load balancing/Flow Distribution: NO 516 Load balancing cannot be performed when the node has only one 517 interface. 519 o Preferences: YES 521 The source address can be chosen according to preferences set up 522 by the user, or according to preferences set up in the network 523 (such as with the default router preferences option introduced in 524 Router Advertisement [9]), or by the ISP. 526 o Aggregated Bandwidth: MAYBE 528 With only one interface connected to a link, the node generally 529 will not be able to benefit from an increased aggregated bandwidth 530 with multiple prefixes. However, this benefit might be gained 531 indirectly. For instance, by alternating between different 532 addresses, the total throughput may be higher (eg. due to load 533 sharing). Also, some web and file transfer servers limit transfer 534 bandwidths based on the client's address. By using different 535 addresses to connect to the same server, the node may also see an 536 increase in file transfer rate. 538 5.2. Case 2: Several Interfaces 540 In this case, the node may use its multiple interfaces either 541 alternatively or simultaneously. If used simultaneously, the node 542 uses several IPv6 addresses at the same time (at least one address 543 per interface, or several if several prefixes are announced on the 544 link(s) it is connected to). If used alternatively, the node may 545 switch between its interfaces (e.g, one at a time), which is the case 546 described above in Section 5.1. In the paragraphs below, we assume 547 that multiple interfaces are used simultaneously. We also note that 548 multiple interfaces can be connected to the same link as well as to 549 different links. These configurations will imply different issues. 550 All these multihomed configurations may yield different benefits to 551 the node. 553 A typical example is a node with two interfaces, each one on a 554 different technology (e.g. a WLAN 802.11b interface and a 3GPP GPRS 555 interface), in order to benefit from a better coverage area and the 556 characteristics of each technology. 558 We now analyse how each of the goals listed in Section 4 can be met 559 with such multihomed configuration: 561 o Ubiquitous Access: MAYBE 563 It is easier to guarantee ubiquitous access when the node has 564 multiple interfaces since distinct technologies may be available 565 at a given time according to the location and administrative 566 policies. 568 o Flow redirection: YES 570 In case of a change in user preferences, or a failure, flows might 571 need to be redirected from one interface to another one. Flows 572 can be redirected individually or all flows attached to an 573 interface might be redirected at once. 575 o Reliability: YES 577 Two levels of redundancy can be seen in this case: either one 578 address of one interface is not valid anymore (e.g. because the 579 corresponding prefix is not advertised on the link), or the node 580 loses its internet connectivity through one interface. In the 581 former case, another IPv6 address available on the interface would 582 allow the node to switch addresses for on-going flows. In the 583 latter case, another connection to the internet through another 584 interface would allow it to redirect on-going flow from the 585 previous interface to the new one. In either cases the node needs 586 to change the IPv6 address for on-going sessions from the no 587 longer valid address to one of the address available on the target 588 interface. The redirection will trigger a decision process to 589 choose the best target interface to redirect the flow to. 591 Bi-casting might be used to ensure the packets delivery on the 592 node. It would also allow seamless redirection between two 593 addresses / interfaces with zero packets loss. Bi-casting can be 594 performed if several IPv6 addresses can be simultaneously used for 595 one flow. One entity between the CN (included) and the node 596 (excluded) must duplicate the traffic to the destination node. 598 o Load Sharing: YES 600 This benefit is mainly for the network side: if different access 601 routers or routes can be used to forward traffic going into and 602 out of the node, they can share the traffic load on the network. 603 If the node uses several addresses at the same time for its on- 604 going sessions, load sharing can be performed in the network. 605 This goal can be a parameter that helps the source address 606 selection. 608 o Load balancing/Flow Distribution: YES 610 Load balancing can be achieved on the node if several interfaces 611 are used simultaneously. Several interfaces can be used to spread 612 the traffic load on the node. This implies the choice of the IPv6 613 address to use for each flow and the ability to choose a different 614 address for each flow. 616 o Preferences: YES 618 Interface and address selection is required. The problem can be 619 seen exactly as in the first case (the node has only one 620 interface) if we consider that the interface preference is a 621 parameter for the address selection. Therefore in this case, the 622 interface selection/preference is a supplementary parameter in the 623 address selection algorithm. 625 o Aggregated Bandwidth: YES 626 With multiple interfaces connected to different links, the node 627 generally will be able to benefit from an increased aggregated 628 bandwidth. 630 6. Issues 632 In this section, we attempt to list a number of generic issues that 633 will have to be solved in order to meet the multihoming goals. 635 Figure 2 summarizes which issues apply to which case detailed in the 636 previous section (availability of a single interface or multiple 637 interfaces). The sign '+', '-' or '=' indicates if the issue is more 638 important, less important, or equally important to solve for the case 639 under consideration 641 +====================================+=====+=====+ 642 | | Cases | 643 | +-----+-----+ 644 | Issues | (1) | (2) | 645 +====================================+=====+=====+ 646 | Source Address Selection | o = | o = | 647 +------------------------------------+-----+-----+ 648 | Recovery Delay | o | o + | 649 +------------------------------------+-----+-----+ 650 | Change of e2e Path Characteristics | o - | o + | 651 +------------------------------------+-----+-----+ 652 | Transparency | o + | o + | 653 +====================================+=====+=====+ 655 Figure 2: Issues and their Importance for Each Case 657 6.1. Address Selection 659 The multihomed node has several addresses, which implies the 660 appropriate address must be chosen when an IPv6 communication is 661 established (e.g. when a TCP connection is opened). An address 662 selection mechanism is therefore needed. 664 The choice of the address can be influenced by many parameters: user 665 preferences, ingress filtering, preference flag in Router 666 Advertisement, destination prefix, type of interface, link 667 characteristics, etc. 669 6.2. Failure Discovery and Recovery Delay 671 A particular access to the Internet may become unavailable while it 672 is being used. The time needed for detecting an address has become 673 invalid and the time to redirect communications to one of its other 674 addresses is considered critical. Efficient failure detection and 675 recovery mechanisms are therefore required. 677 Note that transport sessions with multihoming capabilies such as SCTP 679 [10] may be able to continue easily since SCTP has built-in 680 transmission rate control mechanims to take into account the 681 differences between two paths. 683 6.3. Change of Traffic Characteristics 685 The change of path for a specific session (e.g. due to change of 686 interface) may cause changes on the end-to-end path characteristics 687 (higher delay, different PMTU, etc). This could have an impact on 688 upper layer protocols such as transport protocols (particularly TCP) 689 or applications that are sensitive to changes. 691 6.4. Transparency 693 In some situations, it will be necessary to divert some or all of the 694 sessions from one interface or prefix to another (e.g. due to loss of 695 network connection or the access router becoming unreachable - this 696 could be particularly frequent for mobile nodes). With no support 697 mechanism, an address change would cause on-going sessions using the 698 invalid former address to terminate, and to be restarted using the 699 new address. To avoid this, a recovery mechanism allowing the 700 redirection of all current communications to one of the other IPv6 701 addresses is needed. 703 In the case of a mobile node changing its point of attachment using 704 the same interface, all flows must be redirected to the new location 705 in order to maintain sessions. A mobility management solution may be 706 required, such as Mobile IPv6 [11] for mobile hosts or NEMO Basic 707 Support [6] for mobile routers. Additional mechanisms may be needed 708 if the node was using several addresses on its previous link, such as 709 which flows shall be to redirected, which address must be associated 710 with the new address(es). The scalability of the operations involved 711 in the redirection of flows may also be an issue, if we consider that 712 the node had several addresses on the previous link and several flows 713 and/or correspondents. Issues pertaining to Mobile IPv6 and NEMO 714 Basic Support are explained in companion drafts [2] and [3] 715 respectively. 717 7. Conclusion 719 In this document we studied multihoming at the level of the end node. 721 A node is multihomed in a situation where it has multiple addresses, 722 usually due to the availability of multiple interfaces on the node, 723 or the announcement of multiple prefixes on the link it is attached 724 to. 726 This fits a number of needs and brings a number of potential 727 benefits. The availability of multiple addresses allows the use of 728 an alternate address as the replacement of another (permanent and 729 ubiquitous access to the Internet, reliability) or the transmission 730 of multiple flows simultaneously over different routes (flow 731 redirection, load sharing, load balancing/flow distribution, 732 preference settings or aggregate bandwidth). 734 This study is motivated for both fixed nodes and mobile nodes, but 735 the motivation prevails for mobile nodes (hosts and routers). The 736 benefits of multihoming can only be achieved once some issues are 737 solved. Generic issues were outlined in the present document, 738 whereas issues specific to mobile hosts and mobile routers are 739 investigated in the associated documents [2] and [3] and, 740 respectively. 742 8. Contributors 744 This document is based on an earlier document to which Thomas Noel 745 (ULP, Strasbourg) and EunKyoung Paik (SNU, Seoul) also contributed in 746 addition to the authors listed in the present document. 748 9. Acknowledgments 750 We would like to extend our gratitude to Niko A. Fikouras, Ken 751 Nagami, Pekka Savola, Hesham Soliman, and many others who had 752 provided valuable comments to this document. 754 10. Informative References 756 [1] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 757 Multihoming Architectures", RFC 3582, August 2003. 759 [2] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. 760 Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 761 draft-ietf-monami6-mipv6-analysis-03 (work in progress), 762 July 2007. 764 [3] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of Multihoming 765 in Network Mobility Support", 766 draft-ietf-nemo-multihoming-issues-06 (work in progress), 767 June 2006. 769 [4] Fikouras, N., "Mobile IPv4 Flow Mobility Problem Statement", 770 draft-nomad-mip4-flow-mobility-pb-00.txt (work in progress), 771 Feb 2004. 773 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", 774 RFC 3753, June 2004. 776 [6] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 777 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 778 January 2005. 780 [7] Malki, K. and H. Soliman, "Simultaneous Bindings for Mobile 781 IPv6 Fast Handovers", draft-elmalki-mobileip-bicasting-v6-06 782 (work in progress), July 2005. 784 [8] Hinden, R. and D. Thaler, "IPv6 Host to Router Load Sharing", 785 draft-ietf-ipv6-host-load-sharing-04 (work in progress), 786 June 2005. 788 [9] Draves, R. and D. Thaler, "Default Router Preferences and More- 789 Specific Routes", RFC 4191, November 2005. 791 [10] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 792 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 793 Paxson, "Stream Control Transmission Protocol", RFC 2960, 794 October 2000. 796 [11] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 797 IPv6", RFC 3775, June 2004. 799 Authors' Addresses 801 Thierry Ernst 802 INRIA 803 INRIA Rocquencourt 804 Domaine de Voluceau B.P. 105 805 Le Chesnay, 78153 806 France 808 Phone: +33-1-39-63-59-30 809 Fax: +33-1-39-63-54-91 810 Email: thierry.ernst@inria.fr 811 URI: http://www.nautilus6.org/~thierry 813 Nicolas Montavont 814 Ecole Nationale Superieure des telecommunications de Bretagne 815 2, rue de la chataigneraie 816 Cesson Sevigne 35576 817 France 819 Phone: (+33) 2 99 12 70 23 820 Email: nicolas.montavont@enst-bretagne.fr 821 URI: http://www-r2.u-strasbg.fr/~montavont/ 823 Ryuji Wakikawa 824 Keio University 825 Department of Environmental Information, Keio University. 826 5322 Endo 827 Fujisawa, Kanagawa 252-8520 828 Japan 830 Phone: +81-466-49-1100 831 Fax: +81-466-49-1395 832 Email: ryuji@sfc.wide.ad.jp 833 URI: http://www.wakikawa.org/ 834 Chan-Wah Ng 835 Panasonic Singapore Laboratories Pte Ltd 836 Blk 1022 Tai Seng Ave #06-3530 837 Tai Seng Industrial Estate 838 Singapore 534415 839 SG 841 Phone: +65 65505420 842 Email: chanwah.ng@sg.panasonic.com 844 Koojana Kuladinithi 845 University of Bremen 846 ComNets-ikom,University of Bremen. 847 Otto-Hahn-Allee NW 1 848 Bremen, Bremen 28359 849 Germany 851 Phone: +49-421-218-8264 852 Fax: +49-421-218-3601 853 Email: koo@comnets.uni-bremen.de 854 URI: http://www.comnets.uni-bremen.de/~koo/ 856 Full Copyright Statement 858 Copyright (C) The IETF Trust (2007). 860 This document is subject to the rights, licenses and restrictions 861 contained in BCP 78, and except as set forth therein, the authors 862 retain all their rights. 864 This document and the information contained herein are provided on an 865 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 866 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 867 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 868 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 869 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 870 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 872 Intellectual Property 874 The IETF takes no position regarding the validity or scope of any 875 Intellectual Property Rights or other rights that might be claimed to 876 pertain to the implementation or use of the technology described in 877 this document or the extent to which any license under such rights 878 might or might not be available; nor does it represent that it has 879 made any independent effort to identify any such rights. Information 880 on the procedures with respect to rights in RFC documents can be 881 found in BCP 78 and BCP 79. 883 Copies of IPR disclosures made to the IETF Secretariat and any 884 assurances of licenses to be made available, or the result of an 885 attempt made to obtain a general license or permission for the use of 886 such proprietary rights by implementers or users of this 887 specification can be obtained from the IETF on-line IPR repository at 888 http://www.ietf.org/ipr. 890 The IETF invites any interested party to bring to its attention any 891 copyrights, patents or patent applications, or other proprietary 892 rights that may cover technology that may be required to implement 893 this standard. Please address the information to the IETF at 894 ietf-ipr@ietf.org. 896 Acknowledgment 898 Funding for the RFC Editor function is provided by the IETF 899 Administrative Support Activity (IASA).