Internet Engineering Task Force O. Akonjang
Internet-Draft A. Feldmann
Intended status: Informational DT Labs/TU Berlin
Expires: September 3, 2009 S. Previdi
B. Davie
Cisco Systems, Inc.
D. Saucez
Universite catholique de Louvain
March 2, 2009
The PROXIDOR Service
draft-akonjang-alto-proxidor-00.txt
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 September 3, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Akonjang, et al. Expires September 3, 2009 [Page 1]
Internet-Draft ALTO PROXIDOR March 2009
Abstract
Several applications, such as peer-to-peer (P2P), content
distribution and realtime services rely on selection mechanisms in
order to select the peer or server from which to request the service.
Examples of such services are: file sharing, media streaming and
voice gateways.
Application-layer selection algorithms do not typically take into
account network-layer topology information; either that information
is unavailable to them, or when such information is available (e.g.,
from BGP Looking Glass servers), it does not include sufficient
information about the local topology in the neighbourhood of the
application client(s). Therefore, most applications today make their
selection decisions based on performance measurements (combined with
some amount of random selection) and largely ignore network layer
routing. It has been demonstrated that by keeping the traffic local
(e.g., within the same Autonomous System) both infrastructure
utilization and application performance may be improved.
By enhancing selection algorithms through the use of accurate
network-layer topology, applications may improve performance while
network operators are also able to reduce the utilization of
infrastructure resources by application traffic. At the same time,
exchange of information between the application and the network
should not be allowed to compromise confidentiality for either party.
Detailed routing information owned by the service provider should not
be made publicly available, while detailed information about the
application should also not be made known to the service provider.
This draft introduces a signaling protocol which we call "PROXIDOR".
The PROXIDOR protocol is a request-response protocol in which a
PROXIDOR Client (PxC) issues requests to and receives responses from
a PROXIDOR Server (PxS). The questions of how a PxC discovers a PxS
and how a PxS acquires network-layer topology information are beyond
the scope of this document.
Akonjang, et al. Expires September 3, 2009 [Page 2]
Internet-Draft ALTO PROXIDOR March 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Historical Background of this Proposal . . . . . . . . . . 5
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Benefits of the PROXIDOR Service . . . . . . . . . . . . . . . 5
3.1. Benefits to End-users . . . . . . . . . . . . . . . . . . 5
3.2. Benefits to the ISP . . . . . . . . . . . . . . . . . . . 5
4. The PROXIDOR Architecture . . . . . . . . . . . . . . . . . . 5
4.1. Definitions and Terminologies . . . . . . . . . . . . . . 6
4.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Design Choices . . . . . . . . . . . . . . . . . . . . . . 7
5. Entities of the PROXIDOR System . . . . . . . . . . . . . . . 8
5.1. The PROXIDOR Client . . . . . . . . . . . . . . . . . . . 8
5.2. The PROXIDOR Server . . . . . . . . . . . . . . . . . . . 9
5.3. The Ranking System . . . . . . . . . . . . . . . . . . . . 9
6. PROXIDOR Messages . . . . . . . . . . . . . . . . . . . . . . 10
6.1. The Query Message . . . . . . . . . . . . . . . . . . . . 10
6.2. The Response Message . . . . . . . . . . . . . . . . . . . 10
7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. The Oracle Use Case . . . . . . . . . . . . . . . . . . . 11
7.2. The Proximity Use Case . . . . . . . . . . . . . . . . . . 12
7.3. The IDIPS Use Case . . . . . . . . . . . . . . . . . . . . 13
8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . . 15
Akonjang, et al. Expires September 3, 2009 [Page 3]
Internet-Draft ALTO PROXIDOR March 2009
1. Introduction
This draft introduces the concept of a PROXIDOR service (PS). A
PROXIDOR Service (PS) aims to deliver to selection algorithms at the
application layer (or any other consumer of the PROXIDOR service) the
topological guidance that will allow an improved selection scheme,
taking into considerations the topology and infrastructure that is
going to be used for transmitting data from/to a given selected peer,
host or server. The protocol defined in this draft aims to be
generic and exploitable by any application entity requiring such a
service, no matter its architecture and implementation.
This draft describes a signaling protocol through which a PROXIDOR
Client (PxC) requests service from a PROXIDOR Server (PxS). In the
current version of the document, the protocol is described only in
high-level, abstract terms.
As an example, a peer-to-peer client, once it has obtained from the
application layer the list of peers through which a given content or
service can be obtained, requests PROXIDOR services from a PROXIDOR
server. The PROXIDOR query is built with the list of candidate
peers' IP addresses and sent to the PxS. The PxS replies with the
original list of IP addresses sorted by preference.
The definition of "preference" in this context requires some further
explanation. By assigning a higher preference to a particular
address, the PxS indicates to the application that, all things being
equal, the application should prefer that address to other addresses
of lower preference. Exactly what the PxS means by higher
preference, or how this preference is calculated, is intentionally
not made explicit. As an example, preference may be calculated by
using routing metric distance, with nodes that are a shorter distance
from the requester being given a higher preference than those that
are at a greater distance. Such a calculation could, for example, be
performed by inspecting network-layer information (IGP, BGP, etc) and
may also be influenced by policies of the service provider.
We assume that the service provider cannot force the application to
adhere to the preferences that the PROXIDOR service provides.
Therefore, the service provider has an incentive to provide
information that is useful to the application; otherwise it is likely
to be ignored.
Although we use IP addresses in the preceding example, similar
ranking operations could also be performed on AS numbers, address
prefixes, etc. While it is necessary to ensure interoperability
through the standardization of the signaling protocol, there is no
immediate need to standardize any algorithm or any computational
Akonjang, et al. Expires September 3, 2009 [Page 4]
Internet-Draft ALTO PROXIDOR March 2009
method that computes ranks or preferences.
1.1. Historical Background of this Proposal
The architecture and protocol described in this document arose from
the merger of three previous pieces of work: the Oracle service [1],
the ISP-Driven Informed Path Selection (IDIPS) service [5] and the
Proximity service [6]. The name PROXIDOR, like the proposal itself,
contains elements of each of these three original work items.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Benefits of the PROXIDOR Service
The PROXIDOR service offers many benefits to both end-users
(consumers of the service) and Internet Service Providers (ISPs)
(providers of the service).
3.1. Benefits to End-users
Hosts that use the PROXIDOR service can benefit in multiple ways,
e.g., they no longer need to infer topology information or measure
path performance by themselves. They can take advantage of the
knowledge of the ISP to avoid bottlenecks and boost performance.
3.2. Benefits to the ISP
ISPs also benefit from the PROXIDOR service. It enables them to
influence the neighborhood selection process of overlay networks to
e.g. ensure locality of traffic and also regain the ability to
efficiently engineer traffic that traverses backbone and transit
links, thus allowing a better provisioning of the networking
infrastructure.
4. The PROXIDOR Architecture
The PROXIDOR architecture can be defined in terms of its entities,
the set of messages that are exchanged between these entities and the
rules governing the exchanges.
Akonjang, et al. Expires September 3, 2009 [Page 5]
Internet-Draft ALTO PROXIDOR March 2009
4.1. Definitions and Terminologies
Autonomous System (AS):
A single network or a collection of networks under the same
administrative control.
Autonomous System Number (ASN):
A globally unique number, used to identify an AS and to exchange
exterior routing information with other (neighboring) ASes.
PROXIDOR client (PxC):
An Internet end-host that requests for PROXIDOR services by
creating and sending queries.
PROXIDOR server (PxS):
An Internet system that accepts and processes PROXIDOR queries.
Metric:
Criteria used by server to process/rank IP addresses,
prefixes or ASNs in a query.
PROXIDOR Query (PxQ):
A message to request for a particular PROXIDOR service.
PROXIDOR Response (PxR):
An answer to a PROXIDOR query.
PROXIDOR Error (PxE):
Indicates non-conformity.
PROXIDOR Failure (PxF):
A PROXIDOR system malfunction.
PROXIDOR Services (PS):
A PROXIDOR service that can be directly requested by clients.
PROXIDOR Service Protocol (PSP):
The protocol used by PROXIDOR entities to communicate with
each oher.
PROXIDOR Source List (PSL):
A list of sources that is sent to PxS for ranking.
PROXIDOR Target List (PTL):
A list of targets that is sent to PxS for ranking.
PROXIDOR Couples (PC):
A ranked list of <source, destination>.
Akonjang, et al. Expires September 3, 2009 [Page 6]
Internet-Draft ALTO PROXIDOR March 2009
PROXIDOR Source Address (PSA):
Source IP or Prefix address used in PxQ when requesting for
PROXIDOR services.
Type Length Value (TLV):
Data encoding format for PROXIDOR payloads.
4.2. Scope
This draft defines the PROXIDOR service, describes its functionality
and gives details of its architecture. Details of the PROXIDOR
protocol itself (i.e., details of the messages that are exchanged
between entities of the PROXIDOR service) are out of scope of this
document.
4.3. Design Goals
We expect the PROXIDOR service to be requested by a high number of
simultaneous clients and therefore aspects such as simplicity,
scalability, performance and flexibility are among the most important
criteria:
o Simplicity. The protocol must be lightweight in its content and
state machinery. Different flavors may be defined in order to
cope with different application scenarios. However, in most of
practical cases, the protocol should carry the minimal set of
information in its simplest form of encoding.
o Scalability. The protocol is expected to be used by a large
amount of consumers simultaneously, which means that providers
will have to absorb a large amount of transactions. Protocol
specification should take into account the scalability factors
that would allow the protocol and its implementations to scale.
o Performance. Related to scalability, PROXIDOR servers will have
to handle a high number of simultaneous transactions and therefore
the performance of handling protocol packets is critical for the
overall scalability and deployability of the protocol.
o Flexibility. The protocol should allow different modes of
operations with different encoding techniques.
4.4. Design Choices
Two major concerns of the PROXIDOR protocol design are scalability
and performance. A server (or a cluster of servers) should be able
to simultaneously handle a very large number of client requests and
yet, suffer no penalties in terms of performance. To address these
Akonjang, et al. Expires September 3, 2009 [Page 7]
Internet-Draft ALTO PROXIDOR March 2009
concerns, important design choices need to be made, including;
i) Choice of transport protocol:
The PROXIDOR service SHOULD be able to function with UDP, TCP
and HTTP.
ii) Choice of approach:
Although most aspects of the PROXIDOR protocol are new,
advantage is still taken of already existing protocols, such as
the Domain Name System (DNS) protocol. In principle, we see a
lot of functional similarities between the DNS and the PROXIDOR
service. The DNS is not only distributed and very scalable,
but can also effectively handle many queries from a large
number of clients simultaneously. The DNS protocol approach is
thus partly adopted.
Further concerns of the protocol design are flexibility and
extensibility. The protocol should be flexible enough to adapt to
changes in end-users' and ISPs' needs and be extensible enough to
incorporate new types of services without the need to undergo a
fundamental change.
To address these concerns, PROXIDOR uses both Service Codes (to
request for particular PROXIDOR services or to express their
preferences) and Service Categories (to create and categorize (new)
PROXIDOR service groups).
5. Entities of the PROXIDOR System
A PROXIDOR system consists of PROXIDOR clients and PROXIDOR servers.
Both entities implement the PROXIDOR protocol in order to interact
with each other. Each entity independently plays an important role
in the overall system architecture.
5.1. The PROXIDOR Client
The PROXIDOR client can either be an end-user host that generates and
sends queries to a PROXIDOR server or a PROXIDOR server that
generates and/or forwards queries to other PROXIDOR servers.
To use the PROXIDOR service, a client (PxC) must generate a standard
PROXIDOR query (PxQ) and send to the PROXIDOR server (PxS). It can
also optionally cache a copy of the sent packet. It MUST clear its
cache before attempting to contact another PROXIDOR server.
Akonjang, et al. Expires September 3, 2009 [Page 8]
Internet-Draft ALTO PROXIDOR March 2009
5.2. The PROXIDOR Server
A PROXIDOR server that receives a query, can generally react in one
of the following ways:
o grant the request by responding appropriately to the query,
o silently drop the query if it is e.g., running out of resources,
o send back a PROXIDOR error message (PxE), in case of a malformed
request,
o send back a PROXIDOR failure message (PxF), in case of system
malfunction,
o send back a re-direct message, re-directing the client to another
PROXIDOR server, if it doesn't offer the requested service and
knows another (trusted) server that does.
The server MAY also decide to explicitly express the criteria it used
in ranking the contents of the response message. It should be noted
that revealing the criteria does not directly reveal the algorithm or
functions that these criteria were used to construct.
The PROXIDOR protocol may also be used between servers. When a
server needs more accurate information that is not available in its
database, it may also use the PROXIDOR service to request this
information from another server. This could be typical in
environments such as the global coordinate system in [2]. PROXIDOR
protocol supports authentication between a client and a server and
between servers. Authentication could be used to establish a kind of
trust between PROXIDOR entities involved in a transaction.
5.3. The Ranking System
The most common (perhaps the default) criteria for the ranking system
is the minimal distance between the requester and each individual IP
address in the query message. In this case the PxS evaluates the
distance between requester and each address of the list and returns
the list in an ordered fashion. Distance is evaluated according to
the network-layer topology.
A different preference criteria can be specified, relying on AS
membership: Given an unsorted list of IP addresses, the PxS returns
the list ordered by preference in AS membership. The ranked list
starts with addresses belonging to the same AS of the requester, then
all other addresses ordered according to the number of AS-hops
between their AS and requester's AS.
Akonjang, et al. Expires September 3, 2009 [Page 9]
Internet-Draft ALTO PROXIDOR March 2009
The ranking system can also use criteria that are based on measured
performance, such as available bandwidth and link delays, as well as
those that are based on the ISP's private policies and need to be
taken into consideration.
Criteria MAY be used either alone or in combinations, when evaluating
preferences.
While a ranking is one way to assign preferences to addresses,
prefixes, etc., it may also be desirable to assign a weight to the
elements in the list, to indicate more clearly the extent to which
some elements are preferred over others. This approach is described
in [4].
The semantic of each ranking request is carried within the query
message (implicitly or explicitly). However, the server MAY or MAY
NOT take this into account.
6. PROXIDOR Messages
There are generally two types of PROXIDOR messages; the PROXIDOR
query (PxQ) message and the PROXIDOR response (PxR) message.
6.1. The Query Message
A standard (default) PROXIDOR query (PxQ) is that which is sent from
a PROXIDOR client (PxC) to a PROXIDOR server (PxS). A PROXIDOR
server (PxS) can also query another PxS using the same message
format. The PROXIDOR protocol differentiates between these two query
types.
Query messages may also carry requests that express desires for more
specific information or services. The server is not compelled to
grant them. The server MAY decide to grant or ignore them, depending
on its own preferences or individual policies. For example, it can
decide to grant server-generated desires sent by trusted PxS peers
and ignore client-generated ones that it considers to be too
intrusive.
6.2. The Response Message
Response messages are similar in structure to query messages.
Response messages can make use of attributes (optional) to send
additional information about designated payload types, e.g., when
responding to queries sent by a trusted PxS peer. Such peers could
exist within an AS or in a global coordinate system, made up of
PROXIDOR servers that are managed by different ISPs. The additional
information supplied by the use of attributes can help the receiving
Akonjang, et al. Expires September 3, 2009 [Page 10]
Internet-Draft ALTO PROXIDOR March 2009
server make better decisions before responding to client-generated
queries.
The order of the items in the response message is very important.
The first item indicates highest priority or preference and the last
one, least priority or preference. There is no general derivable
relationship between this order and the criteria used to create it,
since the latter MAY depend on factors that are of the PROXIDOR
Service Provider's individual choice.
Although some characteristics of the response message is also
determined by the same factors that affect those of the query
message, all response packets MUST additionally adhere to the
important factor of strict ranking. Ranking could force the response
payload to be packaged in particular orders relative to each other,
requiring the use of extra bytes in the response message than that
used in the query. The details of this aspect is out of scope of
this document.
7. Use Cases
Use cases are grouped according to service categories, such as the
Oracle service category, the Proximity service category and the IDIPS
service category.
7.1. The Oracle Use Case
i) The PROXIDOR service is used in a P2P environment to influence the
neighborhood selection process.
An end-host that wants to join a P2P overlay, first needs to
locate and cretae a list of potential neighbors. Instead of
randomly connecting to clients in the list, the end-host can use
the PROXIDOR service to establish a more effective connection
pattern.
1. The PROXIDOR client (PxC) creates a PROXIDOR Target List (PTL)
from the list of potentials neighbors.
2. PXC contructs a PROXIDOR query message (PxQ) with the PTL as
payload.
3. PxC then sends PxQ to a PROXIDOR server (PxS) for ranking.
4. PxS receives and extracts PTL from PxQ. It uses its knowledge
of the network to re-arrange the list, ranking them according
to some pre-defined criteria, e.g. locality and bandwidth.
Akonjang, et al. Expires September 3, 2009 [Page 11]
Internet-Draft ALTO PROXIDOR March 2009
+ The list is ranked according to priority (or preference),
i.e., from highest to lowest.
+ Proximal and optimal performing neighbors (relative to PxC)
are given highest priority and are placed at the top of the
list.
+ PxS can decide to supplement the response with extra
information through the use of attributes and their values.
5. PxS then sends the ranked PTL back to PxC.
6. PxC can now use the ranked PTL to establish optimal overlay
connections.
ii) The PROXIDOR service is used in a P2P environment to influence
the selection of sources from where content is downloaded.
After a successful search or after joining a swarm, PxC may have
multiple sources from which content could be downloaded. It can
use the PROXIDOR service again to locate the best sources (from
among these potential sources) to download from.
1. PxC creates a new PTL from the list of potential sources.
2. PxC constructs a new PxQ using the new PTL.
3. PxC sends the new PxQ to PxS.
4. PxS extracts and ranks the PTL according to optimal
performance.
5. PxS sends the ranked PTL back to PxC.
6. PxC can now use the ranked PTL to download from the best
ranked sources in a more efficient mannner.
7.2. The Proximity Use Case
1. PxC obtains from the application layer the list of servers/peers
where data or service is available. PxC builds a list of IP
addresses corresponding to these peers/servers.
2. PxC builds a PROXIDOR query (PxQ). PxC insert following
information in the query:
* PSA: the PxC IP address.
Akonjang, et al. Expires September 3, 2009 [Page 12]
Internet-Draft ALTO PROXIDOR March 2009
* PTL: the list of target IP addresses.
* PRC: set to IP-Address-based or AS-based.
3. PxC sends the PxQ to the PxS.
4. PxS receives PxQ and extracts the following information:
* PROXIDOR Source Address (PSA). PSA is the source IP address
of the requester.
* PROXIDOR Target List (PTL). PTL is the list of IP addresses
for which PROXIDOR service is requested.
* PROXIDOR Ranking Criteria.
5. PxS computes PROXIDOR algorithms and ranks the PTL based on PRC.
Preference is determined according to network-layer topology
information.
6. PxS creates a PxR message including:
* PROXIDOR Source Address (PSA): the PSA address as received in
the request packet.
* PROXIDOR Target List (PTL): the ordered (ranked) original PTL
(as received in the request packet).
* PROXIDOR Ranking Criteria: same as PRC in PxR message.
7. PxC receives PxR, extracts PTL and may apply it to its selection
scheme.
7.3. The IDIPS Use Case
The PxC is connected to its network with, at the same time, a
wireless and a wired connection.
1. PxC obtains from the application layer the list of servers/peers
where data or service is available. PxC builds a list of IP
addresses corresponding to these peers/servers.
2. PxC builds a PROXIDOR query (PxQ). PxC insert following
information in the query:
* PSL: the list of PxC IP addresses.
Akonjang, et al. Expires September 3, 2009 [Page 13]
Internet-Draft ALTO PROXIDOR March 2009
* PTL: the list of target IP addresses.
* PRC: set to delay-based.
3. PxC sends the PxQ to the PxS.
4. PxS receives PxQ and extracts the following information:
* PROXIDOR Source List (PSL). PSL is the list of IP addresses
of the requester.
* PROXIDOR Target List (PTL). PTL is the list of IP addresses
for which PROXIDOR service is requested.
* PROXIDOR Ranking Criteria.
5. PxS determines the feasible <source,destination> pairs where
souces are in PSL and destinations are in PTL. PxS computes
PROXIDOR algorithms and ranks the pairs. Preference is
determined according to network-layer topology information.
6. PxS creates a PxR message including:
* PROXIDOR Couples (PC): the ordered (ranked) list of <source,
destination> pairs built with the original PSL and the
original PTL.
* PROXIDOR Ranking Criteria: same as PRC in PxQ message.
7. PxC receives PxQ, extracts PC and may apply it to its selection
scheme.
8. Extensibility
The protocol is capable of using different transport mechanisms and
also allows both clients and servers to express particular desires.
These aspects add a great deal of flexibility to the protocol
construct.
The use of service categories also creates enough room for
extensibility when the need for such arises, e.g., when changes in
end-users' or ISPs' needs necessitate the creation of additional
service features or even totally new service groups.
9. Security Considerations
The PROXIDOR system MUST ensure that data is exchanged between
PROXIDOR servers in a secure manner. Details of this aspect and
Akonjang, et al. Expires September 3, 2009 [Page 14]
Internet-Draft ALTO PROXIDOR March 2009
further security considerations will be treated in future versions of
this document.
10. Contributors
We acknowledge with much thanks the enormous contributions made
through discussions, remarks and suggestions by the following
individuals (in alphabetical order): Vinay Aggarwal, Olivier
Bonaventure, Pierre Francois, Benjamin Frank, Luigi Iannone, Jun
Jiang, Ingmar Poese, Georgios Smaragdakis and Pengchun Xie.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[1] Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs
and P2P systems co-operate for improved performance?", ACM
SIGCOMM Computer Communications Review (CCR), 37(3):29-40,
July 2007.
[2] Aggarwal, V., Feldmann, A., and R. Karrer, "An Internet
Coordinate system to enable collaboration between ISPs and
P2P systems", In Proceedings of the 11th International
ICIN Conference , October 2007.
[3] Aggarwal, V., Akonjang, O., and A. Feldmann, "Improving
User and ISP Experience through ISP-aided P2P Locality",
In Proceedings of 11th IEEE Global Internet Symposium 2008
(GI '08) , 2008.
[4] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information
Export Service", draft-shalunov-alto-infoexport-00 (work
in progress) , October 2008.
[5] Saucez, D., Donnet, B., and O. Bonaventure, "IDIPS: ISP-
Driven Informed Path Selection",
draft-saucez-alto-idips-01 (work in progress) ,
February 2008.
[6] Previdi, S., "Routing Proximity Services", IETF 73,
http://www.ietf.org/proceedings/08nov/slides/alto-0.pdf,
November 2008.
Akonjang, et al. Expires September 3, 2009 [Page 15]
Internet-Draft ALTO PROXIDOR March 2009
Authors' Addresses
Obi Akonjang
DT Labs/TU Berlin
Ernst-Reuter-Platz 7
10587 Berlin
Germany
EMail: obi@net.t-labs.tu-berlin.de
Anja Feldmann
DT Labs/TU Berlin
Ernst-Reuter-Platz 7
10587 Berlin
Germany
EMail: anja@net.t-labs.tu-berlin.de
Stefano Previdi
Cisco Systems, Inc.
Via Del Serafico
Rome 00142
Italy
EMail: sprevidi@cisco.com
Bruce Davie
Cisco Systems, Inc.
1414 Mass. Ave.
Boxborough, MA 01719
USA
EMail: bsd@cisco.com
Damien Saucez
Universite catholique de Louvain
Place Sainte Barbe 2
Louvain-la-Neuve, 1348
Belgium
EMail: damien.saucez@uclouvain.be
Akonjang, et al. Expires September 3, 2009 [Page 16]