PPSP Rui S. Cruz
INTERNET-DRAFT IST/INESC-ID/INOV
Intended Status: Informational Mario S. Nunes
Expires: December 22, 2011 IST/INESC-ID/INOV
Joao P. Taveira
IST/INOV
June 20, 2011
HTTP-based PPSP Tracker Protocol
draft-cruz-ppsp-http-tracker-protocol-00
Abstract
This document presents a proposal for an HTTP-based P2P streaming
Peer Protocol, outlining the requirements, functional entities,
message flows, formal syntax and semantics, with detailed message
processing instructions using an HTTP/XML encoding, the respective
parameters, methods, and message formats. The PPSP Peer Protocol
proposed in this document extends the capabilities of PPSP to support
adaptive and scalable video and 3D video, for Video On Demand (VoD)
and Live video services.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Cruz, et al. Expires December 22, 2011 [Page 1]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
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
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Streaming Modes . . . . . . . . . . . . . . . . . . . . . . 10
3.5 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . 11
3.6 Manifest File . . . . . . . . . . . . . . . . . . . . . . . 11
4 Messages syntax and processing . . . . . . . . . . . . . . . . 14
4.1 HTTP/XML Encoding . . . . . . . . . . . . . . . . . . . . . 14
4.2 Method Fields . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Message Processing . . . . . . . . . . . . . . . . . . . . 16
4.4 CONNECT Message . . . . . . . . . . . . . . . . . . . . . . 17
4.5 DISCONNECT message . . . . . . . . . . . . . . . . . . . . 18
4.6 JOIN Message . . . . . . . . . . . . . . . . . . . . . . . 19
4.7 LEAVE Message . . . . . . . . . . . . . . . . . . . . . . . 20
4.8 FIND_PEER Message . . . . . . . . . . . . . . . . . . . . . 21
4.9 FIND_CHUNK Message . . . . . . . . . . . . . . . . . . . . 23
4.10 STAT_REPORT Message . . . . . . . . . . . . . . . . . . . 25
4.11 KEEPALIVE Message . . . . . . . . . . . . . . . . . . . . 28
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 29
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 29
7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 29
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.1 Normative References . . . . . . . . . . . . . . . . . . . 30
8.2 Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Cruz, et al. Expires December 22, 2011 [Page 2]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
1 Introduction
The P2P Streaming Protocol (PPSP) is composed of two protocols: the
PPSP Tracker Protocol and the PPSP Peer Protocol
[I-D.ietf-ppsp-problem-statement].
The PPSP Peer protocol controls the advertising and exchange of media
data directly between peers.
The PPSP Tracker Protocol provides communication between Trackers and
Peers, by which Peers exchange meta information with trackers, report
streaming status and request candidate lists from trackers.
The PPSP architecture requires PPSP peers able to communicate with a
tracker in order to participate in a particular swarm. This
centralized tracker service is used for peer bootstrapping and for
content registration and location. Content indexes (manifest files)
are also stored in the tracker system allowing the association of
content location information to the active peers sharing the content
in the swarm.
The EU research project SARACEN (Socially Aware, collaboRative,
scAlable Coding mEdia distributioN) is developing an innovative P2P
architecture that targets the optimization of the Quality of
Experience in personalized media streaming, through the integration
of scalable media coding and multi view coding techniques, and with
respect to user privacy [refs.saracenwebpage].
The process used for streaming distribution in SARACEN relies on a
chunk transfer scheme whereby the original content is re-encoded
using adaptive or scalable techniques and then chopped into small
video chunks with a short duration:
1. (adaptive) - alternate versions with different qualities and
bitrates;
2. (scalable description levels) - multiple additive descriptions
(i.e., addition of descriptions refine the quality of the video);
3. (scalable layered levels) - nested dependent layers corresponding
to several hierarchical levels of quality, i.e., higher
enhancement layers refine the quality of the video of lower
layers.
4. (scalable multi views) - views correspond to 2D and to
stereoscopic 3D videos, with several hierarchical levels of
quality.
These streaming distribution techniques support dynamic variations in
video streaming quality while ensuring support for a plethora of end
user devices and network connections.
Cruz, et al. Expires December 22, 2011 [Page 3]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
The signaling and the media transfer between PPSP peers in SARACEN is
done using a request/reply mechanism as defined in HTTP-based PPSP
Peer Protocol [I-D.cruz-ppsp-http-peer-protocol].
The HTTP-based PPSP Tracker Protocol used in SARACEN and presented in
this draft follows the design defined in PPSP Tracker protocol
[I-D.gu-ppsp-tracker-protocol], but extending the capabilities of
PPSP to support adaptive and scalable video.
The goal of this draft is to derive from the work being developed in
the SARACEN Project the implications for the standardization of the
PPSP streaming protocols, believed as important inputs to the IETF
PPSP working group, in order to identify open issues and promote
further discussion. [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 RFC 2119 [RFC2119].
This draft uses the terms defined in
[I-D.ietf-ppsp-problem-statement] and in
[I-D.gu-ppsp-tracker-protocol].
Absolute Time: Absolute time is expressed as ISO 8601 [ISO.8601.2004]
timestamps, using zero UTC offset (GMT). Fractions of a second may
be indicated. Example for December 25, 2010 at 14h56 and 20.25
seconds: basic format 20101225T145620.25Z or extended format
2010-12-25T14:56:20.25Z.
Adaptive Streaming: multiple alternate versions (different qualities
and bitrates) of the same media content co-exist for the same
streaming session; each alternate version corresponds to a different
media quality level; peers can choose among the alternate versions
for decode and playback.
Base Layer: the playable level in Scalable Video Coding (SVC)
required by all upper level Enhancements Layers for proper decoding
of the video.
Chunk: A chunk is a basic unit of partitioned streaming media, which
is used by a peer for the purpose of storage, advertisement and
exchange among peers.
Enhancement Layer: enhancement differential quality level in Scalable
Video Coding (SVC) used to produce a higher quality, higher
definition video in terms of space (i.e., image resolution), time
Cruz, et al. Expires December 22, 2011 [Page 4]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
(i.e., frame rate) or Signal-to-Noise Ratio (SNR) when combined with
the playable Base Layer.
Live streaming: The scenario where all clients receive streaming
content for the same ongoing event. The lags between the play points
of the clients and that of the streaming source are small.
Manifest: The manifest file holds information about the content,
i.e., describes the structure of the media, namely, the codecs used,
the chunks, and the corresponding mapping within a container file
system.
Peer: A peer refers to a participant in a P2P streaming system that
not only receives streaming content, but also stores and uploads
streaming content to other participants.
PeerID: Unique identifier for the peer. The PeerID and any required
security certificates are obtained from an offline enrollment server.
Peer-Peer Messages (i.e., Peer Protocol): The Peer Protocol messages
enable each Peer to exchange content availability with other Peers
and request other Peers for content.
PPSP: The abbreviation of P2P Streaming Protocols. PPSP protocols
refer to the key signaling protocols among various P2P streaming
system components, including the tracker and peers.
Scalable Streaming: With Multiple Description Coding (MDC), multiple
additive descriptions (that can be independently played-out) to
refine the quality of the video when combined together. With Scalable
Video Coding (SVC), nested dependent enhancement layers (hierarchical
levels of quality), refine the quality of lower layers, from the
lowest level (the playable Base Layer).
Swarm: A swarm refers to a group of clients (i.e., peers) sharing the
same content (e.g., video/audio program, digital file, etc.) at a
given time.
SwarmID: Unique identifier for a swarm. It is used to describe a
specific resource shared among peers.
Tracker: A tracker refers to a directory service which maintains the
lists of PPSP peers storing chunks for a specific channel or
streaming file, and answers queries from PPSP peers.
Tracker-Peer Messages (i.e., Tracker Protocol): The Tracker Protocol
messages provide communication between Peers and Trackers, by which
Peers provide content availability, report streaming status and
Cruz, et al. Expires December 22, 2011 [Page 5]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
request candidate Peer lists from Trackers.
UserID: Unique identifier for the peer client user. The UserID and
any required security certificates or Tokens are obtained from an
offline enrollment server.
Video-on-demand (VoD): A kind of application that allows users to
select and watch video content on demand.
3. Protocol Overview
The function entities involved in the PPSP Tracker Protocol are
Trackers and Peers (which may support different capabilities).
Peers are organized in (various) swarms corresponding each swarm to
the group of peers sharing a content at any given time.
The Tracker is a logical entity that maintains the lists of peers
storing chunks for a specific channel or streaming file, answers
queries from peers and collects information on the activity of peers.
The tracker protocol is not used to exchange actual content data
(either VoD or Live streaming) with peers, but information about
which peers can provide which pieces of content.
A P2P streaming process is summarized in Figure 1.
When a peer wants to receive streaming of a selected content:
1. Peer connects to a tracker and joins a swarm.
2. Peer acquires a list of peers from the tracker.
3. Peer exchanges its content availability with the peers on the
obtained peer list.
4. Peer identifies the peers with desired content.
5. Peer requests for the content from the identified peers.
When a peer wants to share streaming of certain content with others:
1. Peer connects to the tracker.
2. Peer sends information to the tracker about the swarm it belongs
to (joins), plus streaming status and/or content availability.
Cruz, et al. Expires December 22, 2011 [Page 6]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
+-----------------------------------+
| Tracker |
+-----------------------------------+
^ | ^
connect/ | | |
join/ | | peer list |streaming Status/
find/ | | |Content availability/
leave/ | | |node capability
disconnect | V |
+-------------+ +------------+
| Peer 1 |<------------->| Peer 2 |
+-------------+ content info/ +------------+
data requests
Figure 1: A PPSP streaming process
The PPSP Tracker Protocol is a request-response protocol. Requests
are sent, and responses returned to these requests. A single request
generates a single response (neglecting fragmentation of messages).
The specific operations of the protocol at present, are (names
correspond to Method strings):
1. CONNECT
2. DISCONNECT
3. JOIN
4. LEAVE
5. FIND_PEER
6. FIND_CHUNK
7. STAT_REPORT
8. KEEPALIVE
CONNECT: This method is used when a Peer connects to the system. The
Service Tracker records the Peer-ID, connect-time (referenced to the
absolute time), peer IP address and link status.
DISCONNECT: This method is used when the Peer intends to leave the
system and no longer participate in any swarm. The Service Tracker
deletes the corresponding activity records related to the peer
(including its status and all content status for all swarms) updating
the information on the historical profile record of that peer.
JOIN: This method is used for Peers to notify the Service Tracker
that they wish to participate in a particular swarm.
LEAVE: This method is used when Peers want to indicate to the Service
Tracker that they no longer wish to participate in a particular
swarm.
Cruz, et al. Expires December 22, 2011 [Page 7]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
FIND_PEER: This method allows Peers to request to the Service Tracker
the Peer list for a specific content or a particular swarm.
FIND_CHUNK: This method allows Peers to request to the Service
Tracker the Peer list for a specific Chunk of a particular swarm.
STAT_REPORT: This method allows the exchange of statistic and status
data between Peers and Service Tracker to improve system performance.
The method is initiated by the peer, periodically.
KEEPALIVE: These messages are periodically sent from Peers to the
Service Tracker to notify it that the Peer is still alive, to prevent
the Service Tracker from disconnecting the Peer, after some pre-
configured time (assume that the Peer is no longer available).
The Response messages correspond to a number of logical responses
common to the Tracker or the Peer protocols request messages.
Incorrectly formatted XML request bodies are handled by the HTTP
protocol itself and reported in an HTTP message.
At present, the minimum set of response messages for the PPSP
Streaming Protocols is the following, re-using the error codes from
HTTP conveyed in the actual HTTP message:
SUCCESSFUL (200 OK): a message has been processed properly and the
desired operation has completed. If the message is a request for
information, the body of the message will also include the requested
information.
INVALID SYNTAX (400 Bad Request): Indicates an error in the format of
the message/message body. These responses correspond to errors within
the XML/PPSP protocol messages, not HTTP.
VERSION NOT SUPPORTED (400 Bad Request): Invalid version of the
protocol or message bodies. These responses correspond to errors
within the XML/PPSP protocol messages, not HTTP.
AUTHENTICATION REQUIRED (401 UNAUTHORISED): Authentication is
required to access this information.
MESSAGE FORBIDDEN (403 FORBIDDEN): The requester is not allowed to
make this request.
OBJECT NOT FOUND (404 NOT FOUND): The requested object or a swarm
that is being searched for cannot be found.
INTERNAL ERROR (500 INTERNAL SERVER ERROR): The server was unable to
process the request due to an internal error.
Cruz, et al. Expires December 22, 2011 [Page 8]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
TEMPORARILY OVERLOADED (503 SERVICE UNAVAILABLE): The server is
unable to process this message at this time.
3.1 Assumptions
The function entities related to PPSP protocols are the Client Media
Player, the service Portal, the Service Tracker and Peers. Their
complete description is not discussed in this document (as not in the
scope of this specification).
The Client Media Player is the entity providing a direct interface to
the end user at the client device, and includes the functions to
select, request, decode and render contents. In PPSP the Client Media
Player interfaces with the peer using request and response standard
formats for HTTP Request and Response messages [RFC2616].
The service Portal is a logical entity typically used for client
enrollment and content information publishing, searching and
retrieval.
The Service Tracker is a logical entity that maintains the lists of
PPSP active peers storing and exchanging chunks for a specific
content. The tracker also stores the status of peers, to help in the
selection of appropriate candidate peers for a requesting peer.
The Peer is also a logical entity embedding the P2P core engine, with
a client serving side interface (a proxy HTTP server) to respond to
Client Media Player requests and a network side interface (also an
HTTP server) to exchange data and PPSP signaling with peers and
trackers.
3.2 Bootstrapping
In order to join an existing P2P streaming service and to participate
in content sharing, any peer must first locate a Tracker service,
using for example, the following methods (as illustrated in
Figure 2):
1. From a service provider provisioning mechanism: this is a typical
case used on the provider Super-Seeders (edge caches and/or Media
Servers).
2. From a web page: a Publishing and Searching Portal may provide
tracker location information to end users
3. From the Manifest file of a content: this metainfo file must
contain information about the address of one or more trackers
controlling the swarm for that content.
In order to be able to bootstrap, a peer must first obtain a PeerID
Cruz, et al. Expires December 22, 2011 [Page 9]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
and any required security certificates from an enrollment service
(user registration).
+--------+ +--------+ +--------+ +---------+ +--------+
| Player | | Peer 1 | | Portal | | Tracker | | Peer 2 |
+--------+ +--------+ +--------+ +---------+ +--------+
| | | | |
| Page request | | | |
|------------------------------->| | |
| Page with links | | |
|<-------------------------------| | |
| Select stream | | |
|------------------------------->| | |
| Manifest | | |
|<-------------------------------| | |
| Manifest | CONNECT | | |
|--------------->|----------------------------->| |
| |<-------------------------OK--| |
| | JOIN | |
| |----------------------------->| |
| |<-------------------------OK--| |
| | GET_PEERS | |
| |----------------------------->| |
|<-----------OK--|<----------------OK Peerlist--| |
| | | | |
| GET (Chunk) | GET_CHUNK | | |
|--------------->|----------------------------------------->|
| Chunk | | |
|<---------------|<-------------------------------OK Chunk--|
| | | | |
Figure 2: A typical PPSP bootstrap procedure
3.3 Streaming Modes
The streaming technique is pull-based, i.e., the client peer requests
the media chunks from serving peers and is responsible for handling
the buffering that is necessary for the playback processes during the
download of the media chunked files, turning this technique more
robust to peer churn but still with acceptable latency for a smooth
play-out.
In Live streaming, all peers are interested in the media coming from
an ongoing program, which means that all peers share nearly the same
streaming content at a given point of time. Peers may store the live
media for further distribution (known as time-shift TV), where the
stored media is distributed in a VoD-like manner.
Cruz, et al. Expires December 22, 2011 [Page 10]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
In VoD, different peers watch different parts of the recorded media
content during a past event. In this case, each peer keeps asking
other peers which media chunks are stored in which peers, and then
gets the required media from certain/selected peers.
3.5 NAT Traversal
It is assumed that all trackers must be in the public Internet. This
document will not describe NAT Traversal mechanisms but the proposed
protocol tries to enable flexible NAT Traversal. Future versions will
consider the requirements raised by NAT.
3.6 Manifest File
The Manifest file holds information about the content, i.e.,
describes the structure of the media, namely, the codecs used (as
registered with the MP4 registration authority [MP4-Reg]), the
chunks, the number of layers (in case of SVC), number of descriptions
(in case of MDC) or views (in case of 3D) and the corresponding
mapping within a container file system.
The Manifest is a Well-Formed XML Document, encoded as double-byte
Unicode.
123456abcd
path/name
some description
Figure 3: XML Manifest for a VoD scalable video
The Manifest is a composite schema that includes, as root Element, a
Cruz, et al. Expires December 22, 2011 [Page 11]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
StreamInfo field that encapsulates all the metadata required for the
play-out of the media in groups of fields with
elements corresponding to each component of the media (video, audio)
streams, as well as other associated metadata (subtitles, text
descriptions, etc.). The different elements may include
specific descriptor elements, like Video and Audio and respective
attributes for each of the media types. An example of a XML manifest
for a VoD scalable video content is the following (Figure 3):
The Manifest file for P2P Streaming MUST contain Tracker information
prior to its upload to the Service Tracker during the publishing
procedure and can be compressed with GZIP file format [RFC 1952] in
order to be used with HTTP compression [RFC 2616] for faster
transmission times and less network bandwidth usage.
The Client Media Player parses the downloaded Manifest file and, if
it includes information for P2P Streaming, sends the file to the Peer
via a HTTP POST and waits for the response in order to start
requesting media chunks to decode and play-out. For applications
where the Peer is not co-located with the Media Player in the same
device (e.g., the Peer is in a Home Media Gateway), more than one
Media Player MAY use the same Peer.
The Manifest file can also be used for direct download/stream (HTTP
Streaming) from a specific server, and in this case, the file is not
appended with the P2P Tracker information. The Client Media Player,
in this case, just starts requesting media chunks from the HTTP
Streaming server to decode and play-out.
The Manifest file for Live Streaming has a similar structure but
describes a sliding window of a small range of from
the live program stream timeline (typically, 10 seconds of video).
The sliding window is updated for every new encoded (a
range of chunks defined by the attributes from="##" and to="##") of
the program stream. An example of a XML manifest for a Live scalable
video content is the following (Figure 4):
Cruz, et al. Expires December 22, 2011 [Page 12]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
654321xyz
TRUE
06:56:18
1258
path/name
some description
Figure 4: XML Manifest for a Live scalable video
The naming convention used to identify the media chunks considers a
sequential numbering for the chunks, concatenated with the identifier
of the content, typically an alphanumeric string. For SVC and MDC
contents, a "leveltype" and a "level_id" are added. For SVC in 3D, a
"view" number is also added, immediately after the content
identifier. The resulting media chunks become named as follows:
SVC/MDC: <-><->.
SVC/3D:
<->-<->.
other: <->.
Where is the character V followed by the number of views,
is a character with values L for SVC Layers and D for MDC
descriptions, is a numeric value identifying the layer
(SVC) or description (MDC) and follows the common media content
extension naming.
Cruz, et al. Expires December 22, 2011 [Page 13]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
Examples of the naming convention for a content_id="A123456789" are
as following:
SVC: A123456789-L0-00000.264 - chunk 0, layer 0 (base layer)
SVC: A123456789-L1-00000.264 - chunk 0, layer 1 (enhanced layer)
SVC/3D: A123456789-V2-L0-00000.264 - chunk 0, layer 0, 2 views
MDC: A123456789-D0-0000.h264 - chunk 0, description 0
Audio AAC: A123456789-00000.m4a - chunk 0
Video MPEG: A123456789-00000.mp4 - chunk 0
4 Messages syntax and processing
The PPSP Peer Protocol messages follow the request and response
standard formats for HTTP Request and Response messages [RFC2616].
4.1 HTTP/XML Encoding
A Request message is a standard HTTP Request generated by the HTTP
Client Peer with the following syntax:
/ HTTP/1.1
Host:
Content-Lenght:
Content-Type:
The HTTP Method and URI path (the Resource) indicates the operation
requested. The current proposal uses only HTTP POST as a mechanism
for the request messages.
The Response message is also a standard HTTP Response generated by
the Tracker with the following syntax:
HTTP/1.1
Content-Lenght:
Content-Type:
Content-Encoding:
The Host header field in the Request message follows the standard
rules for the HTTP 1.1 Host Header. Other Header fields MAY be
included in the Request and Response messages if necessary.
The body for both Request and Response messages are encoded in XML
for all the PPSP Peer Protocols messages, with the following schema
(the XML information being method specific):
Cruz, et al. Expires December 22, 2011 [Page 14]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
***
***
***
***
###
...XML information specific of the Method...
In the XML body, the *** represents alphanumeric data and ###
represents numeric data to be inserted. The corresponds to
the method type for the message, the corresponds to the
response method type of the message and the element
uniquely identifies the transaction.
The Request messages MUST include identification and authentication
token of the peer user.
The Response message MAY use Content-Encoding entity-header with
"gzip" compression scheme [RFC2616] for faster transmission times and
less network bandwidth usage.
4.2 Method Fields
Table 1 and Table 2 define the valid string representations for the
requests and responses, respectively. These values MUST be treated
as case-insensitive.
+--------------+--------------------------+
| PPSP Request | XML Request Value String |
+--------------+--------------------------+
| CONNECT | CONNECT |
| DISCONNECT | DISCONNECT |
| JOIN | JOIN |
| LEAVE | LEAVE |
| FIND_PEER | FIND_PEER |
| FIND_CHUNK | FIND_CHUNK |
| STAT_REPORT | STAT_REPORT |
| KEEPALIVE | KEEPALIVE |
+--------------+--------------------------+
Table 1: Valid Strings for Requests
Cruz, et al. Expires December 22, 2011 [Page 15]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
+----------------------+---------------------+--------------------+
| Response Method Name | HTTP Response | XML Response Value |
| | Mechanism | String |
+----------------------+---------------------+--------------------+
| SUCCESSFUL (OK) | 200 OK | OK |
| INVALID SYNTAX | 400 Bad Request | INVALID SYNTAX |
| VERSION NOT | 400 Bad Request | VERSION NOT |
| SUPPORTED | | SUPPORTED |
| AUTHENTICATION | 401 Unauthorized | AUTHENTICATION |
| REQUIRED | | REQUIRED |
| MESSAGE FORBIDDEN | 403 Forbidden | MESSAGE FORBIDDEN |
| OBJECT NOT FOUND | 404 Not Found | OBJECT NOT FOUND |
| INTERNAL ERROR | 500 Internal Server | INTERNAL ERROR |
| | Error | |
| TEMPORARILY | 503 Service | TEMPORARILY |
| OVERLOADED | Unavailable | OVERLOADED |
+----------------------+---------------------+--------------------+
Table 2: Valid Strings for Responses
4.3 Message Processing
When a PPSP Tracker Protocol message is received, some basic
processing is performed, regardless of the message type.
Upon reception, a message is examined to ensure that it 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 also verify that the XML body is
properly formed.
If the message is found to be incorrectly formed or the length does
not match the length encoded in the header, the receiver MUST reply
with an HTTP 400 response with a PPSP XML body with the Response
method set to INVALID SYNTAX.
If the version number of the protocol is for a version the receiver
does not supports, the receiver MUST reply with an HTTP 400 response
with a PPSP XML body with the Response method set to VERSION NOT
SUPPORTED.
If the receiver is unable to process the message for being in an
overloaded state, the receiver SHOULD reply with an HTTP 503 response
with a PPSP XML body with the Response method set to TEMPORARILY
OVERLOADED.
Cruz, et al. Expires December 22, 2011 [Page 16]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
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 body with the Response method set to INTERNAL ERROR.
4.4 CONNECT Message
This method is used when a Peer connects to the system. The Service
Tracker records the Peer-ID, connect-time, IP address and link
status.
The peer MUST properly form the XML body, set the Request Method to
CONNECT, set the PeerID with the identifier of the peer, randomly
generate and set the TransactionID and include identification
(UserID) and authentication token (AuthToken) of the peer user. The
peer SHOULD also include the IP addresses of its network interfaces
in the CONNECT message.
The CONNECT Request message uses a HTTP POST method with the
following body:
CONNECT
***
***
***
###
When receiving a well-formed CONNECT Request message, the Tracker
processes the peer and user authentication information to check
whether they are valid and that they can connect to the service. A
Response message with a corresponding response value and method will
be generated.
The element MAY contain multiple child
elements with attributes "ip" and "port" corresponding to each of the
network interfaces of the peer. The "ip" attribute can be expressed
in dotted decimal format for IPv4 or 16-bit hexadecimal values (hh)
separated by colons (:) for IPv6.
The Response message is a HTTP 200 OK with a SUCCESSFUL response in
case of success. In case of error one of the response methods of
Table 2 is returned. The response MUST have the same TransactionID
Cruz, et al. Expires December 22, 2011 [Page 17]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
value as the request.
An example of the SUCCESSFUL Response message structure for the
CONNECT Request is the following:
OK
###
4.5 DISCONNECT message
This method is used when the Peer intends to leave the system and no
longer participate in any swarm. The Service Tracker deletes the
corresponding activity records related to the peer (including its
status and all content status for all swarms) updating the
information on the historical profile record of that peer.
In the case where the peer serves multiple clients (on the same or on
different swarms), the DISCONNECT message SHALL NOT be used while
there are more than one active clients. There is no need for a peer
that sends a DISCONNECT to send a separate LEAVE to the Tracker for
each swarm it is participating, in the case there is only one active
client left that intends to leave the system and no longer
participate in any swarm.
The peer MUST properly form the XML body, set the Request Method to
DISCONNECT, set the PeerID with the identifier of the peer, randomly
generate and set the TransactionID and include identification
(UserID) and authentication token (AuthToken) of the peer user.
The DISCONNECT Request message uses a HTTP POST method with the
following body:
DISCONNECT
***
***
***
###
The Response message is a HTTP 200 OK with a SUCCESSFUL response in
case of success. In case of error one of the response methods of
Table 2 is returned. The response MUST have the same TransactionID
value as the request.
Cruz, et al. Expires December 22, 2011 [Page 18]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
Upon receiving a DISCONNECT message, the tracker MUST remove the peer
from the peer list and from all swarms the peer joined, as if a LEAVE
message was received for each swarm.
An example of the SUCCESSFUL Response message structure for the
DISCONNECT Request is the following:
OK
###
4.6 JOIN Message
This method is used for peers to notify the Service Tracker that they
wish to participate in a particular swarm.
The JOIN message is used when the peer does not have any chunks or
has some or all the chunks of a content. The JOIN is used for both
VoD or Live streaming modes.
The peer MUST properly form the XML body, set the Request Method to
JOIN, set the PeerID with the identifier of the peer, set the SwarmID
with the identifier of the swarm it is interested in, randomly
generate and set the TransactionID and include identification
(UserID) and authentication token (AuthToken) of the peer user. The
peer MAY include an ExpireTime set to a non-zero value expressed in
seconds, indicating that the peer expects to no longer be
participating at the end of that time. The ExpireTime MUST be set to
zero if the peer does not wish to set an expiration time.
The JOIN Request message uses a HTTP POST method with the following
body:
JOIN
***
***
***
***
###
###
OK
###
4.7 LEAVE Message
This method is used when peers want to indicate to the Service
Tracker that they no longer wish to participate in a particular
swarm. The Service Tracker deletes the corresponding activity records
related to the peer, including its status and all content status for
all swarms, updating the information on the historical profile record
of that peer.
The peer MUST properly form the XML body, set the Request Method to
LEAVE, set the PeerID with the identifier of the peer, set the
SwarmID with the identifier of the swarm the peer is not anymore
interested, randomly generate and set the TransactionID and include
identification (UserID) and authentication token (AuthToken) of the
peer user.
Cruz, et al. Expires December 22, 2011 [Page 20]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
The LEAVE Request message uses a HTTP POST method with the following
body:
LEAVE
***
***
***
***
###
OK
###
4.8 FIND_PEER Message
This method allows peers to request to the Service Tracker the Peer
list for a specific swarm.
The peer MUST properly form the XML body, set the Request Method to
FIND_PEER, set the PeerID with the identifier of the peer, set the
SwarmID with the identifier of the swarm the peer is interested,
optionally include information about the content, like Clip Name and
Type, randomly generate and set the TransactionID and include
identification (UserID) and authentication token (AuthToken) of the
peer user.
Cruz, et al. Expires December 22, 2011 [Page 21]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
The Request message uses a HTTP POST method with the following body:
FIND_PEER
***
***
***
***
***
(video, audio, etc.)
###
When receiving a well-formed FIND_PEER Request message, the Tracker
processes the peer and user authentication information to check
whether they are valid.
If the request is valid, a Response message with a corresponding
response value and method will be generated and the tracker will
search the internal data store to select and return an appropriate
list of peers, with their identifiers and IP Addresses, that will be
able to provide the desired content.
The Response message is an HTTP 200 OK SUCCESSFUL message in case of
success. The Tracker MUST reject the FIND_PEER message with an HTTP
400 Bad Request Response with a PPSP XML body of INVALID SYNTAX if
this condition has occurred, or for other conditions, with one of the
response methods of Table 2. The response MUST have the same
TransactionID value as the request.
Cruz, et al. Expires December 22, 2011 [Page 22]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
An example of the SUCCESSFUL Response message structure for the
FIND_PEER request is the following:
OK
***
###
***
***
... more addresses ...
***
***
###
... Other peer info ...
The field record in the XML body can be instantiated
multiple times in the element, one instance per peer.
The response message also carries information associated with network
topology information for each peer listed.
4.9 FIND_CHUNK Message
This method allows Peers to request to the Service Tracker the Peer
list for a specific Chunk of a particular swarm.
The peer MUST properly form the XML body, set the Request Method to
FIND_CHUNK, set the PeerID with the identifier of the peer, set the
SwarmID with the identifier of the swarm the peer is interested,
include Clip Name, Type and the Type information of the content,
randomly generate and set the TransactionID and include
identification (UserID) and authentication token (AuthToken) of the
peer user.
Cruz, et al. Expires December 22, 2011 [Page 23]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
The FIND_CHUNK Request message uses a HTTP POST method with the
following body:
FIND_CHUNK
***
***
***
***
***
(video, audio, etc.)
###
###
When receiving a well-formed FIND_CHUNK Request message, the Tracker
processes the peer and user authentication information to check
whether they are valid.
If the request is valid, a Response message with a corresponding
response value and method will be generated and the tracker will
search the internal data store to select and return an appropriate
list of peers, with their identifiers and IP Addresses, that will be
able to provide the desired content chunk.
The Response message is an HTTP 200 OK SUCCESSFUL message in case of
success. The Tracker MUST reject the FIND_CHUNK message with an HTTP
400 Bad Request Response with a PPSP XML body of INVALID SYNTAX if
this condition has occurred, or for other conditions, with one of the
response methods of Table 2. If the data is not found an HTTP 404 Not
Found with a PPSP XML Response method set to OBJECT NOT FOUND. The
response MUST have the same TransactionID value as the request.
Cruz, et al. Expires December 22, 2011 [Page 24]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
An example of the SUCCESSFUL Response message structure for the
FIND_CHUNK request is the following:
OK
***
###
***
***
... more addresses ...
***
***
###
... Other peer info ...
The field record in the XML body can be instantiated
multiple times in the element, one instance per peer.
The response message also carries information associated with network
topology information for each peer listed.
4.10 STAT_REPORT Message
This method allows the exchange of statistic and status data between
peers and Service Trackers to improve system performance. The method
is initiated by the peer, periodically.
The peer MUST properly form the XML body, set the Request Method to
STAT_REPORT, set the PeerID with the identifier of the peer, randomly
generate and set the TransactionID, include identification (UserID)
and authentication token (AuthToken) of the peer user. The report
consists of a element in the XML body containing multiple
fields.
The field record in the XML body can be instantiated multiple
Cruz, et al. Expires December 22, 2011 [Page 25]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
times in the element, one instance per "property" to report.
If the property being reported is associated with a swarm then the
peer MUST set the SwarmID element with the identifier of the swarm
and include other relevant information like Clip Name, Type and
information of the content.
The properties listed in Table 3 correspond to the REQUIRED minimum
set of information for the STAT_REPORT.
+-------------------+----------------------------------------------+
| Property Value | Definitions/Description |
+-------------------+----------------------------------------------+
| ChunkMap | a base64 encoded bitmap of chunks available |
| StreamStats | information on network streaming: |
| :UploadedBytes | total bytes sent to other peers in the swarm |
| :DownloadedBytes | total bytes received from peers in the swarm |
| :AvailBandwidth | total bytes received from peers in the swarm |
+------------------+-----------------------------------------------+
Table 3: Minimum set of Property Types for STAT_REPORT messages
Cruz, et al. Expires December 22, 2011 [Page 26]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
The STAT_REPORT Request message uses a HTTP POST method with the
following body:
STAT_REPORT
***
***
***
###
***
***
... encoded string ...
***
###
###
###
When receiving a well-formed STAT_REPORT message, the Tracker
processes the peer and user authentication information to check
whether they are valid.
If the request is valid, a Response message with a corresponding
response value and method will be generated and the tracker MAY
process the received information for future use.
The Response message is an HTTP 200 OK SUCCESSFUL message in case of
success. The Tracker MUST reject the STAT_REPORT message with an HTTP
400 Bad Request Response with a PPSP XML body of INVALID SYNTAX if
this condition has occurred, or for other conditions, with one of the
Cruz, et al. Expires December 22, 2011 [Page 27]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
response methods of Table 2. The response MUST have the same
TransactionID value as the request.
An example of the SUCCESSFUL Response message structure for the
STAT_REPORT is the following:
OK
###
4.11 KEEPALIVE Message
These messages are periodically sent from peers to the Service
Tracker to notify it that the peer is still alive (although not
actively exchanging data with other peers), to prevent the Service
Tracker from disconnecting the Peer (after some pre-configured time)
assuming that the peer was no longer available).
The peer MUST properly form the XML body, set the Request Method to
KEEPALIVE, set the PeerID with the identifier of the peer, randomly
generate and set the TransactionID, include identification (UserID)
and authentication token (AuthToken) of the peer user.
The KEEPALIVE Request message uses a HTTP POST method with the
following body:
KEEPALIVE
***
***
***
###
When receiving a well-formed KEEPALIVE message, the Tracker processes
the peer and user authentication information to check whether they
are valid.
If the request is valid, a Response message with a corresponding
response value and method will be generated and the tracker SHOULD
update an internal timer to indicate that the tracker has heard from
the peer.
The Response message is an HTTP 200 OK SUCCESSFUL message in case of
success. The Tracker MUST reject the KEEPALIVE message with an HTTP
Cruz, et al. Expires December 22, 2011 [Page 28]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
400 Bad Request Response with a PPSP XML body of INVALID SYNTAX if
this condition has occurred, or for other conditions, with one of the
response methods of Table 2. The response MUST have the same
TransactionID value as the request.
An example of the SUCCESSFUL Response message structure for the
KEEPALIVE is the following:
OK
###
5 Security Considerations
Since the protocol uses HTTP to transfer signaling most of the same
security considerations described in RFC 2616 also apply [RFC2616].
To protect the PPSP signaling from attackers pretending to be valid
peers (or peers other than themselves) all messages received in the
tracker are required to be received from authorized peers and MUST be
digitally signed with the peer user authentication token, providing
therefore end-to-end security for communications.
For that purpose a peer must enroll in the system via a centralized
enrollment server. The enrollment server is expected to provide a
proper PeerID for the peer as well as a UserID and corresponding
authentication Token. The specification of the enrollment method and
the provision of identifiers and authentication tokens is out of
scope of this draft.
6 IANA Considerations
There are presently no IANA considerations with this document.
7 Acknowledgments
The authors would like to thank all the people participating in the
EU FP7 project SARACEN for contributions and feedback to this
document.
SARACEN (Socially Aware, collaboRative, scAlable Coding mEdia
distributioN), is a research initiative funded partially by the
Information Society and Media Directorate General of the European
Commission under the Seventh Framework programme (contract no. ICT-
248474).
Cruz, et al. Expires December 22, 2011 [Page 29]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
The views and conclusions contained herein are those of the authors
and should not be interpreted as necessarily representing the
official policies or endorsements, either expressed or implied, of
the SARACEN project or the European Commission.
The Response method names and some text describing them, was borrowed
from [I-D.gu-ppsp-tracker-protocol].
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.
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
RFC 1952, May 1996.
[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.
[ISO.8601.2004] International Organization for Standardization, "Data
elements and interchange formats - Information interchange
- Representation of dates and times", ISO Standard 8601,
December 2004.
8.2 Informative References
[I-D.ietf-ppsp-reqs] Zong, N., Zhang, Y., Avila, V., Williams, C.,
and L. Xiao, "P2P Streaming Protocol (PPSP)
Requirements", draft-ietf-ppsp-reqs-02 (work in progress),
February 2011.
[I-D.ietf-ppsp-problem-statement] Zhang, Y., Zong, N., Camarillo, G.,
Seng, J., and Y. Yang, "Problem Statement of P2P Streaming
Protocol (PPSP)", draft-ietf-ppsp-problem-statement-01
(work in progress), January 2011.
[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.cruz-ppsp-http-peer-protocol] Cruz, R., Nunes, M. and Taveira,
J., "HTTP-based PPSP Peer Protocol", draft-cruz-ppsp-http-
peer-protocol-00 (work in progress), May 2011.
Cruz, et al. Expires December 22, 2011 [Page 30]
INTERNET DRAFT HTTP-based PPSP Tracker Protocol June 20, 2011
[I-D.gu-ppsp-tracker-protocol] Yingjie, G., Bryan, D., Zhang, Y., and
H. liao, "PPSP Tracker Protocol", draft-gu-ppsp-tracker-
protocol-04 (work in progress), May 2011.
[MP4-Reg] MP4REG, The MPEG-4 Registration Authority, URL:
.
[refs.saracenwebpage] "SARACEN Project Website",
http://www.saracen-p2p.eu/.
Authors' Addresses
Rui Santos Cruz
IST/INESC-ID/INOV
Phone: +351.939060939
Email: rui.cruz@ieee.org
Mario Serafim Nunes
IST/INESC-ID/INOV
Rua Alves Redol, n.9
1000-029 LISBOA, Portugal
Phone: +351.213100256
Email: mario.nunes@inov.pt
Joao Pedro Taveira Pinto Silva
IST/INOV
Phone: +351.966913777
Email: joao.taveira@inov.pt
Cruz, et al. Expires December 22, 2011 [Page 31]