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

Versions: 00

Network Working Group                                            Y. Wang
Internet-Draft                                           Microsoft Corp.
Intended status: Informational                                  R. Alimi
Expires: September 5, 2009                               Yale University
                                                                D. Pasko
                                                                 Verizon
                                                               L. Popkin
                                                    Pando Networks, Inc.
                                                                 Y. Yang
                                                         Yale University
                                                           March 4, 2009


                       P4P Protocol Specification
                draft-wang-alto-p4p-specification-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 5, 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



Wang, et al.            Expires September 5, 2009               [Page 1]

Internet-Draft         P4P Protocol Specification             March 2009


   and restrictions with respect to this document.

Abstract

   Provider Portal for Network Applications (P4P) is a framework that
   enables Internet Service Providers (ISPs) and network application
   software developers to work jointly and cooperatively to optimize
   application communications.  The goals of this cooperation are to
   reduce network resource consumption and to accelerate applications.
   To achieve these goals, P4P allows ISPs to provide network
   information and guidance to network applications, allowing clients to
   exchange data more effectively.  This document specifies the P4P
   protocol operations and message formats.  The goal is provide a
   formal specification for developers to create inter-operable
   implementations.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Status of this Memo  . . . . . . . . . . . . . . . . . . .  4
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . .  5
       1.3.1.  Location Portal Service  . . . . . . . . . . . . . . .  5
       1.3.2.  pDistance Portal Service . . . . . . . . . . . . . . .  5
     1.4.  Common Application Scenario  . . . . . . . . . . . . . . .  5
     1.5.  Key Features . . . . . . . . . . . . . . . . . . . . . . .  6
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  6
   3.  Messages . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  6
       3.1.1.  Basic Types  . . . . . . . . . . . . . . . . . . . . .  7
       3.1.2.  IP Addresses . . . . . . . . . . . . . . . . . . . . .  7
       3.1.3.  Autonomous System Numbers  . . . . . . . . . . . . . .  7
       3.1.4.  Network Location Identifiers . . . . . . . . . . . . .  8
       3.1.5.  ISP Identifiers  . . . . . . . . . . . . . . . . . . .  8
       3.1.6.  PIDs . . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.1.7.  pDistance Values . . . . . . . . . . . . . . . . . . .  8
       3.1.8.  pDistance Endpoint . . . . . . . . . . . . . . . . . .  9
     3.2.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . .  9
       3.2.1.  Headers  . . . . . . . . . . . . . . . . . . . . . . .  9
       3.2.2.  Content-Type . . . . . . . . . . . . . . . . . . . . . 10
       3.2.3.  GetPID and PID Messages  . . . . . . . . . . . . . . . 10
       3.2.4.  GetPIDMap and PIDMap Messages  . . . . . . . . . . . . 11
       3.2.5.  GetpDistance and pDistance Messages  . . . . . . . . . 11
   4.  Protocol Operations  . . . . . . . . . . . . . . . . . . . . . 13
     4.1.  Standard Definitions and Reserved Values . . . . . . . . . 13
       4.1.1.  PIDs . . . . . . . . . . . . . . . . . . . . . . . . . 13
       4.1.2.  pDistances . . . . . . . . . . . . . . . . . . . . . . 14
     4.2.  Message Handling . . . . . . . . . . . . . . . . . . . . . 14



Wang, et al.            Expires September 5, 2009               [Page 2]

Internet-Draft         P4P Protocol Specification             March 2009


       4.2.1.  Common Operations  . . . . . . . . . . . . . . . . . . 15
       4.2.2.  GetPID . . . . . . . . . . . . . . . . . . . . . . . . 15
       4.2.3.  GetPIDMap  . . . . . . . . . . . . . . . . . . . . . . 16
       4.2.4.  GetpDistance . . . . . . . . . . . . . . . . . . . . . 17
     4.3.  Exception Handling . . . . . . . . . . . . . . . . . . . . 19
       4.3.1.  Invalid Request URI Path . . . . . . . . . . . . . . . 19
       4.3.2.  Invalid Request Format . . . . . . . . . . . . . . . . 19
     4.4.  Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     4.5.  Message Exchange Examples  . . . . . . . . . . . . . . . . 19
       4.5.1.  GetPID . . . . . . . . . . . . . . . . . . . . . . . . 20
       4.5.2.  GetPIDMap  . . . . . . . . . . . . . . . . . . . . . . 22
       4.5.3.  GetpDistance . . . . . . . . . . . . . . . . . . . . . 23
   5.  Discussions  . . . . . . . . . . . . . . . . . . . . . . . . . 24
     5.1.  Discovery  . . . . . . . . . . . . . . . . . . . . . . . . 24
     5.2.  Delegation . . . . . . . . . . . . . . . . . . . . . . . . 25
     5.3.  Load Balancing Considerations  . . . . . . . . . . . . . . 25
     5.4.  Caching P4P Information  . . . . . . . . . . . . . . . . . 25
     5.5.  Transport and Encoding Considerations  . . . . . . . . . . 25
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
     6.1.  Protecting P4P Information . . . . . . . . . . . . . . . . 26
       6.1.1.  Authentication . . . . . . . . . . . . . . . . . . . . 26
       6.1.2.  Encryption . . . . . . . . . . . . . . . . . . . . . . 26
     6.2.  ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     6.3.  Clients  . . . . . . . . . . . . . . . . . . . . . . . . . 27
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
   8.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 27
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 27
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 28
   Appendix A.  Contributors  . . . . . . . . . . . . . . . . . . . . 28
   Appendix B.  Acknowledgments . . . . . . . . . . . . . . . . . . . 29




















Wang, et al.            Expires September 5, 2009               [Page 3]

Internet-Draft         P4P Protocol Specification             March 2009


1.  Introduction

   Provider Portal for Network Applications (P4P) [I-D.p4p-framework] is
   a framework that enables Internet Service Providers (ISPs) and
   network application software developers to work jointly and
   cooperatively to optimize application communications.  The goals of
   this cooperation are to reduce network resource consumption and to
   accelerate applications.  To achieve these goals, P4P allows ISPs to
   provide network information and guidance to network applications,
   allowing clients to exchange data more effectively.

   This document specifies the P4P protocol operations and message
   formats.  The goal is provide a formal specification for developers
   to create inter-operable implementations.

