PPSP Rachel Huang INTERNET-DRAFT Huawei Intended Status: Standards Track Rui S. Cruz Expires: January 8, 2013 Mario S. Nunes IST/INESC-ID/INOV Joao P. Taveira IST/INOV July 8, 2012 PPSP Tracker Protocol--Extended Protocol (PPSP-TP/1.1) draft-huang-ppsp-extended-tracker-protocol-00 Abstract This document specifies the extended Peer-to-Peer Streaming Protocol - Tracker Protocol (PPSP-TP/1.1), a new extension protocol complementing the basic core messages and usages specified in PPSP=TP/1.0 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 PPSP-TP/1.0 to include new optional messages providing granular controls and usages in the communications between peer and tracker. The extension protocol is retro-compatible with PPSP-TP/1.0. 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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Huang, et al. Expires January 8, 2013 [Page 1] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 Copyright and License Notice Copyright (c) 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. PPSP-TP/1.1 Overview . . . . . . . . . . . . . . . . . . . . 4 3.1. Request Messages . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Enhanced Request Messages . . . . . . . . . . . . . . . 4 3.1.1.1 CONNECT . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1.2 STAT_REPORT . . . . . . . . . . . . . . . . . . . . 5 3.1.2. New Request Messages . . . . . . . . . . . . . . . . . 5 3.1.2.1. JOIN . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.2.2. DISCONNECT . . . . . . . . . . . . . . . . . . . . 6 3.1.2.3. FIND . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Extended Tracker Transaction State Machine . . . . . . . . 7 3.2.1. Normal Operation . . . . . . . . . . . . . . . . . . . 8 3.2.2. Error Conditions . . . . . . . . . . . . . . . . . . . 10 3.3. Extended Request/Response Syntax and Format . . . . . . . . 10 3.3.1. Extended Semantics of PPSPTrackerProtocol Elements . . 12 3.3.2. Extended Request/Response Element in Request Messages . 16 3.4. Compatibility with PPSP-TP/1.0 . . . . . . . . . . . . . . 16 4. Request/Response Processing . . . . . . . . . . . . . . . . . . 18 4.1. Enhanced CONNECT Request . . . . . . . . . . . . . . . . . 18 4.1.1 Registration CONNECT Request . . . . . . . . . . . . . . 18 4.1.2 Fast CONNECT Request . . . . . . . . . . . . . . . . . . 19 4.2. DISCONNECT Request . . . . . . . . . . . . . . . . . . . . 23 4.3. JOIN Request . . . . . . . . . . . . . . . . . . . . . . . 25 4.4. FIND Request . . . . . . . . . . . . . . . . . . . . . . . 28 4.5. Enhanced STAT_REPORT Request . . . . . . . . . . . . . . . 30 4.6. Error and Recovery Conditions . . . . . . . . . . . . . . . 32 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 33 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 33 Huang, et al. Expires January 8, 2013 [Page 2] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 33 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 8.1 Normative References . . . . . . . . . . . . . . . . . . . 34 8.2 Informative References . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Huang, et al. Expires January 8, 2013 [Page 3] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 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 [I-D.ietf-ppsp-problem-statement], PPSP- TP/1.0 specified in [I-D.cruz-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're mandatory messages covering most basic use cases and MUST be implemented in all PPSP-based streaming systems. This document specifies PPSP-TP/1.1 to complement the basic core messages and usages specified in [I-D.cruz-ppsp-base-tracker- protocol]. It extends PPSP-TP/1.0 to include some new optional messages for providing granular controls and usages in some dedicated scenarios. The extension protocol is retro-compatible with PPSP- TP/1.0. For a peer, it can implement either PPSP-TP/1.0 or PPSP- TP/1.1. For a tracker, it is recommended to implement PPSP-TP/1.1, which is also able to deal with the requests of PPSP-TP/1.0. 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 [I-D.ietf-ppsp-problem-statement] and [I-D.cruz-ppsp-base-tracker-protocol]. 3. PPSP-TP/1.1 Overview 3.1. Request Messages 3.1.1. Enhanced Request Messages In this section, the request messages specified in PPSP-TP/1.0 are extended to enable granular control and optional information delivery. 3.1.1.1 CONNECT Besides the semantics defined in PPSP-TP/1.0 specifications, the enhanced CONNECT Request message is also used when a peer registers in the tracker without simultaneously requesting additional actions to be carried upon successful registration. In such a case, the Huang, et al. Expires January 8, 2013 [Page 4] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 tracker records the Peer-ID, connect-time (referenced to the absolute time), peer IP addresses and link status, and waits for further requests from the peer. This message is also extended to allow a peer participating in some swarms as LEECH and simultaneously joining other swarms as SEED when it registers in the tracker. For example, a peer is a seeder of several certain contents that it generated, but it is also a consumer of a streaming program. For some reason the connectivity failed and it wants to reconnect from the point it was before. Then the enhanced CONNECT request message could satisfy this kind of usage. 3.1.1.2 STAT_REPORT The STAT_REPORT Request message is extended to allow 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 peer lists when peers request to the tracker for the peer lists of some specific contents. An example of a STAT_REPORT for multiple properties is illustrated in subsection 4.5. 3.1.2. New Request Messages Three new messages, listed in Table 1, are introduced in this section to extend those specified in PPSP-TP/1.0 [I-D.cruz-ppsp-base-tracker- protocol]. +---------------+ | PPSP Tracker | | Extension | | Req. Messages | +---------------+ | DISCONNECT | | JOIN | | FIND | +---------------+ Table 1: Extended Request Messages 3.1.2.1. JOIN The JOIN Request message is used for a peer to notify the tracker that it wishes to participate in a swarm. The tracker records the content availability, i.e., adds the peer to the peers list for the swarm. On receiving a JOIN message, the tracker first checks the PeerMode type and then decides the next step (more details are referred in section 4.3). Huang, et al. Expires January 8, 2013 [Page 5] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 A use case of this request message is showed in Figure 1. In this case, the seeder of a certain provider has already registered in a tracker through the CONNECT message. When it receives some "Start" activation signal for a program x, it could send the JOIN message to the connected tracker to join the swarm. When it receives another signal for joining another program y, it can send the JOIN message to the tracker to request for joining the other swarm, but remaining sharing the content for the first one. +-------------+ +---------+ | Peer Seeder | | Tracker | +-------------+ +---------+ | | Start->|--CONNECT -------------------->| |<--------------------------OK--| : : Start->|--JOIN x---------------------->| |<--------------------------OK--| : : Start->|--JOIN y---------------------->| |<--------------------------OK--| : : Figure 1: An Example of JOIN Request Message Usages 3.1.2.2. DISCONNECT The DISCONNECT Request message is used when the peer intends to no longer participate in a specific swarm, or in all swarms. When receiving the 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). Continuing the example in 3.1.1, when the newly joined program is no longer available, a "DISCONNECT z" message is sent by the seeder to indicate that it leaves swarm z. Note that this activity does not affect other swarms (swarm x, y). The seeder still maintains all the other swarms it participates in. Another use case is that this request message can be used to stop peer participation in all swarms and de-register from the system. In such a case, DISCONNECT message will have the same effect of timer expiring (from the tracker perspective), but providing a graceful disconnect from the system. 3.1.2.3. FIND The FIND Request message allows a peer to request the tracker for the Huang, et al. Expires January 8, 2013 [Page 6] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 peer list of a swarm. The request can include specific content scopes, either media content representations or specific chunks of a media representation in a swarm. On receiving a FIND message, the tracker finds the peers, listed in content status of the specified swarm that can satisfy the requesting peer's requirements, returning the list to the requesting peer. To create the peer list, the tracker may take peer status, capabilities and peers priority into consideration. Peer priority may be determined by network topology preference, operator policy preference, etc. This message can be used in scenarios when peers want to obtain the updated peer lists from the tracker. For example, when a peer acting as leech has joined a swarm, and after a while part of the content is not available in the previously known peers, it can send a FIND request message to the tracker to update the peer lists which could satisfy the peer's requirement. Another scenario could be found when a peer has changed its primary network attachment. One example is that a peer with a LAN and a WiFi interface which are going through different routers. The peer is using some P2P app which can keep working when the peer switch from the LAN to the WiFi (for example, unplugging the Ethernet cable, the P2P connection can recover automatically). In this case, the peer can send a FIND Request message to the tracker for the updated peer lists. And the response replied by the tracker to the FIND Request message should include the requesting peer transport address as well as the required peer list. 3.2. Extended Tracker Transaction State Machine The tracker state machine has been introduced in PPSP-TP/1.0 [I- D.cruz-ppsp-base-tracker-protocol]. Every tracker MUST keep a tracker state machine in which the state transitions are triggered by peer registrations. In addition to the tracker state machine, a transaction state machine for each registered Peer-ID is also specified. In this specification, as some additional granularity messages have been introduced, an extended "per-Peer-ID" transaction state machine (Figure 2) is specified to provide more functionality and detailed control to the tracker protocol. PPSP-TP/1.1 MUST include both "per-Peer-ID" transaction state machines to remain compatible with PPSP-TP/1.0. A Tracker implementing PPSP-TP/1.1 could instantiate corresponding "per-Peer-ID" transaction state machine based on the version of the CONNECT request message received from the peer. Huang, et al. Expires January 8, 2013 [Page 7] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 +-------+ rcv CONNECT(@) | START | --------------- (1) +-------+ [snd OK response] +-----------+ | strt init timer | TERMINATE | | +-----------+ | ---- rcv FIND ^ | / \ or rcv CONNECT(@) | | | (A) | rcv CONNECT rcv DISCONNECT (nil) | v v | or ---------------- (5) | +------------+ / rcv STAT_REPORT snd OK response | | PEER |-- --------------- stop track timer | | REGISTERED | snd error clean peer info | +------------+ rst init timer del registration | | ^ | | | | | rcv @action=join | | | | rcv JOIN on timeout | | | | ----------------- (2) ---------------- (C) | | | | snd OK (PeerList) clean peer info | / / / stop init timer del registration +<------- / / strt track timer | / / rcv DISCONNECT (x) | (6)/ / rcv FIND or JOIN ---------------- (6) | / / ----------------- (3) snd OK response \ / / ---- snd OK (PeerList) ---- \ | / / \ rst track timer / \ \ | | | | | | | | | | | rcv CONNECT(@) (7) rcv CONNECT(@)| (B) | | | | | | rcv STAT_REPORT (4) ----------- | v | | v v | rcv DISCONNECT (x) (4) snd error \ +--------------+ /------------------ rst track timer ----| TRACKING |---- snd OK response(4) +--------------+ rst track timer snd OK(PList)(7) 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 basic tracker protocol with extended protocol. Note that Specific error conditions are not shown in the state diagram. 3.2.1. Normal Operation On normal operation the extended process consists of the following steps: 1) When an enhanced CONNECT message is received from a peer, if Huang, et al. Expires January 8, 2013 [Page 8] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 successfully authenticated and validated, the tracker registers the Peer-ID and associated information (IP addresses). In case the CONNECT request also includes Swarm @action requests (using the same semantics of PPSP-TP/1.0), it removes to PEER REGISTERED state carrying the Swarm @action to be performed. In case the CONNECT request does not contain any Swarm @action requests, it sends the response of successful registration to peer ,starts the "init timer" and moves to PEER REGISTERED state. 2) While PEER REGISTERED, when a JOIN message or swarm @action="JOIN" request is received with valid swarm information, the tracker stops the "init timer", starts the "track timer" and sends the response of successful join to the peer. The response MAY contain the appropriate list of peers in the swarm, depending on PeerMode. A successful request in this state starts the TRACKING state associated with the peer-ID for the requested swarm. 3) While TRACKING, a JOIN or FIND message received with valid swarm information from the peer resets the "track timer" and is responded with a successful condition, either for the JOIN to (an additional) swarm or for including the appropriate list of peers for the scope in the FIND request. 4) While TRACKING, a DISCONNECT(x) message received from the peer, containing a valid x=Swarm-ID resets the "track timer" and is responded with a successful condition. The tracker cleans the information associated with the participation of the Peer-ID in the specified swarm(s). In TRACKING state a STAT_REPORT message received from the peer resets the "track timer" and is responded with a successful condition. The STAT_REPORT message MAY contain information related with Swarm-IDs to which the peer is joined. 5) From either PEER REGISTERED or TRACKING states a DISCONNECT(x) message received from the peer, where x=nil, 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. The same operations are performed if a CONNECT message including valid Swarm @action="LEAVE" requests (using the same semantics of PPSP- TP/1.0) is received while in TRACKING state (valid actions in Table 9). 6) From TRACKING state a DISCONNECT(x) message received from the peer, where x=ALL or x=Swarm-ID is the last swarm, the tracker stops the "track timer", cleans the information associated with Huang, et al. Expires January 8, 2013 [Page 9] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 the participation of the Peer-ID in the the swarm(s) joined, responds with a successful condition and transitions to PEER REGISTERED state. 7) While TRACKING, a CONNECT message received from the peer including a valid pair of Swarm @action requests (one being @action="LEAVE" and the other being @action="JOIN", using the same semantics of PPSP-TP/1.0), resets the "track timer" and is responded with a successful condition (valid actions in Table 9). For the @action="JOIN" the response to the request MAY include the appropriate list of peers. 3.2.2. Error Conditions A) At the PEER REGISTERED state (while the "init timer" has not expired) receiving FIND, CONNECT or STAT_REPORT messages from the peer is considered as an error condition. The tracker responds with error code 403 Forbidden, and resets the "init timer" one last time. B) At the TRACKING state (while the "track timer" has not expired) receiving an enhanced CONNECT message or swarm @action="JOIN" request from the peer is considered an error condition. The tracker responds with error code 403 Forbidden, and resets the "track timer". NOTE: This situation may correspond to a malfunction at the peer or to malicious conditions. A preventive measure would be to reset the "track timer" one last time and if no valid message is received proceed to TERMINATE state for the Peer-ID by de- registering the peer and cleaning all peer information. C) Without receiving messages from the peer, either from PEER REGISTERED sate (init timer) or TRACKING state (track timer), on timeout the tracker cleans all the information associated with the Peer-ID in all swarms it was joined, deletes the registration, and transitions to TERMINATE state for that Peer-ID. The same action is taken if no valid message is received at the PEER REGISTERED state after the last "init timer" expires. 3.3. Extended Request/Response Syntax and Format The architecture of PPSP-TP/1.1 is consistent with the architecture of the the basic tracker protocol specified in PPSP- TP/1.0 [I-D.cruz-ppsp-base-tracker-protocol]. It still uses the same two-layer architecture OF PPSP-TP/1.0. Besides that, the message syntax is identical with that used by PPSP-TP/1.0. Note that PPSP-TP/1.1 is compatible with all the syntax and formats of Huang, et al. Expires January 8, 2013 [Page 10] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 PPSP-TP/1.0. The difference is that some request/response syntax has been extended for PPSP-TP/1.1 to contain the new optional messages. This section extends the generic format of Request to satisfy the extended request messages. The extended generic format of a Request is the following: The generic format of a Response is the following: The version of PPSPTrackerProtocol has been changed to 1.1 which indicates that the peer is using extended tracker protocol (PPSP- TP/1.1). Besides that, syntax of some elements has been extended for three extended request messages. The SwarmID element MUST be present in FIND, JOIN and DISCONNECT requests. The PeerNum element MAY be present in JOIN and FIND requests and MAY contain the attribute @abilityNAT to inform the tracker on the preferred type of peers, in what concerns their NAT traversal situation, to be returned in a peer list. The PeerGroup element MUST be present in CONNECT requests and Huang, et al. Expires January 8, 2013 [Page 11] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 responses and MAY be present in responses to JOIN and FIND requests if the corresponding response returns information about peers. One element "ContentGroup" is added to the format of Request. It MAY be present in requests referencing content, i.e., JOIN 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 subsection 3.3.1. 3.3.1. Extended Semantics of PPSPTrackerProtocol Elements Some of the semantics defined in the PPSP-TP/1.0 MUST be extended for PPSP-TP/1.1. The extension semantics of PPSPTrackerProtocol elements are described in bellow. +----------------------+---------+----------------------------------+ | 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" | Huang, et al. Expires January 8, 2013 [Page 12] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 | PeerGroup | 0...1 | Information on peers (Table 3) | | ContentGroup | 0...1 | Provides information on content. | | | | More details in Table 4 | | StatisticsGroup | 0...1 | Statistic data of peer. | | | | More details in 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 2: Semantics of the Extended PPSPTrackerProtocol. The semantics of PeerGroup element is almost identical with that in PPSP-TP/1.0. It is listed below for convenience of reading. The implementation of this element has been extended in this specification, which is described in 4.3. +----------------------+---------+----------------------------------+ | 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 | 1...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. | +----------------------+---------+----------------------------------+ | 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 @ | Huang, et al. Expires January 8, 2013 [Page 13] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 +-------------------------------------------------------------------+ Table 3: Semantics of PeerGroup. Table 4 describes the semantics of StatisticsGroup element. +----------------------+---------+----------------------------------+ | 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 in Table 5. | | SwarmID | 0...1 | Swarm Identification. | | UploadedBytes | 0...1 | Bytes sent to swarm. | | DownloadedBytes | 0...1 | Bytes received from swarm. | | AvailBandwidth | 0...1 | Upstream Bandwidth available. | | Representation | 0...N | Describes a component of content.| | @id | CM | Unique identifier for this | | | | Representation. | | SegmentInfo | 1...N | Provides segment information by | | | | segment range. The chunkmap can | | | | be encoded in Base64 [RFC4648]. | | @startIndex | CM | The index of the first media | | | | segment in the chunkmap report | | | | for this Representation. | | @endIndex | CM | The index of the last media | | | | segment in the chunkmap report | | | | for this Representation. | | @chunkmapSize| CM | Size of chunkmap reported. | +----------------------+---------+----------------------------------+ | 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 StatisticsGroup. +-------------------+-------------------------------------+ | @property | Description | +-------------------+-------------------------------------+ | StreamStatistics | Stream statistic values per SwarmID | Huang, et al. Expires January 8, 2013 [Page 14] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 | ContentMap | Reports map of chunks the peer has | | | per Representation of the content | +-------------------+-------------------------------------+ Table 5: StatisticsGroup Default Stat @property Values. ContentGroup is a new element extended in this specification. The semantics of this element is described in Table 6. +----------------------+---------+----------------------------------+ | Element Name or | Use | Description | | Attribute Name | | | +----------------------+---------+----------------------------------+ | ContentGroup | 0...1 | Provides information on content. | | 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 6: Semantics of ContentGroup The Representation element describes a component of a content identified by its attribute @id in the MPD. This element MAY be present for each component desired in the scope of the JOIN or FIND request. The scope of each Representation is indicated in the SegmentInfo element by the attribute @startIndex and, optionally, @endIndex. The peer may use this information in JOIN or FIND requests, for example, to join a swarm starting from a specific point (as is the case of a live program, by specifying the adequate @startIndex) and/or find adequate peers in the swarm for that content scope. An example of on-demand usage is the case of an end-user that Huang, et al. Expires January 8, 2013 [Page 15] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 previously watched a content with a certain audio language, then interrupted for a while (having disconnected) and later continued by re-joining from that point onwards but selecting a different available audio language. In this case the JOIN request would specify the required Representations and the @startIndex for each, i.e., all the adequate video components and the selected audio component. An example is illustrated in subsection 4.3. 3.3.2. Extended Request/Response Element in Request Messages Table 7 specifies the valid string representations for the requests in PPSP-TP/1.1. These values MUST be treated as case-sensitive. +----------------------+ | Extended XML Request | | Methods String Values| +----------------------+ | CONNECT | | DISCONNECT | | JOIN | | FIND | | STAT_REPORT | +----------------------+ Table 7: Extended Valid Strings for Request Element of Requests. The response elements in response messages of PPSP-TP/1.1 are identical with those specified in PPSP-TP/1.0, which can be found in subsection 7.2.3 of [I-D.cruz-ppsp-base-tracker-protocol]. 3.4. Compatibility with PPSP-TP/1.0 Peers and trackers may implement different versions of PPSP tracker protocol. Table 8 illustrate the different conditions when peer and tracker have different PPSP-TP versions. Huang, et al. Expires January 8, 2013 [Page 16] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 +---------+---------+---------+----------+ | Peer | Tracker | Request | Response | | Version | Version | Version | Version | +---------+---------+---------+----------+ | 1.0 | 1.0 | 1.0 | 1.0 | +---------+---------+---------+----------+ | 1.0 | 1.1 | 1.0 | 1.0 | +---------+---------+---------+----------+ | | | 1.1 | invalid | | 1.1 | 1.0 |---------+----------| | | | 1.0 | 1.0 | +---------+---------+---------+----------+ | 1.1 | 1.1 | 1.1 | 1.1 | +---------+---------+---------+----------+ Table 8: The Implementations of Different PPSP-TP Versions Just as Table 8 shows, when both peer and tracker implement PPSP- TP/1.0, all the requests and responses are processed based on semantics and schema of PPSP-TP/1.0. When peer implements PPSP-TP/1.0 and tracker implements PPSP-TP/1.1, the peer sends CONNECT 1.0 and tracker responds with the semantics and version of PPSP-TP/1.0. When peer implements PPSP-TP/1.1 and tracker implements PPSP-TP/1.0, the peer sends CONNECT 1.1 and tracker will respond with 400 (Bad request, with reason-phrase "PPSP version 1.0") to indicate that the peer has sent the invalid version of the request. After the peer receives the response with 400, it MUST send CONNECT 1.0 to be retro- compatible with the tracker implementing PPSP-TP/1.0. When both peer and tracker implement PPSP- TP/1.1, peer may use an advanced CONNECT 1.1 with the semantics, rules and restrictions similar to the PPSP- TP/1.0 to switch channels, re-connect after a failure or use an advanced CONNECT 1.1 to register first and then wait for all other messages to perform other steps, such as JOIN, FIND, etc. Huang, et al. Expires January 8, 2013 [Page 17] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 4. Request/Response Processing 4.1. Enhanced CONNECT Request This method is used when a peer registers to the system. 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. The enhanced CONNECT Request has two variants: a registration CONNECT Request and a fast CONNECT request (retro-compatible with PPSP- TP/1.0). 4.1.1 Registration CONNECT Request An example of the message-body of a registration CONNECT Request is the following: CONNECT 656164657221 12345 When receiving a well-formed CONNECT Request message, the tracker will first processes the peer authentication information (provided as Authorization scheme and token in the HTTP message) to check whether it is valid and that it can connect to the service, and then proceed to register the peer in the service. In case of success a Response message with a corresponding response value of SUCCESSFUL will be generated. Huang, et al. Expires January 8, 2013 [Page 18] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 The element PeerInfo MAY contain multiple PeerAddress child elements with attributes @addrType, @ip, and @port, and optionally @priority and @type (if PPSP-ICE NAT traversal techniques are used) corresponding to each of the network interfaces of the peer. If STUN-like function is enabled in the tracker, the response MAY include the peer reflexive address (public transport address "candidate" of the peer). The response to the registration CONNECT request MUST have the same TransactionID value as the request. An example of a Response message for the CONNECT Request is the following: SUCCESSFUL 12345 The Response MUST include a PeerGroup with PeerInfo data that includes the peer public IP address. If STUN-like function is enabled in the tracker, the PeerAddress includes the attribute @type with a value of REFLEXIVE, corresponding to the transport address "candidate" of the peer. The tracker MAY also include the attribute @asn with network location information of the transport address, corresponding to the Autonomous System Number of the access network provider. 4.1.2 Fast CONNECT Request Fast CONNECT request is retro-compatible with the CONNECT request message defined in PPSP-TP/1.0 specification. An example of the message-body of the fast CONNECT Request is the following. This example is identical with PPSP-TP/1.0. Huang, et al. Expires January 8, 2013 [Page 19] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 CONNECT 656164657220 1111 2222 12345.0 Another example of fast CONNECT request usage is showed in below: CONNECT 656164657220 1111 2222 3333 12345.0 Huang, et al. Expires January 8, 2013 [Page 20] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 In this example, the peer wants to participate in swarm 3333 to watch the program as a leecher, and meanwhile it also has 2 programs, swarm 1111 and swarm 2222, to share with other peers as a seeder. It is possible to simultaneously participate in multiple swarms as LEECH. In some cases, the peer has finished watching several programs and it may not have all the chunks of all the representations of the contents it had. But it may wish to continue sharing these programs with other peers. As such, a fast CONNECT request message could involve some @action="JOIN" in LEECH mode and some in SEED mode. +--------+-----------+---------+----------+----------+----------+ |SwarmID | @peerMode | @action | Initial | Final | Request | |Elements| value | value | State | State | validity | +--------+-----------+---------+----------+----------+----------| | 1 | LEECH | JOIN | START | TRACKING | Valid | +--------+-----------+---------+----------+----------+----------+ | 1 | LEECH | LEAVE | START | TERMINATE| Invalid | +--------+-----------+---------+----------+----------+----------+ | 1 | LEECH | LEAVE | TRACKING | TERMINATE| Valid | +--------+-----------+---------+----------+----------+----------+ | 1 | LEECH | JOIN | START | TERMINATE| Invalid | | 1 | LEECH | LEAVE | | | | +--------+-----------+---------+----------+----------+----------+ | 1 | LEECH | JOIN | TRACKING | TRACKING | Valid | | 1 | LEECH | LEAVE | | | | +--------+-----------+---------+----------+----------+----------+ | x | LEECH | JOIN | START | TRACKING | Valid | | y | SEED | JOIN | | | | +--------+-----------+---------+----------+----------+----------+ | N | SEED | JOIN | START | TRACKING | Valid | +--------+-----------+---------+----------+----------+----------+ | N | SEED | JOIN | TRACKING | TERMINATE| Invalid | +--------+-----------+---------+----------+----------+----------+ | N | SEED | LEAVE | TRACKING | TERMINATE| Valid | +--------+-----------+---------+----------+----------+----------+ Table 9: Validity of SwarmID @action combinations in CONNECT Request In Table 9, the valid sets of SwarmID @action combinations is extended for the fast CONNECT Request logic in PPSP-TP/1.1 (referring to the "per-peer-ID" transaction state machine). The allowed number of SwarmID elements in a request is indicated, where x, y and N take values greater or equal to 1. When N is indicated, it means that if N requests are @action="JOIN" for the named swarms, the sameN requests MUST be used for the corresponding @action="LEAVE" of the same swarms when using the fast CONNECT Request logic. Huang, et al. Expires January 8, 2013 [Page 21] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 The response MUST have the same TransactionID values as the corresponding request and actions. The Response to the Fast CONNECT Request MUST include a PeerGroup with PeerInfo data of the requesting peer public IP address. If STUN-like function is enabled in the tracker, the PeerAddress includes the attribute @type with a value of REFLEXIVE, corresponding to the transport address "candidate" of the peer. The PeerGroup MAY also include PeerInfo data corresponding to the Peer-IDs and public IP addresses of the selected active peers in the requested swarm. The tracker MAY also include the attribute @asn with network location information of the transport address, corresponding to the Autonomous System Number of the access network provider. In case the @peerMode is SEED, the tracker responds with a SUCCESSFUL response and enters the peer information into the corresponding swarm activity. In case the @peerMode is LEECH the tracker will search and select an appropriate list of peers satisfying the conditions set by the requesting peer. The peer list returned 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 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 CONNECT Request from a peer leecher is the following: SUCCESSFUL 200 OK 200 OK 200 OK 656164657221 956264622298 3332001256741 4.2. DISCONNECT Request This method is used when the peer intends to leave one or multiple specific swarms, or 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 and include the SwarmID information. The element SwarmID MUST be present with cardinality 1 to N, each containing no child elements. The SwarmID value MUST be either specific Swarm-ID the peer had previously joined, the value "ALL" to designate all joined swarms, or the value "nil" to completely disconnect from the system. An example of the message-body of a DISCONNECT Request for the peer leaving all joined swarms is the following: DISCONNECT 656164657221 ALL Huang, et al. Expires January 8, 2013 [Page 23] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 12345 An example of the message-body of a DISCONNECT Request for a peer seeder leaving several specific swarms is the following: DISCONNECT 656164657220 1111 2222 12345.0 In case of success a Response message with a corresponding response value of SUCCESSFUL will be generated. The response MUST have the same TransactionID value as the request. Upon receiving a DISCONNECT message, the tracker cleans the information associated with the participation of the Peer-ID in the specified swarms (or in all swarms). An example of a Response message for the first DISCONNECT Request is the following: SUCCESSFUL 12345 An example of a Response message for the second DISCONNECT Request is the following: SUCCESSFUL 12345 200 OK 200 OK Huang, et al. Expires January 8, 2013 [Page 24] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 200 OK If the scope of SwarmID in the DISCONNECT request is "nil", the tracker will also delete the registration of the Peer-ID. 4.3. JOIN Request This method is used for peers to notify the tracker that they wish to participate in a particular swarm. The JOIN message is used when the peer has none or just some chunks (LEECH), or has all the chunks (SEED) of a content. The JOIN is used for both on-demand or Live streaming modes. The peer MUST properly form the XML message-body, set the Request method to JOIN, set the PeerID with the identifier of the peer, set the SwarmID with the identifier of the swarm it is interested in, and randomly generate and set the TransactionID. A peer seeder may send the JOIN message to participate in several swarms. In such a case, the ContentGroup element MUST NOT be included in the request message. The PeerMode element SHOULD be set to SEED. An example of the message-body of a JOIN Request for a peer seeder joining two swarms is the following: JOIN 656164657221 12345.0 1111 2222 When receiving a well-formed JOIN Request the tracker processes the information to check if it is valid and if the peer can join the swarm of interest. In case of success a response message with a Response value of SUCCESSFUL will be generated and the tracker enters the peer information into the corresponding swarm activity. In case the PeerMode is SEED, the tracker just responds with a SUCCESSFUL response and enters the peer information into the corresponding swarm activity. Huang, et al. Expires January 8, 2013 [Page 25] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 The response MUST have the same TransactionID value as the request. An example of a Response message for the above JOIN Request is: SUCCESSFUL 200 OK 200 OK 200 OK As a leecher, the peer can participate in only one swarm at a time. In this case, the JOIN request message may include the ContentGroup element to indicate a specific point in the stream. The PeerMode element SHOULD be set to SEED. An example of the message-body of a JOIN Request for a peer leecher is the following: JOIN 656164657220 12345 1111 5 The JOIN request MAY include a PeerNum element to indicate to the tracker the number of peers to be returned in a list corresponding to Huang, et al. Expires January 8, 2013 [Page 26] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 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 JOIN to a specific point in a stream the request SHOULD include a ContentGroup to specify the joining point in terms of content Representations. The above example of a JOIN request would be for the case of an end-user that previously watched a content with a certain audio language, then interrupted for a while (having disconnected) and later continued by re-joining from that point onwards but selecting a different available audio language. In case the PeerMode is LEECH the tracker will search and select an appropriate 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 preferences or Operators' policy preferences, with regard to the possibility of connecting with other IETF efforts such as ALTO [I.D.ietf-alto-protocol]. The response MUST have the same TransactionID value as the request. An example of a Response message for the JOIN Request from a leecher is: SUCCESSFUL 12345 956264622298 3332001256741 The Response MUST include a PeerGroup with PeerInfo data that Huang, et al. Expires January 8, 2013 [Page 27] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 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. 4.4. FIND Request This method allows peers to request to the tracker, whenever needed, a new peer list for the swarm or for specific scope of chunks 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, the peer also may include information about the content in the JOIN request message. This message is mainly used for leechers to update the peer list. It is unnecessary to set the PeerMode element in JOIN 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: FIND 656164657221 1111 12345 5 The FIND request MAY include a PeerNum element to indicate to the Huang, et al. Expires January 8, 2013 [Page 28] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 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 request SHOULD include a ContentGroup to specify the content Representations segment range of interest. 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 the following: SUCCESSFUL 12345 956264622298 3332001256741 The Response MUST include a PeerGroup with PeerInfo data that includes the public IP address of the selected active peers in the Huang, et al. Expires January 8, 2013 [Page 29] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 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 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: SUCCESSFUL 12345 656164657221 956264622298 3332001256741 4.5. Enhanced STAT_REPORT Request This message still uses the specifications of PPSP-TP/1.0 defined in [I-D.cruz-ppsp-base-tracker-protocol]. The Stat element has Huang, et al. Expires January 8, 2013 [Page 30] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 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 and JOIN requests for specific content chunks, unless peers report this kind of information. Examples are provided below. An example of the message-body of an enhanced STAT_REPORT request is the following: STAT_REPORT 656164657221 12345 1111 512 768 1024000 2222 1024 2048 512000 1111 A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/.... A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/.... A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/.... Huang, et al. Expires January 8, 2013 [Page 31] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 2222 A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/.... A/8D/wP/A/8D/wP/A/8D/wP/A/8D/wP/.... If the request is valid the tracker process the received information for future use, and generates a response message with a Response 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: SUCCESSFUL 12345 4.6. Error and Recovery Conditions This document does not introduce any new error and recovery conditions. The implementation of error treatment MUST refer to PPSP-TP-1.0 specification [I-D.cruz-ppsp-base-tracker-protocol], subsection 8.6. Huang, et al. Expires January 8, 2013 [Page 32] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 5. Security Considerations The PPSP-TP/1.1 proposed in this document introduces no new security considerations beyond those described in PPSP-TP/1.0 specification [I-D.cruz-ppsp-base-tracker-protocol]. 6. IANA Considerations There are presently no IANA considerations with this document. 7. Acknowledgments The authors would like to thank many people for their help and comments, particularly: Zhang Yunfei, Zong Ning, 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 January 8, 2013 [Page 33] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 8 References 8.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. 8.2 Informative References [I-D.ietf-ppsp-problem-statement] Zhang, Y., Zong, N., Camarillo, G., Seng, J., and Y. Yang, "Problem Statement of P2P Streaming Protocol (PPSP)", draft-ietf-ppsp-problem-statement-09 (work in progress), November 2011. [I-D.cruz-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-cruz-ppsp-base-tracker- protocol-00 (work in progress), June 2011. [I.D.ietf-alto-protocol] Alimi, R., Penno, R., Yang, Y., "ALTO Protocol", draft-ietf-alto-protocol-11, (work in progress), March 2012. [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 January 8, 2013 [Page 34] INTERNET DRAFT PPSP-TP/1.1 July 8, 2012 Authors' Addresses Rachel Huang Huawei Phone: +86-25-56623633 EMail: rachel.huang@huawei.com Rui Santos Cruz IST/INESC-ID/INOV Phone: +351.939060939 Email: rui.cruz@ieee.org Mario Serafim Nunes IST/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 January 8, 2013 [Page 35]