A Survey of Information-Centric Networki

This article has been accepted for inclusion in a future issue of this journal.
Content is final as presented, with the exception of pagination.

IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION 1
A Survey of Information-Centric
Networking Research
George Xylomenos, Christopher N. Ververidis, Vasilios A. Siris, Nikos Fotiou, Christos Tsilopoulos, Xenofon
Vasilakos, Konstantinos V. Katsaros, and George C. Polyzos
Abstract—The current Internet architecture was founded upon The tremendous growth of the Internet and the introduction
a host-centric communication model, which was appropriate for of new applications to fulfill emerging needs, has given rise
coping with the needs of the early Internet users. Internet usage to new requirements from the architecture, such as support for
has evolved however, with most users mainly interested in ac-
cessing (vast amounts of) information, irrespective of its physical scalable content distribution, mobility, security, trust, and so
location. This paradigm shift in the usage model of the Internet, on. However, the Internet was never designed to address such
along with the pressing needs for, among others, better security requirements and in order to help it “evolve” a vicious cycle
and mobility support, has led researchers into considering a of functionality patches began appearing, such as Mobile IP.
radical change to the Internet architecture. In this direction, we Most of those patches increased the complexity of the overall
have witnessed many research efforts investigating Information-
Centric Networking (ICN) as a foundation upon which the Future architecture and proved to be only temporal solutions [1]. In
Internet can be built. Our main aims in this survey are: (a) addition, many current and emerging requirements still cannot
to identify the core functionalities of ICN architectures, (b) to be addressed adequately by the current Internet. This has
describe the key ICN proposals in a tutorial manner, highlighting raised the question of whether we can continue “patching over
the similarities and differences among them with respect to those patches,” or whether a new clean-slate architectural approach
core functionalities, and (c) to identify the key weaknesses of ICN
proposals and to outline the main unresolved research challenges for the Internet is actually needed [2]. Along these lines, a
in this area of networking research. research community has been formed which, having identified
the limitations of the current Internet, is discussing the key
Index Terms—Information-Centric Networking, Content-
Centric Networking, Named-Data Networking, Future Internet, requirements and objectives of the Future Internet, and is
Publish-Subscribe, Internet Architecture proposing new architectures and paradigms to address them.
In this context, Information-Centric Networking (ICN) has
I. I NTRODUCTION emerged as a promising candidate for the architecture of
HE CURRENT problems of the Internet are a natural the Future Internet. Inspired by the fact that the Internet is
T consequence of its architecture, which was designed to
address the communication needs of a time when a network
increasingly used for information dissemination, rather than
for pair-wise communication between end hosts, ICN aims to
was needed for sharing rare and expensive resources, such as reflect current and future needs better than the existing Internet
peripherals, mainframe computers, and long distance commu- architecture. By naming information at the network layer, ICN
nication links. The basic requirement from the Internet at that favors the deployment of in-network caching (or storage, more
time was merely that of forwarding packets of data among a generally) and multicast mechanisms, thus facilitating the
limited number of stationary machines, with well-established efficient and timely delivery of information to the users. How-
trust relationships. The key design principles of the Internet ever, there is more to ICN than information distribution, with
made it very simple to link new networks to the Internet and related research initiatives employing information-awareness
enabled a tremendous growth in its size. In parallel to the as the means for addressing a series of additional limitations
Internet’s growth, an unprecedented number of innovations, in the current Internet architecture, for example, mobility
in both the applications and services running on top of it, as management and security enforcement, so as to fulfill the
well as in the technologies below the (inter-)network layer, entire spectrum of Future Internet requirements and objectives.
have emerged. This is attributed to the hourglass approach Although very good survey papers exist for research in the
followed by the Internet’s protocol architecture: the network Future Internet area (e.g., [3] and [4]), due to their broad
layer forming the waist of the hourglass is transparent enough, coverage they treat ICN architectures and related research
so that almost any application can run on top of it, and efforts either sketchily or incompletely. The aim of this survey
simple enough, so that it can run over almost any link-layer is to focus on ICN and cover the state-of-the-art evenly,
technology. broadly, and at some depth. Compared to other ICN surveys
(e.g. [5] and [6]) the present survey covers in more detail and
Manuscript received March 28, 2012; revised September 30, 2012 and April
18, 2012. depth the most representative and mature ICN architectures
The authors are with the Mobile Multimedia Laboratory, Department of and approaches, instead of a subset. In addition to describing
Informatics, Athens University of Economics and Business, Athens 10434, the goals and basic concepts of the various research projects
Greece (e-mail: {xgeorge, chris, vsiris, fotiou, tsilochr, xvas, ntinos, poly-
zos}@aueb.gr). on ICN, it identifies the core functionalities of all ICN archi-
Digital Object Identifier 10.1109/SURV.2013.070813.00063 tectures and highlights their similarities and differences in how
1553-877X/13/$31.00
c 2013 IEEE
This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.
2 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION
these functionalities are implemented. Furthermore, it provides The basic assumption behind this is that information is named,
a critical analysis of the main unresolved research challenges addressed, and matched independently of its location, there-
in ICN that require further attention by the community. fore it may be located anywhere in the network [18], [19].
The structure of this paper is as follows: In Section II we In ICN, instead of specifying a source-destination host pair
provide an overview of ICN, presenting the key concepts for communication, a piece of information itself is named.
of ICN architectures and discuss the important problems An indirect implication (and benefit) of moving from the
and limitations of the current Internet that ICN attempts to host naming model to the information naming model, is that
solve. In Section III we identify the core functionalities of information retrieval becomes receiver-driven. In contrast to
all ICN architectures and then present the most mature and the current Internet where senders have absolute control over
representative ICN approaches. In Section IV we discuss the the data exchanged, in ICN no data can be received unless
similarities and differences among ICN architectures, with it is explicitly requested by the receiver. In ICN, after a
respect to the implementation of these core functionalities. request is sent, the network is responsible for locating the
In Section V, we outline the main challenges that remain best source that can provide the desired information. Routing
unresolved for researchers interested in this area of networking of information requests thus seeks to find the best source for
research. Finally, a brief summary and our conclusions are the information, based on a location-independent name.
provided in Section VI.
B. Focus on Information Delivery
II. I NFORMATION -C ENTRIC N ETWORKING :
T ERMINOLOGY, C ONCEPTS AND OVERVIEW The shift towards content-centric bandwidth-demanding ap-
plications requires the Internet to efficiently deliver massive
In this section we introduce the key concepts and principles
amounts of information and handle large spikes or surges in
of ICN and discuss how each one of them aims to address
traffic, commonly referred to as flash crowds. However, the
some of the current Internet’s problems and limitations. This
data-agnostic Internet architecture lacks native mechanisms
discussion also sets the framework for examining in detail
for handling flash crowd events and for enabling efficient
each proposed ICN architecture in Section III.
information delivery. In the current Internet, data in transit
are treated by network elements as a series of bytes that
A. Focus on Information Naming have to be transferred from a specific source to a specific
The Internet has been transformed from an academic net- destination and, as such, network elements have no knowledge
work to a global infrastructure for the massive distribution of of the information they transfer and hence cannot realize
information, with over 1 billion of connected devices [7], 1 optimizations that would otherwise be possible (e.g., smart
trillion of indexed web pages [8] and Exabytes of annually in-network caching, information replication at various points,
transferred data [7]. Users are more and more interested information-aware traffic engineering). For the Internet to fully
in receiving information/content/data1 wherever it may be exploit the existing in-network storage capabilities, it must
located, rather than in accessing a particular computer system be extended with in-network information-aware mechanisms
(host or server). However, the fact that the Internet is still for the identification and retrieval of information from its
based on an underlying host-centric communication model optimal location [20]. The emergence of such techniques at
requires the user to specify in each request not only the the application level (e.g., web caching) only confirms that
desired information, but also the specific server from which they were actually an afterthought for the Internet.
it can be retrieved from. Unless add-on functionality is used, Content Delivery Networks (CDNs) deployed as overlays,
the Internet’s native network-layer mechanisms cannot locate apply these techniques over the wide area at the application
and fetch the requested information from the optimal location layer but, especially for the case of flash crowds, the amount,
where it is hosted, unless the user somehow knows and location, and destination of traffic cannot always be anticipated
includes the optimal location in the request. In the research and the investment for having a CDN to accommodate all
community, the first ideas for shifting from the host-centric possible cases is certainly not viable, especially given the
network design to an information-centric network design were constant rise in user-generated information. Moreover, CDNs
introduced almost a decade ago in the seminal papers of Gritter typically employ network-unaware mechanisms, which lead
and Cheriton [9] (in the context of the TRIAD project [10]) to inefficient utilization of the underlying network resources.
and Carzaniga et al. [11], [12], [13]. Other works of that period Instead, an Internet-wide infrastructure supporting in-network
also realized the need for information-centric communication, mechanisms for efficient information retrieval would be prefer-
assuming however that it would operate as an overlay on top able. Recent work [21] based on empirical evidence and data
of the current architecture, based on the functionality offered analysis from Open CDNs shows that some flash crowds
by Distributed Hash Tables (DHTs) [14], [15].2 can grow too quickly for application layer dynamic resource
The ICN approach fundamentally decouples information allocation to keep up, e.g., by the CDN reallocating cache
from its sources, by means of a clear location-identity split. resources, and that the problem becomes worse when the flash
crowd is related to uncacheable (dynamic) information.
1 The terms information, content and data will be used interchangeably and
In ICN the network may satisfy an information request
with the same meaning in the rest of the manuscript, as in [6]. not only through locating the original information source,
2 Subsequent works also explored the direct application of DHTs to
information-centric communication, without an underlying routing proto- but also by utilizing (possibly multiple) in-network caches
col [16], [17]. that hold copies of the desired information (or pieces of
XYLOMENOS et al.: A SURVEY OF INFORMATION-CENTRIC NETWORKING RESEARCH 3
it). This can be accomplished without resorting to add-on, interested in information subscribe to it, i.e., they denote their
proprietary and costly overlay solutions (e.g., CDNs), since the interest for it to the network, and users offering informa-
network layer in ICN operates directly on named information. tion publish advertisements for information to the network.
ICN-based architectures see non-opaque data packets, in the Inside the network, brokers are responsible for matching
sense that these are named based on the information they subscriptions with publications i.e., they provide a rendezvous
carry. Therefore, information fragments (packets in current function. It is important to note that the publish/subscribe
terms) can be cached and retrieved easily, unlike in the terminology used in the context of ICN (e.g., [27]) differs from
current Internet where costly techniques like Deep Packet that of traditional publish/subscribe systems (e.g., [11], [12],
Inspection (DPI) would have to be used for answering requests [13], [26]). In traditional publish/subscribe systems, publish
with data/packets cached on the routers [22], [23], [24], not to involves the actual transmission of data while subscribe results
mention that DPI does not work when packets are encrypted. in receiving data published in the future, with the ability of
Moreover, by naming information, ICN allows the aggregation receiving previously published data being optional. In ICN,
of requests for the same information, thus facilitating its deliv- on the other hand, publish involves only announcement of the
ery to the corresponding destinations via multicast forwarding. availability of information to the network, whereas subscrip-
Finally, access controls (i.e., who is allowed to access which tions by default refer to already available information, leaving
data) can potentially be applied directly at the network layer, the option of permanent subscriptions (i.e., receiving multiple
since network elements are aware of what information is being publications matching a single subscription) as optional.
transferred inside each packet. The strength of the publish/subscribe communication model
stems from the fact that publication and subscription opera-
C. Focus on Mobility tions are decoupled in time and space [28]. The communica-
The addressing scheme of the Internet was designed with tion between a publisher and a subscriber does not need to be
fixed hosts in mind, since a host’s IP address must belong to time-synchronized, i.e., the publisher may publish information
the network where the host is currently attached. However, before any subscribers have requested it and the subscribers
statistics show a constantly increasing number of non-fixed may initiate information requests after publication announce-
hosts accessing the Internet, with forecasts saying that by ments. Publishers do not usually hold references to the sub-
2015, traffic from wireless terminals will exceed traffic from scribers, neither do they know how many subscribers are
wired ones [7]. Wireless and mobile devices may easily switch receiving a particular publication and, similarly, subscribers do
networks, changing their IP address and thus introducing new not usually hold references to the publishers, neither do they
communication modes based on intermittent and, possibly, know how many publishers are providing the information [26].
opportunistic connectivity. However, such an approach does These properties allow for the efficient support of mobility:
not achieve continuous connectivity while on the move, which mobile nodes can simply reissue subscriptions for information
is becoming an increasingly important requirement. after handoffs and the network may direct these subscriptions
On the other hand, the Mobile IP protocol, a patch to to nearby caches rather than the original publisher.
remedy the problem of locating moving hosts, imposes “tri-
angular routing”: packets first need to be routed to a home D. Focus on Security
agent, representing the mobile host at its home network, and The Internet was designed to operate in a completely
from there to the current location of the mobile node via a trustworthy environment. User and data authentication, data
tunnel. This is a major inefficiency, since traffic has to travel integrity and user privacy were not a requirement; indeed the
along a path longer than the optimal, a problem significantly focus was on openness and flexibility in allowing new hosts
aggravated when the mobile node, its home agent, and the to join the network. Moreover, the Internet was designed to
third party that the host is communicating with are all located forward any traffic injected in the network, resulting in an
in distant Autonomous Systems (AS). Even traffic originating imbalance of power between senders and receivers. These
from a mobile node may need to be tunneled via its home characteristics allow spammers, hackers and attackers in gen-
agent, since many routers on the Internet exercise ingress eral to launch Denial of Service (DoS) attacks against the
filtering, i.e., they check that incoming traffic comes from the Internet infrastructure or against Internet hosts and services,
actual network it claims to originate from, meaning that the while easily covering their tracks. In order to cope with such
mobile node may not be able to directly send traffic from malicious and/or selfish behavior, add-on security patches and
its current location using its permanent home address. Mobile trust mechanisms have been developed, such as firewalls and
IP, just like overlay networks [25], also tends to violate the spam filters, as well as new security protocols that com-
usual “valley free” Border Gateway Protocol (BGP) routing plement the existing (inter)networking protocols (e.g., IPSec
policies, since packets are first routed to the mobile node’s and DNSSec). However, such solutions do not penetrate deep
home agent and from there re-routed to its currently hosting into the network and bad data still gets forwarded, clogging
network. This leads to (a) “valley routing”, i.e., a client AS systems and possibly fooling filtering mechanisms [3]. The
(where the home agent is located) serves traffic for a provider required processing overhead and the Internet’s end-to-end
AS, and (b) “exit policy violation”, i.e., traffic exiting from an philosophy have so far prevented placing security and trust
exit point different than the one it was supposed to, according mechanisms deeper into the network, where it would be most
to the BGP rules for a given traffic destination. effective in avoiding or identifying and stopping attacks.
In ICN, host mobility is addressed by employing the pub- Many of the security problems of the Internet are largely
lish/subscribe communication model [26]. In this model, users due to the disconnection between information semantics at the
application layer and the opaque data in individual IP packets. over the network is one of the main characteristics of
This places a significant burden on integrating accountability each ICN architectural proposal. In all ICN architectures
mechanisms into the overall architecture. Point solutions like information names are location-independent. On the other
DPI or lawful interception try to restore this broken link be- hand, depending on the approach, names may range
tween the actual information semantics and the data scattered from flat to hierarchical and may or may not be human-
in individual packets. However, this is achieved at a relatively readable.
high cost and is therefore only applicable to critical problems, • Name resolution and data routing: Name resolution
such as law enforcement. As a result, while secure end-to-end involves matching an information name to a provider
connections are prevalent, the overall Internet architecture is or source that can supply that information, while data
still not self-protected against malicious attacks and data is not routing involves constructing a path for transferring the
secure. At the same time, the lack of an accountability frame- information from that provider to the requesting host. A
work which would allow non-intrusive and non-discriminatory key issue is whether these two functions are integrated,
means to detect misbehavior and mitigate its effects, while or coupled, or are independent, or decoupled. In the
retaining the broad accessibility to the Internet and ensuring coupled approach, the information request is routed to
both data security and communication privacy (i.e., hiding an information provider, which subsequently sends the
from non-authorized parties that a communication between information to the requesting host by following the
two parties took place) is a crucial limitation to overcome [20]. reverse path over which the request was forwarded. In
ICN architectures are in contrast interest-driven, i.e., there is the decoupled approach, the name resolution function
no data flow unless a user has explicitly asked for a particular does not determine or restrict the path that the data will
piece of information. This is expected to significantly reduce use from the provider to the subscriber. For example,
the amount of unwanted data transfers (such as spam) and also an independent data routing module may send to the
facilitate the deployment of accountability and forensic mech- provider a source route to the requesting host.
anisms on the network points that handle “availability” and • Caching: We distinguish between on-path and off-path
“interest” signaling. Moreover, for ICN architectures that use caching. In on-path caching the network exploits infor-
self-certifying names for information, malicious data filtering mation cached along the path taken by a name resolution
will be possible even by in-network mechanisms. Finally, most request, while in off-path caching the network exploits
ICN architectures add a point of indirection between users information cached outside that path. In ICN architectures
requesting a piece of information and users possessing this with decoupled name resolution and data routing, off-
piece of information, decoupling the communication between path caching must be supported by the name resolution
these parties. This decoupling can be a step towards fighting system, which handles caches as regular information pub-
denial of service attacks, as requests can be evaluated at the lishers. If name resolution and data transfer are coupled,
indirection point, prior to arriving to their final destination. off-path caching must be supported by the routing system
Indirection can also benefit user privacy, as a publisher does used to forward the requests for information.
not need to be aware of the identities of its subscribers. • Mobility: Subscriber mobility is intrinsically supported
in ICN architectures, since mobile subscribers can just
III. ICN A PPROACHES send new subscriptions for information after a handoff.
Publisher mobility is more difficult to support, since the
The various existing ICN initiatives focus on designing name resolution system (in the coupled approach) or the
an Internet architecture that will replace the current host- routing tables (in the decoupled approach) need to be
centric model and will directly address the problems and updated.
limitations identified in the previous section. ICN oriented • Security: This aspect is tightly related to the naming
projects (see Figure 1) include the DONA [29] project at structure [40]. On the one hand, human-readable names
Berkeley, the EU funded projects Publish-Subscribe Internet require a trusted agent or a trust relationship with the
Technology (PURSUIT) [30] and its predecessor Publish- name resolution system to verify that the returned in-
Subscribe Internet Routing Paradigm (PSIRP) [31], Scalable formation corresponds to the requested name. On the
& Adaptive Internet soLutions (SAIL) [32] and its predecessor other hand, flat names can support self-certification, but
4WARD [33], COntent Mediator architecture for content- are not-human readable, thus requiring another trusted
aware nETworks (COMET) [34], CONVERGENCE [35], the system to map human-readable names to flat names.
US funded projects Named Data Networking (NDN) [36] and
It is important to note that these are not ICN-specific
its predecessor Content Centric Networking (CCN) [37] and
functionalities, but rather the common core of all the ICN
MobilityFirst [38], as well as the French funded project ANR
architectures considered. As such, this list simply aims to
Connect [39] which adopts the NDN architecture.
assist in shaping the presentation of each individual ICN
Although they are still under active development, these ICN architecture in the remainder of this section, as well as the
architectures address a set of key functionalities, albeit with ensuing discussions in the following sections.
different approaches. Below we identify these key functional-
ities, which will form the basis for presenting and comparing
the various ICN initiatives in the remainder of the paper. A. DONA
• Naming: The structure of the name assigned to a piece While many projects, starting with TRIAD [10], pro-
of information (or service) that can be communicated posed extending the Internet with content routing capabil-
TRIAD [10]
1999 (Jul 1999-Dec 2002)
OceanStore [15] 2000
TRIAD [9], Content-based networking [11] 2001
i3 [14] 2002
2003
2004
2005
VRR [16], ROFL [17]

