Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 7476

Information-Centric Networking: Baseline Scenarios

Pages: 45
Part 1 of 3 – Pages 1 to 11
None   None   Next

Top   ToC   RFC7476 - 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).
Top   ToC   RFC7476 - 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   ToC   RFC7476 - 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 supported. 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   RFC7476 - 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   RFC7476 - 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   RFC7476 - 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 list. 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   RFC7476 - 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   RFC7476 - 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   RFC7476 - 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 2.6. 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   RFC7476 - 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   RFC7476 - 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 Section