1.1.  Status of this Memo

   The goal of this specification is to provide a snapshot of the
   current P4P design and implementation.  Please refer to the P4P
   Framework document [I-D.p4p-framework] for detailed description of
   the design rationale and architecture.  As the P4P framework is still
   under field trials and active development, this document will be
   updated to track the progress of major milestones or releases of the
   P4P framework.

1.2.  Terminology

   A detailed description of the terminology can be found in
   [I-D.p4p-framework].  This section provides a short list of the
   terminology used in this specification.

   o  Network Location Identifier: IP address, IP prefix, or an
      autonomous system number (ASN).

   o  PID (Partition ID): an identifier for a set of Network Location
      Identifiers defined by ISPs for aggregation purposes under similar
      network characteristics; a PID can represent different network
      scopes such as subnet, groups of subnets, autonomous system (AS),
      etc. depending on the granularity desired by an ISP.

   o  pDistance: a metric representing network information or preference
      between PIDs or Network Location Identifiers. pDistances have
      (optional) attributes to indicate type (e.g., routing cost, hop
      count, geographical distance, etc) and their interpretation (e.g.,
      numerical or ordinal ranking).

   o  Location Portal Service: (described in Section 1.3.1)




Wang, et al.            Expires September 5, 2009               [Page 4]

Internet-Draft         P4P Protocol Specification             March 2009


   o  pDistance Portal Service: (described in Section 1.3.2)

1.3.  Protocol Overview

   The P4P framework provides two services to applications, which
   correspond to the two sets of information defined in the P4P
   Protocol: the Location Portal Service and the pDistance Portal
   Service.

1.3.1.  Location Portal Service

   The Location Portal Service provides a lookup service for the
   mappings between PIDs and Network Location Identifiers.  There are
   two interfaces defined in the Location Portal Service:

   o  GetPID: returns the PIDs corresponding to the Network Location
      Identifiers queried.

   o  GetPIDMap: returns the lists of Network Location Identifiers
      contained within the PIDs queried.  This allows applications to
      locally perform the mapping from Network Location Identifiers to
      their corresponding PIDs without further querying the Location
      Portal Service.

1.3.2.  pDistance Portal Service

   The pDistance Portal Service: provides a lookup service for the
   pDistances between given PIDs.  There is a single interface:

   o  GetpDistance: returns the pDistances between given PID pairs or
      between given Network Location Identifier pairs.

1.4.  Common Application Scenario

   A common usage scenario is for a network application, such as a peer-
   to-peer application, to use the P4P services to determine the order
   of communication preferences among a pool of available nodes that can
   provide the desired contents or services.

   One possibility is for an application to rely on the pDistance Portal
   Service alone by using Network Location Identifiers directly in the
   query.  The returned pDistances may then be used by the application
   to specify the order in which target nodes are contacted.  This use
   case may raise privacy and scalability issues due to inclusion of
   private information in requests and frequent queries.

   A second possibility is that the application queries the Location
   Portal Service to first obtain mappings between PIDs and network



Wang, et al.            Expires September 5, 2009               [Page 5]

Internet-Draft         P4P Protocol Specification             March 2009


   nodes.  These PID mappings may remain stable for a longer period of
   time.  The application can then query the pDistance Portal Service to
   obtain pDistances between the target PIDs and its own PIDs, and rank
   the network nodes accordingly.  The pDistance information may be
   refreshed at a smaller timescale than PID mappings.

   The introduction of PIDs as an aggregation point can reduce redundant
   lookups among nodes belong to the PIDs where pDistances are known
   (from prior lookups).  The separation of the Location Portal Service
   and the pDistance Portal Service provides a clean differentiation
   between the two basic types of information in P4P, which can be
   updated at different timescales.

1.5.  Key Features

   While the P4P Framework does not depend on any particular transport
   or message formats and encodings, the current P4P protocol is
   implemented primarily considering ease of application integration,
   caching of network information (Section 5.4), and authentication and
   encryption (Section 6.1).  Also see Section 5.5 for further
   discussion.

2.  Conventions Used in This Document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   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 [RFC2119].

3.  Messages

   This section formally specifies the P4P protocol messages that
   implement the P4P interfaces presented in Section 1.3.  This section
   presents encodings for data types used in the messages, and then
   defines the messages themselves.

   The current P4P protocol uses textual encodings for request and
   response messages.  The following definitions use the Augmented BNF
   and Core Rules in [RFC4234] to specify the encodings.

3.1.  Definitions

   The P4P interfaces make use of data types such as IP addresses and
   PIDs.  We first define the encodings used for these data types.





Wang, et al.            Expires September 5, 2009               [Page 6]

Internet-Draft         P4P Protocol Specification             March 2009


3.1.1.  Basic Types

   P4P data type definitions use some basic data types:

       ACHAR       = ALPHA                     ; Alphanumeric character
                   / DIGIT
       SCHAR       = ACHAR                     ; Alphanumeric character
                   / "-"                       ;   or hyphen

       ASTRING     = 1*ACHAR                   ; Alphanumeric string

       NZDIGIT     = %x31-39                   ; Non-zero digit

       UINT        = NZDIGIT *DIGIT            ; Unsigned integer
                   / "0"

   Note that when a particular definition requires an unsigned integer
   with a particular range (e.g., 16-bit unsigned integer with range 0 -
   65535), its format is indicated as UINT-K where K is the size in bits
   (e.g., UINT-16).

3.1.2.  IP Addresses

   IPv4 addresses and prefixes use their standard textual
   representation:

       ipv4-addr   = UINT-8 3("." UINT-8)      ; IPv4 address
       ipv4-prfx   = ipv4-addr "/" UINT-5      ; IPv4 prefix

   IPv6 addresses and prefixes use the standard textual representations
   as specified in Sections 2.2 and 2.3 of [RFC2373].  These
   representations are indicated in this document as 'ipv6-addr' and
   ipv6-prfx', respectively.

   IP Addresses and Prefixes may either be IPv4 or IPv6:

       ip-addr     = ipv4-addr                 ; IP address
                   / ipv6-addr
       ip-prfx     = ipv4-prfx                 ; IP prefix
                   / ipv6-prfx

3.1.3.  Autonomous System Numbers

   Autonomous System numbers may either be 16-bit or 32-bit:







Wang, et al.            Expires September 5, 2009               [Page 7]

Internet-Draft         P4P Protocol Specification             March 2009


       asn16       = "AS" UINT-16              ; 16-bit ASN
       asn32       = "AS" UINT-16 "." UINT-16  ; 32-bit ASN

       asn         = asn16                     ; 16-bit or 32-bit ASN
                   / asn32

3.1.4.  Network Location Identifiers

   Network Location Identifiers can be either IPv4 or IPv6 addresses or
   prefixes, as well as Autonomous System numbers:

       netloc-id   = ip-addr                   ; Network Location
                   / ip-prfx                   ;   Identifier
                   / asn

3.1.5.  ISP Identifiers

   ISP identifiers follow standard domain name syntax:

       hostname    = ACHAR *(*SCHAR ACHAR)     ; Hostname
       tld         = 1*ACHAR                   ; Top-level Domain
       domainname  = 1*(hostname ".") tld      ; Domain name

       isp-id      = domainname                ; ISP identifier

3.1.6.  PIDs

   PIDs use an indicator to specify whether they represent intradomain
   ("internal") or interdomain ("external") network locations:

       pid-ind-int = "i"                       ; Internal PID indicator
       pid-ind-ext = "e"                       ; External PID indicator

       pid-ind     = pid-ind-int               ; PID indicator
                   / pid-ind-ext

   A PID name is fully-specified by a 16-bit integer, its indicator, and
   ISP identifier:

       pid         = UINT-16 "." pid-ind "." isp-id
                                               ; PID

3.1.7.  pDistance Values

   pDistance values are 16-bit unsigned integers:

       pdist       = UINT-16                   ; pDistance value




Wang, et al.            Expires September 5, 2009               [Page 8]

Internet-Draft         P4P Protocol Specification             March 2009


3.1.8.  pDistance Endpoint

   pDistances are configured between pDistance Endpoints, which may be
   PIDs or specialized to Network Location Identifiers:

       pdist-endp  = pid                       ; pDistance Endpoint
                   / netloc-id

3.2.  Syntax

   This section formally defines the message formats used by the P4P
   interfaces.  The P4P protocol operates over HTTP 1.0 [RFC1945] or 1.1
   [RFC2616].  Thus, this specification defines the following components
   of the request and response messages:

   o  Request Method

   o  Request URI Path and Query String

   o  Request Data

   o  Response Data

3.2.1.  Headers

   In addition to the components of individual messages defined in this
   section, the P4P protocol defines additional headers.

3.2.1.1.  PIDMap Version Tag Response Header

   A PIDMap Version Tag (discussed in Section 4.2.1.1) is specified in
   response messages from a Portal Server using the header:

       X-P4P-PIDMap: <UINT-32>

   where <UINT-32> is a string following the 'UINT-32' format.

3.2.1.2.  pDistance Type Response Header

   The Type of pDistances contained in a response from the pDistance
   Portal Service is specified using the header:

       X-P4P-pDistType: <ASTRING>

   where <ASTRING> is a string following the 'ASTRING' format.






Wang, et al.            Expires September 5, 2009               [Page 9]

Internet-Draft         P4P Protocol Specification             March 2009


3.2.1.3.  pDistance Mode Response Header

   The Mode of pDistances contained in a response from the pDistance
   Portal Service is specified using the header:

       X-P4P-pDistMode: <ASTRING>

   where <ASTRING> is a string following the 'ASTRING' format.

3.2.2.  Content-Type

   The data contained in the request and response messages MUST use a
   Content-Type of 'text/plain'.  The standard HTTP mechanisms for
   encoding (e.g., Content-Encoding and Transfer-Encoding) the data MAY
   additionally be applied as indicated by the HTTP standard.

3.2.3.  GetPID and PID Messages

3.2.3.1.  GetPID Request

   The GetPID message requests the PIDs corresponding to a set of
   Network Location Identifiers.

   The format of the Request Data is:

       getpid-data     = *(netloc-id CRLF)

   The GetPID message is then specified as:

       Request Method: POST (may be GET if Request Data is empty)
       Request URI:    /pid
       Request Data:   getpid-data

3.2.3.2.  PID Response

   The PID message is returned by a Portal Server in response to a
   GetPID request and provides the PID for the requested Network
   Location Identifiers.

   The format of the Response Data is:

       pid-data        = 1*(netloc-id WSP pid CRLF)

   The PID message is specified as:

       Response Data:  pid-data





Wang, et al.            Expires September 5, 2009              [Page 10]

Internet-Draft         P4P Protocol Specification             March 2009


3.2.4.  GetPIDMap and PIDMap Messages

3.2.4.1.  GetPIDMap Request

   The GetPIDMap message requests the Network Location Identifiers
   contained within PIDs.

   The format of the Request Data is:

       getpidmap-data    = *(pid CRLF)

   The GetPIDMap message is specified as:

       Request Method: POST (may be GET if Request Data is empty)
       Request URI:    /pid/map
       Request Data:   getpidmap-data

3.2.4.2.  PIDMap Response

   The PIDMap message is returned by a Portal Server in response to a
   GetPIDMap request and provides the list of Network Location
   Identifiers for each of the requested PIDs.

   Each line of the Response Data contains a PID and the Network
   Location Identifiers contained in the PID.  The count of Network
   Location Identifiers in the list is also included to simplify
   processing.  The format of the Response Data is:

       pidmap-line     = pid WSP UINT-32 1*(WSP netloc-id)

       pidmap-data     = *(pidmap-line CRLF)

   The PIDMap message is specified as:

       Response Data:  pidmap-data

3.2.5.  GetpDistance and pDistance Messages

3.2.5.1.  GetpDistance Request

   The GetpDistance message requests pDistances of the specified type
   between pDistance Endpoints (i.e., a list of Source Endpoint ->
   Destination Endpoint pairs).

   pDistance Type and Mode are optionally specified as a query string
   arguments in the Request URI.

   Conceptually, the message data specifies a list of Source ->



Wang, et al.            Expires September 5, 2009              [Page 11]