CCN Google Tech Talk [41] 2006
DONA [29] 2007
PSIRP [31] 4WARD [33]

2008
(Jan 2008-Jun2010) (Jan 2008-Jun 2010)
CCN [42], LIPSIN [53] 2009

COMET [34] CONVERGENCE [35] NDN [36]
(Jan 2010-Dec 2012) (Jun 2010-Feb 2013) (Sep 2010- Aug 2013)
2010 SAIL [32] PURSUIT [30] MobilityFirst [38]
(Aug 2010-Jan 2013) (Sep 2010-Feb 2013) (Sep 2010-Sep 2013)
ANR Connect [39]

2011
(Jan 2011- Dec 2012)
2012
Fig. 1. Timeline of key ICN milestones. Seminal ICN papers are shown on the left hand side, while ICN-related projects are shown on the right hand side.
ities (see Figure 1), the Data Oriented Network Architec- an entire web site or each individual web page within it.
ture (DONA) [29] from UC Berkeley is one of the first Names are flat, application-independent, location-independent
complete ICN architectures, as it radically changes naming and globally unique. For immutable data the label can be
by replacing the hierarchical URLs with flat names. Unlike the cryptographic hash of the information object itself, thus
URLs which are bound to specific locations via their DNS allowing any purveyor (e.g., a CDN) to offer such data. Clients
component, the flat names in DONA can be persistent, even interested in an information object are assumed to learn its
if the information moves. This allows information to be cached name through some trusted external mechanisms (e.g., a search
and replicated at the network layer, thus increasing information engine). Unlike structured DNS names, flat names in DONA
availability. Finally, names in DONA allow users to verify do not embed a fixed administrative structure, thus they are
that the received information matches a requested name via easy to map to any private namespace of human-readable
cryptographic techniques. On the other hand, DONA maintains names.
IP addressing and routing, either globally or locally (see 2) Name Resolution and Data Routing: Name resolution
below), deploying a name resolution mechanism as an overlay in DONA is provided by specialized servers called Resolution
that maps its flat names to the corresponding information. Handlers (RHs). There is at least one logical RH at each
1) Naming: In DONA each piece of information (or ser- AS. RHs are interconnected, forming a hierarchical name
vice) is associated with a principal. Names consist of the resolution service on top of the existing inter-domain routing
cryptographic hash of the principal’s public key P and a relations, as shown in Figure 2, so as to allow name resolution
label L uniquely identifying the information with respect to and data routing to respect the established routing policies be-
the principal. Naming granularity is left to the principals, tween AS’s. In order to make an information object available,
who are considered to be the owners of the correspond- the publisher (principal) sends a R EGISTER message with the
ing information. For instance, principals may name either object’s name to its local RH, who stores a pointer to the
Router Tier-1 AS
RH
)
(9
(1 0
)
(5 )
(3)
(6)
Router
(2) Router Router

RH
RH
AS 1 RH AS 2 AS 3
(8)
(11)
)
(1
( 7)
(4)
Peering Link
Client-Provider Link
(1-3) Register Message
(4-7) Find Message
(8-11) Data Subscriber
Publisher
Fig. 2. The DONA architecture. RH stands for Resolution Handler.
principal (arrow 1). The RH then propagates this registration RH to RH, indicating the sequence of AS’s crossed by the
to the RHs in its parent and peering domains, following request. When the request reaches the publisher, these path-
the established routing policies (arrows 2-3), causing each labels are simply used in the reverse order to retrace the
intermediate RH to store a mapping between the object’s name path towards the subscriber (arrows 8-11). While the coupled
and the address of the RH that forwarded the registration. As a option obviates the need for global IP addresses and large BGP
result, registrations are replicated in RHs all the way up to the routing tables, since all path-labels have a local meaning, it
tier-1 providers and, since all tier-1 providers are peers with enforces symmetric routing (at least, at the AS level) between
each other, RHs located at tier-1 providers are aware of all requests and responses, which is not necessarily the case with
registrations in the entire network. Publishers can also issue regular BGP routing.
wildcard R EGISTER messages to notify the RH hierarchy that DONA can also support multicast channels, by allowing
they can provide all possible data items for a specific principal. F IND messages to be cached in RHs for a specified period
In order to locate an item, a subscriber sends a F IND of time and sending information updates in response to these
message to its local RH, which also propagates this message messages until they expire. When additional F IND messages
to its parent according to its routing policies, until a match- for the same information are received by the RH, they are
ing registration entry is found (arrows 4-5). At that point, merged into a single entry with multiple path-labels for the
requests follow the pointers created by the registrations in responses, thus creating a multicast distribution tree. Note that
order to eventually reach the publisher (arrows 6-7). Since this can only work with the coupled option, as it requires data
tier-1 providers are aware of all objects in the network, this to follow the reverse AS path taken by the F IND messages.
process is guaranteed to succeed if the requested name exists. 3) Caching: DONA supports on-path caching via the RH
Subscribers can also issue wildcard F IND messages to ask for infrastructure. A RH that decides to cache a requested data
immutable data with a specific label, regardless of its purveyor. object can replace the source IP address of an incoming
Data routing can be either decoupled or coupled with name F IND request with its own IP address, before forwarding the
resolution. In the decoupled option, when a F IND message message to the next RH. As a result, any response will surely
reaches an appropriate publisher, the data can be directly sent traverse the current RH, thus the data returned will be cached
to the subscriber using regular IP routing and forwarding. The there. If path-labels are used, the data always return via the
actual data transmission will follow the established routing intermediate RHs, who can then decide whether to cache the
policies for traffic between the publisher’s and the subscriber’s information or not. If a subsequent F IND message requesting
AS’s. This requires global IP addresses, which are nearly the same object reaches a caching RH, the RH can directly
exhausted, so DONA also offers a coupled option which relies return the data to the subscriber. Information may also be
on domain-local IP addresses only. In the coupled option replicated off-path, provided that each purveyor registers the
the F IND messages gather path-labels as they move from information through its local RH. A RH receiving multiple
R EGISTER messages for the same information maintains (and something considered to be critical for the scalability of the
propagates upwards) only the pointers to the best available architecture.
copy (e.g., the closest one). 1) Naming: Names in NDN are hierarchical and may
4) Mobility: Mobile subscribers can simply issue new be similar to URLs, for example, an NDN name can be
F IND messages from their current location, relying on the /aueb.gr/ai/main.html. However, NDN names are not
RH infrastructure to provide them with the closest copy of necessarily URLs: their first part is not a DNS name or an IP
the information. Mobile publishers can also unregister and address and they do not have to be human-readable. Instead, in
re-register their information when changing their network NDN each name component can be anything, including a dot-
location, but this incurs a non-negligible messaging overhead, ted human-readable string or a hash value. In NDN a request
since these messages need to be relayed all the way to the for a name is considered to match any piece of information
tier-1 RHs to ensure that (a) no stale registration state will whose name has the requested name as a prefix, for example,
exist and (b) that the advertised information is traceable to its /aueb.gr/ai/main.html can be matched by an informa-
new location. tion object named /aueb.gr/ai/main.html/_v1/_s1,
5) Security: Names in DONA are self-certifying, i.e., they which could mean the first segment of the first version of
allow the subscriber to verify that the data received matches the requested data. After receiving this information object, the
the name requested. For mutable data, a client requesting subscriber could ask for the next data segment either directly
an information object named P:L will also receive as meta- by requesting /aueb.gr/ai/main.html/_v1/_s2, or
data the public key of the principal (which is bound to P for the next sibling under this version. Alternatively, the
via its hash) and a signature for the data object itself, thus subscriber could ask for the next version by requesting the
allowing the data to be authenticated as coming from the first sibling of /aueb.gr/ai/main.html/_v1. While
specific principal. For immutable data, the subscriber can the way information objects are segmented is expected to be
simply verify that the label L is indeed the cryptographic hash known by the subscriber’s application, the prefix matching
of the information object, regardless of the purveyor acting as rule enables an application to discover what is available.
the principal. This allows subscribers to choose a purveyor Furthermore, it allows the subscriber to ask for data that
according to its reputation and performance. have not been produced yet: a publisher can advertise that
The design of DONA can either prevent or mitigate a series it can satisfy requests for a specific prefix, and then return
of attacks to the RH infrastructure. A RH will only accept information objects with complete NDN names. This can be
information registrations by authenticated principals (bound used to implement various applications where information
to P) or purveyors of immutable information (bound to L) objects are generated dynamically, hence their full names
and it will only accept forwarded registrations from trusted cannot be known in advance, such as voice conferencing [43].
RHs, since all traffic follows established routing policies. 2) Name Resolution and Data Routing: In NDN sub-
Providers can enforce contractual limits on R EGISTER and scribers issue I NTEREST messages to request information
F IND messages from customers to guard against control-plane objects which arrive in the form of DATA messages, with
resource exhaustion attacks. In order to protect customer AS’s both types of message carrying the name of the re-
from misbehaving RHs, DONA allows explicit requests for quested/transferred information object. As shown in Fig-
access to copies other than the closest one. Finally, DONA ure 3, all messages are forwarded hop-by-hop by Content
delegates the responsibility for guarding against user-plane Routers (CRs), with each CR maintaining three data struc-
resource exhaustion attacks to existing IP mechanisms. tures: the Forwarding Information Base (FIB), the Pending
Interest Table (PIT) and the Content Store (CS). The FIB
maps information names to the output interface(s) that should
B. NDN be used to forward I NTEREST messages towards appropriate
The Content Centric Networking (CCN) [37] architecture data sources. The PIT tracks the incoming interface(s) from
from PARC is the other pioneering fully-fledged ICN ar- which pending I NTEREST messages have arrived, i.e., those
chitecture. Its basic ideas were described in a Google tech I NTEREST messages for which matching DATA messages
talk [41], long before the first paper describing the CCN are expected. Finally, the CS serves as a local cache for
architecture was published [42] (see Figure 1). The Named information objects that have passed through the CR.
Data Networking (NDN) [36] project, funded by the US When an I NTEREST arrives, the CR extracts the information
Future Internet Architecture program, is further developing name and looks for an information object in its CS whose
the CCN architecture. NDN envisions reshaping the Internet name matches the requested prefix. If something is found, it
protocol stack by making the exchange of named data the thin is immediately sent back through the incoming interface in
waist of the Internet architecture, using various networking a DATA message and the I NTEREST is discarded. Otherwise
technologies below the waist for connectivity, including, but the router performs a longest prefix match on its FIB in
not limited to, IP. In NDN a strategy layer mediates between order to decide towards which direction this I NTEREST should
the named data layer and the underlying network technologies be forwarded. If an entry is found in the FIB, the router
to optimize resource usage, e.g., to select a link in a multi- records the I NTEREST’s incoming interface in the PIT and
homed node, while a security layer applies security function- pushes the I NTEREST to the CR indicated by the FIB. In
alities directly on named data. A crucial aspect of NDN is that Figure 3, the subscriber sends an I NTEREST for the name
names are hierarchical, thus allowing name resolution and data /aueb.gr/ai/new.htm (arrows 1-3). If the PIT already
routing information to be aggregated across similar names, contains an entry for the exact name, meaning that this exact
C’s routing tables after C’s routing tables after

