idnits 2.17.1 draft-ernst-generic-goals-and-benefits-01.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.a on line 28. -- Found old boilerplate from RFC 3978, Section 5.5 on line 785. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 762. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 769. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 775. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. 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 21, 2005) is 7003 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 (-06) exists of draft-elmalki-mobileip-bicasting-v6-05 -- Possible downref: Normative reference to a draft: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 3582 (ref. '3') ** Obsolete normative reference: RFC 3775 (ref. '4') (Obsoleted by RFC 6275) == Outdated reference: A later version (-07) exists of draft-ietf-ipv6-router-selection-06 == Outdated reference: A later version (-04) exists of draft-ietf-ipv6-host-load-sharing-03 == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-02 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-multihoming-issues (ref. '8') == Outdated reference: A later version (-05) exists of draft-montavont-mobileip-multihoming-pb-statement-03 -- Possible downref: Normative reference to a draft: ref. '9' -- Possible downref: Normative reference to a draft: ref. '10' Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 No Specific Working Group T. Ernst 3 Internet-Draft WIDE at Keio University 4 Expires: August 25, 2005 N. Montavont 5 LSIIT - ULP 6 R. Wakikawa 7 Keio University 8 E. Paik 9 KT 10 C. Ng 11 Panasonic Singapore Labs 12 K. Kuladinithi 13 University of Bremen 14 T. Noel 15 LSIIT - ULP 16 February 21, 2005 18 Goals and Benefits of Multihoming 19 draft-ernst-generic-goals-and-benefits-01 21 Status of this Memo 23 This document is an Internet-Draft and is subject to all provisions 24 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 25 author represents that any applicable patent or other IPR claims of 26 which he or she is aware have been or will be disclosed, and any of 27 which he or she become aware will be disclosed, in accordance with 28 RFC 3668. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as 33 Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on August 25, 2005. 48 Copyright Notice 49 Copyright (C) The Internet Society (2005). 51 Abstract 53 This document attempts to define the goals and benefits of 54 multihoming for fixed and mobile hosts and routers. Those goals and 55 benefits are illustrated with a set of scenarios. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Goals and Benefits of Multihoming . . . . . . . . . . . . . . 5 64 3.1 Permanent and Ubiquitous Access . . . . . . . . . . . . . 5 65 3.2 Redundancy/Fault-Recovery . . . . . . . . . . . . . . . . 5 66 3.3 Load Sharing . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.4 Load Balancing . . . . . . . . . . . . . . . . . . . . . . 6 68 3.5 Bi-casting (n-casting) . . . . . . . . . . . . . . . . . . 6 69 3.6 Preference Settings . . . . . . . . . . . . . . . . . . . 6 70 3.7 Increased Bandwidth . . . . . . . . . . . . . . . . . . . 6 72 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4.1 Load Balancing, Increased Bandwidth (no mobility) . . . . 7 74 4.2 Preference Settings and Transparent Flow Handoffs 75 (with mobility) . . . . . . . . . . . . . . . . . . . . . 7 76 4.3 Preference Settings for House Networking (fixed) . . . . . 7 77 4.4 Load Balancing, Preference Settings, Increased 78 Bandwidth (no mobility) . . . . . . . . . . . . . . . . . 8 79 4.5 Ubiquitous Access and Load Sharing (with mobility) . . . . 8 80 4.6 Redundancy and Bi-Casting (with no mobility) . . . . . . . 8 82 5. Classification . . . . . . . . . . . . . . . . . . . . . . . . 9 83 5.1 Case 1: One Interface, Multiple Prefixes . . . . . . . . . 9 84 5.2 Case 2: Several Interfaces . . . . . . . . . . . . . . . . 11 86 6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 6.1 Router Selection . . . . . . . . . . . . . . . . . . . . . 14 88 6.2 Source Address Selection . . . . . . . . . . . . . . . . . 14 89 6.3 Flow Redirection and Broken Sessions . . . . . . . . . . . 14 90 6.4 Recovery Delay . . . . . . . . . . . . . . . . . . . . . . 14 91 6.5 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 95 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 98 A. Change Log From Previous Version . . . . . . . . . . . . . . . 18 100 Intellectual Property and Copyright Statements . . . . . . . . 19 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 due to 110 the loss of connectivity or change of the network conditions. 112 Several access technologies are also integrated in order to increase 113 bandwidth availability or to select the technology the most 114 appropriate according to the type of flow or choices of the user. 115 Basically, each network interface has different cost, performance, 116 bandwidth, access range, and reliability. Users are also willing to 117 select the most appropriate set of network interface(s) depending on 118 the network environment, particularly in wireless networks which are 119 mutable and less reliable than wired networks. Users should also be 120 able to select the most appropriate interface per communication type 121 or to combine a set of interfaces to get sufficient bandwidth. 123 The purpose of this document is to emphasize the goals and benefits 124 of multihoming for fixed and mobile hosts and routers in a generic 125 fashion, i.e. without focusing on issues pertaining to hosts, or 126 routers, or mobility. 128 Issues pertaining to site multihoming in fixed networks are discussed 129 in [3]. Mobility issues pertaining to mobile nodes and mobile 130 networks are respectively discussed in companion drafts [9] and [8]. 131 Our document is targetted to IPv6, although our analysis may be 132 applicable to IPv4 as well. The readers may refer to [10] for a 133 description of the problem specific to Mobile IPv4. 135 This document is organized as follows: we first define the terms used 136 in the document before emphasizing the goals and benefits of 137 multihoming in Section 3. Then, the needs for multihoming are 138 illustrated through a set of scenarios in Section 4. Next follows an 139 analysis in Section 5 of two different cases where a multihomed node 140 has either a single interface or multiple interfaces. 142 2. Terminology 144 This draft is based on the terminology defined in [2]. For the 145 purpose of clarity, we remind the definition of interface. Terms 146 related to multihoming are not known to be defined in existing IETF 147 RFCs. 149 Interface 151 A node's point of attachment to a link (from [2]) 153 Multihomed Node 155 A node (either a host or a router) is multihomed when it has 156 several IPv6 addresses to choose between, i.e. in the following 157 cases when it is either: 159 * multi-prefixed: multiple prefixes are advertised on the link(s) 160 the node is attached to, or. 162 * multi-interfaced: the node has multiple interfaces to choose 163 between, on the same link or not. 165 Multihomed Network 167 From the above definition, it follows that a network is multihomed 168 when either the network is simultaneously connected to the 169 Internet via more than one router, or when a router is 170 multi-prefixed or multi-interfaced. 172 3. Goals and Benefits of Multihoming 174 We cannot distinguish the goals from the benefits of multihoming, but 175 there are several situations where it is either advisable or 176 beneficial to be multihomed: 178 3.1 Permanent and Ubiquitous Access 180 To provide an extended coverage area via distinct access 181 technologies. Multiple interfaces bound to distinct technologies can 182 be used to ensure a permanent connectivity is offered. 184 3.2 Redundancy/Fault-Recovery 186 To act upon failure of one point of attachment, i.e. the functions 187 of a system component are assumed by secondary system components when 188 the primary component becomes unavailable (e.g. failure). 189 Connectivity is guaranteed as long as at least one connection to the 190 Internet is maintained. 192 3.3 Load Sharing 194 To spread network traffic load among several routes. This is 195 achieved when traffic load is distributed among different connections 196 between the node and the Internet [7]. 198 3.4 Load Balancing 200 To balance load between multiple points of attachment (simultaneously 201 active or not), usually chosing the less loaded connection or 202 according to preferences on the mapping between flows and interfaces. 204 3.5 Bi-casting (n-casting) 206 To duplicate a particular flow simultaneously through different 207 routes. This minimizes packet loss typically for real-time 208 communication and burst traffic. It also minimizes delay of packet 209 delivery caused by congestion and achieves more reliable real-time 210 communication than single-casting. For mobile computing, bi-casting 211 avoids dropping packets when a mobile node changes its interface 212 during communication [1]. 214 3.6 Preference Settings 216 To provide the user or the application or the ISP the ability to 217 choose the preferred transmission technology or access network. for 218 matters of cost, efficiency, politics, bandwidth requirement, delay, 219 etc. 221 3.7 Increased Bandwidth 223 To provide the user or the application with more bandwidth than is 224 available with any one interface. Multiple interfaces connected to 225 different links can increase the total available bandwith. 227 4. Scenarios 229 The following real-life scenarios highlight the benefits of 230 multihoming. Each scenario usually yields more than one of the 231 benefits outlined in the above section. All scenarios focus on 232 wireless technologies though no mobility management may be involved 233 (one can use wireless access at office). 235 The first scenario focuses on using two wireless interfaces for the 236 purpose of increasing bandwidth while the second shows the usage of 237 preference settings. The third is a combination of the first two. 238 The fourth and fifth illustrate how multiple connections can provide 239 ubiquitous Internet access and how load can be balanced according to 240 some preferences. The last one illustrates redundancy and 241 bi-casting. 243 4.1 Load Balancing, Increased Bandwidth (no mobility) 245 Alice is at the airport waiting to board the plane. She receives a 246 call from her husband. This audio communication is received via a 247 wireless local area network (WLAN) link realized over one of the 248 available hot-spots. She knows this is going to be a long flight and 249 wishes to catch up on some work. Alice uses a WLAN connection to 250 download the necessary data. However, there is not enough time and 251 Alice decides to accelerate the download. Her notebook is equipped 252 with an additional WLAN interface. Alice decides to use this 253 additional WLAN interface to connect to another access point, and 254 distribute the different download flows between the two wireless 255 interfaces. 257 4.2 Preference Settings and Transparent Flow Handoffs (with mobility) 259 Mr. Smith is on his way to work waiting at a train station. He uses 260 this opportunity and the presence of a WLAN hot-spot to download the 261 news from his favorite on-line news channel. His train is announced. 262 Mr. Smith decides to buy a ticket. However, the ticket reservation 263 service is only available via a wide area cellular link of a specific 264 provider. While Mr. Smith is downloading the news and accessing the 265 train ticket reservation service, he receives a phone call over a 266 wide area cellular link. Mr. Smith decides he wishes to initiate a 267 video flow for this communication. The bandwidth and traversal delay 268 of the wide area cellular link is not adequate for the video 269 conference, so both flows (video/audio) are transferred to the WLAN 270 link provided by the hot-spot. This transfer occurs transparently 271 and without affecting any other active flows. 273 4.3 Preference Settings for House Networking (fixed) 275 Mr. Verne works at home for a publishing company. He has an 276 in-house network and get access to the Internet via ADSL, a public 277 802.11b WLAN from the street and satellite. He has subscribed to the 278 lowest ADSL service with limited upward bandwidth. The satellite 279 link he has access to is only downward but is extremely cheap for TV 280 broadcasting. He has noticed the 802.11b is unreliable at some point 281 in time during the day, so he chooses to send requests and periodic 282 refreshments for joining the TV broadcasting via ADSL rather the 283 802.11b although 802.11b in the street is free. On the other hand, 284 he has configured his network to use the 802.11b link at night to 285 publish web content comprising video. Once a week, he communicate 286 with overseas peer staff by videoconferencing. Voice being the most 287 important, he has configured his VoIP session over ADSL. Video is 288 sent at maximum rate when 802.11b is working fine, otherwise the 289 video is sent at lower rate. 291 4.4 Load Balancing, Preference Settings, Increased Bandwidth (no 292 mobility) 294 An ambulance is called at the scene of a car accident. A paramedic 295 initiates a communication to a hospital via a wide area cellular link 296 for the relay of low bit-rate live video from the site of the crash 297 to assess the severity of the accident. It is identified that one of 298 the passengers has suffered a severe head injury. The paramedic 299 decides to consult a specialist via video conferencing. This session 300 is initiated from the specialist via the same wide area cellular 301 link. Meanwhile, the paramedic requests for the download of the 302 patient medical records from the hospital servers. The paramedic 303 decides in mid-session that the wide area cellular link is too slow 304 for this download and transfers the download to the ambulance 305 satellite link. Even though this link provides a significantly 306 faster bit rate it has a longer traversal delay and only down-link is 307 available. For this, only the down-stream of the download is 308 transferred while up-stream proceeds over the wide area cellular 309 link. Connectivity with the ambulance is managed over a WLAN link 310 between the paramedic and the ambulance. Even though the paramedic 311 has performed a partial hand-off for the transfer of the download 312 down-stream to the satellite link, the upstream and the video 313 conferencing session remains on the wide area cellular link. This 314 serves best the time constraint requirements of the real time 315 communication. 317 4.5 Ubiquitous Access and Load Sharing (with mobility) 319 Jules drives his car and constantly keeps some sort of Internet 320 connectivity through one of the available access technologies. His 321 car navigator downloads road information from the Internet and his 322 car-audio plays on-line audio streaming. When his car passes an area 323 where both high-data-rate WLAN and low-data-rate cellular network are 324 available, it distributes load to the WLAN access and the cellular 325 network access. When his car passes an area where only a wide 326 coverage-range cellular network is available, it maintains its 327 connection via the cellular network. 329 4.6 Redundancy and Bi-Casting (with no mobility) 331 Dr. Catherine performs an operation via long-distance medical 332 system. She watches a patient in a battle field over the screen 333 which delivers real-time images of the patient. Sensors on her arms 334 deliver her operational action and a robot performs her operation in 335 the battle field. Since the operation is critical, the delivery of 336 patient images and Catherine's action is done by bi-casting from/to 337 multiple interfaces bound to a distinct technology or distinct radio 338 range. So in case packets are delayed or one of the interface fails 339 to maintain connectivity to the network, her distant can be 340 continued. 342 5. Classification 344 From the definition of a multihomed node it follows that a multihomed 345 node has several IPv6 addresses to choose between. In order to 346 expose the goals and benefits to manage multihomed nodes, we propose 347 to distinguish two main cases: either the node has only one 348 interface, or the node has several interfaces. 350 5.1 Case 1: One Interface, Multiple Prefixes 352 The single-interfaced node is multihomed when several prefixes are 353 advertised on its interface. The node must therefore configure 354 several IPv6 addresses. The node has to choose which address to use 355 when an IPv6 communication is established (e.g. open a TCP 356 connection). This choice can be influenced by many parameters: user 357 preference, different price on prefixes, preference flag in Router 358 Advertisement, destination prefix, etc. An address selection 359 mechanism is needed. 361 A typical example is a node with an IEEE 802.11 interface, connected 362 to an access point. The access point is connected trough an Ethernet 363 link to two access routers. Each access router is configured to send 364 Router Advertisements on the link and can be used as default router. 365 Several reasons may lead to configure two access routers are on the 366 same link: for instance, the access points may be shared between 367 different ISPs, or two access routers may be used for redundancy or 368 load sharing purposes. The node will then build two global IPv6 369 addresses on its interface. 371 We now analyse which of the benefits detailed in Section 3 can be 372 attained for this configuration. 374 o Ubiquitous Access 376 Ubiquitous access cannot be guaranteed when the node looses 377 Internet connectivity through its sole interface (e.g. the node 378 is going outside the coverage area of its access point). 380 o Redundancy 382 In case of failure of one IPv6 prefix, one of the address of the 383 node will not be valid anymore. Another available address built 384 from other prefixes should allow the node to recover this sort of 385 failure. However transparency may not be achieved since on-going 386 sessions using the invalid address would have to be terminated, 387 and restarted using the new address. To avoid this, the node 388 needs a recovery mechanism allowing to redirect all current 389 communication to one of its other IPv6 address. The time needed 390 for the detection of the prefix failure and the time to redirect 391 communications to one of its other addresses is considered as 392 critical. 394 o Load sharing 396 Load Sharing can be performed in the network, according to the 397 address used by the node. The choice of the address used by the 398 node and the router selection can be influenced by the load 399 sharing rules. This mostly benefits the network side: if 400 different access routers or routes can be used to forward the 401 node's traffic, it will share the traffic load on the network. 403 o Load balancing 405 Load balancing cannot be performed as the node has only one 406 interface. 408 o Bi-casting 410 Bi-casting can be performed to ensure the delivery of packets on 411 the node. To do so, more than one IPv6 address must be used 412 simultaneously for one flow. Although packets can not be 413 distributed to different interfaces on the node, bi-casting would 414 allow the node to seamlessly change the address used on the node 415 if such a protocol is used to change address of on-going flow. 416 Time synchronization can be an issue in this case. If we use 417 different access technologies or routes for each casting, the 418 round trip time (RTT) can differ from casting to casting. Thus 419 the receiver will receive the same contents at different times. 421 o Preference 423 The source address can be chosen according to preferences set up 424 by the user, or according to preferences set up in the network 425 (such as with the default router preferences option introduced in 426 Router Advertisement [6], or by the ISP. 428 o Increased Bandwidth 430 With only one interface connected to a link, the node generally 431 will not be able to enjoy increased bandwidth with multiple 432 prefixes. However, this benefit might be gained indirectly. For 433 instance, by alternating between different addresses, the total 434 throughput may be higher (eg. due to load sharing). Also, some 435 web and file transfer servers limit transfer bandwidths based on 436 the client's address. By using different addresses to connect to 437 the same server, the node may also see an increase in file 438 transfer rate. 440 5.2 Case 2: Several Interfaces 442 In this case, the node may use its multiple interfaces either 443 alternatively or simultaneously. If used alternatively, the node is 444 either multihomed if multiple prefixes are advertised on its current 445 link (case 1, one interface), or not multihomed if only one prefix is 446 advertised on its current link. We will thus assume that multiple 447 interfaces are used simultaneously. At least one IPv6 address will 448 be configured per interface (or several addresses per interface if 449 several prefixes are announced on the link(s) it is connected to). 450 Also, multiple interfaces can be connected to the same link as well 451 as to different links. These configurations will imply different 452 issues. 454 An address selection mechanism is also needed, but this time the 455 interface on which the address is bound to will be a supplementary 456 parameter in the address selection. The different characteristics of 457 each interface may help to decide first which interface to use. 459 A typical example is a node with two interfaces, each one on a 460 different technology (e.g. a WLAN IEEE 802.11b interface and a 3GPP 461 GPRS interface), in order to benefit from a better coverage area 462 (ubiquitous access) and the characteristics of each technology. 464 This multihomed configuration may yield different benefits to the 465 node. We now analyse how each of the benefits listed in Section 3 466 could be applied: 468 o Ubiquitous Access 470 It is easier to guarantee ubiquitous access when the node has 471 multiple interfaces since distinct technologies may be available 472 at a given time according to the location and administrative 473 policies. However, the node must be able to use several 474 technologies at the same time and to maintain Internet 475 connectivity while a technology can not be used. It is obvious 476 that the node must have the choice to use any of the available 477 technologies, and that this choice must not prevent the node to 478 redirect a communication to another interface/address. 480 o Redundancy 482 Two levels of redundancy can be seen in this case: either one 483 address of one interface is not valid anymore (e.g. because the 484 corresponding prefix is not advertised on the link), or the node 485 loses its internet connectivity through one interface. In the 486 former case, another IPv6 address available on the interface would 487 allow the node to switch addresses for on-going flows. In the 488 latter case, another connection to the internet through another 489 interface would allow it to redirect on-going flow from the 490 previous interface to the new one. In either cases the node needs 491 to change the IPv6 address for on-going sessions from the no 492 longer valid address to one of the address available on the target 493 interface. The redirection will trigger a decision process to 494 choose the best target interface to redirect the flow. In both 495 cases, transparency of the addressses switching is an important 496 issue. 498 Loss of a prefix: If the node loses one of its prefix, it can no 499 longer use the corresponding address anymore. So the node needs a 500 recovery mechanism that allows it to transfer all current 501 communications to one of its other IPv6 address(es). The time 502 needed for the detection of the prefix failure and the time to 503 redirect communications to one of its other addresses may be 504 critical. 506 Interface failure: If one of the used interface breaks down (loss 507 of network connection or access router is not reachable anymore), 508 the node must be able to redirect all its flows from that 509 interface to one of the alive interfaces. The time needed to 510 discover the failure and to redirect each flow has to be 511 considered. The scalability of such a solution is also an issue. 513 Mobility of the node: If the node moves to a new point of 514 attachment in another subnet, it will need to change its IPv6 515 addresses. In order to maintain all its previous communications, 516 it will need to redirect the flows to its new point of attachment, 517 whatever the old address used for the flow. The scalability of 518 the redirection can also be considered here. 520 o Load Sharing 522 This benefit is mainly for the network side: if different access 523 routers or routes can be used to forward traffic going into and 524 out of the node, they can share the traffic load on the network. 525 If the node uses several addresses at the same time for its 526 on-going sessions, load sharing can be performed in the network. 527 This goal can be a parameter that helps the source address 528 selection. 530 o Load balancing 532 Load balancing can be achieved on the node if several interfaces 533 are used simultaneously. Several interfaces can be used to spread 534 the traffic load on the node. This implies the choice of the IPv6 535 address to use for each flow and the ability to choose a different 536 address for each flow. 538 o Bi-casting 540 Bi-casting might be used to ensure the packets delivery on the 541 node. It also allow seamless redirection between two addresses / 542 interfaces with zero packets loss. Bi-casting can be performed if 543 several IPv6 addresses can be simultaneously used for one flow. 544 One entity between the CN (included) and the node (excluded) must 545 duplicate the traffic to the destination node. 547 o Preferences 549 Interface and address selection is required. The problem can be 550 seen exactly as in the first case (the node has only one 551 interface) if we consider that the interface preference is a 552 parameter for the address selection. Therefore in this case, the 553 interface selection/preference is a supplementary parameter in the 554 address selection algorithm. 556 o Increased Bandwidth 558 With multiple interface connected to a link, the node generally 559 will be able to enjoy increased bandwidth. 561 6. Issues 563 In this section, we attempt to list a number of generic issues 564 [[Comment.1: Tentative section under construction --Note]] 566 6.1 Router Selection 568 Each access router the node is connected to might have different 569 capacity. For example, if the network the node is located in (either 570 a fixed network or a mobile network) is connected to the Internet via 571 2 routers, each path may have very different bandwidth and delay. 572 This would have a strong impact on the node behind those routers. 573 Therefore, it is desirable for the node to obtain enough information 574 so that it can choose its best default router. 576 6.2 Source Address Selection 578 The node has to choose which address to use when an IPv6 579 communication is established (e.g. open a TCP connection). This 580 choice can be influenced by many parameters: user preference, 581 different price on prefixes, preference flag in Router Advertisement, 582 destination prefix, etc. An address selection mechanism is needed. 584 6.3 Flow Redirection and Broken Sessions 586 Sessions may break as a result of diverting from one interface or 587 prefix to another. With no support mechanism, an address change 588 would cause on-going sessions using the invalid former address to 589 terminate, and to be restarted using the new address. To avoid this, 590 the node needs a recovery mechanism allowing to redirect all current 591 communication to one of its other IPv6 address. 593 6.4 Recovery Delay 595 The time needed for the detection an address has become invalid and 596 the time to redirect communications to one of its other addresses is 597 considered as critical. 599 6.5 Mobility 601 A node which moves to a new point of attachment in another subnet 602 must obtain a new IPv6 address on the new link. In order to maintain 603 sessions, all flows must be redirected to the new location and a 604 mobility management solution may be required, such as Mobile IPv6 [4] 605 or NEMO Basic Support [5]. More mechanisms may be needed if the node 606 was using several addresses on its old link, such as which flow to 607 redirect, which address must be associated with the new address(es). 608 The scalability of the operations involved in the redirection of 609 flows may also be an issue, if we consider that the node had several 610 addresses on the old link and several flows and/or correspondents. 611 Issues pertaining to Mobile IPv6 are explained in companion drafts 612 [9] and [8]. 614 7. Acknowledgments 616 We would like to thank all the people who have provided comments on 617 this draft, and also co-authors of earlier documents in which authors 618 of this present document have been engaged. As such, we would like 619 to thank Niko A. Figouras, Hesham Soliman, Ken Nagami, and many 620 others. 622 8. References 624 [1] Malki, K. and H. Soliman, "Simultaneous Bindings for Mobile 625 IPv6 Fast Handovers", 626 Internet-Draft draft-elmalki-mobileip-bicasting-v6-05, November 627 2003. 629 [2] Manner, J. and M. Kojo, "Mobility Related Terminology", 630 RFC 3753, June 2004. 632 [3] Abley, J., Black, B. and V. Gill, "Goals for IPv6 633 Site-Multihoming Architectures", RFC 3582, August 2003. 635 [4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 636 IPv6", RFC 3775, June 2004. 638 [5] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubert, 639 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 640 January 2005. 642 [6] Draves, R. and D. Thaler, "Default Router Preferences and 643 More-Specific Routes", 644 Internet-Draft draft-ietf-ipv6-router-selection-06, October 645 2004. 647 [7] Hinden, R., "IPv6 Host to Router Load Sharing", 648 Internet-Draft draft-ietf-ipv6-host-load-sharing-03, October 649 2004. 651 [8] Ng, C., Paik, E. and T. Ernst, "Analysis of Multihoming in 652 Network Mobility Support", 653 Internet-Draft draft-ietf-nemo-multihoming-issues-02, February 654 2005. 656 [9] Montavont, N., Wakikawa, R. and T. Ernst, "Analysis of 657 Multihoming in Mobile IPv6", 658 Internet-Draft draft-montavont-mobileip-multihoming-pb-statement-03 659 , January 2005. 661 [10] Fikouras, N., "Mobile IPv4 Flow Mobility Problem Statement", 662 Internet-Draft draft-nomad-mip4-flow-mobility-pb-00.txt, Feb 663 2004. 665 Authors' Addresses 667 Thierry Ernst 668 WIDE at Keio University 669 Jun Murai Lab., Keio University. 670 K-square Town Campus, 1488-8 Ogura, Saiwa-Ku 671 Kawasaki, Kanagawa 212-0054 672 Japan 674 Phone: +81-44-580-1600 675 Fax: +81-44-580-1437 676 Email: ernst@sfc.wide.ad.jp 677 URI: http://www.sfc.wide.ad.jp/~ernst/ 679 Nicolas Montavont 680 LSIIT - Univerity Louis Pasteur 681 Pole API, bureau C444 682 Boulevard Sebastien Brant 683 Illkirch 67400 684 FRANCE 686 Phone: (33) 3 90 24 45 87 687 Email: montavont@dpt-info.u-strasbg.fr 688 URI: http://www-r2.u-strasbg.fr/~montavont/ 690 Ryuji Wakikawa 691 Keio University 692 Jun Murai Lab., Keio University. 693 5322 Endo 694 Fujisawa, Kanagawa 252-8520 695 Japan 697 Phone: +81-466-49-1100 698 Fax: +81-466-49-1395 699 Email: ryuji@sfc.wide.ad.jp 700 URI: http://www.mobileip.jp/ 701 Eun Kyoung Paik 702 KT 703 Portable Internet Team, Convergence Lab., KT 704 17 Woomyeon-dong, Seocho-gu 705 Seoul 137-792 706 Korea 708 Phone: +82-2-526-5233 709 Fax: +82-2-526-5200 710 Email: euna@kt.co.kr 711 URI: http://mmlab.snu.ac.kr/~eun/ 713 Chan-Wah Ng 714 Panasonic Singapore Laboratories Pte Ltd 715 Blk 1022 Tai Seng Ave #06-3530 716 Tai Seng Industrial Estate 717 Singapore 534415 718 SG 720 Phone: +65 65505420 721 Email: cwng@psl.com.sg 723 Koojana Kuladinithi 724 University of Bremen 725 ComNets-ikom,University of Bremen. 726 Otto-Hahn-Allee NW 1 727 Bremen, Bremen 28359 728 Germany 730 Phone: +49-421-218-8264 731 Fax: +49-421-218-3601 732 Email: koo@comnets.uni-bremen.de 733 URI: http://www.comnets.uni-bremen.de/~koo/ 735 Thomas Noel 736 LSIIT - Univerity Louis Pasteur 737 Pole API, bureau C444 738 Boulevard Sebastien Brant 739 Illkirch 67400 740 FRANCE 742 Phone: (33) 3 90 24 45 92 743 Email: noel@dpt-info.u-strasbg.fr 744 URI: http://www-r2.u-strasbg.fr/~noel/ 746 Appendix A. Change Log From Previous Version 748 o Added tentative section "Issues" 750 o Typos, rephrasing, added sub-sections into TOC, updated 751 references, added ACK section 753 Intellectual Property Statement 755 The IETF takes no position regarding the validity or scope of any 756 Intellectual Property Rights or other rights that might be claimed to 757 pertain to the implementation or use of the technology described in 758 this document or the extent to which any license under such rights 759 might or might not be available; nor does it represent that it has 760 made any independent effort to identify any such rights. Information 761 on the procedures with respect to rights in RFC documents can be 762 found in BCP 78 and BCP 79. 764 Copies of IPR disclosures made to the IETF Secretariat and any 765 assurances of licenses to be made available, or the result of an 766 attempt made to obtain a general license or permission for the use of 767 such proprietary rights by implementers or users of this 768 specification can be obtained from the IETF on-line IPR repository at 769 http://www.ietf.org/ipr. 771 The IETF invites any interested party to bring to its attention any 772 copyrights, patents or patent applications, or other proprietary 773 rights that may cover technology that may be required to implement 774 this standard. Please address the information to the IETF at 775 ietf-ipr@ietf.org. 777 Disclaimer of Validity 779 This document and the information contained herein are provided on an 780 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 781 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 782 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 783 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 784 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 785 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 787 Copyright Statement 789 Copyright (C) The Internet Society (2005). This document is subject 790 to the rights, licenses and restrictions contained in BCP 78, and 791 except as set forth therein, the authors retain all their rights. 793 Acknowledgment 795 Funding for the RFC Editor function is currently provided by the 796 Internet Society.