PPSP Y. Gu Internet-Draft J. Xia Intended status: Standards Track Huawei Expires: May 3, 2012 R. Cruz M. Nunes IST/INESC-ID/INOV David A. Bryan Polycom J. Taveira ID/INOV Oct 31, 2011 Peer Protocol draft-gu-ppsp-peer-protocol-03 Abstract This document presents the architecture of the PPSP Peer protocol outlining the functional entities, message flows and message processing instructions, with the respective parameters. 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. The protocol messages formal syntax and semantics, methods, and formats are presented for both Binary and HTTP/XML encoded formats. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 3, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Gu, et al. Expires May 3, 2012 [Page 1] Internet-Draft Peer Protocol Oct 2011 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. Document Conventions . . . . . . . . . . . . . . . . . . . . . 4 2.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Protocol Architecture . . . . . . . . . . . . . . . . . . 7 3.2. Example Call Flow . . . . . . . . . . . . . . . . . . . . 9 3.3. Chunk Scheduling . . . . . . . . . . . . . . . . . . . . . 10 4. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 11 5. Security Consideration . . . . . . . . . . . . . . . . . . . . 13 5.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Content Integrity Protection Against Polluting Peers/Trackers . . . . . . . . . . . . . . . . . . . . . . 13 5.3. Residual Attacks and Mitigation . . . . . . . . . . . . . 14 5.4. Pro-incentive Parameter Trustfulness . . . . . . . . . . . 14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 6.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Binary Encoding . . . . . . . . . . . . . . . . . . . 16 A.1. Methods in Peer messages . . . . . . . . . . . . . . . . . 17 Appendix B. HTTP/XML Encoding . . . . . . . . . . . . . . . . . . 21 B.1. HTTP/XML Encoding . . . . . . . . . . . . . . . . . . . . 21 B.2. Method Fields . . . . . . . . . . . . . . . . . . . . . . 22 B.3. Message Processing . . . . . . . . . . . . . . . . . . . . 23 B.4. GET_PEERLIST Message . . . . . . . . . . . . . . . . . . . 24 B.5. GET_CHUNKMAP Message . . . . . . . . . . . . . . . . . . . 26 B.6. GET_CHUNK Message . . . . . . . . . . . . . . . . . . . . 27 B.7. PEER_STATUS Message . . . . . . . . . . . . . . . . . . . 29 B.8. TRANSPORT_NEGOTIATION Message . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Gu, et al. Expires May 3, 2012 [Page 2] Internet-Draft Peer Protocol Oct 2011 1. Introduction The P2P Streaming Protocol (PPSP) is composed of two protocols: the PPSP Tracker Protocol and the PPSP Peer Protocol [I-D.ietf-ppsp-problem-statement]. The PPSP 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 PPSP Tracker Protocol provides communication between Trackers and Peers and outlines how a peer is able to communicate with a tracker in order to exchange meta information about the location of other peers contributing with a specific stream (swarm) the peer interested in, as well as to report streaming status. The Peer can also apply to be a contributor for several streams (swarms), periodically reporting its status to the Tracker, allow it to estimate whether the peer is a competent contributor. The PPSP Peer protocol outlines how a peer is able to communicate with other peers in order to control the advertising and exchange of media data, directly between peers, for a specific stream (swarm), as described in [I-D.ietf-ppsp-problem-statement]. 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). For simplicity, in this document the segments (and subsegments) of media are named Chunks. The media streaming process 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 Gu, et al. Expires May 3, 2012 [Page 3] Internet-Draft Peer Protocol Oct 2011 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 information that should be exchanged between peers using this Peer Protocol includes: 1. ChunkMap indicating which chunks a peer possesses. 2. Required ChunkIDs 3. Peer preferences and status information 4. Signalling and Data Transport protocol negotiation 5. Information that can help improve the performance of PPSP. In this document, a set of concrete information that needs to be exchanged between peers is introduced, together with the messages to convey such information. This documents describes the PPSP Peer protocol and how it 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. This PPSP Peer Protocol proposal presents an early sketch for an extensible protocol that extends the capabilities of PPSP to support adaptive and scalable video. 2. Document Conventions 2.1. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2.2. Terminology The draft uses the terms defined in [I-D.ietf-ppsp-problem-statement], [I-D.gu-ppsp-tracker-protocol] and [I-D.cruz-ppsp-http-peer-protocol]. Additionally, This document uses the following acronyms and definitions frequently in itself: Gu, et al. Expires May 3, 2012 [Page 4] Internet-Draft Peer Protocol Oct 2011 Peer-Peer Messages The Peer Protocol messages enable each Peer to exchange content availability with other Peers and request other Peers for content. Tracker-Peer Messages 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. Connection Tracker The Tracker Node to which the PPSP Peer will connect when it wants to join the PPSP system. Sender Peer A peer that contains the corresponding chunk files requested by leech peer is the Sender peer. Many peers can contain the content, but only one who is contributing the content to the leech peer can be named as Sender peer. Leech Peer A peer that requests the specific media content from other peers. Note that the leech peer can also contribute the downloaded media content (i.e., chunks) even the swarm is not completed, in such case, the leech peer will take on the role of sender peer for downloaded chunks. Chunk Map A peer list that indicates which chunks can be available for leech peer to playback smoothly. 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. Video-on-demand (VoD) The scenario where all clients are allowed to select and watch video content on demand. Gu, et al. Expires May 3, 2012 [Page 5] Internet-Draft Peer Protocol Oct 2011 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. 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 (MVC), multiple views allow the video to be played in 3D when the views are combined together. Base Layer The playable level in Scalable Video Coding (SVC) required by all upper level Enhancements Layers for proper decoding of the video. 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 (i.e., frame rate) or Signal-to-Noise Ratio (SNR) when combined with the playable Base Layer. Continuous Media Media with an inherent notion of time, for example, speech, audio, video, timed text or timed metadata. 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. 3. Protocol Overview Gu, et al. Expires May 3, 2012 [Page 6] Internet-Draft Peer Protocol Oct 2011 3.1. Protocol Architecture The functional entities involved in the PPSP Peer Protocol are 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 contacts a 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. The tracker is a logical entity that maintains the lists of peers storing/exchanging chunks for a specific Live media channel or VoD media streaming content, answers queries from peers and collects information on the activity of peers. A simplified network diagram showing this interaction of tracker and peers is depicted in Figure 1. +-----------------------------------+ | 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 signaling between PPSP Peers and trackers is done using a request/reply mechanism as defined in PPSP Tracker protocol [I-D.gu-ppsp-tracker-protocol]. This protocol can be used to connect peers that are sharing real-time streams of video or offline video, segmented in chunks. As for the streams of video, they can correspond to Live or Video on Demand streaming modes. There are some significant differences between the details of these Gu, et al. Expires May 3, 2012 [Page 7] Internet-Draft Peer Protocol Oct 2011 scenarios, i.e., Live streaming, VoD and offline video. From a high level perspective the overall structure is quite similar. The optimal signaling flow for the different scenarios could also be different, but it depends on the real situation and on the implementer's choice This draft defines a PULL based streaming signaling, as mandatory. However, a PUSH based or hybrid streaming signaling can optionally be considered. For a PULL based Peer Protocol, the steps of signaling for a peer wishing to participate either in a Live streaming or a VoD or offline video is as follows (assuming the leech peer has already obtained from the Tracker a list of peers) and that, in case of traversing a NAT, performed ICE connectivity checks [I-D.li-ppsp-nat-traversal] with candidate peers using PPSP's own authentication method, as described in [I-D.gu-ppsp-tracker-protocol]: 1. The leech peer using PPSP Peer Protocol messages, establishes a connection to at least one of the peers in the Peerlist, based on the known PeerID and Peer IP address. 2. The peer sends request to candidate peers and the request could include one or more of the information described in below: * Request for the data availability of the candidate peer; * Notify its data availability to the candidate peer; * Request for the peer status of the candidate peer; * Notify its peer status to the candidate peer; * Request for additional peerlist; * Transport negotiation, wherein the requesting peer can have two choices: + Only support Mandatory Tranport Protocol; + Providing a list of supported Transport protocol. 3. Finally, the peers exchange the actual chunks of data, using the mechanism/protocol negotiated in the previous step. In terms of Data Transport protocol negotiation, the leech peer can either inform the candidate that it supports a Mandatory Tranport Protocol or provides a list of supported Transport protocols. That Gu, et al. Expires May 3, 2012 [Page 8] Internet-Draft Peer Protocol Oct 2011 there are several options here to negotiate the connection model. The PPSP Peer Protocol may include new mechanisms to negotiate the protocol used to exchange data, or the offer-answer mechanism in SIP [RFC3261] (the IETF protocol for session establishment) along with SDP [RFC4566]. Note also that these mechanisms are not new protocols defined in PPSP, but existing protocols, and would eventually differ between an offline and a Live streaming scenario. Mechanisms such as flow control are handled in the negotiated Data Transport mechanism, not in the Peer Protocol itself. 3.2. Example Call Flow This is a very high-level example of a session in which a leech peer joins a swarm, and retrieves some data (either via blocks or by streaming). The protocol used is indicated for each transaction. Note that not all of the communication shown in this figure are in scope of Peer Protocol, only those request/response followed by Peer Protocol are in scope. Gu, et al. Expires May 3, 2012 [Page 9] Internet-Draft Peer Protocol Oct 2011 +--------+ +--------+ +--------+ +---------+ +--------+ | Player | | Peer 1 | | Portal | | Tracker | | Peer 2 | +--------+ +--------+ +--------+ +---------+ +--------+ | | | | | | | | | | | |------------FIND(optional)--------------->| |<-----------OK--|<----------------Peerlist(optional)-------| | | | | | | |--------GET_CHUNKMAP (Peer protocol)----->| | |<--------------------ChunkMap-------------| | | | | | | |--------GET_STATUS (Peer protocol)------->| | |<----------------PEER2 STATUS-------------| | | | | | | |--TRANSPORT_NEGOTIATION (Peer protocol)-->| | |<-------------CONNECTION SETUP------------| | | | | | |--GET (Chunk)-->|--------GET_CHUNK (Peer protocol)-------->| |<---OK+Chunk----|<-----------------Chunk-------------------| : : : : : | |--------GET_STATUS (Peer protocol)------->| | |<----------------PEER2 STATUS-------------| | | | | | |--GET (Chunk)-->|--------GET_CHUNK (Peer protocol)-------->| |<-----OK+Chunk--|<------------------Chunk------------------| : : : : : | | | | Figure 2: Example Call Flow 3.3. Chunk Scheduling The goal of chunk trading is receiving the stream smoothly (and with small delay) and to cooperate in the distribution procedure. Peers need to exchange information about their current status to enable scheduling decisions. The information exchanged refers to the state of the peer with respect to the flow, i.e., a map of which chunks are needed by a peer to smoothly playback the stream. This task means: 1. sending chunk maps to other nodes with the proper timing, 2. receiving chunk maps from other nodes and merging the information in the local buffer map. 3. besides chunk map exchange, the signaling includes Status/ Request/Select primitives used to trade chunks. Gu, et al. Expires May 3, 2012 [Page 10] Internet-Draft Peer Protocol Oct 2011 The core of the scheduler, not described in this specification, is the algorithm used to choose the chunks to be exchanged and the peers to communicate with. 4. Protocol Architecture The PPSP Peer 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). As shown in example call flow depicted in Figure 2, the Peer protocol only provides signaling messages for obtaining additional peerlist (optionally), query for content availability and negotiation for transfer protocol. Peer protocol may also provide communication for peers to exchange information that can improve system performance. The encoding for the signaling messages is not yet decided. Two encodings are proposed, a Text-based (HTTP/XML) and a Binary-based, described in Appendixes A and B. The authors will raise more discussion on the encoding, and will move the one that gets rough consensus of the PPSP WG to the draft text. In the Appendixes, some considerations are provided on each encoding based on the Mail List discussions. The specific PPSP signaling messages are listed as following: GET_PEERLIST: The GET_PEERLIST message is sent from a leech peer to one or more remote peers in order for a peer to refresh/update the list of active peers in the swarm. When receiving the GET_PEERLIST message, and if the message is well formed and accepted, the peer will search for the requested data and will respond to the leech peer with the peer list with PeerIDs (and respective IP Addresses) of sender peers that can provide the specific content. GET_CHUNKMAP: The GET_CHUNKMAP message is sent from a leech peer to one or more remote peers in order to receive the map of chunks of a content (of a swarm identified by SwarmID) the other peer presently stores. The chunk map returned by the other peer lists ranges of chunks. Gu, et al. Expires May 3, 2012 [Page 11] Internet-Draft Peer Protocol Oct 2011 When receiving the GET_CHUNKMAP message, and if the message is well formed and accepted, the peer will search for the requested data and will respond to the leech peer with the map of chunks it currently stores of the specific content. GET_CHUNK: The GET_CHUNK message is sent from a leech peer to sender peer in order to request the delivery of media content chunks. When receiving the GET_CHUNK message, and if the message is well formed and accepted, the peer will search for the requested data and will respond to the leech peer with the specific chunks the leech peer requested. GET_STATUS: The GET_ STATUS message is sent from a leech peer to one or more remote peers in order to request the corresponding properties of the sender peers. The corresponding properties are enumerated in [draft-gu-ppsp-tracker-protocol], e.g., Caching Size, Bandwidth etc. When receiving the GET_STATUS message, and if the message is well formed and accepted, the peer will search for the requested data and will respond to the leech peer with the specific parameters to the properties the leech peer requested. TRANSPORT_NEGOTIATION: The TRANSPORT_NEGOTIATION message is sent from a leech peer to a sender peer in order to negotiate the underlying transport protocol. Leech peer provide a set of transport protocols it supported to sender peer, and leave send peer to choose its preference. Reusing existing transport protocol to transfer data is recommended. When receiving the TRANSPORT_NEGOTIATION message, and if the message is well formed and accepted, the sender peer will decide the transport protocol and will respond to the leech peer with the specific transport protocol the sender peer preferred. Gu, et al. Expires May 3, 2012 [Page 12] Internet-Draft Peer Protocol Oct 2011 5. Security Consideration 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 peer-peer communication even in the face of a large number of malicious peers. As in typical Peer to Peer network, the most significant security issue is that the peers are untrusted. A peer may announce that it has a specific content, but the content might be just noise or it could be poisoned. A peer could also download a large number of chunks but upload very few of them. This problem can be alleviated by incentive mechanism, the goal of which is to reward honest peers and degrade dishonest peers. 5.1. Authentication 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 authetication mechanism MUST allow the means for negotiating data security layer mechanisms to provide data integrity, data confidentiality, and other services, subject to local policies and security requirements. 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 Gu, et al. Expires May 3, 2012 [Page 13] Internet-Draft Peer Protocol Oct 2011 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 Properties for PEER_STATUS messages will consider pro-incentive parameters, which can enable the improvement of 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). 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. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. Gu, et al. Expires May 3, 2012 [Page 14] Internet-Draft Peer Protocol Oct 2011 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [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. [draft-ietf-p2psip-base] Jennings, C., Lowekamp, B., Ed., Rescorla, E., and H. Schulzrinne, "draft-ietf-p2psip-base-07", February 2010, . 6.2. Informative References [I-D.ietf-ppsp-problem-statement] Zhang, Y., Zong, N., Camarillo, V., Seng, J., and R. Yang, "Problem Statement of P2P Streaming Protocol (PPSP)", Januray 2011, . [I-D.ietf-ppsp-reqs] Zong, N., Zhang, Y., Pascual, V., and C. Williams, "P2P Streaming Protocol (PPSP) Requirements", February 2011, . [I-D.ietf-ppsp-survey] Gu, Y., Zong, N., Zhang, H., Zhang, Y., Camarillo, G., and Y. Liu, "Survey of P2P Streaming Applications", March 2011, . [I-D.gu-ppsp-tracker-protocol] Cruz, R., Nunes, M., Gu, Y., Xia, J., Bryan, D., Taveira, J., and D. Deng, "PPSP Tracker Protocol", March 2011, . [I-D.cruz-ppsp-http-peer-protocol] Gu, Y., Xia, J., Cruz, R., Nunes, M., Bryan, D., and J. Taveira, "PPSP HTTP-Based Peer Protocol", March 2011, . [I-D.li-ppsp-nat-traversal] Li , L., Wang , J., and W. Chen , "PPSP NAT Traversal", March 2011, . [BittorrentSpecification] "Bittorrent Protocol Specification v1.0", February 2010, . Gu, et al. Expires May 3, 2012 [Page 15] Internet-Draft Peer Protocol Oct 2011 Appendix A. Binary Encoding Binary Encoding is an encoding of data in plain text. More precisely, it is an encoding of binary data in a sequence of ASCII- printable characters. Binary Encoding is necessary for transmission of data when the channel or the protocol only allows ASCII-printable characters. The PPSP Peer protocol can be carried on top of IP, UDP, RTP or TCP. But using which layer to carry peer protocol is out of scope in current stage. The peer message header has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PPSP Peer Protocol Token | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: PPSP Peer message header The fields have the following meaning: PPSP Peer Protocol Token: 32 bits A fixed token indicating to the receiver this message is a PPSP Peer Protocol message. The token field is four bytes long. This value MUST be set to 0x50505350, the string "PPSP". Version: 8 bits The version of the PPSP peer protocol being used in the form of a fixed point integer between 0.1 and 25.4. For the version of the protocol described in this document, this field MUST be set to 0.1. The version field is one byte long. Gu, et al. Expires May 3, 2012 [Page 16] Internet-Draft Peer Protocol Oct 2011 Message Types: 8 bits Message types currently have two kinds of value: Request and Response. Reserved: 16 bits Not to be assigned. Reserved values are held for special uses, such as to extend the namespace when it becomes exhausted. Reserved values are not available for general assignment. Transaction ID: 64 bits Identifies the transaction and also allows receivers to disambiguate transactions which are otherwise identical. Responses use the same Transaction ID as the request they correspond to. Transaction IDs are also used for fragment reassembly. Message Length: 32 bits: The length of the message, including header, in bytes. Note if the message is fragmented, this is the length of this message, not the total length of all assembled fragments. A.1. Methods in Peer messages To improve the compatibility of the peer methods, the method fields in message extension MUST be encoded as TLV elements as described below and sketched in Figure 4: To improve the compatibility of the peer methods, the method fields in message extension MUST be encoded as TLV elements as described below and sketched in Figure 4: o Type: A single-octet identifier that defines the type of the parameter represented in this TLV element. o Length: A two-octet field that indicates the length (in octets) of the TLV element excluding the Type and Length fields, and the 8-bit Reserved field between them. Note that this length does not include any padding that is required for alignment. Gu, et al. Expires May 3, 2012 [Page 17] Internet-Draft Peer Protocol Oct 2011 o Value: Variable-size set of octets that contains the specific value for the parameter. In the extensions, the Reserved field SHALL be set to zero and ignored. If a TLV element does not fall on a 32-bit boundary, the last word MUST be padded to the boundary using further bits set to zero. In a peer message, any method extension MUST be placed after the mandatory message header. The extensions MAY be placed in any order. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Value : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Structure of a TLV element Method Type: 8 bits Indicates the method type for the message. There are five method types: GET_PEERLIST, GET_CHUNKMAP, GET_CHUNK, GET_ PROPERTY and TRANSPORT_NEGOTIATION. They are counted from 1 to 5. Method Body Length: 24 bits The length of the method body in bytes. A.1.1. GET_PEERLIST Peerlist is composed of several pairs of Peer ID and Peer IP. Peer ID is a 128 bit integer that is unique in the P2P streaming system. That's no matter there is a centralized tracker or several distributed trackers in the streaming system, a peer ID should be unique. Gu, et al. Expires May 3, 2012 [Page 18] Internet-Draft Peer Protocol Oct 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 00000001 | Method Body Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PEER ID 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PEER IP 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PEER ID 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PEER IP 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: GET_PEERLIST Method Body A.1.2. GET_CHUNKMAP Chunkmap of a content (a swarm identified by SwarmID) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 00000002 | Method Body Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SWARM ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunkmap | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Gu, et al. Expires May 3, 2012 [Page 19] Internet-Draft Peer Protocol Oct 2011 Figure 6: GET_CHUNKMAP Method Body A.1.3. GET_CHUNK [TBD] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 00000003 | Method Body Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SWARM ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Chunk ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: GET_CHUNKMAP Method Body A.1.4. GET_STATUS Several property types are defined in I-D.gu-ppsp-tracker-protocol. But not all of the property types are reasonable to be used in peer protocol. So we just list the following property types. New types can be easily added. +-------------+----------------------------------------------+------+ | PROPERTY | Description | Code | +-------------+----------------------------------------------+------+ | CachingSize | Caching size: available size for caching | 0x01 | | Bandwidth | Bandwidth: available bandwidth | 0x02 | | LinkNumber | Link number: acceptable links for remote | 0x03 | | | peer | | | Certificate | Certificate: certificate of the peer | 0x04 | +-------------+----------------------------------------------+------+ Table 1: Status changed between peers Gu, et al. Expires May 3, 2012 [Page 20] Internet-Draft Peer Protocol Oct 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 00000004 | Method Body Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | STATUS Code| STATUS Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | STATUS Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: GET_STATUS Method Body A.1.5. TRANSPORT_NEGOTIATION To Do: Define mandatory transport protocol and some optional transport protocol. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 00000005 | Method Body Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method Body | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: TRANSPORT_NEGOTIATION Method Body Appendix B. HTTP/XML Encoding The PPSP Peer Protocol HTTP/XML encoding messages follow the request and response standard formats for HTTP Request and Response messages [RFC2616]. B.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: Gu, et al. Expires May 3, 2012 [Page 21] Internet-Draft Peer Protocol Oct 2011 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 Host header follows the standard rules for the HTTP 1.1 Host Header. The Response message is also a standard HTTP Response generated by the HTTP Serving Peer with the following syntax: HTTP/1.1 Content-Lenght: Content-Type: Content-Encoding: 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): *** *** ### ...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 Response message MAY use Content-Encoding entity-header with "gzip" compression scheme [RFC2616] for faster transmission times and less network bandwidth usage. B.2. Method Fields Table B 1 and Table B 2 define the valid string representations for the requests and responses, respectively. These values MUST be treated as case-insensitive. Gu, et al. Expires May 3, 2012 [Page 22] Internet-Draft Peer Protocol Oct 2011 +-----------------------+--------------------------+ | PPSP Request | XML Request Value String | +-----------------------+--------------------------+ | GET_PEERLIST | GET_PEERLIST | | GET_CHUNKMAP | GET_CHUNKMAP | | GET_CHUNK | GET_CHUNK | | PEER_STATUS | PEER_STATUS | | TRANSPORT_NEGOTIATION | TRANSP_NEGO | +-----------------------+--------------------------+ Table B 1: Valid Strings for Requests +----------------------+---------------------+--------------------+ | Response Method Name | HTTP Response | XML Response Value | | | Mechanism | | +----------------------+---------------------+--------------------+ | SUCCESSFUL (OK) | 200 OK | OK | | INVALID SYNTAX | 400 Bad Request | INVALID SYNTAX | | VERSION NOT | 400 Bad Request | VERSION NOT | | SUPPORTED | | SUPPORTED | | 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 B 2: Valid Strings for Responses B.3. Message Processing When a PPSP Peer Protocol message is received in a peer, 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. Gu, et al. Expires May 3, 2012 [Page 23] Internet-Draft Peer Protocol Oct 2011 B.4. GET_PEERLIST Message The GET_PEERLIST message is sent from a client peer to a selected serving peer in order for a peer to refresh/update the list of active peers in the swarm. The Request message uses a HTTP POST method with the following body: GET_PEERLIST *** *** ### The sender MUST properly form the XML body, MUST set the Method string to GET_PEERLIST, MUST set the PeerID to the PeerID of the peer, MUST set the SwarmID to the joined swarm identifier and randomly generate and set the TransactionID value. When receiving the GET_PEERLIST message, and if the message is well formed and accepted, the peer will search for the requested data and will respond to the requesting peer with an HTTP 200 OK message response with a PPSP XML payload SUCCESSFUL, as well as the peer list with PeerIDs (and respective IP Addresses) of peers that can provide the specific content. The response MUST have the same TransactionID value as the request. An example of the Response message structure is the following: Gu, et al. Expires May 3, 2012 [Page 24] Internet-Draft Peer Protocol Oct 2011 OK *** ### *** *** **** *** ### *** *** **** *** ### The element MAY contain multiple child elements. 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 elements and have a string format, and together with the element of numerical integer format, form a set of information related to peer location. Gu, et al. Expires May 3, 2012 [Page 25] Internet-Draft Peer Protocol Oct 2011 B.5. GET_CHUNKMAP Message The GET_CHUNKMAP message is sent from a client peer to a selected serving peer in order to receive the map of chunks of a content (of a swarm identified by SwarmID) the other peer presently stores. The chunk map returned by the other peer lists ranges of chunks. The Request message uses a HTTP POST method with the following body: GET_CHUNKMAP *** *** ### The sender MUST properly form the XML body, MUST set the Method string to GET_CHUNKMAP, MUST set the PeerID to the PeerID of the peer, MUST set the SwarmID to the joined swarm identifier and randomly generate and set the TransactionID value. When receiving the GET_CHUNKMAP message, and if the message is well formed and accepted, the peer will search for the requested data and will respond to the requesting peer with an HTTP 200 OK message response with a PPSP XML payload SUCCESSFUL, as well as the map of chunks it currently stores of the specific content. The response MUST have the same TransactionID value as the request. The Response message is an HTTP 200 OK message with the following body, exemplified for a video component of a media clip: OK ### *** *** ...(base64 string)... Gu, et al. Expires May 3, 2012 [Page 26] Internet-Draft Peer Protocol Oct 2011 The element MAY contain multiple child elements. The element has an attribute "type" that indicates the type of media of the corresponding chunks. A element MAY contain multiple child elements with attributes "from" and "to" corresponding to ranges of contiguous chunks. The "from", "to", and "bitmapSize" attributes are expressed as integer number string format. The content corresponds to the chunk map, and is represented as base64 encoded string. B.6. GET_CHUNK Message The GET_CHUNK message is sent from a client peer to a serving peer in order to request the delivery of media content chunks. The Request message uses a HTTP POST method with the following body: GET_CHUNK *** *** ### The sender MUST properly for the HTTP request for a POST method including the URI path (the Resource) of the chunk. The sender MUST also properly form the XML body, MUST set the Method string to GET_CHUNK, MUST set the PeerID to the PeerID of the peer, MUST set the SwarmID to the joined swarm identifier and randomly generate and set the TransactionID value. Gu, et al. Expires May 3, 2012 [Page 27] Internet-Draft Peer Protocol Oct 2011 +--------------+ +-------------+ | Peer (Leech) | | Peer (Seed) | +--------------+ +-------------+ | POST /path/name/123456789-L0-00000.h264 HTTP/1.1 | | Host: example.net | |------------------------------------------------------>| | | | | | GET_CHUNK | | *** | | *** | | ### | | | | | | | | HTTP/1.1 200 OK | | Content-Type: text/xml | | Transfer-Encoding: chunked | |<------------------------------------------------------| | | | 143 | | | | | | OK | | ### | | | | | | ### | | (### bytes of the video chunk) | | 0 | Figure B 1: Example of GET_CHUNK message sequence (simplified) When receiving the GET_CHUNK message, and if the message is well formed and accepted, the peer will search for the requested data and will respond to the requesting peer with an HTTP 200 OK message response with a PPSP XML payload SUCCESSFUL. The Response message is an HTTP 200 OK message. If The Data Transport Protocol negotiated is also HTTP/XML, the body of the response to GET_CHUNK can be immediately followed by the chunk data transfer, as shown in Figure B 1. The response MUST have the same TransactionID as the request. Gu, et al. Expires May 3, 2012 [Page 28] Internet-Draft Peer Protocol Oct 2011 B.7. PEER_STATUS Message The PEER_STATUS message is sent from a serving peer to a client peer to indicate its participation status. The information conveyed may include information related to chunk trading like "choke" (to inform the other peer of the intention to stop sending data to it) and "unchoke" (to inform the other peer of the intention to start/re- start sending data to it). The Request message uses a HTTP POST method with the following body: PEER_STATUS *** *** ### (choke/unchoke) The sender MUST properly form the XML body, MUST set the Method string to PEER_STATUS, MUST set the PeerID to the PeerID of the peer, MUST set the SwarmID to the joined swarm identifier and randomly generate and set the TransactionID value. When receiving the PEER_STATUS message, and if the message is well formed and accepted, the peer will respond to the requesting peer with an HTTP 200 OK message response with a PPSP XML payload SUCCESSFUL. If the status signal received is "choke" the peer will stop requesting chunks from the other peer until receiving an "unchoke" status signal. The only element currently defined in the request message is , assuming values of "choke" and "unchoke", but, in future, other values may be added. The Response message is an HTTP 200 OK message with the following body. OK ### The response MUST have the same TransactionID value as the request. Gu, et al. Expires May 3, 2012 [Page 29] Internet-Draft Peer Protocol Oct 2011 The only element currently defined in the response message is the , but, in future, other elements may be added, for example, containing statistical data or other primitives for chunk trading negotiation. B.8. TRANSPORT_NEGOTIATION Message To Do: Define message format, mandatory transport protocol and some optional transport protocols. Authors' Addresses Yingjie Gu Huawei No.101 Software Avenue Nanjing, Jiangsu Province 210012 P.R.China Phone: +86-25-56622638 Email: guyingjie@huawei.com Jinwei Xia Huawei Software No.101 Nanjing, Yuhuatai District 210012 China Phone: +86-025-86622310 Email: xiajinwei@huawei.com Rui Santos Cruz IST/INESC-ID/INOV Phone: +351.939060939 Email: rui.cruz@ieee.org Gu, et al. Expires May 3, 2012 [Page 30] Internet-Draft Peer Protocol Oct 2011 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 San Jose, CA, USA, USA Phone: Email: dbryan@ethernot.org Joao P. Taveira ID/INOV Email: joao.silva@inov.pt Gu, et al. Expires May 3, 2012 [Page 31]