Internet-Draft         P4P Protocol Specification             March 2009


   Destination pairs in the Request Data.  For efficiency, however, a
   more compact representation is used.

   Each line of the Request Data encodes a request for the pDistances
   from a particular Source Endpoint to a list of Destination Endpoints.
   By specifying an "inc-reverse" option, the pDistances from the
   Destination Endpoints to the Source Endpoint may also be requested.
   The count of Destination Endpoints in the list is also included to
   simplify processing.  The format of the Request Data is:

       getpdist-line   = pdist-endp
                           WSP ("inc-reverse" / "no-reverse")
                           WSP UINT-32
                           1*(WSP pdist-endp)

       getpdist-data   = *(getpdist-line CRLF)

   The GetpDistance message is then specified as:

       Request Method: POST (may be GET if Request Data is empty)
       Request URI:    /pdistance?type=<ASTRING>&mode=<ASTRING>&direct
       Request Data:   getpdist-data

   where <ASTRING> indicates a string following the 'ASTRING' format.
   The 'direct' parameter indicates that pDistance Endpoints are Network
   Location Identifiers instead of PIDs.

   The 'type', 'mode', and 'direct' Request URI query string parameters
   are optional.  Section 4.2.4 indicates the default behavior if not
   explicitly supplied.

3.2.5.2.  pDistance Response

   The pDistance message is returned by a Portal Server in response to a
   GetpDistance request and specifies the pDistances for the requested
   Source Endpoint -> Destination Endpoint pairs.

   The encoding for the Response Data follows a similar pattern as the
   GetpDistance message Request Data.

   Each line of the Response Data specifies the pDistances from a Source
   Endpoint to a list of Destination Endpoints.  The pDistance to a
   Destination Endpoint is encoded directly following Destination
   Endpoint in the list.  If the reverse option is "inc-reverse", a
   second pDistance is included indicating the pDistance from the
   Destination Endpoint to the Source Endpoint.  The format of the
   Response Data is:




Wang, et al.            Expires September 5, 2009              [Page 12]

Internet-Draft         P4P Protocol Specification             March 2009


       dst-pdist       = pdist-endp 1*2(WSP pdist)

       pdist-line      = pdist-endp
                           WSP ("inc-reverse" / "no-reverse")
                           WSP UINT-32
                           1*(WSP dst-pdist)

       pdist-data      = *(pdist-line CRLF)

   The pDistance message is specified as:

       Response Data:  pdist-data

4.  Protocol Operations

   The P4P Protocol is a simple request/response protocol.  This section
   first discusses standard definitions such as well-known values, and
   then defines message and error handling.

4.1.  Standard Definitions and Reserved Values

4.1.1.  PIDs

4.1.1.1.  Well-Known PIDs

   Some PID names are well-known and used for specific purposes.  These
   PIDs use ISP Identifier "pid.p4p".

4.1.1.1.1.  Default Aggregation PID

   Each Portal Server MUST define a PID which implicitly contains all
   Network Location Identifiers not contained by other Aggregation PIDs.
   This PID has the name:

       0.i.pid.p4p

4.1.1.2.  Routing Cost PIDs

   The pDistance Portal Service allows applications to query pDistances
   between PIDs.  We use the term Routing Cost PID to refer to a PID for
   which Routing Cost pDistances are defined.  As defined later in
   Section 4.2.4, a "default" request to the GetpDistance interface
   returns the Routing Cost pDistances between each pair of PIDs.  The
   full set of PIDs contained in this response message is the full set
   of Routing Cost PIDs.






Wang, et al.            Expires September 5, 2009              [Page 13]

Internet-Draft         P4P Protocol Specification             March 2009


4.1.2.  pDistances

4.1.2.1.  Reserved pDistance Types

   The pDistance Portal Service may define pDistances of multiple types.
   Specific pDistance types have reserved names beginning with "p4p".

4.1.2.1.1.  Routing Cost pDistance

   Each Portal Server MUST define the Routing Cost pDistance type.  This
   type uses the name:

       p4proutingcost

4.1.2.2.  Reserved pDistance Modes

   pDistances have an attribute, called a Mode, indicating how they
   should be interpreted.  Modes for both numerical and ordinal
   pDistances have reserved names.

4.1.2.2.1.  Numerical pDistances

   Each Portal Server MUST reserve the following pDistance Mode to
   indicate numerical pDistances:

       p4pnumerical

   Numerical pDistances are defined such that a smaller pDistance value
   indicates a higher preference, while larger pDistance values
   indicates a lower preference.

4.1.2.2.2.  Ordinal pDistances

   Each Portal Server MUST reserve the following pDistance Mode to
   indicate ordinal pDistances:

       p4pordinal

   Ordinal pDistances are defined such that a smaller pDistance value
   indicates a higher preference, while a larger pDistance value
   indicates a lower preference.

4.2.  Message Handling

   This section further defines P4P interfaces by detailing the
   semantics applied to the P4P messages discussed in Section 3.2.





Wang, et al.            Expires September 5, 2009              [Page 14]

Internet-Draft         P4P Protocol Specification             March 2009


4.2.1.  Common Operations

   In addition to the specific message handling behavior discussed later
   in this section, certain common operations apply to all P4P
   interfaces.

4.2.1.1.  PIDMap Version Tag

   Recall that P4P information is separated into two services, and that
   information provided by the pDistance Portal Service may be dependent
   on current PID mappings provided by the Location Portal Service.
   Applications may query the services independently, but should also
   ensure that they use consistent information.

   PIDMap Version Tags are opaque identifiers that allow an application
   to detect when previously-retrieved PID mappings are no longer valid.
   Conceptually, a Portal Server maintains a database, called the
   PIDMap, containing the mappings between Network Location Identifiers
   and PIDs.  All responses from the Location Portal Service and
   pDistance Portal Service include the Version Tag of the PIDMap used
   to generate the response.  If the Version Tag for pDistance
   information received by an application does not match the Version Tag
   for the stored PID mappings, the PID mappings should be updated from
   the Location Portal Service.

   One way to implement the Version Tag is as an integer which is
   incremented when the PIDMap is changed at the Portal Server.  The
   integer can wrap around to 0 if necessary.

   Each non-error response message from a Portal Server MUST include a
   'X-P4P-PIDMap' header with its value being the Version Tag of the
   PIDMap used to generate the response.

4.2.1.2.  Successful Responses

   A Portal Server MUST use HTTP Status Code 200 when replying to an
   operation that completed successfully.  Note that this includes cases
   where the Portal Server responds with only a subset of the requested
   information, as discussed later in this section.  The requesting
   application is expected to handle such cases if necessary.

