idnits 2.17.1
draft-huang-ppsp-extended-tracker-protocol-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (January 24, 2014) is 3743 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)
== Unused Reference: 'RFC4648' is defined on line 957, but no explicit
reference was found in the text
== Outdated reference: A later version (-12) exists of
draft-ietf-ppsp-base-tracker-protocol-02
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 PPSP Rui S. Cruz
3 INTERNET-DRAFT IST/INESC-ID/INOV
4 Intended Status: Standards Track Rachel Huang
5 Expires: July 28, 2014 Ning Zong
6 Huawei
7 Mario S. Nunes
8 INESC-ID/INOV
9 Joao P. Taveira
10 IST/INOV
11 January 24, 2014
13 PPSP Tracker Protocol-Extended Protocol
14 draft-huang-ppsp-extended-tracker-protocol-05
16 Abstract
18 This document specifies an extended Peer-to-Peer Streaming Protocol -
19 Tracker Protocol, which is a new extension protocol complementing the
20 basic core messages and usages specified in the base tracker protocol
21 for the exchange of meta information between trackers and peers, such
22 as initial offer/request of participation in multimedia content
23 streaming, content information, peer lists and reports of activity
24 and status. It extends the base tracker protocol to include new
25 optional messages providing new usages in the communications between
26 peer and tracker. The extension protocol is retro-compatible with the
27 base tracker protocol.
29 Status of this Memo
31 This Internet-Draft is submitted to IETF in full conformance with the
32 provisions of BCP 78 and BCP 79.
34 Internet-Drafts are working documents of the Internet Engineering
35 Task Force (IETF), its areas, and its working groups. Note that
36 other groups may also distribute working documents as
37 Internet-Drafts.
39 Internet-Drafts are draft documents valid for a maximum of six months
40 and may be updated, replaced, or obsoleted by other documents at any
41 time. It is inappropriate to use Internet-Drafts as reference
42 material or to cite them other than as "work in progress."
44 The list of current Internet-Drafts can be accessed at
45 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.2. Extended Semantics of PPSPTrackerProtocol Elements . . . . 11
79 5.3. Extended Request/Response Element in Request Messages . . . 15
80 5.4. Compatibility with the Base Tracker Protocol . . . . . . . 15
81 5.5. Negotiation of Chunk Addressing Methods . . . . . . . . . . 15
82 6. Request/Response Processing . . . . . . . . . . . . . . . . . . 15
83 6.1. Enhanced CONNECT Request . . . . . . . . . . . . . . . . . 16
84 6.2. Enhanced FIND Request . . . . . . . . . . . . . . . . . . . 18
85 6.3. Enhanced STAT_REPORT Request . . . . . . . . . . . . . . . 20
86 6.4. DISCONNECT Request . . . . . . . . . . . . . . . . . . . . 22
87 7. Error and Recovery Conditions . . . . . . . . . . . . . . . . . 23
88 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 23
89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23
90 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
91 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
92 11.1 Normative References . . . . . . . . . . . . . . . . . . . 24
93 11.2 Informative References . . . . . . . . . . . . . . . . . . 24
94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
96 1. Introduction
98 The PPSP Tracker Protocol is one of the Peer-to-Peer Streaming
99 Protocol which specifies standard format/encoding of information and
100 messages between PPSP peers and PPSP trackers. Based on the
101 requirements defined in [RFC6972], the base tracker protocol
102 specified in [I-D.ietf-ppsp-base-tracker-protocol] has provided the
103 basic core messages to be exchanged between trackers and peers in
104 order to carry out some fundamental operations. They are mandatory
105 messages covering most basic and universal use cases and MUST be
106 implemented in all PPSP-based streaming systems.
108 This document specifies extensions to the base core messages of
109 [I-D.ietf-ppsp-base-tracker-protocol] and new optional request
110 messages providing new usages in some dedicated scenarios. The
111 extensions protocol is retro-compatible with the base tracker
112 protocol. Messages using this specification MUST be safely rejected
113 by trackers not supportting the extensions to avoid affecting
114 interoperability.
116 2. Terminology
118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
120 document are to be interpreted as described in RFC 2119 [RFC2119].
122 This draft uses terms defined in [RFC6972] and [I-D.ietf-ppsp-base-
123 tracker-protocol].
125 3. Motivation
127 There are a number of possible usages and issues which may be useful
128 for discussion and which the base tracker protocol may not be able to
129 deal with.
131 1. In the base tracker protocol, the disconnection between peer and
132 tracker is achieved by a timeout (of periodic STAT_REPORT messages)
133 which means that trackers lack the ability to timely free up
134 resources. In some cases when the number of connected peers is
135 reaching the maximum capacity of a tracker, resources of the tracker
136 cannot be released immediately, even if some peers leave the swarm.
137 Some P2P applications may require to overcome this shortage of the
138 base tracker protocol.
140 2. A peer may have the requirement to start streaming the content
141 from some specific point of the content timeline. For example, when
142 the end user watched only part of a content and decided to stop and
143 leave, or paused for a long time. When the end user decides to
144 resume the session he/she expects to continue watching the content
145 from the point where he/she interrupted. The peer may then request
146 the tracker to select a subset of peers capable to provide that
147 specific content scope.
149 The above use cases require the base tracker protocol to be extended.
151 4. Extended Tracker Protocol Overview
153 The extended Tracker Protocol consists of three Request-Response
154 Extensions (to the CONNECT, FIND and STAT_REPORT Request messages of
155 the Base Protocol) and one Protocol-level Extension (a new DISCONNECT
156 Request message).
158 4.1. Request-Response Extension
160 In this section, the CONNECT, FIND and STAT_REPORT messages specified
161 in the base tracker protocol are extended to meet the needs of use
162 cases listed in section 3.
164 CONNECT: This enhanced CONNECT Request message tends to solve the
165 issue 2 raised in section 3. The extension of the CONNECT
166 Request message includes information of specific content
167 scopes, either media content representations or specific
168 chunks/segments of a media representation in a swarm. The
169 format and detailed processing of enhanced CONNECT Request
170 message is presented in Section 5.1.
172 FIND: The enhanced FIND Request message allows a peer to request
173 the tracker for a subset of peers in a swarm but including
174 specific content scopes, either media content
175 representations or specific chunks/segments of a media
176 representation in a swarm, and may also include an updated
177 network address of the peer. On receiving a FIND message,
178 the tracker selects a subset of peers satisfying the
179 requesting scope. To create the peer list, the tracker may
180 also take peer status, capabilities and peers priority into
181 consideration. Peer priority may be determined by network
182 topology preference, operator policy preference, etc. The
183 format and detailed processing of enhanced CONNECT Request
184 message is presented in Section 5.2.
186 STAT_REPORT: The enhanced STAT_REPORT Request message allows the
187 exchanges of content data information, like chunkmaps,
188 between an active peer and a tracker. The information can
189 be used by a tracker as a qualification to select
190 appropriate subsets of peers in the swarm satisfying
191 specific scopes (in terms of content). The format and
192 detailed processing of enhanced CONNECT Request message is
193 presented in Section 5.3.
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 need 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
205 to the peer (including its status and all content status
206 for the corresponding swarms). In such a case, the
207 DISCONNECT Request message will have the same effect of
208 timer expiring (STAT_REPORT), but providing a graceful
209 disconnect of that peer from the system.
211 4.3. Usage of Extended Request Messages
213 An example of usage of the extended request messages is the
214 illustrated in Figure 1. In that figure a peers starts by connecting
215 to the system and joining a specific swarm (swarm_a) in SEED mode.
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. During the streaming
221 the peer requests an updated list of peers in that new swarm to the
222 tracker.
224 When the end user wants to leave the second content, not having even
225 finished watching, the peer sends CONNECT message with a leave action
226 for the corresponding swarm (swarm_b) but remains sharing the first
227 content (swarm_a). Later the peer DISCONNECTs from the system.
229 When in a next time, the end user wants to continue watching the
230 content he/she previously left unfinished, the peer CONNECTs to the
231 corresponding swarm in LEECH mode but sending the specific content
232 information scope.
234 +--------+ +---------+
235 | Peer | | Tracker |
236 +--------+ +---------+
237 | |
238 |--CONNECT(swarm_a;SEED)---------->|
239 |<--------------------------OK-----|
240 : :
241 |--STAT_REPORT(activity)---------->|
242 |<--------------------------Ok-----|
243 : :
244 |--CONNECT(swarm_b;LEECH)--------->|
245 |<-----------------OK+PeerList-----|
246 : :
247 |--STAT_REPORT(ChunkMap_b)-------->|
248 |<--------------------------Ok-----|
249 : :
250 |--FIND(swarm_b)------------------>|
251 |<-----------------OK+PeerList-----|
252 : :
253 |--CONNECT(leave swarm_b)--------->|
254 |<--------------------------Ok-----|
255 : :
256 |--STAT_REPORT(activity)---------->|
257 |<--------------------------Ok-----|
258 : :
259 |--DISCONNECT(nil)---------------->|
260 |<---------------------Ok(BYE)-----|
261 : :
262 |-CONNECT(swarm_b;LEECH;ChunkMap)->|
263 |<-----------------OK+PeerList-----|
264 : :
266 Figure 1: Example of a session for a extended PPSP-TP.
268 4.4. Extended Tracker Transaction State Machine
270 The tracker state machine introduced in the base tracker protocol
271 [I-D.ietf-ppsp-base-tracker-protocol] is now updated in this
272 specification to reflect the extensions introduced. An updated "per-
273 Peer-ID" transaction state machine (Figure 2) is described,
274 corresponding to the enhanced functionalities and control steps of
275 the extended tracker protocol. This extended "per-Peer-ID"
276 transaction state machine is compatible with the one specified in the
277 base tracker protocol.
279 +-----------+ +-------+ rcv CONNECT
280 (Transient) | TERMINATE | | START | --------------- (1)
281 +-----------+ +-------+ strt init timer
282 rcv STAT_REPORT ^ |
283 rcv FIND | |
284 rcv DISCONNECT | |
285 on registration error | v
286 on action error | +------------+
287 ---------------- (A) +<-----| PEER | (Transient)
288 stop init timer | | REGISTERED |
289 snd error | +------------+
290 | |
291 | | process swarm actions
292 | | --------------------- (2)
293 on CONNECT Error (B) | | snd OK (PeerList)
294 on timeout (C) | / stop init timer
295 ---------------- | / strt track timer
296 stop track timer | /
297 clean peer info | |
298 del registration | |
299 snd error (B) | |
300 | |
301 rcv CONNECT(@leave) | | rcv FIND
302 rcv DISCONNECT (nil) | | ----------------- (3)
303 --------------- (5) \ | ---- snd OK (PeerList)
304 snd OK response ---- \ | / \ rst tracker timer
305 / \ \ | | |
306 rcv CONNECT | (4) | | | | |
307 ----------- | v | v v | rcv STAT_REPORT
308 snd OK \ +-------------+ / --------------- (3)
309 rst track timer ----| TRACKING |---- snd OK response
310 +--------------+ rst track timer
312 Figure 2: Extended Per-Peer-ID Transaction State Machine
314 The state diagram in Figure 2 illustrates the complete state changes
315 together with the causing events and resulting actions when
316 implementing the extensions to the base tracker protocol. Note that
317 Specific error conditions are not shown in the state diagram.
319 4.4.1. Normal Operation
321 On normal operation the extended process consists of the following
322 steps:
324 1) This step is same step 1) in section 2.4.1 of the base tracker
325 protocol [I-D.ietf-ppsp-base-tracker-protocol].
327 2) This step is same step 2) in section 2.4.1 of the base tracker
328 protocol [I-D.ietf-ppsp-base-tracker-protocol].
330 3) This step is same step 3) in section 2.4.1 of the base tracker
331 protocol [I-D.ietf-ppsp-base-tracker-protocol], but with extended
332 scope in the FIND Request message and in the STAT_REPORT Request
333 message.
335 4) This step is same step 4) in section 2.4.1 of the base tracker
336 protocol [I-D.ietf-ppsp-base-tracker-protocol]
338 5) While TRACKING, a DISCONNECT message received from the peer, or a
339 CONNECT message with the action to leave the last swarm, the
340 tracker stops the "track timer", cleans the information associated
341 with the participation of the Peer-ID in the the swarm(s) joined,
342 responds with a successful condition, deletes the registration of
343 the Peer-ID and transitions to TERMINATED state for that Peer-ID.
345 4.4.2. Error Conditions
347 Peers MUST NOT generate protocol elements that are invalid.
348 However, several situations of a peer may lead to abnormal
349 conditions in the interaction with the tracker. The situations
350 may be related with peer malfunction or communications errors.
351 The tracker reacts to the abnormal situations depending on its
352 current state related to a Peer ID, as follows:
354 A) At PEER REGISTERED state, if the Peer ID is considered invalid (in
355 the case of a DISCONNECT requests received from an unregistered
356 Peer ID), the tracker responds with either error codes 401
357 Unauthorized or 403 Forbidden, transitions to TERMINATE state for
358 that Peer ID and the state machine is destroyed.
360 B) This step is the same step B) in section 2.4.2 of the base tracker
361 protocol [I-D.ietf-ppsp-base-tracker-protocol.
363 C) This step is the same step c) in section 2.4.2 of the base
364 tracker protocol [I-D.ietf-ppsp-base-tracker-protocol.
366 NOTE: These situations may correspond to a malfunction at the peer
367 or to malicious conditions. Therefore, as preventive measure, the
368 tracker proceeds to TERMINATE state for the Peer ID by de-
369 registering the peer and cleaning all peer information.
371 5 Extended Tracker Protocol Specification
373 5.1. Request/Response Syntax and Format
374 The architecture specified in the base tracker protocol [I-D.ietf-
375 ppsp-base-tracker-protocol] does not suffer any modification in the
376 extended protocol. The syntax is identical with some elements
377 extended to contain new optional attributes:
379 The SwarmID element MAY be present in DISCONNECT requests.
381 The element "ContentGroup" is added to the format of Request. It MAY
382 be present in requests referencing content, i.e., CONNECT and FIND,
383 if the request includes a content scope.
385 The extended semantics of the attributes and elements within a
386 PPSPTrackerProtocol root element is described in section 5.2.
388 5.2. Extended Semantics of PPSPTrackerProtocol Elements
390 The extension semantics of PPSPTrackerProtocol is a follows.
392 +----------------------+---------+----------------------------------+
393 | Element Name or | Use | Description |
394 | Attribute Name | | |
395 +----------------------+---------+----------------------------------+
396 | PPSPTrackerProtocol | 1 | The root element. |
397 | @version | M | Provides the version of PPSP-TP. |
398 | Request | 0...1 | Provides the request method |
399 | | | and MUST be present in Request. |
400 | Response | 0...1 | Provides the response method |
401 | | | and MUST be present in Response. |
402 | TransactionID | M | Root transaction Identification. |
403 | Result | 0...N | Result of @action MUST be present|
404 | | | in Responses. |
405 | @transactionID | CM | Identifier of the @action. |
406 | PeerID | 0...1 | Peer Identification. |
407 | | | MUST be present in Request. |
408 | SwarmID | 0...N | Swarm Identification. |
409 | | | MUST be present in Requests. |
410 | @action | CM | Must be set to JOIN or LEAVE. |
411 | @peerMode | CM | Mode of Peer participation in |
412 | | | the swarm, "LEECH" or "SEED". |
413 | @transactionID | CM | Identifier for the @action. |
414 | PeerNUM | 0...1 | Maximum peers to be received |
415 | | | with capabilities indicated. |
416 | @abilityNAT | CM | Type of NAT traversal peers, as |
417 | | | "No-NAT","STUN","TURN" or "PROXY"|
418 | @concurrentLinks| CM | Concurrent connectivity level of |
419 | | | peers, "HIGH", "LOW" or "NORMAL" |
420 | @onlineTime | CM | Availability or online duration |
421 | | | of peers, "HIGH" or "NORMAL" |
422 | @uploadBWlevel | CM | Upload bandwidth capability of |
423 | | | peers, "HIGH" or "NORMAL" |
424 | ContentGroup | 0...1 | Information on content (Table 4) |
425 | PeerGroup | 0...1 | Information on peers (Table 3) |
426 | StatisticsGroup | 0...1 | Statistic data (Table 5) |
427 +----------------------+---------+----------------------------------+
428 | Legend: |
429 | Use for attributes: M=Mandatory, OP=Optional, |
430 | CM=Conditionally Mandatory |
431 | Use for elements: minOccurs...maxOccurs (N=unbounded) |
432 | Elements are represented by their name (case-sensitive) |
433 | Attribute names (case-sensitive) are preceded with an @ |
434 +-------------------------------------------------------------------+
435 Table 1: Semantics of the Extended PPSPTrackerProtocol.
437 The semantics of PeerGroup element is almost identical with that of the
438 base tracker protocol.
440 +----------------------+---------+----------------------------------+
441 | Element Name or | Use | Description |
442 | Attribute Name | | |
443 +----------------------+---------+----------------------------------+
444 | PeerGroup | 0...1 | Contains description of peers. |
445 | PeerInfo | 1...N | Provides information on a peer. |
446 | @swarmID | 0...1 | Swarm Identification. |
447 | PeerID | 0...1 | Peer Identification. |
448 | | | MAY be present in responses. |
449 | PeerAddress | 0...N | IP Address information. |
450 | @addrType | M | Type of IP address, which can be |
451 | | | "ipv4" or "ipv6" |
452 | @priority | CM | The priority of this interface. |
453 | | | Used for NAT traversal. |
454 | @type | CM | Describes the address for NAT |
455 | | | traversal, which can be "HOST" |
456 | | | "REFLEXIVE" or "PROXY". |
457 | @connection | OP | Access type ("3G", "ADSL", etc.) |
458 | @asn | OP | Autonomous System number. |
459 | @ip | M | IP address value. |
460 | @port | M | IP service port value. |
461 | @peerProtocol | OP | PPSP Peer Protocol supported. |
462 +----------------------+---------+----------------------------------+
463 | Legend: |
464 | Use for attributes: M=Mandatory, OP=Optional, |
465 | CM=Conditionally Mandatory |
466 | Use for elements: minOccurs...maxOccurs (N=unbounded) |
467 | Elements are represented by their name (case-sensitive) |
468 | Attribute names (case-sensitive) are preceded with an @ |
469 +-------------------------------------------------------------------+
470 Table 2: Semantics of PeerGroup.
472 Table 3 describes the semantics of StatisticsGroup element, extended
473 with content information attributes.
474 +----------------------+---------+----------------------------------+
475 | Element Name or | Use | Description |
476 | Attribute Name | | |
477 +----------------------+---------+----------------------------------+
478 | StatisticsGroup | 0...1 | Provides statistic data on peer |
479 | | | and content. |
480 | Stat | 1...N | Groups statistics property data. |
481 | @property | M | The property to be reported |
482 | | | property values and elements |
483 | | | in Table 5 of [I-D.ietf-ppsp-base|
484 | | | -tracker-protocol] |
485 | ContentGroup | 0...1 | Information on content (Table 4) |
486 +----------------------+---------+----------------------------------+
487 | Legend: |
488 | Use for attributes: M=Mandatory, OP=Optional, |
489 | CM=Conditionally Mandatory |
490 | Use for elements: minOccurs...maxOccurs (N=unbounded) |
491 | Elements are represented by their name (case-sensitive) |
492 | Attribute names (case-sensitive) are preceded with an @ |
493 +-------------------------------------------------------------------+
494 Table 3: Semantics of StatisticsGroup.
496 ContentGroup is a new element. The semantics of this element is
497 described in Table 4.
499 +----------------------+---------+----------------------------------+
500 | Element Name or | Use | Description |
501 | Attribute Name | | |
502 +----------------------+---------+----------------------------------+
503 | ContentGroup | 0...1 | Provides information on content. |
504 | CAM | 1 | Describes the chunk addressing |
505 | | | method of this content. The value|
506 | | | is identical with the value of |
507 | | | Table 6 of [I-D.ietf-ppsp-peer |
508 | | | -protocol] |
509 | Representation | 1...N | Describes a component of content.|
510 | @id | M | Unique identifier for this |
511 | | | Representation. |
512 | SegmentInfo | 1 | Provides segment information. |
513 | @startIndex | M | The index of the first media |
514 | | | segment in the request scope for |
515 | | | this Representation. |
516 | @endIndex | OP | The index of the last media |
517 | | | segment in the request scope for |
518 | | | this Representation. |
519 +----------------------+---------+----------------------------------+
520 | Legend: |
521 | Use for attributes: M=Mandatory, OP=Optional, |
522 | CM=Conditionally Mandatory |
523 | Use for elements: minOccurs...maxOccurs (N=unbounded) |
524 | Elements are represented by their name (case-sensitive) |
525 | Attribute names (case-sensitive) are preceded with an @ |
526 +-------------------------------------------------------------------+
528 Table 4: Semantics of ContentGroup
530 The Representation element describes a component of a content
531 identified by its attribute @id in the Media Presentation Description
532 (MPD). This element MAY be present for each component desired in the
533 scope of the FIND or CONNECT requests. The scope of each
534 Representation is indicated by the SegmentInfo element and the
535 attributes @startIndex and, optionally, @endIndex.
537 5.3. Extended Request/Response Element in Request Messages
539 Table 5 specifies the valid string representations for the requests
540 extended in this specification to complement those define in the base
541 tracker protocol. These values MUST be treated as case-sensitive.
543 +----------------------+
544 | Extended XML Request |
545 | Methods String Values|
546 +----------------------+
547 | DISCONNECT |
548 +----------------------+
550 Table 5: Extended Valid Strings for Request Element of Requests.
552 The response elements in the extension are identical to those of the
553 base tracker protocol [I-D.ietf-ppsp-base-tracker-protocol].
555 5.4. Compatibility with the Base Tracker Protocol
557 Trackers are RECOMMENDED to implement extended tracker protocol to be
558 compatible with peers using base tracker protocol or peers using
559 extended tracker protocol. But it is not mandatory. When peers using
560 extended tracker protocol changes content information with a tracker
561 only supporting base tracker protocol, the tracker could directly
562 ignore the content related information, e.g. ContentGroup element and
563 Representation attribute. Peers implementing the extended tracker
564 protocol sending DISCONNECT message to legacy trackers will get
565 respond with 400 (Bad request, with reason-phrase "Unknown
566 Messages"), which indicate the messages could not be recognized by
567 the tracker. In this case, the peers MUST stop interacting with the
568 tracker in extended request messages and use the base tracker
569 protocol instead.
571 5.5. Negotiation of Chunk Addressing Methods
573 Multiple chunk addressing methods could be used in this document to
574 present content information. But only one of them MUST be used for
575 one swarm when a peer communicating with a tracker. Before peers
576 connect to a tracker, it MUST get the knowledge of the chunk
577 addressing methods supported by the tracker. How to get the
578 information is out of scope of the tracker protocol. It could be some
579 out-of-band methods. For example, the chunk addressing methods
580 supported by the tracker could be obtained from the web portal
581 together with other information of the tracker, e.g. IP address.
583 6. Request/Response Processing
584 6.1. Enhanced CONNECT Request
586 This method is used when a peer wants to join one or multiple swarms.
587 The tracker records the Peer-ID, connect-time, IP addresses and link
588 status.
590 The peer MUST properly form the XML message-body, set the Request
591 method to CONNECT, generate and set the TransactionID, and set the
592 PeerID with the identifier of the peer. The peer SHOULD also include
593 the IP addresses of its network interfaces in the CONNECT message.
595 Extended CONNECT request is retro-compatible with the CONNECT request
596 message defined in the base tracker protocol specification.
598 An example of the message-body of the extended CONNECT Request is the
599 following.
601
602
603 CONNECT
604 656164657220
605 12345.0
606 1111
608 5
612
613
614
615
616
617
618
619
620
621
622
624
628
629
630
631 In this example, the peer wants to participate in swarm 1111 to watch
632 the program as LEECH, and it also wishes to start from a specific
633 point of the content timeline. As such, the CONNECT request message
634 contains a ContentGroup element including the information to restrict
635 the search for peers in the swarm. The extended CONNECT request MAY
636 include a PeerNum element to indicate to the tracker the number of
637 peers to be returned in a list corresponding to the indicated
638 properties, being @abilityNAT for NAT traversal (considering that
639 PPSP-ICE NAT traversal techniques may be used), and optionally
640 @concurrentLinks, @onlineTime and @uploadBWlevel for the preferred
641 capabilities. In case PeerMode is LEECH, the tracker will search and
642 select a proper list of peers satisfying the conditions requested.
643 The peer list MUST contain the Peer-IDs and the corresponding IP
644 addresses. To create the peer list, the tracker may take peer status
645 and network location information into consideration, to express
646 network topology preference or operators' policy preferences, with
647 regard to the possibility of connecting with other IETF efforts such
648 as ALTO [I.D.ietf-alto-protocol]. Thus a PeerGroup MAY also be
649 needed in an extended CONNECT request messages.
651 The response MUST have the same TransactionID value as the request.
652 An example of a Response message for the extended CONNECT Request
653 from a leecher is the following:
655
656
657 SUCCESSFUL
658 12345
659
660
661 656164657220
662
667
668
669 956264622298
670
672
673
674 3332001256741
675
677
678
680
682 6.2. Enhanced FIND Request
684 This method allows peers to request to the tracker, whenever needed,
685 a new peer list for the swarm for specific scope of chunks/segments
686 of a media content representation of that swarm.
688 The peer MUST properly form the XML message-body, set the request
689 method to FIND, set the PeerID with the identifier of the peer, set
690 the SwarmID with the identifier of the swarm the peer is interested
691 in. And optionally, in order to find peer having the specific
692 chunks/segments, the peer may include the ContentGroup element in the
693 JOIN request message to indicate a specific point in the content
694 timeline.
696 This message is mainly used for leechers to update the peer list. It
697 is unnecessary to set the PeerMode element in FIND request messages.
699 The peer MUST generate and set the TransactionID for the request.
701 An example of the message-body of a FIND Request is the following:
703
704
705 FIND
706 656164657221
707 1111
708 12345
709 5
713
714
715
716
717
718
720 The FIND request MAY include a PeerNum element to indicate to the
721 tracker the number of peers to be returned in a list corresponding to
722 the indicated properties, being @abilityNAT for NAT traversal
723 (considering that PPSP-ICE NAT traversal techniques may be used), and
724 optionally @concurrentLinks, @onlineTime and @uploadBWlevel for the
725 preferred capabilities.
727 In the case of a FIND with a specific scope of a stream content the
728 request SHOULD include a ContentGroup to specify the segment range of
729 content Representations.
731 When receiving a well-formed FIND Request the tracker processes the
732 information to check if it is valid. In case of success a response
733 message with a Response value of SUCCESSFUL will be generated and the
734 tracker will include the appropriate list of peers satisfying the
735 conditions requested. The peer list returned MUST contain the Peer-
736 IDs and the corresponding IP Addresses.
738 The tracker may take peer status and network location information
739 into consideration when selecting the peer list to return, to express
740 network topology preferences or Operators' policy preferences, with
741 regard to the possibility of connecting with other IETF efforts such
742 as ALTO [I.D.ietf-alto-protocol].
744 An example of a Response message for the FIND Request is:
746
747
748 SUCCESSFUL
749 12345
750
751
752 956264622298
753
755
756
757 3332001256741
758
760
761
762
764 The Response MUST include a PeerGroup with PeerInfo data that
765 includes the public IP address of the selected active peers in the
766 swarm.
768 The tracker MAY also include the attribute @asn with network location
769 information of the transport addresses of the peers, corresponding to
770 the Autonomous System Numbers of the access network provider of each
771 peer in the list.
773 The response MAY also include a PeerGroup with PeerInfo data that
774 includes the requesting peer public IP address. If STUN-like
775 function is enabled in the tracker, the PeerAddress includes the
776 attribute @type with a value of REFLEXIVE, corresponding to the
777 transport address "candidate" of the peer.
779 An example of a Response message for the FIND Request including the
780 requesting peer public IP address is the following:
782
783
784 SUCCESSFUL
785 12345
786
787
788 656164657221
789
794
795
796 956264622298
797
799
800
801 3332001256741
802
804
805
806
808 6.3. Enhanced STAT_REPORT Request
810 This message still uses the specifications of the base tracker
811 protocol [I-D.ietf-ppsp-base-tracker-protocol]. The Stat element has
812 been extended with one property, "ContentMap", to allow peers
813 reporting map of chunks they have. The tracker would not have the
814 ability to treat the FIND requests for specific content chunks,
815 unless peers report this kind of information.
817 An example of the message-body of an enhanced STAT_REPORT request is
818 the following:
820
821
822 STAT_REPORT
823 656164657221
824 12345
825
826
827 1111
828 512
829 768
830 1024000
831
832
833 2222
834 1024
835 2048
836 512000
837
838
839 1111
840
841
842 A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/....
843
844
845
846
847 A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/....
848
849
850 A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/....
851
852
853
854
855 2222
856
857
858 A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/....
859
860
861
862
863 A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/....
864
865
866
867
868
870 If the request is valid the tracker process the received information
871 for future use, and generates a response message with a Response
872 value of SUCCESSFUL.
874 The response MUST have the same TransactionID value as the request.
876 An example of a Response message for the START_REPORT Request is the
877 following:
879
880
881 SUCCESSFUL
882 12345
883
885 6.4. DISCONNECT Request
887 This method is used when the peer intends to leave the system and no
888 longer participate.
890 The tracker SHOULD delete the corresponding activity records related
891 with the peer in the corresponding swarms (including its status and
892 all content status).
894 The peer MUST properly form the XML message-body, set the Request
895 method to DISCONNECT, set the PeerID with the identifier of the peer,
896 randomly generate and set the TransactionID.
898 An example of the message-body of a DISCONNECT Request for the peer
899 leaving all joined swarms is the following:
901
902
903 DISCONNECT
904 656164657221
905 12345
906
908 An example of a Response message for the DISCONNECT Request is the
909 following:
911
912
913 SUCCESSFUL
914 12345
915
917 7. Error and Recovery Conditions
919 This document does not introduces any new error and recovery
920 conditions. The implementation of error treatment MUST refer to the
921 base tracker protocol specification [I-D.ietf-ppsp-base-tracker-
922 protocol].
924 8. Security Considerations
926 The extended tracker protocol proposed in this document introduces no
927 new security considerations beyond those described in the base
928 tracker protocol specification [I-D.ietf-ppsp-base-tracker-protocol].
930 9. IANA Considerations
932 There are presently no IANA considerations with this document.
934 10. Acknowledgments
936 The authors would like to thank many people for their help and
937 comments, particularly: Zhang Yunfei, Martin Stiemerling, Johan
938 Pouwelse and Arno Bakker.
940 The authors would also like to thank the people participating in the
941 EU FP7 project SARACEN (contract no. ICT-248474)
942 [refs.saracenwebpage] for contributions and feedback to this
943 document.
945 The views and conclusions contained herein are those of the authors
946 and should not be interpreted as necessarily representing the
947 official policies or endorsements, either expressed or implied, of
948 the SARACEN project or the European Commission.
950 11 References
952 11.1 Normative References
954 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
955 Requirement Levels", BCP 14, RFC 2119, March 1997.
957 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
958 Encodings", RFC 4648, October 2006.
960 [ISO.8601.2004] International Organization for Standardization, "Data
961 elements and interchange formats - Information interchange
962 - Representation of dates and times", ISO Standard 8601,
963 December 2004.
965 11.2 Informative References
967 [RFC6972] Zhang, Y. and N. Zong, "Problem Statement and Requirements
968 of the Peer-to-Peer Streaming Protocol (PPSP)", RFC 6972,
969 July 2013..
971 [I-D.ietf-ppsp-base-tracker-protocol] Cruz, R., Nunes, M., Gu, Y.,
972 Xia, J., and J. Taveira, "PPSP Tracker Protocol-Base
973 Protocol (PPSP-TP/1.0)", draft-ietf-ppsp-base-tracker-
974 protocol-02 (work in progress), October 2013.
976 [I.D.ietf-alto-protocol] Alimi, R., Penno, R. and Y. Yang, "ALTO
977 Protocol", draft-ietf-alto-protocol-20, (work in
978 progress), October 2013.
980 [ISO.IEC.23009-1] ISO/IEC, "Information technology -- Dynamic
981 adaptive streaming over HTTP (DASH) -- Part 1: Media
982 presentation description and segment formats", ISO/IEC DIS
983 23009-1, Aug. 2011.
985 [refs.saracenwebpage] "SARACEN Project Website",
986 http://www.saracen-p2p.eu/.
988 Authors' Addresses
990 Rui Santos Cruz
991 IST/INESC-ID/INOV
992 Phone: +351.939060939
993 Email: rui.cruz@ieee.org
995 Rachel Huang
996 Huawei
997 Phone: +86-25-56623633
998 EMail: rachel.huang@huawei.com
1000 Ning Zong
1001 Huawei
1002 Phone: +86-25-56624760
1003 EMail: zongning@huawei.com
1005 Mario Serafim Nunes
1006 INESC-ID/INOV
1007 Rua Alves Redol, n.9
1008 1000-029 LISBOA, Portugal
1009 Phone: +351.213100256
1010 Email: mario.nunes@inov.pt
1012 Joao P. Taveira
1013 IST/INOV
1014 Email: joao.silva@inov.pt