idnits 2.17.1 draft-cruz-ppsp-base-tracker-protocol-01.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 (October 21, 2012) is 4198 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) == Missing Reference: 'ITU-T.H.264' is mentioned on line 391, but not defined ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLNameSpace' -- 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-11 == Outdated reference: A later version (-23) exists of draft-pantos-http-live-streaming-10 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 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: April 24, 2013 Yingjie Gu 6 Jinwei Xia 7 Huawei 8 Joao P. Taveira 9 IST/INOV 10 Deng Lingli 11 China Mobile 12 October 21, 2012 14 PPSP Tracker Protocol--Base Protocol (PPSP-TP/1.0) 15 draft-cruz-ppsp-base-tracker-protocol-01 17 Abstract 19 This document specifies the base Peer-to-Peer Streaming Protocol- 20 Tracker Protocol (PPSP-TP/1.0), an application-layer control 21 (signaling) protocol for the exchange of meta information between 22 trackers and peers. The specification outlines the architecture of 23 the protocol and its functionality, and describes message flows, 24 message processing instructions, message formats, formal syntax and 25 semantics. The PPSP Tracker Protocol enables cooperating peers to 26 form content streaming overlay networks to support near real-time 27 Structured Media content (audio, video, associated timed text and 28 metadata) delivery, such as adaptive multi-rate, layered (scalable) 29 and multi-view (3D), in live, time-shifted and on-demand modes. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as 39 Internet-Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/1id-abstracts.html 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html 51 Copyright and License Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Use Scenarios and Streaming Modes . . . . . . . . . . . . . 4 70 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 5 71 1.2.1. Enrollment and Bootstrap . . . . . . . . . . . . . . . 6 72 1.2.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . 7 73 1.2.3. Content Information Metadata . . . . . . . . . . . . . 8 74 1.2.4. Authentication, Confidentiality, Integrity . . . . . . 8 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 3. Architectural and Functional View . . . . . . . . . . . . . . . 11 77 4. Messaging Model . . . . . . . . . . . . . . . . . . . . . . . . 13 78 5. Request/Response model . . . . . . . . . . . . . . . . . . . . 13 79 6. State Machines and Flows of the Protocol . . . . . . . . . . . 14 80 6.1. Normal Operation . . . . . . . . . . . . . . . . . . . . . 16 81 6.2. Error Conditions . . . . . . . . . . . . . . . . . . . . . 17 82 7. Protocol Specification . . . . . . . . . . . . . . . . . . . . 17 83 7.1. Request/Response Syntax and Format . . . . . . . . . . . . 17 84 7.2. Semantics of PPSPTrackerProtocol elements . . . . . . . . . 20 85 7.3. Request element in request Messages . . . . . . . . . . . . 22 86 7.4. Response element in response Messages . . . . . . . . . . . 23 87 8. Request/Response Processing . . . . . . . . . . . . . . . . . . 24 88 8.1. CONNECT Request . . . . . . . . . . . . . . . . . . . . . . 24 89 8.2. STAT_REPORT Request . . . . . . . . . . . . . . . . . . . . 28 90 8.3. Error and Recovery conditions . . . . . . . . . . . . . . . 29 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 30 92 9.1. Authentication between Tracker and Peers . . . . . . . . . 30 93 9.2. Content Integrity protection against polluting 94 peers/trackers . . . . . . . . . . . . . . . . . . . . . . 31 95 9.3. Residual attacks and mitigation . . . . . . . . . . . . . . 31 96 9.4. Pro-incentive parameter trustfulness . . . . . . . . . . . 31 97 10. Guidelines for Extending PPSP-TP . . . . . . . . . . . . . . . 32 98 10.1. Forms of PPSP-TP Extension . . . . . . . . . . . . . . . . 33 99 10.2. Issues to Be Addressed in PPSP-TP Extensions . . . . . . . 34 100 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 101 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 102 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 103 13.1. Normative References . . . . . . . . . . . . . . . . . . . 36 104 13.2. Informative References . . . . . . . . . . . . . . . . . . 37 105 Appendix A. PPSP-TP Message Syntax for HTTT/1.1 . . . . . . . . . 39 106 A.1. Header Fields . . . . . . . . . . . . . . . . . . . . . . . 40 107 A.2. Methods . . . . . . . . . . . . . . . . . . . . . . . . . . 40 108 A.3. Message Bodies . . . . . . . . . . . . . . . . . . . . . . 40 109 A.4. Message Response Codes . . . . . . . . . . . . . . . . . . 41 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 112 1. Introduction 114 The Peer-to-Peer Streaming Protocol (PPSP) is composed of two 115 protocols: the PPSP Tracker Protocol and the PPSP Peer Protocol 116 [I-D.ietf-ppsp-problem-statement] specifies that the Tracker Protocol 117 should standardize format/encoding of information and messages 118 between PPSP peers and PPSP trackers and also defines the 119 requirements. 121 The PPSP Tracker Protocol provides communication between trackers and 122 peers, by which peers send meta information to trackers, report 123 streaming status and obtain peer lists from trackers. 125 The PPSP architecture requires PPSP peers able to communicate with a 126 tracker in order to participate in a particular streaming content 127 swarm. This centralized tracker service is used by PPSP peers for 128 content registration and location. 130 The signaling and the media data transfer between PPSP peers is not 131 in the scope of this specification. 133 This document describes the base PPSP Tracker protocol and how it 134 satisfies the requirements for the IETF Peer-to-Peer Streaming 135 Protocol, in order to derive the implications for the standardization 136 of the PPSP streaming protocols and to identify open issues and 137 promote further discussion. 139 1.1. Use Scenarios and Streaming Modes 141 This section is tutorial in nature and does not contain any normative 142 statements. 144 This section describes some aspects of the use of PPSP-TP. The 145 examples were chosen to illustrate the basic operation, but not to 146 limit what PPSP-TP may be used for. 148 The functional entities related to PPSP protocols are the Client 149 Media Player, the service Portal, the tracker and the peers. The 150 complete description of these entities is not discussed here, as not 151 in the scope the specification. 153 The Client Media Player is a logical entity providing direct 154 interface to the end user at the client device, and includes the 155 functions to select, request, decode and render contents. The Client 156 Media Player may interface with the local peer application using 157 request and response standard formats for HTTP Request and Response 158 messages [RFC2616]. 160 The service Portal is a logical entity typically used for client 161 enrollment and content information publishing, searching and 162 retrieval. 164 The tracker is a logical entity that maintains the lists of PPSP 165 active peers storing and exchanging a specific media content. The 166 tracker also stores the status of active peers in swarms, to help in 167 the selection of appropriate peers for a requesting peer. The 168 tracker can be realized by geographically distributed tracker nodes 169 or multiple server nodes in a data center, increasing the content 170 availability, the service robustness and the network scalability or 171 reliability. The management and locating of content index 172 information are totally internal behaviors of the tracker system, 173 which is invisible to the PPSP Peer. 175 The peer is also a logical entity in the client device embedding the 176 P2P core engine, with a client serving side interface to respond to 177 Client Media Player requests and a network side interface to exchange 178 data and PPSP signaling with trackers and other peers. 180 The streaming technique is chunk-based, i.e., client peers obtain 181 media chunks from serving peers and handle the buffering that is 182 necessary for the playback processes during the download of the media 183 chunks. 185 In Live streaming, all end users are interested in a specific media 186 coming from an ongoing program, which means that all respective peers 187 share nearly the same streaming content at a given point of time. 188 Peers may store the live media for further distribution (known as 189 time-shift TV), where the stored media is distributed in a VoD-like 190 manner. 192 In VoD, different end users watch different parts of the recorded 193 media content during a past event. In this case, each respective 194 peer obtains from other peers the information on media chunks they 195 store and then get the required media from a selected set of those 196 peers. While watching VoD, an end user can also switch to any place 197 of the content, e.g., skip the credits part, or skip the part that it 198 is not interested in. In this case the respective participating peer 199 may not store all the content segments. From the whole swarm point 200 of view, the participating peers typically store different parts of 201 content. 203 1.2. Assumptions 205 This section is tutorial in nature and does not contain any normative 206 statements. 208 The process used for media streaming distribution assumes a segment 209 (chunk) transfer scheme whereby the original content (that can be 210 encoded using adaptive or scalable techniques) is chopped into small 211 segments having the following representations: 213 1. Adaptive - alternate representations with different qualities and 214 bitrates; a single representation is non-adaptive; 215 2. Scalable description levels - multiple additive descriptions 216 (i.e., addition of descriptions refine the quality of the video); 217 3. Scalable layered levels - nested dependent layers corresponding to 218 several hierarchical levels of quality, i.e., higher enhancement 219 layers refine the quality of the video of lower layers. 220 4. Scalable multiple views - views correspond to mono (2D) and 221 stereoscopic (3D) videos, with several hierarchical levels of 222 quality. 224 These streaming distribution techniques support dynamic variations in 225 video streaming quality while ensuring support for a plethora of end 226 user devices and network connections. 228 1.2.1. Enrollment and Bootstrap 230 In order to join an existing P2P streaming service and to participate 231 in content sharing, any peer must first locate a tracker, using for 232 example, the following methods (illustrated in Figures 1, 2): 234 +--------+ +--------+ +--------+ +---------+ +--------+ 235 | Player | | Peer 1 | | Portal | | Tracker | | Peer 2 | 236 +--------+ +--------+ +--------+ +---------+ +--------+ 237 | | | | | 238 (a) |--Page request----------------->| | | 239 |<--------------Page with links--| | | 240 |--Select stream (MPD Request)-->| | | 241 |<--------------------OK+MPD(x)--| | | 242 (b) |--Start/Resume->|--CONNECT(join x)------------>| | 243 |<-----------OK--|<----------------OK+Peerlist--| | 244 | | | | 245 |--Get(Chunk)--->|<---------- (Peer protocol) ------------->| 246 |<--------Chunk--|<---------------------------------Chunks--| 247 : : : : : 248 | |--STAT_REPORT---------------->| | 249 | |<-------------------------Ok--| | 250 : : : : : 251 |--Get(Chunk)--->|<---------- (Peer protocol) ------------->| 252 |<--------Chunk--|<---------------------------------Chunks--| 253 : : : : : 255 Figure 1: A typical PPSP session for watching a streaming content. 257 +-------------+ +---------+ 258 | Peer Seeder | | Tracker | 259 +-------------+ +---------+ 260 | | 261 Start->|--CONNECT (join x,y,z)-------->| 262 |<--------------------------OK--| 263 : : 264 | | 265 |--STAT_REPORT----------------->| 266 |<--------------------------Ok--| 267 : : 268 | | 269 |--STAT_REPORT----------------->| 270 |<--------------------------Ok--| 271 : : 273 Figure 2: A typical PPSP session for a streaming Seeder 275 1. From a content service provider provisioning mechanism: this is 276 the typical case used for the provider Seeders (edge caches and/or 277 Media Servers), where some "Start" activation signal triggers the 278 process for contents x, y, z (Figure 2). 279 2. From a web page: a Publishing and Searching Portal may provide 280 tracker location information to end users. 281 3. From the Media Presentation Description (MPD) file of a content: 282 this meta-info file must contain information about the address of 283 one or more trackers (that can be grouped by tiers of priority) 284 which are controlling the swarm for that media content, as 285 illustrated in Figure 1 for a content x. 287 As illustrated in Figure 1, a peer may initiate a stream using the 288 above method 3 starting at point (a), or resume a previously 289 initiated stream, using also method 3 but starting at point (b). 291 In order to be able to bootstrap, a peer must first obtain a Peer-ID 292 (identifier of the peer) and any required security certificates or 293 authorization tokens from an enrollment service (end user 294 registration). The specification of the format of the Peer-ID is not 295 in the scope of this document. 297 The specification of the mechanisms used by the Client Media Player 298 and the peer (to signal start/resume streams or request media 299 chunks), obtain a Peer-ID, security certificates or tokens are not in 300 the scope of this document. 302 1.2.2. NAT Traversal 304 It is assumed that all trackers must be in the public Internet and 305 have been placed there deliberately. This document will not describe 306 NAT Traversal mechanisms but the protocol facilitates flexible NAT 307 Traversal techniques, such as those based on ICE [RFC5245], 308 considering that the tracker node may provide NAT traversal services, 309 as a STUN-like tracker. Being a STUN-like tracker, it can discover 310 the reflexive candidate addresses of a peer and make them available 311 in responses to other requesting peers. 313 1.2.3. Content Information Metadata 315 Multimedia contents may consist of several media components (for 316 example, audio, video, and timed text), each of which might have 317 different characteristics. 319 The representations of a media content correspond to encoded 320 alternatives of the same media component, varying from other 321 representations by bitrate, resolution, number of channels, or other 322 characteristics. Each representation consists of one or multiple 323 segments. Segments are the media stream transport chunks in temporal 324 sequence. 326 These characteristics may be described in a Media Presentation 327 Description (MPD) file. It is envisioned that the content information 328 metadata used in PPSP may align with MPD formats, such as ISO/IEC 329 23009-1 [ISO.IEC.23009-1] and [I-D.pantos-http-live-streaming]. 331 1.2.4. Authentication, Confidentiality, Integrity 333 Channel-oriented security can be used in the communication between 334 peers and tracker, such as the Transport Layer Security (TLS) to 335 provide privacy and data integrity. HTTP/1.1 over TLS (HTTPS) 336 [RFC2818] is the preferred approach for preventing disclosure of peer 337 critical information via the communication channel. 339 Due to the transactional nature of the communication between peers 340 and tracker a method for adding authentication and data security 341 services via replaceable mechanisms may be employed. One such method 342 is the OAuth 2.0 Authorization [RFC6749] with bearer token, providing 343 the peer with the information required to successfully utilize the 344 access token to make protected requests to the tracker [RFC6750]. 346 2. Terminology 348 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 349 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 350 document are to be interpreted as described in RFC 2119 [RFC2119]. 352 This draft uses terms defined in [I-D.ietf-ppsp-problem-statement]. 354 Absolute Time: Absolute time is expressed as ISO 8601 355 [ISO.8601.2004] timestamps, using zero UTC offset (GMT). Fractions 356 of a second may be indicated. Example for December 25, 2010 at 14h56 357 and 20.25 seconds: basic format 20101225T145620.25Z or extended 358 format 2010-12-25T14:56:20.25Z. 360 Adaptive Streaming: Multiple alternate representations (different 361 qualities and bitrates) of the same media content co-exist for the 362 same streaming session; each alternate representation corresponds to 363 a different media quality level; peers can choose among the 364 alternate representations for decode and playback. 366 Base Layer: The playable representation level in Scalable Video 367 Coding (SVC) required by all upper level Enhancements Layers for 368 proper decoding of the video. 370 Chunk: A chunk is a basic unit of data block organized in P2P 371 streaming for storage, scheduling, advertisement and exchange among 372 peers. A chunk therefore refers to a segment of partitioned 373 streaming media. 375 Complementary Representation: Representation in a set of content 376 representations which have inter-representation dependencies and 377 which, when combined, result in a single representation for decoding 378 and presentation. 380 Connection Tracker: The tracker node to which the PPSP peer will 381 connect when it wants to get registered and join the PPSP system. 383 Continuous media: Media with an inherent notion of time, for 384 example, speech, audio, video, timed text or timed metadata. 386 Enhancement Layer: Enhancement differential quality level 387 (complementary representation) in Scalable Video Coding (SVC) used to 388 produce a higher quality, higher definition video in terms of space 389 (i.e., image resolution), time (i.e., frame rate) or Signal-to-Noise 390 Ratio (i.e., fidelity) when combined with the playable Base Layer 391 [ITU-T.H.264]. 393 Join Time: Join time is the absolute time when a peer registers on a 394 tracker. This value is recorded by the tracker and is used to 395 calculate Online Time. 397 Leecher: A Peer that has not yet completed the transfer of all 398 chunks of the media content. 400 Live streaming: The scenario where all clients receive streaming 401 content for the same ongoing event. The lags between the play points 402 of the clients and that of the streaming source are small. 404 Media Component: An encoded version of one individual media type 405 such as audio, video or timed text with specific attributes, e.g., 406 bandwidth, language, or resolution. 408 Media Presentation Description (MPD): Formalized description for a 409 media presentation, i.e., describes the structure of the media, 410 namely, the representations, the codecs used, the segments (chunks), 411 and the corresponding addressing scheme. 413 Method: The method is the primary function that a request from a 414 peer is meant to invoke on a tracker. The method is carried in the 415 request message itself. 417 Online Time: Online Time shows how long the peer has been in the P2P 418 streaming system since it joins. This value indicates the stability 419 of a peer, and can be calculated by tracker when necessary. 421 Peer: A peer refers to a participant in a P2P streaming system that 422 not only receives streaming content, but also stores and uploads 423 streaming content to other participants. 425 Peer-ID: Unique identifier for the peer. The Peer-ID is mandatory, 426 can take the form of a universal unique identifier (UUID), defined in 427 [RFC4122], and can be bound to a network address of the peer, i.e., 428 an IP address uniform resource identifier/locator (URI/URL) that 429 uniquely identifies the corresponding peer in the network. The Peer- 430 ID and any required security certificates are obtained from an 431 offline enrollment server. 433 Peer-Peer Messages (i.e., Peer Protocol): The Peer Protocol messages 434 enable each peer to exchange content availability with other peers 435 and request other peers for content. 437 PPSP: The abbreviation of Peer-to-Peer Streaming Protocols. PPSP 438 protocols refer to the key signaling protocols among various P2P 439 streaming system components, including the tracker and peers. 441 Representation: Structured collection of one or more media 442 components. 444 Request: A message sent from a peer to a tracker, for the purpose of 445 invoking a particular operation. 447 Response: A message sent from a tracker to a peer, for indicating 448 the status of a request sent from the peer to the tracker. 450 Scalable Streaming: With Multiple Description Coding (MDC), multiple 451 additive descriptions (that can be independently played-out) to 452 refine the quality of the video when combined together. With 453 Scalable Video Coding (SVC), nested dependent enhancement layers 454 (hierarchical levels of quality), refine the quality of lower layers, 455 from the lowest level (the playable Base Layer). With Multiple View 456 Coding (MVC), multiple views allow the video to be played in 3D when 457 the views are combined together. 459 Seeder: A Peer that holds and shares the complete media content. 461 Segment: A segment is a resource that can be identified, by an ID or 462 an HTTP-URL and possibly a byte-range, and is included in the MPD. 463 The segment is a basic unit of partitioned streaming media, which is 464 used by a peer for the purpose of storage, advertisement and exchange 465 among peers. 467 Swarm: A swarm refers to a group of peers sharing the same content 468 (e.g., video/audio program, digital file, etc.) at a given time. 470 Swarm-ID: Unique identifier for a swarm. The Swarm-ID may use a 471 universal unique identifier (UUID), e.g., a 64 or 128 bit datum to 472 refer to the content resource being shared among peers. 474 Tracker: A tracker refers to a centralized logical directory service 475 used to communicate with PPSP Peers for content registration and 476 location, which maintains the lists of PPSP peers storing segments 477 for a specific live content channel or streaming media and answers 478 queries from PPSP peers. 480 Tracker-Peer Messages (i.e., Tracker Protocol): The Tracker Protocol 481 messages provide communication between peers and trackers, by which 482 peers can provide content availability, report streaming status and 483 request peer lists from trackers. 485 Video-on-demand (VoD): A kind of application that allows users to 486 select and watch video content on demand. 488 3. Architectural and Functional View 490 The PPSP Tracker Protocol architecture is intended to be compatible 491 with the web infrastructure. PPSP-TP is designed with a layered 492 approach i.e., a PPSP-TP Request/Response layer, a Messaging layer 493 and a Transport layer. 495 The PPSP-TP Request/Response layer deals with the interactions 496 between tracker and peers using Request and Response codes (see 497 Figure 3). 499 The messaging layer deals with the framing format, for encoding and 500 transmitting the data through the underlying transport protocol, and 501 the asynchronous nature of the interactions between tracker and 502 peers. 504 The transport layer is responsible for the actual transmission of 505 requests and responses over network transports, including the 506 determination of the connection to use for a request or response 507 message when using a connection-oriented transport like TCP, or TLS 508 [RFC5246] over it. 510 +----------------------+ 511 | Application | 512 +----------------------+ 513 | Request/Response | PPSP-TP 514 |----------------------| 515 | (HTTP)Messages | 516 +----------------------+ 517 | TRANSPORT | 518 +----------------------+ 520 Figure 3: Abstract layering of PPSP-TP 522 The functional entities involved in the PPSP Tracker Protocol are 523 trackers and peers (which may support different capabilities). 525 A Peer corresponds to a logical entity (typically in a user device) 526 that actually participate in sharing a media content. Peers are 527 organized in (various) swarms corresponding each swarm to the group 528 of peers streaming a certain content at any given time. 530 The tracker is a logical entity that maintains the lists of peers 531 storing segments for a specific Live media channel or on-demand media 532 streaming content, answers queries from peers and collects 533 information on the activity of peers. While a tracker may have an 534 underlying implementation consisting of more than one physical nodes, 535 logically the tracker can most simply be thought of as a single 536 element, and in this document it will be treated as a single logical 537 entity. 539 The Tracker Protocol is not used to exchange actual content data 540 (either on-demand or Live streaming) with peers, but information 541 about which peers can provide the content. 543 When a peer wants to receive streaming of a selected content: 545 1. Peer connects to a local connection tracker and joins a swarm. 546 2. Peer acquires a list of peers from the connection tracker. 548 3. Peer exchanges its content availability with the peers on the 549 obtained peer list (via peer protocol). 550 4. Peer identifies the peers with desired content. 551 5. Peer requests content from the identified peers (peer protocol). 553 When a peer wants to share streaming contents (Seeder mode) with 554 other peers: 556 1. Peer connects to the connection tracker. 557 2. Peer sends information to the connection tracker about the swarms 558 it belongs to (joins). 560 After having been disconnected due to some termination condition, a 561 peer can resume previous activity by connecting and re-joining the 562 corresponding swarm(s). 564 4. Messaging Model 566 The messaging model of PPSP-TP aligns with HTTP protocol and the 567 semantics of its messages, currently in version 1.1 [RFC2616], but 568 intended to support future versions of HTTP and framing formats used 569 for encoding and transmitting the data over the wire, e.g., the 570 format proposed in [I-D.montenegro-httpbis-speed-mobility]. The 571 exchange of messages of PPSP-TP is envisioned to be performed over a 572 stream-oriented reliable transport protocol, like TCP. 574 Appendix A describes the message syntax when using HTTT/1.1 messages. 576 5. Request/Response model 578 PPSP-TP is a text-based protocol, uses the UTF-8 character set 579 [RFC3629] and the protocol messages are either requests from client 580 peers to a tracker server, or responses from a tracker server to 581 client peers. 583 PPSP-TP Request and Response semantics are carried as entities 584 (header and body) in messages which correspond to either HTTP request 585 methods or HTTP response codes, respectively. 587 Requests are sent, and responses returned to these requests. A 588 single request generates a single response (neglecting fragmentation 589 of messages in transport). 591 The response codes are consistent with HTTP response codes, however, 592 not all HTTP response codes are used for the PPSP-TP (section 7). 594 The Request Messages of the base protocol, are listed in Table 1: 596 +---------------+ 597 | PPSP-TP/1.0 | 598 | Req. Messages | 599 +---------------+ 600 | CONNECT | 601 | STAT_REPORT | 602 +---------------+ 603 Table 1: Request Messages 605 CONNECT: This Request message is used when a peer registers (or if 606 already registered) in the tracker notifies it about the 607 participation in named swarm(s). The tracker records the Peer-ID, 608 connect-time (referenced to the absolute time), peer IP addresses and 609 link status. The tracker also changes the content availability of 610 the valid named swarm(s), i.e., changes the peers lists of the 611 corresponding swarm(s) for the requester Peer-ID. On receiving a 612 CONNECT message, the tracker first checks the peer mode type 613 (Seed/Leech) for the specified swarm(s) and then decides the next 614 steps (more details are referred in section 8.1) 616 STAT_REPORT: This Request message allows an active peer to send 617 status data to the tracker to signal continuing activity. This 618 request message MUST be sent periodically to the tracker while the 619 peer is active in the system. 621 6. State Machines and Flows of the Protocol 623 The state machine for the tracker is very simple, as shown in 624 Figure 4. 626 Peer-ID registrations represent a dynamic piece of state maintained 627 by the network. 629 -------------------------------------------- 630 / \ 631 | +------------+ +---------+ +------+ | 632 \-| TERMINATED |<---| STARTED |<---| INIT |<-/ 633 +------------+ +---------+ +------+ 634 \- (start tracker) 635 Figure 4: Tracker State Machine 637 When there are no peers connected in the tracker, the state machine 638 is in the INIT state. 640 When the "first" peer connects for registration with its Peer-ID, the 641 state machine moves from INIT to STARTED. 643 As long as there is at least one active registration of a Peer-ID, 644 the state machine remains in the STARTED state. When the "last" 645 Peer-ID is removed, the state machine transitions to TERMINATED. 646 From there, it immediately transitions back to the INIT state. 647 Because of that, the TERMINATED state here is transient. 649 In addition to the tracker state machine, each Peer-ID is modeled 650 with its own transaction state machine (Figure 5), instantiated per 651 Peer-ID in the tracker, and deleted when it is removed. 653 -------------------------------------------- 654 / \ 655 | +------------+ +---------+ +------+ | 656 \-| TERMINATED |<---| STARTED |<---| INIT |<-/ 657 +------------+ +---------+ +------+ 658 | (1) \- (start tracker) 659 V 660 +-----------+ +-------+ rcv CONNECT 661 | TERMINATE | | START | --------------- (1) 662 +-----------+ +-------+ strt init timer 663 ^ | 664 | | 665 on registration error | v 666 on action error | +------------+ 667 ---------------- (A) +<-----| PEER | (Transient) 668 stop init timer | | REGISTERED | 669 snd error | +------------+ 670 | | 671 | | process swarm actions 672 | | --------------------- (2) 673 on CONNECT Error (B) | | snd OK (PeerList) 674 on timeout (5) | / stop init timer 675 ---------------- | / strt track timer 676 stop track timer | / 677 clean peer info | | 678 del registration | | 679 snd error (B) \ | ---- 680 ---- \ | / \ 681 / \ \ | | | 682 rcv CONNECT | (4) | | | | | 683 ----------- | v | v v | rcv STAT_REPORT 684 snd OK \ +--------------+ / --------------- (3) 685 rst track timer ----| TRACKING |---- snd OK response 686 +--------------+ rst track timer 688 Figure 5: Per-Peer-ID Transaction State Machine and Flow Diagram 690 Unlike the tracker state machine, which exists even when no Peer-IDs 691 are registered, the "per-Peer-ID" transaction state machine is 692 instantiated only when the Peer-ID starts registration in the 693 tracker, and is deleted when the Peer-ID is de-registered/removed. 694 This allows for an implementation optimization whereby the tracker 695 can destroy the objects associated with the "per-Peer-ID" transaction 696 state machine once it enters the TERMINATE state (Figure 5). 698 When a new Peer-ID is added, the corresponding "per-Peer-ID" state 699 machine is instantiated, and it moves into the PEER REGISTERED state. 700 Because of that, the START state here is transient. 702 When the Peer-ID is no longer bound to a registration, the "per-Peer- 703 ID" state machine moves to the TERMINATE state, and the state machine 704 is destroyed. 706 During the lifetime of streaming activity of a peer, the "per-Peer- 707 ID" transaction state machine progresses from one state to another in 708 response to various events. The events that may potentially advance 709 the state include: 711 o Reception of CONNECT and STAT_REPORT messages, or 712 o Timeout events. 714 The state diagram in Figure 5 illustrates state changes, together 715 with the causing events and resulting actions. Specific error 716 conditions are not shown in the state diagram. 718 6.1. Normal Operation 720 On normal operation the process consists of the following steps: 722 1) When a Peer wants to access the system it needs to register on a 723 tracker by sending a CONNECT message asking for the swarm(s) it 724 wants to join. This CONNECT request triggers a new "per-Peer-ID" 725 State machine. In the START state the tracker initiates the 726 registration of the Peer-ID and associated information (IP 727 addresses), starts the "init timer" and moves to PEER REGISTERED 728 state. 730 2) In PEER REGISTERED state, if Peer-ID is valid, the tracker 731 processes the requested action(s) for the valid swarm information. 732 In case of success the tracker stops the "init timer", starts the 733 "track timer" and sends the response to the peer. The response 734 MAY contain the appropriate list of peers for the joining 735 swarm(s), depending on peer mode (section 8.1). At the PEER 736 REGISTERED state, if Peer-ID is considered invalid, the tracker 737 responds with either error codes 401 Unauthorized or 403 Forbidden 738 (described in section 7), and transitions to TERMINATE state for 739 that Peer-ID. 741 3) In TRACKING state, a STAT_REPORT message received from the peer 742 resets the "track timer" and is responded with a successful 743 condition. 745 4) While TRACKING, a CONNECT message received with valid swarm 746 actions information (section 8.1) from the peer resets the "track 747 timer" and is responded with a successful condition. 749 5) In TRACKING state, without receiving messages from the peer, on 750 timeout (track timer) the tracker cleans all the information 751 associated with the Peer-ID in all swarms it was joined, deletes 752 the registration, and transitions to TERMINATE state for that 753 Peer-ID. 755 6.2. Error Conditions 757 Peers MUST NOT generate protocol elements that are invalid. 758 However, several situations of a peer may lead to abnormal 759 conditions in the interaction with the tracker. The situations 760 may be related with peer malfunction or communications errors. 761 The tracker reacts to the abnormal situations depending on its 762 current state related to a peer-ID, as follows: 764 A) At PEER REGISTERED state, when a CONNECT Request only contains 765 invalid swarm actions (section 8.1), the tracker responds with 766 error code 403 Forbidden, deletes the registration and transition 767 to TERMINATE state for that Peer-ID. 769 B) At the TRACKING state (while the "track timer" has not expired) 770 receiving a CONNECT message from the peer with invalid swarm 771 actions (section 8.1) is considered an error condition. The 772 tracker responds with error code 403 Forbidden (described in 773 section 7), stops the "track timer", deletes the registration and 774 transitions to TERMINATE state for that Peer-ID. 776 NOTE: These situations may correspond to a malfunction at the peer 777 or to malicious conditions. Therefore, the adequate preventive 778 measure is to proceed to TERMINATE state for the Peer-ID by de- 779 registering the peer and cleaning all peer information. 781 7. Protocol Specification 783 7.1. Request/Response Syntax and Format 785 The message-body for Requests and Responses requiring it, correspond 786 to a XML document [XML], optionally represented in a binary compact 787 form using for example Efficient XML Interchange (EXI) Format [EXI 788 Format]. 790 The XML message-body MUST begin with an XML declaration line 791 specifying the version of XML being used and indicating the character 792 encoding, which SHOULD be "UTF-8". The root element MUST begin with 793 an element. This element identifies the start 794 of an PPSP-TP protocol element, the namespace used within the 795 protocol, and the location of the protocol schema. 797 The generic format of a Request is the following: 799 800 801 802 803 804 805 806 807 808 810 The generic format of a Response is the following: 812 813 814 815 816 817 819 The Request element MUST be present in requests and corresponds to 820 the request method type for the message. 822 The Response element MUST be present in responses and corresponds to 823 the response method type of the message. 825 The element TransactionID MUST be present in requests to uniquely 826 identify the transaction. Responses to completed transactions use 827 the same TransactionID as the request they correspond to. 829 The element SwarmID MUST be present in requests to identify the 830 actions to be taken in the specified swarms. 832 The version of PPSP-TP being used is indicated by the attribute 833 @version of the root element, specified in an XML Schema 834 ([XMLSchema.1] and [XMLSchema.2]) with XML namespaces [XMLNameSpace] 835 to identify protocol grammars. 837 All Request messages MUST contain a PeerID element to uniquely 838 identify the peer (Peer-ID) in the network. 840 The PeerID information may be present on the following levels: 842 - On PPSPTrackerProtocol level in PPSPTrackerProtocol.PeerID element. 843 For details refer to 7.2.1 Table 2. 845 - On PeerGroup level in PeerGroup.PeerInfo.PeerID element. For 846 details refer to 7.2.1 Table 3. 848 The SwarmID element MUST be be present in CONNECT Requests and SHOULD 849 be present in STAT_REPORT Requests on the following levels: 851 - On PPSPTrackerProtocol level in PPSPTrackerProtocol.SwarmID 852 element. For details refer to 7.2.1 Table 2. 854 - On StatisticsGroup level in StatisticsGroup.Stat.SwarmID element. 855 For details refer to 7.2.1 Table 4. 857 The PeerNum element MAY be present in CONNECT requests and MAY 858 contain the attribute @abilityNAT to inform the tracker on the 859 preferred type of peers, in what concerns their NAT traversal 860 situation, to be returned in a peer list. 862 The StatisticsGroup element MAY be present in STAT_REPORT requests. 863 Details of usage in 8.2. 865 The semantics of the attributes and elements within a 866 PPSPTrackerProtocol root element is described in subsection 7.2.1. 868 Request and Response processing is provided in section 8 for each 869 message. 871 7.2. Semantics of PPSPTrackerProtocol elements 873 The semantics of PPSPTrackerProtocol elements and attributes are 874 described in the following tables. 876 +----------------------+---------+----------------------------------+ 877 | Element Name or | Use | Description | 878 | Attribute Name | | | 879 +----------------------+---------+----------------------------------+ 880 | PPSPTrackerProtocol | 1 | The root element. | 881 | @version | M | Provides the version of PPSP-TP. | 882 | Request | 0...1 | Provides the request method | 883 | | | and MUST be present in Request. | 884 | Response | 0...1 | Provides the response method | 885 | | | and MUST be present in Response. | 886 | TransactionID | M | Root transaction Identification. | 887 | Result | 0...N | Result of @action MUST be present| 888 | | | in Responses. | 889 | @transactionID | CM | Identifier of the @action. | 890 | PeerID | 0...1 | Peer Identification. | 891 | | | MUST be present in Request. | 892 | SwarmID | 0...N | Swarm Identification. | 893 | | | MUST be present in Requests. | 894 | @action | CM | Must be set to JOIN or LEAVE. | 895 | @peerMode | CM | Mode of Peer participation in | 896 | | | the swarm, "LEECH" or "SEED". | 897 | @transactionID | CM | Identifier for the @action. | 898 | PeerNUM | 0...1 | Maximum peers to be received | 899 | | | with capabilities indicated. | 900 | @abilityNAT | CM | Type of NAT traversal peers, as | 901 | | | "No-NAT","STUN","TURN" or "PROXY"| 902 | @concurrentLinks | CM | Concurrent connectivity level of | 903 | | | peers, "HIGH", "LOW" or "NORMAL" | 904 | @onlineTime | CM | Availability or online duration | 905 | | | of peers, "HIGH" or "NORMAL" | 906 | @uploadBWlevel | CM | Upload bandwidth capability of | 907 | | | peers, "HIGH" or "NORMAL" | 908 | PeerGroup | 0...1 | Information on peers (Table 3) | 909 | StatisticsGroup | 0...1 | Statistic data of peer (Table 4) | 910 +----------------------+---------+----------------------------------+ 911 | Legend: | 912 | Use for attributes: M=Mandatory, OP=Optional, | 913 | CM=Conditionally Mandatory | 914 | Use for elements: minOccurs...maxOccurs (N=unbounded) | 915 | Elements are represented by their name (case-sensitive) | 916 | Attribute names (case-sensitive) are preceded with an @ | 917 +-------------------------------------------------------------------+ 918 Table 2: Semantics of the base PPSPTrackerProtocol. 920 +----------------------+---------+----------------------------------+ 921 | Element Name or | Use | Description | 922 | Attribute Name | | | 923 +----------------------+---------+----------------------------------+ 924 | PeerGroup | 0...1 | Contains description of peers. | 925 | PeerInfo | 1...N | Provides information on a peer. | 926 | @swarmID | 0...1 | Swarm Identification. | 927 | PeerID | 0...1 | Peer Identification. | 928 | | | MAY be present in responses. | 929 | PeerAddress | 0...N | IP Address information. | 930 | @addrType | M | Type of IP address, which can be | 931 | | | "ipv4" or "ipv6" | 932 | @priority | CM | The priority of this interface. | 933 | | | Used for NAT traversal. | 934 | @type | CM | Describes the address for NAT | 935 | | | traversal, which can be "HOST" | 936 | | | "REFLEXIVE" or "PROXY". | 937 | @connection | OP | Access type ("3G", "ADSL", etc.) | 938 | @asn | OP | Autonomous System number. | 939 | @ip | M | IP address value. | 940 | @port | M | IP service port value. | 941 | @peerProtocol | OP | PPSP Peer Protocol supported. | 942 +----------------------+---------+----------------------------------+ 943 | Legend: | 944 | Use for attributes: M=Mandatory, OP=Optional, | 945 | CM=Conditionally Mandatory | 946 | Use for elements: minOccurs...maxOccurs (N=unbounded) | 947 | Elements are represented by their name (case-sensitive) | 948 | Attribute names (case-sensitive) are preceded with an @ | 949 +-------------------------------------------------------------------+ 950 Table 3: Semantics of PeerGroup. 952 If STUN-like functions are enabled in the tracker and a PPSP-ICE 953 method is used the attributes @type and @priority MUST be returned 954 with the transport address candidates in responses to CONNECT 955 requests. 957 The @asn attribute MAY be used to inform about the network location, 958 in terms of Autonomous System, for each of the active public network 959 interfaces of the peer. 961 The @connection attribute is informative on the type of access 962 network of the respective interface. 964 +----------------------+---------+----------------------------------+ 965 | Element Name or | Use | Description | 966 | Attribute Name | | | 967 +----------------------+---------+----------------------------------+ 968 | StatisticsGroup | 0...1 | Provides statistic data on peer | 969 | | | and content. | 970 | Stat | 1...N | Groups statistics property data. | 971 | @property | M | The property to be reported. | 972 | | | Property values in Table 6. | 973 | SwarmID | 0...1 | Swarm Identification. | 974 | UploadedBytes | 0...1 | Bytes sent to swarm. | 975 | DownloadedBytes | 0...1 | Bytes received from swarm. | 976 | AvailBandwidth | 0...1 | Upstream Bandwidth available. | 977 +----------------------+---------+----------------------------------+ 978 | Legend: | 979 | Use for attributes: M=Mandatory, OP=Optional, | 980 | CM=Conditionally Mandatory | 981 | Use for elements: minOccurs...maxOccurs (N=unbounded) | 982 | Elements are represented by their name (case-sensitive) | 983 | Attribute names (case-sensitive) are preceded with an @ | 984 +-------------------------------------------------------------------+ 986 Table 4: Semantics of StatisticsGroup. 988 The Stat element is used to describe several properties relevant to 989 the P2P network. These properties can be related with stream 990 statistics and peer status information. Each Stat element will 991 correspond to a @property type and several Stat blocks can be 992 reported in a single STAT_REPORT message, corresponding to some or 993 all the swarms the peer is actively involved. 995 Other properties may be defined, related, for example, with 996 incentives and reputation mechanisms, like peer online time, or 997 connectivity conditions, like physical link status, etc. 999 For that purpose, the Stat element may be extended to provide 1000 additional scheme specific information for new @property groups, new 1001 elements and new attributes. 1003 7.3. Request element in request Messages 1005 Table 5 defines the valid string representations for the requests. 1006 These values MUST be treated as case-sensitive. 1008 +----------------------+ 1009 | XML Request Methods | 1010 | String Values | 1011 +----------------------+ 1012 | CONNECT | 1013 | STAT_REPORT | 1014 +----------------------+ 1016 Table 5: Valid Strings for Request element of requests. 1018 7.4. Response element in response Messages 1020 Table 6 defines the valid string representations for Response 1021 messages that require message-body. These values MUST be treated as 1022 case-sensitive. 1024 Response messages not requiring message-body only use the standard 1025 HTTP Status-Code and Reason-Phrase (appended, if appropriate, with 1026 detail phrase, as described in section 8.6). 1028 +-------------------------+---------------------+ 1029 | XML Response Method | HTTP Status-Code | 1030 | String Values | and Reason-Phrase | 1031 +-------------------------+---------------------+ 1032 | SUCCESSFUL | 200 OK | 1033 | AUTHENTICATION REQUIRED | 401 Unauthorized | 1034 +------------------------+----------------------+ 1036 Table 6: Valid Strings for Response element of responses. 1038 SUCCESSFUL: indicates that the request has been processed properly 1039 and the desired operation has completed. The body of the response 1040 message includes the requested information and MUST include the same 1041 TransactionID of the corresponding request. 1043 In CONNECT Request: returns information about the successful 1044 registration of the peer and/or of each swarm @action requested. 1045 MAY additionally return the list of peers corresponding to the 1046 join @action requested. 1048 In STAT_REPORT Request: confirms the success of the requested 1049 operation. 1051 AUTHENTICATION REQUIRED: Authentication is required for the peer to 1052 make the request. 1054 8. Request/Response Processing 1056 When a PPSP-TP message is received some basic processing is 1057 performed, regardless of the message type. 1059 Upon reception, a message is examined to ensure that it is properly 1060 formed. The receiver MUST check that the HTTP message itself is 1061 properly formed, and if not, appropriate standard HTTP errors MUST be 1062 generated. The receiver must also verify that the XML body is 1063 properly formed. In case of error due to malformed messages 1064 appropriate responses MUST be returned, as described in 8.6. 1066 8.1. CONNECT Request 1068 This method is used when a peer registers to the system and/or 1069 requests swarm actions. 1071 The peer MUST properly form the XML message-body, set the Request 1072 method to CONNECT, generate and set the TransactionIDs, set the 1073 PeerID with the identifier of the peer and include SwarmID action(s) 1074 to be performed. The peer MAY also include the IP addresses of its 1075 network interfaces in the CONNECT message. 1077 An example of the message-body of a CONNECT Request for a peer Seeder 1078 is the following: 1080 1081 1082 CONNECT 1083 656164657220 1084 1111 1086 2222 1088 12345.0 1089 1091 An example of the message-body of a CONNECT Request for a peer 1092 Leecher requesting join to a swarm and providing optional information 1093 on the addresses of its interfaces is the following: 1095 1096 1097 CONNECT 1098 656164657221 1099 5 1100 1111 1102 12345.0 1103 1104 1105 1107 1109 1110 1111 1113 An example of the message-body of a CONNECT Request for a peer 1114 Leecher "leaving" a previously joined swarm and requesting join to a 1115 new swarm is the following: 1117 1118 1119 CONNECT 1120 656164657221 1121 5 1122 1111 1124 2222 1126 12345.0 1127 1129 When receiving a well-formed CONNECT Request message, the tracker 1130 MAY, when applicable, start by pre-processing the peer authentication 1131 information (provided as Authorization scheme and token in the HTTP 1132 message) to check whether it is valid and that it can connect to the 1133 service, then proceed to register the peer in the service and perform 1134 the swarm actions requested. In case of success a Response message 1135 with a corresponding response value of SUCCESSFUL will be generated. 1137 The element SwarmID MUST be present with cardinality 1 to N, each 1138 containing the request for @action, the @peerMode of the peer and the 1139 child @transactionID for that swarm. The @peerMode element MUST be 1140 set to the type of participation of the peer in the swarm (SEED or 1141 LEECH). 1143 The valid sets of SwarmID @action combinations for the CONNECT 1144 Request logic in PPSP-TP base protocol are summarized in Table 7 1145 (referring to the tracker State Machine). 1147 +-----------+-----------+---------+----------+-----------+----------+ 1148 | SwarmID | @peerMode | @action | Initial | Final | Request | 1149 | Elements | value | value | State | State | validity | 1150 +-----------+-----------+---------+----------+-----------+----------| 1151 | 1 | LEECH | JOIN | START | TRACKING | Valid | 1152 +-----------+-----------+---------+----------+-----------+----------+ 1153 | 1 | LEECH | LEAVE | START | TERMINATE | Invalid | 1154 +-----------+-----------+---------+----------+-----------+----------+ 1155 | 1 | LEECH | LEAVE | TRACKING | TERMINATE | Valid | 1156 +-----------+-----------+---------+----------+-----------+----------+ 1157 | 1 | LEECH | JOIN | START | TERMINATE | Invalid | 1158 | 1 | LEECH | LEAVE | | | | 1159 +-----------+-----------+---------+----------+-----------+----------+ 1160 | 1 | LEECH | JOIN | TRACKING | TRACKING | Valid | 1161 | 1 | LEECH | LEAVE | | | | 1162 +-----------+-----------+---------+----------+-----------+----------+ 1163 | N | SEED | JOIN | START | TRACKING | Valid | 1164 +-----------+-----------+---------+----------+-----------+----------+ 1165 | N | SEED | JOIN | TRACKING | TERMINATE | Invalid | 1166 +-----------+-----------+---------+----------+-----------+----------+ 1167 | N | SEED | LEAVE | TRACKING | TERMINATE | Valid | 1168 +-----------+-----------+---------+----------+-----------+----------+ 1170 Table 7: Validity of SwarmID @action combinations in CONNECT Request. 1172 The element PeerInfo, if present, MAY contain multiple PeerAddress 1173 child elements with attributes @addrType, @ip, @port and 1174 @peerProtocol, and optionally @priority and @type (if PPSP-ICE NAT 1175 traversal techniques are used) corresponding to each of the network 1176 interfaces of the peer. 1178 The element PeerNum indicates to the tracker the number of peers to 1179 be returned in a list corresponding to the indicated properties, 1180 being @abilityNAT for NAT traversal (considering that PPSP-ICE NAT 1181 traversal techniques may be used), and optionally @concurrentLinks, 1182 @onlineTime and @uploadBWlevel for the preferred capabilities. 1184 If STUN-like function is enabled in the tracker, the response MAY 1185 include the peer reflexive address. 1187 The response MUST have the same TransactionID values as the 1188 corresponding request and actions. 1190 An example of a Response message for the CONNECT Request is the 1191 following: 1193 1194 1195 SUCCESSFUL 1196 1197 200 OK 1198 200 OK 1199 200 OK 1200 1201 1202 1203 656164657221 1204 1209 1210 1211 956264622298 1212 1214 1215 1216 3332001256741 1217 1219 1220 1221 1223 The Response MUST include a PeerGroup with PeerInfo data of the 1224 requesting peer public IP address. If STUN-like function is enabled 1225 in the tracker, the PeerAddress includes the attribute @type with a 1226 value of REFLEXIVE, corresponding to the transport address 1227 "candidate" of the peer. The PeerGroup MAY also include PeerInfo data 1228 corresponding to the Peer-IDs and public IP addresses of the selected 1229 active peers in the requested swarm. 1231 The tracker MAY also include the attribute @asn with network location 1232 information of the transport address, corresponding to the Autonomous 1233 System Number of the access network provider. 1235 In case the @peerMode is SEED, the tracker responds with a SUCCESSFUL 1236 response and enters the peer information into the corresponding swarm 1237 activity. 1239 In case the @peerMode is LEECH the tracker will search and select an 1240 appropriate list of peers satisfying the conditions set by the 1241 requesting peer. The peer list returned MUST contain the Peer-IDs 1242 and the corresponding IP Addresses. To create the peer list, the 1243 tracker may take peer status and network location information into 1244 consideration, to express network topology preferences or Operators' 1245 policy preferences, with regard to the possibility of connecting with 1246 other IETF efforts such as ALTO [I.D.ietf-alto-protocol]. 1248 8.2. STAT_REPORT Request 1250 This method allows peers to send status and statistic data to 1251 trackers. The method is initiated by the peer, periodically while 1252 active. 1254 The peer MUST properly form the XML message-body, set the Request 1255 method to STAT_REPORT, set the PeerID with the identifier of the 1256 peer, and generate and set the TransactionID. 1258 The report MAY include a StatisticsGroup containing multiple Stat 1259 elements describing several properties relevant to the P2P network. 1260 These properties can be related with stream statistics and peer 1261 status information. 1263 Other properties may be defined, related for example, with incentives 1264 and reputation mechanisms. 1266 In case no StatisticsGroup is included, the STAT_REPORT may be used 1267 as a "keep-alive" message, to prevent the Tracker from de-registering 1268 the peer when timer expired. 1270 An example of the message-body of a STAT_REPORT Request is the 1271 following: 1273 1274 1275 STAT_REPORT 1276 656164657221 1277 12345 1278 1279 1280 1111 1281 512 1282 768 1283 1024000 1284 1285 1286 1287 If the request is valid the tracker processes the received 1288 information for future use, and generates a response message with a 1289 Response value of SUCCESSFUL. 1291 The response MUST have the same TransactionID value as the request. 1293 An example of a Response message for the START_REPORT Request is the 1294 following: 1296 1297 1298 SUCCESSFUL 1299 12345 1300 1302 8.3. Error and Recovery conditions 1304 If the peer fails to read the tracker response, the same Request with 1305 identical content, including the same TransactionID, SHOULD be 1306 repeated, if the condition is transient. 1308 The TransactionID on a Request can be reused if and only if all of 1309 the content is identical, including eventual Date/Time information. 1310 Details of the retry process (including time intervals to pause, 1311 number of retries to attempt, and timeouts for retrying) are 1312 implementation dependent. 1314 The tracker SHOULD be prepared to receive a Request with a repeated 1315 TransactionID. 1317 Error situations resulting from the Normal Operation or from abnormal 1318 conditions (section 6.2) MUST be responded with the adequate response 1319 codes, as described here: 1321 If the message is found to be incorrectly formed, the receiver MUST 1322 respond with a 400 (Bad Request) response with an empty message- 1323 body. The Reason-Phrase SHOULD identify the syntax problem in more 1324 detail, for example, "Missing Content-Type header field". 1326 If the version number of the protocol is for a version the receiver 1327 does not supports, the receiver MUST respond with a 400 (Bad 1328 Request) with an empty message-body. Additional information SHOULD 1329 be provided in the Reason-Phrase, for example, "PPSP Version #.#". 1331 If the length of the message does not matches the Content-Length 1332 specified in the message header, or the message is received without 1333 a defined Content-Length, the receiver MUST respond with a 411 1334 (Length Required) response with an empty message-body. 1336 If the Request-URI in a Request message is longer than the tracker 1337 is willing to interpret, the tracker MUST respond with a 414 1338 (Request-URI Too Long) response with an empty message-body. 1340 In the PEER REGISTERED and TRACKING states of the tracker, certain 1341 requests are not allowed (section 6.2). The tracker MUST respond 1342 with a 403 (Forbidden) response with an empty message-body. The 1343 Reason-Phrase SHOULD identify the error condition in more detail, for 1344 example, "Action not allowed". 1346 If the tracker is unable to process a Request message due to 1347 unexpected condition, it SHOULD respond with a 500 (Internal Server 1348 Error) response with an empty message-body. 1350 If the tracker is unable to process a Request message for being in an 1351 overloaded state, it SHOULD respond with a 503 (Service Unavailable) 1352 response with an empty message-body. 1354 9. Security Considerations 1356 P2P streaming systems are subject to attacks by malicious/unfriendly 1357 peers/trackers that may eavesdrop on signaling, forge/deny 1358 information/knowledge about streaming content and/or its 1359 availability, impersonating to be another valid participant, or 1360 launch DoS attacks to a chosen victim. 1362 No security system can guarantees complete security in an open P2P 1363 streaming system where participants may be malicious or 1364 uncooperative. The goal of security considerations described here is 1365 to provide sufficient protection for maintaining some security 1366 properties during the tracker-peer communication even in the face of 1367 a large number of malicious peers and/or eventual distrustful 1368 trackers (under the distributed tracker deployment scenario). 1370 Since the protocol uses HTTP to transfer signaling most of the same 1371 security considerations described in RFC 2616 also apply [RFC2616]. 1373 9.1. Authentication between Tracker and Peers 1375 To protect the PPSP-TP signaling from attackers pretending to be 1376 valid peers (or peers other than themselves) all messages received in 1377 the tracker SHOULD be received from authorized peers. 1379 For that purpose a peer SHOULD enroll in the system via a centralized 1380 enrollment server. The enrollment server is expected to provide a 1381 proper Peer-ID for the peer and information about the authentication 1382 mechanisms. The specification of the enrollment method and the 1383 provision of identifiers and authentication tokens is out of scope of 1384 this specification. 1386 A Channel-oriented security mechanism should be used in the 1387 communication between peers and tracker, such as the Transport Layer 1388 Security (TLS) to provide privacy and data integrity. 1390 Due to the transactional nature of the communication between peers 1391 and tracker the method for adding authentication and data security 1392 services can be the OAuth 2.0 Authorization [RFC6749] with bearer 1393 token, which provides the peer with the information required to 1394 successfully utilize an access token to make protected requests to 1395 the tracker [RFC6750]. 1397 9.2. Content Integrity protection against polluting peers/trackers 1399 Malicious peers may declaim ownership of popular content to the 1400 tracker but try to serve polluted (i.e., decoy content or even 1401 virus/trojan infected contents) to other peers. 1403 This kind of pollution can be detected by incorporating integrity 1404 verification schemes for published shared contents. As content 1405 chunks are transferred independently and concurrently, a 1406 correspondent chunk-level integrity verification MUST be used, 1407 checked with signed fingerprints received from authentic origin. 1409 9.3. Residual attacks and mitigation 1411 To mitigate the impact of Sybil attackers, impersonating a large 1412 number of valid participants by repeatedly acquiring different peer 1413 identities, the enrollment server SHOULD carefully regulate the rate 1414 of peer/tracker admission. 1416 There is no guarantee that peers honestly report their status to the 1417 tracker, or serve authentic content to other peers as they claim to 1418 the tracker. It is expected that a global trust mechanism, where the 1419 credit of each peer is accumulated from evaluations for previous 1420 transactions, may be taken into account by other peers when selecting 1421 partners for future transactions, helping to mitigate the impact of 1422 such malicious behaviors. A globally trusted tracker MAY also take 1423 part of the trust mechanism by collecting evaluations, computing 1424 credit values and providing them to joining peers. 1426 9.4. Pro-incentive parameter trustfulness 1428 Property types for STAT_REPORT messages may consider pro-incentive 1429 parameters, which can enable the tracker to improve the performance 1430 of the whole P2P streaming system. 1432 Trustworthiness of these pro-incentive parameters is critical to the 1433 effectiveness of the incentive mechanisms. 1435 Furthermore, both the amount of uploaded and downloaded data should 1436 be reported to the tracker to allow checking if there is any 1437 inconsistency between the upload and download report, and establish 1438 an appropriate credit/trust system. Alternatively, exchange of 1439 cryptographic receipts signed by receiving peers can be used to 1440 attest to the upload contribution of a peer to the swarm, as 1441 suggested in [Contracts]. 1443 10. Guidelines for Extending PPSP-TP 1445 Extension mechanisms allow designers to add new features or to 1446 customize existing features of a protocol for different operating 1447 environments. 1449 Since the beginning that extensibility has been a design goal of 1450 PPSP-TP, as the protocol is represented in the Extensible Markup 1451 Language [XML]. 1453 A powerful feature of XML is the extensibility, but this feature also 1454 provides multiple opportunities to make poor design decisions. 1456 Extending a protocol implies either the addition of features without 1457 changing the protocol itself or the addition of new elements creating 1458 new versions of an existing schema and therefore new versions of the 1459 protocol. 1461 In PPSP-TP it means that an extension MUST NOT alter an existing 1462 protocol schema as the changes would result in a new version of an 1463 existing schema, not an extension of an existing schema, typically 1464 non-backwards-compatible. 1466 Additionally, a designer MUST remember that extensions themselves MAY 1467 also be extensible. 1469 Extensions MUST adhere to the principles described in this section in 1470 order to be considered valid. 1472 Extensions MAY be documented as Internet-Draft and RFC documents if 1473 there are requirements for coordination, interoperability, and broad 1474 distribution. 1476 Extensions need not be published as Internet-Draft or RFC documents 1477 if they are intended for operation in a closed environment or are 1478 otherwise intended for a limited audience. 1480 10.1. Forms of PPSP-TP Extension 1482 PPSP-TP extensions MUST be specified in XML. This ensures that 1483 parsers capable of processing PPSP-TP structures will also be capable 1484 of processing PPSP-TP extensions. Guidelines for the use of XML in 1485 IETF protocols can be found in RFC 3470 [RFC3470]. 1487 In PPSP-TP two extension mechanisms can be used: a Request-Response 1488 Extension or a Protocol-level Extension. 1490 o Request-Response Extension: Adding elements or attributes to an 1491 existing element mapping in the schema is the simplest form of 1492 extension. This form should be explored before any other. This 1493 task can be accomplished by extending an existing element mapping. 1495 For example, an element mapping for the StatisticsGroup (Section 1496 7.2.1, Table 4) can be extended to include additional elements 1497 needed to express status information about the activity of the 1498 peer, such as OnlineTime for the Stat element: 1500 1501 3600 1502 1504 Another example also for the StatisticsGroup is for additional 1505 @property attributes and elements, such as those necessary to 1506 report content chunk availability information: 1508 1509 1510 A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/.... 1511 1512 1514 o Protocol-level Extension: If there is no existing element mapping 1515 that can be extended to meet the requirements and the existing 1516 PPSP-TP Request and Response message structures are insufficient, 1517 then extending the protocol should be considered in order to 1518 define new operational Requests and Responses. 1520 For example, to enhance the level of control and the granularity 1521 of the operations, a new version of the protocol with new messages 1522 (JOIN, DISCONNECT), a retro-compatible change in semantics of an 1523 existing CONNECT Request/Response and an extension in STAT_REPORT 1524 could be considered. 1526 As illustrated in Figure 6, the peer would use an enhanced CONNECT 1527 Request to perform the initial registration in the system. Then 1528 it would JOIN a first swarm as Seeder, later JOIN a second swarm 1529 as Leecher, and then DISCONNECT from the latter swarm but keeping 1530 as Seeder for the first one. When deciding to leave the system, 1531 the peer DISCONNECTs gracefully from it: 1533 +--------+ +---------+ 1534 | Peer | | Tracker | 1535 +--------+ +---------+ 1536 | | 1537 |--CONNECT--------------------->| 1538 |<--------------------------OK--| 1539 |--JOIN(swarm_a;SEED)---------->| 1540 |<--------------------------OK--| 1541 : : 1542 |--STAT_REPORT(activity)------->| 1543 |<--------------------------Ok--| 1544 : : 1545 |--JOIN(swarm_b;LEECH)--------->| 1546 |<-----------------OK+PeerList--| 1547 : : 1548 |--STAT_REPORT(ChunkMap_b)----->| 1549 |<--------------------------Ok--| 1550 : : 1551 |--DISCONNECT(swarm_b)--------->| 1552 |<--------------------------Ok--| 1553 : : 1554 |--STAT_REPORT(activity)------->| 1555 |<--------------------------Ok--| 1556 : : 1557 |--DISCONNECT------------------>| 1558 |<---------------------Ok(BYE)--| 1560 Figure 6: Example of a session for a PPSP-TP extended version. 1562 10.2. Issues to Be Addressed in PPSP-TP Extensions 1564 There are several issues that all extensions should take into 1565 consideration. 1567 - Overview of the Extension: It is RECOMMENDED that extensions to 1568 PPSP-TP have a protocol overview section that discusses the basic 1569 operation of the extension. The most important processing rules 1570 for the elements in the message flows SHOULD also be mentioned. 1572 - Backward Compatibility: One of the most important issues to 1573 consider is whether the new extension is backward compatible with 1574 the base PPST-TP. 1576 - Syntactic Issues: Extensions that define new Request/Response 1577 methods SHOULD use all capitals for the method name, keeping with 1578 a long-standing convention in many protocols, such as HTTP. Method 1579 names are case sensitive in PPSP-TP. Method names SHOULD be 1580 shorter than 16 characters and SHOULD attempt to convey the 1581 general meaning of the Request or Response. 1583 - Semantic Issues: PPSP-TP extensions MUST clearly define the 1584 semantics of the extensions. Specifically, the extension MUST 1585 specify the behaviors expected from both the Peer and the Tracker 1586 in processing the extension, with the processing rules in temporal 1587 order of the common messaging scenario. 1589 Processing rules generally specify actions to be taken on receipt 1590 of messages and expiration of timers. 1592 The extension SHOULD specify procedures to be taken in exceptional 1593 conditions that are recoverable. Handling of unrecoverable errors 1594 does not require specification. 1596 - Security Issues: Being security an important component of any 1597 protocol, designers of PPSP-TP extensions need to carefully 1598 consider security requirements, namely authorization requirements 1599 and requirements for end-to-end integrity. 1601 - Examples of Usage: The specification of the extension SHOULD give 1602 examples of message flows and message formatting and include 1603 examples of messages containing new syntax. Examples of message 1604 flows should be given to cover common cases and at least one 1605 failure or unusual case. 1607 11. IANA Considerations 1609 There are presently no IANA considerations with this document. 1611 12. Acknowledgments 1613 The authors would like to thank many people for for their help and 1614 comments, particularly: Zhang Yunfei, Liao Hongluan, Roni Even, 1615 Bhumip Khasnabish, Wu Yichuan, Peng Jin, Chi Jing, Zong Ning, Song 1616 Haibin, Chen Wei, Zhijia Chen, Christian Schmidt, Lars Eggert, David 1617 Harrington, Henning Schulzrinne, Kangheng Wu, Martin Stiemerling, 1618 Jianyin Zhang, Johan Pouwelse and Arno Bakker. 1620 The authors would also like to thank the people participating in the 1621 EU FP7 project SARACEN (contract no. ICT-248474) 1622 [refs.saracenwebpage] for contributions and feedback to this 1623 document. 1625 The views and conclusions contained herein are those of the authors 1626 and should not be interpreted as necessarily representing the 1627 official policies or endorsements, either expressed or implied, of 1628 the SARACEN project or the European Commission. 1630 13. References 1632 13.1. Normative References 1634 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1635 Requirement Levels", BCP 14, RFC 2119, March 1997. 1637 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1638 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1639 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1641 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1642 10646", STD 63, RFC 3629, November 2003. 1644 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1645 (ICE): A Protocol for Network Address Translator (NAT) 1646 Traversal for Offer/Answer Protocols", RFC 5245, April 1647 2010. 1649 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1650 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1652 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1653 October 2008. 1655 [ISO.8601.2004] International Organization for Standardization, 1656 "Data elements and interchange formats - Information 1657 interchange - Representation of dates and times", ISO 1658 Standard 8601, December 2004. 1660 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and F. 1661 Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1662 Edition)", W3C xml, November 2008, 1663 . 1665 [XMLSchema.1] Thompson, H., Beech, D., Maloney, M. and N. 1666 Mendelsohn, "XML Schema Part 1: Structures Second 1667 Edition", W3C xmlschema-1, October 2004, 1668 . 1670 [XMLSchema.2] Biron, P. and A. Malhotra, "XML Schema Part 2: 1671 Datatypes Second Edition", W3C xmlschema-2, October 2004, 1672 . 1674 [XMLNameSpace] Bray, T., Hollander, D., Layman, A., Tobin, R. and H. 1675 Thompson, "Namespaces in XML", W3C REC-xml-names, December 1676 2009, . 1678 [EXI Format] Schneider, J. and T. Kamiya, "Efficient XML Interchange 1679 (EXI) Format 1.0", W3C exi, March 2011, 1680 . 1682 13.2. Informative References 1684 [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", 1685 RFC 1952, May 1996. 1687 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1689 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for 1690 the Use of Extensible Markup Language (XML) within IETF 1691 Protocols", BCP 70, RFC 3470, January 2003. 1693 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1694 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 1695 2005. 1697 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1698 RFC 6749, October 2012. 1700 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 1701 Framework: Bearer Token Usage", RFC 6750, October 2012. 1703 [I-D.ietf-ppsp-problem-statement] Zhang, Y., Zong, N., Camarillo, G., 1704 Seng, J. and Y. Yang, "Problem Statement of P2P Streaming 1705 Protocol (PPSP)", draft-ietf-ppsp-problem-statement-11 1706 (work in progress), October 2012. 1708 [I-D.pantos-http-live-streaming] Pantos. R. and W. May, "HTTP Live 1709 Streaming", draft-pantos-http-live-streaming-10 (work in 1710 progress), October 2012. 1712 [I.D.ietf-alto-protocol] Alimi, R., Penno, R. and Y. Yang, "ALTO 1713 Protocol", draft-ietf-alto-protocol-13, (work in 1714 progress), September 2012. 1716 [I-D.montenegro-httpbis-speed-mobility] Trace, R., Foresti, A., 1717 Singhal, S., Mazahir, O., Nielsen, H., Raymor, B., Rao, R. 1718 and G. Montenegro, "HTTP Speed+Mobility," draft- 1719 montenegro-httpbis-speed-mobility-02 (work in progress), 1720 June 2012. 1722 [ISO.IEC.23009-1] ISO/IEC, "Information technology -- Dynamic 1723 adaptive streaming over HTTP (DASH) -- Part 1: Media 1724 presentation description and segment formats", ISO/IEC DIS 1725 23009-1, Aug. 2011. 1727 [refs.saracenwebpage] "SARACEN Project Website", 1728 http://www.saracen-p2p.eu/. 1730 [Contracts] Piatek, M., Venkataramani, A., Yang, R., Zhang, D. and A. 1731 Jaffe, "Contracts: Practical Contribution Incentives for 1732 P2P Live Streaming", in NSDI '10: USENIX Symposium on 1733 Networked Systems Design and Implementation, April 2010. 1735 Appendix A. PPSP-TP Message Syntax for HTTT/1.1 1737 PPSP-TP messages use the generic message format of RFC 5322 [RFC5322] 1738 for transferring the payload of the message (Requests and 1739 Responses). 1741 PPSP-TP messages consist of a start-line, one or more header fields, 1742 an empty line indicating the end of the header fields, and, when 1743 applicable, a message-body. 1745 The start-line, each message-header line, and the empty line MUST be 1746 terminated by a carriage-return line-feed sequence (CRLF). Note that 1747 the empty line MUST be present even if the message-body is not. 1749 The PPSP-TP message and header field syntax is identical to HTTP/1.1 1750 [RFC2616]. 1752 A Request message is a standard HTTP/1.1 message starting with a 1753 Request-Line generated by the HTTP client peer. The Request-Line 1754 contains a method name, a Request-URI, and the protocol version 1755 separated by a single space (SP) character. 1757 Request-Line = 1758 Method SP Request-URI SP HTTP-Version CRLF 1760 A Request message example is the following: 1762 / HTTP/1.1 1763 Host: 1764 Content-Lenght: 1765 Content-Type: 1766 Authorization: 1768 [Request_Body] 1770 The HTTP Method token and Request-URI (the Resource) identifies the 1771 resource upon which to apply the operation requested. 1773 The Response message is also a standard HTTP/1.1 message starting 1774 with a Status-Line generated by the tracker. The Status-Line 1775 consists of the protocol version followed by a numeric Status-Code 1776 and its associated Reason-Phrase, with each element separated by a 1777 single SP character. 1779 Status-Line = 1780 HTTP-Version SP Status-Code SP Reason-Phrase CRLF 1782 A Response message example is the following: 1784 HTTP/1.1 1785 Content-Lenght: 1786 Content-Type: 1787 Content-Encoding: 1789 [Response_Body] 1791 The Status-Code element is a 3-digit integer result code that 1792 indicates the outcome of an attempt to understand and satisfy a 1793 request. 1795 The Reason-Phrase element is intended to give a short textual 1796 description of the Status-Code. 1798 A.1. Header Fields 1800 The header fields are identical to HTTP/1.1 header fields in both 1801 syntax and semantics. 1803 Some header fields only make sense in requests or responses. If a 1804 header field appears in a message not matching its category (such as 1805 a request header field in a response), it MUST be ignored. 1807 The Host request-header field in the request message follows the 1808 standard rules for the HTTP/1.1 Host header. 1810 The Content-Type entity-header field MUST be used in requests and 1811 responses containing message-bodies to define the Internet media type 1812 of the message-body. 1814 The Content-Encoding entity-header field MAY be used in response 1815 messages with "gzip" compression scheme [RFC1952] for faster 1816 transmission times and less network bandwidth usage. 1818 The Content-Length entity-header field MUST be used in messages 1819 containing message-bodies to locate the end of each message in a 1820 stream. 1822 The Authorization header field in the request message allows a peer 1823 to authenticate itself with a tracker, containing authentication 1824 information. 1826 A.2. Methods 1828 PPSP-TP uses HTTP/1.1 POST method token for all request messages. 1830 A.3. Message Bodies 1831 PPSP-TP requests MUST contain message-bodies. 1833 PPSP-TP responses MAY include a message-body. 1835 If the message-body has undergone any encoding such as compression, 1836 then this MUST be indicated by the Content-Encoding header field; 1837 otherwise, Content-Encoding MUST be omitted. 1839 The character set of the message body is indicated as part of the 1840 Content-Type header-field, and the default value for PPSP-TP messages 1841 is "UTF-8". 1843 A.4. Message Response Codes 1845 The response codes in PPSP-TP response messages are consistent with 1846 HTTP/1.1 response status-codes. However, not all HTTP/1.1 response 1847 status-codes are appropriate for PPSP-TP, and only those that are 1848 appropriate are given here. Other HTTP/1.1 response codes SHOULD NOT 1849 be used in PPSP-TP. 1851 The class of the response is defined by the first digit of the 1852 Status-Code. The last two digits do not have any categorization 1853 role. For this reason, any response with a Status-Code between 200 1854 and 299 is referred to as a "2xx response", and similarly to the 1855 other supported classes: 1857 2xx: Success -- the action was successfully received, understood, and 1858 accepted; 1859 4xx: Peer Error -- the request contains bad syntax or cannot be 1860 fulfilled at this tracker; 1861 5xx: Tracker Error -- the tracker failed to fulfill an apparently 1862 valid request; 1864 The valid response codes are the following (Status-Code Reason- 1865 Phrase): 1867 200 OK -- The request has succeeded. The information returned with 1868 the response describes or contains the result of the action; 1870 400 Bad Request -- The request could not be understood due to 1871 malformed syntax. 1873 401 Unauthorized -- The request requires authentication. 1875 403 Forbidden -- The tracker understood the request, but is refusing 1876 to fulfill it. The request SHOULD NOT be repeated. 1878 404 Not Found -- This status is returned if the tracker did not find 1879 anything matching the Request-URI. 1881 408 Request Timeout -- The peer did not produce a request within the 1882 time that the tracker was prepared to wait. 1884 411 Length Required -- The tracker refuses to accept the request 1885 without a defined Content-Length. The peer MAY repeat the request 1886 if it adds a valid Content-Length header field containing the 1887 length of the message-body in the request message. 1889 414 Request-URI Too Long -- The tracker is refusing to service the 1890 request because the Request-URI is longer than the tracker is 1891 willing to interpret. This rare condition is likely to occur 1892 when the tracker is under attack by a client attempting to 1893 exploit security holes. 1895 500 Internal Server Error -- The tracker encountered an unexpected 1896 condition which prevented it from fulfilling the request. 1898 503 Service Unavailable -- The tracker is currently unable to handle 1899 the request due to a temporary overloading or maintenance 1900 condition. 1902 Authors' Addresses 1904 Rui Santos Cruz 1905 IST/INESC-ID/INOV 1906 Phone: +351.939060939 1907 Email: rui.cruz@ieee.org 1909 Gu Yingjie 1910 Huawei 1911 Phone: +86-25-56624760 1912 Fax: +86-25-56624702 1913 Email: guyingjie@huawei.com 1915 Mario Serafim Nunes 1916 IST/INESC-ID/INOV 1917 Rua Alves Redol, n.9 1918 1000-029 LISBOA, Portugal 1919 Phone: +351.213100256 1920 Email: mario.nunes@inov.pt 1922 Jinwei Xia 1923 Huawei 1924 Nanjing, Baixia District 210001, China 1925 Phone: +86-025-86622310 1926 Email: xiajinwei@huawei.com 1928 Joao P. Taveira 1929 IST/INOV 1930 Email: joao.silva@inov.pt 1932 Deng Lingli 1933 China Mobile