Recent Information-Centric Networking Approaches

Dolvara Gunatilaka, dgunatilaka@wustl.edu (A paper written under the guidance of Prof. Raj Jain)

Download

Abstract:

Information-Centric Networking (ICN) proposes a future Internet architecture that revolves about the contents being exchanged rather than the communication of hosts and network devices. This paradigm shift is caused by the tremendous growth of information on the Internet and the increased demands for data access. Many research projects have proposed different ICN approaches over the past few years. Therefore, in this paper, we will give an overview of the ICN concept, and will provide a detailed summary of the recent proposed ICN architectures, which include Network of Information (NetInf), Named Data Networking (NDN), Publish-Subscribe Architecture, COMET, and CONVERGENCE.

Keywords:

Information-Centric Networking, ICN, Content-Centric Networking, Data-Oriented Networking, Future Internet Architecture, Named Data Networking, NDN, Network of Information, NetInf, SAIL, Publish- Subscribe Architecture, PURSUIT, COMET, CONVERGENCE.

Table of Contents

• 1. Introduction
• 2. ICN Concept and Components
  • 2.1 ICN Naming Scheme
  • 2.2 ICN Routing and Forwarding
  • 2.3 ICN Caching
• 3. ICN Approaches
  • 3.1 Network of Information (NetInf)
  • 3.2 Named Data Netowkring (NDN)
  • 3.3 Publish-Subscribe Architecture
  • 3.4 COMET
  • 3.5 CONVERGENCE
• 4. Summary
• 5. References
• Acronyms

1. Introduction

The current Internet architecture was designed to center around communication between hosts in the networks. As a result, a user has to specify a host in order to retrieve information. Today, there is a drastic increase in information distribution over the Internet, and the growth demand of information from users. Internet traffic becomes more variable, ranging from multimedia traffic, web pages, real-time streaming, etc. Consequently, the existing Internet architecture could not adapt well to the changes.

The current solution such as TCP/IP becomes inefficient and subjects to certain problems [Haque13]. For example, to search for a specific content, the piece of information must be mapped to a host, and then the DNS translates the host name to the location i.e. IP address. The two-step mapping incurs access overhead. IP address also binds to a location so it does not support node and content mobility. Security is another important issue since the security mechanism is tightly coupled to the host. Therefore, host becomes a target of many security threats. In addition, because the IP router is stateless and does not provide a caching capability, the same request would be made multiple times through the path, and cause an unnecessary bandwidth usage. This prompted the research into shifting Internet architecture from a host-centric to information-centric.

Earlier architectures such as Content Delivery Networks (CDN) and Peer-to-Peer (P2P) addressed similar problems and took the initiative to improve user's information access. Then, Information Centric Networking (ICN) has been subsequently proposed for the future Internet architecture. The main concept of ICN is to deploy content name at the network level. The content identifier is independent of its location, therefore allowing content to move freely on the Internet. ICN supports in-network caching, which helps the content to become closer to the user. Security is coupled with the content rather than the host. Hence, information can be distributed and retrieved in a scalable and efficient fashion.

Many ICN related projects have been proposed in the past years. TRIAD [TRIAD], which proposed name-based routing model, and UC Berkeley Data Oriented Network Architecture (DONA) [Koponen07] are earlier ICN affiliated projects. Since then, many research efforts on ICN have been put forward into the research community. In this paper, we will first start with the introduction to the ICN concept, and then follow by recently proposed ICN projects including Name Data Networking (NDN), Network of Information (NetInf), Publish and Subscribe Architecture, Content Mediation Networks (COMET), and CONVERGENCE architecture.

2. ICN Concept and Components

In this section, we introduce a general concept of ICN by providing an overview description of ICN components, which includes the naming scheme, the routing mechanism, and the caching capability.

2.1 ICN Naming Scheme

Information/content unit in ICN is generally called Named Data Object (NDO). NDO can be any kind of digital content such as a video, an image, a document, a webpage, etc, or it can represent a real world object. It consists of a location-independent identifier (name), data, and possibly a metadata, which describes an NDO. The same NDO can be identified by multiple names. An NDO is designed differently in each ICN approach. ICN categorizes the naming scheme into 2 different types [Choi11]. The commonly used schemes are flat and hierarchical naming.

