Internet DRAFT - draft-xiao-ppsp-reload-distributed-tracker

draft-xiao-ppsp-reload-distributed-tracker



PPSP                                                           L.Xiao
Internet Draft                                  Nokia Siemens Networks
Intended status: Informational                                D.Bryan
Expires: April 26, 2012                        Cogent Force, LLC/Huawei
                                                                  Y.Gu
                                                                Huawei
                                                                 X.Tai
                                                     China Mobile/BUPT
                                                       October 25, 2011


                      A PPSP Tracker Usage for Reload
               draft-xiao-ppsp-reload-distributed-tracker-03


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 April 26, 2012.

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 Simplified BSD License.




Xiao                   Expires April 26,2012                 [Page 1]

Internet-Draft      A PPSP Tracker Usage for Reload       October 2011


   This document may not be modified, and derivative works of it may not
   be created, and it may not be published except as an Internet-Draft.

Abstract

This document defines PPSP tracker usages for REsource LOcation And
Discovery (RELOAD). Although PPSP assumes a centralized tracker from
peer's point of view, the logical centralized tracker could be realized
by a cluster of geographically distributed trackers. In this draft, we
design distributed trackers system, which are organized by RELOAD. It
provides lookup service for file/channel indexes and Peer Status among
the distributed trackers.

Table of Contents


   1. Introduction ................................................ 2
   2. Terminology and Conventions.................................. 4
   3. Content Information Registration and Update.................. 5
      3.1. Data structure of ContentRegistration................... 5
      3.2. Message flows .......................................... 7
   4. Lookup Content Index (a Swarm)............................... 8
   5. Peer Status Registration, Update and Lookup.................. 9
      5.1. Data Structure of PeerStatusIndex...................... 10
   6. Kind Definition ............................................ 10
      6.1. CONTENT-REGISTRATION Kind Definition................... 10
      6.2. PEER-STATUS Kind Definition............................ 10
   7. Security Considerations..................................... 11
   8. IANA Considerations ........................................ 11
   9. Acknowledgments ............................................ 11
      9.1. Normative References................................... 12
      9.2. Informative References................................. 12
   Author's Addresses ............................................ 13

1. Introduction

   PPSP assumes that a centralized 'tracker' is used to communicate with
   the PPSP Peers for content registration and location.  The content
   index is stored in the tracker with location information that which
   peers have the content.

   However, the logically centralized 'tracker' could be also realized
   by a cluster of geographically distributed trackers or deployed in
   multiple servers in a data center, which can increase the content
   availability, the service robustness and the network scalability or
   reliability. The management and locating of index information are
   totally internal behaviors of the tracker cluster, which is invisible


Xiao                   Expires April 21, 2012                 [Page 2]

Internet-Draft      A PPSP Tracker Usage for Reload       October 2011


   to PPSP Peers. The signaling between PPSP Peers and trackers is still
   the simple request/reply mechanism defined in PPSP tracker protocols.
   Therefore, the Tracker Nodes themselves construct and maintain a P2P
   overlay as shown in Figure 1. This document is to define the
   behaviors of the tracker overlay as a usage for RELOAD. Because all
   protocols this draft applies to - the PPSP tracker protocol, PPSP
   peer protocol and RELOAD - are still changing, this draft will
   certainly change in the future, and is very much a work in progress.
   The authors encourage list discussion of the draft and any
   suggestions are welcome.

                           Tracker1  Tracker6
                              --        --
                          ---|  |------|  |---
                         |    --        --    |
                         |                    |
                         --                   --
               Tracker2 |  | Tracker Overlay |  | Tracker5
                         --                   --
                         |                    |
                         |    --        --    |
                          ---|  |------|  |---
                    Tracker3  --        --   Tracker4
                             / \         \
                            /   \         \
                           /     \         \
                         -----   -----   -----
                        |Peer1| |Peer2| |Peer3|
                         -----   -----   -----
          Figure 1  PPSP Peers connect with Tracker Overlay by Tracker
                                   Protocol

   The document tries to handle the data maintenance for two kinds of
   information: content index and PPSP peer status, among a cluster of
   distributed trackers. Four basic functions in tracker overlay are
   defined as follows:












Xiao                   Expires April 21, 2012                 [Page 3]

