idnits 2.17.1 draft-huang-ppsp-extended-tracker-protocol-06.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 == Line 20 has weird spacing: '...cements and u...' -- The document date (July 4, 2014) is 3581 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: 'RFC6972' is mentioned on line 120, but not defined == Unused Reference: 'RFC4648' is defined on line 584, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 599, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-ppsp-base-tracker-protocol-04 == Outdated reference: A later version (-12) exists of draft-ietf-ppsp-peer-protocol-10 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPSP Rachel Huang 3 INTERNET-DRAFT Huawei 4 Intended Status: Standards Track Rui Cruz 5 Expires: January 5, 2015 Mario S. Nunes 6 INESC-ID/INOV 7 Joao P. Taveira 8 IST/INOV 9 Lingli Deng 10 China Mobile 11 July 4, 2014 13 PPSP Tracker Protocol-Extended Protocol 14 draft-huang-ppsp-extended-tracker-protocol-06 16 Abstract 18 This document specifies an extension to the PPSP Tracker Protocol - 19 Base Protocol, which complements the core messages of the protocol 20 with Request-Response enhancements and usages, and with a new 21 DISCONNECT Protocol-level message. These enhancements and usages are 22 related with the exchange of meta information between trackers and 23 peers, such as initial offer/request of participation in multimedia 24 content streaming, content information, peer lists, reports of 25 activity and status, and graceful disconnection from the network. 26 The extension is retro-compatible with the PPSP-TP Base Protocol. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 35 other groups may also distribute working documents as 36 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/1id-abstracts.html 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 Copyright and License Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Extended Tracker Protocol Overview . . . . . . . . . . . . . . 5 70 4.1. Request-Response Extension . . . . . . . . . . . . . . . . 5 71 4.2. Protocol-level Extension . . . . . . . . . . . . . . . . . 6 72 4.3. Usage of Extended Request Messages . . . . . . . . . . . . 6 73 4.4. Extended Tracker Transaction State Machine . . . . . . . . 7 74 4.4.1. Normal Operation . . . . . . . . . . . . . . . . . . . 8 75 4.4.2. Error Conditions . . . . . . . . . . . . . . . . . . . 9 76 5 Extended Tracker Protocol Specification . . . . . . . . . . . . 9 77 5.1. Request/Response Syntax and Format . . . . . . . . . . . . 9 78 5.3. Extended Request/Response Element in Request Messages . . . 11 79 5.4. Compatibility with the Base Tracker Protocol . . . . . . . 12 80 5.5. Negotiation of Chunk Addressing Methods . . . . . . . . . . 12 81 5.6. Request/Response Processing . . . . . . . . . . . . . . . . 13 82 5.6.1. Enhanced FIND Request . . . . . . . . . . . . . . . . . 13 83 5.6.2. Enhanced STAT_REPORT Request . . . . . . . . . . . . . 13 84 5.6.3. DISCONNECT Request . . . . . . . . . . . . . . . . . . 13 85 6. Error and Recovery Conditions . . . . . . . . . . . . . . . . . 14 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 14 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 88 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 14 89 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 10.1 Normative References . . . . . . . . . . . . . . . . . . . 14 91 10.2 Informative References . . . . . . . . . . . . . . . . . . 15 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 94 1. Introduction 96 The PPSP Tracker Protocol is one of the Peer-to-Peer Streaming 97 Protocol which specifies standard format/encoding of information and 98 messages between PPSP peers and PPSP trackers. Based on the 99 requirements defined in RFC 6972 [RFC6972], the base tracker protocol 100 specified in [I-D.ietf-ppsp-base-tracker-protocol] has provided the 101 basic core messages to be exchanged between trackers and peers in 102 order to carry out some fundamental operations. The core messages 103 are mandatory, covering most basic and universal use cases, and MUST 104 be implemented in all PPSP-based streaming systems. 106 This document specifies extensions to the base core messages of 107 [I-D.ietf-ppsp-base-tracker-protocol] with enhancements in 108 request/responses and new optional request message, providing new 109 usages in some scenarios. The extension of the base protocol is 110 retro-compatible with the PPSP-TP Base Protocol, and Messages using 111 this specification MUST be safely rejected by trackers not supporting 112 the extensions to avoid affecting interoperability. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 This draft uses terms defined in [RFC6972] and [I-D.ietf-ppsp-base- 121 tracker-protocol]. 123 3. Motivation 125 There are a number of possible usages and issues which may be useful 126 for discussion and which the base tracker protocol may not be able to 127 deal with. 129 1. In the base tracker protocol, the disconnection between peer and 130 tracker is achieved by a timeout (of periodic STAT_REPORT 131 messages) which means that trackers lack the ability to timely 132 free up resources. In some cases when the number of connected 133 peers is reaching the maximum capacity of a tracker, resources of 134 the tracker cannot be released immediately even if some peers 135 leave the swarm, which will lead to connection failures. Some P2P 136 applications may require to overcome this shortage of the base 137 tracker protocol. This case requires a message to provide the 138 ability to notify the tracker that a peer has left this tracker. 139 2. A peer may have the requirement to start streaming the content 140 from some specific point of the content timeline. For example, 141 when the end-user watched only part of a content and decided to 142 stop and leave, or paused for a long time. When the end-user 143 decides to resume the session he/she expects to continue watching 144 the content from the point where he/she interrupted. The peer may 145 then request the tracker to select a subset of peers capable to 146 provide that specific content scope. In this case, it requires 147 that the quest for content from neighbor peers should contain the 148 content scope information and peers should constantly report their 149 content scope information to the tracker. 151 The above use cases require the base tracker protocol to be extended. 153 4. Extended Tracker Protocol Overview 155 The extended Tracker Protocol consists of three Request-Response 156 Extensions (to the CONNECT, FIND and STAT_REPORT Request messages of 157 the Base Protocol) and one Protocol-level Extension (a new DISCONNECT 158 Request message). 160 4.1. Request-Response Extension 162 In this section, the FIND and STAT_REPORT messages specified in the 163 base tracker protocol are extended to meet the needs of use case 2 164 listed in section 3. 166 FIND: The enhanced FIND Request message allows a peer to request the 167 tracker for a subset of peers in a swarm but including 168 specific content scopes, either media content representations 169 or specific chunks/segments of a media representation in a 170 swarm, and may also include an updated network address of the 171 peer. On receiving a FIND message, the tracker selects a 172 subset of peers satisfying the requesting scope. To create 173 the peer list, the tracker may also take peer status, 174 capabilities and peers priority into consideration. Peer 175 priority may be determined by network topology preference, 176 operator policy preference, etc. The format and detailed 177 processing of enhanced CONNECT Request message is presented in 178 Section 5.2. 180 STAT_REPORT: The enhanced STAT_REPORT Request message allows the 181 exchanges of content data information, like chunkmaps, between 182 an active peer and a tracker. The information can be used by 183 a tracker as a qualification to select appropriate subsets of 184 peers in the swarm satisfying specific scopes (in terms of 185 content). The format and detailed processing of enhanced 186 CONNECT Request message is presented in Section 5.3. 188 To present the content data information, The chunk addressing schemes 189 (section 4 of [I-D.ietf-ppsp-peer-protocol]) are used to support 190 different ways of identifying chunks and expressing chunk 191 availability of a peer in a compact fashion. The chunk addressing 192 methods for certain content should be recorded in the metadata of the 193 swarm for the content, and they can be obtained by peers or trackers 194 during the enrollment and bootstrap stage. 196 4.2. Protocol-level Extension 198 A new Request message is introduced in this section to extend those 199 specified in the base tracker protocol [I-D.ietf-ppsp-base-tracker- 200 protocol], to meet the needs of issue 1 listed in section 3. 202 DISCONNECT: The DISCONNECT Request message is used when the peer 203 intends to no longer participate in all swarms. When 204 receiving the DISCONNECT Request message from a peer, the 205 tracker deletes the corresponding activity records related to 206 the peer (including its status and all content status for the 207 corresponding swarms). In such a case, the DISCONNECT Request 208 message will have the same effect of timer expiring 209 (STAT_REPORT), but providing a graceful disconnect of that 210 peer from the system. 212 4.3. Usage of Extended Request Messages 214 An example of usage of the extended request messages is illustrated 215 in Figure 1. In that figure a peer starts by connecting to the 216 system and joining a specific swarm (swarm_a) in SEED mode (step_1). 218 While active, the peer periodically updates the tracker using 219 STAT_REPORT messages. Later, the peer CONNECTs to another swarm 220 (swarm_b) but in LEECH mode, i.e., the end-user intends to watch that 221 new content while still sharing the first one (step_2). During the 222 streaming session the peer requests an updated list of peers in that 223 new swarm to the tracker (step_3). 225 When the end-user wants to leave the second content, not having even 226 finished watching, the peer sends a CONNECT message with a "leave" 227 action (step_4) for the corresponding swarm (swarm_b) but remains 228 sharing the first content (swarm_a). Later the peer DISCONNECTs from 229 the system (step_5). 231 When in a next time, the end user wants to continue watching the 232 content he/she previously left unfinished, the peer CONNECTs to the 233 corresponding swarm in LEECH mode but sending the specific content 234 information scope. 236 +--------+ +---------+ 237 | Peer | | Tracker | 238 +--------+ +---------+ 239 | | 240 step_1 |--CONNECT(swarm_a;SEED)---------->| 241 |<--------------------------OK-----| 242 : : 243 |--STAT_REPORT(activity)---------->| 244 |<--------------------------Ok-----| 245 : : 246 step_2 |--CONNECT(swarm_b;LEECH)--------->| 247 |<-----------------OK+PeerList-----| 248 : : 249 |--STAT_REPORT(ChunkMap_b)-------->| 250 |<--------------------------Ok-----| 251 : : 252 step_3 |--FIND(swarm_b;ChunkMap)--------->| 253 |<-----------------OK+PeerList-----| 254 : : 255 step_4 |--CONNECT(leave swarm_b)--------->| 256 |<--------------------------Ok-----| 257 : : 258 |--STAT_REPORT(activity)---------->| 259 |<--------------------------Ok-----| 260 : : 261 step_5 |--DISCONNECT(nil)---------------->| 262 |<---------------------Ok(BYE)-----| 263 : : 265 Figure 1: Example of a session for a extended PPSP-TP. 267 4.4. Extended Tracker Transaction State Machine 269 The tracker state machine introduced in the base tracker protocol 270 [I-D.ietf-ppsp-base-tracker-protocol] is now updated in this 271 specification to reflect the extensions introduced. An updated "per- 272 Peer-ID" transaction state machine (Figure 2) is described, 273 corresponding to the enhanced functionalities and control steps of 274 the extended tracker protocol. This extended "per-Peer-ID" 275 transaction state machine is compatible with the one specified in the 276 base tracker protocol. 278 -------------------------------------------- 279 / \ 280 | +------------+ +=========+ +======+ | 281 \-| TERMINATED |<---| STARTED |<---| INIT |<-/ 282 +------------+ +=========+ +======+ 283 (Transient) | (1) \- (start tracker) 284 V 285 +-----------+ +-------+ rcv CONNECT 286 (Transient) | TERMINATE | | START | --------------- (1) 287 +-----------+ +-------+ strt init timer 288 rcv DICONNECT ^ | 289 rcv FIND | | 290 rcv STAT_REPORT | | 291 on registration error | v 292 on action error | +------------+ 293 ---------------- (A) +<-----| PEER | (Transient) 294 stop init timer | | REGISTERED | 295 snd error | +------------+ 296 | | 297 | | process swarm actions 298 on CONNECT Error (B) | | --------------------- (2) 299 on timeout (C) | | snd OK (PeerList) 300 on DISCONNECT (5) | / stop init timer 301 ---------------- | / strt track timer 302 stop track timer | / 303 clean peer info | | 304 del registration | | rcv FIND 305 snd error (B) \ | ---- --------------- (3) 306 ---- \ | / \ snd OK (PeerList) 307 / \ \ | | | rst track timer 308 rcv CONNECT | (4) | | | | | 309 ----------- | v | v v | rcv STAT_REPORT 310 snd OK \ +==============+ / --------------- (3) 311 rst track timer ----| TRACKING |---- snd OK response 312 +==============+ rst track timer 314 Figure 2: Extended "Per-Peer-ID" Transaction State Machine 316 The state diagram in Figure 2 illustrates the complete state changes 317 together with the causing events and resulting actions when 318 implementing the extensions to the base tracker protocol. Note that 319 Specific error conditions are not shown in the state diagram. 321 4.4.1. Normal Operation 323 Normal operation steps are the same with section 2.4.1 of the base 324 tracker protocol [I-D.ietf-ppsp-base-tracker-protocol] except step 5: 326 5) While TRACKING, a DISCONNECT message received from the peer, or a 327 CONNECT message with the action to leave the last swarm, the 328 tracker stops the "track timer", cleans the information associated 329 with the participation of the Peer-ID in the the swarm(s) joined, 330 responds with a successful condition, deletes the registration of 331 the Peer-ID and transitions to TERMINATED state for that Peer-ID. 333 4.4.2. Error Conditions 335 Error condition steps are the same with section 2.4.2 of the base 336 tracker protocol [I-D.ietf-ppsp-base-tracker-protocol] except step 337 A: 339 A) At PEER REGISTERED state, if the Peer ID is considered invalid (in 340 the case of a DISCONNECT requests received from an unregistered 341 Peer ID), the tracker responds with either error codes 401 342 Unauthorized or 403 Forbidden, transitions to TERMINATE state for 343 that Peer ID and that state machine instance is destroyed. 345 5 Extended Tracker Protocol Specification 347 5.1. Request/Response Syntax and Format 349 The architecture specified in the base tracker protocol [I-D.ietf- 350 ppsp-base-tracker-protocol] does not suffers any modification in the 351 extended protocol. The syntax is identical with some elements 352 extended to contain new optional attributes: 354 The request type includes CONNECT, FIND, STAT_REPORT and DISCONNECT, 355 including a "content" element to the FIND method, that MAY be present 356 in requests referencing content, i.e., FIND and STAT_REPORT, if the 357 request includes a content scope. 359 The extended semantics of the request therefore is described as 360 follows. 362 typedef enum ppsp_tp_request_type { 363 PPSP_TP_CONNECT = 0x02, // or "CONNECT" 364 PPSP_TP_FIND = 0x04, // or "FIND" 365 PPSP_TP_DISCONNECT = 0x06 // or "DISCONNECT" 366 PPSP_TP_STAT_REPORT = 0x08 // or "STAT_REPORT" 367 } ppsp_tp_request_type_t; 368 typedef struct { 369 ppsp_tp_version_t version; 370 ppsp_tp_request_type_t type; 371 ppsp_tp_transaction_id_t id; 372 ppsp_tp_peer_id_t peer_id; 373 union { 374 struct { 375 ppsp_tp_peer_num_t peer_num; 376 ppsp_tp_peer_info_t peer_info; 377 ppsp_tp_swarm_action_t swarm_actions[]; 378 } connect; 379 struct { 380 ppsp_tp_peer_num_t peer_num; 381 ppsp_tp_content_info_t content_info[]; 382 } find; 383 struct { 384 ppsp_tp_stat_t stats[]; 385 } stat_report; 386 } request_data; 387 } ppsp_tp_request; 389 The semantics for the content_info element is described as follow: 391 typedef unique_id_t ppsp_tp_segment_start_t; 392 typedef unique_id_t ppsp_tp_segment_end_t; 393 typedef unique_id_t ppsp_tp_chunk_addr_t; 395 typedef struct { 396 ppsp_tp_chunk_addr_t chunk_addressing_method; 397 ppsp_tp_segment_info_t segments[]; 398 } ppsp_tp_content_info_t; 400 typedef struct { 401 ppsp_tp_segment_start_t start_index; 402 ppsp_tp_segment_end_t end_index; // 0 means no end 403 } ppsp_tp_segment_info_t; 405 The semantics of Statistics is extended as follows: 407 typedef struct { 408 ppsp_tp_stat_type_t type; 409 union { 410 struct { 411 ppsp_tp_swarm_id_t swarm_id; 412 ppsp_tp_integer_t uploaded_bytes; 413 ppsp_tp_integer_t downloaded_bytes; 414 ppsp_tp_integer_t available_bandwidth; 415 } stream_stats; 416 struct { 417 ppsp_tp_content_info_t content_info[]; 418 } content_map; 419 } stat_data; 420 } ppsp_tp_stat_t; 422 Currently, the value of chunk_addressing_method is identical to the 423 addressing method listed in section 7.8 of [I-D.ietf-ppsp-peer- 424 protocol], as follow: 426 +--------+---------------------+ 427 | Method | Description | 428 +--------+---------------------+ 429 | 0 | 32-bit bins | 430 | 1 | 64-bit byte ranges | 431 | 2 | 32-bit chunk ranges | 432 | 3 | 64-bit bins | 433 | 4 | 64-bit chunk ranges | 434 | 5-255 | Unassigned | 435 +--------+---------------------+ 437 Table 1: Chunk Addressing Methods 439 Implementations MUST support "32-bit chunk ranges" (default) and "64- 440 bit chunk ranges". When the chunk_addressing_method is 32-bit bins 441 or 64-bit bins, end_index in SegmentInfo MUST be set to 0. Chunk 442 addressing methods could be extended to allow new algorithms in 443 future specifications, e.g., [BFbitmap]. This document does not 444 extends the semantics and format of Responses. 446 5.3. Extended Request/Response Element in Request Messages 448 Table 1 specifies the valid string representations for the requests 449 extended in this specification to complement those define in the base 450 tracker protocol. 452 +------------------------+ 453 | Extended Request Types | 454 +------------------------+ 455 | DISCONNECT 3 | 456 +------------------------+ 458 Table 1: Extended Request Type of PPSP-TP requests. 460 The response elements in the extension are identical to those of the 461 base tracker protocol [I-D.ietf-ppsp-base-tracker-protocol]. 463 5.4. Compatibility with the Base Tracker Protocol 465 Trackers are RECOMMENDED to implement extended tracker protocol to be 466 compatible with peers using base tracker protocol or peers using 467 extended tracker protocol. But it is not mandatory. When peers 468 using extended tracker protocol exchange content information with a 469 tracker only supporting the base tracker protocol, the tracker could 470 directly ignore the content related information, e.g., ContentGroup 471 element. Peers implementing the extended tracker protocol sending 472 DISCONNECT message to legacy trackers will get responses with 400 473 (Bad request, with reason-phrase "Unknown Messages"), which indicates 474 the messages could not be recognized by the tracker. In this case, 475 peers MUST stop interacting with the tracker in extended request 476 messages and use the base tracker protocol instead. 478 5.5. Negotiation of Chunk Addressing Methods 480 Multiple chunk addressing methods could be used in this document to 481 present content information. But only one of them MUST be used for 482 one swarm when a peer communicating with a tracker. Before peers 483 connect to a tracker, they MUST get to know the chunk addressing 484 methods supported by the swarm. It is out of scope of the tracker 485 protocol the mechanism used to obtain that information. For example, 486 it could be some out-of-band methods that obtains that information 487 from the web portal, together with other information about the 488 trackers, e.g., IP addresses. 490 If the chunk addressing method of a swarm can not be supported by a 491 tracker, the tracker is not suggested to serve that swarm. If the 492 chunk addressing method contained in requests is not supported by the 493 swarm controlled by the tracker, the tracker could directly ignore 494 the content related information. 496 5.6. Request/Response Processing 498 5.6.1. Enhanced FIND Request 500 This method allows peers to request to the tracker, whenever needed, 501 a new peer list for the swarm for specific scope of chunks/segments 502 of a media content representation of that swarm. 504 The peer MUST properly set the request type to FIND, set the PeerID 505 with the identifier of the peer, and set the SwarmID with the 506 identifier of the swarm the peer is interested in. Optionally, in 507 order to find peers having the specific chunks/segments, the peer may 508 include the ContentGroup element in the FIND request message to 509 indicate a specific point in the content timeline. 511 This message is mainly used for peers in LEECH mode in order to 512 update the peer list of a swarm. For those requests whose peer_mode 513 are not set to LEECH, the tracker must respond with 400 (Bad request, 514 with reason-phrase "Unknown Messages"). 516 In the case of a FIND with a specific scope of a stream content the 517 request SHOULD include a ContentGroup to specify the segment range of 518 content Representations. 520 The response MAY also include a PeerGroup with PeerInfo data that 521 includes the requesting peer public IP address. 523 5.6.2. Enhanced STAT_REPORT Request 525 This message still uses the specifications of the base tracker 526 protocol [I-D.ietf-ppsp-base-tracker-protocol]. The Stat element has 527 been extended with one property, "ContentGroup", to allow peers 528 reporting map of chunks they have. The tracker would not have the 529 ability to treat the FIND requests for specific content chunks, 530 unless peers report this kind of information. The corresponding 531 Response has not been extended in this specification. 533 5.6.3. DISCONNECT Request 535 This method is used when the peer intends to leave the system and no 536 longer participate. The tracker SHOULD delete the corresponding 537 activity records related with the peer in all the swarms (including 538 its status and all content status). 540 The peer MUST properly form the Request message, set the request type 541 to DISCONNECT, set the PeerID with the identifier of the peer, and 542 randomly generate and set the TransactionID. 544 6. Error and Recovery Conditions 546 This document does not introduces any new error and recovery 547 conditions. The implementation of error treatment MUST refer to the 548 base tracker protocol specification [I-D.ietf-ppsp-base-tracker- 549 protocol]. 551 7. Security Considerations 553 The extended tracker protocol proposed in this document introduces no 554 new security considerations beyond those described in the base 555 tracker protocol specification [I-D.ietf-ppsp-base-tracker-protocol]. 557 8. IANA Considerations 559 There are presently no IANA considerations with this document. 561 9. Acknowledgments 563 The authors would like to thank many people for their help and 564 comments, particularly: Zhang Yunfei, Martin Stiemerling, Johan 565 Pouwelse and Arno Bakker. 567 The authors would also like to thank the people participating in the 568 EU FP7 project SARACEN (contract no. ICT-248474) 569 [refs.saracenwebpage] for contributions and feedback to this 570 document. 572 The views and conclusions contained herein are those of the authors 573 and should not be interpreted as necessarily representing the 574 official policies or endorsements, either expressed or implied, of 575 the SARACEN project or the European Commission. 577 10 References 579 10.1 Normative References 581 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 582 Requirement Levels", BCP 14, RFC 2119, March 1997. 584 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 585 Encodings", RFC 4648, October 2006. 587 [I-D.ietf-ppsp-base-tracker-protocol] Cruz, R., Nunes, M., Gu, Y., 588 Xia, J., J. Taveira, and Lingli, D., "PPSP Tracker 589 Protocol-Base Protocol (PPSP-TP/1.0)", draft-ietf-ppsp- 590 base-tracker-protocol-04 (work in progress), July 2014. 592 [I-D.ietf-ppsp-peer-protocol] Bakker, A., Petrocco, R. and V. 593 Grishchenko, "Peer-to-Peer Streaming Peer Protocol", 594 draft-ietf-ppsp-peer-protocol-10 (work in progress), June 595 2014. 597 10.2 Informative References 599 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 600 October 2008. 602 [refs.saracenwebpage] "SARACEN Project Website", 603 http://www.saracen-p2p.eu/. 605 [BFbitmap] Bloom, B., "Space/time trade-offs in hash coding with 606 allowable errors.", Communications of ACM Vol. 13, No.7, 607 pp. 422-426, 1970. 609 Authors' Addresses 611 Rachel Huang 612 Huawei 613 Phone: +86-25-56623633 614 EMail: rachel.huang@huawei.com 616 Rui Santos Cruz 617 IST/INESC-ID/INOV 618 Phone: +351.939060939 619 Email: rui.cruz@ieee.org 621 Mario Serafim Nunes 622 INESC-ID/INOV 623 Rua Alves Redol, n.9 624 1000-029 LISBOA, Portugal 625 Phone: +351.213100256 626 Email: mario.nunes@inov.pt 628 Joao P. Taveira 629 IST/INOV 630 Email: joao.silva@inov.pt 632 Lingli Deng 633 China Mobile 634 Email: denglingli@chinamobile.com