PPSP Y. Gu
Internet-Draft Huawei
Intended status: Standards Track David A. Bryan
Expires: November 21, 2011 Cogent Force, LLC
L. Deng
China Mobile
May 20, 2011
PPSP Tracker Protocol
draft-gu-ppsp-tracker-protocol-04
Abstract
This document outlines the functionality required for a P2P streaming
Tracker Protocol, including functional entities and architecture,
components, encoding format and syntax.
The Tracker protocol is an application-level protocol for peers to
register, publish/request content and provide peer status to
Trackers. It is also used by trackers to provide peer lists to
peers, as well as to send control/management messages to and
communicate with other trackers. The PPSP tracker protocol can serve
live media and VoD, as well as file sharing applications.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 21, 2011.
Copyright Notice
Copyright (c) 2011 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
Gu, et al. Expires November 21, 2011 [Page 1]
Internet-Draft PPSP Tracker Protocol May 2011
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Document History . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Function Entities . . . . . . . . . . . . . . . . . . . . 4
4.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Bootstrapping . . . . . . . . . . . . . . . . . . . . 6
4.2.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . 6
4.3. Description of the PPSP Tracker Protocol . . . . . . . . . 7
4.3.1. Responses . . . . . . . . . . . . . . . . . . . . . . 9
5. Message Syntax and Processing . . . . . . . . . . . . . . . . 10
5.1. HTTP/XML Encoding . . . . . . . . . . . . . . . . . . . . 10
5.1.1. HTTP Encoding . . . . . . . . . . . . . . . . . . . . 11
5.1.2. Common Message Processing . . . . . . . . . . . . . . 13
5.1.3. CONNECT Messages . . . . . . . . . . . . . . . . . . . 14
5.1.4. DISCONNECT Messages . . . . . . . . . . . . . . . . . 14
5.1.5. JOIN and JOIN_CHUNK Messages . . . . . . . . . . . . . 15
5.1.6. LEAVE Messages . . . . . . . . . . . . . . . . . . . . 18
5.1.7. FIND Messages . . . . . . . . . . . . . . . . . . . . 19
5.1.8. KEEPALIVE Messages . . . . . . . . . . . . . . . . . . 20
5.1.9. STAT Messages . . . . . . . . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6.1. Authentication between communicating tracker and peers . . 23
6.2. Signaling protection between communicating tracker and
peers . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3. Content Integrity protection against polluting
peers/trackers . . . . . . . . . . . . . . . . . . . . . . 24
6.4. Residual attacks and mitigation . . . . . . . . . . . . . 24
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Normative References . . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Gu, et al. Expires November 21, 2011 [Page 2]
Internet-Draft PPSP Tracker Protocol May 2011
1. Introduction
The P2P Streaming Protocol (PPSP) is composed of two protocols: the
PPSP Tracker Protocol and the PPSP Peer Protocol. The PPSP Tracker
Protocol provides communication between Trackers and Peers, by which
Peers report streaming status to the tracker and request candidate
lists from the tracker. [I-D.ietf-ppsp-problem-statement]specifies
that the Tracker protocol should standardize format/encoding of
information and messages between PPSP peers and PPSP trackers.
[I-D.ietf-ppsp-reqs] defines the detailed requirements for Tracker
Protocol.
This draft presents a proposal for the PPSP Tracker Protocol. We
first analyze and present the functional entities involved in Tracker
protocol. Following this, a list of functions are introduced. Then
we introduce definitions for formal syntax, semantics, and detailed
message processing instructions for the PPSP Tracker Protocol, using
an HTTP/XML encoding. This include parameters, methods, and message
formats. Most implemented P2P protocols are proprietary, as
introduced in . This draft intends to extract the fundamental
features, functionalities and policies of the proprietary protocols,
extend it based on implementation experience, and present an early
strawman sketch for an extensible protocol as a way to identify open
issues and further discussion in the PPSP WG. [I-D.ietf-ppsp-survey]
2. Terminology
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].
The draft uses the terms defined in[I-D.ietf-ppsp-problem-statement]
Additionally, this draft also uses the following terms:
Swarm: A swarm is a set of peers who are sharing the same file, live
channel or VoD program.
Chunk: A chunk is a basic unit of partitioned stream, which is used
by a peer for the purpose of storage, advertisement and exchange
among peers.
Join Time: Join time is the absolute time when a peer registers on a
Tracker. This value is recorded by the Tracker and is used to
calculate Online Time.
Online Time: Online Time shows how long the peer has been in the P2P
Gu, et al. Expires November 21, 2011 [Page 3]
Internet-Draft PPSP Tracker Protocol May 2011
streaming system since it joins. This value indicates the stability
of a peer, and it is calculated by Tracker when necessary.
Absolute Time: Absolute time is expressed as ISO 8601 [ISO.8601.2000]
timestamps, using UTC (GMT). Fractions of a second may be indicated.
Example for November 8, 1996 at 14h37 and 20 and a quarter seconds
UTC:19961108T143720.25Z
3. Document History
Changes from -03 to -04: Remove Binary encoding, add security
considertaitons and make editorial revision.
Changes from -02 to -03: The document has been updated to reflect
that both Peer-IDs and IP addresses will be returned, rather than
only Peer-IDs. Binary encoding is moved to Appendix B.
Changes from -01 to -02: The document has been updated to reflect
that Peer-IDs will be returned, rather than the open issue on Peer-
IDs or IP addresses.
Changes from -00 to -01: The operations of the protocol and their
names were changed to help clarify the functions and to eliminate
confusion. Substantial modifications were made to the proposed
protocol.
4. Protocol Overview
4.1. Function Entities
There are two primary functional entities involved in the PPSP
Tracker Protocol: Trackers and Peers.
The tracker is a logical entity storing information about which peers
can provide which pieces of information. The tracker may also
storing the status of peers, e.g. caching size, which will help the
tracker to select appropriate candidate peers for a requesting peer.
While a tracker may have an underlying implementation consisting of
more than one device, logically the tracker can most simply be
thought of as a single element, and in this document, we will treat
the tracker as a single logical unit. Trackers store a list of all
peers making up a swarm for a particular stream or file, and
(particularly in the live streaming case) may also store a list of
which chunks each peer stores.
The peers are devices actually participating in sharing information
Gu, et al. Expires November 21, 2011 [Page 4]
Internet-Draft PPSP Tracker Protocol May 2011
related to a particular stream or file. Each peer stores some
pieces, called chunks, and contacts the tracker to advertise which
information is available. When a peer wishes to obtain information,
it contacts the tracker to find other peers participating in the
swarm. The peers communicate with one another to exchange the actual
chunks, and in the case where the tracker stores only the list of
peers in the swarm, to exchange the lists of chunks.
Peer
+-------------------+
|peer signaling |
| +===============+ |
| | CONNECT | |
| | DISCONNECT | |
| | JOIN | |
| | JOIN_CHUNK | |
| | LEAVE | |
| | FIND | |
| | KEEPALIVE | |
| | STAT_REPORT | |
| +===============+ |
+-------------------+
^
-----------*-------------
Tracker V
+-------------------+
|tracker signaling |
| |
| (JOIN/LEAVE/ |
| KEEPALIVE/PUT/ |
| GET/STAT_QUERY/ |
| STAT_REPORT) |
+-------------------+
Figure 1: Tracker Protocol components
Gu, et al. Expires November 21, 2011 [Page 5]
Internet-Draft PPSP Tracker Protocol May 2011
Peer
+-------------------+
|Data management |
| Swarm ID |
| - Chunk ID |
| - peer list |
| - Buffer map |
| |
+-------------------+
^
--------------*-----------
Tracker V
+----------------------------------------------------------+
| Data management on Tracker |
| |
| +======================+ +======================+ |
| |peer status | |content status | |
| | peer ID | | +---------------+ | |
| | - online time | | | Swarm ID | | |
| | - peer property | | | - Chunk ID | | |
| | - link status | | | - peer list| | |
| | - etc. | | +---------------+ | |
| +======================+ +======================+ |
+----------------------------------------------------------+
Figure 2: Data management components in PPSP
4.2. Assumptions
4.2.1. Bootstrapping
When a peer wishes to join an existing P2P streaming application, it
must first locate a Tracker. Peers may use any method to find a
Tracker, for example obtaining it from service provider provisioning
mechanisms, from a web page, or via broadcast. Tracker discovery is
out of scope of this specification.
Similarly, we assume that peers obtain their Peer-IDs and any
certificates required for security (i.e. their peer certificates and
the tracker certificate) out of band. While this functionality may
be incorporated into the tracker, it is not require to do so. The
specification of the mechanism used to obtain a Peer-ID and
certificates is not discussed in this draft.
4.2.2. NAT Traversal
For simplicity, we assume that all trackers must be in the public
Internet and have been placed there deliberately. Issues of NAT
Gu, et al. Expires November 21, 2011 [Page 6]
Internet-Draft PPSP Tracker Protocol May 2011
traversal required in this scenario are not yet specified. The
issues related to any scheme contemplating promotion (i.e. selecting
peers be promoted and to serve as a tracker) or implementing a fully
distributed tracker are not considered in this version of the draft.
Though this draft will not describe NAT Traversal mechanism in PPSP
in detail, it tries to enable flexible NAT Traversal in future and
will consider the requirements raised by NAT draft.
4.3. Description of the PPSP Tracker Protocol
The PPSP Tracker Protocol presented is a request-response protocol.
Requests are sent, and responses returned to these requests. While
most requests are sent to the tracker from peers requesting
information, the tracker may also send messages to the peers to query
information. A single request generates a single response
(neglecting fragmentation of messages).
Note that the tracker protocol does not actually exchange any data
between the peers (either streaming of information in the live
streaming case or offline information in the time shifted scenario.).
Instead, the tracker maintains a list of peers participating in
particular stream or having chunks of a particular session, and
shares this information. Exchange of the data is negotiated and
performed by the peer protocol.
The specific operations of the protocol are:
CONNECT: Connect is the first method a peer performs. There is no
relationship between peer and tracker before the CONNECT operation
completes. Trackers will never serve a peer that has not
connected. When a peer connects, the tracker records the peer's
information, e.g. peer-ID, Connect-time, peer property, peer link
status, etc. After connecting, the peer may send additional
requests to the tracker to publish content availability, or obtain
lists of peers with specific content from the tracker. A peer
will first obtain a peer-ID and any required security certificates
from an offline enrollment server prior to performing a CONNECT
operation. Peer-ID and Certificates are recommended to be obtain
by an out-of-band mothod, so CONNECT doesn't support of returnning
a Peer-ID/Certificates.
DISCONNECT: When peer intends to leave the system and no longer
will be participating, it sends a DISCONNECT message to the
tracker. The tracker deletes the corresponding records related to
the peer, including those in peer status and content status.
After disconnecting, a peer can no longer make requests to the
tracker, except to connect again, and information about the peer
Gu, et al. Expires November 21, 2011 [Page 7]
Internet-Draft PPSP Tracker Protocol May 2011
will not be provided to other peers.
JOIN and JOIN_CHUNK: Peers use JOIN to notify a tracker they wish
to participate in a particular swarm, but do not indicate
particular chunks they possess. JOIN_CHUNK performs the same
function, but with specific chunks listed, specifying which chunks
of which swarms it presently stores. The tracker records the
content availability, i.e. adds the peer to the candidate peers
list for the notified chunk IDs of a particular swarm.
LEAVE: Peers use the LEAVE operation to indicate to the tracker
that they no longer are participating in (either sharing or
requesting) a particular swarm. The tracker will no longer
provide this peer to others when they request to join a swarm.
Note that a DISCONNECT implicitly leaves all swarms the peer is
currently participating in -- there is no need for a peer that
sends a DISCONNECT to send a separate LEAVE to the tracker for
each swarm in which they are participating.
FIND: Peers use the FIND method to request that the tracker return
lists of peers that can provide specific content or are in a
particular swarm. On receiving a FIND message, the tracker finds
the candidate peers listed in content status, and returns the list
to the requesting peer. The tracker may take peer status and
peers priority into consideration when it picks the candidate
peers to add to this list. Peer priority could be determined by
network topology preference (for example the ongoing IETF work in
ALTO), operator policy preference, etc. In Live streaming, when
receiving a FIND messages, the tracker also updates content status
to involve the new peer under a specific channel. The FIND
operation may specify a particular location within a stream and/or
chunks that the peer is interested in. Tracker can return
candidate peer list in a single response message, or split the
candidate peers into several peer list. PPSP can provide
provider-friendly traffic direction. E.g., there are 100 peers
that have the requested chunks, how should Tracker choose them?
One option is to choose peers upon their capability, the other is
to find out from ALTO server which peers are more cost effective.
But P2P application is much complicate, some existing protocols
that only try top N peers of the returned peerlist, while some
others randomly choose some peers from peerlist. So ALTO may not
helpful in this case. In this case, if Tracker can reply in a
series of responses containing decreasing priority peer lists,
PPSP can guarantee that Peers obey Trackers' choice and make no
changes to existing Peers.
KEEPALIVE: Keepalive messages are periodically sent from peers to
the tracker to notify the tracker that the peer is still alive.
Gu, et al. Expires November 21, 2011 [Page 8]
Internet-Draft PPSP Tracker Protocol May 2011
If a tracker does not receive keep-alive message for some pre-
configured time, the tracker will assume that the peer is no
longer available and will perform the same logical operations as
in Leave.
STAT_REPORT: This method allows peers to submit statistic data to
the tracker improve system performance.
STAT_QUERY: This method Tracker to request statistical information
from a particular peer.
4.3.1. Responses
As discussed at WG session and mailing list, a rough consensus is to
adopt HTTP/XML encoding. The HTTP protocol itself would handle
malformed messages, but incorrectly formatted XML bodies could
generate tracker-protocol level errors, the contents of which are
reported in an HTTP message.
SUCCESSFUL (OK): Indicates that a message has been processed
properly, and that the desired operation completed. If the
message is a request for information, the body of the message will
also include the requested information. As a result, the
following information is returned for each message:
CONNECT, DISCONNECT, JOIN, JOIN_CHUNK, FIND, FIND_CHUNK,
KEEPALIVE and STAT_REPORT return any required status
information about the successfully completed operation.
FIND and FIND_CHUNK return the list of peers meeting the
desired criteria.
STAT_QUERY returns the requested statistics in the body of the
message.
INVALID SYNTAX: Indicates an error in the format of the message/
message body.
VERSION NOT SUPPORTED: Invalid version of the protocol or message
bodies.
MESSAGE NOT SUPPORTED: The particular request is not supported by
this tracker. As an example, some trackers might choose not to
implement the statistics functions.
TEMPORARILY OVERLOADED: The server is unable to process this
message at this time. (this may be handled at the HTTP level in
the HTTP/XML case)
Gu, et al. Expires November 21, 2011 [Page 9]
Internet-Draft PPSP Tracker Protocol May 2011
INTERNAL ERROR: The server was unable to process the request due
to an internal error. (this may be handled at the HTTP in the
HTTP/XML case)
MESSAGE FORBIDDEN: The requester is not allowed to make this
request. For example. a peer may not be able to query statistical
information from a tracker. (this may be handled at the HTTP level
in the HTTP/XML case)
OBJECT NOT FOUND: The requested object (i.e., a swarm to be joined
or a swarm that is being searched for) cannot be found. (this may
be handled at the HTTP level in the HTTP/XML case)
AUTHENTICATION REQUIRED: Authentication is required to access this
information. (this may be handled at the HTTP level in the HTTP/
XML case).
PAYMENT REQUIRED: Payment is required to access this service.
(this may be handled at the HTTP level in the HTTP/XML case)
5. Message Syntax and Processing
These encodings are currently rather skeletal. For example, while we
offer mechanisms to encode particular chunks, we do not currently
define a mechanism to encode the position (offset) for a stream.
Until the WG has made more decisions about specific encoding, these
encodings/processing rules are provided primarily to provide a
starting point for discussion, and as such are missing some essential
features. The authors will extend (and prune, in the case of two
encodings) and refine the protocol as the WG makes specific decisions
about design of the protocol.
5.1. HTTP/XML Encoding
The current encoding is a very simple strawman encoding. Clearly,
more attention will need to be paid to the proper HTTP messages to
convey information, and to the appropriate way to encode the
information in XML. As mentioned earlier, the authors hope that an
existing XML encoding from another protocol may be able to be used in
some places.
The authors acknowledge they are not experts in either HTTP or XML,
and may have made significant mistakes in this initial encoding
attempt. As a result, this section may change dramatically in the
next version as the authors continue their research into how to use
HTTP/XML.
Gu, et al. Expires November 21, 2011 [Page 10]
Internet-Draft PPSP Tracker Protocol May 2011
For simplicity, the current proposal uses only HTTP POST as a
mechanism. Error codes from HTTP are reused when possible, with the
error conveyed in the actual HTTP message. One possible extension
would be the use of HTTP CONNECT in connection with the security
model to be defined later. This basic approach is subject to change.
5.1.1. HTTP Encoding
The format of the shared message XML body is as follows. This is not
a formal XML schema, but will be elaborated to be such at a future
date.
***
***
***
...Method specific xml information...
Figure 3: Common Message XML Header
In this representation, *** is used to represent data to be inserted.
The fields in the header are:
version: The version of the PPSP Tracker Protocol being used in the
form of a fixed point integer between 0.1 and 25.4. For the
version of the protocol described in this document, this field
MUST be set to 0.1.
Method: Indicates the method type for the message. The Method is
encoded as a string, and is case insensitive. The valid
strings are defined in Section 5.1.1.1. Only one of Method or
Response will be present in any given method -- the presence of
both constitutes an error.
Response: Indicates the response type for the message. The Response
is encoded as a string, and is case insensitive. The valid
strings are defined in Section 5.1.1.1. Only one of Method or
Response will be present in any given method -- the presence of
both constitutes an error. Some responses that are defined as
protocol responses in the binary encoding below are not present
here, as standard HTTP responses are used instead.
Transaction ID: A unique 64 bit integer that identifies the
transaction and also allows receivers to disambiguate
transactions which are otherwise identical. Responses use the
same Transaction ID as the request they correspond to. It may
be possible to a use native HTTP construct in place of this
value.
Gu, et al. Expires November 21, 2011 [Page 11]
Internet-Draft PPSP Tracker Protocol May 2011
5.1.1.1. Method Field Encoding
As discussed earlier, the PPSP Tracker Protocol uses a request-
response approach to protocol messages. Messages are either a
request, asking for an action, or a response, in reply to a request.
Message methods are transmitted using an HTTP POST, with an
appropriate XML body as defined above (and expanded per message
below).
The tables below define the valid string representations for the
requests and responses. These values MUST be treated as case-
insensitive.
+--------------+----------------------------+
| PPSP Request | PPSP Request Method String |
+--------------+----------------------------+
| CONNECT | CONNECT |
| DISCONNECT | DISCONNECT |
| JOIN | JOIN |
| JOIN_CHUNK | JOIN_CHUNK |
| LEAVE | LEAVE |
| FIND | FIND |
| KEEPALIVE | KEEPALIVE |
| STAT_QUERY | STAT_QUERY |
| STAT_REPORT | STAT_REPORT |
+--------------+----------------------------+
Table 1: Valid Strings for Requests
+----------------------+---------------------+----------------------+
| Response Method Name | HTTP Response | XML Response Value |
| | Mechanism | |
+----------------------+---------------------+----------------------+
| SUCCESSFUL (OK) | 200 OK | OK |
| INVALID SYNTAX | 400 Bad Request | INVALID SYNTAX |
| VERSION NOT | 400 Bad Request | VERSION NOT |
| SUPPORTED | | SUPPORTED |
| MESSAGE NOT | 403 Forbidden | MESSAGE NOT |
| SUPPORTED | | SUPPORTED |
| TEMPORARILY | 503 Service | TEMPORARILY |
| OVERLOADED | Unavailable | OVERLOADED |
| INTERNAL ERROR | 500 Internal Server | INTERNAL ERROR |
| | Error | |
| MESSAGE FORBIDDEN | 403 Forbidden | MESSAGE FORBIDDEN |
| OBJECT NOT FOUND | 404 Not Found | OBJECT NOT FOUND |
| AUTHENTICATION | 401 Unauthorized | AUTHENTICATION |
| REQUIRED | | REQUIRED |
Gu, et al. Expires November 21, 2011 [Page 12]
Internet-Draft PPSP Tracker Protocol May 2011
| PAYMENT REQUIRED | 402 Payment | PAYMENT REQUIRED |
| | Required | |
+----------------------+---------------------+----------------------+
Table 2: Method Field Encodings for Responses
Note that many responses are included in 400 Bad Request bodies, as
these are errors within the XML/PPSP protocol messages, not HTTP
itself, and as such, responses such as 405 Method Not Allowed are not
appropriate. (the device supports POST, but not the particular PPSP
XML body included)
5.1.2. Common Message Processing
When a PPSP Tracker Protocol message is received, some basic
processing is performed, regardless of the message type or the type
of receiver (tracker or peer).
Upon receiving a message, the message is examined to ensure that the
message is properly formed. The receiver MUST check that the HTTP
message itself is properly formed, and if not appropriate standard
HTTP errors MUST be generated. The receiver must verify that the XML
payload is properly formed. If the message is found to be
incorrectly formed or the length does not match the length encoded in
the common header, the receiver MUST reply with an HTTP 400 response
with a PPSP XML payload with the Response attribute set to INVALID
SYNTAX.
The common message XML MUST be examined to obtain the version number
of the message. In the event that the version number is for a
version the receiver does not support, the receiver MUST reply with
an HTTP 400 response with a PPSP XML payload with the Response
attribute set to VERSION NOT SUPPORTED.
The common message XML MUST be examined to obtain the message type of
the message. In the event the message listed is not supported by the
receiver, the receiver MUST reply with an HTTP 400 response with a
PPSP XML payload with the Response attribute set to MESSAGE NOT
SUPPORTED.
If the receiver is unable to process the message at this time because
it is in an overloaded state, the receiver SHOULD reply with an HTTP
503 response with a PPSP XML payload TEMPORARILY OVERLOADED.
If the receiver encounters an internal error while attempting to
process the message, the receiver MUST generate an HTTP 500 response
with a PPSP XML payload INTERNAL ERROR message indicating this has
occurred.
Gu, et al. Expires November 21, 2011 [Page 13]
Internet-Draft PPSP Tracker Protocol May 2011
5.1.3. CONNECT Messages
The CONNECT message is sent when a peer wishes to join a system and
connect to the tracker. Note that a peer must have obtained a
Peer-ID via an out-of-band mechanism. The CONNECT procedure follows
the general rules described below:
1) A CONNECT message is sent from the new peer to the tracker,
indicating the desire to connect;
2) A response is generated by the tracker indicating success,
failure, or some condition that must be satisfied to succeed (for
example, providing credentials).
5.1.3.1. Forming and Sending a CONNECT Message
CONNECT message is sent from peer to tracker. To form a CONNECT
Message, the sender constructs the common message XML. The sender
MUST properly form the XML, set the Method attribute to CONNECT, and
randomly generate and set the Transaction ID.
The method specific XML of the CONNECT message takes the form shown
below:
***
***
The PeerID of the body MUST be set to the PeerID of the peer. If
authentication is required in the P2P streaming application, a
certification is also carried in CONNECT message. This reports that
the peer is connecting.
5.1.3.2. Recieving and Processing a CONNECT Message
When receive a CONNECT message, the tracker records the peer as a
connected peer. The tracker may authenticate the peer to check
whether this is a valid peer that can be connected to the tracker. A
response with corresponding response value will be generated to
indicate whether the peer has successfuly connected to the tracker.
5.1.4. DISCONNECT Messages
5.1.4.1. Forming and Sending a DISCONNECT Message
DISCONNECT message is sent from peer to tracker. To form a
DISCONNECT Message, the sender constructs the common message XML.
The sender MUST properly form the XML, set the Method attribute to
DISCONNECT, and randomly generate and set the Transaction ID.
Gu, et al. Expires November 21, 2011 [Page 14]
Internet-Draft PPSP Tracker Protocol May 2011
The method specific XML of the DISCONNECT message takes the form
shown below:
***
***
Figure 4: DISCONNECT Method Specific XML
The PeerID of the body MUST be set to the PeerID of the peer. If
authentication is required in the P2P streaming application, a
certification is also carried in DISCONNECT message.This reports that
the peer is disconnecting, and implicitly informs the tracker that
the peer is no longer involved in any swarms.
5.1.4.2. Recieving and Processing a DISCONNECT Message
Upon receiving a DISCONNECT message, the tracker MUST remove the peer
from the peer list. It will honor no more requests from the peer
unless the peer CONNECTs again. In addition, it will not provide the
peer in response to GETs in the future. The tracker MUST remove the
peer from all swarms as if a LEAVE was received for each swarm in
which the peer is currently participating.
One consequence of this design is that you will need to have a
mapping of what swarms the peer is in, so that you can remove it from
all those swarm lists (assuming that a local index of swarms->peers
is stored, which for fast lookup seems essential.
5.1.5. JOIN and JOIN_CHUNK Messages
The JOIN messages (JOIN and JOIN_CHUNK) are used by the Peer to
inform the Tracker that it would like to participate in a particular
swarm, and optionally what portions of that swarm it has available.
JOIN is used when the Peer has some chunks or wishes to join a live
stream, but does not provide the list of chunks or location in the
stream to the tracker (i.e., gossip is used between peers to exchange
the chunk list/stream position or it simply joins at the current
position). JOIN_CHUNK is used when the peer wishes to provide a
detailed list of chunks in the stream to the tracker.
5.1.5.1. Forming and Sending a JOIN Message
JOIN message is sent from peer to tracker. To form a JOIN Message,
the sender constructs the common message XML. The sender MUST
properly form the XML, set the Method attribute to JOIN, and randomly
generate and set the Transaction ID.
The method specific XML of the JOIN message takes the form shown
Gu, et al. Expires November 21, 2011 [Page 15]
Internet-Draft PPSP Tracker Protocol May 2011
below:
***
***
***
Figure 5: JOIN Method Specific XML
The PeerID of the body MUST be set to the PeerID of the peer, and
SwarmID MUST be set to the SwarmID of the swarm the peer is
interested in. Expiration Time MAY be set to some non-zero value in
seconds, indicating that the peer expects to no longer be
participating at the end of the time. If the peer does not wish to
set an Expiration Time, this field MUST be set to zero.
5.1.5.2. Forming and Sending a JOIN_CHUNK Message
JOIN_CHUNK message is sent from peer to tracker. To form a
JOIN_CHUNK Message, the sender constructs the common message XML.
The sender MUST properly form the XML, set the Method attribute to
JOIN_CHUNK, and randomly generate and set the Transaction ID.
When implementing JOIN_CHUNK, one may wonder how often shall a peer
notify the tracker of its chunk availability. Shall a peer report
every single chunk as soon as it is received, or report periodically?
In real-time reporting, both the peer and the tracker will be busy
processing JOIN_CHUNK message and responses. In periodic reporting,
the period should be configured carefully, or the peer may not
operate efficiently.
In a VOD swarm or live streaming, a peer will keep receiving
continuous chunks of a designated swarm. After a peer JOIN_CHUNKs a
first chunk, the tracker can communicate which chunks are currently
stored in the peer, according to the caching size and time difference
between JOIN_CHUNK and current time. For example, a peer join chunk
A, and the join time is time A. The peer won't send any JOIN_CHUNK
message afterwards. When other peers want to get chunk B at time B,
tracker can calculate by (time B - Time A) /length-of-a-chunk + chunk
A. Tracker will know whether the peer has cached chunk B. The
calculation mechanism may be different at different application,
because applications may have various ways to define chunks. But
dynamically JOIN_CHUNK can help to reduce load on tracker and peer.
The method specific XML of the JOIN_CHUNK message takes the form
shown below:
Gu, et al. Expires November 21, 2011 [Page 16]
Internet-Draft PPSP Tracker Protocol May 2011
***
***
***
***
***
***
***
... more chunk IDs ...
Figure 6: JOIN_CHUNK Method Specific XML
As with the JOIN_CHUNK message, the PeerID of the body MUST be set to
the PeerID of the peer, and SwarmID MUST be set to the SwarmID of the
swarm the peer is interested in. Expiration Time MAY be set to some
non-zero value in seconds, indicating that the peer expects to no
longer be participating at the end of the time. If the peer does not
wish to set an Expiration Time, this field MUST be set to zero.
Dynamic of the body MAY be set to indicate the peer would share the
chunks start with the chunk ID in the message, and won't send
JOIN_CHUNK again, but tracker can calculate which chunks the peer can
share at a specific time. Systemtime indicates the time the peer
gets the start chunk. Caching length indicates the size of cache for
this specific swarm on sender. Following these fields, one or more
32 bit ChunkID fields MAY be provided, if the peer would share chunks
that are beyond the chunk indicated in Dynamic part of the message.
5.1.5.3. Recieving and Processing a JOIN or JOIN_CHUNK Message
When a JOIN or JOIN_CHUNK Message is received, the tracker will
process the request. The tracker MAY reject the request using one of
the error codes in Table 2. If the tracker accepts the message, it
MUST verify the fields are properly formed (including any
continuation messages for JOIN_CHUNK messages) and MUST reject the
message with an HTTP 400 response with a PPSP XML payload INVALID
SYNTAX indicating this has occurred. If the message is well formed
and accepted, the tracker enters the information into the internal
data store, and respond with an HTTP 200 OK SUCCESS message response
with a PPSP XML payload SUCCESSFUL.
The response MUST have the same Transaction ID as the request, and
MUST not contain any additional body information.
Gu, et al. Expires November 21, 2011 [Page 17]
Internet-Draft PPSP Tracker Protocol May 2011
5.1.6. LEAVE Messages
The LEAVE message is used by the Peer to inform the Tracker that it
no longer wishes to participate in a particular swarm.
5.1.6.1. Forming and Sending a LEAVE Message
LEAVE message is sent from peer to tracker. To form a LEAVE Message,
the sender constructs the common message XML. The sender MUST
properly form the XML, set the Method attribute to LEAVE, and
randomly generate and set the Transaction ID. The method specific
information formed as discussed below.
The method specific XML of the LEAVE message takes the form shown
below:
***
***
Figure 7: LEAVE Method Specific XML
The PeerID of the body MUST be set to the PeerID of the peer, and
SwarmID MUST be set to the SwarmID of the swarm the peer is no longer
interested in participating in.
5.1.6.2. Recieving and Processing a LEAVE Message
When a LEAVE Message is received, the tracker will process the
request. The tracker MAY reject the request using one of the error
codes in Table 2. If the tracker accepts the message, it MUST verify
the fields are properly formed (including any continuation messages
for JOIN_CHUNK messages) and MUST reject the message with an HTTP 400
response with a PPSP XML payload INVALID SYNTAX indicating this has
occurred. If the message is well formed and accepted, the tracker
will remove the peer from the list of peers participating in a
particular swarm and will respond with an HTTP 200 OK SUCCESS message
response with a PPSP XML payload SUCCESSFUL. The tracker does not
notify other peers in the swarm that the peer has left -- this
functionality is left for the peer protocol.
The response MUST have the same Transaction ID as the request, and
MUST not contain any additional body information.
Gu, et al. Expires November 21, 2011 [Page 18]
Internet-Draft PPSP Tracker Protocol May 2011
5.1.7. FIND Messages
5.1.7.1. Forming and Sending a FIND Message
FIND message is sent from peer to tracker. To form a FIND Message,
the sender constructs the common message XML. The sender MUST
properly form the XML, set the Method attribute to FIND, and randomly
generate and set the Transaction ID.
The method specific XML of the FIND message takes the form shown
below:
***
***
***
***
***
... more stats ...
Figure 8: FIND Method Specific XML
The PeerID of the body MUST be set to the PeerID of the peer, and
SwarmID MUST be set to the SwarmID of the swarm the peer is
interested in obtaining chunks from. Chunk ID MAY be set to a
particular chunk, and if set, the tracker will only return peers
having chunks with this ID and higher value. If the peer is
interested in any chunks, the peer MUST set the value of the Chunk ID
to all zero. Peernum MAY be set to indicate how many peers in the
peerlist the requesting peer would like tracker to provide. It's set
to zero if requesting peer has no preference on peer number. Status
MAY be set to indicate the requesting peer's requirements to the
property of peers that can share the specific content. One or more
Stat attributes are provided, with a property field corresponding to
the data as described in . (Table 3)
5.1.7.2. Recieving and Processing a FIND Message
When a FIND Message is received, the tracker will process the
request. The tracker MAY reject the request using one of the error
codes in Table 2. If the tracker accepts the message, it MUST verify
the fields are properly formed and MUST reject the message with an
HTTP 400 response with a PPSP XML payload INVALID SYNTAX indicating
this has occurred. If the message is well formed and accepted, the
tracker will search the internal data store for the requested data
Gu, et al. Expires November 21, 2011 [Page 19]
Internet-Draft PPSP Tracker Protocol May 2011
and if found will respond the requesting peer with an HTTP 200 OK
SUCCESS message response with a PPSP XML payload SUCCESSFUL, as well
as the peerlist with ID and IP Addresses of peers that can provide
the specific content. If Status filed is indicated, based on peers'
property that has been recorded on tracker and the property
requiremnts indicated in request message, tracker will choose peers
that can provide the specific content and satisfy the property
requirement set by requesting peers.If the data is not found an HTTP
404 will be generated with the PPSP XML Response set to OBJECT NOT
FOUND.
The response MUST have the same Transaction ID as the request
The FIND response MUST include an XML payload of the form below:
***
***
Peer list (SEE BELOW)
Figure 9: FIND Response XML
The SwarmID MUST be set to the swarm to which the chunks belong. The
ChunkID May be set to indicate the specific chunk. If ChunkID is
set, it means that the peers in the peerlist can provide the specific
chunk.
The peer list consists of a list of peers, identified by of peers. Requesting peers can request and obtain
specific content from peers listed in peerlist, according to the
Peer-IDs or IP addresses.
5.1.8. KEEPALIVE Messages
5.1.8.1. Forming and Sending a KEEPALIVE Message
KEEPALIVE message is sent from peer to tracker. To form a KEEPALIVE
Message, the sender constructs the common message XML. The sender
MUST properly form the XML, set the Method attribute to KEEPALIVE,
and randomly generate and set the Transaction ID.
The method specific XML of the KEEPALIVE message takes the form shown
below:
Gu, et al. Expires November 21, 2011 [Page 20]
Internet-Draft PPSP Tracker Protocol May 2011
***
Figure 10: KEEPALIVE Method Specific XML
The PeerID of the body MUST be set to the PeerID of the peer.
5.1.8.2. Recieving and Processing a KEEPALIVE Message
When tracker receives a KEEPALIVE message, it should update an
internal timer to indicate that the tracker has heard from the peer.
5.1.9. STAT Messages
There are two types of STAT Messages. STAT_REPORT messages are used
to report statistics information, and STAT_QUERY messages are used to
request information.
5.1.9.1. Property Types for STAT Messages
The following statistics are listed as examples of information that
might be useful, and we define example type values here. As the
protocol firms up, we will likely want to reconsider these and add to
them or remove.
+------------------+------------------------------------------------+
| XML Value | Definitions/Description |
+------------------+------------------------------------------------+
| CachingSize | Caching size: available size for caching |
| Bandwidth | Bandwidth: available bandwidth |
| LinkNumber | Link number: acceptable links for remote peer |
| Certificate | Certificate: certificate of the peer |
| NAT | NAT/Firewall: peer believes it is behind NAT |
| | (Boolean Value) |
| STUN | STUN: peer supports STUN service (Boolean |
| | Value) |
| TURN | TURN: peer supports TURN service (Boolean |
| | Value) |
| SumBytes | Sum Volume: Sum of bytes of data peers |
| | received from the steaming system |
| AccessMode | Access Mode: ADSL/Fiber/GPRS/3G/LTE/WiFi etc. |
| EndDevice | End Device: STB/PC/MobilePhone |
| AvailableBattery | Available Battery Level |
+------------------+------------------------------------------------+
Table 3: Sample Property Types for STAT messages
Gu, et al. Expires November 21, 2011 [Page 21]
Internet-Draft PPSP Tracker Protocol May 2011
5.1.9.2. Forming and Sending a STAT_REPORT Message
STAT_REPORT message is sent from peer to tracker. To form a
STAT_REPORT Message, the sender constructs the common message XML.
The sender MUST properly form the XML, set the Method attribute to
STAT_REPORT, and randomly generate and set the Transaction ID.
The method specific XML of the STAT_REPORT message takes the form
shown below:
###
***
... more stats ...
Figure 11: STAT_REPORT Method Specific XML
The PeerID of the body MUST be set to the PeerID of the peer.
Following this field, one or more Stat attributes are provided, with
a property field corresponding to the data as described in Table 3
and an appropriate value provided.
5.1.9.3. Recieving and Processing a STAT_REPORT Message
In addition to normal processing rules, when a Tracker receives a
STAT_REPORT message, it MAY process the message and store the
statistical information for future use. The response MUST contain
the same Transaction ID as the request.
5.1.9.4. Forming and Sending a STAT_QUERY Message
STAT_QUERY message is sent from tracker to peer. To form a
STAT_QUERY Message, the sender constructs the common message XML.
The sender MUST properly form the XML, set the Method attribute to
STAT_QUERY, and randomly generate and set the Transaction ID.
The method specific XML of the STAT_QUERY message takes the form
shown below:
... more stats ...
Gu, et al. Expires November 21, 2011 [Page 22]
Internet-Draft PPSP Tracker Protocol May 2011
Figure 12: STAT_QUERY Method Specific XML
Each Stat in the StatRequest MUST have the property set as defined in
Table 3 and MUST NOT have any value.
5.1.9.5. Recieving and Processing a STAT_QUERY Message
When a STAT_QUERY message is received by the peer, it MUST respond,
using one of the response codes defined above. The body contains one
value each requested statistic:
###
***
... more stats ...
Figure 13: STAT_QUERY Response Method Specific XML
The PeerID of the body MUST be set to the PeerID of the peer.
Following this field, one or more Stat attributes are provided, with
a property field corresponding to the data as described in Table 3
and an appropriate value provided.
6. Security Considerations
P2P streaming systems are subject to attacks by malicious/unfriendly
peers/trackers that may eavesdrop on signaling, forge/deny
information/knowledge about streaming content and/or its
availability, impersonating to be another valid participant, or
launch DoS attacks to a chosen victim.
No security system can guarantees complete security in an open P2P
streaming system where most of its participants are malicious or not
cooperating. The goal of security considerations described here is
to provide sufficient protection for maintaining some security
properties during the tracker-peer communication even in the face of
a large number of malicious peers and/or distrustful trackers under
the distributed deployment scenario.
6.1. Authentication between communicating tracker and peers
To protect signaling from impersonation attackers, who pretend to be
another peer rather than their authentic identities, certificates
Gu, et al. Expires November 21, 2011 [Page 23]
Internet-Draft PPSP Tracker Protocol May 2011
along with TLS/DTLS could be used to ensure that each message is sent
from an authorized participant (tracker or peer) of the P2P streaming
system.
Specifically, when a peer enrolls in the system, a centralized
enrollment server can help to issue a valid peer/tracker certificate.
The enrollment server is expected to choose a proper PEER_ID for the
requestor and certify the provided public key to the chosen PEER_ID
in the form of a peer certificate. But the specification of
enrollment and PEER_ID and certificate is out of scope in this draft.
6.2. Signaling protection between communicating tracker and peers
To prevent signaling eavesdropping and manipulation, each message/
response between a peer and its connected tracker is confidentiality/
integrity protected by symmetric keys negotiated through TLS/DTLS
mechanisms along with the authentication procedure during the earlier
CONNECT operation.
6.3. Content Integrity protection against polluting peers/trackers
Malicious peers may declaim ownership of popular content to the
tracker and serve polluted (i.e. decoy content or even virus instead
of authentic content) later to other peers. This kind of pollution
can be detected by incorporating a checksum distribution scheme for
published sharing content. As content chunks of the same content are
transferred independently and concurrently, correspondent chunk-level
checksums MUST be distributed from an authentic origin.
6.4. Residual attacks and mitigation
To mitigate the impact of sybil attacker, impersonating a large
number of valid participants by repeatedly acquiring different peer
certificates, the enrollment server SHOULD carefully regulate the
rate of peer/tracker admission.
There is no guarantee that a peer honestly report its status to the
tracker, or server authentic content to other peers as it claims to
the tracker. It is expected that a global trust mechanism, where
each peer's credit is accumulated from evaluations for previous
transactions and taken into account by other peers when selecting
partner for future transactions, is helpful to mitigate the impact of
such malicious behaviors. Globally trusted tracker MAY take part of
the trust mechanism by collecting evaluations, computing credit
values and providing them to joining peers through JOIN responses.
Gu, et al. Expires November 21, 2011 [Page 24]
Internet-Draft PPSP Tracker Protocol May 2011
7. Acknowledgments
We would like to acknowledgments to the following for their help and
comments: Zhang Yunfei, Liao Hongluan, Roni Even, Bhumip Khasnabish,
Wu Yichuan, Peng Jin, Chi Jing, Zong Ning, Song Haibin, Chen wei,
Zhijia Chen, Christian Schmidt, Lars Eggert, David Harrington,
Henning Schulzrinne, and Kangheng Wu.
The fragmentation mechanism used in the binary protocol proposal, and
some text describing it, was borrowed from [I-D.ietf-p2psip-base].
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", April 2010.
8.2. Informative References
[I-D.ietf-ppsp-problem-statement]
Zhang, Y., Zong, N., Camarillo, G., Seng, J., and R. Yang,
"PPSP Problem Statement".
[I-D.ietf-ppsp-survey]
Yingjie, G., Zong, N., Zhang, H., Zhang, Y., Lei, J.,
Camarillo, G., and L. Yong, "Survey of P2P Streaming
Applications", draft-gu-ppsp-survey-02 (work in progress),
March 2011.
[I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-12 (work in
progress), November 2010.
[I-D.ietf-ppsp-reqs]
Zong, N., Zhang, Y., Avila, V., Williams, C., and L. Xiao,
"P2P Streaming Protocol (PPSP) Requirements",
draft-zong-ppsp-reqs-04 (work in progress), February 2011.
[I-D.gu-ppsp-peer-protocol]
Yingjie, G. and D. Bryan, "Peer Protocol",
Gu, et al. Expires November 21, 2011 [Page 25]
Internet-Draft PPSP Tracker Protocol May 2011
draft-gu-ppsp-peer-protocol-01 (work in progress),
October 2010.
Authors' Addresses
Gu Yingjie
Huawei
Phone: +86-25-56624760
Fax: +86-25-56624702
Email: guyingjie@huawei.com
David A. Bryan
Cogent Force, LLC
P.O. Box 6741
Williamsburg, Virginia 23188
United States of America
Phone: +1.571.314.0256
Email: dbryan@ethernot.org
Deng Lingli
China Mobile
Phone:
Email: denglingli@chinamobile.com
Gu, et al. Expires November 21, 2011 [Page 26]