idnits 2.17.1 draft-wang-alto-p4p-specification-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 : ---------------------------------------------------------------------------- == There are 13 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1038 has weird spacing: '...isp.net no-r...' == Line 1039 has weird spacing: '...isp.net no-r...' == Line 1040 has weird spacing: '...isp.net no-r...' == Line 1041 has weird spacing: '...isp.net no-r...' == Line 1053 has weird spacing: '...isp.net no-r...' == (3 more instances...) -- The document date (March 4, 2009) is 5531 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'SIGCOMM08' is defined on line 1241, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Wang 3 Internet-Draft Microsoft Corp. 4 Intended status: Informational R. Alimi 5 Expires: September 5, 2009 Yale University 6 D. Pasko 7 Verizon 8 L. Popkin 9 Pando Networks, Inc. 10 Y. Yang 11 Yale University 12 March 4, 2009 14 P4P Protocol Specification 15 draft-wang-alto-p4p-specification-00.txt 17 Status of This Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 5, 2009. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Abstract 53 Provider Portal for Network Applications (P4P) is a framework that 54 enables Internet Service Providers (ISPs) and network application 55 software developers to work jointly and cooperatively to optimize 56 application communications. The goals of this cooperation are to 57 reduce network resource consumption and to accelerate applications. 58 To achieve these goals, P4P allows ISPs to provide network 59 information and guidance to network applications, allowing clients to 60 exchange data more effectively. This document specifies the P4P 61 protocol operations and message formats. The goal is provide a 62 formal specification for developers to create inter-operable 63 implementations. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Status of this Memo . . . . . . . . . . . . . . . . . . . 4 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 71 1.3.1. Location Portal Service . . . . . . . . . . . . . . . 5 72 1.3.2. pDistance Portal Service . . . . . . . . . . . . . . . 5 73 1.4. Common Application Scenario . . . . . . . . . . . . . . . 5 74 1.5. Key Features . . . . . . . . . . . . . . . . . . . . . . . 6 75 2. Conventions Used in This Document . . . . . . . . . . . . . . 6 76 3. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 78 3.1.1. Basic Types . . . . . . . . . . . . . . . . . . . . . 7 79 3.1.2. IP Addresses . . . . . . . . . . . . . . . . . . . . . 7 80 3.1.3. Autonomous System Numbers . . . . . . . . . . . . . . 7 81 3.1.4. Network Location Identifiers . . . . . . . . . . . . . 8 82 3.1.5. ISP Identifiers . . . . . . . . . . . . . . . . . . . 8 83 3.1.6. PIDs . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 3.1.7. pDistance Values . . . . . . . . . . . . . . . . . . . 8 85 3.1.8. pDistance Endpoint . . . . . . . . . . . . . . . . . . 9 86 3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 3.2.1. Headers . . . . . . . . . . . . . . . . . . . . . . . 9 88 3.2.2. Content-Type . . . . . . . . . . . . . . . . . . . . . 10 89 3.2.3. GetPID and PID Messages . . . . . . . . . . . . . . . 10 90 3.2.4. GetPIDMap and PIDMap Messages . . . . . . . . . . . . 11 91 3.2.5. GetpDistance and pDistance Messages . . . . . . . . . 11 92 4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 13 93 4.1. Standard Definitions and Reserved Values . . . . . . . . . 13 94 4.1.1. PIDs . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 4.1.2. pDistances . . . . . . . . . . . . . . . . . . . . . . 14 96 4.2. Message Handling . . . . . . . . . . . . . . . . . . . . . 14 97 4.2.1. Common Operations . . . . . . . . . . . . . . . . . . 15 98 4.2.2. GetPID . . . . . . . . . . . . . . . . . . . . . . . . 15 99 4.2.3. GetPIDMap . . . . . . . . . . . . . . . . . . . . . . 16 100 4.2.4. GetpDistance . . . . . . . . . . . . . . . . . . . . . 17 101 4.3. Exception Handling . . . . . . . . . . . . . . . . . . . . 19 102 4.3.1. Invalid Request URI Path . . . . . . . . . . . . . . . 19 103 4.3.2. Invalid Request Format . . . . . . . . . . . . . . . . 19 104 4.4. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 19 105 4.5. Message Exchange Examples . . . . . . . . . . . . . . . . 19 106 4.5.1. GetPID . . . . . . . . . . . . . . . . . . . . . . . . 20 107 4.5.2. GetPIDMap . . . . . . . . . . . . . . . . . . . . . . 22 108 4.5.3. GetpDistance . . . . . . . . . . . . . . . . . . . . . 23 109 5. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 24 110 5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 24 111 5.2. Delegation . . . . . . . . . . . . . . . . . . . . . . . . 25 112 5.3. Load Balancing Considerations . . . . . . . . . . . . . . 25 113 5.4. Caching P4P Information . . . . . . . . . . . . . . . . . 25 114 5.5. Transport and Encoding Considerations . . . . . . . . . . 25 115 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 116 6.1. Protecting P4P Information . . . . . . . . . . . . . . . . 26 117 6.1.1. Authentication . . . . . . . . . . . . . . . . . . . . 26 118 6.1.2. Encryption . . . . . . . . . . . . . . . . . . . . . . 26 119 6.2. ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 120 6.3. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 27 121 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 122 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27 123 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 124 9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 125 9.2. Informative References . . . . . . . . . . . . . . . . . . 28 126 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 28 127 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 29 129 1. Introduction 131 Provider Portal for Network Applications (P4P) [I-D.p4p-framework] is 132 a framework that enables Internet Service Providers (ISPs) and 133 network application software developers to work jointly and 134 cooperatively to optimize application communications. The goals of 135 this cooperation are to reduce network resource consumption and to 136 accelerate applications. To achieve these goals, P4P allows ISPs to 137 provide network information and guidance to network applications, 138 allowing clients to exchange data more effectively. 140 This document specifies the P4P protocol operations and message 141 formats. The goal is provide a formal specification for developers 142 to create inter-operable implementations. 144 1.1. Status of this Memo 146 The goal of this specification is to provide a snapshot of the 147 current P4P design and implementation. Please refer to the P4P 148 Framework document [I-D.p4p-framework] for detailed description of 149 the design rationale and architecture. As the P4P framework is still 150 under field trials and active development, this document will be 151 updated to track the progress of major milestones or releases of the 152 P4P framework. 154 1.2. Terminology 156 A detailed description of the terminology can be found in 157 [I-D.p4p-framework]. This section provides a short list of the 158 terminology used in this specification. 160 o Network Location Identifier: IP address, IP prefix, or an 161 autonomous system number (ASN). 163 o PID (Partition ID): an identifier for a set of Network Location 164 Identifiers defined by ISPs for aggregation purposes under similar 165 network characteristics; a PID can represent different network 166 scopes such as subnet, groups of subnets, autonomous system (AS), 167 etc. depending on the granularity desired by an ISP. 169 o pDistance: a metric representing network information or preference 170 between PIDs or Network Location Identifiers. pDistances have 171 (optional) attributes to indicate type (e.g., routing cost, hop 172 count, geographical distance, etc) and their interpretation (e.g., 173 numerical or ordinal ranking). 175 o Location Portal Service: (described in Section 1.3.1) 176 o pDistance Portal Service: (described in Section 1.3.2) 178 1.3. Protocol Overview 180 The P4P framework provides two services to applications, which 181 correspond to the two sets of information defined in the P4P 182 Protocol: the Location Portal Service and the pDistance Portal 183 Service. 185 1.3.1. Location Portal Service 187 The Location Portal Service provides a lookup service for the 188 mappings between PIDs and Network Location Identifiers. There are 189 two interfaces defined in the Location Portal Service: 191 o GetPID: returns the PIDs corresponding to the Network Location 192 Identifiers queried. 194 o GetPIDMap: returns the lists of Network Location Identifiers 195 contained within the PIDs queried. This allows applications to 196 locally perform the mapping from Network Location Identifiers to 197 their corresponding PIDs without further querying the Location 198 Portal Service. 200 1.3.2. pDistance Portal Service 202 The pDistance Portal Service: provides a lookup service for the 203 pDistances between given PIDs. There is a single interface: 205 o GetpDistance: returns the pDistances between given PID pairs or 206 between given Network Location Identifier pairs. 208 1.4. Common Application Scenario 210 A common usage scenario is for a network application, such as a peer- 211 to-peer application, to use the P4P services to determine the order 212 of communication preferences among a pool of available nodes that can 213 provide the desired contents or services. 215 One possibility is for an application to rely on the pDistance Portal 216 Service alone by using Network Location Identifiers directly in the 217 query. The returned pDistances may then be used by the application 218 to specify the order in which target nodes are contacted. This use 219 case may raise privacy and scalability issues due to inclusion of 220 private information in requests and frequent queries. 222 A second possibility is that the application queries the Location 223 Portal Service to first obtain mappings between PIDs and network 224 nodes. These PID mappings may remain stable for a longer period of 225 time. The application can then query the pDistance Portal Service to 226 obtain pDistances between the target PIDs and its own PIDs, and rank 227 the network nodes accordingly. The pDistance information may be 228 refreshed at a smaller timescale than PID mappings. 230 The introduction of PIDs as an aggregation point can reduce redundant 231 lookups among nodes belong to the PIDs where pDistances are known 232 (from prior lookups). The separation of the Location Portal Service 233 and the pDistance Portal Service provides a clean differentiation 234 between the two basic types of information in P4P, which can be 235 updated at different timescales. 237 1.5. Key Features 239 While the P4P Framework does not depend on any particular transport 240 or message formats and encodings, the current P4P protocol is 241 implemented primarily considering ease of application integration, 242 caching of network information (Section 5.4), and authentication and 243 encryption (Section 6.1). Also see Section 5.5 for further 244 discussion. 246 2. Conventions Used in This Document 248 In examples, "C:" and "S:" indicate lines sent by the client and 249 server respectively. 251 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 252 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 253 document are to be interpreted as described in [RFC2119]. 255 3. Messages 257 This section formally specifies the P4P protocol messages that 258 implement the P4P interfaces presented in Section 1.3. This section 259 presents encodings for data types used in the messages, and then 260 defines the messages themselves. 262 The current P4P protocol uses textual encodings for request and 263 response messages. The following definitions use the Augmented BNF 264 and Core Rules in [RFC4234] to specify the encodings. 266 3.1. Definitions 268 The P4P interfaces make use of data types such as IP addresses and 269 PIDs. We first define the encodings used for these data types. 271 3.1.1. Basic Types 273 P4P data type definitions use some basic data types: 275 ACHAR = ALPHA ; Alphanumeric character 276 / DIGIT 277 SCHAR = ACHAR ; Alphanumeric character 278 / "-" ; or hyphen 280 ASTRING = 1*ACHAR ; Alphanumeric string 282 NZDIGIT = %x31-39 ; Non-zero digit 284 UINT = NZDIGIT *DIGIT ; Unsigned integer 285 / "0" 287 Note that when a particular definition requires an unsigned integer 288 with a particular range (e.g., 16-bit unsigned integer with range 0 - 289 65535), its format is indicated as UINT-K where K is the size in bits 290 (e.g., UINT-16). 292 3.1.2. IP Addresses 294 IPv4 addresses and prefixes use their standard textual 295 representation: 297 ipv4-addr = UINT-8 3("." UINT-8) ; IPv4 address 298 ipv4-prfx = ipv4-addr "/" UINT-5 ; IPv4 prefix 300 IPv6 addresses and prefixes use the standard textual representations 301 as specified in Sections 2.2 and 2.3 of [RFC2373]. These 302 representations are indicated in this document as 'ipv6-addr' and 303 ipv6-prfx', respectively. 305 IP Addresses and Prefixes may either be IPv4 or IPv6: 307 ip-addr = ipv4-addr ; IP address 308 / ipv6-addr 309 ip-prfx = ipv4-prfx ; IP prefix 310 / ipv6-prfx 312 3.1.3. Autonomous System Numbers 314 Autonomous System numbers may either be 16-bit or 32-bit: 316 asn16 = "AS" UINT-16 ; 16-bit ASN 317 asn32 = "AS" UINT-16 "." UINT-16 ; 32-bit ASN 319 asn = asn16 ; 16-bit or 32-bit ASN 320 / asn32 322 3.1.4. Network Location Identifiers 324 Network Location Identifiers can be either IPv4 or IPv6 addresses or 325 prefixes, as well as Autonomous System numbers: 327 netloc-id = ip-addr ; Network Location 328 / ip-prfx ; Identifier 329 / asn 331 3.1.5. ISP Identifiers 333 ISP identifiers follow standard domain name syntax: 335 hostname = ACHAR *(*SCHAR ACHAR) ; Hostname 336 tld = 1*ACHAR ; Top-level Domain 337 domainname = 1*(hostname ".") tld ; Domain name 339 isp-id = domainname ; ISP identifier 341 3.1.6. PIDs 343 PIDs use an indicator to specify whether they represent intradomain 344 ("internal") or interdomain ("external") network locations: 346 pid-ind-int = "i" ; Internal PID indicator 347 pid-ind-ext = "e" ; External PID indicator 349 pid-ind = pid-ind-int ; PID indicator 350 / pid-ind-ext 352 A PID name is fully-specified by a 16-bit integer, its indicator, and 353 ISP identifier: 355 pid = UINT-16 "." pid-ind "." isp-id 356 ; PID 358 3.1.7. pDistance Values 360 pDistance values are 16-bit unsigned integers: 362 pdist = UINT-16 ; pDistance value 364 3.1.8. pDistance Endpoint 366 pDistances are configured between pDistance Endpoints, which may be 367 PIDs or specialized to Network Location Identifiers: 369 pdist-endp = pid ; pDistance Endpoint 370 / netloc-id 372 3.2. Syntax 374 This section formally defines the message formats used by the P4P 375 interfaces. The P4P protocol operates over HTTP 1.0 [RFC1945] or 1.1 376 [RFC2616]. Thus, this specification defines the following components 377 of the request and response messages: 379 o Request Method 381 o Request URI Path and Query String 383 o Request Data 385 o Response Data 387 3.2.1. Headers 389 In addition to the components of individual messages defined in this 390 section, the P4P protocol defines additional headers. 392 3.2.1.1. PIDMap Version Tag Response Header 394 A PIDMap Version Tag (discussed in Section 4.2.1.1) is specified in 395 response messages from a Portal Server using the header: 397 X-P4P-PIDMap: 399 where is a string following the 'UINT-32' format. 401 3.2.1.2. pDistance Type Response Header 403 The Type of pDistances contained in a response from the pDistance 404 Portal Service is specified using the header: 406 X-P4P-pDistType: 408 where is a string following the 'ASTRING' format. 410 3.2.1.3. pDistance Mode Response Header 412 The Mode of pDistances contained in a response from the pDistance 413 Portal Service is specified using the header: 415 X-P4P-pDistMode: 417 where is a string following the 'ASTRING' format. 419 3.2.2. Content-Type 421 The data contained in the request and response messages MUST use a 422 Content-Type of 'text/plain'. The standard HTTP mechanisms for 423 encoding (e.g., Content-Encoding and Transfer-Encoding) the data MAY 424 additionally be applied as indicated by the HTTP standard. 426 3.2.3. GetPID and PID Messages 428 3.2.3.1. GetPID Request 430 The GetPID message requests the PIDs corresponding to a set of 431 Network Location Identifiers. 433 The format of the Request Data is: 435 getpid-data = *(netloc-id CRLF) 437 The GetPID message is then specified as: 439 Request Method: POST (may be GET if Request Data is empty) 440 Request URI: /pid 441 Request Data: getpid-data 443 3.2.3.2. PID Response 445 The PID message is returned by a Portal Server in response to a 446 GetPID request and provides the PID for the requested Network 447 Location Identifiers. 449 The format of the Response Data is: 451 pid-data = 1*(netloc-id WSP pid CRLF) 453 The PID message is specified as: 455 Response Data: pid-data 457 3.2.4. GetPIDMap and PIDMap Messages 459 3.2.4.1. GetPIDMap Request 461 The GetPIDMap message requests the Network Location Identifiers 462 contained within PIDs. 464 The format of the Request Data is: 466 getpidmap-data = *(pid CRLF) 468 The GetPIDMap message is specified as: 470 Request Method: POST (may be GET if Request Data is empty) 471 Request URI: /pid/map 472 Request Data: getpidmap-data 474 3.2.4.2. PIDMap Response 476 The PIDMap message is returned by a Portal Server in response to a 477 GetPIDMap request and provides the list of Network Location 478 Identifiers for each of the requested PIDs. 480 Each line of the Response Data contains a PID and the Network 481 Location Identifiers contained in the PID. The count of Network 482 Location Identifiers in the list is also included to simplify 483 processing. The format of the Response Data is: 485 pidmap-line = pid WSP UINT-32 1*(WSP netloc-id) 487 pidmap-data = *(pidmap-line CRLF) 489 The PIDMap message is specified as: 491 Response Data: pidmap-data 493 3.2.5. GetpDistance and pDistance Messages 495 3.2.5.1. GetpDistance Request 497 The GetpDistance message requests pDistances of the specified type 498 between pDistance Endpoints (i.e., a list of Source Endpoint -> 499 Destination Endpoint pairs). 501 pDistance Type and Mode are optionally specified as a query string 502 arguments in the Request URI. 504 Conceptually, the message data specifies a list of Source -> 505 Destination pairs in the Request Data. For efficiency, however, a 506 more compact representation is used. 508 Each line of the Request Data encodes a request for the pDistances 509 from a particular Source Endpoint to a list of Destination Endpoints. 510 By specifying an "inc-reverse" option, the pDistances from the 511 Destination Endpoints to the Source Endpoint may also be requested. 512 The count of Destination Endpoints in the list is also included to 513 simplify processing. The format of the Request Data is: 515 getpdist-line = pdist-endp 516 WSP ("inc-reverse" / "no-reverse") 517 WSP UINT-32 518 1*(WSP pdist-endp) 520 getpdist-data = *(getpdist-line CRLF) 522 The GetpDistance message is then specified as: 524 Request Method: POST (may be GET if Request Data is empty) 525 Request URI: /pdistance?type=&mode=&direct 526 Request Data: getpdist-data 528 where indicates a string following the 'ASTRING' format. 529 The 'direct' parameter indicates that pDistance Endpoints are Network 530 Location Identifiers instead of PIDs. 532 The 'type', 'mode', and 'direct' Request URI query string parameters 533 are optional. Section 4.2.4 indicates the default behavior if not 534 explicitly supplied. 536 3.2.5.2. pDistance Response 538 The pDistance message is returned by a Portal Server in response to a 539 GetpDistance request and specifies the pDistances for the requested 540 Source Endpoint -> Destination Endpoint pairs. 542 The encoding for the Response Data follows a similar pattern as the 543 GetpDistance message Request Data. 545 Each line of the Response Data specifies the pDistances from a Source 546 Endpoint to a list of Destination Endpoints. The pDistance to a 547 Destination Endpoint is encoded directly following Destination 548 Endpoint in the list. If the reverse option is "inc-reverse", a 549 second pDistance is included indicating the pDistance from the 550 Destination Endpoint to the Source Endpoint. The format of the 551 Response Data is: 553 dst-pdist = pdist-endp 1*2(WSP pdist) 555 pdist-line = pdist-endp 556 WSP ("inc-reverse" / "no-reverse") 557 WSP UINT-32 558 1*(WSP dst-pdist) 560 pdist-data = *(pdist-line CRLF) 562 The pDistance message is specified as: 564 Response Data: pdist-data 566 4. Protocol Operations 568 The P4P Protocol is a simple request/response protocol. This section 569 first discusses standard definitions such as well-known values, and 570 then defines message and error handling. 572 4.1. Standard Definitions and Reserved Values 574 4.1.1. PIDs 576 4.1.1.1. Well-Known PIDs 578 Some PID names are well-known and used for specific purposes. These 579 PIDs use ISP Identifier "pid.p4p". 581 4.1.1.1.1. Default Aggregation PID 583 Each Portal Server MUST define a PID which implicitly contains all 584 Network Location Identifiers not contained by other Aggregation PIDs. 585 This PID has the name: 587 0.i.pid.p4p 589 4.1.1.2. Routing Cost PIDs 591 The pDistance Portal Service allows applications to query pDistances 592 between PIDs. We use the term Routing Cost PID to refer to a PID for 593 which Routing Cost pDistances are defined. As defined later in 594 Section 4.2.4, a "default" request to the GetpDistance interface 595 returns the Routing Cost pDistances between each pair of PIDs. The 596 full set of PIDs contained in this response message is the full set 597 of Routing Cost PIDs. 599 4.1.2. pDistances 601 4.1.2.1. Reserved pDistance Types 603 The pDistance Portal Service may define pDistances of multiple types. 604 Specific pDistance types have reserved names beginning with "p4p". 606 4.1.2.1.1. Routing Cost pDistance 608 Each Portal Server MUST define the Routing Cost pDistance type. This 609 type uses the name: 611 p4proutingcost 613 4.1.2.2. Reserved pDistance Modes 615 pDistances have an attribute, called a Mode, indicating how they 616 should be interpreted. Modes for both numerical and ordinal 617 pDistances have reserved names. 619 4.1.2.2.1. Numerical pDistances 621 Each Portal Server MUST reserve the following pDistance Mode to 622 indicate numerical pDistances: 624 p4pnumerical 626 Numerical pDistances are defined such that a smaller pDistance value 627 indicates a higher preference, while larger pDistance values 628 indicates a lower preference. 630 4.1.2.2.2. Ordinal pDistances 632 Each Portal Server MUST reserve the following pDistance Mode to 633 indicate ordinal pDistances: 635 p4pordinal 637 Ordinal pDistances are defined such that a smaller pDistance value 638 indicates a higher preference, while a larger pDistance value 639 indicates a lower preference. 641 4.2. Message Handling 643 This section further defines P4P interfaces by detailing the 644 semantics applied to the P4P messages discussed in Section 3.2. 646 4.2.1. Common Operations 648 In addition to the specific message handling behavior discussed later 649 in this section, certain common operations apply to all P4P 650 interfaces. 652 4.2.1.1. PIDMap Version Tag 654 Recall that P4P information is separated into two services, and that 655 information provided by the pDistance Portal Service may be dependent 656 on current PID mappings provided by the Location Portal Service. 657 Applications may query the services independently, but should also 658 ensure that they use consistent information. 660 PIDMap Version Tags are opaque identifiers that allow an application 661 to detect when previously-retrieved PID mappings are no longer valid. 662 Conceptually, a Portal Server maintains a database, called the 663 PIDMap, containing the mappings between Network Location Identifiers 664 and PIDs. All responses from the Location Portal Service and 665 pDistance Portal Service include the Version Tag of the PIDMap used 666 to generate the response. If the Version Tag for pDistance 667 information received by an application does not match the Version Tag 668 for the stored PID mappings, the PID mappings should be updated from 669 the Location Portal Service. 671 One way to implement the Version Tag is as an integer which is 672 incremented when the PIDMap is changed at the Portal Server. The 673 integer can wrap around to 0 if necessary. 675 Each non-error response message from a Portal Server MUST include a 676 'X-P4P-PIDMap' header with its value being the Version Tag of the 677 PIDMap used to generate the response. 679 4.2.1.2. Successful Responses 681 A Portal Server MUST use HTTP Status Code 200 when replying to an 682 operation that completed successfully. Note that this includes cases 683 where the Portal Server responds with only a subset of the requested 684 information, as discussed later in this section. The requesting 685 application is expected to handle such cases if necessary. 687 4.2.2. GetPID 689 A P4P Portal Server MUST implement the GetPID interface. 691 The GetPID interface is defined to allow the Portal Server to 692 directly return the PIDs for the supplied list of Network Location 693 Identifiers. In the absence of an error condition specified in 694 Section 4.3, the Portal Server MUST respond with a PID message 695 specifying a PID for each queried Network Location Identifier 696 supplied in the GetPID request message. 698 4.2.2.1. Empty Requests 700 If the GetPID request message is empty (i.e., it contains a zero- 701 length list of Network Location Identifiers), the Portal Server MUST 702 interpret the request as if the list of Network Location Identifiers 703 contained the IP address of the requestor as its only element. 705 This provides an easy mechanism for a client to lookup its own PID 706 even when it is behind a NAT or has multiple network interfaces. 708 4.2.3. GetPIDMap 710 A P4P Portal Server SHOULD implement the GetPIDMap interface. 712 The GetPIDMap interface is defined to provide an application 713 information such that it can locally map between Network Location 714 Identifiers and PIDs. In the absence of an error condition specified 715 in Section 4.3, the Portal Server MUST respond with a PIDMap message 716 containing lists of Network Location Identifiers for at least the 717 Routing Cost PIDs supplied in the GetPIDMap request message. If the 718 request specifies a non-empty list of PIDs, the Portal Server MUST 719 NOT respond with lists of Network Location Identifiers for PIDs not 720 contained in the request. 722 4.2.3.1. Empty Requests 724 If the GetPIDMap request message is empty (i.e., it contains a zero- 725 length list of PIDs), the Portal Server MUST interpret the request as 726 if the list of PIDs were the full set of Routing Cost PIDs. 728 4.2.3.2. Non-Routing Cost PIDs 730 If the GetPIDMap request message contains PIDs that are not in the 731 set of Routing Cost PIDs, the Portal Server MAY interpret the request 732 as if the list of PIDs did not contain such PIDs. 734 4.2.3.3. Network Location Identifier Lists 736 The Network Location Identifiers returned by the Portal Server 737 SHOULD, where possible, allow applications to locally obtain 738 equivalent mappings between PIDs and Network Location Identifiers as 739 would be obtained using the GetPID interface. If the list of Network 740 Location Identifiers contains AS numbers, the Portal Server SHOULD 741 ensure that this mapping can be done by applications with reasonable 742 accuracy with publicly-available information (e.g., public 743 databases). 745 4.2.4. GetpDistance 747 A P4P Portal Server MUST implement the GetpDistance interface for 748 pDistances amongst PIDs. A P4P Portal Server MAY implement the 749 GetpDistance interface for pDistances directly between Network 750 Location Identifiers. 752 The GetpDistance interface provides pDistances between PIDs defined 753 by the Location Portal Service. It may also be used to directly 754 query the pDistances between Network Location Identifiers. In the 755 absence of an error condition specified in Section 4.3, the Portal 756 Server MUST respond with a pDistance message containing pDistances of 757 the requested type for all requested Source Endpoint -> Destination 758 Endpoint pairs for which the pDistance type is defined. If the 759 request specifies a non-empty list of Source Endpoint -> Destination 760 Endpoint pairs, the Portal Server MUST NOT respond with pDistances 761 for pairs not contained in the request. 763 4.2.4.1. Endpoint Types 765 If the GetpDistance request message does not specify the 'direct' 766 query string parameter, the Portal Server MUST parse all endpoints in 767 the Request Data as PIDs (and hence follow the 'pid' syntax). If the 768 'direct' query string parameter is specified, the Portal Server MUST 769 parse all endpoints in the Request Data as Network Location 770 Identifiers (and hence follow the 'netloc-id' syntax). If an 771 endpoint in the request is found to not meet the expected format, the 772 Portal Server MUST reject the request as being incorrectly formatted 773 (see Section 4.3.2). 775 4.2.4.2. Invalid PID Pairs 777 If the GetpDistance request message contains PIDs that are not in the 778 set of PIDs that define pDistances of the requested type, the Portal 779 Server MAY interpret the request as if the list of Source PID -> 780 Destination PID pairs did not contain pairs referring to such PIDs. 782 4.2.4.3. Network Location Identifier Endpoints 784 If the 'direct' query string parameter is specified, the the Portal 785 Server MAY return customized pDistances instead of pDistances amongst 786 the PIDs that contain the Network Location Identifiers. 788 If a Portal Server does not implement the GetpDistance query for 789 Network Location Identifiers, it MUST reply with a HTTP 501 (Not 790 Implemented) status code. 792 4.2.4.4. Default pDistance Type 794 If the GetpDistance request message does not specify a pDistance type 795 via a 'type' query string parameter, the Portal Server MUST interpret 796 the message as if it specified the type as 'p4proutingcost'. 798 4.2.4.5. Unsupported pDistance Type 800 If the GetpDistance request message specifies a pDistance type that 801 is not supported by the Portal Server, the Portal Server MUST reply 802 with a HTTP 501 (Not Implemented) status code. 804 4.2.4.6. pDistance Type Handling 806 The pDistances encoded in the response message MUST be pDistances 807 with the Type specified in the request message. If the pDistances 808 encoded in the response message are not Routing Cost pDistances, the 809 Portal Server MUST specify the returned pDistances' Type using the 810 'X-P4P-pDistType' header. 812 4.2.4.7. Default pDistance Mode 814 If the GetpDistance request message does not specify a pDistance Mode 815 via a 'mode' query string parameter, the Portal Server MUST interpret 816 the message as if it specified the mode as 'p4pnumerical'. 818 4.2.4.8. Unsupported pDistance Mode 820 If the GetPDistance request message specifies a pDistance Mode that 821 is not supported, the Portal Server MUST reply with pDistances with 822 either a Mode of 'p4pnumerical' or 'p4pordinal'. Thus, a Portal 823 Server must implement at least one of 'p4pnumerical' or 'p4pordinal' 824 pDistances, but it may choose which to support. 826 4.2.4.9. pDistance Mode Handling 828 The pDistances encoded in the response message SHOULD be pDistances 829 with the Mode specified in the request message. If the pDistances 830 encoded in the response message are not numerical pDistances, the 831 Portal Server MUST specify the returned pDistances' Mode using the 832 'X-P4P-pDistMode' header. 834 4.2.4.10. Empty Requests 836 If the GetpDistance request message is empty (i.e., it contains no 837 Source Endpoint -> Destination Endpoint pairs) and the 'direct' query 838 string parameter is not specified, the Portal Server MUST interpret 839 the request as if the list of PIDs were the full set of PIDs that 840 define pDistances of the requested type. 842 If the request message is empty and the 'direct' query string 843 parameter is specified, the Portal Server MUST reject the request as 844 being incorrectly formatted (see Section 4.3.2). 846 4.3. Exception Handling 848 This section specifies Portal Server behavior for specific error 849 conditions that may be encountered. Standard HTTP status codes are 850 returned by a Portal Server. The Portal Server MUST follow the HTTP 851 protocol version in use for the current request for error conditions 852 (e.g., indicating server overload conditions) not explicitly listed 853 in this section. 855 4.3.1. Invalid Request URI Path 857 If the Path portion of the Request URI does not refer to a valid P4P 858 interface, the Portal Server MUST return an HTTP 404 (Not Found) 859 status code. 861 4.3.2. Invalid Request Format 863 If the Request Data or a Request URI Query String parameter is 864 formatted incorrectly (i.e., it does not follow the syntax in 865 Section 3.2 or it fails to meet additional requirements specified in 866 Section 4.2), the Portal Server MUST return an HTTP 400 (Bad Request) 867 status code. 869 4.4. Timers 871 The P4P protocol is simple request/response protocol and hence does 872 not require any additional timers beyond those required by the 873 underlying protocol (i.e., HTTP and TCP). 875 4.5. Message Exchange Examples 877 This section presents example message captures from the P4P protocol. 878 Note that the message captures use HTTP chunked encoding for requests 879 and responses. This is an implementation detail and does not imply 880 that the P4P protocol must use chunked encoding. 882 The message exchange examples in this section use a Portal Server 883 configured with the following simple, illustrative topology. Labels 884 on arrows between PIDs indicate pDistances. The pDistance from a PID 885 to itself is configured to be 1. Note that the Portal Server reports 886 end-to-end pDistances. The method and factors (including, but not 887 limited to, algorithm and routing policy) for computing end-to-end 888 pDistances is a policy decision implemented by the Portal Server, and 889 is outside the scope of this document. These examples are only 890 provided to illustrate message format. 892 .-------------. 893 | 4.e.isp.net | 894 '-------------' 895 ^ 896 | 60 897 v 898 .-------------. 8 .-------------. 899 | 0.i.isp.net | <------> | 3.i.isp.net | 900 '-------------' '-------------' 901 ^ ^ 902 | 4 | 4 903 v v 904 .-------------. 10 .-------------. 40 .-------------. 905 | 1.i.isp.net | <------> | 2.i.isp.net | <--> | 5.e.isp.net | 906 '-------------' '-------------' '-------------' 908 Each PID has a set of Network Location Identifiers configured: 910 0.i.isp.net : 10.0.0.0/24 10.0.1.0/24 911 1.i.isp.net : 10.1.0.0/16 912 2.i.isp.net : 10.2.0.0/24 10.2.1.0/24 913 3.i.isp.net : 10.3.0.0/24 914 4.e.isp.net : 172.16.0.0/12 915 5.e.isp.net : 192.168.0.0/16 917 4.5.1. GetPID 919 4.5.1.1. Request PID for Own IP Address 921 The following message exchange illustrates a client requesting its 922 own PID from a Portal Server. The client uses an empty request, and 923 the Portal Server responds with the client's IP address and the PID 924 corresponding to the IP address. 926 C: POST /pid HTTP/1.1 927 C: Host: localhost:6671 928 C: Accept: */* 929 C: Transfer-Encoding: chunked 930 C: Expect: 100-continue 932 S: HTTP/1.1 100 Continue 934 C: 2 936 C: 0 938 S: HTTP/1.1 200 OK 939 S: Transfer-Encoding: chunked 940 S: X-P4P-PIDMap: 1 941 S: Cache-Control: max-age=604800 942 S: Content-Type: text/plain 943 S: Date: Tue, 24 Feb 2009 19:26:43 GMT 945 S: 17 946 S: 10.1.1.12 1.i.isp.net 948 S: 0 950 4.5.1.2. Request PIDs for List of IP Addresses 952 The following message exchange illustrates a client directly asking 953 the Portal Server to map a set of IP addresses into their 954 corresponding PIDs. 956 C: POST /pid HTTP/1.1 957 C: Host: localhost:6671 958 C: Accept: */* 959 C: Transfer-Encoding: chunked 960 C: Expect: 100-continue 962 S: HTTP/1.1 100 Continue 964 C: 1e 965 C: 10.1.23.200 966 C: 192.168.1.128 968 C: 0 970 S: HTTP/1.1 200 OK 971 S: Transfer-Encoding: chunked 972 S: X-P4P-PIDMap: 1 973 S: Cache-Control: max-age=604800 974 S: Content-Type: text/plain 975 S: Date: Tue, 24 Feb 2009 19:26:47 GMT 977 S: 34 978 S: 10.1.23.200 1.i.isp.net 979 S: 192.168.1.128 5.e.isp.net 981 S: 0 983 4.5.2. GetPIDMap 985 4.5.2.1. Request PID Map 987 The following message exchange illustrates an application requesting 988 the set of Network Location Identifiers contained within particular 989 PIDs. Note that the application could also request for Network 990 Location Identifiers in all Routing Cost PIDs by using an empty 991 request. 993 C: GET /pid/map HTTP/1.1 994 C: Host: localhost:6671 995 C: Accept: */* 996 C: Transfer-Encoding: chunked 997 C: Expect: 100-continue 999 S: HTTP/1.1 100 Continue 1001 C: 1c 1002 C: 0.i.isp.net 1003 C: 2.i.isp.net 1005 C: 0 1007 S: HTTP/1.1 200 OK 1008 S: Transfer-Encoding: chunked 1009 S: X-P4P-PIDMap: 1 1010 S: Cache-Control: max-age=604800 1011 S: Content-Type: text/plain 1012 S: Date: Tue, 24 Feb 2009 19:26:55 GMT 1014 S: 4E 1015 S: 0.i.isp.net 2 10.0.0.0/24 10.0.1.0/24 1016 S: 2.i.isp.net 2 10.2.0.0/24 10.2.1.0/24 1018 S: 0 1020 4.5.3. GetpDistance 1022 4.5.3.1. Request pDistance Among PIDs 1024 The following message exchange illustrates an application requesting 1025 Routing Cost pDistances between particular PIDs. Note that the 1026 application could also request pDistances amongst all Routing Cost 1027 PIDs by using an empty request. 1029 C: POST /pdistance HTTP/1.1 1030 C: Host: localhost:6671 1031 C: Accept: */* 1032 C: Transfer-Encoding: chunked 1033 C: Expect: 100-continue 1035 S: HTTP/1.1 100 Continue 1037 C: 98 1038 C: 0.i.isp.net no-reverse 1 2.i.isp.net 1039 C: 1.i.isp.net no-reverse 1 5.e.isp.net 1040 C: 2.i.isp.net no-reverse 1 0.i.isp.net 1041 C: 3.i.isp.net no-reverse 1 4.e.isp.net 1043 C: 0 1045 S: HTTP/1.1 200 OK 1046 S: Transfer-Encoding: chunked 1047 S: X-P4P-PIDMap: 1 1048 S: Cache-Control: max-age=7200 1049 S: Content-Type: text/plain 1050 S: Date: Tue, 24 Feb 2009 19:26:39 GMT 1052 S: A4 1053 S: 0.i.isp.net no-reverse 1 2.i.isp.net 14 1054 S: 1.i.isp.net no-reverse 1 5.e.isp.net 50 1055 S: 2.i.isp.net no-reverse 1 0.i.isp.net 14 1056 S: 3.i.isp.net no-reverse 1 4.e.isp.net 68 1058 S: 0 1060 5. Discussions 1062 5.1. Discovery 1064 To make use of a P4P Portal Server, an application must first be able 1065 to identify the address and port on which the server is running. The 1066 discovery mechanism is not part of the P4P protocol specification as 1067 it can be provided as a modular component in the framework. Several 1068 existing protocols, such as DNS, DHCP, or IP multicast, can be used 1069 to discover the service locations of the P4P Portal Servers. This 1070 section briefly describes the discovery mechanism used by the current 1071 P4P implementation. 1073 The P4P prototype is (as of this writing) deployed with a small 1074 number of active Portal Servers. Thus, a simple centralized 1075 discovery mechanism is used for clients that must discover a Portal 1076 Server. Manual configuration is used for tracker-based integrations, 1077 by configuring Application Trackers with addresses of available 1078 Portal Servers. This mechanism is independent of the protocol 1079 messages exchanged between applications and Portal Servers, and hence 1080 can easily be replaced by another mechanism (e.g., as recommended by 1081 ALTO). 1083 5.2. Delegation 1085 During P4P field tests, ISPs have proposed the possibility of 1086 delegation, in which an ISP provides information for customer 1087 networks which do not wish to run Portal Servers themselves. A 1088 consideration for delegation is that customer networks may wish to 1089 explicitly configure such delegation. 1091 5.3. Load Balancing Considerations 1093 Due to a large volume of requests or fault tolerance concerns, it may 1094 an ISP may wish to provide multiple Portal Servers to serve requests. 1095 The current P4P protocol only requests information from Portal 1096 Servers, so it is straightforward to use existing load balancing 1097 techniques and/or providing redundant backup Portal Servers. 1099 5.4. Caching P4P Information 1101 P4P information can include parameters controlling the lifetime and 1102 caching options. In particular, the standard HTTP Expires (for HTTP 1103 1.0 and 1.1) and Cache-Control (for HTTP 1.1) headers MAY be included 1104 in response messages from Portal Services. Portal Servers MUST NOT 1105 include Cache-Control headers enabling caching in responses to non- 1106 empty requests. The semantics applied to the Expires and Cache- 1107 Control headers follow the interpretation in the standard HTTP 1108 protocol. 1110 Requests to Portal Services MAY include Cache-Control headers to 1111 serve as instructions to the Portal Server. The Portal Server MUST 1112 follow standard HTTP behavior in response to such headers. Note that 1113 this includes the possibility of ignoring the instruction and 1114 including a Warning header in the response message. 1116 5.5. Transport and Encoding Considerations 1118 The P4P framework does not depend on any particular message transport 1119 or encoding. However, the current P4P Protocol uses HTTP since it is 1120 widely-implemented and directly provides or integrates with much of 1121 the desired functionality: 1123 o Authentication and Encryption: HTTP directly provides Basic and 1124 Digest authentication options. Existing implementations also 1125 commonly integrate SSL/TLS which can also provide authentication 1126 and encryption. See Section 6.1 for further discussion. 1128 o Caching: Network information may be easily cached to reduce load 1129 on a Portal Server. The current P4P protocol formats requests and 1130 responses (by specifying operations and parameters in the Request 1131 URI) such that they may be cached using existing HTTP cache 1132 servers. As discussed in Section 5.4, Portal Servers indicate the 1133 lifetime of P4P information, and the same caching parameters 1134 indicate to applications how long P4P information is valid before 1135 it should be refreshed. 1137 Note, however, that other transports or message encodings may have 1138 benefits in certain (e.g., UDP for small messages). 1140 6. Security Considerations 1142 6.1. Protecting P4P Information 1144 A Portal Server can optionally control access to P4P information to 1145 specific users or applications. Additionally, the transport of such 1146 information may be encrypted. This section discusses the 1147 authentication and encryption as they relate to the P4P protocol. 1148 Note that authorization is outside the scope of this document. 1150 Note that the discovery mechanism may need to account for certain 1151 Portal Server capabilities (e.g., SSL/TLS). 1153 6.1.1. Authentication 1155 If a Portal Server wishes the P4P interfaces to be accessible to 1156 particular users or applications, it MAY use either a standard HTTP 1157 authentication techniques (e.g., Basic and Digest), or SSL/TLS. 1159 6.1.2. Encryption 1161 If a Portal Server wishes requests and responses to be encrypted, it 1162 MAY use standard SSL/TLS techniques. 1164 6.2. ISPs 1166 Additional security consideration for ISPs lies in the potential risk 1167 of disclosing network topology and provisioning information through 1168 PIDs and pDistances. ISPs must evaluate how much information to 1169 reveal and the associated risks. For example, if an ISP reveals 1170 extremely fine-grained information, it may be easier for attackers to 1171 infer network topology information. ISPs should also take into 1172 account that revealing overly coarse-grained information may not 1173 provide benefits to either them or applications. 1175 6.3. Clients 1177 There are two possible security concerns for the clients: privacy and 1178 malicious P4P providers. First, clients can potentially disclose 1179 private information to the P4P Service Portals if either PIDs are 1180 extremely fine-grained or Network Location Identifiers are included 1181 directly in the query. In such a case, ISPs may be able to infer 1182 from the queries the communication patterns of a client. One 1183 possibility is for clients to only retrieve the full set of PIDs (via 1184 GetPIDMap) and pDistances (via GetpDistance). 1186 Second, a malicious or ineffective P4P service provider could lead to 1187 bad application performance or, in extreme cases, denial of service. 1188 Clients may use other mechanisms to complement P4P information, or 1189 replace or ignore P4P information if it is ineffective. 1191 7. IANA Considerations 1193 The P4P protocol includes identifiers and well-known values that may 1194 be assigned by the IANA. However, as the P4P framework is still 1195 under field trials and active development, this current specification 1196 does not cover such policies. This document will be updated to 1197 include any IANA considerations at a later point. 1199 8. Conclusions 1201 The main contribution of the P4P Framework is to establish a 1202 communication channel between network applications and the 1203 infrastructure providers (ISPs). The current implementation focuses 1204 on providing the services to query PIDs for aggregation and 1205 pDistances for network information and preferences among PIDs for 1206 communication. This document provides a formal specification of the 1207 detailed operations and message formats for the base P4P protocol 1208 used in the P4P framework. 1210 9. References 1212 9.1. Normative References 1214 [I-D.p4p-framework] Alimi, R., Pasko, D., Popkin, L., Wang, Y., and 1215 Y. Yang, "P4P: Provider Portal for P2P 1216 Applications", draft-p4p-framework-00 (work in 1217 progress), November 2008. 1219 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, 1220 "Hypertext Transfer Protocol -- HTTP/1.0", 1221 RFC 1945, May 1996. 1223 [RFC2119] Bradner, S., "Key words for use in RFCs to 1224 Indicate Requirement Levels", BCP 14, RFC 2119, 1225 March 1997. 1227 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 1228 Addressing Architecture", RFC 2373, July 1998. 1230 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, 1231 H., Masinter, L., Leach, P., and T. Berners-Lee, 1232 "Hypertext Transfer Protocol -- HTTP/1.1", 1233 RFC 2616, June 1999. 1235 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF 1236 for Syntax Specifications: ABNF", RFC 4234, 1237 October 2005. 1239 9.2. Informative References 1241 [SIGCOMM08] H. Xie, Y.R. Yang, A. Krishnamurthy, Y. Liu, and 1242 A. Silberschatz., "P4P: Provider Portal for 1243 (P2P) Applications", In ACM SIGCOMM. 2008. 1245 Appendix A. Contributors 1247 The P4P project includes contributions from many members of the P4P 1248 Working Group, hosted by DCIA. 1250 The individuals involved in the design and P4P field tests include 1251 (in alphabetical order): 1253 o Richard Alimi, Yale University 1255 o Alex Gerber, AT&T 1257 o Chris Griffiths, Comcast 1259 o Ramit Hora, Pando Networks 1261 o Arvind Krishnamurthy, University of Washington 1263 o Y. Grace Liu, IBM Watson 1265 o Jason Livingood, Comcast 1267 o Michael Merritt, AT&T 1268 o Doug Pasko, Verizon 1270 o Reinaldo Penno, Juniper Networks 1272 o Laird Popkin, Pando Networks 1274 o Stefano Previdi, Cisco 1276 o Satish Raghunath, Juniper Networks 1278 o James Royalty, Pando Networks 1280 o Thomas Scholl, AT&T 1282 o Emilio Sepulveda, Telefonica 1284 o Stanislav Shalunov, BitTorrent 1286 o Avi Silberschatz, Yale 1288 o Hassan Sipra, Bell Canada 1290 o Haibin Song, Huawei 1292 o Oliver Spatscheck, AT&T 1294 o Jia Wang, AT&T 1296 o Richard Woundy, Comcast 1298 o Hao Wang, Yale University 1300 o Ye Wang, Yale University 1302 o Haiyong Xie, Yale University 1304 o Y. Richard Yang, Yale University 1306 Appendix B. Acknowledgments 1308 The authors would like to thank the members of the P4P Working Group 1309 for their collaboration, and the members of the p2pi mailing list for 1310 their comments and questions. We would like to think Marty Lafferty 1311 from DCIA, Erran Li, Jin Li, and See-Mong Tang for giving us 1312 excellent feedback. 1314 We would also like to thank David Zhang from PPLive for identifying 1315 the need for PIDMap Version Tags. 1317 Authors' Addresses 1319 Yu-Shun Wang 1320 Microsoft Corp. 1321 One Microsoft Way 1322 Redmond, WA 98052 1323 USA 1325 EMail: yu-shun.wang@microsoft.com 1327 Richard Alimi 1328 Yale University 1330 EMail: richard.alimi@yale.edu 1332 Doug Pasko 1333 Verizon 1335 EMail: doug.pasko@verizon.com 1337 Laird Popkin 1338 Pando Networks, Inc. 1340 EMail: laird@pando.com 1342 Y. Richard Yang 1343 Yale University 1345 EMail: yry@cs.yale.edu