PPSP Working Group Y. Zhang Internet-Draft China Mobile Intended status: Standards Track L. Gui Expires: January 2, 2012 Beijing University of Posts and Telecommunications J. Peng China Mobile C.Schmidt L.Xiao Nokia Siemens Networks July 1, 2011 eICP: Extended Internet Cache Protocol to support today's content-based cache exchange draft-zhang-ppsp-eicp-00 Abstract This draft proposes three ways to extend the existing ICP protocol in order to support today's content-based Internet environment. Since the newly created PPSP protocol is especially designed for today's network condition, we will take its advantages here. The three proposals are: (1) Embedding PPSP in ICP; (2) PPSP and ICP Co-existing in caches communication; (3) Using PPSP to replace ICP. 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 January 2, 2012. Copyright Notice Copyright (c) 2011 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 Zhang, et al. Expires January 2, 2012 [Page 1] Internet-Draft eICP July 2011 (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. Conventions used in this document . . . . . . . . . . . . . . 4 2.1. Notational conventions . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. Three ways to extend the original ICP protocol . . . . . . . . 5 3.1. Embedding PPSP in ICP protocol . . . . . . . . . . . . . . 5 3.2. PPSP and ICP Co-existing in caches communication . . . . . 7 3.3. Using PPSP to replace ICP . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Zhang, et al. Expires January 2, 2012 [Page 2] Internet-Draft eICP July 2011 1. Introduction The existing ICP (Internet Cache Protocol) protocol is a lightweight message format used between neighbor Web Caches to communicate with each other. ICP is used to exchange hints about the URLs in neighbor caches in order to select the most appropriate location to retrieve object. [RFC2186] However, nowadays, as the Peer-to-Peer communication becomes popular and we prefer content to document since content's usually easier to transport and share as it can be segmented in to smaller chunks.[ draft-ietf-ppsp-problem-statement-01] The ICP protocol may become unsuitable since it just locates the object by its URL. In today's network, caches often cache chunks, which are the pieces of the desired complete content.[ draft-ietf-ppsp-problem-statement-01] This makes data transmission faster with better user experience. In such cases URL may be not applicable to locate these chunks (even were this the case, it may be too heavyweight and what worse, same chunks with different URLs cannot be easily identified and shared). Therefore the ICP protocol loses its prowess to some extent. Fortunately, the newly proposed PPSP (P2P Streaming Protocol) protocol can locate the cached chunks, by their Chunk IDs, and PPSP Peer protocol can be used by caches to communication among them to exchange chunk information as below [draft-gu-ppsp-peer-protocol-02]: 1. Bitmap indicating which chunks a peer possesses (for the offline case) or swarms they are participating in (for the live streaming case); 2. Required chunk IDs or requested streams; 3. Peer preference indicating what kind of candidate peers a requesting peer may prefer; 4. Information that can help to improve the performance of PPSP. Recently, caches have being tried to change their topology and communication paradigm to better deal with large-size chunks(e.g., Video and file)[reference, Akamai, Limelight]. In this sense caches can be treated as peers as well, and we can introduce PPSP protocol here to complement the ICP protocol since it may be more suitable for today's data storing. Zhang, et al. Expires January 2, 2012 [Page 3] Internet-Draft eICP July 2011 2. Conventions used in this document 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 RFC-2119 [RFC2119]. 2.2. Terminology The draft uses the terms defined in [I-D.ietf-ppsp-problem-statement] and [draft-gu-ppsp-tracker-protocol]. Zhang, et al. Expires January 2, 2012 [Page 4] Internet-Draft eICP July 2011 3. Three ways to extend the original ICP protocol Here we propose three possible ways to update the original ICP protocol to make it adapt to the new mode of data transmission and storage. 3.1. Embedding PPSP in ICP protocol Here we just propose one possible way to embed PPSP in ICP. We may use an identifier to indicate if the protocol is an original ICP protocol or a new one with PPSP embedded in. According to [RFC2186], the values of Opcode in ICP are in the interval [0,23] and both 5~9 and 12~20 are unused. So we may use just one bit of the 8-bit Opcode for identification. For example, when this 1-bit identifier sets to zero, we may think that this message is an ICP message, and when it sets to one, then it is a PPSP message. The extended format of ICP protocol is as below: +-----------------------------------------------------------------+ | 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 | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| ||I| Opcode | Version | Message Length || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Request Number || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Options || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Option Data || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || Sender Host Address || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| || || || || |\ Payload \| |\ \| || || || || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | | +-----------------------------------------------------------------+ Zhang, et al. Expires January 2, 2012 [Page 5] Internet-Draft eICP July 2011 Figure 1 Further we can extend the Opcode by using the unused values to express the PPSP information: +-------+-----------------------+ | Value | Name | +-------+-----------------------+ | 5 | FIND | | | | | 6 | CHUN_AVAILABILITY | | | | | 7 | PROPERTY_QUERY | | | | | 8 | TRANSPORT_NEGOTIATION | | | | | 12 | SUCCESSFUL(OK) | | | | | 13 | INVALID_SYNTAX | | | | | 14 | VERSION_NOT_SUPPORTED | | | | | 15 | MESSAGE_NOT_SUPPORTED | | | | | 16 | MESSAGE_FORBIDDEN | +-------+-----------------------+ Table 1 When the 1-bit identifier sets to one, then the values above will be activated and the cache receiving ICP message turns to interpret a PPSP message. The messages above are used the definitions in [draft-gu-ppsp-peer-protocol-02]. Note: Whether we can reuse part of Opcode of the original ICP protocol to achieve the PPSP functionality will be discussed in updated version of this draft. Accordingly, when we use the PPSP message, the specific response message should carry Chunk IDs in its body instead of URLs in the ICP format. If the protocol between neighbor caches is ICP protocol, it means the transmitting data between neighbor caches should be document, otherwise should be chunks. Zhang, et al. Expires January 2, 2012 [Page 6] Internet-Draft eICP July 2011 3.2. PPSP and ICP Co-existing in caches communication In this design, if cache nodes cache the document, then when others want this document's information, caches will use ICP protocol to communicate, if caches cache chunks instead, then caches will communicate using PPSP protocol. However, caches may need a functional entity, namely a Data Type Prober, to identify the form of the data (document/chunk). Here we give a paragraph to illustrate this scenario: +------------------------------------------------------+ | | |++++++++++++++++++ ++++++++++++++++++ | || | | | | || Cache 1 | | Cache 2 | | || ---------- | | ---------- | | || | Data Type|| || Data Type| | | || | Prober |--------ICP-------| Prober | | | || | |-------PPSP-------| | | | || ---------- | | ---------- | | || | | | | |++++++++++++++++++ ++++++++++++++++++ | +------------------------------------------------------+ Figure 2 As figure 2 shows, in this scenario, each cache needs to inform the Data Type Prober the data it caches, and by using some mechanism, the Data Type Prober will know if the data type is document or chunk. When communication occurs, the Data Type Prober will decide the message type according to the type of cached data. Note: Since there are two formats of protocol between caches, this condition may bring in some terrible consequences such as confusion and ambiguity. 3.3. Using PPSP to replace ICP In this means, we just use PPSP protocol to make caches exchange their information. However, we may need to extend the existing PPSP protocol since it does not support locating data by URLs right now. This scenario is familiar with scenario in section 3.1, the only difference is that we are trying to update the existing PPSP protocol Zhang, et al. Expires January 2, 2012 [Page 7] Internet-Draft eICP July 2011 instead. Here we need to introduce a new member? to PPSP message field. We call it "TYPE" here to indicate the type of cached data. Then we extend the existing PPSP protocol by adding ICP Opcodes in its method field. When TYPE indicates that the cached data would be a document, these Opcodes will be activated, otherwise it is just a normal PPSP protocol. According to [RFC2186], the Opcodes are: ICP_OP_INVALID; ICP_OP_QUERY; ICP_OP_HIT; ICP_OP_MISS; ICP_OP_ERR; ICP_OP_SECHO; ICP_OP_DECHO; ICP_OP_MISS_NOFETCH; ICP_OP_DENIED; ICP_OP_HIT_OBJ; and their definitions and corresponding operations will be in accordance with [RFC2186]. However, is the PPSP message should also be called ICP? It's a further discussion we will make in the future. Note: Whether we can reuse some operations already defined in PPSP protocol method field to achieve the ICP functionality will be discussed in updated version of this draft. Zhang, et al. Expires January 2, 2012 [Page 8] Internet-Draft eICP July 2011 4. Security Considerations The security considerations of ICP protocol and PPSP protocol are in accordance with descriptions in [RFC2187] and [draft-gu-ppsp-peer-protocol-02]. However, in this memo, we should consider if the extension of ICP protocol or PPSP protocol would bring in redundancy in encoding as section 3.1 and 3.3 mentioned. Besides, we should consider the scenario that both ICP and PPSP exist as section 3.2 mentioned, since this proposal may introduce confusion and ambiguity. Zhang, et al. Expires January 2, 2012 [Page 9] Internet-Draft eICP July 2011 5. IANA Considerations There are no IANA considerations associated to this memo. Zhang, et al. Expires January 2, 2012 [Page 10] Internet-Draft eICP July 2011 6. Conclusions Here we introduce three ways to extend the existing ICP protocol in order to adapt to today's content-based network condition. We can extend ICP protocol by: 1. Setting a 1-bit identifier and adding new definitions in its Opcode field; 2. Using both ICP and PPSP in caches communication, and a functional entity called Data Type Prober will help to determine which protocol should be used; 3. Adding a newly defined message in method field which called "TYPE" to indicate the type of this protocol, we may also add ICP Opcode operations in PPSP method field, too. Zhang, et al. Expires January 2, 2012 [Page 11] Internet-Draft eICP July 2011 7. References 7.1. Normative References [RFC2187] Wessels, D. and K. Claffy, "Application of Internet Cache Protocol (ICP), version 2", RFC 2187, September 1997. [RFC2186] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP), version 2", RFC 2186, September 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [draft-gu-ppsp-peer-protocol-02] Gu, Y. and D. Bryan, "Peer Protocol". [I-D.ietf-ppsp-problem-statement] Zhany, Y., Zong, N., Camarillo, G., Seng, J., and R. Yang, "Problem Statement of P2P Streaming Protocol (PPSP)". [draft-gu-ppsp-tracker-protocol] Gu, Y., Bryan, D., and L. Deng, "PPSP Tracker Protocol". 7.2. Informative References Zhang, et al. Expires January 2, 2012 [Page 12] Internet-Draft eICP July 2011 Authors' Addresses Yunfei Zhang China Mobile Unit 2, 28 Xuanwumenxi Ave, Xuanwu District Beijing 100053 P.R.China Email: zhangyunfei@chinamobile.com Liwen Gui Beijing University of Posts and Telecommunications 10 Xitucheng Ave, Haidian District Beijing 100876 P.R.China Email: guiliwen@139.com Jin Peng China Mobile Unit 2, 28 Xuanwumenxi Ave, Xuanwu District Beijing 100053 P.R.China Email: pengjin@chinamobile.com Christian Schmidt Nokia Siemens Networks Munich,Germany Email:christian.1.schmidt@nsn.com Lin Xiao Nokia Siemens Networks No.14 Jiuxianqiao Road Beijing, 100016 P.R.China Phone: +86-13810361287 Email: lin.xiao@nsn.com Zhang, et al. Expires January 2, 2012 [Page 13]