receiving Interest packet receiving Data packet
FIB FIB
Name Next Name Next
/aueb.gr/ Publisher 1 /aueb.gr/ Publisher 1
PIT PIT
Name Requested Name Requested
/aueb.gr/ai/new.htm CR A - -
A’s tables after receiving
Data packet CS CS
Name Data Name Data
FIB /aueb.gr/ai/new.htm ...
- -
Name Next
/aueb.gr/ CR C
/aueb.gr/cs CR B
A’s tables after receiving PIT
Interest packet Name Requested
( 3)
- -
FIB
Name Next
CS (4 ) Publisher 1
Name Data
/aueb.gr/ CR C
/aueb.gr/ai/new.htm ... FIB
/aueb.gr/cs CR B
Name Next
PIT
Name Requested (2) CR C /aueb.gr/cs Publisher 2
/aueb.gr/ai/new.htm Subscriber PIT
(5) Name Requested
CS
- -
Name Data
- - CS
Name Data
(1) - -
( 6) CR A
CR B
Subscriber
Publisher 2
Link
(1-3) Interest Message
(4-6) Data
Fig. 3. The NDN architecture. CR stands for Content Router, FIB for Forwarding Information Base, PIT for Pending Interest Table, CS for Content Store.
information object had already been requested, the router since DATA messages follow the pointers left in the PITs
adds the incoming interface to this PIT entry and discards by I NTEREST messages, therefore routing is by definition
the I NTEREST, effectively forming a multicast tree for the symmetric. In order to populate the FIBs, NDN can use
information object. distributed routing protocols like OSPF [42], in which CRs
When an information object that matches the requested advertise name prefixes rather than IP address ranges, e.g., a
name is found at a publisher node or a CS, the I NTEREST mes- router could advertise /aueb.gr to inform the network that
sage is discarded and the information is returned in a DATA it can provide information objects whose prefix is /aueb.gr.
message. This message is forwarded back to subscriber(s) in A CR may have multiple interfaces in its FIB for a prefix, for
a hop-by-hop manner, based on the state maintained in the example, if it is multi-homed or if it is aware of multiple
PITs. Specifically, when a CR receives a DATA message, it CDN servers hosting the information. In this case its strategy
first stores the corresponding information object in its CS and layer may choose to send the I NTEREST either to all these
then it performs a longest-prefix match in its PIT to locate an interfaces (if multiple DATA messages are returned, all but
entry matching the DATA packet;3 if a PIT entry lists multiple the first are automatically discarded) or only to the interface
interfaces, the DATA message is duplicated, thus achieving that has exhibited the best performance so far.
multicast delivery. Finally, the CR forwards the DATA message
packet to these interfaces and deletes the entry from the PIT 3) Caching: NDN natively supports on-path caching, since
(arrows 4-6). In case there are no matching entries in the PIT, each CR first consults its CS whenever it receives an I N -
the router discards the DATA packet as a duplicate. TEREST message and caches all information objects carried
In NDN name resolution and data routing are coupled, by DATA messages. The CS can use LRU or any other
replacement policy, but, realistically, it cannot be used for
3 The longest-prefix match is needed since the requested name may be a long-term storage if it just caches everything it sees [44], [45],
prefix of the one returned. therefore it is mostly useful for recovery from packet losses
and for handling flash crowds, where many users request the a subscription to a publication, it directs the topology
same data in close succession. Off-path caching is supported management function to create a route between the publisher
by delivering an I NTEREST to any data source that may be and the subscriber. This route is finally used by the forwarding
hosting the requested information object, e.g., the strategy function to perform the actual transfer of data.
layer can direct the I NTEREST to a CDN server rather than 1) Naming: Information objects in PURSUIT are identified
to the originating publisher. This is not transparent to NDN by a (statistically) unique pair of IDs, the scope ID and
however, as it requires populating the FIBs with pointers to the rendezvous ID. The scope ID groups related information
such copies, which in turn requires the name prefixes of these objects while the rendezvous ID is the actual identity for a
copies to be advertised by the CDN server through the routing particular piece of information [49]. Information objects may
protocol used. belong to multiple scopes (possibly with different rendezvous
4) Mobility: When a subscriber moves in NDN, it can sim- IDs), but they must always belong to at least one scope. Scopes
ply issue new I NTEREST messages from its current location serve as a means of (a) defining sets of information objects
for the information objects it has not yet received. These will within a given context and (b) enforcing “boundaries” based
be suppressed by the PIT of the first common CR in both on some dissemination strategy for the scope. For example,
delivery routes (prior and post the handoff). Of course, the a publisher may place a photograph under a “friends” scope
corresponding information objects will also be delivered to and a “family” scope, with each scope having different access
its old location. When a publisher moves on the other hand, rights. While PURSUIT names are flat as in DONA, scopes in
the FIBs pointing to it have to be updated, which requires PURSUIT can be organized in scope graphs of variable forms,
advertising again the name prefixes for the information it is including hierarchies, therefore a complete name consists of
hosting via the routing protocol. As this represents a very a sequence of scope IDs and a single rendezvous ID, thus
high overhead in high-mobility solutions, NDN utilizes the generalizing the DONA naming scheme.
Listen First Broadcast Later (LFBL) protocol [46] to im- 2) Name Resolution and Data Routing: Name resolution
plement mobility in ad-hoc/opportunistic networks. In LFBL, in PURSUIT is handled by the rendezvous function, which is
I NTEREST messages are flooded. When a potential source for implemented by a collection of Rendezvous Nodes (RNs), the
the requested information receives an I NTEREST, it listens to Rendezvous Network (RENE), implemented as a hierarchical
the (wireless) channel in order to discover if another node has DHT [50], [51], as shown in Figure 4. When a publisher
already sent a matching DATA message. If not, it sends the wants to advertise an information object, it issues a P UBLISH
DATA message itself towards the subscriber. message to its local RN which is routed by the DHT to
5) Security: NDN supports the association of human- the RN assigned with the corresponding scope ID (arrows 1-
readable hierarchical information names with the correspond- 2).4 When a subscriber issues a S UBSCRIBE message for the
ing information objects in a verifiable way [47]. Each DATA same information object to its local RN, it is routed by the
message contains a signature over the name and the in- DHT to the same RN (arrows 3-6). The RN then instructs a
formation included in the message, plus information about Topology Manager (TM) node to create a route connecting the
the key used to produce the signature, e.g., the public key publisher with the subscriber for data delivery (arrows 7-8).
of the signer, a certificate for that public key or a pointer The TM sends that route to the publisher in a S TART P UBLISH
to them. This allows any node, including CRs, to verify message (arrows 9-10), which finally uses this route to send
the binding between the (possibly, human-readable) name the information object via a set of Forwarding Nodes (FNs).
of the packet and the accompanying information. In order The TM nodes in PURSUIT jointly implement the topology
to verify that the information comes from an authorized management function by executing a distributed routing pro-
source though, the subscriber must trust the owner of the tocol to discover the network topology, e.g., OSPF. The actual
public key used for signing. The hierarchical structure of delivery paths are calculated upon request by the rendezvous
names simplifies building trust relationships, for example, function as a series of links between FNs and encoded into
/aueb.gr/ai/main.html may be signed by the owner source routes using a technique based on Bloom filters [52].
of the /aueb.gr/ai domain, whose key may be certified Specifically, each network node assigns a tag, i.e., a long
by the owner of the /aueb.gr domain. NDN also supports bit string produced by a set of hash functions, to each of
anonymous operation by using a Tor-like approach named its outgoing links, and advertises these tags via the routing
ANDaNA [48]. protocol. A path through the network is then encoded by
ORing the tags of its constituent links and the resulting Bloom
filter is included in each data packet. When a data packet
C. PURSUIT
arrives at a FN, the FN simply ANDs the tags of its outgoing
The Publish Subscribe Internet Routing links with the Bloom filter in the packet; if any tag matches,
Paradigm (PSIRP) [31] project and its continuation the then the packet is forwarded over the corresponding link [53].
Publish Subscribe Internet Technology (PURSUIT) [30] In this manner, the only state maintained at the FNs is the
project (see Figure 1), both funded by the EU Framework 7 link tags. Multicast transmission can be achieved by simply
Programme, have produced an architecture that completely encoding the entire multicast tree into a single Bloom filter.
replaces the IP protocol stack with a publish-subscribe Subsequent packets belonging to the same information
protocol stack. The PURSUIT architecture consists of
three separate functions: rendezvous, topology management 4 Note that the RN assigned with a scope ID may reside outside the AS of
and forwarding. When the rendezvous function matches its publisher, due to the way DHTs operate.
Tier-1 AS
GLOBAL RENE
RN RN
RN
(6 )
(5 )
RENE 1 RENE 2
RN RN
RN RN RN RN
(4
FN
(2)
)
(7)
FN FN TM
(13)
(3)
FN (1 2) (1 4)
(1)
(8)
(10) AS2
(9)
(11)
Subscriber
Publisher AS1
TM
Overlay Link
Inter-domain Link
Intra-domain Link
(1, 2) Publish Message
(3-6) Subscribe Message
(7, 8) Delivery Path Request Message
(9, 10) Start Publish Message
(11-14) Data
Fig. 4. The PURSUIT architecture. RN stands for Rendezvous Node, RENE for REndezvous NEtwork, FN for Forwarding Node and TM for Topology
Manager.
object can be individually requested by the subscriber using 3) Caching: PURSUIT can support both on-path and off-
the notion of Algorithmic IDs, i.e., packet names generated path caching [54]. In the on-path case, forwarded packets
by an algorithm agreed by the communicating entities. These are cached at FNs in order to potentially serve subsequent
requests are forwarded similarly to data packets, using reverse requests. However, on-path caching may not be very effective
Bloom filters calculated by the TM to bypass the RENE. This due to the decoupled nature of name resolution and data
allows the realization of transport layer protocols, e.g., via a routing, since requests for the same information object can
sliding window of pending requests. reach the same RN, whereas the actual data transfers may use
Name resolution and data routing are decoupled in PUR- entirely different paths. In the off-path case, caches operate
SUIT, since name resolution is performed by the RENE, while as publishers, by advertising the available information to the
data routing is organized by the TMs and executed by the RENE. Managed information replication, as in CDNs, can also
FNs. While name resolution can be time consuming, especially be efficiently supported by the PURSUIT architecture [55].
since DHT routing does not follow the shortest paths between 4) Mobility: Mobility in PURSUIT is greatly facilitated by
the communicating nodes, data forwarding can take place the use of multicast and caching [54]. Four types of mobility
at line speeds, without placing any state at the FNs [53]. cases are considered, based on host movement (local, global)
Furthermore, the separation of routing and forwarding allows and technology interchange (static when a single technology
the TMs to calculate paths using complex criteria (e.g., load is involved, dynamic when vertical handoffs are performed).
balancing), without requiring signaling to the (stateless) FNs. Local subscriber mobility can be handled via multicast and
On the other hand, the topology management and forwarding caching, i.e., by multicasting information objects to multiple
functions as described are only adequate for the intra-domain possible locations for the mobile subscriber and receiving
case and need to be extended (e.g., with label switching) for information objects from nearby caches after a handoff. Global
the inter-domain level. subscriber mobility is handled by modifying the forwarding
function of the architecture [56]. Mobility prediction can In the decoupled case, a Name Resolution System (NRS)
be used to reduce handoff latencies by caching information is used to map object names to locators that can be used
requested by the subscriber to the areas where the subscriber to reach the corresponding information object, such as IP
is expected to move after a handoff [54]. Publisher mobility addresses. The NRS is some form of DHT, either a multilevel
is harder, since the topology management function has to be DHT [61] or a hierarchical SkipNet [62]. In the multilevel
notified of the publisher’s new position in the network. DHT solution, each authority maintains its own local NRS
5) Security: PURSUIT supports the Packet Level Authen- to handle the resolution of the L part, while a global NRS
tication (PLA) technique [57] for encrypting and signing handles the resolution of the A part. A publisher makes an
individual packets. This technique assures data integrity and information object available by sending a P UBLISH message
confidentiality as well as malicious publisher accountability. with its locator to the local NRS, which stores the L to
PLA can be used to check packets either at FNs or at their final locator mapping (arrow 1). The local NRS aggregates all the
destination. The use of flat names also permits self-certifying L parts for the same authority A into a Bloom filter [52],
names for immutable data objects, using the object’s hash as and sends a P UBLISH message to the global NRS (arrow 2).
the rendezvous ID. Moreover, paths encoded into Bloom filters The global NRS stores the mapping between the authority
can use dynamic link identifiers, making it impossible for an A plus the Bloom filter and the local NRS, replacing any
attacker to craft Bloom filters or even to reuse old Bloom previous such mapping. When a subscriber is interested in
filters to launch DoS attacks. Finally, security solutions for an information object, it can send a G ET message to its local
mitigating spam [58] and for preserving privacy have been NRS which consults the global NRS (arrows 3-4) in order
developed for PURSUIT. to return a locator for the object (arrows 4-5). Finally, the
subscriber sends a G ET message to the publisher, using the
D. SAIL returned locator (arrows 7-9), and the publisher responds with
the information object in a DATA message (arrows 10-12).
The Architecture and design for the future Inter-
In the coupled case, a routing protocol is used to advertise
net (4WARD) [33] project and its continuation Scalable and
object names and populate the routing tables of Content
Adaptive Internet Solutions (SAIL) [32] (see Figure 1), both
Routers (CRs), as in NDN. A subscriber sends a G ET message
funded by the EU Framework 7 Programme, are investigating
to its local CR, which propagates it hop-by-hop towards the
designs for the Future Internet and ways to facilitate a smooth
publisher or a cache (arrows a-c). When the information object
transition from the current Internet. While both projects have a
is found, it is returned via a DATA message, reversing the path
very wide scope, in this survey we will focus on one of their
taken by the G ET message (arrows d-f). However, in contrast
research areas, the Network of Information (NetInf), which
to NDN where pointers left in CRs are used for the return
designs an ICN architecture that supports the exchange of
path, in SAIL the G ET messages accumulate routing directions
named information objects. Beyond the aspects covered below,
along their path, which are simply reversed at the publisher
the SAIL architecture5 includes many other services, such as
or cache in order to reach the subscriber.
searching for information objects via keywords. The SAIL
In the hybrid mode of operation, the NRS returns routing
architecture is very general: it combines elements present in
hints, that is, partial locators that can direct a G ET message
the NDN and PURSUIT approaches and can even operate
in one or more directions where more information about the
in a hybrid mode. Furthermore, it can be implemented over
requested information object may be found. A G ET message
different routing and forwarding technologies, by introducing
can thus start with some routing hints from the NRS to reach
convergence layers to translate SAIL messages to actual
the vicinity of the requested information object, and then
network packets [59].
exploit name-based routing information stored in the CRs to
1) Naming: Information object names in SAIL are “flat-
reach its destination. Alternatively, a G ET message can start
ish”: they provide some structure and they can even be
with the name-based routing information stored in the CRs
hierarchical, but they do not carry location or organizational
and resort to the NRS for further routing hints when a CR
information. SAIL defines the ni://A/L URI scheme in
does not have sufficient information to forward it. As a result,
which names consist of an authority part A and a local (with
routing in SAIL can be a mix of hop-by-hop and partial paths.
respect to the authority) part L. Each part can be a hash, thus
3) Caching: The SAIL architecture, in addition to on-path
allowing for self-certification, or any other type of string, thus
caching at the CRs, envisions the deployment of large scale
allowing for regular URLs [60]. SAIL names are considered
information object caching and replication mechanisms in
flat for name comparison purposes, that is, a subscription will
co-operation with the NRS, i.e., these caches are treated as
only match a publication if there is an exact name match
publishers. SAIL considers a hierarchy of caches in which
between them, as in PURSUIT. On the other hand, SAIL
local caches are part of a tree that contains a small number of
names can be considered hierarchical when used for routing,
caching servers at the root. Caches higher up in the hierarchy
that is, routers can use longest prefix matching to determine
have larger storage space in order to store popular objects,
how to route a message, as in NDN [59].
which otherwise would have been evicted by local caches
2) Name Resolution and Data Routing: Name resolution
due to their small size. The project also investigates cache
and data routing can be either coupled or decoupled in SAIL,
migration policies, in which popular objects are dynamically
and even hybrid operation is possible, as shown in Figure 5.
migrated to caches that are closer to the consumers [60].
5 While the architecture is most frequently referred to as NetInf, we use 4) Mobility: Host mobility is supported by having the
instead the project’s name (SAIL) as for the other ICN efforts. NRS maintain topological information for each registered
Global NRS
Local NRS Local NRS
(2) (5)
(4)
CR CR
(e)
(3)
(6)
( 1)
(b)
) Case 1: Routers Perform ( f)

(d ) Name-based Routing (a
(c )
(9)
(7 )
Publisher (1 0 ) Subscriber
)
CR CR (1 2
(8)
(11)
Case 2: Routers Perform

Regular Routing
Link
(1, 2) Publish Message
(3, 6) Resolve Request /Response Message
(7-9, a-c) GET Message
(10-12, d-f) Data
Fig. 5. The SAIL architecture. NRS stands for Name Resolution System, CR for Content Router.
host. Upon a change of location, the moving host updates SAIL names may explicitly identify the hash scheme used,
the topological information in the NRS where it is registered e.g., SHA-1, to allow many such schemes to co-exist [60].
and an appropriate notification is sent to any nodes that are
currently communicating with the mobile host. The NRS E. COMET
also uses a Late Name Binding (LNB) strategy to allow the The COntent Mediator architecture for content-aware nET-
resolution process to terminate at a node close to the current works (COMET) [34] project (see Figure 1), funded by the
area of a moving host. This is facilitated by the use of routing EU Framework 7 Programme, is designing mechanisms for
hints in the NRS, which allow messages to first be forwarded optimizing information source selection and distribution by
in the appropriate direction, and then get resolved to their mapping information to appropriate hosts or servers based
exact destination. For example, when a publisher moves within on transmission requirements, user preferences, and network
its current area, it can simply update its local NRS with its state [63]. The core component of the COMET architec-
location, without invalidating the routing hints in the global ture is a Content Mediation Plane (CMP) which mediates
NRS that point to its current area. between the network providers and the information servers,
5) Security: The SAIL architecture envisions a fully- being aware of both information and infrastructure. The
fledged security system that covers name security, information COMET project has produced two very different architectures
integrity, authentication and confidentiality, and authorization for the CMP: a coupled design called Content-Ubiquitous
and provenance. The basic building block of the security Resolution and Delivery Infrastructure for Next Generation
architecture is the inclusion of hash values in names, which Services (CURLING) [64], which is an ICN architecture
allows self-certification of both the authority and the local part. with coupled name resolution and routing, and a decoupled
(4)
(4 a
(5) CRS )
CaR
(2) Tier-1 AS
)
(9)
(8
CaR
CaR
(5a)
(3a)
CRS
CRS
(6)
AS1 (3) AS2
(1)
0)
)
(7
(1
Peering Relationship
Link
(1, 2) Register/Publish Message
(3-6) Consume Message
(3a, 4a, 5a) Route Configuration Subscriber
Publisher (7-10) Data
Fig. 6. The coupled COMET architecture. CRS stands for Content Resolution System, CaR for Content-aware Router.
design that enhances information delivery without fundamen- that name (arrows 3-4). The subscriber may either limit the
tally changing the underlying Internet [65]. Unlike other ICN propagation of this information to a specific area or exclude
approaches which strive for location independence, COMET specific areas from this propagation. When a match is found,
allows both subscribers and publishers to explicitly include the C ONSUME message follows the pointers in the CRSs to
location preferences for information, following established reach the actual publisher (arrows 5-6). As the C ONSUME
business practices. For example, a subscriber may ask for message travels from the subscriber to the publisher, each
bookstores in a specific country, and a publisher may only CRS on the way installs forwarding state at the Content-
make videos available to a specific country. aware Routers (CaRs) of each intermediate AS, pointing back
1) Naming: A precise naming scheme has not been defined towards the subscriber (arrows 3a-5a). The publisher can thus
for COMET. However, in COMET the information names send the corresponding data to the subscriber by using these
are provided by a Content Resolution System (CRS) when pointers (arrows 7-10).
the information is registered by the publishers, thus allowing While the coupled approach in COMET shares many ideas
names for related information to be explicitly aggregatable, with DONA on name resolution and with NDN on data
e.g., episodes of a TV series can have sequential names. routing, there are some important differences. With respect
This allows the naming system to scale by exploiting existing to name resolution, in COMET the P UBLISH messages are
relationships between information objects. not propagated to peering AS’s, but only to parents, in
2) Name Resolution and Data Routing: The coupled ap- order to reduce the state maintained at CRSs. This has two
proach in COMET is presented in Figure 6. A publisher that implications: first, when a C ONSUME message reaches a tier-1
wants to make some information available sends a R EGISTER provider without finding a match, it must be propagated to all
message to its local CRS node which issues a name for the other Tier-1 providers to guarantee that a match will be found,
information and stores the actual location of the information, if one exists, since all tier-1 providers are peers with each
e.g., the IP address of the publisher (arrow 1). This information other; second, both name resolution and data routing (which
is propagated upstream in the AS hierarchy using P UBLISH are coupled) do not exploit peering links, therefore additional
messages, so that each parent CRS ends up with a pointer to signaling is needed to switch to peering paths if available. For
its child CRS that sent the P UBLISH message (arrow 2). The example, in Figure 6 data routing can switch to the peering
publisher may limit the propagation of this information to a link between AS1 and AS2 [64]. With respect to data routing,
specific area, e.g., an IP prefix, so P UBLISH messages may while in NDN both name resolution and data routing use the
not reach the Tier-1 provider. A subscriber that is interested same CRs, in COMET name resolution uses the CRSs while
in some information issues a C ONSUME message to its local data routing uses the CaRs, thus allowing the CRSs in each
CRS, which is similarly propagated upwards in the CRS AS more flexibility in choosing the most appropriate paths
hierarchy until it reaches a CRS that has information about between the available CaRs of that AS.
(3)
CRS/PC CaR (4)
Tier-1 AS
(5)
(6)
(7)
(8)
CRS/PC CRS/PC
CaR CaR
(11)
(14)
(9)
(1)
(2)
AS1 AS2
(1 0
(1 )
2
(1 5
)
(1
3)
)
Peering Relationship
Link
(1) Register/Publish Message
(2) Consume Message Subscriber
(3-6) Resolve Request/Response Message
Publisher
(7-8) Path Request/Response Message
(9) Path Information
(10-12) Data Request
(13-15) Data
Fig. 7. The decoupled COMET architecture. CRS stands for Content Resolution System, CaR for Content-aware Router, PC for Path Configurator.
The decoupled approach in COMET is presented in Fig- that is, on-path caching is a byproduct of name resolution,
ure 7. In this case, the CRS system is similar to DNS, in that while off-path caching requires registering cached copies with
the CRSs split the object namespace among themselves in a the CRS. COMET has performed considerable work in on-
fixed hierarchical manner. This means that when a publisher path caching algorithms, proposing two novel schemes instead
wants to make some information available, it simply sends a of NDN’s “cache everything” scheme. ProbCache is a proba-
R EGISTER message to its local CRS (arrow 1), which is not bilistic caching scheme where each CaR first approximates
propagated further because it must belong to the namespace how many times an information packet should be cached
assigned to that CRS. When a subscriber issues a C ONSUME on a path by assuming other CaRs have the same caching
message for some information (arrow 2), this is resolved by capacity as itself and estimating the total traffic on the path
the root CRS to a pointer towards the publisher’s CRS (arrows by the requests it receives per unit time. Then, each CaR,
3-4). The subscriber’s CRS contacts the publisher’s CRS to based on this approximation, its distance from the publisher
get the location of the publisher (arrows 5-6), e.g., its IP and its distance from the subscriber that made the request,
address. Then the subscriber’s Path Configurator (PC) contacts probabilistically caches the packet [44]. On the other hand,
the publisher’s PC (shown co-located with the CRS nodes for the Centrality scheme is based on the observation that CaRs
simplicity) requesting a source route from the subscriber to lying on many shortest paths are more likely to get a cache
the publisher (arrows 7-8). This source route is returned to hit, hence an information object should only be cached by the
the subscriber (arrow 9) which uses it to request information CaR with the highest “centrality” in its path. The centrality is
(arrows 10-12); its reverse is used by the publisher to return the captured by the number of times a specific node is contained
information (arrows 13-15). COMET’s decoupled approach on the shortest paths between all pairs of nodes in a network
has some of the limitations of DNS, for example, names are topology. Computing the centrality at each CaR would require
location-dependent due to the fixed assignment of namespace that every CaR has knowledge of the global topology. Thus,
areas to network areas. As a result, it cannot be considered a simplified metric, for which a node needs only to know
a true ICN architecture, hence in the remainder of this paper its 1-hop neighbors and the paths among them, is used [45].
the term COMET architecture will refer only to the coupled Simulation results show that both caching schemes outperform
approach. the NDN scheme in terms of scalability and hit ratio [44], [45].
3) Caching: COMET supports on-path and off-path 4) Mobility: COMET uses specialized mobility-aware
caching in a manner similar to other coupled architectures, CaRs placed at the edge of the access networks to support
user mobility [66]. Mobility-aware CaRs track the mobility of 2) Name Resolution and Data Routing: The CONVER-
users and information and can predict their future locations. GENCE architecture, shown in Figure 8, has many similarities
When a subscriber moves to a new CaR in the same domain, with NDN; indeed, its prototype has been implemented as a
the latter can obtain the subscriber’s context information modification of the NDN prototype [68]. Subscribers issue
from the previous CaR. When the subscriber moves to a I NTEREST messages requesting an information object, which
different domain, the situation is more complicated since new are forwarded hop-by-hop by Border Nodes (BNs) to pub-
CaRs may need to be configured with routing state after the lishers or Internal Nodes (INs) that provide caching (arrows
handoff. As this process may lead to extended latencies during 1-3 and 6). Publishers respond with DATA messages which
handover, a proactive handover approach can be adopted to follow the reverse path (arrows 7-10). In order to reduce
avoid handoff latencies: the currently hosting domain predicts the state requirements at the BNs, CONET diverges from
the domain to which the subscriber is likely to hand over, NDN in three aspects. First, BNs do not maintain name-
allowing for user context information to be transferred in based routing information for every advertised name prefix,
advance. but only for a small portion of them, hence their routing
5) Security: COMET adopts security techniques from other table operates like a route cache. If an I NTEREST message
ICN architectures [65]. The security techniques that may be cannot be forwarded because there is no routing information
used depend however on the exact naming structure used. For for the corresponding name, the BN consults an external
example, if related pieces of information use sequential names Name Resolution System (NRS), e.g., DNS, in order to find
for aggregation purposes, these names cannot use the self- out how to forward the I NTEREST (arrows 4-5). Second,
certification approach of DONA which relies on embedding as I NTEREST messages are propagated they accumulate the
hashes in the names. One aspect of COMET that simplifies network addresses of the BNs they pass, allowing the publisher
security provisioning is the use of AS paths rather than global to route the DATA message by reversing this path information,
addresses in both the CRSs and the CaRs, thus preventing without requiring the maintenance of pointers at BNs. Third,
attackers from using arbitrary network paths to launch unde- BNs do not have to be directly connected; instead, the path
tected attacks. between two BNs can involve multiple hops, e.g., via IP
routers as shown in Figure 8, hence their designation as border
nodes. Therefore, unlike CRs in NDN, BNs map names to
F. CONVERGENCE network addresses, e.g., IP addresses, rather than to interfaces.
The CONVERGENCE [35] project (see Figure 1), funded In CONVERGENCE name resolution and data routing are
by the EU Framework 7 Programme, envisions an ICN-based coupled, since the path taken by a DATA message is the reverse
Future Internet that facilitates user access to information, of the path followed by the corresponding I NTEREST message,
spanning from digital data and services to people and real- even though each step of this path may not be a single hop but
world objects. Each such object in CONVERGENCE is an entire IP path, hence the path segments between BNs which
represented by a Versatile Digital Item (VDI), a common an I NTEREST message and its corresponding DATA message
container for all kinds of digital information, based on the follow are not necessarily symmetric. The NRS is used if an
MPEG-21 specification. A Content Network (CONET) [67] appropriate route is not found at some BN. The details of the
allows publishers to make available VDIs and subscribers to NRS used have not been defined by the CONVERGENCE
express interest in those VDIs. A distinguishing characteristic project. The name-based routing tables at BNs may also be
of the CONVERGENCE architecture6 is that it attempts to partially populated without resorting to the NRS, by running
ease transition from IP by reusing existing functionality. For a routing protocol for name prefixes, e.g., OSPF, as in NDN.
example, since CONVERGENCE messages are expected to 3) Caching: CONVERGENCE supports on-path caching in
be large due to naming and security meta-data, rules are a manner similar to NDN. Off-path caching and replication are
defined for splitting them to carrier packets, e.g., IP data- supported by registering additional copies of an information
grams. Furthermore, an IP header option has been defined object stored at INs to the NRS; however, the signaling
to carry the essential information from CONVERGENCE overhead for this registration is unclear, as an NRS mechanism
message headers, allowing CONVERGENCE-aware IP routers has not been defined yet for CONVERGENCE.
to treat IP datagrams containing CONVERGENCE messages 4) Mobility: In principle, CONVERGENCE supports sub-
differently. scriber mobility exactly as in NDN, i.e., by having subscribers
1) Naming: In CONVERGENCE object names consist issue new I NTEREST messages after a handoff. However,
of a namespace ID and a name part, whose format is the efficiency of CONVERGENCE in supporting subscriber
determined by the namespace ID. While the default format mobility is questionable, as it decouples forwarding infor-
of CONVERGENCE names is similar to that in DONA, i.e., mation from BNs. More specifically, in NDN the re-issued
a flat P:L pair [67], hierarchical names may also be used I NTEREST messages are suppressed when they reach the first
as in NDN [68], or even URLs. The exact properties of the BN that had received a previous such message. This does
names depend therefore on the specific namespace used. Since not apply to CONVERGENCE, since BNs do not maintain
CONVERGENCE is most similar to NDN, we assume in the per I NTEREST state. Therefore, pre-handoff and post-handoff
following the use of hierarchical names. I NTEREST messages are treated separately by the network,
propagating all the way to the publisher, where they trigger
6 While the architecture is most frequently referred to as CONET, we use independent (and duplicated) DATA messages in response.
again the project’s name (CONVERGENCE) as for the other ICN efforts. Publisher mobility on the other hand requires updating the
NRS
(4)
(5)
IN
(3) (2)
(8) (9)
) Router
(6 (1
BN A BN B )
)
(7 (1
0)
4-5 Name Lookup

1-3, 6 Interest
Publisher 7-10 Data
Subscriber
Fig. 8. The CONVERGENCE architecture. NRS stands for Name Resolution System, BN for Border Node, IN for Internal Node.
NRS, whose overhead is unknown, as noted above. unique GUID, and if an entity (e.g., video file) is available
5) Security: CONVERGENCE adopts the per DATA mes- in multiple network locations, then all of its copies will have
sage security approach of NDN, i.e., each DATA message the same GUID. By naming all network entities, MobilityFirst
contains a digital signature. Due to the large overhead of the can support both name-based information delivery (via infor-
meta-data required for signature verification, DATA messages mation GUIDs) and host-to-host communication (via device
are expected to be much larger than carrier packets, e.g., IP GUIDs).
datagrams encapsulated in Ethernet frames. For this reason, 2) Name Resolution and Data Routing: In MobilityFirst
CONVERGENCE proposes performing security checks on all communication starts with GUIDs, which are translated
information only at the DATA message level at the subscriber, to network addresses in one or more steps, via a Global
leaving the BNs to only deal with the (smaller) carrier packets Name Resolution Service (GNRS) as shown in Figure 9. A
that cannot be individually authenticated [68]. publisher that wishes to make some information available asks
the naming service for a GUID and then registers the GUID
with its network address in the GNRS (arrow 1). A GUID is
G. MobilityFirst mapped via hashing to a set of GNRS server addresses, which
The MobilityFirst [38] project (see Figure 1), funded by the are contacted using regular routing [70]. When a subscriber
US Future Internet Architecture program, proposes a clean- wants to receive some information, it sends a G ET message
slate Future Internet architecture with an emphasis on treating that includes the GUID of the requested object, along with its
mobile devices as first-class citizens [69]. As a result, Mobil- own GUID for the response, to its local Content Router (CR)
ityFirst provides detailed mechanisms to handle both mobility (arrow 2). The CR can only route based on actual network
and wireless links, as well as multicast, multi-homing, in- addresses, e.g., IP addresses, hence it asks the GNRS for
network caching and security. The basis of the MobilityFirst a mapping between the destination GUID and one or more
architecture is the separation of names for all entities attached network addresses (arrow 3). The GNRS replies (arrow 4)
to the network (including information objects, devices and with a set of network addresses (optionally it may also send
services) from their network addresses: each entity has a a source route, a partial source route and/or intermediate
globally unique name, which can be translated into one or network addresses). The CR selects one of these network
more network addresses at various points in the network, thus addresses, adds it to the G ET message, which it then forwards
allowing messages to be dynamically redirected in order to using the regular routing tables in the CRs (arrows 5-6 and
follow a mobile device or content. 9). The GET message includes both the destination GUID
1) Naming: Each network entity in MobilityFirst is as- and the destination network address, and any CR along the
signed a Globally Unique Identifier (GUID) via a global nam- path can consult the GNRS to receive an updated list of
ing service that translates human-readable names to GUIDs. network addresses for the destination GUID (arrows 7-8) if,
Every device in MobilityFirst must obtain GUIDs for itself, its for example, due to mobility the GET message cannot be
information objects, and its services. GUIDs are flat 160-bit delivered to the publisher. The publisher sends its response
strings with no semantic structure and they may be randomly to the subscriber’s GUID, using the same procedure (arrows
selected, since their length ensures that the probability of a 10-13).
collision is small. Alternatively, GUIDs can be self-certifying The resulting name resolution and data routing process is a
hashes of information objects, thus allowing information in- hybrid between IP routing and name-based routing. The actual
tegrity verification, or hashes of public keys, thus binding routing is performed based on network addresses, with the
devices to principals. Each network attached entity has a GNRS only used to map GUIDs to network addresses. For
Global Name
Resolution Service GNRS
GNRS
GNRS
(1)
(7)
(8)
(3)
(4)
(6) (9)
) (11) (10)
( 2) (5 CR Publisher
Subscriber
CR
(13 2)
) (1
Core Network
CR
Link
(1) Register Message
(2, 5, 6, 9) Request
(3, 4, 7, 8) Resolve GUID to Locator Request/Response
(10-13) Data
Fig. 9. The MobilityFirst architecture. GNRS stands for Global Name Resolution Service, CR for Content Router.
less dynamic services, MobilityFirst can translate each GUID a network attached object changes its point of attachment. No
to a network address once, as with DNS, and operate based on routing level indirections such as those performed in mobile
network addresses only, ignoring the GUID. For more dynamic IP are required. Network mobility is supported at lower levels
services, the GUID may be translated multiple times; the first and another distributed protocol (analogous to BGP) can be
router (optionally, others too) asks the GNRS for the network utilized for disseminating routing updates. While BGP can
addresses bound to a given GUID and makes forwarding be used for inter-domain routing, a storage-aware routing
decisions based on the reply from the GNRS. Forwarding mechanism can be employed at the intra-domain level in order
can thus be “fast path”, when the GNRS is bypassed, or to best support networks where disconnections due to mobility
“slow path”, when routers (re-)consult the GNRS in order to and variable link conditions are prevalent, by exploiting local
obtain an updated list of network addresses. This late binding storage, as in delay-tolerant networking [71].
or re-binding is especially useful for mobile destinations. 5) Security: MobilityFirst envisions a decentralized trust
Note that each message is delivered separately, i.e., the G ET model for name certification, where independent naming or-
message and the information object sent in response to it ganizations exist (e.g., one per country or one per institute) for
are individually routed based on their destination GUIDs, mapping human-readable names to GUIDs. The GUID of an
therefore name resolution and data routing are decoupled in entity can be securely bound to that entity via cryptographic
MobilityFirst. techniques, thus enabling traffic accountability. On the other
3) Caching: MobilityFirst supports on-path caching by hand, users can frequently request a new GUID to avert
opportunistically caching passing messages at intermediate profiling.
CRs, thus allowing subsequent requests for the same GUID to
be answered with the locally cached copy. In addition, each IV. C OMPARISON OF A PPROACHES
time an information object is cached off-path or replicated, The ICN architectures discussed in Section III have both
the GNRS is informed of the change in order to update similarities and differences in the way they implement the
the corresponding GUID entry with the additional network key ICN functionalities. In addition to summarizing the most
addresses. While the GNRS can be repeatedly consulted as salient characteristics of each ICN architecture in Table I,
a message travels through the network, this is a “slow-path” in this section we provide a more detailed analysis and
operation, and each CR can implement its own policy on when comparison of the different design choices.
to consult with the GNRS for additional cached copies.
4) Mobility: In MobilityFirst the aim is to address host, A. Naming
information, and entire network mobility. Host mobility is The naming of information objects and services is one of the
primarily handled by the GNRS, which must be updated when fundamental design choices in each ICN architecture, since the
TABLE I
I MPLEMENTATION OF KEY FUNCTIONALITIES IN ICN ARCHITECTURES .
Name Resolution and