Hierarchical Naming consists of multiple components. The format is similar to the URL i.e. com1/com2/obj, where “/” denotes the boundary between components. Hierarchical naming enhances scalability since name prefix can be aggregated in the same way as the URL. Therefore, It is more coherent to the existing IP networks. The name is user-friendly and conveys meaning to users. Therefore it is easy to remember. However, it imposes security vulnerability since the name is visible and does not bind to a hash.

Flat Naming offers uniqueness and persistency. There are no structure binds to the name. The hash of the content or the hash of the source's key is put as part of the name, which adds self-certifying property. Therefore, the name is not human-friendly. Flat naming has a scalability problem since it does not support routing aggregation. Therefore, the architecture must add additional structure to solve this issue [Ahlgren12].

More recent ICN proposals allow a hybrid naming which mix flat naming and hierarchical naming to take advantage of both schemes.

2.2 ICN Routing and Forwarding

ICN handles NDO packet routing and forwarding through 2 different methods, Name Resolution (2-step approach), and Name-Based Routing (1-step approach) [Bari12].

Name Resolution approach provides a means for client to search for NDO by name. It consists of 2 steps, the name to source locators (NDO storage) mapping, and the forwarding of request message to the source. This 2-step approach needs additional entity called Name Resolution System (NRS) to provide the translation. The disadvantage of this approach is that NRS can be a point-of-failure, and as a consequense, many NDO registered on that NRS would be inaccessible. Another drawback is that the NRS requires a large storage to store NDO mapping. However, this approach guarantees the finding of the requested NDO since NRS already provides a pointer to the NDO source.

Name-Based Routing is a 1-step approach. NDO request is forwarded by content routers (CR), where CR locally decides the next hop of the NDO request based on NDO name. There are 2 types of routing models [Choi11]. The first is the Unstructured Routing, which is similar to the traditional IP routing with some modification. Therefore, it does not work well when there is NDO movement and when the number of copies of NDOs is large. The second model is the Structured Routing. It uses Distributed Hash Table (DHT) to provide a lookup and routing service. The pros of this method are its ability to scale and a small overhead when changes occur. Name-Based Routing approach does not guarantee the discovery of the NDO since the resolving and forwarding process is done hop-by-hop.

2.3 ICN Caching

ICN offers caching service to improve the performance of NDO access of the subsequent requests. Multiple copies of NDOs can be distributed across the networks. It can be stored locally on a node's cache or can be a shared on a network cache. Caching can also be classified into in-network caching where the caching is done within the networks, i.e., on the content routers, and the edge caching in which the end nodes store the cache. Furthermore, caching can also be divided into 3 levels based on granularity; object level (complete NDO), chunk level (part of NDO) and packet level (bytes of NDO) [Pavlou13_2]. Each ICN architecture applies different caching granularity, scheme, and policy depending on its design. Overall, caching helps reducing the request traffic towards the source. It also enhances the response time of NDO requests. In the next section, we will discuss in more details about different proposed ICN architectures.

3. ICN Approaches

There are many ICN approaches that have been put forward in the past few years. In this section we will give a summary of recent ICN architectures. In each approach, we consider its general concept; the information model, the naming scheme, and the routing and forwarding of NDO request and response.

3.1 Network of Information (NetInf)

Network of Information (NetInf) is one of the proposed designs for the future Internet architecture. It was initiated by the European FP7 4WARD project [4WARD], and has been further developed by the SAIL project [SAIL]. In this section, we will focus on the NetInf architecture of the SAIL project.