Internet-Draft      A PPSP Tracker Usage for Reload       October 2011


   o  Content/ channel index information registration: PPSP Peers
   registrar/update their contents/channels to a Connection Tracker.(How
   to find the initial tracker locally is out of scope.) This tracker
   takes the advantage of the RELOAD data storage functionality to store
   the index information to tracker nodes in the tracker overly
   accordingly. At the same time, the local Connection Tracker keeps a
   copy of local peer's content information for traffic localization.



   o  Look up a content/channel index: Once a PPSP Peer search for
   certain content/channel, it makes the request to a local Connection
   Tracker as defined in PPSP tracker protocol. If the swarm cannot be
   found or there is not enough peer records for such swarm in the
   Connection Tracker locally, the tracker will further locate the
   required index information in the tracker overlay on behalf of the
   requesting PPSP Peer. Once the full Peer List is fetched, the PPSP
   Peer will set up communications with the PPSP Peers in the Peer List
   as defined in PPSP Peer protocol;

   o  PPSP peer status registration: PPSP Peers registrar/update their
   status in the tracker overlay. All PPSP peers should firstly
   register their status to the local Connection Tracker. In order to
   enable this information being aware globally, the Connection Tracker
   should then store the position of the PPSP peer's status in the
   tracker overlay according to RELOAD scheme. The following peer
   status updates are only sent to the local Connection Tracker, the
   RELOAD based tracker overlay here only offers a way for remote nodes
   to find the location of requested peer status.

   o  Look up status of a certain peer: the tracker overlay can look up
   the status of a certain PPSP Peer. If the peer status cannot be
   found in the local Connection Tracker (that means it's not a local
   peer), the local tracker then searches the Status Position Tracker
   for the requested peer in the tracker overlay by RELOAD, which gives
   a route to access the status of the remote peer.

2. Terminology and Conventions

   This document makes extensive use of the terminology and definitions
   from the RELOAD Base Protocol [I-D.ietf-p2psip-base], PPSP
   Requirements and Problem Statements [I-D.ietf-ppsp-problem-
   statement][I-D.ietf-ppsp-reqs] and the Gu PPSP Tracker Protocol
   proposal [I-D.gu-ppsp-tracker-protocol].

   This document defines the following additional terminology:



Xiao                   Expires April 21, 2012                 [Page 4]

Internet-Draft      A PPSP Tracker Usage for Reload       October 2011


   PPSP Peer: The peer in PPSP protocol for content sharing and
   distribution among swarms.

   Tracker Node: The RELOAD Node with PPSP tracker usage. Each Tracker
   Node takes the responsibility to store and maintain certain
   content/channel index.

   Tracker Overlay:  A RELOAD overlay constructed by Tracker Nodes. This
   Overlay is logically separated with overlay formed by PPSP Peers.

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

   Swarm Tracker:  The Tracker Node who is responsible for the swarm in
   the overlay, and stores the content information (e.g. Peerlist) of
   the swarm.

   Status Position Tracker:  A Tracker Node which is responsible to
   store the Position of certain peers' status of a particular list of
   Peers.

3. Content Information Registration and Update

   To fulfill the functions of content information registration and
   update mentioned in Section 1, Tracker Node must maintain such
   resources related to peers;

   Content Registration: Information about the content which belongs to
   a specific swarm.  It can be stored in a data structure denoted as
   ContentRegistration, which primarily includes an identification of
   the swarm, a name of the content, and a Peer List.

3.1. Data structure of ContentRegistration


   Structure The data structure of ContentRegistration uses the RELOAD
   dictionary kind whereas the DictionaryKey value is the Swarm ID of
   the content required.  The data structure of type ContentRegistration
   is shown as follows:

      struct{

             Uint32 index;

             ChunkID chunk_id;



Xiao                   Expires April 21, 2012                 [Page 5]

Internet-Draft      A PPSP Tracker Usage for Reload       October 2011


      }ArrayChunkListData;



      struct{

             PeerID peer_id;

             ArrayChunkListData  chunklist_data;

      }PeerListData;



      struct{

             uint16 length;

             PeerListData peerlist_data;

      }PeerList;



      struct {

             uint16 length;

             opaque content_name<0..2^16-1>;

             PeerList peerlist <0..2^16-1>;

      } ContentRegistration;



   The content of the PeerList structure are as follows:

      length

           the length of the data structure

      content_name

           the name of the content

      peerlist


Xiao                   Expires April 21, 2012                 [Page 6]

Internet-Draft      A PPSP Tracker Usage for Reload       October 2011


           the content of Peer List



3.2. Message flows

   When a PPSP Peer wishes to share its contents to others, it will
   inform Tracker Overlay with the swarm information of the contents,
   then Swarm Tracker need to add this PPSP Peer into the corresponding
   Peer List to the swarm, or create a new swarm when there is no record
   of the swarm. A local record of the swarm may also be set up at the
   Connection tracker. Correspondingly, When a PPSP Peer deletes some
   old contents locally, it will inform Tracker Overlay that it would
   like to leave from a particular swarm, then both Connection Tracker
   and Swarm Tracker need to delete this PPSP Peer from the
   corresponding Peer List which is defined in the requirement of PPSP
   [I-D.ietf-ppsp-reqs].

   An example is given as the figure has shown below:

   1.  PPSP Peer wants to join into a swarm to share the content, first
   it will send a PPSP message "Join" with a Swarm-ID to TrackerA, which
   is a connection tracker of the Tracker Overlay for PPSP Peer connects
   to;

   2.  TrackerA first handles the registration locally, then finds the
   Swarm Tracker by mapping the swarm ID to node ID of the Swarm Tracker,
   to forward the request. So TrackerA sends a RELOAD message "StoreReq"
   to TrackerB who is the Swarm Tracker for the content swarm;

   3.  When Swarm Tracker (TrackerB) receives the request (or if
   TrackerA is responsible for the Peer List of the swarm,
   TrackerB=TrackerA), it searches locally the Peer List of the swarm
   whose ID is the Swarm-ID, then add the Node-ID of the PPSP Peer into
   the Peer List or delete it from that, and send the result of the
   operation (e.g. successful or failed) in a RELOAD message
   "StoreReqAns" to TrackerA through Tracker Overlay;

   4.  Finally, TrackerA analyses the received message, and responds to
   the requesting Peer by a corresponding PPSP message: "Successful
   (OK)" or some error messages.

   Note: When PPSP Peer is the first node of the swarm, which means it
   is the first one who stores this kind of content in the network,
   TrackerB doesn't have records of the new swarm, TrackerB will create
   a new ContentRegistration for the swarm locally, and put the
   identification of PPSP Peer into Peer List of this new


Xiao                   Expires April 21, 2012                 [Page 7]

Internet-Draft      A PPSP Tracker Usage for Reload       October 2011


   ContentRegistration, then send the result of the operation (e.g.
   successful or failed) in a RELOAD message "StoreReqAns" to TrackerA
   through Tracker Overlay.


                      (connection)       (overlay)       (swarm)
      PPSP Peer        TrackerA          TrackerX        TrackerB
      --------------------------------------------------------------
            --JOIN-> |keep a copy|

                                --StoreReq->

                                               --StoreReq->

                                              <-StoreReqAns--

                               <-StoreReqAns--

             <-SUCCESSFUL(OK) -

             Figure 2  Content Information Registration and Update

   If PPSP Peer wishes to update content information, for example, list
   of chunks it has, it sends a PPSP message "JOIN_CHUNK" to TrackerA.
   TrackerA makes update in its local table, and then sends the
   corresponding RELOAD message to TrackerB to update the detailed
   chunk-IDs in the Swarm according to the request message.



4. Lookup Content Index (a Swarm)

   When a PPSP Peer wants to use some streaming service, which means it
   wants to download some interested contents from the system, it
   firstly needs to get related Peer List from Tracker Overlay.  As the
   figure has shown below:

   1)  PPSP Peer wants to watch a video belonging to a swarm with a
   Swarm-ID, firstly it sends a PPSP message "Find" with the Swarm-ID to
   Connection TrackerA;

   2)  If TrackerA has enough local peer record for swarm, it can reply
   the request directly. Or it maps the Swarm-ID into a Node-ID to
   identify the Swarm Tracker, TrackerB, which stores the Peer List of
   the requested swarm. It then sends a RELOAD message "FetchReq" to
   TrackerB;



Xiao                   Expires April 21, 2012                 [Page 8]

Internet-Draft      A PPSP Tracker Usage for Reload       October 2011


   3)  When Swarm TrackerB receives the request (or if TrackerA is
   responsible for the Peer List of the swarm, TrackerbB=TrackerA), it
   searches the Peer List of the swarm locally, then send the Peer List
   which is organized by the data structure of PeerList in a RELOAD
   message "FetchReqAns" to TrackerA through Tracker Overlay;

   4)  Finally, TrackerA analyses the received PeerList structure, and
   reconstructs it into a PPSP message "Successful(OK)", then forwards
   it to the PPSP Peer.


                     (connection)        (overlay)       (swarm)
      PPSP Peer        TrackerA          TrackerX        TrackerB
      --------------------------------------------------------------
               --Find->

       <-SUCCESSFUL(OK) |or| --FetchReq->

                                              --FetchReq->

                                            <-FetchReqAns--

                           <-FetchReqAns--

           <-SUCCESSFUL(OK)-

                     Figure 3  Content Information Lookup

