RFC 8763
Deployment Considerations for Information-Centric Networking (ICN)
Deployment Considerations for Information-Centric Networking (ICN) 🦋
Okay bestie, here's the header tea ☕💖
- RFC number: 8763
- Stream: Internet Research Task Force (IRTF) 🌈
- Category: Informational
- ISSN: 2070-1721
- Date: April 2020
- Authors: A. Rahman (InterDigital Communications, LLC), D. Trossen (Huawei), D. Kutscher (Emden University), and R. Ravindran (Sterlite Technologies) 👑
- Obsoletes / Updates: the header doesn't list anything here, so this RFC doesn't replace or update any earlier RFC 🙈
Abstract ✨
Information-Centric Networking (ICN) is finally reaching technological maturity after years of fundamental research and experimentation 🔥. This document gives a bunch of deployment considerations so the ICN community can take the next step toward live deployments 🚀. It starts by describing the major deployment configurations for ICN, including the key overlay and underlay approaches 🧩. Then it outlines proposed deployment migration paths for major practical issues, like network and application migration 🦋. After that, it sums up some selected ICN trial experiences 🌸. Last but not least, it identifies the protocol areas that need further standardization so future ICN deployments can be interoperable 💜. This document is a product of the Information-Centric Networking Research Group (ICNRG) 🫶.
Status of This Memo 📜
This document is not an Internet Standards Track specification. It's published for informational purposes, so no pressure 💅.
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities, and those results might not be suitable for deployment, so keep that in mind 🙈. This RFC represents the consensus of the Information-Centric Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard. See Section 2 of RFC 7841 for the details 📖.
Info about the current status of this document, any errata, and how to give feedback on it can be found at https://www.rfc-editor.org/info/rfc8763 🔗.
Copyright Notice ©️
Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document ⚖️.
Table of Contents 🗺️
1. Introduction
2. Terminology
3. Abbreviations List
4. Deployment Configurations
4.1. Clean-Slate ICN
4.2. ICN-as-an-Overlay
4.3. ICN-as-an-Underlay
4.3.1. Edge Network
4.3.2. Core Network
4.4. ICN-as-a-Slice
4.5. Composite-ICN Approach
5. Deployment Migration Paths
5.1. Application and Service Migration
5.2. Content Delivery Network Migration
5.3. Edge Network Migration
5.4. Core Network Migration
6. Deployment Trial Experiences
6.1. ICN-as-an-Overlay
6.1.1. FP7 PURSUIT Efforts
6.1.2. FP7 SAIL Trial
6.1.3. NDN Testbed
6.1.4. ICN2020 Efforts
6.1.5. UMOBILE Efforts
6.2. ICN-as-an-Underlay
6.2.1. H2020 POINT and RIFE Efforts
6.2.2. H2020 FLAME Efforts
6.2.3. CableLabs Content Delivery System
6.2.4. NDN IoT Trials
6.2.5. NREN ICN Testbed
6.2.6. DOCTOR Testbed
6.3. Composite-ICN Approach
6.4. Summary of Deployment Trials
7. Deployment Issues Requiring Further Standardization
7.1. Protocols for Application and Service Migration
7.2. Protocols for Content Delivery Network Migration
7.3. Protocols for Edge and Core Network Migration
7.4. Summary of ICN Protocol Gaps and Potential Protocol Efforts
8. Conclusion
9. IANA Considerations
10. Security Considerations
11. Informative References
Acknowledgments
Authors' Addresses1. Introduction 🎀
The ICNRG charter lists deployment guidelines as an important topic area for the ICN community 💅. To be specific, the charter says that defining concrete migration paths for ICN deployments that avoid forklift upgrades, and defining practical ICN interworking configurations with the existing Internet paradigm, are key topic areas that need further investigation [ICNRGCharter]. It's also well understood that results and conclusions from any mid- to large-scale ICN experiments on the live Internet will give useful guidance for deployments too 🙌.
Honestly, outside of some preliminary investigations, like [ICN-DEP-CON], there hasn't been a whole lot of progress on this topic 😭. So this document is trying to fill some of those gaps. It defines clear deployment configurations for ICN and the migration pathways for those configurations 🧚. It also sums up selected deployment trial experiences of ICN technology. And it makes recommendations for potential future IETF standardization of key protocol functionality that will make interoperable ICN deployments easier going forward ✨.
The major configurations for possible ICN deployments are identified in this document as: (1) Clean-slate ICN replacement of existing Internet infrastructure, (2) ICN-as-an-Overlay, (3) ICN-as-an-Underlay, (4) ICN-as-a-Slice, and (5) Composite-ICN 🌈. Existing ICN trial systems mostly fall under the ICN-as-an-Overlay, ICN-as-an-Underlay, and Composite-ICN configurations. Each of these deployment configurations has its own strengths and weaknesses 💜. This document aims to give guidance to current and future members of the ICN community when they're thinking about deploying ICN technologies 🫶.
This document represents the consensus of the Information-Centric Networking Research Group (ICNRG). It was reviewed extensively by the Research Group (RG) members who are active in the specific areas of work covered by the document 👑.
2. Terminology 💅
This document assumes readers are, in general, familiar with the terms and concepts defined in [RFC7927] and [ICN-TERM]. On top of that, this document defines the following terminology 📚:
Deployment: The final stage of the process of setting up an ICN network that is (1) ready for useful work (e.g., transmission of end-user video and text) in a live environment, and (2) integrated and interoperable with the Internet 🌸. We consider the Internet in its widest sense, where it covers various access networks (e.g., Wi-Fi or mobile radio networks), service edge networks (e.g., for edge computing), transport networks, Content Distribution Networks (CDNs), core networks (e.g., mobile core networks), and back-end processing networks (e.g., data centers). However, throughout this document the discussion is usually limited to edge networks, core networks, and CDNs, just to keep things simple 🙈.
Information-Centric Networking (ICN): A data-centric network architecture where accessing data by name is the essential network primitive. See [ICN-TERM] for further information 🦋.
Network Functions Virtualization (NFV): A networking approach where network functions (e.g., firewalls or load balancers) are modularized as software logic that can run on general purpose hardware. That means they're specifically decoupled from the previous generation of proprietary and dedicated hardware 🧩. See [RFC8568] for further information.
Software-Defined Networking (SDN): A networking approach where the control and data planes for switches are separated. That allows for things like traffic isolation and programmable forwarding actions 🍓. See [RFC7426] for further information.
3. Abbreviations List 🧚
API: Application Programming Interface
BIER: Bit Index Explicit Replication
BoF: Birds of a Feather (session)
CCNx: Content-Centric Networking
CDN: Content Distribution Network
CoAP: Constrained Application Protocol
DASH: Dynamic Adaptive Streaming over HTTP
Diffserv: Differentiated Services
DoS: Denial of Service
DTN: Delay-Tolerant Networking
ETSI: European Telecommunications Standards Institute
EU: European Union
FP7: 7th Framework Programme for Research and Technological
Development
HLS: HTTP Live Streaming
HTTP: HyperText Transfer Protocol
HTTPS: HyperText Transfer Protocol Secure
H2020: Horizon 2020 (research program)
ICN: Information-Centric Networking
ICNRG: Information-Centric Networking Research Group
IETF: Internet Engineering Task Force
IntServ: Integrated Services
IoT: Internet of Things
IP: Internet Protocol
IPv4: Internet Protocol Version 4
IPv6: Internet Protocol Version 6
IPTV: Internet Protocol Television
IS-IS: Intermediate System to Intermediate System
ISP: Internet Service Provider
k: kilo (1000)
L2: Layer 2
LTE: Long Term Evolution (or 4th generation cellular system)
MANO: Management and Orchestration
MEC: Multi-access Edge Computing
Mbps: Megabits per second
M2M: Machine-to-Machine
NAP: Network Attachment Point
NDN: Named Data Networking
NETCONF: Network Configuration Protocol
NetInf: Network of Information
NFD: Named Data Networking Forwarding Daemon
NFV: Network Functions Virtualization
NICT: Japan's National Institute of Information and
Communications Technology
NR: New Radio (access network for 5G)
OAM: Operations, Administration, and Maintenance
ONAP: Open Network Automation Platform
OSPF: Open Shortest Path First
PoC: Proof of Concept (demo)
POINT: IP Over ICN - the better IP (project)
qMp: Quick Mesh Project
QoS: Quality of Service
RAM: Random Access Memory
RAN: Radio Access Network
REST: Representational State Transfer (architecture)
RESTCONF: Representational State Transfer Configuration (protocol)
RIFE: Architecture for an Internet For Everybody (project)
RIP: Routing Information Protocol
ROM: Read-Only Memory
RSVP: Resource Reservation Protocol
RTP: Real-time Transport Protocol
SDN: Software-Defined Networking
SFC: Service Function Chaining
SLA: Service Level Agreement
TCL: Transport Convergence Layer
TCP: Transmission Control Protocol
UDP: User Datagram Protocol
UMOBILE: Universal Mobile-centric and Opportunistic
Communications Architecture
US: United States
USA: United States of America
VoD: Video on Demand
VPN: Virtual Private Network
WG: Working Group
YANG: Yet Another Next Generation (data modeling language)
5G: Fifth Generation (cellular network)
6LoWPAN: IPv6 over Low-Power Wireless Personal Area Networks4. Deployment Configurations ✨
okay so, this section is where we look at different ways ICN can actually get deployed 🌸 These are presented as "configurations" so you can study each option more closely. Heads up that the doc walks through some experiences with a few of these in Section 6, but we are not doing a deep technical or commercial evaluation of any of them. For that, go check out existing literature, like [Tateson] 📚
4.1. Clean-Slate ICN
ICN is often described as a "clean-slate" approach, where the goal is to renew or replace the whole IP infrastructure of the Internet 🔥 So existing routing hardware and support services, like applications that are usually tied directly to the TCP/IP stack, are not taken for granted. Like, at all. In a Clean-slate ICN deployment, existing IP routers would be swapped out for ICN-specific forwarding and routing elements, such as NFD [NFD], CCNx routers [Jacobson], or Publish-Subscribe Internet Technology (PURSUIT) forwarding nodes [IEEE_Communications]. Bold move, ngl 💅
Now, clean-slate replacement could look like it's only for ICN deployments, but some ICN approaches (e.g., [POINT]) also depend on general infrastructure upgrades. In this case, that means SDN switches 🦋 Different proposals have been made for various ICN approaches to run over an SDN transport [Reed] [CONET] [C_FLOW]. It's giving teamwork 🫶
4.2. ICN-as-an-Overlay
Similar to other big changes to the Internet routing fabric, like the move from IPv4 to IPv6 or the introduction of IP multicast, this deployment configuration imagines building an ICN overlay 🧚 Quick note: this overlay approach is sometimes, informally, called a tunneling approach too. The overlay can be implemented directly (e.g., ICN-over-UDP), as described in [CCNx_UDP]. Or the overlay can be done with ICN-in-L2-in-IP, as in [IEEE_Communications], which describes a recursive layering process 🌈 Another approach, used in the Network of Information (NetInf), is to define a convergence layer that maps NetInf semantics to HTTP [NetInf]. Last but not least, [Overlay_ICN] describes an incremental way to deploy an ICN architecture that is especially well suited to SDN-based networks, and it does this by also separating ICN user-plane and control-plane traffic 👑
But, and this is important bestie, regardless of the flavor, the overlay approach results in islands of ICN deployments sitting on top of existing IP-based infrastructure 🙈 These ICN islands are typically connected to each other through ICN/IP tunnels. In certain scenarios, this means you need interoperability between existing IP routing protocols (e.g., OSPF, RIP, or IS-IS) and ICN-based ones. ICN-as-an-Overlay can be deployed over the IP infrastructure in either edge or core networks. Honestly, this is why it's so attractive for ICN experimentation and testing, since it allows rapid and easy deployment of ICN over existing IP networks 💖
4.3. ICN-as-an-Underlay
Proposals like [POINT] and [White] lay out the deployment option of using an ICN underlay. The underlay would integrate with existing (external) IP-based networks by putting application-layer gateways in appropriate locations ✨ The main reason for this configuration is bringing ICN technology into given islands (e.g., inside a CDN or an edge IoT network) so you can get the benefits of native ICN. Those benefits include underlying multicast delivery, mobility support, fast indirection thanks to location independence, in-network computing, and possibly more 🎀 So the underlay approach results in islands of native ICN deployments that are connected to the rest of the Internet through protocol conversion gateways or proxies. The routing domains are strictly separated. Outside the ICN island, normal IP routing protocols apply. Inside the ICN island, ICN-based routing schemes apply. The gateways transfer the semantic content of the messages (i.e., IP packet payload) between the two routing domains 🦋
4.3.1. Edge Network
Native ICN networks may be located at the edge of the network, where introducing new network architectures and protocols is easier, in what are called greenfield deployments 🌱 In this context, ICN is an attractive option for scenarios such as IoT [ICN-IoT]. The integration with the current IP protocol suite happens at an application gateway/proxy at the edge network boundary. For example, it could translate incoming CoAP request/response transactions [RFC7252] into ICN message exchanges, or the other way around 💜
The work in [VSER] positions ICN as an edge service gateway. It's driven by a generalized ICN-based service orchestration system that has its own compute and network virtualization controllers to manage an ICN infrastructure 🧚 The platform also offers service discovery, so user applications can find the right ICN service gateways. As an example use case, the [VSER] platform shows a multi-party audio/video conferencing service running over this kind of edge cloud deployment of ICN routers, which are built on commodity hardware platforms 🎀 The platform has also been extended to offer seamless mobility as a service, which [VSER-Mob] covers. Iconic 😭
4.3.2. Core Network
In this suboption, a core network would use edge-based protocol mapping onto the native ICN underlay 🍓 For instance, [POINT] proposes mapping HTTP transactions, or some other IP-based transactions such as CoAP, directly onto an ICN-based message exchange. This mapping happens at the NAP, for example in access points or customer premise equipment. That gear then provides a standard IP interface to existing user devices. So the NAP gives the apparent perception of an IP-based core network toward any external peering network 🌸
The work in [White] proposes a similar deployment configuration. Here the goal is to use ICN for content distribution within CDN server farms 💅 Specifically, the protocol mapping happens at the ingress of the server farm, where the HTTP-based retrieval request is served. The response is then delivered through a suitable egress node translation 🫶
4.4. ICN-as-a-Slice
The objective of network slicing [NGMN-5G] is to multiplex a general pool of compute, storage, and bandwidth resources among multiple service networks. Each of those networks has exclusive SLA requirements on transport and compute-level QoS and security 🔥 This is enabled through NFV and SDN technology functions, which allow functional decomposition (and so modularity, independent scalability of control and/or user-plane functions), agility, and service-driven programmability. Network slicing is often associated with 5G, but it is clearly not limited to such systems 💖 From a 5G perspective, though, the definition of slicing includes access networks that dynamically slice spectrum resources among various services. That naturally extends to end points and cloud resources across multiple domains, so you can get end-to-end guarantees ✨ Once instantiated, these slices could include a mix of connectivity services (e.g., LTE-as-a-service), Over-the-Top (OTT) services (e.g., VoD), or other IoT services. They're composed from a group of virtual and/or physical network functions at the control, user, and service-plane levels 🌈 Such a framework can also be used to realize ICN slices with their own control and forwarding plane, over which one or more end-user services can be delivered [NGMN-Network-Slicing]. Ate that 💅
The 5G next generation architecture [fiveG-23501] lets you deploy ICN-as-a-Slice over either the edge (RAN) or the mobile core network. Otherwise, ICN-as-a-Slice may be deployed end to end 🦋 Further discussion on extending the architecture presented in [fiveG-23501], and the corresponding procedures in [fiveG-23502] to support ICN, is provided in [ICN-5GC]. That document covers two possible approaches to enable ICN 🧚
- As an edge service, using the local data network (LDN) feature in 5G. It uses User Plane Function (UPF) classification functions to fast handover to the ICN forwarder.
- As a native deployment, using the non-IP Protocol Data Unit (PDU) support. This allows new network layer PDUs to be handed over to ICN UPFs collocated with the Generation NodeB (gNB) functions, without invoking any IP functions.
The first deployment would still rely on 3GPP-based mobility functions. The second one would let ICN handle mobility natively 💜 Either way, both deployment modes should benefit from other ICN features, like in-network caching and computing. Tied to this ICN user-plane enablement, control-plane extensions are also proposed. They use the 5th Generation Core Network (5GC)'s interface to other application functions (AFs) to allow new network service-level programmability 👑 Such a generalized network slicing framework should be able to offer service slices over both IP and ICN. Coupled with the view of ICN functions as "service function chaining" [RFC7665], an ICN deployment within such a slice could also be realized within the emerging control plane that is targeted for adoption in future (e.g., 5G mobile) network deployments 🌸 Finally, it's worth noting that ICN isn't creating the network slice. Instead, the slice is created to run a 5G-ICN instance [Ravindran]. Plot twist 🙈
When it comes to the specific technologies involved, like ONAP [ONAP] (which can be used to orchestrate slices), the 5G-ICN slice needs compatibility at the level of the forwarding/data plane. What that looks like depends on whether it's realized as an overlay or using programmable data planes 🎀 With SDN emerging for new network deployments, some ICN approaches will need to integrate as a data-plane forwarding function with SDN, as briefly discussed in Section 4.1. Further cross-domain ICN slices can also be realized using frameworks such as [ONAP] 🦋
4.5. Composite-ICN Approach
Some deployments don't clearly match any of the basic configurations we defined earlier: (1) Clean-slate ICN, (2) ICN-as-an-Overlay, (3) ICN-as-an-Underlay, and (4) ICN-as-a-Slice. Or, a deployment might be a composite mix of properties from these basic configurations 🌈 For example, the Hybrid ICN [H-ICN_1] approach carries ICN names in existing IPv6 headers. It doesn't have distinct gateways or tunnels connecting ICN islands, or any other distinct feature from the basic configurations above. So we categorize Hybrid ICN, and other approaches that don't clearly match one of the basic configurations, as a Composite-ICN approach 💖
5. Deployment Migration Paths 🛤️
Now we get to the fun part: the migration paths that matter to the different stakeholders who usually get involved in deploying ICN networks 💅 We can identify these stakeholders as:
- application providers
- ISPs and service providers, both as core and access network providers, as well as ICN network providers
- CDN providers (due to the strong relation of the ICN proposition to content delivery)
- end-device manufacturers and users
Our focus is on the technological side of migration 🫶 Economic or regulatory aspects, like those studied in [Tateson], [Techno_Economic], and [Internet_Pricing], are left out of our discussion.
5.1. Application and Service Migration
okay so the Internet runs a MULTITUDE of apps and services on top of the packet-level IP service 🌸 HTTP is kinda the big convergence point, because so many web development frameworks are built on its semantics 💅 and in recent years even video delivery has been moving away from the classic RTP-over-UDP setup and over to HTTP-level streaming, like DASH [DASH] and friends 🎀 but ngl, plenty of non-HTTP services are still out there, and they all need a look when you're moving from the IP-based Internet to an ICN-based one 🫶
the underlay deployment configuration in Section 4.3 is giving compatibility with the existing ecosystem through a proxy-based message flow mapping mechanism 🦋 for example, mapping existing HTTP/TCP/IP message flows onto HTTP/ICN message flows. a related approach, mapping TCP/IP onto TCP/ICN message flows, is covered in [Moiseenko] ✨ then there's [Marchal], which uses HTTP/NDN gateways and is obsessed with the right strategy for mapping HTTP to NDN, so you keep a high level of HTTP compatibility while still getting efficient caching of data in the ICN island 🧚 the choice between these is a design decision about how you configure the protocol stack. like, the [Moiseenko] approach carries the TCP layer into the ICN underlay, while the [Marchal] approach terminates both HTTP and TCP at the edge of the ICN underlay and maps those functions onto existing ICN functionalities 💜
alternatively, ICN-as-an-Overlay (Section 4.2) and ICN-as-a-Slice (Section 4.4) let you bring in the FULL capabilities of ICN, through new application/service interfaces and operations inside the network 🔥 so these deployment approaches will probably aim at new apps and services that actually lean into those ICN capabilities, like in-network multicast and/or caching. main character energy 👑
finally, [ICN-LTE-4G] outlines a dual-stack end-user device approach that works for ALL deployment configurations 🌈 it adds middleware layers (called the TCL) on the device that dynamically adapt existing applications to either an underlying ICN protocol stack or a standard IP protocol stack. this involves the end device signaling with the network to figure out which protocol stack instance, and which associated middleware adaptation layers, to use for a given application transaction 🧚✨
5.2. Content Delivery Network Migration
a LOT of services and apps are devoted to content delivery in some form, like video delivery, social media platforms, and loads more 📺 CDNs exist to help these services by localizing content requests, which cuts latency and can possibly boost utilization of available bandwidth, and it also takes load off origin servers 💖 same vibe as the last subsection: the underlay deployment configuration in Section 4.3 is aiming to give existing CDNs a migration path 🌸 a BIER use-case document [BIER] highlights this too, with potential benefits from using multicast to deliver content, plus less load on origin and delegation servers 🙈 we come back to this benefit in the trial experiences in Section 6 🎀
5.3. Edge Network Migration
edge networks are often where novel network-level tech shows up, like in the IoT space 🌈 for years, IoT deployments have relied (and often still do) on proprietary protocols, for reasons like increased efficiency, a lack of standardization incentives, and others 💅 using the underlay deployment configuration in Section 4.3.1, application gateways/proxies can plug those edge deployments into IP-based services. for instance, they can use CoAP-based [RFC7252] M2M platforms like oneM2M [oneM2M] or others 🦋
another hot area of edge innovation is mobile (access) networks, especially in the context of 5G mobile networks 📱 network softwarization (using tech like service orchestration frameworks that leverage NFV and SDN concepts) is now common in access networks and other network segments. so the ICN-as-a-Slice deployment configuration in Section 4.4 is a solid migration path for bringing non-IP-based edge networks into the overall system, by realizing the relevant (ICN) protocols in an access network slice ✨
with the rise of SDN and NFV, so-called campus or site-specific deployments could start introducing ICN islands at the edge 🎮 think scenarios like gaming, or deployments based on Augmented Reality (AR) / Virtual Reality (VR), like smart cities or theme parks 🎢 literally so fun to picture
5.4. Core Network Migration
migrating core networks, whether Internet or mobile, takes way more than significant infrastructure renewal 😭 you also have to hit the key performance requirements, especially around throughput 💀 for the parts of the core network that would migrate to an SDN-based optical transport, the ICN-as-a-Slice deployment configuration in Section 4.4 would let you introduce native ICN solutions within slices 🔥 this isolates the ICN traffic while still getting the specific ICN performance benefits (like in-network multicast or caching), and it also deals with the specific constraints (like needing certain network elements within those isolated slices) 🫶
for ICN solutions that natively work on top of SDN, the underlay deployment configuration in Section 4.3.2 gives an extra migration path 🦋 it keeps the IP-based services and applications at the edge of the network, while the core network routing gets realized through an ICN solution (possibly itself realized in a slice of the SDN transport network) ✨
6. Deployment Trial Experiences 🧪
okay now the fun part, the trial experiences 🎀 this section outlines trials, often run inside collaborative project efforts. the focus is on how the various deployment configurations from Section 4 actually got realized, so we sort the trial experiences by those configurations 💜 there's a big pile of simulation and emulation work out there too, but we're deliberately leaving those studies out of our analysis so we stay focused on real-life experiences 🌸
6.1. ICN-as-an-Overlay
6.1.1. FP7 PURSUIT Efforts
the FP7 PURSUIT [IEEE_Communications] efforts were generally positioned as a Clean-slate ICN replacement of IP (Section 4.1), but the project actually ran its experimental testbed as an L2 VPN-based overlay between several European, US, and Asian sites 🌍 that followed the overlay deployment configuration in Section 4.2 ✨ software-based forwarders handled the ICN message exchange, and native ICN applications (like video transmissions) got showcased 🎬 at the height of the project, about 70+ nodes were active in the (overlay) network, with presentations at several conferences and to the ICNRG 👑 slay
6.1.2. FP7 SAIL Trial
the Network of Information (NetInf) is the approach to ICN developed by the EU FP7 Scalable and Adaptive Internet Solutions (SAIL) project [SAIL] 🧚 NetInf gives you name-based forwarding with CCNx-like semantics AND name resolution (for indirection and late binding) 💖 the NetInf architecture supports different deployment options through its convergence layer, like using UDP, HTTP, and even DTN underlays 🦋 in its first prototypes and trials, NetInf was deployed mostly as an HTTP embedding and as a UDP overlay following the overlay deployment configuration in Section 4.2 🌈 [SAIL_Prototyping] describes several trials, including a stadium environment and a multi-site testbed, which leveraged NetInf's routing hint approach for routing scalability [SAIL_Content_Delivery] 🏟️ iconic
6.1.3. NDN Testbed
Named Data Networking (NDN) is one of the research projects of the National Science Foundation (NSF) of the USA, as part of the Future Internet Architecture (FIA) Program 🇺🇸 the original NDN proposal was positioned as a Clean-slate ICN replacement of IP (Section 4.1) 🙈 BUT in several trials, NDN generally follows the overlay deployment configuration of Section 4.2 to connect institutions over the public Internet across several continents 🌏 the use cases covered in the trials include real-time videoconferencing, geolocating, and interfacing to consumer applications 📹 typical trials involve up to 100 NDN-enabled nodes [NDN-testbed] [Jangam] 💅
6.1.4. ICN2020 Efforts
ICN2020 is an ICN-related project of the EU H2020 research program and NICT [ICN2020-overview] 🌸 it has a specific focus on advancing ICN toward real-world deployments through applications like video delivery, interactive videos, and social networks 🎥 the federated testbed spans the USA, Europe, and Japan 🗾 both NDN and CCNx approaches are in scope for the project 🫶
ICN2020 has released a set of interim public technical reports 📄 the report [ICN2020-Experiments] has a detailed description of the progress made in both local testbeds and federated testbeds 🔬 the plan for the federated testbed includes integrating the NDN testbed, the CUTEi testbed [RFC7945] [CUTEi], and the GEANT testbed [GEANT] to create an overlay deployment configuration of Section 4.2 over the public Internet 🌐 the total network contains 37 nodes, and since video was an important application, typical throughput was measured in certain scenarios and found to be in the order of 70 Mbps per node 🚀 absolutely iconic numbers 🌈
6.1.5. UMOBILE Efforts 🚌✨
okay so UMOBILE is another ICN research project under the H2020 research program 📚 [UMOBILE-overview]. The big idea is that it mashes DTN and ICN together in one framework so it can support edge computing and mobile opportunistic wireless environments (think post-disaster scenarios and remote areas) 🌍. The UMOBILE architecture [UMOBILE-2] was built on top of the NDN framework, following the overlay deployment configuration from Section 4.2. Its whole goal is to extend Internet functionality by combining ICN and DTN tech 🦋
One of the key aspects was extending NDN so network services (like mobility management and intermittent connectivity support) and user services (like pervasive content management) live as close to the end users as possible 💖. That helps optimize bandwidth utilization and resource management, and it's giving efficiency 💅. Another aspect was evolving NDN so it can actually work in challenging wireless networks, especially in emergency scenarios [UMOBILE-3] and in environments with intermittent connectivity 🚨. To make that happen, NDN got a new messaging app called Oi! [UMOBILE-4] [UMOBILE-5] that supports intermittent wireless networking 📱
UMOBILE also has a brand-new data-centric wireless routing protocol, DABBER [UMOBILE-6] [DABBER] 🧠. It was designed around data reachability metrics that take into account how available the adjacent wireless nodes are and what different data sources exist 🔍. The contextual awareness of the wireless network is powered by a machine-learning agent running inside the wireless nodes [UMOBILE-7] 🤖✨ literally so smart.
The consortium has finished several ICN deployment trials 🎉. In a post-disaster scenario trial [UMOBILE-8], they created a special DTN face to reach remote areas with no typical Internet connection 🆘. Another trial was the ICN deployment over the "Guifi.net" community network in the Barcelona region 🌸. This one focused on evaluating an ICN edge computing platform called PiCasso [UMOBILE-9]. Ten (10) Raspberry Pis were deployed across Barcelona to create an ICN overlay network on top of the existing IP routing protocol (for example, qMp routing) 🍓. The trial showed that ICN can play a key role in improving data delivery QoS and cutting down traffic in intermittent connectivity environments, like wireless community networks 🙌. A third trial in Italy showed how the UMOBILE architecture can reach disconnected areas and help responsible authorities in emergencies, in an infrastructure scenario 🚑. The demo included seven (7) end-user devices, one (1) access point, and one (1) gateway 🎀
6.2. ICN-as-an-Underlay 🌊
6.2.1. H2020 POINT and RIFE Efforts 🛰️
POINT and RIFE are two more ICN-related research projects in the H2020 research program 💜. The POINT and RIFE efforts follow the underlay deployment configuration in Section 4.3.2. Edge-based NAPs handle the IP/HTTP-level protocol mapping onto ICN protocol exchanges, while the SDN underlay (or the VPN-based L2 underlay) is used as the transport network 🧚
The multicast and service endpoint surrogate benefit shows up in HTTP-based scenarios, like HTTP-level streaming video delivery 🎬. It was demonstrated in the deployed POINT testbed, where 80+ nodes were in use 🔥. The ICNRG got demos of this capability, and it was also shown publicly at events [MWC_Demo] 🎪. The trial was accepted by the ETSI MEC group as a public proof-of-concept demonstration 🏆
Ngl, the demos so far all used the overlay deployment, but H2020 also ran ICN underlay trials 🙈. One of them involved commercial end users on the PrimeTel network in Cyprus, with a use case centered on IPTV and HLS video dissemination 📺. Another was over the "Guifi.net" community network in the Barcelona region, where the solution was deployed in 40 households that got general Internet connectivity 🏡. Standard IPTV Set-Top Boxes(STBs) and HLS video players were used, which matched the goal of this deployment configuration: application and service migration 💅
6.2.2. H2020 FLAME Efforts 🦩
The H2020 Facility for Large-Scale Adaptive Media Experimentation (FLAME) efforts are all about giving the POINT/RIFE solution an experimental playground 🧪. They started out in two city-scale locations, Bristol and Barcelona 🌆. This trial followed the underlay deployment configuration in Section 4.3.2, like POINT/RIFE does. Experiments were run with the city/university joint venture Bristol-is-Open (BIO) to make sure the city-scale SDN transport network was ready 🙌. Another trial was for the ETSI MEC PoC, which showed the operational benefits of the ICN underlay in a location-based game 🎮. The benefits were reduced network utilization through better video delivery performance (multicast of all captured videos to service surrogates deployed around the city at six locations) 📹. There was also lower latency, since the video played out from the local NAP, which was collocated with the Wi-Fi Access Point (AP) instead of a remote server. In other words, the playout latency was bounded by the maximum single-hop latency ⚡
Twenty three (23) large-scale media service experiments are planned as part of the H2020 FLAME efforts in the area of Future Media Internet (FMI) 🎞️. The platform includes ICN capabilities that are integrated with the infrastructure's NFV and SDN capabilities 🧩. The ultimate goal is full integration of ICN into the overall media function platform, so advanced (media-centric) Internet services can be provisioned 👑
6.2.3. CableLabs Content Delivery System 📦
The CableLabs ICN work reported in [White] proposes an underlay deployment configuration based on Section 4.3.2 🧱. The use case is ICN for content distribution inside complex CDN server farms, to take advantage of ICN's superior in-network caching properties 💾. This ICN-based "island" CDN is then used to serve standard HTTP/IP-based content retrieval requests coming from the general Internet 🌐. The approach recognizes that a whole-scale replacement (see Section 4.1) of existing HTTP/IP end-user applications and related web infrastructure is a difficult proposition 😩. [White] is clear that the proposed architecture has not been tested experimentally yet, but implementations are in process and expected in the 3-5 year time frame ⏳
6.2.4. NDN IoT Trials 🤖
[Baccelli] summarizes a trial of an NDN system adapted specifically for a wireless IoT scenario 📡. The trial ran with 60 nodes spread over several multistory buildings on a university campus 🏫. The NDN protocols were optimized to run directly over 6LoWPAN wireless link layers 🔧. The performance of the NDN-based IoT system was then compared to an equivalent system running standard IP-based IoT protocols 📊. It was found that the NDN-based IoT system was superior in several respects, including energy consumption and RAM and ROM footprints [Baccelli] [Anastasiades] ⚡💜. For example, compared to the standard IP-based IoT protocol stack on given devices, the NDN protocol stack's binary file size was up to 60% less for ROM size and up to 80% less for RAM size 🤯
6.2.5. NREN ICN Testbed 🎓
The National Research and Education Network (NREN) ICN Testbed is a project sponsored by Cisco, Internet2, and the US Research and Education community 🇺🇸. Participants include universities and US federal government entities that connect through a nationwide VPN-based L2 underlay 🏛️. The testbed uses the CCNx approach and is based on the [CICN] open-source software 💻. Approximately 15 nodes spread across the USA connect to the testbed 🗺️. The project's current focus is advancing data-intensive science and network research by improving data movement, searchability, and accessibility 🔬✨
6.2.6. DOCTOR Testbed 🩺
The DOCTOR project is a French research project, and its name means "Deployment and Securisation of new Functionalities in Virtualized Networking Environments" 🇫🇷. The project aims to run NDN over virtualized NFV infrastructure [Doctor] (based on Docker technology) 🐳. It focuses on the NFV MANO aspects to build an operational NDN network, with an eye on important performance criteria like security, performance, and interoperability 🛡️
The data plane relies on an HTTP/NDN gateway [Marchal] that processes HTTP traffic and carries it over NDN in an optimized way 🚀. This lets the testbed benefit from the properties of the NDN island, by mapping HTTP semantics to NDN semantics inside the island 🏝️. The testbed carries real Web traffic from users and has been evaluated with the top 1000 most popular websites 🌐. Users only need to set the gateway as their web proxy 💁♀️
The control plane relies on a central manager that uses machine-learning-based detection methods [Mai-1] on the data gathered by distributed probes 🧠. It applies orchestrated countermeasures against NDN attacks [Nguyen-1] [Nguyen-2] [Mai-2] or performance issues 🛠️. A remediation can be, for example, scaling up a bottleneck component or deploying a security function, like a firewall or a signature verification module 🧱. Test results so far indicate that key attacks can be detected accurately 🎯. For example, content poisoning attacks can be detected at over 95% accuracy, with less than 0.01% false positives [Nguyen-3] 😱
6.3. Composite-ICN Approach 🧬
Hybrid ICN [H-ICN_1] [H-ICN_2] is an approach where ICN names are mapped to IPv6 addresses, and other ICN information is carried as payload inside the IP packet 📦. This lets standard (ICN-unaware) IP routers forward packets based on IPv6 info, but it also lets ICN-aware routers apply ICN semantics 🧭. The intent is to enable rapid hybrid deployments and seamless interconnection of IP and Hybrid ICN domains 🌈. Hybrid ICN uses the [CICN] open-source software 💖. Initial tests were done with 150 clients consuming DASH videos, and they showed good scalability on the server side using the Hybrid ICN transport [H-ICN_3] [H-ICN_2] 🥳✨
6.4. Summary of Deployment Trials ✨
okay so, in summary, there have been SO many trials over the years 🔥 with all the major ICN protocol flavors (CCNx, NDN, and POINT), using both the ICN-as-an-Overlay and ICN-as-an-Underlay deployment configurations 💅. The big limitation is that only a limited number of applications have been tested. BUT the tested apps include both native ICN and existing IP-based apps (like videoconferencing and IPTV), so it's not all bad 🫶. Another limitation is that every single one of them involves less than 1k users 🙈.
Huawei and China Unicom have just started trials of the ICN-as-a-Slice configuration 🦋. They're showing off ICN features of security, mobility, and bandwidth efficiency over a wired infrastructure, using videoconferencing as the application scenario [Chakraborti]. And get this, the prototype has been extended to show the same thing over a 5G-NR access 😭🌈.
The Clean-slate ICN approach has obviously never been in trials. Like, complete replacement of Internet infrastructure (existing applications, the TCP/IP protocol stack, IP routers, etc.) is just no longer considered a viable option 💀.
Finally, Hybrid ICN is a Composite-ICN approach and it's giving interesting alternative 👑. It lets ICN semantics be embedded in standard IPv6 packets, so the packets can be routed through either IP routers or Hybrid ICN routers 🧚. Some other trials, like the DOCTOR testbed (Section 6.2.6), could also be called a Composite-ICN approach, because it has both ICN gateways (as in ICN-as-an-Underlay) and virtualized infrastructure (as in ICN-as-a-Slice) 🎀. However, for the DOCTOR testbed, we've chosen to characterize it as an ICN-as-an-Underlay configuration, because that's the dominant characteristic 💜.
7. Deployment Issues Requiring Further Standardization 🌸
"Information-Centric Networking (ICN) Research Challenges" [RFC7927] describes key ICN principles and technical research topics. As the title suggests, [RFC7927] is research oriented, without a specific focus on deployment or standardization issues. This section tackles that open area by identifying key protocol functionality that may be relevant for further standardization effort in the IETF 🦋. The focus is specifically on protocols that will facilitate future interoperable ICN deployments, correlating to the scenarios in the deployment migration paths in Section 5. The list of potential protocol functionality is not exhaustive, so don't come for me if something's missing 😭.
7.1. Protocols for Application and Service Migration 💅
End-user applications and services need a standardized approach to trigger ICN transactions. Like, in today's Internet and web apps, there are established socket APIs, communication paradigms (such as REST), common libraries, and best practices 🫶. We need to study application requirements in an ICN environment further and, at the same time, develop new APIs and best practices that can take advantage of ICN communication characteristics ✨.
7.2. Protocols for Content Delivery Network Migration 🍓
A key CDN issue is quickly finding the location of a copy of the object an end user requested 👀. In ICN, a Named Data Object (NDO) is typically defined by its name. [RFC6920] defines a mechanism that's suitable for static naming of ICN data objects. Other ways of encoding and representing ICN names have been described in [RFC8609] and [RFC8569] 🧚. Naming dynamically generated data requires different approaches (hash-digest-based names would normally not work), and there's a lack of established conventions and standards 💀.
Another CDN issue for ICN is multicast distribution of content. Existing CDNs have started using multicast mechanisms for certain cases, like broadcasting streaming TV 📺. However, as discussed in Section 6.2.1, certain ICN approaches provide substantial improvements over IP multicast, such as the implicit support for multicast retrieval of content in all ICN flavors 🔥.
Caching is an implicit feature in many ICN architectures, and it can improve performance and availability in several scenarios 💖. ICN in-network caching can augment a managed CDN and improve its performance. The details of the interplay between ICN caching and managed CDN still need further consideration 🤔.
7.3. Protocols for Edge and Core Network Migration 🌈
ICN has the potential to redesign current edge and core network computing approaches ✨. Leveraging ICN's inherent security, and its ability to make named data and dynamic computation results available independent of location, can enable a lightweight insertion of traffic into the network without relying on redirection of DNS requests 🦋. For this, proxies that translate from commonly used protocols on the general Internet to ICN message exchanges in the ICN domain could be used for the migration of applications and services, both within deployments at the network edge and in core networks 🫶. This is similar to existing approaches for IoT scenarios, where a proxy translates CoAP request/responses to other message formats. For example, [RFC8075] specifies proxy mapping between CoAP and HTTP protocols. Also, [RFC8613] is an example of how to pass end-to-end encrypted content between HTTP and CoAP by an application-layer security mechanism 🔐. Further work is required to identify whether an approach like [RFC8613], or some other approach, is suitable for preserving ICN message security through future protocol translation functions of gateways/proxies 👑.
Interaction and interoperability between existing IP routing protocols (e.g., OSPF, RIP, or IS-IS) and ICN routing approaches (e.g., NFD and CCNx routers) are expected, especially in the overlay approach 💅. Another important topic is the integration of ICN into networks that support virtualized infrastructure in the form of NFV/SDN, which most likely utilize SFC as a key protocol. Further work is required to validate this idea and document best practices 🧚.
There are several existing approaches to supporting QoS in IP networks, including Diffserv, IntServ, and RSVP 🎀. Some initial ideas for QoS support in ICN networks are outlined in [FLOW-CLASS], which proposes an approach based on flow classification to enable functions such as ICN rate control and cache control. Also, [ICN-QoS] proposes how to use Diffserv Differentiated Services Code Point (DSCP) codes to support QoS for ICN-based data path delivery 💜. Further work is required to identify the best approaches for supporting QoS in ICN networks ✨.
OAM is a crucial area that the ICN research community hasn't fully addressed yet, but it's obviously critical for future ICN deployments 😭.
Potential areas that need investigation include whether the YANG data modeling approach and associated NETCONF/RESTCONF protocols need any specific updates for ICN support 🤓. Another open area is how to measure and benchmark performance of ICN networks, comparable to the sophisticated techniques that exist for standard IP networks, virtualized networks, and data centers 📊. It should be noted that some initial progress has been made on ICN network path traceroute facilities, with approaches such as CCNxinfo [CNNinfo] [Contrace] 🦋.
7.4. Summary of ICN Protocol Gaps and Potential Protocol Efforts 👑
Without claiming completeness, Table 1 maps the open ICN issues identified in this document to potential protocol efforts that could address some aspects of each gap 🫶.
+--------------+------------------------------------------+
| ICN Gap | Potential Protocol Effort |
+==============+==========================================+
| 1-Support of | HTTP/CoAP support of ICN semantics |
| REST APIs | |
+--------------+------------------------------------------+
| 2-Naming | Dynamic naming of ICN data objects |
+--------------+------------------------------------------+
| 3-Routing | Interactions between IP and ICN routing |
| | protocols |
+--------------+------------------------------------------+
| 4-Multicast | Multicast enhancements for ICN |
| distribution | |
+--------------+------------------------------------------+
| 5-In-network | ICN cache placement and sharing |
| caching | |
+--------------+------------------------------------------+
| 6-NFV/SDN | Integration of ICN with NFV/SDN and |
| support | including possible impacts to SFC |
+--------------+------------------------------------------+
| 7-ICN | Mapping of HTTP and other protocols onto |
| mapping | ICN message exchanges (and vice versa) |
| | while preserving ICN message security |
+--------------+------------------------------------------+
| 8-QoS | Support of ICN QoS via mechanisms, such |
| support | as Diffserv and flow classification |
+--------------+------------------------------------------+
| 9-OAM | YANG data models, NETCONF/RESTCONF |
| support | protocols, and network-performance |
| | measurements |
+--------------+------------------------------------------+
Table 1: Mapping of ICN Gaps to Potential Protocol Efforts8. Conclusion ✨
okay bestie, this is the wrap-up 🎀 The doc lays out the five main ways you could deploy ICN: (1) Clean-slate ICN replacement of existing Internet infrastructure, (2) ICN-as-an-Overlay, (3) ICN-as-an-Underlay, (4) ICN-as-a-Slice, and (5) Composite-ICN. Most of the existing trial systems fall under ICN-as-an-Overlay, ICN-as-an-Underlay, and Composite-ICN 🌸
For migration paths, ICN-as-an-Underlay gives CDN, edge, or core networks a clear way to move to an ICN paradigm (IoT deployments, for example) while leaving the big pile of existing end-user apps totally untouched 🦋 ICN-as-an-Overlay is the easiest one to roll out quickly because it leaves the underlying IP infrastructure basically alone. BUT its fit for general deployment needs a case-by-case look. (Like, can it support all the user apps you actually need? 🤔)
ICN-as-a-Slice is giving very upcoming 5G energy 📡 It'll naturally support network slicing for 5G radio and core networks, but it still needs more trial experience to be validated 💜 Composite-ICN can literally combine some of the best parts of the other configurations ✨ Same deal though: its general deployment fit is case-by-case. Like, can enough IP routers get upgraded to support Composite-ICN functionality to actually give meaningful performance benefits? 👀
Now the trials. There's been lots of trial experience with all the major ICN protocol flavors (CCNx, NDN, and POINT) 🔥 Real talk though: only a limited number of applications have been tested so far, and the biggest trial has had fewer than 1k users. So the recommendation is to scale users gradually and keep a close eye on network performance as you go above 1k users 🙈 A logical approach is to increase the number of users in a slowly increasing linear way, and to monitor performance and stability, especially at every multiple of 1k users 📈
Last thing! This doc also describes a set of technical features in ICN that could be worth future IETF specification work 🧚 That'll help early and incremental deployments happen in an interoperable way 🫶 The detailed protocol specs, though, are best left for future study by the right IETF WGs and/or BoFs. In the meantime, the ICNRG can help by continuing to look at key system issues like QoS mechanisms, flexible naming schemes, and OAM support for ICN 💅
9. IANA Considerations ✨
This document has no IANA actions. Nothing to register here, babe 🌈
10. Security Considerations 💀
okay this section is SERIOUS and I'm not gonna pretend otherwise 😭 ICN was purposefully designed from the start to have certain intrinsic security properties. The most well known are authentication of delivered content and (optional) encryption of the content 🔐 [RFC7945] has an extensive discussion of many aspects of ICN security, including lots that matter for deployments 📚 Specifically, [RFC7945] points out that ICN access control, privacy, security of in-network caches, and protection against various network attacks (e.g., DoS) haven't been fully developed yet, because there just isn't a big enough mass of deployments 😤 It also points out relevant advances in the ICN research community that hold promise for addressing each of the identified security gaps 🙌 And finally, [RFC7945] says that as secure communications on the existing Internet (e.g., HTTPS) become the norm, major gaps in ICN security will inevitably slow down ICN adoption. Not ideal!! 🥺
On top of the [RFC7945] findings, this document highlights that all anticipated ICN deployment configurations will involve coexisting with existing Internet infrastructure and applications 🫠 So even the basic authentication and encryption properties of ICN content will need to account for interworking with non-ICN content to preserve end-to-end security 🛡️ For example, in the edge network underlay deployment configuration described in Section 4.3.1, the gateway/proxy that translates HTTP or CoAP request/responses into ICN message exchanges will need to support a security model to preserve end-to-end security. One option would be to look at an approach similar to [RFC8613], which is used to pass end-to-end encrypted content between HTTP and CoAP through an application-layer security mechanism 🧁 Further investigation is required to see whether this approach is suitable for preserving ICN message security through future protocol translation functions (e.g., ICN to HTTP or CoAP to ICN) of gateways/proxies 🔍
⚠️ Okay, the big one: the DOCTOR project from Section 6.2.6 is an early deployment looking at specific attacks against ICN infrastructure. Here they're looking at Interest Flooding Attacks [Nguyen-2] and Content Poisoning Attacks [Nguyen-1] [Mai-2] [Nguyen-3], and evaluating potential countermeasures based on MANO-orchestrated actions on the virtualized infrastructure [Mai-1] 👑
11. Informative References 📖
Here's the full reference list, every single entry, exactly as written 🫶
[Anastasiades]
Anastasiades, C., "Information-centric communication in
mobile and wireless networks", PhD Dissertation,
DOI 10.7892/boris.83683, June 2016,
<http://boris.unibe.ch/83683/1/16anastasiades_c.pdf>.
[Baccelli] Baccelli, E., et al., "Information Centric Networking in
the IoT: Experiments with NDN in the Wild", ACM-ICN '14:
Proceedings of the 1st ACM Conference on Information-
Centric Networking, DOI 10.1145/2660129.2660144, September
2014, <http://conferences2.sigcomm.org/acm-
icn/2014/papers/p77.pdf>.
[BIER] Trossen, D., Rahman, A., Wang, C., and T. Eckert,
"Applicability of BIER Multicast Overlay for Adaptive
Streaming Services", Work in Progress, Internet-Draft,
draft-ietf-bier-multicast-http-response-03, 4 February
2020, <https://tools.ietf.org/html/draft-ietf-bier-
multicast-http-response-03>.
[CCNx_UDP] PARC, "CCNx Over UDP", <https://www.ietf.org/proceedings/
interim-2015-icnrg-04/slides/slides-interim-2015-icnrg-
4-5.pdf>.
[Chakraborti]
Chakraborti, A., et al., "Design and Evaluation of a
Multi-source Multi-destination Real-time Application on
Content Centric Network", 2018 1st IEEE International
Conference on Hot Information-Centric Networking (HotICN),
DOI 10.1109/HOTICN.2018.8605980, August 2018,
<https://doi.org/10.1109/HOTICN.2018.8605980>.
[CICN] fd.io, "Cicn", <https://wiki.fd.io/view/Cicn>.
[CNNinfo] Asaeda, H., Ooka, A., and X. Shao, "CCNinfo: Discovering
Content and Network Information in Content-Centric
Networks", Work in Progress, Internet-Draft, draft-irtf-
icnrg-ccninfo-04, 22 March 2020,
<https://tools.ietf.org/html/draft-irtf-icnrg-ccninfo-04>.
[CONET] Veltri, L., et al., "Supporting Information-Centric
Functionality in Software Defined Networks", 2012 IEEE
International Conference on Communications (ICC),
DOI 10.1109/ICC.2012.6364916, November 2012,
<http://netgroup.uniroma2.it/Stefano_Salsano/papers/
salsano-icc12-wshop-sdn.pdf>.
[Contrace] Asaeda, H., et al., "Contrace: a tool for measuring and
tracing content-centric networks", IEEE Communications
Magazine, Volume 53, Issue 3,
DOI 10.1109/MCOM.2015.7060502, March 2015,
<https://doi.org/10.1109/MCOM.2015.7060502>.
[CUTEi] Asaeda, H., Li, R., and N. Choi, "Container-Based Unified
Testbed for Information Centric Networking", IEEE Network
Volume 28, Issue:6, DOI 10.1109/MNET.2014.6963806,
November 2014,
<https://doi.org/10.1109/MNET.2014.6963806>.
[C_FLOW] D. Chang, et al., "C_flow: An efficient content delivery
framework with OpenFlow", The International Conference on
Information Networking 2014 (ICOIN2014), pp. 270-275,
DOI 10.1109/ICOIN.2014.6799480, February 2014,
<https://ieeexplore.ieee.org/document/6799480>.
[DABBER] Mendes, P., Sofia, R., Tsaoussidis, V., and C. Borrego,
"Information-centric Routing for Opportunistic Wireless
Networks", Work in Progress, Internet-Draft, draft-mendes-
icnrg-dabber-04, 14 March 2020,
<https://tools.ietf.org/html/draft-mendes-icnrg-dabber-
04>.
[DASH] DASH, "DASH Industry Forum", <http://dashif.org/>.
[Doctor] DOCTOR, "Deployment and securisation of new
functionalities in virtualized networking environments",
<http://www.doctor-project.org/index.htm>.
[fiveG-23501]
3GPP, "System Architecture for the 5G System", Release 15,
3GPP TS 23.501, December 2017.
[fiveG-23502]
3GPP, "Procedures for the 5G System (5GS)", Release 15,
3GPP TS 23.502.
[FLOW-CLASS]
Moiseenko, I. and D. Oran, "Flow Classification in
Information Centric Networking", Work in Progress,
Internet-Draft, draft-moiseenko-icnrg-flowclass-05, 20
January 2020, <https://tools.ietf.org/html/draft-
moiseenko-icnrg-flowclass-05>.
[GEANT] GEANT, "GEANT", <https://www.geant.org/>.
[H-ICN_1] Cisco, "Cisco Announces Important Steps toward Adoption of
Information-Centric Networking", February 2017,
<http://blogs.cisco.com/sp/cisco-announces-important-
steps-toward-adoption-of-information-centric-networking>.
[H-ICN_2] Cisco, "Mobile Video Delivery with Hybrid ICN: IP-
integrated ICN Solution for 5G",
<https://www.cisco.com/c/dam/en/us/solutions/collateral/
service-provider/ultra-services-platform/mwc17-hicn-video-
wp.pdf>.
[H-ICN_3] Muscariello, L., et al, "Hybrid Information-Centric
Networking: ICN inside the Internet Protocol", ICNRG
Interim Meeting, March 2018,
<https://datatracker.ietf.org/meeting/interim-2018-icnrg-
01/materials/slides-interim-2018-icnrg-01-sessa-hybrid-
icn-hicn-luca-muscariello>.
[ICN-5GC] Ravindran, R., Suthar, P., Trossen, D., Wang, C., and G.
White, "Enabling ICN in 3GPP's 5G NextGen Core
Architecture", Work in Progress, Internet-Draft, draft-
ravi-icnrg-5gc-icn-04, 31 May 2019,
<https://tools.ietf.org/html/draft-ravi-icnrg-5gc-icn-04>.
[ICN-DEP-CON]
Paik, E., Yun, W., Kwon, T., and H. Choi, "Deployment
Considerations for Information-Centric Networking", Work
in Progress, Internet-Draft, draft-paik-icn-deployment-
considerations-00, 15 July 2013,
<https://tools.ietf.org/html/draft-paik-icn-deployment-
considerations-00>.
[ICN-IoT] Ravindran, R., Zhang, Y., Grieco, L., Lindgren, A., Burke,
J., Ahlgren, B., and A. Azgin, "Design Considerations for
Applying ICN to IoT", Work in Progress, Internet-Draft,
draft-irtf-icnrg-icniot-03, 2 May 2019,
<https://tools.ietf.org/html/draft-irtf-icnrg-icniot-03>.[ICN-LTE-4G] 🧚 Suthar, P., Stolic, M., Jangam, A., Ed., Trossen, D., and R. Ravindran, "Native Deployment of ICN in LTE, 4G Mobile Networks", Work in Progress, Internet-Draft, draft-irtf-icnrg-icn-lte-4g-05, 4 November 2019, https://tools.ietf.org/html/draft-irtf-icnrg-icn-lte-4g-05.
[ICN-QoS] 💖 Jangam, A., Suthar, P., and M. Stolic, "Supporting QoS aware Data Delivery in Information Centric Networks", Work in Progress, Internet-Draft, draft-anilj-icnrg-icn-qos-00, 14 July 2018, https://tools.ietf.org/html/draft-anilj-icnrg-icn-qos-00.
[ICN-TERM] 🦋 Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, D., and C. Tschudin, "Information-Centric Networking (ICN): CCNx and NDN Terminology", Work in Progress, Internet-Draft, draft-irtf-icnrg-terminology-08, 17 January 2020, https://tools.ietf.org/html/draft-irtf-icnrg-terminology-08.
[ICN2020-Experiments] 🌸 ICN2020, "D4.1: 1st Yearly WP4 Report & Demonstration", August 2017, https://projects.gwdg.de/attachments/6840/D4.1-PU.pdf.
[ICN2020-overview] ✨ ICN2020, "ICN2020 Project Overview", http://www.icn2020.org/.
[ICNRGCharter] 👑 IRTF, "Information-Centric Networking Research Group Charter", https://datatracker.ietf.org/doc/charter-irtf-icnrg/.
[IEEE_Communications] 🔥 Trossen, D. and G. Parisis, "Designing and realizing an information-centric internet", IEEE Communications Magazine, Volume 50, Issue 7, DOI 10.1109/MCOM.2012.6231280, https://doi.org/10.1109/MCOM.2012.6231280.
[Internet_Pricing] 💅 Trossen, D. and G. Biczok, "Not paying the truck driver: differentiated pricing for the future internet", ReARCH '10: Proceedings of the Re-Architecting the Internet Workshop, ReArch '10: Proceedings of the Re-Architecting the Internet Workshop, DOI 10.1145/1921233.1921235, November 2010, https://doi.org/10.1145/1921233.1921235.
[Jacobson] 🎀 Jacobson, V., et al., "Networking Named Content", CoNEXT '09: Proceedings of the 5th international conference on Emerging networking experiments and technologies, DOI 10.1145/1658939.1658941, December 2009, https://doi.org/10.1145/1658939.1658941.
[Jangam] 🫶 Jangam, A., et al., "nlsrSIM: Porting and Simulation of Named-data Link State Routing Protocol into ndnSIM", DIVANet '17: Proceedings of the 6th ACM Symposium on Development and Analysis of Intelligent Vehicular Networks and Applications, DOI 10.1145/3132340.3132351, November 2017, https://dl.acm.org/citation.cfm?id=3132351.
[Mai-1] 🌈 Mai, H., et al., "Implementation of content poisoning attack detection and reaction in virtualized NDN networks", 2018 21st Conference on Innovation in Clouds, Internet and Networks and Workshops (ICIN), DOI 10.1109/ICIN.2018.8401591, July 2018, https://ieeexplore.ieee.org/document/8401591.
[Mai-2] 🍓 Mai, H., et al., "Towards a Security Monitoring Plane for Named Data Networking: Application to Content Poisoning Attack", NOMS 2018 - 2018 IEEE/IFIP Network Operations Management Symposium, DOI 10.1109/NOMS.2018.8406246, July 2018, https://doi.org/10.1109/NOMS.2018.8406246.
[Marchal] ⭐ Marchal, X., et al., "Leveraging NFV for the Deployment of NDN: Application to HTTP Traffic Transport", NOMS 2018 - 2018 IEEE/IFIP Network Operations and Management Symposium, DOI 10.1109/NOMS.2018.8406206, July 2018, http://www.mallouli.com/recherche/publications/noms2018-1.pdf.
[Moiseenko] 💜 Moiseenko, I. and D. Oran, "TCP/ICN: Carrying TCP over Content Centric and Named Data Networks", ACM-ICN '16: Proceedings of the 3rd ACM Conference on Information-Centric Networking, DOI 10.1145/2984356.2984357, September 2016, http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p112-moiseenko.pdf.
[MWC_Demo] 🦋 InterDigital, "InterDigital Demo at Mobile World Congress (MWC)", 2016, http://www.interdigital.com/download/56d5c71bd616f892ba001861.
[NDN-testbed] 🧚 NDN, "NDN Testbed", https://named-data.net/ndn-testbed/.
[NetInf] 💖 Kutscher, D., Farrell, S., and E. Davies, "The NetInf Protocol", Work in Progress, Internet-Draft, draft-kutscher-icnrg-netinf-proto-01, 10 February 2013, https://tools.ietf.org/html/draft-kutscher-icnrg-netinf-proto-01.
[NFD] ✨ NDN, "NFD - Named Data Networking Forwarding Daemon", https://named-data.net/doc/NFD/current/.
[NGMN-5G] 👑 NGMN Alliance, "5G White Paper", February 2015, https://www.ngmn.org/wp-content/uploads/NGMN_5G_White_Paper_V1_0.pdf.
[NGMN-Network-Slicing] 🔥 NGMN Alliance, "Description of Network Slicing Concept", NGMN 5G P1, Requirements & Architecture, Work Stream End-to-End Architecture, Version 1.0, January 2016, https://www.ngmn.org/wp-content/uploads/160113_NGMN_Network_Slicing_v1_0.pdf.
[Nguyen-1] 💅 Nguyen, T., et al., "Content Poisoning in Named Data Networking: Comprehensive characterization of real deployment", 2017 IFIP/IEEE Symposium on Integrated Network and Service Management (IM), DOI 10.23919/INM.2017.7987266, July 2017, https://doi.org/10.23919/INM.2017.7987266.
[Nguyen-2] 🎀 Nguyen, T., Cogranne, R., and G. Doyen, "An optimal statistical test for robust detection against interest flooding attacks in CCN", 2015 IFIP/IEEE International Symposium on Integrated Network Management (IM), DOI 10.1109/INM.2015.7140299, July 2015, https://doi.org/10.1109/INM.2015.7140299.
[Nguyen-3] 🫶 Nguyen, T., et al., "A Security Monitoring Plane for Named Data Networking Deployment", IEEE Communications Magazine, Volume: 56, Issue 11, DOI 10.1109/MCOM.2018.1701135, November 2018, https://doi.org/10.1109/MCOM.2018.1701135.
[ONAP] 🌈 ONAP, "Open Network Automation Platform", https://www.onap.org/.
[oneM2M] 🍓 OneM2M, "oneM2M Service Layer Standards for M2M and IoT", 2017, http://www.onem2m.org/.
[Overlay_ICN] ⭐ Shailendra, S., et al., "A novel overlay architecture for Information Centric Networking", 2015 21st National Conference on Communications, NCC 2015, DOI 10.1109/NCC.2015.7084921, April 2016, https://www.researchgate.net/publication/282779666_A_novel_overlay_architecture_for_Information_Centric_Networking.
[POINT] 💜 Trossen, D., et al., "IP over ICN - The better IP?", 2015 European Conference on Networks and Communications (EuCNC), DOI 10.1109/EuCNC.2015.7194109, June 2015, https://doi.org/10.1109/EuCNC.2015.7194109.
[Ravindran] 🦋 Ravindran, R., et al., "5G-ICN : Delivering ICN Services over 5G using Network Slicing", IEEE Communications Magazine, Volume 55, Issue 5, DOI 10.1109/MCOM.2017.1600938, October 2016, https://arxiv.org/abs/1610.01182.
[Reed] 🧚 Reed, M., et al., "Stateless multicast switching in software defined networks", 2016 IEEE International Conference on Communications (ICC), DOI 10.1109/ICC.2016.7511036, May 2016, https://doi.org/10.1109/ICC.2016.7511036.
[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, https://www.rfc-editor.org/info/rfc6920.
[RFC7252] ✨ Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, https://www.rfc-editor.org/info/rfc7252.
[RFC7426] 👑 Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, https://www.rfc-editor.org/info/rfc7426.
[RFC7665] 🔥 Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, https://www.rfc-editor.org/info/rfc7665.
[RFC7927] 💅 Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, https://www.rfc-editor.org/info/rfc7927.
[RFC7945] 🎀 Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., and G. Boggia, "Information-Centric Networking: Evaluation and Security Considerations", RFC 7945, DOI 10.17487/RFC7945, September 2016, https://www.rfc-editor.org/info/rfc7945.
[RFC8075] 🫶 Castellani, A., Loreto, S., Rahman, A., Fossati, T., and E. Dijk, "Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)", RFC 8075, DOI 10.17487/RFC8075, February 2017, https://www.rfc-editor.org/info/rfc8075.
[RFC8568] 🌈 Bernardos, CJ., Rahman, A., Zuniga, JC., Contreras, LM., Aranda, P., and P. Lynch, "Network Virtualization Research Challenges", RFC 8568, DOI 10.17487/RFC8568, April 2019, https://www.rfc-editor.org/info/rfc8568.
[RFC8569] 🍓 Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019, https://www.rfc-editor.org/info/rfc8569.
[RFC8609] ⭐ Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019, https://www.rfc-editor.org/info/rfc8609.
[RFC8613] 💜 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, https://www.rfc-editor.org/info/rfc8613.
[SAIL] 🦋 SAIL, "Scalable and Adaptive Internet Solutions (SAIL)", http://www.sail-project.eu/.
[SAIL_Content_Delivery] 🧚 FP7, "NetInf Content Delivery and Operations", Objective FP7-ICT-2009-5-257448/D-3.2, January 2013, https://sail-project.eu/wp-content/uploads/2012/06/SAIL_DB2_v1_0_final-Public.pdf.
[SAIL_Prototyping] 💖 FP7, "Prototyping and Evaluation", Objective FP7-ICT-2009-5-257448/D.B.4, March 2013, http://www.sail-project.eu/wp-content/uploads/2013/05/SAIL_DB4_v1.1_Final_Public.pdf.
[Tateson] Tateson, J., et al., "Final Evaluation Report on
Deployment Incentives and Business Models", PSIRP,
Version 1.0, May 2010,
<http://www.psirp.org/files/Deliverables/FP7-INFSO-ICT-
216173-PSIRP-D4.6_FinalReportOnDeplIncBusinessModels.pdf>.
[Techno_Economic]
Trossen, D. and A. Kostopoulos, "Techno-Economics Aspects
of Information-Centric Networking", Volume 2, Journal for
Information Policy , DOI 10.5325/jinfopoli.2.2012.0026,
June 2012,
<https://doi.org/10.5325/jinfopoli.2.2012.0026>.
[UMOBILE-2]
Sarros, C., et al., "Connecting the Edges: A Universal,
Mobile-Centric, and Opportunistic Communications
Architecture", IEEE Communications Magazine, Volume 56,
Issue 2, DOI 10.1109/MCOM.2018.1700325, February 2018,
<https://doi.org/10.1109/MCOM.2018.1700325>.
[UMOBILE-3]
Tavares, M., Aponte, O., and P. Mendes, "Named-data
Emergency Network Services", MobiSys '18: Proceedings of
the 16th Annual International Conference on Mobile
Systems, Applications, and Services,
DOI 10.1145/3210240.3210809, June 2018,
<https://doi.org/10.1145/3210240.3210809>.
[UMOBILE-4]
Amaral, L., et al., "Oi! - Opportunistic Data Transmission
Based on Wi-Fi Direct", 2016 IEEE Conference on Computer
Communications Workshops (INFOCOM WKSHPS),
DOI 10.1109/INFCOMW.2016.7562142, April 2016,
<https://doi.org/10.1109/INFCOMW.2016.7562142>.
[UMOBILE-5]
Dynerowicz, S. and P. Mendes, "Demo: named-data networking
in opportunistic network", ICN '17: Proceedings of the 4th
ACM Conference on Information-Centric Networking,
DOI 10.1145/3125719.3132107, September 2017,
<https://doi.org/10.1145/3125719.3132107>.
[UMOBILE-6]
Mendes, P.,et al., "Information-centric routing for
opportunistic wireless networks", ICN '18: Proceedings of
the 5th ACM Conference on Information-Centric Networking,
DOI 10.1145/3267955.3269011, September 2018,
<https://doi.org/10.1145/3267955.3269011>.
[UMOBILE-7]
Sofia, R., "D4.5 Report on Data Collection and Inference
Models", Deliverable, September 2017.
[UMOBILE-8]
Sarros, C., et al., "ICN-based edge service deployment in
challenged networks", ICN '17: Proceedings of the 4th ACM
Conference on Information-Centric Networking,
DOI 10.1145/3125719.3132096, September 2017,
<https://doi.org/10.1145/3125719.3132096>.
[UMOBILE-9]
Lertsinsrubtavee, A., et al., "Information-Centric Multi-
Access Edge Computing Platform for Community Mesh
Networks", COMPASS '18: Proceedings of the 1st ACM SIGCAS
Conference on Computing and Sustainable Societies,
DOI 10.1145/3209811.3209867, June 2018,
<https://doi.org/10.1145/3209811.3209867>.
[UMOBILE-overview]
UMOBILE, "Universal, mobile-centric and opportunistic
communications architecture",
<http://www.umobile-project.eu/>.
[VSER] Ravindran, R., et al., "Towards software defined ICN based
edge-cloud services", 2013 IEEE 2nd International
Conference on Cloud Networking (CloudNet),
DOI 10.1109/CloudNet.2013.6710583,
<https://doi.org/10.1109/CloudNet.2013.6710583>.
[VSER-Mob] Azgin, A., et al., "Seamless Producer Mobility as a
Service in Information-centric Networks", ACM-ICN '16:
Proceedings of the 3rd ACM Conference on Information-
Centric Networking, DOI 10.1145/2984356.2988521, September
2016, <https://doi.org/10.1145/2984356.2988521>.
[White] White, G. and G. Rutz, "Content Delivery with Content-
Centric Networking", February 2016,
<http://www.cablelabs.com/wp-content/uploads/2016/02/
Content-Delivery-with-Content-Centric-Networking-Feb-
2016.pdf>.That's the whole reading list, bestie 📚✨ every single source the authors leaned on, all lined up so you can go find them yourself 🕵️♀️💜
Acknowledgments 🫶
Okay, now the shoutouts 📣 The authors want to thank Alex Afanasyev, Hitoshi Asaeda, Giovanna Carofiglio, Xavier de Foy, Guillaume Doyen, Hannu Flinck, Anil Jangam, Michael Kowal, Adisorn Lertsinsrubtavee, Paulo Mendes, Luca Muscariello, Thomas Schmidt, Jan Seedorf, Eve Schooler, Samar Shailendra, Milan Stolic, Prakash Suthar, Atsushi Mayutan, and Lixia Zhang for their super useful reviews and comments on the document. 🌸
Special thanks go to Dave Oran (ICNRG Co-chair) and Marie-Jose Montpetit 👑 for their extensive and thoughtful reviews. Their reviews helped to immeasurably improve the document quality, which is honestly iconic behaviour 😭💅
Authors' Addresses 💌
Here's where to find the people who wrote this thing, so you can slide into their inboxes if you have questions 🦋
Akbar Rahman
InterDigital Communications, LLC
1000 Sherbrooke Street West, 10th floor
Montreal H3A 3G4
Canada
Email: Akbar.Rahman@InterDigital.com
URI: http://www.InterDigital.com/
Dirk Trossen
Huawei Technologies Duesseldorf GmbH
Riesstrasse 25
80992 Munich
Germany
Email: dirk.trossen@huawei.com
URI: http://www.huawei.com/
Dirk Kutscher
University of Applied Sciences Emden/Leer
Constantiapl. 4
26723 Emden
Germany
Email: ietf@dkutscher.net
URI: https://www.hs-emden-leer.de/en/
Ravi Ravindran
Sterlite Technologies
5201 Greatamerica Pkwy
Santa Clara, 95054
United States of America
Email: ravi.ravindran@gmail.comAnd that's the whole RFC, bestie 🌈💖✨
📦 where this page comes from
- ietf: rfc8763 2020-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms