idnits 2.17.1 draft-akonjang-alto-proxidor-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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. -- The document date (March 2, 2009) is 5496 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '3' is defined on line 671, but no explicit reference was found in the text -- No information found for draft-saucez-alto-idips - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force O. Akonjang 3 Internet-Draft A. Feldmann 4 Intended status: Informational DT Labs/TU Berlin 5 Expires: September 3, 2009 S. Previdi 6 B. Davie 7 Cisco Systems, Inc. 8 D. Saucez 9 Universite catholique de Louvain 10 March 2, 2009 12 The PROXIDOR Service 13 draft-akonjang-alto-proxidor-00.txt 15 Status of This Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 3, 2009. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 Several applications, such as peer-to-peer (P2P), content 52 distribution and realtime services rely on selection mechanisms in 53 order to select the peer or server from which to request the service. 54 Examples of such services are: file sharing, media streaming and 55 voice gateways. 57 Application-layer selection algorithms do not typically take into 58 account network-layer topology information; either that information 59 is unavailable to them, or when such information is available (e.g., 60 from BGP Looking Glass servers), it does not include sufficient 61 information about the local topology in the neighbourhood of the 62 application client(s). Therefore, most applications today make their 63 selection decisions based on performance measurements (combined with 64 some amount of random selection) and largely ignore network layer 65 routing. It has been demonstrated that by keeping the traffic local 66 (e.g., within the same Autonomous System) both infrastructure 67 utilization and application performance may be improved. 69 By enhancing selection algorithms through the use of accurate 70 network-layer topology, applications may improve performance while 71 network operators are also able to reduce the utilization of 72 infrastructure resources by application traffic. At the same time, 73 exchange of information between the application and the network 74 should not be allowed to compromise confidentiality for either party. 75 Detailed routing information owned by the service provider should not 76 be made publicly available, while detailed information about the 77 application should also not be made known to the service provider. 79 This draft introduces a signaling protocol which we call "PROXIDOR". 80 The PROXIDOR protocol is a request-response protocol in which a 81 PROXIDOR Client (PxC) issues requests to and receives responses from 82 a PROXIDOR Server (PxS). The questions of how a PxC discovers a PxS 83 and how a PxS acquires network-layer topology information are beyond 84 the scope of this document. 86 Table of Contents 88 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 89 1.1. Historical Background of this Proposal . . . . . . . . . . 5 90 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 91 3. Benefits of the PROXIDOR Service . . . . . . . . . . . . . . . 5 92 3.1. Benefits to End-users . . . . . . . . . . . . . . . . . . 5 93 3.2. Benefits to the ISP . . . . . . . . . . . . . . . . . . . 5 94 4. The PROXIDOR Architecture . . . . . . . . . . . . . . . . . . 5 95 4.1. Definitions and Terminologies . . . . . . . . . . . . . . 6 96 4.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 97 4.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . 7 98 4.4. Design Choices . . . . . . . . . . . . . . . . . . . . . . 7 99 5. Entities of the PROXIDOR System . . . . . . . . . . . . . . . 8 100 5.1. The PROXIDOR Client . . . . . . . . . . . . . . . . . . . 8 101 5.2. The PROXIDOR Server . . . . . . . . . . . . . . . . . . . 9 102 5.3. The Ranking System . . . . . . . . . . . . . . . . . . . . 9 103 6. PROXIDOR Messages . . . . . . . . . . . . . . . . . . . . . . 10 104 6.1. The Query Message . . . . . . . . . . . . . . . . . . . . 10 105 6.2. The Response Message . . . . . . . . . . . . . . . . . . . 10 106 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 107 7.1. The Oracle Use Case . . . . . . . . . . . . . . . . . . . 11 108 7.2. The Proximity Use Case . . . . . . . . . . . . . . . . . . 12 109 7.3. The IDIPS Use Case . . . . . . . . . . . . . . . . . . . . 13 110 8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 14 111 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 112 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 113 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 114 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 115 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 117 1. Introduction 119 This draft introduces the concept of a PROXIDOR service (PS). A 120 PROXIDOR Service (PS) aims to deliver to selection algorithms at the 121 application layer (or any other consumer of the PROXIDOR service) the 122 topological guidance that will allow an improved selection scheme, 123 taking into considerations the topology and infrastructure that is 124 going to be used for transmitting data from/to a given selected peer, 125 host or server. The protocol defined in this draft aims to be 126 generic and exploitable by any application entity requiring such a 127 service, no matter its architecture and implementation. 129 This draft describes a signaling protocol through which a PROXIDOR 130 Client (PxC) requests service from a PROXIDOR Server (PxS). In the 131 current version of the document, the protocol is described only in 132 high-level, abstract terms. 134 As an example, a peer-to-peer client, once it has obtained from the 135 application layer the list of peers through which a given content or 136 service can be obtained, requests PROXIDOR services from a PROXIDOR 137 server. The PROXIDOR query is built with the list of candidate 138 peers' IP addresses and sent to the PxS. The PxS replies with the 139 original list of IP addresses sorted by preference. 141 The definition of "preference" in this context requires some further 142 explanation. By assigning a higher preference to a particular 143 address, the PxS indicates to the application that, all things being 144 equal, the application should prefer that address to other addresses 145 of lower preference. Exactly what the PxS means by higher 146 preference, or how this preference is calculated, is intentionally 147 not made explicit. As an example, preference may be calculated by 148 using routing metric distance, with nodes that are a shorter distance 149 from the requester being given a higher preference than those that 150 are at a greater distance. Such a calculation could, for example, be 151 performed by inspecting network-layer information (IGP, BGP, etc) and 152 may also be influenced by policies of the service provider. 154 We assume that the service provider cannot force the application to 155 adhere to the preferences that the PROXIDOR service provides. 156 Therefore, the service provider has an incentive to provide 157 information that is useful to the application; otherwise it is likely 158 to be ignored. 160 Although we use IP addresses in the preceding example, similar 161 ranking operations could also be performed on AS numbers, address 162 prefixes, etc. While it is necessary to ensure interoperability 163 through the standardization of the signaling protocol, there is no 164 immediate need to standardize any algorithm or any computational 165 method that computes ranks or preferences. 167 1.1. Historical Background of this Proposal 169 The architecture and protocol described in this document arose from 170 the merger of three previous pieces of work: the Oracle service [1], 171 the ISP-Driven Informed Path Selection (IDIPS) service [5] and the 172 Proximity service [6]. The name PROXIDOR, like the proposal itself, 173 contains elements of each of these three original work items. 175 2. Conventions 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in RFC 2119 [RFC2119]. 181 3. Benefits of the PROXIDOR Service 183 The PROXIDOR service offers many benefits to both end-users 184 (consumers of the service) and Internet Service Providers (ISPs) 185 (providers of the service). 187 3.1. Benefits to End-users 189 Hosts that use the PROXIDOR service can benefit in multiple ways, 190 e.g., they no longer need to infer topology information or measure 191 path performance by themselves. They can take advantage of the 192 knowledge of the ISP to avoid bottlenecks and boost performance. 194 3.2. Benefits to the ISP 196 ISPs also benefit from the PROXIDOR service. It enables them to 197 influence the neighborhood selection process of overlay networks to 198 e.g. ensure locality of traffic and also regain the ability to 199 efficiently engineer traffic that traverses backbone and transit 200 links, thus allowing a better provisioning of the networking 201 infrastructure. 203 4. The PROXIDOR Architecture 205 The PROXIDOR architecture can be defined in terms of its entities, 206 the set of messages that are exchanged between these entities and the 207 rules governing the exchanges. 209 4.1. Definitions and Terminologies 211 Autonomous System (AS): 212 A single network or a collection of networks under the same 213 administrative control. 215 Autonomous System Number (ASN): 216 A globally unique number, used to identify an AS and to exchange 217 exterior routing information with other (neighboring) ASes. 219 PROXIDOR client (PxC): 220 An Internet end-host that requests for PROXIDOR services by 221 creating and sending queries. 223 PROXIDOR server (PxS): 224 An Internet system that accepts and processes PROXIDOR queries. 226 Metric: 227 Criteria used by server to process/rank IP addresses, 228 prefixes or ASNs in a query. 230 PROXIDOR Query (PxQ): 231 A message to request for a particular PROXIDOR service. 233 PROXIDOR Response (PxR): 234 An answer to a PROXIDOR query. 236 PROXIDOR Error (PxE): 237 Indicates non-conformity. 239 PROXIDOR Failure (PxF): 240 A PROXIDOR system malfunction. 242 PROXIDOR Services (PS): 243 A PROXIDOR service that can be directly requested by clients. 245 PROXIDOR Service Protocol (PSP): 246 The protocol used by PROXIDOR entities to communicate with 247 each oher. 249 PROXIDOR Source List (PSL): 250 A list of sources that is sent to PxS for ranking. 252 PROXIDOR Target List (PTL): 253 A list of targets that is sent to PxS for ranking. 255 PROXIDOR Couples (PC): 256 A ranked list of . 258 PROXIDOR Source Address (PSA): 259 Source IP or Prefix address used in PxQ when requesting for 260 PROXIDOR services. 262 Type Length Value (TLV): 263 Data encoding format for PROXIDOR payloads. 265 4.2. Scope 267 This draft defines the PROXIDOR service, describes its functionality 268 and gives details of its architecture. Details of the PROXIDOR 269 protocol itself (i.e., details of the messages that are exchanged 270 between entities of the PROXIDOR service) are out of scope of this 271 document. 273 4.3. Design Goals 275 We expect the PROXIDOR service to be requested by a high number of 276 simultaneous clients and therefore aspects such as simplicity, 277 scalability, performance and flexibility are among the most important 278 criteria: 280 o Simplicity. The protocol must be lightweight in its content and 281 state machinery. Different flavors may be defined in order to 282 cope with different application scenarios. However, in most of 283 practical cases, the protocol should carry the minimal set of 284 information in its simplest form of encoding. 286 o Scalability. The protocol is expected to be used by a large 287 amount of consumers simultaneously, which means that providers 288 will have to absorb a large amount of transactions. Protocol 289 specification should take into account the scalability factors 290 that would allow the protocol and its implementations to scale. 292 o Performance. Related to scalability, PROXIDOR servers will have 293 to handle a high number of simultaneous transactions and therefore 294 the performance of handling protocol packets is critical for the 295 overall scalability and deployability of the protocol. 297 o Flexibility. The protocol should allow different modes of 298 operations with different encoding techniques. 300 4.4. Design Choices 302 Two major concerns of the PROXIDOR protocol design are scalability 303 and performance. A server (or a cluster of servers) should be able 304 to simultaneously handle a very large number of client requests and 305 yet, suffer no penalties in terms of performance. To address these 306 concerns, important design choices need to be made, including; 308 i) Choice of transport protocol: 310 The PROXIDOR service SHOULD be able to function with UDP, TCP 311 and HTTP. 313 ii) Choice of approach: 315 Although most aspects of the PROXIDOR protocol are new, 316 advantage is still taken of already existing protocols, such as 317 the Domain Name System (DNS) protocol. In principle, we see a 318 lot of functional similarities between the DNS and the PROXIDOR 319 service. The DNS is not only distributed and very scalable, 320 but can also effectively handle many queries from a large 321 number of clients simultaneously. The DNS protocol approach is 322 thus partly adopted. 324 Further concerns of the protocol design are flexibility and 325 extensibility. The protocol should be flexible enough to adapt to 326 changes in end-users' and ISPs' needs and be extensible enough to 327 incorporate new types of services without the need to undergo a 328 fundamental change. 330 To address these concerns, PROXIDOR uses both Service Codes (to 331 request for particular PROXIDOR services or to express their 332 preferences) and Service Categories (to create and categorize (new) 333 PROXIDOR service groups). 335 5. Entities of the PROXIDOR System 337 A PROXIDOR system consists of PROXIDOR clients and PROXIDOR servers. 338 Both entities implement the PROXIDOR protocol in order to interact 339 with each other. Each entity independently plays an important role 340 in the overall system architecture. 342 5.1. The PROXIDOR Client 344 The PROXIDOR client can either be an end-user host that generates and 345 sends queries to a PROXIDOR server or a PROXIDOR server that 346 generates and/or forwards queries to other PROXIDOR servers. 348 To use the PROXIDOR service, a client (PxC) must generate a standard 349 PROXIDOR query (PxQ) and send to the PROXIDOR server (PxS). It can 350 also optionally cache a copy of the sent packet. It MUST clear its 351 cache before attempting to contact another PROXIDOR server. 353 5.2. The PROXIDOR Server 355 A PROXIDOR server that receives a query, can generally react in one 356 of the following ways: 358 o grant the request by responding appropriately to the query, 360 o silently drop the query if it is e.g., running out of resources, 362 o send back a PROXIDOR error message (PxE), in case of a malformed 363 request, 365 o send back a PROXIDOR failure message (PxF), in case of system 366 malfunction, 368 o send back a re-direct message, re-directing the client to another 369 PROXIDOR server, if it doesn't offer the requested service and 370 knows another (trusted) server that does. 372 The server MAY also decide to explicitly express the criteria it used 373 in ranking the contents of the response message. It should be noted 374 that revealing the criteria does not directly reveal the algorithm or 375 functions that these criteria were used to construct. 377 The PROXIDOR protocol may also be used between servers. When a 378 server needs more accurate information that is not available in its 379 database, it may also use the PROXIDOR service to request this 380 information from another server. This could be typical in 381 environments such as the global coordinate system in [2]. PROXIDOR 382 protocol supports authentication between a client and a server and 383 between servers. Authentication could be used to establish a kind of 384 trust between PROXIDOR entities involved in a transaction. 386 5.3. The Ranking System 388 The most common (perhaps the default) criteria for the ranking system 389 is the minimal distance between the requester and each individual IP 390 address in the query message. In this case the PxS evaluates the 391 distance between requester and each address of the list and returns 392 the list in an ordered fashion. Distance is evaluated according to 393 the network-layer topology. 395 A different preference criteria can be specified, relying on AS 396 membership: Given an unsorted list of IP addresses, the PxS returns 397 the list ordered by preference in AS membership. The ranked list 398 starts with addresses belonging to the same AS of the requester, then 399 all other addresses ordered according to the number of AS-hops 400 between their AS and requester's AS. 402 The ranking system can also use criteria that are based on measured 403 performance, such as available bandwidth and link delays, as well as 404 those that are based on the ISP's private policies and need to be 405 taken into consideration. 407 Criteria MAY be used either alone or in combinations, when evaluating 408 preferences. 410 While a ranking is one way to assign preferences to addresses, 411 prefixes, etc., it may also be desirable to assign a weight to the 412 elements in the list, to indicate more clearly the extent to which 413 some elements are preferred over others. This approach is described 414 in [4]. 416 The semantic of each ranking request is carried within the query 417 message (implicitly or explicitly). However, the server MAY or MAY 418 NOT take this into account. 420 6. PROXIDOR Messages 422 There are generally two types of PROXIDOR messages; the PROXIDOR 423 query (PxQ) message and the PROXIDOR response (PxR) message. 425 6.1. The Query Message 427 A standard (default) PROXIDOR query (PxQ) is that which is sent from 428 a PROXIDOR client (PxC) to a PROXIDOR server (PxS). A PROXIDOR 429 server (PxS) can also query another PxS using the same message 430 format. The PROXIDOR protocol differentiates between these two query 431 types. 433 Query messages may also carry requests that express desires for more 434 specific information or services. The server is not compelled to 435 grant them. The server MAY decide to grant or ignore them, depending 436 on its own preferences or individual policies. For example, it can 437 decide to grant server-generated desires sent by trusted PxS peers 438 and ignore client-generated ones that it considers to be too 439 intrusive. 441 6.2. The Response Message 443 Response messages are similar in structure to query messages. 444 Response messages can make use of attributes (optional) to send 445 additional information about designated payload types, e.g., when 446 responding to queries sent by a trusted PxS peer. Such peers could 447 exist within an AS or in a global coordinate system, made up of 448 PROXIDOR servers that are managed by different ISPs. The additional 449 information supplied by the use of attributes can help the receiving 450 server make better decisions before responding to client-generated 451 queries. 453 The order of the items in the response message is very important. 454 The first item indicates highest priority or preference and the last 455 one, least priority or preference. There is no general derivable 456 relationship between this order and the criteria used to create it, 457 since the latter MAY depend on factors that are of the PROXIDOR 458 Service Provider's individual choice. 460 Although some characteristics of the response message is also 461 determined by the same factors that affect those of the query 462 message, all response packets MUST additionally adhere to the 463 important factor of strict ranking. Ranking could force the response 464 payload to be packaged in particular orders relative to each other, 465 requiring the use of extra bytes in the response message than that 466 used in the query. The details of this aspect is out of scope of 467 this document. 469 7. Use Cases 471 Use cases are grouped according to service categories, such as the 472 Oracle service category, the Proximity service category and the IDIPS 473 service category. 475 7.1. The Oracle Use Case 477 i) The PROXIDOR service is used in a P2P environment to influence the 478 neighborhood selection process. 480 An end-host that wants to join a P2P overlay, first needs to 481 locate and cretae a list of potential neighbors. Instead of 482 randomly connecting to clients in the list, the end-host can use 483 the PROXIDOR service to establish a more effective connection 484 pattern. 486 1. The PROXIDOR client (PxC) creates a PROXIDOR Target List (PTL) 487 from the list of potentials neighbors. 489 2. PXC contructs a PROXIDOR query message (PxQ) with the PTL as 490 payload. 492 3. PxC then sends PxQ to a PROXIDOR server (PxS) for ranking. 494 4. PxS receives and extracts PTL from PxQ. It uses its knowledge 495 of the network to re-arrange the list, ranking them according 496 to some pre-defined criteria, e.g. locality and bandwidth. 498 + The list is ranked according to priority (or preference), 499 i.e., from highest to lowest. 501 + Proximal and optimal performing neighbors (relative to PxC) 502 are given highest priority and are placed at the top of the 503 list. 505 + PxS can decide to supplement the response with extra 506 information through the use of attributes and their values. 508 5. PxS then sends the ranked PTL back to PxC. 510 6. PxC can now use the ranked PTL to establish optimal overlay 511 connections. 513 ii) The PROXIDOR service is used in a P2P environment to influence 514 the selection of sources from where content is downloaded. 516 After a successful search or after joining a swarm, PxC may have 517 multiple sources from which content could be downloaded. It can 518 use the PROXIDOR service again to locate the best sources (from 519 among these potential sources) to download from. 521 1. PxC creates a new PTL from the list of potential sources. 523 2. PxC constructs a new PxQ using the new PTL. 525 3. PxC sends the new PxQ to PxS. 527 4. PxS extracts and ranks the PTL according to optimal 528 performance. 530 5. PxS sends the ranked PTL back to PxC. 532 6. PxC can now use the ranked PTL to download from the best 533 ranked sources in a more efficient mannner. 535 7.2. The Proximity Use Case 537 1. PxC obtains from the application layer the list of servers/peers 538 where data or service is available. PxC builds a list of IP 539 addresses corresponding to these peers/servers. 541 2. PxC builds a PROXIDOR query (PxQ). PxC insert following 542 information in the query: 544 * PSA: the PxC IP address. 546 * PTL: the list of target IP addresses. 548 * PRC: set to IP-Address-based or AS-based. 550 3. PxC sends the PxQ to the PxS. 552 4. PxS receives PxQ and extracts the following information: 554 * PROXIDOR Source Address (PSA). PSA is the source IP address 555 of the requester. 557 * PROXIDOR Target List (PTL). PTL is the list of IP addresses 558 for which PROXIDOR service is requested. 560 * PROXIDOR Ranking Criteria. 562 5. PxS computes PROXIDOR algorithms and ranks the PTL based on PRC. 563 Preference is determined according to network-layer topology 564 information. 566 6. PxS creates a PxR message including: 568 * PROXIDOR Source Address (PSA): the PSA address as received in 569 the request packet. 571 * PROXIDOR Target List (PTL): the ordered (ranked) original PTL 572 (as received in the request packet). 574 * PROXIDOR Ranking Criteria: same as PRC in PxR message. 576 7. PxC receives PxR, extracts PTL and may apply it to its selection 577 scheme. 579 7.3. The IDIPS Use Case 581 The PxC is connected to its network with, at the same time, a 582 wireless and a wired connection. 584 1. PxC obtains from the application layer the list of servers/peers 585 where data or service is available. PxC builds a list of IP 586 addresses corresponding to these peers/servers. 588 2. PxC builds a PROXIDOR query (PxQ). PxC insert following 589 information in the query: 591 * PSL: the list of PxC IP addresses. 593 * PTL: the list of target IP addresses. 595 * PRC: set to delay-based. 597 3. PxC sends the PxQ to the PxS. 599 4. PxS receives PxQ and extracts the following information: 601 * PROXIDOR Source List (PSL). PSL is the list of IP addresses 602 of the requester. 604 * PROXIDOR Target List (PTL). PTL is the list of IP addresses 605 for which PROXIDOR service is requested. 607 * PROXIDOR Ranking Criteria. 609 5. PxS determines the feasible pairs where 610 souces are in PSL and destinations are in PTL. PxS computes 611 PROXIDOR algorithms and ranks the pairs. Preference is 612 determined according to network-layer topology information. 614 6. PxS creates a PxR message including: 616 * PROXIDOR Couples (PC): the ordered (ranked) list of pairs built with the original PSL and the 618 original PTL. 620 * PROXIDOR Ranking Criteria: same as PRC in PxQ message. 622 7. PxC receives PxQ, extracts PC and may apply it to its selection 623 scheme. 625 8. Extensibility 627 The protocol is capable of using different transport mechanisms and 628 also allows both clients and servers to express particular desires. 629 These aspects add a great deal of flexibility to the protocol 630 construct. 632 The use of service categories also creates enough room for 633 extensibility when the need for such arises, e.g., when changes in 634 end-users' or ISPs' needs necessitate the creation of additional 635 service features or even totally new service groups. 637 9. Security Considerations 639 The PROXIDOR system MUST ensure that data is exchanged between 640 PROXIDOR servers in a secure manner. Details of this aspect and 641 further security considerations will be treated in future versions of 642 this document. 644 10. Contributors 646 We acknowledge with much thanks the enormous contributions made 647 through discussions, remarks and suggestions by the following 648 individuals (in alphabetical order): Vinay Aggarwal, Olivier 649 Bonaventure, Pierre Francois, Benjamin Frank, Luigi Iannone, Jun 650 Jiang, Ingmar Poese, Georgios Smaragdakis and Pengchun Xie. 652 11. References 654 11.1. Normative References 656 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 657 Requirement Levels", BCP 14, RFC 2119, March 1997. 659 11.2. Informative References 661 [1] Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs 662 and P2P systems co-operate for improved performance?", ACM 663 SIGCOMM Computer Communications Review (CCR), 37(3):29-40, 664 July 2007. 666 [2] Aggarwal, V., Feldmann, A., and R. Karrer, "An Internet 667 Coordinate system to enable collaboration between ISPs and 668 P2P systems", In Proceedings of the 11th International 669 ICIN Conference , October 2007. 671 [3] Aggarwal, V., Akonjang, O., and A. Feldmann, "Improving 672 User and ISP Experience through ISP-aided P2P Locality", 673 In Proceedings of 11th IEEE Global Internet Symposium 2008 674 (GI '08) , 2008. 676 [4] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information 677 Export Service", draft-shalunov-alto-infoexport-00 (work 678 in progress) , October 2008. 680 [5] Saucez, D., Donnet, B., and O. Bonaventure, "IDIPS: ISP- 681 Driven Informed Path Selection", 682 draft-saucez-alto-idips-01 (work in progress) , 683 February 2008. 685 [6] Previdi, S., "Routing Proximity Services", IETF 73, 686 http://www.ietf.org/proceedings/08nov/slides/alto-0.pdf, 687 November 2008. 689 Authors' Addresses 691 Obi Akonjang 692 DT Labs/TU Berlin 693 Ernst-Reuter-Platz 7 694 10587 Berlin 695 Germany 697 EMail: obi@net.t-labs.tu-berlin.de 699 Anja Feldmann 700 DT Labs/TU Berlin 701 Ernst-Reuter-Platz 7 702 10587 Berlin 703 Germany 705 EMail: anja@net.t-labs.tu-berlin.de 707 Stefano Previdi 708 Cisco Systems, Inc. 709 Via Del Serafico 710 Rome 00142 711 Italy 713 EMail: sprevidi@cisco.com 715 Bruce Davie 716 Cisco Systems, Inc. 717 1414 Mass. Ave. 718 Boxborough, MA 01719 719 USA 721 EMail: bsd@cisco.com 723 Damien Saucez 724 Universite catholique de Louvain 725 Place Sainte Barbe 2 726 Louvain-la-Neuve, 1348 727 Belgium 729 EMail: damien.saucez@uclouvain.be