tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7476

Pages: 45
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IRTF

Information-Centric Networking: Baseline Scenarios

Part 1 of 3, p. 1 to 11
None       Next RFC Part


Top       ToC       Page 1 
Internet Research Task Force (IRTF)                  K. Pentikousis, Ed.
Request for Comments: 7476                                          EICT
Category: Informational                                        B. Ohlman
ISSN: 2070-1721                                                 Ericsson
                                                               D. Corujo
                                                  Universidade de Aveiro
                                                               G. Boggia
                                                     Politecnico di Bari
                                                                G. Tyson
                                        Queen Mary, University of London
                                                               E. Davies
                                                  Trinity College Dublin
                                                             A. Molinaro
                                                                  S. Eum
                                                              March 2015

           Information-Centric Networking: Baseline Scenarios


   This document aims at establishing a common understanding about a set
   of scenarios that can be used as a base for the evaluation of
   different information-centric networking (ICN) approaches so that
   they can be tested and compared against each other while showcasing
   their own advantages.  Towards this end, we review the ICN literature
   and document scenarios which have been considered in previous
   performance evaluation studies.  We discuss a variety of aspects that
   an ICN solution can address.  This includes general aspects, such as,
   network efficiency, reduced complexity, increased scalability and
   reliability, mobility support, multicast and caching performance,
   real-time communication efficiency, energy consumption frugality, and
   disruption and delay tolerance.  We detail ICN-specific aspects as
   well, such as information security and trust, persistence,
   availability, provenance, and location independence.

   This document is a product of the IRTF Information-Centric Networking
   Research Group (ICNRG).

Page 2 
Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Research Task Force
   (IRTF).  The IRTF publishes the results of Internet-related research
   and development activities.  These results might not be suitable for
   deployment.  This RFC represents the consensus of the Information-
   Centric Networking Research Group of the Internet Research Task Force
   (IRTF).  Documents approved for publication by the IRSG are not a
   candidate for any level of Internet Standard; see Section 2 of RFC

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Top       Page 3 
Table of Contents

   1. Introduction ....................................................3
      1.1. Baseline Scenario Selection ................................4
      1.2. Document Goals and Outline .................................5
   2. Scenarios .......................................................6
      2.1. Social Networking ..........................................6
      2.2. Real-Time Communication ....................................7
      2.3. Mobile Networking ..........................................9
      2.4. Infrastructure Sharing ....................................11
      2.5. Content Dissemination .....................................13
      2.6. Vehicular Networking ......................................14
      2.7. Delay- and Disruption-Tolerance ...........................17
           2.7.1. Opportunistic Content Sharing ......................20
           2.7.2. Emergency Support and Disaster Recovery ............21
      2.8. Internet of Things ........................................22
      2.9. Smart City ................................................25
   3. Cross-Scenario Considerations ..................................27
      3.1. Multiply Connected Nodes and Economics ....................27
      3.2. Energy Efficiency .........................................31
      3.3. Operation across Multiple Network Paradigms ...............33
   4. Summary ........................................................34
   5. Security Considerations ........................................35
   6. Informative References .........................................36
   Acknowledgments ...................................................44
   Authors' Addresses ................................................44

1.  Introduction

   Information-centric networking (ICN) marks a fundamental shift in
   communications and networking.  In contrast with the omnipresent and
   very successful host-centric paradigm, which is based on perpetual
   connectivity and the end-to-end principle, ICN changes the focal
   point of the network architecture from the end host to "named
   information" (or content, or data).  In this paradigm, connectivity
   may well be intermittent.  End-host and in-network storage can be
   capitalized upon transparently, as bits in the network and on storage
   devices have exactly the same value.  Mobility and multiaccess are
   the norm, and anycast, multicast, and broadcast are natively

   It is also worth noting that with the transition from a host-centric
   to an information-centric communication model the security paradigm
   changes as well.  In a host-centric network, the basic idea is to
   create secure (remote-access) tunnels to trusted providers of data.
   In an information-centric network, on the other hand, any source
   (cache) should be equally usable.  This requires some mechanism for

