doc: Add RFC documents

1 files changed, 2523 insertions, 0 deletions

diff --git a/doc/rfc/rfc7476.txt b/doc/rfc/rfc7476.txt
new file mode 100644
index 0000000..720bb21
--- /dev/null
+++ b/doc/rfc/rfc7476.txt
@@ -0,0 +1,2523 @@
+
+
+
+
+
+
+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
+                                                                   UNIRC
+                                                                  S. Eum
+                                                                    NICT
+                                                              March 2015
+
+
+           Information-Centric Networking: Baseline Scenarios
+
+Abstract
+
+   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).
+
+
+
+
+
+
+
+
+
+
+
+Pentikousis, et al.           Informational                     [Page 1]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+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
+   5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7476.
+
+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
+   (http://trustee.ietf.org/license-info) 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pentikousis, et al.           Informational                     [Page 2]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+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
+
+
+
+
+Pentikousis, et al.           Informational                     [Page 3]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   making each information item trustworthy by itself; this can be
+   achieved, for example, by name-data integrity or by signing data
+   objects.
+
+   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
+
+
+
+
+
+Pentikousis, et al.           Informational                     [Page 4]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   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
+   <http://telematics.poliba.it/icn-baseline-scenarios>.
+
+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.
+
+
+
+
+
+
+
+Pentikousis, et al.           Informational                     [Page 5]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+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,
+
+
+
+Pentikousis, et al.           Informational                     [Page 6]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   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
+   primitives.
+
+   \--/
+   |C0|
+   /--\     +--+     +--+     +--+               +--+
+       *=== |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|
+   \--/     +--+     +--+     +--+                +--+
+   |Cz|
+   /--\
+
+   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
+
+
+
+Pentikousis, et al.           Informational                     [Page 7]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   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.
+
+
+
+
+
+Pentikousis, et al.           Informational                     [Page 8]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+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
+
+
+
+
+Pentikousis, et al.           Informational                     [Page 9]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   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
+
+
+
+Pentikousis, et al.           Informational                    [Page 10]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   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.
+
+2.4.  Infrastructure Sharing
+
+   A key idea in ICN is that the network should secure information
+   objects per se, not the communications channel that they are
+   delivered over.  This means that hosts attached to an information-
+   centric network can share resources on an unprecedented scale,
+   especially when compared to what is possible in an IP network.  All
+   devices with network access and storage capacity can contribute their
+   resources thereby increasing the value of an information-centric
+
+
+
+
+Pentikousis, et al.           Informational                    [Page 11]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   network, although compensation schemes motivating users to contribute
+   resources remain a research challenge primarily from a business
+   perspective.
+
+   For example, Jacobson et al. [CBIS] argue that in ICN the "where and
+   how" of obtaining information are new degrees of freedom.  They
+   illustrate this with a scenario involving a photo-sharing application
+   that takes advantage of whichever access network connectivity is
+   available at the moment (WLAN, Bluetooth, and even SMS) without
+   requiring a centralized infrastructure to synchronize between
+   numerous devices.  It is important to highlight that since the focus
+   of communication changes, keep-alives in this scenario are simply
+   unnecessary, as devices participating in the testbed network
+   contribute resources in order to maintain user content consistency,
+   not link state information as is the case in the host-centric
+   paradigm.  This means that the notion of "infrastructure" may be
+   completely different in the future.
+
+   Muscariello et al. [SHARE], for instance, presented early work on an
+   analytical framework that attempts to capture the storage/bandwidth
+   tradeoffs that ICN enables and can be used as the foundation for a
+   network planning tool.  In addition, Chai et al. [CL4M] explore the
+   benefits of ubiquitous caching throughout an information-centric
+   network and argue that "caching less can actually achieve more."
+   These papers also sit alongside a variety of other studies that look
+   at various scenarios such as caching HTTP-like traffic [CCNCT] and
+   BitTorrent-like traffic [BTCACHE].  We observe that much more work is
+   needed in order to understand how to make optimal use of all
+   resources available in an information-centric network.  In real-world
+   deployments, policy and commercial considerations are also likely to
+   affect the use of particular resources, and more work is expected in
+   this direction as well.
+
+   In conclusion, scenarios in this category would cover the
+   communication-computation-storage tradeoffs that an ICN deployment
+   must consider.  This would exercise features relating to network
+   planning, perhaps capitalizing on user-provided resources, as well as
+   operational and economical aspects of ICN, and contrast them with
+   other approaches.  An obvious baseline to compare against in this
+   regard is existing federations of IP-based Content Distribution
+   Networks (CDNs), such as the ones discussed in the IETF Content
+   Delivery Networks Interconnection Working Group.
+
+
+
+
+
+
+
+
+
+Pentikousis, et al.           Informational                    [Page 12]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+2.5.  Content Dissemination
+
+   Content dissemination has attracted more attention than other aspects
+   of ICN.  Scenarios in this category abound in the literature,
+   including stored and streaming A/V distribution, file distribution,
+   mirroring and bulk transfers, versioned content services (cf.
+   Subversion-type revision control), as well as traffic aggregation.
+
+   Decentralized content dissemination with on-the-fly aggregation of
+   information sources was envisaged in [N-Scen], where information
+   objects can be dynamically assembled based on hierarchically
+   structured subcomponents.  For example, a video stream could be
+   associated with different audio streams and subtitle sets, which can
+   all be obtained from different sources.  Using the topology depicted
+   in Figure 1 as an example, an application at C1 may end up obtaining,
+   say, the video content from I1, but the user-selected subtitles from
+   Px.  Semantics and content negotiation, on behalf of the user, were
+   also considered, e.g., for the case of popular tunes that may be
+   available in different encoding formats.  Effectively, this scenario
+   has the information consumer issuing independent requests for content
+   based on information identifiers, and stitching the pieces together
+   irrespective of "where" or "how" they were obtained.
+
+   A case in point for content dissemination are vehicular ad hoc
+   networks (VANETs), as an ICN approach may address their needs for
+   information dissemination between vehicles better than today's
+   solutions, as discussed in the following section.  The critical part
+   of information dissemination in a VANET scenario revolves around
+   "where" and "when".  For instance, one may be interested in traffic
+   conditions 2 km ahead while having no interest in similar information
+   about the area around the path origin.  VANET scenarios may provide
+   fertile ground for showcasing the ICN advantage with respect to
+   content dissemination especially when compared with current host-
+   centric approaches.  That said, information integrity and filtering
+   are challenges that must be addressed.  As mentioned above, content
+   dissemination scenarios in VANETs have a particular affinity to the
+   mobility scenarios discussed in Section 2.3.
+
+   Content dissemination scenarios, in general, have a large overlap
+   with those described in the previous sections and are explored in
+   several papers, such as [DONA], [PSI], [PSIMob], [NetInf], [CCN],
+   [CBIS], and [CCR], just to name a few.  In addition, Chai et al.
+   [CURLING] present a hop-by-hop hierarchical content resolution
+   approach that employs receiver-driven multicast over multiple
+   domains, advocating another content dissemination approach.  Yet,
+   largely, work in this area did not address the issue of access
+   authorization in detail.  Often, the distributed content is mostly
+   assumed to be freely accessible by any consumer.  Distribution of
+
+
+
+Pentikousis, et al.           Informational                    [Page 13]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   paid-for or otherwise restricted content on a public ICN network
+   requires more attention in the future.  Fotiou et al. [ACDICN]
+   consider a scheme to this effect, but it still requires access to an
+   authorization server to verify the user's status after the
+   (encrypted) content has been obtained.  This may effectively negate
+   the advantage of obtaining the content from any node, especially in a
+   disruption-prone or mobile network.
+
+   In summary, scenarios in this category aim to exercise primarily
+   scalability and the cost and performance attributes of content
+   dissemination.  Particularly, they should highlight the ability of an
+   ICN to scale to billions of objects, while not exceeding the cost of
+   existing content dissemination solutions (i.e., CDNs) and, ideally,
+   increasing performance.  These should be shown in a holistic manner,
+   improving content dissemination for both information consumers and
+   publishers of all sizes.  We expect that in particular for content
+   dissemination, in both extreme as well as typical scenarios, can be
+   specified by drawing data from current CDN deployments.
+
+2.6.  Vehicular Networking
+
+   Users "on wheels" are interested in road safety, traffic efficiency,
+   and infotainment applications that can be supported through vehicle-
+   to-vehicle (V2V) and vehicle-to-infrastructure (V2I) wireless
+   communications.  These applications exhibit unique features in terms
+   of traffic generation patterns, delivery requirements, and spatial
+   and temporal scope, which pose great challenges to traditional
+   networking solutions.  VANETs, by their nature, are characterized by
+   challenges such as fast-changing topology, intermittent connectivity,
+   and high node mobility, but also by the opportunity to combine
+   information from different sources as each vehicle does not care
+   about "who" delivers the named data objects.
+
+   ICN is an attractive candidate solution for vehicular networking, as
+   it has several advantages.  First, ICN fits well to the nature of
+   typical vehicular applications that are geography- and time-dependent
+   (e.g., road traveler information, accident warning, point-of-interest
+   advertisements) and usually target vehicles in a given area,
+   regardless of their identity or IP address.  These applications are
+   likely to benefit from in-network and decentralized data caching and
+   replication mechanisms.  Second, content caching is particularly
+   beneficial for intermittent on-the-road connectivity and can speed up
+   data retrieval through content replication in several nodes.  Caching
+   can usually be implemented at relatively low cost in vehicles, as the
+   energy demands of the ICN device are likely to be a negligible
+   fraction of the total vehicle energy consumption, thus allowing for
+   sophisticated processing, continuous communication, and adequate
+   storage in the vehicle.  Finally, ICN natively supports asynchronous
+
+
+
+Pentikousis, et al.           Informational                    [Page 14]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   data exchange between end-nodes.  By using (and redistributing)
+   cached named information objects, a mobile node can serve as a link
+   between disconnected areas.  In short, ICN can enable communication
+   even under intermittent network connectivity, which is typical of
+   vehicular environments with sparse roadside infrastructure and fast-
+   moving nodes.
+
+   The advantages of ICN in vehicular networks were preliminarily
+   discussed in [EWC] and [DMND], and additionally investigated in
+   [DNV2V], [RTIND], [CCNHV], [CCDIVN], [CCNVANET], and [CRoWN].  For
+   example, Bai and Krishnamachari [EWC] take advantage of the localized
+   and dynamic nature of a VANET to explore how a road congestion
+   notification application can be implemented.  Wang et al. [DMND]
+   consider data collection where Road-Side Units (RSUs) collect
+   information from vehicles by broadcasting NDN-like Interest packets.
+   The proposed architecture is evaluated using simulation in a grid
+   topology and is compared against a host-centric alternative based on
+   Mobile IP.  See Figure 3 for an indicative example of an urban VANET
+   topology.  Their results indicate high efficiency for ICN even at
+   high speeds.  That said, this work is a preliminary exploration of
+   ICN in vehicular environments, so various issues remain for
+   evaluation.  They include system scalability to large numbers of
+   vehicles and the impact of vehicles that forward Interest packets or
+   relay data to other vehicles.
+
+      + - - _- - -_- - - -_- - _- - - +
+      |    /_\   /_\     /_\  /_\     |
+      |    o o   o o     o o  o o     |
+      |    +-------+     +-------+ _  |
+      |    |       |     |       |/_\ |
+      |  _ |       |     |       |o o |
+      | /_\|       |    |       |     |
+      | o o+--_----+\===/+--_----+    |
+      |      /_\    |RSU|  /_\        |
+      |      o o    /===\  o o        |
+      |    +-------+     +-------+ _  |
+      |    |       |     |       |/_\ |
+      | _  |       |     |       |o o |
+      |/_\ |       |     |       |    |
+      |o o +_-----_+     +_-----_+    |
+      |    /_\   /_\     /_\   /_\    |
+      +_ _ o_o_ _o_o_ _ _o_o_ _o_o_ _ +
+
+   Figure 3.  Urban Grid VANET Topology
+
+   As mentioned in the previous section, due to the short communication
+   duration between a vehicle and the RSU, and the typically short time
+   of sustained connectivity between vehicles, VANETs may be a good
+
+
+
+Pentikousis, et al.           Informational                    [Page 15]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   showcase for the ICN advantages with respect to content
+   dissemination.  Wang et al. [DNV2V], for instance, analyze the
+   advantages of hierarchical naming for vehicular traffic information
+   dissemination.  Arnould et al. [CCNHV] apply ICN principles to safety
+   information dissemination between vehicles with multiple radio
+   interfaces.  In [CCDIVN], TalebiFard and Leung use network coding
+   techniques to improve content dissemination over multiple ICN paths.
+   Amadeo et al. [CCNVANET] [CRoWN] propose an application-independent
+   ICN framework for content retrieval and distribution where the role
+   of provider can be played equivalently by both vehicles and RSUs.
+   ICN forwarding is extended through path-state information carried in
+   Interest and Data packets, stored in a new data structure kept by
+   vehicular nodes, and exploited also to cope with node mobility.
+
+   Typical scenarios for testing content distribution in VANETs may be
+   highways with vehicles moving in straight lines, with or without RSUs
+   along the road, as shown in Figure 4.  With an NDN approach in mind,
+   for example, RSUs may send Interest packets to collect data from
+   vehicles [DMND], or vehicles may send Interest packets to collect
+   data from other peers [RTIND] or from RSUs [CCNVANET].  Figure 2
+   applies to content dissemination in VANET scenarios as well, where C0
+   represents a vehicle that can obtain named information objects via
+   multiple wireless peers and/or RSUs (I2 and I3 in the figure).  Grid
+   topologies such as the one illustrated in Figure 3 should be
+   considered in urban scenarios with RSUs at the crossroads or
+   co-located with traffic lights as in [CRoWN].
+
+        \___/                    \___/
+        |RSU|                    |RSU|
+      ================================
+           _     _     _     _
+          /_\   /_\   /_\   /_\
+      _ _ o_o_ _o_o_ _o_o_ _o_o_ _ _ _
+           _     _     _     _
+          /_\   /_\   /_\   /_\
+          o o   o o   o o   o o
+      ================================
+
+   Figure 4.  Highway VANET Topology
+
+   To summarize, VANET scenarios aim to exercise ICN deployment from
+   various perspectives, including scalability, caching, transport, and
+   mobility issues.  There is a need for further investigation in (i)
+   challenging scenarios (e.g., disconnected segments); (ii) scenarios
+   involving both consumer and provider mobility; (iii) smart caching
+   techniques that take into consideration node mobility patterns,
+   spatial and temporal relevance, content popularity, and social
+   relationships between users/vehicles; (iv) identification of new
+
+
+
+Pentikousis, et al.           Informational                    [Page 16]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   applications (beyond data dissemination and traffic monitoring) that
+   could benefit from the adoption of an ICN paradigm in vehicular
+   networks (e.g., mobile cloud, social networking).
+
+2.7.  Delay- and Disruption-Tolerance
+
+   Delay- and Disruption-Tolerant Networking (DTN) originated as a means
+   to extend the Internet to interplanetary communications [DTN].
+   However, it was subsequently found to be an appropriate architecture
+   for many terrestrial situations as well.  Typically, this was where
+   delays were greater than protocols such as TCP could handle, and
+   where disruptions to communications were the norm rather than
+   occasional annoyances, e.g., where an end-to-end path does not
+   necessarily exist when communication is initiated.  DTN has now been
+   applied to many situations, including opportunistic content sharing,
+   handling infrastructural issues during emergency situations (e.g.,
+   earthquakes) and providing connectivity to remote rural areas without
+   existing Internet provision and little or no communications or power
+   infrastructure.
+
+   The DTN architecture [RFC4838] is based on a "store, carry, and
+   forward" paradigm that has been applied extensively to situations
+   where data is carried between network nodes by a "data mule", which
+   carries bundles of data stored in some convenient storage medium
+   (e.g., a USB memory stick).  With the advent of sensor and peer-to-
+   peer (P2P) networks between mobile nodes, DTN is becoming a more
+   commonplace type of networking than originally envisioned.  Since ICN
+   also does not rely on the familiar end-to-end communications
+   paradigm, there are clear synergies [DTNICN].  It could therefore be
+   argued that many of the key principles embodied within DTN also exist
+   in ICN, as we explain next.
+
+   First, both approaches rely on in-network storage.  In the case of
+   DTN, bundles are stored temporarily on devices on a hop-by-hop basis.
+   In the case of ICN, information objects are also cached on devices in
+   a similar fashion.  As such, both paradigms must provision storage
+   within the network.
+
+   Second, both approaches espouse late binding of names to locations
+   due to the potentially large interval between request and response
+   generation.  In the case of DTN, it is often impossible to predict
+   the exact location (in a disconnected topology) where a node will be
+   found.  Similarly, in the case of ICN, it is also often impossible to
+   predict where an information object might be found.  As such, the
+   binding of a request/bundle to a destination (or routing locator)
+   must be performed as late as possible.
+
+
+
+
+
+Pentikousis, et al.           Informational                    [Page 17]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   Finally, both approaches treat data as a long-lived component that
+   can exist in the network for extended periods of time.  In the case
+   of DTN, bundles are carried by nodes until appropriate next hops are
+   discovered.  In the case of ICN, information objects are typically
+   cached until storage is exhausted.  As such, both paradigms require a
+   direct shift in the way applications interact with the network.
+
+   Through these similarities, it becomes possible to identify many DTN
+   principles that are already in existence within ICN architectures.
+   For example, ICN nodes will often retain information objects locally,
+   making them accessible later on, much as DTN bundles are handled.
+   Consequently, these synergies suggest strong potential for marrying
+   the two technologies.  This could include, for instance, building new
+   integrated Information-Centric Delay Tolerant Network (ICDTN)
+   protocols or, alternatively, building ICN schemes over existing DTN
+   protocols (and vice versa).
+
+   The above similarities suggest that integration of the two principles
+   would be feasible.  Beyond this, there are also a number of
+   identifiable direct benefits.  Through caching and replication, ICN
+   offers strong information resilience, whilst, through store-and-
+   forward, DTN offers strong connectivity resilience.  As such, both
+   architectures could benefit greatly from each other.  Initial steps
+   have already been taken in the DTN community to integrate ICN
+   principles, e.g., the Bundle Protocol Query Block [BPQ] has been
+   proposed for the DTN Bundle Protocol [RFC5050].  Similarly, initial
+   steps have also been taken in the ICN community, such as [SLINKY].
+   In fact, the Scalable and Adaptive Internet Solutions (SAIL) project
+   has developed a prototype implementation of NetInf running over the
+   DTN Bundle Protocol.
+
+   Of course, in many circumstances, information-centricity is not
+   appropriate for use in delay- and disruption-tolerant environments.
+   This is particularly the case when information is not the key
+   communications atom transmitted.  Further, situations where a single
+   sink is always used for receiving information may not warrant the
+   identification and routing of independent information objects.
+   However, there are a number of key scenarios where clear benefits
+   could be gained by introducing information-centric principles into
+   DTNs, two of which we describe later in this section.
+
+   For the purpose of evaluating the use of ICNs in a DTN setting, two
+   key scenarios are identified in this document.  (Note the rest of
+   this section uses the term "ICDTN".)  These are both prominent use
+   cases that are currently active in both the ICN and DTN communities.
+   The first is opportunistic content sharing, whilst the second is the
+   use of ad hoc networks during disaster recovery (e.g., earthquakes).
+   We discuss both types of scenarios in the context of a simulation-
+
+
+
+Pentikousis, et al.           Informational                    [Page 18]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   based evaluation: due to the scale and mobility of DTN-like setups,
+   this is the primary method of evaluation used.  Within the DTN
+   community, the majority of simulations are performed using the
+   Opportunistic Network Environment (ONE) simulator [ONE], which is
+   referred to in this document.  Before exploring the two scenarios,
+   the key shared components of their simulation are discussed.  This is
+   separated into the two primary inputs that are required: the
+   environment and the workload.
+
+   In both types of scenarios the environment can be abstractly modeled
+   by a time series of active connections between device pairs.  Unlike
+   other scenarios in this document, an ICDTN scenario therefore does
+   not depend on (relatively) static topologies but, rather, a set of
+   time-varying disconnected topologies.  In opportunistic networks,
+   these topologies are actually products of the mobility of users.  For
+   example, if two users walk past each other, an opportunistic link can
+   be created.  There are two methods used to generate these mobility
+   patterns and, in turn, the time series of topologies.  The first is
+   synthetic, whereby a (mathematical) model of user behavior is created
+   in an agent-based fashion, e.g., random waypoint, Gauss-Markov.  The
+   second is trace-driven, whereby the mobility of real users is
+   recorded and used.  In both cases, the output is a sequence of time-
+   stamped "contacts", i.e., periods of time in which two devices can
+   communicate.  An important factor missing from typical mobility
+   traces, however, is the capacity of these contacts: how much data can
+   be transferred?  In both approaches to modeling mobility, links are
+   usually configured as Bluetooth or Wi-Fi (ONE easily allows this,
+   although lower-layer considerations are ignored, e.g., interference).
+   This is motivated by the predominance of these technologies on mobile
+   phones.
+
+   The workload in an ICDTN is modeled much like the workload within the
+   other scenarios.  It involves object creation/placement and object
+   retrieval.  Object creation/placement can either be done statically
+   at the beginning of the simulations or, alternatively, dynamically
+   based on a model of user behavior.  In both cases, the latter is
+   focused on, as it models far better the characteristics of the
+   scenarios.
+
+   Once the environment and workload have been configured, the next step
+   is to decide the key metrics for the study.  Unlike traditional
+   networking, the QoS expectation is typically far lower in an ICDTN,
+   thereby moving away from metrics such as throughput.  At a high
+   level, it is of clear interest to evaluate different ICN approaches
+   with respect to both their delay- and disruption-tolerance (i.e., how
+   effective is the approach when used in an environment subject to
+   significant delay and/or disruption) and to their active support for
+   operations in a DTN environment.
+
+
+
+Pentikousis, et al.           Informational                    [Page 19]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   The two most prominent metrics considered in a host-centric DTN are
+   delivery probability and delivery delay.  The former relates to the
+   probability by which a sent message will be received within a certain
+   delay bound, whilst the latter captures the average length of time it
+   takes for nodes to receive the message.  These metrics are similarly
+   important in an ICDTN, although they are slightly different due to
+   the request-response nature of ICN.  Therefore, the two most
+   prominent evaluative metrics are satisfaction probability and
+   satisfaction delay.  The former refers to the probability by which an
+   information request (e.g., Interest) will be satisfied (i.e., how
+   often a Data response will be received).  Satisfaction delay refers
+   to the length of time it takes an information request to be
+   satisfied.
+
+   Note that the key difference between the host-centric and
+   information-centric metrics is the need for a round-trip rather than
+   a one-way communication.  Beyond this, depending on the focus of the
+   work, other elements that may be investigated include name
+   resolution, routing, and forwarding in disconnected parts of the
+   network; support for unidirectional links; number of round trips
+   needed to complete a data transfer; long-term content availability
+   (or resilience); efficiency in the face of disruption; and so on.  It
+   is also important to weigh these performance metrics against the
+   necessary overheads.  In the case of an ICDTN, this is generally
+   measured by the number of message replicas required to access
+   content.  Note that routing in a DTN is often replication based,
+   which leads to many copies of the same message.
+
+2.7.1.  Opportunistic Content Sharing
+
+   The first key baseline scenario in this context is opportunistic
+   content sharing.  This occurs when mobile nodes create opportunistic
+   links between each other to share content of interest.  For example,
+   people riding on an underground train can pass news items between
+   their mobile phones.  Equally, content generated on the phones (e.g.,
+   tweets [TWIMIGHT]) could be stored for later forwarding (or even
+   forwarded amongst interested passengers on the train).  Such
+   scenarios, clearly, must be based around either the altruistic or
+   incentivized interaction amongst users.  The latter is a particularly
+   active area of research.  These networks are often termed "pocket-
+   switched networks", as they are independently formed between the user
+   devices.  Here, the evaluative scenario of ICDTN microblogging is
+   proposed.  As previously discussed, the construction of such an
+   evaluative scenario requires a formalization of its environment and
+   workload.  Fortunately, there exist a number of datasets that offer
+   exactly this information required for microblogging.
+
+
+
+
+
+Pentikousis, et al.           Informational                    [Page 20]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   In terms of the environment (i.e., mobility patterns), the Haggle
+   project produced contact traces based on conference attendees using
+   Bluetooth.  These traces are best targeted at application scenarios
+   in which a small group of (50-100) people are in a relatively
+   confined space.  In contrast, larger-scale traces are also available,
+   most notably MIT's Reality Mining project.  These are better suited
+   for cases where longer-term movement patterns are of interest.
+
+   The second input, workload, relates to the creation and consumption
+   of microblogs (e.g., tweets).  This can be effectively captured
+   because subscriptions conveniently formalize who consumes what.  For
+   bespoke purposes, specific data can be directly collected from
+   Twitter for trace-driven simulations.  Several Twitter datasets are
+   already available to the community containing a variety of data,
+   ranging from Tweets to follower graphs.  See
+   <http://www.tweetarchivist.com> and
+   <http://socialcomputing.asu.edu/datasets/Twitter>.  These datasets
+   can therefore be used to extract information production, placement,
+   and consumption.
+
+2.7.2.  Emergency Support and Disaster Recovery
+
+   The second key baseline scenario in this context relates to the use
+   of ICDTNs in emergency scenarios.  In these situations, it is typical
+   for infrastructure to be damaged or destroyed, leading to the
+   collapse of traditional forms of communications (e.g., cellular
+   telephone networks).  This has been seen in the recent North Indian
+   flooding, as well as the 2011 Tohoku earthquake and tsunami.  Power
+   problems often exacerbate the issue, with communication failures
+   lasting for days.  Therefore, in order to address this, DTNs have
+   been used due to their high levels of resilience and independence
+   from fixed infrastructure.  The most prominent use of DTNs in
+   disaster areas would be the dissemination of information, e.g.,
+   warnings and evacuation maps.  Unlike the previous scenario, it can
+   be assumed that certain users (e.g., emergency responders) are highly
+   altruistic.  However, it is likely many other users (e.g., endangered
+   civilians) might become far more conservative in how they use their
+   devices for battery-conserving purposes.  Here, we focus on the
+   dissemination of standard broadcast information that should be
+   received by all parties; generally, this is something led by
+   emergency responders.
+
+   For the environmental setup, there are no commonly used mobility
+   traces for disaster zones, unlike in the previous scenario.  This is
+   clearly due to the difficultly (near impossibility) of acquiring them
+   in a real setting.  That said, various synthetic models are
+   available.  The Post-Disaster Mobility Model [MODEL1] models
+   civilians and emergency responders after a disaster has occurred,
+
+
+
+Pentikousis, et al.           Informational                    [Page 21]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   with people attempting to reach evacuation points (this has also been
+   implemented in the ONE simulator).  Aschenbruck et al. [MODEL2] focus
+   on emergency responders, featuring the removal of nodes from the
+   disaster zone, as well as things like obstacles (e.g., collapsed
+   buildings).  Cabrero et al. [MODEL3] also look at emergency
+   responders but focus on patterns associated with common procedures.
+   For example, command and control centers are typically set up with
+   emergency responders periodically returning.  Clearly, the mobility
+   of emergency responders is particularly important in this setting
+   because they usually are the ones who will "carry" information into
+   the disaster zone.  It is recommended that one of these emergency-
+   specific models be used during any evaluations, due to the inaccuracy
+   of alternate models used for "normal" behavior.
+
+   The workload input in this evaluative scenario is far simpler than
+   for the previous scenario.  In emergency cases, the dissemination of
+   individual pieces of information to all parties is the norm.  This is
+   often embodied using things like the Common Alert Protocol (CAP),
+   which is an XML standard for describing warning message.  It is
+   currently used by various systems, including the Integrated Public
+   Alert & Warning System and Google Crisis Response.  As such, small
+   objects (e.g., 512 KB to 2 MB) are usually generated containing text
+   and images; note that the ONE simulator offers utilities to easily
+   generate these.  These messages are also always generated by central
+   authorities, therefore making the placement problem easier (they
+   would be centrally generated and given to emergency responders to
+   disseminate as they pass through the disaster zone).  The key
+   variable is therefore the generation rate, which is synonymous with
+   the rate that microblogs are written in the previous scenario.  This
+   will largely be based on the type of disaster occurring; however,
+   hourly updates would be an appropriate configuration.  Higher rates
+   can also be tested, based on the rate at which situations change
+   (landslides, for example, can exhibit highly dynamic properties).
+
+   To summarize, this section has highlighted the applicability of ICN
+   principles to existing DTN scenarios.  Two evaluative setups have
+   been described in detail, namely, mobile opportunistic content
+   sharing (microblogging) and emergency information dissemination.
+
+2.8.  Internet of Things
+
+   Advances in electronics miniaturization combined with low-power
+   wireless access technologies (e.g., ZigBee, Near Field Communication
+   (NFC), Bluetooth, and others) have enabled the coupling of
+   interconnected digital services with everyday objects.  As devices
+   with sensors and actuators connect into the network, they become
+   "smart objects" and form the foundation for the so-called Internet of
+
+
+
+
+Pentikousis, et al.           Informational                    [Page 22]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   Things (IoT).  IoT is expected to increase significantly the amount
+   of content carried by the network due to machine-to-machine (M2M)
+   communication as well as novel user-interaction possibilities.
+
+   Yet, the full potential of IoT does not lie in simple remote access
+   to smart object data.  Instead, it is the intersection of Internet
+   services with the physical world that will bring about the most
+   dramatic changes.  Burke [IoTEx], for instance, makes a very good
+   case for creating everyday experiences using interconnected things
+   through participatory sensing applications.  In this case, inherent
+   ICN capabilities for data discovery, caching, and trusted
+   communication are leveraged to obtain sensor information and enable
+   content exchange between mobile users, repositories, and
+   applications.
+
+   Kutscher and Farrell [IWMT] discuss the benefits that ICN can provide
+   in these environments in terms of naming, caching, and optimized
+   transport.  The Named Information URI scheme (ni) [RFC6920], for
+   instance, could be used for globally unique smart object
+   identification, although an actual implementation report is not
+   currently available.  Access to information generated by smart
+   objects can be of varied nature and often vital for the correct
+   operation of large systems.  As such, supporting timestamping,
+   security, scalability, and flexibility need to be taken into account.
+
+   Ghodsi et al. [NCOA] examine hierarchical and self-certifying naming
+   schemes and point out that ensuring reliable and secure content
+   naming and retrieval may pose stringent requirements (e.g., the
+   necessity for employing PKI), which can be too demanding for low-
+   powered nodes, such as sensors.  That said, earlier work by Heidemann
+   et al. [nWSN] shows that, for dense sensor network deployments,
+   disassociating sensor naming from network topology and using named
+   content at the lowest level of communication in combination with in-
+   network processing of sensor data is feasible in practice and can be
+   more efficient than employing a host-centric binding between node
+   locator and the content existing therein.
+
+   Burke et al. [NDNl] describe the implementation of a building
+   automation system for lighting control where the security, naming,
+   and device discovery NDN mechanisms are leveraged to provide
+   configuration, installation, and management of residential and
+   industrial lighting control systems.  The goal is an inherently
+   resilient system, where even smartphones can be used for control.
+   Naming reflects fixtures with evolved identification and node-
+   reaching capabilities, thus simplifying bootstrapping, discovery, and
+   user interaction with nodes.  The authors report that this ICN-based
+   system requires less maintenance and troubleshooting than typical
+   IP-based alternatives.
+
+
+
+Pentikousis, et al.           Informational                    [Page 23]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   Biswas et al. [CIBUS] visualize ICN as a contextualized information-
+   centric bus (CIBUS) over which diverse sets of service producers and
+   consumers coexist with different requirements.  ICN is leveraged to
+   unify different platforms to serve consumer-producer interaction in
+   both infrastructure and ad hoc settings.  Ravindran et al. [Homenet]
+   show the application of this idea in the context of a home network,
+   where consumers (residents) require policy-driven interactions with
+   diverse services such as climate control, surveillance systems, and
+   entertainment systems.  Name-based protocols are developed to enable
+   zero-configuration node and service discovery, contextual service
+   publishing and subscription, policy-based routing and forwarding with
+   name-based firewall, and hoc device-to-device communication.
+
+   IoT exposes ICN concepts to a stringent set of requirements that are
+   exacerbated by the quantity of nodes, as well as by the type and
+   volume of information that must be handled.  A way to address this is
+   proposed in [IoTScope], which tackles the problem of mapping named
+   information to an object, diverting from the currently typical
+   centralized discovery of services and leveraging the intrinsic ICN
+   scalability capabilities for naming.  It extends the base [PURSUIT]
+   design with hierarchically based scopes, facilitating lookup, access,
+   and modifications of only the part of the object information that the
+   user is interested in.  Another important aspect is how to
+   efficiently address resolution and location of the information
+   objects, particularly when large numbers of nodes are connected, as
+   in IoT deployments.  In [ICN-DHT], Katsaros et al. propose a
+   Distributed Hash Table (DHT) that is compared with the Data-Oriented
+   Network Architecture described in [DONA].  Their results show how
+   topological routing information has a positive impact on resolution,
+   at the expense of memory and processing overhead.
+
+   The use of ICN mechanisms in IoT scenarios faces the most dynamic and
+   heterogeneous type of challenges, when taking into consideration the
+   requirements and objectives of such integration.  The disparity in
+   technologies (not only in access technologies, but also in terms of
+   end-node diversity such as sensors, actuators, and their
+   characteristics) as well as in the information that is generated and
+   consumed in such scenarios, will undoubtedly bring about many of the
+   considerations presented in the previous sections.  For instance, IoT
+   shares similarities with the constraints and requirements applicable
+   to vehicular networking.  Here, a central problem is the deployment
+   of mechanisms that can use opportunistic connectivity in unreliable
+   networking environments (similar to the vehicular networking and DTN
+   scenarios).
+
+   However, one important concern in IoT scenarios, also motivated by
+   this strongly heterogeneous environment, is how content dissemination
+   will be affected by the different semantics of the disparate
+
+
+
+Pentikousis, et al.           Informational                    [Page 24]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   information and content being shared.  In fact, this is already a
+   difficult problem that goes beyond the scope of ICN [SEMANT].  With
+   the ability of the network nodes to cache forwarded information to
+   improve future requests, a challenge arises regarding whether the ICN
+   fabric should be involved in any kind of procedure (e.g., tagging)
+   that facilitates the relationship or the interpretation of the
+   different sources of information.
+
+   Another issue lies with the need for having energy-efficiency
+   mechanisms related to the networking capabilities of IoT
+   infrastructures.  Often, the devices in IoT deployments have limited
+   battery capabilities, and thus need low power consumption schemes
+   working at multiple levels.  In principle, energy efficiency gains
+   should be observed from the inherent in-network caching capability.
+   However, this might not be the most usual case in IoT scenarios,
+   where the information (particularly from sensors or controlling
+   actuators) is more akin to real-time traffic, thus reducing the scale
+   of potential savings due to ubiquitous in-network caching.
+
+   ICN approaches, therefore, should be evaluated with respect to their
+   capacity to handle the content produced and consumed by extremely
+   large numbers of diverse devices.  IoT scenarios aim to exercise ICN
+   deployment from different aspects, including ICN node design
+   requirements, efficient naming, transport, and caching of time-
+   restricted data.  Scalability is particularly important in this
+   regard as the successful deployment of IoT principles could increase
+   both device and content numbers dramatically beyond all current
+   expectations.
+
+2.9.  Smart City
+
+   The rapid increase in urbanization sets the stage for the most
+   compelling and challenging environments for networking.  By 2050 the
+   global population will reach nine billion people, 75% of which will
+   dwell in urban areas.  In order to cope with this influx, many cities
+   around the world have started their transformation toward the "smart
+   city" vision.  Smart cities will be based on the following innovation
+   axes: smart mobility, smart environment, smart people, smart living,
+   and smart governance.  In development terms, the core goal of a smart
+   city is to become a business-competitive and attractive environment,
+   while serving citizen well-being [CPG].
+
+   In a smart city, ICT plays a leading role and acts as the glue
+   bringing together all actors, services, resources (and their
+   interrelationships) that the urban environment is willing to host and
+   provide [MVM].  ICN appears particularly suitable for these
+   scenarios.  Domains of interest include intelligent transportation
+   systems, energy networks, health care, A/V communications, peer-to-
+
+
+
+Pentikousis, et al.           Informational                    [Page 25]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   peer and collaborative platforms for citizens, social inclusion,
+   active participation in public life, e-government, safety and
+   security, and sensor networks.  Clearly, this scenario has close ties
+   to the vision of IoT, discussed in the previous section, as well as
+   to vehicular networking.
+
+   Nevertheless, the road to build a real information-centric digital
+   ecosystem will be long, and more coordinated effort is required to
+   drive innovation in this domain.  We argue that smart-city needs and
+   ICN technologies can trigger a virtuous innovation cycle toward
+   future ICT platforms.  Recent concrete ICN-based contributions have
+   been formulated for home energy management [iHEMS], geo-localized
+   services [ACC], smart-city services [IB], and traffic information
+   dissemination in vehicular scenarios [RTIND].  Some of the proposed
+   ICN-based solutions are implemented in real testbeds, while others
+   are evaluated through simulation.
+
+   Zhang et al. [iHEMS] propose a secure publish-subscribe architecture
+   for handling the communication requirements of Home Energy Management
+   Systems (HEMS).  The objective is to safely and effectively collect
+   measurement and status information from household elements, aggregate
+   and analyze the data, and ultimately enable intelligent control
+   decisions for actuation.  They consider a simple experimental testbed
+   for their proof-of-concept evaluation, exploiting open source code
+   for the ICN implementation, and emulating some node functionality in
+   order to facilitate system operation.
+
+   A different scenario is considered in [ACC], where DHTs are employed
+   for distributed, scalable, and geographically aware service lookup in
+   a smart city.  Also in this case, the ICN application is validated by
+   considering a small-scale testbed: a small number of nodes are
+   emulated with simple embedded PCs or specific hardware boards (e.g.,
+   for some sensor nodes); other nodes (which connect the principal
+   actors of the tests) are emulated with workstations.  The proposal in
+   [IB] draws from a smart-city scenario (mainly oriented towards waste
+   collection management) comprising sensors and moving vehicles, as
+   well as a cloud-computing system that supports data retrieval and
+   storage operations.  The main aspects of this proposal are analyzed
+   via simulation using open source code that is publicly available.
+   Some software applications are designed on real systems (e.g., PCs
+   and smartphones).
+
+   With respect to evaluating ICN approaches in smart-city scenarios, it
+   is necessary to consider generic metrics useful to track and monitor
+   progress on services results and also for comparing localities
+   between themselves and learn from the best [ISODIS].  In particular,
+   it is possible to select a specific set of Key Performance Indicators
+   (KPIs) for a given project in order to evaluate its success.  These
+
+
+
+Pentikousis, et al.           Informational                    [Page 26]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   KPIs may reflect the city's environmental and social goals, as well
+   as its economic objectives, and they can be calculated at the global,
+   regional, national, and local levels.  Therefore, it is not possible
+   to define a unique set of interesting metrics, but in the context of
+   smart cities, the KPIs should be characterized with respect to the
+   developed set of services offered by using the ICN paradigm.
+
+   To sum up, smart-city scenarios aim to exercise several ICN aspects
+   in an urban environment.  In particular, they can be useful to (i)
+   analyze the capacity of using ICN for managing extremely large data
+   sets; (ii) study ICN performance in terms of scalability in
+   distributed services; (iii) verify the feasibility of ICN in a very
+   complex application like vehicular communication systems; and (iv)
+   examine the possible drawbacks related to privacy and security issues
+   in complex networked environments.
+
+3.  Cross-Scenario Considerations
+
+   This section discusses considerations that span multiple scenarios.
+
+3.1.  Multiply Connected Nodes and Economics
+
+   The evolution of, in particular, wireless networking technologies has
+   resulted in a convergence of the bandwidth and capabilities of
+   various different types of network.  Today, a leading-edge mobile
+   telephone or tablet computer will typically be able to access a Wi-Fi
+   access point, a 4G cellular network, and the latest generation of
+   Bluetooth local networking.  Until recently, a node would usually
+   have a clear favorite network technology appropriate to any given
+   environment.  The choice would, for example, be primarily determined
+   by the available bandwidth with cost as a secondary determinant.
+   Furthermore, it is normally the case that a device only uses one of
+   the technologies at a time for any particular application.
+
+   It seems likely that this situation will change so that nodes are
+   able to use all of the available technologies in parallel.  This will
+   be further encouraged by the development of new capabilities in
+   cellular networks including Small Cell Networks [SCN] and
+   Heterogeneous Networks [HetNet].  Consequently, mobile devices will
+   have similar choices to wired nodes attached to multiple service
+   providers allowing "multihoming" via the various different
+   infrastructure networks as well as potential direct access to other
+   mobile nodes via Bluetooth or a more capable form of ad hoc Wi-Fi.
+
+   Infrastructure networks are generally under the control of separate
+   economic entities that may have different policies about the
+   information of an ICN deployed within their network caches.  As ICN
+   shifts the focus from nodes to information objects, the interaction
+
+
+
+Pentikousis, et al.           Informational                    [Page 27]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   between networks will likely evolve to capitalize on data location
+   independence, efficient and scalable in-network named object
+   availability, and access via multiple paths.  These interactions
+   become critical in evaluating the technical and economic impact of
+   ICN architectural choices, as noted in [ArgICN].  Beyond simply
+   adding diversity in deployment options, these networks have the
+   potential to alter the incentives among existing (and future, we may
+   add) network players, as noted in [EconICN].
+
+   Moreover, such networks enable more numerous internetwork
+   relationships where exchange of information may be conditioned on a
+   set of multilateral policies.  For example, shared SCNs are emerging
+   as a cost-effective way to address coverage of complex environments
+   such as sports stadiums, large office buildings, malls, etc.  Such
+   networks are likely to be a complex mix of different cellular and
+   WLAN access technologies (such as HSPA, LTE, and Wi-Fi) as well as
+   ownership models.  It is reasonable to assume that access to content
+   generated in such networks may depend on contextual information such
+   as the subscription type, timing, and location of both the owner and
+   requester of the content.  The availability of such contextual
+   information across diverse networks can lead to network
+   inefficiencies unless data management can benefit from an
+   information-centric approach.  The "Event with Large Crowds"
+   demonstrator created by the SAIL project investigated this kind of
+   scenario; more details are available in [SAIL-B3].
+
+   Jacobson et al. [CCN] include interactions between networks in their
+   overall system design and mention both "an edge-driven, bottom-up
+   incentive structure" and techniques based on evolutions of existing
+   mechanisms both for ICN router discovery by the end-user and for
+   interconnecting between Autonomous Systems (ASes).  For example, a
+   BGP extension for domain-level content prefix advertisement can be
+   used to enable efficient interconnection between ASes.  Liu et al.
+   [MLDHT] proposed to address the "suffix-hole" issue found in prefix-
+   based name aggregation through the use of a combination of Bloom-
+   filter-based aggregation and multi-level DHT.
+
+   Name aggregation has been discussed for a flat naming design, for
+   example, in [NCOA], in which the authors note that based on
+   estimations in [DONA] flat naming may not require aggregation.  This
+   is a point that calls for further study.  Scenarios evaluating name
+   aggregation, or lack thereof, should take into account the amount of
+   state (e.g., size of routing tables) maintained in edge routers as
+   well as network efficiency (e.g., amount of traffic generated).
+
+
+
+
+
+
+
+Pentikousis, et al.           Informational                    [Page 28]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+                 +---------------+
+     +---------->| Popular Video |
+     |           +---------------+
+     |             ^           ^
+     |             |           |
+     |           +-+-+ $0/MB +-+-+
+     |           | A +-------+ B |
+     |           ++--+       +-+-+
+     |            | ^         ^ |
+     |      $8/MB | |         | | $10/MB
+     |            v |         | v
+   +-+-+  $0/MB  +--+---------+--+
+   | D +---------+       C       |
+   +---+         +---------------+
+
+   Figure 5.  Relationships and Transit Costs between Networks A to D
+
+   DiBenedetto et al. [RP-NDN] study policy knobs made available by NDN
+   to network operators.  New policies that are not feasible in the
+   current Internet are described, including a "cache sharing peers"
+   policy, where two peers have an incentive to share content cached in,
+   but not originating from, their respective network.  The simple
+   example used in the investigation considers several networks and
+   associated transit costs, as shown in Figure 5 (based on Figure 1 of
+   [RP-NDN]).  Agyapong and Sirbu [EconICN] further establish that ICN
+   approaches should incorporate features that foster (new) business
+   relationships.  For example, publishers should be able to indicate
+   their willingness to partake in the caching market, proper reporting
+   should be enabled to avoid fraud, and content should be made
+   cacheable as much as possible to increase cache hit ratios.
+
+   Kutscher et al. [SAIL-B3] enable network interactions in the NetInf
+   architecture using a name resolution service at domain edge routers
+   and a BGP-like routing system in the NetInf Default-Free Zone.
+   Business models and incentives are studied in [SAIL-A7] and
+   [SAIL-A8], including scenarios where the access network provider (or
+   a virtual CDN) guarantees QoS to end users using ICN.  Figure 6
+   illustrates a typical scenario topology from this work that involves
+   an interconnectivity provider.
+
+
+
+
+
+
+
+
+
+
+
+
+Pentikousis, et al.           Informational                    [Page 29]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   +----------+     +-----------------+     +------+
+   | Content  |     | Access Network/ |     | End  |
+   | Provider +---->|  ICN Provider   +---->| User |
+   +----------+     +-+-------------+-+     +------+
+                      |             |
+                      |             |
+                      v             v
+   +-------------------+     +----------------+       +------+
+   | Interconnectivity |     | Access Network |       | End  |
+   |     Provider      +---->|     Provider   +------>| User |
+   +-------------------+     +----------------+       +------+
+
+   Figure 6.  Setup and Operating Costs of Network Entities
+
+   Jokela et al. [LIPSIN] propose a two-layer approach where additional
+   rendezvous systems and topology formation functions are placed
+   logically above multiple networks and enable advertising and routing
+   content between them.  Visala et al. [LANES] further describe an ICN
+   architecture based on similar principles, which, notably, relies on a
+   hierarchical DHT-based rendezvous interconnect.  Rajahalme et al.
+   [PSIRP1] describe a rendezvous system using both a BGP-like routing
+   protocol at the edge and a DHT-based overlay at the core.  Their
+   evaluation model is centered around policy-compliant path stretch,
+   latency introduced by overlay routing, caching efficacy, and load
+   distribution.
+
+   Rajahalme et al. [ICCP] point out that ICN architectural changes may
+   conflict with the current tier-based peering model.  For example,
+   changes leading to shorter paths between ISPs are likely to meet
+   resistance from Tier-1 ISPs.  Rajahalme [IDMcast] shows how
+   incentives can help shape the design of specific ICN aspects, and in
+   [IDArch] he presents a modeling approach to exploit these incentives.
+   This includes a network model that describes the relationship between
+   Autonomous Systems based on data inferred from the current Internet,
+   a traffic model taking into account business factors for each AS, and
+   a routing model integrating the valley-free model and policy
+   compliance.  A typical scenario topology is illustrated in Figure 7,
+   which is redrawn here based on Figure 1 of [ICCP].  Note that it
+   relates well with the topology illustrated in Figure 1 of this
+   document.
+
+
+
+
+
+
+
+
+
+
+
+Pentikousis, et al.           Informational                    [Page 30]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+                        o-----o
+                  +-----+  J  +-----+
+                  |     o--*--o     |
+                  |        *        |
+               o--+--o     *     o--+--o
+               |  H  +-----------+  I  |
+               o-*-*-o     *     o-*-*-o
+                 * *       *       * *
+            ****** ******* * ******* *******
+            *            * * *             *
+         o--*--o        o*-*-*o         o--*--o
+         |  E  +--------+  F  +---------+  G  +
+         o-*-*-o        o-----o         o-*-*-o
+           * *                            * *
+      ****** *******                 ****** ******
+      *            *                 *           *
+   o--*--o      o--*--o           o--*--o     o--*--o
+   |  A  |      |  B  +-----------+  C  |     |  D  |
+   o-----o      o--+--o           o--+--o     o----+o
+                   |                 |         ^^  | route
+             data  |            data |    data ||  | to
+                   |                 |         ||  | data
+               o---v--o          o---v--o     o++--v-o
+               | User |          | User |     | Data |
+               o------o          o------o     o------o
+
+   Legend:
+   *****  Transit link
+   +---+  Peering link
+   +--->  Data delivery or route to data
+
+   Figure 7.  Tier-Based Set of Interconnections between AS A to J
+
+   To sum up, the evaluation of ICN architectures across multiple
+   network types should include a combination of technical and economic
+   aspects, capturing their various interactions.  These scenarios aim
+   to illustrate scalability, efficiency, and manageability, as well as
+   traditional and novel network policies.  Moreover, scenarios in this
+   category should specifically address how different actors have proper
+   incentives, not only in a pure ICN realm, but also during the
+   migration phase towards this final state.
+
+3.2.  Energy Efficiency
+
+   ICN has prominent features that can be taken advantage of in order to
+   significantly reduce the energy footprint of future communication
+   networks.  Of course, one can argue that specific ICN network
+   elements may consume more energy than today's conventional network
+
+
+
+Pentikousis, et al.           Informational                    [Page 31]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   equipment due to the potentially higher energy demands for named-data
+   processing en route.  On balance, however, ICN introduces an
+   architectural approach that may compensate on the whole and can even
+   achieve higher energy efficiency rates when compared to the host-
+   centric paradigm.
+
+   We elaborate on the energy efficiency potential of ICN based on three
+   categories of ICN characteristics.  Namely, we point out that a) ICN
+   does not rely solely on end-to-end communication, b) ICN enables
+   ubiquitous caching, and c) ICN brings awareness of user requests (as
+   well as their corresponding responses) at the network layer thus
+   permitting network elements to better schedule their transmission
+   patterns.
+
+   First, ICN does not mandate perpetual end-to-end communication, which
+   introduces a whole range of energy consumption inefficiencies due to
+   the extensive signaling, especially in the case of mobile and
+   wirelessly connected devices.  This opens up new opportunities for
+   accommodating sporadically connected nodes and could be one of the
+   keys to an order-of-magnitude decrease in energy consumption compared
+   to the potential contributions of other technological advances.  For
+   example, web applications often need to maintain state at both ends
+   of a connection in order to verify that the authenticated peer is up
+   and running.  This introduces keep-alive timers and polling behavior
+   with a high toll on energy consumption.  Pentikousis [EEMN] discusses
+   several related scenarios and explains why the current host-centric
+   paradigm, which employs perpetual end-to-end connections, introduces
+   built-in energy inefficiencies, and argues that patches to make
+   currently deployed protocols energy-aware cannot provide for an
+   order-of-magnitude increase in energy efficiency.
+
+   Second, ICN network elements come with built-in caching capabilities,
+   which is often referred to as "ubiquitous caching".  Pushing data
+   objects to caches closer to end-user devices, for example, could
+   significantly reduce the amount of transit traffic in the core
+   network, thereby reducing the energy used for data transport.  Guan
+   et al. [EECCN] study the energy efficiency of a CCNx architecture
+   (based on their proposed energy model) and compare it with
+   conventional content dissemination systems such as CDNs and P2P.
+   Their model is based on the analysis of the topological structure and
+   the average hop length from all consumers to the nearest cache
+   location.  Their results show that an information-centric approach
+   can be more energy efficient in delivering popular and small-size
+   content.  In particular, they also note that different network-
+   element design choices (e.g., the optical bypass approach) can be
+   more energy efficient in delivering infrequently accessed content.
+
+
+
+
+
+Pentikousis, et al.           Informational                    [Page 32]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   Lee et al. [EECD] investigate the energy efficiency of various
+   network devices deployed in access, metro, and core networks for both
+   CDNs and ICN.  They use trace-based simulations to show that an ICN
+   approach can substantially improve the network energy efficiency for
+   content dissemination mainly due to the reduction in the number of
+   hops required to obtain a data object, which can be served by
+   intermediate nodes in ICN.  They also emphasize that the impact of
+   cache placement (in incremental deployment scenarios) and
+   local/cooperative content replacement strategies needs to be
+   carefully investigated in order to better quantify the energy
+   efficiencies arising from adopting an ICN paradigm.
+
+   Third, ICN elements are aware of the user request and its
+   corresponding data response; due to the nature of name-based routing,
+   they can employ power consumption optimization processes for
+   determining their transmission schedule or powering down inactive
+   network interfaces.  For example, network coding [NCICN] or adaptive
+   video streaming [COAST] can be used in individual ICN elements so
+   that redundant transmissions, possibly passing through intermediary
+   networks, could be significantly reduced, thereby saving energy by
+   avoiding carrying redundant traffic.
+
+   Alternatively, approaches that aim to simplify routers, such as
+   [PURSUIT], could also reduce energy consumption by pushing routing
+   decisions to a more energy-efficient entity.  Along these lines, Ko
+   et al. [ICNDC] design a data center network architecture based on ICN
+   principles and decouple the router control-plane and data-plane
+   functionalities.  Thus, data forwarding is performed by simplified
+   network entities, while the complicated routing computation is
+   carried out in more energy-efficient data centers.
+
+   To summarize, energy efficiency has been discussed in ICN evaluation
+   studies, but most published work is preliminary in nature.  Thus, we
+   suggest that more work is needed in this front.  Evaluating energy
+   efficiency does not require the definition of new scenarios or
+   baseline topologies, but does require the establishment of clear
+   guidelines so that different ICN approaches can be compared not only
+   in terms of scalability, for example, but also in terms of power
+   consumption.
+
+3.3.  Operation across Multiple Network Paradigms
+
+   Today the overwhelming majority of networks are integrated with the
+   well-connected Internet with IP at the "waist" of the technology
+   hourglass.  However, there is a large amount of ongoing research into
+   alternative paradigms that can cope with conditions other than the
+   standard set assumed by the Internet.  Perhaps the most advanced of
+   these is Delay- and Disruption-Tolerant Networking (DTN).  DTN is
+
+
+
+Pentikousis, et al.           Informational                    [Page 33]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   considered as one of the scenarios for the deployment in Section 2.7,
+   but here we consider how ICN can operate in an integrated network
+   that has essentially disjoint "domains" (a highly overloaded term!)
+   or regions that use different network paradigms and technologies, but
+   with gateways that allow interoperation.
+
+   ICN operates in terms of named data objects so that requests and
+   deliveries of information objects can be independent of the
+   networking paradigm.  Some researchers have contemplated some form of
+   ICN becoming the new waist of the hourglass as the basis of a future
+   reincarnation of the Internet, e.g., [ArgICN], but there are a large
+   number of problems to resolve, including authorization, access
+   control, and transactional operation for applications such as
+   banking, before some form of ICN can be considered as ready to take
+   over from IP as the dominant networking technology.  In the meantime,
+   ICN architectures will operate in conjunction with existing network
+   technologies as an overlay or in cooperation with the lower layers of
+   the "native" technology.
+
+   It seems likely that as the reach of the "Internet" is extended,
+   other technologies such as DTN will be needed to handle scenarios
+   such as space communications where inherent delays are too large for
+   TCP/IP to cope with effectively.  Thus, demonstrating that ICN
+   architectures can work effectively in and across the boundaries of
+   different networking technologies will be important.
+
+   The NetInf architecture, in particular, targets the inter-domain
+   scenario by the use of a convergence-layer architecture [SAIL-B3],
+   and Publish-Subscribe Internet Routing Paradigm (PSIRP) and/or
+   Publish-Subscribe Internet Technology (PURSUIT) is envisaged as a
+   candidate for an IP replacement.
+
+   The key items for evaluation over and above the satisfactory
+   operation of the architecture in each constituent domain will be to
+   ensure that requests and responses can be carried across the network
+   boundaries with adequate performance and do not cause malfunctions in
+   applications or infrastructure because of the differing
+   characteristics of the gatewayed domains.
+
+4.  Summary
+
+   This document presents a wide range of different application areas in
+   which the use of information-centric network designs have been
+   evaluated in the peer-reviewed literature.  Evidently, this broad
+   range of scenarios illustrates the capability of ICN to potentially
+   address today's problems in an alternative and better way than host-
+   centric approaches as well as to point to future scenarios where ICN
+   may be applicable.  We believe that by putting different ICN systems
+
+
+
+Pentikousis, et al.           Informational                    [Page 34]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   to the test in diverse application areas, the community will be
+   better equipped to judge the potential of a given ICN proposal and
+   therefore subsequently invest more effort in developing it further.
+   It is worth noting that this document collected different kinds of
+   considerations, as a result of our ongoing survey of the literature
+   and the discussion within ICNRG, which we believe would have
+   otherwise remained unnoticed in the wider community.  As a result, we
+   expect that this document can assist in fostering the applicability
+   and future deployment of ICN over a broader set of operations, as
+   well as possibly influencing and enhancing the base ICN proposals
+   that are currently available and possibly assist in defining new
+   scenarios where ICN would be applicable.
+
+   We conclude this document with a brief summary of the evaluation
+   aspects we have seen across a range of scenarios.
+
+   The scalability of different mechanisms in an ICN architecture stands
+   out as an important concern (cf. Sections 2.1, 2.2, 2.5, 2.6, 2.8,
+   2.9, and 3.1) as does network, resource, and energy efficiency (cf.
+   Sections 2.1, 2.3, 2.4, 3.1, and 3.2).  Operational aspects such as
+   network planing, manageability, reduced complexity and overhead (cf.
+   Sections 2.2, 2.3, 2.4, 2.8, and 3.1) should not be neglected
+   especially as ICN architectures are evaluated with respect to their
+   potential for deployment in the real world.  Accordingly, further
+   research in economic aspects as well as in the communication,
+   computation, and storage tradeoffs entailed in each ICN architecture
+   is needed.
+
+   With respect to purely technical requirements, support for multicast,
+   mobility, and caching lie at the core of many scenarios (cf. Sections
+   2.1, 2.3, 2.5, and 2.6).  ICN must also be able to cope when the
+   Internet expands to incorporate additional network paradigms (cf.
+   Section 3.3).  We have also seen that being able to address stringent
+   QoS requirements and increase reliability and resilience should also
+   be evaluated following well-established methods (cf. Sections 2.2,
+   2.8, and 2.9).
+
+   Finally, we note that new applications that significantly improve the
+   end-user experience and forge a migration path from today's host-
+   centric paradigm could be the key to a sustained and increasing
+   deployment of the ICN paradigm in the real world (cf. Sections 2.2,
+   2.3, 2.6, 2.8, and 2.9).
+
+5.  Security Considerations
+
+   This document does not impact the security of the Internet.
+
+
+
+
+
+Pentikousis, et al.           Informational                    [Page 35]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+6.  Informative References
+
+   [RFC5743]  Falk, A., "Definition of an Internet Research Task Force
+              (IRTF) Document Stream", RFC 5743, December 2009,
+              <http://www.rfc-editor.org/info/rfc5743>.
+
+   [RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
+              Specification", RFC 5050, November 2007,
+              <http://www.rfc-editor.org/info/rfc5050>.
+
+   [RFC4838]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
+              R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
+              Networking Architecture", RFC 4838, April 2007,
+              <http://www.rfc-editor.org/info/rfc4838>.
+
+   [RFC5568]  Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568,
+              July 2009, <http://www.rfc-editor.org/info/rfc5568>.
+
+   [RFC6920]  Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
+              Keranen, A., and P. Hallam-Baker, "Naming Things with
+              Hashes", RFC 6920, April 2013,
+              <http://www.rfc-editor.org/info/rfc6920>.
+
+   [NetInf]   Ahlgren, B. et al., "Design considerations for a network
+              of information", Proc. CoNEXT Re-Arch Workshop, ACM, 2008.
+
+   [CCN]      Jacobson, V., et al., "Networking Named Content", Proc.
+              CoNEXT, ACM, 2009.
+
+   [CCNx]     Mosko, M.,  Solis, I., and E. Uzun, "CCN 1.0 Protocol
+              Architecture", Project CCNx documentation, Xerox Palo Alto
+              Research Center, 2013,
+              <http://ccnx.org/pubs/ICN_CCN_Protocols.pdf>.
+
+   [NDNP]     Zhang, L., et al., "Named Data Networking (NDN) Project",
+              NDN Technical Report NDN-0001, Oct. 2010,
+              <http://named-data.net/publications/techreports/>.
+
+   [PSI]      Trossen, D. and G. Parisis, "Designing and realizing an
+              information-centric internet", IEEE Commun. Mag., vol. 50,
+              no. 7, July 2012.
+
+   [DONA]     Koponen, T., et al., "A Data-Oriented (and Beyond) Network
+              Architecture", Proc. SIGCOMM, ACM, 2007.
+
+   [SoA1]     Ahlgren, B., et al., "A survey of information-centric
+              networking", IEEE Commun. Mag., vol. 50, no. 7, July 2012.
+
+
+
+
+Pentikousis, et al.           Informational                    [Page 36]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   [SoA2]     Xylomenos, G., et al. "A survey of information-centric
+              networking research", IEEE Communications Surveys and
+              Tutorials (2013): 1-26.
+
+   [ICN-SN]   Mathieu, B., et al., "Information-centric networking: a
+              natural design for social network applications", IEEE
+              Commun. Mag., vol. 50, no. 7, July 2012.
+
+   [VPC]      Kim, J., et al., "Content Centric Network-based Virtual
+              Private Community", Proc. ICCE, IEEE, 2011.
+
+   [CBIS]     Jacobson, V., et al., "Custodian-Based Information
+              Sharing", IEEE Commun. Mag., vol. 50, no. 7, July 2012.
+
+   [VPC2]     Kim, D. and J. Lee, "CCN-based virtual private community
+              for extended home media service", IEEE Trans. Consumer
+              Electronics, vol. 57, no. 2, May 2011.
+
+   [CCR]      Arianfar, S., et al., "On content-centric router design
+              and implications", Proc. CoNEXT Re-Arch Workshop, ACM,
+              2010.
+
+   [VoCCN]    Jacobson, V., et al., "VoCCN: Voice-over Content-Centric
+              Networks", Proc. CoNEXT Re-Arch Workshop, ACM, 2009.
+
+   [NDNpb]    Xuan, Y. and Z. Yan, "Enhancing Routing Efficiency in
+              Named Data Network with Piggybacked Interest", Proc. CFI,
+              ACM, 2013.
+
+   [ACT]      Zhu, Z., et al., "ACT: Audio Conference Tool Over Named
+              Data Networking", Proc. SIGCOMM ICN Workshop, ACM, 2011.
+
+   [G-COPSS]  Chen, J., et al., "G-COPSS: A Content Centric
+              Communication Infrastructure for Gaming Applications",
+              Proc. ICDCS, IEEE, 2012.
+
+   [MMIN]     Pentikousis, K., and P. Bertin., "Mobility Management in
+              Infrastructure Networks", IEEE Internet Computing 17, no.
+              5 (2013): 74-79.
+
+   [SCES]     Allman, M., et al., "Enabling an Energy-Efficient Future
+              Internet through Selectively Connected End Systems", Proc.
+              HotNets-VI, ACM, 2007.
+
+   [EEMN]     Pentikousis, K., "In Search of Energy-Efficient Mobile
+              Networking", IEEE Commun. Mag., vol. 48, no. 1, Jan. 2010.
+
+
+
+
+
+Pentikousis, et al.           Informational                    [Page 37]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   [MOBSURV]  Tyson, G., et al., "A Survey of Mobility in Information-
+              Centric Networks: Challenges and Research Directions",
+              Proc. MobiHoc Workshop on Emerging Name-Oriented Mobile
+              Networking Design, ACM, 2012.
+
+   [N-Scen]   Dannewitz, C., et al., "Scenarios and research issues for
+              a Network of Information", Proc. MobiMedia, ICST, 2012.
+
+   [DTI]      Ott, J. and D. Kutscher, "Drive-thru Internet: IEEE
+              802.11b for 'automobile' users", Proc. INFOCOM, IEEE,
+              2004.
+
+   [PSIMob]   Xylomenos, G., et al., "Caching and Mobility Support in a
+              Publish-Subscribe Internet Architecture", IEEE Commun.
+              Mag., vol. 50, no. 7, July 2012.
+
+   [mNetInf]  Pentikousis, K. and T. Rautio, "A Multiaccess Network of
+              Information", Proc. WoWMoM, IEEE, 2010.
+
+   [HybICN]   Lindgren, A., "Efficient content distribution in an
+              information-centric hybrid mobile networks", Proc. CCNC,
+              IEEE, 2011.
+
+   [E-CHANET] M. Amadeo, et al., "E-CHANET: Routing, Forwarding and
+              Transport in Information-Centric Multihop Wireless
+              Networks", Computer Communications, Elsevier, Jan. 2013
+              online.
+
+   [MobiA]    Meisel, M., et al., "Ad Hoc Networking via Named Data",
+              Proc. MobiArch, ACM 2010.
+
+   [CCNMANET] Oh, S. Y., et al., "Content Centric Networking in Tactical
+              and Emergency MANETs", Proc. Wireless Days, IFIP, 2010.
+
+   [RTIND]    Wang, L., et al., "Rapid Traffic Information Dissemination
+              Using Named Data", Proc. MobiHoc NoM workshop, ACM, 2012.
+
+   [CCNVANET] Amadeo, M., et al., "Content-Centric Networking: is that a
+              Solution for Upcoming Vehicular Networks?", Proc. VANET,
+              ACM, 2012.
+
+   [ABC]      Gustafsson, E., and A. Jonsson. "Always best connected",
+              Wireless Communications, IEEE 10.1 (2003): 49-55.
+
+   [SHARE]    Muscariello, L., et al., "Bandwidth and storage sharing
+              performance in information centric networking", Proc.
+              SIGCOMM ICN Workshop, ACM, 2011.
+
+
+
+
+Pentikousis, et al.           Informational                    [Page 38]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   [CL4M]     Chai, W. K., et al., "Cache 'Less for More' in
+              Information-centric Networks", Proc. Networking, IFIP,
+              2012.
+
+   [CCNCT]    Psaras, I., et al., "Modelling and Evaluation of CCN-
+              Caching Trees", In Proc. of the 10th international IFIP
+              conference on Networking, Valencia, Spain, May 2011.
+
+   [BTCACHE]  Tyson, G., et al., "A Trace-Driven Analysis of Caching in
+              Content-Centric Networks", Proc. ICCCN, IEEE, 2012.
+
+   [CURLING]  Chai, W. K., et al., "CURLING: Content-Ubiquitous
+              Resolution and Delivery Infrastructure for Next-Generation
+              Services", IEEE Commun. Mag., vol. 49, no. 3, Mar. 2011.
+
+   [ACDICN]   Fotiou, N., et al., "Access control enforcement delegation
+              for information-centric networking architectures", Proc.
+              SIGCOMM ICN Workshop, ACM, 2012.
+
+   [EWC]      Bai, F. and B. Krishnamachari, "Exploiting the wisdom of
+              the crowd: localized, distributed information-centric
+              VANETs", IEEE Commun. Mag., vol. 48, no. 5, May 2010.
+
+   [DMND]     Wang, J., R. Wakikawa, and L. Zhang, "DMND: Collecting
+              data from mobiles using Named Data", Proc. Vehicular
+              Networking Conference (VNC), IEEE, 2010.
+
+   [DNV2V]    Wang, L., et al., "Data Naming in Vehicle-to-Vehicle
+              Communications", Proc. INFOCOM NOMEN workshop, IEEE, 2012.
+
+   [CCNHV]    Arnould, G., et al., "A Self-Organizing Content Centric
+              Network Model for Hybrid Vehicular Ad-Hoc Networks". Proc.
+              DIVANet, ACM, 2011.
+
+   [CCDIVN]   TalebiFard, P. and V.C.M. Leung, "A Content Centric
+              Approach to Dissemination of Information in Vehicular
+              Networks", Proc. DIVANet, ACM, 2012.
+
+   [CRoWN]    Amadeo, M., et al., "CRoWN: Content-Centric Networking in
+              Vehicular Ad Hoc Networks", IEEE Communications Letters,
+              vol. 16, no. 9, Sept. 2012.
+
+   [SCN]      Hoydis, J., et al., "Green small-cell networks", IEEE
+              Vehicular Technology Magazine, vol. 6, no.1, pp. 37-43,
+              March 2011.
+
+
+
+
+
+
+Pentikousis, et al.           Informational                    [Page 39]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   [HetNet]   Li, H., et al. "Efficient HetNet implementation using
+              broadband wireless access with fiber-connected massively
+              distributed antennas architecture", IEEE Wireless
+              Communications, vol. 18, no.3, pp. 72-78, June 2011.
+
+   [ArgICN]   Trossen, D., et al., "Arguments for an information centric
+              internetworking architecture", ACM SIGCOMM CCR, 40:26-33,
+              Apr. 2010.
+
+   [EconICN]  Agyapong, P. and M. Sirbu, "Economic Incentives in
+              Information Centric Networking: Implications for Protocol
+              Design and Public Policy", IEEE Commun. Mag., vol. 50, no.
+              12, Dec. 2012.
+
+   [SAIL-B3]  Kutscher, D., Ed., et al., "Final NetInf Architecture",
+              SAIL Project Deliverable D-B.3, Jan. 2013,
+              <http://www.sail-project.eu/deliverables/>.
+
+   [MLDHT]    Liu, H., et al., "A multi-level DHT routing framework with
+              aggregation", Proc. SIGCOMM ICN Workshop, ACM, 2012.
+
+   [NCOA]     Ghodsi, A., et al., "Naming in Content-oriented
+              Architectures", Proc. SIGCOMM ICN Workshop, ACM, 2011.
+
+   [RP-NDN]   DiBenedetto, S., et al., "Routing policies in named data
+              networking", Proc. SIGCOMM ICN Workshop, ACM, 2011.
+
+   [SAIL-A7]  Salo, J., Ed., et al., "New business models and business
+              dynamics of the future networks", SAIL Project Deliverable
+              D-A.7, Aug. 2011,
+              <http://www.sail-project.eu/deliverables/>.
+
+   [SAIL-A8]  Zhang, N., Ed., et al., "Evaluation of business models",
+              SAIL Project Deliverable D-A.8, Jan. 2013,
+              <http://www.sail-project.eu/deliverables/>.
+
+   [LIPSIN]   Jokela, P., et al., "LIPSIN: line speed publish/subscribe
+              inter-networking", Proc. of ACM SIGCOMM 2009.
+
+   [LANES]    Visala, K., et al., "LANES: An Inter-Domain Data-Oriented
+              Routing Architecture", Proc. CoNEXT Re-Arch Workshop, ACM,
+              2009.
+
+   [PSIRP1]   Rajahalme, J., et al., "Inter-Domain Rendezvous Service
+              Architecture", PSIRP Technical Report TR09-003, Dec. 2009.
+
+
+
+
+
+
+Pentikousis, et al.           Informational                    [Page 40]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   [ICCP]     Rajahalme J., et al., "Incentive-Compatible Caching and
+              Peering in Data-Oriented Networks", Proc. CoNEXT Re-Arch
+              Workshop, ACM, 2008.
+
+   [IDMcast]  Rajahalme, J., "Incentive-informed Inter-domain
+              Multicast", Proc. Global Internet Symposium 2010.
+
+   [IDArch]   Rajahalme, J., "Inter-domain incentives and Internet
+              architecture", PhD. Dissertation, Aalto University, Aug.
+              2012.
+
+   [PURSUIT]  Fotiou, N., et al., "Developing Information Networking
+              Further: From PSIRP to PURSUIT", Proc. BROADNETS, ICST,
+              2010.
+
+   [EECCN]    Guan, K., et al., "On the Energy Efficiency of Content
+              Delivery Architectures", Proc. ICC Workshops, IEEE, 2011.
+
+   [EECD]     Lee, U., Rimac, I., Kilper, D., and V. Hilt, "Toward
+              energy-efficient content dissemination", IEEE Network,
+              vol. 25, no. 2, March-April 2011.
+
+   [NCICN]    Montpetit, M. J., Westphal, C., and D. Trossen, "Network
+              coding meets information-centric networking: an
+              architectural case for information dispersion through
+              native network coding", Proc. MOBIHOC NoM Workshop, ACM,
+              2012.
+
+   [COAST]    Gruneberg, K., et al., "File format specification and 3D
+              video codec", COAST Project Deliverable D5.1, July 2011,
+              <http://www.coast-fp7.eu/deliverables.html>.
+
+   [ICNDC]    Ko, B. J., Pappas, V., Raghavendra, R., Song, Y.,
+              Dilmaghani, R. B., Lee, K.-w., and D. Verma, "An
+              information-centric architecture for data center
+              networks", Proc. SIGCOMM ICN Workshop, ACM, 2012.
+
+   [DTN]      Fall, K., "A delay-tolerant network architecture for
+              challenged internets", Proc. SIGCOMM, ACM, 2003.
+
+   [DTNICN]   Tyson, G., Bigham, J., and E. Bodanese, "Towards an
+              Information-Centric Delay-Tolerant Network", Proc. IEEE
+              INFOCOM NOMEN 2013, Turin, Italy.
+
+   [BPQ]      Farrell, S., Lynch, A., Kutscher, D., and A. Lindgren,
+              "Bundle Protocol Query Extension Block", Work in Progress,
+              draft-irtf-dtnrg-bpq-00, May 2012.
+
+
+
+
+Pentikousis, et al.           Informational                    [Page 41]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   [SLINKY]   Kawadia, V., Riga, N., Opper, J., and D. Sampath, "Slinky:
+              An adaptive protocol for content access in disruption-
+              tolerant ad hoc networks", in Proc. MobiHoc Workshop on
+              Tactical Mobile Ad Hoc Networking, 2011.
+
+   [ONE]      "The Opportunistic Network Environment simulator",
+              <http://www.netlab.tkk.fi/tutkimus/dtn/theone>.
+
+   [TWIMIGHT] Hossmann, T., et al. "Twitter in disaster mode: smart
+              probing for opportunistic peers", Proc. 3rd ACM
+              International Workshop on Mobile Opportunistic Networks,
+              ACM, 2012.
+
+   [MODEL1]   Uddin, M.Y.S., Nicol, D.M., Abdelzaher, T.F., and R.H.
+              Kravets, "A post-disaster mobility model for Delay
+              Tolerant Networking", Simulation Conference (WSC),
+              Proceedings of the 2009 Winter, pp. 2785-2796, 13-16 Dec.
+              2009.
+
+   [MODEL2]   Aschenbruck, N., Gerhards-Padilla, E., and P. Martini,
+              "Modeling mobility in disaster area scenarios",
+              Performance Evaluation 66, no. 12 (2009): 773-790.
+
+   [MODEL3]   Cabrero, S., Paneda, X.G., Plagemann, T., Melendi, D., and
+              R. Garcia, "An Overlay Routing Protocol for Video over
+              sparse MANETs in Emergencies", Cadernos de Informatica 6,
+              no. 1 (2011): 195-202.
+
+   [IoTEx]    Burke, J., "Authoring Place-based Experiences with an
+              Internet of Things: Tussles of Expressive, Operational,
+              and Participatory Goals", Position Paper, Interconnecting
+              Smart Objects with the Internet Workshop, IAB, 2011.
+
+   [IWMT]     Kutscher, D. and S. Farrell, "Towards an Information-
+              Centric Internet with more Things", Position Paper,
+              Interconnecting Smart Objects with the Internet Workshop,
+              IAB, 2011.
+
+   [nWSN]     Heidemann, J., et al., "Building efficient wireless sensor
+              networks with low-level naming", Proc. SOSP, ACM, 2001.
+
+   [NDNl]     Burke, J., et al., "Authenticated Lighting Control Using
+              Named Data Networking", NDN Technical Report NDN-0011,
+              Oct. 2012.
+
+   [CIBUS]    Biswas, T., et al., "Contextualized Information-Centric
+              Home Network", Proc. ACM SIGCOMM, ACM, 2013.
+
+
+
+
+Pentikousis, et al.           Informational                    [Page 42]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   [Homenet]  Ravindran, R., et al., "Information-centric Networking
+              based Homenet", Proc. International Workshop on Management
+              of the Future Internet (ManFI), IFIP/IEEE, 2013.
+
+   [IoTScope] Marias, G.F., et al., "Efficient information lookup for
+              the Internet of Things", Proc. WoWMoM, IEEE, 2012.
+
+   [ICN-DHT]  Katsaros, K., et al., "On inter-domain name resolution for
+              information-centric networks", Proc. Networking, Springer,
+              2012.
+
+   [SEMANT]   Sheth, A., et al., "Semantic Sensor Web," Internet
+              Computing, IEEE , vol. 12, no. 4, pp.78-83, July-Aug. 2008
+
+   [CPG]      Cianci, I., et al., "Content Centric Services in Smart
+              Cities", Proc. NGMAST, IEEE, 2012.
+
+   [MVM]      Hernndez-Munoz, J.M., et al., "Smart cities at the
+              forefront of the future Internet", The Future Internet,
+              Springer, 2011.
+
+   [iHEMS]    Zhang, J., et al., "iHEMS: An Information-Centric Approach
+              to Secure Home Energy Management", Proc. SmartGridComm,
+              IEEE, 2012.
+
+   [ACC]      Andreini, F., et al., "A scalable architecture for geo-
+              localized service access in smart cities", Proc. Future
+              Network and Mobile Summit, IEEE, 2011.
+
+   [IB]       Idowu, S. and N. Bari, "A Development Framework for Smart
+              City Services, Integrating Smart City Service Components",
+              Master's Thesis, Lulea University of Technology, 2012.
+
+   [ISODIS]   ISO/DIS, "Sustainable development and resilience of
+              communities --Indicators for city services and quality of
+              life", ISO/DIS 37120, 2013.
+
+   [EVAL-METHOD]
+              Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S.,
+              Boggia, G., and P. Mahadevan, "Information-centric
+              Networking: Evaluation Methodology", Work in Progress,
+              draft-irtf-icnrg-evaluation-methodology-00, July 2014.
+
+   [CHALLENGES]
+              Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
+              Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
+              "ICN Research Challenges", Work in Progress, draft-irtf-
+              icnrg-challenges-01, February 2015.
+
+
+
+Pentikousis, et al.           Informational                    [Page 43]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+Acknowledgments
+
+   Dorothy Gellert contributed to an earlier draft version of this
+   document.
+
+   This document has benefited from reviews, pointers to the growing ICN
+   literature, suggestions, comments, and proposed text provided by the
+   following members of the IRTF Information-Centric Networking Research
+   Group (ICNRG), listed in alphabetical order: Marica Amadeo, Hitoshi
+   Asaeda, Claudia Campolo, Luigi Alfredo Grieco, Myeong-Wuk Jang, Ren
+   Jing, Will Liu, Hongbin Luo, Priya Mahadevan, Ioannis Psaras, Spiros
+   Spirou, Dirk Trossen, Jianping Wang, Yuanzhe Xuan, and Xinwen Zhang.
+
+   The authors would like to thank Mark Stapp, Juan Carlos Zuniga, and
+   G.Q. Wang for their comments and suggestions as part of their open
+   and independent review of this document within ICNRG.
+
+Authors' Addresses
+
+   Kostas Pentikousis (editor)
+   EICT GmbH
+   Torgauer Strasse 12-15
+   10829 Berlin
+   Germany
+
+   EMail: k.pentikousis@eict.de
+
+
+   Borje Ohlman
+   Ericsson Research
+   S-16480 Stockholm
+   Sweden
+
+   EMail: Borje.Ohlman@ericsson.com
+
+
+   Daniel Corujo
+   Instituto de Telecomunicacoes
+   Campus Universitario de Santiago
+   P-3810-193 Aveiro
+   Portugal
+
+   EMail: dcorujo@av.it.pt
+
+
+
+
+
+
+
+
+Pentikousis, et al.           Informational                    [Page 44]
+
+RFC 7476                 ICN Baseline Scenarios               March 2015
+
+
+   Gennaro Boggia
+   Dep. of Electrical and Information Engineering
+   Politecnico di Bari
+   Via Orabona 4
+   70125 Bari
+   Italy
+
+   EMail: g.boggia@poliba.it
+
+
+   Gareth Tyson
+   School and Electronic Engineering and Computer Science
+   Queen Mary, University of London
+   United Kingdom
+
+   EMail: gareth.tyson@eecs.qmul.ac.uk
+
+
+   Elwyn Davies
+   Trinity College Dublin/Folly Consulting Ltd
+   Dublin, 2
+   Ireland
+
+   EMail: davieseb@scss.tcd.ie
+
+
+   Antonella Molinaro
+   Dep. of Information, Infrastructures, and Sustainable
+   Energy Engineering
+   Universita' Mediterranea di Reggio Calabria
+   Via Graziella 1
+   89100 Reggio Calabria
+   Italy
+
+   EMail: antonella.molinaro@unirc.it
+
+
+   Suyong Eum
+   National Institute of Information and Communications Technology
+   4-2-1, Nukui Kitamachi, Koganei
+   Tokyo  184-8795
+   Japan
+
+   Phone: +81-42-327-6582
+   EMail: suyong@nict.go.jp
+
+
+
+
+
+
+Pentikousis, et al.           Informational                    [Page 45]
+