[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

ICN Research Group                                                 L. Li
Internet-Draft                                                     X. Xu
Intended status: Informational                                   J. Wang
Expires: April 23, 2013                                           Z. Hao
                                                         ZTE Corporation
                                                        October 20, 2012


                 Information-Centric Network in an ISP
                       draft-li-icnrg-icn-isp-01

Abstract

   Information-Centric Network (ICN) may be deployed over different
   underlying networks, e.g. ad hoc networks, DTN and ISP's networks.
   This document discusses deploying ICN in an ISP's existing networks
   and ICN design for ISPs.

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 April 23, 2013.

Copyright Notice

   Copyright (c) 2012 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.





Li, et al.               Expires April 23, 2013                 [Page 1]


Internet-Draft                   ICN-ISP                    October 2012


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Deployment Considerations in an ISP . . . . . . . . . . . . . . 3
   4.  Routing and Caching Control . . . . . . . . . . . . . . . . . . 4
   5.  ICN with a Centralized Controller . . . . . . . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8







































Li, et al.               Expires April 23, 2013                 [Page 2]


Internet-Draft                   ICN-ISP                    October 2012


1.  Introduction

   Information-Centric Network (ICN) may be deployed over different
   underlying networks, e.g. ad hoc networks, DTN and ISP's networks.
   This document discusses deploying ICN in an ISP's existing networks
   and ICN design for ISPs.


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].


3.  Deployment Considerations in an ISP

   Information-centric networks can be deployed on top of layer-3 or
   layer-2 networks.  It should be preferable for ISPs to deploy ICN as
   an overlay network on top of layer-3 networks, for the following
   considerations: firstly, in the case of incremental deployment,
   packets between newly deployed content routers have to go through
   ordinary routers which do not understand ICN protocols; secondly,
   content routers should be preferably deployed in areas with
   requirements of reducing cost or improving Quality of Service (QoS),
   and there is no necessity of deployment in areas where QoS
   requirements can be fulfilled, and link cost is lower.

   Content routers may be deployed at the edges of networks close to
   content consumers, for the following considerations: firstly, early
   cache hit at network edges means better QoS and more link cost
   savings; secondly, deploying caches at network edges can mitigate the
   impact of unstable wireless link in the case of mobile access users;
   thirdly, it is easier to handle the requests since traffic is light
   at network edges, and cache hits at network edges reduce the load at
   content routers in core network which forwarding high volume traffic.

   Content routers with huge cache spaces may be deployed in core
   networks to achieve high cache hit rates.  Research on cache, e.g.
   [web_caching] and [cooperative_caching], shows that both cache size
   and serving user number affect cache hit rate.  Though early cache
   hit is better, cache hit rate at network edge is limited.  An edge
   content router's cache hit rate is limited by its cache size and
   serving user number.  Firstly, in order to reach a high cache hit
   rate, huge cache space is needed.  But it's costly to deploy huge
   cache spaces in large number of edge content routers.  Secondly,
   fewer users are served by an edge content router.  As a result, a
   large proportion of content requests are for one-time access



Li, et al.               Expires April 23, 2013                 [Page 3]


Internet-Draft                   ICN-ISP                    October 2012


   contents, and hit rate is limited at network edges.

   It is not necessary to deploy a deep hierarchy of content routers in
   an ISP.  On one hand, it is easier to deploy fewer content routers in
   current network.  On the other hand, it is preferable that the cache
   space of a content router is much bigger that the one in a lower
   tier, which means the number of tiers is small.  Because of the Zipf-
   like distribution of content requests, the cache size must grow
   exponentially when the tier grows.  Otherwise, cache hit rate of each
   non-bottom tier is very low.