Top      ToC       Page 4 
   making each information item trustworthy by itself; this can be
   achieved, for example, by name-data integrity or by signing data

   Although interest in ICN is growing rapidly, ongoing work on
   different architectures, such as NetInf [NetInf], the original
   Content-Centric Networking [CCN], and its successors, Project CCNx
   [CCNx] and Named Data Networking (NDN) [NDNP], the Publish-Subscribe
   Internet (PSI) architecture [PSI], and the Data-Oriented Network
   Architecture [DONA] is far from being completed.  One could think of
   ICN today as being at a stage of development similar to that of
   packet-switched networking in the late 1970s when different
   technologies, e.g., DECnet, Internetwork Packet Exchange (IPX), and
   IP, just to name a few, were being actively developed and put to the
   test.  As such, ICN's current development phase and the plethora of
   approaches to tackle the hardest problems make this a very active and
   growing research area, but, on the downside, it also makes it more
   difficult to compare different proposals on an equal footing.  This
   document aims to partially address this by establishing a common
   understanding about potential experimental setups where different ICN
   approaches can be tested and compared against each other while
   showcasing their advantages.

   The first draft version of this document appeared in November 2012.
   It was adopted by ICNRG at IETF 87 (July 2013) as the document to
   address the work item on the definition of "reference baseline
   scenarios to enable performance comparisons between different
   approaches".  Earlier draft versions of this document have been
   presented during the ICNRG meetings at IETF 85, IETF 86, IETF 87,
   IETF 88, IETF 89, and the ICNRG interim meeting in Stockholm in
   February 2013.  This document has been reviewed, commented, and
   discussed extensively for a period of nearly two years by the vast
   majority of ICNRG members, which certainly exceeds 100 individuals.
   It is the consensus of ICNRG that the baseline scenarios described in
   this document should be published in the IRTF Stream of the RFC
   series.  This document does not constitute a standard.

1.1.  Baseline Scenario Selection

   Earlier surveys [SoA1] [SoA2] note that describing ICN architectures
   is akin to shooting a moving target.  We find that comparing these
   different approaches is often even more tricky.  It is not uncommon
   that researchers devise different performance evaluation scenarios,
   typically with good reason, in order to highlight the advantages of
   their approach.  This should be expected to some degree at this early
   stage of ICN development.  Nevertheless, this document shows that

Top      ToC       Page 5 
   certain baseline scenarios seem to emerge in which ICN architectures
   could showcase their comparative advantages over current systems, in
   general, and against each other, in particular.

   This document surveys the peer-reviewed ICN literature and presents
   prominent evaluation study cases as a foundation for the baseline
   scenarios to be considered by the IRTF Information-Centric Networking
   Research Group (ICNRG) in its future work.  There are two goals for
   this document: first, to provide a set of use cases and applications
   that highlight opportunities for testing different ICN proposals;
   second, to identify key attributes of a common set of techniques that
   can be instrumental in evaluating ICN.  Further, these scenarios are
   intended to equip researchers with sufficient configuration data to
   effectively evaluate their ICN proposals in a variety of settings,
   particularly extending beyond scenarios focusing simply on
   traditional content delivery.  The overall aim is that each scenario
   is described at a sufficient level of detail, and with adequate
   references to already published work, so that it can serve as the
   base for comparative evaluations of different approaches.  Example
   code that implements some of the scenarios and topologies included in
   this document is available from

1.2.  Document Goals and Outline

   This document incorporates input from ICNRG participants and their
   corresponding text contributions, has been reviewed by several ICNRG
   active participants (see Section 7), and represents the consensus of
   the research group.  However, this document does not constitute an
   IETF standard, but is an Informational document; see also [RFC5743].
   As mentioned above, these scenarios are intended to provide a
   framework for evaluating different ICN approaches.  The methodology
   for how to do these evaluations as well as definitions of metrics
   that should be used are described in a separate document
   [EVAL-METHOD].  In addition, interested readers should consider
   reviewing [CHALLENGES].

   The remainder of this document presents a number of scenarios grouped
   into several categories in Section 2, followed by a number of cross-
   scenario considerations in Section 3.  Overall, note that certain
   evaluation scenarios span across these categories, so the boundaries
   between them should not be considered rigid and inflexible.
   Section 4 summarizes the main evaluation aspects across the range of
   scenarios discussed in this document.

Top      ToC       Page 6 
2.  Scenarios

   This section presents nine scenario categories based on use cases and
   evaluations that have appeared in the peer-reviewed literature.