Two classes of objects are defined in NetInf [Dannewitz09]. 1.) Information Object (IO), which represents the real world object 2.) Data Object (DO) represents a digital object, for example, a Star War movie is an information object, while its encoding, MP4, is the data object. In NetInf information model, each information object can be decomposed into multiple information objects, which mapped to one or more data object. The data object then mapped to one or more locators. This model allows users to access information by specifying a semantic object rather than a host. We will use the term named data object (NDO) as a general term for information object. An NDO in NetInf consists of a unique identifier, a metadata, and the data. Metadata provides description of the data. In many cases, it is used for a security purpose.

SAIL's naming scheme is flat. The name is defined by using a “ni:” and “nih:” URI scheme. Naming in NetInf also provides name-data integrity to ensure that given the name, the retrieved object really corresponds to it. To provide a user-friendlier naming, a mapping system can be provided for translating between “ni:” name and a human-friendly name.

SAIL provides two different models for forwarding user request. In the first model, Name Resolution System (NRS) is used to map the name to its locators indicated where the NDO is stored. NRS uses multilevel DHT to form a hierarchical resolution system, which consists of global NRS and local NRS. The local and global scope helps make sure that the selected locator is always close to the user. In addition, the NRS also keeps track of the user's request and collects request statistics. This information is useful for determining which NDO should be cached locally, and thus speed up the NDO retrieval. Alternatively, in Name-Based Routing model, NDO information is stored and distributed in network routers using a routing protocol. Therefore, NDO request can be directly forwarded to the NDO source. Moreover, SAIL also integrates NRS with Named-Based Routing to support a more flexible mechanism. The hybrid mode allows user to query the NRS, which then responds back with a routing hint. The hint will guide the request towards the NDO source.

Figure 1: SAIL Name Resolution and Name-Based Routing Approach

SAIL implements NetInf model on top of the HTTP layer of the TCP/IP stack or on top of a non-IP stack. The NetInf communication layer is called a Convergence Layer (CL). Figure 1 [Xylomenos13] shows the flow of NDO request and its corresponding data response of NRS and Name-Based Routing models. For NRS, A source, who owns a copy of NDO, sends a PUBLISH message to its local NRS. The local NRS then registers the NDO to the global NRS. A client sends a name resolution request to the local NRS. If there is no match, a request is forwarded to global NRS, which returns an NDO locator to the client. The client then requests for an NDO by sending out GET message. The GET message is forwarded by the underlying network to the source. The DATA RESPONSE is then route back from the source to client using the same path. In Named-Base Routing approach, a client sends a GET message directly to the content routers (CR). The router contained NDO information will forward the request to the NDO source.

3.2 Named Data Networking (NDN)

Named Data Networking (NDN) [NDN] proposed an architecture that is shifted from the current IP model to the data oriented communication. NDN was developed from the proposed Content-Centric Networking (CCN) [Jacobson09].

In NDN, there are two types of packet. An INTEREST packet that client sends out to request for a Named Data Object (NDO). It includes the name specifying the NDO. A DATA packet is a response from the data source. It contains the name, as well as the signature, and the data content. NDN uses a hierarchical scheme for naming. A name can be human-readable or a binary object and is not visible to the networks. Client and source must agree upon name construction so at the end both of them can conclude with the same name. For each NDO, name and data are bonded and attached with a signature to achieve name-data integrity and authenticity.

NDN device provides 3 modules for forwarding, routing packet and caching data [Zhang10]. 1.) Forwarding Information Base (FIB) is a table that provides forwarding information. It directs INTEREST packet toward one or more sources. FIB is generated by a named-based routing protocol. 2.) Pending Interest Table (PIT) collects one or more incoming interfaces of the INTEREST packet so the DATA packet can be delivered back on the same path. 3.) Content Store (CS) is used for caching NDO so the subsequent request can access the data faster.

A client request for an NDO sends out INTEREST packet. When the packet arrives at the NDN node, i.e., server or router, the node checks whether an NDO exists in its content storage or not by checking the NDO name. If there is a match, a DATA packet is sent back to the client. If not, a node will check its PIT table. If the entry exists on a PIT, the INTEREST packet is dropped and the arrival interface of the entry is updated. This means that the client already made an NDO request hence the request will not be forwarded again. On the other hand, if it does not exist, a new arrival interface is added to the PIT. A node then determines where to forward the INTEREST packet by checking the FIB table. When the INTEREST packet reaches the source, the DATA packet is generated and routed back to the client on the same path by using collected route data from PIT. As the DATA packet is forwarded back along the path, the corresponding PIT entry is removed.