4.2.2.  GetPID

   A P4P Portal Server MUST implement the GetPID interface.

   The GetPID interface is defined to allow the Portal Server to
   directly return the PIDs for the supplied list of Network Location
   Identifiers.  In the absence of an error condition specified in



Wang, et al.            Expires September 5, 2009              [Page 15]

Internet-Draft         P4P Protocol Specification             March 2009


   Section 4.3, the Portal Server MUST respond with a PID message
   specifying a PID for each queried Network Location Identifier
   supplied in the GetPID request message.

4.2.2.1.  Empty Requests

   If the GetPID request message is empty (i.e., it contains a zero-
   length list of Network Location Identifiers), the Portal Server MUST
   interpret the request as if the list of Network Location Identifiers
   contained the IP address of the requestor as its only element.

   This provides an easy mechanism for a client to lookup its own PID
   even when it is behind a NAT or has multiple network interfaces.

4.2.3.  GetPIDMap

   A P4P Portal Server SHOULD implement the GetPIDMap interface.

   The GetPIDMap interface is defined to provide an application
   information such that it can locally map between Network Location
   Identifiers and PIDs.  In the absence of an error condition specified
   in Section 4.3, the Portal Server MUST respond with a PIDMap message
   containing lists of Network Location Identifiers for at least the
   Routing Cost PIDs supplied in the GetPIDMap request message.  If the
   request specifies a non-empty list of PIDs, the Portal Server MUST
   NOT respond with lists of Network Location Identifiers for PIDs not
   contained in the request.

4.2.3.1.  Empty Requests

   If the GetPIDMap request message is empty (i.e., it contains a zero-
   length list of PIDs), the Portal Server MUST interpret the request as
   if the list of PIDs were the full set of Routing Cost PIDs.

4.2.3.2.  Non-Routing Cost PIDs

   If the GetPIDMap request message contains PIDs that are not in the
   set of Routing Cost PIDs, the Portal Server MAY interpret the request
   as if the list of PIDs did not contain such PIDs.

4.2.3.3.  Network Location Identifier Lists

   The Network Location Identifiers returned by the Portal Server
   SHOULD, where possible, allow applications to locally obtain
   equivalent mappings between PIDs and Network Location Identifiers as
   would be obtained using the GetPID interface.  If the list of Network
   Location Identifiers contains AS numbers, the Portal Server SHOULD
   ensure that this mapping can be done by applications with reasonable



Wang, et al.            Expires September 5, 2009              [Page 16]

Internet-Draft         P4P Protocol Specification             March 2009


   accuracy with publicly-available information (e.g., public
   databases).

4.2.4.  GetpDistance

   A P4P Portal Server MUST implement the GetpDistance interface for
   pDistances amongst PIDs.  A P4P Portal Server MAY implement the
   GetpDistance interface for pDistances directly between Network
   Location Identifiers.

   The GetpDistance interface provides pDistances between PIDs defined
   by the Location Portal Service.  It may also be used to directly
   query the pDistances between Network Location Identifiers.  In the
   absence of an error condition specified in Section 4.3, the Portal
   Server MUST respond with a pDistance message containing pDistances of
   the requested type for all requested Source Endpoint -> Destination
   Endpoint pairs for which the pDistance type is defined.  If the
   request specifies a non-empty list of Source Endpoint -> Destination
   Endpoint pairs, the Portal Server MUST NOT respond with pDistances
   for pairs not contained in the request.

4.2.4.1.  Endpoint Types

   If the GetpDistance request message does not specify the 'direct'
   query string parameter, the Portal Server MUST parse all endpoints in
   the Request Data as PIDs (and hence follow the 'pid' syntax).  If the
   'direct' query string parameter is specified, the Portal Server MUST
   parse all endpoints in the Request Data as Network Location
   Identifiers (and hence follow the 'netloc-id' syntax).  If an
   endpoint in the request is found to not meet the expected format, the
   Portal Server MUST reject the request as being incorrectly formatted
   (see Section 4.3.2).

4.2.4.2.  Invalid PID Pairs

   If the GetpDistance request message contains PIDs that are not in the
   set of PIDs that define pDistances of the requested type, the Portal
   Server MAY interpret the request as if the list of Source PID ->
   Destination PID pairs did not contain pairs referring to such PIDs.

4.2.4.3.  Network Location Identifier Endpoints

   If the 'direct' query string parameter is specified, the the Portal
   Server MAY return customized pDistances instead of pDistances amongst
   the PIDs that contain the Network Location Identifiers.

   If a Portal Server does not implement the GetpDistance query for
   Network Location Identifiers, it MUST reply with a HTTP 501 (Not



Wang, et al.            Expires September 5, 2009              [Page 17]

Internet-Draft         P4P Protocol Specification             March 2009


   Implemented) status code.

4.2.4.4.  Default pDistance Type

   If the GetpDistance request message does not specify a pDistance type
   via a 'type' query string parameter, the Portal Server MUST interpret
   the message as if it specified the type as 'p4proutingcost'.

4.2.4.5.  Unsupported pDistance Type

   If the GetpDistance request message specifies a pDistance type that
   is not supported by the Portal Server, the Portal Server MUST reply
   with a HTTP 501 (Not Implemented) status code.

4.2.4.6.  pDistance Type Handling

   The pDistances encoded in the response message MUST be pDistances
   with the Type specified in the request message.  If the pDistances
   encoded in the response message are not Routing Cost pDistances, the
   Portal Server MUST specify the returned pDistances' Type using the
   'X-P4P-pDistType' header.

4.2.4.7.  Default pDistance Mode

   If the GetpDistance request message does not specify a pDistance Mode
   via a 'mode' query string parameter, the Portal Server MUST interpret
   the message as if it specified the mode as 'p4pnumerical'.

4.2.4.8.  Unsupported pDistance Mode

   If the GetPDistance request message specifies a pDistance Mode that
   is not supported, the Portal Server MUST reply with pDistances with
   either a Mode of 'p4pnumerical' or 'p4pordinal'.  Thus, a Portal
   Server must implement at least one of 'p4pnumerical' or 'p4pordinal'
   pDistances, but it may choose which to support.

