1 Introduction

Internet is a global communication infrastructure that hosts billion of devices and enables the exchange of exabytes of data per year. According to its native design, the communication between clients (i.e., the data consumer) and remote servers (i.e., the data producer) entails the establishment of end-to-end connections. This data exchange mechanism can be considered as host-centric in nature: Any information is strictly related to the location of nodes that make them available, as generally expressed by the Uniform Resource Locator (URL) or the IP address. Such a conventional paradigm was considered a winning strategy since the creation of packet-switched networks, but the current network usage is extraordinarily increasingly requiring the adoption of different communication paradigms. Nowadays, in fact, users are more interested in sharing contents rather than in interacting with remote devices. As a result, they are experiencing a novel content-centric usage of the Internet (Jacobson et al. 2009). At the time of this writing, there exist many solutions that could be used for better supporting content distribution and service provisioning, while truing to overcoming the limitation of the classic host-to-host Internet model. They include (just to name a few) Content Delivery Networks, Peer-to-Peer architectures, and cloud-based platforms (Piro et al. 2014, Sadiku et al. 2014). Unfortunately, conventional communication schemes generate, in this context, heavy issues in terms of scalable content distribution, mobility, security and trust, resilience of ICT services to system failures, and content availability (Piro et al. 2014). Therefore, the research community started to elaborate innovative solutions, based on radically different Internet primitives (Pan et al. 2011).

In this exciting field of research, information-centric networking (ICN) has emerged as a revolutionary formulation: It intends to re-think the foundation of the current Internet by introducing flexible and efficient mechanisms for content dissemination (Ahlgren et al. 2012). In its main rationale, ICN envisages that: (1) each content is addressed through a name that does not contain anymore a reference to its location; (2) the user interested to a specific content just sends a request including the name of the desired data item; (3) the request is processed by the network based on specific name resolution and/or routing-by-name approaches (Xylomenos et al. 2014). In addition, ICN provides in-network caching strategies that ease the distribution of contents among users, reducing, at the same time, the traffic load at the server side. Due to its inherent features, ICN offers asynchronous communications, built-in security capabilities, easy support to peer-to-peer communications, Quality of Service (QoS) management strategies, and native support for mobility, multipath, and multicast communications (Ahlgren et al. 2012; Xylomenos et al. 2014; AbdAllah et al. 2015; Fang et al. 2015; Fang et al. 2014).

The ICN approach has been investigated and developed in several international projects, such as data-oriented network architecture (DONA), Network of Information (NetInf), publish/subscribe Internet technology (PURSUIT), scalable and adaptive Internet solutions (SAIL), CONVERGENCE, Named-Data networking (NDN), MobilityFirst, and COntent Mediator architecture for content-aware nETworks (COMET) (Xylomenos et al. 2014). Starting from the architectures proposed in these projects, since 2009 researchers are investigating the possibility to extend and improve ICN functionalities, as well as evaluating their real effectiveness through computer simulations and experimental tests. Preliminary research works investigated the use of ICN for the dissemination of contents with heterogeneous levels of popularity and the provisioning of multimedia services (both real-time and on-demand) (Sadiku et al. 2014, Fang et al. 2014). Those efforts have pointed out the gain provided by ICN with respect to the current Internet architecture in massive content distribution scenarios. These findings, indeed, highlighted the need to further assess ICN potentiality in more complex and real use cases.

Therefore, current research trend strives to address questions such as: can ICN be part of our everyday life by enabling both pioneering and effective applications? Can ICN be smoothly applied to the currently available Internet infrastructure?

With the final aim to provide initial answers to such questions, the present contribution intends to:

  • provide an overview of the most important ICN architectures developed so far, by presenting their main aspects, their common networking approaches, and their significant differences;

  • illustrate the work carried out in standardization bodies, with particular attention to the list of baseline scenarios defined in this context;

  • present the main international projects that are trying to integrate ICN networking primitives in pioneering use cases;

  • describe proposed architectures and related challenges for enabling information-centric primitives in current network infrastructures;

  • highlight design principles and core components to build ICN-enabled network devices.

The rest of the paper is organized as follows: Sect. 2 overviews ICN solutions, exposes recent standardization activities carried out in the context of the Internet Research Task Force (IRTF), and illustrates pioneering use cases where ICN-based approaches are being to be investigated and applied. Section 3 describes different approaches used to integrate the ICN paradigm into traditional network infrastructure. Finally, Sect. 4 closes the manuscript and draws future research.

2 Current solutions and upcoming trends in the ICN research arena

The need of ICN has been mainly motivated by the inefficiency of traditional host-centric networks in delivering contents, and the foreseen difficulty they will have in meeting future user expectations, with increasing request of online video exchange and large files transfer. ICN focuses on the content (i.e., what is relevant to the user) rather than on who is providing the content (and thus where the content is located) and targets receiver-driven communications, based on content names, name-based routing, and self-certifying packets. Hence, a user, namely a data consumer, expresses an interest for a content. Then, the ICN architecture takes care of routing-by-name the content request toward the best source (that could be the data producer, a replica server, or an in-network cache) and sends back to the user the related data. As stated in the Introduction, several networking architectures developed within international projects, e.g., DONA, NetInf, PURSUIT, CONVERGENCE, NDN, MobilityFirst, COMET (Ahlgren et al. 2012, Xylomenos et al. 2014), already share this simple, but effective, communication paradigm. However, they differently address some other key aspects, including naming schema and security, routing strategies, cache management, as described hereafter in more detail.

As regards naming schema and security aspects, two main approaches have been explored. The NDN project adopts a hierarchical human-readable name that is composed by multiple strings of characters, arranged in a URL fashion. In general, a trusted relationship between such names and the matching data is required. To this aim, NDN appends to the returned data packet a signature (generated from a concatenation of name and information included in the message itself) and details about the key used to produce the signature (for instance, the public key of the signer, and a certificate for that public key). Instead, DONA, PURSUIT, SAIL, NetInf, and MobilityFirst projects rely on a flat self-certifying structure of names: Each datum is identified through the hash of its name, authenticated by using the public key of the data producer. Differently from NDN, flat naming schemes natively integrate security aspects. The CONVERGENCE architecture supports both flat and hierarchical naming schemes. Finally, the COMET project introduces URI-based names, which are generally self-certified.

ICN solutions also differ in terms of routing mechanisms, used for both name resolution and data path creation. Name resolution usually refers to the mapping of a content name to possible locators of content sources. The data path, instead, identifies the set of intermediate routers through which the data packet is forwarded toward the user that generated the request. Note that these two operations may be coupled (i.e., data are sent back to the user through the same path of the request) or decoupled (i.e., requests and corresponding data packets follow different routing paths, often created by different logical nodes). Coupled approaches are adopted in CONVERGE, NDN, and COMET. Decoupled schemes are integrated in NetInf, PURSUIT, and Mobility first proposals. DONA and SAIL support both of them.

