PPSP Tracker Protocol-Base Protocol (PPSP-TP/1.0)
draft-ietf-ppsp-base-tracker-protocol-06
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7846.
|
|
|---|---|---|---|
| Authors | Rui António dos Santos Cruz , Mario Sera Nunes , Gu Yingjie , Jinwei Xia , Joao P. Taveira , Deng Lingli | ||
| Last updated | 2014-10-27 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
OPSDIR Last Call review
(of
-10)
by Nevil Brownlee
Serious Issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 7846 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Martin Stiemerling | ||
| Send notices to | ppsp-chairs@tools.ietf.org, draft-ietf-ppsp-base-tracker-protocol@tools.ietf.org |
draft-ietf-ppsp-base-tracker-protocol-06
PPSP Rui S. Cruz
INTERNET-DRAFT Mario S. Nunes
Intended Status: Standards Track IST/INESC-ID/INOV
Expires: April 30, 2015 Yingjie Gu
Jinwei Xia
Rachel Huang
Huawei
Joao P. Taveira
IST/INOV
Deng Lingli
China Mobile
October 27, 2014
PPSP Tracker Protocol-Base Protocol (PPSP-TP/1.0)
draft-ietf-ppsp-base-tracker-protocol-06
Abstract
This document specifies the base Peer-to-Peer Streaming Protocol-
Tracker Protocol (PPSP-TP/1.0), 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, and describes message flows,
message processing instructions, message formats, formal syntax and
semantics. The PPSP Tracker Protocol enables cooperating peers to
form content streaming overlay networks to support near real-time
Structured Media content delivery (audio, video, 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 Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Cruz, et al. Expires April 30, 2015 [Page 1]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Operation and Protocol Architecture Overview . . . . . . . . . 7
2.1 Operation . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Enrollment and Bootstrap . . . . . . . . . . . . . . . . . 8
2.3 Architectural and Functional View . . . . . . . . . . . . . 10
2.3.1 Messaging Model . . . . . . . . . . . . . . . . . . . . 11
2.3.2 Request/Response model . . . . . . . . . . . . . . . . 11
2.4 State Machines and Flows of the Protocol . . . . . . . . . 12
2.4.1 Normal Operation . . . . . . . . . . . . . . . . . . . 14
2.4.2 Error Conditions . . . . . . . . . . . . . . . . . . . 15
3 Presentation Language . . . . . . . . . . . . . . . . . . . . . 16
3.1 Generalization of String and Integer Protocol Element
Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Enumerated Types . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Contructed Types . . . . . . . . . . . . . . . . . . . . . . 17
3.5 Protocol Representations for Extensibility . . . . . . . . . 18
4 Protocol Specification . . . . . . . . . . . . . . . . . . . . 19
4.1 Request/Response Syntax and Semantics . . . . . . . . . . . 19
4.2 Response element in response Messages . . . . . . . . . . . 24
5 Request/Response Processing . . . . . . . . . . . . . . . . . . 24
Cruz, et al. Expires April 30, 2015 [Page 2]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
5.1 CONNECT Request . . . . . . . . . . . . . . . . . . . . . . 25
5.2 FIND Request . . . . . . . . . . . . . . . . . . . . . . . 27
5.3 STAT_REPORT Request . . . . . . . . . . . . . . . . . . . . 28
5.4 Error and Recovery conditions . . . . . . . . . . . . . . . 29
6 Operations and Manageability . . . . . . . . . . . . . . . . . 30
6.1 Operational Considerations . . . . . . . . . . . . . . . . 30
6.1.1 Installation and Initial Setup . . . . . . . . . . . . 30
6.1.2 Migration Path . . . . . . . . . . . . . . . . . . . . 31
6.1.3 Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . 31
6.1.4 Impact on Network Operation . . . . . . . . . . . . . . 31
6.1.5 Verifying Correct Operation . . . . . . . . . . . . . . 31
6.2 Management Considerations . . . . . . . . . . . . . . . . . 31
6.2.1 Interoperability . . . . . . . . . . . . . . . . . . . 32
6.2.2 Management Information . . . . . . . . . . . . . . . . 32
6.2.3 Fault Management . . . . . . . . . . . . . . . . . . . 32
6.2.4 Configuration Management . . . . . . . . . . . . . . . 32
6.2.5 Accounting Management . . . . . . . . . . . . . . . . . 33
6.2.6 Performance Management . . . . . . . . . . . . . . . . 33
6.2.7 Security Management . . . . . . . . . . . . . . . . . . 33
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 33
7.1 Authentication between Tracker and Peers . . . . . . . . . 34
7.2 Content Integrity protection against polluting
peers/trackers . . . . . . . . . . . . . . . . . . . . . . 34
7.3 Residual attacks and mitigation . . . . . . . . . . . . . . 34
7.4 Pro-incentive parameter trustfulness . . . . . . . . . . . 35
8 Guidelines for Extending PPSP-TP . . . . . . . . . . . . . . . 35
8.1 Forms of PPSP-TP Extension . . . . . . . . . . . . . . . . 36
8.2 Issues to Be Addressed in PPSP-TP Extensions . . . . . . . 37
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 38
10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1 Normative References . . . . . . . . . . . . . . . . . . . 39
11.2 Informative References . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Cruz, et al. Expires April 30, 2015 [Page 3]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
1 Introduction
The Peer-to-Peer Streaming Protocol (PPSP) is composed of two
protocols: the PPSP Tracker Protocol and the PPSP Peer Protocol. RFC
6972 [RFC6972] specifies that the Tracker Protocol should standardize
the messages between PPSP peers and PPSP trackers and also defines
the requirements.
The PPSP Tracker Protocol 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 that PPSP peers 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 content registration and location.
The signaling and the media data transfer between PPSP peers is not
in the scope of this specification.
This document describes the base PPSP Tracker protocol and how it
satisfies the requirements for the IETF Peer-to-Peer Streaming
Protocol, in order to derive the implications for the standardization
of the PPSP streaming protocols and to identify open issues and
promote further discussion.
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 RFC 2119 [RFC2119].
ABSOLUTE TIME: Absolute time is expressed as ISO 8601 timestamps,
using zero UTC offset (GMT). Fractions of a second may be indicated.
Example for December 25, 2010 at 14h56 and 20.25 seconds: basic
format 20101225T145620.25Z or extended format 2010-12-
25T14:56:20.25Z.
CHUNK: A Chunk is a 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, and is described in the MPD.
TRACKER: A TRACKER refers to a directory service that maintains a
list of PEERs participating in a specific audio/video channel or in
Cruz, et al. Expires April 30, 2015 [Page 4]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
the distribution of a streaming file. PEERs interact with a TRACKER
for requests like PEER LIST queries. The TRACKER is a logical
component which can be centralized or distributed.
CONNECTION TRACKER: The node running the tracker service to which
the PPSP peer will connect when it wants to get registered and join
the PPSP system.
LEECHER: A Peer that has not yet completed the transfer of all
Chunks of the media content.
LIVE STREAMING: It refers to a scenario where all the audiences
receive streaming content for the same ongoing event. It is desired
that the lags between the play points of the audiences and streaming
source be small.
MEDIA PRESENTATION DESCRIPTION (MPD): 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.
METHOD: The method is the primary function that a request from a
peer is meant to invoke on a tracker. The method is carried in the
request message itself.
ONLINE TIME: Online Time shows how long the peer has been in the P2P
streaming system since it joined. This value indicates the stability
of a peer, and can be calculated by the tracker whenever necessary.
PEER: A PEER refers to 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 by using its ID. The Peer ID is
mandatory, can take the form of a universal 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 which are in a same SWARM maintained by
the TRACKER. A PEER can fetch the PEER LIST of a SWARM from the
TRACKER or from other PEERs in order to know which PEERs have the
required streaming content.
PPSP: The abbreviation of Peer-to-Peer Streaming Protocols. PPSP
Cruz, et al. Expires April 30, 2015 [Page 5]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
refer to the primary signaling protocols among various P2P streaming
system components, including the TRACKER and the PEER.
PPSP-TP: The abbreviation of Peer-to-Peer Streaming Protocols -
Tracker Protocol.
REPRESENTATION: Structured collection of one or more media
components.
REQUEST: A message sent from a peer to a tracker, for the purpose of
invoking a particular operation.
RESPONSE: A message sent from a tracker to a peer, for indicating
the status of a request sent from the peer to the tracker.
SEEDER: A Peer that holds and shares the complete media content.
SWARM: A SWARM refers to a group of PEERs who 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 a common streaming content. The Swarm-ID may use a universal
unique identifier (UUID), e.g., a 64 or 128 bit datum to refer to the
content resource being shared among peers.
SUPER-NODE: A SUPER-NODE is a special kind of PEER deployed by ISPs.
This kind of PEER is more stable with higher computing, storage and
bandwidth capabilities than normal PEERs.
TRANSACTION ID: The identifier of a REQUEST from the PEER to the
TRACKER. Used to disambiguate RESPONSES that may arrive in a
different order of the corresponding REQUESTs.
VIDEO-ON-DEMAND (VoD): It refers to a scenario where different
audiences may watch different parts of the same recorded streaming
with downloaded content.
SERVICE PORTAL: A logical entity typically used for client enrollment
and content information publishing, searching and retrieval. It is
usually located in a server of content provider.
Cruz, et al. Expires April 30, 2015 [Page 6]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
2 Operation and Protocol Architecture Overview
2.1 Operation
The functional entities related to PPSP 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 not in the scope the specification. The
functional entities directly involved in the PPSP Tracker Protocol
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 contents. The Client
Media Player may interface with the local peer application using
request and response standard formats for HTTP Request and Response
messages [RFC2616].
A Peer corresponds to a logical entity (typically in a user device)
that actually participates in sharing a media content. Peers are
organized in (various) swarms corresponding each swarm to the group
of peers streaming a certain content at any given time.
The 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, and in this document it will be treated as a single logical
entity.
The Tracker Protocol 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.
When a peer wants to receive streaming of a selected content (Leech
mode):
1. Peer connects to a connection tracker and joins a swarm.
2. Peer acquires a list of other peers in the swarm from the
connection tracker.
3. [Peer Protocol] Peer exchanges its content availability with the
peers on the obtained peer list.
4. [Peer Protocol] Peer identifies the peers with desired content. 5.
[Peer Protocol] Peer requests content from the identified peers.
Cruz, et al. Expires April 30, 2015 [Page 7]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
When a peer wants to share streaming contents (Seeder mode) with
other peers:
1. Peer connects to the connection tracker.
2. Peer sends information to the connection tracker about the swarms
it belongs to (joined swarms).
After having been disconnected due to some termination condition, a
peer can resume previous activity by connecting and re-joining the
corresponding swarm(s).
2.2 Enrollment and Bootstrap
In order to be able to bootstrap in the P2P network, a peer must
first obtain a Peer ID (identifier of the peer) and any required
security certificates or authorization tokens from an enrollment
service (end-user registration). The specification of the format of
the Peer ID is not in the scope of this document.
+--------+ +--------+ +--------+ +---------+ +--------+
| 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 a content.
To join an existing P2P streaming service and to participate in
content sharing, any peer must first locate a tracker.
Cruz, et al. Expires April 30, 2015 [Page 8]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
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 LEECHER.
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 (that can be grouped by tiers of
priority) which are controlling 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.
The PPSP streaming session is then started (or resumed) at Peer_1 by
sending a PPSP-TP 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 onwards every chunk request is addressed by
Peer_1 to its neighbors (Peer_2 in Figure 1) using the PPSP Peer
Protocol, 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 PPSP-TP STAT_REPORT message.
If Peer_1 needs to refresh its neighborhood (for example, due to
churn) it will send a PPSP-TP FIND message (with the desired scope)
to the tracker.
Peers that are only SEEDERs (i.e., serving contents to other peers),
as are the typical cases of service provider P2P edge caches and/or
Media Servers, trigger their P2P streaming sessions for contents 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 PPSP-TP CONNECT
message to the tracker, in order to "join" all the requested swarms
(Figure 2).
Periodically, the peer also report its status and statistics data to
the tracker using a PPSP-TP STAT_REPORT message.
+---------+ +---------+
| Seeder | | Tracker |
+---------+ +---------+
Cruz, et al. Expires April 30, 2015 [Page 9]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
| |
Start->|--CONNECT (join x,y,z)-------->|
|<--------------------------OK--|
: :
| |
|--STAT_REPORT----------------->|
|<--------------------------Ok--|
: :
| |
|--STAT_REPORT----------------->|
|<--------------------------Ok--|
: :
Figure 2: A typical PPSP session for a streaming Seeder.
The specification of the mechanisms used by the Client Media Player
(or provisioning process) and the peer to signal start/resume streams
or request media chunks, obtain a Peer ID, security certificates or
tokens are not in the scope of this document.
2.3 Architectural and Functional View
The PPSP Tracker Protocol architecture is intended to be compatible
with the web infrastructure. PPSP-TP is designed with a layered
approach i.e., a PPSP-TP Request/Response layer, a Message layer and
a Transport layer. The PPSP-TP Request/Response layer deals with the
interactions between tracker and peers using Request and Response
codes (see Figure 3).
+----------------------+
| Application |
+----------------------+
| Request/Response | PPSP-TP
+----------------------+
| (HTTP) Message |
+----------------------+
| TRANSPORT |
+----------------------+
Figure 3: Abstract layering of PPSP-TP.
The Message layer deals with the framing format, for encoding and
transmitting the 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
Cruz, et al. Expires April 30, 2015 [Page 10]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
determination of the connection to use for a request or response
message when using a connection-oriented transport like TCP
[RFC0793], or TLS [RFC5246].
2.3.1 Messaging Model
The messaging model of PPSP-TP aligns with HTTP protocol and the
semantics of its messages, currently in version 1.1 [RFC2616], but
intended to support future versions of HTTP. The exchange of
messages of PPSP-TP is envisioned to be performed over a stream-
oriented reliable transport protocol, like TCP [RFC0793].
2.3.2 Request/Response model
PPSP-TP messages 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 which correspond to either HTTP request methods or HTTP
response codes, respectively.
Requests are sent, and responses returned to these requests. A
single request generates a single response (neglecting fragmentation
of messages in transport).
The response codes are consistent with HTTP response codes, however,
not all HTTP response codes are used for the PPSP-TP (Section 3).
The Request Messages of the base protocol are listed in Table 1:
+---------------+
| PPSP-TP/1.0 |
| Req. Messages |
+---------------+
| CONNECT |
| FIND |
| STAT_REPORT |
+---------------+
Table 1: Request Messages
CONNECT: This Request message is an "action signal" used when a peer
registers in the tracker (or if already registered) to
notify it about the participation in 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
Cruz, et al. Expires April 30, 2015 [Page 11]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
peers lists of the corresponding swarm(s) for the requester
Peer ID. On receiving a CONNECT message, the tracker first
checks the peer mode type (SEED/LEECH) for the specified
swarm(s) and then decides the next steps (more details are
referred in section 4.1)
FIND: This Request message is an "action signal" used by peers to
send to the tracker, whenever needed, a list of peers
active in the named swarm. On receiving a FIND message,
the tracker finds the peers, listed in content status of
the specified swarm that can satisfy the requesting peer's
requirements, returning the list to the requesting peer. To
create the peer list, the tracker may take peer status,
capabilities and peers priority into consideration. Peer
priority may be determined by network topology preference,
operator policy preference, etc.
STAT_REPORT: This Request message is an "information signal" that
allows 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.4 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 the INIT state.
When the "first" peer connects for registration 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 the STARTED state. When the "last" Peer ID is removed, the state
machine transitions to TERMINATED. From there, it immediately
transitions back to the INIT state. Because of that, the TERMINATED
state here is transient.
Cruz, et al. Expires April 30, 2015 [Page 12]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
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.
--------------------------------------------
/ \
| +------------+ +=========+ +======+ |
\-| TERMINATED |<---| STARTED |<---| INIT |<-/
+------------+ +=========+ +======+
(Transient) | (1) \- (start tracker)
V
+-----------+ +-------+ rcv CONNECT
(Transient) | TERMINATE | | START | --------------- (1)
+-----------+ +-------+ strt init timer
rcv FIND ^ |
rcv STAT_REPORT | |
on registration error | v
on action error | +------------+
---------------- (A) +<-----| PEER | (Transient)
stop init timer | | REGISTERED |
snd error | +------------+
| |
| | process swarm actions
| | --------------------- (2)
on CONNECT Error (B) | | snd OK (PeerList)
on timeout (C) | / stop init timer
---------------- | / strt track timer
stop track timer | /
clean peer info | |
del registration | | rcv FIND
snd error (B) \ | ---- --------------- (3)
---- \ | / \ snd OK (PeerList)
/ \ \ | | | rst track timer
rcv CONNECT | (4) | | | | |
----------- | v | v v | rcv STAT_REPORT
snd OK \ +==============+ / --------------- (3)
rst track timer ----| TRACKING |---- snd OK response
+==============+ rst track timer
Figure 5: Per-Peer-ID Transaction State Machine and Flow Diagram
Unlike the tracker state machine, which exists even when no Peer IDs
are registered, the "per-Peer-ID" transaction 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" transaction
state machine once it enters the TERMINATE state (Figure 5).
Cruz, et al. Expires April 30, 2015 [Page 13]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
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.
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" transaction 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, or
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.4.1 Normal Operation
On normal operation the process consists of the following steps:
1) When a Peer wants to access the system it needs to register on a
tracker by sending a CONNECT message asking for the swarm(s) it
wants to join. This CONNECT 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" SM, the tracker
initiates the registration of the Peer ID and associated
information (IP addresses), starts the "init timer" and moves to
PEER REGISTERED state.
2) In PEER REGISTERED state, if Peer ID is valid, the tracker either
a) processes the requested action(s) for the valid swarm
information contained in the CONNECT request and in case of
success 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 are respectively
responded with a) a successful condition, b) a successful
condition containing the appropriate list of peers for the named
swarm (section 4.2).
Cruz, et al. Expires April 30, 2015 [Page 14]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
4) While TRACKING, a CONNECT message received from that Peer ID with
valid swarm actions information (section 4.1) resets the "track
timer" and is responded with a successful condition.
2.4.2 Error Conditions
Peers MUST NOT generate protocol elements that are invalid.
However, several situations of a peer may lead to abnormal
conditions in the interaction with the tracker. The situations
may be related with peer malfunction or communications errors. The
tracker reacts to the abnormal situations depending on its current
state related to a Peer ID, as follows:
A) At PEER REGISTERED state, when a CONNECT Request only contains
invalid swarm actions (section 4.1), the tracker responds with
error code 403 Forbidden, deletes the registration, transition to
TERMINATE state for that Peer ID and the SM is destroyed.
At the 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 error codes 401 Unauthorized or 403
Forbidden (described in section 4.4), transitions to TERMINATE
state for that Peer ID and the SM is destroyed.
B) At the TRACKING state (while the "track timer" has not expired)
receiving a CONNECT message from that Peer ID with invalid swarm
actions (section 4.1) is considered an error condition. The
tracker responds with error code 403 Forbidden (described in
section 3), stops the "track timer", deletes the registration,
transitions to TERMINATE state for that Peer ID and the SM is
destroyed.
C) In TRACKING state, without receiving messages from the peer, on
timeout (track timer) the tracker cleans all the information
associated with the Peer ID in all swarms it was joined, deletes
the registration, transitions to TERMINATE state for that Peer ID
and and the SM is destroyed.
NOTE: These situations may correspond to a malfunction at the peer
or to malicious conditions. Therefore, as preventive measure, the
tracker proceeds to TERMINATE state for the Peer ID by de-registering
the peer and cleaning all peer information.
Cruz, et al. Expires April 30, 2015 [Page 15]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
3 Presentation Language
In this document, only the syntax and format of the PPSP-TP messages
are defined, and here, a C-like syntax, similar to the presentation
language used to defined TLS [RFC5246] was also adopted, but using a
generalization for the definition of protocol elements and fields,
their types and structures, turning it extensible. The purpose of
this C-like presentation language is to document PPSP-TP only.
In this presentation language, comments begin with "//". The basic
numeric data type is an unsigned byte (uint8_t), and larger numeric
data types (uint16_t, uint32_t, etc.) are formed from concatenated
fixed-length series of bytes, also unsigned. For a binary encoding,
all integer fields are carried in network byte order, i.e., most
significant octet first.
3.1 Generalization of String and Integer Protocol Element Types
The generalization of string and integer values allows the definition
of types for different protocol elements (section 3.5). For this
purpose the following element types were defined:
PPSP-TP String type: ppsp_tp_string_t
PPSP-TP Integer type: ppsp_tp_integer_t
The following examples illustrate the concrete assignments for
different encoding representations of these generalized types.
For example, in a text-based encoding, like XML, the elements <ASN>
is defined as of type ppsp_tp_string_t (a string).
ppsp_tp_string_t -> String
e.g., "<ASN>AS1234</ASN>" // element <ASN> is string
Similarly, the element <Priority> or the attribute @priority are
defined as of type ppsp_tp_integer_t (integers).
ppsp_tp_integer_t -> Integer
e.g., "<Priority>10</Priority>" // element <Priority> is integer
e.g., "... priority='10'" // attribute @priority is integer
For a binary-type encoding representation, the same element ASN would
be represented as a char array:
ppsp_tp_string_t -> char *
e.g., "AS1234 "
Cruz, et al. Expires April 30, 2015 [Page 16]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
Similarly, the element Priority or the attribute @port of an IP
address are defined as uintXX_t:
ppsp_tp_integer_t -> uint8_t
e.g., Priority value: 0x0A // represented in hexadecimal
ppsp_tp_integer_t -> uint16_t
e.g., port value: 8088 // represented in decimal
3.2 Constants
Typed constants can be defined by declaring a symbol of the desired
type and assigning values to it.
3.3 Enumerated Types
A field of type "enum" can only assume the values declared in its
definition, and every element of an enumerated type must be assigned
with a unique value, in any order. Only "enum" fields of the same
type may be assigned or compared.
enum { e1(v1), e2(v2), ... , en(vn) } type_name;
The names of the elements of an enumeration are scoped within the
defined type.
3.4 Contructed Types
Similarly to enumerated types, fields of type "struct" can be
constructed from primitive types and each definition declares a new
and unique type.
struct {
s1 e1;
s2 e2;
...
sn en;
} type_name;
The names of the elements of a "struct" are scoped within the defined
type. The elements within a "struct" field may be qualified using the
name of the type with a syntax similar to the enumerated type.
Cruz, et al. Expires April 30, 2015 [Page 17]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
To allow extensibility in the specification some structures must be
identified using a well known code, e.g., STREAM_STATS = 0x01:
typedef enum {
STREAM_STATS = 0x01
} ppsp_tp_stat_type_t;
For those extensible element types, the protocol implementer can be
able to access the data of the specified structure from its type
code.
3.5 Protocol Representations for Extensibility
The concept of concrete specification of Protocol Representations,
i.e, the type CONCRETE_PROTO_SPEC_DEPENDENT, allows any concrete
specification of the protocol to define the best representation to a
data type.
For example, to represent the ppsp_tp_peer_protocol_t type (PPSP Peer
Protocol) in a PeerAddress "struct" field, several representations
can be chosen, such as:
typedef CONCRETE_PROTO_SPEC_DEPENDENT ppsp_tp_peer_protocol_t;
- IANA protocol assigned number: uint8_t
- Formally defined integer (uint8_t) enumeration:
PPSPPPv1=1, PPSPPPv2=2, WS=3, ...
- Formally defined string (char *):
"PPSPPPv1", "PPSPPPv2", "WebSocket", "MP4Box", ...
Another example is the generalized definition of integer and string
type elements for PPSP-TP, as already described in Section 3.1:
typedef CONCRETE_PROTO_SPEC_DEPENDENT ppsp_tp_string_t;
typedef CONCRETE_PROTO_SPEC_DEPENDENT ppsp_tp_integer_t;
Cruz, et al. Expires April 30, 2015 [Page 18]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
4 Protocol Specification
PPSP-TP is a message-oriented request/response protocol. The
messages can be encoded using binary type or text type, which can be
indicated in the Content-Type field in HTTP/1.1 [RFC2616], but that
definition is not in the scope of this specification.
4.1 Request/Response Syntax and Semantics
The generic format of a PPSP-TP Request is the following:
typedef struct {
ppsp_tp_version_t version;
ppsp_tp_request_type_t type;
ppsp_tp_transaction_id_t id;
ppsp_tp_peer_id_t peer_id;
union {
struct {
ppsp_tp_peer_num_t peer_num;
ppsp_tp_peer_info_t peer_info;
ppsp_tp_swarm_action_t swarm_actions[];
} connect;
struct {
ppsp_tp_peer_num_t peer_num;
} find;
struct {
ppsp_tp_stat_t stats[];
} stat_report;
} request_data;
} ppsp_tp_request;
The generic format of a PPSP-TP Response is the following:
typedef struct {
ppsp_tp_version_t version;
ppsp_tp_response_type_t type;
ppsp_tp_transaction_id_t id;
ppsp_tp_swarm_action_result_t results[];
ppsp_tp_peer_info_t peers[];
} ppsp_tp_response;
The Request element MUST be present in requests and corresponds to
the request method type for the message.
Cruz, et al. Expires April 30, 2015 [Page 19]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
The request type includes CONNECT, FIND and STAT_REPORT, defined as
follows:
typedef enum ppsp_tp_request_type {
PPSP_TP_CONNECT = 0x02, // or "CONNECT"
PPSP_TP_FIND = 0x04, // or "FIND"
PPSP_TP_STAT_REPORT = 0x08 // or "STAT_REPORT"
} ppsp_tp_request_type_t;
The Response element MUST be present in responses and corresponds to
the response method type of the message, defined as follows:
typedef enum ppsp_tp_response_type {
PPSP_TP_SUCCESSFUL = 0x00, // or "SUCCESSFUL"
PPSP_TP_AUTH_REQUIRED = 0x01 // or "AUTH_REQUIRED"
} ppsp_tp_response_type_t;
The element Transaction_ID MUST be present in requests to uniquely
identify the transaction. Responses to completed transactions use
the same TransactionID as the request they correspond to.
The element SwarmID MUST be present in in CONNECT and FIND Requests
and SHOULD be present in STAT_REPORT Requests to identify the actions
to be taken in the specified swarms or the related statistics
information.
The version of PPSP-TP being used is indicated by the attribute
@version.
All Request messages MUST contain a Peer_Info element to uniquely
identify the requesting peer in the network. It includes the
Peer_ID, IP addresses and ports, with a few optional attributes.
The PeerNum element MAY be present in CONNECT and FIND requests and
MAY contain the attribute @abilityNAT to inform the tracker on the
preferred type of peers, in what concerns their NAT traversal
situation, to be returned in a peer list.
If STUN-like functions are enabled in the tracker and a PPSP-ICE
method [RFC5245] is used the attributes @type and @priority MUST be
returned with the transport address candidates in responses to
CONNECT requests.
The @asn attribute MAY be used to inform about the network location,
in terms of Autonomous System, for each of the active public network
interfaces of the peer. The @connection attribute is informative on
the type of access network of the respective interface.
Cruz, et al. Expires April 30, 2015 [Page 20]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
The semantics of the above elements and attributes are defined as
follows:
typedef CONCRETE_PROTO_SPEC_DEPENDENT unique_id_t;
typedef unique_id_t ppsp_tp_transaction_id_t;
typedef unique_id_t ppsp_tp_swarm_id_t;
typedef unique_id_t ppsp_tp_peer_id_t;
typedef struct {
ppsp_tp_transaction_id_t action_id;
ppsp_tp_response_type_t response_type;
} ppsp_tp_swarm_action_result_t;
typedef enum ppsp_tp_versions {
PPSP_TP_BASE = 0x10, // or "1.0"
} ppsp_tp_version_t;
typedef struct {
ppsp_tp_integer_t peer_count;
enum {
NO_NAT,
STUN,
TURN,
PROXY
} ability_nat;
enum {
NORMAL,
LOW,
HIGH
} concurrent_links;
enum {
NORMAL,
HIGH
} online_time;
enum {
NORMAL,
HIGH
} upload_bandwidth_level;
} ppsp_tp_peer_num_t;
Cruz, et al. Expires April 30, 2015 [Page 21]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
typedef struct {
enum {
IPV4,
IPV6
} addr_type;
CONCRETE_PROTO_SPEC_DEPENDENT address;
// string, addr_in4,
// addr_in6, addr_storage
CONCRETE_PROTO_SPEC_DEPENDENT port;
// string (IANA service port),
// or uint16 (service port)
ppsp_tp_integer_t priority;
enum {
HOST,
REFLEXIVE,
PROXY
} type;
enum {
3G,
ADSL,
LTE,
ETHER
} connection;
ppsp_tp_string_t asn;
ppsp_tp_peer_protocol_t peer_protocol;
} ppsp_tp_peer_addr_t;
typedef struct {
ppsp_tp_peer_id_t id;
ppsp_tp_swarm_id_t swarm_id;
ppsp_tp_peer_addr_t peer_addresses[];
} ppsp_tp_peer_info_t
typedef struct {
ppsp_tp_swarm_id_t id;
enum {
JOIN,
LEAVE
} action;
enum {
SEED,
LEECH
} peer_mode;
ppsp_tp_transction_id_t transaction_id;
} ppsp_tp_swarm_action_t;
Cruz, et al. Expires April 30, 2015 [Page 22]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
The Peer_ID information may be present on the following levels:
- The identifier of the requesting peer on PPSP-TP Request level.
- At the Peer_Info element level
The peer also MAY include some attributes:
- Priority: the preferred interface for the connection to the P2P
network.
- Type: Describes the type of NAT traversal for the interface, which
can be HOST REFLEXIVE or PROXY.
- Connection: Identifies the Network Access type of the interface
(3G, ADSL, etc.).
- ASN: Identifies the Autonomous System Number of the Public Access
Network the peer is connected to.
The statistics and status elements MAY be present in STAT_REPORT
requests.
The Stat element is used to describe several properties relevant to
the P2P network. These properties can be related with 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.
The semantics of the statistic element elements and attributes are
defined as follows:
typedef struct {
ppsp_tp_stat_type_t type;
union {
struct {
ppsp_tp_swarm_id_t swarm_id;
ppsp_tp_integer_t uploaded_bytes;
ppsp_tp_integer_t downloaded_bytes;
ppsp_tp_integer_t available_bandwidth;
} stream_stats;
} stat_data;
} ppsp_tp_stat_t;
Other properties may be defined, related, for example, with
incentives and reputation mechanisms like "peer online time", or
connectivity conditions like physical "link status", etc.
For that purpose, the Stat element may be extended to provide
additional specific information for new properties, elements or
attributes (guidelines in section 7).
Cruz, et al. Expires April 30, 2015 [Page 23]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
4.2 Response element in response Messages
Response messages not requiring message-body only use the standard
HTTP Status-Code and Reason-Phrase (appended, if appropriate, with
detail phrase, as described in section 4.4).
Otherwise, the response elements will include the response elements,
related with the corresponding requests. Table 2 indicates the HTTP
Status-Code and Reason-Phrase for Response messages that require
message-body. These values MUST be treated as case-sensitive.
+--------------------+---------------------+
| Response Element | HTTP Status-Code |
| | and Reason-Phrase |
+--------------------+---------------------+
| SUCCESSFUL | 200 OK |
| AUTH_REQUIRED | 401 Unauthorized |
+-------------------+----------------------+
Table 2: Valid Strings for Response element of responses.
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
TransactionID of the corresponding request.
In CONNECT Request: 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
join @action requested.
In FIND Request: returns the list of peers corresponding to the
requested scope.
In STAT_REPORT Request: confirms the success of the requested
operation.
AUTH_REQUIRED: authentication is required for the peer to make the
request.
5 Request/Response Processing
Upon reception, a message is examined to ensure that it is properly
formed. The receiver MUST check that the HTTP message itself is
properly formed, and if not, appropriate standard HTTP errors MUST be
generated.
Cruz, et al. Expires April 30, 2015 [Page 24]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
5.1 CONNECT Request
This method is used when a peer registers to the system and/or
requests swarm actions. The peer MUST properly set the Request type
to CONNECT, generate and set the TransactionIDs, set the PeerInfo and
MAY include the swarm the peer is interested in, followed by the
corresponding action_type and peer_mode.
When a peer already possesses a content and agrees to share it to
others, it should set the action_type to the value JOIN, as well as
set the peer_mode to SEED during its start (or re-start) period.
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
MAY, when applicable, start 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. In case of success a Response message
with a corresponding response value of SUCCESSFUL will be generated.
The valid sets of SwarmID whose action_type is combined with
peer_mode for the CONNECT Request logic are enumerated in Table 3
(referring to the tracker "per-Peer-ID" state machine in section
2.4).
Cruz, et al. Expires April 30, 2015 [Page 25]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
+-----------+-----------+---------+----------+-----------+----------+
| SwarmID | @peerMode | @action | Initial | Final | Request |
| Elements | value | value | State | State | validity |
+-----------+-----------+---------+----------+-----------+----------|
| 1 | LEECH | JOIN | START | TRACKING | Valid |
+-----------+-----------+---------+----------+-----------+----------+
| 1 | LEECH | LEAVE | START | TERMINATE | Invalid |
+-----------+-----------+---------+----------+-----------+----------+
| 1 | LEECH | LEAVE | TRACKING | TERMINATE | Valid |
+-----------+-----------+---------+----------+-----------+----------+
| 1 | LEECH | JOIN | START | TERMINATE | Invalid |
| 1 | LEECH | LEAVE | | | |
+-----------+-----------+---------+----------+-----------+----------+
| 1 | LEECH | JOIN | TRACKING | TRACKING | Valid |
| 1 | LEECH | LEAVE | | | |
+-----------+-----------+---------+----------+-----------+----------+
| N | SEED | JOIN | START | TRACKING | Valid |
+-----------+-----------+---------+----------+-----------+----------+
| N | SEED | JOIN | TRACKING | TERMINATE | Invalid |
+-----------+-----------+---------+----------+-----------+----------+
| N | SEED | LEAVE | TRACKING | TERMINATE | Valid |
+-----------+-----------+---------+----------+-----------+----------+
Table 3: Validity of @action combinations in CONNECT Request.
In the CONNECT Request the element SwarmID MUST be present with
cardinality 1 to N, each containing the request for @action, the
@peerMode of the peer and the child @transactionID for that swarm.
The @peerMode element MUST be set to the type of participation of the
peer in the swarm (SEED or LEECH).
The element PeerInfo, if present, MAY contain multiple PeerAddress
child elements with attributes @addrType, @ip, @port and
@peerProtocol, and optionally @priority and @type (if PPSP-ICE NAT
traversal techniques are used) corresponding to each of the network
interfaces the peer wants to advertise.
The element PeerNum indicates to the tracker the number of peers to
be returned in a list corresponding to the indicated properties,
being @abilityNAT for NAT traversal (considering that PPSP-ICE NAT
traversal techniques may be used), and optionally @concurrentLinks,
@onlineTime and @uploadBWlevel for the preferred capabilities. If
STUN-like function is enabled in the tracker, the response MAY
include the peer reflexive address.
The response MUST have the same TransactionID values as the
corresponding request and actions.
Cruz, et al. Expires April 30, 2015 [Page 26]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
The Response MUST include PeerInfo data of the requesting peer public
IP address. If STUN-like function is enabled in the tracker, the
PeerAddress includes the attribute @type with a value of REFLEXIVE,
corresponding to the transport address "candidate" of the peer. The
PeerGroup MAY also include PeerInfo data corresponding to the Peer
IDs and public IP addresses of the selected active peers in the
requested swarm. The tracker MAY also include the attribute @asn
with network location information of the transport address,
corresponding to the Autonomous System Number of the access network
provider of the referenced peer.
In case the @peerMode is SEED, the tracker responds with a SUCCESSFUL
response and enters the peer information into the corresponding swarm
activity. In case the @peerMode is LEECH (or if the peer Seeder
includes a PeerNum 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 ALTO [I.D.ietf-alto-protocol].
IMPLEMENTATION NOTE: If no PeerNum attributes are present in the
request or peer_count = 0, the tracker MUST return a default number
of peers from the peer population.
5.2 FIND Request
This method allows peers to request to the tracker, whenever needed,
a new peer list for the swarm.
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 AbilityNAT for NAT traversal (considering that PPSP-ICE NAT
traversal techniques may be used), and optionally ConcurrentLinks,
OnlineTime and UploadBWlevel for the preferred capabilities.
When receiving a well-formed FIND Request the tracker processes the
information to check if it is valid. In case of success a response
message with a Response value of SUCCESSFUL will be generated and the
tracker will 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 peer status and network location information
Cruz, et al. Expires April 30, 2015 [Page 27]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
into consideration when selecting the peer list to return, to express
network topology preferences or Operators' policy preferences, with
regard to the possibility of connecting with other IETF efforts such
as ALTO [I.D.ietf-alto-protocol].
To provide more choices for the requesting peer, the tracker may
select a new peer list with lower priority from the list of peers and
return it to the requesting peer later.
The Response MUST include PeerInfo data that includes the public IP
addresses of the selected active peers in the swarm.
The peer list MUST contain the Peer IDs and the corresponding IP
Addresses, 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 tracker MAY also include the attribute @asn with network location
information of the transport addresses of the peers, corresponding to
the Autonomous System Numbers of the access network provider of each
peer in the list.
The response MAY also include PeerInfo data that includes the
requesting peer public IP address. If STUN-like function is enabled
in the tracker, the PeerAddress includes the attribute @type with a
value of REFLEXIVE, corresponding to the transport address
"candidate" of the peer.
IMPLEMENTATION NOTE: If no PeerNum attributes are present in the
request or peer_count = 0, the tracker MUST return a default number
of peers from the peer population.
5.3 STAT_REPORT Request
This method allows peers to send status and statistic data to
trackers. The method is initiated by the peer, periodically while
active.
The peer MUST set the Request method to STAT_REPORT, set the PeerID
with the identifier of the peer, and generate and set the
TransactionID.
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 ploadedBytes, DownloadedBytes, AvailBandwidth and etc.
Other properties may be defined (guidelines in section 7.1) related
Cruz, et al. Expires April 30, 2015 [Page 28]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
for example, with incentives and reputation mechanisms. In case no
StatisticsGroup is included, the STAT_REPORT is used as a "keep-
alive" message to prevent the tracker from de-registering the peer
when "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 TransactionID value as the request.
5.4 Error and Recovery conditions
If the peer fails to read the tracker response, the same Request with
identical content, including the same TransactionID, SHOULD be
repeated, if the condition is transient.
The TransactionID 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 SHOULD be prepared to receive a Request with a repeated
TransactionID.
Error situations resulting from the Normal Operation or from abnormal
conditions (Section 2.4.2) MUST be responded with the adequate
response codes, as described here:
If the message is found to be incorrectly formed, the receiver MUST
respond with a 400 (Bad Request) response with an empty message-
body. The Reason-Phrase SHOULD identify the syntax problem in more
detail, for example, "Missing Content-Type header field".
If the version number of the protocol is for a version the receiver
does not supports, the receiver MUST respond with a 400 (Bad
Request) with an empty message-body. Additional information SHOULD
be provided in the Reason-Phrase, for example, "PPSP Version #.#".
If the length of the received message does not matches the Content-
Length specified in the message header, or the message is received
without a defined Content-Length, the receiver MUST respond with a
411 (Length Required) response with an empty message-body.
If the Request-URI in a Request message is longer than the tracker
is willing to interpret, the tracker MUST respond with a 414
(Request-URI Too Long) response with an empty message-body.
Cruz, et al. Expires April 30, 2015 [Page 29]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
In the PEER REGISTERED and TRACKING states of the tracker, certain
requests are not allowed (Section 2.4.2). The tracker MUST respond
with a 403 (Forbidden) response with an empty message-body. The
Reason-Phrase SHOULD identify the error condition in more detail, for
example, "Action not allowed".
If the tracker is unable to process a Request message due to
unexpected condition, it SHOULD respond with a 500 (Internal Server
Error) response with an empty message-body.
If the tracker is unable to process a Request message for being in an
overloaded state, it SHOULD respond with a 503 (Service Unavailable)
response with an empty message-body.
6 Operations and Manageability
This section provides the operational and managements aspects that
are required to be considered in implementations of the PPSP Tracker
Protocol. These aspects follow the recommendations expressed in
RFC 5706 [RFC5706].
6.1 Operational Considerations
The PPSP-TP 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
contents.
The "serving" 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 contents.
6.1.1 Installation and Initial Setup
Content providers wishing to use PPSP for content distribution should
setup at least a PPSP Tracker and a service Portal to publish links
of the content descriptions, for access to their on-demand or live
original contents sources. Content/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
all the flexibility for implementers.
The SWARM IDs of available contents, as well as the addresses of the
Cruz, et al. Expires April 30, 2015 [Page 30]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
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.
End-users browse and search for the desired contents in the service
Portal, selecting by clicking the links of the corresponding MPDs.
This action typically launches the Client Media Player (with PPSP
awareness) which will then, using PPSP-TP, 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.
6.1.2 Migration Path
Since there is no previous standard protocol providing similar
functionality, this specification does not details a migration path.
6.1.3 Requirements on Other Protocols and Functional Components
For security reasons, when using PPSP Peer protocol with PPSP-TP, the
mechanisms described in section 7 should be observed.
6.1.4 Impact on Network Operation
As the messaging model of PPSP-TP aligns with HTTP protocol and the
semantics of its messages, the impact on Network Operation is similar
to using HTTP.
6.1.5 Verifying Correct Operation
The correct operation of PPSP-TP can be verified both at the Tracker
and at the peer by logging the behavior of PPSP-TP. Additionally,
the PPSP Tracker collects the status of the peers including peer's
activity, and such information can be used to monitor and obtain the
global view of the operation.
6.2 Management Considerations
The management considerations for PPSP-TP 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.
Cruz, et al. Expires April 30, 2015 [Page 31]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
6.2.1 Interoperability
Interoperability refers to allowing information sharing and
operations between multiple devices and multiple management
applications. For PPSP-TP, distinct types of devices host PPSP-TP
servers (Trackers) and clients (Peers). Therefore, support for
multiple standard schema languages, management protocols and
information models, suited to different purposes, was considered in
the PPSP-TP design. Specifically, management functionalities for
PPSP-TP devices can be achieved with Simple Network Management
Protocol (SNMP) [RFC3410], syslog [RFC5424] and NETCONF [RFC6241].
6.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 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 PPSP-TP, providing adequate metrics for the analysis of
performance for transaction flows in the network, in direct
relationship to the transport of PPSP-TP.
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.
The TCP-MIB [RFC4022] can additionally be considered for network
monitoring.
Logging is an important functionality for PPSP-TP server (Tracker)
and client (Peer), done via syslog [RFC5424].
6.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 PPSP-TP and the management of PPSP Tracker
servers, appear sufficient for PPSP-TP fault monitoring.
6.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
Cruz, et al. Expires April 30, 2015 [Page 32]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
a set of server nodes. This functionality can be provided via
NETCONF [RFC6241].
6.2.5 Accounting Management
PPSP-TP implementations, namely for content provider environments,
can benefit from accounting standardization efforts as defined in
[RFC2975], in terms of resource consumption data, for the purposes of
capacity and trend analysis, cost allocation, auditing, and billing.
6.2.6 Performance Management
Being transaction-oriented, PPSP-TP performance, in terms of
availability and responsiveness, can be measured with the facilities
of the APM-MIB [RFC3729] and the TPM-MIB [RFC4150].
6.2.7 Security Management
Standard SNMP notifications for PPSP Tracker management and syslog
messages [RFC5424] can be used, to alert operators to the conditions
identified in the security considerations (Section 7).
The statistics collected about the operation of PPSP-TP can be used
for detecting attacks, such as the receipt of malformed messages,
messages out of order, or messages with invalid timestamps.
7 Security Considerations
P2P streaming systems are subject to attacks by malicious/unfriendly
peers/trackers that may eavesdrop on signaling, forge/deny
information/knowledge about streaming content and/or its
availability, impersonating to be another valid participant, or
launch DoS attacks to a chosen victim.
No security system can guarantees complete security in an open P2P
streaming system where participants may be malicious or
uncooperative. The goal of security considerations described here is
to provide sufficient protection for maintaining some security
properties during the 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 same
security considerations described in RFC 2616 also apply [RFC2616].
Cruz, et al. Expires April 30, 2015 [Page 33]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
7.1 Authentication between Tracker and Peers
To protect the PPSP-TP 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 scope of
this specification.
A channel-oriented security mechanism should be used in the
communication between peers and tracker, such as the Transport Layer
Security (TLS) to provide privacy and data integrity.
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 bearer
token, which provides the peer with the information required to
successfully utilize an access token to make protected requests to
the tracker [RFC6750].
7.2 Content Integrity protection against polluting peers/trackers
Malicious peers may declaim ownership of popular content to the
tracker but try to serve polluted (i.e., decoy content or even
virus/trojan infected contents) to other peers.
This kind of pollution can be detected by incorporating integrity
verification schemes for published shared contents. As content
chunks are transferred independently and concurrently, a
correspondent chunk-level integrity verification MUST be used,
checked with signed fingerprints received from authentic origin.
7.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
Cruz, et al. Expires April 30, 2015 [Page 34]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
partners for future transactions, helping to mitigate the impact of
such malicious behaviors. A globally trusted tracker MAY also take
part of the trust mechanism by collecting evaluations, computing
credit values and providing them to joining peers.
7.4 Pro-incentive parameter trustfulness
Property types for STAT_REPORT messages may consider additional pro-
incentive parameters (guidelines for extension in Section 8), 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, both the amount of uploaded and downloaded data should
be reported to the tracker to allow checking if there is any
inconsistency between the upload and download report, and 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, 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].
8 Guidelines for Extending PPSP-TP
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 PPSP-TP it 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.
Cruz, et al. Expires April 30, 2015 [Page 35]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
Extensions MUST adhere to the principles described in this section in
order to be considered valid.
Extensions MAY be documented as Internet-Draft and RFC documents if
there are requirements for coordination, interoperability, and broad
distribution.
Extensions need not be published as Internet-Draft or RFC documents
if they are intended for operation in a closed environment or are
otherwise intended for a limited audience.
8.1 Forms of PPSP-TP Extension
In PPSP-TP 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 StatisticsGroup can be
extended to include additional elements needed to express status
information about the activity of the peer, such as OnlineTime 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
PPSP-TP Request and Response message structures are insufficient,
then extending the protocol should be considered in order to
define new operational Requests and Responses.
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 Leecher, and then DISCONNECT from the latter swarm but keeping
as Seeder for the first one. When deciding to leave the system,
the peer DISCONNECTs gracefully from it:
Cruz, et al. Expires April 30, 2015 [Page 36]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
+--------+ +---------+
| Peer | | Tracker |
+--------+ +---------+
| |
|--CONNECT--------------------->|
|<--------------------------OK--|
|--JOIN(swarm_a;SEED)---------->|
|<--------------------------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 PPSP-TP extended version.
8.2 Issues to Be Addressed in PPSP-TP Extensions
There are several issues that all extensions should take into
consideration.
- Overview of the Extension: It is RECOMMENDED that extensions to
PPSP-TP 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.
- Backward Compatibility: One of the most important issues to
consider is whether the new extension is backward compatible with
the base PPST-TP.
- 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 PPSP-TP. Method names SHOULD be
shorter than 16 characters and SHOULD attempt to convey the
Cruz, et al. Expires April 30, 2015 [Page 37]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
general meaning of the Request or Response.
- Semantic Issues: PPSP-TP 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.
- Security Issues: Being security an important component of any
protocol, designers of PPSP-TP extensions need to carefully
consider security requirements, namely authorization requirements
and requirements for end-to-end integrity.
- 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.
9 IANA Considerations
There are presently no IANA considerations with this document.
10 Acknowledgments
The authors would like to thank many people for for their help and
comments, particularly: Zhang Yunfei, Liao Hongluan, Roni Even,
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 and Arno Bakker.
Rui Cruz, Mario Nunes and Joao Taveira are partially supported by the
SARACEN project [SARACEN], a research project of the European Union
7th Framework Programme (contract no. ICT-248474).
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, the European Commission, Huawei or China Mobile.
Cruz, et al. Expires April 30, 2015 [Page 38]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
11 References
11.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April
1 1995.
[TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925,
April 1 1996.
[RFC2564] Kalbfleisch, C., Krupczak, C., Presuhn, R., and J.
Saperia, "Application Management MIB", RFC 2564, May 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB",
RFC 2790, March 2000.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3729] Waldbusser, S., "Application Performance Measurement MIB",
RFC 3729, March 2004.
[RFC4022] Raghunarayan, R., Ed., "Management Information Base for
the Transmission Control Protocol (TCP)", RFC 4022, March
2005.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, July
2005.
[RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics
MIB", RFC 4150, August 2005.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
Cruz, et al. Expires April 30, 2015 [Page 39]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
[RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions",
RFC 5706, November 2009.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, June 2011.
[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709,
September 2012.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, October 2012.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, October 2012.
[RFC6972] Zhang, Y. and N. Zong, "Problem Statement and Requirements
of the Peer-to-Peer Streaming Protocol (PPSP)", RFC 6972,
July 2013.
11.2 Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header",
RFC 3514, April 1 2003.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5513] Farrel, A., "IANA Considerations for Three Letter
Acronyms", RFC 5513, April 1 2009.
[RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1
2009.
[I.D.ietf-alto-protocol] Alimi, R., Penno, R. and Y. Yang, "ALTO
Protocol", draft-ietf-alto-protocol-27, (work in progress), March
2014.
[Contracts] Piatek, M., Venkataramani, A., Yang, R., Zhang, D. and A.
Jaffe, "Contracts: Practical Contribution Incentives for P2P Live
Streaming", in NSDI '10: USENIX Symposium on Networked Systems Design
and Implementation, April 2010.
Cruz, et al. Expires April 30, 2015 [Page 40]
INTERNET DRAFT PPSP-TP/1.0 October 27, 2014
[SARACEN] "SARACEN Project Website",
http://www.saracen-p2p.eu/.
Authors' Addresses
Rui Santos Cruz
IST/INESC-ID/INOV
Phone: +351.939060939
Email: rui.cruz@ieee.org
Gu Yingjie
Email: guyingjie@gmail.com
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
Joao P. Taveira
IST/INOV
Email: joao.silva@inov.pt
Deng Lingli
China Mobile
Email: denglingli@chinamobile.com
Cruz, et al. Expires April 30, 2015 [Page 41]