5. Peer Status Registration, Update and Lookup

   To fulfill the functions of peer status registration, update and
   lookup mentioned above, Tracker Node must maintain such resource
   related to peers:

   Information about status of peers: the local Connection Tracker takes
   the responsibility to maintain the PPSP Peer status locally,
   including online time, link status, node capability and other
   streaming parameters, etc.  It can be stored in a data structure
   denoted as PeerStatus.

   Position of PPSP peer status: each PPSP Peer can be mapped to a
   Status Position Tracker in the tracker overlay. The status Position
   Tracker takes responsibility to only record the route (i.e., the
   address of the local Connection Tracker of the Peer) to access the
   PPSP Peer status.




Xiao                   Expires April 21, 2012                 [Page 9]

Internet-Draft      A PPSP Tracker Usage for Reload       October 2011


5.1. Data Structure of PeerStatusIndex

   The data structure of PeerStatusIndex uses the RELOAD dictionary kind
   whereas the DictionaryKey value is the Peer ID.  The data structure
   of type PeerStatusIndex is shown as follows:



            struct{

                   TrackerID Connection_Tracker_ID;

            }PeerStatusIndex;

   The content of the PeerStatusIndex structure are as follows:

   trackerID the ID of the Peer's Connection Tracker;


6. Kind Definition


6.1. CONTENT-REGISTRATION Kind Definition

   This section defines the CONTENT-REGISTRATION kind.

   o  Name: CONTENT-REGISTRATION

   o  Kind IDs: The Resource Name for the CONTENT-REGISTRATION Kind-ID
   is Swarm Name. The data stored is a CONTENT-REGISTRATION, which
   contains a identification of the swarm, a name of the content, and a
   list of PPSP Peer-IDs with or not a list of chunk-IDs for each PPSP
   Peer to show which chunks the PPSP Peer has.

   o  Data Model: The data model for the CONTENT-REGISTRATION Kind-ID is
   dictionary.  The dictionary key is the Swarm-ID of the peer action as
   focus.

   o  Access Control: USER-NODE-MATCH.

6.2. PEER-STATUS Kind Definition

   This section defines the PEER-STATUS kind.

   o  Name: PEER-STATUS



Xiao                   Expires April 21, 2012                [Page 10]

Internet-Draft      A PPSP Tracker Usage for Reload       October 2011


   o  Kind IDs: The Resource Name for the PEER-STATUS Kind-ID is Peer
   Status. The data stored is a PEER-STATUS, which contains a
   identification of the peer and a identification of the peer's
   connection tracker.

   o  Data Model: The data model for the PEER-STATUS Kind-ID is
   dictionary.  The dictionary key is the Peer-ID.

   o  Access Control: USER-NODE-MATCH.

7. Security Considerations

   This document does not currently introduce security considerations.

8. IANA Considerations

   This document does not specify IANA considerations.

9. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.



























Xiao                   Expires April 21, 2012                [Page 11]

Internet-Draft      A PPSP Tracker Usage for Reload       October 2011


   References

9.1. Normative References

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

   [2]  [I-D.ietf-ppsp-reqs] Zong, N., Zhang, Y., Avila, V., Williams,
         C., and L. Xiao, "P2P Streaming Protocol (PPSP) Requirements",
         draft-ietf-ppsp-reqs-03 (work in progress), July 2011.

   [3]  [I-D.ietf-ppsp-problem-statement] Zhang, Y., Zong, N.,
         Camarillo, G., Seng, J., and Y. Yang, "Problem Statement of P2P
         Streaming Protocol (PPSP)", draft-ietf-ppsp-problem-statement-
         03 (work in progress), August 2011.

   [4]  [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E.,
         Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery
         (RELOAD) Base Protocol", draft-ietf-p2psip-base-18 (work in
         progress), August 2011.

   [5]  [I-D.gu-ppsp-tracker-protocol] Yingjie, G., Bryan, D., Zhang,
         Y., and H. liao, "Tracker Protocol", draft-gu-ppsp-tracker-
         protocol-04 (work in progress), May 2011.

9.2. Informative References






















Xiao                   Expires April 21, 2012                [Page 12]

Internet-Draft      A PPSP Tracker Usage for Reload       October 2011


Author's Addresses

   Lin Xiao
   Nokia Siemens Networks
   No.14 Jiuxianqiao Road
   Beijing,   100016
   P.R.China

   Phone: +86-13810361287
   Email: lin.xiao@nsn.com


   David A. Bryan
   Cogent Force, LLC / Huawei

   Email: dbryan@ethernot.org


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

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


   Xuan Tai
   China Mobile/BUPT

   Phone: +86-13581762082
   Email: taixuanyueshi@gmail.com















Xiao                   Expires April 21, 2012                [Page 13]