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]