Naming Caching Mobility Security
Data Routing
Resolution handlers Subscriber
On-path caching
organized following AS mobility via Principal is hash
at resolution
hierarchy. new requests. of public key.
Flat, consisting handlers. Off-
Coupled: A source-route is Publisher Label can be
DONA of principal and path caching
created during resolution. mobility hash of
label part. requires
Decoupled: Resolution requires immutable
additional
handlers return network additional content.
registrations.
address. registrations.
On-path caching Subscriber
Routing protocol used to
at content mobility via Signatures
flood name prefix
Hierarchical, routers. Off- new requests. included in
information.
may contain path caching Interest packets.
NDN Coupled: Routing state for
publisher- requires flooding Certification
data is established at
specific prefix. additional protocol for chain can follow
routers during request
routing publisher name hierarchy.
propagation.
information. mobility.
DHT-based rendezvous
Subscriber
network matches On-path caching
mobility via Packet level
Flat, consisting subscriptions to difficult due to
new requests. authentication
of scope and publications. Scopes can decoupled
Publisher for individual
rendezvous part. be used to limit operation. Off-
PURSUIT mobility packets. Names
Scopes may be publication/resolution. path caching
requires can be
organized Decoupled: topology requires
updating the optionally self-
hierarchically. management and additional
topology certifying.
forwarding are separated registrations.
manager.
from rendezvous.
Coupled: requests On-path caching Subscriber
Flat-ish names,
accumulate routing state at content mobility via
consisting of
during name resolution. routers. Off- new requests.
authority and
Decoupled: DHT-based path caching Support for Names can be
local part.
SAIL name resolution returns requires publisher optionally self-
Possible name
content locator. additional mobility via certifying.
aggregation for
Hybrid: name resolution routing routing hints in
the same
returns routing hints to information or hybrid
authority.
assist coupled operation. registrations. operation.
Unspecified. Specialized
Coupled: DONA-like Probabilistic on-
Names produced mobility-aware Unspecified, but
resolution but forwarding path caching at
by name content routers explicitly
state is installed in content content routers.
resolution system at access aggregatable
COMET routers during resolution. Off-path
which creates network that names make
Scoping/filtering used to caching requires
aggregatable exchange self-certification
limit additional
names for related mobile context impossible.
publication/resolution. registrations.
content. state.
Name prefixes cached at
On-path caching Subscriber
content routers,
at content mobility via
unspecified name
Either flat or routers. Off- new requests. Signatures
resolution system for non-
hierarchical, path caching Publisher included in
cached prefixes.
CONVERGENCE most work based relies on mobility relies objects larger
Coupled: Interest
on hierarchical. unspecified on unspecified than packets.
messages accumulate
name resolution name resolution
routing state during name
system. system.
resolution.
Hash –based global name
Subscriber and
resolution service to map On-path caching
publisher
names to network at content
mobility via late
Flat, consisting addresses, may be used routers. Off- Names can be
binding to first
MobilityFirst of a single repeatedly for late binding path caching optionally self-
reach the
component. of addresses. requires certifying.
mobile’s area
Decoupled: requests and additional
and then find
data are independently registrations.
the mobile.
resolved and routed.
structure of names and their semantics have a profound impact prefixes in the routing tables, but this requires an external
on all other aspects of the architecture. The main choices are name resolution system, which would face the same scalability
hierarchical or flat names, and there is an ongoing debate on problems.
the merits of each approach [40]. For ICN architectures based on flat names on the other
The main argument for hierarchical names is that they allow hand, the main issue in name resolution is how to handle a
the system to scale via aggregation. This is an especially huge naming space that cannot be aggregated. In DONA and
critical issue if we consider the number of named objects COMET name resolution state is accumulated as we move
that will need to be supported, which are estimated between towards tier-1 ISPs, requiring the top-level resolution servers
1013 and 1015 [61], which is way beyond what current to store huge amounts of data, especially in DONA which
systems, e.g., DNS or BGP, can handle. NDN, which uses replicates everything at the top level [51]. COMET tries to
hierarchical names for all resolution and routing decisions, partially mitigate this by using scoping to limit the propagation
assumes that extensive name aggregation will be applied in of name resolution information; it also proposes creating
content routers (especially at the core) in order to reduce explicitly aggregatable names to reduce state requirements,
routing table sizes. However, to achieve significant name but these names cannot be self-certifying. PURSUIT relies on
aggregation, names must be allocated in a manner that reflects a hierarchical DHT to spread this load, at the cost of inflating
the actual network topology. For example, consider content name resolution paths, routing policy violations and reliance
router A in Figure 3. Its routing entries indicate that all on external name resolution servers for local information [50],
names with the prefix /aueb.gr/ are reachable via content [51]. SAIL relies on a two level (local and global) DHT
router C, with the exception of the /aueb.gr/cs prefix solution in order to always locally resolve requests for global
which is reachable via content router B. Assume now that a information, at the cost however of binding names to specific
new prefix /aueb.gr/db is announced to content router AS’s [61]. MobilityFirst distributes the name resolution ser-
A. If it is reachable via content router C, then it will be vice by using a hashing scheme to determine the address of a
aggregated with the existing entry for /aueb.gr/, but if name resolution server for each GUID, relying then on regular
it is reachable via content router B, then a new routing entry routing to reach this server; this however requires that all AS’s
will be required, as it cannot be aggregated with the entry for in the world implement the same scheme [70].
/aueb.gr/cs. This shows that either all names with the Another proposed approach is to explicitly aggregate flat
same prefix must point at the same area, or the prefix will not names [40]. In this approach, a request contains a series of
be aggregatable. Unfortunately, binding names to locations has concatenated flat names, e.g., A.B.C, and routing decisions
been identified as one of the main shortcomings of the current are based on a deepest match: the router searches for matches
Internet architecture with respect to mobility support, and there in its routing table from right to left. In the above example,
are several pre-ICN proposals for decoupling object names a router would first look up C, if that failed it would look up
from topological addresses [72], [73], [74]. Therefore, the B, and so on. Explicit aggregation allows reducing the size of
exact benefits of hierarchical name aggregation to scalability routing tables, e.g., an entry for A is enough for addressing
are debatable. requests for A.B.C, as long as users include A as a routing
The main argument for flat names is that they avoid this hint in their request.
location-identity binding, thus simplifying mobility. However, The approaches to data routing taken by ICN architectures
flat names are not easy to aggregate, thus requiring either have already been classified as coupled or decoupled from
huge routing and/or name resolution tables, or complicated name resolution. In the coupled approaches, routing informa-
and costly solutions like DHTs, as discussed in the following tion is accumulated during name resolution, therefore data are
section. In addition, these data structures also need to be normally forwarded by reversing the path taken by requests,
updated whenever information moves. while in the decoupled approaches the request and data paths
Another aspect of the debate between hierarchical and flat may be totally different. The exact details however vary greatly
names is that the former can be human-readable while the between ICN approaches. Among the coupled approaches,
latter can be self-certifying; unfortunately, one cannot have NDN and COMET install forwarding information in content
both [40]. For example, NDN has to rely on an external routers as requests are resolved towards the publisher, while
trust mechanism to bind signed information to human-readable CONVERGENCE and the coupled variants of DONA and
names [47], while MobilityFirst has to rely on an external SAIL accumulate this information in the request packets
naming system to bind human-readable names to GUIDs [69]. themselves and then rely on source routing to return the
corresponding data to the subscribers. As a result, in the first
case the data routing state is maintained in the content routers,
B. Name Resolution and Data Routing while in the second case the data routing state is included in
For ICN architectures based on hierarchical names, the the data packets themselves.
main issue in name resolution is how to scale the system Among the decoupled approaches, the decoupled versions
without requiring location-identity binding. Initial work on of DONA and SAIL rely on the name resolution system to
NDN suggests using ISP-provided names as prefixes for return an IP address for the desired information, which can
achieving name-aggregation, since there is yet no clear way to then be reached via regular IP routing; multiple addresses may
avoid this without losing the scalability benefits of hierarchical be returned if the information is available at many locations.
aggregation [75]. CONVERGENCE tries to bypass the scal- PURSUIT uses an independent topology management entity
ability problem by caching only a limited number of name to calculate data routing paths, which are encoded in Bloom
filters that are used as source routes; Bloom filters however need to be updated, but it is unclear how this could be
do not scale to Internet sizes and suffer from false positives as achieved economically, as the routing protocols proposed for
more links are added to them [53]. MobilityFirst relies on a advertising name prefixes are based on flooding. MobilityFirst
very fast name resolution system to iteratively retrieve network also faces problems in this area, as it relies on a global lookup
addresses [70], starting with general directions and ending mechanism for name resolution, therefore it is unclear how
with specific addresses, so as to best support mobility. In locally cached copies can be advertised only within an AS.
addition, MobilityFirst treats requests and data in a symmetric
manner, thus simplifying subscriber and publisher mobility. D. Mobility
We note that, independent of the exact details of how name
The location-identity split in ICN approaches and the state-
resolution and data routing are performed, decoupling name
less nature of the publish/subscribe paradigm can potentially
resolution and data routing allows more flexibility in how each
facilitate the support of mobility. In practice however, the
function is implemented, allowing, for example, different paths
situation is not that simple. In some approaches the location-
to be used for signaling (control) traffic and data traffic.
identity split may be partial for scalability purposes, e.g., in
NDN; in others, the cost of looking up network addresses
C. Caching may be too high for fast moving objects, e.g., in DONA.
Furthermore, while individual requests for information objects
Caching is a fundamental feature of ICN architectures, as
can be issued from different locations, mobility during the
information awareness allows the network to identify cached
reception of a simple object remains a problem, something
information without resorting to the application layer, as in
more likely to occur with larger information objects.
Web caching. In on-path caching, when a router receives a
Supporting subscriber mobility is generally simpler. In the
request for a piece of information it responds with a locally
worst case, the subscriber will just issue new requests for
cached copy, without involving the name resolution system.
information, wasting any resources spent on pending trans-
In off-path caching, caches announce their information to
missions. This is the most sensible approach in the decoupled
the name resolution system, so that they may be matched
versions of DONA and SAIL, where the name resolution
to information requests that would not normally reach them,
system returns the network addresses of the host carrying the
essentially becoming alternative information publishers. On-
requested content. In NDN and COMET on the other hand,
path caching is generally opportunistic, i.e., routers cache
re-issued requests will eventually cross paths with the state
information that happens to flow through them, while off-path
left in content routers by the old requests, thus redirecting
caching can also be used to actively replicate information, as
the pending information to the new location of the mobile
in CDNs.
subscriber. ICN architectures based on source routing require
While all ICN architectures natively support on-path
routes to be patched after a mobile moves, to point at its new
caching in principle, when name resolution and data routing
location. This may not be very efficient, but it is relatively easy
are decoupled there are less opportunities to exploit oppor-
in CONVERGENCE and the coupled variants of SAIL and
tunistic caching, as the name resolution path generally differs
DONA where each part of the path is visible. It is trickier in
from the data routing path: while the information can be
PURSUIT where links are encoded into a Bloom filter, as it is
opportunistically cached on the data routing path, subsequent
easy to add links to the Bloom filter, but hard to remove them.
requests for the same information follow the (different) name
MobilityFirst offers the most flexible solution, as it relies on a
resolution path, reducing the possibility for a cache hit. When
series of resolution steps to delay binding a mobile’s identity
name resolution and data routing are coupled on the other
with its current address as much as possible, thus allowing
hand, if data is cached on the data routing path it will result
mobiles to only update their location in their local area.
in a cache hit when subsequently requested over the same
Publisher mobility requires updating the name resolution
name resolution path. Opportunistic caching can range from
system with the new location of the mobile publisher. Unlike
the “cache everything” approach of NDN, to the probabilistic
off-path caching where we would prefer caches to only be
caching approach of COMET [44], [45].
advertised locally, with publisher mobility the information
In off-path caching (and replication), beyond the more
needs to be globally available. While updating the name
general problem of choosing what to cache and where [55],
resolution system can be a costly operation, it can be kept
the main issue is how to reduce the overhead required in order
within the local area in systems supporting late binding of
to inform the name resolution system when new items are
information to location, such as MobilityFirst and the hybrid
cached or old items are discarded. The exact details depend
variant of SAIL. Note that the hybrid variant of SAIL only
on the name resolution scheme used, but one common goal is
applies late name binding to requests, not data, hence it cannot
to keep updates local, e.g., within an AS, so as to reduce
be used to handle subscriber mobility.
signaling overhead and only serve customers from within
that AS. In DONA and COMET cached information can be
advertised only within an AS and not propagated upwards in E. Security
the AS hierarchy (COMET provides the scope mechanism for All ICN architectures identify security as a fundamental
this purpose). Similarly, in the decoupled version of SAIL problem of the current Internet architecture. The primary focus
and in PURSUIT cached information can only be advertised of the proposed architectures is on information confidentiality
within the local DHT of an AS. In NDN, CONVERGENCE and integrity, as opposed to the channel confidentiality and
and the coupled version of SAIL, the name prefix tables integrity of IP based solutions. Content confidentiality and
integrity are achieved by using cryptographic mechanisms ICN, the identification of traffic types (and of any other meta-
either combined with data included in the information name, information related to a flow) may constitute standard network
as in DONA, or associated with the information using meta- functionality, thus unveiling sensitive information not only to
data, as in NDN. As we explained above, each approach ISPs, but also to potential attackers.
requires an external trusted system to complete the binding
between a human-readable name, a name for the information B. Name Resolution
and the information itself. Most ICN architectures rely on
The vast size of the naming space poses a significant scala-
self-certifying names, as these allow any network node to
bility challenge for name resolution. DHT based designs have
verify that the name in a packet matches the information
attracted the attention of researchers due to their logarithmic
inside it, leaving to the user the problem of determining
scalability. The routing policy violations and inflated path
whether this information is actually what was desired. While
lengths of DHTs have resulted in hierarchical schemes that
both hierarchical and flat names can be transformed to self-
try to adapt the structure of the name space to the underlying
certifying names, this process is easier when the latter are
inter-domain network topology [76], but the routing efficiency
used, hence all systems supporting flat names generally allow
of these approaches is still lacking [51]. Moreover, recent
self-certifying names to be used.
studies on the structure of the inter-domain graph suggest that
the increase of peering relationships between AS’s gradually
V. O PEN I SSUES IN ICN leads to a mesh-like inter-domain graph [77], [78], therefore,
In this section we identify a series of issues and problems employing a strictly hierarchical structure for the organization
that have either not been satisfactorily addressed or have not of the name space does not seem to reflect reality. Another
even been tackled by the ICN research community so far. recently proposed approach is to use hashing to map names
directly to IP addresses and rely on IP routing to find the re-
A. Naming solvers [70], but this requires global participation in the name
resolution system. Hence, a flexible and practical approach,
There is no clear consensus yet on whether hierarchical
able to express the dynamically evolving routing relationships
or flat names should be used. Hierarchical names can be
between AS’s, is still lacking.
human-readable and are easier to aggregate in principle, but
it is unclear whether they can scale to Internet levels without
turning into DNS names due to aggregation. On the other C. Data Routing
hand, flat names are easier to administer, they do not impose While a lot of effort has been devoted to the design of
processing requirements for longest prefix matching, they can routing mechanisms for the intra-domain level, e.g., [53], little
be self-certifying and they can be easily handled with highly attention has been paid to the inter-domain level. Inter-domain
scalable structures such as DHTs, but it is unclear whether routing is strongly affected by business relationships between
DHTs can offer satisfactory performance. the involved parties and is an area of active research even
There has been practically no research on incorporating in the context of the current Internet architecture [79]. In the
versioning, deletion and revocation of information objects ICN area, the main issue is scaling the proposed solutions to
to the naming structure, and only preliminary work on the Internet sizes. As shown in [80], the content routers in NDN
optimal granularity of information objects (i.e., an object could face serious scalability limitations at the inter-domain level,
correspond to a packet, to variable-sized information chunks or something that also applies to some extent to COMET, which
to entire application-level objects). Indeed, some work argues also installs forwarding state at routers.
that performing signature checks on individual packets may In the PURSUIT architecture which uses in-packet Bloom
have excessive overhead [68], while other work argues that filters for source routing, the most obvious issue is that
this is feasible with hardware-level implementations [57]. longer paths (or larger multicast trees) lead to many false
Searching for information has also not received much positives, i.e., wasted packet transmissions [53]. Since larger
attention in ICN research, something rather peculiar, given Bloom filters would introduce much higher overhead, ideas
that most projects rely on flat names that have to be some- such as Bloom filter switching [81] and variable-sized Bloom
how discovered by human users. Information-awareness may filters [82] have been explored. But the real problem is
provide the means for efficient searching, possibly taking establishing inter-domain paths, since it is unrealistic to expect
into account meta-information such as contextual parameters, topology managers to have a global view of the network, due
location, information type, language, etc. For example, SAIL to both the size of the Internet and the limited information
envisions an extended name resolution system that integrates exchanged between AS’s. This means that a hierarchical de-
meta-information to the resolution process [60]. As informa- composition of the inter-domain routing problem is required,
tion is the primary entity in ICNs, it is possible for this coupled with Bloom filter switching between the AS’s, to keep
meta-information to co-exist with the actual information inside topology management local and path lengths short [81], [83].
the network, thus allowing the intelligent manipulation of On the other hand, in the architectures where source routes
traffic for other purposes, such as for enabling geocasting are accumulated during name resolution, such as CONVER-
and flow prioritization. However, the availability of such GENCE and the coupled variants of DONA and SAIL, the
meta-information also raises significant concerns regarding main issue is the amount of overhead introduced in both
network neutrality. Earlier attempts to throttle certain types request and data packets as these routes grow larger. Mobility-
of traffic (e.g., P2P) were based on DPI techniques. With First and the decoupled variants of DONA and SAIL basically
rely on IP routing, with the possibility of additional resolution F. Security, Privacy and Trust
steps in MobilityFirst and the hybrid variant of SAIL. This
Security in all ICN architectures is based on using encryp-
means that they do not introduce any new problems, but they,
tion with keys associated with the information name. Little
at least partially, inherit the existing problems of IP routing.
work exists however on how these keys will be managed, i.e.,
who will be responsible for creating, distributing and revok-
D. Caching ing those keys. The need for key management mechanisms
becomes of paramount importance if we consider the fact
Mechanisms for caching (and replication) have been widely that most ICN approaches rely on cryptographic keys and
studied at the application level, mostly in the context of trusted entities for information-name verification [40], [47].
web applications. It has been recently advocated that the Moreover, most of the proposed ICN architectures envision
benefits from the extensive use of caching in ICN will not access control mechanisms, nevertheless there is very little
be substantial [27]. Although they raise serious concerns work on the definition of access control policies, the applica-
about the performance of the envisioned caching mechanisms, tion of access control policies to cached information and the
these observations are mostly based on studies performed authentication of users (e.g., [88], [89]).
more than a decade ago [84]. Additional research on current ICN architectures can create severe privacy threats, as users
traffic patterns could shed additional light on the popularity reveal their interest in particular information and the name of
characteristics of information today and thus to the possible the information being requested is available to all the ICN
benefits from widespread caching. For instance, a recent nodes processing the request [27]. A convincing solution for
study has shown that web information popularity has changed this threat has not been provided yet. Finally, efficient mech-
during the past few years, affecting application level caching anisms for building trust relationships and handling privacy
performance [85]. tussles amongst the various stakeholders are envisioned in ICN
Another issue is that when caching takes place inside the architectures (e.g., [90]), yet this still remains an open issue.
network, as in ICN, several types of traffic will compete for the
same caching space. Cache space management therefore be-
comes crucial for the network, and recent works, albeit based G. Transport
on simplified traffic models, have indicated that intelligent
schemes can substantially improve performance [45], [44], The information awareness in ICN architectures enables
[86]. Moreover, the deployment of caching and replication a series of new mechanisms and functionalities inside the
mechanisms inside the network opens up the possibility of network that make data transport a more complicated process
jointly optimizing routing, forwarding and in-network cache than in the current end-to-end model. Mechanisms such as
management. For instance, routing decisions could be affected in-network caching and replication offer the opportunity for
by cache locations, the cache-ability of information and/or exchanging bandwidth with storage, thus radically changing
indications of cache contention. the transport layer. Moreover, new delivery modes such as
multicast (i.e., one-to-many) and concast (many-to-one), the
ability of the network to apply anycast, as well as the support
E. Mobility for multi-path routing in several ICN approaches, offer a rich
set of mechanisms affecting the design of flow, congestion
Though identified as a major shortcoming of the current In- and error control functions. However, the fact that ICN ar-
ternet architecture, network support for mobility has received chitectures are still under active development, complicates
very limited attention in ICN efforts (e.g., [46], [56]). Past research in the area. Recent efforts have started to investigate
research efforts on the support of mobility in the context the interaction of these mechanisms (e.g., [91], [92], [93]),
of publish/subscribe systems [28] and on multicast-assisted which is however far from being well-understood.
mobility [87] have contributed to the understanding of the
emerging issues. This work, coupled with the native ICN
support for caching and multicast, has been leveraged to assist H. Quality of Service
mobility in PURSUIT [54]. However, publisher (and, there-
fore, information) mobility remains a major challenge, since Most ICN initiatives devote some thought to Quality of
most ICN architectures use name resolution systems that are Service (QoS) provisioning. Nonetheless, only a few of them
slow to update, whether they are name-based routing tables, provide details about practical QoS mechanisms, while the
hierarchical DHTs or hierarchical resolution handlers. The use rest treat the issue superficially. The most extensive treatment
of source routes, that may become invalid even as they are of QoS issues is in the COMET architecture which defines
formed, is an additional complication. Even more problematic three Classes of Service (CoS) used to prioritize end-to-end
is the use of name aggregation in routing tables, as it implicitly information traffic. COMET maps the delivery requirements of
reintroduces a location-identity binding. The most promising the information as expressed by a CoS into the network paths
approach in this area is the late name binding advocated by offered by each AS via a path provisiong process [65]. Some
MobilityFirst and the hybrid variant of SAIL, which simplify work has also been performed on exploiting the centralized
mobility management without losing the advantages of flat topology management and source routing of PURSUIT to im-
names. The performance of these schemes in practical and plement routing algorithms that are infeasible with distributed
large scale scenarios remains to be seen, however. routing, such as Steiner tree-based multicasting [94].
I. Business and Deployment Aspects proposals by defining a set of core ICN functionalities, e.g.,
Taking a step away from technical issues, a series of naming, name resolution and data routing, caching, mobility
questions need to be answered with regard to the business and security. We presented seven ICN architectures, explain-
aspects of ICN. To name but a few: Who are the new actors ing their general goals and operation, as well as how they
enabled by ICN architectures? How are the roles/relationships implement each of these functionalities, culminating with a
between current actors of the Internet ecosystem going to be comparative analysis of the various design choices in each of
affected? Which are the application domains to target first? these areas. This led to a discussion of the open issues for ICN
Should overlay or native ICN solutions be deployed first? For architectures, not only in the core functionalities, but also in
example, CDNs already provide several features of the ICN other areas that, while important, have so far received much
paradigm at an overlay level. It is not clear however how less attention from the majority of ICN efforts.
CDNs would possibly fit in an ICN world, as a major part As a final conclusion, we can state that ICN is a promising
of their functionality would be provided by the network itself. and fertile research field that has shown its potential for
A first attempt to perform a socio-economic analysis of an addressing at least some of the current problems of the
ICN architecture was performed in the PSIRP project [95]. Internet, but mostly in a qualitative way so far. There is,
According to its findings the logical order of markets to target therefore, an urgent need for further research and quantitative
would be government, business ICT, and information-centric studies for evaluating the benefits and potential performance
applications. This is because the business opportunities in gains brought by this new architectural paradigm, as well as
the government sector can be satisfied with the adoption of for additional work in hitherto neglected areas that are however
purely overlay mechanisms, which entail a smaller overall crucial for the applicability and viability of the ICN paradigm.
cost compared to the adoption of native mechanisms. On the
other hand, native mechanisms are necessary to fully exploit
R EFERENCES
the business opportunities related to the business ICT sector.
Finally, the investment in information-centric applications is [1] M. Handley, “Why the Internet only just works,” BT Technology J.,
strongly dependent on traffic volumes, which in turn depend vol. 24, no. 3, pp. 119–129, July 2006.
[2] J. Rexford and C. Dovrolis, “Future Internet architecture: clean-slate
on the widespread access to applications, and hence requires a versus evolutionary research,” Commun. ACM, vol. 53, no. 9, pp. 36–
widespread deployment of the new architecture. According to 40, September 2010.
the same analysis, the adoption of an ICN architecture should [3] P. Stuckmann and R. Zimmermann, “European research on future
Internet design,” IEEE Wireless Commun., vol. 16, no. 5, pp. 14–22,
start with the adoption of overlay mechanisms in the current October 2009.
Internet, followed by the adoption of native mechanisms on the [4] J. Pan, S. Paul, and R. Jain, “A survey of the research on future Internet
network backbone. The adoption of such native mechanisms architectures,” IEEE Commun. Mag., vol. 49, no. 7, pp. 26–36, July
2011.
should start from the business ICT sector. Issues like billing,
[5] J. Choi, J. Han, E. Cho, T. Kwon, and Y. Choi, “Survey on content-
costing and invoicing for ICN traffic however remain open. oriented networking for efficient content delivery,” IEEE Commun.
With regard to deployment, it is clear that an incremental Mag., vol. 49, no. 3, pp. 121–127, March 2011.
transition into ICN is needed, so as to maintain compatibility [6] B. Ahlgren, C. Dannewitz, C. Imbrenda, D. Kutscher, and B. Ohlman,
“A survey of information-centric networking,” IEEE Commun. Mag.,
with TCP/IP-based applications for an extended period. Al- vol. 50, no. 7, pp. 26–36, July 2012.
though such a transition is straightforward for overlay ICN [7] Cisco. (2011, June) Visual networking index: Forecast and
solutions, it is not well understood how it can be achieved methodology, 2010-2015. White Paper. [Online]. Available:
http://www.cisco.com/go/vni
for the case of clean-slate ICN solutions. In addition the [8] Google. (2008, July) We knew the web was big. [Online]. Available:
ICN community has not reached a consensus on several http://googleblog.blogspot.com/2008/07/we-knew-web-was-big.html
fundamental design choices (e.g., routing and forwarding in [9] M. Gritter and D. R. Cheriton, “An architecture for content routing
support in the Internet,” in USENIX Symposium on Internet Technologies
NDN vs. PURSUIT) hence there are several architectures and Systems (USITS), 2001.
proposed, each fitting the requirements of different networking [10] Stanford University TRIAD project. [Online]. Available: http://www-
environments and/or business scenarios. It is therefore possible dsg.stanford.edu/triad/
[11] A. Carzaniga and A. L. Wolf, “Content-based networking: A new
to reach a state where multiple different ICN architectures will communication infrastructure,” in NSF Workshop on an Infrastructure
be deployed in parallel and interoperability issues may arise. for Mobile and Wireless Systems, 2001, pp. 59–68.
[12] ——, “Forwarding in a content-based network,” in ACM SIGCOMM,
VI. C ONCLUSIONS 2003, pp. 163–174.
[13] A. Carzaniga, M. J. Rutherford, and A. L. Wolf, “A routing scheme for
We have attempted to provide an in depth survey of the content-based networking,” in IEEE INFOCOM, 2004, pp. 918–928.
ICN research landscape. As a first step, we identified a series [14] I. Stoica, D. Adkins, S. Zhuang, S. Shenker, and S. Surana, “Internet
of issues in the current Internet architecture that motivate a indirection infrastructure,” in ACM SIGCOMM, 2002, pp. 73–86.
[15] J. Kubiatowicz, D. Bindel, Y. Chen, S. Czerwinski, P. Eaton, D. Geels,
fundamental rethinking of how the Internet should operate in R. Gummadi, S. Rhea, H. Weatherspoon, W. Weimer, C. Wells, and
order to cope with new and emerging requirements. Several B. Zhao, “Oceanstore: an architecture for global-scale persistent stor-
ICN architectures have been proposed to address some of age,” ACM SIGPLAN Notices, vol. 35, no. 11, pp. 190–201, November
2000.
these requirements, such as the need for efficient information [16] M. Caesar, M. Castro, E. B. Nightingale, G. O’Shea, and A. Rowstron,
delivery and mobility support. We have shown how ICN “Virtual ring routing: network routing inspired by DHTs,” in ACM
research has developed in the last decade, with a major bloom SIGCOMM, 2006, pp. 351–362.
of related activities taking place during the last five years. [17] M. Caesar, T. Condie, J. Kannan, K. Lakshminarayanan, and I. Stoica,
“ROFL: routing on flat labels,” in ACM SIGCOMM, 2006, pp. 363–374.
Even though the ICN related research area is still shaping, [18] S. Arianfar, P. Nikander, and J. Ott, “On content-centric router design
we made an effort to provide a unified view of the alternative and implications,” in ACM ReARCH, 2010.
[19] M. Diallo, S. Fdida, V. Sourlas, P. Flegkas, and L. Tassiulas, “Leveraging [50] J. Rajahalme, M. Särelä, K. Visala, and J. Riihijärvi, “On name-based
caching for Internet-scale content-based publish/subscribe networks,” in inter-domain routing,” Computer Networks, vol. 55, no. 4, pp. 975–986,
IEEE ICC, 2011, pp. 1–5. March 2011.
[20] European Community Future Internet Architecture (FIArch) [51] K. V. Katsaros, N. Fotiou, X. Vasilakos, C. N. Ververidis, C. Tsilopoulos,
Experts Group. (2011, March) Fundamental limitations of current G. Xylomenos, and G. C. Polyzos, “On inter-domain name resolution
Internet and the path to future Internet. [Online]. Available: for information-centric networks,” in Proc. IFIP-TC6 Networking Con-
http://www.future-internet.eu/publications/view/article/fundamental- ference, 2012.
limitations-of-current-internet.html [52] B. H. Bloom, “Space/time trade-offs in hash coding with allowable
[21] P. Wendell and M. J. Freedman, “Going viral: flash crowds in an open errors,” Communications of the ACM, vol. 13, no. 7, pp. 422–426, July
CDN,” in ACM Internet Measurement Conference (IMC), 2011, pp. 549– 1970.
558. [53] P. Jokela, A. Zahemszky, C. E. Rothenberg, S. Arianfar, and P. Nikan-
[22] Z. Wang, Z. Qian, Q. Xu, Z. Mao, and M. Zhang, “An untold story der, “LIPSIN: line speed publish/subscribe inter-networking,” in ACM
of middleboxes in cellular networks,” in ACM SIGCOMM, 2011, pp. SIGCOMM, 2009, pp. 195–206.
374–385. [54] G. Xylomenos, X. Vasilakos, C. Tsilopoulos, V. A. Siris, and G. C.
[23] A. Anand, A. Gupta, A. Akella, S. Seshan, and S. Shenker, “Packet Polyzos, “Caching and mobility support in a publish-subscribe Internet
caches on routers: the implications of universal redundant traffic elimi- architecture,” IEEE Commun. Mag., vol. 50, no. 7, pp. 52–58, July 2012.
nation,” in ACM SIGCOMM, 2008, pp. 219–230. [55] V. Sourlas, P. Flegkas, G. S. Paschos, D. Katsaros, and L. Tassiu-
[24] A. Anand, V. Sekar, and A. Akella, “SmartRE: an architecture for co- las, “Storage planning and replica assignment in content-centric pub-
ordinated network-wide redundancy elimination,” in ACM SIGCOMM, lish/subscribe networks,” Computer Networks, vol. 55, no. 18, pp. 4021–
209, pp. 87–98. 4032, December 2011.
[25] S. Seetharaman and M. Ammar, “Characterizing and mitigating inter- [56] N. Fotiou, K. Katsaros, G. Polyzos, M.Sarela, D. Trossen, and G. Xy-
domain policy violations in overlay routes,” in IEEE International lomenos, “Handling mobility in future publish-subscribe information-
Conference on Network Protocols (ICNP), 2006, pp. 259–268. centric networks,” Telecommunication Systems, to appear.
[26] P. T. Eugster, P. A. Felber, R. Guerraoui, and A. Kermarrec, “The many [57] D. Lagutin, “Redesigning Internet-the packet level authentication archi-
faces of publish/subscribe,” ACM Computing Surveys, vol. 35, no. 2, pp. tecture,” Licentiate Thesis, Helsinki University of Technology, Finland,
114–131, June 2003. 2008.
[27] A. Ghodsi, S. Shenker, T. Koponen, A. Singla, B. Raghavan, and [58] N. Fotiou, G. Marias, and G. Polyzos, “Fighting spam in pub-
J. Wilcox, “Information-centric networking: seeing the forest for the lish/subscribe networks using information ranking,” in Euro-NF Con-
trees,” in ACM Workshop on Hot Topics in Networks (HotNets), 2011. ference on Next Generation Internet (NGI), 2010.
[28] Y. Huang and H. Garcia-Molina, “Publish/subscribe in a mobile envi- [59] SAIL Project. (2013, January) SAIL deliverable B.3 (3.3):
ronment,” Wireless Networks, vol. 10, no. 6, pp. 643–652, November Final NetInf architecture. [Online]. Available: http://www.sail-
2004. project.eu/deliverables/
[29] T. Koponen, M. Chawla, B. Chun, A. Ermolinskiy, K. H. Kim, [60] ——. (2011, July) SAIL deliverable B.1 (3.1): The network
S. Shenker, and I. Stoica, “A data-oriented (and beyond) network of information: Architecture and applications. [Online]. Available:
architecture,” in ACM SIGCOMM, 2007, pp. 181–192. http://www.sail-project.eu/deliverables/
[30] FP7 PURSUIT project. [Online]. Available: http://www.fp7- [61] M. D’Ambrosio, C. Dannewitz, H. Karl, and V. Vercellone, “MDHT: a
pursuit.eu/PursuitWeb/ hierarchical name resolution service for information-centric networks,”
[31] FP7 PSIRP project. [Online]. Available: http://www.psirp.org/ in ACM Workshop on Information-Centric Networking (ICN), 2011.
[32] FP7 SAIL project. [Online]. Available: http://www.sail-project.eu/ [62] C. Dannewitz, M. DAmbrosio, and V. Vercellone, “Hierarchical DHT-
[33] FP7 4WARD project. [Online]. Available: http://www.4ward-project.eu/ based name resolution for information-centric networks,” Computer
Communications, vol. 36, no. 7, p. 736749, April 2013.
[34] FP7 COMET project. [Online]. Available: http://www.comet-project.org/
[63] G. Garcia, A. Beben, F. J. Ramon, A. Maeso, I. Psaras, G. Pavlou,
[35] FP7 CONVERGENCE project. [Online]. Available: http://www.ict-
N. Wang, J. Sliwinski, S. Spirou, S. Soursos, and E. Hadjioannou,
convergence.eu/
“COMET: Content mediator architecture for content-aware networks,”
[36] NSF Named Data Networking project. [Online]. Available: in Future Network & Mobile Summit, 2011.
http://www.named-data.net/
[64] W. K. Chai, N. Wang, I. Psaras, G. Pavlou, C. Wang, G. C. de Blas,
[37] Content Centric Networking project. [Online]. Available: F. Ramon-Salguero, L. Liang, S. Spirou, A. Beben, and E. Hadjioannou,
http://www.ccnx.org/ “CURLING: Content-ubiquitous resolution and delivery infrastructure
[38] NSF Mobility First project. [Online]. Available: for next-generation services,” IEEE Commun. Mag., vol. 49, no. 3, pp.
http://mobilityfirst.winlab.rutgers.edu/ 112–120, March 2011.
[39] ANR Connect project. [Online]. Available: http://anr-connect.org/ [65] COMET Project. (2011, December) COMET deliverable 3.2: Final
[40] A. Ghodsi, T. Koponen, J. Rajahalme, P. Sarolahti, and S. Shenker, specification of mechanisms, protocols and algorithms for the
“Naming in content-oriented architectures,” in ACM Workshop on content mediation system. [Online]. Available: http://www.comet-
Information-Centric Networking (ICN), 2011. project.org/deliverables.html
[41] V. Jacobson, “A new way to look at networking,” Google Tech Talk, [66] ——. (2011, December) COMET deliverable 4.2: Final specification of
August 2006. mechanisms, protocols and algorithms for enhanced network platforms.
[42] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, [Online]. Available: http://www.comet-project.org/deliverables.html
and R. L. Braynard, “Networking named content,” in ACM CoNEXT, [67] A. Detti, N. Blefari-Melazzi, S. Salsano, and M. Pomposini, “CONET:
2009. A content centric inter-networking architecture,” in ACM Workshop on
[43] V. Jacobson, D. K. Smetters, N. H. Briggs, M. F. Plass, P. Stewart, Information-Centric Networking (ICN), 2011.
J. D. Thornton, and R. L. Braynard, “VoCCN: Voice over content-centric [68] S. Salsano, A. Detti, M. Cancellieri, M. Pomposini, and N. Blefari-
networks,” in ACM ReArch Workshop, 2009. Melazzi, “Transport-layer issues in information centric networks,” in
[44] W. K. Chai, D. He, I. Psaras, and G. Pavlou, “Cache “less for ACM Workshop on Information-Centric Networking (ICN), 2012.
more” in information-centric networks,” in Proc. IFIP-TC6 Networking [69] A. Baid, T.Vu, and D. Raychaudhuri, “Comparing alternative approaches
Conference, 2012. for networking of named objects in the future Internet,” in IEEE
[45] I. Psaras, W. K. Chai, and G. Pavlou, “Probabilistic in-network caching Workshop on Emerging Design Choices in Name-Oriented Networking
for information-centric networks,” in ACM Workshop on Information- (NOMEN), 2012.
Centric Networking (ICN), 2012. [70] T. Vu, A. Baid, Y. Zhang, T. Nguyen, J. Fukuyama, R. Martin, and
[46] M. Meisel, V. Pappas, and L. Zhang, “Ad hoc networking via named D. Raychaudhuri, “DMap: A shared hosting scheme for dynamic iden-
data,” in ACM MobiArch, 2010. tifier to locator mappings in the global Internet,” in IEEE International
[47] D. Smetters and V. Jacobson, “Securing network content,” PARC, Tech. Conference on Distributed Computing Systems (ICDCS), 2012, pp. 698–
Rep. TR-2009-01, October 2009. 707.
[48] S. DiBenedetto, P. Gasti, G. Tsudik, and E. Uzun, “ANDaNA: Anony- [71] S. Nelson, G. Bhanage, and D. Raychaudhuri, “GSTAR: Generalized
mous named data networking application,” in Network and Distributed storage-aware routing for MobilityFirst in the future mobile Internet,”
System Security Symposium (NDSS), 2012. in ACM MobiArch, 2011.
[49] D. Trossen and G. Parisis, “Designing and realizing an information- [72] M. Walfish, H. Balakrishnan, and S. Shenker, “Untangling the web from
centric Internet,” IEEE Commun. Mag., vol. 50, no. 7, pp. 60–67, July DNS,” in Symposium on Networked Systems Design and Implementation
2012. (NSDI), 2004, pp. 225–238.
[73] H. Balakrishnan, K. Lakshminarayanan, S. Ratnasamy, S. Shenker, George Xylomenos is an Assistant Professor of