4.  Routing and Caching Control

   There are two ways to collect topology data and generate routing
   table, namely, self-generation and centralized generation.  In the
   self-generation way, content routers run routing protocols to
   exchange topology data inside an AS or among ASes.  Then each content
   router runs a routing algorithm locally to generate a routing table
   independently.  Alternatively, inside an AS, content routing tables
   can be generated in a centralized way.  In this way, one or more
   controllers collect topology data, and generate routing tables for
   all the content routers.  Then the controller(s) sends route entries
   to content routers.

   There are also two ways to control caching.  A content router can
   decide to cache a content or not on its own by running a cache
   replacement algorithm like LRU or LFU.  However, an ISP may also want
   to use centralized controller(s) to enforce some cache policies.

   An ISP may utilize centralized controller(s) to enforce routing and
   cache policy under following considerations.  First, to meet QoS
   requirement, an ISP may decide routing path and cache resource
   assignment based on factors like content type, content download
   frequency and distance to content source.  Second, to reduce link
   cost, an ISP may assign more cache resource for the contents passing
   through costly links by controlling routing path and/or cache
   priority.  Third, to balance link load and cache load, an ISP may
   optimize routes based on load status.  Fourth, an ISP may provide
   better services to paid users or content providers by controlling
   routing path and/or cache priority.

   To control routing and caching, an ICN controller may need to collect
   not only topology data and traffic data, but also content data like
   content type and content download frequency.






Li, et al.               Expires April 23, 2013                 [Page 4]


Internet-Draft                   ICN-ISP                    October 2012


5.  ICN with a Centralized Controller

   The figure below shows an example of ICN in an ISP.  In this example,
   there are two tiers of content routers, a tier of edge content
   routers with small cache spaces and a tier of centric content routers
   with huge cache spaces.  To store massive contents, the centric
   content routers use cache clusters.  The ICN network is an overlay
   network deployed over IP network.  An ICN controller is responsible
   for generating routing tables and sending route entries to content
   routers.

              O----------O                                O----------O
              |  content |                                |  content |
              |  source  |\                               |  source  |
              |   node   | \                              |   node   |
              O-+--------O  \                             O---+------O
               /             \                                |
              /               \                               |
    /--------+--\              \                              |
    |           |               \,---------.             ,----+----.
    |controller |------------> ,'  centric  `.         ,'    edge   `.
    |           |             (    content    )       (    content    )
    \-----------/             .'.  router   ,'         `.   router  ,'
          |                      `----+----' \       _..-'---+-----'
          |                 .'        |       `. _.-'     .' |
          |               .'          |     _..-\       .'   |
          |             .'            |__.-'     \    .'     |
          |           .'           _.-|           `..'       |
          |         .'        _.--'   |          .-'\        |
          |       .'       __.        |        .'    \       |
          V     .'     _.-'           |      .'       `.     |
      ,---------. _.--'           ,---+----.:           \,---+-----.
    ,'   edge    `.             ,'    edge   `.        ,'    edge   `.
   (   content     )           (    content    )      (    content    )
    `.  router   ,'             `.   router  ,'        `.   router  ,'
      `---+-----'                 `---------'            `---------'
          |
          |
       +--+----+
       |content|
       |client |
       +-------+

   The figure below depicts the roll of a centralized controller in the
   ICN.  Content routing tables of the routers and caching policy of the
   centric content router (CCR) are all generated by the controller
   according to its analysis of collected information, and ISP policies
   can be enforced.  When a content router starts up, it discovers the



Li, et al.               Expires April 23, 2013                 [Page 5]


