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

Versions: 00

P2PSIP Working Group                                               L. Li
Internet-Draft                                                   J. Wang
Intended status: BCP                                             J. Shen
Expires: September 2, 2010                                       Y. Meng
                                                         ZTE Corporation
                                                           March 1, 2010


      A P2P CDN based Content Sharing System using PPSP and RELOAD
                        draft-li-ppsp-p2p-cdn-00

Abstract

   This document defines a P2P CDN (Content Delivery Network) based
   content sharing system using PPSP (Peer to Peer Streaming Protocol)
   and RELOAD (REsource LOcation And Discovery).  The P2P CDN provides a
   unified platform for service/content providers and content sharing
   users to share content efficiently and safely.  The shared contents
   may include streaming media, files, etc.  This content sharing system
   uses PPSP as signaling protocol for P2P content distributing, and
   uses RELOAD to improve reliability and scalability.  More
   specifically, RELOAD is used to construct P2P overlays storing of
   massive contents and locating contents reliably.

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 2, 2010.

Copyright Notice



Li, et al.              Expires September 2, 2010               [Page 1]


Internet-Draft           Content Sharing System               March 2010


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  CDN Provider . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Content/Service Provider . . . . . . . . . . . . . . . . .  6
     3.3.  Content Sharing Client . . . . . . . . . . . . . . . . . .  6
   4.  Message Flows  . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Publishing/unpublishing Content Location in the
           Tracker Overlay  . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Storing Content in the Storage Overlay . . . . . . . . . .  7
     4.3.  CSC Downloading Content  . . . . . . . . . . . . . . . . .  8
     4.4.  Pushing Content to Cacher  . . . . . . . . . . . . . . . .  9
   5.  Deployment Options . . . . . . . . . . . . . . . . . . . . . . 11
   6.  Protocol Detail  . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
















Li, et al.              Expires September 2, 2010               [Page 2]


Internet-Draft           Content Sharing System               March 2010


1.  Introduction

   This document defines a P2P CDN (Content Delivery Network) based
   content sharing system using PPSP (Peer to Peer Streaming Protocol)
   [I-D.zhang-ppsp-problem-statement] and RELOAD (REsource LOcation And
   Discovery) [I-D.ietf-p2psip-base].  The content sharing system allows
   content/service providers to publish their shared contents such as
   streaming media, files, etc. to a peer-to-peer CDN.  The P2P CDN
   provides the services of tracking and distributing shared content
   with RELOAD and PPSP protocols.  The overlay tracks the shared
   contents' locations and distributes contents to the edge of network.
   At the edge of network, CSCs(Content Sharing Client) download
   contents from nearby CDN nodes and other CSCs.






































Li, et al.              Expires September 2, 2010               [Page 3]


Internet-Draft           Content Sharing System               March 2010


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   We use the terminology and definitions from "Concepts and Terminology
   for Peer to Peer SIP" [I-D.ietf-p2psip-concepts] and "Problem
   Statement of P2P Streaming Protocol"
   [I-D.zhang-ppsp-problem-statement] extensively in this document.
   RELOAD and PPSP both use the term "peer".  In this document, the term
   "peer" refers to PPSP peer if not specified.  Other terms used in
   this document are defined below.

   CSC (Content Sharing Client): The client that is running in a user
   device for downloading shared contents.  User devices includes mobile
   device, laptop, PC etc.  A CSC is a PPSP peer.

   Chunk: A chunk is a piece of partitioned content.  A large content
   can be partitioned into multiple chunks based on size, time, etc.  A
   small content MAY only have one chunk.  Chunk is the unit for
   storing, advertising and locating content.  A node MAY store only
   some chunks of a content, and report only the chunks it has to
   tracker.  The unit of transferring content SHOULD be chunk or smaller
   piece.

   Content portal: a content portal is a server that provides CSCs the
   list of shared content and some information about each content.

   Content source: a content source is a server that publishes shared
   content to the content sharing system.  A content source is PPSP peer
   and MAY also be a RELOAD client.

   Storage overlay: a RELOAD overlay storing contents.  Storage overlay
   provides reliable massive storage service.

   Tracker overlay: a RELOAD overlay storing content locations.  Each
   node in the overlay is a PPSP tracker.

   Storer: the server in the storage overlay.  A storer is both a RELOAD
   peer and PPSP peer.

   Cacher: a cacher is a dedicated server that downloads and caches
   contents for nearby CSCs.  Cacher can optimze network traffic and
   reduce the latency of CSC downloading content.  Cacher is PPSP peer.






Li, et al.              Expires September 2, 2010               [Page 4]


Internet-Draft           Content Sharing System               March 2010


3.  Architecture

   Usually, there are three kinds of participators in a P2P CDN based
   content sharing system: content/service provider, CDN provider and
   user.  The content sharing system defined in this document is shown
   in Figure 1.  In the system, user nodes are CSCs, and the other nodes
   are servers provided by content/service provider and CDN provider.
   Usually, content/service provider provides two kinds of servers:
   content portal and content source, while the CDN provider provides
   tracker overlay, storage overlay and cachers.  This MAY varies in
   different scenarios.


                +------------+  +------------+
                | Content    |__| Content    +-----------------------------------------------+
+---------------| Portal     |  | Source     +-----------------------------------+           |
|               +------------+  +-----+------+                                   |           |
|                                     |                                          |           |
|                                     |                                          |           |
|                                     |                                          |           |
|                                     |                                          |           |
|                                     |                                          |           |
|                                     |                                          |           |
|             +-----------------------+--------+         +-----------------------+--------+  |
|             |Tracker overlay(RELOAD)|        |         |Storage overlay(RELOAD)|        |  |
|             |   +--------+      +---+----+   |         |   +--------+      +---+----+   |  |
|             |   |Tracker |------|Tracker |   |         |   | Storer |------| Storer |   |  |
|             |   +--------+      +--------+   |         |   +--------+      +--------+   |  |
|             |       |               |        |         |       |               |        |  |
|             |   +--------+      +--------+   |         |   +--------+      +--------+   |  |
|             |   |Tracker |------|Tracker |---+---------+---| Storer |------| Storer |   |  |
|             |   +------+-+      +-----+--+   |         |   +--+-----+      +--------+   |  |
|             +----------+--------------+------+         +------+-------------------------+  |
|                        |              |                       |                            |
|                        |              |                       |                            |
|                        |          +---+----+              +---+----+                       |
|                        |          | Cacher |--------------+ Cacher +-----------------------+
|                        |          +--------+              +----+---+
|                        |                                       |
|                        |                                       |
|                    +---+----+                              +---+----+
+--------------------+  CSC   |------------------------------+  CSC   |
                     +--------+                              +--------+


          Figure 1: Content Sharing System using PPSP and RELOAD





Li, et al.              Expires September 2, 2010               [Page 5]


Internet-Draft           Content Sharing System               March 2010


3.1.  CDN Provider

   The CDN provider provides cachers and two RELOAD overlays: tracker
   overlay and storage overlay.  The tracker overlay acts as distributed
   tracker providing the service of storing/fetching the content
   location efficiently and safely.  The storage overlay acts as storage
   cloud providing the services of storing massive content safely and
   reliably.  Cachers are deployed near CSCs, and cache the hot contents
   for CSCs.  With PPSP protocol, tracker overlay, storage overlay and
   cachers efficiently distribute content from content source to the
   edge of network near CSCs.

   Content and content location are stored in the unit of chunk.  A
   large content can be divided into multiple chunks based on size,
   time, etc.  Take a streaming media named gone_with_the_wind as an
   example, we can define a rule of slicing the streaming media by 1
   minute of time, and the naming rule can be file name plus 1 minute
   plus series number, then the chunks name can be
   gone_with_the_wind_1minute_1, gone_with_the_wind_1minute_2, etc.

