RFC 7476
Information-Centric Networking: Baseline Scenarios
RFC 7476: Information-Centric Networking: Baseline Scenarios 🦋
okay bestie, let's start with the vibes. this is an Informational RFC from the IRTF (not an IETF standard!!), published by the Information-Centric Networking Research Group (ICNRG) in March 2015 🌸. the editor is K. Pentikousis (EICT), and the co-authors are B. Ohlman (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), and S. Eum (NICT). its ISSN is 2070-1721. the header doesn't list anything it obsoletes or updates, so it's a clean slate 💅
Abstract
this doc is all about getting everyone on the same page about a set of scenarios that can be used as a base for evaluating different information-centric networking (ICN) approaches ✨. the goal is that they can be tested and compared against each other while each one still gets to showcase its own strengths 💖. to do this, the authors went through the ICN literature and wrote down scenarios that earlier performance evaluation studies had already considered 📚.
they talk about a bunch of aspects an ICN solution can address. the general ones are 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 🔥. then they get into the ICN-specific stuff too, like information security and trust, persistence, availability, provenance, and location independence 🧚.
this document is a product of the IRTF Information-Centric Networking Research Group (ICNRG) 🌈.
Status of This Memo
okay this part is the legal-ish bit, but it's important, so here we go 🎀. this document is not an Internet Standards Track specification. it's just published for informational purposes 💜.
it's a product of the Internet Research Task Force (IRTF), which publishes results of Internet-related research and development activities. these results might not be suitable for deployment, so don't just yolo them into production 💀. this RFC represents the consensus of the Information-Centric Networking Research Group of the IRTF. documents approved for publication by the IRSG are not a candidate for any level of Internet Standard, and you can read more about that in Section 2 of RFC 5741 🦋.
if you want the current status of this doc, any errata, or to send feedback, check 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) as they were in effect on the date of publication. please actually read these, bestie, because they describe your rights and restrictions with respect to this document 🙈.
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 ................................................441. Introduction ✨
okay so ICN is a seriously fundamental shift in how networking works 🔥. the host-centric paradigm has been omnipresent and super successful, and it's built on perpetual connectivity and the end-to-end principle 💅. ICN flips the focal point of the network architecture from the end host to "named information" (or content, or data) 🌸. in this world, connectivity may well be intermittent 🙈. end-host and in-network storage can be used transparently, because 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 🦋. main character energy, honestly 👑.
the security paradigm changes too, and this is so iconic 😭. 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, any source (cache) should be equally usable 🧚. that means there needs to be some mechanism that makes each information item trustworthy by itself. the document says this can be achieved, for example, by name-data integrity or by signing data objects 🔐.
ICN is growing fast, but the work on different architectures is still far from finished 🚧. the list includes 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] 🌈. honestly, ICN today is kinda like packet-switched networking in the late 1970s, when technologies like DECnet, Internetwork Packet Exchange (IPX), and IP were being actively developed and tested at the same time 🍓. that's why it's such an active and growing research area ✨. the downside is that it's harder to compare proposals on an equal footing 😭. this document tries to help 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 of this document appeared in November 2012 🌸. it was adopted by ICNRG at IETF 87 (July 2013) as the document for the work item on defining "reference baseline scenarios to enable performance comparisons between different approaches" 🎀. earlier drafts were presented at the ICNRG meetings at IETF 85, IETF 86, IETF 87, IETF 88, and IETF 89, plus the ICNRG interim meeting in Stockholm in February 2013 🧚. it was reviewed, commented on, and discussed extensively for nearly two years by the vast majority of ICNRG members, which is definitely more than 100 individuals 🫶. the consensus of ICNRG is that the baseline scenarios in this document should be published in the IRTF Stream of the RFC series ✨. and to be super clear: this document does not constitute a standard 💅.
1.1. Baseline Scenario Selection
okay, the vibe check here is that earlier surveys [SoA1] [SoA2] note that describing ICN architectures is like shooting a moving target 🎯. comparing these approaches is even trickier 😭. researchers keep making up different performance evaluation scenarios, usually for good reasons, to highlight the advantages of their own approach 💅. that's expected to some degree at this early stage of ICN development 🌸. still, this document shows that certain baseline scenarios seem to emerge, where 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 📚. these form the foundation for the baseline scenarios that the IRTF Information-Centric Networking Research Group (ICNRG) will consider in its future work 🦋. there are two goals here. the first is to provide a set of use cases and applications that highlight opportunities for testing different ICN proposals 🧚. the second is to identify the key attributes of a common set of techniques that can be useful for evaluating ICN 💖. these scenarios are also meant to give researchers enough configuration data to evaluate their ICN proposals in a variety of settings 🔥. that goes beyond scenarios that just focus on traditional content delivery, which is the big point 🙌. the overall aim is that each scenario is described in enough detail, 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 in this document is available from http://telematics.poliba.it/icn-baseline-scenarios 🍓.
1.2. Document Goals and Outline
this document pulls in input from ICNRG participants and their text contributions 🫶. several ICNRG active participants reviewed it (see Section 7), and it represents the consensus of the research group ✨. but again, it is not an IETF standard. it's an Informational document, see also [RFC5743] 💜. as mentioned above, these scenarios are meant to provide a framework for evaluating different ICN approaches 🌈. the methodology for doing these evaluations, plus the definitions of the metrics that should be used, are described in a separate document [EVAL-METHOD] 📚. if you're curious, interested readers should also check out [CHALLENGES] 🧚.
the rest of the document has a bunch of scenarios grouped into categories in Section 2, followed by cross-scenario considerations in Section 3 🌸. just a heads up: some evaluation scenarios span across these categories, so the boundaries between them should not be treated as rigid and inflexible 🦋. Section 4 summarizes the main evaluation aspects across the range of scenarios in this document 💅.
2. Scenarios 🎀
Okay bestie, this section covers nine scenario categories, all based on use cases and evaluations that have shown up in the peer-reviewed literature. 📚✨
2.1. Social Networking 💬
Social-networking apps have been everywhere for the past decade, and they're built on overlay content dissemination systems that need big infrastructure investments to roll out and maintain. 💸 Content dissemination is literally the heart of the ICN paradigm, so social networking is giving "natural fit" energy for comparing ICN performance with traditional client-server TCP/IP-based systems. 🦋 Mathieu et al. [ICN-SN], for instance, show how an Internet Service Provider (ISP) can use CCN to deploy a Twitter-like short-message service 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. So a single user addresses a large number of recipients: some get the new message right away because they're online at that exact moment, while others get it whenever they connect to the network. 📱
Along similar lines, Kim et al. [VPC] present an ICN-based social-networking platform where a user shares content with her/his family and friends without needing 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] then present a proof-of-concept evaluation where users with ordinary smartphones can browse a list of members or content using a name, and download the content they pick from the list. 📲
In other words, the evaluation studies above suggest 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] looks at a similar pull-based content retrieval scenario, but with a different architecture, and points to significant performance advantages. 🚀 The authors consider a network topology (redrawn in Figure 1 for convenience) with some really interesting characteristics, but they don't explicitly address social networking in their evaluation scenario. Still, the similarities are easy to spot: "followers" (like 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 cover a whole array of services, from one-to-one voice calls to multiparty multimedia conferences with features ranging from whiteboards to augmented reality. 🎥 Real-time communications have been studied and deployed over packet- and circuit-switched networks for decades, and the stringent Quality of Service (QoS) requirements this type of communication puts on network infrastructure are well known. 😤 One could argue that network primitives that are excellent for information dissemination aren't necessarily well-suited for conversational services, so ICN evaluation studies should consider real-time communication scenarios in detail. 🧐
Notably, Jacobson et al. [VoCCN] presented an early evaluation comparing the performance of a VoIP (Voice over IP) call using an information-centric approach with an off-the-shelf VoIP implementation using RTP/UDP. 📊 The results showed that, despite the extra cost of adding security support in the ICN approach, performance was virtually identical in the two cases evaluated in their testbed. The catch? The experimental setup is pretty rudimentary, and the evaluation only considered a single voice call. 🙈 Xuan and Yan [NDNpb] revisit the same scenario but are mainly interested in reducing the overhead that may come up in one-to-one communication using an ICN architecture. Both studies show that quality telephony services are feasible with at least one ICN approach. 🌸 That said, future ICN evaluations should use 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 how widespread real-time A/V communications are, an evaluation of an ICN system should show capabilities beyond feasibility. 👑 For example, when it comes 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. 🔐 Chen et al. [G-COPSS] also 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 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 raises the issue of named data granularity for dynamically generated content. ⏱️ In many cases, A/V data is generated in real time and distributed immediately. One option is to apply a single name to the entire content, but this could result in significant distribution delays. 😬 The other option is distributing A/V content in smaller "chunks" that are each named individually, which may be a better fit for real-time distribution but raises naming scalability concerns. 🧩
All in all, the ICN research community has so far only scratched the surface when it comes to showing the benefits of an information-centric approach as opposed to a host-centric one, so more work is recommended in this direction. 🔍 Scenarios in this category should show not only feasibility but also reduced complexity, increased scalability, reliability, and the capacity to meet stringent QoS/QoE requirements compared to established host-centric solutions. 💖 So the main goal here is to exercise each ICN architecture in terms of its ability to satisfy real-time QoS requirements and deliver an improved user experience. 🦋✨
2.3. Mobile Networking 📱
okay so IP mobility management relies on anchors to keep end-hosts and moving networks connected everywhere they go [MMIN]. This is a natural fit for the host-centric paradigm, which needs end-to-end connectivity and a continuous network presence for hosts [SCES]. The hidden assumption here is that the mobile node wants to reach one particular peer, while also keeping global reachability and service continuity [EEMN]. 💅 With ICN, though, new mobility ideas should come to the fore, and they can lean into what makes ICN different, like native support for multihoming, network addresses being abstracted away from applications, less dependence on connection-oriented sessions, and so on [MOBSURV]. main character energy, honestly ✨
Dannewitz et al. [N-Scen] show a scenario where a multiaccess end-host can fetch email securely using a mix of cellular and Wireless Local Area Network (WLAN) connectivity. 🦋 This scenario borrows elements from earlier work, e.g., [DTI], and develops them further for multiaccess. Unfortunately, Dannewitz et al. [N-Scen] do not present any results showing that an ICN approach is, indeed, better. ngl that's a bit of a bummer 😭 That said, it's still interesting, because it focuses on content specific to a single user (i.e., her mailbox) and it does point to reduced complexity. It's also compatible with recent work in the Distributed Mobility Management (DMM) Working Group within the IETF. 🫶 Finally, Xylomenos et al. [PSIMob] and Pentikousis [EEMN] argue that an information-centric architecture can dodge the complexity of managing tunnels to keep end-to-end connectivity, which is what mobile anchor-based protocols like Mobile IP (and its variants) have to deal with. Similar considerations hold for a vehicular (networking) environment, as we discuss in Section 2.6. 🚗
Overall, mobile networking scenarios haven't been developed in detail, let alone evaluated at a large scale. 🥲 Also, most of the scenarios discussed so far have been about the mobility of the information consumer, rather than the source. We expect more papers to tackle this topic in the coming period. Earlier work [mNetInf] argues that for mobile and multiaccess networking scenarios, we need to go beyond the current mobility management mechanisms in order to make the most of core ICN features. 🌸 They present a testbed setup (redrawn in Figure 2) that can serve as a basis for other ICN evaluations. In this scenario, node "C0" has multiple network interfaces that can access local domains N0 and N1 at the same time, so C0 can retrieve objects from whichever server (I2 or I3) can supply them, without needing to go through the servers in the core network "C" (P1 and P2). Lindgren [HybICN] explores this scenario further for an urban setting. He uses simulation and reports sizable gains in 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 of using the broadcast nature of wireless access technologies haven't been explored to their full potential in the ICN literature yet, including quantifying possible gains in energy efficiency [E-CHANET]. 🌈 Obviously, ICN architectures must avoid broadcast storms! Early work in this area looks at distributed packet suppression techniques that use delayed transmissions and overhearing. You can find examples in [MobiA] and [CCNMANET] for ICN-based mobile ad-hoc networks (MANETs), and in [RTIND] and [CCNVANET] for vehicular scenarios. 🧚
One would expect mobile networking scenarios to be naturally coupled with the ones in the previous sections, since more users access social-networking and multimedia apps through mobile devices. 📲 Plus, the constraints of real-time A/V applications make mobility super tricky, especially when it comes to keeping service continuity. iykyk 🙈 So this scenario spans most of the others in this document, and it will likely need some level of integration, especially given the well-documented increases in mobile traffic. Mobility gets more attention in Section 2.7, and the economic consequences of nodes having multiple network interfaces are explored in Section 3.1. 💜
Host-centric mobility management has traditionally used a range of metrics to evaluate performance, both per node and network-wide. The first metric that comes to mind is handover latency, defined in [RFC5568] as the "period during which the mobile node is unable to send or receive packets". 😳 This metric should be part of ICN performance evaluation studies that deal with mobility. Note that in IP-based networks, handover latency has been tackled by mobility management protocols that hide node mobility from the correspondent node. These often follow a make-before-break approach to keep connectivity seamless and to minimize (or completely eliminate) 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 could argue that such mechanisms aren't particularly suited for ICN. That said, there has been a lot of recent interest in distributed mobility management schemes (see [MMIN] for a summary), where mobility management support isn't "always on" by default. Those schemes may be a better fit for ICN. As a general recommendation, ICN designs should aim to minimize handover latency so that end-user and service QoE isn't adversely affected. 👑
Network overhead is another metric to consider when studying ICN mobility management, such as the amount of signaling needed to minimize handover latency. 🍓 In the past, network overhead has been seen as one of the main factors holding back the deployment of various mobility solutions. In IP-based networks, network overhead includes, but isn't limited to, tunneling overhead, in-band control protocol overhead, and 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 sum up, mobile networking scenarios should aim to provide service continuity for the applications that need it, decrease complexity and control signaling for the network infrastructure, and increase wireless capacity utilization by taking advantage of the broadcast nature of the medium. 🎀 Beyond that, mobile networking scenarios should form a cross-scenario platform that shows how other scenarios can still maintain their performance metrics during periods of high mobility. periodt 💖
2.4. Infrastructure Sharing 🤝
A key idea in ICN is that the network should secure information objects per se, not the communications channel they're delivered over. 🔐 This means hosts attached to an information-centric network can share resources on an unprecedented scale, especially compared to what's possible in an IP network. Every device with network access and storage capacity can contribute its resources, which makes an information-centric network more valuable. Compensation schemes that motivate users to contribute resources are still a research challenge, though, mostly 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 app that uses whichever access network connectivity is available at the moment (WLAN, Bluetooth, and even SMS), without needing a centralized infrastructure to sync numerous devices. It's important to point out that because the focus of communication changes, keep-alives are simply unnecessary in this scenario. Devices in the testbed network contribute resources to maintain user content consistency, not link state information like in the host-centric paradigm. So 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 tries to capture the storage/bandwidth tradeoffs that ICN enables. It can be used as the foundation for a network planning tool. 🧠 Chai et al. [CL4M] also explore the benefits of ubiquitous caching throughout an information-centric network, and they argue that "caching less can actually achieve more." 🤯 These papers sit alongside other studies looking at scenarios like caching HTTP-like traffic [CCNCT] and BitTorrent-like traffic [BTCACHE]. We observe that much more work is needed to understand how to make optimal use of all the resources available in an information-centric network. In real-world deployments, policy and commercial considerations are also likely to affect how particular resources get used, and more work is expected in that direction too. 💼
In conclusion, scenarios in this category would cover the communication-computation-storage tradeoffs that an ICN deployment must consider. ✨ This would exercise features related to network planning, perhaps capitalizing on user-provided resources, as well as operational and economic aspects of ICN, and contrast them with other approaches. An obvious baseline to compare against here is existing federations of IP-based Content Distribution Networks (CDNs), such as the ones discussed in the IETF Content Delivery Networks Interconnection Working Group. 🎀🫶
2.5. Content Dissemination 📡✨
Okay bestie, content dissemination has basically stolen the spotlight from everything else in ICN 💅. Scenarios like this are everywhere in the literature, and they cover stored and streaming A/V distribution, file distribution, mirroring and bulk transfers, versioned content services (think Subversion-style revision control), and traffic aggregation. Main character energy 👑
Decentralized content dissemination with on-the-fly aggregation of information sources was envisaged in [N-Scen] 🧩. The idea is that information objects can be dynamically assembled out of hierarchically structured subcomponents. So picture a video stream that's paired with different audio streams and subtitle sets, and all of those pieces can come from totally different sources 🎬. Using the topology in Figure 1 as an example, an application at C1 might end up grabbing the video from I1 but the user-picked subtitles from Px. Iconic 🫶. The authors also looked at semantics and content negotiation done on the user's behalf, like for popular tunes that might exist in different encoding formats 🎵. Basically, this scenario has the consumer firing off independent requests based on information identifiers, then stitching the pieces together no matter "where" or "how" they were obtained. Not me being obsessed with this 😭
Content dissemination is also a case in point for vehicular ad hoc networks (VANETs) 🚗. An ICN approach may serve their information dissemination needs between vehicles better than today's solutions, and we'll get into that in the next section. The big thing in a VANET is "where" and "when" 📍. For example, you might care about traffic conditions 2 km ahead while having zero interest in the same info about the area around the path origin. VANET scenarios could be fertile ground for showing off the ICN advantage for content dissemination, especially next to current host-centric approaches 💜. That said, information integrity and filtering are challenges that must be addressed, so no skipping that part 🙈. As mentioned above, content dissemination scenarios in VANETs have a special vibe with the mobility scenarios from Section 2.3.
Content dissemination scenarios in general overlap a lot with the ones in the earlier sections 🫠. They've been explored in several papers, including [DONA], [PSI], [PSIMob], [NetInf], [CCN], [CBIS], and [CCR], just to name a few 📚. Chai et al. [CURLING] also present a hop-by-hop hierarchical content resolution approach that uses receiver-driven multicast across multiple domains, which pushes yet another content dissemination approach 🌈. Still, the work in this area mostly didn't dig into access authorization in detail 👀. The distributed content is usually just assumed to be freely accessible to any consumer. Paid-for or otherwise restricted content on a public ICN network needs more attention in the future 💸. Fotiou et al. [ACDICN] do consider a scheme for this, but it still needs an authorization server to check the user's status after the (encrypted) content has already been obtained. Honestly, that could totally cancel out the perk of grabbing content from any node, especially in a disruption-prone or mobile network 💀.
In summary, scenarios in this category are mainly meant to test scalability and the cost and performance attributes of content dissemination 🎯. They should especially show that an ICN can scale to billions of objects, without costing more than existing content dissemination solutions (i.e., CDNs) and, ideally, while improving performance 🚀. This should all be shown holistically, so both information consumers and publishers of all sizes come out ahead 🍓. We expect that, in particular for content dissemination, both extreme and typical scenarios can be specified by drawing data from current CDN deployments 🧚.
2.6. Vehicular Networking 🚙💨
Users "on wheels" care about road safety, traffic efficiency, and infotainment apps 🎧. Those can be supported through vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) wireless communications. These apps have unique features when it comes to traffic generation patterns, delivery requirements, and spatial and temporal scope, which is a lot for traditional networking solutions to handle 😤. VANETs are naturally characterized by fast-changing topology, intermittent connectivity, and high node mobility. But they also come with the opportunity to combine information from different sources, because each vehicle doesn't care about "who" delivers the named data objects, just that it gets them ✨.
ICN is a very attractive candidate for vehicular networking, and it has several advantages 🦋. First, ICN fits really well with typical vehicular apps that depend on geography and time (like road traveler info, accident warnings, and point-of-interest ads). Those usually target vehicles in a given area, regardless of their identity or IP address 📍. These apps are likely to benefit from in-network and decentralized data caching and replication 🗂️. Second, content caching is especially helpful for intermittent on-the-road connectivity, and it can speed up retrieval by replicating content across several nodes 🏎️. Caching can usually be done at a relatively low cost in vehicles, because the ICN device's energy demands are likely a negligible fraction of the vehicle's total energy consumption. That leaves room for sophisticated processing, continuous communication, and plenty of storage in the vehicle 🔋. Finally, ICN natively supports asynchronous data exchange between end-nodes. By using (and redistributing) cached named information objects, a mobile node can act as a link between disconnected areas 🌉. Basically, ICN can enable communication even under intermittent connectivity, which is the norm in vehicular environments with sparse roadside infrastructure and fast-moving nodes 🫶.
The advantages of ICN in vehicular networks were first discussed in [EWC] and [DMND], and then further investigated in [DNV2V], [RTIND], [CCNHV], [CCDIVN], [CCNVANET], and [CRoWN] 🔍. For example, Bai and Krishnamachari [EWC] use the localized and dynamic nature of a VANET to explore how a road congestion notification app could work 🚧. Wang et al. [DMND] look at data collection, where Road-Side Units (RSUs) gather information from vehicles by broadcasting NDN-like Interest packets 📻. The proposed architecture was evaluated by simulation on a grid topology and compared against a host-centric alternative based on Mobile IP. See Figure 3 for an indicative example of an urban VANET topology 🏙️. Their results show high efficiency for ICN even at high speeds 🏁. Still, this work is only a preliminary exploration of ICN in vehicular environments, so there are various issues left to evaluate 🧐. Those 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, VANETs are a good showcase for ICN advantages in content dissemination 🎀. That's because the communication between a vehicle and the RSU is short, and the time vehicles stay connected to each other is typically short too ⏱️. 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 that have 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 equally by vehicles and RSUs 🤝. ICN forwarding gets extended through path-state information carried in Interest and Data packets, which is stored in a new data structure kept by vehicular nodes. That info is also used to cope with node mobility 🧠.
Typical scenarios for testing content distribution in VANETs could 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 too, where C0 is a vehicle that can get named information objects through multiple wireless peers and/or RSUs (I2 and I3 in the figure) 💖. Grid topologies like the one in Figure 3 should be considered for 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 sum up, VANET scenarios aim to exercise ICN deployment from several angles, including scalability, caching, transport, and mobility issues 🌟. There's a need for more investigation in (i) challenging scenarios (e.g., disconnected segments); (ii) scenarios involving both consumer and provider mobility; (iii) smart caching techniques that take into account node mobility patterns, spatial and temporal relevance, content popularity, and social relationships between users/vehicles; and (iv) identification of new applications (beyond data dissemination and traffic monitoring) that could benefit from adopting an ICN paradigm in vehicular networks (e.g., mobile cloud, social networking) 🚀💜
2.7. Delay- and Disruption-Tolerance
okay bestie, let's talk about DTN 🧚 Delay- and Disruption-Tolerant Networking (DTN) started out as a way to stretch the Internet to interplanetary communications [DTN]. but then people realized it was lowkey the perfect architecture for a ton of earthly situations too 🌍✨ usually that's where delays are longer than what protocols like TCP can handle, and where disruptions are the norm instead of a minor annoyance. like, an end-to-end path might not even exist when you start trying to communicate 💀 DTN is now used for so many things, including opportunistic content sharing, keeping infrastructure working during emergencies (think earthquakes 🫶), and bringing connectivity to remote rural areas that have no Internet, and very little or no communications or power infrastructure.
the DTN architecture [RFC4838] runs on a "store, carry, and forward" vibe 🎀 it's been used a lot in situations where data gets carried between network nodes by a "data mule", which is basically a person hauling bundles of data around on some convenient storage medium (like a USB memory stick 🧸). with sensor networks and peer-to-peer (P2P) networks between mobile nodes showing up, DTN is becoming way more common than anyone originally imagined 🦋 and since ICN also doesn't rely on the familiar end-to-end communications paradigm, there are clear synergies [DTNICN]. so it could honestly be argued that a lot of the key principles in DTN also exist in ICN, and we're about to see why 👑
first, both approaches rely on in-network storage 🍓 in DTN, bundles get stored temporarily on devices on a hop-by-hop basis. in ICN, information objects also get cached on devices in a similar fashion. so both paradigms have to provision storage within the network. no shade, just storage 💅
second, both approaches espouse late binding of names to locations, because the gap between a request and the response generation can be really long 😭 in DTN, it's often impossible to predict the exact location (in a disconnected topology) where a node will be found. same vibe in ICN, where it's also often impossible to predict where an information object might be found. so the binding of a request/bundle to a destination (or routing locator) must be performed as late as possible.
finally, both approaches treat data as a long-lived component that can hang out in the network for extended periods of time ⏳ in DTN, bundles are carried by nodes until appropriate next hops are discovered. in ICN, information objects are typically cached until storage is exhausted. so both paradigms require a direct shift in the way applications interact with the network. it's a whole glow-up 🌸
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. so these synergies suggest strong potential for marrying the two technologies 💜 this could include building new integrated Information-Centric Delay Tolerant Network (ICDTN) protocols or, alternatively, building ICN schemes over existing DTN protocols (and vice versa). iconic energy, fr fr 🔥
the similarities above suggest that integrating the two principles would be feasible 🫶 and beyond that, there are also a bunch of identifiable direct benefits. through caching and replication, ICN offers strong information resilience, whilst, through store-and-forward, DTN offers strong connectivity resilience. so both architectures could benefit greatly from each other 🌈 the DTN community has already taken initial steps to integrate ICN principles, e.g., the Bundle Protocol Query Block [BPQ] has been proposed for the DTN Bundle Protocol [RFC5050]. the ICN community has taken initial steps too, such as [SLINKY]. and the Scalable and Adaptive Internet Solutions (SAIL) project has actually developed a prototype implementation of NetInf running over the DTN Bundle Protocol. main character energy 🧚♀️
of course, in lots of circumstances, information-centricity is not appropriate for delay- and disruption-tolerant environments 🙈 this is especially true when information isn't the key communications atom being transmitted. also, situations where a single sink is always used for receiving information may not warrant identifying and routing independent information objects. however, there are a number of key scenarios where clear benefits could come from introducing information-centric principles into DTNs, and we'll describe two of them later in this section 🎀
for evaluating ICNs in a DTN setting, this document identifies two key scenarios. (note the rest of this section uses the term "ICDTN".) both are prominent use cases currently active in the ICN and DTN communities. the first is opportunistic content sharing, and the second is the use of ad hoc networks during disaster recovery (e.g., earthquakes) 🌸 we'll talk about both through a simulation-based evaluation, because the scale and mobility of DTN-like setups make this the primary method of evaluation used. within the DTN community, most simulations use the Opportunistic Network Environment (ONE) simulator [ONE], which this document refers to too. before we explore the two scenarios, we'll go over the key shared components of their simulation, which splits 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 the other scenarios in this document, an ICDTN scenario doesn't depend on (relatively) static topologies. instead it uses a set of time-varying disconnected topologies. in opportunistic networks, these topologies are actually products of user mobility 🚶♀️ like, 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, where a (mathematical) model of user behavior gets created in an agent-based fashion, e.g., random waypoint, Gauss-Markov. the second is trace-driven, where the mobility of real users gets 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 📱
here's the tea though ☕ an important factor missing from typical mobility traces is the capacity of these contacts: how much data can actually 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 how dominant these technologies are on mobile phones 🫠
the workload in an ICDTN is modeled pretty much like the workload in 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 dynamically, based on a model of user behavior. in both cases, the latter is the one that gets focused on, since it models the characteristics of these scenarios way better 🧠
once the environment and workload are configured, the next step is deciding the key metrics for the study 📊 unlike traditional networking, the QoS expectation is typically far lower in an ICDTN, so the focus moves away from metrics like throughput. at a high level, it's clearly interesting to evaluate different ICN approaches on both their delay- and disruption-tolerance (i.e., how effective the approach is in an environment subject to significant delay and/or disruption) and their active support for operations in a DTN environment 🌟
the two most prominent metrics in a host-centric DTN are delivery probability and delivery delay. the first relates to the probability that a sent message will be received within a certain delay bound 🎯 the second captures the average length of time it takes for nodes to receive the message. these metrics are just as important in an ICDTN, although they're a bit different because of the request-response nature of ICN. so the two most prominent evaluative metrics are satisfaction probability and satisfaction delay. satisfaction probability refers to the probability that an information request (e.g., Interest) will be satisfied (i.e., how often a Data response gets 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 things that may be investigated include name resolution, routing, and forwarding in disconnected parts of the network; support for unidirectional links; the 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's also important to weigh these performance metrics against the necessary overheads. in an ICDTN, that's generally measured by the number of message replicas required to access content. and ngl, routing in a DTN is often replication based, which leads to many copies of the same message 💀🫶
2.7.1. Opportunistic Content Sharing ✨
okay so the first key baseline scenario here is opportunistic content sharing 🚇💖 This is when mobile nodes spin up opportunistic links with each other to share content they actually care about. Picture people on an underground train passing news items between their phones 📱 Content generated on the phones (think tweets [TWIMIGHT] 🐦) could also be stored for later forwarding, or even forwarded to other interested passengers on the train 🫶 Obviously these scenarios must be based on either altruistic or incentivized interaction between users. The incentivized side is a seriously active area of research 👀 These networks are often called "pocket-switched networks" because the user devices form them independently, all by themselves 🧚
Here's where the evaluative scenario of ICDTN microblogging comes in 💅 As discussed earlier, building an evaluative scenario means formalizing its environment and workload. Lucky us, there are already datasets that give exactly that information for microblogging 🎀
In terms of the environment (aka mobility patterns), the Haggle project made contact traces from conference attendees using Bluetooth 🌸 These traces are best for application scenarios where a small group of (50-100) people are in a fairly confined space. For bigger, longer-term vibes, there's MIT's Reality Mining project, which is better suited to cases where you care about long-term movement patterns 🌈
The second input is the workload, which is all about creating and consuming microblogs (like tweets) 💜 This is easy to capture because subscriptions already formalize who consumes what 🙈 For bespoke purposes, you can collect specific data straight from Twitter for trace-driven simulations. Several Twitter datasets already exist for the community, covering everything from tweets to follower graphs. Check out <http://www.tweetarchivist.com> and <http://socialcomputing.asu.edu/datasets/Twitter> 🦋 These datasets can be used to extract information production, placement, and consumption.
2.7.2. Emergency Support and Disaster Recovery 🚨
The second key baseline scenario is about using ICDTNs in emergencies 😭 In these situations, infrastructure is typically damaged or destroyed, which causes traditional communications (like cellular telephone networks) to collapse 💀 We've seen this with the recent North Indian flooding and the 2011 Tohoku earthquake and tsunami. Power problems often make things worse, with communication failures lasting for days. So DTNs have been used to address this, thanks to their high levels of resilience and independence from fixed infrastructure 💪 The biggest use of DTNs in disaster areas is disseminating information, like warnings and evacuation maps 🗺️ Unlike the previous scenario, we can assume that certain users (like emergency responders) are highly altruistic 🫡 But many other users (like endangered civilians) may become way more conservative about how they use their devices, to save battery 🔋 Here, we focus on disseminating standard broadcast information that should be received by all parties. This is generally led by emergency responders ✨
For the environmental setup, there aren't any commonly used mobility traces for disaster zones, unlike the previous scenario 🥺 That's obviously because collecting them in a real setting is incredibly difficult, if not nearly impossible. That said, various synthetic models are available 🧪 The Post-Disaster Mobility Model [MODEL1] simulates civilians and emergency responders after a disaster, with people trying to reach evacuation points (this has also been implemented in the ONE simulator 🎮). Aschenbruck et al. [MODEL2] focus on emergency responders, including nodes leaving the disaster zone and obstacles like collapsed buildings 🏚️ Cabrero et al. [MODEL3] also look at emergency responders, but focus on patterns tied to common procedures. For example, command and control centers are usually set up with emergency responders periodically coming back 🔁 Honestly, the mobility of emergency responders matters a lot here, because they're usually the ones who "carry" information into the disaster zone 🎀 It is recommended that one of these emergency-specific models be used during any evaluations, since alternate models used for "normal" behavior can be inaccurate 🙅♀️
The workload in this evaluative scenario is way simpler than the last one 💅 In emergencies, disseminating individual pieces of information to all parties is the norm. This is often done with things like the Common Alert Protocol (CAP), which is an XML standard for describing warning messages 📣 It's currently used by various systems, including the Integrated Public Alert & Warning System and Google Crisis Response. So small objects (around 512 KB to 2 MB) usually get generated, containing text and images, and the ONE simulator has utilities to generate these easily 🖼️ These messages are also always generated by central authorities, which makes the placement problem easier. They get centrally generated and handed to emergency responders, who disseminate them as they pass through the disaster zone 🚑 The key variable is the generation rate, which is basically the same thing as the rate microblogs get written at in the previous scenario 📊 This will mostly depend on the type of disaster, but hourly updates would be an appropriate configuration ⏰ Higher rates can be tested too, based on how fast the situation changes (landslides, for example, can be super dynamic ⛰️)
To summarize, this section showed how ICN principles apply to existing DTN scenarios 🧚♀️ Two evaluative setups were described in detail: mobile opportunistic content sharing (microblogging) and emergency information dissemination 👑
2.8. Internet of Things 🌸
okay so, tiny electronics got SO good, and paired with low-power wireless tech like ZigBee, Near Field Communication (NFC), Bluetooth, and others, everyday objects can now plug into digital services 🔌✨ once a device has sensors and actuators and connects to the network, it becomes a "smart object," and all of them together form the so-called Internet of Things (IoT) 🧚. IoT is expected to really increase the amount of content the network carries, thanks to machine-to-machine (M2M) communication and brand new ways for users to interact with stuff 💖
ngl, the full potential of IoT is not just remote access to smart object data 🙈 the real glow-up happens where Internet services meet the physical world 🌈 Burke [IoTEx] makes a really strong case for everyday experiences built from interconnected things, through participatory sensing applications 🦋 here, inherent ICN capabilities for data discovery, caching, and trusted communication get used to collect sensor information and let content move between mobile users, repositories, and applications. it's giving collaboration, fr fr 🫶
Kutscher and Farrell [IWMT] talk about what ICN can bring to these environments when it comes to naming, caching, and optimized transport 💅 the Named Information URI scheme (ni) [RFC6920] could, for example, be used for globally unique smart object identification 🍓 though, bestie, there's no actual implementation report available yet 😭 info coming from smart objects can be super varied and is often vital for big systems to run correctly, so timestamping, security, scalability, and flexibility all need to be taken into account ✨
Ghodsi et al. [NCOA] look at hierarchical and self-certifying naming schemes and point out that making content naming and retrieval reliable and secure might come with stringent requirements (for example, having to use PKI) 💀 which can be way too demanding for low-powered nodes like sensors 🥺 that said, earlier work by Heidemann et al. [nWSN] shows that in dense sensor network deployments, separating sensor naming from network topology, using named content at the lowest level of communication, and doing in-network processing of sensor data is feasible in practice 💜 and it can be more efficient than a host-centric binding between a node locator and the content living there. slay 👑
Burke et al. [NDNl] describe a building automation system for lighting control, where NDN's security, naming, and device discovery mechanisms handle 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, which makes bootstrapping, discovery, and user interaction with nodes way simpler 🎀 the authors report that this ICN-based system requires less maintenance and troubleshooting than typical IP-based alternatives. literally iconic 🌟
Biswas et al. [CIBUS] picture ICN as a contextualized information-centric bus (CIBUS), where lots of different service producers and consumers coexist with different requirements 🚌 ICN is used to unify different platforms so consumer-producer interaction works in both infrastructure and ad hoc settings 🦋 Ravindran et al. [Homenet] show this idea working in a home network, where consumers (residents) want policy-driven interactions with services like climate control, surveillance systems, and entertainment systems 🏠 name-based protocols are developed for zero-configuration node and service discovery, contextual service publishing and subscription, policy-based routing and forwarding with a name-based firewall, and hoc device-to-device communication. main character energy 💅🔥
IoT pushes ICN concepts into a seriously strict set of requirements 😤 which get even more intense because of how many nodes there are, plus the type and volume of information that has to be handled 🌊 one way to tackle this is proposed in [IoTScope], which deals with mapping named information to an object. it moves away from the usual centralized discovery of services and leverages ICN's intrinsic scalability capabilities for naming 🧠 it extends the base [PURSUIT] design with hierarchically based scopes, so you can look up, access, and modify just the part of the object information you care about 🎯 another big deal is how to efficiently handle address resolution and location of information objects, especially when large numbers of nodes are connected, like in IoT deployments 🌐 in [ICN-DHT], Katsaros et al. propose a Distributed Hash Table (DHT) and compare it with the Data-Oriented Network Architecture described in [DONA]. their results show topological routing information has a positive impact on resolution, but it comes 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 once you think about the requirements and objectives of this integration 🌈 the disparity in technologies is wild, not only in access technologies but also in end-node diversity (sensors, actuators, and their characteristics) 🤯 and the same goes for the information that's generated and consumed in these scenarios. this will undoubtedly bring about many of the considerations from the previous sections ✨ for instance, IoT shares similarities with the constraints and requirements of vehicular networking 🚗 a central problem here is deploying mechanisms that can use opportunistic connectivity in unreliable networking environments (similar to vehicular networking and DTN scenarios) 🫠
however, one important concern in IoT scenarios, also motivated by this super heterogeneous environment, is how content dissemination gets affected by the different semantics of the disparate information and content being shared 🧩 honestly, this is already a hard problem that goes beyond the scope of ICN [SEMANT] 😵💫 with network nodes able to cache forwarded information to improve future requests, a challenge pops up: should the ICN fabric be involved in any kind of procedure (e.g., tagging) that helps relate or interpret the different sources of information? 🏷️ that's the question, bestie 💜
another issue is the need for energy-efficiency mechanisms tied to the networking capabilities of IoT infrastructures 🔋 devices in IoT deployments often have limited battery capabilities, so they need low power consumption schemes working at multiple levels ⚡ in principle, energy efficiency gains should show up from the inherent in-network caching capability. but this might not be the usual case in IoT, where the information (especially from sensors or controlling actuators) is more like real-time traffic 🙃 which shrinks the potential savings from ubiquitous in-network caching 📉
so, ICN approaches should be evaluated based on how well they handle the content produced and consumed by extremely large numbers of diverse devices 💖 IoT scenarios want to test ICN deployment from lots of angles, including ICN node design requirements, efficient naming, transport, and caching of time-restricted data ⏰ scalability is especially important here, because successful deployment of IoT principles could increase both device and content numbers dramatically, beyond all current expectations 🚀🌌
2.9. Smart City 🏙️
okay so the cities are about to get SO crowded 😭 by 2050 the world hits nine billion people, and 75% of them will be living in urban areas 🌆 so cities everywhere are doing a glow-up into the "smart city" vibe ✨ the big innovation axes are smart mobility, smart environment, smart people, smart living, and smart governance 💅 the core goal is to become a business-competitive, attractive place while also taking care of citizen well-being [CPG] 🫶
ICT is literally the glue here 🧚 it connects all the actors, services, and resources (plus how they relate to each other) that the city is willing to host and provide [MVM] 💜 and ICN is giving "perfect fit" energy for all of this 🦋 the domains it's looking at are intelligent transportation systems, energy networks, health care, A/V communications, peer-to-peer and collaborative platforms for citizens, social inclusion, active participation in public life, e-government, safety and security, and sensor networks 🌈 this scenario is also super closely tied to the IoT vibe we just talked about, plus vehicular networking 🚗💕
ngl the road to a real information-centric digital ecosystem is still long 😩 more coordinated effort is needed to push innovation here 🔥 the argument is that smart-city needs and ICN technologies can set off a virtuous innovation cycle toward future ICT platforms 🎀 there are already some concrete ICN-based contributions: home energy management [iHEMS], geo-localized services [ACC], smart-city services [IB], and traffic information dissemination in vehicular scenarios [RTIND] 🍓 some of these solutions are running on real testbeds, and others are checked out through simulation 👑
so Zhang et al. [iHEMS] propose a secure publish-subscribe architecture for Home Energy Management Systems (HEMS) 🏠⚡ the goal is to safely and effectively collect measurement and status info from household elements, aggregate and analyze the data, and then enable smart control decisions for actuation 🧠 for their proof-of-concept they used a simple experimental testbed, open source code for the ICN implementation, and emulated some node functionality to keep the system running smoothly 💖
a different scenario is in [ACC], where DHTs are used for distributed, scalable, and geographically aware service lookup in a smart city 🗺️✨ this one also got validated on a small-scale testbed 🧪 a few nodes were emulated with simple embedded PCs or specific hardware boards (for example, some sensor nodes), and other nodes (the ones connecting the main actors of the tests) were emulated with workstations 💻
the proposal in [IB] pulls from a smart-city scenario that's mostly about waste collection management 🗑️♻️ it has sensors, moving vehicles, and a cloud-computing system that handles data retrieval and storage 🌥️ the main parts were analyzed through simulation using publicly available open source code, and some software was built on real systems like PCs and smartphones 📱 slay 🫡
now, for evaluating ICN approaches in smart-city scenarios, it's necessary to look at generic metrics that help track progress on service results, compare localities with each other, and learn from the best [ISODIS] 📊 for a specific project you can pick a set of Key Performance Indicators (KPIs) to judge its success 🎯 these KPIs can reflect the city's environmental and social goals, along with its economic objectives, and they can be calculated at global, regional, national, and local levels 🌍 so there isn't one magic set of metrics 🙅♀️ but in smart cities, the KPIs should be characterized based on the set of services offered using the ICN paradigm 💜
to sum up, smart-city scenarios are a whole workout for ICN in an urban environment 💪 they're 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 🔐🌸 main character energy for sure 👑✨
3. Cross-Scenario Considerations 🌈
this section talks about the considerations that span multiple scenarios 🦋
3.1. Multiply Connected Nodes and Economics ✨
okay bestie, so the wireless world has gotten SO good that the bandwidth and capabilities of all these different network types are basically converging 🫶📶. Like, a leading-edge phone or tablet can totally hop onto a Wi-Fi access point, a 4G cellular network, and the newest Bluetooth local networking all at once, and it's giving main character energy 💅. Until pretty recently, a node usually had one clear fave network technology for any given environment. The pick was mostly driven by available bandwidth, with cost as the backup decider 💸. And honestly? A device normally only uses one of these technologies at a time for any particular application, which is so 2015 🙈.
It seems likely this is about to change, and nodes will be able to use ALL the available technologies in parallel 🔥. This is going to be hyped up even more by new cellular capabilities like Small Cell Networks [SCN] and Heterogeneous Networks [HetNet] 🌈. So mobile devices are going to get choices similar to wired nodes, meaning they can attach to multiple service providers and do "multihoming" across the different infrastructure networks 🦋. They can also get direct access to other mobile nodes through Bluetooth or a fancier form of ad hoc Wi-Fi 🧚.
Infrastructure networks are usually run by separate economic entities, and they 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 way networks interact will probably evolve to take advantage of data location independence, efficient and scalable in-network named object availability, and access via multiple paths 💜. These interactions are super critical when you're evaluating the technical and economic impact of ICN architectural choices, as noted in [ArgICN] 🎀. Beyond just adding diversity in deployment options, these networks could also shake up the incentives among existing (and future, we may add) network players, as noted in [EconICN] 👑.
Moreover, these networks allow for way more internetwork relationships, where exchanging information may depend on a set of multilateral policies 🌸. For example, shared SCNs are emerging as a cost-effective way to cover complex environments like sports stadiums, large office buildings, malls, etc. 🏟️ These networks are likely to be a complex mix of different cellular and WLAN access technologies (such as HSPA, LTE, and Wi-Fi) plus different ownership models 🔥. It's reasonable to assume that access to content generated in these networks may depend on contextual information like the subscription type, timing, and location of both the owner and requester of the content ⭐. If that contextual information isn't available across diverse networks, it 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 looked into this exact kind of scenario, and you can find more details in [SAIL-B3] 🙌.
Jacobson et al. [CCN] include interactions between networks in their overall system design, and they mention both "an edge-driven, bottom-up incentive structure" and techniques based on evolutions of existing mechanisms 🧠. Those techniques cover ICN router discovery by the end-user and 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 addressing the "suffix-hole" issue found in prefix-based name aggregation by combining Bloom-filter-based aggregation with a multi-level DHT 🌺.
Name aggregation has been discussed for a flat naming design, for example in [NCOA], where 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 of it) should take into account the amount of state (e.g., size of routing tables) kept in edge routers, as well as network efficiency (e.g., amount of traffic generated) ✨.
+---------------+
+---------->| 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 the policy knobs NDN makes available to network operators 🎛️. They describe New policies that aren't feasible in the current Internet, 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 in the investigation considers several networks and their 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 include 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 🦋.
+----------+ +-----------------+ +------+
| 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] 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 business factors into account 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 👀.
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 dataFigure 7. Tier-Based Set of Interconnections between AS A to J 🗺️
To sum up, evaluating ICN architectures across multiple network types should include a mix 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 toward this final state 🫶.
3.2. Energy Efficiency
okay so this section is literally about how ICN could save power 🔋💚 ngl the whole point is that it's a different vibe from the host-centric paradigm, and it might even come out more energy efficient overall, even though some ICN elements might use more energy for named-data processing along the way 🧚. on balance though, it's giving "compensates on the whole" 💅
we're gonna look at three things about ICN that help with energy: a) ICN doesn't rely only on end-to-end communication, b) ICN has ubiquitous caching, and c) ICN lets the network layer know about user requests and their responses, so network elements can better schedule their transmission patterns 🎀
first up, ICN doesn't need perpetual end-to-end communication 🙈 which is a huge energy drain from all the extra signaling, especially for mobile and wireless devices. this opens the door for sporadically connected nodes and could be one of the keys to an order-of-magnitude decrease in energy consumption, compared to what other tech advances might contribute 🔥. for example, web apps often have to keep state at both ends of a connection just to check that the authenticated peer is still up and running, which brings keep-alive timers and polling with a high energy toll 💀. Pentikousis [EEMN] talks through several related scenarios and explains why the current host-centric paradigm, with its perpetual end-to-end connections, has built-in energy inefficiencies. he argues that patching currently deployed protocols to be energy-aware can't deliver an order-of-magnitude increase in energy efficiency 😭
second, ICN elements come with built-in caching, which people call "ubiquitous caching" ✨ pushing data objects to caches closer to end-user devices could significantly cut the amount of transit traffic in the core network, and that means less energy used for data transport 🌸. Guan et al. [EECCN] studied the energy efficiency of a CCNx architecture (based on their own energy model) and compared it with conventional content dissemination systems like CDNs and P2P 👑. their model is based on analyzing the topological structure and the average hop length from all consumers to the nearest cache location. the results show an information-centric approach can be more energy efficient when delivering popular and small-size content 🍓. they also note that different network-element design choices (e.g., the optical bypass approach) can be more energy efficient for delivering infrequently accessed content 🦋
Lee et al. [EECD] looked at the energy efficiency of various network devices in access, metro, and core networks, for both CDNs and ICN 💜. they used trace-based simulations to show that an ICN approach can substantially improve network energy efficiency for content dissemination, mainly because there are fewer hops needed to get a data object, since intermediate nodes in ICN can serve it 🫶. they also stress that the impact of cache placement (in incremental deployment scenarios) and local/cooperative content replacement strategies needs to be carefully investigated, so we can better quantify the energy efficiencies from adopting an ICN paradigm 🌈
third, ICN elements are aware of the user request and its matching data response 👀 because of how name-based routing works, they can run power consumption optimization processes to decide their transmission schedule or to power down inactive network interfaces ⭐. for example, network coding [NCICN] or adaptive video streaming [COAST] can be used in individual ICN elements so redundant transmissions (which might pass through intermediary networks) get cut down, saving energy by not carrying redundant traffic 💖
alternatively, approaches that aim to simplify routers, such as [PURSUIT], could also cut energy use 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 functions 🎀. so data forwarding is done by simplified network entities, while the complicated routing computation happens in more energy-efficient data centers 💅
to sum up, energy efficiency has been discussed in ICN evaluation studies, but most of the published work is preliminary 🥺 so we think more work is needed here 🔥. evaluating energy efficiency doesn't require defining new scenarios or baseline topologies, but it does require clear guidelines so different ICN approaches can be compared not only for scalability, for example, but also for power consumption ✨
3.3. Operation across Multiple Network Paradigms
okay so today the vast majority of networks are hooked up to the well-connected Internet, with IP at the "waist" of the technology hourglass 🌐 but there's a ton of ongoing research into alternative paradigms that can handle conditions other than the standard ones the Internet assumes 🧪. the most advanced of these is Delay- and Disruption-Tolerant Networking (DTN) 🚀. DTN is considered one of the deployment scenarios in Section 2.7, but here we look at how ICN can operate in an integrated network made of basically disjoint "domains" (such an overloaded term, I know 😭) or regions that use different network paradigms and technologies, connected by gateways that let them interoperate 🫶
ICN works in terms of named data objects, so requests and deliveries of information objects can be independent of the networking paradigm 💖 some researchers have considered 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 solve first, including authorization, access control, and transactional operation for apps like banking 🏦 before any form of ICN can be considered ready to take over from IP as the dominant networking technology 💅. in the meantime, ICN architectures will run alongside 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" grows, other technologies like DTN will be needed for scenarios like space communications, where the inherent delays are too large for TCP/IP to cope with effectively 🚀✨ so showing that ICN architectures can work well in and across the boundaries of different networking technologies is going to be important 🌸
the NetInf architecture, in particular, targets the inter-domain scenario using 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 things to evaluate, beyond the architecture working fine in each constituent domain, are making sure requests and responses can cross network boundaries with adequate performance, and that they don't cause malfunctions in applications or infrastructure because of the differing characteristics of the gatewayed domains 🔥
- Summary ✨
okay this document has presented a wide range of application areas where information-centric network designs have been evaluated in the peer-reviewed literature 📚 this broad range of scenarios shows that ICN could potentially address today's problems in an alternative and better way than host-centric approaches, and point to future scenarios where ICN might apply 🌟. we believe that by putting different ICN systems to the test in diverse application areas, the community will be better equipped to judge the potential of a given ICN proposal, and therefore invest more effort in developing it further 💖
it's also worth noting that this document collected different kinds of considerations, from our ongoing survey of the literature and discussions within ICNRG, which otherwise might have gone unnoticed in the wider community 🫶 so we expect this document can help the applicability and future deployment of ICN across a broader set of operations 🌈, possibly influence and improve the base ICN proposals that exist today 👑, and possibly help define new scenarios where ICN would apply 🦋
we're gonna wrap up with a brief summary of the evaluation aspects we've seen across a range of scenarios 🎀
scalability of the different mechanisms in an ICN architecture is a big concern (cf. Sections 2.1, 2.2, 2.5, 2.6, 2.8, 2.9, and 3.1) 😭 and so are network, resource, and energy efficiency (cf. Sections 2.1, 2.3, 2.4, 3.1, and 3.2) ⭐. operational aspects like 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 get evaluated for potential real-world deployment 💅. so further research is needed in economic aspects, and in the communication, computation, and storage tradeoffs in each ICN architecture 🧠
for purely technical requirements, support for multicast, mobility, and caching sits 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 include additional network paradigms (cf. Section 3.3) 🌍. we've also seen that addressing stringent QoS requirements and increasing reliability and resilience should be evaluated using well-established methods (cf. Sections 2.2, 2.8, and 2.9) 🔥
finally, new applications that significantly improve the end-user experience and build a migration path away from today's host-centric paradigm could be the key to sustained, growing deployment of ICN in the real world 🚀✨ (cf. Sections 2.2, 2.3, 2.6, 2.8, and 2.9) 🫶
- Security Considerations 🔐
this document does not impact the security of the Internet 🛡️ (no drama, just vibes 💅)
- 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.[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.[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.[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.[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.[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.
Next up, the reference list. Every single one of these papers and drafts is a key ingredient in the whole ICN-meets-everything story, so here they all are, exactly as written 💅
[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.
[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.
[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.Acknowledgments 🌈
Huge shoutout to Dorothy Gellert 🎀, who contributed to an earlier draft version of this document. Icon behaviour 🫶
This document has benefited from reviews, pointers to the growing ICN literature, suggestions, comments, and proposed text 💜 from a crew of amazing people in the IRTF Information-Centric Networking Research Group (ICNRG). They're listed here in alphabetical order, because everyone deserves the spotlight ✨: 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. Absolute legends 🙌
The authors would also 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. Open, independent review is the whole vibe 🍓
Authors' Addresses 🦋
Here are the people behind the document, with their contact details. Kostas Pentikousis is the editor 👑
Kostas Pentikousis (editor)
EICT GmbH
Torgauer Strasse 12-15
10829 Berlin
Germany
EMail: k.pentikousis@eict.deBorje Ohlman
Ericsson Research
S-16480 Stockholm
Sweden
EMail: Borje.Ohlman@ericsson.comDaniel Corujo
Instituto de Telecomunicacoes
Campus Universitario de Santiago
P-3810-193 Aveiro
Portugal
EMail: dcorujo@av.it.ptGennaro Boggia
Dep. of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4
70125 Bari
Italy
EMail: g.boggia@poliba.itGareth Tyson
School and Electronic Engineering and Computer Science
Queen Mary, University of London
United Kingdom
EMail: gareth.tyson@eecs.qmul.ac.ukElwyn Davies
Trinity College Dublin/Folly Consulting Ltd
Dublin, 2
Ireland
EMail: davieseb@scss.tcd.ieAntonella 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.itSuyong 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.jpAnd that's a wrap on the whole doc, bestie 🌸💖
📦 where this page comes from
- ietf: rfc7476 2015-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms