diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc7846.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc7846.txt')
| -rw-r--r-- | doc/rfc/rfc7846.txt | 3083 |
1 files changed, 3083 insertions, 0 deletions
diff --git a/doc/rfc/rfc7846.txt b/doc/rfc/rfc7846.txt new file mode 100644 index 0000000..bd202bb --- /dev/null +++ b/doc/rfc/rfc7846.txt @@ -0,0 +1,3083 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Cruz +Request for Comments: 7846 M. Nunes +Category: Standards Track IST/INESC-ID/INOV +ISSN: 2070-1721 J. Xia + R. Huang, Ed. + Huawei + J. Taveira + IST/INOV + D. Lingli + China Mobile + May 2016 + + + Peer-to-Peer Streaming Tracker Protocol (PPSTP) + +Abstract + + This document specifies the base Peer-to-Peer Streaming Tracker + Protocol (PPSTP) version 1, an application-layer control (signaling) + protocol for the exchange of meta information between trackers and + peers. The specification outlines the architecture of the protocol + and its functionality; it also describes message flows, message + processing instructions, message formats, formal syntax, and + semantics. The PPSTP enables cooperating peers to form content- + streaming overlay networks to support near real-time delivery of + structured media content (audio, video, and associated timed text and + metadata), such as adaptive multi-rate, layered (scalable), and + multi-view (3D) videos in live, time-shifted, and on-demand modes. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7846. + + + + + + + + + +Cruz, et al. Standards Track [Page 1] + +RFC 7846 PPSTP May 2016 + + +Copyright Notice + + Copyright (c) 2016 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 + 1.1. Terminology ................................................4 + 1.2. Design Overview ............................................6 + 1.2.1. Typical PPSP Session ................................7 + 1.2.2. Example of a PPSP Session ...........................7 + 2. Protocol Architecture and Functional View ......................10 + 2.1. Messaging Model ...........................................10 + 2.2. Request/Response Model ....................................10 + 2.3. State Machines and Flows of the Protocol ..................12 + 2.3.1. Normal Operation ...................................14 + 2.3.2. Error Conditions ...................................15 + 3. Protocol Specification .........................................16 + 3.1. Presentation Language .....................................16 + 3.2. Resource Element Types ....................................16 + 3.2.1. Version ............................................16 + 3.2.2. Peer Number Element ................................17 + 3.2.3. Swarm Action Element ...............................18 + 3.2.4. Peer Information Elements ..........................18 + 3.2.5. Statistics and Status Information Element ..........20 + 3.3. Requests and Responses ....................................21 + 3.3.1. Request Types ......................................21 + 3.3.2. Response Types .....................................21 + 3.3.3. Request Element ....................................22 + 3.3.4. Response Element ...................................23 + 3.4. PPSTP Message Element .....................................24 + 4. Protocol Specification: Encoding and Operation .................24 + 4.1. Requests and Responses ....................................25 + 4.1.1. CONNECT Request ....................................25 + 4.1.1.1. Example ...................................28 + 4.1.2. FIND Request .......................................32 + 4.1.2.1. Example ...................................33 + + + +Cruz, et al. Standards Track [Page 2] + +RFC 7846 PPSTP May 2016 + + + 4.1.3. STAT_REPORT Request ................................34 + 4.1.3.1. Example ...................................35 + 4.2. Response Element in Response Messages .....................36 + 4.3. Error and Recovery Conditions .............................37 + 4.4. Parsing of Unknown Fields in message-body .................38 + 5. Operations and Manageability ...................................38 + 5.1. Operational Considerations ................................38 + 5.1.1. Installation and Initial Setup .....................38 + 5.1.2. Migration Path .....................................39 + 5.1.3. Requirements on Other Protocols and + Functional Components ..............................39 + 5.1.4. Impact on Network Operation ........................39 + 5.1.5. Verifying Correct Operation ........................40 + 5.2. Management Considerations .................................40 + 5.2.1. Interoperability ...................................40 + 5.2.2. Management Information .............................40 + 5.2.3. Fault Management ...................................41 + 5.2.4. Configuration Management ...........................41 + 5.2.5. Accounting Management ..............................41 + 5.2.6. Performance Management .............................41 + 5.2.7. Security Management ................................41 + 6. Security Considerations ........................................42 + 6.1. Authentication between Tracker and Peers ..................42 + 6.2. Content Integrity Protection against Polluting + Peers/Trackers ............................................43 + 6.3. Residual Attacks and Mitigation ...........................43 + 6.4. Pro-incentive Parameter Trustfulness ......................44 + 6.5. Privacy for Peers .........................................44 + 7. Guidelines for Extending PPSTP .................................45 + 7.1. Forms of PPSTP Extension ..................................45 + 7.2. Issues to Be Addressed in PPSTP Extensions ................47 + 8. IANA Considerations ............................................48 + 8.1. MIME Type Registry ........................................48 + 8.2. PPSTP Version Number Registry .............................49 + 8.3. PPSTP Request Type Registry ...............................49 + 8.4. PPSTP Error Code Registry .................................50 + 9. References .....................................................51 + 9.1. Normative References ......................................51 + 9.2. Informative References ....................................53 + Acknowledgments ...................................................54 + Authors' Addresses ................................................55 + + + + + + + + + + +Cruz, et al. Standards Track [Page 3] + +RFC 7846 PPSTP May 2016 + + +1. Introduction + + The Peer-to-Peer Streaming Protocol (PPSP) is composed of two + protocols: the Tracker Protocol (defined in this document) and the + Peer Protocol (defined in [RFC7574]). [RFC6972] specifies that the + Tracker Protocol should standardize the messages between PPSP peers + and PPSP trackers and also defines the requirements. + + The Peer-to-Peer Streaming Tracker Protocol (PPSTP) provides + communication between trackers and peers by which peers send meta + information to trackers, report streaming status, and obtain peer + lists from trackers. + + The PPSP architecture requires PPSP peers to be able to communicate + with a tracker in order to participate in a particular streaming + content swarm. This centralized tracker service is used by PPSP + peers for acquisition of peer lists. + + The signaling and the media data transfer between PPSP peers is not + in the scope of this specification. + + This document introduces a base Peer-to-Peer Streaming Tracker + Protocol (PPSTP) that satisfies the requirements in [RFC6972]. + +1.1. 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 [RFC2119]. + + absolute time: Expressed as ISO 8601 timestamps, using zero UTC + offset. Fractions of a second may be indicated, for example, + December 25, 2010 at 14h56 and 20.25 seconds in basic format is + 20101225T145620.25Z and in extended format is + 2010-12-25T14:56:20.25Z. + + chunk: An uniformly atomic subset of the resource that constitutes + the basic unit of data organized in P2P streaming for storage, + scheduling, advertisement, and exchange among peers. + + chunk ID: A unique resource identifier for a chunk. The identifier + type depends on the addressing scheme used, i.e., an integer, an + HTTP-URL, and possibly a byte-range. The identifier type is + described in the Media Presentation Description (MPD). + + LEECH: The peers in a swarm that download content from other peers as + well as contribute downloaded content with others. A LEECH should + join the swarm with uncompleted media content. + + + +Cruz, et al. Standards Track [Page 4] + +RFC 7846 PPSTP May 2016 + + + MPD (Media Presentation Description): Formalized description for a + media presentation, i.e., describes the structure of the media, + namely, the representations, the codecs used, the chunks, and the + corresponding addressing scheme. + + peer: A participant in a P2P streaming system that not only receives + streaming content, but also caches and streams streaming content + to other participants. + + peer ID: The identifier of a peer such that other peers, or the + Tracker, can refer to the peer using its ID. The peer ID is + mandatory, can take the form of a universally unique identifier + (UUID), defined in [RFC4122], and can be bound to a network + address of the peer, i.e., an IP address or a uniform resource + identifier/locator (URI/URL) that uniquely identifies the + corresponding peer in the network. The peer ID and any required + security certificates are obtained from an offline enrollment + server. + + peer list: A list of peers that are in the same swarm maintained by + the tracker. A peer can fetch the peer list of a swarm from the + tracker. + + PPSP: The abbreviation of Peer-to-Peer Streaming Protocol. + + PPSTP: The abbreviation of Peer-to-Peer Streaming Tracker Protocol. + + SEEDER: The peers in a swarm that only contribute the content they + have to others. A SEEDER should join the swarm with complete + media content. + + service portal: A logical entity typically used for client enrollment + and for publishing, searching, and retrieving content information. + It is usually located in a server of a content provider. + + swarm: A group of peers that exchange data to distribute chunks of + the same content (e.g., video/audio program, digital file, etc.) + at a given time. + + swarm ID: The identifier of a swarm containing a group of peers + sharing common streaming content. The swarm ID may use a + universally unique identifier (UUID), e.g., a 64- or 128-bit datum + to refer to the content resource being shared among peers. + + tracker: A directory service that maintains a list of peers + participating in a specific audio/video channel or in the + distribution of a streaming file. It is a logical component that + can be deployed in a centralized or distributed way. + + + +Cruz, et al. Standards Track [Page 5] + +RFC 7846 PPSTP May 2016 + + + transaction ID: The identifier of a request from the peer to the + tracker. It is used to disambiguate responses that may arrive in + a different order than the corresponding requests. + +1.2. Design Overview + + The functional entities related to peer-to-peer streaming protocols + are the Client Media Player, the service portal, the tracker, and the + peers. The complete description of Client Media Player and service + portal is not discussed here, as they are not in the scope of the + specification. The functional entities directly involved in PPSTP + are trackers and peers (which may support different capabilities). + + The Client Media Player is a logical entity providing direct + interface to the end user at the client device and includes the + functions to select, request, decode, and render content. The Client + Media Player may interface with the local peer application using the + standard format for HTTP request and response messages [RFC7230]. + + The service portal is a logical entity typically used for client + enrollment and for publishing, searching, and retrieving content + information. + + A peer corresponds to a logical entity (typically in a user device) + that actually participates in sharing media content. Peers are + organized in various swarms; each swarm corresponds to the group of + peers streaming certain content at any given time. + + A tracker is a logical entity that maintains the lists of peers + storing chunks for a specific live media channel or on-demand media + streaming content, answers queries from peers, and collects + information on the activity of peers. While a tracker may have an + underlying implementation consisting of more than one physical node, + logically, the tracker can most simply be thought of as a single + element; in this document, it will be treated as a single logical + entity. Communication between these physical nodes to present them + as a single tracker to peers is not considered in PPSTP, which is a + protocol between a tracker and a peer. + + PPSTP is not used to exchange actual content data (either on demand + or live streaming) with peers, but information about which peers can + provide the content. PPSTP is not designed for applications for + which in-sync reception is needed. + + + + + + + + +Cruz, et al. Standards Track [Page 6] + +RFC 7846 PPSTP May 2016 + + +1.2.1. Typical PPSP Session + + When a peer wants to receive streaming of selected content (LEECH + mode): + + 1. Peer connects to a tracker and joins a swarm. + + 2. Peer acquires a list of other peers in the swarm from the tracker. + + 3. Peer exchanges its content availability with the peers on the + obtained peer list. + + 4. Peer identifies the peers with desired content. + + 5. Peer requests content from the identified peers. + + When a peer wants to share streaming content (SEEDER mode) with other + peers: + + 1. Peer connects to a tracker. + + 2. Peer sends information to the tracker about the swarms it belongs + to (joined swarms). + + 3. Peer waits for other peers in LEECH mode to connect with it (see + steps 3-5 in the previous list). + + After having been disconnected due to some termination conditions or + user controls, a peer can resume previous activity by connecting and + re-joining the corresponding swarm(s). + +1.2.2. Example of a PPSP Session + + In order to be able to bootstrap in the P2P network, a peer must + first obtain a peer ID and any required security certificates or + authorization tokens from an enrollment service (end-user + registration). The peer ID MUST be unique (see the definition of + "peer ID" in Section 1.1); however, the representation of the peer ID + is not considered in this document. + + + + + + + + + + + + +Cruz, et al. Standards Track [Page 7] + +RFC 7846 PPSTP May 2016 + + + +--------+ +--------+ +--------+ +---------+ +--------+ + | Player | | Peer_1 | | Portal | | Tracker | | Peer_2 | + +--------+ +--------+ +--------+ +---------+ +--------+ + | | | | | + (a) |--Page request----------------->| | | + |<--------------Page with links--| | | + |--Select stream (MPD request)-->| | | + |<--------------------OK+MPD(x)--| | | + (b) |--Start/Resume->|--CONNECT(join x)------------>| | + |<-----------OK--|<----------------OK+Peerlist--| | + | | | | + |--Get(chunk)--->|<---------- (Peer protocol) ------------->| + |<--------chunk--|<---------------------------------chunks--| + : : : : : + | |--STAT_REPORT---------------->| | + | |<-------------------------OK--| | + : : : : : + | |--FIND----------------------->| | + | |<----------------OK+Peerlist--| | + : : : : : + |--Get(chunk)--->|<---------- (Peer protocol) ------------->| + |<--------chunk--|<---------------------------------chunks--| + : : : : : + + Figure 1: A Typical PPSP Session for Streaming Content + + To join an existing P2P streaming service and to participate in + content sharing, a peer must first locate a tracker. + + As illustrated in Figure 1, a P2P streaming session may be initiated + starting at point (a), with the Client Media Player browsing for the + desired content in order to request it (to the local Peer_1 in the + figure), or resume a previously initiated stream, but starting at + point (b). For this example, the Peer_1 is in mode LEECH. + + At point (a) in Figure 1, the Client Media Player accesses the portal + and selects the content of interest. The portal returns the Media + Presentation Description (MPD) file that includes information about + the address of one or more trackers (which can be grouped by tiers of + priority) that control the swarm x for that media content (e.g., + content x). + + With the information from the MPD, the Client Media Player is able to + trigger the start of the streaming session, requesting to the local + Peer_1 the chunks of interest. + + + + + + +Cruz, et al. Standards Track [Page 8] + +RFC 7846 PPSTP May 2016 + + + The PPSP streaming session is then started (or resumed) at Peer_1 by + sending a PPSTP CONNECT message to the tracker in order to join swarm + x. The tracker will then return the OK response message containing a + peer list, if the CONNECT message is successfully accepted. From + that point, every chunk request is addressed by Peer_1 to its + neighbors (Peer_2 in Figure 1) using a peer protocol, e.g., + [RFC7574], returning the received chunks to the Client Media Player. + + Once connected, Peer_1 needs to periodically report its status and + statistics data to the tracker using a STAT_REPORT message. + + If Peer_1 needs to refresh its neighborhood (for example, due to + churn), it will send a PPSTP FIND message (with the desired scope) to + the tracker. + + Peers that are only SEEDERs (i.e., serving content to other peers), + as are the typical cases of service provider P2P edge caches and/or + media servers, trigger their P2P streaming sessions for content x, y, + z... (Figure 2), not from Media Player signals, but from some + "Start" activation signal received from the service provider + provisioning mechanism. In this particular case, the peer starts or + resumes all its streaming sessions just by sending a PPSTP CONNECT + message to the tracker (Figure 2), in order to "join" all the + requested swarms. + + Periodically, the peer also reports its status and statistics data to + the tracker using a PPSTP STAT_REPORT message. + + +---------+ +---------+ + | SEEDER | | Tracker | + +---------+ +---------+ + | | + Start->|--CONNECT (join x,y,z)-------->| + |<--------------------------OK--| + : : + | | + |--STAT_REPORT----------------->| + |<--------------------------Ok--| + : : + | | + |--STAT_REPORT----------------->| + |<--------------------------Ok--| + : : + + Figure 2: A Typical PPSP Session for a Streaming SEEDER + + + + + + +Cruz, et al. Standards Track [Page 9] + +RFC 7846 PPSTP May 2016 + + + The specification of the mechanisms used by the Client Media Player + (or provisioning process) and the peer to signal start/resume of + streams, request media chunks, and obtain a peer ID, security + certificates, or tokens is not in the scope of this document. + +2. Protocol Architecture and Functional View + + PPSTP is designed with a layered approach i.e., a PPSTP + Request/Response layer, a Message layer, and a Transport layer (see + Figure 3). + + +------------------------+ + | Application | + +------------------------+ + |(PPSTP) Request/Response| + |------------------------| + | (HTTP) Message | + +------------------------+ + | Transport | + +------------------------+ + + Figure 3: Abstract Layering of PPSTP + + The PPSTP Request/Response layer deals with the interactions between + tracker and peers using request and response messages. + + The Message layer deals with the framing format for encoding and + transmitting data through the underlying transport protocol, as well + as the asynchronous nature of the interactions between tracker and + peers. + + The Transport layer is responsible for the actual transmission of + requests and responses over network transports, including the + determination of the connection to use for a request or response + message when using TCP or Transport Layer Security (TLS) [RFC5246] + over it. + +2.1. Messaging Model + + The messaging model of PPSTP aligns with HTTP, which is currently in + version 1.1 [RFC7230], and the semantics of its messages. PPSTP is + intended to also support future versions of HTTP. + +2.2. Request/Response Model + + PPSTP uses a design like REST (Representational State Transfer) with + the goal of leveraging current HTTP implementations and + infrastructure, as well as familiarity with existing REST-like + + + +Cruz, et al. Standards Track [Page 10] + +RFC 7846 PPSTP May 2016 + + + services in popular use. PPSTP messages use the UTF-8 character set + [RFC3629] and are either requests from peers to a tracker service or + responses from a tracker service to peers. The request and response + semantics are carried as entities (header and body) in messages that + correspond to either HTTP request methods or HTTP response codes, + respectively. + + PPSTP uses the HTTP POST method to send parameters in requests. + PPSTP messages use JavaScript Object Notation (JSON) [RFC7159] to + encode message bodies. + + Peers send requests to trackers. Trackers send a single response for + each request though both requests and responses can be subject to + fragmentation of messages in transport. + + The request messages of the base protocol are listed in Table 1: + + +------------------------------+ + | PPSTP Request Messages | + +------------------------------+ + | CONNECT | + | FIND | + | STAT_REPORT | + +------------------------------+ + + Table 1: Request Messages + + CONNECT: + This request message is used when a peer registers in the tracker + to notify it about participation in the named swarm(s). If the + peer is already registered in the tracker, this request message + simply notifies the tracker about participation in the named + swarm(s). The tracker records the peer ID, connect-time + (referenced to the absolute time), peer IP addresses (and + associated location information), link status, and peer mode for + the named swarm(s). The tracker also changes the content + availability of the valid named swarm(s), i.e., changes the peer's + lists of the corresponding swarm(s) for the requesting peer ID. + On receiving a CONNECT message, the tracker first checks the peer + mode type (SEEDER/LEECH) for the specified swarm(s) and then + decides the next steps (see Section 4.1 for more details). + + FIND: + This request message is used by peers to request a list of peers + active in the named swarm from the tracker whenever needed. On + receiving a FIND message, the tracker finds the peers listed in + the content status of the specified swarm that can satisfy the + requesting peer's requirements and returns the list to the + + + +Cruz, et al. Standards Track [Page 11] + +RFC 7846 PPSTP May 2016 + + + requesting peer. To create the peer list, the tracker may take + peer status, capabilities, and peer priority into consideration. + Peer priority may be determined by network topology preference, + operator policy preference, etc. + + STAT_REPORT: + This request message is used to allow an active peer to send + status (and optionally statistic data) to the tracker to signal + continuing activity. This request message MUST be sent + periodically to the tracker while the peer is active in the + system. + +2.3. State Machines and Flows of the Protocol + + The state machine for the tracker is very simple, as shown in Figure + 4. Peer ID registrations represent a dynamic piece of state + maintained by the network. + + -------------------------------------------- + / \ + | +------------+ +=========+ +======+ | + \-| TERMINATED |<---| STARTED |<---| INIT |<-/ + +------------+ +=========+ +======+ + (Transient) \- (start tracker) + + Figure 4: Tracker State Machine + + When there are no peers connected in the tracker, the state machine + is in INIT state. + + When the first peer connects to register with its peer ID, the state + machine moves from INIT to STARTED. As long as there is at least one + active registration of a peer ID, the state machine remains in + STARTED state. When the last peer ID is removed, the state machine + transitions to TERMINATED. From there, it immediately transitions + back to INIT state. Because of this, TERMINATED state is transient. + + Once in STARTED state, each peer is instantiated (per peer ID) in the + tracker state machine with a dedicated transaction state machine + (Figure 5), which is deleted when the peer ID is removed. + + + + + + + + + + + +Cruz, et al. Standards Track [Page 12] + +RFC 7846 PPSTP May 2016 + + + -------------------------------------------- + / \ + | +------------+ +=========+ +======+ | + \-| TERMINATED |<---| STARTED |<---| INIT |<-/ + +------------+ +=========+ +======+ + (Transient) | (1) \- (start tracker) + V + +-----------+ +-------+ rcv CONNECT + (Transient) | TERMINATE | | START | --------------- (1) + +-----------+ +-------+ strt init timer + rcv FIND (B) ^ | + rcv STAT_REPORT (B) | | + on registration error (B)| v + on action error (A) | +------------+ + ---------------- +<--| PEER | (Transient) + stop init timer | | REGISTERED | + snd error | +------------+ + | | + on timeout (D) | | process swarm actions + ---------------- | | --------------------- (2) + stop track timer | | snd OK (PeerList) + clean peer info | / stop init timer + del registration | / strt track timer + | / + | | + | | rcv FIND + STAT_REPORT ERR(C) \ | ---- --------------- (3) + FIND ERR(C) ---- \ | / \ snd OK (PeerList) + CONNECT ERR(C) / \ | | | | rst track timer + rcv CONNECT | (4) | | | | | + ----------- | v | v v | rcv STAT_REPORT + snd OK \ +==============+ / --------------- (3) + rst track timer ----| TRACKING |---- snd OK response + snd error (C) +==============+ rst track timer + + Figure 5: "Per-Peer-ID" State Machine and Flow Diagram + + Unlike the tracker state machine, which exists even when no peer IDs + are registered, the "per-Peer-ID" State Machine is instantiated only + when the peer ID starts registration in the tracker and is deleted + when the peer ID is de-registered/removed. This allows for an + implementation optimization whereby the tracker can destroy the + objects associated with the "per-Peer-ID" State Machine once it + enters the TERMINATE state (Figure 5). + + When a new peer ID is added, the corresponding "per-Peer-ID" State + Machine is instantiated, and it moves into the PEER REGISTERED state. + Because of that, the START state here is transient. + + + +Cruz, et al. Standards Track [Page 13] + +RFC 7846 PPSTP May 2016 + + + When the peer ID is no longer bound to a registration, the "per-Peer- + ID" State Machine moves to the TERMINATE state, and the state machine + is destroyed. + + During the lifetime of streaming activity of a peer, the instantiated + "per-Peer-ID" State Machine progresses from one state to another in + response to various events. The events that may potentially advance + the state include: + + o Reception of CONNECT, FIND, and STAT_REPORT messages + + o Timeout events + + The state diagram in Figure 5 illustrates state changes, together + with the causing events and resulting actions. Specific error + conditions are not shown in the state diagram. + +2.3.1. Normal Operation + + For normal operation, the process consists of the following steps: + + 1) When a peer wants to access the system, it needs to register with + a tracker by sending a CONNECT message asking for the swarm(s) it + wants to join. This request from a new peer ID triggers the + instantiation in the tracker of a "per-Peer-ID" State Machine. In + the START state of the new "per-Peer-ID" State Machine, the + tracker registers the peer ID and associated information (IP + addresses), starts the "init timer", and moves to PEER REGISTERED + state. + + 2) In PEER REGISTERED state, if the peer ID is valid, the tracker + either: + + a) processes the requested action(s) for the valid swarm + information contained in the CONNECT requests, and if + successful, the tracker stops the "init timer", starts the + "track timer", and sends the response to the peer (the response + may contain the appropriate list of peers for the joining + swarm(s), as detailed in Section 4.1), or + + b) moves the valid FIND request to TRACKING state. + + 3) In TRACKING state, STAT_REPORT or FIND messages received from that + peer ID will reset the "track timer", and the tracker responds to + the requests with the following, respectively: + + + + + + +Cruz, et al. Standards Track [Page 14] + +RFC 7846 PPSTP May 2016 + + + a) a successful condition, or + + b) a successful condition containing the appropriate list of peers + for the named swarm (Section 4.2). + + 4) While in TRACKING state, a CONNECT message received from that peer + ID with valid swarm action information (Section 4.1.1) resets the + "track timer", and the tracker responds to the request with a + successful condition. + +2.3.2. Error Conditions + + Peers are required not to generate protocol elements that are + invalid. However, several situations may lead to abnormal conditions + in the interaction with the tracker. These situations may be related + to peer malfunction or communication errors. The tracker reacts to + these abnormal situations depending on its current state related to a + peer ID, as follows: + + A) In PEER REGISTERED state, when a CONNECT request only contains + invalid swarm actions (Section 4.1.1), the tracker responds with a + PPSTP error code as specified in Section 4.3, deletes the + registration, and transitions to TERMINATE state for that peer ID. + The state machine is destroyed. + + B) In PEER REGISTERED state, if the peer ID is considered invalid (in + the case of a CONNECT request or in the case of FIND or + STAT_REPORT requests received from an unregistered peer ID), the + tracker responds with either a 06 (Authentication Required) + error_code or a 03 (Forbidden Action) error_code as described in + Section 4.3 and transitions to TERMINATE state for that peer ID. + The state machine is destroyed. + + C) In TRACKING state (while the "track timer" has not expired), + receiving a CONNECT message from a peer ID with invalid swarm + actions (Section 4.1.1) or receiving a FIND/STAT_REPORT message + from a peer ID with an invalid swarm ID is considered an error + condition. The tracker responds with the corresponding error code + (described in Section 4.3). + + D) In TRACKING state, without receiving messages from the peer on + timeout (the "track timer" has expired), 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 state machine is destroyed. + + + + + + +Cruz, et al. Standards Track [Page 15] + +RFC 7846 PPSTP May 2016 + + + NOTE: These situations may correspond to malfunctions at the peer or + to malicious conditions. As a preventive measure, the tracker + proceeds to TERMINATE state for that peer ID. + +3. Protocol Specification + +3.1. Presentation Language + + PPSTP uses a REST-like design, encoding the requests and responses + using JSON [RFC7159]. For a generalization of the definition of + protocol elements and fields, as well as their types and structures, + this document uses a C-style notation, similar to the presentation + language used to define TLS [RFC5246]. + + A JSON object consists of name/value pairs with the grammar specified + in [RFC7159]. In this document, comments begin with "//", and the + "ppsp_tp_string_t" and "ppsp_tp_integer_t" types are used to indicate + the JSON string and number, respectively. Optional fields are + enclosed in "[ ]" brackets. An array is indicated by two numbers in + angle brackets, <min..max>, where "min" indicates the minimal number + of values and "max" the maximum. An "*" is used to denote a no + upper-bound value for "max". + +3.2. Resource Element Types + + This section details the format of PPSTP resource element types. + +3.2.1. Version + + For both requests and responses, the version of PPSTP being used MUST + be indicated by the attribute version, defined as follows: + + ppsp_tp_integer_t ppsp_tp_version_t = 1 + + The defined value for ppsp_tp_version_t is listed in Table 2. + + +----------------------------------------------------------+ + | ppsp_tp_version_t | Description | + +----------------------------------------------------------+ + | 0 | Reserved | + | 1 | PPSTP version 1 | + | 2-255 | Unassigned | + +----------------------------------------------------------+ + + Table 2: PPSTP Version Numbers + + + + + + +Cruz, et al. Standards Track [Page 16] + +RFC 7846 PPSTP May 2016 + + +3.2.2. Peer Number Element + + The peer number element is a scope selector optionally present in + CONNECT and FIND requests. + + This element contains the attribute peer_count to indicate the + maximum number of peers in the returned peer list. peer_count should + be less than 30 in this specification. The other 4 attributes, i.e., + ability_nat, concurrent_links, online_time, and upload_bandwidth may + also be contained in this element to inform the tracker the status of + the peer so that the tracker could return some eligible peers based + on the implementing rules set by the service providers: + + o ability_nat is used to indicate the preferred NAT traversal + situation of the requesting peer. + + o concurrent_links means the number of P2P links the peer currently + has. + + o online_time represents online duration time of the peer. The unit + is second. + + o upload_bandwidth is the maximum upload bandwidth capability of the + peer. The unit is Kbps. + + The scope selector element and its attributes are defined as follows: + + Object { + ppsp_tp_integer_t peer_count; + [ppsp_tp_string_t ability_nat = "NO_NAT" + | "STUN" + | "TURN";] + [ppsp_tp_integer_t concurrent_links;] + [ppsp_tp_integer_t online_time;] + [ppsp_tp_integer_t upload_bandwidth;] + } ppsp_tp_peer_num_t; + + + + + + + + + + + + + + + +Cruz, et al. Standards Track [Page 17] + +RFC 7846 PPSTP May 2016 + + +3.2.3. Swarm Action Element + + The swarm action element identifies the action(s) to be taken in the + named swarm(s) as well as the corresponding peer mode (if the peer is + LEECH or SEEDER in that swarm). + + Object { + ppsp_tp_string_t swarm_id; //swarm ID + ppsp_tp_string_t action = "JOIN" + |"LEAVE"; // Action type of + // the CONNECT + // message + + ppsp_tp_string_t peer_mode = "SEEDER" + | "LEECH"; // Mode of the peer + // participating + // in this swarm + } ppsp_tp_swarm_action_t; + +3.2.4. Peer Information Elements + + The peer information elements provide network identification + information of peers. A peer information element consists of a peer + identifier and the IP-related addressing information. + + Object { + ppsp_tp_string_t peer_id; + ppsp_tp_peer_addr_t peer_addr; + } ppsp_tp_peer_info_t; + + The ppsp_tp_peer_addr_t element includes the IP address and port, + with a few optional attributes related to connection type and network + location (in terms of ASN) as well as, optionally, the identifier of + the peer protocol being used. + + Object { + ppsp_tp_ip_address ip_address; + ppsp_tp_integer_t port; + ppsp_tp_integer_t priority; + ppsp_tp_string_t type = "HOST" + | "REFLEXIVE" + | "PROXY"; + [ppsp_tp_string_t connection = "wireless" + | "wired";] + [ppsp_tp_string_t asn;] + [ppsp_tp_string_t peer_protocol;] + } ppsp_tp_peer_addr_t; + + + + +Cruz, et al. Standards Track [Page 18] + +RFC 7846 PPSTP May 2016 + + + The semantics of ppsp_tp_peer_addr_t attributes are listed in + Table 3: + + +----------------------+----------------------------------+ + | Element or Attribute | Description | + +----------------------+----------------------------------+ + | ip_address | IP address information | + | port | IP service port value | + | priority | The priority of this interface. | + | | It may be determined by network | + | | topology preference, operator | + | | policy preference, etc. How to | + | | create a priority is outside of | + | | the scope. The larger the value,| + | | the higher the priority. | + | type | Describes the address for NAT | + | | traversal, which can be HOST | + | | REFLEXIVE or PROXY | + | connection | Access type (wireless or wired) | + | asn | Autonomous System Number | + | peer_protocol | Peer-to-Peer Streaming Peer | + | | Protocol (PPSPP) supported | + +----------------------+----------------------------------+ + + Table 3: Semantics of ppsp_tp_peer_addr_t + + In this document, IP address is specified as ppsp_tp_addr_value. The + exact characters and format depend on address_type: + + o The IPv4 address is encoded as specified by the "IPv4address" rule + in Section 3.2.2 of [RFC3986]. + + o The IPv6 address is encoded as specified in Section 4 of + [RFC5952]. + + Object { + ppsp_tp_string_t address_type; + ppsp_tp_addr_value address; + } ppsp_tp_ip_address; + + The peer information in responses is grouped in a + ppsp_tp_peer_group_t element: + + Object { + ppsp_tp_peer_info_t peer_info<1..*>; + } ppsp_tp_peer_group_t; + + + + + +Cruz, et al. Standards Track [Page 19] + +RFC 7846 PPSTP May 2016 + + +3.2.5. Statistics and Status Information Element + + The statistics element (stat) is used to describe several properties + relevant to the P2P network. These properties can be related to + stream statistics and peer status information. Each stat element + will correspond to a property type, and several stat blocks can be + reported in a single STAT_REPORT message, corresponding to some or + all the swarms the peer is actively involved. This specification + only defines the property type "STREAM_STATS". + + The definition of the statistic element and attributes is as follows: + + Object { + ppsp_tp_string_t swarm_id; + ppsp_tp_integer_t uploaded_bytes; + ppsp_tp_integer_t downloaded_bytes; + ppsp_tp_integer_t available_bandwidth; + ppsp_tp_integer_t concurrent_links; + } stream_stats; + + The semantics of stream_stats attributes are listed in Table 4: + + +----------------------+----------------------------------+ + | Element or Attribute | Description | + +----------------------+----------------------------------+ + | swarm_id | Swarm ID | + | uploaded_bytes | Bytes sent to swarm | + | downloaded_bytes | Bytes received from swarm | + | available_bandwidth | Available instantaneous upload | + | | bandwidth | + | concurrent_links | Number of concurrent links | + +----------------------+----------------------------------+ + + Table 4: Semantics of stream_stats + + The stat information is grouped in the ppsp_tp_stat_group_t element: + + Object { + ppsp_tp_string_t type = "STREAM_STATS"; // property type + stream_stats stat<1..*>; + } ppsp_tp_stat_group_t + + Other properties may be defined, related, for example, to incentives + and reputation mechanisms like "peer online time" or connectivity + conditions like physical "link status", etc. + + + + + + +Cruz, et al. Standards Track [Page 20] + +RFC 7846 PPSTP May 2016 + + + For that purpose, the stat element may be extended to provide + additional specific information for new properties, elements, or + attributes (see the guidelines in Section 7). + +3.3. Requests and Responses + + This section defines the structure of PPSTP requests and responses. + +3.3.1. Request Types + + The request type includes CONNECT, FIND, and STAT_REPORT, defined as + follows: + + ppsp_tp_string_t ppsp_tp_request_type_t = "CONNECT" + | "FIND" + | "STAT_REPORT"; + +3.3.2. Response Types + + Response type corresponds to the response method type of the message, + defined as follows: + + JSONValue ppsp_tp_response_type_t = 0x00 // SUCCESSFUL + | 0x01; // FAILED + + + + + + + + + + + + + + + + + + + + + + + + + + + +Cruz, et al. Standards Track [Page 21] + +RFC 7846 PPSTP May 2016 + + +3.3.3. Request Element + + The request element MUST be present in requests and corresponds to + the request method type for the message. + + The generic definition of a request element is as follows: + + Object { + [ppsp_tp_peer_num_t peer_num;] + [ppsp_tp_peer_addr_t peer_addr<1..*>;] + ppsp_tp_swarm_action_t swarm_action<1..*>; + } ppsp_tp_request_connect; + + Object { + ppsp_tp_string_t swarm_id; + [ppsp_tp_peer_num_t peer_num;] + } ppsp_tp_request_find; + + Object { + ppsp_tp_version_t version; + ppsp_tp_request_type_t request_type; + ppsp_tp_string_t transaction_id; + ppsp_tp_string_t peer_id; + JSONValue request_data = ppsp_tp_req_connect connect + | ppsp_tp_req_find find + | ppsp_tp_stat_group_t stat_report; + } ppsp_tp_request; + + A request element consists of the version of PPSTP, the request type, + a transaction ID, the requesting peer ID, and requesting body (i.e., + request_data). The request_data MUST be correctly set to the + corresponding element based on the request type (see Table 5). + + +----------------------+----------------------+ + | request_type | request_data | + +----------------------+----------------------+ + | "CONNECT" | "connect" | + | "FIND" | "find" | + | "STAT_REPORT" | "stat_report" | + +----------------------+----------------------+ + + Table 5: The Relationship between request_type and request_data + + + + + + + + + +Cruz, et al. Standards Track [Page 22] + +RFC 7846 PPSTP May 2016 + + +3.3.4. Response Element + + The generic definition of a response element is as follows: + + Object { + ppsp_tp_version_t version; + ppsp_tp_response_type_t response_type; + ppsp_tp_integer_t error_code; + ppsp_tp_string_t transaction_id; + [ppsp_tp_peer_addr_t peer_addr;] + [ppsp_tp_swarm_action_result_t swarm_result<1..*>;] + } ppsp_tp_response; + + A response element consists of the version of PPSTP, the response + type, the error code, a transaction ID, and optionally the public + address of the requesting peer and one or multiple swarm action + result elements. Normally, swarm action result elements SHOULD be + present and error_code MUST be set to 00 (No Error) when + response_type is 0x00. Swarm action result elements SHOULD NOT be + set when error_code is 01 (Bad Request). Detailed selection of + error_code is introduced in Section 4.3. + + Object { + ppsp_tp_string_t swarm_id; + ppsp_tp_response_type_t result; + [ppsp_tp_peer_group_t peer_group;] + } ppsp_tp_swarm_action_result_t; + + A swarm action result element represents the result of an action + requested by the peer. It contains a swarm identifier that globally + indicates the swarm, the result for the peer of this action (which + could be CONNECT ("JOIN" or "LEAVE"), FIND, or STAT_REPORT), and + optionally one peer group element. The attribute result indicates + the operation result of the corresponding request. When the response + element corresponds to the STAT_REPORT request or the result + attribute is set to 0x01, the peer group element SHOULD NOT be set. + + + + + + + + + + + + + + + +Cruz, et al. Standards Track [Page 23] + +RFC 7846 PPSTP May 2016 + + +3.4. PPSTP Message Element + + PPSTP messages (requests or responses) are designed to have a similar + structure with a root field named "PPSPTrackerProtocol" containing + meta information and data pertaining to a request or a response. + + The base type of a PPSTP message is defined as follows: + + Object { + JSONValue PPSPTrackerProtocol = ppsp_tp_request Request + | ppsp_tp_response Response; + } ppsp_tp_message_root; + +4. Protocol Specification: Encoding and Operation + + PPSTP is a message-oriented request/response protocol. PPSTP + messages use a text type encoding in JSON [RFC7159], which MUST be + indicated in the Content-Type field in HTTP/1.1 [RFC7231], specifying + the "application/ppsp-tracker+json" media type for all PPSTP request + parameters and responses. + + Implementations MUST support the "https" URI scheme [RFC2818] and + Transport Layer Security (TLS) [RFC5246]. + + For deployment scenarios where peer (client) authentication is + desired at the tracker, HTTP Digest Access Authentication [RFC7616] + MUST be supported, with TLS Client Authentication as the preferred + mechanism, if available. + + PPSTP uses the HTTP POST method to send parameters in requests to + provide information resources that are the function of one or more of + those input parameters. Input parameters are encoded in JSON in the + HTTP entity body of the request. + + The section describes the operation of the three types of requests of + PPSTP and provides some examples of usage. + + + + + + + + + + + + + + + +Cruz, et al. Standards Track [Page 24] + +RFC 7846 PPSTP May 2016 + + +4.1. Requests and Responses + +4.1.1. CONNECT Request + + This method is used when a peer registers to the system and/or + requests some swarm actions (join/leave). The peer MUST properly set + the request type to CONNECT, generate and set the transaction_ids, + set the peer_id, and include swarms the peer is interested in, + followed by the corresponding action type and peer mode. + + o When a peer already possesses content and agrees to share it with + others, it should set the action type to the value JOIN, as well + as set the peer mode to SEEDER during its start (or re-start) + period. + + o When a peer makes a request to join a swarm to consume content, it + should set the action type to the value JOIN, as well as set the + peer mode to LEECH during its start (or re-start) period. + + In the above cases, the peer can provide optional information on the + addresses of its network interface(s), for example, the priority, + type, connection, and ASN. + + When a peer plans to leave a previously joined swarm, it should set + action type to LEAVE, regardless of the peer mode. + + When receiving a well-formed CONNECT request message, the tracker + starts by pre-processing 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, + then proceed to register the peer in the service and perform the + swarm actions requested. If successful, a response message with a + corresponding response value of SUCCESSFUL will be generated. + + The valid sets of the number of swarms whose action type is combined + with peer mode for the CONNECT request logic are enumerated in + Table 6 (referring to the "per-Peer-ID" State Machine in + Section 2.3). + + + + + + + + + + + + + +Cruz, et al. Standards Track [Page 25] + +RFC 7846 PPSTP May 2016 + + + +-----------+-----------+---------+----------+-----------+----------+ + | Swarm | peer_mode | action | Initial | Final | Request | + | Number | 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 | | | | + +-----------+-----------+---------+----------+-----------+----------+ + | N | SEEDER | JOIN | START | TRACKING | Valid | + +-----------+-----------+---------+----------+-----------+----------+ + | N | SEEDER | JOIN | TRACKING | TERMINATE | Invalid | + +-----------+-----------+---------+----------+-----------+----------+ + | N | SEEDER | LEAVE | TRACKING | TERMINATE | Valid | + +-----------+-----------+---------+----------+-----------+----------+ + + Table 6: Validity of Action Combinations in CONNECT Requests + + In the CONNECT request message, multiple swarm action elements + ppsp_tp_swarm_action_t could be contained. Each of them contains the + request action and the peer_mode of the peer. The peer_mode + attribute MUST be set to the type of participation of the peer in the + swarm (SEEDER or LEECH). + + The CONNECT message may contain multiple peer_addr elements with + attributes ip_address, port, priority, and type (if Interactive + Connectivity Establishment (ICE) [RFC5245] NAT traversal techniques + are used), and optionally connection, asn, and peer_protocol + corresponding to each of the network interfaces the peer wants to + advertise. + + The element peer_num indicates the maximum number of peers to be + returned in a list from the tracker. The returned peer list can be + optionally filtered by some indicated properties, such as ability_nat + for NAT traversal, and concurrent_links, online_time and + upload_bandwidth for the preferred capabilities. + + The element transaction_id MUST be present in requests to uniquely + identify the transaction. Responses to completed transactions use + the same transaction_id as the request they correspond to. + + + + +Cruz, et al. Standards Track [Page 26] + +RFC 7846 PPSTP May 2016 + + + The response may include peer_addr data of the requesting peer public + IP address. Peers can use Session Traversal Utilities for NAT (STUN) + [RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766] to + gather their candidates, in which case peer_addr SHOULD NOT present + in the response. If no STUN is used and the tracker is able to work + as a "STUN-like" server that can inspect the public address of a + peer, the tracker can return the address back with a "REFLEXIVE" + attribute type. The swarm_result may also include peer_addr 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 of the referenced peer. + + If the peer_mode is SEEDER, the tracker responds with a SUCCESSFUL + response and enters the peer information into the corresponding swarm + activity. If the peer_mode is LEECH (or if a SEEDER includes a + peer_num element in the request), 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 Application-Layer Traffic Optimization + (ALTO) [RFC7285]. + + IMPLEMENTATION NOTE: If no peer_num attributes are present in the + request, the tracker may return a random sample from the peer + population. + + + + + + + + + + + + + + + + + + + + + +Cruz, et al. Standards Track [Page 27] + +RFC 7846 PPSTP May 2016 + + +4.1.1.1. Example + + The following example of a CONNECT request corresponds to a peer that + wants to start (or re-start) sharing its previously streamed content + (peer_mode is SEEDER). + + POST https://tracker.example.com/video_1 HTTP/1.1 + Host: tracker.example.com + Content-Length: 494 + Content-Type: application/ppsp-tracker+json + Accept: application/ppsp-tracker+json + + { + "PPSPTrackerProtocol": { + "version": 1, + "request_type": "CONNECT", + "transaction_id": "12345", + "peer_id": "656164657220", + "connect":{ + "peer_addr": { + "ip_address": { + "address_type": "ipv4", + "address": "192.0.2.2" + }, + "port": 80, + "priority": 1, + "type": "HOST", + "connection": "wired", + "asn": "45645" + }, + "swarm_action": [{ + "swarm_id": "1111", + "action": "JOIN", + "peer_mode": "SEEDER" + }, + { + "swarm_id": "2222", + "action": "JOIN", + "peer_mode": "SEEDER" + }] + } + } + } + + Another example of the message-body of a CONNECT request corresponds + to a peer (peer_mode is LEECH, meaning that the peer is not in + possession of the content) requesting join to a swarm, in order to + + + + +Cruz, et al. Standards Track [Page 28] + +RFC 7846 PPSTP May 2016 + + + start receiving the stream and providing optional information on the + addresses of its network interface(s): + + { + "PPSPTrackerProtocol": { + "version": 1, + "request_type": "CONNECT", + "transaction_id": "12345.0", + "peer_id": "656164657221", + "connect":{ + "peer_num": { + "peer_count": 5, + "ability_nat": "STUN", + "concurrent_links": "5", + "online_time": "200", + "upload_bandwidth": "600" + }, + "peer_addr": [{ + "ip_address": { + "address_type": "ipv4", + "address": "192.0.2.2" + }, + "port": 80, + "priority": 1, + "type": "HOST", + "connection": "wired", + "asn": "3256546" + }, + { + "ip_address":{ + "address_type": "ipv6", + "address": "2001:db8::2" + }, + "port": 80, + "priority": 2, + "type": "HOST", + "connection": "wireless", + "asn": "34563456", + "peer_protocol": "PPSP-PP" + }], + "swarm_action": { + "swarm_id": "1111", + "action": "JOIN", + "peer_mode": "LEECH" + } + } + } + } + + + +Cruz, et al. Standards Track [Page 29] + +RFC 7846 PPSTP May 2016 + + + The next example of a CONNECT request corresponds to a peer leaving a + previously joined swarm and requesting to join a new swarm. This is + the typical example of a user watching a live channel but then + deciding to switch to a different one: + + { + "PPSPTrackerProtocol": { + "version": 1, + "request_type": "CONNECT", + "transaction_id": "12345", + "peer_id": "656164657221", + "connect":{ + "peer_num": { + "peer_count": 5, + "ability_nat": "STUN", + "concurrent_links": "5", + "online_time": "200", + "upload_bandwidth": "600" + }, + "swarm_action": [{ + "swarm_id": "1111", + "action": "LEAVE", + "peer_mode": "LEECH" + }, + { + "swarm_id": "2222", + "action": "JOIN", + "peer_mode": "LEECH" + }] + } + } + } + + The next example illustrates the response for the previous example of + a CONNECT request where the peer requested two swarm actions and not + more than 5 other peers, receiving from the tracker a peer list with + only two other peers in the swarm "2222": + + HTTP/1.1 200 OK + Content-Length: 1342 + Content-Type: application/ppsp-tracker+json + + { + "PPSPTrackerProtocol": { + "version": 1, + "response_type": 0, + "error_code": 0, + "transaction_id": "12345", + + + +Cruz, et al. Standards Track [Page 30] + +RFC 7846 PPSTP May 2016 + + + "peer_addr": { + "ip_address": { + "address_type": "ipv4", + "address": "198.51.100.1" + }, + "port": 80, + "priority": 1, + "asn": "64496" + }, + "swarm_result": { + "swarm_id": "2222", + "result": 0, + "peer_group": { + "peer_info": [{ + "peer_id": "956264622298", + "peer_addr": { + "ip_address": { + "address_type": "ipv4", + "address": "198.51.100.22" + }, + "port": 80, + "priority": 2, + "type": "REFLEXIVE", + "connection": "wired", + "asn": "64496", + "peer_protocol": "PPSP-PP" + } + }, + { + "peer_id": "3332001256741", + "peer_addr": { + "ip_address": { + "address_type": "ipv4", + "address": "198.51.100.201" + }, + "port": 80, + "priority": 2, + "type": "REFLEXIVE", + + "connection": "wired", + "asn": "64496", + "peer_protocol": "PPSP-PP" + } + }] + } + } + } + } + + + +Cruz, et al. Standards Track [Page 31] + +RFC 7846 PPSTP May 2016 + + +4.1.2. FIND Request + + This method allows peers to request a new peer list for the swarm + from the tracker whenever needed. + + The FIND request may include a peer_number element to indicate to the + tracker the maximum number of peers to be returned in a list + corresponding to the indicated conditions set by the requesting peer, + being ability_nat for NAT traversal (considering that PPSP-ICE NAT + traversal techniques may be used), and optionally concurrent_links, + online_time, and upload_bandwidth for the preferred capabilities. + + When receiving a well-formed FIND request, the tracker processes the + information to check if it is valid. If successful, a response + message with a response value of SUCCESSFUL will be generated, and + the tracker will search out the list of peers for the swarm and + select an appropriate peer list satisfying the conditions set by the + requesting peer. The peer list returned MUST contain the peer IDs + and the corresponding IP addresses. + + The tracker may take the ability of peers and popularity of the + requested content into consideration. For example, the tracker could + select peers with higher ability than the current peers that provide + the content if the content is relatively popular (see Section 5.1.1); + the tracker could also select peers with lower ability than the + current peers that provide the content when the content is relatively + uncommon. The tracker may take network location information into + consideration as well, to express network topology preferences or + operators' policy preferences. It can implement other IETF efforts + like ALTO [RFC7285], which is out of the scope of this document. + + The response MUST include a peer_group element that contains the peer + IDs and the corresponding IP addresses; it 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 of the referenced peer. + + The response may also include a peer_addr element that includes the + requesting peer public IP address. If no STUN is used and the + tracker is able to work as a "STUN-like" server that can inspect the + public address of a peer, the tracker can return the address back + with a "REFLEXIVE" attribute type. + + IMPLEMENTATION NOTE: If no peer_num attributes are present in the + request, the tracker may return a random sample from the peer + population. + + + + + +Cruz, et al. Standards Track [Page 32] + +RFC 7846 PPSTP May 2016 + + +4.1.2.1. Example + + An example of the message-body of a FIND request, where the peer + requests from the tracker a list of not more than 5 peers in the + swarm "1111" conforming to the characteristics expressed (concurrent + links, online time, and upload bandwidth level) is as follows: + + { + "PPSPTrackerProtocol": { + "version": 1, + "request_type": "FIND", + "transaction_id": "12345", + "peer_id": "656164657221", + "swarm_id": "1111", + "peer_num": { + "peer_count": 5, + "ability_nat": "STUN", + "concurrent_links": "5", + "online_time": "200", + "upload_bandwidth": "600" + } + } + } + + An example of the message-body of a response for the above FIND + request, including the requesting peer public IP address information, + is as follows: + + { + "PPSPTrackerProtocol": { + "version": 1, + "response_type": 0, + "error_code": 0, + "transaction_id": "12345", + "swarm_result": { + "swarm_id": "1111", + "result": 0, + "peer_group": { + "peer_info": [{ + + "peer_id": "656164657221", + "peer_addr": { + "ip_address": { + "address_type": "ipv4", + "address": "198.51.100.1" + }, + "port": 80, + "priority": 1, + + + +Cruz, et al. Standards Track [Page 33] + +RFC 7846 PPSTP May 2016 + + + "type": "REFLEXIVE", + "connection": "wireless", + "asn": "64496" + } + }, + { + "peer_id": "956264622298", + "peer_addr": { + "ip_address": { + "address_type": "ipv4", + "address": "198.51.100.22" + }, + "port": 80, + "priority": 1, + "type": "REFLEXIVE", + "connection": "wireless", + "asn": "64496" + } + }, + { + "peer_id": "3332001256741", + "peer_addr": { + "ip_address": { + "address_type": "ipv4", + "address": "198.51.100.201" + }, + "port": 80, + "priority": 1, + "type": "REFLEXIVE", + + "connection": "wireless", + "asn": "64496" + } + }] + } + } + } + } + +4.1.3. STAT_REPORT Request + + This method allows peers to send status and statistic data to + trackers. The method is periodically initiated by the peer while it + is active. + + The peer MUST set the request_type to "STAT_REPORT", set the peer_id + with the identifier of the peer, and generate and set the + transaction_id. + + + +Cruz, et al. Standards Track [Page 34] + +RFC 7846 PPSTP May 2016 + + + The report may include multiple statistics elements describing + several properties relevant to a specific swarm. These properties + can be related with stream statistics and peer status information, + including uploaded_bytes, downloaded_bytes, available_bandwidth, + concurrent_links, etc. + + Other properties may be defined (see the guidelines in Section 7.1), + for example, those related to incentives and reputation mechanisms. + If no Statistics Group is included, the STAT_REPORT is used as a + "keep-alive" message to prevent the tracker from de-registering the + peer when the "track timer" expires. + + If the request is valid, the tracker processes the received + information for future use and generates a response message with a + response value of SUCCESSFUL. + + The response MUST have the same transaction_id value as the request. + +4.1.3.1. Example + + An example of the message-body of a STAT_REPORT request is: + + { + "PPSPTrackerProtocol": { + "version": 1, + "request_type": "STAT_REPORT", + "transaction_id": "12345", + "peer_id": "656164657221", + "stat_report": { + "type": "STREAM_STATS", + "Stat": { + "swarm_id": "1111", + "uploaded_bytes": 512, + "downloaded_bytes": 768, + "available_bandwidth": 1024000, + "concurrent_links": 5 + } + } + } + } + + + + + + + + + + + +Cruz, et al. Standards Track [Page 35] + +RFC 7846 PPSTP May 2016 + + + An example of the message-body of a response for the START_REPORT + request is: + + { + "PPSPTrackerProtocol": { + "version": 1, + "response_type": 0, + "error_code": 0, + "transaction_id": "12345", + "swarm_result": { + "swarm_id": "1111", + "result": 0 + } + } + } + +4.2. Response Element in Response Messages + + Table 7 indicates the response type and corresponding semantics. + + +--------------------+---------------------+ + | Response Type | Semantics | + | | | + +--------------------+---------------------+ + | 0 | SUCCESSFUL | + | 1 | FAILED | + +--------------------+---------------------+ + + Table 7: Semantics for the Value of Response Type + + SUCCESSFUL: Indicates that the request has been processed properly + and the desired operation has completed. The body of the response + message includes the requested information and MUST include the same + transaction_id as the corresponding request. + + CONNECT: Returns information about the successful registration of + the peer and/or of each swarm action requested. May additionally + return the list of peers corresponding to the action attribute + requested. + + FIND: Returns the list of peers corresponding to the requested + scope. + + STAT_REPORT: Confirms the success of the requested operation. + + FAILED: Indicates that the request has not been processed properly. + A corresponding error_code SHOULD be set according to the conditions + described in Section 4.3. + + + +Cruz, et al. Standards Track [Page 36] + +RFC 7846 PPSTP May 2016 + + +4.3. Error and Recovery Conditions + + If the peer receives an invalid response, the same request with + identical content including the same transaction_id MUST be repeated. + + The transaction_id on a request can be reused if and only if all of + the content is identical, including date/time information. Details + of the retry process (including time intervals to pause, number of + retries to attempt, and timeouts for retrying) are implementation + dependent. + + The tracker MUST be prepared to receive a request with a repeated + transaction_id. + + Error situations resulting from normal operation or from abnormal + conditions (Section 2.3.2) MUST be responded to with response_type + set to 0x01 and with the adequate error_code, as described here: + + o If the message is found to be incorrectly formed, the receiver + MUST respond with a 01 (Bad Request) error_code with an empty + message-body (no peer_addr and swarm_result attributes). + + o If the version number of the protocol is for a version the + receiver does not support, the receiver MUST respond with a 02 + (Unsupported Version Number) error_code with an empty message-body + (no peer_addr and swarm_result attributes). + + o In the PEER REGISTERED and TRACKING states of the tracker, certain + requests are not allowed (Section 2.3.2). The tracker MUST + respond with a 03 (Forbidden Action) error_code with an empty + message-body (no peer_addr and swarm_result attributes). + + o If the tracker is unable to process a request message due to an + unexpected condition, it SHOULD respond with a 04 (Internal Server + Error) error_code with an empty message-body (no peer_addr and + swarm_result attributes). + + o If the tracker is unable to process a request message because it + is in an overloaded state, it SHOULD respond with a 05 (Service + Unavailable) error_code with an empty message-body (no peer_addr + and swarm_result attributes). + + o If authentication is required for the peer to make the request, + the tracker SHOULD respond with a 06 (Authentication Required) + error_code with an empty message-body (no peer_addr and + swarm_result attributes). + + + + + +Cruz, et al. Standards Track [Page 37] + +RFC 7846 PPSTP May 2016 + + +4.4. Parsing of Unknown Fields in message-body + + This document only details object members used by this specification. + Extensions may include additional members within JSON objects defined + in this document. PPSTP implementations MUST ignore unknown members + when processing PPSTP messages. + +5. Operations and Manageability + + This section provides the operational and management aspects that are + required to be considered in implementations of PPSTP. These aspects + follow the recommendations expressed in [RFC5706]. + +5.1. Operational Considerations + + PPSTP provides communication between trackers and peers and is + conceived as a "client-server" mechanism, allowing the exchange of + information about the participant peers sharing multimedia streaming + content. + + The "server" component, i.e., the tracker, is a logical entity that + can be envisioned as a centralized service (implemented in one or + more physical nodes) or a fully distributed service. + + The "client" component can be implemented at each peer participating + in the streaming of content. + +5.1.1. Installation and Initial Setup + + Content providers wishing to use PPSP for content distribution should + set up at least a PPSP tracker and a service portal (public web + server) to publish links of the content descriptions, for access to + their on-demand or live original content sources. Content and + service providers should also create conditions to generate peer IDs + and any required security certificates, as well as chunk IDs and + swarm IDs for each streaming content. The configuration processes + for the PPSP tracking facility, the service portal, and content + sources are not standardized, enabling flexibility for implementers. + + The swarm IDs of available content, as well as the addresses of the + PPSP tracking facility, can be distributed to end users in various + ways, but it is common practice to include both the swarm ID and the + corresponding PPSP tracker addresses (as URLs) in the MPD of the + content, which is obtainable (a link) from the service portal. + + The available content could have different importance attribute + values to indicate whether the content is popular or not. However, + it is a totally implementation design and outside the scope of this + + + +Cruz, et al. Standards Track [Page 38] + +RFC 7846 PPSTP May 2016 + + + specification. For example, the importance attribute values of the + content could be set by content providers when distributing them or + could be determined by the tracker based on the statistics of the + requests from the peers that request the content. The tracker could + set an upper threshold to decide that the content is popular enough + when the importance attribute value is higher than the upper + threshold. The tracker could also set a lower threshold to decide + that the content is uncommon enough when the importance attribute + value is lower than the lower threshold. + + End users browse and search for desired content in the service portal + and select by clicking the links of the corresponding MPDs. This + action typically requires security certificates or authorization + tokens from an enrollment service (end-user registration) and then + launches the Client Media Player (with PPSP awareness), which will + then, using PPSTP, contact the PPSP tracker to join the corresponding + swarm and obtain the transport addresses of other PPSP peers in order + to start streaming the content. + +5.1.2. Migration Path + + There is no previous standard protocol providing functionality + similar to PPSTP. However, some popular proprietary protocols, e.g., + BitTorrent, are used in existing systems. There is no way for PPSTP + to migrate to proprietary protocols like the BitTorrent tracker + protocol. Because PPSTP is an application-level protocol, there is + no harm in PPSTP having no migration path. However, proprietary + protocols migrating to standard protocols like PPSTP can solve the + problems raised in [RFC6972]. It is also possible for systems to use + PPSTP as the management protocol to work with exiting propriety peer + protocols like the BitTorrent peer protocol. + +5.1.3. Requirements on Other Protocols and Functional Components + + For security reasons, when using the Peer-to-Peer Streaming Peer + Protocol (PPSPP) with PPSTP, the mechanisms described in Section 6.1 + should be observed. + +5.1.4. Impact on Network Operation + + As the messaging model of PPSTP aligns with HTTP and the semantics of + its messages, the impact on network operation is similar to using + HTTP. + + + + + + + + +Cruz, et al. Standards Track [Page 39] + +RFC 7846 PPSTP May 2016 + + +5.1.5. Verifying Correct Operation + + The correct operation of PPSTP can be verified both at the tracker + and at the peer by logging the behavior of PPSTP. Additionally, the + PPSP tracker collects the status of the peers, including the peers' + activity; such information can be used to monitor and obtain the + global view of the operation. + +5.2. Management Considerations + + The management considerations for PPSTP are similar to other + solutions using HTTP for large-scale content distribution. The PPSP + tracker can be realized by geographically distributed tracker nodes + or multiple server nodes in a data center. As these nodes are akin + to WWW nodes, their configuration procedures, detection of faults, + measurement of performance, usage accounting, and security measures + can be achieved by standard solutions and facilities. + +5.2.1. Interoperability + + Interoperability refers to allowing information sharing and + operations between multiple devices and multiple management + applications. For PPSTP, distinct types of devices host PPSTP + trackers and peers. Therefore, support for multiple standard schema + languages, management protocols, and information models, suited to + different purposes, was considered in the PPSTP design. + Specifically, management functionality for PPSTP devices can be + achieved with the Simple Network Management Protocol (SNMP) + [RFC3410], syslog [RFC5424], and the Network Configuration Protocol + (NETCONF) [RFC6241]. + +5.2.2. Management Information + + PPSP trackers may implement SNMP management interfaces, namely, the + Application Management MIB [RFC2564], without the need to instrument + the tracker application itself. The channel, connections, and + transaction objects of the Application Management MIB can be used to + report the basic behavior of the PPSP tracker service. + + The Application Performance Measurement MIB (APM-MIB) [RFC3729] and + the Transport Performance Metrics MIB (TPM-MIB) [RFC4150] can be used + with PPSTP to provide adequate metrics for the analysis of + performance for transaction flows in the network, in direct + relationship to the transport of PPSTP. + + The Host Resources MIB [RFC2790] can be used to supply information on + the hardware, the operating system, and the installed and running + software on a PPSP tracker host. + + + +Cruz, et al. Standards Track [Page 40] + +RFC 7846 PPSTP May 2016 + + + The TCP-MIB [RFC4022] can additionally be considered for network + monitoring. + + Logging is an important functionality for PPSTP trackers and peers; + it is done via syslog [RFC5424]. + +5.2.3. Fault Management + + As PPSP tracker failures can be mainly attributed to host or network + conditions, the facilities previously described for verifying the + correct operation of PPSTP and the management of PPSP tracker servers + appear sufficient for PPSTP fault monitoring. + +5.2.4. Configuration Management + + PPSP tracker deployments, when realized by geographically distributed + tracker nodes or multiple server nodes in a data center, may benefit + from a standard way of replicating atomic configuration updates over + a set of server nodes. This functionality can be provided via + NETCONF [RFC6241]. + +5.2.5. Accounting Management + + PPSTP implementations, primarily in content provider environments, + can benefit from accounting standardization efforts as described in + [RFC2975], which indicates that accounting management is "concerned + with the collection of resource consumption data for the purposes of + capacity and trend analysis, cost allocation, auditing, and billing". + +5.2.6. Performance Management + + Because PPSTP is transaction oriented, its performance in terms of + availability and responsiveness can be measured with the facilities + of the APM-MIB [RFC3729] and the TPM-MIB [RFC4150]. + +5.2.7. Security Management + + Standard SNMP notifications for PPSP tracker management [RFC5590] and + syslog messages [RFC5424] can be used to alert operators to the + conditions identified in the security considerations (Section 6). + + The statistics collected about the operation of PPSTP can be used for + detecting attacks (e.g., the receipt of malformed messages, messages + out of order, or messages with invalid timestamps). However, + collecting such endpoint properties may also raise some security + issues. For example, the statistics collected by the tracker may be + disclosed to an unauthorized third party that has malicious + intentions. To address such risk, the provider of the tracker should + + + +Cruz, et al. Standards Track [Page 41] + +RFC 7846 PPSTP May 2016 + + + evaluate how much information is revealed and the associated risks. + A confidentiality mechanism must be provided by HTTP over TLS to + guarantee the confidentiality of PPSTP. + +6. Security Considerations + + P2P streaming systems are subject to attacks by malicious or + unfriendly peers/trackers that may eavesdrop on signaling, forge/deny + information/knowledge about streaming content and/or its + availability, impersonate a valid participant, or launch DoS attacks + on a chosen victim. + + No security system can guarantee complete security in an open P2P + streaming system where participants may be malicious or + uncooperative. The goal of the security considerations described + here is to provide sufficient protection for maintaining some + security properties during tracker-peer communication even in the + face of a large number of malicious peers and/or eventual distrustful + trackers (under the distributed tracker deployment scenario). + + Since the protocol uses HTTP to transfer signaling, most of the + security considerations described in [RFC7230] and [RFC7231] also + apply. Due to the transactional nature of the communication between + peers and tracker, the method for adding authentication and data + security services can be the OAuth 2.0 Authorization [RFC6749] with a + bearer token, which provides the peer with the information required + to successfully utilize an access token to make protected requests to + the tracker. + +6.1. Authentication between Tracker and Peers + + To protect PPSTP signaling from attackers pretending to be valid + peers (or peers other than themselves), all messages received in the + tracker SHOULD be received from authorized peers. For that purpose, + a peer SHOULD enroll in the system via a centralized enrollment + server. The enrollment server is expected to provide a proper peer + ID for the peer and information about the authentication mechanisms. + The specification of the enrollment method and the provision of + identifiers and authentication tokens is out of the scope of this + specification. + + Transport Layer Security (TLS) [RFC5246] MUST be used in the + communication between peers and tracker to provide privacy and data + integrity. Software engineers developing and service providers + deploying the tracker should make themselves familiar with the Best + Current Practices (BCP) on configuring HTTP over TLS [RFC7525]. + + + + + +Cruz, et al. Standards Track [Page 42] + +RFC 7846 PPSTP May 2016 + + + OAuth 2.0 Authorization [RFC6749] SHOULD also be considered when + digest authentication [RFC7616] and HTTPS client certificates are + required. + +6.2. Content Integrity Protection against Polluting Peers/Trackers + + Malicious peers may claim ownership of popular content to the tracker + and try to serve polluted (i.e., decoy content or even virus/trojan- + infected content) to other peers. Since trackers do not exchange + content information among peers, it is difficult to detect whether or + not a peer is polluting the content. Usually, this kind of pollution + can be detected by the Peer-to-Peer Streaming Peer Protocol (PPSPP) + [RFC7574] with requiring the use of Merkle Hash Tree scheme for + protecting the integrity of the content. More details can be seen in + Section 5 of [RFC7574]. + + Some attackers that disrupt P2P streaming on behalf of content + providers may provide false or modified content or peer list + information to achieve certain malicious goals. Peers connecting to + those portals or trackers provided by the attackers may be redirected + to some corrupted malicious content. However, there is no standard + way for peers to avoid this kind of situation completely. Peers can + have mechanisms to detect undesirable content or results themselves. + For example, if a peer finds that the portal returned some undesired + content information or the tracker returned some malicious peer + lists, the peer may choose to quit the swarm or switch to other P2P + streaming services provided by other content providers. + +6.3. Residual Attacks and Mitigation + + To mitigate the impact of Sybil attackers impersonating a large + number of valid participants by repeatedly acquiring different peer + identities, the enrollment server SHOULD carefully regulate the rate + of peer/tracker admission. + + There is no guarantee that peers honestly report their status to the + tracker, or serve authentic content to other peers as they claim to + the tracker. It is expected that a global trust mechanism, where the + credit of each peer is accumulated from evaluations for previous + transactions, may be taken into account by other peers when selecting + partners for future transactions, helping to mitigate the impact of + such malicious behaviors. A globally trusted tracker may also take + part in the trust mechanism by collecting evaluations, computing + credit values, and providing them to joining peers. + + + + + + + +Cruz, et al. Standards Track [Page 43] + +RFC 7846 PPSTP May 2016 + + +6.4. Pro-incentive Parameter Trustfulness + + Property types for STAT_REPORT messages may consider additional pro- + incentive parameters (see the guidelines for extension in Section 7), + which can enable the tracker to improve the performance of the whole + P2P streaming system. Trustworthiness of these pro-incentive + parameters is critical to the effectiveness of the incentive + mechanisms. Furthermore, the amount of both uploaded and downloaded + data should be reported to the tracker to allow checking for + inconsistencies between the upload and download report and to + establish an appropriate credit/trust system. + + One such solution could be a reputation-incentive mechanism, based on + the notions of reputation, social awareness, and fairness. The + mechanism would promote cooperation among participants (via each + peer's reputation) based on the history of past transactions, such + as, count of chunk requests (sent and received) in a swarm, + contribution time of the peer, cumulative uploaded and downloaded + content, JOIN and LEAVE timestamps, attainable rate, etc. + + Alternatively, exchange of cryptographic receipts signed by receiving + peers can be used to attest to the upload contribution of a peer to + the swarm, as suggested in [Contracts]. + +6.5 Privacy for Peers + + PPSTP provides mechanisms in which the peers can send messages + containing IP addresses, ports, and other information to the tracker. + A tracker or a third party who is able to intercept such messages can + store and process the obtained information in order to analyze peers' + behaviors and communication patterns. Such analysis can lead to + privacy risks. For example, an unauthorized party may snoop on the + data transmission from the peer to a tracker in order to introduce + some corrupted chunks. + + The Peer-to-Peer Streaming Peer Protocol (PPSPP) [RFC7574] has + already introduced some mechanisms to protect streamed content; see + Sections 12.3 and 12.4 of [RFC7574]. For PPSTP, peer implementations + as well as tracker implementations MUST support the "https" URI + scheme [RFC2818] and Transport Layer Security (TLS) [RFC5246]. In + addition, a peer should be cognizant about potential trackers + tracking through queries of peers, e.g., by using HTTP cookies. + PPSTP as specified in this document does not rely on HTTP cookies. + Thus, peers may decide not to return cookies received from the + tracker, in order to make additional tracking more difficult. + + + + + + +Cruz, et al. Standards Track [Page 44] + +RFC 7846 PPSTP May 2016 + + +7. Guidelines for Extending PPSTP + + Extension mechanisms allow designers to add new features or to + customize existing features of a protocol for different operating + environments [RFC6709]. + + Extending a protocol implies either the addition of features without + changing the protocol itself or the addition of new elements creating + new versions of an existing schema and therefore new versions of the + protocol. + + In PPSTP, this means that an extension MUST NOT alter an existing + protocol schema as the changes would result in a new version of an + existing schema, not an extension of an existing schema, typically + non-backwards-compatible. + + Additionally, a designer MUST remember that extensions themselves may + also be extensible. + + Extensions MUST adhere to the principles described in this section in + order to be considered valid. + + Extensions MUST be documented in Standards Track RFCs if there are + requirements for coordination, interoperability, and broad + distribution. + +7.1. Forms of PPSTP Extension + + In PPSTP, two extension mechanisms can be used: a Request-Response + Extension or a Protocol-Level Extension. + + o Request-Response Extension: Adding elements or attributes to an + existing element mapping in the schema is the simplest form of + extension. This form should be explored before any other. This + task can be accomplished by extending an existing element mapping. + + For example, an element mapping for the Statistics Group can be + extended to include additional elements needed to express status + information about the activity of the peer, such as online time + for the stat element. + + o Protocol-Level Extension: If there is no existing element mapping + that can be extended to meet the requirements and the existing + PPSTP request and response message structures are insufficient, + then extending the protocol should be considered in order to + define new operational requests and responses. + + + + + +Cruz, et al. Standards Track [Page 45] + +RFC 7846 PPSTP May 2016 + + + For example, to enhance the level of control and the granularity + of the operations, a new version of the protocol with new messages + (JOIN, DISCONNECT), a retro-compatible change in semantics of an + existing CONNECT request/response, and an extension in STAT_REPORT + could be considered. + + As illustrated in Figure 6, the peer would use an enhanced CONNECT + request to perform the initial registration in the system. Then + it would join a first swarm as SEEDER, later join a second swarm + as LEECH, and then disconnect from the latter swarm but remain as + SEEDER for the first one. When deciding to leave the system, the + peer disconnects gracefully from it: + + +--------+ +---------+ + | Peer | | Tracker | + +--------+ +---------+ + | | + |--CONNECT--------------------->| + |<--------------------------OK--| + |--JOIN(swarm_a;SEEDER)---------->| + |<--------------------------OK--| + : : + |--STAT_REPORT(activity)------->| + |<--------------------------Ok--| + : : + |--JOIN(swarm_b;LEECH)--------->| + |<-----------------OK+PeerList--| + : : + |--STAT_REPORT(ChunkMap_b)----->| + |<--------------------------Ok--| + : : + |--DISCONNECT(swarm_b)--------->| + |<--------------------------Ok--| + : : + |--STAT_REPORT(activity)------->| + |<--------------------------Ok--| + : : + |--DISCONNECT------------------>| + |<---------------------Ok(BYE)--| + + Figure 6: Example of a Session for a PPSTP Extended Version + + + + + + + + + + +Cruz, et al. Standards Track [Page 46] + +RFC 7846 PPSTP May 2016 + + +7.2. Issues to Be Addressed in PPSTP Extensions + + There are several issues that all extensions should take into + consideration. + + o Overview of the Extension: It is RECOMMENDED that extensions to + PPSTP have a protocol overview section that discusses the basic + operation of the extension. The most important processing rules + for the elements in the message flows SHOULD also be mentioned. + + o Backward Compatibility: The new extension MUST be backward + compatible with the base PPSTP specified in this document. + + o Syntactic Issues: Extensions that define new request/response + methods SHOULD use all capitals for the method name, keeping with + a long-standing convention in many protocols, such as HTTP. + Method names are case sensitive in PPSTP. Method names SHOULD be + shorter than 16 characters and SHOULD attempt to convey the + general meaning of the request or response. + + o Semantic Issues: PPSTP extensions MUST clearly define the + semantics of the extensions. Specifically, the extension MUST + specify the behaviors expected from both the peer and the tracker + in processing the extension, with the processing rules in temporal + order of the common messaging scenario. + + Processing rules generally specify actions to be taken on receipt + of messages and expiration of timers. + + The extension SHOULD specify procedures to be taken in exceptional + conditions that are recoverable. Handling of unrecoverable errors + does not require specification. + + o Security Issues: As security is an important component of any + protocol, designers of PPSTP extensions need to carefully consider + security requirements, e.g., authorization requirements and + requirements for end-to-end integrity. + + o Examples of Usage: The specification of the extension SHOULD give + examples of message flows and message formatting and include + examples of messages containing new syntax. Examples of message + flows should be given to cover common cases and at least one + failure or unusual case. + + + + + + + + +Cruz, et al. Standards Track [Page 47] + +RFC 7846 PPSTP May 2016 + + +8. IANA Considerations + +8.1. MIME Type Registry + + This document registers "application/ppsp-tracker+json" media types. + + Type name: application + + Subtype name: ppsp-tracker+json + + Required parameters: n/a + + Optional parameters: n/a + + Encoding considerations: Encoding considerations are identical to + those specified for the "application/json" media type. See + [RFC7159]. + + Security considerations: See Section 6 of RFC 7846. + + Interoperability considerations: This document specifies the format + of conforming messages and the interpretation thereof. + + Published specification: RFC 7846. + + Applications that use this media type: PPSP trackers and peers + either stand alone or are embedded within other applications. + + Additional information: + + Magic number(s): n/a + + File extension(s): n/a + + Macintosh file type code(s): n/a + + Fragment identifier considerations: n/a + + Person & email address to contact for further information: See + Authors' Addresses section. + + Intended usage: COMMON + + Restrictions on usage: none + + Author: See Authors' Addresses section of RFC 7846. + + Change controller: IESG (iesg@ietf.org) + + + +Cruz, et al. Standards Track [Page 48] + +RFC 7846 PPSTP May 2016 + + +8.2. PPSTP Version Number Registry + + IANA has created the "PPSTP Version Number Registry". Values are + integers in the range 0-255, with initial assignments and + reservations given in Table 2. New PPSTP version types are assigned + after IETF Review [RFC5226] to ensure that proper documentation + regarding the new version types and their usage has been provided. + +8.3. PPSTP Request Type Registry + + IANA has created the "PPSTP Request Type Registry". Values are + strings listed in Table 8. New PPSTP request types are assigned + after IETF Review [RFC5226] to ensure that proper documentation + regarding the new request types and their usage has been provided. + + +----------------------+-------------------------------------------+ + | request_type | Description | + +----------------------+-------------------------------------------+ + | "CONNECT" | Returns information about the successful | + | | registration of the peer and/or of each | + | | swarm action requested. May additionally | + | | return the list of peers corresponding to | + | | the action attribute | + | | requested. | + | | | + | "FIND" | Returns the list of peers corresponding | + | | to the requested scope. | + | | | + | "STAT_REPORT" | Confirms the success of the requested | + | | operation. | + +----------------------+-------------------------------------------+ + + Table 8: The PPSTP Request Type Registry + + + + + + + + + + + + + + + + + + +Cruz, et al. Standards Track [Page 49] + +RFC 7846 PPSTP May 2016 + + +8.4. PPSTP Error Code Registry + + IANA has created the "PPSTP Error Code Registry". Values are the + strings listed in Table 9. New PPSTP error codes are assigned after + IETF Review [RFC5226] to ensure that proper documentation regarding + the new error codes and their usage has been provided. + + +---------------+-------------------------------------------+ + | error_code | Description | + +---------------+-------------------------------------------+ + | 00 | No Error | + | 01 | Bad Request | + | 02 | Unsupported Version Number | + | 03 | Forbidden Action | + | 04 | Internal Server Error | + | 05 | Service Unavailable | + | 06 | Authentication Required | + +---------------+-------------------------------------------+ + + Table 9: The PPSTP Error Code Registry + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Cruz, et al. Standards Track [Page 50] + +RFC 7846 PPSTP May 2016 + + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, + DOI 10.17487/RFC2818, May 2000, + <http://www.rfc-editor.org/info/rfc2818>. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November + 2003, <http://www.rfc-editor.org/info/rfc3629>. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, RFC + 3986, DOI 10.17487/RFC3986, January 2005, + <http://www.rfc-editor.org/info/rfc3986>. + + [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment + (ICE): A Protocol for Network Address Translator (NAT) + Traversal for Offer/Answer Protocols", RFC 5245, + DOI 10.17487/RFC5245, April 2010, + <http://www.rfc-editor.org/info/rfc5245>. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + <http://www.rfc-editor.org/info/rfc5246>. + + [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, + "Session Traversal Utilities for NAT (STUN)", RFC 5389, + DOI 10.17487/RFC5389, October 2008, + <http://www.rfc-editor.org/info/rfc5389>. + + [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem + for the Simple Network Management Protocol (SNMP)", STD + 78, RFC 5590, DOI 10.17487/RFC5590, June 2009, + <http://www.rfc-editor.org/info/rfc5590>. + + [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal + Using Relays around NAT (TURN): Relay Extensions to + Session Traversal Utilities for NAT (STUN)", RFC 5766, + DOI 10.17487/RFC5766, April 2010, + <http://www.rfc-editor.org/info/rfc5766>. + + + +Cruz, et al. Standards Track [Page 51] + +RFC 7846 PPSTP May 2016 + + + [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 + Address Text Representation", RFC 5952, + DOI 10.17487/RFC5952, August 2010, + <http://www.rfc-editor.org/info/rfc5952>. + + [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., + Ed., and A. Bierman, Ed., "Network Configuration Protocol + (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, + <http://www.rfc-editor.org/info/rfc6241>. + + [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", + RFC 6749, DOI 10.17487/RFC6749, October 2012, + <http://www.rfc-editor.org/info/rfc6749>. + + [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) + Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, + March 2014, <http://www.rfc-editor.org/info/rfc7159>. + + [RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext + Transfer Protocol (HTTP/1.1): Message Syntax and + Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, + <http://www.rfc-editor.org/info/rfc7230>. + + [RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext + Transfer Protocol (HTTP/1.1): Semantics and Content", RFC + 7231, DOI 10.17487/RFC7231, June 2014, + <http://www.rfc-editor.org/info/rfc7231>. + + [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, + S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, + "Application-Layer Traffic Optimization (ALTO) Protocol", + RFC 7285, DOI 10.17487/RFC7285, September 2014, + <http://www.rfc-editor.org/info/rfc7285>. + + [RFC7574] Bakker, A., Petrocco, R., and V. Grishchenko, "Peer-to- + Peer Streaming Peer Protocol (PPSPP)", RFC 7574, + DOI 10.17487/RFC7574, July 2015, + <http://www.rfc-editor.org/info/rfc7574>. + + [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP + Digest Access Authentication", RFC 7616, + DOI 10.17487/RFC7616, September 2015, + <http://www.rfc-editor.org/info/rfc7616>. + + + + + + + + +Cruz, et al. Standards Track [Page 52] + +RFC 7846 PPSTP May 2016 + + +9.2. Informative References + + [Contracts] Piatek, M., Krishnamurthy, A., Venkataramani, A., Yang, + R., Zhang, D., and A. Jaffe, "Contracts: Practical + Contribution Incentives for P2P Live Streaming", NSDI: + USENIX Symposium on Networked Systems Design and + Implementation, April 2010. + + [RFC2564] Kalbfleisch, C., Krupczak, C., Presuhn, R., and J. + Saperia, "Application Management MIB", RFC 2564, + DOI 10.17487/RFC2564, May 1999, + <http://www.rfc-editor.org/info/rfc2564>. + + [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC + 2790, DOI 10.17487/RFC2790, March 2000, + <http://www.rfc-editor.org/info/rfc2790>. + + [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to + Accounting Management", RFC 2975, DOI 10.17487/RFC2975, + October 2000, <http://www.rfc-editor.org/info/rfc2975>. + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, + DOI 10.17487/RFC3410, December 2002, + <http://www.rfc-editor.org/info/rfc3410>. + + [RFC3729] Waldbusser, S., "Application Performance Measurement + MIB", RFC 3729, DOI 10.17487/RFC3729, March 2004, + <http://www.rfc-editor.org/info/rfc3729>. + + [RFC4022] Raghunarayan, R., Ed., "Management Information Base for + the Transmission Control Protocol (TCP)", RFC 4022, + DOI 10.17487/RFC4022, March 2005, + <http://www.rfc-editor.org/info/rfc4022>. + + [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally + Unique IDentifier (UUID) URN Namespace", RFC 4122, + DOI 10.17487/RFC4122, July 2005, + <http://www.rfc-editor.org/info/rfc4122>. + + [RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics + MIB", RFC 4150, DOI 10.17487/RFC4150, August 2005, + <http://www.rfc-editor.org/info/rfc4150>. + + + + + + + +Cruz, et al. Standards Track [Page 53] + +RFC 7846 PPSTP May 2016 + + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + <http://www.rfc-editor.org/info/rfc5226>. + + [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI + 10.17487/RFC5424, March 2009, + <http://www.rfc-editor.org/info/rfc5424>. + + [RFC5706] Harrington, D., "Guidelines for Considering Operations + and Management of New Protocols and Protocol Extensions", + RFC 5706, DOI 10.17487/RFC5706, November 2009, + <http://www.rfc-editor.org/info/rfc5706>. + + [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design + Considerations for Protocol Extensions", RFC 6709, + DOI 10.17487/RFC6709, September 2012, + <http://www.rfc-editor.org/info/rfc6709>. + + [RFC6972] Zhang, Y. and N. Zong, "Problem Statement and + Requirements of the Peer-to-Peer Streaming Protocol + (PPSP)", RFC 6972, DOI 10.17487/RFC6972, July 2013, + <http://www.rfc-editor.org/info/rfc6972>. + + [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, + "Recommendations for Secure Use of Transport Layer + Security (TLS) and Datagram Transport Layer Security + (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May + 2015, <http://www.rfc-editor.org/info/rfc7525>. + + [SARACEN] Sarecen P2P, <http://www.saracen-p2p.eu/>. + +Acknowledgments + + The authors appreciate the contributions made by Yingjie Gu in the + early stages of the specification. Also, they thank the following + people for their help and comments: Zhang Yunfei, Liao Hongluan, Roni + Even, Dave Cottlehuber, Bhumip Khasnabish, Wu Yichuan, Peng Jin, Chi + Jing, Zong Ning, Song Haibin, Chen Wei, Zhijia Chen, Christian + Schmidt, Lars Eggert, David Harrington, Henning Schulzrinne, Kangheng + Wu, Martin Stiemerling, Jianyin Zhang, Johan Pouwelse, Riccardo + Petrocco, and Arno Bakker. + + 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 [SARACEN], the European Commission, Huawei, or + China Mobile. + + + +Cruz, et al. Standards Track [Page 54] + +RFC 7846 PPSTP May 2016 + + +Authors' Addresses + + 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 + + + Jinwei Xia + Huawei + Nanjing, Baixia District 210001 + China + Phone: +86-025-86622310 + Email: xiajinwei@huawei.com + + + Rachel Huang (editor) + Huawei + Email: rachel.huang@huawei.com + + + Joao P. Taveira + IST/INOV + Email: joao.silva@inov.pt + + + Deng Lingli + China Mobile + Email: denglingli@chinamobile.com + + + + + + + + + + + + + +Cruz, et al. Standards Track [Page 55] + |