4.2.4.9.  pDistance Mode Handling

   The pDistances encoded in the response message SHOULD be pDistances
   with the Mode specified in the request message.  If the pDistances
   encoded in the response message are not numerical pDistances, the
   Portal Server MUST specify the returned pDistances' Mode using the
   'X-P4P-pDistMode' header.

4.2.4.10.  Empty Requests

   If the GetpDistance request message is empty (i.e., it contains no
   Source Endpoint -> Destination Endpoint pairs) and the 'direct' query



Wang, et al.            Expires September 5, 2009              [Page 18]

Internet-Draft         P4P Protocol Specification             March 2009


   string parameter is not specified, the Portal Server MUST interpret
   the request as if the list of PIDs were the full set of PIDs that
   define pDistances of the requested type.

   If the request message is empty and the 'direct' query string
   parameter is specified, the Portal Server MUST reject the request as
   being incorrectly formatted (see Section 4.3.2).

4.3.  Exception Handling

   This section specifies Portal Server behavior for specific error
   conditions that may be encountered.  Standard HTTP status codes are
   returned by a Portal Server.  The Portal Server MUST follow the HTTP
   protocol version in use for the current request for error conditions
   (e.g., indicating server overload conditions) not explicitly listed
   in this section.

4.3.1.  Invalid Request URI Path

   If the Path portion of the Request URI does not refer to a valid P4P
   interface, the Portal Server MUST return an HTTP 404 (Not Found)
   status code.

4.3.2.  Invalid Request Format

   If the Request Data or a Request URI Query String parameter is
   formatted incorrectly (i.e., it does not follow the syntax in
   Section 3.2 or it fails to meet additional requirements specified in
   Section 4.2), the Portal Server MUST return an HTTP 400 (Bad Request)
   status code.

4.4.  Timers

   The P4P protocol is simple request/response protocol and hence does
   not require any additional timers beyond those required by the
   underlying protocol (i.e., HTTP and TCP).

4.5.  Message Exchange Examples

   This section presents example message captures from the P4P protocol.
   Note that the message captures use HTTP chunked encoding for requests
   and responses.  This is an implementation detail and does not imply
   that the P4P protocol must use chunked encoding.

   The message exchange examples in this section use a Portal Server
   configured with the following simple, illustrative topology.  Labels
   on arrows between PIDs indicate pDistances.  The pDistance from a PID
   to itself is configured to be 1.  Note that the Portal Server reports



Wang, et al.            Expires September 5, 2009              [Page 19]

Internet-Draft         P4P Protocol Specification             March 2009


   end-to-end pDistances.  The method and factors (including, but not
   limited to, algorithm and routing policy) for computing end-to-end
   pDistances is a policy decision implemented by the Portal Server, and
   is outside the scope of this document.  These examples are only
   provided to illustrate message format.

       .-------------.
       | 4.e.isp.net |
       '-------------'
              ^
              | 60
              v
       .-------------.    8     .-------------.
       | 0.i.isp.net | <------> | 3.i.isp.net |
       '-------------'          '-------------'
              ^                        ^
              | 4                      | 4
              v                        v
       .-------------.    10    .-------------.  40  .-------------.
       | 1.i.isp.net | <------> | 2.i.isp.net | <--> | 5.e.isp.net |
       '-------------'          '-------------'      '-------------'

   Each PID has a set of Network Location Identifiers configured:

       0.i.isp.net : 10.0.0.0/24 10.0.1.0/24
       1.i.isp.net : 10.1.0.0/16
       2.i.isp.net : 10.2.0.0/24 10.2.1.0/24
       3.i.isp.net : 10.3.0.0/24
       4.e.isp.net : 172.16.0.0/12
       5.e.isp.net : 192.168.0.0/16

4.5.1.  GetPID

4.5.1.1.  Request PID for Own IP Address

   The following message exchange illustrates a client requesting its
   own PID from a Portal Server.  The client uses an empty request, and
   the Portal Server responds with the client's IP address and the PID
   corresponding to the IP address.












Wang, et al.            Expires September 5, 2009              [Page 20]

Internet-Draft         P4P Protocol Specification             March 2009


       C: POST /pid HTTP/1.1
       C: Host: localhost:6671
       C: Accept: */*
       C: Transfer-Encoding: chunked
       C: Expect: 100-continue

       S: HTTP/1.1 100 Continue

       C: 2

       C: 0

       S: HTTP/1.1 200 OK
       S: Transfer-Encoding: chunked
       S: X-P4P-PIDMap: 1
       S: Cache-Control: max-age=604800
       S: Content-Type: text/plain
       S: Date: Tue, 24 Feb 2009 19:26:43 GMT

       S: 17
       S: 10.1.1.12 1.i.isp.net

       S: 0

4.5.1.2.  Request PIDs for List of IP Addresses

   The following message exchange illustrates a client directly asking
   the Portal Server to map a set of IP addresses into their
   corresponding PIDs.






















Wang, et al.            Expires September 5, 2009              [Page 21]

Internet-Draft         P4P Protocol Specification             March 2009


       C: POST /pid HTTP/1.1
       C: Host: localhost:6671
       C: Accept: */*
       C: Transfer-Encoding: chunked
       C: Expect: 100-continue

       S: HTTP/1.1 100 Continue

       C: 1e
       C: 10.1.23.200
       C: 192.168.1.128

       C: 0

       S: HTTP/1.1 200 OK
       S: Transfer-Encoding: chunked
       S: X-P4P-PIDMap: 1
       S: Cache-Control: max-age=604800
       S: Content-Type: text/plain
       S: Date: Tue, 24 Feb 2009 19:26:47 GMT

       S: 34
       S: 10.1.23.200   1.i.isp.net
       S: 192.168.1.128 5.e.isp.net

       S: 0

4.5.2.  GetPIDMap

4.5.2.1.  Request PID Map

   The following message exchange illustrates an application requesting
   the set of Network Location Identifiers contained within particular
   PIDs.  Note that the application could also request for Network
   Location Identifiers in all Routing Cost PIDs by using an empty
   request.















Wang, et al.            Expires September 5, 2009              [Page 22]

