idnits 2.17.1 draft-cruz-ppsp-http-peer-protocol-00.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 (May 31, 2011) is 4714 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 1952' is mentioned on line 529, but not defined == Missing Reference: 'RFC 2616' is mentioned on line 530, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Unused Reference: 'RFC1952' is defined on line 1001, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ppsp-reqs' is defined on line 1015, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-05) exists of draft-ietf-ppsp-reqs-02 == Outdated reference: A later version (-15) exists of draft-ietf-ppsp-problem-statement-01 == Outdated reference: A later version (-07) exists of draft-gu-ppsp-tracker-protocol-04 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPSP Rui S. Cruz 3 INTERNET-DRAFT IST/INESC-ID/INOV 4 Intended Status: Informational Mario S. Nunes 5 Expires: December 2, 2011 IST/INESC-ID/INOV 6 Joao P. Taveira 7 IST/INOV 8 May 31, 2011 10 HTTP-based PPSP Peer Protocol 11 draft-cruz-ppsp-http-peer-protocol-00 13 Abstract 15 This document presents a proposal for an HTTP-based P2P streaming 16 Peer Protocol, outlining the requirements, functional entities, 17 message flows, formal syntax and semantics, with detailed message 18 processing instructions using an HTTP/XML encoding, the respective 19 parameters, methods, and message formats. The PPSP Peer Protocol 20 proposed in this document extends the capabilities of PPSP to support 21 adaptive and scalable video, for Video On Demand (VoD) and Live video 22 services. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright and License Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.2 Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.3 Streaming Modes . . . . . . . . . . . . . . . . . . . . . . 10 67 3.4 Chunk Scheduling . . . . . . . . . . . . . . . . . . . . . 11 68 3.5 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . 11 69 3.6 Manifest File . . . . . . . . . . . . . . . . . . . . . . . 11 70 4 Messages syntax and processing . . . . . . . . . . . . . . . . 14 71 4.1 HTTP/XML Encoding . . . . . . . . . . . . . . . . . . . . . 14 72 4.2 Method Fields . . . . . . . . . . . . . . . . . . . . . . . 15 73 4.3 Message Processing . . . . . . . . . . . . . . . . . . . . 16 74 4.4 GET_PEERLIST Message . . . . . . . . . . . . . . . . . . . 16 75 4.5 GET_CHUNKMAP Message . . . . . . . . . . . . . . . . . . . 19 76 4.6 GET_CHUNK Message . . . . . . . . . . . . . . . . . . . . . 20 77 4.7 PEER_STATUS Message . . . . . . . . . . . . . . . . . . . . 22 78 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 23 79 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23 80 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 23 81 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 82 8.1 Normative References . . . . . . . . . . . . . . . . . . . 23 83 8.2 Informative References . . . . . . . . . . . . . . . . . . 24 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 86 1 Introduction 88 The P2P Streaming Protocol (PPSP) is composed of two protocols: the 89 PPSP Tracker Protocol and the PPSP Peer Protocol 90 [I-D.ietf-ppsp-problem-statement]. 92 The PPSP Tracker Protocol provides communication between Trackers and 93 Peers, by which Peers exchange meta information with trackers, report 94 streaming status and request candidate lists from trackers. The PPSP 95 Peer protocol controls the advertising and exchange of media data 96 directly between peers. 98 The PPSP architecture requires PPSP peers able to communicate with a 99 tracker in order to participate in a particular swarm. This 100 centralized tracker service is used for peer boostraping and for for 101 content registration and location. Content indexes (manifest files) 102 are also stored in the tracker system allowing the association of 103 content location information to the active peers sharing the content 104 in the swarm. 106 The signaling between PPSP Peers and trackers is done using a 107 request/reply mechanism as defined in PPSP Tracker protocol 108 [I-D.gu-ppsp-tracker-protocol]. 110 The signaling between PPSP Peers can also be done using a 111 request/reply mechanism proposed in this document as PPSP Peer 112 protocol. 114 The process used for streaming distribution relies on a chunk 115 transfer scheme whereby the original content is re-encoded using 116 adaptive or scalable techniques and then chopped into small video 117 chunks with a short duration: 119 1. (adaptive) - alternate versions with different qualities and 120 bitrates; 121 2. (scalable description levels) - multiple additive descriptions 122 (i.e., addition of descriptions refine the quality of the video); 123 3. (scalable layered levels) - nested dependent layers corresponding 124 to several hierarchical levels of quality, i.e., higher 125 enhancement layers refine the quality of the video of lower 126 layers. 128 These streaming distribution techniques support dynamic variations in 129 video streaming quality while ensuring support for a plethora of end 130 user devices and network connections. 132 The information that should be exchanged among peers using this peer 133 protocol includes: 135 1. peer lists, for the swarms they are participating in. 136 2. chunk maps, indicating which chunks a peer possesses (for both VoD 137 and Live streaming). 138 3. required chunks. 139 4. peer activity and status. 140 5. information to help improve the performance of PPSP. 142 This PPSP Peer Protocol proposal presents an early sketch for an 143 extensible protocol that extends the capabilities of PPSP to support 144 adaptive and scalable video, as a way to identify open issues and 145 further discussion in the PPSP WG [I-D.ietf-ppsp-survey]. 147 2 Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119 [RFC2119]. 153 This draft uses the terms defined in 154 [I-D.ietf-ppsp-problem-statement] and in 155 [I-D.gu-ppsp-tracker-protocol]. 157 Absolute Time: Absolute time is expressed as ISO 8601 [ISO.8601.2004] 158 timestamps, using zero UTC offset (GMT). Fractions of a second may 159 be indicated. Example for December 25, 2010 at 14h56 and 20.25 160 seconds: basic format 20101225T145620.25Z or extended format 161 2010-12-25T14:56:20.25Z. 163 Adaptive Streaming: multiple alternate versions (different qualities 164 and bitrates) of the same media content co-exist for the same 165 streaming session; each alternate version corresponds to a different 166 media quality level; peers can choose among the alternate versions 167 for decode and playback. 169 Base Layer: the playable level in Scalable Video Coding (SVC) 170 required by all upper level Enhancements Layers for proper decoding 171 of the video. 173 Chunk: A chunk is a basic unit of partitioned streaming media, which 174 is used by a peer for the purpose of storage, advertisement and 175 exchange among peers. 177 Enhancement Layer: enhancement differential quality level in Scalable 178 Video Coding (SVC) used to produce a higher quality, higher 179 definition video in terms of space (i.e., image resolution), time 180 (i.e., frame rate) or Signal-to-Noise Ratio (SNR) when combined with 181 the playable Base Layer. 183 Live streaming: The scenario where all clients receive streaming 184 content for the same ongoing event. The lags between the play points 185 of the clients and that of the streaming source are small. 187 Manifest: The manifest file holds information about the content, 188 i.e., describes the structure of the media, namely, the codecs used, 189 the chunks, and the corresponding mapping within a container file 190 system. 192 Peer: A peer refers to a participant in a P2P streaming system that 193 not only receives streaming content, but also stores and uploads 194 streaming content to other participants. 196 PeerID: Unique identifier for the peer. The PeerID and any required 197 security certificates are obtained from an offline enrollment server. 199 Peer-Peer Messages (i.e., Peer Protocol): The Peer Protocol messages 200 enable each Peer to exchange content availability with other Peers 201 and request other Peers for content. 203 PPSP: The abbreviation of P2P Streaming Protocols. PPSP protocols 204 refer to the key signaling protocols among various P2P streaming 205 system components, including the tracker and peers. 207 Scalable Streaming: With Multiple Description Coding (MDC), multiple 208 additive descriptions (that can be independently played-out) to 209 refine the quality of the video when combined together. With Scalable 210 Video Coding (SVC), nested dependent enhancement layers (hierarchical 211 levels of quality), refine the quality of lower layers, from the 212 lowest level (the playable Base Layer). 214 Swarm: A swarm refers to a group of clients (i.e., peers) sharing the 215 same content (e.g., video/audio program, digital file, etc.) at a 216 given time. 218 SwarmID: Unique identifier for certain swarm. It is used to describe 219 a specific resource shared among peers. 221 Tracker: A tracker refers to a directory service which maintains the 222 lists of PPSP peers storing chunks for a specific channel or 223 streaming file, and answers queries from PPSP peers. 225 Tracker-Peer Messages (i.e., Tracker Protocol): The Tracker Protocol 226 messages provide communication between Peers and Trackers, by which 227 Peers provide content availability, report streaming status and 228 request candidate Peer lists from Trackers. 230 Video-on-demand (VoD): A kind of application that allows users to 231 select and watch video content on demand. 233 3. Protocol Overview 235 The function entities involved in the PPSP Peer Protocol are Peers 236 which may support different capabilities. 238 Peers are of two types (in terms of media sharing role): Seeder and 239 Leecher. 241 The Seeder holds the complete media content (i.e., the container with 242 all the corresponding chunk files). 244 The Leecher is a Peer that is downloading the content and has not yet 245 completed the transfer of all chunk files of the media content 246 (although contributes to the swarm with the files already 247 downloaded). 249 Peers are organized in (various) swarms corresponding each swarm to 250 the group of peers sharing a content at any given time. 252 A P2P streaming process is summarized in Figure 1. 254 When a peer wants to receive streaming of a selected content: 256 1. Peer connects to a tracker and joins a swarm. 257 2. Peer acquires a list of peers from the tracker. 258 3. Peer exchanges its content availability with the peers on the 259 obtained peer list. 260 4. Peer identifies the peers with desired content. 261 5. Peer requests for the content from the identified peers. 263 When a peer wants to share streaming of certain content with others: 265 1. Peer connects to the tracker. 266 2. Peer sends information to the tracker about the swarm it belongs 267 to (joins), plus streaming status and/or content availability. 269 +-----------------------------------+ 270 | Tracker | 271 +-----------------------------------+ 272 ^ | ^ 273 connect/ | | | 274 join/ | | peer list |streaming Status/ 275 query | | |Content availability/ 276 | | |node capability 277 | V | 278 +-------------+ +------------+ 279 | Peer 1 |<------------->| Peer 2 | 280 +-------------+ content info/ +------------+ 281 data requests 283 Figure 1: A PPSP streaming process 285 The PPSP Peer Protocol messages allow for information to be shared 286 directly between Peers. This information includes at least the 287 following: 289 1. peer lists, for the swarms the peers are participating in. 290 2. chunk maps, indicating which chunks a peer possesses (for both VoD 291 and Live streaming). 292 3. required chunks. 293 4. peer activity and status. 294 5. information to help improve the performance of PPSP. 296 The PPSP Peer Protocol is a request-response protocol. Requests are 297 sent, and responses returned to these requests. A single request 298 generates a single response (neglecting fragmentation of messages). 299 The specific operations of the protocol at present, are (names 300 correspond to Method strings): 302 1. GET_PEERLIST 303 2. GET_CHUNKMAP 304 3. GET_CHUNK 305 4. PEER_STATUS 307 GET_PEERLIST: This method allows a peer to request the Peer list for 308 a specific content of a particular swarm to other Peers. The method 309 is mainly used for a peer to refresh/update the list of active peers 310 in the swarm. 312 GET_CHUNKMAP: This method allows a peer to request which chunks of a 313 content the other peer presently stores. The chunk map returned by 314 the other peers lists ranges of chunks. 316 GET_CHUNK: This method allows peers to request chunks to the other 317 Peers. 319 PEER_STATUS: This method allows a peer to exchange information with 320 other peer on its participation status. 322 The Response messages correspond to a number of logical responses 323 common to the Tracker or the Peer protocols request 324 messages.Incorrectly formatted XML request bodies are handled by the 325 HTTP protocol itself and reported in an HTTP message. 327 At present, the minimum set of response messages for the PPSP 328 Streaming Protocols is the following: 330 SUCCESSFUL (200 OK): a message has been processed properly and the 331 desired operation has completed. If the message is a request for 332 information, the body of the message will also include the requested 333 information. 335 INVALID SYNTAX (400 Bad Request): Indicates an error in the format of 336 the message/message body. These responses correspond to errors within 337 the XML/PPSP protocol messages, not HTTP. 339 VERSION NOT SUPPORTED (400 Bad Request): Invalid version of the 340 protocol or message bodies. These responses correspond to errors 341 within the XML/PPSP protocol messages, not HTTP. 343 AUTHENTICATION REQUIRED (401 UNAUTHORISED): Authentication is 344 required to access this information. 346 MESSAGE FORBIDDEN (403 FORBIDDEN): The requester is not allowed to 347 make this request. 349 OBJECT NOT FOUND (404 NOT FOUND): The requested object or a swarm 350 that is being searched for cannot be found. 352 INTERNAL ERROR (500 INTERNAL SERVER ERROR): The server was unable to 353 process the request due to an internal error. 355 TEMPORARILY OVERLOADED (503 SERVICE UNAVAILABLE): The server is 356 unable to process this message at this time. 358 3.1 Assumptions 360 The function entities related to PPSP protocols are the Client Media 361 Player, the service Portal, the Tracker and Peers. Their complete 362 description is not discussed in this document (as not in the scope of 363 this specification). 365 The Client Media Player is the entity providing a direct interface to 366 the end user at the client device, and includes the functions to 367 select, request, decode and render contents. In PPSP the Client Media 368 Player interfaces with the peer using request and response standard 369 formats for HTTP Request and Response messages [RFC2616]. 371 The service Portal is a logical entity typically used for client 372 enrollment and content information publishing, searching and 373 retrieval. 375 The Tracker is a logical entity that maintains the lists of PPSP 376 active peers storing and exchanging chunks for a specific content. 377 The tracker also stores the status of peers, to help in the selection 378 of appropriate candidate peers for a requesting peer. 380 The Peer is also a logical entity embedding the P2P core engine, with 381 a client serving side interface (a proxy HTTP server) to respond to 382 Client Media Player requests and a network side interface (also an 383 HTTP server) to exchange data and PPSP signaling with peers and 384 trackers. 386 3.2 Bootstrapping 388 In order to join an existing P2P streaming service and to participate 389 in content sharing, any peer must first locate a Tracker service, 390 using for example, the following methods (as illustrated in 391 Figure 2): 393 1. From a service provider provisioning mechanism: this is a typical 394 case used on the provider Super-Seeders (edge caches and/or Media 395 Servers). 396 2. From a web page: a Publishing and Searching Portal may provide 397 tracker location information to end users 398 3. From the Manifest file of a content: this metainfo file must 399 contain information about the address of one or more trackers 400 controlling the swarm for that content. 402 In order to be able to bootstrap, a peer must first obtain a PeerID 403 and any required security certificates from an enrollment service 404 (user registration). 406 +--------+ +--------+ +--------+ +---------+ +--------+ 407 | Player | | Peer 1 | | Portal | | Tracker | | Peer 2 | 408 +--------+ +--------+ +--------+ +---------+ +--------+ 409 | | | | | 410 | Page request | | | | 411 |------------------------------->| | | 412 | Page with links | | | 413 |<-------------------------------| | | 414 | Select stream | | | 415 |------------------------------->| | | 416 | Manifest | | | 417 |<-------------------------------| | | 418 | Manifest | CONNECT | | | 419 |--------------->|----------------------------->| | 420 | |<-------------------------OK--| | 421 | | JOIN | | 422 | |----------------------------->| | 423 | |<-------------------------OK--| | 424 | | GET_PEERS | | 425 | |----------------------------->| | 426 |<-----------OK--|<----------------OK Peerlist--| | 427 | | | | | 428 | GET (Chunk) | GET_CHUNK | | | 429 |--------------->|----------------------------------------->| 430 | Chunk | | | 431 |<---------------|<-------------------------------OK Chunk--| 432 | | | | | 434 Figure 2: A typical PPSP bootstrap procedure 436 3.3 Streaming Modes 438 The streaming technique is pull-based, i.e., the client peer requests 439 the media chunks from serving peers and is responsible for handling 440 the buffering that is necessary for the playback processes during the 441 download of the media chunked files, turning this technique more 442 robust to peer churn but still with acceptable latency for a smooth 443 play-out. 445 In Live streaming, all peers are interested in the media coming from 446 an ongoing program, which means that all peers share nearly the same 447 streaming content at a given point of time. Peers may store the live 448 media for further distribution (known as time-shift TV), where the 449 stored media is distributed in a VoD-like manner. 451 In VoD, different peers watch different parts of the recorded media 452 content during a past event. In this case, each peer keeps asking 453 other peers which media chunks are stored in which peers, and then 454 gets the required media from certain/selected peers. 456 3.4 Chunk Scheduling 458 The goal of chunk trading is receiving the stream smoothly (and with 459 small delay) and to cooperate in the distribution procedure. Peers 460 need to exchange information about their current status to enable 461 scheduling decisions. The information exchanged refers to the state 462 of the peer with respect to the flow, i.e., a map of which chunks are 463 needed by a peer to smoothly play-out the stream. 465 This task means: 467 1. sending chunk maps to other nodes with the proper timing, 468 2. receiving chunk maps from other nodes and merging the information 469 in the local buffer map. 470 3. besides chunk map exchange, the signaling includes 471 Status/Request/Select primitives used to trade chunks. 473 The core of the scheduler, not described in this specification, is 474 the algorithm used to choose the chunks to be exchanged and the peers 475 to communicate with. 477 3.5 NAT Traversal 479 It is assumed that all trackers must be in the public Internet. This 480 document will not describe NAT Traversal mechanisms but the proposed 481 protocol tries to enable flexible NAT Traversal. Future versions will 482 consider the requirements raised by NAT. 484 3.6 Manifest File 486 The Manifest file holds information about the content, i.e., 487 describes the structure of the media, namely, the codecs used, the 488 chunks, the number of layers (in case of SVC) or number of 489 descriptions (in case of MDC), and the corresponding mapping within a 490 container file system. 492 The Manifest is a Well-Formed XML Document, encoded as double-byte 493 Unicode. 495 The Manifest is a composite schema that includes, as root Element, a 496 StreamInfo field that encapsulates all the metadata required for the 497 play-out of the media in groups of fields with 498 elements corresponding to each component of the media (video, audio) 499 streams, as well as other associated metadata (subtitles, text 500 descriptions, etc.). The different elements may include 501 specific descriptor elements, like Video and Audio and respective 502 attributes for each of the media types. An example of a XML manifest 503 for a VoD scalable video content is the following (Figure 3): 505 506 507 508 509 510 511 123456abcd 512 513 path/name 514 some description 515 519 520 521 522 523 525 Figure 3: XML Manifest for a VoD scalable video 527 The Manifest file for P2P Streaming MUST contain Tracker information 528 prior to its upload to the Service Tracker during the publishing 529 procedure and can be compressed with GZIP file format [RFC 1952] in 530 order to be used with HTTP compression [RFC 2616] for faster 531 transmission times and less network bandwidth usage. 533 The Client Media Player parses the downloaded Manifest file and, if 534 it includes information for P2P Streaming, sends the file to the Peer 535 via a HTTP POST and waits for the response in order to start 536 requesting media chunks to decode and play-out. 538 The Manifest file can also be used for direct download/stream (HTTP 539 Streaming) from a specific server, and in this case, the file is not 540 appended with the P2P Tracker information. The Client Media Player, 541 in this case, just starts requesting media chunks from the HTTP 542 Streaming server to decode and play-out. 544 The Manifest file for Live Streaming has a similar structure but 545 describes a sliding window of a small range of from 546 the live program stream timeline (typically, 10 seconds of video). 547 The sliding window is updated for every new encoded segment of the 548 program stream. An example of a XML manifest for a Live scalable 549 video content is the following (Figure 4): 551 552 553 554 555 556 557 654321xyz 558 TRUE 559 06:56:18 560 561 1258 562 path/name 563 some description 564 568 569 570 571 572 574 Figure 4: XML Manifest for a Live scalable video 576 The naming convention used to identify the media chunks considers a 577 sequencial numbering for the chunks, concatenated with the identifier 578 of the content, tipically an alphanumeric string. For SVC and MDC 579 contents, a "leveltype" and a "level_id" are added, being the media 580 chunks named as follows: 582 SVC/MDC: 583 <-><->. 585 other: <->. 587 Where is a character with values L for SVC Layers and D 588 for MDC descriptions, and is a numeric value identifying 589 the layer (SVC) or description (MDC). 591 Examples of the naming convention for a content_id="A123456789" are 592 as following: 594 SVC: A123456789-L0-00000.h264 - chunk 0, layer 0 (base layer) 595 SVC: A123456789-L1-00000.h264 - chunk 0, layer 1 (enhanced layer) 596 MDC: A123456789-D0-0000.h264 - chunk 0, description 0 597 Audio AAC: A123456789-00000.aac 598 Video MPEG: A123456789-00000.mp4 600 4 Messages syntax and processing 602 The PPSP Peer Protocol messages follow the request and response 603 standard formats for HTTP Request and Response messages [RFC2616]. 605 4.1 HTTP/XML Encoding 607 A Request message is a standard HTTP Request generated by the HTTP 608 Client Peer with the following syntax: 610 / HTTP/1.1 611 Host: 613 The HTTP Method and URI path (the Resource) indicates the operation 614 requested. The current proposal uses only HTTP POST as a mechanism 615 for the request messages. 617 The Host header follows the standard rules for the HTTP 1.1 Host 618 Header. 620 The Response message is also a standard HTTP Response generated by 621 the HTTP Serving Peer with the following syntax: 623 HTTP/1.1 624 Content-Lenght: 625 Content-Type: 626 Content-Encoding: 627 629 The body for both Request and Response messages are encoded in XML 630 for all the PPSP Peer Protocols messages, with the following schema 631 (the XML information being method specific): 633 634 635 *** 636 *** 637 ### 638 ...XML information specific of the Method... 639 641 In the XML body, the *** represents alphanumeric data and ### 642 represents numeric data to be inserted. The corresponds to 643 the method type for the message, the corresponds to the 644 response method type of the message and the element 645 uniquely identifies the transaction. 647 The Response message MAY use Content-Encoding entity-header with 648 "gzip" compression scheme [RFC2616] for faster transmission times and 649 less network bandwidth usage. 651 4.2 Method Fields 653 Table 1 and Table 2 define the valid string representations for the 654 requests and responses, respectively. These values MUST be treated 655 as case-insensitive. 657 +--------------+--------------------------+ 658 | PPSP Request | XML Request Value String | 659 +--------------+--------------------------+ 660 | GET_PEERLIST | GET_PEERLIST | 661 | GET_CHUNKMAP | GET_CHUNKMAP | 662 | GET_CHUNK | GET_CHUNK | 663 | PEER_STATUS | PEER_STATUS | 664 +--------------+--------------------------+ 666 Table 1: Valid Strings for Requests 668 +----------------------+---------------------+--------------------+ 669 | Response Method Name | HTTP Response | XML Response Value | 670 | | Mechanism | | 671 +----------------------+---------------------+--------------------+ 672 | SUCCESSFUL (OK) | 200 OK | OK | 673 | INVALID SYNTAX | 400 Bad Request | INVALID SYNTAX | 674 | VERSION NOT | 400 Bad Request | VERSION NOT | 675 | SUPPORTED | | SUPPORTED | 676 | AUTHENTICATION | 401 Unauthorized | AUTHENTICATION | 677 | REQUIRED | | REQUIRED | 678 | MESSAGE FORBIDDEN | 403 Forbidden | MESSAGE FORBIDDEN | 679 | OBJECT NOT FOUND | 404 Not Found | OBJECT NOT FOUND | 680 | INTERNAL ERROR | 500 Internal Server | INTERNAL ERROR | 681 | | Error | | 682 | TEMPORARILY | 503 Service | TEMPORARILY | 683 | OVERLOADED | Unavailable | OVERLOADED | 684 +----------------------+---------------------+--------------------+ 686 Table 2: Valid Strings for Responses 688 4.3 Message Processing 690 When a PPSP Peer Protocol message is received in a peer, some basic 691 processing is performed, regardless of the message type. 693 Upon reception, a message is examined to ensure that it is properly 694 formed. The receiver MUST check that the HTTP message itself is 695 properly formed, and if not appropriate standard HTTP errors MUST be 696 generated. The receiver must also verify that the XML body is 697 properly formed. If the message is found to be incorrectly formed or 698 the length does not match the length encoded in the header, the 699 receiver MUST reply with an HTTP 400 response with a PPSP XML body 700 with the Response method set to INVALID SYNTAX. 702 4.4 GET_PEERLIST Message 704 The GET_PEERLIST message is sent from a client peer to a selected 705 serving peer in order for a peer to refresh/update the list of active 706 peers in the swarm. 708 The Request message uses a HTTP POST method with the following body: 710 711 712 GET_PEERLIST 713 *** 714 *** 715 ### 716 718 The sender MUST properly form the XML body, MUST set the Method 719 string to GET_PEERLIST, MUST set the PeerID to the PeerID of the 720 peer, MUST set the SwarmID to the joined swarm identifier and 721 randomly generate and set the TransactionID value. 723 When receiving the GET_PEERLIST message, and if the message is well 724 formed and accepted, the peer will search for the requested data and 725 will respond to the requesting peer with an HTTP 200 OK message 726 response with a PPSP XML payload SUCCESSFUL, as well as the peer list 727 with PeerIDs (and respective IP Addresses) of peers that can provide 728 the specific content. 730 The response MUST have the same TransactionID value as the request. 732 An example of the Response message structure is the following: 734 735 736 OK 737 *** 738 ### 739 740 741 *** 742 *** 743 744 746 748 749 **** 750 *** 751 ### 752 753 754 *** 755 *** 756 757 759 761 762 **** 763 *** 764 ### 765 766 767 769 The element MAY contain multiple child 770 elements. 772 The element MAY contain multiple child 773 elements with attributes "ip" and "port" corresponding to each of the 774 network interfaces of the peer. The "ip" attribute can be expressed 775 in dotted decimal format for IPv4 or 16-bit hexadecimal values (hh) 776 separated by colons (:) for IPv6. 778 The elements and have a string 779 format, and together with the element of numerical 780 integer format, form a set of information related to peer location. 782 4.5 GET_CHUNKMAP Message 784 The GET_CHUNKMAP message is sent from a client peer to a selected 785 serving peer in order to receive the map of chunks of a content (of a 786 swarm identified by SwarmID) the other peer presently stores. The 787 chunk map returned by the other peer lists ranges of chunks. The 788 Request message uses a HTTP POST method with the following body: 790 791 792 GET_CHUNKMAP 793 *** 794 *** 795 ### 796 798 The sender MUST properly form the XML body, MUST set the Method 799 string to GET_CHUNKMAP, MUST set the PeerID to the PeerID of the 800 peer, MUST set the SwarmID to the joined swarm identifier and 801 randomly generate and set the TransactionID value. 803 When receiving the GET_CHUNKMAP message, and if the message is well 804 formed and accepted, the peer will search for the requested data and 805 will respond to the requesting peer with an HTTP 200 OK message 806 response with a PPSP XML payload SUCCESSFUL, as well as the map of 807 chunks it currently stores of the specific content. 809 The response MUST have the same TransactionID value as the request. 811 The Response message is an HTTP 200 OK message with the following 812 body, exemplified for a video component of a media clip: 814 815 816 OK 817 ### 818 819 *** 820 821 *** 822 823 825 ...(base64 string)... 826 827 828 829 830 832 The element MAY contain multiple child elements. 834 The element has an attribute "type" that indicates 835 the type of media of the corresponding chunks. 837 A element MAY contain multiple child 838 elements with attributes "from" and "to" corresponding to ranges of 839 contiguous chunks. The "from", "to", and "bitmapSize" attributes are 840 expressed as integer number string format. The content 841 corresponds to the chunk map, and is represented as base64 encoded 842 string. 844 4.6 GET_CHUNK Message 846 The GET_CHUNK message is sent from a client peer to a serving peer in 847 order to request the delivery of media content chunks. The Request 848 message uses a HTTP POST method with the following body: 850 851 852 GET_CHUNK 853 *** 854 *** 855 ### 856 858 The sender MUST properly for the HTTP request for a POST method 859 including the URI path (the Resource) of the chunk. The sender MUST 860 also properly form the XML body, MUST set the Method string to 861 GET_CHUNK, MUST set the PeerID to the PeerID of the peer, MUST set 862 the SwarmID to the joined swarm identifier and randomly generate and 863 set the TransactionID value. 865 +--------------+ +-------------+ 866 | Peer (Leech) | | Peer (Seed) | 867 +--------------+ +-------------+ 868 | POST /path/name/123456789-L0-00000.h264 HTTP/1.1 | 869 | Host: example.net | 870 |------------------------------------------------------>| 871 | | 872 | | 873 | GET_CHUNK | 874 | *** | 875 | *** | 876 | ### | 877 | | 878 | | 879 | | 880 | HTTP/1.1 200 OK | 881 | Content-Type: text/xml | 882 | Transfer-Encoding: chunked | 883 |<------------------------------------------------------| 884 | | 885 | 143 | 886 | | 887 | | 888 | OK | 889 | ### | 890 | | 891 | | 892 | ### | 893 | (### bytes of the video chunk) | 894 | 0 | 896 Figure 5: Example of GET_CHUNK message sequence (simplified) 898 When receiving the GET_CHUNK message, and if the message is well 899 formed and accepted, the peer will search for the requested data and 900 will respond to the requesting peer with an HTTP 200 OK message 901 response with a PPSP XML payload SUCCESSFUL, as well as the map of 902 chunks it currently stores of the specific content. 904 The Response message is an HTTP 200 OK message with the body, 905 immediately followed by the chunk data transfer, as shown in 906 Figure 5. 908 The response MUST have the same TransactionID as the request. 910 4.7 PEER_STATUS Message 912 The PEER_STATUS message is sent from a serving peer to a client peer 913 to indicate its participation status. The information conveyed may 914 include information related to chunk trading like "choke" (to inform 915 the other peer of the intention to stop sending data to it) and 916 "unchoke" (to inform the other peer of the intention to start/re- 917 start sending data to it). 919 The Request message uses a HTTP POST method with the following body: 921 922 923 PEER_STATUS 924 *** 925 *** 926 ### 927 (choke/unchoke) 928 930 The sender MUST properly form the XML body, MUST set the Method 931 string to PEER_STATUS, MUST set the PeerID to the PeerID of the peer, 932 MUST set the SwarmID to the joined swarm identifier and randomly 933 generate and set the TransactionID value. 935 When receiving the PEER_STATUS message, and if the message is well 936 formed and accepted, the peer will respond to the requesting peer 937 with an HTTP 200 OK message response with a PPSP XML payload 938 SUCCESSFUL. 940 If the status signal received is "choke" the peer will stop 941 requesting chunks from the other peer until receiving an "unchoke" 942 status signal. 944 The only element currently defined in the request message is 945 , assuming values of "choke" and "unchoke", but, in future, 946 other values may be added. 948 The Response message is an HTTP 200 OK message with the following 949 body. 951 952 953 OK 954 ### 955 957 The response MUST have the same TransactionID value as the request. 959 The only element currently defined in the response message is the 960 , but, in future, other elements may be added, for 961 example, containing statistical data or other primitives for chunk 962 trading negotiation. 964 5 Security Considerations 966 The security considerations will depend on the design of the PPSP 967 peer protocol. Security will be considered in further version of this 968 draft. 970 6 IANA Considerations 972 There are presently no IANA considerations with this document. 974 7 Acknowledgments 976 The authors would like to thank all the people participating in the 977 EU FP7 project SARACEN for contributions and feedback to this 978 document. 980 SARACEN (Socially Aware, collaboRative, scAlable Coding mEdia 981 distributioN), is a research initiative funded partially by the 982 Information Society and Media Directorate General of the European 983 Commission under the Seventh Framework programme (contract no. ICT- 984 248474). 986 The views and conclusions contained herein are those of the authors 987 and should not be interpreted as necessarily representing the 988 official policies or endorsements, either expressed or implied, of 989 the SARACEN project or the European Commission. 991 The Response method names and some text describing them, was borrowed 992 from [I-D.gu-ppsp-tracker-protocol]. 994 8 References 996 8.1 Normative References 998 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 999 Requirement Levels", BCP 14, RFC 2119, March 1997. 1001 [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", 1002 RFC 1952, May 1996. 1004 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1005 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1006 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1008 [ISO.8601.2004] International Organization for Standardization, "Data 1009 elements and interchange formats - Information interchange 1010 - Representation of dates and times", ISO Standard 8601, 1011 December 2004. 1013 8.2 Informative References 1015 [I-D.ietf-ppsp-reqs] Zong, N., Zhang, Y., Avila, V., Williams, C., 1016 and L. Xiao, "P2P Streaming Protocol (PPSP) 1017 Requirements", draft-ietf-ppsp-reqs-02 (work in progress), 1018 February 2011. 1020 [I-D.ietf-ppsp-problem-statement] Zhang, Y., Zong, N., Camarillo, G., 1021 Seng, J., and Y. Yang, "Problem Statement of P2P Streaming 1022 Protocol (PPSP)", draft-ietf-ppsp-problem-statement-01 1023 (work in progress), January 2011. 1025 [I-D.ietf-ppsp-survey] Yingjie, G., Zong, N., Zhang, H., Zhang, Y., 1026 Lei, J., Camarillo, G., and L. Yong, "Survey of P2P 1027 Streaming Applications", draft-gu-ppsp-survey-02 (work in 1028 progress), March 2011. 1030 [I-D.gu-ppsp-tracker-protocol] Yingjie, G., Bryan, D., Zhang, Y., and 1031 H. liao, "PPSP Tracker Protocol", draft-gu-ppsp-tracker- 1032 protocol-04 (work in progress), May 2011. 1034 [refs.saracenwebpage] "SARACEN Project Website", 1035 http://www.saracen-p2p.eu/. 1037 Authors' Addresses 1039 Rui Santos Cruz 1040 IST/INESC-ID/INOV 1041 Phone: +351.939060939 1042 Email: rui.cruz@ieee.org 1044 Mario Serafim Nunes 1045 IST/INESC-ID/INOV 1046 Rua Alves Redol, n.9 1047 1000-029 LISBOA, Portugal 1048 Phone: +351.213100256 1049 Email: mario.nunes@inov.pt 1051 Joao Pedro Taveira Pinto Silva 1052 IST/INOV 1053 Phone: +351.966913777 1054 Email: joao.taveira@inov.pt