Figure 2: NDN Name-Based Routing Architecture

Figure 2 [Xylomenos13] shows NDN message flows. The table includes entries on CS, PIT, and FIB when the INTEREST packet is forwarded hop-by-hop from client to source. The routing process in NDN is hop-by-hop and one request generates one response.

3.3 Publish-Subscribe Architecture

In Publish-Subscribe Architecture, a source publishes information. A client then subscribes to the content it needs. If the information is available, it will be delivered to the client. The Publish-Subscribe Internet Routing Paradigm (PSIRP) [PSIRP] was an earlier ICN model that proposed this architecture and then followed by its successor project, PURSUIT [PURSUIT]. Both PSIRP and PURSUIT are part of the European FP 7 project. In this section, we will present the Publish-Subscribe model of the PURSUIT project.

Figure 3: PURSUIT Information Model

The data unit in PURSUIT is called an information item. Each information item has a pair of identifiers, which are Scope ID (SId) and Rendezvous ID (RId). SId tells which group an information item belongs to, while RId represents each information piece. Each information item must be in at least one scope. The scope provides policy enforcement and access right for each group of information items. Figure 3 [PSIRP] shows a hierarchy of scopes. Naming in PURSUIT follows flat scheme, comprises of sequences of SId(s) and an RId. A name is a path from the root of the tree to the leaf node, which is RId. Same piece of information can be specified by multiple names. For example, SId1/SId1/RId1, or SId2/SId1/RId1 specifies RId1.

Three core functions drive PURSUIT architecture: Rendezvous Function, Topology Function, and Forwarding Function. Rendezvous Function plays a major role in PURSUIT by providing a name resolution function, which maps a subscriber to a publisher. It also initializes the delivery of information item to the client. The Rendezvous Function performs at the Rendezvous Point (RP) on the Rendezvous Node (RN). RNs are structured in hierarchy through Distributed Hash Table (DHT). An RN node is responsible for managing different scope. The Topology Function deploys a routing protocol to collect the topology of its domain and exchange routing information with other domains for global routing. It is operated by Topology Manager (TM). One domain contains one TM. Lastly, Forwarding Function is implemented on the Forwarding Node (FN), which directs the information item to a client. The forwarding mechanism is label-based and uses the Bloom Filter technique to speed up the information delivery. In addition, FN also has caching ability.

Figure 4: PURSUIT, Request and Data Flows Architecture

Figure 4 [Ahlgren12] [Xylomenos13] shows the sequence of NDO publish and request in PURSUIT. A source publishes information item (SId, RId) to the RN, who is the owner of the scope. The scope owner RN can be source local RN or RNs in different domain. The client specifies RId and SId in order to request for an information item. It sends out a subscription message via its local RN towards the scope owner RN using RId. The scope owner RN then sends a request to TM to generate a return path and send it to the source, which then uses source routing to deliver NDO to client. The information item is forwarded via FNs, which uses Bloom Filter's Forwarding Identifier (FId) to decide where to send the packet.If a client requests for an information item it asked for before, PURSUIT provides a mechanism to bypass the RN functions, so the request message can be forwarded directly by the FNs to the source using a Bloom Filter's reverse path [Xylomenos13].

3.4 COMET

COMET [COMET] is another ICN project funded by the European FP 7. Its architecture distinguishes two types of planes. First, the Content Mediation Plane (CMP) that lies between the contents and the physical network layer. The plane tightly connects the two layers together allowing the gain of content awareness (i.e. characteristics of content), server awareness (i.e. server conditions), and network awareness (i.e. topologies and available paths), which helps COMET enhance efficient content retrieval. The second plane is the Content Forwarding Plane (CFP). 

