PPSP Tracker Protocol-Extended Protocol
draft-huang-ppsp-extended-tracker-protocol-05
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Rui António dos Santos Cruz , Rachel Huang , Ning Zong , Mario Sera Nunes , Joao P. Taveira | ||
| Last updated | 2014-01-23 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-huang-ppsp-extended-tracker-protocol-05
PPSP Rui S. Cruz
INTERNET-DRAFT IST/INESC-ID/INOV
Intended Status: Standards Track Rachel Huang
Expires: July 28, 2014 Ning Zong
Huawei
Mario S. Nunes
INESC-ID/INOV
Joao P. Taveira
IST/INOV
January 24, 2014
PPSP Tracker Protocol-Extended Protocol
draft-huang-ppsp-extended-tracker-protocol-05
Abstract
This document specifies an extended Peer-to-Peer Streaming Protocol -
Tracker Protocol, which is a new extension protocol complementing the
basic core messages and usages specified in the base tracker protocol
for the exchange of meta information between trackers and peers, such
as initial offer/request of participation in multimedia content
streaming, content information, peer lists and reports of activity
and status. It extends the base tracker protocol to include new
optional messages providing new usages in the communications between
peer and tracker. The extension protocol is retro-compatible with the
base tracker protocol.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
Huang, et al. Expires July 28, 2014 [Page 1]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Huang, et al. Expires July 28, 2014 [Page 2]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Extended Tracker Protocol Overview . . . . . . . . . . . . . . 5
4.1. Request-Response Extension . . . . . . . . . . . . . . . . 5
4.2. Protocol-level Extension . . . . . . . . . . . . . . . . . 6
4.3. Usage of Extended Request Messages . . . . . . . . . . . . 6
4.4. Extended Tracker Transaction State Machine . . . . . . . . 7
4.4.1. Normal Operation . . . . . . . . . . . . . . . . . . . 8
4.4.2. Error Conditions . . . . . . . . . . . . . . . . . . . 9
5 Extended Tracker Protocol Specification . . . . . . . . . . . . 9
5.1. Request/Response Syntax and Format . . . . . . . . . . . . 9
5.2. Extended Semantics of PPSPTrackerProtocol Elements . . . . 11
5.3. Extended Request/Response Element in Request Messages . . . 15
5.4. Compatibility with the Base Tracker Protocol . . . . . . . 15
5.5. Negotiation of Chunk Addressing Methods . . . . . . . . . . 15
6. Request/Response Processing . . . . . . . . . . . . . . . . . . 15
6.1. Enhanced CONNECT Request . . . . . . . . . . . . . . . . . 16
6.2. Enhanced FIND Request . . . . . . . . . . . . . . . . . . . 18
6.3. Enhanced STAT_REPORT Request . . . . . . . . . . . . . . . 20
6.4. DISCONNECT Request . . . . . . . . . . . . . . . . . . . . 22
7. Error and Recovery Conditions . . . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1 Normative References . . . . . . . . . . . . . . . . . . . 24
11.2 Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Huang, et al. Expires July 28, 2014 [Page 3]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
1. Introduction
The PPSP Tracker Protocol is one of the Peer-to-Peer Streaming
Protocol which specifies standard format/encoding of information and
messages between PPSP peers and PPSP trackers. Based on the
requirements defined in [RFC6972], the base tracker protocol
specified in [I-D.ietf-ppsp-base-tracker-protocol] has provided the
basic core messages to be exchanged between trackers and peers in
order to carry out some fundamental operations. They are mandatory
messages covering most basic and universal use cases and MUST be
implemented in all PPSP-based streaming systems.
This document specifies extensions to the base core messages of
[I-D.ietf-ppsp-base-tracker-protocol] and new optional request
messages providing new usages in some dedicated scenarios. The
extensions protocol is retro-compatible with the base tracker
protocol. Messages using this specification MUST be safely rejected
by trackers not supportting the extensions to avoid affecting
interoperability.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
This draft uses terms defined in [RFC6972] and [I-D.ietf-ppsp-base-
tracker-protocol].
3. Motivation
There are a number of possible usages and issues which may be useful
for discussion and which the base tracker protocol may not be able to
deal with.
1. In the base tracker protocol, the disconnection between peer and
tracker is achieved by a timeout (of periodic STAT_REPORT messages)
which means that trackers lack the ability to timely free up
resources. In some cases when the number of connected peers is
reaching the maximum capacity of a tracker, resources of the tracker
cannot be released immediately, even if some peers leave the swarm.
Some P2P applications may require to overcome this shortage of the
base tracker protocol.
2. A peer may have the requirement to start streaming the content
from some specific point of the content timeline. For example, when
the end user watched only part of a content and decided to stop and
Huang, et al. Expires July 28, 2014 [Page 4]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
leave, or paused for a long time. When the end user decides to
resume the session he/she expects to continue watching the content
from the point where he/she interrupted. The peer may then request
the tracker to select a subset of peers capable to provide that
specific content scope.
The above use cases require the base tracker protocol to be extended.
4. Extended Tracker Protocol Overview
The extended Tracker Protocol consists of three Request-Response
Extensions (to the CONNECT, FIND and STAT_REPORT Request messages of
the Base Protocol) and one Protocol-level Extension (a new DISCONNECT
Request message).
4.1. Request-Response Extension
In this section, the CONNECT, FIND and STAT_REPORT messages specified
in the base tracker protocol are extended to meet the needs of use
cases listed in section 3.
CONNECT: This enhanced CONNECT Request message tends to solve the
issue 2 raised in section 3. The extension of the CONNECT
Request message includes information of specific content
scopes, either media content representations or specific
chunks/segments of a media representation in a swarm. The
format and detailed processing of enhanced CONNECT Request
message is presented in Section 5.1.
FIND: The enhanced FIND Request message allows a peer to request
the tracker for a subset of peers in a swarm but including
specific content scopes, either media content
representations or specific chunks/segments of a media
representation in a swarm, and may also include an updated
network address of the peer. On receiving a FIND message,
the tracker selects a subset of peers satisfying the
requesting scope. To create the peer list, the tracker may
also take peer status, capabilities and peers priority into
consideration. Peer priority may be determined by network
topology preference, operator policy preference, etc. The
format and detailed processing of enhanced CONNECT Request
message is presented in Section 5.2.
STAT_REPORT: The enhanced STAT_REPORT Request message allows the
exchanges of content data information, like chunkmaps,
between an active peer and a tracker. The information can
be used by a tracker as a qualification to select
appropriate subsets of peers in the swarm satisfying
Huang, et al. Expires July 28, 2014 [Page 5]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
specific scopes (in terms of content). The format and
detailed processing of enhanced CONNECT Request message is
presented in Section 5.3.
4.2. Protocol-level Extension
A new Request message is introduced in this section to extend those
specified in the base tracker protocol [I-D.ietf-ppsp-base-tracker-
protocol], to meet the need of issue 1 listed in section 3.
DISCONNECT: The DISCONNECT Request message is used when the peer
intends to no longer participate in all swarms. When
receiving the DISCONNECT Request message from a peer, the
tracker deletes the corresponding activity records related
to the peer (including its status and all content status
for the corresponding swarms). In such a case, the
DISCONNECT Request message will have the same effect of
timer expiring (STAT_REPORT), but providing a graceful
disconnect of that peer from the system.
4.3. Usage of Extended Request Messages
An example of usage of the extended request messages is the
illustrated in Figure 1. In that figure a peers starts by connecting
to the system and joining a specific swarm (swarm_a) in SEED mode.
While active, the peer periodically updates the tracker using
STAT_REPORT messages. Later, the peer CONNECTs to another swarm
(swarm_b) but in LEECH mode, i.e., the end-user intends to watch that
new content while still sharing the first one. During the streaming
the peer requests an updated list of peers in that new swarm to the
tracker.
When the end user wants to leave the second content, not having even
finished watching, the peer sends CONNECT message with a leave action
for the corresponding swarm (swarm_b) but remains sharing the first
content (swarm_a). Later the peer DISCONNECTs from the system.
When in a next time, the end user wants to continue watching the
content he/she previously left unfinished, the peer CONNECTs to the
corresponding swarm in LEECH mode but sending the specific content
information scope.
+--------+ +---------+
| Peer | | Tracker |
+--------+ +---------+
| |
|--CONNECT(swarm_a;SEED)---------->|
Huang, et al. Expires July 28, 2014 [Page 6]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
|<--------------------------OK-----|
: :
|--STAT_REPORT(activity)---------->|
|<--------------------------Ok-----|
: :
|--CONNECT(swarm_b;LEECH)--------->|
|<-----------------OK+PeerList-----|
: :
|--STAT_REPORT(ChunkMap_b)-------->|
|<--------------------------Ok-----|
: :
|--FIND(swarm_b)------------------>|
|<-----------------OK+PeerList-----|
: :
|--CONNECT(leave swarm_b)--------->|
|<--------------------------Ok-----|
: :
|--STAT_REPORT(activity)---------->|
|<--------------------------Ok-----|
: :
|--DISCONNECT(nil)---------------->|
|<---------------------Ok(BYE)-----|
: :
|-CONNECT(swarm_b;LEECH;ChunkMap)->|
|<-----------------OK+PeerList-----|
: :
Figure 1: Example of a session for a extended PPSP-TP.
4.4. Extended Tracker Transaction State Machine
The tracker state machine introduced in the base tracker protocol
[I-D.ietf-ppsp-base-tracker-protocol] is now updated in this
specification to reflect the extensions introduced. An updated "per-
Peer-ID" transaction state machine (Figure 2) is described,
corresponding to the enhanced functionalities and control steps of
the extended tracker protocol. This extended "per-Peer-ID"
transaction state machine is compatible with the one specified in the
base tracker protocol.
Huang, et al. Expires July 28, 2014 [Page 7]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
+-----------+ +-------+ rcv CONNECT
(Transient) | TERMINATE | | START | --------------- (1)
+-----------+ +-------+ strt init timer
rcv STAT_REPORT ^ |
rcv FIND | |
rcv DISCONNECT | |
on registration error | v
on action error | +------------+
---------------- (A) +<-----| PEER | (Transient)
stop init timer | | REGISTERED |
snd error | +------------+
| |
| | process swarm actions
| | --------------------- (2)
on CONNECT Error (B) | | snd OK (PeerList)
on timeout (C) | / stop init timer
---------------- | / strt track timer
stop track timer | /
clean peer info | |
del registration | |
snd error (B) | |
| |
rcv CONNECT(@leave) | | rcv FIND
rcv DISCONNECT (nil) | | ----------------- (3)
--------------- (5) \ | ---- snd OK (PeerList)
snd OK response ---- \ | / \ rst tracker timer
/ \ \ | | |
rcv CONNECT | (4) | | | | |
----------- | v | v v | rcv STAT_REPORT
snd OK \ +-------------+ / --------------- (3)
rst track timer ----| TRACKING |---- snd OK response
+--------------+ rst track timer
Figure 2: Extended Per-Peer-ID Transaction State Machine
The state diagram in Figure 2 illustrates the complete state changes
together with the causing events and resulting actions when
implementing the extensions to the base tracker protocol. Note that
Specific error conditions are not shown in the state diagram.
4.4.1. Normal Operation
On normal operation the extended process consists of the following
steps:
1) This step is same step 1) in section 2.4.1 of the base tracker
protocol [I-D.ietf-ppsp-base-tracker-protocol].
Huang, et al. Expires July 28, 2014 [Page 8]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
2) This step is same step 2) in section 2.4.1 of the base tracker
protocol [I-D.ietf-ppsp-base-tracker-protocol].
3) This step is same step 3) in section 2.4.1 of the base tracker
protocol [I-D.ietf-ppsp-base-tracker-protocol], but with extended
scope in the FIND Request message and in the STAT_REPORT Request
message.
4) This step is same step 4) in section 2.4.1 of the base tracker
protocol [I-D.ietf-ppsp-base-tracker-protocol]
5) While TRACKING, a DISCONNECT message received from the peer, or a
CONNECT message with the action to leave the last swarm, the
tracker stops the "track timer", cleans the information associated
with the participation of the Peer-ID in the the swarm(s) joined,
responds with a successful condition, deletes the registration of
the Peer-ID and transitions to TERMINATED state for that Peer-ID.
4.4.2. Error Conditions
Peers MUST NOT generate protocol elements that are invalid.
However, several situations of a peer may lead to abnormal
conditions in the interaction with the tracker. The situations
may be related with peer malfunction or communications errors.
The tracker reacts to the abnormal situations depending on its
current state related to a Peer ID, as follows:
A) At PEER REGISTERED state, if the Peer ID is considered invalid (in
the case of a DISCONNECT requests received from an unregistered
Peer ID), the tracker responds with either error codes 401
Unauthorized or 403 Forbidden, transitions to TERMINATE state for
that Peer ID and the state machine is destroyed.
B) This step is the same step B) in section 2.4.2 of the base tracker
protocol [I-D.ietf-ppsp-base-tracker-protocol.
C) This step is the same step c) in section 2.4.2 of the base
tracker protocol [I-D.ietf-ppsp-base-tracker-protocol.
NOTE: These situations may correspond to a malfunction at the peer
or to malicious conditions. Therefore, as preventive measure, the
tracker proceeds to TERMINATE state for the Peer ID by de-
registering the peer and cleaning all peer information.
5 Extended Tracker Protocol Specification
5.1. Request/Response Syntax and Format
Huang, et al. Expires July 28, 2014 [Page 9]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
The architecture specified in the base tracker protocol [I-D.ietf-
ppsp-base-tracker-protocol] does not suffer any modification in the
extended protocol. The syntax is identical with some elements
extended to contain new optional attributes:
The SwarmID element MAY be present in DISCONNECT requests.
The element "ContentGroup" is added to the format of Request. It MAY
be present in requests referencing content, i.e., CONNECT and FIND,
if the request includes a content scope.
The extended semantics of the attributes and elements within a
PPSPTrackerProtocol root element is described in section 5.2.
Huang, et al. Expires July 28, 2014 [Page 10]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
5.2. Extended Semantics of PPSPTrackerProtocol Elements
The extension semantics of PPSPTrackerProtocol is a follows.
+----------------------+---------+----------------------------------+
| Element Name or | Use | Description |
| Attribute Name | | |
+----------------------+---------+----------------------------------+
| PPSPTrackerProtocol | 1 | The root element. |
| @version | M | Provides the version of PPSP-TP. |
| Request | 0...1 | Provides the request method |
| | | and MUST be present in Request. |
| Response | 0...1 | Provides the response method |
| | | and MUST be present in Response. |
| TransactionID | M | Root transaction Identification. |
| Result | 0...N | Result of @action MUST be present|
| | | in Responses. |
| @transactionID | CM | Identifier of the @action. |
| PeerID | 0...1 | Peer Identification. |
| | | MUST be present in Request. |
| SwarmID | 0...N | Swarm Identification. |
| | | MUST be present in Requests. |
| @action | CM | Must be set to JOIN or LEAVE. |
| @peerMode | CM | Mode of Peer participation in |
| | | the swarm, "LEECH" or "SEED". |
| @transactionID | CM | Identifier for the @action. |
| PeerNUM | 0...1 | Maximum peers to be received |
| | | with capabilities indicated. |
| @abilityNAT | CM | Type of NAT traversal peers, as |
| | | "No-NAT","STUN","TURN" or "PROXY"|
| @concurrentLinks| CM | Concurrent connectivity level of |
| | | peers, "HIGH", "LOW" or "NORMAL" |
| @onlineTime | CM | Availability or online duration |
| | | of peers, "HIGH" or "NORMAL" |
| @uploadBWlevel | CM | Upload bandwidth capability of |
| | | peers, "HIGH" or "NORMAL" |
| ContentGroup | 0...1 | Information on content (Table 4) |
| PeerGroup | 0...1 | Information on peers (Table 3) |
| StatisticsGroup | 0...1 | Statistic data (Table 5) |
+----------------------+---------+----------------------------------+
| Legend: |
| Use for attributes: M=Mandatory, OP=Optional, |
| CM=Conditionally Mandatory |
| Use for elements: minOccurs...maxOccurs (N=unbounded) |
| Elements are represented by their name (case-sensitive) |
| Attribute names (case-sensitive) are preceded with an @ |
+-------------------------------------------------------------------+
Table 1: Semantics of the Extended PPSPTrackerProtocol.
Huang, et al. Expires July 28, 2014 [Page 11]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
The semantics of PeerGroup element is almost identical with that of the
base tracker protocol.
+----------------------+---------+----------------------------------+
| Element Name or | Use | Description |
| Attribute Name | | |
+----------------------+---------+----------------------------------+
| PeerGroup | 0...1 | Contains description of peers. |
| PeerInfo | 1...N | Provides information on a peer. |
| @swarmID | 0...1 | Swarm Identification. |
| PeerID | 0...1 | Peer Identification. |
| | | MAY be present in responses. |
| PeerAddress | 0...N | IP Address information. |
| @addrType | M | Type of IP address, which can be |
| | | "ipv4" or "ipv6" |
| @priority | CM | The priority of this interface. |
| | | Used for NAT traversal. |
| @type | CM | Describes the address for NAT |
| | | traversal, which can be "HOST" |
| | | "REFLEXIVE" or "PROXY". |
| @connection | OP | Access type ("3G", "ADSL", etc.) |
| @asn | OP | Autonomous System number. |
| @ip | M | IP address value. |
| @port | M | IP service port value. |
| @peerProtocol | OP | PPSP Peer Protocol supported. |
+----------------------+---------+----------------------------------+
| Legend: |
| Use for attributes: M=Mandatory, OP=Optional, |
| CM=Conditionally Mandatory |
| Use for elements: minOccurs...maxOccurs (N=unbounded) |
| Elements are represented by their name (case-sensitive) |
| Attribute names (case-sensitive) are preceded with an @ |
+-------------------------------------------------------------------+
Table 2: Semantics of PeerGroup.
Table 3 describes the semantics of StatisticsGroup element, extended
with content information attributes.
+----------------------+---------+----------------------------------+
| Element Name or | Use | Description |
| Attribute Name | | |
+----------------------+---------+----------------------------------+
| StatisticsGroup | 0...1 | Provides statistic data on peer |
| | | and content. |
| Stat | 1...N | Groups statistics property data. |
| @property | M | The property to be reported |
| | | property values and elements |
| | | in Table 5 of [I-D.ietf-ppsp-base|
| | | -tracker-protocol] |
Huang, et al. Expires July 28, 2014 [Page 12]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
| ContentGroup | 0...1 | Information on content (Table 4) |
+----------------------+---------+----------------------------------+
| Legend: |
| Use for attributes: M=Mandatory, OP=Optional, |
| CM=Conditionally Mandatory |
| Use for elements: minOccurs...maxOccurs (N=unbounded) |
| Elements are represented by their name (case-sensitive) |
| Attribute names (case-sensitive) are preceded with an @ |
+-------------------------------------------------------------------+
Table 3: Semantics of StatisticsGroup.
Huang, et al. Expires July 28, 2014 [Page 13]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
ContentGroup is a new element. The semantics of this element is
described in Table 4.
+----------------------+---------+----------------------------------+
| Element Name or | Use | Description |
| Attribute Name | | |
+----------------------+---------+----------------------------------+
| ContentGroup | 0...1 | Provides information on content. |
| CAM | 1 | Describes the chunk addressing |
| | | method of this content. The value|
| | | is identical with the value of |
| | | Table 6 of [I-D.ietf-ppsp-peer |
| | | -protocol] |
| Representation | 1...N | Describes a component of content.|
| @id | M | Unique identifier for this |
| | | Representation. |
| SegmentInfo | 1 | Provides segment information. |
| @startIndex | M | The index of the first media |
| | | segment in the request scope for |
| | | this Representation. |
| @endIndex | OP | The index of the last media |
| | | segment in the request scope for |
| | | this Representation. |
+----------------------+---------+----------------------------------+
| Legend: |
| Use for attributes: M=Mandatory, OP=Optional, |
| CM=Conditionally Mandatory |
| Use for elements: minOccurs...maxOccurs (N=unbounded) |
| Elements are represented by their name (case-sensitive) |
| Attribute names (case-sensitive) are preceded with an @ |
+-------------------------------------------------------------------+
Table 4: Semantics of ContentGroup
The Representation element describes a component of a content
identified by its attribute @id in the Media Presentation Description
(MPD). This element MAY be present for each component desired in the
scope of the FIND or CONNECT requests. The scope of each
Representation is indicated by the SegmentInfo element and the
attributes @startIndex and, optionally, @endIndex.
Huang, et al. Expires July 28, 2014 [Page 14]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
5.3. Extended Request/Response Element in Request Messages
Table 5 specifies the valid string representations for the requests
extended in this specification to complement those define in the base
tracker protocol. These values MUST be treated as case-sensitive.
+----------------------+
| Extended XML Request |
| Methods String Values|
+----------------------+
| DISCONNECT |
+----------------------+
Table 5: Extended Valid Strings for Request Element of Requests.
The response elements in the extension are identical to those of the
base tracker protocol [I-D.ietf-ppsp-base-tracker-protocol].
5.4. Compatibility with the Base Tracker Protocol
Trackers are RECOMMENDED to implement extended tracker protocol to be
compatible with peers using base tracker protocol or peers using
extended tracker protocol. But it is not mandatory. When peers using
extended tracker protocol changes content information with a tracker
only supporting base tracker protocol, the tracker could directly
ignore the content related information, e.g. ContentGroup element and
Representation attribute. Peers implementing the extended tracker
protocol sending DISCONNECT message to legacy trackers will get
respond with 400 (Bad request, with reason-phrase "Unknown
Messages"), which indicate the messages could not be recognized by
the tracker. In this case, the peers MUST stop interacting with the
tracker in extended request messages and use the base tracker
protocol instead.
5.5. Negotiation of Chunk Addressing Methods
Multiple chunk addressing methods could be used in this document to
present content information. But only one of them MUST be used for
one swarm when a peer communicating with a tracker. Before peers
connect to a tracker, it MUST get the knowledge of the chunk
addressing methods supported by the tracker. How to get the
information is out of scope of the tracker protocol. It could be some
out-of-band methods. For example, the chunk addressing methods
supported by the tracker could be obtained from the web portal
together with other information of the tracker, e.g. IP address.
6. Request/Response Processing
Huang, et al. Expires July 28, 2014 [Page 15]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
6.1. Enhanced CONNECT Request
This method is used when a peer wants to join one or multiple swarms.
The tracker records the Peer-ID, connect-time, IP addresses and link
status.
The peer MUST properly form the XML message-body, set the Request
method to CONNECT, generate and set the TransactionID, and set the
PeerID with the identifier of the peer. The peer SHOULD also include
the IP addresses of its network interfaces in the CONNECT message.
Extended CONNECT request is retro-compatible with the CONNECT request
message defined in the base tracker protocol specification.
An example of the message-body of the extended CONNECT Request is the
following.
<?xml version="1.0" encoding="UTF-8"?>
<PPSPTrackerProtocol xmlns="TBD" schemaLocation="TBD" version="1.0">
<Request>CONNECT</Request>
<PeerID>656164657220</PeerID>
<TransactionID>12345.0</TransactionID>
<SwarmID action="JOIN" peerMode="LEECH"
transactionID="12345.1">1111</SwarmID>
<PeerNum abilityNAT="STUN"
concurrentLinks="HIGH"
onlineTime="NORMAL"
uploadBWlevel="NORMAL">5</PeerNum>
<ContentGroup>
<Representation id="tag0">
<SegmentInfo startIndex="20" />
</Representation>
<Representation id="tag6">
<SegmentInfo startIndex="20" />
</Representation>
</ContentGroup>
<PeerGroup>
<PeerInfo>
<PeerAddress addrType="ipv4" ip="192.0.2.1" port="80"
priority="1" />
<PeerAddress addrType="ipv6" ip="2001:db8::1" port="80"
priority="2"
type="HOST"
connection="ADSL" />
</PeerInfo>
</PeerGroup>
</PPSPTrackerProtocol>
Huang, et al. Expires July 28, 2014 [Page 16]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
In this example, the peer wants to participate in swarm 1111 to watch
the program as LEECH, and it also wishes to start from a specific
point of the content timeline. As such, the CONNECT request message
contains a ContentGroup element including the information to restrict
the search for peers in the swarm. The extended CONNECT request MAY
include a PeerNum element to indicate to the tracker the number of
peers to be returned in a list corresponding to the indicated
properties, being @abilityNAT for NAT traversal (considering that
PPSP-ICE NAT traversal techniques may be used), and optionally
@concurrentLinks, @onlineTime and @uploadBWlevel for the preferred
capabilities. In case PeerMode is LEECH, the tracker will search and
select a proper list of peers satisfying the conditions requested.
The peer list MUST contain the Peer-IDs and the corresponding IP
addresses. To create the peer list, the tracker may take peer status
and network location information into consideration, to express
network topology preference or operators' policy preferences, with
regard to the possibility of connecting with other IETF efforts such
as ALTO [I.D.ietf-alto-protocol]. Thus a PeerGroup MAY also be
needed in an extended CONNECT request messages.
The response MUST have the same TransactionID value as the request.
An example of a Response message for the extended CONNECT Request
from a leecher is the following:
<?xml version="1.0" encoding="UTF-8"?>
<PPSPTrackerProtocol xmlns="TBD" schemaLocation="TBD" version="1.0">
<Response>SUCCESSFUL</Response>
<TransactionID>12345</TransactionID>
<PeerGroup>
<PeerInfo>
<PeerID>656164657220</PeerID>
<PeerAddress addrType="ipv4" ip="198.51.100.1" port="80"
priority="1"
type="REFLEXIVE"
connection="3G"
asn="64496" />
</PeerInfo>
<PeerInfo>
<PeerID>956264622298</PeerID>
<PeerAddress addrType="ipv4" ip="198.51.100.22" port="80"
asn="64496" />
</PeerInfo>
<PeerInfo>
<PeerID>3332001256741</PeerID>
<PeerAddress addrType="ipv4" ip="198.51.100.201" port="80"
asn="64496" />
</PeerInfo>
</PeerGroup>
Huang, et al. Expires July 28, 2014 [Page 17]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
</PPSPTrackerProtocol>
6.2. Enhanced FIND Request
This method allows peers to request to the tracker, whenever needed,
a new peer list for the swarm for specific scope of chunks/segments
of a media content representation of that swarm.
The peer MUST properly form the XML message-body, set the request
method to FIND, set the PeerID with the identifier of the peer, set
the SwarmID with the identifier of the swarm the peer is interested
in. And optionally, in order to find peer having the specific
chunks/segments, the peer may include the ContentGroup element in the
JOIN request message to indicate a specific point in the content
timeline.
This message is mainly used for leechers to update the peer list. It
is unnecessary to set the PeerMode element in FIND request messages.
The peer MUST generate and set the TransactionID for the request.
An example of the message-body of a FIND Request is the following:
<?xml version="1.0" encoding="UTF-8"?>
<PPSPTrackerProtocol xmlns="TBD" schemaLocation="TBD" version="1.0">
<Request>FIND</Request>
<PeerID>656164657221</PeerID>
<SwarmID>1111</SwarmID>
<TransactionID>12345</TransactionID>
<PeerNum abilityNAT="STUN"
concurrentLinks="HIGH"
onlineTime="NORMAL"
uploadBWlevel="NORMAL">5</PeerNum>
<ContentGroup>
<Representation id="tag4">
<SegmentInfo startIndex="110" endIndex="150" />
</Representation>
</ContentGroup>
</PPSPTrackerProtocol>
The FIND request MAY include a PeerNum element to indicate to the
tracker the number of peers to be returned in a list corresponding to
the indicated properties, being @abilityNAT for NAT traversal
(considering that PPSP-ICE NAT traversal techniques may be used), and
optionally @concurrentLinks, @onlineTime and @uploadBWlevel for the
preferred capabilities.
In the case of a FIND with a specific scope of a stream content the
Huang, et al. Expires July 28, 2014 [Page 18]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
request SHOULD include a ContentGroup to specify the segment range of
content Representations.
When receiving a well-formed FIND Request the tracker processes the
information to check if it is valid. In case of success a response
message with a Response value of SUCCESSFUL will be generated and the
tracker will include the appropriate list of peers satisfying the
conditions requested. The peer list returned MUST contain the Peer-
IDs and the corresponding IP Addresses.
The tracker may take peer status and network location information
into consideration when selecting the peer list to return, to express
network topology preferences or Operators' policy preferences, with
regard to the possibility of connecting with other IETF efforts such
as ALTO [I.D.ietf-alto-protocol].
An example of a Response message for the FIND Request is:
<?xml version="1.0" encoding="UTF-8"?>
<PPSPTrackerProtocol xmlns="TBD" schemaLocation="TBD" version="1.0">
<Response>SUCCESSFUL</Response>
<TransactionID>12345</TransactionID>
<PeerGroup>
<PeerInfo>
<PeerID>956264622298</PeerID>
<PeerAddress addrType="ipv4" ip="198.51.100.22" port="80"
asn="64496" />
</PeerInfo>
<PeerInfo>
<PeerID>3332001256741</PeerID>
<PeerAddress addrType="ipv4" ip="198.51.100.201" port="80"
asn="64496" />
</PeerInfo>
</PeerGroup>
</PPSPTrackerProtocol>
The Response MUST include a PeerGroup with PeerInfo data that
includes the public IP address of the selected active peers in the
swarm.
The tracker MAY also include the attribute @asn with network location
information of the transport addresses of the peers, corresponding to
the Autonomous System Numbers of the access network provider of each
peer in the list.
The response MAY also include a PeerGroup with PeerInfo data that
includes the requesting peer public IP address. If STUN-like
function is enabled in the tracker, the PeerAddress includes the
Huang, et al. Expires July 28, 2014 [Page 19]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
attribute @type with a value of REFLEXIVE, corresponding to the
transport address "candidate" of the peer.
An example of a Response message for the FIND Request including the
requesting peer public IP address is the following:
<?xml version="1.0" encoding="UTF-8"?>
<PPSPTrackerProtocol xmlns="TBD" schemaLocation="TBD" version="1.0">
<Response>SUCCESSFUL</Response>
<TransactionID>12345</TransactionID>
<PeerGroup>
<PeerInfo>
<PeerID>656164657221</PeerID>
<PeerAddress addrType="ipv4" ip="198.51.100.1" port="80"
priority="1"
type="REFLEXIVE"
connection="3G"
asn="64496" />
</PeerInfo>
<PeerInfo>
<PeerID>956264622298</PeerID>
<PeerAddress addrType="ipv4" ip="198.51.100.22" port="80"
asn="64496" />
</PeerInfo>
<PeerInfo>
<PeerID>3332001256741</PeerID>
<PeerAddress addrType="ipv4" ip="198.51.100.201" port="80"
asn="64496" />
</PeerInfo>
</PeerGroup>
</PPSPTrackerProtocol>
6.3. Enhanced STAT_REPORT Request
This message still uses the specifications of the base tracker
protocol [I-D.ietf-ppsp-base-tracker-protocol]. The Stat element has
been extended with one property, "ContentMap", to allow peers
reporting map of chunks they have. The tracker would not have the
ability to treat the FIND requests for specific content chunks,
unless peers report this kind of information.
An example of the message-body of an enhanced STAT_REPORT request is
the following:
<?xml version="1.0" encoding="UTF-8"?>
<PPSPTrackerProtocol xmlns="TBD" schemaLocation="TBD" version="1.0">
<Request>STAT_REPORT</Request>
<PeerID>656164657221</PeerID>
Huang, et al. Expires July 28, 2014 [Page 20]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
<TransactionID>12345</TransactionID>
<StatisticsGroup>
<Stat property="StreamStatistics">
<SwarmID>1111</SwarmID>
<UploadedBytes>512</UploadedBytes>
<DownloadedBytes>768</DownloadedBytes>
<AvailBandwidth>1024000</AvailBandwidth>
</Stat>
<Stat property="StreamStatistics">
<SwarmID>2222</SwarmID>
<UploadedBytes>1024</UploadedBytes>
<DownloadedBytes>2048</DownloadedBytes>
<AvailBandwidth>512000</AvailBandwidth>
</Stat>
<Stat property="ContentMap">
<SwarmID>1111</SwarmID>
<Representation id="tag0">
<SegmentInfo startIndex="0" endIndex="24">
A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/....
</SegmentInfo>
</Representation>
<Representation id="tag1">
<SegmentInfo startIndex="0" endIndex="14">
A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/....
</SegmentInfo>
<SegmentInfo startIndex="20" endIndex="24">
A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/....
</SegmentInfo>
</Representation>
</Stat>
<Stat property="ContentMap">
<SwarmID>2222</SwarmID>
<Representation id="tag5">
<SegmentInfo startIndex="0" endIndex="4">
A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/....
</SegmentInfo>
</Representation>
<Representation id="tag6">
<SegmentInfo startIndex="0" endIndex="4">
A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/....
</SegmentInfo>
</Representation>
</Stat>
</StatisticsGroup>
</PPSPTrackerProtocol>
If the request is valid the tracker process the received information
for future use, and generates a response message with a Response
Huang, et al. Expires July 28, 2014 [Page 21]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
value of SUCCESSFUL.
The response MUST have the same TransactionID value as the request.
An example of a Response message for the START_REPORT Request is the
following:
<?xml version="1.0" encoding="UTF-8"?>
<PPSPTrackerProtocol xmlns="TBD" schemaLocation="TBD" version="1.0">
<Response>SUCCESSFUL</Response>
<TransactionID>12345</TransactionID>
</PPSPTrackerProtocol>
6.4. DISCONNECT Request
This method is used when the peer intends to leave the system and no
longer participate.
The tracker SHOULD delete the corresponding activity records related
with the peer in the corresponding swarms (including its status and
all content status).
The peer MUST properly form the XML message-body, set the Request
method to DISCONNECT, set the PeerID with the identifier of the peer,
randomly generate and set the TransactionID.
An example of the message-body of a DISCONNECT Request for the peer
leaving all joined swarms is the following:
<?xml version="1.0" encoding="UTF-8"?>
<PPSPTrackerProtocol xmlns="TBD" schemaLocation="TBD" version="1.0">
<Request>DISCONNECT</Request>
<PeerID>656164657221</PeerID>
<TransactionID>12345</TransactionID>
</PPSPTrackerProtocol>
An example of a Response message for the DISCONNECT Request is the
following:
<?xml version="1.0" encoding="UTF-8"?>
<PPSPTrackerProtocol xmlns="TBD" schemaLocation="TBD" version="1.0">
<Response>SUCCESSFUL</Response>
<TransactionID>12345</TransactionID>
<PPSPTrackerProtocol>
Huang, et al. Expires July 28, 2014 [Page 22]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
7. Error and Recovery Conditions
This document does not introduces any new error and recovery
conditions. The implementation of error treatment MUST refer to the
base tracker protocol specification [I-D.ietf-ppsp-base-tracker-
protocol].
8. Security Considerations
The extended tracker protocol proposed in this document introduces no
new security considerations beyond those described in the base
tracker protocol specification [I-D.ietf-ppsp-base-tracker-protocol].
9. IANA Considerations
There are presently no IANA considerations with this document.
10. Acknowledgments
The authors would like to thank many people for their help and
comments, particularly: Zhang Yunfei, Martin Stiemerling, Johan
Pouwelse and Arno Bakker.
The authors would also like to thank the people participating in the
EU FP7 project SARACEN (contract no. ICT-248474)
[refs.saracenwebpage] for contributions and feedback to this
document.
The views and conclusions contained herein are those of the authors
and should not be interpreted as necessarily representing the
official policies or endorsements, either expressed or implied, of
the SARACEN project or the European Commission.
Huang, et al. Expires July 28, 2014 [Page 23]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
11 References
11.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[ISO.8601.2004] International Organization for Standardization, "Data
elements and interchange formats - Information interchange
- Representation of dates and times", ISO Standard 8601,
December 2004.
11.2 Informative References
[RFC6972] Zhang, Y. and N. Zong, "Problem Statement and Requirements
of the Peer-to-Peer Streaming Protocol (PPSP)", RFC 6972,
July 2013..
[I-D.ietf-ppsp-base-tracker-protocol] Cruz, R., Nunes, M., Gu, Y.,
Xia, J., and J. Taveira, "PPSP Tracker Protocol-Base
Protocol (PPSP-TP/1.0)", draft-ietf-ppsp-base-tracker-
protocol-02 (work in progress), October 2013.
[I.D.ietf-alto-protocol] Alimi, R., Penno, R. and Y. Yang, "ALTO
Protocol", draft-ietf-alto-protocol-20, (work in
progress), October 2013.
[ISO.IEC.23009-1] ISO/IEC, "Information technology -- Dynamic
adaptive streaming over HTTP (DASH) -- Part 1: Media
presentation description and segment formats", ISO/IEC DIS
23009-1, Aug. 2011.
[refs.saracenwebpage] "SARACEN Project Website",
http://www.saracen-p2p.eu/.
Huang, et al. Expires July 28, 2014 [Page 24]
INTERNET DRAFT PPSP-TP/1.1 January 24, 2014
Authors' Addresses
Rui Santos Cruz
IST/INESC-ID/INOV
Phone: +351.939060939
Email: rui.cruz@ieee.org
Rachel Huang
Huawei
Phone: +86-25-56623633
EMail: rachel.huang@huawei.com
Ning Zong
Huawei
Phone: +86-25-56624760
EMail: zongning@huawei.com
Mario Serafim Nunes
INESC-ID/INOV
Rua Alves Redol, n.9
1000-029 LISBOA, Portugal
Phone: +351.213100256
Email: mario.nunes@inov.pt
Joao P. Taveira
IST/INOV
Email: joao.silva@inov.pt
Huang, et al. Expires July 28, 2014 [Page 25]