3.2.  Content/Service Provider

   Content/service provider is the original owner of the shared content
   in the content sharing system.  Content/service provider provides
   content source and content portal.  It is assumed that the digital
   right management (DRM) issues are addressed appropriately.

   The content portal provides CSCs the list of the shared contents and
   information about each content.  The information of a shared content
   may include content name, content size, the rule for slicing the
   shared content, the rule for naming the content chunks, etc.
   Alternately, some information may be stored in the tracker overlay.

   The content source stores content in storage overlay and/or publishes
   content location in tracker overlay.  To publish content location in
   tracker overlay, the content source acts as PPSP peer.  To store
   content in the storage overlay, the content source acts as a RELOAD
   client.

3.3.  Content Sharing Client

   Content Sharing Client is the user node downloading and consuming the
   shared content.  A CSC MAY also uploading other CSCs contents it has
   downloaded.  CSC can query content portal for the list of shared
   contents and some content information.  CSC can query content
   location from tracker overlay, and report the content it has to
   tracker overlay.




Li, et al.              Expires September 2, 2010               [Page 6]


Internet-Draft           Content Sharing System               March 2010


4.  Message Flows

4.1.  Publishing/unpublishing Content Location in the Tracker Overlay

   The tracker overlay provides the function of tracking content
   location.  Content source, storer, cacher, CSC can report the
   contents they have/delete to the tracker overlay with PPSP tracker
   protocol.

   Content location is stored in the tracker overlay in the unit of
   chunk.  RELOAD protocol defines three data models: single value,
   array and dictionary.  [I-D.zong-ppsp-chunk-discovery] proposes to
   use dictionary to store chunk location.  Using dictionary model,
   locations of the same content's chunks share the same Resource-ID,
   which reduces the messages of storing/fetching chunk location.  This
   document follows [I-D.zong-ppsp-chunk-discovery] and adopts the
   dictionary model.  Each content has a unique Resource-ID, which may
   be generated by hashing content, hashing content name or other ways.
   Each chunk has a dictionary key, which can be the same as chunk name.


 content source/CSC/storer/cacher                      tracker overlay
                |                                             |
                |                                             |
                | report content availability/unavailability  |
                |-------------------------------------------->|
                |                                             |
                |                                  +----------+------------------+
                |                                  |Store/delete content location|
                |                                  +----------+------------------+
                |             report  answer                  |
                |<--------------------------------------------|
                |                                             |
                |                                             |


                   Figure 2: Publishing Content Location

4.2.  Storing Content in the Storage Overlay

   The storage overlay provides the function of long-term storing
   content in RELOAD's P2P algorithms such as DHT algorithms.  With this
   function, content source can store massive contents in the storage
   overlay reliably, which reduces the overhead of maintaining content
   sources.

   As shown in Figure 3, content source stores content in the storage
   overlay with the RELOAD Store method.  Content is stored in the unit



Li, et al.              Expires September 2, 2010               [Page 7]


Internet-Draft           Content Sharing System               March 2010


   of chunk.  The storage overlay stores multiple copies of each chunk.
   The storer responsible for storing chunk SHOULD report to the tracker
   overlay.  Then the tracker overlay stores chunk location.

   RELOAD protocol defines three data models: single value, array and
   dictionary.  This document proposes to use single value model to
   store chunk.  Single value model distributes a content's chunks over
   the RELOAD overlay, which results in better load distribution.  Each
   chunk has a unique Resource-ID, which may be generated by hashing
   chunk name or other ways.


Content Portal  Content Source          storage overlay             tracker overlay
     |                |                        |                           |
     |                |                        |                           |
     |                |                        |                           |
     |                |Store content chunk req |                           |
     |                |----------------------->|                           |
     |                |                        |                           |
     |                |                        |                           |
     |                |             +----------+---------+                 |
     |                |             | store content chunk|                 |
     |                |             +----------+---------+                 |
     |                |                        |                           |
     |                |                        |report content availability|
     |                |                        |-------------------------->|
     |                |    Store answer        |                           |
     |                |<-----------------------|                +----------+-----------+
     |                |                        |                |Store  chunk  location|
     |                |                        |                +----------+-----------+
     |Content Info    |                        |       report answer       |
     |<---------------|                        |<--------------------------|
     |                |                        |                           |


                         Figure 3: Storing Content

4.3.  CSC Downloading Content

   Figure 4 shows an example of a CSC downloading content.  The CSC
   first gets some content information from content portal.  With the
   information, the CSC can generate content chunk ID.  Some content
   information required for generating chunk ID can be stored in the
   tracker overlay alternatively.  In that case, the CSC SHALL use
   RELOAD Fetch method to fetch the content information from the
   overlay.  Then the CSC queries chunk location from the tracker
   overlay with PPSP tracker protocol.  After getting the chunk
   location, the CSC uses PPSP peer protocol to negotiate with content



Li, et al.              Expires September 2, 2010               [Page 8]


Internet-Draft           Content Sharing System               March 2010


   owner(s).  Finally it downloads content from content owner(s).


cacher/CSC/storer/content source             CSC      Content Portal     tracker overlay
               |                              |                |                |
               |                              |                |                |
               |                              |                |                |
               |                              |Content Info Req|                |
               |                              |--------------->|                |
               |                              |                |                |
               |                              |                |                |
               |                              |Content Info    |                |
               |                              |<---------------|                |
               |                              |                |                |
               |                              |                |                |
               |                              |   query peer list of a chunk    |
               |                              |-------------------------------->|
               |                              |                |                |
               |                              |                |    +-----------+----------+
               |                              |                |    | Fetch chunk location |
               |                              |                |    +-----------+----------+
               |                              |      Return chunk location      |
               |                              |<--------------------------------|
               |                              |                |                |
               |    negotiate for transfer    |                |                |
               |<---------------------------->|                |                |
               |                              |                |                |
               |       Transfer chunk         |                |                |
               |----------------------------->|                |                |
               |                              |                |                |


                     Figure 4: CSC Downloading Content

4.4.  Pushing Content to Cacher

   Figure 5 shows an example of pushing content to a cacher.  First a
   tracker instructs the cacher to download specified chunk from a list
   of content owners.  Then the cacher negotiates with content owners
   and downloads chunk.











Li, et al.              Expires September 2, 2010               [Page 9]


Internet-Draft           Content Sharing System               March 2010


 tracker overlay               cacher          content source/storage/cacher
        |                        |                           |
        |                        |                           |
        |download chunk instruct |                           |
        |----------------------->|                           |
        |                        |                           |
        |    instruct answer     |                           |
        |<-----------------------|                           |
        |                        |                           |
        |                        |  negotiate for transfer   |
        |                        |<------------------------->|
        |                        |    transfer chunk         |
        |                        |<--------------------------|
        |                        |                           |
        |                  +-----+-----+                     |
        |                  |cache chunk|                     |
        |                  +-----+-----+                     |
        |                        |                           |
        |                        |                           |
        |                        |                           |
        |                        |                           |


                         Figure 5: Pushing Content



























Li, et al.              Expires September 2, 2010              [Page 10]


Internet-Draft           Content Sharing System               March 2010


5.  Deployment Options

   The content sharing system architecture shown in Figure 1 MAY varies
   in different scenarios.  In a very large network, the P2P CDN in a
   content sharing system MAY extend to multiple layers or multiple
   domains having multiple tracker overlays and storage overlays.  In a
   small network, a CDN node can be both a storer and cacher at the same
   time.  Also, as shown in Figure 6, one RELOAD overlay MAY performs as
   both a tracker overlay and storage overlay.


                +------------+  +------------+
                | Content    |__| Content    +-----------------------------------------------+
