PPSP Rui S. Cruz INTERNET-DRAFT Mario S. Nunes Intended Status: Standards Track IST/INESC-ID/INOV Expires: May 2, 2012 Yingjie Gu Jinwei Xia Huawei David A. Bryan Polycom Joao P. Taveira IST/INOV Deng Lingli China Mobile October 30, 2011 PPSP Tracker Protocol draft-gu-ppsp-tracker-protocol-06 Abstract This document outlines the functionality required for an HTTP-based P2P Streaming Tracker Protocol, including requirements, functional entities and architecture, components, message flows, with detailed message processing instructions using an HTTP/XML encoding, the respective parameters, methods, and message formats, formal syntax and semantics. The PPSP Tracker 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. The Tracker Protocol is an application-level protocol for peers to publish/request content, provide peer lists to peers and peer status to Trackers. 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." Gu, et al. Expires May 2, 2012 [Page 1] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 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 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Protocol Request Messages . . . . . . . . . . . . . . . . . 10 3.2 Protocol Response Messages . . . . . . . . . . . . . . . . . 11 3.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4 Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . 12 3.5 Streaming Modes . . . . . . . . . . . . . . . . . . . . . . 14 3.6 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . 14 3.7 Media Presentation Description (MPD) . . . . . . . . . . . . 14 4 Messages syntax and processing . . . . . . . . . . . . . . . . . 17 4.1 HTTP/XML Encoding . . . . . . . . . . . . . . . . . . . . . 17 4.2 Method Fields . . . . . . . . . . . . . . . . . . . . . . . 19 4.3 Message Processing . . . . . . . . . . . . . . . . . . . . . 19 4.4 CONNECT Message . . . . . . . . . . . . . . . . . . . . . . 20 4.5 DISCONNECT message . . . . . . . . . . . . . . . . . . . . . 22 4.6 JOIN Message . . . . . . . . . . . . . . . . . . . . . . . . 23 4.7 LEAVE Message . . . . . . . . . . . . . . . . . . . . . . . 26 4.8 FIND Message . . . . . . . . . . . . . . . . . . . . . . . . 27 4.9 STAT_REPORT Message . . . . . . . . . . . . . . . . . . . . 29 4.10 KEEPALIVE Message . . . . . . . . . . . . . . . . . . . . . 31 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 32 Gu, et al. Expires May 2, 2012 [Page 2] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 5.1 Authentication between Tracker and Peers . . . . . . . . . . 32 5.2 Content Integrity protection against polluting peers/trackers . . . . . . . . . . . . . . . . . . . . . . . 33 5.3 Residual attacks and mitigation . . . . . . . . . . . . . . 33 5.4 Pro-incentive parameter trustfulness . . . . . . . . . . . . 33 6 PPSP Requirements Compliance . . . . . . . . . . . . . . . . . . 34 6.1 PPSP Basic Requirements . . . . . . . . . . . . . . . . . . 34 6.2 PPSP Tracker Protocol Requirements . . . . . . . . . . . . . 35 6.3 PPSP Security Considerations . . . . . . . . . . . . . . . . 35 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 36 8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 36 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 37 9.2 Informative References . . . . . . . . . . . . . . . . . . . 37 Appendix A. PPSP Tracker Protocol XML-Schema . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 Gu, et al. Expires May 2, 2012 [Page 3] INTERNET DRAFT PPSP Tracker Protocol October 30, 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] specifies that the Tracker Protocol should standardize format/encoding of information and messages between PPSP peers and PPSP trackers and [I-D.ietf-ppsp-reqs] defines the requirements. 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 and content registration and location. Content indexes (Media Presentation Descriptions) are also stored in the Tracker system allowing the association of content location information to the active peers in the swarm sharing the content. The process used for media streaming distribution assumes a segment transfer scheme whereby the original content (that can be encoded using adaptive or scalable techniques) is chopped into small segments (and subsegments) and has the following representations: 1. Adaptive - alternate representations with different qualities and bitrates; a single represention is non-adaptive; 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 multiple views - views correspond to mono and 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. The signaling and the media data transfer between PPSP peers is not in the scope of this specification. This documents describes the PPSP Tracker protocol and how it Gu, et al. Expires May 2, 2012 [Page 4] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 satisfies the requirements for the IETF Peer-to-Peer Streaming Protocol (PPSP), in order to derive the implications for the standardization of the PPSP streaming protocols and 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 terms defined in [I-D.ietf-ppsp-problem-statement] and in [I-D.xiao-ppsp-reload-distributed-tracker]. 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 representations (different qualities and bitrates) of the same media content co-exist for the same streaming session; each alternate representation corresponds to a different media quality level; peers can choose among the alternate representations for decode and playback. Base Layer: the playable representation level in Scalable Video Coding (SVC) required by all upper level Enhancements Layers for proper decoding of the video. Chunk: A chunk is a generic term used whenever no ambiguity is raised, to refer to a segment or a subsegment of partitioned streaming media. Complementary Representation: Representation in a set of representations which have inter-representation dependencies and which when combined result in a single representation for decoding and presentation. Connection Tracker: The Tracker Node to which the PPSP Peer will connect when it wants to join the PPSP system. Continuous media: Media with an inherent notion of time, for example, speech, audio, video, timed text or timed metadata. Enhancement Layer: enhancement differential quality level (complementary representation) in Scalable Video Coding (SVC) used to produce a higher quality, higher definition video in terms of space Gu, et al. Expires May 2, 2012 [Page 5] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 (i.e., image resolution), time (i.e., frame rate) or Signal-to-Noise Ratio (SNR) when combined with the playable Base Layer. 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. 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. Media Component: An encoded version of one individual media type such as audio, video or timed text with specific attributes, e.g., bandwidth, language, or resolution. Media Presentation Description (MPD): Formalized description for a media presentation, i.e., describes the structure of the media, namely, the codecs used, the chunks, and the corresponding mapping within a container file system. Online Time: Online Time shows how long the peer has been in the P2P streaming system since it joins. This value indicates the stability of a peer, and it is calculated by Tracker when necessary. 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 Peer-to-Peer Streaming Protocols. PPSP protocols refer to the key signaling protocols among various P2P streaming system components, including the tracker and peers. Representation: Structured collection of one or more media components. 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). With Multiple View Coding Gu, et al. Expires May 2, 2012 [Page 6] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 (MVC), multiple views allow the video to be played in 3D when the views are combined together. Segment: A segment is a resource that can be identified, by an ID or an HTTP-URL and possibly a byte-range, and is included in the MPD. The segment is a basic unit of partitioned streaming media, which is used by a peer for the purpose of storage, advertisement and exchange among peers. Subsegment: Smallest unit within segments which may be indexed at the segment level. 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 centralized logical directory service used to communicate with PPSP Peers for content registration and location, which maintains the lists of PPSP peers storing segments for a specific live content 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 request candidate Peer lists from Trackers. Video-on-demand (VoD): A kind of application that allows users to select and watch video content on demand. 3. Protocol Overview The functional entities involved in the PPSP Tracker Protocol are Trackers and Peers (which may support different capabilities). Peers correspond to devices that actually participate in sharing a media content and are organized in (various) swarms corresponding each swarm to the group of peers streaming that content at any given time. Each peer stores chunks of the media content, called segments (or subsegments), and contacts the Tracker to advertise which information it has available. When a peer wishes to obtain information about the swarm, it contacts the Tracker to find other peers participating in that specific swarm. Gu, et al. Expires May 2, 2012 [Page 7] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 The Tracker is a logical entity that maintains the lists of peers storing chunks for a specific Live media channel or media streaming content, answers queries from peers and collects information on the activity of peers. While a Tracker may have an underlying implementation consisting of more than one physical node, logically the Tracker can most simply be thought of as a single element, and in this document, it will be treated as a single logical entity. 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 local Connection Tracker and joins a swarm. 2. Peer acquires a list of peers from the Connection 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 Connection Tracker. 2. Peer sends information to the Connection Tracker about the swarm it belongs to (joins), plus streaming status and/or content availability. +-----------------------------------+ | 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 Gu, et al. Expires May 2, 2012 [Page 8] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 generates a single response (neglecting fragmentation of messages). The specific operations of the protocol at present, are listed in Table 1: +---------------+ | PPSP Tracker | | Req. Messages | +---------------+ | CONNECT | | DISCONNECT | | JOIN | | LEAVE | | FIND | | STAT_REPORT | | KEEPALIVE | +---------------+ Table 1: Request Messages The data managed at the peer and the tracker correspond to status information about the peer in each swarm, as illustrated in Figure 2. Peer +-------------------+ |Data management | | SwarmID | | - peer list | | - Buffer map | | | +-------------------+ ^ --------------*----------- Tracker V +---------------------------------------------------------+ | Data management on Tracker | | | | +======================+ +======================+ | | |peer status | |content status | | | | PeerID | | +----------------+ | | | | - online time | | | SwarmID | | | | | - peer property | | | - Chunk Map | | | | | - link status | | | - peer list | | | | | - etc. | | +----------------+ | | | +======================+ +======================+ | +---------------------------------------------------------+ Figure 2: PPSP Tracker Protocol data management components Gu, et al. Expires May 2, 2012 [Page 9] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 3.1 Protocol Request Messages CONNECT: This message is used when a Peer connects to the system. The Tracker records the PeerID, connect-time (referenced to the absolute time), peer IP addresses and link status. The method allows a security layer to be negotiated in the authentication protocol exchange between the Peer and the Tracker [RFC4422]. The security layer provides data integrity, data confidentiality, and other services. The security layer is installed by the Tracker after indicating the outcome of the authentication exchange (an authentication token) and installed by the peer upon receipt of the outcome indication. In both cases, the layer is installed before transfer of further protocol data. The security layer remains in effect until either a subsequently negotiated security layer is installed or the connection is closed (via DISCONNECT or after some pre-configured time). DISCONNECT: This message is used when the Peer intends to leave the system and no longer participate in any swarm. The Tracker deletes the corresponding activity records related to the Peer (including its status and all content status for all swarms), optionally updating the information on the historical profile record of that Peer. JOIN: This message is used for a Peer to notify the Tracker that it wish to participate in a particular swarm. The tracker records the content availability, i.e., adds the Peer to the candidate peers list for the swarm. LEAVE: This message is used when a Peer wants to indicate to the Tracker that it no longer wish to participate in a particular swarm. The tracker will no longer provide this Peer information to others when they request to join that swarm. FIND: This message allows a Peer to request to the Tracker the peer list for a specific content representation or specific chunks of a media component in a swarm. On receiving a FIND message, the Tracker finds the candidate peers listed in content status, and returns the list to the requesting peer. To create the peer list, the Tracker may take peer status, capabilities and peers priority into consideration when selecting the candidate peers. Peer priority may be determined by network topology preference, operator policy preference, etc. STAT_REPORT: This message allows the exchange of statistic and status data between an active Peer and a Tracker to improve system performance. The method is initiated by the peer. KEEPALIVE: These messages are periodically sent from a Peer to the Tracker to notify it that the Peer is still alive, even if inactive, Gu, et al. Expires May 2, 2012 [Page 10] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 preventing the Tracker from disconnecting the Peer after some pre- configured time (assuming that the Peer is no longer available). Timer on the tracker can be reset by any other message send from the Peer. 3.2 Protocol Response Messages The Response messages correspond to a number of logical responses common to the Tracker or the Peer protocols request messages. Incorrectly formatted 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): indicates that 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. The information returned in this message body for each request message is the following: JOIN, FIND, KEEPALIVE and STAT_REPORT: returns any required status information about the successfully completed operation. FIND: returns the list of peers meeting the desired criteria. 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. TEMPORARILY OVERLOADED (503 SERVICE UNAVAILABLE): The server is Gu, et al. Expires May 2, 2012 [Page 11] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 unable to process this message at this time. 3.3 Assumptions The functional entities related to PPSP protocols are the Client Media Player, the service Portal, the 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 Tracker is a logical entity that maintains the lists of PPSP active peers storing and exchanging chunks for a specific media content. The Tracker also stores the status of peers, to help in the selection of appropriate candidate peers for a requesting peer. The Tracker can be realized by geographically distributed tracker nodes or multiple server nodes in a data center, increasing the content availability, the service robustness and the network scalability or reliability. The management and locating of content index information are totally internal behaviors of the Tracker system, which is invisible to the PPSP Peer [I-D.xiao-ppsp-reload-distributed-tracker]. 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 to exchange data and PPSP signaling with Peers and Trackers. 3.4 Bootstrapping In order to join an existing P2P streaming service and to participate in content sharing, any Peer must first locate a Tracker, using for example, the following methods (as illustrated in Figure 3): 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 MPD file of a content: this metainfo file must contain Gu, et al. Expires May 2, 2012 [Page 12] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 information about the address of one or more Connection Trackers (that can be grouped by tiers of priority) which are controlling the swarm for that media content. In order to be able to bootstrap, a peer must first obtain a PeerID (identity associated with the authentication credentials) 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 (MPD Request)-->| | | |<-----------------------OK+MPD--| | | |--MPD---------->|--CONNECT-------------------->| | | |<---------------OK+AuthToken--| | | |--JOIN----------------------->| | |<-----------OK--|<----------------OK+Peerlist--| | | |--GET_CHUNKMAP (Peer protocol)----------->| | |<-------------------------------ChunkMap--| |--GET (Chunk)-->|--GET_CHUNK (Peer protocol)-------------->| |<-----OK+Chunk--|<----------------------------------Chunk--| : : : : : | |--FIND----------------------->| | | |<----------------OK+Peerlist--| | |--GET (Chunk)-->|--GET_CHUNK (Peer protocol)-------------->| |<-----OK+Chunk--|<----------------------------------Chunk--| : : : : : | | | | | | |--STAT_REPORT---------------->| | | |<-------------------------Ok--| | |--GET (Chunk)-->|--GET_CHUNK (Peer protocol)-------------->| |<-----OK+Chunk--|<----------------------------------Chunk--| : : : : : | | | | | |--KEEPALIVE------------------>| | | |<-------------------------Ok--| | : : : : : | | | | | |--LEAVE/DISCONNECT----------->| | | |<-------------------------Ok--| | Figure 3: A typical PPSP session The specification of the mechanism used to obtain a PeerID and Gu, et al. Expires May 2, 2012 [Page 13] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 certificates is not in the scope of this document. 3.5 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 chunks, 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. 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. While watching VoD, a peer can also switch to any place of the content, e.g., skip the credits, or skip the part that is not interested in. In this case the peer may not download and store all the content segments. From the whole swarm point of view, the participating peers typically store different parts of content. 3.6 NAT Traversal It is assumed that all trackers must be in the public Internet and have been placed there deliberately. This document will not describe NAT Traversal mechanisms but the proposed protocol tries to enable flexible NAT Traversal using ICE [RFC5245], considering that the Tracker node provides NAT traversal services in PPSP (STUN-like Tracker) by discovering the reflexive address of Peer via PPSP Tracker Protocol messages, enabling it to put the address it observes in CONNECT responses [I-D.li-ppsp-nat-traversal-02]. Future versions will consider the requirements raised by NAT. 3.7 Media Presentation Description (MPD) The MPD file describes a Media Presentation, i.e., a bounded or unbounded presentation of media content. In particular, it defines formats to announce resource identifiers for segments and subsegments (layers in case of SVC, descriptions in case of MDC, or views in case of 3D) and to provide the context for these identified resources within a Media Presentation, i.e., describes the structure of the media, the codecs used (as registered with the MP4 registration authority [MP4-Reg]), the segments and the corresponding mapping Gu, et al. Expires May 2, 2012 [Page 14] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 within a container file system. The MPD contains information about the preferred Connection Trackers, than can be classified in tiers of priority (attribute "tier"). The MPD is a Well-Formed XML Document, encoded as double-byte Unicode. The XML-Schema of the MPD will in the future align with ISO/IEC 23001-6 [ISO.IEC.23001-6]. 123456abcd path/name some description Figure 4: XML MPD for a VoD scalable video The MPD is a composite schema that includes, as root Element, a 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 MPD for a VoD scalable video content is the following (Figure 4): The MPD file for P2P Streaming MUST contain Tracker information prior to its upload to the Tracker during the publishing procedure and can be compressed with GZIP file format [RFC1952] in order to be used with HTTP compression [RFC2616] for faster transmission times and less network bandwidth usage. Gu, et al. Expires May 2, 2012 [Page 15] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 The Client Media Player parses the downloaded MPD 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. The MPD 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 MPD for a Live scalable video content is the following (Figure 5): 654321xyz TRUE 06:56:18 1258 path/name some description Figure 5: XML MPD for a Live scalable video The naming convention used to identify the media chunks (segments/subsegments) considers a sequential numbering for segments/subsegments, 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 MVC in 3D, a "view" number is also added, immediately after the content identifier. The resulting media chunks become named as follows: Gu, et al. Expires May 2, 2012 [Page 16] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 SVC/MDC: <-><->. MVC/3D: <->-<->. AVC: <->. 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. Examples of the naming convention for a content_id="A123456789" are as following: SVC: A123456789-L0-00000.264 - chunk 0, layer 0 (subsegment BL) SVC: A123456789-L1-00000.264 - chunk 0, layer 1 (subsegment EL) MVC: A123456789-V2-L0-00000.264 - chunk 0, layer 0, view 2 MDC: A123456789-D0-0000.h264 - chunk 0, description 0 AAC: A123456789-00000.m4a - chunk 0 AVC: A123456789-00000.mp4 - chunk 0 (segment) 4 Messages syntax and processing The PPSP Tracker 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. Gu, et al. Expires May 2, 2012 [Page 17] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 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 Tracker Protocols messages, with the following structure (the XML information being method specific): *** *** *** *** ### ...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. Only one of Method or Response will be present in any given method -- the presence of both constitutes an error. The version of the PPSP Tracker Protocol being used is in the form of a fixed point integer. The TransactionID is a unique identifier for the transaction allowing receivers to disambiguate transactions which would be otherwise identical. Responses use the same TransactionID as the request they correspond to. All Request messages except CONNECT MUST include authentication identity (PeerID) and authentication token [RFC4422]. The security mechanism considers using re-keying service (key renegotiation process) for the AuthToken [RFC4422]. The Response message MAY use Content-Encoding entity-header with "gzip" compression scheme [RFC2616] for faster transmission times and less network bandwidth usage. Gu, et al. Expires May 2, 2012 [Page 18] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 The XML-Schema of PPSP Tracker Protocol is provided in Appendix A. 4.2 Method Fields Table 2 and Table 3 define the valid string representations for the requests and responses, respectively. These values MUST be treated as case-insensitive. +--------------------------+ | XML Request Value String | +--------------------------+ | CONNECT | | DISCONNECT | | JOIN | | LEAVE | | FIND | | STAT_REPORT | | KEEPALIVE | +--------------------------+ Table 2: Valid Strings for Requests +----------------------+---------------------+--------------------+ | 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 3: 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. Gu, et al. Expires May 2, 2012 [Page 19] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 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. 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 Tracker records the PeerID, connect-time, IP address and link status. The peer MUST properly form the XML body, set the Request Method to CONNECT, randomly generate and set the TransactionID, set the PeerID with the identifier of the peer and include the authentication initial response [RFC4422]. The peer SHOULD also include the IP addresses of its network interfaces in the CONNECT message. Gu, et al. Expires May 2, 2012 [Page 20] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 The CONNECT Request message uses a HTTP POST method with the following body: CONNECT *** AG1hZ251cwAxMjM0NT= ### When receiving a well-formed CONNECT Request message, the Tracker processes the peer authentication information to check whether it is valid and that it 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", "port", "priority" and "type" 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 attributes "priority" and "type" are related with NAT Traversal service [I-D.li-ppsp-nat-traversal-02]. 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 3 is returned. If STUN-like function is enabled in the Tracker, the response MAY include the Peer reflexive address [I-D.li-ppsp-nat-traversal-02]. The response MUST have the same TransactionID value as the request and contain the Authentication Token to be used by the Peer in subsequent messages until disconnecting. Gu, et al. Expires May 2, 2012 [Page 21] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 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 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 DISCONNECT, set the PeerID with the identifier of the peer, randomly generate and set the TransactionID and include the re-keyed authentication token (AuthToken). The DISCONNECT Request message uses a HTTP POST method with the following body: DISCONNECT *** *** ### The Response message is an HTTP 200 OK with a SUCCESSFUL response in case of success. In case of error one of the response methods of Table 3 is returned. The response MUST have the same TransactionID value as the request. 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. Gu, et al. Expires May 2, 2012 [Page 22] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 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 Tracker that they wish to participate in a particular swarm. The JOIN message is used when the peer has none or just some chunks (LEECH), or has all the chunks (SEED) 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 the re-keyed authentication token (AuthToken). 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 message also includes property information to indicate the capabilities of the peer, such as NAT traversal information, PeerMode set to the type of participation in the swarm (can be SEED, LIVESEED or LEECH, but other qualifiers may additionally be defined) and also the maximum number of candidates to be received in the Peer List, when applicable. Gu, et al. Expires May 2, 2012 [Page 23] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 The JOIN Request message uses a HTTP POST method with the following body: JOIN *** *** *** *** true ### *** ### ### OK *** *** *** ... more addresses ... *** *** ### ... Other peer info ... ### Gu, et al. Expires May 2, 2012 [Page 25] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 4.7 LEAVE Message This method is used when peers want to indicate to the Tracker that they no longer wish to participate in a particular swarm. The 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 the re-keyed authentication token (AuthToken). The LEAVE Request message uses a HTTP POST method with the following body: LEAVE *** *** *** ### OK ### Gu, et al. Expires May 2, 2012 [Page 26] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 4.8 FIND Message This method allows peers to request to the Tracker, whenever needed and after being joined to a swarm, the peer list for the swarm or for specific chunks of a media content representation of that swarm. The peer MUST properly form the XML body, set the Request Method to FIND, set the PeerID with the identifier of the peer, set the SwarmID with the identifier of the swarm the peer is interested, optionally, in order to find specific chunks, include information about the content, like Clip Name, type and the segment IDs, randomly generate and set the TransactionID and include authentication token (AuthToken). The message also includes property information to indicate the capabilities of the peer, such as NAT traversal information. The Request message uses a HTTP POST method with the following body: FIND *** *** *** ### true *** ### When receiving a well-formed FIND Request message, the Tracker processes the peer authentication information to check whether it is valid and can be authorized. 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 Tracker may take peer status and priority information into Gu, et al. Expires May 2, 2012 [Page 27] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 consideration when selecting the peer list candidates and the selection may change in subsequent requests to express network topology preferences or Operators' policy preferences, with regard to the possibility of connecting with other IETF efforts such as ALTO [I.D.ietf-alto-protocol]. The Response message is an HTTP 200 OK SUCCESSFUL message in case of success. The Tracker MUST reject the FIND 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 3. If the data is not found (find chunk option) 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. An example of the SUCCESSFUL Response message structure for the FIND 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 PeerLocation, ConnectionType and EndPointRankCost express network topology preferences or Operators' policy preferences, related with Gu, et al. Expires May 2, 2012 [Page 28] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 the possibility of connecting with other IETF efforts such as ALTO [I.D.ietf-alto-protocol] The response message also carries information associated with network topology information for each peer listed. 4.9 STAT_REPORT Message This method allows the exchange of statistic and status data between peers and Trackers to improve system performance. The method is initiated by the peer, periodically while active. 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 authentication token (AuthToken). The report consists of a element in the XML body containing multiple fields. The field record in the XML body can be instantiated multiple 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 4 correspond to the REQUIRED minimum set of information for the STAT_REPORT, but additional properties are deemed to be defined in the future. +-------------------+----------------------------------------------+ | 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 | | NAT Traversal | The type of NAT Traversal capabilities | | :NAT | Peer believes it is behind NAT (boolean) | | :STUN | Peer supports STUN service (boolean) | +------------------+-----------------------------------------------+ Table 4: Minimum set of Property Types for STAT_REPORT messages Gu, et al. Expires May 2, 2012 [Page 29] INTERNET DRAFT PPSP Tracker Protocol October 30, 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 authentication information to check whether it is 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 response methods of Table 3. The response MUST have the same Gu, et al. Expires May 2, 2012 [Page 30] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 TransactionID value as the request. An example of the SUCCESSFUL Response message structure for the STAT_REPORT is the following: OK ### 4.10 KEEPALIVE Message These messages are periodically sent from peers to the Tracker to notify it that the peer is still alive (although not actively exchanging data with other peers), to prevent the Tracker from disconnecting the Peer (after some pre-configured time) by 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 and include authentication token (AuthToken). 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 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 Gu, et al. Expires May 2, 2012 [Page 31] INTERNET DRAFT PPSP Tracker Protocol October 30, 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 KEEPALIVE is the following: OK ### 5 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 participants may be malicious or uncooperative. 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 eventual distrustful trackers (under the distributed tracker deployment scenario). Since the protocol uses HTTP to transfer signaling most of the same security considerations described in RFC 2616 also apply [RFC2616]. 5.1 Authentication between Tracker and Peers 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. 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 and information about the authentication mechanisms. The specification of the enrollment method and the provision of identifiers and authentication tokens is out of scope of this draft. The method for adding authentication and data security services via replaceable mechanisms to the PPSP Tracker Protocol (connection- oriented) is the Simple Authentication and Security Layer (SASL) framework [RFC4422]. Gu, et al. Expires May 2, 2012 [Page 32] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 The SASL method also provides the means for negotiating data security layer mechanisms to provide data integrity, data confidentiality, and other services, subject to local policies and security requirements. The authentication exchange between Peer and Tracker consists of a CONNECT message from the Peer to the Tracker requesting authentication via a particular mechanism, followed by a message from the Tracker indicating the outcome of the authentication exchange (the AuthToken). C: Request authentication exchange + Initial response S: Outcome of authentication exchange All subsequent messages, while the Peer is active will use the AuthToken, and the security mechanism considers using re-keying service (key renegotiation process) for the AuthToken [RFC4422]. 5.2 Content Integrity protection against polluting peers/trackers Malicious peers may declaim ownership of popular content to the Tracker but serve polluted (i.e., decoy content or even virus/trojan infected contents) 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. 5.3 Residual attacks and mitigation To mitigate the impact of sybil attackers, impersonating a large number of valid participants by repeatedly acquiring different peer identities, 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 the credit of each peer is accumulated from evaluations for previous transactions, may be taken into account by other peers when selecting partner for future transactions, helping to mitigate the impact of such malicious behaviors. A globally trusted Tracker MAY also take part of the trust mechanism by collecting evaluations, computing credit values and providing them to joining peers. 5.4 Pro-incentive parameter trustfulness Property Types for STAT_REPORT messages will consider pro-incentive Gu, et al. Expires May 2, 2012 [Page 33] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 parameters, which can enable the Tracker to improve the performance of the whole P2P streaming system. Trustworthiness of these pro- incentive parameters is critical to the effectiveness of the incentive mechanisms. For example, ChunkMap is essential, and needs to be accurate. The P2P system should be designed in a way such that a peer will have the incentive to report truthfully its ChunkMap (otherwise it may penalize itself, as in the case of under-reporting addressed in [prTorrent]). Furthermore, both the amount of upload and download should be reported to the Tracker to allow checking if there is any inconsistency between the upload and download report, and establish an appropriate credit/trust system. Alternatively, exchange of cryptographic receipts signed by receiving peers can be used to attest to the upload contribution of a peer to the swarm, as suggested in [Contracts]. 6 PPSP Requirements Compliance 6.1 PPSP Basic Requirements PPSP.REQ-1: The design of the Tracker protocol in this draft allows the Peer Protocol to be similar in terms of design, message formats and flows. PPSP.REQ-2: The design of the Tracker protocol in this draft enables peers to receive streaming content within required time constraints. PPSP.REQ-3: Each Peer has a unique ID (i.e., PeerID) that identifies the Peer in all swarms joined. PPSP.REQ-4: Each streaming content is uniquely identified by a SwarmID. PPSP.REQ-5: The streaming content is partitioned into chunks individually addressable. PPSP.REQ-6: Each chunk has an unique ID in the swarm and is individually addressable. PPSP.REQ-7: The Tracker Protocol is carried over TCP. PPSP.REQ-8: The Tracker Protocol is designed to facilitate acceptable QoS, supporting, without special algorithms, adaptive and scalable video and 3D video, for both Video On Demand (VoD) and Live video services, allowing additionally complementary mechanisms like super peers, in-network storage, alternative peer addresses and usage of QoS information for advanced peer selection. Gu, et al. Expires May 2, 2012 [Page 34] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 6.2 PPSP Tracker Protocol Requirements PPSP.TP.REQ-1: The Tracker Protocol implements the reception of queries from peers, such as those in JOIN and FIND messages and periodical peer status reports (STAT_REPORT), as well as the corresponding replies. PPSP.TP.REQ-2: The peer MUST implement the Tracker Protocol designed in this draft. PPSP.TP.REQ-3: The tracker request messages JOIN and FIND allow the requesting of peer list from the Tracker with respect to a specific SwarmID and include preferred number of peers in the peer list as well as peer properties which enable appropriate candidate peer selections by the Tracker. PPSP.TP.REQ-4: The tracker replies to JOIN and FIND messages allow the Tracker to offer the peer list to the requesting peer with respect of a specific SwarmID. PPSP.TP.REQ-5: The Tracker supports generating the peer lists with the help of traffic optimization services like ALTO. PPSP.TP.REQ-6: The STATUS_REPORT message informs the Tracker about the peer's activity in the swarm. PPSP.TP.REQ-7: The chunk availability information (ChunkMaps) of the Peer (for all joined swarms) is reported to the Tracker in STATUS_REPORT messages. PPSP.TP.REQ-8: The ChunkMaps exchanged between Peer and Tracker are expressed as compact encoded strings. PPSP.TP.REQ-9: The STATUS_REPORT message informs the Tracker about the Peer status and capabilities. 6.3 PPSP Security Considerations PPSP.SEC.REQ-1: The Tracker Protocol supports closed swarms, where the peers are required to be authenticated. PPSP.SEC.REQ-2: Confidentiality of the streaming content can be supported, and the corresponding key management mechanisms can be negotiated in the authentication and authorization phase (via CONNECT message) before the peer JOINing the swarm. PPSP.SEC.REQ-3: The Tracker Protocol uses SASL mechanisms with option to negotiate additional security layers to encrypt the data exchanged Gu, et al. Expires May 2, 2012 [Page 35] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 among the PPSP entities. PPSP.SEC.REQ-4: The Tracker Protocol SASL mechanisms help to limit potential damages caused by malfunctioning and badly behaving peers in the P2P streaming system. The streaming mechanism, being pull- based, even in Live Streaming, prevents pollution of contents. PPSP.SEC.REQ-6: The use of trusted Trackers and Peer authentication and authorization mechanisms capable to provide additional security and confidentiality, allow to mitigate and prevent peers from DoS attacks. PPSP.SEC.REQ-7: The Tracker Protocol design supports distributed tracker architectures, providing robustness to the streaming service in case of centralized Tracker failure. PPSP.SEC.REQ-8: The Tracker Protocol use of SASL mechanisms avoid the need for developing new security mechanisms. PPSP.SEC.REQ-9: The Tracker Protocol together with the Media Presentation Description (MPD) allow the use of streaming content integrity mechanisms. 7 IANA Considerations There are presently no IANA considerations with this document. 8 Acknowledgments The authors would like to thank many people for for their help and comments, particularly: 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, Kangheng Wu., Martin Stiemerling from NEC Labs, Johan Pouwelse and Arno Bakker form TU Delft. The authors would also like to thank the people participating in the EU FP7 project SARACEN (contract no. ICT-248474) [refs.saracenwebpage] for contributions and feedback to this document. 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. Gu, et al. Expires May 2, 2012 [Page 36] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 9 References 9.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. [RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [ISO.8601.2004] International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO Standard 8601, December 2004. 9.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. Gu, et al. Expires May 2, 2012 [Page 37] INTERNET DRAFT PPSP Tracker Protocol October 30, 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. [I-D.li-ppsp-nat-traversal-02] Li, L., Wang, J., Chen, W., "PPSP NAT Traversal", draft-li-ppsp-nat-traversal-02 (work in progress), July 2011. [I-D.xiao-ppsp-reload-distributed-tracker] Xiao, L., Bryan, D., Gu, Y., Tai, X., "A PPSP Tracker Usage for Reload", draft- xiao-ppsp-reload-distributed-tracker-03 (work in progress), October 2011. [I.D.ietf-alto-protocol] Alimi, R., Penno, R., Yang, Y., "ALTO Protocol", draft-ietf-alto-protocol-09, (work in progress), June 2011. [MP4-Reg] MP4REG, The MPEG-4 Registration Authority, URL: . [ISO.IEC.23001-6] International Organization for Standardization/International Electrotechnical Commission, "Information technology - MPEG systems technologies - Part 6: Dynamic adaptive streaming over HTTP (DASH)", ISO/IEC DIS 23001-6, Jan 2011. [refs.saracenwebpage] "SARACEN Project Website", http://www.saracen-p2p.eu/. [prTorrent] Roy, S., Zeng, W., "prTorrent: On Establishment of Piece Rarity in the BitTorrent Unchoking Algorithm", in IEEE Ninth International Conference on Peer-to-Peer Computing, September 2009. [Contracts] Piatek, M., Venkataramani, A., Yang, R., Zhang, D., Jaffe, A., "Contracts: Practical Contribution Incentives for P2P Live Streaming", in NSDI '10: USENIX Symposium on Networked Systems Design and Implementation, April 2010. Appendix A. PPSP Tracker Protocol XML-Schema Gu, et al. Expires May 2, 2012 [Page 38] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 Gu, et al. Expires May 2, 2012 [Page 39] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 Gu, et al. Expires May 2, 2012 [Page 40] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 Gu, et al. Expires May 2, 2012 [Page 41] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 Gu, et al. Expires May 2, 2012 [Page 42] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 Authors' Addresses Rui Santos Cruz IST/INESC-ID/INOV Phone: +351.939060939 Email: rui.cruz@ieee.org Gu Yingjie Huawei Phone: +86-25-56624760 Fax: +86-25-56624702 Email: guyingjie@huawei.com Mario Serafim Nunes IST/INESC-ID/INOV Rua Alves Redol, n.9 1000-029 LISBOA, Portugal Phone: +351.213100256 Email: mario.nunes@inov.pt David A. Bryan Polycom P.O. Box 6741 Gu, et al. Expires May 2, 2012 [Page 43] INTERNET DRAFT PPSP Tracker Protocol October 30, 2011 Williamsburg, Virginia 23188 United States of America Phone: +1.571.314.0256 Email: dbryan@ethernot.org Jinwei Xia Huawei Nanjing, Baixia District 210001 China Phone: +86-025-86622310 Email: xiajinwei@huawei.com Joao P. Taveira IST/INOV Email: joao.silva@inov.pt Deng Lingli China Mobile Gu, et al. Expires May 2, 2012 [Page 44]