RFC 7927

Information-Centric Networking (ICN) Research Challenges 🦋

okay so bestie, this is the research-challenges doc from the IRTF's ICN Research Group, and it is a whole vibe 💅 ✨ it's Informational, not a standard, so nobody's forcing you to implement it. It's the big "here's what we still need to figure out" list for the Internet rethinking itself around named data instead of host addresses. 🌸

Here's the cast of authors, all from different unis and orgs 🎀 D. Kutscher (NEC, the editor), S. Eum (Osaka University), K. Pentikousis (Travelping), I. Psaras (UCL), D. Corujo (Universidade de Aveiro), D. Saucez (INRIA), T. Schmidt (HAW Hamburg), and M. Waehlisch (FU Berlin). The date is July 2016, and it's published under the IRTF stream with ISSN 2070-1721. It doesn't obsolete or update any other RFCs. 🫶

Abstract

okay so the abstract is giving "here's the pitch" 💖 ICN wants to evolve the Internet so that uniquely named data is a core principle, and that data becomes independent of location, application, storage, and transport. the payoff is things like security, mobility, multicast, and in-network caching 🧚 the memo covers research challenges across naming, security, routing, scalability, mobility, wireless, transport, caching, and network management.

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

Status of This Memo

not a Standards Track spec, just published for info purposes 🙈 IRTF results "might not be suitable for deployment," and the group's consensus isn't a candidate for any Internet Standard level. (See Section 2 of RFC 7841 for why.) If you want the current status, errata, or to send feedback, the RFC Editor page is http://www.rfc-editor.org/info/rfc7927. 💅

Copyright Notice

