CDNI Working Group T. Lin Internet Draft Y. Li Intended status: Informational Y. Zhang Expires: February 2016 S. Ren IIE, CAS August 17, 2015 A collaborative framework for in-network caching in mobile networks draft-lin-cdni-mobile-caching-framework-00 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), 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 February 17, 2016. Copyright Notice Copyright (c) 2015 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 T. Lin et al., Expires February 17, 2016 [Page 1] Internet-Draft A collaborative framework for in-network caching in mobile networks August 2015 Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document presents a framework for in-network caching in LTE mobile networks. The purpose of the framework is to provide an overall picture of the problem space of in-network caching and to describe the relationships among the various components of mobile networks and the newly added entities, such as content nodes and content controller. The framework requires the specification of interfaces and mechanisms to address issues such as content placement, request routing and content catalog maintenance. The intent of this document is to outline what each interface needs to accomplish and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. Table of Contents 1. Introduction and Scope .................................2 1.1. Terminology........................................3 2. Framework overview .....................................3 3. Content retrieval operation flow .......................7 4. Interface introduction ................................10 5. Example of collaborative caching ......................12 5.1. Distributed caching decision example..............12 5.2. Centralized caching decision example..............13 5.3. Collaborative caching decision example............13 6. References ............................................15 1. Introduction and Scope The explosive growth of mobile video traffic brings a great pressure on LTE mobile networks. Rencent researches have shown deploying caches in 3G/LTE mobile networks can efficiently relieve this pressure by reducing duplicate content transmissions [1-3]. This document provides a collaborative caching framework for LTE mobile networks with caches deployed at the evolved packet core (EPC) and radio access network (RAN) to reduce the bandwidth cost of Internet access and improve the end-user experience in terms of delay and congestion. Specifically, this document describes the T. Lin et al., Expires February 17, 2016 [Page 2] Internet-Draft A collaborative framework for in-network caching in mobile networks August 2015 necessary content retrieval operation flows and interfaces in general terms and outlines how they fit together to form a complete system for collaborative in-network caching. This document makes use of three examples to illustrate the operation of various caching schemes, but these examples should be considered illustrative rather than prescriptive. It is worthy to be noted that deploying transparent caches in LTE mobile networks needs carefully design to adapt to the LTE protocols and specifications, in order not to affect the normal operation of mobile networks. Besides, once caches are deployed at mobile base stations, some important issues, such as mobility and billing, may become main concerns and needs to be well addressed. The above mentioned problems are out of the scope of this document and we leave the solution of these problems to other documents. 1.1. Terminology Edge content node: a storage node located at the eNodeB that caches the content according to the predefined caching mechanism. It can be embedded in the eNodeB or cascades to the eNodeB. Central content node: a storage node located at the Core network in the LTE (PDN-GW or SAE-GW) that caches the content according to the predefined caching mechanism. It can be embedded in the PDN-GW(or SAE-GW) or cascades to the PDN- GW(or SAE-GW). Content controller: a node in the LTE that connects the content nodes logically in order to collect the information from the content nodes and generate caching policy. It is usually located in LTE core network. 2. Framework overview Deploying content caching capability in mobile network provides a brilliant solution in alleviating the pressure of mobile traffic growth and improving user experience. However, caching management faces a huge challenge because of the large number of content nodes and the limitations of storage capacity, especially when considering the limited user number T. Lin et al., Expires February 17, 2016 [Page 3] Internet-Draft A collaborative framework for in-network caching in mobile networks August 2015 for each edge content node. In this case, collaborative caching is an effective method to improve the overall efficiency of mobile caching networks. This document provides a framework of collaborative caching in mobile networks, as illustrated in Figure 1. In addition to the existing network entities, such as Base Station and Mobile gateway, two kinds of logical entities, namely, content node and content controller, are defined in this figure. Content node is an entity with the capability of computation and storage to support transparent content caching. According to the deployment location, content node can be further classified into edge content node and central content node. Edge node is collocated with base station (i.e., eNodeB), while central content node is collocated with mobile gateway, such as the serving gateway (SGW) and the packet data gateway (PGW). Note that content node can be a physical entity cascade to base station or mobile gateway, as shown in figure 1, or it can be embedded with base station or mobile gateway. Content controller is a control plane node, communicateing with all the content nodes. It periodically collects information from each content node. The collected information should include, but is not limited to, content items, user request records, and available uplink bandwidth. The above mentioned information can be collected through the outband interface between content nodes and the controller, i.e., the IP/MPLS interface implemented in the commercial mobile caching system [4]. Based on the collected information, the macro-scale global knowledge of content popularity distribution can be inferred by the content controller. With the global popularity distribution, the content controller can, but not necessarily must, periodically run the content placement algorithm to decide in which content node a content item should be stored. Meanwhile, since the content controller also keeps track of the available serving capacity as well as the content catalog at each content node, it can execute the request routing as a content catalog server to decide which content node a content request should be forwarded to. T. Lin et al., Expires February 17, 2016 [Page 4] Internet-Draft A collaborative framework for in-network caching in mobile networks August 2015 According to different caching policy, the decision of content placement can be divided into three manners, namely, distributed, centralized and cooperative, which will be detailed in Section 5. In the case of distributed caching policy, content placement is decided locally by content nodes themselves. However, with centralized and cooperative caching policy, content controller enforces the decision of content placement. Due to the centralized feature of this collaborative caching scheme, the issue of scalability should be of concern. To this end, the content controller, as a logical entity, can be easily scaled by being deployed on a cloud platform. T. Lin et al., Expires February 17, 2016 [Page 5] Internet-Draft A collaborative framework for in-network caching in mobile networks August 2015 ------------------------------------------------ / +--- + +--- + +--- + \ / |CP1 | |CP2 | |CP3 | \ \ +--- + +--- + +--- + / \ INTERNET / ------------------------------------------------ -------------------------- ||------------------------------ || -------- / Central \ |================= | Content |========================| || \ Node / ************* || || // ----*--- * || || // * * || || // +-----*--- + ----*------ || || || | Mobile | / Content \ || || || | Gateway | | Controller | || || || +-----*--- + \ / || || || * ----------- || || ********************************************* || || * || * * || || * || * * || -||--*-- || ----*--- ---*---|| / Edge \ || / Edge \ / Edge \ | Content | \====| Content | ...... | Content | \ Node / \ Node / \ Node / ---*---- ---*---- ---*---- * * * * * * +---*----- + +----*---- + +-----*--- + | Base | | Base | | Base | | Station | | Station | ...... | Station | +--------- + +--------- + +--------- + * ------------------------- *---------------------------- * +--------+ +--------+ +--------+ |Terminal| |Terminal| |Terminal| +--------+ +--------+ +--------+ ***** LTE link ===== Outband link Figure 1 Logical framework of collaborative caching in mobile networks T. Lin et al., Expires February 17, 2016 [Page 6] Internet-Draft A collaborative framework for in-network caching in mobile networks August 2015 3. Content retrieval operation flow 3.1. Case 1: the content controller and the central content node are not co-located in the same entity. As illustrated in Figure 2, the content retrieval operation flow is based on the following steps: When receiving a content request from a mobile client, edge content node A checks whether the requested content exists in its local cache (step 1 in Figure 2). If hit, edge content node A delivers the content directly to the client (step 7); Otherwise, edge content node A inquires the content controller for the missing request (step 2). If the requested content is found in the caching system within the mobile network, the content controller returns an 802 redirect message in which the IP address of target content node is included (step 3). Then edge content node A retrieves the requested content from target content node B (step 4.1 and 4.2). If the content is not found in the caching system, the content controller also returns an 802 redirect message in which the IP address of the central content node is included (step 3). Subsequently, edge content node deliver a http request message to the central content node (step 5.1) and finally the requested content is retrieved from the original server which is located somewhere outside the mobile network (step 6.1,6.2 and 5.2). Once edge content node A has retrieved the requested content, it delivers the content to the client (step 7). T. Lin et al., Expires February 17, 2016 [Page 7] Internet-Draft A collaborative framework for in-network caching in mobile networks August 2015 Client Edge Content Target Central Original Content Controller Content Content Server Node A Node B Node | | | | | | |1.http req.| | | | | |---------->| | | | | | |2.http req. | | | | | |----------> | | | | | |3.http 802 | | | | | |<-----------| | | | | | | | | | -| |4.1 http req. | | | / | |-------------------->| | | Found| |4.2 http rep. | | | \ | |<--------------------| | | -| | | | | | | |5.1 http req. | | | -| |------------------------------>| | | | | | | |6.1 http req.| Not | | | | |------------>| found| | | | |6.2 http rep.| | | | | | |<------------| \ | |5.2 http rep. | | | -| |<------------------------------| | |7.http rep.| | | | | |<----------| | | | | | | | | | | Figure 2 Content retrieval flow for case 1 3.2. Case 2: the content controller and the central content node are co-located in the same entity. As illustrated in Figure 3, the content retrieval operation flow is based on the following steps: When receiving a content request from a mobile client, edge content node A checks whether the requested content exists in its local cache (step 1 in Figure 3). If hit, edge content node A delivers the content directly to the client (step 6); Otherwise, edge content node A inquires the content controller for the missing request (step 2). T. Lin et al., Expires February 17, 2016 [Page 8] Internet-Draft A collaborative framework for in-network caching in mobile networks August 2015 If the requested content is found in the central content node which is co-located with the content controller, the content controller directly satisfies the request through returning a http reply message (step 3.2). If the requested content is found in other edge content nodes, the content controller returns an 802 redirect message in which the IP address of target content node is included (step 3.1). Then edge content node A retrieves the requested content from target content node B (step 4.1 and 4.2). If the content is not found in the caching system, the content controller delivers an http request message to the original server which is located somewhere outside the mobile network (step 5.1) and finally retrieves the requested content from the original server(5.2 and 3.2). T. Lin et al., Expires February 17, 2016 [Page 9] Internet-Draft A collaborative framework for in-network caching in mobile networks August 2015 Client Edge Content Controller Target Original Content /Central Content Content Server Node A Node Node B | | | | | |1.http req.| | | | |---------->| | | | | |2.http req. | | | | |------------->| | | | | | | | -| |3.1http 802 | | | Found/ | |<-------------| | | but | |4.1http req. | | not | |------------------------------>| | central| |4.2http rep. | | node \ | |<------------------------------| | -| | | | | -| | |5.1http req. | | / | | |-------------------------->| Not | | | |5.2http rep. | | found | | |<--------------------------| \ | |3.2http rep. | | | -| |<-------------| | | |6.http rep.| | | | |<----------| | | | | | | | | Figure 3 Content retrieval flow for case 2 4. Interface definition Figure 4 illustrates the logical connections and interfaces between content nodes and the content controller. The outlined specifications of the interface functions are listed in the following parts. T. Lin et al., Expires February 17, 2016 [Page 10] Internet-Draft A collaborative framework for in-network caching in mobile networks August 2015 +-----------------------------------------------------+ | | | --------------- + ---------- + | | / Central \ | Content | | | | Content * * * * * * * * * Controller | | | \ Node / + -*--*---*- + | | --------------- * * * | | * * * * * * * * * * * * * * * * * * * | | * * * | | * * * * * * * * * * * * * | | * * * | | * * * | | ---*----- ---*----- -----*--- | | / Edge \ / Edge \ / Edge \ | | | Content | | Content | ...... | Content | | | \ Node / \ Node / \ Node / | | --------- --------- --------- | | | | | | | | ***** INTERFACE | | | | | | | +-----------------------------------------------------+ Figure 4 Control plane The interface between content nodes and content controller can be categorized in two kinds: node management interface and content management interface. The specific functions of the interface are as below: Node management interface, including: a) Node join notification. Whenever a content node joins the system, the controller is notified via the interface. b) Node quit notification. Whenever a content node quits from the system, the controller is notified via the interface. c) Node status report. Node status includes link load condition, uplink bandwidth, download bandwidth, etc. T. Lin et al., Expires February 17,2016 [Page 11] Internet-Draft A collaborative framework for in-network caching in mobile networks August 2015 Each content node periodically reports the above status information to the content controller via the interface. The message of node status report can also be used for the purpose of keep alive between content node and content controller. Content management interface, including: a) Caching information report. The caching information, such as local cache size, cached content items, and average hit ratio, can be reported to the content controller via the interface. b) Http request/reply. When a request cannot be satisfied at an edge content node, an Http request routing procedure is performed between the edge content node and content controller via the interface, as illustrated in Figure 2 and Figure 3. c) Content placement strategy notification. When a new content placement strategy is generated or updated, the content controller notifies the strategy to content nodes via the interface. d) Content retrieval record report. Content nodes periodically report its content retrieval record to the content controller. Based on the collecting content retrieval record from each edge content node, the content controller can have the knowledge of a global content popularity which may be used to generate or update the next round content placement strategy. 5. Example of collaborative caching The collaborative framework for in-network caching in mobile edge networks could support different kinds of caching policies. Here three typical caching decision examples are provided. 5.1. Distributed caching decision example In this case, each cache makes its own caching decision independently. Every cache determines the content popularity T. Lin et al., Expires February 17, 2016 [Page 12] Internet-Draft A collaborative framework for in-network caching in mobile networks August 2015 according to its local historic content request statistic information, and then caches the most popular contents in its storage periodically. Meanwhile, the cache node reports its cached contents to the controller, in order to generate the whole content catalog. The contents being cached should be got actively through sending the request by the edge content node, or should be intercepted passively during the contents passed by. Such distributed caching decision mechanism could cause the caching redundancy since each edge content node cache the similar popular contents, leading to the lower cache utilization. 5.2. Centralized caching decision example In this case, the content controller, instead of the content nodes, makes the caching decision centrally. The content controller collects the content requests periodically to get the content popularity, and informs each edge content node what to cache. Thus, all the edge content nodes can cache the popular contents heterogeneously in a complementary way. Furthermore, the content controller keeps a catalog to record the storage location of the cached content, in order to redirect the request from one edge content node to the other edge content node(s). When received the caching decision from the content controller, the edge content node should actively get the content through sending the request, or should passively intercept during the contents passed by. Such centralized caching decision mechanism could cache the maximum contents in the RAN, therefore reduce the egress traffic and increase cache utilization, at a cost of an extra controlling overhead and longer download delay. 5.3. Collaborative caching decision example In this case, the cache size of the edge content node is divided into two independent parts, the non-coordinated local cache part and the coordinated shared cache part, as shown in Fig. 5. To simplify the analysis and without loss of T. Lin et al., Expires February 17, 2016 [Page 13] Internet-Draft A collaborative framework for in-network caching in mobile networks August 2015 generality, we assume that there are n edge content nodes which has the equal cache size c and the equal upstream link capacity. Each edge content node stores in its local cache (i.e., the c-x portion) the top ranked contents in a non- coordinated manner, and all edge content nodes collaboratively store n.x contents that are ranked from c-x+1 to c-x+nx. In order to manage the coordinated caching across the RAN, the content controller has to collect the information of content popularity and disseminate contents to the corresponding edge content nodes periodically. Hence, the content controller keeps the catalog recording the cached content location, in order to redirect the request from one edge content node to the other edge content node(s). -------------- / Central \ | Content | \ Node / -*---*--*--*-- * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ---*----- ---*----- --------- -*------- / Edge \ / Edge \ / Edge \ / Edge \ | Content | | Content | | Content | | Content | \ Node 1 / \ Node 2 / \ Node 3 / \ Node 4 / --------- --------- --------- --------- + ------- + ---- + | c-x | x | + ------- + ---- + local shared cache cache Figure 5 Collaborative caching decision example T. Lin et al., Expires February 17, 2016 [Page 14] Internet-Draft A collaborative framework for in-network caching in mobile networks August 2015 Such collaborative caching decision mechanism could increase cache utilization, and reduce download delay at the same time, at a cost of communication and controlling overhead. 6. References [1] J. Erman, A. Gerber, M.T. Hajiaghayi, D. Pei, S.Sen, O.Spatscheck, To Cache or Not to Cache - The 3G Case. IEEE Internet Computing, vol. 15, no. 2, Mar. 2011, pp. 27-34. [2] S. Woo, E. Jeong, S. Park, J. Lee, S. Ihm, and K. Park, "Comparison of caching strategies in modern cellular backhaul networks," inACM11th annual international conference on Mobile systems, applications,and services, 2013, pp. 319-332. [3] B. A. Ramanan, L. M. Drabeck, M. Haner, N. Nithi, T. E. Klein, and C. Sawkar, "Cacheability analysis of HTTP traffic in an operational LTEnetwork," in IEEE Wireless Telecommunications Symposium (WTS),2013, pp. 1-8. [4] Saguna, "Saguna networks enables mobile network operators to mon-etize their radio networks," http://www.saguna.net/site/assets/files/1/intel_saguna networks_whitepaper.pdf/ T. Lin et al., Expires February 17, 2016 [Page 15] Internet-Draft A collaborative framework for in-network caching in mobile networks August 2015 Authors' Addresses Tao Lin Institute of Information Engineering Chinese Academy of Sciences No.89, Minzhuang Road, Haidian District, Beijing 100093 P.R. China Email: lintao@iie.ac.cn Yang Li Institute of Information Engineering Chinese Academy of Sciences No.89, Minzhuang Road, Haidian District, Beijing 100093 P.R. China Email: liyang@iie.ac.cn Yan Zhang Institute of Information Engineering Chinese Academy of Sciences No.89, Minzhuang Road, Haidian District, Beijing 100093 P.R. China Email: zhangyan@iie.ac.cn Shoushou Ren Institute of Information Engineering Chinese Academy of Sciences No.89, Minzhuang Road, Haidian District, Beijing 100093 P.R. China Email: renshoushou@iie.ac.cn T. Lin et al., Expires February 17, 2016 [Page 16]