PPSP Y. Gu
Internet-Draft Huawei
Intended status: Standards Track David A. Bryan
Expires: September 1, 2010 Ethernot
Y. Zhang
H. Liao
China mobile
February 28, 2010
Tracker Protocol
draft-gu-ppsp-tracker-protocol-00
Abstract
This document defines P2P streaming Tracker Protocol, including
functional entities and architecture, components, syntax and
semantics.
This Tracker protocol is an application-level protocol for peers to
register, publish/request content and provide peer status to
Trackers. It is also for trackers to provide peer lists to peers,
send control/manage messages and communicate with other trackers.
Tracker protocol can serve live media and VoD applications, as well
as file sharing.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 1, 2010.
Gu, et al. Expires September 1, 2010 [Page 1]
Internet-Draft Tracker Protocol February 2010
Copyright Notice
Copyright (c) 2010 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 BSD License.
Gu, et al. Expires September 1, 2010 [Page 2]
Internet-Draft Tracker Protocol February 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 4
2.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Function Entities and Interfaces . . . . . . . . . . . . . 5
3.2. Use of Binary Messages . . . . . . . . . . . . . . . . . . 7
3.3. System Maintenance . . . . . . . . . . . . . . . . . . . . 7
3.4. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 7
3.5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 8
4.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Swarm ID . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Chunk ID . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Peer ID . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Message Length . . . . . . . . . . . . . . . . . . . . . . 9
5. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Overlay Management Methods . . . . . . . . . . . . . . . . 9
5.2. Data Management Methods . . . . . . . . . . . . . . . . . 10
5.3. Information Management Methods . . . . . . . . . . . . . . 10
5.4. Methods Representations . . . . . . . . . . . . . . . . . 10
6. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Message Format . . . . . . . . . . . . . . . . . . . . . . 12
7. Status Code Definitions . . . . . . . . . . . . . . . . . . . 27
7.1. Success 0x1 . . . . . . . . . . . . . . . . . . . . . . . 27
7.2. Error . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.3. Server Error . . . . . . . . . . . . . . . . . . . . . . . 28
8. Security Consideration . . . . . . . . . . . . . . . . . . . . 28
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Gu, et al. Expires September 1, 2010 [Page 3]
Internet-Draft Tracker Protocol February 2010
1. Introduction
P2P Streaming Protocol includes two protocols, i.e. Tracker Protocol
and Peer Protocol. Tracker Protocol provides communication between
Trackers and Peers, by which Peers report streaming status to the
tracker and request candidate lists from the tracker.
[draft-zhang-ppsp-problem-statement] indicates that the Tracker
protocol should standardize format/encoding of information between
PPSP peers and PPSP trackers, as well as standardize messages between
PPSP peers and PPSP trackers. [draft-zong-ppsp-reqs] list the detail
requirements for Tracker Protocol.
This draft defines the Tracker Protocol. First of all, it analyzes
the functional entities involved in Tracker protocol. Then, a list
of functions is introduced. [draft-zong-ppsp-reqs] and
[draft-zhang-ppsp-problem-statement] describe a basic set of
functions and high-level requirements, however, this draft will
introduce detailed and specific ones. The signaling/control path,
corresponding to the functions are defined as well.
The principal part of the draft is syntax and semantics. These
include parameters, methods, and message format. Most implemented
P2P protocols are proprietary ones, as introduced in
[draft-gu-ppsp-survey]. This draft intends to extract the
fundamental features, functionalities and policies of the proprietary
protocols and implementation experience, and present an early
strawman sketch for an extensible protocol as a way to identify open
isses and further discussion in the PPSP WG.
2. Document Conventions
2.1. Notational Conventions
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].
2.2. Terminology
The draft uses the terms defined in
[draft-zhang-ppsp-problem-statement].
This draft also uses some new terms. We list the relevant terms as
following.
Swarm: A swarm is a set of peers who are sharing the same live
channel or VoD.
Gu, et al. Expires September 1, 2010 [Page 4]
Internet-Draft Tracker Protocol February 2010
Chunk: A chunk is a basic unit of partitioned stream, which is used
by a peer for the purpose of storage, advertisement and exchange
among peers.
Join Time: Join time is the absolute time when a peer registers on a
Tracker. This value is recorded by the Tracker and is used to
calculate Online Time.
Online Time: Online Time shows how long the peer has been in the P2P
streaming system since it joins. This value indicates the stability
of a peer, and it is calculated by Tracker when necessary.
Absolute Time: Absolute time is expressed as ISO 8601 [ISO.8601.2000]
timestamps, using UTC (GMT). Fractions of a second may be indicated.
Example for November 8, 1996 at 14h37 and 20 and a quarter seconds
UTC:19961108T143720.25Z
STUN: Simple Traversal of UDP over NATs
TURN: Traversal Using Relay NAT
TLS: Transport Layer Security
3. Protocol Overview
3.1. Function Entities and Interfaces
First of all, we introduce the overview of Tracker Communication. A
peer may get Tracker's address by some way, e.g. from EPG, and then
send JOIN message to the Tracker. Tracker receives the request,
assigns a peer ID and response with the peer ID to the requesting
peer. Meanwhile, Tracker updates the peer status records. The peer
has to send KEEPALIVE message to notify Tracker about its existence
periodically, or else Tracker will assume that the peer is offline
and may remove the peer from content status and peer status. When
the peer wants to watch a live channel or VoD, it sends a GET message
to Tracker to show which content it is going to watch. Tracker
replies with GET Response to provide candidate peers list, from which
the peer can download content from. The peer can also PUT the
content it owns to the Tracker and Tracker upon receiving PUT request
will update content status to include the PUT peer into peer list.
In order to obtain the latest condition of peers, Tracker may send
STATISTICS messages to peers and peers report with the requested
information. LEAVE message is sent from peer to Tracker to announce
it is going to leave the system.
The entities and interfaces participating in the P2P streaming
Gu, et al. Expires September 1, 2010 [Page 5]
Internet-Draft Tracker Protocol February 2010
systems are in the figure bellow.
Application Layer
========================================================
Communication Layer
Peer
+-------------------+
|peer signaling |-------------------+
| |Data management |
| | +===============+ |
| +===============+ | |Swarm ID | |
| | JOIN/LEAVE/ | | | - Chunk ID | |
| | KEEPALIVE/PUT/| | | - peer list | |
| | GET | | | - Buffer map| |
| +===============+ | +===============+ |
+-------------------+ |
+---------------------+
^
-------------------*----------------------------------------------
Tracker V
+-------------------+
|tracker signaling |
| |
| (JOIN/LEAVE/ |
| KEEPALIVE/PUT/ |
| GET/STATISTICS) |
+-------------------+
+----------------------------------------------------------+
| Data management on Tracker |
| |
| +======================+ +======================+ |
| |peer status | |content status | |
| | peer ID | | +---------------+ | |
| | - online time | | | Swarm ID | | |
| | - peer property | | | - Chunk ID | | |
| | - link status | | | - peer list| | |
| | - etc. | | +---------------+ | |
| +======================+ +======================+ |
+----------------------------------------------------------+
==================================================================
Transport Layer
Fig 1 Function Entities of PPSP Tracker Communication
Interface between Tracker signaling and Peer Signaling entities
support the following functions:
Gu, et al. Expires September 1, 2010 [Page 6]
Internet-Draft Tracker Protocol February 2010
1) Transmission of JOIN/LEAVE messages.
2) Transmission of KEEPALIVE messages.
3) Transmission of PUT messages, by which peers tell trackers what
they have.
4) Transmission of GET messages, by which peers request what they
want and get candidate peers list from trackers.
5) Transmission of STATISTICS requests and responses, by which
trackers can get peers status, network performance, etc.
3.2. Use of Binary Messages
We have two options to present the protocol, Binary Language and
ASCII Language. Both have pros and cons. ASCII is easier for people
to understand , but requires more space and bandwidth. Binary
protocols are lighter in both bandwidth and processing, though are
sometimes considered more difficult to understand.
Considering that peers communicate with extremely high frequency and
the streaming application is much sensitive to delay, we choose
Binary presentation when designing PPSP Tracker protocol in this
draft.
Note: this is an open issue for WG to discuss and make determination.
No matter which one is chosen, the basic design principle, including
communication method and terminology, should be the same.
3.3. System Maintenance
In order to keep the streaming system stable and efficient, trackers
should periodically perform KEEPALIVE check to take into account peer
failures. These KEEPALIVE messages are sent automatically by peers
and trackers will verify that peers' KEEPALIVE messages are recieved.
3.4. Bootstrapping
When a peer wishes to join an existing P2P streaming application, it
must first locate a Tracker in order to register and obtain a Peer
ID. Peers may use any method to find a Tracker. Tracker discovery
is out of scope of this specification.
3.5. NAT Traversal
For simplicity, we assume that all trackers MUST be in public
Internet and have been placed there deliberately. Since all sessions
Gu, et al. Expires September 1, 2010 [Page 7]
Internet-Draft Tracker Protocol February 2010
MUST be activated by Peers by sending Join messages, Tracker
Communication will not encounter NAT issues. The issues of
promotion, i.e. selecting peers be promoted as a tracker, or
implementing a fully distributed tracker, will not be considered in
this draft in this version.
4. Protocol Parameters
4.1. Version
Tracker protocol uses a "<major>.<minor>" numbering scheme to
indicate versions of the protocol. The protocol versioning policy is
intended to allow the sender to indicate the format of a message and
its capability for understanding further communication, rather than
the features obtained via that communication. No change is made to
the version number for the addition of message components which do
not affect communication behavior or which only add to extensible
field values.
Version field is 8 bits. The first 4 bits represent <major> number
and the rest 4 bits represent <minor> number.
The <minor> number is incremented when the changes made to the
protocol add features which do not change the general message parsing
algorithm, but which may add to the message semantics and imply
additional capabilities of the sender. The <major> number is
incremented when the format of a message within the protocol is
changed.
Note that the major and minor numbers MUST be treated as separate
integers and that each MAY be incremented by more than a single
digit. Leading zeros MUST be ignored by recipients and MUST NOT be
sent.
The current version is 0.0.
4.2. Swarm ID
Swarm ID: Swarm ID is a 128 bits number to uniquely identify a swarm,
as well as uniquely identify the particular program that the swarm is
watching.
4.3. Chunk ID
Chunk ID indicates the time period of a chunk in an on-demand-
streaming. The Chunk ID of the first chunk of a content MAY be any
number, however, it is RECOMMENDED to start at 0. For each
Gu, et al. Expires September 1, 2010 [Page 8]
Internet-Draft Tracker Protocol February 2010
sequential chunk, the Chunk ID MUST be incremented by one.
A swarm ID and a chunk ID uniquely identified a particular chunk in a
particular streaming.
4.4. Peer ID
Every peer owns a unique Identifier on a particular Tracker, i.e.
Peer ID. Peer ID is a 128 bits number and is randomly generated when
a peer registers.
4.5. Message Length
Message Length (16 bit) indicates the length in Bytes of the message,
including the message header and the following variable message body.
5. Method Definitions
Methods represent the particular operations that peers/trackers want
to do in PPSP Tracker Protocol. We have already listed some methods
in the section 3. Here we introduce the specifications of these
methods.
5.1. Overlay Management Methods
Join: Join is the first method a peer performs. There is no
relationship between peer and tracker before Join happens and no
peer-ID is assigned as well. Tracker will never serve a peer who has
not joined before. Peer registers in tracker by Join and tracker
assigns in the response a peer-ID to peer, which is the only
identification for peer in PPSP. Tracker records peer's information,
e.g. peer-ID, Join-time, peer property, peer link status, etc. After
Join, peer owns the right to apply other methods on the tracker, e.g.
to publish content availability on tracker or get peers lists from
tracker for the specific content. JOIN is a mandatory method.
Leave: When peer intends to quit from the P2P streaming application,
it sends Leave to the tracker. Tracker deletes the corresponding
records related to the peer, including those in peer status and
content status. After Leave, peer can not apply any methods except
Join again, and will not reply to any request from trackers or other
peers. Tracker will release the corresponding peer-ID. LEAVE is a
mandatory method.
Keepalive: Keepalive message is periodically sent from peer to the
tracker to notify that peer is still alive. If tracker does not
receive keep-alive message for a configured time, it will assume that
Gu, et al. Expires September 1, 2010 [Page 9]
Internet-Draft Tracker Protocol February 2010
the peer is not available and do the same operations as in Leave.
KEAPALIVE is an optional method.
Open issue: Should KEEPALIVE be used by peer to carry its current
property if any change happens.
5.2. Data Management Methods
Put: By Put, peer notifies tracker about which chunks of which swarms
it owns. Tracker records the content availability in content status,
i.e. adds peer to the candidate peers list for the notified chunk IDs
of a particular swarm. PUT is a mandatory method.
Get: By Get, peer requests for lists of peers that can provide
specific content from tracker. On receiving Get, tracker finds the
candidate peers lists in content status. Tracker may take peer
status and peers priority into consideration when it picks the
candidate peers lists. Peers lists can be replied in more than more
responses, in order to express tracker's preference among candidate
peers. By peer priority, we refer to the network topology preference
or Operators' policy preference, with regard to the possibility of
connecting with other IETF efforts such as ALTO. In Live streaming,
when receiving Get messages, tracker also updates content status to
involve the new peer under a specific channel. GET is a mandatory
method.
5.3. Information Management Methods
Statistics: This method allows tracker to collect statistic data to
improve system performance. STATISTICS is an optional method.
5.4. Methods Representations
Method is an 8 bit field that indicates the message method. The
first 2 bits show the communication type, i.e. tracker communication
or peer communication.
Tracker-Communication : 0x0
Peer-Communication : 0x1 (Reserved)
Information-Statistics : 0x2
When the first 2 bits is 0x0, i.e. Tracker-Communication, the last
6bits represent the following different methods.
Gu, et al. Expires September 1, 2010 [Page 10]
Internet-Draft Tracker Protocol February 2010
JOIN : 0x0
LEAVE : 0x1
KEEPALIVE : 0x2
PUT : 0x3
GET : 0x4
When the first 2 bits is 0x2, i.e. Information-Statistics, the last
6bits represent the following different methods.
STATISTICS : 0x1
6. Message Syntax
This section provides the details of the binary encoding. Tracker
protocol is a request-response protocol. The messages are encoded
using binary fields. All integers are represented in network byte
order and are present in base 10, decimal, unless otherwise noted in
this draft.
Tracker protocol messages comprises of two parts: message header and
message body.
Message header: contains some information for forwarding operations,
for example, Protocol version, method and type. Tracker Protocol
Message has a fixed length header. Fixed headers can be processed
faster than messages without a fixed header because the headers can
be processed by the stack and redirected to the appropriate peer
without processing the entire message.
Message body: Message body is not designed to be some designated
format, and it usually needs to be interpreted assisted by some
fields in Message Header.
6.1. Message Header
PPSP Protocol has a fixed length of messages header, including 4 bits
Version, 1 bit R/r, 8 bits Method, 16 bits Message Length, 32 bits
Transaction ID, 128 bits Source ID and 128 bits Destination ID.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Status | | | | |
| Version |Code | RSV | Method |S| RSV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 2 Message Header
Gu, et al. Expires September 1, 2010 [Page 11]
Internet-Draft Tracker Protocol February 2010
The fields defined in Message Header is explained in corresponding
section, shown in Table 1.
Table 1 Interpretation of Message Header
+---------------+--------------------+
| Header | Defined in Section |
+---------------+--------------------+
| Version | Section 4.1 |
|---------------|--------------------|
| Method | Section 5.4 |
|---------------|--------------------|
| Message Length| Section 4.5 |
+---------------+--------------------+
6.1.1. Status Code
Status Code : reflects a general status of the request.
The following status codes are examples. More detailed status codes
interpretation are described in section 8.
Successful (OK) : 0x1
Invalid syntax : 0x2
Payment required : 0x3
Request forbidden : 0x4
Object not found : 0X5
Internal server error : 0X6
Does not support : 0x7
Temporarily overloaded : 0x8
Version not support : 0x9
6.1.2. Series Flag
S Flag is 'Series' flag, which indicates whether this message is
fragmented. If S is set, it means receiving end can expect more
messages from the same sender. This flag is used from example, when
the message body carries Peer List Info and Peer Property Info, which
will be introduced in Section 7. For example S Flag is used in Get
Message when there is a very long list of candidate peers sent from
Tracker and the tracker would like to break it to a couple of
messages.
If S is zero, it means the list in this message is either the whole
list of peers or the last fragment of a message.
6.2. Message Format
Gu, et al. Expires September 1, 2010 [Page 12]
Internet-Draft Tracker Protocol February 2010
6.2.1. JOIN
The JOIN procedure follows the general rules described below:
1) A first message is sent, specifying the desire to join;
2) A response including a chosen Peer ID and IP address/port from
where the JOIN message comes, and Tracker will consider this pair
of IP address/port as registration IP address/port of the joining
peer.
JOIN REQUEST
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Status | | | | |
| Version |Code | RSV | JOIN |S| RSV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |C| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 3 Message Format of JOIN REQUEST
C is caching flag. If C is set, it means the joining peer has local
caching and can provide uploading for other peers.(Open Question: Do
we more detail about caching? What is cached? Question of
rechability for peers providing cache support to other peers.)
JOIN RESPONSE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Status | | | | |
| Version |Code | RSV | JOIN |S| RSV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |V| RSV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Peer ID (128bit) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ IPv4 Address(32bit)/ IPv6 address(128bit) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 4 Message Format of JOIN RESPONSE
V flag represents the version of IP address. If V flag is empty, it
means the Address is IPv4 and the Address field is 32 bits, otherwise
Gu, et al. Expires September 1, 2010 [Page 13]
Internet-Draft Tracker Protocol February 2010
it's IPv6 and the Address field is 128 bits.
6.2.2. LEAVE
The LEAVE process MAY include the following steps:
1) The leaving peer sends LEAVE request to Tracker.
2) Tracker updates Peer Status and Content Status.
3) Tracker responds leaving.
LEAVE REQUEST
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Status | | | | |
| Version |Code | RSV | LEAVE |S| RSV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | RSV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Peer ID(128bit) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 5 Message Format of LEAVE REQUEST
LEAVE RESPONSE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Status | | | | |
| Version |Code | RSV | LEAVE |S| RSV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | RSV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 6 Message Format of LEAVE RESPONSE
6.2.3. KEEPALIVE
KEEPALIVE message is used by a peer to periodically notify Tracker
that it is still alive. If Tracker has not received KEEPALIVE
message from a particular peer, Tracker will regard the peer as
offline and it will do the same as in LEAVE.
Gu, et al. Expires September 1, 2010 [Page 14]
Internet-Draft Tracker Protocol February 2010
KEEPALIVE REQUEST
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Status | | | | |
| Version |Code | RSV | KEEPALIVE |S| RSV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |C| RSV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Peer ID(128bit) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 7 Message Format of KEEPALIVE REQUEST
C flag represents the link status of the peer. If it is set, it
means the peer is in congestion.
Open issue: the size of peer-ID, should we define it as fixed bits
(how many bits are suitable) or make it extensible?
KEEPALIVE RESPONSE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Status | | | | |
| Version |Code | RSV | KEEPALIVE |S| RSV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | RSV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 8 Message Format of KEEPALIVE RESPONSE
6.2.4. PUT
PUT message is used by a peer to publish what content it owns, or to
notify its property.
Upon receiving PUT message, Tracker records the peer in content
status and responds to the peer.
As we have mentioned in Section 6.1.3, PUT may carry different type
of information in the Message Body. So in this section, we introduce
the respective Message Format for different type of Message Body.
Gu, et al. Expires September 1, 2010 [Page 15]
Internet-Draft Tracker Protocol February 2010
PUT-Resource Info REQUEST
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Status | | | | | |
| Version |Code | RSV | PUT |S|C| RSV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |K|E| U | RSV | Chunk numbers|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Distance(optional) | RSV(optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Peer ID(128bit) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Swarm ID (128bits) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Chunk ID 1 (16bits, Optional) | . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . |Chunk ID n (16bits, Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiration Time(32 bits, Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 9 Message Format of PUT-Resource Info REQUEST
Gu, et al. Expires September 1, 2010 [Page 16]
Internet-Draft Tracker Protocol February 2010
6.2.4.1. PUT Resource Info
PUT-Resource Info REQUEST
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | Status| | | | |
| Version |R|Pri. | Code | PUT |S|C| RSV |
| | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |K|E| U | RSV | Chunk numbers|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Distance(optional) | RSV(optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Peer ID(128bit) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Swarm ID (128bits) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Chunk ID 1 (16bits, Optional) | . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . |Chunk ID n (16bits, Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiration Time(32 bits, Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 10 Message Format of PUT-Resource Info REQUEST
C (1 bit): It represents which information is carried in message
body, Resource Info or Peer Property Info. If it's set, it means
message body carries Resource Info, else it's Peer Property Info.
K (1 bit): If this bit is set, Chunk ID field MUST be included;
otherwise not.
E (1 bit): If this bit is set, Expiration Time field MUST be
included; otherwise not.
Open issue:
U (1bit): When K is set, U should be interpreted. U represents how a
peer PUT its resource. We have considered the following 3 ways to
PUT resource.
U = 0x0 One Chunk ID in each PUT Resource message. This is
appropriate when only one or few lately downloaded chunk need to be
PUT. Chunk numbers is zero.
U = 0x1 Several Chunk IDs in one PUT Resource message. This is
helpful to reduce volume of messages between peer and Tracker,
especially when there is a large volume of chunk need to be PUT or
Gu, et al. Expires September 1, 2010 [Page 17]
Internet-Draft Tracker Protocol February 2010
when Chunks are not continuous. Chunk numbers indicates how many
chunk IDs are included in the message body.
In the above two kind of scenario, the Distance field and the
corresponding RSV field, which is designed for alignment, does not
exist in the message and Tracker should not intend to interpret it.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Distance(optional) | RSV(optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
However, unlike File sharing system, continuous Chunks are expected
to be cached on peer in Streaming system. And, assuming that Tracker
knows the distance between two continuous Chunk IDS and Chunk ID is
evenly distributed, a peer can only include the First Chunk ID of a
series of continuous Chunks and the number of Chunks to be PUT in PUT
Resource message.
So we design the third way to PUT Resource.
U = 0x2 A PUT Resource message include First Chunk ID of a series of
continuous Chunks, the number of Chunks to be PUT, and the distance
of two continuous Chunk IDs. Chunk numbers indicates how many
continuous Chunks, starting from the First Chunk ID, does the peer
want to PUT.
In this scenario, the Distance field and the corresponding RSV field,
which is designed for alignment, MUST be included and should be
interpreted by Tracker. Distance indicates the difference between
two continuous Chunk IDs, and is used by Tracker to calculate the
Chunk ID that is not directly indicated in the message.
Open issue: How many bits should a Chunk ID occupy? One common
method is to make the Chunk ID of a particular swarm starts from 0,
and is increased by one for every next Chunk. However this is not
always true. So how should we define the length of Chunk ID?
Chunk ID and Expiration Time is optional field. Here we give some
examples whether these fields need to be set or not. In
implementation, there might be other reasons for leaving out theses
fields or not.
Chunk ID: If a peer is going to join a live channel, Chunk ID field
is not necessary. If a peer is going to get a VoD chunk, it needs to
indicate which chunk of the swarm it wants.
Expiration Time: If a peer is putting content on the tracker, it can
decide whether to set an Expiration Time for the content.
Gu, et al. Expires September 1, 2010 [Page 18]
Internet-Draft Tracker Protocol February 2010
Peer ID: Peer ID is the ID of the owner who owns the resource
indicated by swarm ID and chunk ID.
If one optional field is not tagged, the corresponding value field
will not be reserved.
PUT-Resource Info RESPONSE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Status | | | |C| |
| Version |Code | RSV | PUT |S|=| RSV |
| | | | | |1| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | RSV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 11 Message Format of PUT-Resource Info RESPONSE
If a peer PUT more than one Chunk a time and unfortunately fails,
Tracker will notify the peer by PUT Resource Info response that PUT
operation fails and all of the Chunks are not recorded correctly.
6.2.5. PUT Peer Property Info
Peer Property Info is a TLV format. A PUT message can carry multiple
peer property info in its message body.
The TLV format of Peer Property Info is as following:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | P-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Property Value . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 12 TLV Format of Peer Property
With this message, peer can notify Tracker of its property.
We define the following Type:
Gu, et al. Expires September 1, 2010 [Page 19]
Internet-Draft Tracker Protocol February 2010
Table 2 Peer Property Type
+----------------------------------------------------------------+
|P-Type| Definition | Interpretation of Value field |
+----------------------------------------------------------------+
| 0x00 |Caching size| available size of caching |
+----------------------------------------------------------------+
| 0x01 |Bandwidth | available bandwidth |
+----------------------------------------------------------------+
| 0x02 |Link numbers| acceptable links for each remote peer |
+----------------------------------------------------------------+
| 0x03 |Certificate | certificate of the peer |
+----------------------------------------------------------------+
| 0x04 |NAT/Firewall| peer behind NAT, Value field is empty |
+----------------------------------------------------------------+
| 0x05 |STUN | peer supports STUN service, |
| | | Property Value is empty |
+----------------------------------------------------------------+
| 0x06 |TURN | peer supports TURN service, |
| | | Property Value is empty |
+----------------------------------------------------------------+
| 0x07 |Sum Volume | Sum of bytes of data peers receives |
| | | from the steaming system |
+----------------------------------------------------------------+
| 0x08 |Access Mode | ADSL/Fiber/GPRS/3G/LTE/WiFi |
+----------------------------------------------------------------+
| 0x09 |End Device | STB/PC/MobilePhone |
+----------------------------------------------------------------+
| 0x0a |Available | |
| |Battery | |
| | Volume | |
+----------------------------------------------------------------+
0x09 End Device is especially meaningful for Mobile phone users, by
which they can choose a peer with the same end Device in order to
avoid transcoding, or choose a PC peer which may have higher download
bandwidth and larger caching size than Mobile phone.
0x0a Available Battery Volume implies the stability of a peer. If
there is large percent of battery left on a mobile peer, it may
support service longer than one with less battery.
Property Length represents the length in Bytes of the Property Value
field.
If there is a large volume of property values to carry, the message
can be fragmented to a series of messages. The S Flag in Message
Header should be set. We suggest each fragment should carry one or
more complete value, to put it another way, do not split a value into
Gu, et al. Expires September 1, 2010 [Page 20]
Internet-Draft Tracker Protocol February 2010
different fragments.
PUT-Peer Property Info request
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Status | | | |C| |
| Version |Code | RSV | PUT |S|=| RSV |
| | | | | |0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | RSV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Peer ID(128bit) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ TLV Element +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ . . . +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ TLV Element +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 13 Message format of PUT-Peer Property Info REQUEST
PUT-Resource Info response
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Status | | | |C| |
| Version |Code | RSV | PUT |S|=| RSV |
| | | | | |0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | RSV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 14 Message format of PUT-Peer Property Info RESPONSE
6.2.6. GET
GET message is used by a requesting peer to request Tracker for list
of candidate peers that can provide particular content.
Upon receiving GET message, Tracker will do the following steps:
1) Tracker searches Content Status to find out peers list that can
provide the content indicated in the Resource Info.
2) According to the candidate peers property recorded in Peer
Status, Tracker pick out the appropriate candidate peers than can
satisfy the Destination Peer Preference Info, if applicable.
Gu, et al. Expires September 1, 2010 [Page 21]
Internet-Draft Tracker Protocol February 2010
3) Tracker sends to requesting peer the appropriate candidate peers
list, to which requesting peer can ask for wanted content.
4) Meanwhile, Tracker updates the content status and peer status to
reflect the latest status.
If there is no candidate peer for the wanted content, Peer List Info
will not be presented.
A better way to improve general system preference is to provide
candidate peer list with peers who have similar host property to the
requesting peer. So that a Destination Peer Preference is introduced
in GET to enable requesting peer to notify Tracker which property of
a destination peer it prefers.
6.2.6.1. GET Peer List Info without Destination Peer Preference
GET REQUEST without Destination Peer Preference
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Status | | | |D| |
| Version |Code | RSV | GET |S|=| RSV |
| | | | | |0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |K| RSV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Peer ID(128bit) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Swarm ID (128bits) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Chunk ID (128bits, Optional) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 15 Message format of GET REQUEST without Destination Peer Preference
K (1 bit): If this bit is set, Chunk ID field MUST be included;
otherwise not.
D (1 bit): This flag implies whether requesting peer wants to GET
peer list with Destination property preference. If it's empty, it
means requesting peer has no preference. If it's set, it means
requesting peer has indicated Destination property preference in
message body.
GET response
Open issues: Which information should be carried as Peer List, Peer
Address or Peer ID? This issue has close relationship with Peer
Protocol, because it will influence the way that peers communicate
Gu, et al. Expires September 1, 2010 [Page 22]
Internet-Draft Tracker Protocol February 2010
when they are behind NAT.
1) If Peer Address, e.g. IPv4/IPv6 address, is carried, then
requesting peer can communicate with the candidate peers after
obtaining Peer List Info, if the candidate peer is in public
network or is behind Full Cone NAT. One possible problem is that
candidate peers might be behind more restrictive NAT, e.g.
Address-Restricted, Port-Restricted and symmetric NAT, which
makes direct communication between peers difficult.
2) If Peer ID is carried, we have to consider at least two scenario.
One is a Tracker-based P2P network without structured topology
among peers, e.g. topology organized by Chord. In this network,
peers totally depend on Tracker to search content and locate
peers. So even requesting peer obtains candidate Peer ID, it has
to ask Tracker to translate Peer ID into IP address before it can
communicate with candidate peers, which means providing Peer ID
in this scenario is helpless. Another is a Tracker-based P2P
network with structured topology among peers. In this case, if
Peer ID is provided in Peer List, requesting peer can find and
establish connection with the candidate peers by mechanism like
RELOAD. NAT Traversal problem still exists if Peer ID is
carried. And peers cannot directly communicate even if they are
in public network.
It's too early to decide which one is more appropriate when we define
Tracker Protocol. We may have to wait and make progress inline with
Peer Protocol. Herein, we leave it as an open issue and temporarily
define a structure that can be interpreted as either Peer IP Address
or Peer ID, and we call it Peer Identity.
Note that, because of the limited packet size, message with a very
long list of peers will be split into several packets and the S Flag
in Message Header will be set. The requesting peer has to wait until
all packets are received before it is able to get the whole peer
list. An improved solution is for Tracker to split the peer list
into several lists of peers and responds in series, according to some
ISP preference, such as peer preference defined by ALTO, and
preferred peers status defined in Destination Peer Preference Info.
Then requesting peer needs not to wait for the whole list of
candidate peers and the peers it has already received are much likely
to serve it better than those come later.
Peer Identity, which could be IP Address or Peer ID, has the
following structure.
Gu, et al. Expires September 1, 2010 [Page 23]
Internet-Draft Tracker Protocol February 2010
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|V| | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Identity (IPv4 Address:32bits/IPv6 Address or Peer ID:128bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 16 Message format of Peer Identity
P indicates what is carried in Peer Identity, 0 for Peer IP Address
and 1 for Peer ID. If P=0, V flag and port field is interpreted.
V represents IP version. If V is empty, the IP Address is IPv4 and
last 32bits of the 128bits Identity field is interpreted. If V is
set, the IP Address is IPv6.
If P=1, neither V nor Port is interpreted.
The integrated message of GET response is as following.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Status | | | |D| |
| Version |Code | RSV | GET |S|=| |
| | | | | |0| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Identity 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Identity N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 17 Message format of GET RESPONSE
Expiration Time is defined here to indicate how long the response
could live, out of security consideration. It is Absolute time. The
information provided in this message should not be used or
distributed by peers after Expiration Time. Some P2P streaming
application allows peers to share local peer list, and we are still
not sure whether this will be permitted in PPSP Peer Protocol. One
big problem of sharing peer list is validity. For example, a peer,
who is recorded in the peer list, may delete the content but is still
in peer list of the content.
Gu, et al. Expires September 1, 2010 [Page 24]
Internet-Draft Tracker Protocol February 2010
6.2.6.2. GET Peer List with Destination Peer Preference Info
Requesting peer can include Destination Peer Preference Info in the
message to indicate what kind of property the Destination Peer should
have. With Destination Peer Property Info message, a peer can notify
Tracker which kind of destination peer it prefers. This message does
not list the detail value of each kind of property, instead peer's
preference is expressed by several tags.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Status | | | |D| |
| Version |Code | RSV | GET |S|=| RSV |
| | | | | |1| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |K|S|T|L|N| RSV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Peer ID(128bit) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Swarm ID (128bits) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Chunk ID (128bits, Optional) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|B|L|N|Y|T| Property Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 18 Message format of GET REQUEST with Destination Peer Preference Info
K (1 bit): If this bit is set, Chunk ID field MUST be included;
otherwise not.
If Y flag is set, it means the requesting peer want to download from
destination peer with high security levels, e.g a peer supports
signature mechanism is preferred.
If T flag is set, it means the requesting peer want to download from
destination peer who has stay in the system for a relatively long
time.
If L flag is set, it means the requesting peer want to download from
destination peer with large number of concurrent links.
If N flag is set, it means the requesting peer do not mind
downloading from destination peer behind NAT. If it's empty, it
means the requesting peer do not accept destination peer behind NAT
Tracker will interpret and choose appropriate candidate peers
Gu, et al. Expires September 1, 2010 [Page 25]
Internet-Draft Tracker Protocol February 2010
according to Destination Peer Property. The response is the same as
that of GET response described in section6.2.5.1.
6.2.7. STATISTICS
By Statistics message, Tracker can ask peer to report peer property
info. Besides Tracker can also request for what contents a peer owns
and the sum of bytes of data it receives from the streaming system.
STATISTICS request
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | Status| | | |
| Version |R|Pri. | Code | STATISTICS |S| RSV |
| | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | p-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 19 Message format of STATISTICS REQUEST
p-Type(8bits) indicates which attributes the Tracker want to know.
STATISTICS reuses the p-Type defined in section 6.2.4.2, though not
all the p-Types defined in 6.2.4.2 will be applicable in STATISTICS.
For example, Caching size(0x00), Bandwidth(0x01), Link numbers(0x02)
and Sum Volume(0x07)is introduced. Besides, two new types are
defined herein.
Table 3 Statistics Attributes
+---------------------+
|P-Type| Definition |
+---------------------+
| 0x00 |Caching size |
+---------------------+
| 0x01 |Bandwidth |
+---------------------+
| 0x02 |Link numbers |
+---------------------+
| 0x07 |Sum Volume |
+---------------------+
| 0x08 |Content report|
+---------------------+
STATISTICS response resembles the PUT-Peer Property Info request,
e.g. using TLV format to present peer property and can be split into
several messages of response.
Gu, et al. Expires September 1, 2010 [Page 26]
Internet-Draft Tracker Protocol February 2010
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | Status| | | |
| Version |r|Pri. | Code | STATISTICS |S| RSV |
| | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | RSV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Peer ID(128bit) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ TLV Element +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ . . . +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ TLV Element +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 20 Message format of STATISTICS RESPONSE
Particularly, when p-Type is 0x08, PUT request is used to respond to
STATISTICS request, and PUT response is sent back from Tracker as
normal PUT request and response.
7. Status Code Definitions
7.1. Success 0x1
The request has succeeded. The information returned with the
response is dependent on the method used in the request.
7.2. Error
This class of status code indicates that the peer's request was not
successfully received, understood, nor accepted.
7.2.1. Invalid syntax 0x2
The request could not be understood by the Tracker due to malformed
syntax. The peer SHOULD NOT repeat the request without
modifications.
7.2.2. Invalid syntax 0x2
The request could not be understood by the Tracker due to malformed
syntax. The peer SHOULD NOT repeat the request without
modifications.
Gu, et al. Expires September 1, 2010 [Page 27]
Internet-Draft Tracker Protocol February 2010
7.2.3. Payment required 0x3
The request lack necessary information.
7.2.4. Request forbidden 0X4
The requesting peer is forbidden to send such request. For example,
peer can not sent GET request before JOIN.
7.2.5. Object not found 0X5
The target resource is not recorded on Tracker.
7.3. Server Error
This class of status code indicates that the in-network storage does
not work correctly.
7.3.1. Internal server error 0X6
Tracker has internal error and could not work correctly to the
request. The peer could try the same request later.
7.3.2. Does not support 0x7
Tracker does not support the functionality required to fulfill the
request. The peer should not send the request again. For example,
Tracker is running an old version of Tracker Protocol and could not
understand some requests from a peer with latest version.
7.3.3. Temporarily overloaded 0x8
Tracker is overloaded. The peer should try the request later.
7.3.4. Version not support 0x9
Tracker does not support the version in the request.
8. Security Consideration
We consider that at least 3 security aspects should be studied in
Tracker Protocol.
1) To avoid wire tapping between Tracker and peer. This is about
peer privacy. Maybe TLS can be used to protect peer privacy.
Gu, et al. Expires September 1, 2010 [Page 28]
Internet-Draft Tracker Protocol February 2010
2) To avoid over distributing of Peer list, which can be solved by
Expiration Time in GET response.
3) Tracker Identity verification. Signature of Tracker can be
adopted to certify that the particular message is from the right
Tracker. Peer can get Public key of Tracker from Tracker or from
a third party. Tracker responses with signature and then peers
can affirm that the Identity of the sender.
Security will be considered in further version of this draft.
9. Acknowledgments
We give our acknowledgements to the following persons for their help
and comments: Roni Even, Bhumip Khasnabish,Wu Yichuan, Peng Jin, Chi
Jing, Zong Ning, Song Haibin, Zhijia Chen, Schmidt Christian,
Kangheng Wu.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[draft-ietf-p2psip-base-07]
Jennings, C., Lowekamp, B., Ed., Rescorla, E., and H.
Schulzrinne, "draft-ietf-p2psip-base-07", February 2010,
<draft-ietf-p2psip-base-07>.
10.2. Informative References
[draft-zhang-ppsp-problem-statement]
Zhang, Y., Zong, N., Camarillo, V., Seng, J., and R. Yang,
"Problem Statement of P2P Streaming Protocol (PPSP)",
October 2009, <draft-zhang-ppsp-problem-statement>.
[draft-zong-ppsp-reqs]
Zong, N., Zhang, Y., Pascual, V., and C. Williams, "P2P
Streaming Protocol (PPSP) Requirements", October 2009,
<draft-zong-ppsp-reqs>.
[draft-gu-ppsp-survey]
Gu, Y., Zong, N., Zhang, H., Zhang, Y., Camarillo, G., and
Y. Liu, "Survey of P2P Streaming Applications",
October 2009, <draft-gu-ppsp-survey>.
Gu, et al. Expires September 1, 2010 [Page 29]
Internet-Draft Tracker Protocol February 2010
Authors' Addresses
Yingjie Gu
Huawei
Baixia Road No. 91
Nanjing, Jiangsu Province 210001
P.R.China
Phone: +86-25-84565868
Email: guyingjie@huawei.com
David A. Bryan
Ethernot
Phone:
Email: dbryan@ethernot.org
Zhang Yunfei
China mobile
Phone:
Email: zhangyunfei@chinamobile.com
Liao Hongluan
China mobile
Phone:
Email: liaohongluan@chinamobile.com
Gu, et al. Expires September 1, 2010 [Page 30]