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-01 Abstract This document presents a proposal for an HTTP-based P2P streaming Tracker 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], [I-D.ietf-ppsp-reqs]. 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 [RFC1952] in order to be used with HTTP compression [RFC2616] 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]