[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                           O. Bonaventure
Internet-Draft                                                 D. Saucez
Intended status: Informational                                 B. Donnet
Expires: August 21, 2008                Universite catholique de Louvain
                                                       February 18, 2008


            The case for an informed path selection service
            draft-bonaventure-informed-path-selection-00.txt

Status of this Memo

   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.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 21, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   With today's peer-to-peer applications, more and more content is
   available from multiple sources.  In tomorrow's Internet hosts will
   have multiple paths to reach one destination host with the deployment
   of dual-stack IPv4/IPv6 hosts, but also with new techniques such as
   shim6 or other locator/identifier mechanisms being discussed within
   the IRTF RRG.  All these hosts will need to rank paths in order to
   select the best paths to reach a given destination/content.  In this



Bonaventure, et al.      Expires August 21, 2008                [Page 1]

Internet-Draft           Informed path selection           February 2008


   draft, we propose an informed path selection service that would be
   queried by hosts and would rank paths based on policies and
   performance metrics defined by the network operator to meet his
   traffic engineering objectives.  A companion document describes a
   protocol that implements this service.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The informed path selection service  . . . . . . . . . . . . .  4
   3.  Issues with multihoming  . . . . . . . . . . . . . . . . . . .  6
     3.1.  Case 1 : Primary/Backup  . . . . . . . . . . . . . . . . .  6
     3.2.  Case 2 : Load Sharing  . . . . . . . . . . . . . . . . . .  7
     3.3.  Case 3 : Best Path . . . . . . . . . . . . . . . . . . . .  8
   4.  Existing multihoming solutions . . . . . . . . . . . . . . . .  9
     4.1.  BGP-based multihoming  . . . . . . . . . . . . . . . . . .  9
       4.1.1.  Case 1 : Primary/Backup  . . . . . . . . . . . . . . .  9
       4.1.2.  Case 2 : Load Sharing  . . . . . . . . . . . . . . . .  9
       4.1.3.  Case 3 : Best Path . . . . . . . . . . . . . . . . . . 11
     4.2.  Shim6 host-based multihoming . . . . . . . . . . . . . . . 12
       4.2.1.  Case 1 : Primary/Backup  . . . . . . . . . . . . . . . 12
       4.2.2.  Case 2 : Load Sharing  . . . . . . . . . . . . . . . . 13
       4.2.3.  Case 3 : Best Path . . . . . . . . . . . . . . . . . . 13
     4.3.  Dual stack IPv4/IPv6 . . . . . . . . . . . . . . . . . . . 13
     4.4.  LISP and multihoming issues  . . . . . . . . . . . . . . . 13
       4.4.1.  Case 1 : Primary/Backup  . . . . . . . . . . . . . . . 14
       4.4.2.  Case 2 : Load Sharing  . . . . . . . . . . . . . . . . 14
       4.4.3.  Case 3 : Best Path . . . . . . . . . . . . . . . . . . 15
   5.  Application of the informed path selection service . . . . . . 15
     5.1.  Case 1 : Primary/Backup  . . . . . . . . . . . . . . . . . 15
     5.2.  Case 2 : Load Sharing  . . . . . . . . . . . . . . . . . . 15
     5.3.  Case 3 : Best Path . . . . . . . . . . . . . . . . . . . . 15
     5.4.  Other applications of the informed path selection
           service  . . . . . . . . . . . . . . . . . . . . . . . . . 16
   6.  Related work . . . . . . . . . . . . . . . . . . . . . . . . . 16
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   8.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 21









Bonaventure, et al.      Expires August 21, 2008                [Page 2]

Internet-Draft           Informed path selection           February 2008


1.  Introduction

   The current Internet is based on several assumptions that have driven
   the development of most Internet protocols and mechanisms.  A first
   assumption is that (usually) one address is associated to each host.
   Also, the forwarding of packets is exclusively based on the
   destination address.  For this reason, there is usually a single path
   between one source (or client) and one destination (or server).
   Finally, the Internet was designed with the client-server model in
   mind assuming that many clients receive information from (a smaller
   number of) servers.

   During the last years, these assumptions have been severely
   challenged :

   o  The client-server model does not correspond to the current
      operation of many applications.  First, large servers are usually
      replicated and different types of content distribution networks
      are used to efficiently distribute content.  Second, the
      proliferation of peer-to-peer applications implies that most
      clients also act as server.  This is creating several problems in
      many ISP networks [1].  The client-server asymmetry does not hold
      anymore as earlier.

   o  Due to the transition from IPv4 to IPv6 many hosts will be dual-
      stack for the foreseeable future [2].  Furthermore, measurements
      show that IPv4 and IPv6 do not provide the same performance [3],
      even for a single source-destination pair.  This implies that to
      reach a destination supporting both IPv4 and IPv6, a source will
      need to select the utilization of IPv4 or IPv6.

   o  Host based Multihoming techniques such as [4] are emerging.  These
      techniques assume that each host of a multihomed site will have
      several IPv6 addresses (e.g., one per provider).

   o  Several locator/identifier separation protocols [5] [6] being
      discussed within the IRTF Routing Research Group allow one
      identifier to be reachable via multiple locators.

   A consequence of the deployment of these new techniques is that the
   number of end-to-end paths that are available to reach a given
   destination/content will grow.  Several studies and practical
   experience show that resilience of the Internet increases with the
   number of paths [7][8] since if one path fails, it is likely that the
   other paths will continue to work provided that they are sufficiently
   disjoint.  Also, the availability of multiple paths may allow a
   better use of the Internet infrastructure by providing better paths
   in terms of delay, bandwidth, and congestion compared to the unique



Bonaventure, et al.      Expires August 21, 2008                [Page 3]

Internet-Draft           Informed path selection           February 2008


   current IPv4 paths.  This has been shown by several measurements
   studies [8][9].

   However, to obtain these benefits, the hosts (or the routers in some
   of the proposals being discussed within the IRTF RRG), will need to
   be able to accurately select the best path to use to reach a given
   (set of) destination(s).  Several solutions have been proposed to
   allow P2P applications to rank some paths over others [10] [11] [12].
   However, relying on proprietary solutions implies a duplication of
   efforts (e.g. different peer-to-peer applications may use different
   techniques and perform their own measurements).  Also, the existing
   solutions such as the static source address selection mechanism
   defined in [13] are static.

   In this document, we propose an informed path selection service that
   is able to rank paths based on policy and performance criteria.  A
   protocol to implement this service is described in a companion
   document [14].

   This document is organized as follows.  First, we provide a high-
   level description of the proposed service in Section 2.  Then, to
   illustrate the benefits of such a service, we recall in Section 3
   three issues for multihomed networks expressed by J. Schiller in
   [15].  In Section 4 we explain the limitations of existing (i.e.,
   BGP) and proposed techniques (i.e., shim6 and LISP) when solving
   these case studies.  In Section 5 we discuss several possible
   applications of the informed path selection service.  Finally, we
   compare the informed path selection service with related work in
   Section 6.


2.  The informed path selection service

   The informed path selection service is a distributed request-response
   service that allows to rank paths.  This service is typically
   supported inside a domain.  It can benefit from cooperation between
   domains but does not require it.














Bonaventure, et al.      Expires August 21, 2008                [Page 4]

Internet-Draft           Informed path selection           February 2008


                                     BGP, OSPF/ISIS    Measurements
                                       ||                  ||
                                       ||                  ||
                                       \/                  \/
                                     +------------------------+
                                     |                        |
                                     |    Informed Path       |
                                     |      Selection         |
                                     |       Service          |
              +--------+   request   |                        |
              | client | -->----     |                        |
              |        |   -----<--- |                        |
              +--------+  response   +------------------------+
                                              /\
                                              ||
                                           Policies

                      Informed path selection service

                                 Figure 1

   The informed path selection service is used to decide the best
   path(s) among a set of candidate paths.  It can be queried by a host
   having multiple addresses, a LISP router or other entities that need
   to rank paths such as peer-to-peer applications, content distribution
   networks, dual-stack hosts, ...  The informed path selection service
   is based on a request/response mechanism and the path ranking may
   depend on several factors including :

   o  Routing information (e.g., BGP, OSPF/ISIS) that allow the informed
      path selection service to compare different paths based on routing
      metrics (e.g.  BGP local preference, BGP AS-Path length, IGP path
      length, ...).

   o  Active or passive measurements (e.g., delay, bandwidth, loss, ...)
      that allow the informed path selection to compare different paths
      based on quantitative performance metrics.

   o  Policies configured by the network administrator that indicate
      preferences for some paths over others.

   A request will contain the following information :

   o  one or more source addresses (or prefixes),

   o  one or more destination addresses (or prefixes).

   Upon reception of a request, the informed path selection service



Bonaventure, et al.      Expires August 21, 2008                [Page 5]

Internet-Draft           Informed path selection           February 2008


   builds a list of all the possible paths between the source(s) and the
   destination(s).  Then, it removes from consideration the paths that
   are invalid due to routing (e.g., one destination is not reachable
   from a given source address) or policies.  These remaining paths are
   ranked and the reply contains the following information :

   o  the best path (source address, destination prefix),

   o  the second best path (source address, destination prefix),

   o  ...

   o  the Nth best path (source address, destination prefix),

   o  the lifetime for the ranked paths.

   As indicated above, the number of paths returned by the path
   selection service may be lower than the total number of possible
   paths, e.g., because some paths are not usable due to policy reasons
   or because some destinations are not reachable by using some source
   addresses.

   For scalability reasons and based on the experience in developing the
   NAROS protocol [16], the informed path selection service uses two
   mechanisms to allow the client to use the same path for several
   flows.  First, an ordered list of paths is valid for some time and
   the client is encouraged to cache the ordered list for the lifetime
   indicated in the response.  Second, the response may contain paths
   that are composed of a source and a destination prefix instead of
   addresses.  This choice is motivated by the fact that all the IP
   addresses that belong to the same prefix are usually covered by the
   same policies and have similar performance.  Simulations performed
   earlier showed that these two mechanisms allow to significantly
   reduce the number of requests sent to an informed path selection
   service by a given host [8].


3.  Issues with multihoming

   To illustrate the benefits of an informed path selection service and
   compare it with existing techniques, we first summarize the concerns
   raised by J. Schiller on multihoming in [15].  We focus on the three
   main case study described in [15].

3.1.  Case 1 : Primary/Backup

   The first issue mentioned in [15] is the classical case of a
   multihomed network using one primary provider and another as backup.



Bonaventure, et al.      Expires August 21, 2008                [Page 6]

Internet-Draft           Informed path selection           February 2008


   This case is illustrated in Figure 2 where the multihomed customer is
   attached to UUNet/MCI and ATT.  In this example, traffic engineering
   objectives of the multihomed customer are :

   o  All outgoing packets must be sent via UUNet/MCI when this link is
      active.  Otherwise, the packets must be sent via ATT.

   o  All incoming packets must be received via UUNet/MCI when this link
      is active.  Otherwise, the packets must be received via ATT.


                 +---------------+       +---------------+
                 |   UUNET/MCI   +-~-~-~-+      AT&T     |
                 +------:--------+       +-------:-------+
                        \                       //
                         \                     //
                          \                   //
                           \                 //
                            \               //
                             \             //
                              \           //
                               \         //
                                \       //
                                 \     //
                             +----:----:-----+
                             |   Multihomed  |
                             |    customer   |
                             | 63.63.62.0/23 |
                             +---------------+

                 --- primary link to UUNET
                 === backup link to AT&T
                 -~- Internet

                Example of a Primary/Backup implementation

                                 Figure 2

   This problem has been generalized in [15] as follows : "It is
   required to have the ability to set a link or a set of links as
   primary and some other as backup links.  Such that all the traffic is
   carried by the primary links while backup links are used only while
   primary links become unavailable."

3.2.  Case 2 : Load Sharing

   The second case mentioned in [15] is load sharing across links from
   different providers.  This problem is illustrated in Figure 3.  In



Bonaventure, et al.      Expires August 21, 2008                [Page 7]

Internet-Draft           Informed path selection           February 2008


   this example, the high-level objectives of the multihomed customer
   can be specified as :

   o  The same amount of outgoing packets should be sent via the UUNet/
      MCI and ATT links.

   o  The same amount of incoming packets should be received via UUNet/
      MCI and ATT links.

                               Load sharing

                 +---------------+       +---------------+
                 |   UUNET/MCI   +-~-~-~-+      AT&T     |
                 +------:--------+       +-------:-------+
                       \                       //
                        \                     //
                         \                   //
                          \                 //
                           \               //
                            \             //
                             \           //
                              \         //
                               \       //
                                \     //
                            +----:----:-----+
                            |   Multihomed  |
                            |    customer   |
                            | 63.63.62.0/23 |
                            +---------------+

                 --- link to UUNET
                 === link to AT&T
                 -~- Internet

                                 Figure 3

   This problem can, of course, be generalized by considering more than
   two links/providers and also by requiring unequal load sharing among
   the different links (e.g. based on link cost, link capacity, ...).

3.3.  Case 3 : Best Path

   The third case mentioned in [15] is that it should be possible for
   the multihomed customer to have ways to decide whether the paths
   available via one provider are better than the paths available via
   the other provider and use the best paths.  The high-level objectives
   of the multihomed customer in this case become




Bonaventure, et al.      Expires August 21, 2008                [Page 8]

Internet-Draft           Informed path selection           February 2008


   o  For each destination, send the outgoing packets via the provider
      that has the best path to reach this destination.

   o  For each source, receive the incoming packets via the provider
      that is on the best path from this source.

   This problem can be generalized to cover more than two links and
   providers.


4.  Existing multihoming solutions

   In this section, we evaluate how three technical solutions that are
   used today or are being discussed within the IETF/IRTF are able to
   meet the objectives mentioned above.  We first start with BGP-based
   multihoming as described in [15], then discuss shim6 [4] and finally
   LISP [5].

4.1.  BGP-based multihoming

   BGP-based multihoming is a common and widely deployed technique that
   allows a multihomed network to be attached to different providers.
   It is used by existing IPv4 and IPv6 deployments.

4.1.1.  Case 1 : Primary/Backup

   With BGP-based traffic engineering, the common techniques to
   implement primary/backup links are the following [15]:

   o  Set a higher MED for backup links from the same AS.

   o  Set a lower local-preference for backups links of different ASes.

   o  Set a higher weight for static default routes on backup links.

   The main issue with these BGP-based solutions is that a prefix must
   be allocated to each multihomed customer.  Furthermore, this prefix
   is advertised in the BGP routing tables and thus contributes to the
   growth of these routing tables [17].

4.1.2.  Case 2 : Load Sharing

   To solve the load sharing case, several techniques can be used on BGP
   routers.  The following are presented in [Schiller-TE] [15]

   o  Divide IP space and more specific routes announces over the
      different links.




Bonaventure, et al.      Expires August 21, 2008                [Page 9]

Internet-Draft           Informed path selection           February 2008


   o  Modify the MED or local preferences of inbound links.

   o  Modify IGP metrics to move hosts closer to a given exit point.

   o  Manipulate equal cost static default routes.

   Figure 4 from [15] shows how BGP can be used to solve the load
   sharing problem by dividing the IP space of the multihomed customer
   and sending more specific routes.  This solution has several
   drawbacks.  First, it contributes to the growth of the BGP routing
   tables by requiring each multihomed customer to advertise more than
   one prefix [17].  Second, the solution is far from perfect and
   assumes that the two /23 more specific prefixes carry almost the same
   amount of packets.  If this is not the case or if the amount of
   packets changes with time, then the more specific prefixes that need
   to be advertised also need to change with time.  This is not
   desirable as a multihomed customer willing to move some packets from
   one link to another would need to send BGP updates that would change
   over time.
































Bonaventure, et al.      Expires August 21, 2008               [Page 10]

Internet-Draft           Informed path selection           February 2008


              +---------------+          +---------------+
              |   UUNET/MCI   +-~-~-~-~-~+      AT&T     |
              +------:--------+          +-------:-------+
                      \                         //
                       \                       //
                        \                     //
                         \                   //
             advertise 63.63.62.0/23   advertise 63.63.62.0/23
             advertise 63.63.62.0/24   advertise 63.63.63.0/24
                            \             //
                             \           //
                              \         //
                               \       //
                 receive default\     //receive default
                            +----:----:-----+
                            |   Multihomed  |
                            |    customer   |
                            | 63.63.62.0/23 |
                            +---------------+

             --- primary link to UUNET
             === primary link to AT&T
             -~- Internet

                 Example of a load sharing implementation

                                 Figure 4

4.1.3.  Case 3 : Best Path

   With BGP-based multihoming, several techniques can be used to select
   the best path based on different definitions of best.  They all
   require the multihomed customer to receive the full BGP routing
   tables from its providers and run BGP.  A drawback of this solution
   is that the definition of "best path" either depends on the limited
   BGP attributes or must be tuned manually.  Measurements have shown
   that there is not a strong correlation between the length of the AS
   Path carried in BGP messages and the performance of path measured in
   terms of delay or bandwidth [18].

   o  Best path is selected according to the BGP Decision process
      depicted in [19] section 9.1.

   o  Traffic is controlled by the BGP path selection algorithm of the
      source of the traffic.

   o  Manual changes can be used to move traffic from over-loaded links
      to under-loaded links.



Bonaventure, et al.      Expires August 21, 2008               [Page 11]

Internet-Draft           Informed path selection           February 2008


4.2.  Shim6 host-based multihoming

   The shim6 host-based multihoming technique is based on the assumption
   that multihomed hosts will use one IPv6 address per provider.  It is
   expected that most multihomed customers will use PA addresses.  In
   this case, the multihomed customer does not need to advertise any
   prefix with BGP.  The basic network scenario with shim6 is depicted
   in Figure 5.


                +---------------+         +---------------+
                |   UUNET/MCI   +-~-~-~-~-+      AT&T     |
                |               |         |               |
                |   2001::/48   |         |    2002::/48  |
                +------:--------+         +-------:-------+
                        \                        //
                         \                      //
                          \                   //
                           \                 //
                            \               //
                             \             //
                              \           //
                               \         //
                            +---:--------:---+
                            |   Multihomed   |
                            |    customer    |
                            |                |
                            |   2001::1:A    |
                            |   2002::A:1    |
                            +----------------+

                --- primary link to UUNET
                === backup link to AT&T
                -~- Internet

                Example of a Primary/Backup implementation

                                 Figure 5

4.2.1.  Case 1 : Primary/Backup

   With the current IPv6 and shim6 specifications, a primary/backup
   implementation can be supported by using the default address
   selection specified in [13].  This specification defines a table that
   is used by each host to select the source address that it will use to
   reach a given destination based on the type of address, the prefix
   length and preferences that can be defined by the system
   administrators.  This solution allows all hosts to prefer once source



Bonaventure, et al.      Expires August 21, 2008               [Page 12]

Internet-Draft           Informed path selection           February 2008


   address over the other.  However, no protocol has been defined to
   allow a system administrator to distribute the current preferences to
   its hosts.  This implies that the preference is rather static.

4.2.2.  Case 2 : Load Sharing

   Concerning load sharing, the current shim6 specification [4] can be
   configured by using the preferences of the source address selection
   mechanism to prefer one link over the other.  As with BGP-based
   multihoming, this solution is static, it is difficult to dynamically
   change the source address selection preferences of the hosts to
   follow the evolution of the traffic patterns.

4.2.3.  Case 3 : Best Path

   The current shim6 specification does not expect that the hosts will
   select the source and destination addresses for a shim6 session based
   on performance metrics but does not preclude it.  An unrealistic
   option would be to add a BGP and IGP routing table on each host to
   allow them to select the best (source address,destination address)
   pair based on BGP metrics.  Additional information about operator's
   concerns with shim6 may be found in [20].

4.3.  Dual stack IPv4/IPv6

   Several mechanisms have been proposed to ease the transition from the
   current IPv4 Internet towards an IPv6 Internet.  As of today, nobody
   expects that the IPv6 Internet will completely replace the IPv4
   Internet quickly and that both Internets will coexist for several
   years or more.  For the foreseeable future, many networks will be
   attached to both IPv6 and IPv4 providers.  When considering the three
   case studies, the dual stack IPv4/IPv6 hosts have several problems as
   shim6 hosts discussed in the previous section.  The only difference
   is that a host cannot switch from using IPv4 to using IPv6 for an
   established flow (i.e., if IPv4 connectivity becomes broken but IPv6
   connectivity remains active).

4.4.  LISP and multihoming issues

   The Locator/Identifier Separation Protocol (LISP) [5] is currently
   being discussed within the IRTF Routing Research Group as one of the
   possible alternatives to achieve a better scaling of the Internet
   architecture.  LISP distinguishes between identifiers and locators.
   The identifiers are used to identify endhosts.  The locators are
   assigned to ingress routers that implement the LISP tunneling scheme.
   When an endhost needs to contact a remote endhosts, it sends a packet
   with its own identifier as source address and the identifier of the
   remote host as destination address.  This packet will be intercepted



Bonaventure, et al.      Expires August 21, 2008               [Page 13]

Internet-Draft           Informed path selection           February 2008


   by the first LISP router on its path.  This router uses a mapping
   system to query the locator that allows to reach the (identifier of
   the) remote host and encapsulates the packet before sending it to the
   locator associated to the remote host.


                +---------------+          +---------------+
                |   UUNET/MCI   +-~-~-~-~-~+      AT&T     |
                | 210.0.0.0/8   |          |   11.0.0.0/8  |
                +------:--------+          +-------:-------+
                        \                         //
                         \                       //
                          \                     //
                           \                   //
                            \                 //
                             \               //
                              \             //
                               \           //
                              +----:----:-----+
                              |   Multihomed  |
                              |    customer   |
                              |    Locators   |
                              | 210.1.2.0/29  |
                              | 11.200.2.0/28 |
                              +---------------+

               --- primary link to UUNET
               === backup link to AT&T
               -~- Internet

                         Example of LISP scenario

                                 Figure 6

4.4.1.  Case 1 : Primary/Backup

   With the current LISP specification, the primary/backup case can be
   covered by considering the priority that is associated to an EID/
   locator mapping.  A LISP router will prefer the locator having the
   highest priority.  This allows each LISP router to select the best
   locator to reach a given destination.

4.4.2.  Case 2 : Load Sharing

   In addition to the priority mentioned above, LISP also associates a
   weight to each locator.  When several locator have the same priority,
   then load sharing should be performed among the different locators
   based on their weight.



Bonaventure, et al.      Expires August 21, 2008               [Page 14]

Internet-Draft           Informed path selection           February 2008


4.4.3.  Case 3 : Best Path

   If the LISP routers of the multihomed site run BGP, they can use the
   BGP decision process to rank some routes over others.  However, as
   explained earlier, the correlation between BGP attributes such as the
   length of the AS Path and the performance of interdomain paths is
   weak.


5.  Application of the informed path selection service

   In this section, we briefly discuss how the informed path selection
   service could improve the performance of multihomed networks by
   considering our three case studies.  As an example, we consider that
   the informed path selection service is queried by hosts, but the same
   result would apply for LISP routers.

5.1.  Case 1 : Primary/Backup

   By using the informed path selection service, the primary/backup case
   can be easily solved.  Upon reception of a request, the server simply
   needs to always place the prefixes that correspond to the primary
   link at the top of the list and possibly remove the prefixes
   associated to the backup link from the reply.  When the primary link
   fails, the server updates its ranking to allow the hosts to use the
   backup link instead.

5.2.  Case 2 : Load Sharing

   The load sharing case can be naturally solved by using an informed
   path selection service.  Indeed, the service could easily track the
   load on the different links and dynamically change its replies based
   on the link load.  The NAROS protocol [16], proposed in the early
   days of IPv6 multihoming, was designed to solve this problem and the
   evaluation showed that it worked well [8].

5.3.  Case 3 : Best Path

   The informed path selection service brings new benefits for the Best
   path case as it allows the server to base its ordering on active
   measurements to assess the performance of paths by considering
   metrics such as delay or bandwidth.  The informed path selection
   service is not restricted to the BGP information as in the current
   BGP-based multihoming techniques.







Bonaventure, et al.      Expires August 21, 2008               [Page 15]

Internet-Draft           Informed path selection           February 2008


5.4.  Other applications of the informed path selection service

   The informed path selection service is not limited to multihomed
   networks.  It can be used in any environment where several paths need
   to be ranked based on policies and/or performance.

   The peer to peer applications are clear candidate users for such a
   service.  Some peer-to-peer applications already rely on heuristics
   to prefer some sources over others.  A standardized path selection
   service would allow several peer-to-peer applications to share the
   same measurements.  Furthermore, an ISP or campus network running the
   informed path selection service could influence providers used by the
   packets sent/received by the hosts of its networks.

   The informed path selection service could be associated to a DNS
   resolver or server.  When a DNS resolver receives a DNS reply
   containing several addresses for the same name, it could rank them
   and return a ranked DNS response.  A DNS server implementing [21]
   could contact the informed path selection service to update
   dynamically the SRV RR of its local servers.

   The informed path selection service could also be useful for
   multihomed VoIP gateways that need to select the best VoIP gateway to
   forward a voice call.


6.  Related work

   Several solutions have been proposed to improve the performance of
   end-to-end paths.  A first approach was proposed with the RSVP
   signaling protocol [22] and the Integrated Services Architecture
   [23].  RSVP allows to reserve resources on all routers along and end-
   to-end path but does not allow a host to prefer one path over
   another.  Other signaling protocols have been or are being proposed
   to install and maintain state on some intermediate nodes [24].  Our
   proposed path selection service follows the end-to-end principle [25]
   and does not create any state in intermediate nodes.

   Due to scalability concerns, the Integrated Services Architecture has
   not been widely deployed.  Differentiated Services [26] were
   introduced as a more scalable solution based on packet marking.
   Differentiated Services does not by itself allows hosts to prefer
   some paths over others.  However, recent extensions to link state
   routing protocols or the utilization of MPLS allow network operators
   to provision different paths for different classes of services.  Our
   proposed path selection service allows the client to also indicate a
   DSCP in the request to support hosts and applications that are using
   non best-effort service.  Although it does not require Differentiated



Bonaventure, et al.      Expires August 21, 2008               [Page 16]

Internet-Draft           Informed path selection           February 2008


   services, it can easily cooperate with it.

   Several researchers have proposed solutions to similar problems.  For
   example, [27] proposed a mechanism where the source prefix of shim6
   data packets is rewritten by the site routers.  The proposed informed
   path selection service does not require routers to change source
   prefixes. [12] proposed an oracle service that would be configured by
   the network operator and queried by peer-to-peer applications.  The
   oracle could be one of the ways to implement a path selection
   service.  Other mechanisms have been proposed specifically for peer-
   to-peer applications [28] [10] [11].


7.  Security Considerations

   By ranking paths, the informed path selection service influences the
   path that hosts will use to send packets to some destinations.  By
   controlling the informed path selection service, an attacker diverts
   packets through a path that he controls to create man-in-the middle
   attacks or divert packets over an overload path to increase
   congestion.  These problems are similar to the security issues with
   DNS resolver since an attacker who controls a DNS resolver could
   obtain similar results.  To mitigate these risks, it should be
   possible for the clients that are using the informed path selection
   service to authenticate the responses received from a server.


8.  Conclusion

   In this document, we have proposed an informed path selection service
   that is able to rank paths based on policies or performance criteria.
   A companion document [14] proposes a protocol to support this
   service.


9.  Acknowledgements

   This work was partially supported by the European Commission within
   the IST AGAVE and IST ONELAB projects.


10.  Normative References

   [1]   Karagiannis, T., Rodriguez, P., and K. Papagiannaki, "Should
         Internet Service Providers Fear Peer-Assisted Content
         Distribution?", Internet Measurement Conference 2005,
         October 2005.




Bonaventure, et al.      Expires August 21, 2008               [Page 17]

Internet-Draft           Informed path selection           February 2008


   [2]   Cho, K., Luckie, M., and B. Huffaker, "Identifying IPv6 network
         problems in the dual-stack world", ACM SIGCOMM Workshop on
         Network Troubleshooting  283 - 288, September 2004.

   [3]   Zhou, X., Jacobsson, M., Uijterwaal, H., and P. Van Mieghem,
         "IPv6 delay and loss performance evolution", International
         Journal of Communication Systems  DOI: 10.1002/dac.916, 2007.

   [4]   Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming Shim
         Protocol for IPv6", draft-ietf-shim6-proto-09 (work in
         progress), November 2007.

   [5]   Farinacci, D., "Locator/ID Separation Protocol (LISP)",
         draft-farinacci-lisp-05 (work in progress), November 2007.

   [6]   Vogt, C., "Six/One: A Solution for Routing and Addressing in
         IPv6", draft-vogt-rrg-six-one-01 (work in progress),
         November 2007.

   [7]   Andersen, D., Balakrishnan, H., Kaashoek, F., and R. Morris,
         "Resilient Overlay Networks", Proc. 18th ACM SOSP Banff,
         Canada, October 2001.

   [8]   de Launois, C., "Unleashing traffic engineering for IPv6
         multihomed sites", PhD thesis available from
         http://inl.info.ucl.ac.be/delaunoi, October 2005.

   [9]   Akella, A., Maggs, B., Seshan, S., Shaikh, A., and R.
         Sitaraman, "A measurement-based analysis of multihoming", Proc.
         SIGCOMM (Karlsruhe, Germany, August 2003.

   [10]  Xie, H., Krishnamurthy, A., Yang, R., and A. Silberschatz,
         "P4P: Proactive Provider Participation for P2P", Yale Computer
         Science YALE/DCS/TR1377 , March 2007.

   [11]  Dabek, F., Cox, R., Kaashoek, F., and R. Morris, "Vivaldi: a
         decentralized network coordinate system", Proc. SIGCOMM
         2004 15-26, August 2004.

   [12]  Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs and
         P2P systems co-operate for improved performance?", ACM SIGCOMM
         Computer Communications Review Volume 37, Number 3, July 2007.

   [13]  Draves, R., "Default Address Selection for Internet Protocol
         version 6 (IPv6)", RFC 3484, February 2003.

   [14]  Saucez, D., Donnet, B., and O. Bonaventure, "IDIPS : ISP-Driven
         Informed Path Selection", Internet-Draft



Bonaventure, et al.      Expires August 21, 2008               [Page 18]

Internet-Draft           Informed path selection           February 2008


         draft-saucez-idips-00, February 2008.

   [15]  Schiller, J., "Inter-AS Traffic Engineering Case Studies as
         Requirements for IPv6 Multihoming Solutions", NANOG 35,
         May 2005.

   [16]  Launois, C. and O. Bonaventure, "NAROS : Host-Centric IPv6
         Multihoming with Traffic Engineering",
         draft-de-launois-multi6-naros-00 (work in progress), May 2003.

   [17]  Meyer, D., "Report from the IAB Workshop on Routing and
         Addressing", draft-iab-raws-report-02 (work in progress),
         April 2007.

   [18]  Huffaker, B., Fomenkov, M., Plummer, D., and k. Claffy,
         "Distance Metrics in the Internet",  IEEE International
         Telecommunications Symposium , September 2002.

   [19]  Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
         RFC 1771, March 1995.

   [20]  Schiller, J., "Shim6 : network operator concerns", IAB
         Workshop , October 2005.

   [21]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
         specifying the location of services (DNS SRV)", RFC 2782,
         February 2000.

   [22]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
         "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
         Specification", RFC 2205, September 1997.

   [23]  Braden, B., Clark, D., and S. Shenker, "Integrated Services in
         the Internet Architecture: an Overview", RFC 1633, June 1994.

   [24]  Manner, J. and X. Fu, "Analysis of Existing Quality-of-Service
         Signaling Protocols", RFC 4094, May 2005.

   [25]  Saltzer, J., Reed, D., and David. Clark, "End-to-end arguments
         in system design", ACM Transactions on Computer Systems Vol 2,
         N 4 (November 1984) pages 277-288, November 1984.

   [26]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W.
         Weiss, "An Architecture for Differentiated Services", RFC 2475,
         December 1998.

   [27]  Bagnulo, M., Garcia-Martinez, A., and A. Azcorra, "BGP-like TE
         Capabilities for SHIM6", EUROMICRO 2006, September 2006.



Bonaventure, et al.      Expires August 21, 2008               [Page 19]

Internet-Draft           Informed path selection           February 2008


   [28]  Ledlie, J., Gardner,, P., and M. Seltzer, "Network Coordinates
         in the Wild", Proceedings of NSDI 2007 , April 2007.


Authors' Addresses

   Olivier Bonaventure
   Universite catholique de Louvain
   Place Sainte Barbe 2
   Louvain-la-Neuve,   1348
   Belgium

   URI:   http://inl.info.ucl.ac.be


   Damien Saucez
   Universite catholique de Louvain
   Place Sainte Barbe 2
   Louvain-la-Neuve,   1348
   Belgium

   Email: damien.saucez@uclouvain.be
   URI:   http://inl.info.ucl.ac.be


   Benoit Donnet
   Universite catholique de Louvain
   Place Sainte Barbe 2
   Louvain-la-Neuve,   1348
   Belgium

   Email: benoit.donnet@uclouvain.be
   URI:   http://inl.info.ucl.ac.be


















Bonaventure, et al.      Expires August 21, 2008               [Page 20]

Internet-Draft           Informed path selection           February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Bonaventure, et al.      Expires August 21, 2008               [Page 21]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/