2.1.  Social Networking

   Social-networking applications have proliferated over the past decade
   based on overlay content dissemination systems that require large
   infrastructure investments to roll out and maintain.  Content
   dissemination is at the heart of the ICN paradigm.  Therefore, we
   would expect that social-networking scenarios are a "natural fit" for
   comparing ICN performance with traditional client-server TCP/IP-based
   systems.  Mathieu et al. [ICN-SN], for instance, illustrate how an
   Internet Service Provider (ISP) can capitalize on CCN to deploy a
   short-message service akin to Twitter at a fraction of the complexity
   of today's systems.  Their key observation is that such a service can
   be seen as a combination of multicast delivery and caching.  That is,
   a single user addresses a large number of recipients, some of which
   receive the new message immediately as they are online at that
   instant, while others receive the message whenever they connect to
   the network.

   Along similar lines, Kim et al. [VPC] present an ICN-based social-
   networking platform in which a user shares content with her/his
   family and friends without the need for centralized content servers;
   see also Section 2.4, below, and [CBIS].  Based on the CCN naming
   scheme, [VPC] takes a user name to represent a set of devices that
   belong to the person.  Other users in this in-network, serverless
   social sharing scenario can access the user's content not via a
   device name/address but with the user's name.  In [VPC], signature
   verification does not require any centralized authentication server.
   Kim and Lee [VPC2] present a proof-of-concept evaluation in which
   users with ordinary smartphones can browse a list of members or
   content using a name, and download the content selected from the

   In other words, the above-mentioned evaluation studies indicate that
   with ICN there may be no need for an end-to-end system design that
   intermediates between content providers and consumers in a hub-and-
   spoke fashion at all times.

   Earlier work by Arianfar et al. [CCR] considers a similar pull-based
   content retrieval scenario using a different architecture, pointing
   to significant performance advantages.  Although the authors consider
   a network topology (redrawn in Figure 1 for convenience) that has
   certain interesting characteristics, they do not explicitly address
   social networking in their evaluation scenario.  Nonetheless,

Top      ToC       Page 7 
   similarities are easy to spot: "followers" (such as C0, C1, ..., and
   Cz in Figure 1) obtain content put "on the network" (I1, ..., Im, and
   B1, B2) by a single user (e.g., Px) relying solely on network

   /--\     +--+     +--+     +--+               +--+
       *=== |I0| === |I1| ... |In|               |P0|
   \--/     +--+     +--+     +--+               +--+
   |C1|                           \             / o
   /--\                            +--+     +--+  o
    o                              |B1| === |B2|  o
    o              o o o o         +--+     +--+  o
    o                             /             \ o
    o       +--+     +--+     +--+                +--+
    o  *=== |Ik| === |Il| ... |Im|                |Px|
   \--/     +--+     +--+     +--+                +--+

   Figure 1.  Dumbbell with Linear Daisy Chains

   In summary, the social-networking scenario aims to exercise each ICN
   architecture in terms of network efficiency, multicast support,
   caching performance and its reliance on centralized mechanisms (or
   lack thereof).

2.2.  Real-Time Communication

   Real-time audio and video (A/V) communications include an array of
   services ranging from one-to-one voice calls to multiparty multimedia
   conferences with support ranging from whiteboards to augmented
   reality.  Real-time communications have been studied and deployed in
   the context of packet- and circuit-switched networks for decades.
   The stringent Quality of Service (QoS) requirements that this type of
   communication imposes on network infrastructure are well known.
   Since one could argue that network primitives that are excellent for
   information dissemination are not well-suited for conversational
   services, ICN evaluation studies should consider real-time
   communication scenarios in detail.

   Notably, Jacobson et al. [VoCCN] presented an early evaluation where
   the performance of a VoIP (Voice over IP) call using an information-
   centric approach was compared with that of an off-the-shelf VoIP
   implementation using RTP/UDP.  The results indicated that despite the
   extra cost of adding security support in the ICN approach,
   performance was virtually identical in the two cases evaluated in