I. Stoica, and M. Walfish, “A layered naming architecture for the Computer Science at the Athens University of Eco-
Internet,” in ACM SIGCOMM, 2004, pp. 343–352. nomics and Business (AUEB) and a member of
[74] R. Moskowitz and P. Nikander, “Host identity protocol architecture,” the Mobile Multimedia Laboratory. He received
RFC 4423, May 2006. his B.Sc. in Informatics (1993) from AUEB, and
[75] L. Zhang, D. Estrin, J. Burke, V. Jacobson, J. D. Thornton, D. K. M.S. (1996) and Ph.D. (1999) degrees in Com-
Smetters, B. Zhang, G. Tsudik, k. claffy, D. Krioukov, D. Massey, puter Science from the University of California, San
C. Papadopoulos, T. Abdelzaher, L. Wang, P. Crowley, and E. Yeh, Diego (UCSD). His current research interests in-
“Named data networking (NDN) project,” PARC, Tech. Rep. NDN- clude information-centric network architectures and
0001, October 2010. protocols, multicast-based and peer-to-peer content
[76] G. Prasanna, G. Krishna, and H. Garcia-Molina, “Canon in G major: de- distribution, the provision of Quality of Service
signing DHTs with hierarchical structure,” in International Conference over wireless and mobile networks and real-time transport protocols for
on Distributed Computing Systems (ICDCS), 2004, pp. 263–272. multimedia. He has served on the program committee of various international
[77] C. Labovitz, S. Iekel-Johnson, D. McPherson, J. Oberheide, and F. Ja- conferences and workshops, including the ACM SIGCOMM Information-
hanian, “Internet inter-domain traffic,” in ACM SIGCOMM, 2010, pp. Centric Networking Workshop, and has participated in many EU funded FP6
75–86. and FP7 projects, including the pioneering PSIRP and PURSUIT projects
[78] R. Oliveira, D. Pei, W. Willinger, B. Zhang, and L. Zhang, which developed a clean-slate Future Internet architecture based on pub/sub.
“The (in)completeness of the observed Internet AS-level structure,”
IEEE/ACM Trans. Netw., vol. 18, no. 1, pp. 109–122, February 2010.
[79] M. Yannuzzi, X. Masip-Bruin, and O. Bonaventure, “Open issues in
interdomain routing: a survey,” IEEE Network, vol. 19, no. 6, pp. 49–
56, November-December 2005. Christopher N. Ververidis is an experienced
[80] D. Perino and M. Varvello, “A reality check for content centric net- telecommunications and wireless networks re-
working,” in ACM Workshop on Information-Centric Networking (ICN), searcher. He received his B.Sc., M.Sc. and Ph.D.
2011. degrees in 2000, 2001 and 2008, respectively, from
[81] C. Tsilopoulos and G. Xylomenos, “Scaling bloom filter-based multicast the Department of Informatics at AUEB. His Ph.D.
via filter switching,” in International Symposium on Computers and thesis was on cross-layer energy efficient service
Communications (ISCC), 2013. discovery protocols for Mobile Ad Hoc Networks
[82] W. Yang, D. Trossen, and J. Tapolcai, “Scalable forwarding for and revenue optimization mechanisms for charged
information-centric networks,” in International Conference on Commu- service provision in ad hoc environments. From
nications (ICC), 2013. 2009 to 2010 he was a post-doctoral researcher at the
[83] P. Jokela, H. Mahkonen, C. E. Rothenberg, and J. Ott, “(deployable) Department of Wireless Networks at RWTH Aachen
reduction of multicast state with in-packet Bloom filters,” in Proc. IFIP- University, Germany, working in network economics and quality of experience
TC6 Networking Conference, 2013. for cognitive wireless networks. Since 2011 he is a Senior Researcher at the
[84] A. Wolman, M. Voelker, N. Sharma, N. Cardwell, A. Karlin, and H. M. Mobile Multimedia Laboratory. His current research interests lie in the areas
Levy, “On the scale and performance of cooperative web proxy caching,” of Resource Management and QoS Support for future network architectures.
in Symposium on Operating System Principles (SOSP), 1999, pp. 16–31. In 2002 he received the Ericsson Award of Excellence in Telecommunications
[85] S. Ihm and V. S. Pai, “Towards understanding modern web traffic,” in for his master’s thesis on Location Based Services. He has worked in many
ACM Workshop on Information-Centric Networking (ICN), 2011. EU and national projects; he has published 25 refereed articles in journals,
[86] G. Carofiglio, V. Gehlen, and D. Perino, “Experimental evaluation of books and conferences, and he has been awarded one national patent.
memory management in content-centric networking,” in International
Conference on Communications (ICC), 2011.
[87] A. Helmy, “A multicast-based protocol for IP mobility support,” in
Networked Group Communication (NGC), 2000, pp. 29–58.
[88] N. Fotiou, G. Marias, and G. Polyzos, “Towards a secure rendezvous Vasilios A. Siris received a degree in physics from
network for future publish/subscribe architectures,” in Future Internet the National and Kapodistrian University of Athens,
Conference (FIS), 2010, pp. 49–56. Greece, in 1990, the M.S. degree in computer sci-
[89] ——, “Access control enforcement delegation for information-centric ence from Northeastern University, Boston, in 1992,
networking architectures,” in ACM Workshop on Information-Centric and the Ph.D. degree in computer science from
Networking (ICN), 2012. the University of Crete, Greece, in 1998. He is an
[90] D. Trossen and A. Kostopoulos, “Exploring the tussle space for assistant professor in the Department of Informatics,
information-centric networking,” in Research Conference on Commu- AUEB, since 2009, and a research associate at the
nication, Information and Internet Policy, 2012. Institute of Computer Science of FORTH, since
[91] G. Carofiglio, M. Gallo, L. Muscariello, and D. Perino, “Modeling 2002. From 2002 to 2008, he was an assistant
data transfer in content-centric networking,” in International Teletraffic professor at the University of Crete. In Spring 2001,
Congress (ITC), 2011, pp. 111–118. he was a visiting researcher at the Statistical Laboratory of the University of
[92] C. Stais, A. Voulimeneas, and G. Xylomenos, “Towards an error control Cambridge, and in Summer 2001 and 2006, he was a research fellow at
scheme for a publish/subscribe network,” in International Conference on the research laboratories of BT in the UK. His current research interests
Communications (ICC), 2013. include resource management and traffic control in wired and wireless
[93] Y. Thomas, C. Tsilopoulos, G. Xylomenos, and G. C. Polyzos, “Mul- networks, traffic measurement and analysis for monitoring quality of service
tisource and multipath file transfers through publish-subscribe internet- and intrusion/anomaly detection, and architecture of mobile communication
working,” in ACM Workshop on Information-Centric Networking (ICN), systems and future networks. He has served as the general chair or technical
2013. program chair for various international conferences and workshops, such
[94] C. Tsilopoulos, I. Gasparis, G. Xylomenos, and G. C. Polyzos, “Effi- as Wired/Wireless Internet Communications 2008, IEEE WoWMoM 2009,
cient real-time information delivery in future Internet publish-subscribe HotMESH 2011, and IEEE Broadband Wireless Access 2011. He is currently
networks,” in International Conference on Computing, Networking and on the editorial board of the Computer Communications Journal. He is/was
Communications (ICNC), 2013. the principal investigator and coordinator for many research and development
[95] J. Tateson, T. Burbridge, D. Trossen, and M. Ain. PSIRP deliverable projects funded by the EU, the Greek government, and industry.
4.6: Final evaluation report on deployment incentives and business
models. [Online]. Available: http://www.psirp.org/publications.html
Nikos Fotiou is a Ph.D. candidate in Computer Konstantinos V. Katsaros received his B.Sc. in
Science at AUEB and a member of the Mobile Informatics (2003), and his M.Sc. (2005) and Ph.D.
Multimedia Laboratory. He received his Diploma in (2010) degrees in Computer Science from AUEB.
Information and Communication Systems Engineer- His Ph.D. thesis was on information-centric net-
ing from the University of the Aegean in Samos, working with a particular focus on content distri-
Greece (2005) and his M.Sc. in Internetworking bution and mobility support. Since then has worked
from the Royal Institute of Technology (KTH) in as a research associate at the Mobile Multimedia
Stockholm, Sweden (2007). He participated in the Laboratory (AUEB) and the Laboratory of Infor-
PSIRP and PURSUIT projects as well as in the mation, Networking and Communication Sciences
Euro-NF Network of Excellence. His current re- (LINCS) at Telecom ParisTech, France. He has also
search interests include availability of name resolu- worked in mobile grid computing, cognitive radio
tion services, privacy preserving information lookup systems for information and multicast/broadcast service provision over cellular networks. He has
centric architectures, and access control mechanisms for distributed content participated in many EU projects including PSIRP and PURSUIT. His current
storage. research interests include smart grid communications, information-centric
network architectures and cloud computing and networking. Currently he
is a member of the Communication and Information Systems Group at
the Department of Electronic and Electrical Engineering, University College
London, UK.
Christos Tsilopoulos is a Ph.D. candidate at AUEB
and a member of the Mobile Multimedia Laboratory.
He received his B.Sc. in Informatics from AUEB
(2006) and his M.Sc. in Communication Systems George C. Polyzos , Professor of Computer Science
and Networks from the National and Kapodistrian at AUEB since 1999, has founded and is leading
University of Athens (2009). In his Ph.D. studies he the Mobile Multimedia Laboratory. Previously, he
is conducting research in the area of information- was Professor of Computer Science and Engineering
centric network architectures and protocols, focusing at the University of California, San Diego, where
on multicast routing and forwarding. His research he was co-director of the Computer Systems Labo-
interests also include distributed systems and soft- ratory, member of the Steering Committee of the
ware engineering. He has participated in several EU UCSD Center for Wireless Communications, and
funded FP7 projects, including the PSIRP and PURSUIT projects on clean- Senior Fellow of the San Diego Supercomputer
slate information-centric network architectures. Center. While in the US, he participated in large
multi-investigator research efforts, such as “Sequoia
2000,” and has led many other research projects with funding from industry
and the US NSF. He returned at UCSD as Visiting Professor for the 2012-
2013 academic year. In Europe he was recently an organizer of the EIFFEL
Xenofon Vasilakos is a Ph.D. candidate at AUEB Think Tank, on the Steering Board of the Euro-NF Network of Excellence
and a member of the Mobile Multimedia Labo- and head of its “Socio-Economic Aspects” and “Trust, Privacy and Security”
ratory. He obtained his B.Sc. in Informatics from Joint Research Activities. He led his lab’s participation in EU FP7 projects
AUEB in 2007 and his M.Sc. degree in Parallel and PURSUIT and PSIRP that developed a clean-slate Future Internet architecture
Distributed Systems in 2009 from the Vrije Uni- based on pub/sub and the ESA funded projects φSAT (“The Role of Satellite
versiteit, Amsterdam. His current research interests in Future Internet Services”) and “Service Delivery over Integrated Satellite
include Future Internet architectures and protocols and Terrestrial Networks.” He received his Diploma in Electrical Engineering
and especially information-centric networking, with from the National Technical University of Athens and his M.A.Sc. in
an emphasis on seamless mobility support. He has Electrical Engineering and Ph.D. in Computer Science from the University
participated in the EU funded FP7 projects PSIRP of Toronto. His current research interests include Internet architecture and
and PURSUIT on clean-slate information-centric protocols, ubiquitous computing, network security, wireless networks, mobile
network architectures. multimedia communications, and performance evaluation of computer and
communications systems. He has been a reviewer for many research funding
agencies, on the editorial board and as a guest editor for scientific journals, on
the program committees of many conferences and workshops and is currently
on the Steering Committee of the ACM SIGCOMM Information-Centric
Networking workshop and TPC Co-Chair for ACM SIGCOMM ICN 2013.

A Survey of Information-Centric Networki

Uploaded by

Copyright:

Available Formats

A Survey of Information-Centric Networki

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Survey of Information-Centric Networki

Uploaded by

Copyright:

Available Formats

This article has been accepted for inclusion in a future issue of this journal.

Content is final as presented, with the exception of pagination.

OceanStore [15] 2000

TRIAD [9], Content-based networking [11] 2001

VRR [16], ROFL [17]

DONA [29] 2007

PSIRP [31] 4WARD [33]

CCN [42], LIPSIN [53] 2009

ANR Connect [39]

(2) Router Router

Fig. 2. The DONA architecture. RH stands for Resolution Handler.

C’s routing tables after C’s routing tables after

) Case 1: Routers Perform ( f)

Case 2: Routers Perform

CRS/PC CaR (4)

4-5 Name Lookup

Name Resolution and

[73] H. Balakrishnan, K. Lakshminarayanan, S. Ratnasamy, S. Shenker, George Xylomenos is an Assistant Professor of

You might also like