[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

PPSP                                                               Y. Gu
Internet-Draft                                                    J. Xia
Intended status: Standards Track                                  Huawei
Expires: May 3, 2012                                             R. Cruz
                                                                M. Nunes
                                                       IST/INESC-ID/INOV
                                                          David A. Bryan
                                                                 Polycom
                                                              J. Taveira
                                                                 ID/INOV
                                                            Oct 31, 2011


                             Peer Protocol
                     draft-gu-ppsp-peer-protocol-03

Abstract

   This document presents the architecture of the PPSP Peer protocol
   outlining the functional entities, message flows and message
   processing instructions, with the respective parameters.  The PPSP
   Peer Protocol proposed in this document extends the capabilities of
   PPSP to support adaptive and scalable video and 3D video, for Video
   On Demand (VoD) and Live video services.  The protocol messages
   formal syntax and semantics, methods, and formats are presented for
   both Binary and HTTP/XML encoded formats.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on May 3, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Gu, et al.                 Expires May 3, 2012                  [Page 1]


Internet-Draft                Peer Protocol                     Oct 2011


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Document Conventions . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Notational Conventions . . . . . . . . . . . . . . . . . .  4
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Protocol Architecture  . . . . . . . . . . . . . . . . . .  7
     3.2.  Example Call Flow  . . . . . . . . . . . . . . . . . . . .  9
     3.3.  Chunk Scheduling . . . . . . . . . . . . . . . . . . . . . 10
   4.  Protocol Architecture  . . . . . . . . . . . . . . . . . . . . 11
   5.  Security Consideration . . . . . . . . . . . . . . . . . . . . 13
     5.1.  Authentication . . . . . . . . . . . . . . . . . . . . . . 13
     5.2.  Content Integrity Protection Against Polluting
           Peers/Trackers . . . . . . . . . . . . . . . . . . . . . . 13
     5.3.  Residual Attacks and Mitigation  . . . . . . . . . . . . . 14
     5.4.  Pro-incentive Parameter Trustfulness . . . . . . . . . . . 14
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  Binary Encoding . . . . . . . . . . . . . . . . . . . 16
     A.1.  Methods in Peer messages . . . . . . . . . . . . . . . . . 17
   Appendix B.  HTTP/XML Encoding . . . . . . . . . . . . . . . . . . 21
     B.1.  HTTP/XML Encoding  . . . . . . . . . . . . . . . . . . . . 21
     B.2.  Method Fields  . . . . . . . . . . . . . . . . . . . . . . 22
     B.3.  Message Processing . . . . . . . . . . . . . . . . . . . . 23
     B.4.  GET_PEERLIST Message . . . . . . . . . . . . . . . . . . . 24
     B.5.  GET_CHUNKMAP Message . . . . . . . . . . . . . . . . . . . 26
     B.6.  GET_CHUNK Message  . . . . . . . . . . . . . . . . . . . . 27
     B.7.  PEER_STATUS Message  . . . . . . . . . . . . . . . . . . . 29
     B.8.  TRANSPORT_NEGOTIATION Message  . . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30








Gu, et al.                 Expires May 3, 2012                  [Page 2]


Internet-Draft                Peer Protocol                     Oct 2011


1.  Introduction

   The P2P Streaming Protocol (PPSP) is composed of two protocols: the
   PPSP Tracker Protocol and the PPSP Peer Protocol
   [I-D.ietf-ppsp-problem-statement].

   The PPSP architecture requires PPSP peers able to communicate with a
   Tracker in order to participate in a particular swarm.  This
   centralized Tracker service is used for peer and content registration
   and location.  Content indexes (Media Presentation Descriptions) are
   also stored in the Tracker system allowing the association of content
   location information to the active peers in the swarm sharing the
   content.

   The PPSP Tracker Protocol provides communication between Trackers and
   Peers and outlines how a peer is able to communicate with a tracker
   in order to exchange meta information about the location of other
   peers contributing with a specific stream (swarm) the peer interested
   in, as well as to report streaming status.  The Peer can also apply
   to be a contributor for several streams (swarms), periodically
   reporting its status to the Tracker, allow it to estimate whether the
   peer is a competent contributor.

   The PPSP Peer protocol outlines how a peer is able to communicate
   with other peers in order to control the advertising and exchange of
   media data, directly between peers, for a specific stream (swarm), as
   described in [I-D.ietf-ppsp-problem-statement].

   The process used for media streaming distribution assumes a segment
   transfer scheme whereby the original content (that can be encoded
   using adaptive or scalable techniques) is chopped into small segments
   (and subsegments).  For simplicity, in this document the segments
   (and subsegments) of media are named Chunks.  The media streaming
   process has the following representations:

   1.  Adaptive - alternate representations with different qualities and
       bitrates; a single represention is non-adaptive;

   2.  Scalable description levels - multiple additive descriptions
       (i.e., addition of descriptions refine the quality of the video);

   3.  Scalable layered levels - nested dependent layers corresponding
       to several hierarchical levels of quality, i.e., higher
       enhancement layers refine the quality of the video of lower
       layers.

   4.  Scalable multiple views - views correspond to mono and
       stereoscopic 3D videos, with several hierarchical levels of



Gu, et al.                 Expires May 3, 2012                  [Page 3]


Internet-Draft                Peer Protocol                     Oct 2011


       quality.

   These streaming distribution techniques support dynamic variations in
   video streaming quality while ensuring support for a plethora of end
   user devices and network connections.

   The information that should be exchanged between peers using this
   Peer Protocol includes:

   1.  ChunkMap indicating which chunks a peer possesses.

   2.  Required ChunkIDs

   3.  Peer preferences and status information

   4.  Signalling and Data Transport protocol negotiation

   5.  Information that can help improve the performance of PPSP.

   In this document, a set of concrete information that needs to be
   exchanged between peers is introduced, together with the messages to
   convey such information.

   This documents describes the PPSP Peer protocol and how it satisfies
   the requirements for the IETF Peer-to-Peer Streaming Protocol (PPSP),
   in order to derive the implications for the standardization of the
   PPSP streaming protocols and to identify open issues and promote
   further discussion.

   This PPSP Peer Protocol proposal presents an early sketch for an
   extensible protocol that extends the capabilities of PPSP to support
   adaptive and scalable video.


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
   [I-D.ietf-ppsp-problem-statement], [I-D.gu-ppsp-tracker-protocol] and
   [I-D.cruz-ppsp-http-peer-protocol].  Additionally, This document uses
   the following acronyms and definitions frequently in itself:



Gu, et al.                 Expires May 3, 2012                  [Page 4]


Internet-Draft                Peer Protocol                     Oct 2011


   Peer-Peer Messages

      The Peer Protocol messages enable each Peer to exchange content
      availability with other Peers and request other Peers for content.

   Tracker-Peer Messages

      The Tracker Protocol messages provide communication between Peers
      and Trackers, by which Peers provide content availability, report
      streaming status and request candidate Peer lists from Trackers.

   Connection Tracker

      The Tracker Node to which the PPSP Peer will connect when it wants
      to join the PPSP system.

   Sender Peer

      A peer that contains the corresponding chunk files requested by
      leech peer is the Sender peer.  Many peers can contain the
      content, but only one who is contributing the content to the leech
      peer can be named as Sender peer.

   Leech Peer

      A peer that requests the specific media content from other peers.
      Note that the leech peer can also contribute the downloaded media
      content (i.e., chunks) even the swarm is not completed, in such
      case, the leech peer will take on the role of sender peer for
      downloaded chunks.

   Chunk Map

      A peer list that indicates which chunks can be available for leech
      peer to playback smoothly.

   Live Streaming

      The scenario where all clients receive streaming content for the
      same ongoing event.  The lags between the play points of the
      clients and that of the streaming source are small.

   Video-on-demand (VoD)

      The scenario where all clients are allowed to select and watch
      video content on demand.





Gu, et al.                 Expires May 3, 2012                  [Page 5]


Internet-Draft                Peer Protocol                     Oct 2011


   Adaptive Streaming

      Multiple alternate versions (different qualities and bitrates) of
      the same media content co-exist for the same streaming session;
      each alternate version corresponds to a different media quality
      level; peers can choose among the alternate versions for decode
      and playback.

   Scalable Streaming

      With Multiple Description Coding (MDC), multiple additive
      descriptions (that can be independently played-out) to refine the
      quality of the video when combined together.  With Scalable Video
      Coding (SVC), nested dependent enhancement layers (hierarchical
      levels of quality), refine the quality of lower layers, from the
      lowest level (the playable Base Layer).  With Multiple View Coding
      (MVC), multiple views allow the video to be played in 3D when the
      views are combined together.

   Base Layer

      The playable level in Scalable Video Coding (SVC) required by all
      upper level Enhancements Layers for proper decoding of the video.

   Enhancement Layer

      Enhancement differential quality level in Scalable Video Coding
      (SVC) used to produce a higher quality, higher definition video in
      terms of space (i.e., image resolution), time (i.e., frame rate)
      or Signal-to-Noise Ratio (SNR) when combined with the playable
      Base Layer.

   Continuous Media

      Media with an inherent notion of time, for example, speech, audio,
      video, timed text or timed metadata.

   Media Component

      An encoded version of one individual media type such as audio,
      video or timed text with specific attributes, e.g., bandwidth,
      language, or resolution.


3.  Protocol Overview






Gu, et al.                 Expires May 3, 2012                  [Page 6]


Internet-Draft                Peer Protocol                     Oct 2011


3.1.  Protocol Architecture

   The functional entities involved in the PPSP Peer Protocol are Peers,
   which may support different capabilities.

   Peers correspond to devices that actually participate in sharing a
   media content and are organized in (various) swarms corresponding
   each swarm to the group of peers streaming that content at any given
   time.

   Each peer contacts a Tracker to advertise which information it has
   available.  When a peer wishes to obtain information about the swarm,
   it contacts the Tracker to find other peers participating in that
   specific swarm.

   The tracker is a logical entity that maintains the lists of peers
   storing/exchanging chunks for a specific Live media channel or VoD
   media streaming content, answers queries from peers and collects
   information on the activity of peers.  A simplified network diagram
   showing this interaction of tracker and peers is depicted in Figure
   1.

              +-----------------------------------+
              |              Tracker              |
              +-----------------------------------+
                    ^  |                      ^
           connect/ |  |                      |
              join/ |  | peer list            |streaming Status/
              find/ |  |                      |Content availability/
             leave/ |  |                      |node capability
         disconnect |  V                      |
            +-------------+               +------------+
            |    Peer 1   |<------------->|  Peer 2    |
            +-------------+ content info/ +------------+
                           data requests

                  Figure 1: A PPSP streaming process

   The signaling between PPSP Peers and trackers is done using a
   request/reply mechanism as defined in PPSP Tracker protocol
   [I-D.gu-ppsp-tracker-protocol].

   This protocol can be used to connect peers that are sharing real-time
   streams of video or offline video, segmented in chunks.  As for the
   streams of video, they can correspond to Live or Video on Demand
   streaming modes.

   There are some significant differences between the details of these



Gu, et al.                 Expires May 3, 2012                  [Page 7]


Internet-Draft                Peer Protocol                     Oct 2011


   scenarios, i.e., Live streaming, VoD and offline video.  From a high
   level perspective the overall structure is quite similar.  The
   optimal signaling flow for the different scenarios could also be
   different, but it depends on the real situation and on the
   implementer's choice

   This draft defines a PULL based streaming signaling, as mandatory.
   However, a PUSH based or hybrid streaming signaling can optionally be
   considered.

   For a PULL based Peer Protocol, the steps of signaling for a peer
   wishing to participate either in a Live streaming or a VoD or offline
   video is as follows (assuming the leech peer has already obtained
   from the Tracker a list of peers) and that, in case of traversing a
   NAT, performed ICE connectivity checks [I-D.li-ppsp-nat-traversal]
   with candidate peers using PPSP's own authentication method, as
   described in [I-D.gu-ppsp-tracker-protocol]:

   1.  The leech peer using PPSP Peer Protocol messages, establishes a
       connection to at least one of the peers in the Peerlist, based on
       the known PeerID and Peer IP address.

   2.  The peer sends request to candidate peers and the request could
       include one or more of the information described in below:

       *  Request for the data availability of the candidate peer;

       *  Notify its data availability to the candidate peer;

       *  Request for the peer status of the candidate peer;

       *  Notify its peer status to the candidate peer;

       *  Request for additional peerlist;

       *  Transport negotiation, wherein the requesting peer can have
          two choices:

          +  Only support Mandatory Tranport Protocol;

          +  Providing a list of supported Transport protocol.

   3.  Finally, the peers exchange the actual chunks of data, using the
       mechanism/protocol negotiated in the previous step.

   In terms of Data Transport protocol negotiation, the leech peer can
   either inform the candidate that it supports a Mandatory Tranport
   Protocol or provides a list of supported Transport protocols.  That



Gu, et al.                 Expires May 3, 2012                  [Page 8]


Internet-Draft                Peer Protocol                     Oct 2011


   there are several options here to negotiate the connection model.
   The PPSP Peer Protocol may include new mechanisms to negotiate the
   protocol used to exchange data, or the offer-answer mechanism in SIP
   [RFC3261] (the IETF protocol for session establishment) along with
   SDP [RFC4566].

   Note also that these mechanisms are not new protocols defined in
   PPSP, but existing protocols, and would eventually differ between an
   offline and a Live streaming scenario.  Mechanisms such as flow
   control are handled in the negotiated Data Transport mechanism, not
   in the Peer Protocol itself.

3.2.  Example Call Flow

   This is a very high-level example of a session in which a leech peer
   joins a swarm, and retrieves some data (either via blocks or by
   streaming).  The protocol used is indicated for each transaction.
   Note that not all of the communication shown in this figure are in
   scope of Peer Protocol, only those request/response followed by Peer
   Protocol are in scope.































Gu, et al.                 Expires May 3, 2012                  [Page 9]


Internet-Draft                Peer Protocol                     Oct 2011


    +--------+      +--------+     +--------+    +---------+  +--------+
    | Player |      | Peer 1 |     | Portal |    | Tracker |  | Peer 2 |
    +--------+      +--------+     +--------+    +---------+  +--------+
       |                |               |              |           |
       |                |               |              |           |
       |                |------------FIND(optional)--------------->|
       |<-----------OK--|<----------------Peerlist(optional)-------|
       |                |               |              |           |
       |                |--------GET_CHUNKMAP (Peer protocol)----->|
       |                |<--------------------ChunkMap-------------|
       |                |               |              |           |
       |                |--------GET_STATUS (Peer protocol)------->|
       |                |<----------------PEER2 STATUS-------------|
       |                |               |              |           |
       |                |--TRANSPORT_NEGOTIATION (Peer protocol)-->|
       |                |<-------------CONNECTION SETUP------------|
       |                |               |              |           |
       |--GET (Chunk)-->|--------GET_CHUNK (Peer protocol)-------->|
       |<---OK+Chunk----|<-----------------Chunk-------------------|
       :                :               :              :           :
       |                |--------GET_STATUS (Peer protocol)------->|
       |                |<----------------PEER2 STATUS-------------|
       |                |               |              |           |
       |--GET (Chunk)-->|--------GET_CHUNK (Peer protocol)-------->|
       |<-----OK+Chunk--|<------------------Chunk------------------|
       :                :               :              :           :
       |                |                              |           |

                         Figure 2: Example Call Flow

3.3.  Chunk Scheduling

   The goal of chunk trading is receiving the stream smoothly (and with
   small delay) and to cooperate in the distribution procedure.  Peers
   need to exchange information about their current status to enable
   scheduling decisions.  The information exchanged refers to the state
   of the peer with respect to the flow, i.e., a map of which chunks are
   needed by a peer to smoothly playback the stream.

   This task means:

   1.  sending chunk maps to other nodes with the proper timing,

   2.  receiving chunk maps from other nodes and merging the information
       in the local buffer map.

   3.  besides chunk map exchange, the signaling includes Status/
       Request/Select primitives used to trade chunks.



Gu, et al.                 Expires May 3, 2012                 [Page 10]


Internet-Draft                Peer Protocol                     Oct 2011


   The core of the scheduler, not described in this specification, is
   the algorithm used to choose the chunks to be exchanged and the peers
   to communicate with.


4.  Protocol Architecture

   The PPSP Peer Protocol is a request-response protocol.  Requests are
   sent, and responses returned to these requests.  A single request
   generates a single response (neglecting fragmentation of messages).

   As shown in example call flow depicted in Figure 2, the Peer protocol
   only provides signaling messages for obtaining additional peerlist
   (optionally), query for content availability and negotiation for
   transfer protocol.  Peer protocol may also provide communication for
   peers to exchange information that can improve system performance.

   The encoding for the signaling messages is not yet decided.  Two
   encodings are proposed, a Text-based (HTTP/XML) and a Binary-based,
   described in Appendixes A and B. The authors will raise more
   discussion on the encoding, and will move the one that gets rough
   consensus of the PPSP WG to the draft text.  In the Appendixes, some
   considerations are provided on each encoding based on the Mail List
   discussions.

   The specific PPSP signaling messages are listed as following:

   GET_PEERLIST:

      The GET_PEERLIST message is sent from a leech peer to one or more
      remote peers in order for a peer to refresh/update the list of
      active peers in the swarm.

      When receiving the GET_PEERLIST message, and if the message is
      well formed and accepted, the peer will search for the requested
      data and will respond to the leech peer with the peer list with
      PeerIDs (and respective IP Addresses) of sender peers that can
      provide the specific content.


   GET_CHUNKMAP:

      The GET_CHUNKMAP message is sent from a leech peer to one or more
      remote peers in order to receive the map of chunks of a content
      (of a swarm identified by SwarmID) the other peer presently
      stores.  The chunk map returned by the other peer lists ranges of
      chunks.




Gu, et al.                 Expires May 3, 2012                 [Page 11]


Internet-Draft                Peer Protocol                     Oct 2011


      When receiving the GET_CHUNKMAP message, and if the message is
      well formed and accepted, the peer will search for the requested
      data and will respond to the leech peer with the map of chunks it
      currently stores of the specific content.


   GET_CHUNK:

      The GET_CHUNK message is sent from a leech peer to sender peer in
      order to request the delivery of media content chunks.

      When receiving the GET_CHUNK message, and if the message is well
      formed and accepted, the peer will search for the requested data
      and will respond to the leech peer with the specific chunks the
      leech peer requested.


   GET_STATUS:

      The GET_ STATUS message is sent from a leech peer to one or more
      remote peers in order to request the corresponding properties of
      the sender peers.  The corresponding properties are enumerated in
      [draft-gu-ppsp-tracker-protocol], e.g., Caching Size, Bandwidth
      etc.

      When receiving the GET_STATUS message, and if the message is well
      formed and accepted, the peer will search for the requested data
      and will respond to the leech peer with the specific parameters to
      the properties the leech peer requested.


   TRANSPORT_NEGOTIATION:

      The TRANSPORT_NEGOTIATION message is sent from a leech peer to a
      sender peer in order to negotiate the underlying transport
      protocol.  Leech peer provide a set of transport protocols it
      supported to sender peer, and leave send peer to choose its
      preference.  Reusing existing transport protocol to transfer data
      is recommended.

      When receiving the TRANSPORT_NEGOTIATION message, and if the
      message is well formed and accepted, the sender peer will decide
      the transport protocol and will respond to the leech peer with the
      specific transport protocol the sender peer preferred.







Gu, et al.                 Expires May 3, 2012                 [Page 12]


Internet-Draft                Peer Protocol                     Oct 2011


5.  Security Consideration

   P2P streaming systems are subject to attacks by malicious/unfriendly
   peers/trackers that may eavesdrop on signaling, forge/deny
   information/knowledge about streaming content and/or its
   availability, impersonating to be another valid participant, or
   launch DoS attacks to a chosen victim.

   No security system can guarantees complete security in an open P2P
   streaming system where participants may be malicious or
   uncooperative.  The goal of security considerations described here is
   to provide sufficient protection for maintaining some security
   properties during the peer-peer communication even in the face of a
   large number of malicious peers.

   As in typical Peer to Peer network, the most significant security
   issue is that the peers are untrusted.  A peer may announce that it
   has a specific content, but the content might be just noise or it
   could be poisoned.  A peer could also download a large number of
   chunks but upload very few of them.  This problem can be alleviated
   by incentive mechanism, the goal of which is to reward honest peers
   and degrade dishonest peers.

5.1.  Authentication

   To protect the PPSP signaling from attackers pretending to be valid
   peers (or peers other than themselves) all messages received in the
   Tracker are required to be received from authorized peers.

   For that purpose a peer must enroll in the system via a centralized
   enrollment server.  The enrollment server is expected to provide a
   proper PeerID for the peer and information about the authentication
   mechanisms.  The specification of the enrollment method and the
   provision of identifiers and authentication tokens is out of scope of
   this draft.

   The authetication mechanism MUST allow the means for negotiating data
   security layer mechanisms to provide data integrity, data
   confidentiality, and other services, subject to local policies and
   security requirements.

5.2.  Content Integrity Protection Against Polluting Peers/Trackers

   Malicious peers may declaim ownership of popular content to the
   Tracker but serve polluted (i.e., decoy content or even virus/trojan
   infected contents) to other peers.  This kind of pollution can be
   detected by incorporating a checksum distribution scheme for
   published sharing content.  As content chunks of the same content are



Gu, et al.                 Expires May 3, 2012                 [Page 13]


Internet-Draft                Peer Protocol                     Oct 2011


   transferred independently and concurrently, correspondent chunk-level
   checksums MUST be distributed from an authentic origin.

5.3.  Residual Attacks and Mitigation

   To mitigate the impact of sybil attackers, impersonating a large
   number of valid participants by repeatedly acquiring different peer
   identities, the enrollment server SHOULD carefully regulate the rate
   of peer/tracker admission.

   There is no guarantee that a peer honestly report its status to the
   Tracker, or server authentic content to other peers as it claims to
   the Tracker.  It is expected that a global trust mechanism, where the
   credit of each peer is accumulated from evaluations for previous
   transactions, may be taken into account by other peers when selecting
   partner for future transactions, helping to mitigate the impact of
   such malicious behaviors.  A globally trusted Tracker MAY also take
   part of the trust mechanism by collecting evaluations, computing
   credit values and providing them to joining peers.

5.4.  Pro-incentive Parameter Trustfulness

   Properties for PEER_STATUS messages will consider pro-incentive
   parameters, which can enable the improvement of the performance of
   the whole P2P streaming system.  Trustworthiness of these pro-
   incentive parameters is critical to the effectiveness of the
   incentive mechanisms.  For example, ChunkMap is essential, and needs
   to be accurate.  The P2P system should be designed in a way such that
   a peer will have the incentive to report truthfully its ChunkMap
   (otherwise it may penalize itself).

   Furthermore, both the amount of upload and download should be
   reported to the Tracker to allow checking if there is any
   inconsistency between the upload and download report, and establish
   an appropriate credit/trust system.


6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.



Gu, et al.                 Expires May 3, 2012                 [Page 14]


Internet-Draft                Peer Protocol                     Oct 2011


   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [draft-ietf-p2psip-base]
              Jennings, C., Lowekamp, B., Ed., Rescorla, E., and H.
              Schulzrinne, "draft-ietf-p2psip-base-07", February 2010,
              <draft-ietf-p2psip-base>.

6.2.  Informative References

   [I-D.ietf-ppsp-problem-statement]
              Zhang, Y., Zong, N., Camarillo, V., Seng, J., and R. Yang,
              "Problem Statement of P2P Streaming Protocol (PPSP)",
              Januray 2011, <I-D.ietf-ppsp-problem-statement>.

   [I-D.ietf-ppsp-reqs]
              Zong, N., Zhang, Y., Pascual, V., and C. Williams, "P2P
              Streaming Protocol (PPSP) Requirements", February 2011,
              <I-D.ietf-ppsp-reqs>.

   [I-D.ietf-ppsp-survey]
              Gu, Y., Zong, N., Zhang, H., Zhang, Y., Camarillo, G., and
              Y. Liu, "Survey of P2P Streaming Applications",
              March 2011, <I-D.ietf-ppsp-survey>.

   [I-D.gu-ppsp-tracker-protocol]
              Cruz, R., Nunes, M., Gu, Y., Xia, J., Bryan, D., Taveira,
              J., and D. Deng, "PPSP Tracker Protocol", March 2011,
              <I-D.gu-ppsp-tracker-protocol>.

   [I-D.cruz-ppsp-http-peer-protocol]
              Gu, Y., Xia, J., Cruz, R., Nunes, M., Bryan, D., and J.
              Taveira, "PPSP HTTP-Based Peer Protocol", March 2011,
              <I-D.cruz-ppsp-http-peer-protocol>.

   [I-D.li-ppsp-nat-traversal]
              Li , L., Wang , J., and W. Chen , "PPSP NAT Traversal",
              March 2011, <I-D.li-ppsp-nat-traversal>.

   [BittorrentSpecification]
              "Bittorrent Protocol Specification v1.0", February 2010,
              <Bittorrent Specification>.





Gu, et al.                 Expires May 3, 2012                 [Page 15]


Internet-Draft                Peer Protocol                     Oct 2011


Appendix A.  Binary Encoding

   Binary Encoding is an encoding of data in plain text.  More
   precisely, it is an encoding of binary data in a sequence of ASCII-
   printable characters.  Binary Encoding is necessary for transmission
   of data when the channel or the protocol only allows ASCII-printable
   characters.

   The PPSP Peer protocol can be carried on top of IP, UDP, RTP or TCP.
   But using which layer to carry peer protocol is out of scope in
   current stage.

   The peer message header has the following format:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     PPSP Peer Protocol Token                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Version     |    Message    |             Reserved          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Transaction ID
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Message Length                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 3: PPSP Peer message header

   The fields have the following meaning:

   PPSP Peer Protocol Token:  32 bits

      A fixed token indicating to the receiver this message is a PPSP
      Peer Protocol message.  The token field is four bytes long.  This
      value MUST be set to 0x50505350, the string "PPSP".


   Version: 8 bits   The version of the PPSP peer protocol being used in
      the form of a fixed point integer between 0.1 and 25.4.  For the
      version of the protocol described in this document, this field
      MUST be set to 0.1.  The version field is one byte long.








Gu, et al.                 Expires May 3, 2012                 [Page 16]


Internet-Draft                Peer Protocol                     Oct 2011


   Message Types:  8 bits

      Message types currently have two kinds of value: Request and
      Response.


   Reserved:  16 bits

      Not to be assigned.  Reserved values are held for special uses,
      such as to extend the namespace when it becomes exhausted.
      Reserved values are not available for general assignment.


   Transaction ID:  64 bits

      Identifies the transaction and also allows receivers to
      disambiguate transactions which are otherwise identical.
      Responses use the same Transaction ID as the request they
      correspond to.  Transaction IDs are also used for fragment
      reassembly.


   Message Length:  32 bits:

      The length of the message, including header, in bytes.  Note if
      the message is fragmented, this is the length of this message, not
      the total length of all assembled fragments.


A.1.  Methods in Peer messages

   To improve the compatibility of the peer methods, the method fields
   in message extension MUST be encoded as TLV elements as described
   below and sketched in Figure 4:

   To improve the compatibility of the peer methods, the method fields
   in message extension MUST be encoded as TLV elements as described
   below and sketched in Figure 4:


   o  Type: A single-octet identifier that defines the type of the
      parameter represented in this TLV element.

   o  Length: A two-octet field that indicates the length (in octets) of
      the TLV element excluding the Type and Length fields, and the
      8-bit Reserved field between them.  Note that this length does not
      include any padding that is required for alignment.




Gu, et al.                 Expires May 3, 2012                 [Page 17]


Internet-Draft                Peer Protocol                     Oct 2011


   o  Value: Variable-size set of octets that contains the specific
      value for the parameter.

   In the extensions, the Reserved field SHALL be set to zero and
   ignored.  If a TLV element does not fall on a 32-bit boundary, the
   last word MUST be padded to the boundary using further bits set to
   zero.

   In a peer message, any method extension MUST be placed after the
   mandatory message header.  The extensions MAY be placed in any order.

        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     |   Reserved    |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                             Value                             :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 4: Structure of a TLV element

   Method Type:  8 bits

      Indicates the method type for the message.  There are five method
      types: GET_PEERLIST, GET_CHUNKMAP, GET_CHUNK, GET_ PROPERTY and
      TRANSPORT_NEGOTIATION.  They are counted from 1 to 5.


   Method Body Length:  24 bits

      The length of the method body in bytes.


A.1.1.  GET_PEERLIST

   Peerlist is composed of several pairs of Peer ID and Peer IP.  Peer
   ID is a 128 bit integer that is unique in the P2P streaming system.
   That's no matter there is a centralized tracker or several
   distributed trackers in the streaming system, a peer ID should be
   unique.











Gu, et al.                 Expires May 3, 2012                 [Page 18]


Internet-Draft                Peer Protocol                     Oct 2011


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   00000001  |                Method Body Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         PEER ID 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         PEER IP 1                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         PEER ID 2
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 PEER IP 2                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 5: GET_PEERLIST Method Body

A.1.2.  GET_CHUNKMAP

   Chunkmap of a content (a swarm identified by SwarmID)

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   00000002  |                Method Body Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SWARM ID 1                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Chunkmap                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                                                               :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Gu, et al.                 Expires May 3, 2012                 [Page 19]


Internet-Draft                Peer Protocol                     Oct 2011


                          Figure 6: GET_CHUNKMAP Method Body

A.1.3.  GET_CHUNK

   [TBD]

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   00000003  |                Method Body Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         SWARM ID
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +                         Chunk ID
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                         Figure 6: GET_CHUNKMAP Method Body

A.1.4.  GET_STATUS

   Several property types are defined in I-D.gu-ppsp-tracker-protocol.
   But not all of the property types are reasonable to be used in peer
   protocol.  So we just list the following property types.  New types
   can be easily added.

   +-------------+----------------------------------------------+------+
   |   PROPERTY  |                  Description                 | Code |
   +-------------+----------------------------------------------+------+
   | CachingSize |   Caching size: available size for caching   | 0x01 |
   |  Bandwidth  |        Bandwidth: available bandwidth        | 0x02 |
   |  LinkNumber |   Link number: acceptable links for remote   | 0x03 |
   |             |                     peer                     |      |
   | Certificate |     Certificate: certificate of the peer     | 0x04 |
   +-------------+----------------------------------------------+------+


                        Table 1: Status changed between peers







Gu, et al.                 Expires May 3, 2012                 [Page 20]


Internet-Draft                Peer Protocol                     Oct 2011


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   00000004  |                Method Body Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  STATUS Code|                  STATUS Length                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        STATUS Value                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                         Figure 6: GET_STATUS Method Body

A.1.5.  TRANSPORT_NEGOTIATION

   To Do: Define mandatory transport protocol and some optional
   transport protocol.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   00000005  |                Method Body Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Method Body                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                        Figure 7: TRANSPORT_NEGOTIATION Method Body


Appendix B.  HTTP/XML Encoding

   The PPSP Peer Protocol HTTP/XML encoding messages follow the request
   and response standard formats for HTTP Request and Response messages
   [RFC2616].

B.1.  HTTP/XML Encoding

   A Request message is a standard HTTP Request generated by the HTTP
   Client Peer with the following syntax:

         <Method> /<Resource> HTTP/1.1
         Host: <Host>




Gu, et al.                 Expires May 3, 2012                 [Page 21]


Internet-Draft                Peer Protocol                     Oct 2011


   The HTTP Method and URI path (the Resource) indicates the operation
   requested.  The current proposal uses only HTTP POST as a mechanism
   for the request messages.

   The Host header follows the standard rules for the HTTP 1.1 Host
   Header.

   The Response message is also a standard HTTP Response generated by
   the HTTP Serving Peer with the following syntax:

         HTTP/1.1 <StatusCode> <StatusMsg>
         Content-Lenght: <ContentLenght>
         Content-Type: <ContentType>
         Content-Encoding: <ContentCoding>
         <Response_Body>

   The body for both Request and Response messages are encoded in XML
   for all the PPSP Peer Protocols messages, with the following schema
   (the XML information being method specific):

         <?xml version="1.0" encoding="utf-8"?>
         <ProtocolName version="#.#">
            <Method>***</Method>     <!-- for the Request method -->
            <Response>***</Response> <!-- for the Response method -->
            <TransactionID>###</TransactionID>
              ...XML information specific of the Method...
         </ProtocolName>

   In the XML body, the *** represents alphanumeric data and ###
   represents numeric data to be inserted.  The <Method> corresponds to
   the method type for the message, the <Response> corresponds to the
   response method type of the message and the element <TransactionID>
   uniquely identifies the transaction.

   The Response message MAY use Content-Encoding entity-header with
   "gzip" compression scheme [RFC2616] for faster transmission times and
   less network bandwidth usage.

B.2.  Method Fields

   Table B 1 and Table B 2 define the valid string representations for
   the requests and responses, respectively.  These values MUST be
   treated as case-insensitive.








Gu, et al.                 Expires May 3, 2012                 [Page 22]


Internet-Draft                Peer Protocol                     Oct 2011


             +-----------------------+--------------------------+
             | PPSP Request          | XML Request Value String |
             +-----------------------+--------------------------+
             | GET_PEERLIST          |          GET_PEERLIST    |
             | GET_CHUNKMAP          |          GET_CHUNKMAP    |
             | GET_CHUNK             |          GET_CHUNK       |
             | PEER_STATUS           |          PEER_STATUS     |
             | TRANSPORT_NEGOTIATION |          TRANSP_NEGO     |
             +-----------------------+--------------------------+

                  Table B 1: Valid Strings for Requests


     +----------------------+---------------------+--------------------+
     | Response Method Name |    HTTP Response    | XML Response Value |
     |                      |      Mechanism      |                    |
     +----------------------+---------------------+--------------------+
     |    SUCCESSFUL (OK)   |        200 OK       |         OK         |
     |    INVALID SYNTAX    |   400 Bad Request   |   INVALID SYNTAX   |
     |      VERSION NOT     |   400 Bad Request   |     VERSION NOT    |
     |       SUPPORTED      |                     |      SUPPORTED     |
     |    AUTHENTICATION    |   401 Unauthorized  |   AUTHENTICATION   |
     |       REQUIRED       |                     |      REQUIRED      |
     |   MESSAGE FORBIDDEN  |    403 Forbidden    |  MESSAGE FORBIDDEN |
     |   OBJECT NOT FOUND   |    404 Not Found    |  OBJECT NOT FOUND  |
     |    INTERNAL ERROR    | 500 Internal Server |   INTERNAL ERROR   |
     |                      |        Error        |                    |
     |      TEMPORARILY     |     503 Service     |     TEMPORARILY    |
     |      OVERLOADED      |     Unavailable     |     OVERLOADED     |
     +----------------------+---------------------+--------------------+

                    Table B 2: Valid Strings for Responses

B.3.  Message Processing

   When a PPSP Peer Protocol message is received in a peer, some basic
   processing is performed, regardless of the message type.  Upon
   reception, a message is examined to ensure that it is properly
   formed.  The receiver MUST check that the HTTP message itself is
   properly formed, and if not appropriate standard HTTP errors MUST be
   generated.  The receiver must also verify that the XML body is
   properly formed.  If the message is found to be incorrectly formed or
   the length does not match the length encoded in the header, the
   receiver MUST reply with an HTTP 400 response with a PPSP XML body
   with the Response method set to INVALID SYNTAX.






Gu, et al.                 Expires May 3, 2012                 [Page 23]


Internet-Draft                Peer Protocol                     Oct 2011


B.4.  GET_PEERLIST Message

   The GET_PEERLIST message is sent from a client peer to a selected
   serving peer in order for a peer to refresh/update the list of active
   peers in the swarm.

   The Request message uses a HTTP POST method with the following body:

         <?xml version="1.0" encoding="utf-8"?>
         <PPSPPeerProtocol version="#.#">
            <Method>GET_PEERLIST</Method>
            <PeerID>***</PeerID>
            <SwarmID>***</SwarmID>
            <TransactionID>###</TransactionID>
         </PPSPPeerProtocol>

   The sender MUST properly form the XML body, MUST set the Method
   string to GET_PEERLIST, MUST set the PeerID to the PeerID of the
   peer, MUST set the SwarmID to the joined swarm identifier and
   randomly generate and set the TransactionID value.

   When receiving the GET_PEERLIST message, and if the message is well
   formed and accepted, the peer will search for the requested data and
   will respond to the requesting peer with an HTTP 200 OK message
   response with a PPSP XML payload SUCCESSFUL, as well as the peer list
   with PeerIDs (and respective IP Addresses) of peers that can provide
   the specific content.

   The response MUST have the same TransactionID value as the request.

   An example of the Response message structure is the following:




















Gu, et al.                 Expires May 3, 2012                 [Page 24]


Internet-Draft                Peer Protocol                     Oct 2011


         <?xml version="1.0" encoding="utf-8"?>
         <PPSPPeerProtocol version="#.#">
            <Response>OK</Response>
            <SwarmID>***</SwarmID>
            <TransactionID>###</TransactionID>
            <PeerInfoList>
               <PeerInfo>
                  <PeerID>***</PeerID>
                  <PeerType>***</PeerType>
                  <PeerAddresses>
                     <PeerAddress ip="##.##.##.##"
                                  port="###" />
                     <PeerAddress ip="hh:hh:hh:hh:hh:hh:hh:hh"
                                  port="###" />
                  </PeerAddresses>
                  <PeerLocation>****</PeerLocation>
                  <ConnectionType>***</ConnectionType>
                  <EndPointRankCost>###</EndPointRankCost>
               </PeerInfo>
               <PeerInfo>
                  <PeerID>***</PeerID>
                  <PeerType>***</PeerType>
                  <PeerAddresses>
                     <PeerAddress ip="##.##.##.##"
                                  port="###" />
                     <PeerAddress ip="hh:hh:hh:hh:hh:hh:hh:hh"
                                  port="###" />
                  </PeerAddresses>
                  <PeerLocation>****</PeerLocation>
                  <ConnectionType>***</ConnectionType>
                  <EndPointRankCost>###</EndPointRankCost>
               </PeerInfo>
            </PeerInfoList>
         </PPSPPeerProtocol>

   The element <PeerInfoList> MAY contain multiple <PeerInfo> child
   elements.

   The element <PeerAddresses> MAY contain multiple <PeerAddress> child
   elements with attributes "ip" and "port" corresponding to each of the
   network interfaces of the peer.  The "ip" attribute can be expressed
   in dotted decimal format for IPv4 or 16-bit hexadecimal values (hh)
   separated by colons (:) for IPv6.

   The elements <PeerLocation> and <ConnectionType> have a string
   format, and together with the element <EndPointRankCost> of numerical
   integer format, form a set of information related to peer location.




Gu, et al.                 Expires May 3, 2012                 [Page 25]


Internet-Draft                Peer Protocol                     Oct 2011


B.5.  GET_CHUNKMAP Message

   The GET_CHUNKMAP message is sent from a client peer to a selected
   serving peer in order to receive the map of chunks of a content (of a
   swarm identified by SwarmID) the other peer presently stores.  The
   chunk map returned by the other peer lists ranges of chunks.  The
   Request message uses a HTTP POST method with the following body:

         <?xml version="1.0" encoding="utf-8"?>
         <PPSPPeerProtocol version="#.#">
            <Method>GET_CHUNKMAP</Method>
            <PeerID>***</PeerID>
            <SwarmID>***</SwarmID>
            <TransactionID>###</TransactionID>
         </PPSPPeerProtocol>

   The sender MUST properly form the XML body, MUST set the Method
   string to GET_CHUNKMAP, MUST set the PeerID to the PeerID of the
   peer, MUST set the SwarmID to the joined swarm identifier and
   randomly generate and set the TransactionID value.

   When receiving the GET_CHUNKMAP message, and if the message is well
   formed and accepted, the peer will search for the requested data and
   will respond to the requesting peer with an HTTP 200 OK message
   response with a PPSP XML payload SUCCESSFUL, as well as the map of
   chunks it currently stores of the specific content.

   The response MUST have the same TransactionID value as the request.

   The Response message is an HTTP 200 OK message with the following
   body, exemplified for a video component of a media clip:

         <?xml version="1.0" encoding="utf-8"?>
         <PPSPPeerProtocol version="#.#">
            <Response>OK</Response>
            <TransactionID>###</TransactionID>
            <StreamInfo>
               <SwarmID>***</SwarmID>
               <Clip>
                  <Name>***</Name>
                  <ChunkSegments type="video/audio/etc">
                     <ChunkSegment from="###" to="###"
                                   bitmapSize="###">
                        ...(base64 string)...
                    </ChunkSegment>
                  </ChunkSegments>
               </Clip>
            </StreamInfo>



Gu, et al.                 Expires May 3, 2012                 [Page 26]


Internet-Draft                Peer Protocol                     Oct 2011


         </PPSPPeerProtocol>

   The element <StreamInfo> MAY contain multiple <Clip> child elements.

   The element <ChunkSegments> has an attribute "type" that indicates
   the type of media of the corresponding chunks.

   A <ChunkSegments> element MAY contain multiple <ChunkSegment> child
   elements with attributes "from" and "to" corresponding to ranges of
   contiguous chunks.  The "from", "to", and "bitmapSize" attributes are
   expressed as integer number string format.  The <ChunkSegment>
   content corresponds to the chunk map, and is represented as base64
   encoded string.

B.6.  GET_CHUNK Message

   The GET_CHUNK message is sent from a client peer to a serving peer in
   order to request the delivery of media content chunks.  The Request
   message uses a HTTP POST method with the following body:

         <?xml version="1.0" encoding="utf-8"?>
         <PPSPPeerProtocol version="#.#">
            <Method>GET_CHUNK</Method>
            <PeerID>***</PeerID>
            <SwarmID>***</SwarmID>
            <TransactionID>###</TransactionID>
         </PPSPPeerProtocol>

   The sender MUST properly for the HTTP request for a POST method
   including the URI path (the Resource) of the chunk.  The sender MUST
   also properly form the XML body, MUST set the Method string to
   GET_CHUNK, MUST set the PeerID to the PeerID of the peer, MUST set
   the SwarmID to the joined swarm identifier and randomly generate and
   set the TransactionID value.

















Gu, et al.                 Expires May 3, 2012                 [Page 27]


Internet-Draft                Peer Protocol                     Oct 2011


    +--------------+                                     +-------------+
    | Peer (Leech) |                                     | Peer (Seed) |
    +--------------+                                     +-------------+
        |   POST /path/name/123456789-L0-00000.h264 HTTP/1.1    |
        |   Host: example.net                       |
        |------------------------------------------------------>|
        |   <?xml version="1.0" encoding="utf-8"?>              |
        |   <PPSPPeerProtocol version="#.#">                    |
        |      <Method>GET_CHUNK</Method>                       |
        |      <PeerID>***</PeerID>                             |
        |      <SwarmID>***</SwarmID>                           |
        |      <TransactionID>###</TransactionID>               |
        |   </PPSPPeerProtocol>                                 |
        |                                                       |
        |                                                       |
        |   HTTP/1.1 200 OK                                     |
        |   Content-Type: text/xml                              |
        |   Transfer-Encoding: chunked                          |
        |<------------------------------------------------------|
        |                                                       |
        |   143                                                 |
        |   <?xml version="1.0" encoding="utf-8"?>              |
        |   <PPSPPeerProtocol version="#.#">                    |
        |      <Response>OK</Response>                          |
        |      <TransactionID>###</TransactionID>               |
        |   </PPSPPeerProtocol>                                 |
        |                                                       |
        |   ###                                                 |
        |   (### bytes of the video chunk)                      |
        |   0                                                   |

       Figure B 1: Example of GET_CHUNK message sequence (simplified)

   When receiving the GET_CHUNK message, and if the message is well
   formed and accepted, the peer will search for the requested data and
   will respond to the requesting peer with an HTTP 200 OK message
   response with a PPSP XML payload SUCCESSFUL.

   The Response message is an HTTP 200 OK message.  If The Data
   Transport Protocol negotiated is also HTTP/XML, the body of the
   response to GET_CHUNK can be immediately followed by the chunk data
   transfer, as shown in Figure B 1.

   The response MUST have the same TransactionID as the request.







Gu, et al.                 Expires May 3, 2012                 [Page 28]


Internet-Draft                Peer Protocol                     Oct 2011


B.7.  PEER_STATUS Message

   The PEER_STATUS message is sent from a serving peer to a client peer
   to indicate its participation status.  The information conveyed may
   include information related to chunk trading like "choke" (to inform
   the other peer of the intention to stop sending data to it) and
   "unchoke" (to inform the other peer of the intention to start/re-
   start sending data to it).

   The Request message uses a HTTP POST method with the following body:

         <?xml version="1.0" encoding="utf-8"?>
         <PPSPPeerProtocol version="#.#">
            <Method>PEER_STATUS</Method>
            <PeerID>***</PeerID>
            <SwarmID>***</SwarmID>
            <TransactionID>###</TransactionID>
            <Status>(choke/unchoke)</Status>
         </PPSPPeerProtocol>

   The sender MUST properly form the XML body, MUST set the Method
   string to PEER_STATUS, MUST set the PeerID to the PeerID of the peer,
   MUST set the SwarmID to the joined swarm identifier and randomly
   generate and set the TransactionID value.

   When receiving the PEER_STATUS message, and if the message is well
   formed and accepted, the peer will respond to the requesting peer
   with an HTTP 200 OK message response with a PPSP XML payload
   SUCCESSFUL.

   If the status signal received is "choke" the peer will stop
   requesting chunks from the other peer until receiving an "unchoke"
   status signal.

   The only element currently defined in the request message is
   <Status>, assuming values of "choke" and "unchoke", but, in future,
   other values may be added.

   The Response message is an HTTP 200 OK message with the following
   body.

         <?xml version="1.0" encoding="utf-8"?>
         <PPSPPeerProtocol version="#.#">
            <Response>OK</Response>
            <TransactionID>###</TransactionID>
         </PPSPPeerProtocol>

   The response MUST have the same TransactionID value as the request.



Gu, et al.                 Expires May 3, 2012                 [Page 29]


Internet-Draft                Peer Protocol                     Oct 2011


   The only element currently defined in the response message is the
   <TransactionID>, but, in future, other elements may be added, for
   example, containing statistical data or other primitives for chunk
   trading negotiation.

B.8.  TRANSPORT_NEGOTIATION Message

   To Do: Define message format, mandatory transport protocol and some
   optional transport protocols.


Authors' Addresses

   Yingjie Gu
   Huawei
   No.101 Software Avenue
   Nanjing, Jiangsu Province  210012
   P.R.China

   Phone: +86-25-56622638
   Email: guyingjie@huawei.com


   Jinwei Xia
   Huawei
   Software No.101
   Nanjing, Yuhuatai District  210012
   China

   Phone: +86-025-86622310
   Email: xiajinwei@huawei.com


   Rui Santos Cruz
   IST/INESC-ID/INOV

   Phone: +351.939060939
   Email: rui.cruz@ieee.org













Gu, et al.                 Expires May 3, 2012                 [Page 30]


Internet-Draft                Peer Protocol                     Oct 2011


   Mario Serafim Nunes
   IST/INESC-ID/INOV
   Rua Alves Redol, n.9
   1000-029 LISBOA
   Portugal

   Phone: +351.213100256
   Email: mario.nunes@inov.pt


   David A. Bryan
   Polycom
   San Jose, CA, USA,
   USA

   Phone:
   Email: dbryan@ethernot.org


   Joao P. Taveira
   ID/INOV

   Email: joao.silva@inov.pt




























Gu, et al.                 Expires May 3, 2012                 [Page 31]


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