CMP is apprehended by a Content Mediation Server (CMS). CMS provides a name resolution function. It maps a name to a list of content sources or caching devices using hierarchical distributed hash table (DHT) or the DNS approach. One content source is then selected based on the awareness information such as content distance, server workload, and network loads. Another component in COMET is the Content Aware Router (CAR). CAR connects to the CMS and performs content forwarding based on CMS instructions. It situates in the CFP plane. Each COMET domain contains at least one CMS.

Figure 5: COMET Functional Blocks and their Relationship

Figure 5 [Pavlou13_1] shows COMET functional blocks and their relationships.

• Content Resolution Function (CRF) resolves content name to one or more content sources. The list of candidate content sources is considered based on the server awareness information supplied by SNMF.
• Path Management Function (PMF) connects to the physical networks and gathers information regarding network quality of service and route quality.
• Server and Network Monitoring Function (SNMF) collects the network information and server information and delivers to CMF and CRF respectively.
• Content Mediation Function (CMF) acts as a main controller. It receives the client request and triggers CRF for name resolution. It then uses network awareness information from SNMF and routing awareness information from PMF to choose the most suitable content source and the best delivery path for the client.
• Content Aware Forwarding Function (CAFF) is responsible for forwarding the content based on the path specified by the CMF. It functions in the CFP plane.

Figure 6: COMET Coupled Approach

COMET supports two architectures; the Coupled Approach and Decoupled Approach. In the Coupled Approach, name resolution and content delivery are coupled together. A source publishes a new content by sending out a REGISTER message to its local CMS. A local CMS then assigned an identifier to the content and advertises the new content entry to other CMSs by issuing a PUBLISH message to its parent CMSs (COMET domains are structured in hierarchy). The PUBLISH message consists of the content ID, and content location. When a client requests for a content, it sends a CONSUME message to its local CMS. The message is forwarded to the upper-level CMS until the named content is found. Then, the message is sent to the domain where the content resides, and finally to the source. In each CMS, a name resolution is performed. The CMF function decides the best content source for the clients based on awareness information. Finally, CARs deliver the content to the client by using the content delivery tree it stored. The state tree is established during the name resolution by the CMS. Figure 6 [Xylomenos13] presents the flows of request and data message flows of the coupled approach.

For the Decoupled Approach, name resolution is separated from content delivery. CRF function in this case works the same way as the DNS so the content name is a locator. As a result, there is no mobility for the content. In this approach, a source send out a PUBLISH message only to its local CMS. The client also issues a CONSUME message to its CMS. The client CMS will ask its upper-level domain for source CMS location. Then, the client CMS will connect to the source CMS to establish the path from client to source. Client can then use source routing to forward the request message to the source through CARs. The source routes the content to the client using reverse path. The coupled approach is not practical for the information centric architecture.

3.5 CONVERGENCE

CONVERGENCE [CONVERGENCE], a European FP7 project is based on the publish-subscribe model. CONVERGENCE introduces VDI (Versatile Digital Item) as its unit of content distribution. VDI acts as a container that holds name, metadata, and resource (data). Metadata in VDI links to a license, which specifies the action that can be performed to the resource. VDI is represented in an XML format.

CONVERGENCE introduces a 3-level architecture [Chiariglione12]. First, the Application Level is part of the semantic overlay. It forms and ingests VDI, which sent and received through the application-middleware interface. The second is the Middleware Level (CoMid). CoMid provides a VDI processing capability, which allows a node to publish or search for a VDI. Lastly, the Computing Platform offers node's communication infrastructure, which is based on the Content Network (CoNet) architecture. In addition, a content security mechanism (CoSec) is also included in this level.

Content Network (CoNet)[Melazzi12] is an ICN underlying infrastructure in which CONVERGENCE exploits to accommodate the publish and subscribe of NDOs. Its approach is fairly similar to the NDN architecture. However, there are some certain concepts that differentiate the two models. CoNet deploys hierarchical naming scheme. Each name composes of a sequence of components for example, /domainName/objectName/ChunkName. The data source split contents into chunks, each of them specified by name. Therefore, in order to retrieve the complete content, a client need to send out a stream of requests to the source to fetch all chunks.

