idnits 2.17.1 draft-gu-ppsp-peer-protocol-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Oct 31, 2011) is 4551 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: 'TBD' is mentioned on line 853, but not defined == Unused Reference: 'I-D.ietf-ppsp-reqs' is defined on line 649, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ppsp-survey' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'BittorrentSpecification' is defined on line 673, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- No information found for draft-ietf-ppsp-problem-statement - is the name correct? -- No information found for draft-ietf-ppsp-reqs - is the name correct? -- No information found for draft-cruz-ppsp-http-peer-protocol - is the name correct? -- No information found for draft-li-ppsp-nat-traversal - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPSP Y. Gu 3 Internet-Draft J. Xia 4 Intended status: Standards Track Huawei 5 Expires: May 3, 2012 R. Cruz 6 M. Nunes 7 IST/INESC-ID/INOV 8 David A. Bryan 9 Polycom 10 J. Taveira 11 ID/INOV 12 Oct 31, 2011 14 Peer Protocol 15 draft-gu-ppsp-peer-protocol-03 17 Abstract 19 This document presents the architecture of the PPSP Peer protocol 20 outlining the functional entities, message flows and message 21 processing instructions, with the respective parameters. The PPSP 22 Peer Protocol proposed in this document extends the capabilities of 23 PPSP to support adaptive and scalable video and 3D video, for Video 24 On Demand (VoD) and Live video services. The protocol messages 25 formal syntax and semantics, methods, and formats are presented for 26 both Binary and HTTP/XML encoded formats. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 3, 2012. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 65 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 67 3.1. Protocol Architecture . . . . . . . . . . . . . . . . . . 7 68 3.2. Example Call Flow . . . . . . . . . . . . . . . . . . . . 9 69 3.3. Chunk Scheduling . . . . . . . . . . . . . . . . . . . . . 10 70 4. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 11 71 5. Security Consideration . . . . . . . . . . . . . . . . . . . . 13 72 5.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 13 73 5.2. Content Integrity Protection Against Polluting 74 Peers/Trackers . . . . . . . . . . . . . . . . . . . . . . 13 75 5.3. Residual Attacks and Mitigation . . . . . . . . . . . . . 14 76 5.4. Pro-incentive Parameter Trustfulness . . . . . . . . . . . 14 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 79 6.2. Informative References . . . . . . . . . . . . . . . . . . 15 80 Appendix A. Binary Encoding . . . . . . . . . . . . . . . . . . . 16 81 A.1. Methods in Peer messages . . . . . . . . . . . . . . . . . 17 82 Appendix B. HTTP/XML Encoding . . . . . . . . . . . . . . . . . . 21 83 B.1. HTTP/XML Encoding . . . . . . . . . . . . . . . . . . . . 21 84 B.2. Method Fields . . . . . . . . . . . . . . . . . . . . . . 22 85 B.3. Message Processing . . . . . . . . . . . . . . . . . . . . 23 86 B.4. GET_PEERLIST Message . . . . . . . . . . . . . . . . . . . 24 87 B.5. GET_CHUNKMAP Message . . . . . . . . . . . . . . . . . . . 26 88 B.6. GET_CHUNK Message . . . . . . . . . . . . . . . . . . . . 27 89 B.7. PEER_STATUS Message . . . . . . . . . . . . . . . . . . . 29 90 B.8. TRANSPORT_NEGOTIATION Message . . . . . . . . . . . . . . 30 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 93 1. Introduction 95 The P2P Streaming Protocol (PPSP) is composed of two protocols: the 96 PPSP Tracker Protocol and the PPSP Peer Protocol 97 [I-D.ietf-ppsp-problem-statement]. 99 The PPSP architecture requires PPSP peers able to communicate with a 100 Tracker in order to participate in a particular swarm. This 101 centralized Tracker service is used for peer and content registration 102 and location. Content indexes (Media Presentation Descriptions) are 103 also stored in the Tracker system allowing the association of content 104 location information to the active peers in the swarm sharing the 105 content. 107 The PPSP Tracker Protocol provides communication between Trackers and 108 Peers and outlines how a peer is able to communicate with a tracker 109 in order to exchange meta information about the location of other 110 peers contributing with a specific stream (swarm) the peer interested 111 in, as well as to report streaming status. The Peer can also apply 112 to be a contributor for several streams (swarms), periodically 113 reporting its status to the Tracker, allow it to estimate whether the 114 peer is a competent contributor. 116 The PPSP Peer protocol outlines how a peer is able to communicate 117 with other peers in order to control the advertising and exchange of 118 media data, directly between peers, for a specific stream (swarm), as 119 described in [I-D.ietf-ppsp-problem-statement]. 121 The process used for media streaming distribution assumes a segment 122 transfer scheme whereby the original content (that can be encoded 123 using adaptive or scalable techniques) is chopped into small segments 124 (and subsegments). For simplicity, in this document the segments 125 (and subsegments) of media are named Chunks. The media streaming 126 process has the following representations: 128 1. Adaptive - alternate representations with different qualities and 129 bitrates; a single represention is non-adaptive; 131 2. Scalable description levels - multiple additive descriptions 132 (i.e., addition of descriptions refine the quality of the video); 134 3. Scalable layered levels - nested dependent layers corresponding 135 to several hierarchical levels of quality, i.e., higher 136 enhancement layers refine the quality of the video of lower 137 layers. 139 4. Scalable multiple views - views correspond to mono and 140 stereoscopic 3D videos, with several hierarchical levels of 141 quality. 143 These streaming distribution techniques support dynamic variations in 144 video streaming quality while ensuring support for a plethora of end 145 user devices and network connections. 147 The information that should be exchanged between peers using this 148 Peer Protocol includes: 150 1. ChunkMap indicating which chunks a peer possesses. 152 2. Required ChunkIDs 154 3. Peer preferences and status information 156 4. Signalling and Data Transport protocol negotiation 158 5. Information that can help improve the performance of PPSP. 160 In this document, a set of concrete information that needs to be 161 exchanged between peers is introduced, together with the messages to 162 convey such information. 164 This documents describes the PPSP Peer protocol and how it satisfies 165 the requirements for the IETF Peer-to-Peer Streaming Protocol (PPSP), 166 in order to derive the implications for the standardization of the 167 PPSP streaming protocols and to identify open issues and promote 168 further discussion. 170 This PPSP Peer Protocol proposal presents an early sketch for an 171 extensible protocol that extends the capabilities of PPSP to support 172 adaptive and scalable video. 174 2. Document Conventions 176 2.1. Notational Conventions 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 2.2. Terminology 184 The draft uses the terms defined in 185 [I-D.ietf-ppsp-problem-statement], [I-D.gu-ppsp-tracker-protocol] and 186 [I-D.cruz-ppsp-http-peer-protocol]. Additionally, This document uses 187 the following acronyms and definitions frequently in itself: 189 Peer-Peer Messages 191 The Peer Protocol messages enable each Peer to exchange content 192 availability with other Peers and request other Peers for content. 194 Tracker-Peer Messages 196 The Tracker Protocol messages provide communication between Peers 197 and Trackers, by which Peers provide content availability, report 198 streaming status and request candidate Peer lists from Trackers. 200 Connection Tracker 202 The Tracker Node to which the PPSP Peer will connect when it wants 203 to join the PPSP system. 205 Sender Peer 207 A peer that contains the corresponding chunk files requested by 208 leech peer is the Sender peer. Many peers can contain the 209 content, but only one who is contributing the content to the leech 210 peer can be named as Sender peer. 212 Leech Peer 214 A peer that requests the specific media content from other peers. 215 Note that the leech peer can also contribute the downloaded media 216 content (i.e., chunks) even the swarm is not completed, in such 217 case, the leech peer will take on the role of sender peer for 218 downloaded chunks. 220 Chunk Map 222 A peer list that indicates which chunks can be available for leech 223 peer to playback smoothly. 225 Live Streaming 227 The scenario where all clients receive streaming content for the 228 same ongoing event. The lags between the play points of the 229 clients and that of the streaming source are small. 231 Video-on-demand (VoD) 233 The scenario where all clients are allowed to select and watch 234 video content on demand. 236 Adaptive Streaming 238 Multiple alternate versions (different qualities and bitrates) of 239 the same media content co-exist for the same streaming session; 240 each alternate version corresponds to a different media quality 241 level; peers can choose among the alternate versions for decode 242 and playback. 244 Scalable Streaming 246 With Multiple Description Coding (MDC), multiple additive 247 descriptions (that can be independently played-out) to refine the 248 quality of the video when combined together. With Scalable Video 249 Coding (SVC), nested dependent enhancement layers (hierarchical 250 levels of quality), refine the quality of lower layers, from the 251 lowest level (the playable Base Layer). With Multiple View Coding 252 (MVC), multiple views allow the video to be played in 3D when the 253 views are combined together. 255 Base Layer 257 The playable level in Scalable Video Coding (SVC) required by all 258 upper level Enhancements Layers for proper decoding of the video. 260 Enhancement Layer 262 Enhancement differential quality level in Scalable Video Coding 263 (SVC) used to produce a higher quality, higher definition video in 264 terms of space (i.e., image resolution), time (i.e., frame rate) 265 or Signal-to-Noise Ratio (SNR) when combined with the playable 266 Base Layer. 268 Continuous Media 270 Media with an inherent notion of time, for example, speech, audio, 271 video, timed text or timed metadata. 273 Media Component 275 An encoded version of one individual media type such as audio, 276 video or timed text with specific attributes, e.g., bandwidth, 277 language, or resolution. 279 3. Protocol Overview 280 3.1. Protocol Architecture 282 The functional entities involved in the PPSP Peer Protocol are Peers, 283 which may support different capabilities. 285 Peers correspond to devices that actually participate in sharing a 286 media content and are organized in (various) swarms corresponding 287 each swarm to the group of peers streaming that content at any given 288 time. 290 Each peer contacts a Tracker to advertise which information it has 291 available. When a peer wishes to obtain information about the swarm, 292 it contacts the Tracker to find other peers participating in that 293 specific swarm. 295 The tracker is a logical entity that maintains the lists of peers 296 storing/exchanging chunks for a specific Live media channel or VoD 297 media streaming content, answers queries from peers and collects 298 information on the activity of peers. A simplified network diagram 299 showing this interaction of tracker and peers is depicted in Figure 300 1. 302 +-----------------------------------+ 303 | Tracker | 304 +-----------------------------------+ 305 ^ | ^ 306 connect/ | | | 307 join/ | | peer list |streaming Status/ 308 find/ | | |Content availability/ 309 leave/ | | |node capability 310 disconnect | V | 311 +-------------+ +------------+ 312 | Peer 1 |<------------->| Peer 2 | 313 +-------------+ content info/ +------------+ 314 data requests 316 Figure 1: A PPSP streaming process 318 The signaling between PPSP Peers and trackers is done using a 319 request/reply mechanism as defined in PPSP Tracker protocol 320 [I-D.gu-ppsp-tracker-protocol]. 322 This protocol can be used to connect peers that are sharing real-time 323 streams of video or offline video, segmented in chunks. As for the 324 streams of video, they can correspond to Live or Video on Demand 325 streaming modes. 327 There are some significant differences between the details of these 328 scenarios, i.e., Live streaming, VoD and offline video. From a high 329 level perspective the overall structure is quite similar. The 330 optimal signaling flow for the different scenarios could also be 331 different, but it depends on the real situation and on the 332 implementer's choice 334 This draft defines a PULL based streaming signaling, as mandatory. 335 However, a PUSH based or hybrid streaming signaling can optionally be 336 considered. 338 For a PULL based Peer Protocol, the steps of signaling for a peer 339 wishing to participate either in a Live streaming or a VoD or offline 340 video is as follows (assuming the leech peer has already obtained 341 from the Tracker a list of peers) and that, in case of traversing a 342 NAT, performed ICE connectivity checks [I-D.li-ppsp-nat-traversal] 343 with candidate peers using PPSP's own authentication method, as 344 described in [I-D.gu-ppsp-tracker-protocol]: 346 1. The leech peer using PPSP Peer Protocol messages, establishes a 347 connection to at least one of the peers in the Peerlist, based on 348 the known PeerID and Peer IP address. 350 2. The peer sends request to candidate peers and the request could 351 include one or more of the information described in below: 353 * Request for the data availability of the candidate peer; 355 * Notify its data availability to the candidate peer; 357 * Request for the peer status of the candidate peer; 359 * Notify its peer status to the candidate peer; 361 * Request for additional peerlist; 363 * Transport negotiation, wherein the requesting peer can have 364 two choices: 366 + Only support Mandatory Tranport Protocol; 368 + Providing a list of supported Transport protocol. 370 3. Finally, the peers exchange the actual chunks of data, using the 371 mechanism/protocol negotiated in the previous step. 373 In terms of Data Transport protocol negotiation, the leech peer can 374 either inform the candidate that it supports a Mandatory Tranport 375 Protocol or provides a list of supported Transport protocols. That 376 there are several options here to negotiate the connection model. 377 The PPSP Peer Protocol may include new mechanisms to negotiate the 378 protocol used to exchange data, or the offer-answer mechanism in SIP 379 [RFC3261] (the IETF protocol for session establishment) along with 380 SDP [RFC4566]. 382 Note also that these mechanisms are not new protocols defined in 383 PPSP, but existing protocols, and would eventually differ between an 384 offline and a Live streaming scenario. Mechanisms such as flow 385 control are handled in the negotiated Data Transport mechanism, not 386 in the Peer Protocol itself. 388 3.2. Example Call Flow 390 This is a very high-level example of a session in which a leech peer 391 joins a swarm, and retrieves some data (either via blocks or by 392 streaming). The protocol used is indicated for each transaction. 393 Note that not all of the communication shown in this figure are in 394 scope of Peer Protocol, only those request/response followed by Peer 395 Protocol are in scope. 397 +--------+ +--------+ +--------+ +---------+ +--------+ 398 | Player | | Peer 1 | | Portal | | Tracker | | Peer 2 | 399 +--------+ +--------+ +--------+ +---------+ +--------+ 400 | | | | | 401 | | | | | 402 | |------------FIND(optional)--------------->| 403 |<-----------OK--|<----------------Peerlist(optional)-------| 404 | | | | | 405 | |--------GET_CHUNKMAP (Peer protocol)----->| 406 | |<--------------------ChunkMap-------------| 407 | | | | | 408 | |--------GET_STATUS (Peer protocol)------->| 409 | |<----------------PEER2 STATUS-------------| 410 | | | | | 411 | |--TRANSPORT_NEGOTIATION (Peer protocol)-->| 412 | |<-------------CONNECTION SETUP------------| 413 | | | | | 414 |--GET (Chunk)-->|--------GET_CHUNK (Peer protocol)-------->| 415 |<---OK+Chunk----|<-----------------Chunk-------------------| 416 : : : : : 417 | |--------GET_STATUS (Peer protocol)------->| 418 | |<----------------PEER2 STATUS-------------| 419 | | | | | 420 |--GET (Chunk)-->|--------GET_CHUNK (Peer protocol)-------->| 421 |<-----OK+Chunk--|<------------------Chunk------------------| 422 : : : : : 423 | | | | 425 Figure 2: Example Call Flow 427 3.3. Chunk Scheduling 429 The goal of chunk trading is receiving the stream smoothly (and with 430 small delay) and to cooperate in the distribution procedure. Peers 431 need to exchange information about their current status to enable 432 scheduling decisions. The information exchanged refers to the state 433 of the peer with respect to the flow, i.e., a map of which chunks are 434 needed by a peer to smoothly playback the stream. 436 This task means: 438 1. sending chunk maps to other nodes with the proper timing, 440 2. receiving chunk maps from other nodes and merging the information 441 in the local buffer map. 443 3. besides chunk map exchange, the signaling includes Status/ 444 Request/Select primitives used to trade chunks. 446 The core of the scheduler, not described in this specification, is 447 the algorithm used to choose the chunks to be exchanged and the peers 448 to communicate with. 450 4. Protocol Architecture 452 The PPSP Peer Protocol is a request-response protocol. Requests are 453 sent, and responses returned to these requests. A single request 454 generates a single response (neglecting fragmentation of messages). 456 As shown in example call flow depicted in Figure 2, the Peer protocol 457 only provides signaling messages for obtaining additional peerlist 458 (optionally), query for content availability and negotiation for 459 transfer protocol. Peer protocol may also provide communication for 460 peers to exchange information that can improve system performance. 462 The encoding for the signaling messages is not yet decided. Two 463 encodings are proposed, a Text-based (HTTP/XML) and a Binary-based, 464 described in Appendixes A and B. The authors will raise more 465 discussion on the encoding, and will move the one that gets rough 466 consensus of the PPSP WG to the draft text. In the Appendixes, some 467 considerations are provided on each encoding based on the Mail List 468 discussions. 470 The specific PPSP signaling messages are listed as following: 472 GET_PEERLIST: 474 The GET_PEERLIST message is sent from a leech peer to one or more 475 remote peers in order for a peer to refresh/update the list of 476 active peers in the swarm. 478 When receiving the GET_PEERLIST message, and if the message is 479 well formed and accepted, the peer will search for the requested 480 data and will respond to the leech peer with the peer list with 481 PeerIDs (and respective IP Addresses) of sender peers that can 482 provide the specific content. 484 GET_CHUNKMAP: 486 The GET_CHUNKMAP message is sent from a leech peer to one or more 487 remote peers in order to receive the map of chunks of a content 488 (of a swarm identified by SwarmID) the other peer presently 489 stores. The chunk map returned by the other peer lists ranges of 490 chunks. 492 When receiving the GET_CHUNKMAP message, and if the message is 493 well formed and accepted, the peer will search for the requested 494 data and will respond to the leech peer with the map of chunks it 495 currently stores of the specific content. 497 GET_CHUNK: 499 The GET_CHUNK message is sent from a leech peer to sender peer in 500 order to request the delivery of media content chunks. 502 When receiving the GET_CHUNK message, and if the message is well 503 formed and accepted, the peer will search for the requested data 504 and will respond to the leech peer with the specific chunks the 505 leech peer requested. 507 GET_STATUS: 509 The GET_ STATUS message is sent from a leech peer to one or more 510 remote peers in order to request the corresponding properties of 511 the sender peers. The corresponding properties are enumerated in 512 [draft-gu-ppsp-tracker-protocol], e.g., Caching Size, Bandwidth 513 etc. 515 When receiving the GET_STATUS message, and if the message is well 516 formed and accepted, the peer will search for the requested data 517 and will respond to the leech peer with the specific parameters to 518 the properties the leech peer requested. 520 TRANSPORT_NEGOTIATION: 522 The TRANSPORT_NEGOTIATION message is sent from a leech peer to a 523 sender peer in order to negotiate the underlying transport 524 protocol. Leech peer provide a set of transport protocols it 525 supported to sender peer, and leave send peer to choose its 526 preference. Reusing existing transport protocol to transfer data 527 is recommended. 529 When receiving the TRANSPORT_NEGOTIATION message, and if the 530 message is well formed and accepted, the sender peer will decide 531 the transport protocol and will respond to the leech peer with the 532 specific transport protocol the sender peer preferred. 534 5. Security Consideration 536 P2P streaming systems are subject to attacks by malicious/unfriendly 537 peers/trackers that may eavesdrop on signaling, forge/deny 538 information/knowledge about streaming content and/or its 539 availability, impersonating to be another valid participant, or 540 launch DoS attacks to a chosen victim. 542 No security system can guarantees complete security in an open P2P 543 streaming system where participants may be malicious or 544 uncooperative. The goal of security considerations described here is 545 to provide sufficient protection for maintaining some security 546 properties during the peer-peer communication even in the face of a 547 large number of malicious peers. 549 As in typical Peer to Peer network, the most significant security 550 issue is that the peers are untrusted. A peer may announce that it 551 has a specific content, but the content might be just noise or it 552 could be poisoned. A peer could also download a large number of 553 chunks but upload very few of them. This problem can be alleviated 554 by incentive mechanism, the goal of which is to reward honest peers 555 and degrade dishonest peers. 557 5.1. Authentication 559 To protect the PPSP signaling from attackers pretending to be valid 560 peers (or peers other than themselves) all messages received in the 561 Tracker are required to be received from authorized peers. 563 For that purpose a peer must enroll in the system via a centralized 564 enrollment server. The enrollment server is expected to provide a 565 proper PeerID for the peer and information about the authentication 566 mechanisms. The specification of the enrollment method and the 567 provision of identifiers and authentication tokens is out of scope of 568 this draft. 570 The authetication mechanism MUST allow the means for negotiating data 571 security layer mechanisms to provide data integrity, data 572 confidentiality, and other services, subject to local policies and 573 security requirements. 575 5.2. Content Integrity Protection Against Polluting Peers/Trackers 577 Malicious peers may declaim ownership of popular content to the 578 Tracker but serve polluted (i.e., decoy content or even virus/trojan 579 infected contents) to other peers. This kind of pollution can be 580 detected by incorporating a checksum distribution scheme for 581 published sharing content. As content chunks of the same content are 582 transferred independently and concurrently, correspondent chunk-level 583 checksums MUST be distributed from an authentic origin. 585 5.3. Residual Attacks and Mitigation 587 To mitigate the impact of sybil attackers, impersonating a large 588 number of valid participants by repeatedly acquiring different peer 589 identities, the enrollment server SHOULD carefully regulate the rate 590 of peer/tracker admission. 592 There is no guarantee that a peer honestly report its status to the 593 Tracker, or server authentic content to other peers as it claims to 594 the Tracker. It is expected that a global trust mechanism, where the 595 credit of each peer is accumulated from evaluations for previous 596 transactions, may be taken into account by other peers when selecting 597 partner for future transactions, helping to mitigate the impact of 598 such malicious behaviors. A globally trusted Tracker MAY also take 599 part of the trust mechanism by collecting evaluations, computing 600 credit values and providing them to joining peers. 602 5.4. Pro-incentive Parameter Trustfulness 604 Properties for PEER_STATUS messages will consider pro-incentive 605 parameters, which can enable the improvement of the performance of 606 the whole P2P streaming system. Trustworthiness of these pro- 607 incentive parameters is critical to the effectiveness of the 608 incentive mechanisms. For example, ChunkMap is essential, and needs 609 to be accurate. The P2P system should be designed in a way such that 610 a peer will have the incentive to report truthfully its ChunkMap 611 (otherwise it may penalize itself). 613 Furthermore, both the amount of upload and download should be 614 reported to the Tracker to allow checking if there is any 615 inconsistency between the upload and download report, and establish 616 an appropriate credit/trust system. 618 6. References 620 6.1. Normative References 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, March 1997. 625 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 626 A., Peterson, J., Sparks, R., Handley, M., and E. 627 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 628 June 2002. 630 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 631 Description Protocol", RFC 4566, July 2006. 633 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 634 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 635 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 637 [draft-ietf-p2psip-base] 638 Jennings, C., Lowekamp, B., Ed., Rescorla, E., and H. 639 Schulzrinne, "draft-ietf-p2psip-base-07", February 2010, 640 . 642 6.2. Informative References 644 [I-D.ietf-ppsp-problem-statement] 645 Zhang, Y., Zong, N., Camarillo, V., Seng, J., and R. Yang, 646 "Problem Statement of P2P Streaming Protocol (PPSP)", 647 Januray 2011, . 649 [I-D.ietf-ppsp-reqs] 650 Zong, N., Zhang, Y., Pascual, V., and C. Williams, "P2P 651 Streaming Protocol (PPSP) Requirements", February 2011, 652 . 654 [I-D.ietf-ppsp-survey] 655 Gu, Y., Zong, N., Zhang, H., Zhang, Y., Camarillo, G., and 656 Y. Liu, "Survey of P2P Streaming Applications", 657 March 2011, . 659 [I-D.gu-ppsp-tracker-protocol] 660 Cruz, R., Nunes, M., Gu, Y., Xia, J., Bryan, D., Taveira, 661 J., and D. Deng, "PPSP Tracker Protocol", March 2011, 662 . 664 [I-D.cruz-ppsp-http-peer-protocol] 665 Gu, Y., Xia, J., Cruz, R., Nunes, M., Bryan, D., and J. 666 Taveira, "PPSP HTTP-Based Peer Protocol", March 2011, 667 . 669 [I-D.li-ppsp-nat-traversal] 670 Li , L., Wang , J., and W. Chen , "PPSP NAT Traversal", 671 March 2011, . 673 [BittorrentSpecification] 674 "Bittorrent Protocol Specification v1.0", February 2010, 675 . 677 Appendix A. Binary Encoding 679 Binary Encoding is an encoding of data in plain text. More 680 precisely, it is an encoding of binary data in a sequence of ASCII- 681 printable characters. Binary Encoding is necessary for transmission 682 of data when the channel or the protocol only allows ASCII-printable 683 characters. 685 The PPSP Peer protocol can be carried on top of IP, UDP, RTP or TCP. 686 But using which layer to carry peer protocol is out of scope in 687 current stage. 689 The peer message header has the following format: 691 0 1 2 3 692 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | PPSP Peer Protocol Token | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Version | Message | Reserved | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Transaction ID 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Message Length | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 Figure 3: PPSP Peer message header 707 The fields have the following meaning: 709 PPSP Peer Protocol Token: 32 bits 711 A fixed token indicating to the receiver this message is a PPSP 712 Peer Protocol message. The token field is four bytes long. This 713 value MUST be set to 0x50505350, the string "PPSP". 715 Version: 8 bits The version of the PPSP peer protocol being used in 716 the form of a fixed point integer between 0.1 and 25.4. For the 717 version of the protocol described in this document, this field 718 MUST be set to 0.1. The version field is one byte long. 720 Message Types: 8 bits 722 Message types currently have two kinds of value: Request and 723 Response. 725 Reserved: 16 bits 727 Not to be assigned. Reserved values are held for special uses, 728 such as to extend the namespace when it becomes exhausted. 729 Reserved values are not available for general assignment. 731 Transaction ID: 64 bits 733 Identifies the transaction and also allows receivers to 734 disambiguate transactions which are otherwise identical. 735 Responses use the same Transaction ID as the request they 736 correspond to. Transaction IDs are also used for fragment 737 reassembly. 739 Message Length: 32 bits: 741 The length of the message, including header, in bytes. Note if 742 the message is fragmented, this is the length of this message, not 743 the total length of all assembled fragments. 745 A.1. Methods in Peer messages 747 To improve the compatibility of the peer methods, the method fields 748 in message extension MUST be encoded as TLV elements as described 749 below and sketched in Figure 4: 751 To improve the compatibility of the peer methods, the method fields 752 in message extension MUST be encoded as TLV elements as described 753 below and sketched in Figure 4: 755 o Type: A single-octet identifier that defines the type of the 756 parameter represented in this TLV element. 758 o Length: A two-octet field that indicates the length (in octets) of 759 the TLV element excluding the Type and Length fields, and the 760 8-bit Reserved field between them. Note that this length does not 761 include any padding that is required for alignment. 763 o Value: Variable-size set of octets that contains the specific 764 value for the parameter. 766 In the extensions, the Reserved field SHALL be set to zero and 767 ignored. If a TLV element does not fall on a 32-bit boundary, the 768 last word MUST be padded to the boundary using further bits set to 769 zero. 771 In a peer message, any method extension MUST be placed after the 772 mandatory message header. The extensions MAY be placed in any order. 774 0 1 2 3 775 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Type | Reserved | Length | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 : Value : 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 Figure 4: Structure of a TLV element 784 Method Type: 8 bits 786 Indicates the method type for the message. There are five method 787 types: GET_PEERLIST, GET_CHUNKMAP, GET_CHUNK, GET_ PROPERTY and 788 TRANSPORT_NEGOTIATION. They are counted from 1 to 5. 790 Method Body Length: 24 bits 792 The length of the method body in bytes. 794 A.1.1. GET_PEERLIST 796 Peerlist is composed of several pairs of Peer ID and Peer IP. Peer 797 ID is a 128 bit integer that is unique in the P2P streaming system. 798 That's no matter there is a centralized tracker or several 799 distributed trackers in the streaming system, a peer ID should be 800 unique. 802 0 1 2 3 803 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | 00000001 | Method Body Length | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | PEER ID 1 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | PEER IP 1 | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | PEER ID 2 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 PEER IP 2 | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 Figure 5: GET_PEERLIST Method Body 830 A.1.2. GET_CHUNKMAP 832 Chunkmap of a content (a swarm identified by SwarmID) 834 0 1 2 3 835 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | 00000002 | Method Body Length | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | SWARM ID 1 | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Chunkmap | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 : : 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 Figure 6: GET_CHUNKMAP Method Body 851 A.1.3. GET_CHUNK 853 [TBD] 855 0 1 2 3 856 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | 00000003 | Method Body Length | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | SWARM ID 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 + Chunk ID 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 + 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 + | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 Figure 6: GET_CHUNKMAP Method Body 873 A.1.4. GET_STATUS 875 Several property types are defined in I-D.gu-ppsp-tracker-protocol. 876 But not all of the property types are reasonable to be used in peer 877 protocol. So we just list the following property types. New types 878 can be easily added. 880 +-------------+----------------------------------------------+------+ 881 | PROPERTY | Description | Code | 882 +-------------+----------------------------------------------+------+ 883 | CachingSize | Caching size: available size for caching | 0x01 | 884 | Bandwidth | Bandwidth: available bandwidth | 0x02 | 885 | LinkNumber | Link number: acceptable links for remote | 0x03 | 886 | | peer | | 887 | Certificate | Certificate: certificate of the peer | 0x04 | 888 +-------------+----------------------------------------------+------+ 890 Table 1: Status changed between peers 892 0 1 2 3 893 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | 00000004 | Method Body Length | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | STATUS Code| STATUS Length | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | STATUS Value | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 + | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 Figure 6: GET_STATUS Method Body 908 A.1.5. TRANSPORT_NEGOTIATION 910 To Do: Define mandatory transport protocol and some optional 911 transport protocol. 913 0 1 2 3 914 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | 00000005 | Method Body Length | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Method Body | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 Figure 7: TRANSPORT_NEGOTIATION Method Body 923 Appendix B. HTTP/XML Encoding 925 The PPSP Peer Protocol HTTP/XML encoding messages follow the request 926 and response standard formats for HTTP Request and Response messages 927 [RFC2616]. 929 B.1. HTTP/XML Encoding 931 A Request message is a standard HTTP Request generated by the HTTP 932 Client Peer with the following syntax: 934 / HTTP/1.1 935 Host: 937 The HTTP Method and URI path (the Resource) indicates the operation 938 requested. The current proposal uses only HTTP POST as a mechanism 939 for the request messages. 941 The Host header follows the standard rules for the HTTP 1.1 Host 942 Header. 944 The Response message is also a standard HTTP Response generated by 945 the HTTP Serving Peer with the following syntax: 947 HTTP/1.1 948 Content-Lenght: 949 Content-Type: 950 Content-Encoding: 951 953 The body for both Request and Response messages are encoded in XML 954 for all the PPSP Peer Protocols messages, with the following schema 955 (the XML information being method specific): 957 958 959 *** 960 *** 961 ### 962 ...XML information specific of the Method... 963 965 In the XML body, the *** represents alphanumeric data and ### 966 represents numeric data to be inserted. The corresponds to 967 the method type for the message, the corresponds to the 968 response method type of the message and the element 969 uniquely identifies the transaction. 971 The Response message MAY use Content-Encoding entity-header with 972 "gzip" compression scheme [RFC2616] for faster transmission times and 973 less network bandwidth usage. 975 B.2. Method Fields 977 Table B 1 and Table B 2 define the valid string representations for 978 the requests and responses, respectively. These values MUST be 979 treated as case-insensitive. 981 +-----------------------+--------------------------+ 982 | PPSP Request | XML Request Value String | 983 +-----------------------+--------------------------+ 984 | GET_PEERLIST | GET_PEERLIST | 985 | GET_CHUNKMAP | GET_CHUNKMAP | 986 | GET_CHUNK | GET_CHUNK | 987 | PEER_STATUS | PEER_STATUS | 988 | TRANSPORT_NEGOTIATION | TRANSP_NEGO | 989 +-----------------------+--------------------------+ 991 Table B 1: Valid Strings for Requests 993 +----------------------+---------------------+--------------------+ 994 | Response Method Name | HTTP Response | XML Response Value | 995 | | Mechanism | | 996 +----------------------+---------------------+--------------------+ 997 | SUCCESSFUL (OK) | 200 OK | OK | 998 | INVALID SYNTAX | 400 Bad Request | INVALID SYNTAX | 999 | VERSION NOT | 400 Bad Request | VERSION NOT | 1000 | SUPPORTED | | SUPPORTED | 1001 | AUTHENTICATION | 401 Unauthorized | AUTHENTICATION | 1002 | REQUIRED | | REQUIRED | 1003 | MESSAGE FORBIDDEN | 403 Forbidden | MESSAGE FORBIDDEN | 1004 | OBJECT NOT FOUND | 404 Not Found | OBJECT NOT FOUND | 1005 | INTERNAL ERROR | 500 Internal Server | INTERNAL ERROR | 1006 | | Error | | 1007 | TEMPORARILY | 503 Service | TEMPORARILY | 1008 | OVERLOADED | Unavailable | OVERLOADED | 1009 +----------------------+---------------------+--------------------+ 1011 Table B 2: Valid Strings for Responses 1013 B.3. Message Processing 1015 When a PPSP Peer Protocol message is received in a peer, some basic 1016 processing is performed, regardless of the message type. Upon 1017 reception, a message is examined to ensure that it is properly 1018 formed. The receiver MUST check that the HTTP message itself is 1019 properly formed, and if not appropriate standard HTTP errors MUST be 1020 generated. The receiver must also verify that the XML body is 1021 properly formed. If the message is found to be incorrectly formed or 1022 the length does not match the length encoded in the header, the 1023 receiver MUST reply with an HTTP 400 response with a PPSP XML body 1024 with the Response method set to INVALID SYNTAX. 1026 B.4. GET_PEERLIST Message 1028 The GET_PEERLIST message is sent from a client peer to a selected 1029 serving peer in order for a peer to refresh/update the list of active 1030 peers in the swarm. 1032 The Request message uses a HTTP POST method with the following body: 1034 1035 1036 GET_PEERLIST 1037 *** 1038 *** 1039 ### 1040 1042 The sender MUST properly form the XML body, MUST set the Method 1043 string to GET_PEERLIST, MUST set the PeerID to the PeerID of the 1044 peer, MUST set the SwarmID to the joined swarm identifier and 1045 randomly generate and set the TransactionID value. 1047 When receiving the GET_PEERLIST message, and if the message is well 1048 formed and accepted, the peer will search for the requested data and 1049 will respond to the requesting peer with an HTTP 200 OK message 1050 response with a PPSP XML payload SUCCESSFUL, as well as the peer list 1051 with PeerIDs (and respective IP Addresses) of peers that can provide 1052 the specific content. 1054 The response MUST have the same TransactionID value as the request. 1056 An example of the Response message structure is the following: 1058 1059 1060 OK 1061 *** 1062 ### 1063 1064 1065 *** 1066 *** 1067 1068 1070 1072 1073 **** 1074 *** 1075 ### 1076 1077 1078 *** 1079 *** 1080 1081 1083 1085 1086 **** 1087 *** 1088 ### 1089 1090 1091 1093 The element MAY contain multiple child 1094 elements. 1096 The element MAY contain multiple child 1097 elements with attributes "ip" and "port" corresponding to each of the 1098 network interfaces of the peer. The "ip" attribute can be expressed 1099 in dotted decimal format for IPv4 or 16-bit hexadecimal values (hh) 1100 separated by colons (:) for IPv6. 1102 The elements and have a string 1103 format, and together with the element of numerical 1104 integer format, form a set of information related to peer location. 1106 B.5. GET_CHUNKMAP Message 1108 The GET_CHUNKMAP message is sent from a client peer to a selected 1109 serving peer in order to receive the map of chunks of a content (of a 1110 swarm identified by SwarmID) the other peer presently stores. The 1111 chunk map returned by the other peer lists ranges of chunks. The 1112 Request message uses a HTTP POST method with the following body: 1114 1115 1116 GET_CHUNKMAP 1117 *** 1118 *** 1119 ### 1120 1122 The sender MUST properly form the XML body, MUST set the Method 1123 string to GET_CHUNKMAP, MUST set the PeerID to the PeerID of the 1124 peer, MUST set the SwarmID to the joined swarm identifier and 1125 randomly generate and set the TransactionID value. 1127 When receiving the GET_CHUNKMAP message, and if the message is well 1128 formed and accepted, the peer will search for the requested data and 1129 will respond to the requesting peer with an HTTP 200 OK message 1130 response with a PPSP XML payload SUCCESSFUL, as well as the map of 1131 chunks it currently stores of the specific content. 1133 The response MUST have the same TransactionID value as the request. 1135 The Response message is an HTTP 200 OK message with the following 1136 body, exemplified for a video component of a media clip: 1138 1139 1140 OK 1141 ### 1142 1143 *** 1144 1145 *** 1146 1147 1149 ...(base64 string)... 1150 1151 1152 1153 1155 1157 The element MAY contain multiple child elements. 1159 The element has an attribute "type" that indicates 1160 the type of media of the corresponding chunks. 1162 A element MAY contain multiple child 1163 elements with attributes "from" and "to" corresponding to ranges of 1164 contiguous chunks. The "from", "to", and "bitmapSize" attributes are 1165 expressed as integer number string format. The 1166 content corresponds to the chunk map, and is represented as base64 1167 encoded string. 1169 B.6. GET_CHUNK Message 1171 The GET_CHUNK message is sent from a client peer to a serving peer in 1172 order to request the delivery of media content chunks. The Request 1173 message uses a HTTP POST method with the following body: 1175 1176 1177 GET_CHUNK 1178 *** 1179 *** 1180 ### 1181 1183 The sender MUST properly for the HTTP request for a POST method 1184 including the URI path (the Resource) of the chunk. The sender MUST 1185 also properly form the XML body, MUST set the Method string to 1186 GET_CHUNK, MUST set the PeerID to the PeerID of the peer, MUST set 1187 the SwarmID to the joined swarm identifier and randomly generate and 1188 set the TransactionID value. 1190 +--------------+ +-------------+ 1191 | Peer (Leech) | | Peer (Seed) | 1192 +--------------+ +-------------+ 1193 | POST /path/name/123456789-L0-00000.h264 HTTP/1.1 | 1194 | Host: example.net | 1195 |------------------------------------------------------>| 1196 | | 1197 | | 1198 | GET_CHUNK | 1199 | *** | 1200 | *** | 1201 | ### | 1202 | | 1203 | | 1204 | | 1205 | HTTP/1.1 200 OK | 1206 | Content-Type: text/xml | 1207 | Transfer-Encoding: chunked | 1208 |<------------------------------------------------------| 1209 | | 1210 | 143 | 1211 | | 1212 | | 1213 | OK | 1214 | ### | 1215 | | 1216 | | 1217 | ### | 1218 | (### bytes of the video chunk) | 1219 | 0 | 1221 Figure B 1: Example of GET_CHUNK message sequence (simplified) 1223 When receiving the GET_CHUNK message, and if the message is well 1224 formed and accepted, the peer will search for the requested data and 1225 will respond to the requesting peer with an HTTP 200 OK message 1226 response with a PPSP XML payload SUCCESSFUL. 1228 The Response message is an HTTP 200 OK message. If The Data 1229 Transport Protocol negotiated is also HTTP/XML, the body of the 1230 response to GET_CHUNK can be immediately followed by the chunk data 1231 transfer, as shown in Figure B 1. 1233 The response MUST have the same TransactionID as the request. 1235 B.7. PEER_STATUS Message 1237 The PEER_STATUS message is sent from a serving peer to a client peer 1238 to indicate its participation status. The information conveyed may 1239 include information related to chunk trading like "choke" (to inform 1240 the other peer of the intention to stop sending data to it) and 1241 "unchoke" (to inform the other peer of the intention to start/re- 1242 start sending data to it). 1244 The Request message uses a HTTP POST method with the following body: 1246 1247 1248 PEER_STATUS 1249 *** 1250 *** 1251 ### 1252 (choke/unchoke) 1253 1255 The sender MUST properly form the XML body, MUST set the Method 1256 string to PEER_STATUS, MUST set the PeerID to the PeerID of the peer, 1257 MUST set the SwarmID to the joined swarm identifier and randomly 1258 generate and set the TransactionID value. 1260 When receiving the PEER_STATUS message, and if the message is well 1261 formed and accepted, the peer will respond to the requesting peer 1262 with an HTTP 200 OK message response with a PPSP XML payload 1263 SUCCESSFUL. 1265 If the status signal received is "choke" the peer will stop 1266 requesting chunks from the other peer until receiving an "unchoke" 1267 status signal. 1269 The only element currently defined in the request message is 1270 , assuming values of "choke" and "unchoke", but, in future, 1271 other values may be added. 1273 The Response message is an HTTP 200 OK message with the following 1274 body. 1276 1277 1278 OK 1279 ### 1280 1282 The response MUST have the same TransactionID value as the request. 1284 The only element currently defined in the response message is the 1285 , but, in future, other elements may be added, for 1286 example, containing statistical data or other primitives for chunk 1287 trading negotiation. 1289 B.8. TRANSPORT_NEGOTIATION Message 1291 To Do: Define message format, mandatory transport protocol and some 1292 optional transport protocols. 1294 Authors' Addresses 1296 Yingjie Gu 1297 Huawei 1298 No.101 Software Avenue 1299 Nanjing, Jiangsu Province 210012 1300 P.R.China 1302 Phone: +86-25-56622638 1303 Email: guyingjie@huawei.com 1305 Jinwei Xia 1306 Huawei 1307 Software No.101 1308 Nanjing, Yuhuatai District 210012 1309 China 1311 Phone: +86-025-86622310 1312 Email: xiajinwei@huawei.com 1314 Rui Santos Cruz 1315 IST/INESC-ID/INOV 1317 Phone: +351.939060939 1318 Email: rui.cruz@ieee.org 1319 Mario Serafim Nunes 1320 IST/INESC-ID/INOV 1321 Rua Alves Redol, n.9 1322 1000-029 LISBOA 1323 Portugal 1325 Phone: +351.213100256 1326 Email: mario.nunes@inov.pt 1328 David A. Bryan 1329 Polycom 1330 San Jose, CA, USA, 1331 USA 1333 Phone: 1334 Email: dbryan@ethernot.org 1336 Joao P. Taveira 1337 ID/INOV 1339 Email: joao.silva@inov.pt