Internet-Draft                   ICN-ISP                    October 2012


   controller in the domain, registers at the controller, and obtains
   its initial content routing table which is updated by the controller
   afterward.

  +--------+      +-------+      +-------+     +----------+    +-------+
  |        |      |  edge |      |centric|     |          |    |       |
  |content |      |content|      |content|     |          |    |content|
  |consumer|      | router|      | router|     |controller|    |source |
  |        |      | (ECR) |      | (CCR) |     |          |    |       |
  +---+----+      +---+---+      +---+---+     +----+-----|    +---+---+
      |               |              |              |              |
   1. content request:|              |              |              |
   icn://a.com/b/1.avi|              |              |              |
      |-------------->|              |              |              |
      |               |              |              |              |
      |      .---------------.       |              |              |
      |      | 2. cache miss,|       |              |              |
      |      |look up content|       |              |              |
      |      | routing table |       |              |              |
      |      `---------------'       |              |              |
      |               |              |              |              |
      |               |         3. forward content request         |
      |               |------------------------------------------->|
      |               |              |              |              |
      |               |            4. content response             |
      |               |<-------------------------------------------|
      |               |              |              |              |
      |       .---------------.      |              |              |
      |       | 5. store the  |      |              |              |
      |       |   content to  |      |              |              |
      |       |  local cache  |      |              |              |
      |       `---------------'      |              |              |
      |               |              |              |              |
   6. content response|              |              |              |
      |<--------------|              |              |              |
      ~               ~              ~              ~              ~
      |               |  7. report request summary  |              |
      |               |---------------------------->|              |
      |               |              |              |              |
      |               |              |     .----------------.      |
      |               |              |     | 8. analyse the |      |
      |               |              |     |recv'd summaries|      |
      |               |              |     `----------------'      |
      |               |              |              |              |
      |               |             9. instruction: |              |
      |               |       cache icn://a.com/b/* |              |
      |               |              |<-------------|              |
      |               |              |              |              |



Li, et al.               Expires April 23, 2013                 [Page 6]


Internet-Draft                   ICN-ISP                    October 2012


      |               |   10. routing table update: |              |
      |               |      icn://a.com/b/* -> CCR |              |
      |               |<----------------------------|              |
      ~               ~              ~              ~              ~
  11. content request:|              |              |              |
   icn://a.com/b/2.avi|              |              |              |
      |-------------->|              |              |              |
      |               |              |              |              |
      |      12. forward content req |              |              |
      |               |------------->|              |              |
      |               |              |              |              |
      |               |     .-----------------.     |              |
      |               |     | 13. cache miss? |     |              |
      |               |     |fetch the content|     |              |
      |               |     |   from source   |     |              |
      |               |     `-----------------'     |              |
      |               |              |              |              |
      |          14. content response|              |              |
      |               |<-------------|              |              |
      |               |              |              |              |
  15. content response|              |              |              |
      |<--------------|              |              |              |
      |               |              |              |              |

   As shown by steps 1 to 6, upon receiving the content consumer's first
   request to a video content in icn://a.com/b/, the edge content router
   looks up the routing table, and forwards the request to the content
   source.  Upon receiving the response, it decides independently to
   cache the content for a later use, according to a local cache
   replacement algorithm.

   As shown by steps 7 to 10, the controller collects request statistic
   and generate routing tables and CCR caching policy in a centralized
   way.  Each content router generates a summary of requests it recently
   received by some sampling techniques, and sends the summary to the
   controller periodically.  The controller generates content routing
   table according to analysis of the summaries and the ISP's policies,
   and sends the routing table updates to the routers.  The controller
   may decide that the centric content router stores entire or parts of
   a content source site with higher request frequency.  The centric
   content router may prefetch the contents from the source site.  The
   edge content routers update their routing tables accordingly.  A
   routing table item in an aggregated form (in this example,
   icn://a.com/b/*) will direct the requests to the centric content
   router.

   As shown by steps 11 to 15, upon receiving the content consumer's
   second request to a video content in icn://a.com/b/, the edge content



Li, et al.               Expires April 23, 2013                 [Page 7]


Internet-Draft                   ICN-ISP                    October 2012


   router forwards the request to the centric content routers.


6.  Security Considerations

   TBD


7.  References

7.1.  Normative References

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

7.2.  Informative References

   [cooperative_caching]
              Wolman, A., Voelker, G., Sharma, N., Cardwell, N., Karlin,
              A., and H. Levy, "On the Scale and Performance of
              Cooperative Web Proxy Caching",  ACM Symposium on
              Operating Systems Principles, 1999.

   [web_caching]
              Breslau, L., Cao, P., Fan, L., Phillips, G., and S.
              Shenker, "Web Caching and Zipf-like Distributions:
              Evidence and Implications",  INFOCOM, 1999.


Authors' Addresses

   Lichun Li
   ZTE Corporation
   Zijinghua Road 68
   Yuhuatai District, Nanjing 210012
   P. R. China

   Email: li.lichun1@zte.com.cn


   Xin Xu
   ZTE Corporation
   Zijinghua Road 68
   Yuhuatai District, Nanjing 210012
   P. R. China

   Email: xu.xin18@zte.com.cn




Li, et al.               Expires April 23, 2013                 [Page 8]


Internet-Draft                   ICN-ISP                    October 2012


   Jun Wang
   ZTE Corporation
   Zijinghua Road 68
   Yuhuatai District, Nanjing 210012
   P. R. China

   Email: wang.jun17@zte.com.cn


   Zhenwu Hao
   ZTE Corporation
   Zijinghua Road 68
   Yuhuatai District, Nanjing 210012
   P. R. China

   Email: hao.zhenwu@zte.com.cn



































Li, et al.               Expires April 23, 2013                 [Page 9]


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