CoNet composes of multiple CoNet subsystem (CSS), which contains CoNet nodes. There are different approaches for CoNet implementations such as CoNet on top of L3 (IP), CoNet on top of L2, and CoNet L3 integration. CoNet Information Unit (CIU) consists of 2 types. An Interest CIU is sent out to request for an NDO from the sources or caches, and the Data CIU that carries the NDO and delivers it to the client. All types of CIU are transported by the CoNet's carrier-packets.

There are 5 types of CoNet components defined: 1.) End Node (EN) is a client device that requests for an NDO by sending out Interest CIU. 2.) Serving Node (SN) splits the data into chunks and then deliver the data chunk through the Data CIU. 3.) Border Node (BN) helps forward the carrier-packets using name-based routing protocol. It also stores cached NDO and connects 2 CSSs together 4.) Internal Node (IN) provides an in-network caching capability. It sits in between the BNs in the CSS and is optional for the deployment. 5.) Name Routing System Node (NRS), also offers name-based routing service.

The Lookup and Cache Concept allows nodes to forward carrier-packets to the right destination. A Forwarding Information Base (FIB), resides in BN, contains an active forwarding information i.e. route that are frequently used. When an Interest ICU arrives, a name prefix matching is performed. If there is no matching entry in FIB, FIB will send a name lookup request to a Routing Information Base (RIB) located on the NRS. RIB holds a complete set of routing information and responds to FIB query. In the case that FIB cannot find a matching entry, and its table is already full, FIB uses a routing replacement algorithm to determine its action. It can either do nothing and drop the Interest packet or query a new entry from RIB and replace the old entry with the new one. FIB uses algorithm such as Inactive Timeout Estimation to replace the least recently used entry. Too many lookups can incur delay and increase NRS workload.

FIB in CONVERGENCE performs the same function as in NDN, but it contains a smaller set of routing information i.e. the active ones, and consults with RIB when necessary. The two level of routing information storage helps saving cost since a large number of FIBs can be made small and cheap, with only a few large and expensive RIBs provided. After the Interest CIU reaches the source or the caching devices, the Data CIU is routed back through the reverse path using the forwarding information collected by the Interest CIU as it traveled upstream. This is another point that varies CONVERGENCE from NDN since NDN uses PIT entry to route Data packet back to the requester.

Figure 7: CONVERGENCE Request and Data Flows Architecture

Figure 7 [Xylomenos13] shows CONVERGENCE CIUs flows. The Interest CIU is sent from client towards the data source or the caching device. BNs forward the Interest CIU based on information on FIB. FIB can consults with RIB when it cannot find a forwarding entry. Between BNs, network routers are responsible for forwarding Interest CIU to destination BN. When the Interest CIU reaches source, the Data CIU is sent on the reverse path. On the way to client, the data can be cached on the BNs and INs.

4. Summary

The architecture of the Internet has shifted from the traditional TCP/IP based to the content oriented networks where information is disseminated in a more efficient manner and located closer to the users. The paper presents a survey on 5 ICN projects proposed in the past few years (2010 to present). We focus mainly on the naming scheme and routing mechanism of each approach. Table1 [Xylomenos13] [Ahlgren12] provides a summary of different ICN Approaches. NDN and CONVERGENCE uses a hierarchical naming and name-based routing. The hierarchical naming allows name to be aggregated and hence accommodate a large name space. However, with name-based routing, each content router will have to handle a large amount of routing entries. SAIL (NetInf) and PURSUIT (Publish-Subscribe Architecture) applies a flat scheme and name resolution. The main issue of flat naming is scalability. To solve this problem, both SAIL and PURSUIT provide Distributed Hash Tables (DHT) to form a hierarchy of name resolution. In addition, SAIL and PURSUIT also use name-based routing for content delivery. COMET does not clearly specify its naming scheme, but it supports a name resolution mechanism using scope hierarchy provided by the Content Mediation Plane. It also uses content routers to provide name-based routing mechanism.

5. References

Acronyms