idnits 2.17.1 draft-huang-ppsp-extended-tracker-protocol-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 20 has weird spacing: '...cements and u...' -- The document date (October 20, 2014) is 3473 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 119, but not defined == Unused Reference: 'RFC4648' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 608, 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: April 23, 2015 Mario S. Nunes 6 INESC-ID/INOV 7 Joao P. Taveira 8 IST/INOV 9 Lingli Deng 10 China Mobile 11 October 20, 2014 13 PPSP Tracker Protocol-Extended Protocol 14 draft-huang-ppsp-extended-tracker-protocol-07 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 . . . . . . . . . . . . . . . . . . . 9 75 4.4.2. Error Conditions . . . . . . . . . . . . . . . . . . . 10 76 5 Extended Tracker Protocol Specification . . . . . . . . . . . . 10 77 5.1. Request/Response Syntax and Format . . . . . . . . . . . . 10 78 5.3. Compatibility with the Base Tracker Protocol . . . . . . . 12 79 5.4. Negotiation of Chunk Addressing Methods . . . . . . . . . . 13 80 5.5. Request/Response Processing . . . . . . . . . . . . . . . . 14 81 5.5.1. Enhanced FIND Request . . . . . . . . . . . . . . . . . 14 82 5.5.2. Enhanced STAT_REPORT Request . . . . . . . . . . . . . 14 83 5.5.3. DISCONNECT Request . . . . . . . . . . . . . . . . . . 14 84 6. Error and Recovery Conditions . . . . . . . . . . . . . . . . . 15 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 15 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15 87 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 15 88 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 10.1 Normative References . . . . . . . . . . . . . . . . . . . 15 90 10.2 Informative References . . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 The PPSP Tracker Protocol is one of the Peer-to-Peer Streaming 96 Protocol which specifies standard format/encoding of information and 97 messages between PPSP peers and PPSP trackers. Based on the 98 requirements defined in RFC 6972 [RFC6972], the base tracker protocol 99 specified in [I-D.ietf-ppsp-base-tracker-protocol] has provided the 100 basic core messages to be exchanged between trackers and peers in 101 order to carry out some fundamental operations. The core messages 102 are mandatory, covering most basic and universal use cases, and MUST 103 be implemented in all PPSP-based streaming systems. 105 This document specifies extensions to the base core messages of 106 [I-D.ietf-ppsp-base-tracker-protocol] with enhancements in 107 request/responses and new optional request message, providing new 108 usages in some scenarios. The extension of the base protocol is 109 retro-compatible with the PPSP-TP Base Protocol, and Messages using 110 this specification MUST be safely rejected by trackers not supporting 111 the extensions to avoid affecting interoperability. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 This draft uses terms defined in [RFC6972] and [I-D.ietf-ppsp-base- 120 tracker-protocol]. 122 3. Motivation 124 There are a number of possible usages and issues which may be useful 125 for discussion and which the base tracker protocol may not be able to 126 deal with. 128 1. In the base tracker protocol, the disconnection between peer and 129 tracker is achieved by a timeout (of periodic STAT_REPORT 130 messages) which means that trackers lack the ability to timely 131 free up resources. In some cases when the number of connected 132 peers is reaching the maximum capacity of a tracker, resources of 133 the tracker cannot be released immediately even if some peers 134 leave the swarm, which will lead to connection failures. Some P2P 135 applications may require to overcome this shortage of the base 136 tracker protocol. This case requires a message to provide the 137 ability to notify the tracker that a peer has left. 138 2. A peer may have the requirement to start streaming the content 139 from one specific point of the content timeline. For example, 140 when the end-user watched only part of a content and decided to 141 stop and leave, or paused for a long time. When the end-user 142 decides to resume the session he/she expects to continue watching 143 the content from the point where he/she interrupted. The peer may 144 then request the tracker to select a subset of peers capable to 145 provide that specific content scope. In this case, it requires 146 that the quest for content from neighbor peers should contain the 147 content scope information and peers should constantly report their 148 content scope information to the tracker. 150 The above use cases require the base tracker protocol to be extended. 152 4. Extended Tracker Protocol Overview 154 The extended Tracker Protocol consists of two Request-Response 155 Extensions (to the FIND and STAT_REPORT Request messages of the Base 156 Protocol) and one Protocol-level Extension (a new DISCONNECT Request 157 message). 159 4.1. Request-Response Extension 161 In this section, the FIND and STAT_REPORT messages specified in the 162 base tracker protocol are extended to meet the needs of use case 2 163 listed in section 3. 165 FIND: The enhanced FIND Request message allows a peer to request the 166 tracker for a subset of peers in a swarm but including 167 specific content scopes, either media content representations 168 or specific chunks/segments of a media representation in a 169 swarm, and may also include an updated network address of the 170 peer. On receiving a FIND message, the tracker selects a 171 subset of peers satisfying the requesting scope. To create 172 the peer list, the tracker may also take peer status, 173 capabilities and peers priority into consideration. Peer 174 priority may be determined by network topology preference, 175 operator policy preference, etc. The format and detailed 176 processing of enhanced CONNECT Request message is presented in 177 Section 5.2. 179 STAT_REPORT: The enhanced STAT_REPORT Request message allows the 180 exchanges of content data information, like chunkmaps, between 181 an active peer and a tracker. The information can be used by 182 a tracker as a qualification to select appropriate subsets of 183 peers in the swarm satisfying specific scopes (in terms of 184 content). The format and detailed processing of enhanced 185 CONNECT Request message is presented in Section 5.3. 187 To present the content data information, The chunk addressing schemes 188 (section 4 of [I-D.ietf-ppsp-peer-protocol]) are used to support 189 different ways of identifying chunks and expressing chunk 190 availability of a peer in a compact fashion. The chunk addressing 191 methods for certain content should be recorded in the metadata of the 192 swarm for the content, and they can be obtained by peers or trackers 193 during the enrollment and bootstrap stage. 195 4.2. Protocol-level Extension 197 A new Request message is introduced in this section to extend those 198 specified in the base tracker protocol [I-D.ietf-ppsp-base-tracker- 199 protocol], to meet the needs of issue 1 listed in section 3. 201 DISCONNECT: The DISCONNECT Request message is used when the peer 202 intends to no longer participate in all swarms. When 203 receiving the DISCONNECT Request message from a peer, the 204 tracker deletes the corresponding activity records related to 205 the peer (including its status and all content status for the 206 corresponding swarms). In such a case, the DISCONNECT Request 207 message will have the same effect of timer expiring 208 (STAT_REPORT), but providing a graceful disconnection of that 209 peer from the system. 211 4.3. Usage of Extended Request Messages 213 An example of usage of the extended request messages is illustrated 214 in Figure 1. In that figure a peer starts by connecting to the 215 system and joining a specific swarm (swarm_a) in SEED mode (step_1). 217 While active, the peer periodically updates the tracker using 218 STAT_REPORT messages. Later, the peer CONNECTs to another swarm 219 (swarm_b) but in LEECH mode, i.e., the end-user intends to watch that 220 new content while still sharing the first one (step_2). During the 221 streaming session the peer requests an updated list of peers in that 222 new swarm to the tracker (step_3). When the end-user wants to leave 223 the second content, not having even finished watching, the peer sends 224 a CONNECT message with a "leave" action (step_4) for the 225 corresponding swarm (swarm_b) but remains sharing the first content 226 (swarm_a). 228 But later, the end user wants to continue watching the content he/she 229 previously left unfinished. So the peer firstly CONNECTs to the 230 corresponding swarm in LEECH mode, then sends FIND message with the 231 specific content information scope (step_5). Tracker will find the 232 group of peers who has the specific content for this peer. 234 Finally,the peer wants to quit the system completely. It does not 235 have to send a CONNECT message with a "leave" action one by one. It 236 just sends the DISCONNECT message to the tracker (step_6), then 237 tracker will remove all the information for this peer. 239 +--------+ +---------+ 240 | Peer | | Tracker | 241 +--------+ +---------+ 242 | | 243 step_1 |--CONNECT(swarm_a;SEED)---------->| --- 244 |<--------------------------OK-----| | 245 : : | 246 |--STAT_REPORT(activity)---------->| | 247 |<--------------------------Ok-----| | 248 : : | 249 step_2 |--CONNECT(swarm_b;LEECH)--------->| | 250 |<-----------------OK+PeerList-----| Base 251 : : tracker 252 |--STAT_REPORT(ChunkMap_b)-------->| protocol 253 |<--------------------------Ok-----| | 254 : : | 255 step_3 |--FIND(swarm_b)------------------>| | 256 |<-----------------OK+PeerList-----| | 257 : : | 258 step_4 |--CONNECT(leave swarm_b)--------->| | 259 |<--------------------------Ok-----| | 260 : : | 261 |--STAT_REPORT(activity)---------->| | 262 |<--------------------------Ok-----| | 263 : : | 264 step_5 |--CONNECT(swarm_b;LEECH)--------->| | 265 |<-----------------OK+PeerList-----| --- 266 |--FIND(swarm_b;ChunkMap_b)------->| --- 267 |<-----------------OK+PeerList-----| | 268 : : | 269 |--STAT_REPORT(ChunkMap_b)-------->| Extended 270 |<--------------------------Ok-----| tracker 271 : : protocol 272 step_6 |--DISCONNECT(nil)---------------->| | 273 |<---------------------Ok(BYE)-----| | 274 : : --- 276 Figure 1: Example of a session for a extended PPSP-TP. 278 4.4. Extended Tracker Transaction State Machine 280 The tracker state machine introduced in the base tracker protocol 281 [I-D.ietf-ppsp-base-tracker-protocol] is now updated in this 282 specification to reflect the extensions introduced. An updated "per- 283 Peer-ID" transaction state machine (Figure 2) is described, 284 corresponding to the enhanced functionalities and control steps of 285 the extended tracker protocol. This extended "per-Peer-ID" 286 transaction state machine is compatible with the one specified in the 287 base tracker protocol. 289 -------------------------------------------- 290 / \ 291 | +------------+ +=========+ +======+ | 292 \-| TERMINATED |<---| STARTED |<---| INIT |<-/ 293 +------------+ +=========+ +======+ 294 (Transient) | (1) \- (start tracker) 295 V 296 +-----------+ +-------+ rcv CONNECT 297 (Transient) | TERMINATE | | START | --------------- (1) 298 +-----------+ +-------+ strt init timer 299 rcv DICONNECT ^ | 300 rcv FIND | | 301 rcv STAT_REPORT | | 302 on registration error | v 303 on action error | +------------+ 304 ---------------- (A) +<-----| PEER | (Transient) 305 stop init timer | | REGISTERED | 306 snd error | +------------+ 307 | | 308 | | process swarm actions 309 on CONNECT Error (B) | | --------------------- (2) 310 on timeout (C) | | snd OK (PeerList) 311 on DISCONNECT (5) | / stop init timer 312 ---------------- | / strt track timer 313 stop track timer | / 314 clean peer info | | 315 del registration | | rcv FIND 316 snd error (B) \ | ---- --------------- (3) 317 ---- \ | / \ snd OK (PeerList) 318 / \ \ | | | rst track timer 319 rcv CONNECT | (4) | | | | | 320 ----------- | v | v v | rcv STAT_REPORT 321 snd OK \ +==============+ / --------------- (3) 322 rst track timer ----| TRACKING |---- snd OK response 323 +==============+ rst track timer 325 Figure 2: Extended "Per-Peer-ID" Transaction State Machine 327 The state diagram in Figure 2 illustrates the complete state changes 328 together with the causing events and resulting actions when 329 implementing the extensions to the base tracker protocol. Note that 330 Specific error conditions are not shown in the state diagram. 332 4.4.1. Normal Operation 334 Normal operation steps are the same with section 2.4.1 of the base 335 tracker protocol [I-D.ietf-ppsp-base-tracker-protocol] except step 5: 337 5) While TRACKING, a DISCONNECT message received from the peer, or a 338 CONNECT message with the action to leave the last swarm, the 339 tracker stops the "track timer", cleans the information associated 340 with the participation of the Peer-ID in the the swarm(s) joined, 341 responds with a successful condition, deletes the registration of 342 the Peer-ID and transitions to TERMINATED state for that Peer-ID. 344 4.4.2. Error Conditions 346 Error condition steps are the same with section 2.4.2 of the base 347 tracker protocol [I-D.ietf-ppsp-base-tracker-protocol] except step 348 A: 350 A) At PEER REGISTERED state, if the Peer ID is considered invalid (in 351 the case of a DISCONNECT requests received from an unregistered 352 Peer ID), the tracker responds with either error codes 401 353 Unauthorized or 403 Forbidden, transitions to TERMINATE state for 354 that Peer ID and that state machine instance is destroyed. 356 5 Extended Tracker Protocol Specification 358 5.1. Request/Response Syntax and Format 360 The architecture specified in the base tracker protocol [I-D.ietf- 361 ppsp-base-tracker-protocol] does not suffers any modification in the 362 extended protocol. The syntax is identical with some elements 363 extended to contain new optional attributes: 365 The request type includes CONNECT, FIND, STAT_REPORT and DISCONNECT, 366 including a "content" element to the FIND method, that MAY be present 367 in requests referencing content, i.e., FIND and STAT_REPORT, if the 368 request includes a content scope. 370 The extended semantics of the request therefore is described as 371 follows. 373 typedef enum ppsp_tp_request_type { 374 PPSP_TP_CONNECT = 0x02, // or "CONNECT" 375 PPSP_TP_FIND = 0x04, // or "FIND" 376 PPSP_TP_DISCONNECT = 0x06 // or "DISCONNECT" 377 PPSP_TP_STAT_REPORT = 0x08 // or "STAT_REPORT" 378 } ppsp_tp_request_type_t; 379 typedef enum ppsp_tp_versions { 380 PPSP_TP_BASE = 0x10, // or "1.0" 381 PPSP_TP_EXTENDED = 0x11, // or "1.1" 382 } ppsp_tp_version_t; 384 typedef struct { 385 ppsp_tp_version_t version; 386 ppsp_tp_request_type_t type; 387 ppsp_tp_transaction_id_t id; 388 ppsp_tp_peer_id_t peer_id; 389 union { 390 struct { 391 ppsp_tp_peer_num_t peer_num; 392 ppsp_tp_peer_info_t peer_info; 393 ppsp_tp_swarm_action_t swarm_actions[]; 394 } connect; 395 struct { 396 ppsp_tp_peer_num_t peer_num; 397 ppsp_tp_content_info_t content_info[]; 398 } find; 399 struct { 400 ppsp_tp_stat_t stats[]; 401 } stat_report; 402 } request_data; 403 } ppsp_tp_request; 405 The semantics for the content_info element is described as follow: 407 typedef unique_id_t ppsp_tp_segment_start_t; 408 typedef unique_id_t ppsp_tp_segment_end_t; 409 typedef unique_id_t ppsp_tp_chunk_addr_t; 411 typedef struct { 412 ppsp_tp_chunk_addr_t chunk_addressing_method; 413 ppsp_tp_segment_info_t segments[]; 414 } ppsp_tp_content_info_t; 416 typedef struct { 417 ppsp_tp_segment_start_t start_index; 418 ppsp_tp_segment_end_t end_index; // 0 means no end 419 } ppsp_tp_segment_info_t; 421 The semantics of Statistics is extended as follows: 423 typedef struct { 424 ppsp_tp_stat_type_t type; 425 union { 426 struct { 427 ppsp_tp_swarm_id_t swarm_id; 428 ppsp_tp_integer_t uploaded_bytes; 429 ppsp_tp_integer_t downloaded_bytes; 430 ppsp_tp_integer_t available_bandwidth; 431 } stream_stats; 432 struct { 433 ppsp_tp_content_info_t content_info[]; 434 } content_map; 435 } stat_data; 436 } ppsp_tp_stat_t; 438 Currently, the value of chunk_addressing_method is identical to the 439 addressing method listed in section 7.8 of [I-D.ietf-ppsp-peer- 440 protocol], as follow: 442 +--------+---------------------+ 443 | Method | Description | 444 +--------+---------------------+ 445 | 0 | 32-bit bins | 446 | 1 | 64-bit byte ranges | 447 | 2 | 32-bit chunk ranges | 448 | 3 | 64-bit bins | 449 | 4 | 64-bit chunk ranges | 450 | 5-255 | Unassigned | 451 +--------+---------------------+ 453 Table 1: Chunk Addressing Methods 455 Implementations MUST support "32-bit chunk ranges" (default) and "64- 456 bit chunk ranges". When the chunk_addressing_method is 32-bit bins 457 or 64-bit bins, end_index in SegmentInfo MUST be set to 0. Chunk 458 addressing methods could be extended to allow new algorithms in 459 future specifications, e.g., [BFbitmap]. This document does not 460 extends the semantics and format of Responses. 462 5.3. Compatibility with the Base Tracker Protocol 464 Trackers are RECOMMENDED to implement extended tracker protocol to be 465 compatible with peers using base tracker protocol or peers using 466 extended tracker protocol. But it is not mandatory. When peers have 467 different implementations with trackers, following 2 catalogs are 468 given: 470 1. Peer (with extended protocol) vs Tracker (with base protocol) 472 When peers using extended tracker protocol exchange content 473 information with a tracker only supporting the base tracker protocol, 474 the tracker would respond with 400 (Bad request, with reason-phrase 475 "Unknown Messages"), which indicates the messages could not be 476 recognized by the tracker. In this case, peers MUST stop interacting 477 with the tracker in extended request messages and use the base 478 tracker protocol instead. 480 2. Peer (with base protocol) vs Tracker (with extended protocol) 482 The tracker could handle all the requests from the peer because all 483 the messages are base tracker protocol messages which could be 484 perfectly accepted by a tracker implementing extended tracker 485 protocol. 487 5.4. Negotiation of Chunk Addressing Methods 489 Multiple chunk addressing methods could be used in this document to 490 present content information. But only one of them MUST be used for 491 one swarm when a peer communicating with a tracker. Before peers 492 connect to a tracker, they MUST get to know the chunk addressing 493 methods supported by the swarm. It is out of scope of the tracker 494 protocol the mechanism used to obtain that information. For example, 495 it could be some out-of-band methods that obtains that information 496 from the web portal, together with other information about the 497 trackers, e.g., IP addresses. 499 If the chunk addressing method of a swarm can not be supported by a 500 tracker, the tracker is not suggested to serve that swarm. If the 501 chunk addressing method contained in requests is not supported by the 502 swarm controlled by the tracker, the tracker could directly ignore 503 the content related information. 505 5.5. Request/Response Processing 507 5.5.1. Enhanced FIND Request 509 This method allows peers to request to the tracker, whenever needed, 510 a new peer list for the swarm for specific scope of chunks/segments 511 of a media content representation of that swarm. 513 The peer MUST properly set the request type to FIND, set the PeerID 514 with the identifier of the peer, and set the SwarmID with the 515 identifier of the swarm the peer is interested in. Optionally, in 516 order to find peers having the specific chunks/segments, the peer may 517 include the ContentGroup element in the FIND request message to 518 indicate a specific point in the content timeline. 520 This message is mainly used for peers in LEECH mode in order to 521 update the peer list of a swarm. For those requests whose peer_mode 522 are not set to LEECH, the tracker must respond with 400 (Bad request, 523 with reason-phrase "Unknown Messages"). 525 In the case of a FIND with a specific scope of a stream content the 526 request SHOULD include a ContentGroup to specify the segment range of 527 content Representations. 529 The response MAY also include a PeerGroup with PeerInfo data that 530 includes the requesting peer public IP address. 532 5.5.2. Enhanced STAT_REPORT Request 534 This message still uses the specifications of the base tracker 535 protocol [I-D.ietf-ppsp-base-tracker-protocol]. The Stat element has 536 been extended with one property, "ContentGroup", to allow peers 537 reporting map of chunks they have. The tracker would not have the 538 ability to treat the FIND requests for specific content chunks, 539 unless peers report this kind of information. The corresponding 540 Response has not been extended in this specification. 542 5.5.3. DISCONNECT Request 544 This method is used when the peer intends to leave the system and no 545 longer participate. The tracker SHOULD delete the corresponding 546 activity records related with the peer in all the swarms (including 547 its status and all content status). 549 The peer MUST properly form the Request message, set the request type 550 to DISCONNECT, set the PeerID with the identifier of the peer, and 551 randomly generate and set the TransactionID. 553 6. Error and Recovery Conditions 555 This document does not introduces any new error and recovery 556 conditions. The implementation of error treatment MUST refer to the 557 base tracker protocol specification [I-D.ietf-ppsp-base-tracker- 558 protocol]. 560 7. Security Considerations 562 The extended tracker protocol proposed in this document introduces no 563 new security considerations beyond those described in the base 564 tracker protocol specification [I-D.ietf-ppsp-base-tracker-protocol]. 566 8. IANA Considerations 568 There are presently no IANA considerations with this document. 570 9. Acknowledgments 572 The authors would like to thank many people for their help and 573 comments, particularly: Zhang Yunfei, Martin Stiemerling, Fei Song, 574 Johan Pouwelse, and Arno Bakker. 576 The authors would also like to thank the people participating in the 577 EU FP7 project SARACEN (contract no. ICT-248474) 578 [refs.saracenwebpage] for contributions and feedback to this 579 document. 581 The views and conclusions contained herein are those of the authors 582 and should not be interpreted as necessarily representing the 583 official policies or endorsements, either expressed or implied, of 584 the SARACEN project or the European Commission. 586 10 References 588 10.1 Normative References 590 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 591 Requirement Levels", BCP 14, RFC 2119, March 1997. 593 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 594 Encodings", RFC 4648, October 2006. 596 [I-D.ietf-ppsp-base-tracker-protocol] Cruz, R., Nunes, M., Gu, Y., 597 Xia, J., J. Taveira, and Lingli, D., "PPSP Tracker 598 Protocol-Base Protocol (PPSP-TP/1.0)", draft-ietf-ppsp- 599 base-tracker-protocol-04 (work in progress), July 2014. 601 [I-D.ietf-ppsp-peer-protocol] Bakker, A., Petrocco, R. and V. 602 Grishchenko, "Peer-to-Peer Streaming Peer Protocol", 603 draft-ietf-ppsp-peer-protocol-10 (work in progress), June 604 2014. 606 10.2 Informative References 608 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 609 October 2008. 611 [refs.saracenwebpage] "SARACEN Project Website", 612 http://www.saracen-p2p.eu/. 614 [BFbitmap] Bloom, B., "Space/time trade-offs in hash coding with 615 allowable errors.", Communications of ACM Vol. 13, No.7, 616 pp. 422-426, 1970. 618 Authors' Addresses 620 Rachel Huang 621 Huawei 622 Phone: +86-25-56623633 623 EMail: rachel.huang@huawei.com 625 Rui Santos Cruz 626 IST/INESC-ID/INOV 627 Phone: +351.939060939 628 Email: rui.cruz@ieee.org 630 Mario Serafim Nunes 631 INESC-ID/INOV 632 Rua Alves Redol, n.9 633 1000-029 LISBOA, Portugal 634 Phone: +351.213100256 635 Email: mario.nunes@inov.pt 637 Joao P. Taveira 638 IST/INOV 639 Email: joao.silva@inov.pt 641 Lingli Deng 642 China Mobile 643 Email: denglingli@chinamobile.com