Copyright (c) 2016 IETF Trust and the document authors, all rights reserved 🌈 It's subject to BCP 78 and the IETF Trust's Legal Provisions (http://trustee.ietf.org/license-info) as of publication. Read those carefully, bestie, they spell out your rights 💜

Table of Contents

1. Introduction ....................................................4
2. Problems with Host-Centric Communications .......................4
3. ICN Terminology and Concepts ....................................6
   3.1. Terminology ................................................6
   3.2. Concepts ...................................................6
4. ICN Research Challenges .........................................8
   4.1. Naming, Data Integrity, and Data Origin Authentication .....8
   4.2. Security ..................................................10
        4.2.1. Data Integrity and Origin Authentication ...........10
        4.2.2. Binding NDOs to Real-World Identities ..............11
        4.2.3. Access Control and Authorization ...................12
        4.2.4. Encryption .........................................13
        4.2.5. Traffic Aggregation and Filtering ..................13
        4.2.6. State Overloading ..................................13
        4.2.7. Delivering Data Objects from Replicas ..............14
        4.2.8. Cryptographic Robustness ...........................14
        4.2.9. Routing and Forwarding Information Bases ...........15
   4.3. Routing and Resolution System Scalability .................15
        4.3.1. Route-By-Name Routing ..............................15
        4.3.2. Lookup-By-Name Routing .............................16
        4.3.3. Hybrid Routing .....................................17
   4.4. Mobility Management .......................................18
   4.5. Wireless Networking .......................................20
   4.6. Rate and Congestion Control ...............................22
   4.7. In-Network Caching ........................................24
        4.7.1. Cache Placement ....................................24
        4.7.2. Content Placement: Content-to-Cache Distribution ...25
        4.7.3. Request-to-Cache Routing ...........................26
        4.7.4. Staleness Detection of Cached NDOs .................26
        4.7.5. Cache Sharing by Multiple Applications .............27
   4.8. Network Management ........................................27
   4.9. ICN Applications ..........................................29
        4.9.1. Web Applications ...................................30
        4.9.2. Video Streaming and Download .......................30
        4.9.3. Internet of Things .................................31
5. Security Considerations ........................................32
6. Informative References .........................................32
Acknowledgments ...................................................37
Authors' Addresses ................................................37

1. Introduction ✨

okay the big picture: ICN is about evolving the Internet so you can directly ask for Named Data Objects (NDOs) as a first-class network service 🦋 Data stops caring where it lives, which app made it, where it's stored, or how it gets moved, and that unlocks cheap, everywhere caching and replication 💖 The hoped-for wins are better efficiency and security, scaling better with demand, and staying robust in rough network conditions 🌸

You can get there two ways 🧚 You can retool the stack, running name-based access on top of today's IP (named data structures, ubiquitous caching, matching transport services). Or you can treat it as a packet-level internetworking tech that changes routing and forwarding at a fundamental level. Either way, ICN is the path toward a network built around named data with different properties and services 👑

This doc lays out the research challenges to crack in order to get there 💅 It's looking at them from a technical angle, though business relationships between Internet players will also shape things. Business challenges get their own separate document 🙈 The goal here is to write down the technical challenges, current approaches to them, and the requirements future research should address ✨

This document was reviewed, commented on, and discussed for nearly two years by the vast majority of ICNRG members, which is well over 100 people, so it's not a small thing 🎀 ICNRG agreed the research challenges should be published in the IRTF stream of the RFC series. It's not a standard, though 💀

2. Problems with Host-Centric Communications 🍓

okay so the best current move for handling the crazy growth in data volume and devices is to just buy more infrastructure 😭 and also layer on application-level overlays that cache stuff, like CDNs and P2P apps, give location-independent access to data, and optimize delivery. Those platforms basically offer a service model of accessing NDOs (think replicated web resources in data centers) instead of the classic host-to-host packet delivery model 💜

But here's the tea: those overlays are the only ones doing this, so the network itself isn't aware of data requests or transmissions, and the full potential of content distribution can't be unlocked 🫶 The impact is:

• Data traffic usually takes sub-optimal paths, since it's routed by the overlay topology instead of the Internet-layer topology 💀
• Network capabilities like multicast and broadcast are mostly underused or not used at all, so the same request and delivery have to happen multiple times 🙈
• Overlays usually need heavy infrastructure, like authentication portals, content storage, and app servers, so local direct communication often just isn't possible 🌈
• The forwarding layer can't work with transport-layer functions, so things like local retransmission and local rate control end up needing TCP proxies or other middlemen 🧚
• Provenance validation relies on host authentication today, so even when there are cached copies nearby, it's normally not easy to check if they're authentic 😭
• Lots of apps do their own thing for caching, replication, transport, and authenticity validation (if they do it at all), even though they all share similar models for accessing named data 💅

Host-centric systems only let apps transfer data between end-hosts, full stop 🎀 Naming data directly gives apps a powerful "hook" to use, natively supporting multi-party communication (multi-source and multi-destination) and an information ecosystem that isn't tied to end-host addresses 💖

3. ICN Terminology and Concepts 🌸

(continued in next part 🦋)

3.1. Terminology

Information-Centric Networking (ICN) 💖 is a concept for communicating in a network that provides accessing named data objects as a first order service. See Section 3.2 for details.

Named Data Object (NDO) 🎀 is an addressable data unit in an information-centric network that can represent a collection of bytes or a piece of information. In ICN, each data object has a name bound to it, and there are typically mechanisms to secure (and validate) this binding. Different ICN approaches have different concepts for how to map NDOs to individual units of transport, e.g., chunks and segments. Sometimes smaller units may be represented by NDOs themselves. Within the context of this document, an NDO is any named data object that can be requested from the network, and we do not consider sub-units below the NDO level. In this document, we often use the terms "NDO" and "data object" interchangeably. 🦋

Requestor 🧚 is an entity in an ICN network that is sending a request for a named data object to the network.

Publisher 👑 is an entity in an ICN network that publishes an NDO to the network, so that corresponding requests can reach the publisher. The publisher does not need to be identical to the actual creator. For example, a publisher could provide the service of hosting NDOs on behalf of the actual creators/owners. 🫶

3.2. Concepts

Okay so, fundamentally, ICN provides access to named data as a first-order network service, which means the network is able to serve requests to named data natively. 🔥 That means network nodes can receive requests for named data and act as necessary, for example, by forwarding the request to a suitable next hop. Consequently, the network processes requests for named data objects (and corresponding responses) natively. Every network node on a path is enabled to perform forwarding decisions, cache objects, etc. This enables the network to forward such requests on optimal paths, employing the best transmission technologies at every node, e.g., broadcast/multicast transmission in wireless networks to avoid duplicate transmission of both requests and responses. It's giving efficiency. 💅

In ICN, there is a set of common concepts and node requirements beyond this basic service model. Naming data objects is a key concept. In general, ICN names represent neither network nodes nor interfaces. They represent NDOs independently of their location. 🌸

Names do play a key role in forwarding decisions and are used for matching requests to responses. In order to provide better support for accessing copies of NDOs regardless of their location, it is important to be able to validate that a response actually delivers the bits that correspond to an original request for named data. Bestie, this is the vibe check that matters. ✨

Name-content binding validation is a fundamental security service in ICN, and this is often achieved by establishing a verifiable binding between the object name and the actual object or an identity that has created the object. ICN can support other security services, such as provenance validation and encryption, depending on the details of naming schemes, object models, and assumptions on infrastructure support. Security services such as name-content binding validation are available to any node, i.e., not just the actual requestors. This is an important feature for enabling ingress gateways to check object authenticity to prevent denial-of-service attacks. Not me being impressed by this one 😭🔒

Based on these fundamental properties, it is possible to leverage network storage ubiquitously: every ICN node can cache data objects and respond to requests for such objects. It is not required to validate the authenticity of the node itself, since name-content bindings can be validated. 🧁 Ubiquitous in-network storage can be used for different purposes. It can enable sharing, i.e., the same object copy can be delivered to multiple users/nodes as in today's proxy caches and CDNs. It can also be used to make communication more robust (and perform better) by enabling the network to answer requests from local caches instead of from origin servers. In case of disruption (message not delivered), a node can resend the request, and it could be answered by an on-path cache, i.e., on the other side of the disrupted link. The network itself would be able to send local retransmissions, which enables shorter round-trip times and the offloading of origin servers and other parts of the network. Main character energy for the network honestly. 👑

ICN potentially retrieves segments of NDOs from multiple data sources, so only a requestor can determine the completion of a retrieval process. In other words, the retrieval of NDOs or individual segments is typically controlled by a requestor. For this reason, ICN transport protocols are typically based on a receiver-driven mechanism: requestors can control message sending rates by regulating the request sending rate, assuming that every response message has to be triggered by a request message. Retransmission would be achieved by resending requests, e.g., after a timeout. Because objects can be replicated, object transmission and transport sessions would not necessarily have end-to-end semantics. Requests can be answered by caches, and a node can select one or multiple next-hop destinations for a particular request depending on configuration, observed performance, or other criteria. 🦋💜

This receiver-driven communication model potentially enables new interconnection and business models. A request for named data can be linked to an interest of a requestor (or requesting network) in data from another peer, which could suggest modeling peering agreements and charging accordingly. Lowkey the business side is so interesting, not gonna lie. 🌈💀

---

4. ICN Research Challenges 🌈

4.1. Naming, Data Integrity, and Data Origin Authentication ✨

Okay so naming data objects is literally as important for ICN as naming hosts is for today's Internet 🌸 ICN needs a unique name for every individual NDO, because names are how we identify objects no matter where they live or what container they're in. And here's the twist: since NDOs can get cached anywhere, you can't just trust the origin anymore 😭 That's why a verifiable binding between the object and its name matters so much (name-data binding validation). That way a requestor can be sure the bits it received really are the NDO it asked for (data integrity). Data origin authentication is a separate security service that's related to naming, though. It checks that an NDO was actually published by a publisher (which could be identified by a name prefix) 🎀

These functions are basically required for the information-centric network to work reliably. Otherwise, neither network elements nor requestors can trust that an object is authentic 💀 And when nobody can trust object authenticity, a bunch of attacks become possible, including DoS attacks, where spoofed content gets injected into the network. There are different ways to use names and cryptography to get these functions done [ICNNAMING] [ICNSURVEY], and there are different ways to manage namespaces to match 💅

Two types of naming schemes have shown up in the ICN literature: hierarchical and flat namespaces. A hierarchical scheme might look a lot like current URIs, with the hierarchy rooted in a publisher prefix. That structure lets routing information get aggregated, which improves the scalability of the routing system 📈 Some of these names are human readable too, so users can type them in by hand, reuse them, and (to some extent) map the name to what they actually want 🦋

The second general class of naming schemes lets you verify the object's name-data integrity without needing a Public Key Infrastructure (PKI) or some other third party to establish trust in the key first. Ta-da! It works by binding the hash of the NDO content to the object's name. For example, you can embed the hash of the content directly in the name. Another option is an indirect binding, where the name embeds the publisher's public key and the content hash gets signed with the matching private key 🔑 The resulting names are usually non-hierarchical (flat), although the publisher field could be used to build a structure that helps with route aggregation 🌈

There are several design trade-offs for ICN naming that affect both routing and security, and it's giving complicated 🙈 Hash-based names aren't human readable and aren't hierarchical. They can, however, provide some structure for aggregation, like a name part that corresponds to a publisher. With hash-based names and indirect binding, the publisher's key is bound to the NDO's name. So when a user receives, e.g., the triplet (data, key, signature), the receiving entity can check that the NDO was generated by whoever holds that private/public key pair, and that the NDO wasn't changed in transit (data integrity). To do that, you cryptographically hash the received key together with the NDO's name and compare the result to the received hashed key. Once that matches, the key can be used to verify the signature ✨

Data origin authentication can be achieved by validating public key cryptography signatures over an NDO's name and content. To get both data integrity and origin authenticity this way, you need a PKI-like system that links the corresponding public key to a trust chain 🫶

Research challenges specific to naming include:

• Naming static data objects can be done by using content hashes as part of object names. Publishers can calculate the hash over existing data objects, and requestors and any ICN node can validate the name-content binding by recalculating the hash and comparing it to the name (component). [RFC6920] specifies a concrete naming format for this 💖
• Naming dynamic objects refers to use cases where the name has to be generated before the object is created. For example, this could happen with live streaming, when a publisher wants to make the stream available by registering stream chunk names in the network 🎬 One approach is hash-based names with indirect binding, as described above.
• Requestor privacy protection can be a challenge in ICN, and it's a direct result of the accessing-named-data-objects paradigm. If the network can "see" requests and responses, it can also log request history for network segments or individual users, which can be undesirable 👀 That's especially true because names are typically expected to be long-lived. Even if a name doesn't reveal much on its own, the assumption is that it can be used to retrieve the corresponding data objects in the future.
• Updating and versioning NDOs can be tricky because it can contradict fundamental ICN assumptions 🙃 If an NDO can be replicated and stored in in-network storage for later retrieval, names have to be long-lived and the name-content binding must not change. Updating an object (changing the content without generating a new name) isn't possible. Versioning is one possible solution, but it requires a naming scheme that supports it (plus a way for requestors to learn about newer and older versions) 🧚
• Managing accessibility can also be a challenge. The general assumption in ICN is ubiquitous access to NDOs, but there can be real use cases where access should be restricted, for example, to a specific user group 🔒 There are different approaches here, such as object encryption (which requires key distribution and related mechanisms) or the concept of scopes, e.g., based on names that can only be used or resolved under certain constraints.

4.2. Security 🛡️

Security is an active research field in ICN, and this section gives an overview of the important security features and the challenges that come with shifting to information-centric communications 👑 Some challenges are well understood, and there are (sometimes multiple different) approaches to address them. Other challenges are still active research and engineering topics 🔥

4.2.1. Data Integrity and Origin Authentication

As mentioned in Section 4.1, data integrity verification is a big deal for ICN, since NDOs are retrieved not only from an original copy holder but also from any caching point 🧺 That means the communication channel endpoints used to retrieve NDOs aren't trustable anymore, so solutions widely used today, like Transport Layer Security (TLS) [RFC5246], can't be used as a general solution 😬 Because data objects can be maliciously modified, ICN should give receivers a security mechanism to verify the integrity of the data object. There are different ways to achieve this 💜

An efficient approach for static NDOs is to provide a name-content binding by hashing an NDO and using the hash as part of the object's name. [RFC6920] provides a mechanism and a format for representing a digest algorithm and the actual digest in a name (amongst other information) 🍓

For dynamic objects, where you want to refer to an NDO by name before the object has been created, public key cryptography is often applied. Every NDO gets authenticated by a signature made by the data object publisher, so any data object consumer can verify the validity of the data object based on that signature. The catch is that to verify the signature of an object, the consumer has to know the public key of the entity that signed it 🗝️

Data origin authentication (verifying that an NDO really was published by a publisher) requires a secure binding of an NDO name to a publisher identity. This is also typically implemented with public key cryptography, meaning a receiver has to verify the digital signatures that are part of received messages ✍️

One research challenge is supporting a mechanism to distribute publishers' public keys to the consumers of data objects. There are two main approaches. One is based on an external third-party authority, such as a hierarchical Public Key Infrastructure (PKI) (see [RFC5280] for a description of hierarchical PKI). The other is to adapt a hash-based scheme with indirect binding. The former, as the name implies, depends on an external third-party authority to distribute the publisher's public key to the consumers 🏛️ In a hash-based scheme with indirect binding, the public key (or a hash of it) is used as part of the name, which is enough to validate data integrity ✨

If information about a data object's origin isn't available by other means, the object itself has to include the information needed to determine its publisher. For example, it could carry a certificate that can be validated through the PKI. Once the certificate is authenticated, its public key can be used to authenticate the signed data object itself 🎀

4.2.2. Binding NDOs to Real-World Identities

On top of validating NDO authenticity, it's still important to bind real-world identities (like a publisher identity) to objects. That way, a requestor can verify that a received object was actually published by a certain source 🧑‍💻

With hash-based names, real-world identity bindings aren't established intrinsically. The name only provides the hash of the NDO or of the public key that was used to sign the NDO. If that feature is requested, there needs to be another binding to a real-world identity 🫠

If the object name directly provides the publisher name, and that name is protected by a certificate that links to a PKI-like trust chain, then the object name itself can provide an intrinsic binding to a real-world identity 💖

Binding between NDOs and real-world identities is essential, but there's no universal way to do it. It's all intrinsic to a particular ICN approach 🌸

4.2.3. Access Control and Authorization ✨

okay bestie, access control is lowkey a challenge in ICN 😭 because the whole communication model is built on named data, so there's no user-to-server authentication baked in. no cap, that's the vibe killer 💀

all ICN entities can deliver NDOs on demand thanks to their in-network caching function 🧚 so traditional access control schemes based on Access Control List (ACL) are kinda ill-suited 🙈. the widely distributed ICN entities would have to maintain an identical control policy over NDOs for each consumer, and that's prohibited because of computational overhead and privacy issues. there are two complementary approaches to fix this 🦋:

1. Separated approach: access control service comes from a third party that's independent from the ICN entities. since the separation is clean, ICN entities are free from computational overhead when figuring out whether consumers can access NDOs, and consumers can secure their privacy through the independent authorization entity [ACCESS-CTL-DEL]. the challenges here include reducing the authorization delay (when communicating with the access control provider) and the currency and consistency of access control information (when access control lists are distributed).
2. Integrated approach: access control service comes from the ICN entities themselves 💅 this one is often based on content encryption and key distribution [ENCRYPTION-AC]. as mentioned previously, it suffers from prohibitive overhead for ICN entities because of the process of key verification. key distribution is challenging per se, but this approach is beneficial in that NDOs can be retrieved without the help of an external access control provider. the challenges for this approach include:
   1. applying an access control mechanism for dynamic NDOs in in-network caches in a timely manner;
   2. providing consumers with the different levels of accessibility to individual NDOs in a scalable manner; and
   3. managing key revocation and similar PKI management functions.

4.2.4. Encryption 🔐

in ICN, NDOs can be encrypted to implement access control (only consumers holding the corresponding decryption keys can access the content) or privacy (same approach). distributing and managing those keys, plus providing usable interfaces for applications and human users, are challenges and the subject of ongoing work 🌸

in principle, the challenges are similar to those of broadcast/media distribution, and similar approaches (combing symmetric with public key cryptography) are being investigated [NDN-CTL-SHARING] ✨

4.2.5. Traffic Aggregation and Filtering 🍓

one request message to retrieve a data object can actually aggregate requests coming from several consumers. this aggregation cuts down the overall traffic, but it makes per-requestor filtering harder 🥺 the challenge is to come up with a mechanism that allows request aggregation and per-requestor filtering.

one possible solution is to indicate the set of requestors in the aggregated request, so the response can indicate the subset of requestors allowed to access the data object. the catch is that this needs collaboration from other nodes in the network, and it's not suitable for caching 🙃

another possible solution is to encrypt data objects and make sure only authorized consumers can decrypt them. this doesn't preclude caching and doesn't require collaboration from the network, which is giving main character energy 👑 however, it implies a mechanism to generate group keys (e.g., different private keys can be used to decrypt the same encrypted data object) [CHAUM].

4.2.6. State Overloading 🌧️

ICN solutions that implement state on intermediate routers for request routing or forwarding (e.g., Content-Centric Networking (CCN) [CCN]) are subject to denial-of-service attacks from overloading or superseding the internal state of a router (e.g., "interest flooding" [BACKSCATTER]). stateful forwarding can also enable attack vectors such as resource exhaustion or complexity attacks against the routing infrastructure 😱

the challenge is then to provision routers and construct internal state in a way that alleviates sensibility to such attacks. it gets even harder if the protocol doesn't provide information about the origin of messages. without origin, it's a particular challenge to tell regular (intense) use apart from misuse of the infrastructure 🫶

4.2.7. Delivering Data Objects from Replicas 🪞

a common capability of ICN solutions is data replication and in-network storage. delivering replicated data objects from caches decouples content consumption from data sources, which leads to a loss of control over (1) content access and (2) content dissemination. in a widely distributed, decentralized environment like the Internet, this raises several challenges 🌈

one group of challenges is related to content management. without access control, a content provider loses the means to count and survey content consumption, to limit access scopes, to control or know about the number of copies of its data in the network, or to withdraw earlier publications reliably. any non-cooperative or desynchronized data cache may hinder an effective content management policy 😤

another group of challenges comes from potential traffic amplifications in the decoupled environment. ICN solutions that attempt to retrieve content from several replicas in parallel, or decorrelated network routing states, but also distributed attackers, may simultaneously initiate the transmission of content from multiple replicas towards the same destination (e.g., "initiated overloads" or "blockades" [BACKSCATTER]). methods for mitigating such threats need rigorous forwarding checks that require alignment with caching procedures (e.g., on-path or off-path) 🚨

4.2.8. Cryptographic Robustness 🔑

content producers sign their content to ensure the integrity of data and to allow for data object authentication. this is a fundamental requirement in ICN because of distributed caching. publishers who massively sign content, which is long-lived, hand time and data to an attacker for comprising cryptographic credentials 😬 signing a large amount of data makes common attacks that try to breach the publisher's key way easier. based on this observation, the following research challenges emerge:

• To which extent does the content publication model conflict with the cryptographic limitations?
• How can we achieve transparent re-signing without introducing additional cryptographic weaknesses or key management overhead?

in general, ICN implementations should be designed with the guidelines provided by [RFC7696] in mind, especially regarding cryptographic algorithm agility. for example, [RFC6920] specifies a naming scheme for hash-based names that was designed to support algorithm agility 🧠

4.2.9. Routing and Forwarding Information Bases 🗺️

in information-centric networks, one attack vector is to increase the size of routing and forwarding information bases at ICN nodes, i.e., attacking routing scalability in networks that rely on routing by name. this is an intrinsic ICN security issue 🚩 possible mitigation approaches include combining routing information authenticity validation with filtering (e.g., maximum de-aggregation level whenever applicable, blacklists, etc.,).

4.3. Routing and Resolution System Scalability 🚀

ICN routing is a process that finds an NDO based on its name, which is initially provided by a requestor. ICN routing may comprise three steps: (1) name resolution, (2) discovery, and (3) delivery. the name resolution step translates the name of the requested NDO into its locator. the discovery step routes the request to the data object based on its name or locator. the last step, delivery, routes the data object back to the requestor. depending on how these steps are combined, ICN routing schemes can be categorized as Route-By-Name Routing (RBNR), Lookup-By-Name Routing (LBNR), and Hybrid Routing (HR), as discussed in the following subsections 🧩

4.3.1. Route-By-Name Routing 🎀

RBNR omits the first name resolution step, since the name of the NDO is used directly to route the request to the data object. that means routing information for each data object has to be maintained in the routing table. the number of data objects is very large (estimated as 10^11 back in 2007 [DONA], but this may be significantly larger than that, e.g., 10^15 to 10^22), so the size of routing tables becomes a concern. it can be proportional to the number of data objects unless an aggregation mechanism is introduced 😵‍💫

on the other hand, RBNR reduces overall latency and simplifies the routing process because the resolution process is skipped ⚡ for the delivery step, RBNR needs another identifier (ID) of either host or location to forward the requested data object back to the requestor. otherwise, an additional routing mechanism has to be introduced, such as breadcrumbs routing [BREADCRUMBS]. in breadcrumbs routing, each request leaves behind a trail of breadcrumbs along its forwarding path, and then the response is forwarded back to the requestor by consuming that trail 🍞

challenges specific to RBNR include:

• How can we aggregate the names of data objects to reduce the number of routing entries?
• How does a user learn the name that is designed for aggregation by the provider? For example, although we name our contribution "ICN research challenges", the IRTF (provider) may want to change the name to /IETF/IRTF/ICN/Research challenges for aggregation. In this case, how does a user learn the name /IETF/IRTF/ICN/Research challenges to retrieve the contribution initially named "ICN research challenges" without any resolution process? 🤔
• Without introducing the name aggregation scheme, can we still achieve scalable routing by taking advantage of topological structure and distributed copies? For example, would employing compact routing [COMPACT], random walk [RANDOM], or greedy routing [GREEDY] work at the Internet scale?
• How can we incorporate copies of a data object in in-network caches in this routing scheme?
• Breadcrumbs routing implies a symmetric path for ICN request and response delivery. some network configurations and link types prohibit symmetric path forwarding, so it would be challenging to interconnect such networks to an infrastructure based on breadcrumbs routing. for example, certain forwarding strategies in Delay-Tolerant Networking (DTN) [RFC4838] use opportunistic forwarding, where responses cannot be assumed to travel the same path as requests 🦋

4.3.2. Lookup-By-Name Routing ✨

Okay bestie, LBNR is giving "look up first, route second" 💅. Step one is name resolution: it translates the name of the requesting data object into its locator. Then step two, discovery, is carried out based on that locator. Since IP addresses could be used as locators, the discovery step can depend on the current IP infrastructure 🌸. The delivery step can be implemented similarly to IP routing. The locator of the requestor goes in the request message, and then the requested data object is delivered to the requestor based on that locator. An instantiation of LBNR is [MDHT] 🦋.

Challenges specific to LBNR include:

• How can we build a scalable resolution system that provides:
  • Fast lookup: Mapping the name of a data object to its locators (copies as well).
  • Fast update: The location of a data object is expected to change frequently. Also, multiple data objects may change their locations at the same time, e.g., data objects in a laptop.
• How can we incorporate copies of a data object in in-network caches in this routing scheme?

4.3.3. Hybrid Routing 🧚

HR is the best of both worlds 👑. It combines RBNR and LBNR to get the advantages of each. Within a single administrative domain, e.g., an ISP, where scalability issues can be addressed with network planning, RBNR can be adopted to reduce overall latency by skipping the resolution process. On the other hand, LBNR can be used to route between domains that have their own prefix (locator) 💜.

For instance, a request message initially includes the name of the NDO for the operation of RBNR and is forwarded to a cached copy of the NDO or the original server. When the request message fails to find a routing entry in the router, a name resolution step kicks in to translate the name into its locator before forwarding the request message based on the retrieved locator 🫶.

Challenges specific to HR are:

• How can we design a scalable mapping system that, given the name of the NDO, should return a destination domain locator so that a user request can be encapsulated and forwarded to the domain?
• How can the mapping information be secured to prevent a malicious router from hijacking the request message by chaining its locator?
• How can the bind between the name and the content of the NDO be maintained for the verification of its origin and integrity when the name changes due to the retrieved locator?

4.4. Mobility Management 🌈

Mobility management has been an active field in host-centric communications for more than two decades 😭. In the IETF in particular, starting with [RFC2002], a multitude of enhancements to IP have been standardized, aiming to "allow transparent routing of IP datagrams to mobile nodes in the Internet" [RFC5944]. In a nutshell, mobility management for IP networks is locator-oriented and relies on the concept of a mobility anchor as a foundation for providing always-on connectivity to mobile nodes (see [MMIN]). Other standards organizations, such as 3GPP, have followed similar anchor-based approaches. Traffic to and from the mobile node must flow through the mobility anchor, typically using a set of tunnels, which enables the mobile node to remain reachable while changing its point of attachment to the network.

Needless to say, an IP network that supports node mobility is more complex than one that does not, as specialized network entities must be introduced in the network architecture 🙈. This is reflected in the control plane as well, which carries mobility-related signaling messages, establishes and tears down tunnels, and so on. While mobile connectivity was an afterthought in IP, in ICN it is considered a primary deployment environment ✨. Most, if not all, ICN proposals consider mobility from the very beginning, although at varying levels of architectural and protocol detail. That said, no solution has so far come forward with a definite answer on how to handle mobility in ICN using native primitives 💀. In fact, we observe that mobility appears to be addressed on an ICN proposal-specific basis. That is, there is no single paradigm solution, akin to tunneling through a mobility anchor in host-centric networking, that can be applied across different ICN proposals. For instance, although widely deployed mobile network architectures typically come with their own network entities and associated protocols, they follow the same line of design with respect to managing mobility. This design thinking, which calls for incorporating mobility anchors, permeates the ICN literature too.

However, employing mobility anchors and tunneling is probably not the best way forward in ICN research for mobile networking. Fundamentally, this approach is anything but information-centric and location-independent 🍓. In addition, as argued in [SEEN], current mobility management schemes anchor information retrieval not only at a specific network gateway (e.g., home agent in Mobile IP) but also at a specific correspondent node, due to the end-to-end nature of host-centric communication. However, once a change in the point of attachment occurs, information retrieval from the original "correspondent node" may no longer be optimal. This was shown in [MANI], for example, where a simple mechanism that triggers the discovery of new retrieval providers for the same data object, following a change in the point of attachment, clearly outperforms a tunnel-based approach like Mobile IP in terms of object download times 🔥. The challenge here is how to capitalize on location information while facilitating the use of ICN primitives, which natively support multicast and anycast.

ICN naming and name resolution, as well as the security features that come along, should natively support mobility 💖. For example, CCN [CCN] does not have the restriction of spanning tree routing, so it is able to take advantage of multiple interfaces or adapt to the changes produced by rapid mobility (i.e., there is no need to bind a layer 3 address with a layer 2 address) ⭐. In fact, client mobility can be simplified by allowing requests for new content to normally flow from different interfaces or through newly connected points of attachment to the network. However, when the node moving is the (only) content source, it appears that more complex network support might be necessary, including forwarding updates and cache rebuilding. A case in point is a conversation network service, such as a voice or video call between two parties. The requirements in this case are more stringent when support for seamless mobility is required, especially when compared to content dissemination that is amenable to buffering. Another parameter that needs attention is the impact of using different wireless access interfaces based on different technologies, where the performance and link conditions can vary widely depending of numerous factors.

In host-centric networking, mobility management mechanisms ensure optimal handovers and (ideally) seamless transition from one point of attachment to another. In ICN, however, the traditional meaning of "point of attachment" no longer applies, as communication is not restrained by location-based access to data objects 🦋. Therefore, a "seamless transition" in ICN ensures that content reception continues without any perceptible change from the point of view of the ICN application receiving that content. Moreover, this transition needs to be executed in parallel with ICN content identification and delivery mechanisms, enabling scenarios such as preparation of the content delivery process at the target connectivity point prior to the handover (to reduce link switch disturbances). Finally, these mobility aspects can also be tightly coupled with network management aspects, in respect to policy enforcement, link control, and other parameters necessary for establishing the node's link to the network 🎀.

In summary, the following research challenges for ICN mobility management can be derived:

• How can mobility management take full advantage of native ICN primitives?
• How do we avoid the need for mobility anchors in a network that by design supports multicast, anycast, and location-independent information retrieval?
• How can content retrieval mechanisms interface with specific link operations, such as identifying which links are available for certain content?
• How can mobility be offered as a service that is only activated when the specific user/content/conditions require it?
• How can mobility management be coordinated between the node and the network for optimization and policing procedures?
• How do we ensure that managing mobility does not introduce scalability issues in ICN?
• How will the name resolution process be affected by rapid topological changes when the content source itself is mobile?

4.5. Wireless Networking ✨

Okay so, every layer 2 (L2) wireless radio access tech is built on one big assumption: IP is the waist of the protocol stack, and it's gonna stay that way for the foreseeable future 🫶. Because that waist is fixed, engineers can answer a whole bunch of questions in a pretty straightforward way, like how to handle conversational traffic (voice calls) vs. web traffic, how to support multicast, and so on 💅. Broadcast is literally inherent in wireless communication, but it isn't fully taken advantage of 😭. Researchers are more focused on mechanisms that make sure "broadcast storms" don't take down a network 💀. How broadcast can better serve ICN needs hasn't been thoroughly investigated yet 🔥.

Wireless networking is often tangled up with mobility, but not always 🦋. Empirical measurements show that lots of users connect to a single Wi-Fi access point and just stay connected for considerable amounts of time 🍓. A classic example, which the ICN literature keeps citing in different versions, is accessing a document repository during a meeting 📝. In a typical IETF working group meeting, a scribe takes notes and uploads them to a centralized repository (see Figure 1). Then each meeting participant grabs their own copy for local use, annotating, and sharing with colleagues who weren't there 🌸. Note that in this example there's no node mobility, and it doesn't matter whether the document is uploaded in one go at the end of the session or streamed like typical cloud-based document processing today ✨.

        +---------------------+
        | Document Repository |
        +---------------------+
                  ||
              (Internet)
                  ||
          +--------------+
          | Access Point |
          +--------------+
         /  |             \
        /   |              \
       /    |               \
  Scribe   Participant 1 ... Participant N

             Figure 1: Document Sharing During a Meeting

Here's the tea 🫢: the same data object bits (the meeting notes) need to cross the wireless medium at least N+1 times, where N is the number of meeting participants getting a copy. Basically, a broadcast medium gets shoehorned into N+1 virtual unicast channels 🙈. You could argue wireless local connectivity is inexpensive, but that's not the critical factor here 💅. The actual information exchange wastes N times the available network capacity, no matter what the spectral efficiency (or the economics) of the wireless tech is 😤. This waste is a direct result of extending the remote access paradigm from wired to wireless, even though wireless has its own special characteristics 💀.

It goes without saying that an ICN approach which doesn't consider the wireless nature of an interface will waste the same amount of resources as a host-centric paradigm 🙃. In-network caching at the wireless access point could reduce the data carried over the backhaul link, but if the wireless medium is used the same way, the NDO still gets carried over the wireless ether N+1 times 😭. Intelligent caching strategies, replica placement cooperation, and so on simply cannot fix that 💔. On the flip side, promiscuous interface operation and opportunistic caching would maximize wireless network capacity utilization in this example 🧚.

Arguably, if you design a future wireless access technology with an information-centric "layer 3" in mind, a lot of the design choices that are obvious in an all-IP architecture might no longer hold up 🌈.

Although this is clearly outside the scope of this document, a few research challenges the wider community might be into include:

• Can we use wireless resources more frugally with the information-centric paradigm than what's possible today in all-IP wireless networks? 💜
• In the context of wireless access, how can we leverage the broadcast nature of the medium in an information-centric network? 📡
• Would a wireless-oriented ICN protocol stack deliver significant performance gains? How different would it be from a wired-oriented ICN protocol stack? 🤔
• Is it possible that by changing the network paradigm to ICN we can, in practice, increase the spectral efficiency (bits/s/Hz) of a wireless network beyond what's possible with today's host-centric approaches? What would be the impact of doing so on energy consumption? ⚡
• Can promiscuous wireless interface operation coupled with opportunistic caching increase ICN performance, and if so, by how much? 📈
• How can a conversational service be supported at least as efficiently as today's state-of-the-art wireless networks deliver? 📞
• What are the benefits of combining ICN with network coding in wireless networks? 🧩
• How can Multiple-Input Multiple-Output (MIMO) and Coordinated Multipoint Transmission (CoMP) be natively combined with ICN primitives in future cellular networks? 📶

---

4.6. Rate and Congestion Control 🚦

ICN's receiver-driven communication model, which we talked about above, opens up new opportunities for transport protocol design 🙌. It doesn't rely solely on end-to-end communication from a sender to a requestor, because a requested data object can be accessible in multiple different network locations 🗺️. A node can decide how to use multiple sources, for example by sending parallel requests for the same NDO or by switching sources (or next hops) on a suitable schedule for a series of requests 🔀.

In this model, the requestor controls the data rate by regulating its request sending rate and next by doing source/next-hop selections 🎛️. The specific challenges depend on the ICN approach, but general challenges for receiver-driven transport protocols (or mechanisms, since dedicated protocols might not be required) include flow and congestion control, fairness, network utilization, stability (of data rates under stable conditions), and so on 💅. [HRICP] and [CONTUG] describe request rate control protocols and the design challenges that come with them 📚.

As mentioned above, the ICN communication paradigm doesn't depend strictly on end-to-end flows, since content might be received from in-network caches 🧠. So the traditional concept of a flow is kind of not valid anymore, because sub-flows (or flowlets) might be formed on the fly when fractions of an NDO are transmitted from in-network caches 🌊. For a transport-layer protocol this is challenging, because any measurement related to the flow, the way transport protocols such as TCP traditionally do it, can often prove misleading 😵. For example, false Round-Trip Time (RTT) measurements lead to highly variable average and smoothed RTT values, which in turn trigger false timeout expirations ⏰.

Out-of-order delivery is also expected to be common when parts of a data object are retrieved from in-network caches instead of the origin server 🔄. Several techniques for dealing with out-of-order delivery have been proposed in the past for TCP, and some of them could potentially be modified and reused in the context of ICN ♻️. More research is needed here, though, to choose the right technique and adjust it to the requirements of the ICN architecture and the transport protocol in use 🔍.

ICN lets routers aggregate requests and use several paths, which means there's no such thing as a (dedicated) end-to-end communication path 🛤️. For example, a router that receives two requests for the same content at the same time only sends one request to its neighbor 🤝. This aggregation has a general impact on transport protocol design, and it opens up new options for employing per-node forwarding strategies and for rethinking in-network resource sharing [RESOURCE-POOL] 💡.

Achieving fairness for requestors can be a challenge, since it's not possible to identify the number of requestors behind one particular request 🫣. A second problem related to request aggregation is managing request retransmissions 🔁. Generally, it's assumed that a router won't transmit a request if it recently transmitted an identical one. And because there's no information about the requestor, the router can't tell the initial request from a client apart from a retransmission from that same client 🥲. In that situation, routers can adapt their timers to use the best of the communication paths ⏱️.

---

4.7. In-Network Caching 🗄️

Explicitly named data objects allow for caching at virtually any network element, including routers, proxy caches, and end-user devices 💖. That means in-network caching can improve network performance by fetching content from nodes that are geographically closer to the end user 🏃‍♀️. There are several issues that still need further investigation when it comes to in-network caching 🔎. In this section, we list important challenges related to the properties of this new ubiquitous caching system 🌍✨.

Continuing 💖 okay bestie, here's the next bit of the in-network caching section, so let's get into it ✨

4.7.1. Cache Placement 🎀

The declining cost of fast memory gives the opportunity to deploy caches in network routers and to take advantage of cached NDOs. We identify two approaches to in-network caching, namely, on-path and off-path caching. Both approaches have to consider the issue of cache location. Off-path caching is similar to traditional proxy-caching or CDN server placement. Retrieval of contents from off-path caches requires redirection of requests and, therefore, is closely related to the Request-to-Cache Routing problem discussed below. Off-path caches have to be placed in strategic points within a network in order to reduce the redirection delays and the number of detour hops to retrieve cached contents. Previous research on proxy-caching and CDN deployment is helpful in this case.

On the other hand, on-path caching requires less network intervention and fits more neatly in ICN. However, on-path caching requires line-speed operation, which places more constraints on the design and operation of in-network caching elements. Furthermore, the gain of such a system of on-path in-network caches relies on opportunistic cache hits and has therefore been considered of limited benefit, given the huge amount of contents hosted in the Internet. For this reason, network operators might initially consider only a limited number of network elements to be upgraded to in-network caching elements. The decision on which nodes should be equipped with caches is an open issue and might be based, among others, on topological criteria or traffic characteristics. These challenges relate to both the Content Placement problem and the Request-to-Cache Routing problem discussed below.

In most cases, however, the driver for the implementation, deployment, and operation of in-network caches will be its cost. Operating caches at line speed inevitably requires faster memory, which increases the implementation cost. Based on the capital to be invested, ISPs will need to make strategic decisions on the cache placement, which can be driven by several factors, such as avoidance of inter-domain/expensive links, centrality of nodes, size of domain and the corresponding spatial locality of users, and traffic patterns in a specific part of the network (e.g., university vs. business vs. fashion district of a city). 🏙️💅

4.7.2. Content Placement: Content-to-Cache Distribution 🌸

Given a number of on-path or off-path in-network caching elements, content-to-cache distribution will affect both the dynamics of the system, in terms of request redirections (mainly in case of off-path caches) and the gain of the system in terms of cache hits. A straightforward approach to content placement is on-path placement of contents as they travel from source to destination. This approach reduces the computation and communication overhead of placing content within the network but, on the other hand, might reduce the chances of hitting cached contents. This relates to the Request-to-Cache Routing problem discussed next.

Furthermore, the number of replicas held in the system brings up resource management issues in terms of cache allocation. For example, continuously replicating data objects in all network elements results in redundant copies of the same objects. The issue of redundant replication has been investigated in the past for hierarchical web caches. However, in hierarchical web-caching, overlay systems coordination between the data and the control plane can guarantee increased performance in terms of cache hits. Line-speed, on-path, in-network caching poses different requirements; therefore, new techniques need to be investigated. In this direction, reducing the redundancy of cached copies is a study item. However, the issue of coordinated content placement in on-path caches remains open.

The Content-to-Cache Allocation problem relates also to the characteristics of the content to be cached. Popular content might need to be placed where it is going to be requested next. Furthermore, issues of "expected content popularity" or temporal locality need to be taken into account in designing in-network caching algorithms in order for some contents to be given priority (e.g., popular content vs. one-timers). The criteria as to which contents should be given priority in in-network content caches relates also to the business relationships between content providers and network operators. Business model issues will drive some of these decisions on content-to-cache distribution, but such issues are outside the scope of this note and are not discussed here further. 🧁

4.7.3. Request-to-Cache Routing 🦋

In order to take advantage of cached contents, requests have to be forwarded to the nodes that cache the corresponding contents. This challenge relates to name-based routing, discussed earlier. Requests should ideally follow the path to the cached NDO. However, instructions as to which content is cached where cannot be broadcast throughout the network. Therefore, the knowledge of an NDO location at the time of the request either might not exist or might not be accurate (i.e., contents might have been removed by the time a request is redirected to a specific node).

Coordination between the data and the control planes to update information of cached contents has been considered, but in this case, scalability issues arise. We therefore have two options. We either have to rely on opportunistic caching, where requests are forwarded to a server and in case the NDO is found on the path, then the content is fetched from this node instead of the origin server, or we employ cache-aware routing techniques. Cache-aware routing can involve either both the control and the data plane or only one of them. Furthermore, cache-aware routing can be done in a domain-wide scale or can involve more than one individual Autonomous System (AS). In the latter case, business relationships between ASes might need to be exploited in order to build a scalable model. 🗺️✨

4.7.4. Staleness Detection of Cached NDOs 🕰️

Due to the largely distributed copies of NDOs in in-network caches, ICN should be able to provide a staleness verification algorithm that provides synchronization of NDOs located at their providers and in-network caching points. Two types of approaches can be considered for this problem, namely direct and indirect approaches.

In the direct approach, each cache looks up certain information in the NDO's name, e.g., the timestamp, that directly indicates its staleness. This approach is applicable to some NDOs that come from machine-to-machine and Internet of Things scenarios, whose base operation relies on obtaining the latest version of that NDO (i.e., a soil sensor in a farm providing different continuous parameters that are sent to a display or greenhouse regulation system) [FRESHNESS]. 🌱

In the indirect approach, each cache consults the publisher of the cached NDO about its staleness before serving it. This approach assumes that the NDO includes the publisher information, which can be used to reach the publisher. It is suitable for the NDO whose expiration time is difficult to be set in advance, e.g., a web page that contains the main text (which stays the same ever after) and the interactive sections such as comments or ads (which are updated irregularly). 💬

It is often argued that ignoring stale NDOs in caches and simply providing new names for updated NDOs might be sufficient rather than using a staleness verification algorithm to manage them. However, notifying the new names of updated NDOs to users is not a trivial task. Unless the update is informed to all users at the same time, some users would use the old name although they intended to retrieve the updated NDO. 😭

One research challenge is how to design consistency and coherence models for caching NDOs along with their revision handling and updating protocols in a scalable manner. 🧠

4.7.5. Cache Sharing by Multiple Applications 🌈

When ICN is deployed as a general, application-independent network and cache infrastructure, multiple consumers and producers (representing different applications) would communicate over the same infrastructure. With universal naming schemes or sufficiently unique hash-based identifiers, different application could also share identical NDOs in a transparent way.

Depending on the naming, data integrity, and data origin authentication approaches, there may be technical and business challenges to share caches across different applications, for example, content protection, avoiding cache poisoning, ensuring performance isolation, etc. As ICN research matures, these challenges should be addressed more specifically in a dedicated document. 👑

4.8. Network Management 🎀

okay bestie, so managing networks has been a core craft in the IP-based host-centric paradigm ever since the tech hit production networks 💅 but ngl, at the start, management was basically an afterthought 🙈 Tools networkers use every single day, like ping and traceroute, didn't become widely available until more than a decade after IP showed up. SNMP came way later too, and lots of people still think it's not enough, even after years of running host-centric networks 💀 Today, when new networks get deployed, management is a key aspect for any operator. It's a major challenge, and if it's not done well, it shows up directly as higher operational cost 😭 So if we want ICN deployed in infrastructure networks, the management tools and mechanisms have to be developed right alongside the rest of the architecture design. No skipping ahead, periodt ✨

Now, an FCAPS model (Fault, Configuration, Accounting, Performance, and Security) [ISOIEC-7498-4] for ICN is clearly out of scope for this document 🦋 But we still need basic tools early, while ICN is in the design and experimentation phases 🧚 These tools can evolve over time and help network operations centers (NOCs) define policies, check that those policies are actually used in practice, get notified early about failures, and figure out and fix configuration problems. Authentication, Authorization, and Accounting (AAA) and performance management, from a NOC perspective, also need to be considered 🌈 With the expectation of a huge number of nodes and unprecedented traffic volumes, automating tasks is the move, or even better, self-management mechanisms 👑 The main challenge is that every tool we have today is node-centric, end-to-end oriented, or assumes a packet-stream communication environment 😭 Rethinking reachability and operational availability, for example, could give us big insights into how information-centric networks get managed in the future. Iconic research energy 🔥

There are three aspects of network management to think about 🌸 First, any operator has to manage all the resources in the network. That can range from node connectivity to network bandwidth availability, in-network storage, and multi-access support 💖 In ICN, users will also bring significant resources into the network, like network coverage extension, storage, and processing capabilities ✨ Delay Tolerant Networking (DTN) characteristics should also be considered, to the degree that's possible (for example, content dissemination through data mules 🦋). Second, since nodes and links aren't at the center of an information-centric network, network management should capitalize on native ICN mechanisms 💅 For example, in-network storage and name resolution can be used for monitoring, while native publish/subscribe functionality can be used for triggering notifications 🫶 Finally, management is also at the core of network-controlling capabilities. It lets operating actions get mediated and decided, and it triggers and activates networking procedures in an optimized way 👑 For example, monitoring can be combined with different management actions in a coordinated way, so network operations flow in a concerted manner 🎀

But ngl, using intrinsic ICN mechanisms to support management is more than a simple mapping exercise 💀 It brings its own set of challenges, and it also opens up new possibilities for both ICN and "network management" as a concept 🌈 For instance, naming mechanisms are central to ICN operations, since they identify and reach content under different aspects (for example, hierarchically structured vs. "flattish" names) 🧚 That means ICN is decoupled from the host-centric aspects that traditional network management schemes rely on. So new questions come up that turn directly into challenges for network management capability 😭 Like: how do you address a node or a network segment in an ICN naming paradigm? How do you identify which node is connected "where"? How do you know the capabilities of a node, like whether it's a high- or low-powered machine-to-machine (M2M) node? And if there's a host-centric protocol running, can the management process leverage it too? 🙈

On the flip side, these same inherent ICN characteristics let us look at network management from a brand new perspective ✨ By centering operations around NDOs, we can imagine new management operations, like per-content management or access control, and analyzing performance per NDO instead of per link or node 🦋 Those considerations can also be used to manage the operational aspects of ICN mechanisms themselves. For example, [NDN-MGMT] reuses the inherent content-centric capabilities of CCN to manage optimal link connectivity for nodes, in concert with a network optimization process 💖 It's also important to see how these content-centric aspects can influence and impact management in other areas (for example, security and resilience), as shown in [CCN-ACCESS], where access control mechanisms are integrated into a prototype of the [PURSUIT] architecture 🔥

The core research challenges for ICN management include:

• Management and control of NDO reception at the requestor
• Coordination of management information exchange and control between ICN nodes and ICN network control points
• Identification of management and controlling actions and items through information naming
• Relationship between NDOs and host entities identification, i.e., how to identify a particular link, interface, or flow that needs to be managed

4.9. ICN Applications 💜

okay so ICN can be applied to lots of different application domains, and it's expected to give application developers benefits by offering a more suitable interface for them 🫶 (on top of the other ICN benefits we already talked about 🌸). [RFC7476] gives an overview of relevant application domains at large. This section talks about opportunities and challenges for selected application types ✨

4.9.1. Web Applications 🌐

Intuitively, the ICN request/response communication style seems like it maps directly onto web communication over HTTP 🦋 NDO names could be the equivalent of URIs on today's web, proprietary and transparent caching could be made obsolete by ICN in-network caching, and developers could use an ICN request/response API directly to build applications 💅

Research efforts such as [ICN2014-WEB-NDN] have analyzed real-world web applications and ways to implement them in ICN 🔥 The most significant insight is that REST-style (Representational State Transfer) web communication relies heavily on sending user/application context information in HTTP GET requests, and that would have to be mapped to matching ICN messages 😭 The challenge is figuring out exactly how to achieve that mapping. To some degree, it could be done by extending name formats, or by extending the message structure to include cookies and similar context information 🧚 The design decisions would need to account for overhead in routers (for example, if larger GET/Interest messages would have to be stored in corresponding tables on routers) 💀

Other challenges include returning different results based on requestor-specific processing when objects are immutable (and name-object bindings are too) in ICN 🌈 There's also the need for efficient bidirectional communication, which would require some mechanism to name and reach requestor applications 👑

4.9.2. Video Streaming and Download 🎬

One of ICN's prime application areas is video streaming and download, where accessing named data, object-level security, and in-network storage can fulfill the requirements for both video streaming and download 💖 Several prototype developments have shown the applicability and benefits of ICN to video [ICN2014-AHLGREN-VIDEO-DEMO] 🎀

[VIDEO-STREAMING] discusses the opportunities and challenges of implementing today's video services over ICN, like DASH-based (Dynamic Adaptive Streaming over HTTP) streaming and download 🦋 It considers performance requirements, the relationship to peer-to-peer live streaming, IPTV, and Digital Rights Management (DRM) ✨

Beyond just porting today's video apps from a host-centric paradigm to ICN, there are also promising opportunities to use ICN network services to redesign and significantly enhance video access and distribution [ICNRG-2015-01-WESTPHAL] 🔥 For example, ICN store and forward could be used for rate adaptation to get maximum throughput and optimal Quality of Experience (QoE) in scenarios with varying link properties, if capacity information is fed back to rate selection algorithms at senders 🧚 Other optimizations, like more aggressive prefetching, could be done in the network by leveraging visibility of chunk NDO names and NDO metadata 🌸 And multi-source rate adaptation combined with network coding could enable better QoE, for example, in multi-interface/access scenarios where multiple paths from client to upstream caches exist [RFC7476] 💅

4.9.3. Internet of Things 🌸

okay so the whole magic of ICN is name-based routing 🦋 you ask for an NDO by its name, and you don't have to care where it lives. bestie, that's so iconic. it's a perfect fit for IoT, because people can consume data coming from IoT devices without having to keep secure connections open to them 🫶 and the basic request/response style APIs make it way faster and simpler for developers to build IoT apps. no cap, it's giving easy mode 💅

the people working on this have already been busy. [ICN-FOR-IOT], [ICN-ARCH], and [ICN2014-NDNWILD] all dig into the requirements and challenges of ICN for IoT ✨

here's the tricky part 😭 lots of IoT apps rely on a PUSH model, where the publisher starts the data transmission. that's what makes real-time stuff possible, like emergency alarms and things like that 🚨 but ICN doesn't do PUSH natively, because its whole thing is receiver-driven data transmission. so the big question is how to support PUSH efficiently in ICN so developers get publish/subscribe-style APIs for IoT 🧚 one option is adding other types of identifiers, like a device identifier. another is stretching the current request/response style, which could pile on heavy overhead in ICN routers. yikes 💀

and it's not just that. the caching in the content storage of network forwarding entities is a whole vibe too 🍓 it simplifies ICN-based IoT app development, because the network can act on named content. generic names let you address content no matter what device or access technology sits underneath 🌈 and bandwidth use gets optimized since cached content is available. but ngl, these things come with their own drama:

• freshness: the info you get from a cache might not match the last value a sensor actually generated 🙈
• pushing to specific nodes: like when you want to control a device, you need individual addressing so the right node gets identified 🎯
• heterogeneous nodes: IoT devices vary a lot, so some of them might not be able to handle the content signing verification procedures at all 😬

---

5. Security Considerations ✨

okay this part is short, but it's important 🔐 this document does not impact the security of the Internet. 🌍 the security questions around ICN are discussed in Section 4.2, so go check that out if you want the full story 🦋💜

6. Informative References 📚✨

okay bestie, welcome to the reading list era 📚 these are the papers, drafts, and RFCs the document points to for extra info, so you can go deeper whenever you're obsessed enough to want more 🤓

• [ACCESS-CTL-DEL] Fotiou, N., Marias, G., and G. Polyzos, "Access control enforcement delegation for information-centric networking architectures", Proceedings of the second edition of the ICN workshop on Information-centric networking (ICN '12) Helsinki, Finland, DOI 10.1145/2342488.2342507, 2012.
• [BACKSCATTER] Waehlisch, M., Schmidt, TC., and M. Vahlenkamp, "Backscatter from the Data Plane - Threats to Stability and Security in Information-Centric Network Infrastructure", Computer Networks Vol 57, No. 16, pp. 3192-3206, DOI 10.1016/j.comnet.2013.07.009, November 2013.
• [BREADCRUMBS] Rosensweig, E. and J. Kurose, "Breadcrumbs: Efficient, Best-Effort Content Location in Cache Networks", In Proceedings of the IEEE INFOCOM 2009, DOI 10.1109/INFCOM.2009.5062201, April 2009.
• [CCN] Jacobson, V., Smetters, D., Thornton, J., Plass, M., Briggs, N., and R. Braynard, "Networking Named Content", CoNEXT 2009, DOI 10.1145/1658939.1658941, December 2009.
• [CCN-ACCESS] Fotiou, N., Marias, G., and G. Polyzos, "Access control enforcement delegation for information-centric networking architectures", In Proceedings of the second edition of the ICN workshop on Information-centric networking (ICN '12), ACM, New York, NY, USA, 85-90, DOI 10.1145/2342488.2342507, 2012.
• [CHAUM] Chaum, D. and E. van Heijst, "Group signatures", In Proceedings of EUROCRYPT, DOI 10.1007/3-540-46416-6_22, 1991.
• [COMPACT] Cowen, L., "Compact routing with minimum stretch", In Journal of Algorithms, vol. 38, pp. 170-183, DOI 10.1006/jagm.2000.1134, 2001.
• [CONTUG] Arianfar, S., Nikander, P., Eggert, L., Ott, J., and W. Wong, "ConTug: A Receiver-Driven Transport Protocol for Content-Centric Networks", Technical Report Aalto University Comnet, 2011.
• [DONA] Koponen, T., Ermolinskiy, A., Chawla, M., Kim, K., gon Chun, B., and S. Shenker, "A Data-Oriented (and Beyond) Network Architecture", In Proceedings of SIGCOMM 2007, DOI 10.1145/1282427.1282402, August 2007.
• [ENCRYPTION-AC] Kurihara, J., Uzun, E., and C. Wood, "An Encryption-Based Access Control Framework for Content-Centric Networking", IFIP Networking 2015, Toulouse, France, DOI 10.1109/IFIPNetworking.2015.7145300, September 2015.
• [FRESHNESS] Quevedo, J., Corujo, D., and R. Aguiar, "Consumer Driven Information Freshness Approach for Content Centric Networking", IEEE INFOCOM Workshop on Name-Oriented Mobility Toronto, Canada, DOI 10.1109/INFCOMW.2014.6849279, May 2014.
• [GREEDY] Papadopoulos, F., Krioukov, D., Boguna, M., and A. Vahdat, "Greedy forwarding in dynamic scale-free networks embedded in hyperbolic metric spaces", In Proceedings of the IEEE INFOCOM, San Diego, USA, DOI 10.1109/INFCOM.2010.5462131, 2010.
• [HRICP] Carofiglio, G., Gallo, M., and L. Muscariello, "Joint hop-by-hop and receiver-driven interest control protocol for content-centric networks", In Proceedings of ACM SIGCOMM ICN 2012, DOI 10.1145/2342488.2342497, 2012.
• [ICN-ARCH] Zhang, Y., Raychadhuri, D., Grieco, L., Baccelli, E., Burke, J., Ravindran, R., Ed., and G. Wang, "ICN based Architecture for IoT - Requirements and Challenges", Work in Progress, draft-zhang-iot-icn-challenges-02, August 2015.
• [ICN-FOR-IOT] Lindgren, A., Ben Abdesslem, F., Ahlgren, B., Schelen, O., and A. Malik, "Applicability and Tradeoffs of Information-Centric Networking for Efficient IoT", Work in Progress, draft-lindgren-icnrg-efficientiot-03, July 2015.
• [ICN2014-AHLGREN-VIDEO-DEMO] Ahlgren, B., Jonasson, A., and B. Ohlman, "Demo Overview: HTTP Live Streaming over NetInf Transport", ACM SIGCOMM Information-Centric Networking Conference Paris, France, DOI 10.1145/2660129.2660136, September 2014.
• [ICN2014-NDNWILD] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. Waehlisch, "Information Centric Networking in the IoT: Experiments with NDN in the Wild", ACM SIGCOMM Information-Centric Networking Conference Paris, France, DOI 10.1145/2660129.2660144, September 2014.
• [ICN2014-WEB-NDN] Moiseenko, I., Stapp, M., and D. Oran, "Communication Patterns for Web Interaction in Named Data Networking", ACM SIGCOMM Information-Centric Networking Conference Paris, France, DOI 10.1145/2660129.2660152, September 2014.
• [ICNNAMING] Ghodsi, A., Koponen, T., Rajahalme, J., Sarolahti, P., and S. Shenker, "Naming in Content-Oriented Architectures", In Proceedings ACM SIGCOMM Workshop on Information-Centric Networking (ICN), DOI 10.1145/2018584.2018586, 2011.
• [ICNRG-2015-01-WESTPHAL] Westphal, C., "Video over ICN", IRTF ICNRG Meeting Cambridge, Massachusetts, USA, January 2015, http://www.ietf.org/proceedings/interim/2015/01/13/icnrg/slides/slides-interim-2015-icnrg-1-0.pptx.
• [ICNSURVEY] Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D., and B. Ohlman, "A Survey of Information-Centric Networking", In Communications Magazine, IEEE, vol. 50, no. 7, pp. 26-36, DOI 10.1109/MCOM.2012.6231276, 2012.
• [ISOIEC-7498-4] ISO, "Information Processing Systems -- Open Systems Interconnection -- Basic Reference Model -- Part 4: Management Framework", November 1989, http://standards.iso.org/ittf/PubliclyAvailableStandards/s014258_ISO_IEC_7498-4_1989(E).zip.
• [MANI] Pentikousis, K. and T. Rautio, "A multiaccess Network of Information", WoWMoM 2010 IEEE, DOI 10.1109/WOWMOM.2010.5534922, June 2010.
• [MDHT] D'Ambrosio, M., Dannewitz, C., Karl, H., and V. Vercellone, "MDHT: A hierarchical name resolution service for information-centric networks", ACM SIGCOMM workshop on Information-centric networking Toronto, Canada, DOI 10.1145/2018584.2018587, August 2011.
• [MMIN] Pentikousis, K. and P. Bertin, "Mobility management in infrastructure networks", Internet Computing, IEEE vol. 17, no. 5, pp. 74-79, DOI 10.1109/MIC.2013.98, October 2013.
• [NDN-CTL-SHARING] Yu, Y., "Controlled Sharing of Sensitive Content", IRTF ICNRG Meeting San Francisco, USA, October 2015, https://www.ietf.org/proceedings/interim/2015/10/03/icnrg/slides/slides-interim-2015-icnrg-4-8.pdf.
• [NDN-MGMT] Corujo, D., Aguiar, R., Vidal, I., and J. Garcia-Reinoso, "A named data networking flexible framework for management communications", Communications Magazine, IEEE vol. 50, no. 12, pp. 36-43, DOI 10.1109/MCOM.2012.6384449, December 2012.
• [PURSUIT] Fotiou et al., N., "Developing Information Networking Further: From PSIRP to PURSUIT", In Proceedings of Proc. BROADNETS. ICST, DOI 10.1007/978-3-642-30376-0_1, 2010.
• [RANDOM] Gkantsidis, C., Mihail, M., and A. Saberi, "Random walks in peer-to-peer networks: algorithms and evaluation", In Perform. Eval., vol. 63, pp. 241-263, DOI 10.1016/j.peva.2005.01.002, 2006.
• [RESOURCE-POOL] Psaras, I., Saino, L., and G. Pavlou, "Revisiting Resource Pooling: The case of In-Network Resource Sharing", ACM HotNets Los Angeles, USA, DOI 10.1145/2670518.2673875, October 2014.
• [RFC2002] Perkins, C., Ed., "IP Mobility Support", RFC 2002, DOI 10.17487/RFC2002, October 1996, http://www.rfc-editor.org/info/rfc2002.
• [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, April 2007, http://www.rfc-editor.org/info/rfc4838.
• [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, http://www.rfc-editor.org/info/rfc5246.
• [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, http://www.rfc-editor.org/info/rfc5280.
• [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, DOI 10.17487/RFC5944, November 2010, http://www.rfc-editor.org/info/rfc5944.
• [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, http://www.rfc-editor.org/info/rfc6920.
• [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., Tyson, G., Davies, E., Molinaro, A., and S. Eum, "Information-Centric Networking: Baseline Scenarios", RFC 7476, DOI 10.17487/RFC7476, March 2015, http://www.rfc-editor.org/info/rfc7476.
• [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, http://www.rfc-editor.org/info/rfc7696.
• [SEEN] Pentikousis, K., "In search of energy-efficient mobile networking", Communications Magazine, IEEE vol. 48 no. 1, pp. 95-103, DOI 10.1109/MCOM.2010.5394036, January 2010.
• [VIDEO-STREAMING] Westphal, C., Ed., Lederer, S., Posch, D., Timmerer, C., Azgin, A., Liu, S., Mueller, C., Detti, A., Corujo, D., Wang, J., Montpetit, M., Murray, N., Azgin, A., and S. Liu, "Adaptive Video Streaming over ICN", Work in Progress, draft-irtf-icnrg-videostreaming-08, April 2016.

---

Acknowledgments 🫶

the authors wanna give a big shoutout to Georgios Karagiannis 💖 for the suggestions on QoS research challenges, Dimitri Papadimitriou 🌸 for the feedback on the routing section, and Joerg Ott and Stephen Farrell 👑 for reviewing the whole document. literally the dream team 😭✨

Authors' Addresses ✨

okay bestie, these are the humans behind the whole thing 🫶 Every one of them is a legit networking legend, so here are their contact details exactly as they were written 💅

Dirk Kutscher (editor) is the one who kept the whole doc together 👑

Dirk Kutscher (editor)
NEC
Kurfuersten-Anlage 36
Heidelberg
Germany

Email: kutscher@neclab.eu

Suyong Eum 🦋

Suyong Eum
Osaka University, School of Information Science and Technology
1-5 Yamadaoka, Suita
Osaka  565-0871
Japan

Phone: +81-6-6879-4571
Email: suyong@ist.osaka-u.ac.jp

Kostas Pentikousis 🌸

Kostas Pentikousis
Travelping
Koernerstr. 7-10
Berlin  10785
Germany

Email: k.pentikousis@travelping.com

Ioannis Psaras 🧚

Ioannis Psaras
University College London, Dept. of E.E.  Eng.
Torrington Place
London  WC1E 7JE
United Kingdom

Email: i.psaras@ucl.ac.uk

Daniel Corujo 🍓

Daniel Corujo
Universidade de Aveiro
Instituto de Telecomunicacoes, Campus Universitario de Santiago
Aveiro  P-3810-193
Portugal

Email: dcorujo@av.it.pt

Damien Saucez ⭐

Damien Saucez
INRIA
2004 route des Lucioles - BP 93
Sophia Antipolis  06902 Cedex
France

Email: damien.saucez@inria.fr

Thomas C. Schmidt 💜

Thomas C. Schmidt
HAW Hamburg
Berliner Tor 7
Hamburg  20099
Germany

Email: t.schmidt@haw-hamburg.de

Matthias Waehlisch 🌈

Matthias Waehlisch
FU Berlin
Takustr. 9
Berlin  14195
Germany

Email: waehlisch@ieee.org

---

ngl this whole team is iconic, and that's the end of the RFC 🎀✨