Top      ToC       Page 8 
   their testbed.  However, the experimental setup presented is quite
   rudimentary, while the evaluation considered a single voice call
   only.  Xuan and Yan [NDNpb] revisit the same scenario but are
   primarily interested in reducing the overhead that may arise in one-
   to-one communication employing an ICN architecture.  Both studies
   illustrate that quality telephony services are feasible with at least
   one ICN approach.  That said, future ICN evaluations should employ
   standardized call arrival patterns, for example, following well-
   established methodologies from the QoS and QoE (Quality of
   Experience) evaluation toolbox and would need to consider more
   comprehensive metrics.

   Given the widespread deployment of real-time A/V communications, an
   evaluation of an ICN system should demonstrate capabilities beyond
   feasibility.  For example, with respect to multimedia conferencing,
   Zhu et al. [ACT] describe the design of a distributed audio
   conference tool based on NDN.  Their system includes ICN-based
   conference discovery, speaker discovery, and voice data distribution.
   The reported evaluation results point to gains in scalability and
   security.  Moreover, Chen et al. [G-COPSS] explore the feasibility of
   implementing a Massively Multiplayer Online Role-Playing Game
   (MMORPG) based on CCNx code and show that stringent temporal
   requirements can be met, while scalability is significantly improved
   when compared to a host-centric (IP-based) client-server system.
   This type of work points to benefits for both the data and control
   path of a modern network infrastructure.

   Real-time communication also brings up the issue of named data
   granularity for dynamically generated content.  In many cases, A/V
   data is generated in real-time and is distributed immediately.  One
   possibility is to apply a single name to the entire content, but this
   could result in significant distribution delays.  Alternatively,
   distributing A/V content in smaller "chunks" that are named
   individually may be a better option with respect to real-time
   distribution but raises naming scalability concerns.

   We observe that, all in all, the ICN research community has hitherto
   only scratched the surface of illustrating the benefits of adopting
   an information-centric approach as opposed to a host-centric one, and
   thus more work is recommended in this direction.  Scenarios in this
   category should illustrate not only feasibility but reduced
   complexity, increased scalability, reliability, and capacity to meet
   stringent QoS/QoE requirements when compared to established host-
   centric solutions.  Accordingly, the primary aim of this scenario is
   to exercise each ICN architecture in terms of its ability to satisfy
   real-time QoS requirements and provide improved user experience.

Top      ToC       Page 9 
2.3.  Mobile Networking

   IP mobility management relies on anchors to provide ubiquitous
   connectivity to end-hosts as well as moving networks [MMIN].  This is
   a natural choice for a host-centric paradigm that requires end-to-end
   connectivity and a continuous network presence for hosts [SCES].  An
   implicit assumption in host-centric mobility management is therefore
   that the mobile node aims to connect to a particular peer, as well as
   to maintain global reachability and service continuity [EEMN].
   However, with ICN, new ideas about mobility management should come to
   the fore, capitalizing on the different nature of the paradigm, such
   as native support for multihoming, abstraction of network addresses
   from applications, less dependence on connection-oriented sessions,
   and so on [MOBSURV].

   Dannewitz et al. [N-Scen] illustrate a scenario where a multiaccess
   end-host can retrieve email securely using a combination of cellular
   and Wireless Local Area Network (WLAN) connectivity.  This scenario
   borrows elements from previous work, e.g., [DTI], and develops them
   further with respect to multiaccess.  Unfortunately, Dannewitz et al.
   [N-Scen] do not present any results demonstrating that an ICN
   approach is, indeed, better.  That said, the scenario is interesting
   as it considers content specific to a single user (i.e., her mailbox)
   and does point to reduced complexity.  It is also compatible with
   recent work in the Distributed Mobility Management (DMM) Working
   Group within the IETF.  Finally, Xylomenos et al. [PSIMob] as well as
   Pentikousis [EEMN] argue that an information-centric architecture can
   avoid the complexity of having to manage tunnels to maintain end-to-
   end connectivity as is the case with mobile anchor-based protocols
   such as Mobile IP (and its variants).  Similar considerations hold
   for a vehicular (networking) environment, as we discuss in Section

   Overall, mobile networking scenarios have not been developed in
   detail, let alone evaluated at a large scale.  Further, the majority
   of scenarios discussed so far have related to the mobility of the
   information consumer, rather than the source.  We expect that in the
   coming period more papers will address this topic.  Earlier work
   [mNetInf] argues that for mobile and multiaccess networking scenarios
   we need to go beyond the current mobility management mechanisms in
   order to capitalize on the core ICN features.  They present a testbed
   setup (redrawn in Figure 2) that can serve as the basis for other ICN
   evaluations.  In this scenario, node "C0" has multiple network
   interfaces that can access local domains N0 and N1 simultaneously,
   allowing C0 to retrieve objects from whichever server (I2 or I3) can
   supply them without necessarily needing to access the servers in the
   core network "C" (P1 and P2).  Lindgren [HybICN] explores this

Top      ToC       Page 10 
   scenario further for an urban setting.  He uses simulation and
   reports sizable gains in terms of reduction of object retrieval times
   and core network capacity use.

   +------------+      +-----------+
   | Network N0 |      | Network C |
   |            |      |           |
   | +--+       | ==== |    +--+   |
   | |I2|       |      |    |P1|   |
   | +--+       |      |    +--+   |
   |     \--/   |      |           |
   +-----|C0|---+      |           |
   |     /--\   |      |           |
   | +--+       |      |           |
   | |I3|       |      |      +--+ |
   | +--+       | ==== |      |P2| |
   |            |      |      +--+ |
   | Network N1 |      |           |
   +------------+      +-----------+

   Figure 2.  Overlapping Wireless Multiaccess

   The benefits from capitalizing on the broadcast nature of wireless
   access technologies has yet to be explored to its full potential in
   the ICN literature, including quantifying possible gains in terms of
   energy efficiency [E-CHANET].  Obviously, ICN architectures must
   avoid broadcast storms.  Early work in this area considers
   distributed packet suppression techniques that exploit delayed
   transmissions and overhearing; examples can be found in [MobiA] and
   [CCNMANET] for ICN-based mobile ad-hoc networks (MANETs), and in
   [RTIND] and [CCNVANET] for vehicular scenarios.

   One would expect that mobile networking scenarios will be naturally
   coupled with those discussed in the previous sections, as more users
   access social-networking and multimedia applications through mobile
   devices.  Further, the constraints of real-time A/V applications
   create interesting challenges in handling mobility, particularly in
   terms of maintaining service continuity.  This scenario therefore
   spans across most of the others considered in this document with the
   likely need for some level of integration, particularly considering
   the well-documented increases in mobile traffic.  Mobility is further
   considered in Section 2.7 and the economic consequences of nodes
   having multiple network interfaces is explored in Section 3.1.

   Host-centric mobility management has traditionally used a range of
   metrics for evaluating performance on a per-node and network-wide
   level.  The first metric that comes to mind is handover latency,
   defined in [RFC5568] as the "period during which the mobile node is

Top      ToC       Page 11 
   unable to send or receive packets".  This metric should be considered
   in ICN performance evaluation studies dealing with mobility.  Note
   that, in IP-based networks, handover latency has been addressed by
   the introduction of mobility management protocols that aim to hide
   node mobility from the correspondent node, and often follow a make-
   before-break approach in order to ensure seamless connectivity and
   minimize (or eliminate altogether) handover latency.  The "always-on"
   and "always best connected" [ABC] paradigms have guided mobility
   management research and standardization for a good decade or so.  One
   can argue that such mechanisms are not particularly suited for ICN.
   That said, there has been a lot of interest recently in distributed
   mobility management schemes (see [MMIN] for a summary), where
   mobility management support is not "always on" by default.  Such
   schemes may be more suitable for ICN.  As a general recommendation,
   ICN designs should aim to minimize handover latency so that the end-
   user and service QoE is not affected adversely.

   Network overhead, such as the amount of signaling necessary to
   minimize handover latency, is also a metric that should be considered
   when studying ICN mobility management.  In the past, network overhead
   has been seen as one of the main factors hindering the deployment of
   various mobility solutions.  In IP-based networks, network overhead
   includes, but is not limited to, tunneling overhead, in-band control
   protocol overhead, mobile terminal and network equipment state
   maintenance and update.  ICN designs and evaluation studies should
   clearly identify the network overhead associated with handling
   mobility.  Alongside network overhead, deployment complexity should
   also be studied.

   To summarize, mobile networking scenarios should aim to provide
   service continuity for those applications that require it, decrease
   complexity and control signaling for the network infrastructure, as
   well as increase wireless capacity utilization by taking advantage of
   the broadcast nature of the medium.  Beyond this, mobile networking
   scenarios should form a cross-scenario platform that can highlight
   how other scenarios can still maintain their respective performance
   metrics during periods of high mobility.

(page 11 continued on part 2)

Next RFC Part