[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/