P2PSIP Working Group J. Wang Internet-Draft J. Shen Intended status: Standards Track Y. Meng Expires: December 31, 2009 ZTE Corpoporation June 29, 2009 Content Sharing Usage for RELOAD draft-shen-p2psip-content-sharing-00 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 December 31, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Wang, et al. Expires December 31, 2009 [Page 1] Internet-Draft Content Sharing Usage for RELOAD June 2009 Abstract This document defines a content sharing usage for REsource LOcation And Discovery (RELOAD). The content sharing usage provides the functionality of distributing and fetching shared content to and from a P2P overlay network. The shared content including such as streaming media, files etc. are provided by those shared content service providers. Using content sharing usage of RELOAD can construct a peer-to-peer overlay, the overlay performs as Content Delivery Network and is service insensitive. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Storing Content . . . . . . . . . . . . . . . . . . . . . . . 7 5. Fetching Content . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. CSC behavior . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. overlay peer behavior . . . . . . . . . . . . . . . . . . 10 6. Protocol Detail . . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Overlay Optimize Example . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative references . . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Wang, et al. Expires December 31, 2009 [Page 2] Internet-Draft Content Sharing Usage for RELOAD June 2009 1. Introduction The content sharing usage of RELOAD allows content providers to distribute their shared content such as streaming media, files etc. to a peer-to-peer overlay. In such a network, the RELOAD overlay itself performs the distributing and fetching functions ordinarily associated with such servers provided by service providers or carriers, the overlay performs as Content Delivery Network and is service insensitive. The purpose of this content sharing usage for RELOAD is providing a general and standard method to those content sharing service providers and CSC for distributing and fetching shared content efficiently and safely. The content sharing Usage involves two basic functions: Storing content: Content providers can use the RELOAD data storage functionality to store the shared content such as streaming media, files to a peer-to-peer overlay network efficiently and safely. Fetching content: Once an authorized CSC wants to get the shared content, it can use the RELOAD fetch functionality to get the shared content efficiently and safely. Wang, et al. Expires December 31, 2009 [Page 3] Internet-Draft Content Sharing Usage for RELOAD June 2009 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 the RELOAD Base Protocol [I-D.ietf-p2psip-base] extensively in this document. CSC: Content Sharing Client. The device that can fetch shared content, such as mobile device, laptop, PC etc. Resource responsible peer: The resource responsible peer is the peer responsible for a range of resource IDs. Wang, et al. Expires December 31, 2009 [Page 4] Internet-Draft Content Sharing Usage for RELOAD June 2009 3. Architecture The content sharing usage of RELOAD can construct a peer-to-peer overlay which can be used as distributed data storage system as CDN. By this overlay, user can get the shared content that they want efficiently and the overlay is service insensitive. Here, the traditional content distribution system has been divided into two main parts, the content/service provider and the overlay provider. +--------------------------------+ | Content/Service Provider | | | | +------------+ +------------+ | | | Content | | Content | | |---------------| Portal | | Server | | | | +------------+ +------------+ | | | | | | | +-------|---------------|--------+ | | | | | | | | | | | | | +-------|---------------|--------+ | | | | | | | +--------+ +--------+ | | | | Peer |------| Peer | | | | +--------+ +--------+ | | | | | | +--------+ | +--------+ +--------+ | | CSC |------------| Peer |------| Peer | | +--------+ | +--------+ +--------+ | | | | Overlay Provider | +--------------------------------+ Figure 1: Content Sharing Usage for RELOAD The major components of the content sharing usage of RELOAD are: Content/Service Provider: The owner of the shared content. It provides two basic functionalities, storing the shared content and providing content protal for CSC by which CSC can find the shared content. Wang, et al. Expires December 31, 2009 [Page 5] Internet-Draft Content Sharing Usage for RELOAD June 2009 The functionality of Storing the shared content SHALL use overlay network to store the shared content or MAY slice the shared content into segments and use overlay network to store the content segments. The functionality of providing content protal is publishing the content protal for the content that CSC can access. And it also SHALL provide CSC enough information for how to fetch the content, such as the overlay name for storing the content, the content name and also MAY the rule of slicing the content if the content has been stored in segments from which the CSC can generate the resource id(s) of the content and get the resource(s) from overlay. Overlay Provider: The owner of the overlay, it uses RELOAD to construct and run the overlay, provides the service of storing and fetching the content efficiently and safely. If the overlay is constructed and running by carriers, as they know the network infrastructure topology, some policy MAY be used to construct the content sharing overlay for optimizing data flow trafic. Such as construct domains in overlay, the data flow trafic in domain will not across over Backbone Networks. CSC: Content Sharing Client is used to get the shared conent, if the CSC wants to get a shared content, the CSC SHALL get the content information from the content portal first, by which the CSC can generate the content resource id, and this content information MAY also stored in the overlay, the resource ID of this content information MAY be hashed by URI. And then, the CSC can fetch the content from the overlay by resource id. Wang, et al. Expires December 31, 2009 [Page 6] Internet-Draft Content Sharing Usage for RELOAD June 2009 4. Storing Content In RELOAD, this storing function is provided by the overlay, the content provider SHALL use RELOAD data storage methods to store the content and keep the mapping of the content and resource ID if the resource ID is not associated with the content. If the content size is large such as streaming media, the content provider SHOULD slice the content to segments for easy storing and providing a method that CSC can retrieve this large content by segments in parallel or just fetching parts of the content, the rule for slicing the content MAY based on such as time, size etc. Resource Content Portal Content Server Access Peer Responsible Peer | | | | | | | | | | | | | |Store Content | | | |--------------->| | | | | | | | | | | | |Store Content | | | |--------------->| | | | | | | | | | | |Store answer | | | |<---------------| | | | | | | | | | |Store answer | | | |<---------------| | | | | | | | | | |Content Info | | | |<---------------| | | | | | | | | | | | | | | | | | | Figure 2: Storing content As a simple example, if a content sharing service provider wants to share such as a streaming media, the service provider firstly slices the media content into some segments by some rules such as time or Wang, et al. Expires December 31, 2009 [Page 7] Internet-Draft Content Sharing Usage for RELOAD June 2009 size, and then the service provider uses RELOAD Store method to store those media segments to the overlay. In structured P2P networks, resource IDs are generally fixed length and are generated by hashing the resource name, such as using DHT. Here the service provider SHALL use some rules for naming the content segments, then if same content segments have been stored in the overlay, by resource name, duplicate stores can be avoid. For example to slice a streaming media gone_with_the_wind, we can define a rule of slicing the streaming media by 1 minute, and the naming rule can be file name plus 1 minute plus series number, then the segments name can be gone_with_the_wind_1minute_1, gone_with_the_wind_1minute_2, etc. For the basic information of the shared content, such as content name, content size, the overlay name, the rule for slicing the shared content, the rule for naming the content segments etc. by which CSC can generate all resource IDs of the content is also can be stored in the overlay. Here, the key for the information storing can be a content ID which may be a hash value of the content's URI. Wang, et al. Expires December 31, 2009 [Page 8] Internet-Draft Content Sharing Usage for RELOAD June 2009 5. Fetching Content In RELOAD, this fetching functionality is provided by the overlay, the CSC that wants to get the shared content SHALL use RELOAD data storage methods to fetch the shared content. Resource CSC Content Portal Access Peer Responsible Peer | | | | | | | | | | | | |Content Info Req| | | |--------------->| | | | | | | | | | | |Content Info | | | |<---------------| | | | | | | | | | | |Fetch Req for one segment | | |-------------------------------->| | | | | | | | | | | | |Fetch Req | | | |--------------->| | | | | | | | | | | |Content | | | |<---------------| | | | | | | | | | Content of one segment | | |<--------------------------------| | | | | | | | | | | | | | Figure 3: Fetching content 5.1. CSC behavior The CSC SHALL get the basic information of the shared content first from the content sharing service provider, the basic information MAY including content name, content size, the overlay name for storing the content segments, the rule for slicing the shared content, the Wang, et al. Expires December 31, 2009 [Page 9] Internet-Draft Content Sharing Usage for RELOAD June 2009 rule for naming the content segments. As described in section 4, this information can be stored in the overlay, in this case, the CSC SHALL use RELOAD Fetch request to fetch the content information from the overlay. After getting the overlay name the content has been stored, the CSC SHALL check whether the overlay is an attached one, if not, it MUST initiate an overlay joining procedure. CSC MAY visit a topology server to priority a list of peers in the overlay, and choose a closer one to send fetch request. The CSC SHALL use the basic content information to generate the resource ID or resource IDs if the content has been sliced into segments, and then the CSC SHALL use RELOAD Fetch request to fetch the content by resource ID or resource IDs from the overlay. 5.2. overlay peer behavior When one CSC wants to fetch content by resource ID, the access peer in the overlay SHOULD check whether itself has the content of the resource ID, if not, the peer SHALL routing this request to next peer by routing arithmetic(such as searching DHT routing table by resource ID). If the peer takes responsibility for storing the content of the resource ID, it SHALL answer the request and send back the resource. If the overlay supports resource copies, the resource responsible peer SHALL return a list of Node IDs that those peers have the resource. The access peer SHALL choose one peer from the list by some policy such as limitation the data flow trafic, balance the load etc., communicate with the peer to fetch the resource and return the content to CSC. The access peer SHOULD determine whether it need store a copy of the content itself, if it stores the copy of the content, it SHALL communicate with the peer responsible for this resource ID to register this information, then the resource responsible peer MAY add the access peer in the list of storing this resource, in this case, if the access peer leaves the overlay, it MUST communicate with the responsible peer to dismantle the registration. Wang, et al. Expires December 31, 2009 [Page 10] Internet-Draft Content Sharing Usage for RELOAD June 2009 6. Protocol Detail This section describes the detail protocol of Content Sharing Usage for RELOAD, including content slicing and naming rules, registration procedure of copy content, extension of RELOAD for content sharing usage etc. Todo: Need detail analysis. Wang, et al. Expires December 31, 2009 [Page 11] Internet-Draft Content Sharing Usage for RELOAD June 2009 7. Security Considerations RELOAD provides a generic storage service, and also generic security service for any of the RELOAD usage. In this section we discuss security issues that are specific to content sharing usage for RELOAD. Todo: The content of this section need further input. Wang, et al. Expires December 31, 2009 [Page 12] Internet-Draft Content Sharing Usage for RELOAD June 2009 8. IANA Considerations Some new data Kind-ID may be needed for define specific data kind of content sharing usage of RELOAD. Todo: Need complete this section further. Wang, et al. Expires December 31, 2009 [Page 13] Internet-Draft Content Sharing Usage for RELOAD June 2009 9. Overlay Optimize Example As normally, the data flow trafic for content sharing usage is huge, if the overlay is constructed and running by carriers, as they know the network infrastructure topology, some methods can be used to construct the content sharing overlay for optimizing data flow trafic. Such as construct domains in overlay, the data flow in one domain will not across over backbone networks, that can limit the data flow across over backbone networks. The domains can be divided by Node ID ranges, and when one peer need fetch content, it can try to fetch the content from the peer in same domain first. +------------------------------+ +------------------------------+ | | | | | +--------+ +--------+ | | +--------+ +--------+ | | | Peer |------| Peer | | | | Peer |------| Peer | | | +--------+ +--------+ | | +--------+ +--------+ | | | | |---| | | | | +--------+ +--------+ | | +--------+ +--------+ | | | Peer |------| Peer | | | | Peer |------| Peer | | | +--------+ +--------+ | | +--------+ +--------+ | | | | | | domain 1 | | domain 2 | +------------------------------+ +------------------------------+ | | | | +------------------+ | | | | +------------------------------+ +------------------------------+ | | | | | +--------+ +--------+ | | +--------+ +--------+ | | | Peer |------| Peer | | | | Peer |------| Peer | | | +--------+ +--------+ | | +--------+ +--------+ | | | | | | | | | | +--------+ +--------+ |---| +--------+ +--------+ | | | Peer |------| Peer | | | | Peer |------| Peer | | | +--------+ +--------+ | | +--------+ +--------+ | | | | | | domain 3 | | domain 4 | +------------------------------+ +------------------------------+ Figure 4: Overlay optimize Example, Domain Wang, et al. Expires December 31, 2009 [Page 14] Internet-Draft Content Sharing Usage for RELOAD June 2009 10. Acknowledgments This draft is based on "REsource LOcation And Discovery (RELOAD) Base Protocol draft by C. Jennings, B. Lowekamp, E. Rescorla, S. Baset and H. Schulzrinne. The authors would also like to thank many people of the IETF P2PSIP WG that many drafts we have learned. Wang, et al. Expires December 31, 2009 [Page 15] Internet-Draft Content Sharing Usage for RELOAD June 2009 11. References 11.1. 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-02 (work in progress), March 2009. 11.2. Informative References [I-D.hardie-p2psip-p2p-pointers] Hardie, T. and V. Narayanan, "Pointers for Peer-to-Peer Overlay Networks, Nodes, or Resources", draft-hardie-p2psip-p2p-pointers-01 (work in progress), March 2008. [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. Wang, et al. Expires December 31, 2009 [Page 16] Internet-Draft Content Sharing Usage for RELOAD June 2009 Authors' Addresses Jun Wang ZTE Corpoporation 4F,RD Building 2,Zijinghua Road Yuhuatai District,Nanjing 210012 P.R.China Phone: +86-025-5287-7648 Email: wang.jun17@zte.com.cn Jiong Shen ZTE Corpoporation 4F,RD Building 2,Zijinghua Road Yuhuatai District,Nanjing 210012 P.R.China Phone: +86-025-5287-7648 Email: shen.jiong@zte.com.cn Yu Meng ZTE Corpoporation C1-04,RD Building 1,Zijinghua Road Yuhuatai District,Nanjing 210012 P.R.China Phone: +86-025-5287-2045 Email: meng.yu@zte.com.cn Wang, et al. Expires December 31, 2009 [Page 17]