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]