+---------------| Portal     |  | Source     +-----------------------------------+           |
|               +------------+  +-----+------+                                   |           |
|                                     |                                          |           |
|                                     |                                          |           |
|                                     |                                          |           |
|             +-----------------------+------------------------------------------+--------+  |
|             |                       |   Tracker/Storage overlay(RELOAD)        |        |  |
|             |    +-----------------------+                 +-----------------------+    |  |
|             |    |    Tracker/Storer     |-----------------|    Tracker/Storer     |    |  |
|             |    +-----------------------+                 +-----------------------+    |  |
|             |       |               |                          |               |        |  |
|             |    +-----------------------+                 +-----------------------+    |  |
|             |    |    Tracker/Storer     |-----------------|    Tracker/Storer     |    |  |
|             |    +-----------------------+                 +-----------------------+    |  |
|             +----------+--------------+-----------------------+-------------------------+  |
|                        |              |                       |                            |
|                        |              |                       |                            |
|                        |          +---+----+              +---+----+                       |
|                        |          | Cacher |--------------+ Cacher +-----------------------+
|                        |          +--------+              +----+---+
|                        |                                       |
|                        |                                       |
|                    +---+----+                              +---+----+
+--------------------+  CSC   |------------------------------+  CSC   |
                     +--------+                              +--------+


                 Figure 6: One RELOAD Overlay Architecture










Li, et al.              Expires September 2, 2010              [Page 11]


Internet-Draft           Content Sharing System               March 2010


6.  Protocol Detail

   This section describes the protocol detail of the content sharing
   system including content slicing rules, chunk naming rules, RELOAD
   data model, etc.

   Todo: Need detail analysis.












































Li, et al.              Expires September 2, 2010              [Page 12]


Internet-Draft           Content Sharing System               March 2010


7.  Security Considerations

   Todo: The content of this section need further input.
















































Li, et al.              Expires September 2, 2010              [Page 13]


Internet-Draft           Content Sharing System               March 2010


8.  IANA Considerations

   Some new data Kind-ID may be needed to be defined in RELOAD protocol
   for storing chunk and chunk location.

   Todo: Need complete this section further.













































Li, et al.              Expires September 2, 2010              [Page 14]


Internet-Draft           Content Sharing System               March 2010


9.  Acknowledgments

   This draft is based on the works of PPSP and P2PSIP workgroup.  The
   authors would like to thank the people of these two workgroups for
   what we learned from the drafts and maillists.














































Li, et al.              Expires September 2, 2010              [Page 15]


Internet-Draft           Content Sharing System               March 2010


10.  Normative References

   [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-06 (work in
              progress), November 2009.

   [I-D.ietf-p2psip-concepts]
              Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
              Dawkins, "Concepts and Terminology for Peer to Peer SIP",
              draft-ietf-p2psip-concepts-02 (work in progress),
              July 2008.

   [I-D.zhang-ppsp-problem-statement]
              Zhang, Y., Zong, N., Camarillo, G., Seng, J., and R. Yang,
              "Concepts and Terminology for Peer to Peer SIP",
              draft-zhang-ppsp-problem-statement-05 (work in progress),
              October 2009.

   [I-D.zong-ppsp-chunk-discovery]
              Zong, N., "Chunk Discovery for P2P Streaming",
              draft-zong-ppsp-chunk-discovery-00 (work in progress),
              June 2009.

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
























Li, et al.              Expires September 2, 2010              [Page 16]


Internet-Draft           Content Sharing System               March 2010


Authors' Addresses

   Lichun Li
   ZTE Corporation
   4F,RD Building 2,Zijinghua Road No.68
   Yuhuatai District,Nanjing 210012
   P.R.China

   Phone: +86-025-5287-7648
   Email: li.lichun1@zte.com.cn


   Jun Wang
   ZTE Corporation
   4F,RD Building 2,Zijinghua Road No.68
   Yuhuatai District,Nanjing 210012
   P.R.China

   Phone: +86-025-5287-7648
   Email: wang.jun17@zte.com.cn


   Jiong Shen
   ZTE Corporation
   4F,RD Building 2,Zijinghua Road No.68
   Yuhuatai District,Nanjing 210012
   P.R.China

   Phone: +86-025-5287-7648
   Email: shen.jiong@zte.com.cn


   Yu Meng
   ZTE Corporation
   C1-04,RD Building 1,Zijinghua Road No.68
   Yuhuatai District,Nanjing 210012
   P.R.China

   Phone: +86-025-5287-2045
   Email: meng.yu@zte.com.cn











Li, et al.              Expires September 2, 2010              [Page 17]


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