Information-Centric Network in an ISP

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.

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 .

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. and , 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 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.

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.

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.

,' 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 controller in the domain, registers at the controller, and obtains its initial content routing table which is updated by the controller afterward.

| | | | | | | | | | .---------------. | | | | | 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/* | | | | |<-------------| | | | | | | | | 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 router forwards the request to the centric content routers.

TBD