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]