Internet-Draft         P4P Protocol Specification             March 2009


       C: GET /pid/map HTTP/1.1
       C: Host: localhost:6671
       C: Accept: */*
       C: Transfer-Encoding: chunked
       C: Expect: 100-continue

       S: HTTP/1.1 100 Continue

       C: 1c
       C: 0.i.isp.net
       C: 2.i.isp.net

       C: 0

       S: HTTP/1.1 200 OK
       S: Transfer-Encoding: chunked
       S: X-P4P-PIDMap: 1
       S: Cache-Control: max-age=604800
       S: Content-Type: text/plain
       S: Date: Tue, 24 Feb 2009 19:26:55 GMT

       S: 4E
       S: 0.i.isp.net   2   10.0.0.0/24 10.0.1.0/24
       S: 2.i.isp.net   2   10.2.0.0/24 10.2.1.0/24

       S: 0

4.5.3.  GetpDistance

4.5.3.1.  Request pDistance Among PIDs

   The following message exchange illustrates an application requesting
   Routing Cost pDistances between particular PIDs.  Note that the
   application could also request pDistances amongst all Routing Cost
   PIDs by using an empty request.
















Wang, et al.            Expires September 5, 2009              [Page 23]

Internet-Draft         P4P Protocol Specification             March 2009


       C: POST /pdistance HTTP/1.1
       C: Host: localhost:6671
       C: Accept: */*
       C: Transfer-Encoding: chunked
       C: Expect: 100-continue

       S: HTTP/1.1 100 Continue

       C: 98
       C: 0.i.isp.net   no-reverse  1   2.i.isp.net
       C: 1.i.isp.net   no-reverse  1   5.e.isp.net
       C: 2.i.isp.net   no-reverse  1   0.i.isp.net
       C: 3.i.isp.net   no-reverse  1   4.e.isp.net

       C: 0

       S: HTTP/1.1 200 OK
       S: Transfer-Encoding: chunked
       S: X-P4P-PIDMap: 1
       S: Cache-Control: max-age=7200
       S: Content-Type: text/plain
       S: Date: Tue, 24 Feb 2009 19:26:39 GMT

       S: A4
       S: 0.i.isp.net   no-reverse  1   2.i.isp.net 14
       S: 1.i.isp.net   no-reverse  1   5.e.isp.net 50
       S: 2.i.isp.net   no-reverse  1   0.i.isp.net 14
       S: 3.i.isp.net   no-reverse  1   4.e.isp.net 68

       S: 0

5.  Discussions

5.1.  Discovery

   To make use of a P4P Portal Server, an application must first be able
   to identify the address and port on which the server is running.  The
   discovery mechanism is not part of the P4P protocol specification as
   it can be provided as a modular component in the framework.  Several
   existing protocols, such as DNS, DHCP, or IP multicast, can be used
   to discover the service locations of the P4P Portal Servers.  This
   section briefly describes the discovery mechanism used by the current
   P4P implementation.

   The P4P prototype is (as of this writing) deployed with a small
   number of active Portal Servers.  Thus, a simple centralized
   discovery mechanism is used for clients that must discover a Portal
   Server.  Manual configuration is used for tracker-based integrations,



Wang, et al.            Expires September 5, 2009              [Page 24]

Internet-Draft         P4P Protocol Specification             March 2009


   by configuring Application Trackers with addresses of available
   Portal Servers.  This mechanism is independent of the protocol
   messages exchanged between applications and Portal Servers, and hence
   can easily be replaced by another mechanism (e.g., as recommended by
   ALTO).

5.2.  Delegation

   During P4P field tests, ISPs have proposed the possibility of
   delegation, in which an ISP provides information for customer
   networks which do not wish to run Portal Servers themselves.  A
   consideration for delegation is that customer networks may wish to
   explicitly configure such delegation.

5.3.  Load Balancing Considerations

   Due to a large volume of requests or fault tolerance concerns, it may
   an ISP may wish to provide multiple Portal Servers to serve requests.
   The current P4P protocol only requests information from Portal
   Servers, so it is straightforward to use existing load balancing
   techniques and/or providing redundant backup Portal Servers.

5.4.  Caching P4P Information

   P4P information can include parameters controlling the lifetime and
   caching options.  In particular, the standard HTTP Expires (for HTTP
   1.0 and 1.1) and Cache-Control (for HTTP 1.1) headers MAY be included
   in response messages from Portal Services.  Portal Servers MUST NOT
   include Cache-Control headers enabling caching in responses to non-
   empty requests.  The semantics applied to the Expires and Cache-
   Control headers follow the interpretation in the standard HTTP
   protocol.

   Requests to Portal Services MAY include Cache-Control headers to
   serve as instructions to the Portal Server.  The Portal Server MUST
   follow standard HTTP behavior in response to such headers.  Note that
   this includes the possibility of ignoring the instruction and
   including a Warning header in the response message.

5.5.  Transport and Encoding Considerations

   The P4P framework does not depend on any particular message transport
   or encoding.  However, the current P4P Protocol uses HTTP since it is
   widely-implemented and directly provides or integrates with much of
   the desired functionality:

   o  Authentication and Encryption: HTTP directly provides Basic and
      Digest authentication options.  Existing implementations also



Wang, et al.            Expires September 5, 2009              [Page 25]

Internet-Draft         P4P Protocol Specification             March 2009


      commonly integrate SSL/TLS which can also provide authentication
      and encryption.  See Section 6.1 for further discussion.

   o  Caching: Network information may be easily cached to reduce load
      on a Portal Server.  The current P4P protocol formats requests and
      responses (by specifying operations and parameters in the Request
      URI) such that they may be cached using existing HTTP cache
      servers.  As discussed in Section 5.4, Portal Servers indicate the
      lifetime of P4P information, and the same caching parameters
      indicate to applications how long P4P information is valid before
      it should be refreshed.

   Note, however, that other transports or message encodings may have
   benefits in certain (e.g., UDP for small messages).

6.  Security Considerations

6.1.  Protecting P4P Information

   A Portal Server can optionally control access to P4P information to
   specific users or applications.  Additionally, the transport of such
   information may be encrypted.  This section discusses the
   authentication and encryption as they relate to the P4P protocol.
   Note that authorization is outside the scope of this document.

   Note that the discovery mechanism may need to account for certain
   Portal Server capabilities (e.g., SSL/TLS).

6.1.1.  Authentication

   If a Portal Server wishes the P4P interfaces to be accessible to
   particular users or applications, it MAY use either a standard HTTP
   authentication techniques (e.g., Basic and Digest), or SSL/TLS.

