idnits 2.17.1 draft-bonaventure-informed-path-selection-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 902. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 913. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 920. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 926. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (February 18, 2008) is 5909 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'Schiller-TE' on line 408 == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-09 == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-05 == Outdated reference: A later version (-02) exists of draft-vogt-rrg-six-one-01 ** Obsolete normative reference: RFC 3484 (ref. '13') (Obsoleted by RFC 6724) == Outdated reference: A later version (-01) exists of draft-saucez-idips-00 ** Obsolete normative reference: RFC 1771 (ref. '19') (Obsoleted by RFC 4271) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force O. Bonaventure 3 Internet-Draft D. Saucez 4 Intended status: Informational B. Donnet 5 Expires: August 21, 2008 Universite catholique de Louvain 6 February 18, 2008 8 The case for an informed path selection service 9 draft-bonaventure-informed-path-selection-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 21, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 With today's peer-to-peer applications, more and more content is 43 available from multiple sources. In tomorrow's Internet hosts will 44 have multiple paths to reach one destination host with the deployment 45 of dual-stack IPv4/IPv6 hosts, but also with new techniques such as 46 shim6 or other locator/identifier mechanisms being discussed within 47 the IRTF RRG. All these hosts will need to rank paths in order to 48 select the best paths to reach a given destination/content. In this 49 draft, we propose an informed path selection service that would be 50 queried by hosts and would rank paths based on policies and 51 performance metrics defined by the network operator to meet his 52 traffic engineering objectives. A companion document describes a 53 protocol that implements this service. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. The informed path selection service . . . . . . . . . . . . . 4 59 3. Issues with multihoming . . . . . . . . . . . . . . . . . . . 6 60 3.1. Case 1 : Primary/Backup . . . . . . . . . . . . . . . . . 6 61 3.2. Case 2 : Load Sharing . . . . . . . . . . . . . . . . . . 7 62 3.3. Case 3 : Best Path . . . . . . . . . . . . . . . . . . . . 8 63 4. Existing multihoming solutions . . . . . . . . . . . . . . . . 9 64 4.1. BGP-based multihoming . . . . . . . . . . . . . . . . . . 9 65 4.1.1. Case 1 : Primary/Backup . . . . . . . . . . . . . . . 9 66 4.1.2. Case 2 : Load Sharing . . . . . . . . . . . . . . . . 9 67 4.1.3. Case 3 : Best Path . . . . . . . . . . . . . . . . . . 11 68 4.2. Shim6 host-based multihoming . . . . . . . . . . . . . . . 12 69 4.2.1. Case 1 : Primary/Backup . . . . . . . . . . . . . . . 12 70 4.2.2. Case 2 : Load Sharing . . . . . . . . . . . . . . . . 13 71 4.2.3. Case 3 : Best Path . . . . . . . . . . . . . . . . . . 13 72 4.3. Dual stack IPv4/IPv6 . . . . . . . . . . . . . . . . . . . 13 73 4.4. LISP and multihoming issues . . . . . . . . . . . . . . . 13 74 4.4.1. Case 1 : Primary/Backup . . . . . . . . . . . . . . . 14 75 4.4.2. Case 2 : Load Sharing . . . . . . . . . . . . . . . . 14 76 4.4.3. Case 3 : Best Path . . . . . . . . . . . . . . . . . . 15 77 5. Application of the informed path selection service . . . . . . 15 78 5.1. Case 1 : Primary/Backup . . . . . . . . . . . . . . . . . 15 79 5.2. Case 2 : Load Sharing . . . . . . . . . . . . . . . . . . 15 80 5.3. Case 3 : Best Path . . . . . . . . . . . . . . . . . . . . 15 81 5.4. Other applications of the informed path selection 82 service . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 6. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 85 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 87 10. Normative References . . . . . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 89 Intellectual Property and Copyright Statements . . . . . . . . . . 21 91 1. Introduction 93 The current Internet is based on several assumptions that have driven 94 the development of most Internet protocols and mechanisms. A first 95 assumption is that (usually) one address is associated to each host. 96 Also, the forwarding of packets is exclusively based on the 97 destination address. For this reason, there is usually a single path 98 between one source (or client) and one destination (or server). 99 Finally, the Internet was designed with the client-server model in 100 mind assuming that many clients receive information from (a smaller 101 number of) servers. 103 During the last years, these assumptions have been severely 104 challenged : 106 o The client-server model does not correspond to the current 107 operation of many applications. First, large servers are usually 108 replicated and different types of content distribution networks 109 are used to efficiently distribute content. Second, the 110 proliferation of peer-to-peer applications implies that most 111 clients also act as server. This is creating several problems in 112 many ISP networks [1]. The client-server asymmetry does not hold 113 anymore as earlier. 115 o Due to the transition from IPv4 to IPv6 many hosts will be dual- 116 stack for the foreseeable future [2]. Furthermore, measurements 117 show that IPv4 and IPv6 do not provide the same performance [3], 118 even for a single source-destination pair. This implies that to 119 reach a destination supporting both IPv4 and IPv6, a source will 120 need to select the utilization of IPv4 or IPv6. 122 o Host based Multihoming techniques such as [4] are emerging. These 123 techniques assume that each host of a multihomed site will have 124 several IPv6 addresses (e.g., one per provider). 126 o Several locator/identifier separation protocols [5] [6] being 127 discussed within the IRTF Routing Research Group allow one 128 identifier to be reachable via multiple locators. 130 A consequence of the deployment of these new techniques is that the 131 number of end-to-end paths that are available to reach a given 132 destination/content will grow. Several studies and practical 133 experience show that resilience of the Internet increases with the 134 number of paths [7][8] since if one path fails, it is likely that the 135 other paths will continue to work provided that they are sufficiently 136 disjoint. Also, the availability of multiple paths may allow a 137 better use of the Internet infrastructure by providing better paths 138 in terms of delay, bandwidth, and congestion compared to the unique 139 current IPv4 paths. This has been shown by several measurements 140 studies [8][9]. 142 However, to obtain these benefits, the hosts (or the routers in some 143 of the proposals being discussed within the IRTF RRG), will need to 144 be able to accurately select the best path to use to reach a given 145 (set of) destination(s). Several solutions have been proposed to 146 allow P2P applications to rank some paths over others [10] [11] [12]. 147 However, relying on proprietary solutions implies a duplication of 148 efforts (e.g. different peer-to-peer applications may use different 149 techniques and perform their own measurements). Also, the existing 150 solutions such as the static source address selection mechanism 151 defined in [13] are static. 153 In this document, we propose an informed path selection service that 154 is able to rank paths based on policy and performance criteria. A 155 protocol to implement this service is described in a companion 156 document [14]. 158 This document is organized as follows. First, we provide a high- 159 level description of the proposed service in Section 2. Then, to 160 illustrate the benefits of such a service, we recall in Section 3 161 three issues for multihomed networks expressed by J. Schiller in 162 [15]. In Section 4 we explain the limitations of existing (i.e., 163 BGP) and proposed techniques (i.e., shim6 and LISP) when solving 164 these case studies. In Section 5 we discuss several possible 165 applications of the informed path selection service. Finally, we 166 compare the informed path selection service with related work in 167 Section 6. 169 2. The informed path selection service 171 The informed path selection service is a distributed request-response 172 service that allows to rank paths. This service is typically 173 supported inside a domain. It can benefit from cooperation between 174 domains but does not require it. 176 BGP, OSPF/ISIS Measurements 177 || || 178 || || 179 \/ \/ 180 +------------------------+ 181 | | 182 | Informed Path | 183 | Selection | 184 | Service | 185 +--------+ request | | 186 | client | -->---- | | 187 | | -----<--- | | 188 +--------+ response +------------------------+ 189 /\ 190 || 191 Policies 193 Informed path selection service 195 Figure 1 197 The informed path selection service is used to decide the best 198 path(s) among a set of candidate paths. It can be queried by a host 199 having multiple addresses, a LISP router or other entities that need 200 to rank paths such as peer-to-peer applications, content distribution 201 networks, dual-stack hosts, ... The informed path selection service 202 is based on a request/response mechanism and the path ranking may 203 depend on several factors including : 205 o Routing information (e.g., BGP, OSPF/ISIS) that allow the informed 206 path selection service to compare different paths based on routing 207 metrics (e.g. BGP local preference, BGP AS-Path length, IGP path 208 length, ...). 210 o Active or passive measurements (e.g., delay, bandwidth, loss, ...) 211 that allow the informed path selection to compare different paths 212 based on quantitative performance metrics. 214 o Policies configured by the network administrator that indicate 215 preferences for some paths over others. 217 A request will contain the following information : 219 o one or more source addresses (or prefixes), 221 o one or more destination addresses (or prefixes). 223 Upon reception of a request, the informed path selection service 224 builds a list of all the possible paths between the source(s) and the 225 destination(s). Then, it removes from consideration the paths that 226 are invalid due to routing (e.g., one destination is not reachable 227 from a given source address) or policies. These remaining paths are 228 ranked and the reply contains the following information : 230 o the best path (source address, destination prefix), 232 o the second best path (source address, destination prefix), 234 o ... 236 o the Nth best path (source address, destination prefix), 238 o the lifetime for the ranked paths. 240 As indicated above, the number of paths returned by the path 241 selection service may be lower than the total number of possible 242 paths, e.g., because some paths are not usable due to policy reasons 243 or because some destinations are not reachable by using some source 244 addresses. 246 For scalability reasons and based on the experience in developing the 247 NAROS protocol [16], the informed path selection service uses two 248 mechanisms to allow the client to use the same path for several 249 flows. First, an ordered list of paths is valid for some time and 250 the client is encouraged to cache the ordered list for the lifetime 251 indicated in the response. Second, the response may contain paths 252 that are composed of a source and a destination prefix instead of 253 addresses. This choice is motivated by the fact that all the IP 254 addresses that belong to the same prefix are usually covered by the 255 same policies and have similar performance. Simulations performed 256 earlier showed that these two mechanisms allow to significantly 257 reduce the number of requests sent to an informed path selection 258 service by a given host [8]. 260 3. Issues with multihoming 262 To illustrate the benefits of an informed path selection service and 263 compare it with existing techniques, we first summarize the concerns 264 raised by J. Schiller on multihoming in [15]. We focus on the three 265 main case study described in [15]. 267 3.1. Case 1 : Primary/Backup 269 The first issue mentioned in [15] is the classical case of a 270 multihomed network using one primary provider and another as backup. 272 This case is illustrated in Figure 2 where the multihomed customer is 273 attached to UUNet/MCI and ATT. In this example, traffic engineering 274 objectives of the multihomed customer are : 276 o All outgoing packets must be sent via UUNet/MCI when this link is 277 active. Otherwise, the packets must be sent via ATT. 279 o All incoming packets must be received via UUNet/MCI when this link 280 is active. Otherwise, the packets must be received via ATT. 282 +---------------+ +---------------+ 283 | UUNET/MCI +-~-~-~-+ AT&T | 284 +------:--------+ +-------:-------+ 285 \ // 286 \ // 287 \ // 288 \ // 289 \ // 290 \ // 291 \ // 292 \ // 293 \ // 294 \ // 295 +----:----:-----+ 296 | Multihomed | 297 | customer | 298 | 63.63.62.0/23 | 299 +---------------+ 301 --- primary link to UUNET 302 === backup link to AT&T 303 -~- Internet 305 Example of a Primary/Backup implementation 307 Figure 2 309 This problem has been generalized in [15] as follows : "It is 310 required to have the ability to set a link or a set of links as 311 primary and some other as backup links. Such that all the traffic is 312 carried by the primary links while backup links are used only while 313 primary links become unavailable." 315 3.2. Case 2 : Load Sharing 317 The second case mentioned in [15] is load sharing across links from 318 different providers. This problem is illustrated in Figure 3. In 319 this example, the high-level objectives of the multihomed customer 320 can be specified as : 322 o The same amount of outgoing packets should be sent via the UUNet/ 323 MCI and ATT links. 325 o The same amount of incoming packets should be received via UUNet/ 326 MCI and ATT links. 328 Load sharing 330 +---------------+ +---------------+ 331 | UUNET/MCI +-~-~-~-+ AT&T | 332 +------:--------+ +-------:-------+ 333 \ // 334 \ // 335 \ // 336 \ // 337 \ // 338 \ // 339 \ // 340 \ // 341 \ // 342 \ // 343 +----:----:-----+ 344 | Multihomed | 345 | customer | 346 | 63.63.62.0/23 | 347 +---------------+ 349 --- link to UUNET 350 === link to AT&T 351 -~- Internet 353 Figure 3 355 This problem can, of course, be generalized by considering more than 356 two links/providers and also by requiring unequal load sharing among 357 the different links (e.g. based on link cost, link capacity, ...). 359 3.3. Case 3 : Best Path 361 The third case mentioned in [15] is that it should be possible for 362 the multihomed customer to have ways to decide whether the paths 363 available via one provider are better than the paths available via 364 the other provider and use the best paths. The high-level objectives 365 of the multihomed customer in this case become 366 o For each destination, send the outgoing packets via the provider 367 that has the best path to reach this destination. 369 o For each source, receive the incoming packets via the provider 370 that is on the best path from this source. 372 This problem can be generalized to cover more than two links and 373 providers. 375 4. Existing multihoming solutions 377 In this section, we evaluate how three technical solutions that are 378 used today or are being discussed within the IETF/IRTF are able to 379 meet the objectives mentioned above. We first start with BGP-based 380 multihoming as described in [15], then discuss shim6 [4] and finally 381 LISP [5]. 383 4.1. BGP-based multihoming 385 BGP-based multihoming is a common and widely deployed technique that 386 allows a multihomed network to be attached to different providers. 387 It is used by existing IPv4 and IPv6 deployments. 389 4.1.1. Case 1 : Primary/Backup 391 With BGP-based traffic engineering, the common techniques to 392 implement primary/backup links are the following [15]: 394 o Set a higher MED for backup links from the same AS. 396 o Set a lower local-preference for backups links of different ASes. 398 o Set a higher weight for static default routes on backup links. 400 The main issue with these BGP-based solutions is that a prefix must 401 be allocated to each multihomed customer. Furthermore, this prefix 402 is advertised in the BGP routing tables and thus contributes to the 403 growth of these routing tables [17]. 405 4.1.2. Case 2 : Load Sharing 407 To solve the load sharing case, several techniques can be used on BGP 408 routers. The following are presented in [Schiller-TE] [15] 410 o Divide IP space and more specific routes announces over the 411 different links. 413 o Modify the MED or local preferences of inbound links. 415 o Modify IGP metrics to move hosts closer to a given exit point. 417 o Manipulate equal cost static default routes. 419 Figure 4 from [15] shows how BGP can be used to solve the load 420 sharing problem by dividing the IP space of the multihomed customer 421 and sending more specific routes. This solution has several 422 drawbacks. First, it contributes to the growth of the BGP routing 423 tables by requiring each multihomed customer to advertise more than 424 one prefix [17]. Second, the solution is far from perfect and 425 assumes that the two /23 more specific prefixes carry almost the same 426 amount of packets. If this is not the case or if the amount of 427 packets changes with time, then the more specific prefixes that need 428 to be advertised also need to change with time. This is not 429 desirable as a multihomed customer willing to move some packets from 430 one link to another would need to send BGP updates that would change 431 over time. 433 +---------------+ +---------------+ 434 | UUNET/MCI +-~-~-~-~-~+ AT&T | 435 +------:--------+ +-------:-------+ 436 \ // 437 \ // 438 \ // 439 \ // 440 advertise 63.63.62.0/23 advertise 63.63.62.0/23 441 advertise 63.63.62.0/24 advertise 63.63.63.0/24 442 \ // 443 \ // 444 \ // 445 \ // 446 receive default\ //receive default 447 +----:----:-----+ 448 | Multihomed | 449 | customer | 450 | 63.63.62.0/23 | 451 +---------------+ 453 --- primary link to UUNET 454 === primary link to AT&T 455 -~- Internet 457 Example of a load sharing implementation 459 Figure 4 461 4.1.3. Case 3 : Best Path 463 With BGP-based multihoming, several techniques can be used to select 464 the best path based on different definitions of best. They all 465 require the multihomed customer to receive the full BGP routing 466 tables from its providers and run BGP. A drawback of this solution 467 is that the definition of "best path" either depends on the limited 468 BGP attributes or must be tuned manually. Measurements have shown 469 that there is not a strong correlation between the length of the AS 470 Path carried in BGP messages and the performance of path measured in 471 terms of delay or bandwidth [18]. 473 o Best path is selected according to the BGP Decision process 474 depicted in [19] section 9.1. 476 o Traffic is controlled by the BGP path selection algorithm of the 477 source of the traffic. 479 o Manual changes can be used to move traffic from over-loaded links 480 to under-loaded links. 482 4.2. Shim6 host-based multihoming 484 The shim6 host-based multihoming technique is based on the assumption 485 that multihomed hosts will use one IPv6 address per provider. It is 486 expected that most multihomed customers will use PA addresses. In 487 this case, the multihomed customer does not need to advertise any 488 prefix with BGP. The basic network scenario with shim6 is depicted 489 in Figure 5. 491 +---------------+ +---------------+ 492 | UUNET/MCI +-~-~-~-~-+ AT&T | 493 | | | | 494 | 2001::/48 | | 2002::/48 | 495 +------:--------+ +-------:-------+ 496 \ // 497 \ // 498 \ // 499 \ // 500 \ // 501 \ // 502 \ // 503 \ // 504 +---:--------:---+ 505 | Multihomed | 506 | customer | 507 | | 508 | 2001::1:A | 509 | 2002::A:1 | 510 +----------------+ 512 --- primary link to UUNET 513 === backup link to AT&T 514 -~- Internet 516 Example of a Primary/Backup implementation 518 Figure 5 520 4.2.1. Case 1 : Primary/Backup 522 With the current IPv6 and shim6 specifications, a primary/backup 523 implementation can be supported by using the default address 524 selection specified in [13]. This specification defines a table that 525 is used by each host to select the source address that it will use to 526 reach a given destination based on the type of address, the prefix 527 length and preferences that can be defined by the system 528 administrators. This solution allows all hosts to prefer once source 529 address over the other. However, no protocol has been defined to 530 allow a system administrator to distribute the current preferences to 531 its hosts. This implies that the preference is rather static. 533 4.2.2. Case 2 : Load Sharing 535 Concerning load sharing, the current shim6 specification [4] can be 536 configured by using the preferences of the source address selection 537 mechanism to prefer one link over the other. As with BGP-based 538 multihoming, this solution is static, it is difficult to dynamically 539 change the source address selection preferences of the hosts to 540 follow the evolution of the traffic patterns. 542 4.2.3. Case 3 : Best Path 544 The current shim6 specification does not expect that the hosts will 545 select the source and destination addresses for a shim6 session based 546 on performance metrics but does not preclude it. An unrealistic 547 option would be to add a BGP and IGP routing table on each host to 548 allow them to select the best (source address,destination address) 549 pair based on BGP metrics. Additional information about operator's 550 concerns with shim6 may be found in [20]. 552 4.3. Dual stack IPv4/IPv6 554 Several mechanisms have been proposed to ease the transition from the 555 current IPv4 Internet towards an IPv6 Internet. As of today, nobody 556 expects that the IPv6 Internet will completely replace the IPv4 557 Internet quickly and that both Internets will coexist for several 558 years or more. For the foreseeable future, many networks will be 559 attached to both IPv6 and IPv4 providers. When considering the three 560 case studies, the dual stack IPv4/IPv6 hosts have several problems as 561 shim6 hosts discussed in the previous section. The only difference 562 is that a host cannot switch from using IPv4 to using IPv6 for an 563 established flow (i.e., if IPv4 connectivity becomes broken but IPv6 564 connectivity remains active). 566 4.4. LISP and multihoming issues 568 The Locator/Identifier Separation Protocol (LISP) [5] is currently 569 being discussed within the IRTF Routing Research Group as one of the 570 possible alternatives to achieve a better scaling of the Internet 571 architecture. LISP distinguishes between identifiers and locators. 572 The identifiers are used to identify endhosts. The locators are 573 assigned to ingress routers that implement the LISP tunneling scheme. 574 When an endhost needs to contact a remote endhosts, it sends a packet 575 with its own identifier as source address and the identifier of the 576 remote host as destination address. This packet will be intercepted 577 by the first LISP router on its path. This router uses a mapping 578 system to query the locator that allows to reach the (identifier of 579 the) remote host and encapsulates the packet before sending it to the 580 locator associated to the remote host. 582 +---------------+ +---------------+ 583 | UUNET/MCI +-~-~-~-~-~+ AT&T | 584 | 210.0.0.0/8 | | 11.0.0.0/8 | 585 +------:--------+ +-------:-------+ 586 \ // 587 \ // 588 \ // 589 \ // 590 \ // 591 \ // 592 \ // 593 \ // 594 +----:----:-----+ 595 | Multihomed | 596 | customer | 597 | Locators | 598 | 210.1.2.0/29 | 599 | 11.200.2.0/28 | 600 +---------------+ 602 --- primary link to UUNET 603 === backup link to AT&T 604 -~- Internet 606 Example of LISP scenario 608 Figure 6 610 4.4.1. Case 1 : Primary/Backup 612 With the current LISP specification, the primary/backup case can be 613 covered by considering the priority that is associated to an EID/ 614 locator mapping. A LISP router will prefer the locator having the 615 highest priority. This allows each LISP router to select the best 616 locator to reach a given destination. 618 4.4.2. Case 2 : Load Sharing 620 In addition to the priority mentioned above, LISP also associates a 621 weight to each locator. When several locator have the same priority, 622 then load sharing should be performed among the different locators 623 based on their weight. 625 4.4.3. Case 3 : Best Path 627 If the LISP routers of the multihomed site run BGP, they can use the 628 BGP decision process to rank some routes over others. However, as 629 explained earlier, the correlation between BGP attributes such as the 630 length of the AS Path and the performance of interdomain paths is 631 weak. 633 5. Application of the informed path selection service 635 In this section, we briefly discuss how the informed path selection 636 service could improve the performance of multihomed networks by 637 considering our three case studies. As an example, we consider that 638 the informed path selection service is queried by hosts, but the same 639 result would apply for LISP routers. 641 5.1. Case 1 : Primary/Backup 643 By using the informed path selection service, the primary/backup case 644 can be easily solved. Upon reception of a request, the server simply 645 needs to always place the prefixes that correspond to the primary 646 link at the top of the list and possibly remove the prefixes 647 associated to the backup link from the reply. When the primary link 648 fails, the server updates its ranking to allow the hosts to use the 649 backup link instead. 651 5.2. Case 2 : Load Sharing 653 The load sharing case can be naturally solved by using an informed 654 path selection service. Indeed, the service could easily track the 655 load on the different links and dynamically change its replies based 656 on the link load. The NAROS protocol [16], proposed in the early 657 days of IPv6 multihoming, was designed to solve this problem and the 658 evaluation showed that it worked well [8]. 660 5.3. Case 3 : Best Path 662 The informed path selection service brings new benefits for the Best 663 path case as it allows the server to base its ordering on active 664 measurements to assess the performance of paths by considering 665 metrics such as delay or bandwidth. The informed path selection 666 service is not restricted to the BGP information as in the current 667 BGP-based multihoming techniques. 669 5.4. Other applications of the informed path selection service 671 The informed path selection service is not limited to multihomed 672 networks. It can be used in any environment where several paths need 673 to be ranked based on policies and/or performance. 675 The peer to peer applications are clear candidate users for such a 676 service. Some peer-to-peer applications already rely on heuristics 677 to prefer some sources over others. A standardized path selection 678 service would allow several peer-to-peer applications to share the 679 same measurements. Furthermore, an ISP or campus network running the 680 informed path selection service could influence providers used by the 681 packets sent/received by the hosts of its networks. 683 The informed path selection service could be associated to a DNS 684 resolver or server. When a DNS resolver receives a DNS reply 685 containing several addresses for the same name, it could rank them 686 and return a ranked DNS response. A DNS server implementing [21] 687 could contact the informed path selection service to update 688 dynamically the SRV RR of its local servers. 690 The informed path selection service could also be useful for 691 multihomed VoIP gateways that need to select the best VoIP gateway to 692 forward a voice call. 694 6. Related work 696 Several solutions have been proposed to improve the performance of 697 end-to-end paths. A first approach was proposed with the RSVP 698 signaling protocol [22] and the Integrated Services Architecture 699 [23]. RSVP allows to reserve resources on all routers along and end- 700 to-end path but does not allow a host to prefer one path over 701 another. Other signaling protocols have been or are being proposed 702 to install and maintain state on some intermediate nodes [24]. Our 703 proposed path selection service follows the end-to-end principle [25] 704 and does not create any state in intermediate nodes. 706 Due to scalability concerns, the Integrated Services Architecture has 707 not been widely deployed. Differentiated Services [26] were 708 introduced as a more scalable solution based on packet marking. 709 Differentiated Services does not by itself allows hosts to prefer 710 some paths over others. However, recent extensions to link state 711 routing protocols or the utilization of MPLS allow network operators 712 to provision different paths for different classes of services. Our 713 proposed path selection service allows the client to also indicate a 714 DSCP in the request to support hosts and applications that are using 715 non best-effort service. Although it does not require Differentiated 716 services, it can easily cooperate with it. 718 Several researchers have proposed solutions to similar problems. For 719 example, [27] proposed a mechanism where the source prefix of shim6 720 data packets is rewritten by the site routers. The proposed informed 721 path selection service does not require routers to change source 722 prefixes. [12] proposed an oracle service that would be configured by 723 the network operator and queried by peer-to-peer applications. The 724 oracle could be one of the ways to implement a path selection 725 service. Other mechanisms have been proposed specifically for peer- 726 to-peer applications [28] [10] [11]. 728 7. Security Considerations 730 By ranking paths, the informed path selection service influences the 731 path that hosts will use to send packets to some destinations. By 732 controlling the informed path selection service, an attacker diverts 733 packets through a path that he controls to create man-in-the middle 734 attacks or divert packets over an overload path to increase 735 congestion. These problems are similar to the security issues with 736 DNS resolver since an attacker who controls a DNS resolver could 737 obtain similar results. To mitigate these risks, it should be 738 possible for the clients that are using the informed path selection 739 service to authenticate the responses received from a server. 741 8. Conclusion 743 In this document, we have proposed an informed path selection service 744 that is able to rank paths based on policies or performance criteria. 745 A companion document [14] proposes a protocol to support this 746 service. 748 9. Acknowledgements 750 This work was partially supported by the European Commission within 751 the IST AGAVE and IST ONELAB projects. 753 10. Normative References 755 [1] Karagiannis, T., Rodriguez, P., and K. Papagiannaki, "Should 756 Internet Service Providers Fear Peer-Assisted Content 757 Distribution?", Internet Measurement Conference 2005, 758 October 2005. 760 [2] Cho, K., Luckie, M., and B. Huffaker, "Identifying IPv6 network 761 problems in the dual-stack world", ACM SIGCOMM Workshop on 762 Network Troubleshooting 283 - 288, September 2004. 764 [3] Zhou, X., Jacobsson, M., Uijterwaal, H., and P. Van Mieghem, 765 "IPv6 delay and loss performance evolution", International 766 Journal of Communication Systems DOI: 10.1002/dac.916, 2007. 768 [4] Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming Shim 769 Protocol for IPv6", draft-ietf-shim6-proto-09 (work in 770 progress), November 2007. 772 [5] Farinacci, D., "Locator/ID Separation Protocol (LISP)", 773 draft-farinacci-lisp-05 (work in progress), November 2007. 775 [6] Vogt, C., "Six/One: A Solution for Routing and Addressing in 776 IPv6", draft-vogt-rrg-six-one-01 (work in progress), 777 November 2007. 779 [7] Andersen, D., Balakrishnan, H., Kaashoek, F., and R. Morris, 780 "Resilient Overlay Networks", Proc. 18th ACM SOSP Banff, 781 Canada, October 2001. 783 [8] de Launois, C., "Unleashing traffic engineering for IPv6 784 multihomed sites", PhD thesis available from 785 http://inl.info.ucl.ac.be/delaunoi, October 2005. 787 [9] Akella, A., Maggs, B., Seshan, S., Shaikh, A., and R. 788 Sitaraman, "A measurement-based analysis of multihoming", Proc. 789 SIGCOMM (Karlsruhe, Germany, August 2003. 791 [10] Xie, H., Krishnamurthy, A., Yang, R., and A. Silberschatz, 792 "P4P: Proactive Provider Participation for P2P", Yale Computer 793 Science YALE/DCS/TR1377 , March 2007. 795 [11] Dabek, F., Cox, R., Kaashoek, F., and R. Morris, "Vivaldi: a 796 decentralized network coordinate system", Proc. SIGCOMM 797 2004 15-26, August 2004. 799 [12] Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs and 800 P2P systems co-operate for improved performance?", ACM SIGCOMM 801 Computer Communications Review Volume 37, Number 3, July 2007. 803 [13] Draves, R., "Default Address Selection for Internet Protocol 804 version 6 (IPv6)", RFC 3484, February 2003. 806 [14] Saucez, D., Donnet, B., and O. Bonaventure, "IDIPS : ISP-Driven 807 Informed Path Selection", Internet-Draft 808 draft-saucez-idips-00, February 2008. 810 [15] Schiller, J., "Inter-AS Traffic Engineering Case Studies as 811 Requirements for IPv6 Multihoming Solutions", NANOG 35, 812 May 2005. 814 [16] Launois, C. and O. Bonaventure, "NAROS : Host-Centric IPv6 815 Multihoming with Traffic Engineering", 816 draft-de-launois-multi6-naros-00 (work in progress), May 2003. 818 [17] Meyer, D., "Report from the IAB Workshop on Routing and 819 Addressing", draft-iab-raws-report-02 (work in progress), 820 April 2007. 822 [18] Huffaker, B., Fomenkov, M., Plummer, D., and k. Claffy, 823 "Distance Metrics in the Internet", IEEE International 824 Telecommunications Symposium , September 2002. 826 [19] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 827 RFC 1771, March 1995. 829 [20] Schiller, J., "Shim6 : network operator concerns", IAB 830 Workshop , October 2005. 832 [21] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 833 specifying the location of services (DNS SRV)", RFC 2782, 834 February 2000. 836 [22] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 837 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 838 Specification", RFC 2205, September 1997. 840 [23] Braden, B., Clark, D., and S. Shenker, "Integrated Services in 841 the Internet Architecture: an Overview", RFC 1633, June 1994. 843 [24] Manner, J. and X. Fu, "Analysis of Existing Quality-of-Service 844 Signaling Protocols", RFC 4094, May 2005. 846 [25] Saltzer, J., Reed, D., and David. Clark, "End-to-end arguments 847 in system design", ACM Transactions on Computer Systems Vol 2, 848 N 4 (November 1984) pages 277-288, November 1984. 850 [26] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. 851 Weiss, "An Architecture for Differentiated Services", RFC 2475, 852 December 1998. 854 [27] Bagnulo, M., Garcia-Martinez, A., and A. Azcorra, "BGP-like TE 855 Capabilities for SHIM6", EUROMICRO 2006, September 2006. 857 [28] Ledlie, J., Gardner,, P., and M. Seltzer, "Network Coordinates 858 in the Wild", Proceedings of NSDI 2007 , April 2007. 860 Authors' Addresses 862 Olivier Bonaventure 863 Universite catholique de Louvain 864 Place Sainte Barbe 2 865 Louvain-la-Neuve, 1348 866 Belgium 868 URI: http://inl.info.ucl.ac.be 870 Damien Saucez 871 Universite catholique de Louvain 872 Place Sainte Barbe 2 873 Louvain-la-Neuve, 1348 874 Belgium 876 Email: damien.saucez@uclouvain.be 877 URI: http://inl.info.ucl.ac.be 879 Benoit Donnet 880 Universite catholique de Louvain 881 Place Sainte Barbe 2 882 Louvain-la-Neuve, 1348 883 Belgium 885 Email: benoit.donnet@uclouvain.be 886 URI: http://inl.info.ucl.ac.be 888 Full Copyright Statement 890 Copyright (C) The IETF Trust (2008). 892 This document is subject to the rights, licenses and restrictions 893 contained in BCP 78, and except as set forth therein, the authors 894 retain all their rights. 896 This document and the information contained herein are provided on an 897 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 898 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 899 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 900 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 901 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 902 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 904 Intellectual Property 906 The IETF takes no position regarding the validity or scope of any 907 Intellectual Property Rights or other rights that might be claimed to 908 pertain to the implementation or use of the technology described in 909 this document or the extent to which any license under such rights 910 might or might not be available; nor does it represent that it has 911 made any independent effort to identify any such rights. Information 912 on the procedures with respect to rights in RFC documents can be 913 found in BCP 78 and BCP 79. 915 Copies of IPR disclosures made to the IETF Secretariat and any 916 assurances of licenses to be made available, or the result of an 917 attempt made to obtain a general license or permission for the use of 918 such proprietary rights by implementers or users of this 919 specification can be obtained from the IETF on-line IPR repository at 920 http://www.ietf.org/ipr. 922 The IETF invites any interested party to bring to its attention any 923 copyrights, patents or patent applications, or other proprietary 924 rights that may cover technology that may be required to implement 925 this standard. Please address the information to the IETF at 926 ietf-ipr@ietf.org. 928 Acknowledgment 930 Funding for the RFC Editor function is provided by the IETF 931 Administrative Support Activity (IASA).