idnits 2.17.1 draft-gu-ppsp-tracker-protocol-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 24, 2012) is 4442 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) == Outdated reference: A later version (-15) exists of draft-ietf-ppsp-problem-statement-07 == Outdated reference: A later version (-31) exists of draft-ietf-oauth-v2-23 == Outdated reference: A later version (-23) exists of draft-ietf-oauth-v2-bearer-17 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPSP Rui S. Cruz 3 INTERNET-DRAFT Mario S. Nunes 4 Intended Status: Standards Track IST/INESC-ID/INOV 5 Expires: August 27, 2012 Yingjie Gu 6 Jinwei Xia 7 Huawei 8 David A. Bryan 9 Polycom 10 Joao P. Taveira 11 IST/INOV 12 Deng Lingli 13 China Mobile 14 February 24, 2012 16 PPSP Tracker Protocol (PPSP-TP) 17 draft-gu-ppsp-tracker-protocol-07 19 Abstract 21 This document specifies the Peer-to-Peer Streaming Protocol--Tracker 22 Protocol (PPSP-TP), an application-layer control (signaling) protocol 23 for the exchange of meta information between trackers and peers, such 24 as initial offer/request of participation in multimedia content 25 streaming, content information, peer lists and reports of activity 26 and status. The specification outlines the architecture of the 27 protocol and its functionality, and describes message flows, message 28 processing instructions, message formats, formal syntax and 29 semantics. The PPSP Tracker Protocol enables cooperating peers to 30 form content streaming overlay networks to support near real-time 31 Structured Media content (audio, video, associated text/metadata) 32 delivery, such as adaptive multi-rate, layered (scalable) and multi- 33 view (3D), in live, time-shifted and on-demand modes. 35 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as 43 Internet-Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/1id-abstracts.html 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html 56 Copyright and License Notice 58 Copyright (c) 2012 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 1.1. Use Scenarios and Streaming Modes . . . . . . . . . . . . . 5 75 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 7 76 1.2.1. Enrollment and Bootstrap . . . . . . . . . . . . . . . 7 77 1.2.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . 8 78 1.2.3. Content Information Metadata . . . . . . . . . . . . . 8 79 1.2.4. Authentication, Confidentiality, Integrity . . . . . . 9 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 3. Architectural and Functional View . . . . . . . . . . . . . . . 12 82 4. Messaging Model . . . . . . . . . . . . . . . . . . . . . . . . 14 83 5. Request/Response model . . . . . . . . . . . . . . . . . . . . 14 84 6. The Tracker State Machine . . . . . . . . . . . . . . . . . . . 15 85 6.1. Normal Operation . . . . . . . . . . . . . . . . . . . . . 17 86 6.2. Error Conditions . . . . . . . . . . . . . . . . . . . . . 18 87 7. Protocol Specification . . . . . . . . . . . . . . . . . . . . 19 88 7.1. Messages Syntax . . . . . . . . . . . . . . . . . . . . . . 19 89 7.1.1. Header Fields . . . . . . . . . . . . . . . . . . . . . 20 90 7.1.2. Methods . . . . . . . . . . . . . . . . . . . . . . . . 21 91 7.1.3. Message Bodies . . . . . . . . . . . . . . . . . . . . 21 92 7.1.4. Message Response Codes . . . . . . . . . . . . . . . . 21 93 7.2. Request/Response Syntax and Format . . . . . . . . . . . . 22 94 7.2.1. Semantics of PPSPTrackerProtocol elements . . . . . . . 25 95 7.2.2. Request element in request Messages . . . . . . . . . . 29 96 7.2.3. Response element in response Messages . . . . . . . . . 29 97 8. Request/Response Processing . . . . . . . . . . . . . . . . . . 30 98 8.1. CONNECT Request . . . . . . . . . . . . . . . . . . . . . . 30 99 8.2. DISCONNECT Request . . . . . . . . . . . . . . . . . . . . 32 100 8.3. JOIN Request . . . . . . . . . . . . . . . . . . . . . . . 33 101 8.4. FIND Request . . . . . . . . . . . . . . . . . . . . . . . 35 102 8.5. STAT_REPORT Request . . . . . . . . . . . . . . . . . . . . 37 103 8.6. Error and Recovery conditions . . . . . . . . . . . . . . . 40 104 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 41 105 9.1. Authentication between Tracker and Peers . . . . . . . . . 41 106 9.2. Content Integrity protection against polluting 107 peers/trackers . . . . . . . . . . . . . . . . . . . . . . 42 108 9.3. Residual attacks and mitigation . . . . . . . . . . . . . . 42 109 9.4. Pro-incentive parameter trustfulness . . . . . . . . . . . 42 110 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 111 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 113 12.1. Normative References . . . . . . . . . . . . . . . . . . . 44 114 12.2. Informative References . . . . . . . . . . . . . . . . . . 44 115 Appendix A. PPSP Tracker Protocol XML-Schema . . . . . . . . . . . 46 116 Appendix B. Media Presentation Description (MPD) . . . . . . . . . 46 117 Appendix C. PPSP Requirements Compliance . . . . . . . . . . . . . 49 118 C.1. PPSP Basic Requirements . . . . . . . . . . . . . . . . . . 49 119 C.2. PPSP Tracker Protocol Requirements . . . . . . . . . . . . 50 120 C.3. PPSP Security Considerations . . . . . . . . . . . . . . . 51 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 123 1. Introduction 125 The Peer-to-Peer Streaming Protocol (PPSP) is composed of two 126 protocols: the PPSP Tracker Protocol and the PPSP Peer Protocol. 127 [I-D.ietf-ppsp-problem-statement] specifies that the Tracker Protocol 128 should standardize format/encoding of information and messages 129 between PPSP peers and PPSP trackers and [I-D.ietf-ppsp-reqs] defines 130 the requirements. 132 The PPSP Tracker Protocol provides communication between trackers and 133 peers, by which peers send meta information to trackers, report 134 streaming status and obtain peer lists from trackers. 136 The PPSP architecture requires PPSP peers able to communicate with a 137 tracker in order to participate in a particular streaming content 138 swarm. This centralized tracker service is used by PPSP peers for 139 content registration and location. Content information metafiles 140 (Media Presentation Descriptions) are also stored in the tracker 141 system allowing active peers in the swarm to interpret content 142 structure. 144 The signaling and the media data transfer between PPSP peers is not 145 in the scope of this specification. 147 This document describes the PPSP Tracker protocol and how it 148 satisfies the requirements for the IETF Peer-to-Peer Streaming 149 Protocol (PPSP-TP), in order to derive the implications for the 150 standardization of the PPSP streaming protocols and to identify open 151 issues and promote further discussion. 153 1.1. Use Scenarios and Streaming Modes 155 This section is tutorial in nature and does not contain any normative 156 statements. 158 This section describes some aspects of the use of PPSP-TP. The 159 examples were chosen to illustrate the basic operation, but not to 160 limit what PPSP-TP may be used for. 162 The functional entities related to PPSP protocols are the Client 163 Media Player, the service Portal, the tracker and the peers. The 164 complete description of these entities is not discussed here, as not 165 in the scope the specification. 167 The Client Media Player is a logical entity providing direct 168 interface to the end user at the client device, and includes the 169 functions to select, request, decode and render contents. The Client 170 Media Player may interface with the local peer application using 171 request and response standard formats for HTTP Request and Response 172 messages [RFC2616]. 174 The service Portal is a logical entity typically used for client 175 enrollment and content information publishing, searching and 176 retrieval. 178 The tracker is a logical entity that maintains the lists of PPSP 179 active peers storing and exchanging a specific media content. The 180 tracker also stores the status of active peers in swarms, to help in 181 the selection of appropriate peers for a requesting peer. The 182 tracker can be realized by geographically distributed tracker nodes 183 or multiple server nodes in a data center, increasing the content 184 availability, the service robustness and the network scalability or 185 reliability. The management and locating of content index 186 information are totally internal behaviors of the tracker system, 187 which is invisible to the PPSP Peer 188 [I-D.xiao-ppsp-reload-distributed-tracker]. 190 The peer is also a logical entity embedding the P2P core engine, with 191 a client serving side interface to respond to Client Media Player 192 requests and a network side interface to exchange data and PPSP 193 signaling with trackers and other peers. 195 The streaming technique is chunk-based, i.e., client peers obtain 196 media chunks from serving peers and handle the buffering that is 197 necessary for the playback processes during the download of the media 198 chunks. 200 In Live streaming, all end users are interested in a specific media 201 coming from an ongoing program, which means that all respective peers 202 share nearly the same streaming content at a given point of time. 203 Peers may store the live media for further distribution (known as 204 time-shift TV), where the stored media is distributed in a VoD-like 205 manner. 207 In VoD, different end users watch different parts of the recorded 208 media content during a past event. In this case, each respective 209 peer obtains from other peers the information on media chunks they 210 store and then gets the required media from a selected set of those 211 peers. While watching VoD, an end user can also switch to any place 212 of the content, e.g., skip the credits part, or skip the part that it 213 is not interested in. In this case the respective participating peer 214 may not store all the content segments. From the whole swarm point 215 of view, the participating peers typically store different parts of 216 content. 218 1.2. Assumptions 220 This section is tutorial in nature and does not contain any normative 221 statements. 223 The process used for media streaming distribution assumes a segment 224 (chunk) transfer scheme whereby the original content (that can be 225 encoded using adaptive or scalable techniques) is chopped into small 226 segments (and subsegments) having the following representations: 228 1. Adaptive - alternate representations with different qualities and 229 bitrates; a single represention is non-adaptive; 230 2. Scalable description levels - multiple additive descriptions 231 (i.e., addition of descriptions refine the quality of the video); 232 3. Scalable layered levels - nested dependent layers corresponding to 233 several hierarchical levels of quality, i.e., higher enhancement 234 layers refine the quality of the video of lower layers. 235 4. Scalable multiple views - views correspond to mono (2D) and 236 stereoscopic (3D) videos, with several hierarchical levels of 237 quality. 239 These streaming distribution techniques support dynamic variations in 240 video streaming quality while ensuring support for a plethora of end 241 user devices and network connections. 243 1.2.1. Enrollment and Bootstrap 245 In order to join an existing P2P streaming service and to participate 246 in content sharing, any peer must first locate a tracker, using for 247 example, the following method (as illustrated in Figure 1): 249 +--------+ +--------+ +--------+ +---------+ +--------+ 250 | Player | | Peer 1 | | Portal | | Tracker | | Peer 2 | 251 +--------+ +--------+ +--------+ +---------+ +--------+ 252 | | | | | 253 |--Page request----------------->| | | 254 |<--------------Page with links--| | | 255 |--Select stream (MPD Request)-->| | | 256 |<-----------------------OK+MPD--| | | 257 |--MPD---------->|--CONNECT-------------------->| | 258 | |<-------------------------OK--| | 259 | |--JOIN----------------------->| | 260 |<-----------OK--|<----------------OK+Peerlist--| | 261 | | | | 262 |-- Get(Chunk) ->|<---------- (Peer protocol) ------------->| 263 |<---- Chunk ----|<-------------------------------- Chunk --| 264 : : : : : 265 Figure 1: A typical PPSP session 267 1. From a service provider provisioning mechanism: this is a typical 268 case used on the provider Super-Seeders (edge caches and/or Media 269 Servers). 270 2. From a web page: a Publishing and Searching Portal may provide 271 tracker location information to end users. 272 3. From the MPD file of a content: this metainfo file must contain 273 information about the address of one or more trackers (that can be 274 grouped by tiers of priority) which are controlling the swarm for 275 that media content. 277 In order to be able to bootstrap, a peer must first obtain a Peer-ID 278 (identity associated with the end user authentication credentials) 279 and any required security certificates or authorization tokens from 280 an enrollment service (end user registration). 282 The specification of the mechanism used to obtain a Peer-ID, 283 certificates or tokens is not in the scope of this document. 285 1.2.2. NAT Traversal 287 It is assumed that all trackers must be in the public Internet and 288 have been placed there deliberately. This document will not describe 289 NAT Traversal mechanisms but the protocol facilitates flexible NAT 290 Traversal techniques, such as those based on ICE [RFC5245], 291 considering that the tracker node may provide NAT traversal services, 292 as a STUN-like tracker. Being a STUN-like tracker, it can discover 293 the reflexive candidate addresses of a peer and make them available 294 in responses to requesting peers, a mechanism named PPSP-ICE in 295 [I-D.li-ppsp-nat-traversal-02]. 297 1.2.3. Content Information Metadata 299 Multimedia contents may consist of several media components (for 300 example, audio, video, and text), each of which might have different 301 characteristics. 303 The representations of a media content correspond to encoded 304 alternative of the same media component, varying from other 305 representations by bitrate, resolution, number of channels, or other 306 characteristics. Each representation consists of one or multiple 307 segments. Segments are the media stream chunks in temporal sequence. 309 These characteristics may be described in a Media Presentation 310 Description (MPD). Examples of MPD for on-demand and Live programs 311 are illustrated in Appendix B. It is envisioned that the content 312 information metadata used in PPSP may align with the MPD format of 313 ISO/IEC 23009-1 [ISO.IEC.23009-1]. 315 1.2.4. Authentication, Confidentiality, Integrity 317 Channel-oriented security should be used in the communication between 318 peers and tracker, such as the Transport Layer Security (TLS) to 319 provide privacy and data integrity. HTTP/1.1 over TLS (HTTPS) 320 [RFC2818] is the preferred approach for preventing disclosure of peer 321 critical information via the communication channel. 323 Due to the transactional nature of the communication between peers 324 and tracker a method for adding authentication and data security 325 services via replaceable mechanisms should be employed. One such 326 method is the OAuth 2.0 Authorization [I-D.ietf-oauth-v2] with bearer 327 token, providing the peer with the information required to 328 successfully utilize the access token to make protected requests to 329 the tracker [I-D.ietf-oauth-v2-bearer]. 331 2. Terminology 333 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 334 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 335 document are to be interpreted as described in RFC 2119 [RFC2119]. 337 This draft uses terms defined in [I-D.ietf-ppsp-problem-statement] 338 and in [I-D.xiao-ppsp-reload-distributed-tracker]. 340 Absolute Time: Absolute time is expressed as ISO 8601 341 [ISO.8601.2004] timestamps, using zero UTC offset (GMT). Fractions 342 of a second may be indicated. Example for December 25, 2010 at 14h56 343 and 20.25 seconds: basic format 20101225T145620.25Z or extended 344 format 2010-12-25T14:56:20.25Z. 346 Adaptive Streaming: Multiple alternate representations (different 347 qualities and bitrates) of the same media content co-exist for the 348 same streaming session; each alternate representation corresponds to 349 a different media quality level; peers can choose among the 350 alternate representations for decode and playback. 352 Base Layer: The playable representation level in Scalable Video 353 Coding (SVC) required by all upper level Enhancements Layers for 354 proper decoding of the video. 356 Chunk: A chunk is a generic term used whenever no ambiguity is 357 raised, to refer to a segment or a subsegment of partitioned 358 streaming media. 360 Complementary Representation: Representation in a set of 361 representations which have inter-representation dependencies and 362 which when combined result in a single representation for decoding 363 and presentation. 365 Connection Tracker: The tracker node to which the PPSP peer will 366 connect when it wants to get registered and join the PPSP system. 368 Continuous media: Media with an inherent notion of time, for 369 example, speech, audio, video, timed text or timed metadata. 371 Enhancement Layer: Enhancement differential quality level 372 (complementary representation) in Scalable Video Coding (SVC) used to 373 produce a higher quality, higher definition video in terms of space 374 (i.e., image resolution), time (i.e., frame rate) or Signal-to-Noise 375 Ratio (SNR) when combined with the playable Base Layer [ITU-T.H.264]. 377 Join Time: Join time is the absolute time when a peer registers on a 378 tracker. This value is recorded by the tracker and is used to 379 calculate Online Time. 381 Live streaming: The scenario where all clients receive streaming 382 content for the same ongoing event. The lags between the play points 383 of the clients and that of the streaming source are small. 385 Media Component: An encoded version of one individual media type 386 such as audio, video or timed text with specific attributes, e.g., 387 bandwidth, language, or resolution. 389 Media Presentation Description (MPD): Formalized description for a 390 media presentation, i.e., describes the structure of the media, 391 namely, the representations, the codecs used, the segments (chunks), 392 and the corresponding addressing scheme. 394 Method: The method is the primary function that a request from a 395 peer is meant to invoke on a tracker. The method is carried in the 396 request message itself. 398 Online Time: Online Time shows how long the peer has been in the P2P 399 streaming system since it joins. This value indicates the stability 400 of a peer, and it is calculated by tracker when necessary. 402 Peer: A peer refers to a participant in a P2P streaming system that 403 not only receives streaming content, but also stores and uploads 404 streaming content to other participants. 406 Peer-ID: Unique identifier for the peer. The Peer-ID and any 407 required security certificates are obtained from an offline 408 enrollment server. 410 Peer-Peer Messages (i.e., Peer Protocol): The Peer Protocol messages 411 enable each peer to exchange content availability with other peers 412 and request other peers for content. 414 PPSP: The abbreviation of Peer-to-Peer Streaming Protocols. PPSP 415 protocols refer to the key signaling protocols among various P2P 416 streaming system components, including the tracker and peers. 418 Representation: Structured collection of one or more media 419 components. 421 Request: A message sent from a peer to a tracker, for the purpose of 422 invoking a particular operation. 424 Response: A message sent from a tracker to a peer, for indicating 425 the status of a request sent from the peer to the tracker. 427 Scalable Streaming: With Multiple Description Coding (MDC), multiple 428 additive descriptions (that can be independently played-out) to 429 refine the quality of the video when combined together. With 430 Scalable Video Coding (SVC), nested dependent enhancement layers 431 (hierarchical levels of quality), refine the quality of lower layers, 432 from the lowest level (the playable Base Layer). With Multiple View 433 Coding (MVC), multiple views allow the video to be played in 3D when 434 the views are combined together. 436 Segment: A segment is a resource that can be identified, by an ID or 437 an HTTP-URL and possibly a byte-range, and is included in the MPD. 438 The segment is a basic unit of partitioned streaming media, which is 439 used by a peer for the purpose of storage, advertisement and exchange 440 among peers. 442 Subsegment: Smallest unit within segments which may be indexed at 443 the segment level. 445 Swarm: A swarm refers to a group of peers sharing the same content 446 (e.g., video/audio program, digital file, etc.) at a given time. 448 Swarm-ID: Unique identifier for a swarm. It is used to describe a 449 specific resource shared among peers. 451 Tracker: A tracker refers to a centralized logical directory service 452 used to communicate with PPSP Peers for content registration and 453 location, which maintains the lists of PPSP peers storing segments 454 for a specific live content channel or streaming media and answers 455 queries from PPSP peers. 457 Tracker-Peer Messages (i.e., Tracker Protocol): The Tracker Protocol 458 messages provide communication between peers and trackers, by which 459 peers provide content availability, report streaming status and 460 request peer lists from trackers. 462 Video-on-demand (VoD): A kind of application that allows users to 463 select and watch video content on demand. 465 3. Architectural and Functional View 467 The PPSP Tracker Protocol architecture uses a two-layer approach 468 i.e., a PPSP-TP messaging layer and a PPSP-TP request/response layer. 470 The PPSP-TP messaging layer deals with the underlying transport 471 protocol and the asynchronous nature of the interactions between 472 tracker and peers. 474 The PPSP-TP request/response layer deals with the interactions 475 between tracker and peers using Method and Response codes (see 476 Figure 2). 478 The transport layer is responsible for the actual transmission of 479 requests and responses over network transports, including the 480 determination of the connection to use for a request or response when 481 using a connection-oriented transport like TCP, or TLS [RFC5246] over 482 it. 483 +----------------------+ 484 | Application | 485 +----------------------+ 486 +----------------------+ 487 | Request/Response | 488 |----------------------| PPSP-TP 489 | Messages | 490 +----------------------+ 491 +----------------------+ 492 | TRANSPORT | 493 +----------------------+ 495 Figure 2: Abstract layering of PPSP-TP 497 The functional entities involved in the PPSP Tracker Protocol are 498 trackers and peers (which may support different capabilities). 500 Peers correspond to devices that actually participate in sharing a 501 media content and are organized in (various) swarms corresponding 502 each swarm to the group of peers streaming that content at any given 503 time. Each peer stores chunks of the media content, called segments 504 (or subsegments), and contacts the tracker to advertise which 505 information it has available. When a peer wishes to obtain 506 information about the swarm, it contacts the tracker to find other 507 peers participating in that specific swarm. 509 The tracker is a logical entity that maintains the lists of peers 510 storing chunks for a specific Live media channel or media streaming 511 content, answers queries from peers and collects information on the 512 activity of peers. While a tracker may have an underlying 513 implementation consisting of more than one physical node, logically 514 the tracker can most simply be thought of as a single element, and in 515 this document, it will be treated as a single logical entity. 517 The Tracker Protocol is not used to exchange actual content data 518 (either VoD or Live streaming) with peers, but information about 519 which peers can provide which pieces of content. 521 When a peer wants to receive streaming of a selected content: 523 1. Peer connects to a local connection tracker and joins a swarm. 524 2. Peer acquires a list of peers from the connection tracker. 525 3. Peer exchanges its content availability with the peers on the 526 obtained peer list. 527 4. Peer identifies the peers with desired content. 528 5. Peer requests for the content from the identified peers. 530 When a peer wants to share streaming of certain content with other 531 peers: 533 1. Peer connects to the connection tracker. 534 2. Peer sends information to the connection tracker about the swarm 535 it belongs to (joins), plus streaming status and/or content 536 availability. 538 A P2P streaming process is summarized in Figure 3. 540 +-----------------------------------+ 541 | Tracker | 542 +-----------------------------------+ 543 ^ | ^ 544 connect/ | | | 545 join/ | | peer list | status 546 find/ | | | 547 disconnect | | | 548 | V | 549 +-------------+ +------------+ 550 | Peer 1 |<------------->| Peer 2 | 551 +-------------+ content info/ +------------+ 552 data requests 554 Figure 3: A PPSP streaming process 556 4. Messaging Model 558 The messaging model of PPSP-TP is based on the exchange of messages 559 that follow the syntax and semantics of the current HTTP/1.1 560 specification [RFC2616]. The exchange of messages is envisioned to 561 be performed over a stream-oriented reliable transport protocol, like 562 TCP. 564 PPSP-TP is a text-based protocol, uses the UTF-8 character set 565 [RFC3629] and the protocol messages are either requests from client 566 peers to a tracker server, or responses from a tracker server to 567 client peers. 569 5. Request/Response model 571 PPSP-TP request and response semantics are carried as entities 572 (header and body) in PPSP-TP messages which correspond to either 573 HTTP/1.1 request methods or HTTP/1.1 response codes, respectively. 575 Requests are sent, and responses returned to these requests. A 576 single request generates a single response (neglecting fragmentation 577 of messages in transport). 579 The response codes are consistent with HTTP/1.1 response codes, 580 however, not all HTTP/1.1 response codes are used for the PPSP-TP 581 (section 7). 583 The Request Messages of the protocol, are listed in Table 1: 585 +---------------+ 586 | PPSP Tracker | 587 | Req. Messages | 588 +---------------+ 589 | CONNECT | 590 | DISCONNECT | 591 | JOIN | 592 | FIND | 593 | STAT_REPORT | 594 +---------------+ 596 Table 1: Request Messages 598 CONNECT: This request message is used when a peer registers in the 599 tracker. The tracker records the Peer-ID, connect-time (referenced 600 to the absolute time), peer IP addresses and link status. 602 DISCONNECT: This request message is used when the peer intends to no 603 longer participate in a specific swarm, or in all swarms. The 604 tracker deletes the corresponding activity records related to the 605 peer (including its status and all content status for the 606 corresponding swarms). 608 JOIN: This request message is used for a peer to notify the tracker 609 that it wishes to participate in a swarm. The tracker records the 610 content availability, i.e., adds the peer to the peers list for the 611 swarm. On receiving a JOIN message, the tracker first checks the 612 PeerMode type and then decides the next step (more details are 613 referred in section 8.3). 615 FIND: This request message allows a peer to request to the tracker 616 the peer list for a specific content representation or specific 617 chunks of a media component in a swarm, before it can request the 618 content from the peers. On receiving a FIND message, the tracker 619 finds the peers, listed in content status of the specified swarm, 620 that can satisfy the requesting peer's requirements, returning the 621 list to the requesting peer. To create the peer list, the tracker 622 may take peer status, capabilities and peers priority into 623 consideration. Peer priority may be determined by network topology 624 preference, operator policy preference, etc. 626 STAT_REPORT: This request message allows the exchange of statistic 627 and status data between an active peer and a tracker to improve 628 system performance. This request message is sent periodically to the 629 tracker. 631 6. The Tracker State Machine 633 The state machine for the tracker is very simple, as shown in 634 Figure 4. 635 Peer-ID registrations represent a dynamic piece of state maintained 636 by the network. 638 +------+ +---------+ +------------+ 639 | INIT |------------>| STARTED |----------->| TERMINATED | 640 +------+ +---------+ +------------+ 642 Figure 4: Tracker State Machine 644 When there are no peers registered in the tracker, the state machine 645 is in the INIT state. When the first peer is registered with its 646 Peer-ID, the state machine moves from INIT to STARTED. 648 As long as there is at least one active registration of a Peer-ID, 649 the state machine remains in the STARTED state. When the last Peer- 650 ID is removed, the state machine transitions to TERMINATED. From 651 there, it immediately transitions back to the INIT state. Because of 652 that, the TERMINATED state here is transient. 654 In addition to this state machine, each registered Peer-ID is modeled 655 with its own transaction state machine (Figure 5), instantiated per 656 Peer-ID registered in the tracker, and deleted when it is removed. 657 Unlike the state machine for the Peer-ID registration, which exists 658 even when no Peer-IDs are registered, the per-Peer-ID transaction 659 state machine is instantiated when the Peer-ID is registered, and 660 deleted when the Peer-ID is removed. 662 This allows for an implementation optimization whereby the tracker 663 can destroy the objects associated with the per-Peer-ID transaction 664 state machine once it enters the TERMINATE state (Figure 5). 666 +-------+ rcv CONNECT 667 | START | --------------- (1) 668 +-------+ snd OK response 669 +-----------+ | strt init timer 670 | TERMINATE | | 671 +-----------+ | ---- rcv FIND 672 ^ | / \ or 673 | | | (A) | rcv CONNECT 674 rcv DISCONNECT (nil) | v v | or 675 ---------------- (5) | +------------+ / rcv STAT_REPORT 676 snd OK response | | PEER |-- --------------- 677 stop track timer | | REGISTERED | snd error 678 clean peer info | +------------+ rst init timer 679 del registration | | ^ | 680 | | | | rcv JOIN 681 on timeout | | | | ----------------- (2) 682 ---------------- (C) | | | | snd OK (PeerList) 683 clean peer info | / / / stop init timer 684 del registration +<------- / / strt track timer 685 | / / 686 rcv DISCONNECT (x) | (6)/ / rcv FIND or JOIN 687 ---------------- (6) | / / ----------------- (3) 688 snd OK response \ / / ---- snd OK (PeerList) 689 ---- \ | / / \ rst track timer 690 / \ \ | | | | 691 rcv CONNECT | (B) | | | | | | rcv STAT_REPORT 692 ----------- | v | | v v | rcv DISCONNECT (x) 693 snd error \ +--------------+ / ------------------ (4) 694 rst track timer ----| TRACKING |---- snd OK response 695 +--------------+ rst track timer 697 Figure 5: Per-Peer-ID Transaction State Machine 699 When a new Peer-ID is added, the per-Peer-ID state machine for it is 700 instantiated, and it moves into the PEER REGISTERED state. Because of 701 that, the START state here is transient. 703 When the Peer-ID is no longer bound to a registration, the per-Peer- 704 ID state machine moves to the TERMINATE state, and the state machine 705 is destroyed. 707 During the life time of streaming activity of a peer, the per-Peer-ID 708 transaction state machine progresses from one state to another in 709 response to various events. The events that may potentially advance 710 the state include: 712 o Reception of CONNECT, JOIN, FIND, DISCONNECT and STAT_REPORT 713 messages, or 714 o Timeout events. 716 The state diagram in Figure 5 illustrates state changes, together 717 with the causing events and resulting actions. Specific error 718 conditions are not shown in the state diagram. 720 6.1. Normal Operation 722 On normal operation the process consists of the following steps: 724 1) When a CONNECT message is received from a peer, if successfully 725 authenticated and validated, the tracker registers the Peer-ID and 726 associated information (IP addresses), sends the response of 727 successful registration to peer and starts the "init timer" 728 waiting for a new message from the peer. 730 2) While PEER REGISTERED, when a JOIN message is received with valid 731 swarm information, the tracker stops the "init timer", starts the 732 "track timer" and sends the response of successful join to the 733 peer. The response MAY contain the appropriate list of peers in 734 the swarm, depending on PeerMode (section 8.3). A successful 735 first JOIN starts the TRACKING state associated with the peer-ID 736 for the requested swarm. 738 3) While TRACKING, a JOIN or FIND message received with valid swarm 739 information from the peer resets the "track timer" and is 740 responded with a successful condition, either for the JOIN to (an 741 additional) swarm or for including the appropriate list of peers 742 for the scope in the FIND request. 744 4) While TRACKING, a DISCONNECT(x) message received from the peer, 745 containing a valid x=Swarm-ID resets the "track timer" and is 746 responded with a successful condition. The tracker cleans the 747 information associated with the participation of the Peer-ID in 748 the specified swarm(s). 750 In TRACKING state a STAT_REPORT message received from the peer 751 resets the "track timer" and is responded with a successful 752 condition. The STAT_REPORT message MAY contain information related 753 with Swarm-IDs to which the peer is joined. 755 5) From either PEER REGISTERED or TRACKING states a DISCONNECT(x) 756 message received from the peer, where x=nil, the tracker stops the 757 "track timer", cleans the information associated with the 758 participation of the Peer-ID in the the swarm(s) joined, responds 759 with a successful condition, deletes the registration of the Peer- 760 ID and transitions to TERMINATED state for that Peer-ID. 762 6) From TRACKING state a DISCONNECT(x) message received from the 763 peer, where x=ALL or x=Swarm-ID is the last swarm, the tracker 764 stops the "track timer", cleans the information associated with 765 the participation of the Peer-ID in the the swarm(s) joined, 766 responds with a successful condition and transitions to PEER 767 REGISTERED state. 769 6.2. Error Conditions 771 Peers MUST NOT generate protocol elements that are invalid. 772 However, several situations of a peer may lead to abnormal 773 conditions in the interaction with the tracker. The situations 774 may be related with peer malfunction or communications errors. 775 The tracker reacts to the abnormal situations depending on its 776 current state related to a peer-ID, as follows: 778 A) At the PEER REGISTERED state (while the "init timer" has not 779 expired) receiving FIND, CONNECT or STAT_REPORT messages from the 780 peer is considered an error condition. The tracker responds with 781 error code 403 Forbidden (described in section 7), and resets the 782 "init timer" one last time. 784 B) At the TRACKING state (while the "track timer" has not expired) 785 receiving a CONNECT message from the peer is considered an error 786 condition. The tracker responds with error code 403 Forbidden 787 (described in section 7), and resets the "track timer". 789 NOTE: This situation may correspond to a malfunction at the peer 790 or to malicious conditions. A preventive measure would be to 791 reset the "track timer" one last time and if no valid message is 792 received proceed to TERMINATE state for the Peer-ID by de- 793 registering the peer and cleaning all peer information. 795 C) Without receiving messages from the peer, either from PEER 796 REGISTERED sate (init timer) or TRACKING state (track timer), on 797 timeout the tracker cleans all the information associated with the 798 Peer-ID in all swarms it was joined, deletes the registration, and 799 transitions to TERMINATE state for that Peer-ID. The same action 800 is taken if no valid message is received at the PEER REGISTERED 801 state after the last "init timer" expires. 803 7. Protocol Specification 805 7.1. Messages Syntax 807 PPSP-TP messages use the generic message format of RFC 5322 [RFC5322] 808 for transferring the payload of the message (Requests and 809 Responses). 811 PPSP-TP messages consist of a start-line, one or more header fields, 812 an empty line indicating the end of the header fields, and, when 813 applicable, a message-body. 815 The start-line, each message-header line, and the empty line MUST be 816 terminated by a carriage-return line-feed sequence (CRLF). Note that 817 the empty line MUST be present even if the message-body is not. 819 The PPSP-TP message and header field syntax is identical to HTTP/1.1 820 [RFC2616]. 822 A Request message is a standard HTTP/1.1 message starting with a 823 Request-Line generated by the HTTP client peer. The Request-Line 824 contains a method name, a Request-URI, and the protocol version 825 separated by a single space (SP) character. 827 Request-Line = 828 Method SP Request-URI SP HTTP-Version CRLF 830 A Request message example is the following: 832 / HTTP/1.1 833 Host: 834 Content-Lenght: 835 Content-Type: 836 Authorization: 838 [Request_Body] 840 The HTTP Method token and Request-URI (the Resource) identifies the 841 resource upon which to apply the operation requested. 843 The Response message is also a standard HTTP/1.1 message starting 844 with a Status-Line generated by the tracker. The Status-Line 845 consists of the protocol version followed by a numeric Status-Code 846 and its associated Reason-Phrase, with each element separated by a 847 single SP character. 849 Status-Line = 850 HTTP-Version SP Status-Code SP Reason-Phrase CRLF 852 A Response message example is the following: 854 HTTP/1.1 855 Content-Lenght: 856 Content-Type: 857 Content-Encoding: 859 [Response_Body] 861 The Status-Code element is a 3-digit integer result code that 862 indicates the outcome of an attempt to understand and satisfy a 863 request. 865 The Reason-Phrase element is intended to give a short textual 866 description of the Status-Code. 868 7.1.1. Header Fields 870 The header fields are identical to HTTP/1.1 header fields in both 871 syntax and semantics. 873 Some header fields only make sense in requests or responses. If a 874 header field appears in a message not matching its category (such as 875 a request header field in a response), it MUST be ignored. 877 The Host request-header field in the request message follows the 878 standard rules for the HTTP/1.1 Host header. 880 The Content-Type entity-header field MUST be used in requests and 881 responses containing message-bodies to define the Internet media type 882 of the message-body. 884 The Content-Encoding entity-header field MAY be used in response 885 messages with "gzip" compression scheme [RFC2616] for faster 886 transmission times and less network bandwidth usage. 888 The Content-Length entity-header field MUST be used in messages 889 containing message-bodies to locate the end of each message in a 890 stream. 892 The Authorization header field in the request message allows a peer 893 to authenticate itself with a tracker, containing authentication 894 information. 896 7.1.2. Methods 898 PPSP-TP uses HTTP/1.1 POST method token for all request messages. 900 7.1.3. Message Bodies 902 PPSP-TP requests MUST contain message-bodies. 904 PPSP-TP responses MAY include a message-body. 906 If the message-body has undergone any encoding such as compression, 907 then this MUST be indicated by the Content-Encoding header field; 908 otherwise, Content-Encoding MUST be omitted. 910 If applicable, the character set of the message body is indicated as 911 part of the Content-Type header-field, and the default value for 912 PPSP-TP messages is "UTF-8". 914 7.1.4. Message Response Codes 916 The response codes in PPSP-TP response messages are consistent with 917 HTTP/1.1 response status-codes. However, not all HTTP/1.1 response 918 status-codes are appropriate for PPSP-TP, and only those that are 919 appropriate are given here. Other HTTP/1.1 response codes SHOULD NOT 920 be used in PPSP-TP. 922 The class of the response is defined by the first digit of the 923 Status-Code. The last two digits do not have any categorization 924 role. For this reason, any response with a Status-Code between 200 925 and 299 is referred to as a "2xx response", and similarly to the 926 other supported classes: 928 2xx: Success -- the action was successfully received, understood, and 929 accepted; 930 4xx: Peer Error -- the request contains bad syntax or cannot be 931 fulfilled at this tracker; 932 5xx: Tracker Error -- the tracker failed to fulfill an apparently 933 valid request; 935 The valid response codes are the following (Status-Code Reason- 936 Phrase): 938 200 OK -- The request has succeeded. The information returned with 939 the response describes or contains the result of the action; 941 400 Bad Request -- The request could not be understood due to 942 malformed syntax. 944 401 Unauthorized -- The request requires authentication. 946 403 Forbidden -- The tracker understood the request, but is refusing 947 to fulfill it. The request SHOULD NOT be repeated. 949 404 Not Found -- This status is returned if the tracker did not find 950 anything matching the Request-URI. 952 408 Request Timeout -- The peer did not produce a request within the 953 time that the tracker was prepared to wait. 955 411 Length Required -- The tracker refuses to accept the request 956 without a defined Content-Length. The peer MAY repeat the request 957 if it adds a valid Content-Length header field containing the 958 length of the message-body in the request message. 960 414 Request-URI Too Long -- The tracker is refusing to service the 961 request because the Request-URI is longer than the tracker is 962 willing to interpret. This rare condition is likely to occur 963 when the tracker is under attack by a client attempting to 964 exploit security holes. 966 500 Internal Server Error -- The tracker encountered an unexpected 967 condition which prevented it from fulfilling the request. 969 503 Service Unavailable -- The tracker is currently unable to handle 970 the request due to a temporary overloading or maintenance 971 condition. 973 7.2. Request/Response Syntax and Format 975 The message-body for Requests and Responses requiring it, is encoded 976 in XML. 978 The XML message-body MUST begin with an XML declaration line 979 specifying the version of XML being used and indicating the character 980 encoding, that SHOULD be "UTF-8". The root element MUST be 981 PPSPTrackerProtocol. 983 The generic format of a Request is the following: 985 986 987 988 989 990 991 992 993 994 995 996 998 The generic format of a Response is the following: 1000 1001 1002 1003 1004 1005 1006 1008 The Request element MUST be present in requests and corresponds to 1009 the request method type for the message. 1011 The Response element MUST be present in responses and corresponds to 1012 the response method type of the message. 1014 The element TransactionID MUST be present in requests to uniquely 1015 identify the transaction. Responses to completed transactions use 1016 the same TransactionID as the request they correspond to. 1018 The version of PPSP-TP being used is indicated by the attribute 1019 @version of the root element. 1021 All Request messages MUST contain a PeerID element to uniquely 1022 identify the peer (Peer-ID) in the network. 1024 The PeerID information may be present on the following levels: 1026 - On PPSPTrackerProtocol level in PPSPTrackerProtocol.PeerID element. 1027 For details refer to 7.2.1 Table 2. 1029 - On PeerGroup level in PeerGroup.PeerInfo.PeerID element. For 1030 details refer to 7.2.1 Table 3. 1032 The SwarmID element MUST be be present in JOIN, FIND and DISCONNECT 1033 requests. The SwarmID element MUST be present in JOIN and FIND 1034 responses. Details of usage in 8.2, 8.3 and 8.4. 1036 The SwarmID information may be present on the following levels: 1038 - On PPSPTrackerProtocol level in PPSPTrackerProtocol.SwarmID 1039 element. For details refer to 7.2.1 Table 2. 1041 - On StatisticsGroup level in StatisticsGroup.Stat.SwarmID element. 1042 For details refer to 7.2.1 Table 5. 1044 The PeerMode element MUST be present in JOIN requests. Details of 1045 usage in 8.3. 1047 The PeerMode information may be present on the following levels: 1049 - On PPSPTrackerProtocol level in PPSPTrackerProtocol.PeerMode 1050 element. For details refer to 7.2.1 Table 2. 1052 - On PeerGroup level in PeerGroup.PeerMode element. For details refer 1053 to 7.2.1 Table 5. 1055 The PeerNum element MUST be present in JOIN requests and MAY contain 1056 the attribute @abilityNAT to inform the tracker on the preferred type 1057 of peers, in what concerns their NAT traversal situation, to be 1058 returned in a peer list. Details of usage in 8.2, 8.3 and 8.4. 1060 The PeerGroup element MUST be present in CONNECT requests and 1061 responses and MAY be present in responses to JOIN and FIND requests 1062 if the corresponding response returns information about peers. 1063 Details of usage in 8.1, 8.3 and 8.4. 1065 The ContentGroup element MAY be present in requests referencing 1066 content, i.e., JOIN and FIND, if the request includes a content 1067 scope. Details of usage in 8.3 and 8.4. 1069 The StatisticsGroup element MAY be present in STAT_REPORT requests. 1070 Details of usage in 8.5. 1072 The semantics of the attributes and elements within a 1073 PPSPTrackerProtocol root element is described in subsection 7.2.1. 1075 Request and Response processing is provided in section 8 for each 1076 message. 1078 The XML-syntax of the of PPSP-TP XML elements for Requests and 1079 Responses is provided in the XML-Schema of Appendix A. 1081 7.2.1. Semantics of PPSPTrackerProtocol elements 1083 The semantics of PPSPTrackerProtocol elements and attributes are 1084 described in the following tables. 1086 +----------------------+---------+----------------------------------+ 1087 | Element Name or | Use | Description | 1088 | Attribute Name | | | 1089 +----------------------+---------+----------------------------------+ 1090 | PPSPTrackerProtocol | 1 | The root element. | 1091 | @version | M | Provides the version of PPSP-TP. | 1092 | Request | 0...1 | Provides the request method | 1093 | | | and MUST be present in Request. | 1094 | Response | 0...1 | Provides the response method | 1095 | | | and MUST be present in Response. | 1096 | PeerID | 0...1 | Peer Identification. | 1097 | | | MUST be present in Request. | 1098 | SwarmID | 0...1 | Swarm Identification. | 1099 | | | Details in 8.2/8.3/8.4/8.5. | 1100 | PeerMode | 0...1 | Mode of Peer participation in | 1101 | | | a swarm, which can be "LEECH" | 1102 | | | or "SEED". Details in 8.3/8.4. | 1103 | PeerNUM | 0...1 | Maximum peers to be received in | 1104 | | | with capabilities indicated. | 1105 | @abilityNAT | CM | Type of NAT traversal peers, as | 1106 | | | "NoNAT", "STUN","TURN" or "PROXY"| 1107 | @concurrentLinks | CM | Concurrent connectivity level of | 1108 | | | peers, "HIGH", "LOW" or "NORMAL" | 1109 | @onlineTime | CM | Availability or online duration | 1110 | | | of peers, "HIGH" or "NORNMAL" | 1111 | @uploadBWlevel | CM | Upload bandwidth capability of | 1112 | | | peers, "HIGH" or "NORMAL" | 1113 | PeerGroup | 0...1 | Provides information on peers. | 1114 | | | More details in Table 3 | 1115 | ContentGroup | 0...1 | Provides information on content. | 1116 | | | More details in Table 4 | 1117 | StatisticsGroup | 0...1 | Provides statistic data of peer | 1118 | | | and content. Details in Table 5 | 1119 +----------------------+---------+----------------------------------+ 1120 | Legend: | 1121 | Use for attributes: M=Mandatory, OP=Optional, | 1122 | CM=Conditionally Mandatory | 1123 | Use for elements: minOccurs...maxOccurs (N=unbounded) | 1124 | Elements are represented by their name (case-sensitive) | 1125 | Attribute names (case-sensitive) are preceded with an @ | 1126 +-------------------------------------------------------------------+ 1128 Table 2: Semantics of PPSPTrackerProtocol. 1130 +----------------------+---------+----------------------------------+ 1131 | Element Name or | Use | Description | 1132 | Attribute Name | | | 1133 +----------------------+---------+----------------------------------+ 1134 | PeerGroup | 0...1 | Contains description of peers. | 1135 | PeerInfo | 1...N | Provides information on a peer. | 1136 | PeerID | 0...1 | Peer Identification. | 1137 | | | MAY be present in JOIN and FIND | 1138 | | | responses. Details in 8.3/8.4. | 1139 | PeerMode | 0...1 | Mode of Peer participation in | 1140 | | | a swarm, which can be "LEECH" | 1141 | | | or "SEED". | 1142 | | | MAY be present in JOIN and FIND | 1143 | | | responses. Details in 8.3/8.4. | 1144 | PeerAddress | 1...N | IP Address information. | 1145 | @addrType | M | Type of IP address, which can be | 1146 | | | "ipv4" or "ipv6" | 1147 | @priority | CM | The priority of this interface. | 1148 | | | Used for NAT traversal. | 1149 | @type | CM | Describes the address for NAT | 1150 | | | traversal, which can be "HOST" | 1151 | | | "REFLEXIVE" or "PROXY". | 1152 | @connection | OP | Access type ("3G", "ADSL", etc.) | 1153 | @asn | OP | Autonomous System number. | 1154 | @ip | M | IP address value. | 1155 | @port | M | IP service port value. | 1156 +----------------------+---------+----------------------------------+ 1157 | Legend: | 1158 | Use for attributes: M=Mandatory, OP=Optional, | 1159 | CM=Conditionally Mandatory | 1160 | Use for elements: minOccurs...maxOccurs (N=unbounded) | 1161 | Elements are represented by their name (case-sensitive) | 1162 | Attribute names (case-sensitive) are preceded with an @ | 1163 +-------------------------------------------------------------------+ 1165 Table 3: Semantics of PeerGroup. 1167 If STUN-like functions are enabled in the tracker and a PPSP-ICE 1168 method is used, as described in [I-D.li-ppsp-nat-traversal-02], the 1169 attributes @type and @priority MUST be returned with the transport 1170 address candidates in responses to CONNECT, JOIN or FIND requests. 1172 The @asn attribute MAY be used to inform about the network location, 1173 in terms of Autonomous System, for each of the active public network 1174 interfaces of the peer. 1176 The @connection attribute is informative on the type of access 1177 network of the respective interface. 1179 +----------------------+---------+----------------------------------+ 1180 | Element Name or | Use | Description | 1181 | Attribute Name | | | 1182 +----------------------+---------+----------------------------------+ 1183 | ContentGroup | 0...1 | Provides information on content. | 1184 | Representation | 1...N | Describes a component of content.| 1185 | @id | M | Unique identifier for this | 1186 | | | Representation. | 1187 | SegmentInfo | 1 | Provides segment information. | 1188 | @startIndex | M | The index of the first media | 1189 | | | segment in the request scope for | 1190 | | | this Representation. | 1191 | @endIndex | OP | The index of the last media | 1192 | | | segment in the request scope for | 1193 | | | this Representation. | 1194 +----------------------+---------+----------------------------------+ 1195 | Legend: | 1196 | Use for attributes: M=Mandatory, OP=Optional, | 1197 | CM=Conditionally Mandatory | 1198 | Use for elements: minOccurs...maxOccurs (N=unbounded) | 1199 | Elements are represented by their name (case-sensitive) | 1200 | Attribute names (case-sensitive) are preceded with an @ | 1201 +-------------------------------------------------------------------+ 1203 Table 4: Semantics of ContentGroup. 1205 The Representation element describes a component of a content 1206 identified by its attribute @id in the MPD. This element MAY be 1207 present for each component desired in the scope of the JOIN or FIND 1208 request. The scope of each Representation is indicated in the 1209 SegmentInfo element by the attribute @startIndex and, optionally, 1210 @endIndex. 1212 The peer may use this information in JOIN or FIND requests, for 1213 example, to join a swarm starting from a specific point (as is the 1214 case of a live program, by specifying the adequate @startIndex) 1215 and/or find adequate peers in the swarm for that content scope. 1217 An example of on-demand usage is the case of an end-user that 1218 previously watched a content with a certain audio language, then 1219 interrupted for a while (having disconnected) and later continued by 1220 re-joining from that point onwards but selecting a different 1221 available audio language. In this case the JOIN request would 1222 specify the required Representations and the @startIndex for each, 1223 i.e., all the adequate video components and the selected audio 1224 component. An example is illustrated in subsection 8.3. 1226 +----------------------+---------+----------------------------------+ 1227 | Element Name or | Use | Description | 1228 | Attribute Name | | | 1229 +----------------------+---------+----------------------------------+ 1230 | StatisticsGroup | 0...1 | Provides statistic data on peer | 1231 | | | and content. | 1232 | Stat | 1...N | Groups statistics property data. | 1233 | @property | M | The property to be reported. | 1234 | | | Property values in Table 6. | 1235 | SwarmID | 0...1 | Swarm Identification. | 1236 | UploadedBytes | 0...1 | Bytes sent to swarm. | 1237 | DownloadedBytes | 0...1 | Bytes received from swarm. | 1238 | AvailBandwidth | 0...1 | Upstream Bandwidth available. | 1239 | Representation | 0...N | Describes a component of content.| 1240 | @id | CM | Unique identifier for this | 1241 | | | Representation. | 1242 | SegmentInfo | 1...N | Provides segment information by | 1243 | | | segment range. The chunkmap can | 1244 | | | be encoded in Base64 [RFC4648]. | 1245 | @startIndex | CM | The index of the first media | 1246 | | | segment in the chunkmap report | 1247 | | | for this Representation. | 1248 | @endIndex | CM | The index of the last media | 1249 | | | segment in the chunkmap report | 1250 | | | for this Representation. | 1251 | @chunkmapSize| CM | Size of chunkmap reported. | 1252 +----------------------+---------+----------------------------------+ 1253 | Legend: | 1254 | Use for attributes: M=Mandatory, OP=Optional, | 1255 | CM=Conditionally Mandatory | 1256 | Use for elements: minOccurs...maxOccurs (N=unbounded) | 1257 | Elements are represented by their name (case-sensitive) | 1258 | Attribute names (case-sensitive) are preceded with an @ | 1259 +-------------------------------------------------------------------+ 1261 Table 5: Semantics of StatisticsGroup. 1263 The Stat element is used to describe several properties relevant to 1264 the P2P network. These properties can be related with stream 1265 statistics, peer status information and content data information, 1266 like chunkmaps. Each Stat element will correspond to a @property 1267 type and several Stat blocks can be reported in a single STAT_REPORT 1268 message, corresponding to some or all the swarms the peer is actively 1269 involved. 1271 Other properties may be defined, related, for example, with 1272 incentives and reputation mechanisms, like peer online time, or 1273 connectivity conditions, like physical link status, etc. 1275 For that purpose, the Stat element may be extended to provide 1276 additional scheme specific information for new @property groups, new 1277 elements and new attributes. 1279 +-------------------+-------------------------------------+ 1280 | @property | Description | 1281 +-------------------+-------------------------------------+ 1282 | StreamStatistics | Stream statistic values per SwarmID | 1283 | ContentMap | Reports map of chunks the peer has | 1284 | | per Representation of the content | 1285 +-------------------+-------------------------------------+ 1287 Table 6: StatisticsGroup default Stat @property values. 1289 An example of a STAT_REPORT for multiple properties is illustrated in 1290 subsection 8.5. 1292 7.2.2. Request element in request Messages 1294 Table 7 defines the valid string representations for the requests. 1295 These values MUST be treated as case-sensitive. 1297 +----------------------+ 1298 | XML Request Methods | 1299 | String Values | 1300 +----------------------+ 1301 | CONNECT | 1302 | DISCONNECT | 1303 | JOIN | 1304 | FIND | 1305 | STAT_REPORT | 1306 +----------------------+ 1308 Table 7: Valid Strings for Request element of requests. 1310 7.2.3. Response element in response Messages 1312 Table 8 defines the valid string representations for Response 1313 messages that require message-body. These values MUST be treated as 1314 case-sensitive. 1316 Response messages not requiring message-body only use the standard 1317 HTTP/1.1 Status-Code and Reason-Phrase (appended, if appropriate, 1318 with detail phrase, as described in section 8.6). 1320 +-------------------------+---------------------+ 1321 | XML Response Method | HTTP Status-Code | 1322 | String Values | and Reason-Phrase | 1323 +-------------------------+---------------------+ 1324 | SUCCESSFUL | 200 OK | 1325 | AUTHENTICATION REQUIRED | 401 Unauthorized | 1326 +------------------------+----------------------+ 1328 Table 8: Valid Strings for Response element of responses. 1330 SUCCESSFUL: indicates that the request has been processed properly 1331 and the desired operation has completed. The body of the response 1332 message includes the requested information and MUST include the same 1333 TransactionID of the corresponding request. 1335 CONNECT: returns information about the successful registration of 1336 the peer. 1338 DISCONNECT and STAT_REPORT: confirms the success of the requested 1339 operation. 1341 JOIN and FIND: MAY return the list of peers meeting the desired 1342 criteria. 1344 AUTHENTICATION REQUIRED: Authentication is required for the peer 1345 to make the request. 1347 8. Request/Response Processing 1349 When a PPSP-TP message is received some basic processing is 1350 performed, regardless of the message type. 1352 Upon reception, a message is examined to ensure that it is properly 1353 formed. The receiver MUST check that the HTTP message itself is 1354 properly formed, and if not, appropriate standard HTTP errors MUST be 1355 generated. The receiver must also verify that the XML body is 1356 properly formed. In case of error due to malformed messages 1357 appropriate responses MUST be returned, as described in 8.6. 1359 8.1. CONNECT Request 1361 This method is used when a peer registers to the system. The tracker 1362 records the Peer-ID, connect-time, IP addresses and link status. 1364 The peer MUST properly form the XML message-body, set the Request 1365 method to CONNECT, generate and set the TransactionID, and set the 1366 PeerID with the identifier of the peer. The peer SHOULD also include 1367 the IP addresses of its network interfaces in the CONNECT message. 1369 An example of the message-body of a CONNECT Request is the following: 1371 1372 1373 CONNECT 1374 656164657221 1375 12345 1376 1377 1378 1380 1384 1385 1386 1388 When receiving a well-formed CONNECT Request message, the tracker 1389 will first processes the peer authentication information (provided as 1390 Authorization scheme and token in the HTTP message) to check whether 1391 it is valid and that it can connect to the service, and then proceed 1392 to register the peer in the service. In case of success a Response 1393 message with a corresponding response value of SUCCESSFULL will be 1394 generated. 1396 The element PeerInfo MAY contain multiple PeerAddress child elements 1397 with attributes @addrType, @ip, and @port, and optionally @priority 1398 and @type (if PPSP-ICE NAT traversal techniques are used) 1399 corresponding to each of the network interfaces of the peer. 1401 If STUN-like function is enabled in the tracker, the response MAY 1402 include the peer reflexive address [I-D.li-ppsp-nat-traversal-02]. 1404 The response MUST have the same TransactionID value as the request. 1406 An example of a Response message for the CONNECT Request is the 1407 following: 1409 1410 1411 SUCCESSFUL 1412 12345 1413 1414 1415 1420 1421 1422 1424 The Response MUST include a PeerGroup with PeerInfo data that 1425 includes the peer public IP address. If STUN-like function is enabled 1426 in the tracker, the PeerAddress includes the attribute @type with a 1427 value of REFLEXIVE, corresponding to the transport address 1428 "candidate" of the peer. 1430 The tracker MAY also include the attribute @asn with network location 1431 information of the transport address, corresponding to the Autonomous 1432 System Number of the access network provider. 1434 8.2. DISCONNECT Request 1436 This method is used when the peer intends to leave a specific swarm, 1437 or the system, and no longer participate. 1439 The tracker SHOULD delete the corresponding activity records related 1440 with the peer in the corresponding swarms (including its status and 1441 all content status). 1443 The peer MUST properly form the XML message-body, set the Request 1444 method to DISCONNECT, set the PeerID with the identifier of the peer, 1445 randomly generate and set the TransactionID and include the SwarmID 1446 information. 1448 The SwarmID value MUST be either a specific Swarm-ID the peer had 1449 previously joined, the value "ALL" to designate all joined swarms, or 1450 the value "nil" to completely disconnect from the system. 1452 An example of the message-body of a DISCONNECT Request is the 1453 following: 1455 1456 1457 DISCONNECT 1458 656164657221 1459 ALL 1460 12345 1461 1463 In case of success a Response message with a corresponding response 1464 value of SUCCESSFULL will be generated. The response MUST have the 1465 same TransactionID value as the request. 1467 Upon receiving a DISCONNECT message, the tracker cleans the 1468 information associated with the participation of the Peer-ID in the 1469 specified swarm (or in all swarms). 1471 An example of a Response message for the DISCONNECT Request is the 1472 following: 1474 1475 1476 SUCCESSFUL 1477 12345 1478 1480 If the scope of SwarmID in the DISCONNECT request is "nil" the 1481 tracker will also delete the registration of the Peer-ID. 1483 8.3. JOIN Request 1485 This method is used for peers to notify the tracker that they wish to 1486 participate in a particular swarm. 1488 The JOIN message is used when the peer has none or just some chunks 1489 (LEECH), or has all the chunks (SEED) of a content. The JOIN is used 1490 for both on-demand or Live streaming modes. 1492 The peer MUST properly form the XML message-body, set the Request 1493 method to JOIN, set the PeerID with the identifier of the peer, set 1494 the SwarmID with the identifier of the swarm it is interested in, and 1495 randomly generate and set the TransactionID. 1497 An example of the message-body of a JOIN Request is the following: 1499 1500 1501 JOIN 1502 656164657221 1503 1111 1504 12345 1505 5 1509 LEECH 1510 1511 1512 1513 1514 1515 1516 1517 1518 1520 The JOIN request MAY include a PeerNum element to indicate to the 1521 tracker the number of peers to be returned in a list corresponding to 1522 the indicated properties, being @abilityNAT for NAT traversal 1523 (considering that PPSP-ICE NAT traversal techniques may be used), and 1524 optionally @concurrentLinks, @onlineTime and @uploadBWlevel for the 1525 preferred capabilities. 1527 The PeerMode element SHOULD be set to the type of participation of 1528 the peer in the swarm (SEED or LEECH). 1530 In the case of a JOIN to a specific point in a stream the request 1531 SHOULD include a ContentGroup to specify the joining point in terms 1532 of content Representations. The above example of a JOIN request 1533 would be for the case of an end-user that previously watched a 1534 content with a certain audio language, then interrupted for a while 1535 (having disconnected) and later continued by re-joining from that 1536 point onwards but selecting a different available audio language 1537 (Representation with @id="tag6" in the MPD of Appendix B). 1539 When receiving a well-formed JOIN Request the tracker processes the 1540 information to check if it is valid and if the peer can join the 1541 swarm of interest. In case of success a response message with a 1542 Response value of SUCCESSFULL will be generated and the tracker 1543 enters the peer information into the corresponding swarm activity. 1545 In case the PeerMode is SEED, the tracker just responds with a 1546 SUCCESSFUL response and enters the peer information into the 1547 corresponding swarm activity. 1549 In case the PeerMode is LEECH the tracker will search and select an 1550 appropriate list of peers satisfying the conditions requested. The 1551 peer list MUST contain the Peer-IDs and the corresponding IP 1552 Addresses. To create the peer list, the tracker may take peer status 1553 and network location information into consideration, to express 1554 network topology preferences or Operators' policy preferences, with 1555 regard to the possibility of connecting with other IETF efforts such 1556 as ALTO [I.D.ietf-alto-protocol]. 1558 The response MUST have the same TransactionID value as the request. 1560 An example of a Response message for the JOIN Request is: 1562 1563 1564 SUCCESSFUL 1565 12345 1566 1567 1568 956264622298 1569 1571 1572 1573 3332001256741 1574 1576 1577 1578 1580 The Response MUST include a PeerGroup with PeerInfo data that 1581 includes the public IP address of the selected active peers in the 1582 swarm. 1584 The tracker MAY also include the attribute @asn with network location 1585 information of the transport addresses of the peers, corresponding to 1586 the Autonomous System Numbers of the access network provider of each 1587 peer in the list. 1589 8.4. FIND Request 1591 This method allows peers to request to the tracker, whenever needed 1592 and after being joined to a swarm, a new peer list for the swarm or 1593 for specific scope of chunks of a media content Representation of 1594 that swarm. 1596 The peer MUST properly form the XML message-body, set the Request 1597 method to FIND, set the PeerID with the identifier of the peer, set 1598 the SwarmID with the identifier of the swarm the peer is interested, 1599 and optionally, in order to find peers having the specific chunks, 1600 include information about the content. 1602 The peer MUST also generate and set the TransactionID for the 1603 request. 1605 An example of the message-body of a FIND Request is the following: 1607 1608 1609 FIND 1610 656164657221 1611 1111 1612 12345 1613 5 1617 1618 1619 1620 1621 1622 1624 The FIND request MAY include a PeerNum element to indicate to the 1625 tracker the number of peers to be returned in a list corresponding to 1626 the indicated properties, being @abilityNAT for NAT traversal 1627 (considering that PPSP-ICE NAT traversal techniques may be used), and 1628 optionally @concurrentLinks, @onlineTime and @uploadBWlevel for the 1629 preferred capabilities. 1631 In the case of a FIND with a specific scope of a stream content the 1632 request SHOULD include a ContentGroup to specify the content 1633 Representations segment range of interest. 1635 When receiving a well-formed FIND Request the tracker processes the 1636 information to check if it is valid. In case of success a response 1637 message with a Response value of SUCCESSFULL will be generated and 1638 the tracker will include the appropriate list of peers satisfying the 1639 conditions requested. The peer list returned MUST contain the Peer- 1640 IDs and the corresponding IP Addresses. 1642 The tracker may take peer status and network location information 1643 into consideration when selecting the peer list to return, to express 1644 network topology preferences or Operators' policy preferences, with 1645 regard to the possibility of connecting with other IETF efforts such 1646 as ALTO [I.D.ietf-alto-protocol]. 1648 The response MUST have the same TransactionID value as the request. 1650 An example of a Response message for the FIND Request is the 1651 following: 1653 1654 1655 SUCCESSFUL 1656 12345 1657 1658 1659 956264622298 1660 1662 1663 1664 3332001256741 1665 1667 1668 1669 1671 The Response MUST include a PeerGroup with PeerInfo data that 1672 includes the public IP address of the selected active peers in the 1673 swarm. 1675 The tracker MAY also include the attribute @asn with network location 1676 information of the transport addresses of the peers, corresponding to 1677 the Autonomous System Numbers of the access network provider of each 1678 peer in the list. 1680 8.5. STAT_REPORT Request 1682 This method allows the exchange of statistic and status data between 1683 peers and trackers to improve system performance. The method is 1684 initiated by the peer, periodically while active. 1686 The peer MUST properly form the XML message-body, set the Request 1687 method to STAT_REPORT, set the PeerID with the identifier of the 1688 peer, and generate and set the TransactionID. 1690 The report MAY include a StatisticsGroup containing multiple Stat 1691 elements describing several properties relevant to the P2P network. 1692 These properties can be related with stream statistics, peer status 1693 information and content data information, like chunkmaps. 1695 Other properties may be defined, related for example, with incentives 1696 and reputation mechanisms. 1698 In case no StatisticsGroup is included, the STAT_REPORT may be used 1699 as a "keep-alive" message, to prevent the Tracker from de-registering 1700 the peer when timer expired. 1702 An example of the message-body of a STAT_REPORT Request is the 1703 following: 1705 1706 1707 STAT_REPORT 1708 656164657221 1709 12345 1710 1711 1712 1111 1713 512 1714 768 1715 1024000 1716 1717 1718 2222 1719 1024 1720 2048 1721 512000 1722 1723 1724 1111 1725 1726 1728 A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/.... 1729 1730 1731 1732 1734 A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/.... 1735 1736 1739 A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/.... 1740 1741 1742 1743 1744 2222 1745 1746 1748 A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/.... 1749 1750 1751 1752 1754 A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/.... 1755 1756 1757 1758 1759 1761 If the request is valid the tracker process the received information 1762 for future use, and generates a response message with a Response 1763 value of SUCCESSFULL. 1765 The response MUST have the same TransactionID value as the request. 1767 An example of a Response message for the START_REPORT Request is the 1768 following: 1770 1771 1772 SUCCESSFUL 1773 12345 1774 1776 8.6. Error and Recovery conditions 1778 If the peer fails to read the tracker response, the same Request with 1779 identical content, including the same TransactionID, SHOULD be 1780 repeated, if the condition is transient. 1782 The TransactionID on a Request can be reused if and only if all of 1783 the content is identical, including eventual Date/Time information. 1784 Details of the retry process (including time intervals to pause, 1785 number of retries to attempt, and timeouts for retrying) are 1786 implementation dependent. 1788 The tracker SHOULD be prepared to receive a Request with a repeated 1789 TransactionID. 1791 Error situations resulting from the Normal Operation or from abnormal 1792 conditions (section 6.2) MUST be responded with the adequate response 1793 codes, as described here: 1795 If the message is found to be incorrectly formed, the receiver MUST 1796 respond with a 400 (Bad Request) response with an empty message- 1797 body. The Reason-Phrase SHOULD identify the syntax problem in more 1798 detail, for example, "Missing Content-Type header field". 1800 If the version number of the protocol is for a version the receiver 1801 does not supports, the receiver MUST respond with a 400 (Bad 1802 Request) with an empty message-body. Additional information SHOULD 1803 be provided in the Reason-Phrase, for example, "PPSP Version #.#". 1805 If the length of the message does not matches the Content-Length 1806 specified in the message header, or the message is received without 1807 a defined Content-Length, the receiver MUST respond with a 411 1808 (Length Required) response with an empty message-body. 1810 If the Request-URI in a Request message is longer than the tracker 1811 is willing to interpret, the tracker MUST respond with a 414 1812 (Request-URI Too Long) response with an empty message-body. 1814 In the PEER REGISTERED and TRACKING states of the tracker, certain 1815 requests are not allowed (section 6.2). The tracker MUST respond 1816 with a 403 (Forbidden) response with an empty message-body. The 1817 Reason-Phrase SHOULD identify the error condition in more detail, for 1818 example, "Already Connected". 1820 If the tracker is unable to process a Request message due to 1821 unexpected condition, it SHOULD respond with a 500 (Internal Server 1822 Error) response with an empty message-body. 1824 If the tracker is unable to process a Request message for being in an 1825 overloaded state, it SHOULD respond with a 503 (Service Unavailable) 1826 response with an empty message-body. 1828 9. Security Considerations 1830 P2P streaming systems are subject to attacks by malicious/unfriendly 1831 peers/trackers that may eavesdrop on signaling, forge/deny 1832 information/knowledge about streaming content and/or its 1833 availability, impersonating to be another valid participant, or 1834 launch DoS attacks to a chosen victim. 1836 No security system can guarantees complete security in an open P2P 1837 streaming system where participants may be malicious or 1838 uncooperative. The goal of security considerations described here is 1839 to provide sufficient protection for maintaining some security 1840 properties during the tracker-peer communication even in the face of 1841 a large number of malicious peers and/or eventual distrustful 1842 trackers (under the distributed tracker deployment scenario). 1844 Since the protocol uses HTTP to transfer signaling most of the same 1845 security considerations described in RFC 2616 also apply [RFC2616]. 1847 9.1. Authentication between Tracker and Peers 1849 To protect the PPSP-TP signaling from attackers pretending to be 1850 valid peers (or peers other than themselves) all messages received in 1851 the tracker are required to be received from authorized peers. 1853 For that purpose a peer must enroll in the system via a centralized 1854 enrollment server. The enrollment server is expected to provide a 1855 proper Peer-ID for the peer and information about the authentication 1856 mechanisms. The specification of the enrollment method and the 1857 provision of identifiers and authentication tokens is out of scope of 1858 this specification. 1860 A Channel-oriented security mechanism should be used in the 1861 communication between peers and tracker, such as the Transport Layer 1862 Security (TLS) to provide privacy and data integrity. 1864 Due to the transactional nature of the communication between peers 1865 and tracker the method for adding authentication and data security 1866 services can be the OAuth 2.0 Authorization [I-D.ietf-oauth-v2] with 1867 bearer token, which provides the peer with the information required 1868 to successfully utilize an access token to make protected requests to 1869 the tracker [I-D.ietf-oauth-v2-bearer]. 1871 9.2. Content Integrity protection against polluting peers/trackers 1873 Malicious peers may declaim ownership of popular content to the 1874 tracker but try to serve polluted (i.e., decoy content or even 1875 virus/trojan infected contents) to other peers. 1877 This kind of pollution can be detected by incorporating integrity 1878 verification schemes for published shared contents. As content 1879 chunks are transferred independently and concurrently, a 1880 correspondent chunk-level integrity verification MUST be used, 1881 checked with signed fingerprints received from authentic origin. 1883 9.3. Residual attacks and mitigation 1885 To mitigate the impact of sybil attackers, impersonating a large 1886 number of valid participants by repeatedly acquiring different peer 1887 identities, the enrollment server SHOULD carefully regulate the rate 1888 of peer/tracker admission. 1890 There is no guarantee that peers honestly report their status to the 1891 tracker, or serve authentic content to other peers as they claim to 1892 the tracker. It is expected that a global trust mechanism, where the 1893 credit of each peer is accumulated from evaluations for previous 1894 transactions, may be taken into account by other peers when selecting 1895 partners for future transactions, helping to mitigate the impact of 1896 such malicious behaviors. A globally trusted tracker MAY also take 1897 part of the trust mechanism by collecting evaluations, computing 1898 credit values and providing them to joining peers. 1900 9.4. Pro-incentive parameter trustfulness 1902 Property types for STAT_REPORT messages may consider pro-incentive 1903 parameters, which can enable the tracker to improve the performance 1904 of the whole P2P streaming system. 1906 Trustworthiness of these pro-incentive parameters is critical to the 1907 effectiveness of the incentive mechanisms. For example, ChunkMaps 1908 are essential, and need to be accurate. The P2P system should be 1909 designed in a way such that a peer will have the incentive to report 1910 truthfully its ChunkMaps (otherwise it may penalize itself, as in the 1911 case of under-reporting addressed in [prTorrent]). 1913 Furthermore, both the amount of uploaded and downloaded data should 1914 be reported to the tracker to allow checking if there is any 1915 inconsistency between the upload and download report, and establish 1916 an appropriate credit/trust system. Alternatively, exchange of 1917 cryptographic receipts signed by receiving peers can be used to 1918 attest to the upload contribution of a peer to the swarm, as 1919 suggested in [Contracts]. 1921 10. IANA Considerations 1923 There are presently no IANA considerations with this document. 1925 11. Acknowledgments 1927 The authors would like to thank many people for for their help and 1928 comments, particularly: Zhang Yunfei, Liao Hongluan, Roni Even, 1929 Bhumip Khasnabish, Wu Yichuan, Peng Jin, Chi Jing, Zong Ning, Song 1930 Haibin, Chen Wei, Zhijia Chen, Christian Schmidt, Lars Eggert, David 1931 Harrington, Henning Schulzrinne, Kangheng Wu, Martin Stiemerling, 1932 Jianyin Zhang, Johan Pouwelse and Arno Bakker. 1934 The authors would also like to thank the people participating in the 1935 EU FP7 project SARACEN (contract no. ICT-248474) 1936 [refs.saracenwebpage] for contributions and feedback to this 1937 document. 1939 The views and conclusions contained herein are those of the authors 1940 and should not be interpreted as necessarily representing the 1941 official policies or endorsements, either expressed or implied, of 1942 the SARACEN project or the European Commission. 1944 12. References 1946 12.1. Normative References 1948 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1949 Requirement Levels", BCP 14, RFC 2119, March 1997. 1951 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1952 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1953 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1955 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1956 10646", STD 63, RFC 3629, November 2003. 1958 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1959 Encodings", RFC 4648, October 2006. 1961 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1962 (ICE): A Protocol for Network Address Translator (NAT) 1963 Traversal for Offer/Answer Protocols", RFC 5245, April 1964 2010. 1966 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1967 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1969 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1970 October 2008. 1972 [ISO.8601.2004] International Organization for Standardization, "Data 1973 elements and interchange formats - Information interchange 1974 - Representation of dates and times", ISO Standard 8601, 1975 December 2004. 1977 12.2. Informative References 1979 [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", 1980 RFC 1952, May 1996. 1982 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1984 [I-D.ietf-ppsp-reqs] Zong, N., Zhang, Y., Avila, V., Williams, C., 1985 and L. Xiao, "P2P Streaming Protocol (PPSP) 1986 Requirements", draft-ietf-ppsp-reqs-05 (work in progress), 1987 October 2011. 1989 [I-D.ietf-ppsp-problem-statement] Zhang, Y., Zong, N., Camarillo, G., 1990 Seng, J., and Y. Yang, "Problem Statement of P2P Streaming 1991 Protocol (PPSP)", draft-ietf-ppsp-problem-statement-07 1992 (work in progress), November 2011. 1994 [I-D.li-ppsp-nat-traversal-02] Li, L., Wang, J., Chen, W., "PPSP NAT 1995 Traversal", draft-li-ppsp-nat-traversal-02 (work in 1996 progress), July 2011. 1998 [I-D.xiao-ppsp-reload-distributed-tracker] Xiao, L., Bryan, D., Gu, 1999 Y., Tai, X., "A PPSP Tracker Usage for Reload", draft- 2000 xiao-ppsp-reload-distributed-tracker-03 (work in 2001 progress), October 2011. 2003 [I.D.ietf-alto-protocol] Alimi, R., Penno, R., Yang, Y., "ALTO 2004 Protocol", draft-ietf-alto-protocol-10, (work in 2005 progress), October 2011. 2007 [I-D.ietf-oauth-v2] Hammer-Lahav, E., Recordon, D., and D. Hardt, 2008 "The OAuth 2.0 Authorization Protocol," draft-ietf-oauth- 2009 v2-23 (work in progress), January 2012. 2011 [I-D.ietf-oauth-v2-bearer] Jones, M., Hardt, D., and D. Recordon, 2012 "The OAuth 2.0 Authorization Protocol: Bearer Tokens," 2013 draft-ietf-oauth-v2-bearer-17 (work in progress), February 2014 2012. 2016 [MP4REG] MP4REG, The MPEG-4 Registration Authority, URL: 2017 . 2019 [ISO.IEC.23009-1] ISO/IEC, "Information technology -- Dynamic 2020 adaptive streaming over HTTP (DASH) -- Part 1: Media 2021 presentation description and segment formats", ISO/IEC DIS 2022 23009-1, Aug. 2011. 2024 [ITU-T.H.264] ITU-T, "Advanced video coding for generic audiovisual 2025 services," Recommendation H.264 (03/2010), International 2026 Telecommunication Union - Telecommunication 2027 Standardization Sector, Mar. 2010. 2029 [refs.saracenwebpage] "SARACEN Project Website", 2030 http://www.saracen-p2p.eu/. 2032 [prTorrent] Roy, S., Zeng, W., "prTorrent: On Establishment of Piece 2033 Rarity in the BitTorrent Unchoking Algorithm", in IEEE 2034 Ninth International Conference on Peer-to-Peer Computing, 2035 September 2009. 2037 [Contracts] Piatek, M., Venkataramani, A., Yang, R., Zhang, D., 2038 Jaffe, A., "Contracts: Practical Contribution Incentives 2039 for P2P Live Streaming", in NSDI '10: USENIX Symposium on 2040 Networked Systems Design and Implementation, April 2010. 2042 Appendix A. PPSP Tracker Protocol XML-Schema 2044 TO BE ADDED. 2046 Appendix B. Media Presentation Description (MPD) 2048 The MPD file describes a Media Presentation, i.e., a bounded or 2049 unbounded presentation of media content. In particular, it defines 2050 formats to announce resource identifiers for segments and subsegments 2051 (layers in case of SVC, descriptions in case of MDC, or views in case 2052 of 3D) and to provide the context for these identified resources 2053 within a Media Presentation, i.e., describes the structure of the 2054 media, the codecs used (as registered with the MP4 registration 2055 authority [MP4REG]), the segments and the corresponding mapping 2056 within a container file system. 2058 The MPD contains information about the preferred Connection Trackers, 2059 than can be classified in tiers of priority (attribute @tier). 2061 The MPD is a Well-Formed XML Document, encoded as double-byte 2062 Unicode. The XML-Schema of the MPD aligns with ISO/IEC 23009-1 2063 [ISO.IEC.23009-1]. 2065 The following example of MPD is for an on-demand media program 2066 encoded in SVC with two alternative SVC streams, two audio streams 2067 and a text stream. The example SVC stream has one base layer 2068 representation with two complementary enhancement layers for one 2069 video resolution and another SVC stream with a base layer and one 2070 complementary enhancement representation for a higher video 2071 resolution, an audio stream in English and another in Portuguese, and 2072 a timed subtitle file in Portuguese. The contents have protection 2073 schemes and include the root fingerprints (attribute @hash of element 2074 RootFP) in each video and audio groups (for integrity verification 2075 purposes). 2077 2078 2079 2080 Movie in SVC 2081 2082 2083 2084 2086 2087 1234 2088 2089 Program01 2090 2091 2093 2094 2095 2096 2098 2099 2101 2102 2103 2104 2106 2107 2108 2109 2112 2113 2114 2115 2117 2118 2121 2122 2123 2124 2126 2127 2128 2129 2130 2131 2132 2135 2137 2138 2139 2141 2142 2143 2144 2145 2147 2148 2149 2151 2152 2153 2154 2155 2157 2158 2159 2160 2161 subtitles/Program01-pt.xml 2162 2163 2164 2165 2167 The MPD file for P2P Streaming contains tracker information and can 2168 be compressed with GZIP file format [RFC1952] in order to be used 2169 with HTTP compression [RFC2616] for faster transmission times and 2170 less network bandwidth usage. 2172 The Client Media Player parses the downloaded MPD file and, if it 2173 includes information for P2P Streaming, sends the information to the 2174 peer and waits for the response in order to start requesting media 2175 chunks to decode and play-out. 2177 The MPD file for Live Streaming has a similar structure but describes 2178 a sliding window of a small range in the SegmentInfo element from the 2179 live program stream timeline (typically, 10 seconds of video). The 2180 sliding window is updated for every new encoded segments (a range of 2181 chunks defined by the attributes @startIndex and @endIndex) of the 2182 program stream. 2184 The following excerpt of MPD is for a Live scalable video content. 2185 The MPD is updated every 10 seconds while the content is being 2186 encoded in real-time. Note that each segment set defined in the Live 2187 MPD is self-contained and the necessary information related to 2188 eventual content protection and integrity verification keys for the 2189 set is provided: 2191 2192 2197 654321xyz 2198 2199 2200 2202 2203 2204 2205 2207 2208 .... more descriptions .... 2209 2210 .... more descriptions .... 2211 2212 2214 Appendix C. PPSP Requirements Compliance 2216 C.1. PPSP Basic Requirements 2218 PPSP.REQ-1: The design of the Tracker protocol in this document 2219 allows the Peer Protocol to be similar in terms of design, message 2220 formats and flows. 2222 PPSP.REQ-2: The design of the Tracker protocol in this document 2223 enables peers to receive streaming content within required time 2224 constraints. 2226 PPSP.REQ-3: Each peer has a unique ID (i.e., Peer-ID) that identifies 2227 the peer in all swarms joined. 2229 PPSP.REQ-4: Each streaming content is uniquely identified by a Swarm- 2230 ID. 2232 PPSP.REQ-5: The streaming content is partitioned into chunks 2233 individually addressable. 2235 PPSP.REQ-6: Each chunk has an unique ID in the swarm and is 2236 individually addressable. 2238 PPSP.REQ-7: The Tracker Protocol is carried over TCP. 2240 PPSP.REQ-8: The Tracker Protocol is designed to facilitate acceptable 2241 QoS, supporting, without special algorithms, adaptive and scalable 2242 video and 3D video, for both Video On Demand (VoD) and Live video 2243 services, allowing additionally complementary mechanisms like super 2244 peers, in-network storage, alternative peer addresses and usage of 2245 QoS information for advanced peer selection. 2247 C.2. PPSP Tracker Protocol Requirements 2249 PPSP.TP.REQ-1: The Tracker Protocol implements the reception of 2250 queries from peers, such as those in JOIN and FIND messages and 2251 periodical peer status reports (STAT_REPORT), as well as the 2252 corresponding replies. 2254 PPSP.TP.REQ-2: The peer MUST implement the Tracker Protocol designed 2255 in this draft. 2257 PPSP.TP.REQ-3: The tracker request messages JOIN and FIND allow the 2258 requesting of peer list from the tracker with respect to a specific 2259 Swarm-ID and include preferred number of peers in the peer list as 2260 well as peer properties which enable appropriate candidate peer 2261 selections by the tracker. 2263 PPSP.TP.REQ-4: The tracker responses from JOIN and FIND messages 2264 allow the tracker to offer the peer list to the requesting peer with 2265 respect to a specific Swarm-ID. 2267 PPSP.TP.REQ-5: The Tracker supports generating the peer lists with 2268 the help of traffic optimization services like ALTO. 2270 PPSP.TP.REQ-6: The STATUS_REPORT message informs the Tracker about 2271 the peer's activity in the swarm. 2273 PPSP.TP.REQ-7: The chunk availability information (ChunkMaps) of the 2274 Peer (for all joined swarms) is reported to the tracker in 2275 STATUS_REPORT messages. 2277 PPSP.TP.REQ-8: The ChunkMaps exchanged between peer and tracker can 2278 be expressed as compact encoded strings. 2280 PPSP.TP.REQ-9: The STATUS_REPORT message informs the tracker about 2281 the peer status and capabilities. 2283 C.3. PPSP Security Considerations 2285 PPSP.SEC.REQ-1: The Tracker Protocol supports closed swarms, where 2286 the peers are required to be authenticated. 2288 PPSP.SEC.REQ-2: Confidentiality of the streaming content can be 2289 supported, and the corresponding key management mechanisms can be 2290 negotiated in the authentication and authorization phase (via CONNECT 2291 message) before the peer JOINs the swarm. 2293 PPSP.SEC.REQ-3: The Tracker Protocol uses security layers to encrypt 2294 the data exchanged among the PPSP entities. 2296 PPSP.SEC.REQ-4: The Tracker Protocol security layer mechanisms help 2297 to limit potential damages caused by malfunctioning and badly 2298 behaving peers in the P2P streaming system. The streaming mechanisms 2299 considered in the PPSP-TP model prevent pollution of contents. 2301 PPSP.SEC.REQ-6: The use of trusted trackers and peer authentication 2302 and authorization mechanisms capable to provide additional security 2303 and confidentiality, allow to mitigate and prevent peers from DoS 2304 attacks. 2306 PPSP.SEC.REQ-7: The Tracker Protocol design supports distributed 2307 tracker architectures, providing robustness to the streaming service 2308 in case of centralized tracker failure. 2310 PPSP.SEC.REQ-8: The Tracker Protocol use of Transport Layer Security 2311 mechanisms avoids the need for developing new security mechanisms. 2313 PPSP.SEC.REQ-9: The Tracker Protocol together with the Media 2314 Presentation Description (MPD) allow the use of streaming content 2315 integrity mechanisms. 2317 Authors' Addresses 2319 Rui Santos Cruz 2320 IST/INESC-ID/INOV 2321 Phone: +351.939060939 2322 Email: rui.cruz@ieee.org 2323 Gu Yingjie 2324 Huawei 2325 Phone: +86-25-56624760 2326 Fax: +86-25-56624702 2327 Email: guyingjie@huawei.com 2329 Mario Serafim Nunes 2330 IST/INESC-ID/INOV 2331 Rua Alves Redol, n.9 2332 1000-029 LISBOA, Portugal 2333 Phone: +351.213100256 2334 Email: mario.nunes@inov.pt 2336 David A. Bryan 2337 Polycom 2338 P.O. Box 6741 2339 Williamsburg, Virginia 23188 2340 United States of America 2341 Phone: +1.571.314.0256 2342 Email: dbryan@ethernot.org 2344 Jinwei Xia 2345 Huawei 2346 Nanjing, Baixia District 210001 2347 China 2348 Phone: +86-025-86622310 2349 Email: xiajinwei@huawei.com 2351 Joao P. Taveira 2352 IST/INOV 2353 Email: joao.silva@inov.pt 2355 Deng Lingli 2356 China Mobile