6.1.2.  Encryption

   If a Portal Server wishes requests and responses to be encrypted, it
   MAY use standard SSL/TLS techniques.

6.2.  ISPs

   Additional security consideration for ISPs lies in the potential risk
   of disclosing network topology and provisioning information through
   PIDs and pDistances.  ISPs must evaluate how much information to
   reveal and the associated risks.  For example, if an ISP reveals
   extremely fine-grained information, it may be easier for attackers to
   infer network topology information.  ISPs should also take into
   account that revealing overly coarse-grained information may not



Wang, et al.            Expires September 5, 2009              [Page 26]

Internet-Draft         P4P Protocol Specification             March 2009


   provide benefits to either them or applications.

6.3.  Clients

   There are two possible security concerns for the clients: privacy and
   malicious P4P providers.  First, clients can potentially disclose
   private information to the P4P Service Portals if either PIDs are
   extremely fine-grained or Network Location Identifiers are included
   directly in the query.  In such a case, ISPs may be able to infer
   from the queries the communication patterns of a client.  One
   possibility is for clients to only retrieve the full set of PIDs (via
   GetPIDMap) and pDistances (via GetpDistance).

   Second, a malicious or ineffective P4P service provider could lead to
   bad application performance or, in extreme cases, denial of service.
   Clients may use other mechanisms to complement P4P information, or
   replace or ignore P4P information if it is ineffective.

7.  IANA Considerations

   The P4P protocol includes identifiers and well-known values that may
   be assigned by the IANA.  However, as the P4P framework is still
   under field trials and active development, this current specification
   does not cover such policies.  This document will be updated to
   include any IANA considerations at a later point.

8.  Conclusions

   The main contribution of the P4P Framework is to establish a
   communication channel between network applications and the
   infrastructure providers (ISPs).  The current implementation focuses
   on providing the services to query PIDs for aggregation and
   pDistances for network information and preferences among PIDs for
   communication.  This document provides a formal specification of the
   detailed operations and message formats for the base P4P protocol
   used in the P4P framework.

9.  References

9.1.  Normative References

   [I-D.p4p-framework]  Alimi, R., Pasko, D., Popkin, L., Wang, Y., and
                        Y. Yang, "P4P: Provider Portal for P2P
                        Applications", draft-p4p-framework-00 (work in
                        progress), November 2008.

   [RFC1945]            Berners-Lee, T., Fielding, R., and H. Nielsen,
                        "Hypertext Transfer Protocol -- HTTP/1.0",



Wang, et al.            Expires September 5, 2009              [Page 27]

Internet-Draft         P4P Protocol Specification             March 2009


                        RFC 1945, May 1996.

   [RFC2119]            Bradner, S., "Key words for use in RFCs to
                        Indicate Requirement Levels", BCP 14, RFC 2119,
                        March 1997.

   [RFC2373]            Hinden, R. and S. Deering, "IP Version 6
                        Addressing Architecture", RFC 2373, July 1998.

   [RFC2616]            Fielding, R., Gettys, J., Mogul, J., Frystyk,
                        H., Masinter, L., Leach, P., and T. Berners-Lee,
                        "Hypertext Transfer Protocol -- HTTP/1.1",
                        RFC 2616, June 1999.

   [RFC4234]            Crocker, D., Ed. and P. Overell, "Augmented BNF
                        for Syntax Specifications: ABNF", RFC 4234,
                        October 2005.

9.2.  Informative References

   [SIGCOMM08]          H. Xie, Y.R. Yang, A. Krishnamurthy, Y. Liu, and
                        A. Silberschatz., "P4P: Provider Portal for
                        (P2P) Applications", In ACM SIGCOMM. 2008.

Appendix A.  Contributors

   The P4P project includes contributions from many members of the P4P
   Working Group, hosted by DCIA.

   The individuals involved in the design and P4P field tests include
   (in alphabetical order):

   o  Richard Alimi, Yale University

   o  Alex Gerber, AT&T

   o  Chris Griffiths, Comcast

   o  Ramit Hora, Pando Networks

   o  Arvind Krishnamurthy, University of Washington

   o  Y. Grace Liu, IBM Watson

   o  Jason Livingood, Comcast

   o  Michael Merritt, AT&T




Wang, et al.            Expires September 5, 2009              [Page 28]

Internet-Draft         P4P Protocol Specification             March 2009


   o  Doug Pasko, Verizon

   o  Reinaldo Penno, Juniper Networks

   o  Laird Popkin, Pando Networks

   o  Stefano Previdi, Cisco

   o  Satish Raghunath, Juniper Networks

   o  James Royalty, Pando Networks

   o  Thomas Scholl, AT&T

   o  Emilio Sepulveda, Telefonica

   o  Stanislav Shalunov, BitTorrent

   o  Avi Silberschatz, Yale

   o  Hassan Sipra, Bell Canada

   o  Haibin Song, Huawei

   o  Oliver Spatscheck, AT&T

   o  Jia Wang, AT&T

   o  Richard Woundy, Comcast

   o  Hao Wang, Yale University

   o  Ye Wang, Yale University

   o  Haiyong Xie, Yale University

   o  Y. Richard Yang, Yale University

Appendix B.  Acknowledgments

   The authors would like to thank the members of the P4P Working Group
   for their collaboration, and the members of the p2pi mailing list for
   their comments and questions.  We would like to think Marty Lafferty
   from DCIA, Erran Li, Jin Li, and See-Mong Tang for giving us
   excellent feedback.

   We would also like to thank David Zhang from PPLive for identifying
   the need for PIDMap Version Tags.



Wang, et al.            Expires September 5, 2009              [Page 29]

Internet-Draft         P4P Protocol Specification             March 2009


Authors' Addresses

   Yu-Shun Wang
   Microsoft Corp.
   One Microsoft Way
   Redmond, WA 98052
   USA

   EMail: yu-shun.wang@microsoft.com


   Richard Alimi
   Yale University

   EMail: richard.alimi@yale.edu


   Doug Pasko
   Verizon

   EMail: doug.pasko@verizon.com


   Laird Popkin
   Pando Networks, Inc.

   EMail: laird@pando.com


   Y. Richard Yang
   Yale University

   EMail: yry@cs.yale.edu


















Wang, et al.            Expires September 5, 2009              [Page 30]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/