4.4. Mobility Management
Mobility management has been an active field in host-centric
communications for more than two decades. In IETF in particular,
starting with [RFC2002], a multitude of enhancements to IP have been
standardized aiming to "allow transparent routing of IP datagrams to
mobile nodes in the Internet" [RFC5944]. In a nutshell, mobility
management for IP networks is locator-oriented and relies on the
concept of a mobility anchor as a foundation for providing always-on
connectivity to mobile nodes (see [MMIN]). Other standards
organizations, such as 3GPP, have followed similar anchor-based
approaches. Traffic to and from the mobile node must flow through
the mobility anchor, typically using a set of tunnels, enabling the
mobile node to remain reachable while changing its point of
attachment to the network.
Needless to say, an IP network that supports node mobility is more
complex than one that does not, as specialized network entities must
be introduced in the network architecture. This is reflected in the
control plane as well, which carries mobility-related signaling
messages, establishes and tears down tunnels, and so on. While
mobile connectivity was an afterthought in IP, in ICN, this is
considered a primary deployment environment. Most, if not all, ICN
proposals consider mobility from the very beginning, although at
varying levels of architectural and protocol detail. That said, no
solution has so far come forward with a definite answer on how to
handle mobility in ICN using native primitives. In fact, we observe
that mobility appears to be addressed on an ICN proposal-specific
basis. That is, there is no single paradigm solution, akin to
tunneling through a mobility anchor in host-centric networking, that
can be applied across different ICN proposals. For instance,
although widely deployed mobile network architectures typically come
with their own network entities and associated protocols, they follow
the same line of design with respect to managing mobility. This
design thinking, which calls for incorporating mobility anchors,
permeates in the ICN literature too.
However, employing mobility anchors and tunneling is probably not the
best way forward in ICN research for mobile networking.
Fundamentally, this approach is anything but information-centric and
location-independent. In addition, as argued in [SEEN], current
mobility management schemes anchor information retrieval not only at
a specific network gateway (e.g., home agent in Mobile IP) but also
at a specific correspondent node due to the end-to-end nature of
host-centric communication. However, once a change in the point of
attachment occurs, information retrieval from the original
"correspondent node" may no longer be optimal. This was shown in
[MANI], for example, where a simple mechanism that triggers the
discovery of new retrieval providers for the same data object,
following a change in the point of attachment, clearly outperforms a
tunnel-based approach like Mobile IP in terms of object download
times. The challenge here is how to capitalize on location
information while facilitating the use of ICN primitives, which
natively support multicast and anycast.
ICN naming and name resolution, as well as the security features that
come along, should natively support mobility. For example, CCN [CCN]
does not have the restriction of spanning tree routing, so it is able
to take advantage of multiple interfaces or adapt to the changes
produced by rapid mobility (i.e., there is no need to bind a layer 3
address with a layer 2 address). In fact, client mobility can be
simplified by allowing requests for new content to normally flow from
different interfaces or through newly connected points of attachment
to the network. However, when the node moving is the (only) content
source, it appears that more complex network support might be
necessary, including forwarding updates and cache rebuilding. A case
in point is a conversation network service, such as a voice or video
call between two parties. The requirements in this case are more
stringent when support for seamless mobility is required, especially
when compared to content dissemination that is amenable to buffering.
Another parameter that needs to be paid attention to is the impact of
using different wireless access interfaces based on different
technologies, where the performance and link conditions can vary
widely depending of numerous factors.
In host-centric networking, mobility management mechanisms ensure
optimal handovers and (ideally) seamless transition from one point of
attachment to another. In ICN, however, the traditional meaning of
"point of attachment" no longer applies as communication is not
restrained by location-based access to data objects. Therefore, a
"seamless transition" in ICN ensures that content reception continues
without any perceptible change from the point of view of the ICN
application receiving that content. Moreover, this transition needs
to be executed in parallel with ICN content identification and
delivery mechanisms, enabling scenarios such as preparation of the
content delivery process at the target connectivity point prior to
the handover (to reduce link switch disturbances). Finally, these
mobility aspects can also be tightly coupled with network management
aspects, in respect to policy enforcement, link control, and other
parameters necessary for establishing the node's link to the network.
In summary, the following research challenges for ICN mobility
management can be derived:
o How can mobility management take full advantage of native ICN
o How do we avoid the need for mobility anchors in a network that by
design supports multicast, anycast, and location-independent
o How can content retrieval mechanisms interface with specific link
operations, such as identifying which links are available for
o How can mobility be offered as a service that is only activated
when the specific user/content/conditions require it?
o How can mobility management be coordinated between the node and
the network for optimization and policing procedures?
o How do we ensure that managing mobility does not introduce
scalability issues in ICN?
o How will the name resolution process be affected by rapid
topological changes when the content source itself is mobile?
4.5. Wireless Networking
Today, all layer 2 (L2) wireless network radio access technologies
are developed with a clear assumption in mind: the waist of the
protocol stack is IP, and it will be so for the foreseeable future.
By fixing the protocol stack waist, engineers can answer a large set
of questions, including how to handle conversational traffic (e.g.,
voice calls) vs. web traffic, how to support multicast, and so on, in
a rather straightforward manner. Broadcast, on the other hand, which
is inherent in wireless communication, is not fully taken advantage
of. On the contrary, researchers are often more concerned about
introducing mechanisms that ensure that "broadcast storms" do not
take down a network. The question of how can broadcast better serve
ICN needs has yet to be thoroughly investigated.
Wireless networking is often intertwined with mobility, but this is
not always the case. In fact, empirical measurements often indicate
that many users tend to connect (and remain connected) to a single
Wi-Fi access point for considerable amounts of time. A case in
point, which is frequently cited in different variations in the ICN
literature, is access to a document repository during a meeting. For
instance, in a typical IETF working group meeting, a scribe takes
notes, which are uploaded to a centralized repository (see Figure 1).
Subsequently, each meeting participant obtains a copy of the document
on their own devices for local use, annotation, and sharing with
colleagues that are not present at the meeting. Note that in this
example, there is no node mobility and that it is not important
whether the document with the notes is uploaded in one go at the end
of the session or in a streaming-like fashion as is typical today
with online (cloud-based) document processing.
| Document Repository |
| Access Point |
/ | \
/ | \
/ | \
Scribe Participant 1 ... Participant N
Figure 1: Document Sharing During a Meeting
In this scenario, we observe that the same data object bits
(corresponding to the meeting notes) need to traverse the wireless
medium at least N+1 times, where N is the number of meeting
participants obtaining a copy of the notes. In effect, a broadcast
medium is shoehorned into N+1 virtual unicast channels. One could
argue that wireless local connectivity is inexpensive, but this is
not the critical factor in this example. The actual information
exchange wastes N times the available network capacity, no matter
what the spectral efficiency (or the economics) underlying the
wireless technology is. This waste is a direct result of extending
the remote access paradigm from wired to wireless communication,
irrespective of the special characteristics of the latter.
It goes without saying that an ICN approach that does not take into
consideration the wireless nature of an interface will waste the same
amount of resources as a host-centric paradigm. In-network caching
at the wireless access point could reduce the amount of data carried
over the backhaul link, but, if there is no change in the use of the
wireless medium, the NDO will still be carried over the wireless
ether N+1 times. Intelligent caching strategies, replica placement
cooperation, and so on simply cannot alleviate this. On the other
hand, promiscuous interface operation and opportunistic caching would
maximize wireless network capacity utilization in this example.
Arguably, if one designs a future wireless access technology with an
information-centric "layer 3" in mind, many of the design choices
that are obvious in an all-IP architecture may no longer be valid.
Although this is clearly outside the scope of this document, a few
research challenges that the wider community may be interested in
o Can we use wireless resources more frugally with the information-
centric paradigm than what is possible today in all-IP wireless
o In the context of wireless access, how can we leverage the
broadcast nature of the medium in an information-centric network?
o Would a wireless-oriented ICN protocol stack deliver significant
performance gains? How different would it be from a wired-
oriented ICN protocol stack?
o Is it possible that by changing the network paradigm to ICN we
can, in practice, increase the spectral efficiency (bits/s/Hz) of
a wireless network beyond what would be possible with today's
host-centric approaches? What would be the impact of doing so
with respect to energy consumption?
o Can promiscuous wireless interface operation coupled with
opportunistic caching increase ICN performance, and if so, by how
o How can a conversational service be supported at least as
efficiently as today's state-of-the-art wireless networks deliver?
o What are the benefits of combining ICN with network coding in
o How can Multiple-Input Multiple-Output (MIMO) and Coordinated
Multipoint Transmission (CoMP) be natively combined with ICN
primitives in future cellular networks?
4.6. Rate and Congestion Control
ICN's receiver-driven communication model as described above creates
new opportunities for transport protocol design, as it does not rely
solely on end-to-end communication from a sender to a requestor. A
requested data object can be accessible in multiple different network
locations. A node can thus decide how to utilize multiple sources,
e.g., by sending parallel requests for the same NDO or by switching
sources (or next hops) in a suitable schedule for a series of
In this model, the requestor would control the data rate by
regulating its request sending rate and next by performing source/
next-hop selections. Specific challenges depend on the specific ICN
approach, but general challenges for receiver-driven transport
protocols (or mechanisms, since dedicated protocols might not be
required) include flow and congestion control, fairness, network
utilization, stability (of data rates under stable conditions), etc.
[HRICP] and [CONTUG] describe request rate control protocols and
corresponding design challenges.
As mentioned above, the ICN communication paradigm does not depend
strictly on end-to-end flows, as contents might be received from in-
network caches. The traditional concept of a flow is then somewhat
not valid as sub-flows, or flowlets, might be formed on the fly, when
fractions of an NDO are transmitted from in-network caches. For a
transport-layer protocol, this is challenging, as any measurement
related to this flow as traditionally done by transport protocols
such as TCP, can often prove misleading. For example, false Round-
Trip Time (RTT) measurements will lead to largely variable average
and smoothed RTT values, which in turn will trigger false timeout
Furthermore, out-of-order delivery is expected to be common in a
scenario where parts of a data object are retrieved from in-network
caches rather than from the origin server. Several techniques for
dealing with out-of-order delivery have been proposed in the past for
TCP, some of which could potentially be modified and reused in the
context of ICN. Further research is needed in this direction though
to choose the right technique and adjust it according to the
requirements of the ICN architecture and transport protocol in use.
ICN offers routers the possibility to aggregate requests and can use
several paths, meaning that there is no such thing as a (dedicated)
end-to-end communication path, e.g., a router that receives two
requests for the same content at the same time only sends one request
to its neighbor. The aggregation of requests has a general impact on
transport protocol design and offers new options for employing per-
node forwarding strategies and for rethinking in-network resource
Achieving fairness for requestors can be one challenge as it is not
possible to identify the number of requestors behind one particular
request. A second problem related to request aggregation is the
management of request retransmissions. Generally, it is assumed that
a router will not transmit a request if it transmitted an identical
request recently, and because there is no information about the
requestor, the router cannot distinguish the initial request from a
client from a retransmission from the same client. In such a
situation, routers can adapt their timers to use the best of the
4.7. In-Network Caching
Explicitly named data objects allow for caching at virtually any
network element, including routers, proxy caches, and end-user
devices. Therefore, in-network caching can improve network
performance by fetching content from nodes that are geographically
placed closer to the end user. Several issues that need further
investigation have been identified with respect to in-network
caching. In this section, we list important challenges that relate
to the properties of the new ubiquitous caching system.
4.7.1. Cache Placement
The declining cost of fast memory gives the opportunity to deploy
caches in network routers and to take advantage of cached NDOs. We
identify two approaches to in-network caching, namely, on-path and
off-path caching. Both approaches have to consider the issue of
cache location. Off-path caching is similar to traditional proxy-
caching or CDN server placement. Retrieval of contents from off-path
caches requires redirection of requests and, therefore, is closely
related to the Request-to-Cache Routing problem discussed below.
Off-path caches have to be placed in strategic points within a
network in order to reduce the redirection delays and the number of
detour hops to retrieve cached contents. Previous research on proxy-
caching and CDN deployment is helpful in this case.
On the other hand, on-path caching requires less network intervention
and fits more neatly in ICN. However, on-path caching requires line-
speed operation, which places more constraints on the design and
operation of in-network caching elements. Furthermore, the gain of
such a system of on-path in-network caches relies on opportunistic
cache hits and has therefore been considered of limited benefit,
given the huge amount of contents hosted in the Internet. For this
reason, network operators might initially consider only a limited
number of network elements to be upgraded to in-network caching
elements. The decision on which nodes should be equipped with caches
is an open issue and might be based, among others, on topological
criteria or traffic characteristics. These challenges relate to both
the Content Placement problem and the Request-to-Cache Routing
problem discussed below.
In most cases, however, the driver for the implementation,
deployment, and operation of in-network caches will be its cost.
Operating caches at line speed inevitably requires faster memory,
which increases the implementation cost. Based on the capital to be
invested, ISPs will need to make strategic decisions on the cache
placement, which can be driven by several factors, such as avoidance
of inter-domain/expensive links, centrality of nodes, size of domain
and the corresponding spatial locality of users, and traffic patterns
in a specific part of the network (e.g., university vs. business vs.
fashion district of a city).
4.7.2. Content Placement: Content-to-Cache Distribution
Given a number of on-path or off-path in-network caching elements,
content-to-cache distribution will affect both the dynamics of the
system, in terms of request redirections (mainly in case of off-path
caches) and the gain of the system in terms of cache hits. A
straightforward approach to content placement is on-path placement of
contents as they travel from source to destination. This approach
reduces the computation and communication overhead of placing content
within the network but, on the other hand, might reduce the chances
of hitting cached contents. This relates to the Request-to-Cache
Routing problem discussed next.
Furthermore, the number of replicas held in the system brings up
resource management issues in terms of cache allocation. For
example, continuously replicating data objects in all network
elements results in redundant copies of the same objects. The issue
of redundant replication has been investigated in the past for
hierarchical web caches. However, in hierarchical web-caching,
overlay systems coordination between the data and the control plane
can guarantee increased performance in terms of cache hits. Line-
speed, on-path, in-network caching poses different requirements;
therefore, new techniques need to be investigated. In this
direction, reducing the redundancy of cached copies is a study item.
However, the issue of coordinated content placement in on-path caches
The Content-to-Cache Allocation problem relates also to the
characteristics of the content to be cached. Popular content might
need to be placed where it is going to be requested next.
Furthermore, issues of "expected content popularity" or temporal
locality need to be taken into account in designing in-network
caching algorithms in order for some contents to be given priority
(e.g., popular content vs. one-timers). The criteria as to which
contents should be given priority in in-network content caches
relates also to the business relationships between content providers
and network operators. Business model issues will drive some of
these decisions on content-to-cache distribution, but such issues are
outside the scope of this note and are not discussed here further.
4.7.3. Request-to-Cache Routing
In order to take advantage of cached contents, requests have to be
forwarded to the nodes that cache the corresponding contents. This
challenge relates to name-based routing, discussed earlier. Requests
should ideally follow the path to the cached NDO. However,
instructions as to which content is cached where cannot be broadcast
throughout the network. Therefore, the knowledge of an NDO location
at the time of the request either might not exist or might not be
accurate (i.e., contents might have been removed by the time a
request is redirected to a specific node).
Coordination between the data and the control planes to update
information of cached contents has been considered, but in this case,
scalability issues arise. We therefore have two options. We either
have to rely on opportunistic caching, where requests are forwarded
to a server and in case the NDO is found on the path, then the
content is fetched from this node instead of the origin server, or we
employ cache-aware routing techniques. Cache-aware routing can
involve either both the control and the data plane or only one of
them. Furthermore, cache-aware routing can be done in a domain-wide
scale or can involve more than one individual Autonomous System (AS).
In the latter case, business relationships between ASes might need to
be exploited in order to build a scalable model.
4.7.4. Staleness Detection of Cached NDOs
Due to the largely distributed copies of NDOs in in-network caches,
ICN should be able to provide a staleness verification algorithm that
provides synchronization of NDOs located at their providers and in-
network caching points. Two types of approaches can be considered
for this problem, namely direct and indirect approaches.
In the direct approach, each cache looks up certain information in
the NDO's name, e.g., the timestamp, that directly indicates its
staleness. This approach is applicable to some NDOs that come from
machine-to-machine and Internet of Things scenarios, whose base
operation relies on obtaining the latest version of that NDO (i.e., a
soil sensor in a farm providing different continuous parameters that
are sent to a display or greenhouse regulation system) [FRESHNESS].
In the indirect approach, each cache consults the publisher of the
cached NDO about its staleness before serving it. This approach
assumes that the NDO includes the publisher information, which can be
used to reach the publisher. It is suitable for the NDO whose
expiration time is difficult to be set in advance, e.g., a web page
that contains the main text (which stays the same ever after) and the
interactive sections such as comments or ads (which are updated
It is often argued that ignoring stale NDOs in caches and simply
providing new names for updated NDOs might be sufficient rather than
using a staleness verification algorithm to manage them. However,
notifying the new names of updated NDOs to users is not a trivial
task. Unless the update is informed to all users at the same time,
some users would use the old name although they intended to retrieve
the updated NDO.
One research challenge is how to design consistency and coherence
models for caching NDOs along with their revision handling and
updating protocols in a scalable manner.
4.7.5. Cache Sharing by Multiple Applications
When ICN is deployed as a general, application-independent network
and cache infrastructure, multiple consumers and producers
(representing different applications) would communicate over the same
infrastructure. With universal naming schemes or sufficiently unique
hash-based identifiers, different application could also share
identical NDOs in a transparent way.
Depending on the naming, data integrity, and data origin
authentication approaches, there may be technical and business
challenges to share caches across different applications, for
example, content protection, avoiding cache poisoning, ensuring
performance isolation, etc. As ICN research matures, these
challenges should be addressed more specifically in a dedicated
4.8. Network Management
Managing networks has been a core craft in the IP-based host-centric
paradigm ever since the technology was introduced in production
networks. However, at the onset of IP, management was considered
primarily as an add-on. Essential tools that are used daily by
networkers, such as ping and traceroute, did not become widely
available until more than a decade or so after IP was first
introduced. Management protocols, such as SNMP, also became
available much later than the original introduction of IP, and many
still consider them insufficient despite the years of experience we
have running host-centric networks. Today, when new networks are
deployed, network management is considered a key aspect for any
operator, a major challenge that is directly reflected in higher
operational cost if not done well. If we want ICN to be deployed in
infrastructure networks, development of management tools and
mechanisms must go hand in hand with the rest of the architecture
Although defining an FCAPS (Fault, Configuration, Accounting,
Performance, and Security) [ISOIEC-7498-4] management model for ICN
is clearly outside the scope of this document, there is a need for
creating basic tools early on while ICN is still in the design and
experimentation phases that can evolve over time and help network
operations centers (NOCs) to define policies, validate that they are
indeed used in practice, be notified early on about failures, and
determine and resolve configuration problems. Authentication,
Authorization, and Accounting (AAA) as well as performance
management, from a NOC perspective, will also need to be considered.
Given the expectations for a large number of nodes and unprecedented
traffic volumes, automating tasks or even better employing self-
management mechanisms are preferred. The main challenge here is that
all tools we have at our disposal today are node-centric, are end-to-
end oriented, or assume a packet-stream communication environment.
Rethinking reachability and operational availability, for example,
can yield significant insights into how information-centric networks
will be managed in the future.
With respect to network management, we see three different aspects.
First, any operator needs to manage all resources available in the
network, which can range from node connectivity to network bandwidth
availability to in-network storage to multi-access support. In ICN,
users will also bring into the network significant resources in terms
of network coverage extension, storage, and processing capabilities.
Delay Tolerant Networking (DTN) characteristics should also be
considered to the degree that this is possible (e.g., content
dissemination through data mules). Second, given that nodes and
links are not at the center of an information-centric network,
network management should capitalize on native ICN mechanisms. For
example, in-network storage and name resolution can be used for
monitoring, while native publish/subscribe functionality can be used
for triggering notifications. Finally, management is also at the
core of network-controlling capabilities by allowing operating
actions to be mediated and decided, triggering and activating
networking procedures in an optimized way. For example, monitoring
aspects can be conjugated with different management actions in a
coordinated way, allowing network operations to flow in a concerted
However, the considerations on leveraging intrinsic ICN mechanisms
and capabilities to support management operations go beyond a simple
mapping exercise. In fact, it not only raises a series of challenges
on its own, but also opens up new possibilities for both ICN and
"network management" as a concept. For instance, naming mechanisms
are central to ICN-intrinsic operations, which are used to identify
and reach content under different aspects (e.g., hierarchically
structured vs. "flattish" names). In this way, ICN is decoupled from
host-centric aspects on which traditional network management schemes
rely. As such, questions are raised that can directly be translated
into challenges for network management capability, such as, for
example, how to address a node or a network segment in an ICN naming
paradigm, how to identify which node is connected "where", how to be
aware of the node capabilities (i.e., high or low-powered machine-to-
machine (M2M) node), and if there is a host-centric protocol running
where the management process can also leverage.
But, on the other hand, these same inherent ICN characteristics also
allow us to look into network management through a new perspective.
By centering its operations around NDOs, one can conceive new
management operations addressing, for example, per-content management
or access control, as well as analyzing performance per NDO instead
of per link or node. Moreover, such considerations can also be used
to manage operational aspects of ICN mechanisms themselves. For
example, [NDN-MGMT] reutilizes inherent content-centric capabilities
of CCN to manage optimal link connectivity for nodes, in concert with
a network optimization process. Conversely, how these content-
centric aspects can otherwise influence and impact management in
other areas (e.g., security and resilience) is also important, as
exemplified in [CCN-ACCESS], where access control mechanisms are
integrated into a prototype of the [PURSUIT] architecture.
The set of core research challenges for ICN management includes:
o Management and control of NDO reception at the requestor
o Coordination of management information exchange and control
between ICN nodes and ICN network control points
o Identification of management and controlling actions and items
through information naming
o Relationship between NDOs and host entities identification, i.e.,
how to identify a particular link, interface, or flow that needs
to be managed
4.9. ICN Applications
ICN can be applied to different application domains and is expected
to provide benefits for application developers by providing a more
suitable interface for application developers (in addition to the
other ICN benefits described above). [RFC7476] provides an overview
of relevant application domains at large. This section discusses
opportunities and challenges for selected application types.
4.9.1. Web Applications
Intuitively, the ICN request/response communication style seems to be
directly mappable to web communication over HTTP. NDO names could be
the equivalent of URIs in today's web, proprietary and transparent
caching could be obsoleted by ICN in-network caching, and developers
could directly use an ICN request/response API to build applications.
Research efforts such as [ICN2014-WEB-NDN] have analyzed real-world
web applications and ways to implement them in ICN. The most
significant insight is that REST-style (Representational State
Transfer) web communication relies heavily on transmitting user/
application context information in HTTP GET requests, which would
have to be mapped to corresponding ICN messages. The challenge in
ICN would be how to exactly achieve that mapping. This could be done
to some degree by extending name formats or by extending message
structure to include cookies and similar context information. The
design decisions would need to consider overhead in routers (for
example, if larger GET/Interest messages would have to be stored in
corresponding tables on routers).
Other challenges include the ability to return different results
based on requestor-specific processing in the presence of immutable
objects (and name-object bindings) in ICN and the ability for
efficient bidirectional communication, which would require some
mechanism to name and reach requestor applications.
4.9.2. Video Streaming and Download
One of ICN's prime application areas is video streaming and download
where accessing named data, object-level security, and in-network
storage can fulfill requirements for both video streaming and
download. The applicability and benefits of ICN to video has been
demonstrated by several prototype developments
[VIDEO-STREAMING] discusses the opportunities and challenges of
implementing today's video services such as DASH-based (Dynamic
Adaptive Streaming over HTTP) streaming and download over ICN,
considering performance requirements, relationship to peer-to-peer
live streaming, IPTV, and Digital Rights Management (DRM).
In addition to just porting today's video application from a host-
centric paradigm to ICN, there are also promising opportunities to
leverage the ICN network services for redesigning and thus
significantly enhancing video access and distribution
[ICNRG-2015-01-WESTPHAL]. For example, ICN store and forward could
be leveraged for rate adaptation to achieve maximum throughput and
optimal Quality of Experience (QoE) in scenarios with varying link
properties, if capacity information is fed back to rate selection
algorithms at senders. Other optimizations such as more aggressive
prefetching could be performed in the network by leveraging
visibility of chunk NDO names and NDO metadata in the network.
Moreover, multi-source rate adaptation in combination with network
coding could enable better QoE, for example, in multi-interface/
access scenarios where multiple paths from client to upstream caches
4.9.3. Internet of Things
The essence of ICN lies in the name-based routing that enables users
to retrieve NDOs by the names regardless of their locations. By
definition, ICN is well suited for IoT applications, where users
consume data generated from IoTs without maintaining secure
connections to them. The basic request/response style APIs of ICN
enable developers to build IoT applications in a simple and fast
Ongoing efforts such as [ICN-FOR-IOT], [ICN-ARCH], and
[ICN2014-NDNWILD] have addressed the requirements and challenges of
ICN for IoT. For instance, many IoT applications depend on a PUSH
model where data transmission is initiated by the publisher, so they
can support various real-time applications (emergency alarm, etc.).
However, ICN does not support the PUSH model in a native manner due
to its inherent receiver-driven data transmission mechanism. The
challenge would be how to efficiently support the PUSH model in ICN,
so it provides publish/subscribe-style APIs for IoT application
developers. This could be done by introducing other types of
identifiers such as a device identifier or by extending the current
request/response communication style, which may result in heavy
overhead in ICN routers.
Moreover, key characteristics of the ICN underlying operation also
impact important aspects of IoT, such as the caching in content
storage of network forwarding entities. This allows the
simplification of ICN-based IoT application development. Since the
network is able to act on named content, generic names provide a way
to address content independently of the underlying device (and
access) technology, and bandwidth consumption is optimized due to the
availability of cached content. However, these aspects raise
challenges themselves concerning the freshness of the information
received from the cache in contrast to the last value generated by a
sensor, as well as pushing content to specific nodes (e.g., for
controlling them), which requires individual addressing for
identification. In addition, due to the heterogeneous nature of IoT
nodes, their processing capabilities might not be able to handle the
necessary content signing verification procedures.
5. Security Considerations
This document does not impact the security of the Internet. Security
questions related to ICN are discussed in Section 4.2.
6. Informative References
Fotiou, N., Marias, G., and G. Polyzos, "Access control
enforcement delegation for information-centric networking
architectures", Proceedings of the second edition of the
ICN workshop on Information-centric networking (ICN
'12) Helsinki, Finland, DOI 10.1145/2342488.2342507, 2012.
Waehlisch, M., Schmidt, TC., and M. Vahlenkamp,
"Backscatter from the Data Plane - Threats to Stability
and Security in Information-Centric Network
Infrastructure", Computer Networks Vol 57, No. 16, pp.
3192-3206, DOI 10.1016/j.comnet.2013.07.009, November
Rosensweig, E. and J. Kurose, "Breadcrumbs: Efficient,
Best-Effort Content Location in Cache Networks",
In Proceedings of the IEEE INFOCOM 2009,
DOI 10.1109/INFCOM.2009.5062201, April 2009.
[CCN] Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
Briggs, N., and R. Braynard, "Networking Named Content",
CoNEXT 2009, DOI 10.1145/1658939.1658941, December 2009.
Fotiou, N., Marias, G., and G. Polyzos, "Access control
enforcement delegation for information-centric networking
architectures", In Proceedings of the second edition of
the ICN workshop on Information-centric networking (ICN
'12), ACM, New York, NY, USA, 85-90,
DOI 10.1145/2342488.2342507, 2012.
[CHAUM] Chaum, D. and E. van Heijst, "Group signatures",
In Proceedings of EUROCRYPT, DOI 10.1007/3-540-46416-6_22,
[COMPACT] Cowen, L., "Compact routing with minimum stretch",
In Journal of Algorithms, vol. 38, pp. 170-183,
DOI 10.1006/jagm.2000.1134, 2001.
[CONTUG] Arianfar, S., Nikander, P., Eggert, L., Ott, J., and W.
Wong, "ConTug: A Receiver-Driven Transport Protocol for
Content-Centric Networks", Technical Report Aalto
University Comnet, 2011.
[DONA] Koponen, T., Ermolinskiy, A., Chawla, M., Kim, K., gon
Chun, B., and S. Shenker, "A Data-Oriented (and Beyond)
Network Architecture", In Proceedings of SIGCOMM 2007,
DOI 10.1145/1282427.1282402, August 2007.
Kurihara, J., Uzun, E., and C. Wood, "An Encryption-Based
Access Control Framework for Content-Centric Networking",
IFIP Networking 2015, Toulouse, France,
DOI 10.1109/IFIPNetworking.2015.7145300, September 2015.
Quevedo, J., Corujo, D., and R. Aguiar, "Consumer Driven
Information Freshness Approach for Content Centric
Networking", IEEE INFOCOM Workshop on Name-Oriented
Mobility Toronto, Canada,
DOI 10.1109/INFCOMW.2014.6849279, May 2014.
[GREEDY] Papadopoulos, F., Krioukov, D., Boguna, M., and A. Vahdat,
"Greedy forwarding in dynamic scale-free networks embedded
in hyperbolic metric spaces", In Proceedings of the IEEE
INFOCOM, San Diego, USA, DOI 10.1109/INFCOM.2010.5462131,
[HRICP] Carofiglio, G., Gallo, M., and L. Muscariello, "Joint hop-
by-hop and receiver-driven interest control protocol for
content-centric networks", In Proceedings of ACM SIGCOMM
ICN 2012, DOI 10.1145/2342488.2342497, 2012.
[ICN-ARCH] Zhang, Y., Raychadhuri, D., Grieco, L., Baccelli, E.,
Burke, J., Ravindran, R., Ed., and G. Wang, "ICN based
Architecture for IoT - Requirements and Challenges", Work
in Progress, draft-zhang-iot-icn-challenges-02, August
Lindgren, A., Ben Abdesslem, F., Ahlgren, B., Schelen, O.,
and A. Malik, "Applicability and Tradeoffs of Information-
Centric Networking for Efficient IoT", Work in Progress,
draft-lindgren-icnrg-efficientiot-03, July 2015.
Ahlgren, B., Jonasson, A., and B. Ohlman, "Demo Overview:
HTTP Live Streaming over NetInf Transport", ACM SIGCOMM
Information-Centric Networking Conference Paris, France,
DOI 10.1145/2660129.2660136, September 2014.
Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M.
Waehlisch, "Information Centric Networking in the IoT:
Experiments with NDN in the Wild", ACM SIGCOMM
Information-Centric Networking Conference Paris, France,
DOI 10.1145/2660129.2660144, September 2014.
Moiseenko, I., Stapp, M., and D. Oran, "Communication
Patterns for Web Interaction in Named Data Networking",
ACM SIGCOMM Information-Centric Networking
Conference Paris, France, DOI 10.1145/2660129.2660152,
Ghodsi, A., Koponen, T., Rajahalme, J., Sarolahti, P., and
S. Shenker, "Naming in Content-Oriented Architectures",
In Proceedings ACM SIGCOMM Workshop on Information-Centric
Networking (ICN), DOI 10.1145/2018584.2018586, 2011.
Westphal, C., "Video over ICN", IRTF ICNRG
Meeting Cambridge, Massachusetts, USA, January 2015,
Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D.,
and B. Ohlman, "A Survey of Information-Centric
Networking", In Communications Magazine, IEEE, vol. 50,
no. 7, pp. 26-36, DOI 10.1109/MCOM.2012.6231276, 2012.
ISO, "Information Processing Systems -- Open Systems
Interconnection -- Basic Reference Model -- Part 4:
Management Framework", November 1989,
[MANI] Pentikousis, K. and T. Rautio, "A multiaccess Network of
Information", WoWMoM 2010 IEEE,
DOI 10.1109/WOWMOM.2010.5534922, June 2010.
[MDHT] D'Ambrosio, M., Dannewitz, C., Karl, H., and V.
Vercellone, "MDHT: A hierarchical name resolution service
for information-centric networks", ACM SIGCOMM workshop on
Information-centric networking Toronto, Canada,
DOI 10.1145/2018584.2018587, August 2011.
[MMIN] Pentikousis, K. and P. Bertin, "Mobility management in
infrastructure networks", Internet Computing, IEEE vol.
17, no. 5, pp. 74-79, DOI 10.1109/MIC.2013.98, October
Yu, Y., "Controlled Sharing of Sensitive Content", IRTF
ICNRG Meeting San Francisco, USA, October 2015,
[NDN-MGMT] Corujo, D., Aguiar, R., Vidal, I., and J. Garcia-Reinoso,
"A named data networking flexible framework for management
communications", Communications Magazine, IEEE vol. 50,
no. 12, pp. 36-43, DOI 10.1109/MCOM.2012.6384449, December
[PURSUIT] Fotiou et al., N., "Developing Information Networking
Further: From PSIRP to PURSUIT", In Proceedings of Proc.
BROADNETS. ICST, DOI 10.1007/978-3-642-30376-0_1, 2010.
[RANDOM] Gkantsidis, C., Mihail, M., and A. Saberi, "Random walks
in peer-to-peer networks: algorithms and evaluation",
In Perform. Eval., vol. 63, pp. 241-263,
DOI 10.1016/j.peva.2005.01.002, 2006.
Psaras, I., Saino, L., and G. Pavlou, "Revisiting Resource
Pooling: The case of In-Network Resource Sharing", ACM
HotNets Los Angeles, USA, DOI 10.1145/2670518.2673875,
Westphal, C., Ed., Lederer, S., Posch, D., Timmerer, C.,
Azgin, A., Liu, S., Mueller, C., Detti, A., Corujo, D.,
Wang, J., Montpetit, M., Murray, N., Azgin, A., and S.
Liu, "Adaptive Video Streaming over ICN", Work in
Progress, draft-irtf-icnrg-videostreaming-08, April 2016.
The authors would like to thank Georgios Karagiannis for providing
suggestions on QoS research challenges, Dimitri Papadimitriou for
feedback on the routing section, and Joerg Ott and Stephen Farrell
for reviewing the whole document.
Dirk Kutscher (editor)
Osaka University, School of Information Science and Technology
1-5 Yamadaoka, Suita
University College London, Dept. of E.E. Eng.
London WC1E 7JE
Universidade de Aveiro
Instituto de Telecomunicacoes, Campus Universitario de Santiago
2004 route des Lucioles - BP 93
Sophia Antipolis 06902 Cedex
Thomas C. Schmidt
Berliner Tor 7