ICN architectures diverge also in caching mechanisms used for storing content copies within network nodes. On-path and off-path caching strategies have been investigated so far. The on-path caching supposes that a requested data can be stored and later retrieved by any intermediate node visited by the content request. This scheme is natively supported by ICN architecture where name resolution and data path are offered in a coupled fashion, e.g., NDN and CONVERGENCE. With the off-path strategy, replicas of a requested content can be found in network nodes not crossed by the user request. In both cases, the ICN architecture uses nodes with cached content as parallel data producers, which may be taken into account during the name resolution process and/or routing-by-name operations.

A concise outline of the main ICN architectures and the related features set is summarized in Table 1.

Table 1 Features covered by the main ICN architectures
Full size table

2.1 Standardization activities related to ICN

The interest into this research domain has emerged also in the Internet Research Task Force (IRTF) where the Information-Centric Networking Research Group (ICNRG) has been chartered in the 2012 (IRTF https://irtf.org/icnrg). It aims at providing a threefold contribution: (1) the classification of the most important ICN-based solutions emerging from the literature review; (2) the description of the ICN problem statement, the main concepts, and the related research challenges; and (3) the definition of standardized methodologies to evaluate the performance of ICN solutions in reference baseline scenarios. A brief overview of the main ICNRG outcomes is reported below.

First of all, the definition of the message format supported in both NDN architecture and CCNx protocol is presented, in its preliminary formulation, in Mosko and Solis (2015), Mosko and Solis (2015), Stapp (2015a, b). The provisioning of on-demand video streaming services is discussed in Lederer et al. (2015). In this contribution, a particular attention has been devoted to the implementation of MPEG-DASH, P2P, and IPTV protocol architectures over ICN. Moreover, the possibility to provide more challenging streaming services (covering, for example, large-scale live events, video conferencing, adaptive real-time communications, video distribution in heterogeneous wireless environments, and advanced services based on the network coding) is presented too. Then, to support worldwide research activity working on ICN-related aspects, a deep analysis of methodologies that the research community has to follow for evaluating the performance and the effectiveness of their own solutions is also discussed in Pentikousis et al. (2015). They turn around the usage of specific available tools, target scenarios (including topologies and traffic models), and evaluation metrics. The adoption of ICN in the context of the Internet of Things (IoT) is, at the time of this writing, under discussion in three different contributions: (Lindgren et al. 2015; Zhang et al. 2015a, b). A preliminary presentation of challenges and requirements characterizing the integration of ICN primitives in IoT systems is presented (Lindgren et al. 2015) and (Zhang et al. 2015a). From these documents it emerges that naming, scalability, contextual communication, energy consumption, mobility, caching, security and privacy, and communication reliability represent the most important issues that have to be carefully addressed in this context. Furthermore, a unified IoT platform based on the ICN architecture, namely ICN-IoT, is proposed in Zhang et al. (2015b); it leverages the salient features of ICN and thus provides seamless mobility and scalability, as well as efficient content and service delivery.

Furthermore, the ICNRG has recently standardized a set of baseline scenarios where evaluating and demonstrating the performance gain offered by the ICN communication paradigm with respect to legacy systems (Pentikousis et al. 2015). A critical analysis of key aspects and main open issues characterizing each envisaged baseline scenario is reported below.

  • Social networking It refers to content dissemination services within a social network, where users continuously share and exchange heterogeneous contents (like photos, videos, messages, etc.). Conventional social networking applications often leverage dedicated Content Distribution Network (CDN) infrastructures, with high costs of investment and maintenance, for handling the storage and the distribution of contents among registered users. This requirement will be no more needed within the ICN architecture: The use of routing and caching strategies could allow to distribute large amount of content among the social network users, without relying on any ad hoc infrastructure.

  • Real-time communication It focuses on the real-time transmission of multimedia contents, like peer-to-peer voice/video conversation, audio/video conference hosting multiple users, and unicast, multicast, and broadcast streaming services. ICN well supports the unicast retrieving of contents (i.e., video packets) that are generated by data producer (also in real time). Moreover, thanks to its native support to multicast, it provides enormous advantages for multicast/broadcast services, expressed in terms of reduced traffic load at the server side, lower delays experienced by the clients, and better usage of network capacity.

  • Mobile networking The variability of the channel quality, the limited amount of radio resources, and the user mobility are among the main factors that challenge the deployment of mobile wireless networks (e.g., ad hoc, infrastructure Wi-Fi, and broadband systems). In such scenarios, the connectionless-oriented nature of ICN sounds suitable for supporting user mobility, intermittent connectivity, and low-power constrained devices. Novel and dynamic routing mechanisms for ensuring service continuity, regardless the mobility of both user and data provider, have to be designed.

  • Infrastructure sharing This scenario envisions network devices, access nodes, and mobile users that share storage, computational and communication capabilities on the cloud, thus achieving a powerful, distributed, and energy-efficient usage of the network infrastructure. As expected, the connectionless data retrieving, in-network caching, and name-based networking primitives are the most promising features that make ICN appealing in this scenario. However, privacy, security, access policies, operational and economic issues still represent extremely important aspects to evaluate before realizing such global infrastructure sharing.

  • Content dissemination This is a very general scenario that includes one or more use cases afore-listed before (by also considering their deployment on a large scale) and embraces any application that foresees the possibility to distribute contents into the network in both real-time and on-demand fashion. While all the considerations discussed so far are still valid, in this baseline scenario it is even more important the design of scalable and low-cost solutions able to disseminate billions of objects. Moreover, the management of prepaid contents and any other kind of restricted access are critical facets to consider in this context.

  • Vehicular networking It focuses on vehicles that exchange safety and/or infotainment data with other vehicles, or with fixed access points, available in the network infrastructure. User mobility and the intermittent on-the-road connectivity are the main issues that ICN has to address in vehicular scenarios. For instance, safety messages must be diffused in broadcast as soon as possible by means of ICN primitives. Some other information, instead, are cached inside a vehicles until it reaches the right destination node. In this latter scheme, namely store-and-forward strategy, networking functionalities are frozen for a given time interval, until the device reaches a strategic position that helps or optimizes the dissemination of the cached content.

  • Delay- and disruption-tolerant network (DTN) This scenario focuses on a fragmented network where nodes experience intermittent connectivity. It includes two key examples: opportunistic content sharing (i.e., mobile devices can establish an opportunistic link for sharing data) and dissemination/retrieving of information aftermath a disaster. Through name-driven networking primitives, caching, and store-and-forward schema, ICN could offer a strong resilience against connectivity issues. Nevertheless, depending on the application and its QoS constraints, it is important to understand how, where, and when data have to be delivered into the network.

  • Internet of Things (IoT) This scenario envisages the communication among low-power constrained devices, which are pervasively distributed in the environment. Information redundancy is typical of such environments where multiple nodes generate the same data, which can be identified by the same name. ICN networking primitives could route the data request toward the most suitable device (e.g., the closest or the one which has more power), so reducing the overall network energy consumption.

  • Smart city Due to the increment of the number of people living in urban environments, a Smart City represents a challenging scenario where addressing ubiquitous and secure applications in many domains (e.g., e-government and public administration, intelligent transportation systems, public safety, health care, building and urban planning, smart metering). In line with the previous use cases, ICN already offers networking primitives for supporting efficient data dissemination, mobility, security, and QoS. However, in this scenario, scalability and heterogeneity are the major issues that should be addressed.

In summary, the definition of baseline scenarios would effectively drive researchers and industries to find the place where designing and deploying advanced applications based on the promising ICN capabilities.

2.2 Pioneering use cases emerging from international projects

Following the direction already undertaken in the IRTF standardization community, the European Union (EU) is devoting constant efforts to conceive innovative platforms and communication architectures that (1) enable advanced and effective services in different application domains; (2) make use of ICN primitives for reaching better system performances; and (3) provide valid answer to current social challenges. ICN is going to be deployed in several pioneering use cases. To this end, different founding programs (including EPSRC, FP7, and H2020) are supporting the integration of competences and capabilities spread out among different academic entities and companies. A similar initiative was born in the United States (US), where the National Science Foundation (NSF) promoted the continuation of activities in the NDN project.

In line with the work already done in the past by other projects, COMIT (EPSRC COMIT Project https://www.ee.ucl.ac.uk/comit-project/) and INTENT (H2020 INTENT Project, http://cordis.europa.eu/project/rcn/188247_en.html) projects still follow general themes more related to architectural aspects. Both of them, in fact, are going to investigate novel strategies (with particular attention on caching and routing schema) that improve the content dissemination in large-scale networks. Differently, the POINT project targets the design of an innovative communication platform based on the “IP over ICN” approach (H2020 POINT Project, https://www.point-h2020.eu). Stating from the PURSUIT architecture, it intends to implement protocols already standardized for the current Internet (like IP, TCP, HTTP, and CoAP) on top of ICN primitives. At the time of this writing, the killer application considered by the POINT project is the provisioning of streaming services (and hence the dissemination of multimedia contents).

Other projects, instead, are going to consider more complex scenarios covering Smart Grids and Smart buildings, smart transportation, disaster recovery and children safety, content dissemination in social networks, and health care. More details are discussed in what follow.

2.2.1 ICN for smart grids and smart buildings

To notion of “Smart Grid” has been introduced for identifying modern electrical grids where the generation and the transportation of the electricity, as well as the interaction between suppliers and consumers, are continuously monitored and automatically controlled through ICT technologies. In particular, to ensure efficiency, reliability, and the sustainability of the production and distribution of the electricity, actors belonging to a Smart Grid must always interact each other for exchanging a rich set of information. In this challenging scenario, ICN could significantly support an efficient data dissemination process, while ensuring secure, resilient, scalable, and flexible features, together with the satisfaction of QoS requirements.

The C-DAX project fully matches this vision and it is working for designing an innovative ICN-based communication platform for the Smart Grids that supports a heterogeneous set of coexisting monitoring applications (FP7 CDAX Project, http://www.cdax.eu). In particular, C-DAX is investigating three use cases, which map the most important applications available in a Smart Grid:

  • RTU/IEDs at distribution substations In a Smart Grid, Remote Terminal Unit (RTU) and Intelligent Electronic Device (IED) are installed in each substation for measuring its activity. Data are periodically captured, sent to remote SCADA systems, and properly processed. The SCADA system is in charge of automatically controlling operations of actuating elements, as well as generating alarms when some kind of system faults is detected.

  • Pervasive synchrophasor deployment at medium voltage level A synchrophasor is attached to the distribution grid for providing phasor and frequency measurements of both voltage and current. Such data are collected with a high rate (i.e., 50 or 60 frames per second) and processed, in real time, for supporting optimal voltage control, line congestion control, fault detection and localization, post-fault management, local load balancing, and management of grid losses applications. In this case, the C-DAX platform offers a scalable and resilient communication infrastructure able to timely delivery the high volume of synchrophasor measurements, collected from geographically dispersed locations.

  • Retail energy transactions This use case considers the interaction between energy consumers and suppliers. By matching consumer demands and supply offers, it handles pricing negotiation and power rebalancing services.

The core of the C-DAX platform is a cloud infrastructure that interacts with other actors of the Smart Grid by using ICN primitives. All the data produced into the system are identified by a unique name, classified in topics, and disseminated through publish/subscribe mechanisms. Once a new content is generated, it is sent to the C-DAX cloud platform and delivered toward the node responsible for the considered topic. A data consumer sends an interest for a specific topic to the C-DAX cloud platform and retrieves generated data from a specific node of the cloud (i.e., the one responsible for topic). This operation is done without considering the location of data producers.

The integration of ICN primitives into the smart building for providing automation and monitoring services is under investigation in the NDN project (FIA-NP http://www.nsf.gov/awardsearch/showAward?AWD_ID=1345318). Differently from the most of available solutions based on the TCP/IP protocol suite, the NDN project is trying to handle the interaction among devices available in a smart building through ICN primitives. Among the most valuable benefits they propose there are: name-based communication, data-centric security, in-network caching, and native support for user mobility and one-to-many communications.

2.2.2 ICN for smart transportation systems

In line with EU ambitions, Smart, Green and Integrated Transport is nowadays considered as a key aspect to address by the 2020. From one side, Intelligent Transportation Systems (ITS) need to be conceived for reaching a smart and efficient management of both transport means and traffic. From another hand, it is needed to satisfy some critical requirements, like the minimization of the impact of transport systems to both climate and environment, the increment of the quality of life of citizens, and the reduction of energy consumption and carbon footprint.

This theme is considered in the BONVOYAGE project, which aims at designing, developing, and testing a platform that would optimize multimodal and door-to-door transport of passengers and goods (H2020 BONVOYAGE Project, http://bonvoyage2020.eu). The term multimodal is used to indicate that the platform jointly integrates travel information coming from different transport operators, thus offering unified planning and ticketing services. The keyword door-to-door, instead, is used to remark that the goal is to find a (multimodal) travel route able to connect any couple of geographical points (without leaving uncovered, for example, the path from the passengers’ home and the nearest train station).

Entities involved into the BONVOYAGE platform are: users (i.e., passengers and goods), transport operators, travel operators, sensors disseminated along streets, parking, airports, etc., and all the entities implementing the Intelligent Transport Functionalities (like the multiobjective optimization algorithm that calculates optimal multimodal travel itineraries starting from the status of transport systems and user requests). Their interaction is supported by an innovative information-centric communication network, namely Internames. Proposed in its preliminary formulation in Blefari-Melazzi et al. (2014), Internames enables name-to-name communications (natively supported by ICN) in heterogeneous systems made up by different realms working with various networking protocols. With Internames, data coming from data centers, sensors, vehicles, goods and people on the move, as well as any entities belonging to the BONVOYAGE platform, are identified by a specific name. Hence, according to the ICN paradigm, content dissemination completely turns around names, without the constraint of a static binding between information and location. Of course, Internames will be significantly extended during the project in order to better support the interaction among involved actors and to efficiently enable the collection and the dissemination of required data, while satisfying all the requirements of offered travel services. To this end, ICN primitives will be used to provide both request/response and publish/subscribe applications, routing and caching strategies will be properly conceived for optimizing the delivering of information among entities connected to different network realms and store data in strategic place of the system according to the QoS requirements of the corresponding application.

The use cases elaborated in the project involve two cities, namely Bilbao and Oslo, and take into consideration both passengers and goods, as well as different means of transport available in both within and between the cities (like private and public vehicles, fully electric vehicles, trains, undergrounds, busses, trucks, electric bicycles, and bicycles). In particular, two different scenarios have been initially envisaged:

  • Travel of passengers A user releases a travel request, which contains details about source address, destination address, maximum trip duration, number of travelers, environment sustainability, preferred mode of transport, and willingness to walk. The platform processes this request, together with an high number of input parameters, that are status of multimodal transports (e.g., coverage, time tables, routes, schedules), real-time measurements (e.g., traffic conditions, weather forecasts, temporary speed limits, available space and weight to complete the load), user feedbacks (e.g., level of quality experienced by each user during the travel), and user profile (e.g., the history associated with a specific user). Then, a set of travel solutions is sent back to the user. Each proposal may indicate fares restrictions and rules, total travel time, environment impact, and other information related to travel. Now, once the user makes his choice, the system will manage ticketing operations. The selected travel route can change during the time. In fact, the BONVOYAGE platform continuously collects data from the system (for example, it identifies route congestion episodes and realizes the changes in the cost of the tickets). Based on this information, the platform may propose some travel adjustment to the user and modify the travel plan if needed.

  • Goods transportation In this scenario, the BONVOYAGE platform will gather all relevant information about transport carriers’ profile (e.g., usual itineraries, fleet characteristics, and tariff conditions). Companies and individual users may ask for a transportation service by issuing a request containing information about origin and destination, day, type of transportation, weight of the package, etc. The platform will provide multiple travel options. The user will select its favorite offer and it will be informed when the package is delivered. Similarly to the previous example, dynamic travel adjustments are supported too.

2.2.3 ICN for disaster management and children safety

The provisioning of advanced services could be very hard to accomplish, especially in fragmented networks where devices experiences an intermittent connectivity. Such extreme conditions occur when the normal behavior of existing communication infrastructures is interrupted aftermath of a disaster or a user occasionally meets another device and decides to exchange data by using a direct wireless link. In the literature, such kinds of network scenarios are classified as Delay- and Disruption-Tolerant Networks (DTNs) (Khabbaz et al. 2012). In general, DTNs can be used to support both interplanetary and terrestrial communications. However, when focusing the attention on the terrestrial case, they can be adopted for offering minimal connectivity during emergency situations (e.g., earthquakes), as well as opportunistic content sharing.

ICN may support data dissemination in DTN systems: advanced routing strategies and caching mechanisms make the communications resilient against user mobility, system failure, and intermittent network connectivity. This vision is shared by GreenICN (FP7 GreenICN Project, http://www.greenicn.org) and UMOBILE (H2020 UMOBILE Project, http://umobileproject.eu) projects, which are investigating the possibility to integrate ICN primitives in DTN networks, thus reaching common framework for handling disaster management and children’s safety.

GreenICN focuses on disaster recovery episodes and considers the following use cases (FP7 GreenICN Project, http://www.greenicn.org):

  • Disaster scenarios With reference to the fragmented network, with only intermittent connectivity, the project aims at providing large-scale and energy-efficient delivery of disaster information. Particular attention is dedicated to the design of advanced routing and caching mechanisms to use in fragmented/disrupted mobile networks.

  • Video scenarios In this case, the reference topic is the distribution of video content through scalable and efficient dissemination approaches. Nevertheless, developed schemes are quite general and they can be applied also in non-disaster environments.

At the same time, UMOBILE aims at working on prevention services (H2020 UMOBILE Project, http://umobileproject.eu). Reference use cases it considers are:

  • Children safety prevention The main idea is that children have a smartphone (or any kind of wearable device), which occasionally exchange data with the network. For example, a message can be generated when the child arrives at school, when he meets a friend, when he walks within a supermarket, etc. The position and the social behavior extracted by these information can be processed, in real-time, for identifying abnormal situations. Hence, context-aware alerts can be generated and disseminated in specific trusted circles.

  • Prevention of disaster/emergency situations In this use case, personal and public data are occasionally disseminated among users and network infrastructures. Collected information can be used to identify anomalies, as well as to aid disaster prevention measures.

2.2.4 ICN for content dissemination in social networks

Today, Online Social Networks are the most popular applications and they are changing the way data are consumed in the Internet.

In this context, the eCOUSIN project is developing a novel social-aware network architecture with built-in content dissemination functionalities, based on the social-content interdependencies (FP7 eCOUSIN Project, https://ecousin.cms.orange-labs.fr). In particular, such an architecture integrates a high performance distributed tool for collecting necessary data to study and model the social-content interdependencies, along with powerful algorithms that exploit social information for placing and delivering contents in an optimized manner. While focusing on mobile environments, eCOUSIN investigates the following use cases:

  • Content placement In an Online Social Network, data published by a given user may be requested by its followers. Hence, the geographical distribution of followers can highlight where a given (typically mid or low popular) content is more likely to be consumed. Such information can be collected by the Online Social Network and shared with Content Providers, Content Delivery Network operators, and Internet Service Providers. In this way, they can place content in the appropriate locations (e.g., data center or cache node) near to potential consumers. As a result, the end user would benefit from this innovative strategy because it will experience lower delays (i.e., thus enjoy a better Quality of Experience) when accessing to the content.

  • Time-unconstrained content delivery This use case envisages the possibility to pre-fetch social contents that may be of interest of a given user when he is connected to a high capacity network. For example, a user turns on its smartphone in the morning and connects it to his own Wi-Fi network. An application installed on the smartphone recognizes the current user’s context, retrieves information on potential contents to be pre-fetched, and download such interesting contents even if the user did not explicitly yet expressed an interest for them. As soon as the user leaves his home, his smartphone will be connected to mobile network (i.e., 3G or 4G). Now, when the user decides to access to favorite contents from the Online Social Network, he will not need to exchange a lot of data with the mobile interface. The content, in fact, is already available on his smartphone. Also in this case, the user experiences lower delays and high levels of Quality of Experience. Of course, pre-fetching operations start again when the user will come back to home.

  • User-generated content delivery A user may store his user-generated contents (like photos, videos, etc.) in a dedicated device (like Smart TV, DLNA server, etc.) and share them through the Online Social Network. A follower interested to that contents will fetch them directly from the storage device, i.e., without needing to use external and high-loaded platforms (like YouTube for video contents).

2.2.5 ICN for health care

The healthcare use case is taken into account in the PAL project (founded by the EU) and the NDN project (founded by the NSF in the USA).

The PAL project studied the possibility to implement advanced healthcare applications in current and future communication infrastructure (EPSRC PAL project, http://palproject.org.uk). The main goal was the definition of a pervasive and seamless healthcare service that offers (1) self-monitoring, self-management, prevention, and treatment capabilities, (2) enables social inclusion, and (3) eases its usage for patients with some ability constraints.

The main use case considered in the PAL project is:

  • Monitoring of a patient In this example, a patient, exposed to a heart surgery in the past, uses the PAL platform for monitoring his activity (including his physiological state and heart condition). As soon as the patient has an illness (e.g., he faints at home), the platform immediately alerts the medical team and provides all the information needed to better interpret the episode. Other medical data stored in the hospital where he had surgery are delivered too.

In PAL, the communication among all the involved actors is performed through a publish/subscribe mechanism, e.g., enabled with the PURSUIT architecture. In particular, an ICN-based middleware is introduced for offering asynchronous and many-to-many communications, as well as information-centric routing operations.

Recently, also the NDN project started working on the healthcare use case, by choosing the Open mHealth platform as a network environment where deploying and validating ICN primitives based on the NDN architecture (FIA-NP http://www.nsf.gov/awardsearch/showAward?AWD_ID=1345318). Open mHealth was born as an ecosystem of sensing, storage, analysis, and user interface components that exchange health information for supports medical discovery and evidence-based care services. Its implementation over NDN may benefit for several features, which are: (1) identification of contents and services through names rather than hosts and IP addresses, (2) provisioning of simplified request/response interaction among data consumer and data producer, (3) in-network caching mechanisms enabling a distributed storage of health information, useful for reaching fault tolerance and load balancing in large networks, (4) data-centric security, and (5) native support for user mobility and one-to-many communications.

2.3 General considerations

A big picture on goals and use cases targeted by all of the aforementioned projects is provided in Table 2. To demonstrate the perfect alignment with respect to standardization activities carried out in the ICNRG working group, the relation between considered applications and baseline scenarios presented in Pentikousis et al. (2015) is also highlighted.

Table 2 Summary of international projects working on ICN use cases
Full size table

From Table 2, it clearly emerges that ICN is becoming a key enabling technology for supporting a very large number of advanced services, in many domains. Hence, the diffusion of ICN-based solutions in real applications may provide an extremely high impact in our society.

Now it is time to answer a novel question: is it possible to directly extend/adapt available communication technologies under the ICN umbrella, thus accelerating their penetration in the current Internet architecture or something novel is strictly required? Some preliminary answers to such a challenging question will be provided in what follows.

3 Pushing ICN into existing communication architectures

Beyond the potentiality that the ICN paradigm could offer, its deployment is not straightforward. In fact, having been designed as an alternative to IP-based internetworking, which does not care of host locations, IP addresses, and communication channels among hosts, it results a challenge to apply ICN to the current IP (v4 or v6) network architectures. Considering the impact that such paradigm would have in future user-centric networks, a lot of effort has been already put in place by the research and industrial communities to design suitable solutions for ICN deployment. As summarized in Table 3, three different approaches have been proposed so far:

Table 3 Pros and Cons of available ICN approaches
Full size table

  • Clean-Slate ICN over Layer-2 which completely replaces the IP layer and uses the data link protocols (PPP, Ethernet, IEEE802.x) to deliver data between neighbors;

  • Overlay ICN over TCP/IP which either encapsulates ICN protocol data in IP (or UDP/TCP) packet or inserts ICN protocol information using IP options;

  • ICN over SDN it leverages the Software-Defined Networking (SDN) paradigm to implement ICN.

The Clean-Slate approach follows the native idea of replacing the classical IP layer with an ICN one. Few solutions have been developed. A first one is the Blackadder, i.e., the ICN-based router prototype realized by the PURSUIT project (PURSUIT Project, http://www.fp7-pursuit.eu/PursuitWeb/?page_id=338), which can run over Layer-2 Ethernet. And the second one is CRoWN, which applies ICN into Vehicular Ad hoc Networks (VANETs), on top of the IEEE802.11p standard (Campolo et al. 2012). The ICN over L2 approach has not been widely adopted because it is not an easy viable solution: Network devices natively do not support any of the ICN innovative techniques (name-based routing, in-network caching, etc.), and a lot of work is needed for designing ICN-enabled router, as described in detail in Sect. 3.2. Finally the cost for upgrading the whole network infrastructure is not trivial at all. However, some ICN instantiations (CCNx, https://www.ccnx.org/; Zhang et al. 2014 currently provide a preliminary support for a clean-slate layer-3 protocol over Ethernet. Meanwhile, they are devolving notable research efforts to address some of the main issues arising from such kind of deployment, e.g., the fragmentation/reassembly of ICN packets that do not fit smaller-size L2 frames (Mosko 2015; Afanasyev et al. 2015).

The Overlay approach is the most popular one which has been largely investigated by the research community (Syrivelis et al. 2012; Chang et al. 2014; Nguyen et al. 2013; Chanda et al. 2013; Blefari-Melazzi et al. 2012; Salsano et al. 2013; Vahlenkamp et al. 2013; Ooka et al. 2013; van Adrichem and Kuipers 2015; Arumaithurai et al. 2014; Banjar et al. 2014). Implementing ICN over existing IP networks seems to be the straightforward solution for deploying ICN: It has the big advantage of reusing classical infrastructures, with the addition of few (new or upgraded) nodes, which support ICN functionalities. But, it has the drawback of introducing overhead, due to overlay management and encapsulation of ICN messages inside IP (TCP/UDP) protocols, as realized in CCNx (https://www.ccnx.org/), or to the definition of new IPv4/IPv6 options, e.g., as proposed in Detti et al. (2013).

The ICN over Software-Defined Networking approach leverages ICN over IP networks by exploiting SDN facilities. The different solutions available in literature are described in Sect. 3.1.

Beyond the aforementioned approaches, the last generation of programmable network devices has been playing an important role into the ICN experimentation arena. Network Processor Units (NPUs), Graphic Processor Units (GPUs), netFPGA boards are valuable tools to experiment with algorithms and architectures needed to try out unconventional and demanding packet processing workflows.

3.1 ICN over virtualized networks: a SDN-based approach

One of the main features of ICN is the separation of the functionalities which control the matching of information demand and relative supply, from the functions that deal with the forwarding of the network resources. Such approach is very similar to the one adopted by the emerging SDN paradigm, which separates control plane from data (forwarding) plane (Kreutz et al. 2015). In an SDN-based network the intelligence is centralized into a network controller, which is responsible of deciding how traffic flows will be forwarded within the network; while network devices (switches, routers) simply forward the packets, following the per-flow rules installed by the controller. By doing so, SDN simplifies network management, traditionally based on manual intervention of network administrators. In detail, it allows highly dynamic, flexible and automated (re)configuration of the network, more efficient use of network resources, and easier way for operating troubleshooting (Gheorghe et al. 2015) and debugging.

SDN has been identified as a promising approach for deploying ICN networks, because it does not always need the use of ICN capable hardware. When integrating ICN in SDN, one of the first challenges to face is “How to map the basic SDN concept of flow into ICN?” This was addressed in Syrivelis et al. (2012): Syrivelis et al. propose the adoption of a forwarding-specific identifier, which identifies a given flow and is associated with a forwarding action list in each switch. The same forwarding action list can be used for delivering different content, exchanged between the same devices. In fact, the forwarding-specific identifier represents actually the path toward destinations, rather than content names.

To combine ICN with SDN, there is need to implement the fundamental ICN functionality into SDN-enabled hardware (i.e., Open vSwitch) and thus enhance the Open Flow Protocol (ONF 2013), the SDN-de facto standard, to support ICN names, and other ICN-like functionalities (name routing, in-network caching, etc.). Several solutions have been proposed, including C-flow (Syrivelis et al. 2012; Chang et al. 2014; Nguyen et al. 2013; Chanda et al. 2013; Ooka et al. 2013) among others. Actually modifying the OpenFlow protocol does not seem to be the “shortest path” to take for deploying SDN-based ICN networks. The standardization process of OpenFlow for regular IP forwarding has been and is still very slow. Thus, it is very unlikely that a future version of OpenFlow will include also ICN functionalities. Based on this assumption, NDNFlow (van Adrichem and Kuipers 2015) has proposed the use of an NDN-specific controller module and an NDN client plug-in, which can be included into the SDN architecture, without the need of upgrading any device, or changing the OpenFlow specifications.

A kind of “hybrid approach”, which combines the overlay one with the SDN-based, has been proposed by Blefari-Melazzi et al. (2012) Salsano et al. (2013). The suggested CONET (Content NETwork) framework, designed for OpenFlow networks, is also known as “integration approach”, because it suggests to encapsulate ICN packets into IP packets, by adding the content name into an IP option in the IPv4/IPv6 header. The CONET architecture includes OpenFlow switches, and ICN-enabled border nodes, able to perform name-to-location resolution, with the support of an SDN controller. In fact, even though CONET exploits IP options field, the OpenFlow protocol does not support packet match based on IP option fields. Therefore, the border nodes encapsulate the request in a new packet, and a flow identifier is embedded within the transport protocol’s port numbers. The latter are used to forward the packet within the SDN network to the appropriate locations. In detail, the OpenFlow controller performs path computation and determines on which path the data packet (i.e., requested content) will be delivered (Blefari-Melazzi et al. 2012; Salsano et al. 2013). By using a Pending Interest Table (PIT), the border node can reverse the encapsulation and send the response to the original requester. The CONET approach (Veltri et al. 2012) presents a set of shortcomings and open issues, including the need of ICN-aware border routers (running ICN software, and able to perform en/decapsulation), and a new transport protocol, among others.

A team at the NEC laboratories in Germany, in the context of the GreenICN project (FP7 GreenICN Project, http://www.greenicn.org), has proposed another solution (Vahlenkamp et al. 2013) able to overcome the shortcoming of Veltri et al. (2012). They do not use any IP options, or modified transport protocol. ICN messages are encapsulated into UDP or TCP packets, and a Message ID, used for forwarding decision, is encoded in the address fields of the IP header. By doing so, network devices only need to support IP forwarding, and they do not require any ICN protocol knowledge.

While the majority of the research community has tried to exploit SDN for implementing ICN, Arumaithurai et al., for the first time, have proposed to take the opposite path, i.e., to exploit ICN for improving SDN performance, in terms of network management, and service chaining (Arumaithurai et al. 2014). On the same line, the advantages, which ICN can offer for interconnecting several controllers in a multidomain SDN network, have been investigated in Banjar et al. (2014).

Even though the implementation of ICN with SDN has been investigated in several works, there are still several challenges to face: routing computation, path labeling to discover the network topology and to locate data in the network, route assignment to route request for data objects. Mechanisms for caching objects in the network along the path also need more investigation to deliver them more rapidly to an increasing number of users. The distribution of storage capabilities across the path with content routing algorithms remains an open issue. Finally, the integration of SDN concepts in the ICN architecture should also take care of all the scalability problems that affect conventional SDN solutions (Yeganeh et al. 2013).

Despite the advantages and disadvantages, which each suggested scheme has, most of the works on ICN implementations focus on how to implement a specific ICN architecture. However, different ICN architectures employ different transmission techniques and packet formats, which make difficult the coexistence and interoperability of different ICN networks (problem which will be for sure faced in future 5G networks). Thus, there is need for a unified framework (Liu et al. 2013), which allows several SDN-based ICN deployments to interoperate together.

3.2 Designing ICN routers

Nowadays a few common cardinal design principles have been identified across the ICN architectures emerged thus far. Those principles yielded a set of requirements for the design of a prospective ICN-enabled network device. Thereby, some preliminary investigations outlined a list of technical challenges to overcome in order to achieve this goal. These open issues range from the design of novel architectures based on current technologies to the design of new algorithms to run more complex packet processing operations at line speed. This section aims to provide an overview of the results achieved so far in the design of an ICN router and of the pending challenges that the research community still struggles to address.

This overview starts with the description of the workflow followed to process network packets inside an ICN router. The workflow described reflects the one proposed into the NDN architecture (Zhang et al. 2014), because, in the humble authors’ opinion, it mimics all the main building blocks that a future ICN router should feature. However, the authors have striven to outline general guidelines whose applicability could be straightly mapped to different ICN architectures.

Later on, the section illustrates the technical challenges to design every router’s component needed to execute the described workflow, which have also been summarized in Table 4.

Table 4 Challenges and approaches for ICN router components
Full size table

3.2.1 Processing workflow for an ICN packet

In the context of the NDN architecture, a request for a content is called Interest packet and a response containing the requested information is called Data packet. Hereafter, they are called simply Interest and Data. Whenever an Interest is issued, the network nodes forward the request according its name to one or more potential sources for the requested content. The routers make forwarding decisions according to their forwarding tables, wherein information about content availability in the network has been previously disseminated, e.g., by means of a routing protocol (Narayanan et al. 2012; Wang et al. 2012; Hoque et al. 2013). Once the content is hit somewhere in the network on the path toward the content source, Data may travel back to the original requester through the state left into routers by Interests.

To achieve the aforementioned workflow, the NDN architecture envisions routers able to execute in-network cache of network packets, per-packet data plane updates, and forwarding of Interests by names. Inside an NDN router, these three functionalities are performed, respectively, by a Content Store (CS), a Pending Interest Table (PIT), and a Forwarding Information Base (FIB).

The basic workflows for processing Interest and Data are depicted in Fig. 1. When an ICN router receives an incoming Interest (Fig. 1a), firstly it checks whether it has a copy of the requested content into the CS. If so, then it gives it back as Data. If the lookup into the CS fails, then the router checks whether it has already processed a similar Interest, that is, if it still has a pending request to serve into the PIT. If the router has a PIT entry for this content name and the new Interest has been received from the same interface of the previous one, then it drops the new one which is a kind of duplicate. On the other hand, if the router has a PIT entry for this content name and the new Interest has been received from a different interface, then the router updates the PIT entry to include that the Data have to be forwarded back to one more interface. Finally if neither the router has a copy of the content into the CS nor it has a PIT’s entry for such Interest, then it looks up the FIB to search for an outgoing interface to forward this Interest, if the router does know any.

Fig. 1
figure 1

Processing workflows for a Interest packet, b Data packet

Full size image

When a Data is received, the workflow is different as depicted in Fig. 1b. Once a Data is received, first the router checks the PIT to see whether it has previously issued a request for such Data or the reception has been unsolicited. In the latter case it drops the packet. In the former case, the PIT stores a list of the incoming interfaces to which to forward the Data back. Thus the router forwards the Data according to the PIT entry information and it stores a copy of such Data into the CS.

3.2.2 In-network storage

The term in-network storage refers to the capacity of routers to store network packets while processing them. The stored packets can be used later by the router to serve further request for the same content, so reducing the number of requests forwarded upstream and the overall time needed to fetch a content from the network.

Several terms have been either borrowed or coined to refer to such component. In the NDN slang, this component is the CS. However, the CS is a component envisioned by almost all the ICN proposals. Therefore, the design hints illustrated in this section have a universal value, and the same holds for the challenges.

In literature several researchers have sorted out the requirements to design a content store for an ICN device (So et al. 2013; Perino and Varvello 2011). Hereby the authors report the community’s findings and a description of the open issues to address.

A content store usually should be composed of two modules, a smaller index table that keeps track of stored Data, and a bigger packet store, where Data are stored. The reason to split this functionality is mainly dictated by speed requirements. The index table can be built upon fast on-chip memories, e.g., SRAM or RLDRAM, because those memories have lower access times, e.g., respectively, ~5 and 15 ns. In this way, a router could quickly check the index to verify that it has a content stored into the CS, in order to access the slower memory only when there is a high chance that the content is stored therein. The packet store can be implemented using slower memories, e.g., DRAMs with access time of ~50 ns. Today’s commodity network equipment is usually equipped with either 4 GB or 8 GB of DRAM memory, and with less than 100 MB of SRAM memory. Theoretical studies in Arianfar et al. (2010), Perino and Varvello (2011) and preliminary results in Perino et al. (2012) suggest that those memory sizes are sufficient to implement a content CS of 10 GB on DRAM memory that could serve a traffic load of several tens of Gbps.

Usually the index is computed starting from the Interest name using a hashing technique. As outlined in So et al. (2013), the trade-off in the choice of the hashing technique is dictated by two main points: computational load of the hash function and security of generated hashes.

The former refers to the cost of computing the hash of the name to obtain the value to check against the index table. The latter refers to the collision resistance property of the hash function, which is crucial both to improve the worst-case performance of the lookup operations needed to fetch the right memory record and to avoid malicious cache poisoning attacks. In general, the following criteria are followed to design the hash table for a CS: (1) lightweight secure hash function to compute the index; (2) chained hash tables to reduce the probability of collisions into the packet store.

The bottom line of the state-of-the-art works is that a CS for an ICN device is doable using current memory technology and indexing schemes. Nevertheless, the devised schemes fit into a global design that does not perform more the several tens of Gbps and that offers a few GB of storage. The limited size of the content store could not be the main issue, according to some recent findings in the literature (Anand et al. 2009). On the other hand, the data rate of carrier-router’s optical links could hinder the deployment of such devices beyond the enterprise router domain (So et al. 2013; Perino et al. 2012).

For sake of completeness, it is worth mentioning that there are more design choices influencing the low-level design of the CS. For example, the cache replacement policy, namely the decision process leading the eviction of a CS element to make free space for an incoming Data packet, could require additional information to be stored either in the index table or in the packet store to help the decision process. However, such additional design choices can be tuned once an architectural baseline has been identified and assessed.

3.2.3 Per-packet state update

The ICN router has to keep track of forwarded Interests in order to route Data back to the content requester. Therefore, an ICN router maintains in memory a list of pending Interests it has forwarded but that have not got a Data back yet. This status stored by ICN routers provides more valuable functionalities beyond the simple symmetric routing. In fact, the ICN network can use the status scattered all over the network devices to realize functions like loop-free multipath, Interest aggregation, multicast data delivery.

According to current state of the art (Varvello et al. 2013; Dai et al. 2012; Yuan et al. 2012) the PIT should contain entries holding at least the following four information: the name, the expiration time, the list of incoming interfaces, and the list of nonces. The name refers to the name of the Interest that creates the entry into the PIT. The expiration time indicates for how long the entry will be kept into the PIT. The list of incoming interfaces aggregates Interests for the same content from different incoming interfaces that have to be tracked in order to perform the multicast data delivery. The nonces are random identification numbers attached to Interests to distinguish valid Interest retransmissions from looped Interests. The nature of a PIT entails the following design principles:

  • the PIT size is a function of the traffic characteristics in terms of content popularity distributions and of frequencies of requests;

  • the PIT does have to efficiently support many update and insert operations (deletion can be lazy performed);

  • the PIT needs to perform fast exact match operations on variable length content names.

The open challenges in the design of such component are mainly related to the placement inside the device, the size, and the data structure.

The placement refers to where to install this component inside the router, on the ingress line card, on the egress line card, or on both. Perino et al. (Varvello et al. 2013) provide a good overview of the cons and pros of any placement and they also propose a “third-party” placement schema that solves the problems of the other ones, trading up additional switch fabric. Their approach essentially advocates to delegate the PIT function to a third line card that is neither an ingress one nor an egress one, but an additional card deployed for such purpose, so switching every packet two times instead of one before forwarding it.

Many questions arise to size a PIT. What is the frequency of Interest that this router will receive once deployed? How does the popularity of contents will dynamically grow and shrink the memory requirements? What is the expected lifetime of a PIT entry? To answer the first question, approaches seen in literature tend to design solutions robust to deal with the worst combination of factors. This translates to workload composed of smallest Interests holding the full bandwidth of a link, so to generate the bigger amount of requests to serve per interval of time. As regards the second question, research works have so far converted traffic generated by used Internet applications taken out of official traces to generate credible ICN workload (Dai et al. 2012; So et al. 2013). As regards the last question, the most appropriate metric to consider while dimensioning the PIT has been so far the average Internet round-trip time (Perino and Varvello 2011).

As regards the data structure, three different solutions have been proposed so far. The first category of approaches suggests to use Name Prefix Trie (NPT) as logic structure to represent the PIT. Optimizations of the NPT have been designed to reduce the size of the three and to improve the performances of the insert/delete/update operations. One of such improved NPT, namely Encode NPT (ENPT), has been proposed in Dai et al. (2012). The second category uses Counting Bloom Filter (CBF). CBF enables a quick deletion by means of a counter per bit and further it compresses the amount of information to store. However, CBF loses some information through the compression, so that it cannot support anymore some PIT’s essential features likewise the loop detection or the expiration of old entries. Finally, as all the bloom filter techniques, it suffers from the false-positive issues that might pollute the PIT. The third category of approaches uses chained hash tables (HTs). Chained HTs have been quite appealing for the PIT design, because of their well-established reputation as solutions for high-speed packet processing (Kirsch et al. 2010). This last class of solutions mainly stores a fingerprint of the index into SRAM memories and they aim to a constant number of off-chip DRAM accesses.

3.2.4 Forwarding information base for prefix names

An ICN router forwards network packets according to the name of the content those packets ask for. In the NDN architecture, a router has a Forwarding Information Base (FIB) data structure to perform such operation. The FIB of an ICN router looks like similar to the IP’s one, but indeed it has two big differences. First, an ICN FIB stores content name as key for its records, instead of IP network prefixes. Second, an ICN FIB can have multiple output interfaces stored into its records. In Fig. 2, an IP’s FIB and an ICN’s FIB are compared side by side.

Fig. 2
figure 2

Forwarding Information Base (FIB) for a an IP router, b an ICN router

Full size image

There are two main issues related to the design of such component: the size of the table and the matching algorithm. The first one arises from the observation that using content names in place of network prefixes implies to store a bigger number of records into the FIB. In particular, this issue hinders those router located into the Internet backbone that stores a large number of destinations. On one hand, today’s BGP tables size of backbone routers hold between 106 and 105 entries (BGP Analysis Reports: http://bgp.potaroo.net/index-bgp.html). On the other hand, the set of web contents to be likely addressed by the future ICN architecture, those are in the order of 1010 (Daily Estimated Size of the World Wide Web http://www.worldwidewebsize.com/). Those contents could be aggregated exploiting the hierarchical nature of the names used by the web. However the aggregation performed on the basis of common name prefix will reduce the number of entries of some orders of growth, but the reduction will not be enough to fit the FIB into current technology.

Some proposals have emerged to overcome the issue of the FIB’s size. As architectural workaround, Blefari-Melazzi et al. (2012) have proposed to store a subset of routes into the FIB of a router and to rely on a Name Resolution System any time a route is not part of the installed subset. As low-level design feature, in Caesar, Perino et al. (2012) have designed a content router that splits the FIB in parts and assigns those to the line cards according to the prefix names. Every time a line card receives an Interest, it checks whether it is in charge for processing such prefix name. If this is not the case, the line card forwards the Interest to the line card responsible of Interests with that content name.

As regards the matching algorithm, FIB’s records are matched through Longest Prefix Matching (LPM) on name components. Performing such match fast is extremely challenging, because of the unbounded length of the name that is further made of an unbounded number of variable length components. The approaches proposed for the LPM problem into an ICN router can be classified in three categories: hash-table-based, bloom-filter-based, trie-based. A concise overview of the state of the art is available in Yuan and Crowley (2015), wherein the author proposed a binary search of hash tables to have a worst-case log(k) hash-table lookups to match a name with k components, improving on other hash-based techniques that achieve worst-case performance linear in k. Moreover, there exist hybrid approaches that strive to combine the strength of different techniques to overcome their weaknesses. For example, Quan et al. (2014) propose a dual-step approach using first, smaller bloom filters so reducing the false-positive rate, and then, small-scale tries so reducing the memory requirements, to speed-up the lookup.

4 Conclusions

This paper presents a summary of the state of the art on information-centric networking (ICN) research, with a major emphasis on use cases and open technological issues. First of all, the ICN paradigm has been introduced as a promising candidate for reconstructing the Future Internet. Through flexible and efficient mechanisms for content dissemination, in fact, ICN will overtake all the drawbacks affecting the current Internet, while being able to ensure security and trust, resilience to system failures, data availability, and the support for both mobility and multicast communications. Based on this premise, the entire paper aims at demonstrating that ICN does not represents, today, just a buzzwords: it is, instead, a consolidated research topic born more than 10 years ago and involving a very broad international research community.

At the time of this writing, the ICN concept is at the basis of many concrete network architectures, which include DONA, NetInf, PURSUIT, SAIL, CONVERGENCE, NDN, MobilityFirst, and COMET. In addition, the worldwide research community already demonstrated and quantified the performance gain obtained when ICN is leveraged for handling the dissemination of contents with heterogeneous levels of popularity and the provisioning of multimedia services. Nevertheless, apart from these interesting findings, the need to further access ICN potentialities in more complex and real use cases is growing day by day.

In the Internet Research Task Force context, the recently chartered Information-Centric Networking Research Group, namely ICNRG, provides a step ahead in this direction. For the moment, ICNRG classified the most important ICN-based solutions, formulated the ICN problem statement and the related research challenges, and defined standardized methodologies to evaluate the performance of ICN architectures in baseline scenarios. In addition, ICNRG clearly stated that ICN could offer enormous advantages in several domains, including Social networking, real-time communication, mobile networking, infrastructure sharing, content dissemination, vehicular networking, Delay- and Disruption-Tolerant Networks, Internet of Things, and Smart City domains. Accordingly, ICN principles should be translated in reality as soon as possible. Some international projects, like PAL COMIT, INTENT, GreenICN, C-DAX, eCOUSINE, BONVOYAGE, UMOBILE, POINT, and NDN-IP (note that most of them were recently started), completely share this vision. They, in fact, found in the ICN concept the key enabling factor of advanced services in Smart Grid and Smart Building, Smart Transportation, disaster management, children safety, social networks, and health care.

From this resulting big picture, it emerges that society can benefit from the adoption of ICN but before this myth becomes reality it is necessary to concentrate the efforts in ICN research. First, there are too many different ICN flavors that would hardly interoperate so that, if the research community keeps going in this direction, none of the available architectures will reach a stable degree of maturity in next years. Second, quite a few use cases are being formulated on top of ICN, with more or less pronounced assumptions on the underlying communication infrastructure. Third, even if the ICN over Software-Defined Networking is currently assumed to be a viable strategy to drive the deployment of ICN architectures, there are still many open issues (which refer to packet forwarding, caching mechanisms, security, and computational complexity of networking operations in real devices), which surely depict the main research directions to be addressed in the future. Any activity in this context should start from the belief that the number of contents to be likely addressed in the future is extremely high (e.g., in the order of ten billions), as well as their availability could be heavily dynamic.

An effective packet forwarding algorithm should be able to build dynamic routing paths in very large-scale networks, while ensuring high-speed operations (i.e., fast table lookup of variable length names, efficient data structures to store millions/billions of names, and fast packet processing). Caching solutions should optimize the storage of copies of a given contents in strategic places (i.e., close to potential data consumers, in more powerful network devices). The secured access to remote contents is another big challenge to consider. In the current Internet architecture, the implementation of access control policies requires the establishment of an end-to-end secured (and authenticated) communication link between data consumer and service provider. In order words, they are natively based on a host-centric communication model. ICN primitives and the presence of cached copies of the same data, instead, make this approach not more feasible. For this reason, routing and caching mechanisms should be properly re-invented to also integrate emerging attribute-based encryption and access control schemes. Finally, any complex solution may involve high computational load requirements. Unfortunately, it is not uncommon to discover ICN-related research studies that do not account for hardware constraints: As a matter of fact, name-driven networking primitives risk to incur a not negligible lookup overhead whatever the deployment strategy (i.e., clean state or overlay). Therefore, a reality check is much more than welcome before proposing novel approaches.