diff options
Diffstat (limited to 'doc/rfc/rfc8763.txt')
| -rw-r--r-- | doc/rfc/rfc8763.txt | 1711 |
1 files changed, 1711 insertions, 0 deletions
diff --git a/doc/rfc/rfc8763.txt b/doc/rfc/rfc8763.txt new file mode 100644 index 0000000..a7d7b98 --- /dev/null +++ b/doc/rfc/rfc8763.txt @@ -0,0 +1,1711 @@ + + + + +Internet Research Task Force (IRTF) A. Rahman +Request for Comments: 8763 InterDigital Communications, LLC +Category: Informational D. Trossen +ISSN: 2070-1721 Huawei + D. Kutscher + Emden University + R. Ravindran + Sterlite Technologies + April 2020 + + + Deployment Considerations for Information-Centric Networking (ICN) + +Abstract + + Information-Centric Networking (ICN) is now reaching technological + maturity after many years of fundamental research and + experimentation. This document provides a number of deployment + considerations in the interest of helping the ICN community move + forward to the next step of live deployments. First, the major + deployment configurations for ICN are described, including the key + overlay and underlay approaches. Then, proposed deployment migration + paths are outlined to address major practical issues, such as network + and application migration. Next, selected ICN trial experiences are + summarized. Finally, protocol areas that require further + standardization are identified to facilitate future interoperable ICN + deployments. 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 is + published for informational purposes. + + This document is a product of the Internet Research Task Force + (IRTF). The IRTF publishes the results of Internet-related research + and development activities. These results might not be suitable for + deployment. This RFC represents the consensus of the Information- + Centric Networking Research Group of the Internet Research Task Force + (IRTF). Documents approved for publication by the IRSG are not a + candidate for any level of Internet Standard; see Section 2 of RFC + 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained 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, as 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' Addresses + +1. Introduction + + The ICNRG charter identifies deployment guidelines as an important + topic area for the ICN community. Specifically, the charter states + 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 require further investigation [ICNRGCharter]. Also, it is + well understood that results and conclusions from any mid- to large- + scale ICN experiments in the live Internet will also provide useful + guidance for deployments. + + So far, outside of some preliminary investigations, such as + [ICN-DEP-CON], there has not been much progress on this topic. This + document attempts to fill some of these gaps by defining clear + deployment configurations for ICN and associated migration pathways + for these configurations. Also, selected deployment trial + experiences of ICN technology are summarized. Recommendations are + also made for potential future IETF standardization of key protocol + functionality that will facilitate interoperable ICN deployments + going forward. + + The major configurations of 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 primarily fall under the ICN-as-an-Overlay, ICN-as-an- + Underlay, and Composite-ICN configurations. Each of these deployment + configurations have their respective strengths and weaknesses. This + document will aim to provide guidance for current and future members + of the ICN community when they consider deployment of ICN + technologies. + + This document represents the consensus of the Information-Centric + Networking Research Group (ICNRG). It has been reviewed extensively + by the Research Group (RG) members 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 that are defined in [RFC7927] and [ICN-TERM]. In + addition, 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 encompasses various access networks (e.g., + Wi-Fi or mobile radio network), service edge networks (e.g., for + edge computing), transport networks, Content Distribution Networks + (CDNs), core networks (e.g., mobile core network), and back-end + processing networks (e.g., data centers). However, throughout + this document, the discussion is typically limited to edge + networks, core networks, and CDNs, for simplicity. + + 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 and, thus, are 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, allowing for realizing capabilities, such + as 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 Networks + +4. Deployment Configurations + + In this section, we present various deployment options for ICN. + These are presented as "configurations" that allow for studying these + options further. While this document will outline experiences with a + number of these configurations (in Section 6), we will not provide an + in-depth technical or commercial evaluation for any of them -- for + this, we refer to existing literature in this space, such as + [Tateson]. + +4.1. Clean-Slate ICN + + ICN has often been described as a "clean-slate" approach with the + goal to renew or replace the complete IP infrastructure of the + Internet. As such, existing routing hardware and ancillary services, + such as existing applications that are typically tied directly to the + TCP/IP stack, are not taken for granted. For instance, a Clean-slate + ICN deployment would see existing IP routers being replaced by ICN- + specific forwarding and routing elements, such as NFD [NFD], CCNx + routers [Jacobson], or Publish-Subscribe Internet Technology + (PURSUIT) forwarding nodes [IEEE_Communications]. + + While such clean-slate replacement could be seen as exclusive for ICN + deployments, some ICN approaches (e.g., [POINT]) also rely on the + deployment of general infrastructure upgrades, in this case, SDN + switches. Different proposals have been made for various ICN + approaches to enable the operation over an SDN transport [Reed] + [CONET] [C_FLOW]. + +4.2. ICN-as-an-Overlay + + Similar to other significant changes to the Internet routing fabric, + particularly the transition from IPv4 to IPv6 or the introduction of + IP multicast, this deployment configuration foresees the creation of + an ICN overlay. Note that this overlay approach is sometimes, + informally, also referred to as a tunneling approach. The overlay + approach can be implemented directly (e.g., ICN-over-UDP), as + described in [CCNx_UDP]. Alternatively, the overlay can be + accomplished via 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 to + map NetInf semantics to HTTP [NetInf]. Finally, [Overlay_ICN] + describes an incremental approach to deploying an ICN architecture + particularly well suited to SDN-based networks by also segregating + ICN user- and control-plane traffic. + + However, regardless of the flavor, the overlay approach results in + islands of ICN deployments over existing IP-based infrastructure. + Furthermore, these ICN islands are typically connected to each other + via ICN/IP tunnels. In certain scenarios, this requires + 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. This + overlay approach is thus very attractive for ICN experimentation and + testing, as it allows rapid and easy deployment of ICN over existing + IP networks. + +4.3. ICN-as-an-Underlay + + Proposals, such as [POINT] and [White], outline the deployment option + of using an ICN underlay that would integrate with existing + (external) IP-based networks by deploying application-layer gateways + at appropriate locations. The main reasons for such a configuration + option is the introduction of ICN technology in given islands (e.g., + inside a CDN or edge IoT network) to reap the benefits of native ICN, + in terms of underlying multicast delivery, mobility support, fast + indirection due to location independence, in-network computing, and + possibly more. The underlay approach thus results in islands of + native ICN deployments that are connected to the rest of the Internet + through protocol conversion gateways or proxies. Routing domains are + strictly separated. Outside of the ICN island, normal IP routing + protocols apply. Within 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 + the introduction of new network architectures and protocols is easier + in so-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 takes place at an + application gateway/proxy at the edge network boundary, e.g., + translating incoming CoAP request/response transactions [RFC7252] + into ICN message exchanges or vice versa. + + The work in [VSER] positions ICN as an edge service gateway driven by + a generalized ICN-based service orchestration system with its own + compute and network virtualization controllers to manage an ICN + infrastructure. The platform also offers service discovery + capabilities to enable user applications to discover appropriate ICN + service gateways. To exemplify a scenario in a use case, the [VSER] + platform shows the realization of a multi-party audio/video + conferencing service over such an edge cloud deployment of ICN + routers realized over commodity hardware platforms. This platform + has also been extended to offer seamless mobility as a service that + [VSER-Mob] features. + +4.3.2. Core Network + + In this suboption, a core network would utilize edge-based protocol + mapping onto the native ICN underlay. For instance, [POINT] proposes + to map HTTP transactions or some other IP-based transactions, such as + CoAP, directly onto an ICN-based message exchange. This mapping is + realized at the NAP, for example, in access points or customer + premise equipment, which, in turn, provides a standard IP interface + to existing user devices. Thus, the NAP provides the apparent + perception of an IP-based core network toward any external peering + network. + + The work in [White] proposes a similar deployment configuration. + There, the goal is to use ICN for content distribution within CDN + server farms. Specifically, the protocol mapping is realized at the + ingress of the server farm where the HTTP-based retrieval request is + served, while the response is 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 with exclusive SLA requirements on transport and + compute-level QoS and security. This is enabled through NFV and SDN + technology functions that enable functional decomposition (hence, + modularity, independent scalability of control, and/or the user-plane + functions), agility, and service-driven programmability. Network + slicing is often associated with 5G but is clearly not limited to + such systems. However, from a 5G perspective, the definition of + slicing includes access networks enabling dynamic slicing of the + spectrum resources among various services, hence naturally extending + itself to end points and cloud resources across multiple domains, to + offer 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 + through composition of 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 its own control + and forwarding plane, over which one or more end-user services can be + delivered [NGMN-Network-Slicing]. + + The 5G next generation architecture [fiveG-23501] provides the + flexibility to deploy the ICN-as-a-Slice over either the edge (RAN) + or mobile core network; otherwise, the ICN-as-a-Slice may be deployed + end to end. Further discussions on extending the architecture + presented in [fiveG-23501] and the corresponding procedures in + [fiveG-23502] to support ICN has been provided in [ICN-5GC]. The + document elaborates on two possible approaches to enable ICN: (1) as + an edge service using the local data network (LDN) feature in 5G + using User Plane Function (UPF) classification functions to fast + handover to the ICN forwarder and (2) as a native deployment using + the non-IP Protocol Data Unit (PDU) support that would allow new + network layer PDU to be handed over to ICN UPFs collocated with the + Generation NodeB (gNB) functions without invoking any IP functions. + While the former deployment would still rely on 3GPP-based mobility + functions, the later would allow mobility to be handled natively by + ICN. However, both these deployment modes should benefit from other + ICN features, such as in-network caching and computing. Associated + with this ICN user-plane enablement, control-plane extensions are + also proposed leveraging 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 being "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 should be noted that ICN is not creating + the network slice but instead that the slice is created to run a 5G- + ICN instance [Ravindran]. + + At the level of the specific technologies involved, such as ONAP + [ONAP] (which can be used to orchestrate slices), the 5G-ICN slice + requires compatibility, for instance, at the level of the forwarding/ + data plane depending on if it is 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 do not clearly correspond to any of the previously + defined basic configurations of (1) Clean-slate ICN, (2) ICN-as-an- + Overlay, (3) ICN-as-an-Underlay, and (4) ICN-as-a-Slice. Or, a + deployment may contain a composite mixture of the properties of these + basic configurations. For example, the Hybrid ICN [H-ICN_1] approach + carries ICN names in existing IPv6 headers and does not have distinct + gateways or tunnels connecting ICN islands or any other distinct + feature identified in the previous basic configurations. So we + categorize Hybrid ICN and other approaches that do not clearly + correspond to one of the other basic configurations as a Composite- + ICN approach. + +5. Deployment Migration Paths + + We now focus on the various migration paths that will have importance + to the various stakeholders that are usually involved in the + deployment of 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 technological aspects of such migration. Economic or + regulatory aspects, such as those studied in [Tateson], + [Techno_Economic], and [Internet_Pricing], are left out of our + discussion. + +5.1. Application and Service Migration + + The Internet supports a multitude of applications and services using + the many protocols defined over the packet-level IP service. HTTP + provides one convergence point for these services with many web + development frameworks based on the semantics provided by it. In + recent years, even services such as video delivery have been + migrating from the traditional RTP-over-UDP delivery to the various + HTTP-level streaming solutions, such as DASH [DASH] and others. + Nonetheless, many non-HTTP services exist, all of which need + consideration when migrating from the IP-based Internet to an ICN- + based one. + + The underlay deployment configuration option presented in Section 4.3 + aims at providing some level of compatibility to the existing + ecosystem through a proxy-based message flow mapping mechanism (e.g., + mapping of existing HTTP/TCP/IP message flows to HTTP/ICN message + flows). A related approach of mapping TCP/IP to TCP/ICN message + flows is described in [Moiseenko]. Another approach described in + [Marchal] uses HTTP/NDN gateways and focuses, in particular, on the + right strategy to map HTTP to NDN to guarantee a high level of + compatibility with HTTP while enabling an efficient caching of data + in the ICN island. The choice of approach is a design decision based + on how to configure the protocol stack. For example, the approach + described in [Moiseenko] 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 these functionalities onto existing ICN + functionalities. + + Alternatively, ICN-as-an-Overlay (Section 4.2) and ICN-as-a-Slice + (Section 4.4) allow for the introduction of the full capabilities of + ICN through new application/service interfaces, as well as operations + in the network. With that, these approaches of deployment are likely + to aim at introducing new application/services capitalizing on those + ICN capabilities, such as in-network multicast and/or caching. + + Finally, [ICN-LTE-4G] outlines a dual-stack end-user device approach + that is applicable for all deployment configurations. Specifically, + it introduces middleware layers (called the TCL) in the device that + will dynamically adapt existing applications to either an underlying + ICN protocol stack or standard IP protocol stack. This involves end + device signaling with the network to determine which protocol stack + instance and associated middleware adaptation layers to utilize for a + given application transaction. + +5.2. Content Delivery Network Migration + + A significant number of services and applications are devoted to + content delivery in some form, e.g., as video delivery, social media + platforms, and many others. CDNs are deployed to assist these + services through localizing the content requests and therefore + reducing latency and possibly increasing utilization of available + bandwidth, as well as reducing the load on origin servers. Similar + to the previous subsection, the underlay deployment configuration + presented in Section 4.3 aims at providing a migration path for + existing CDNs. This is also highlighted in a BIER use-case document + [BIER], specifically with potential benefits in terms of utilizing + multicast in the delivery of content but also reducing load on origin + and delegation servers. We return to this benefit in the trial + experiences in Section 6. + +5.3. Edge Network Migration + + Edge networks often see the deployment of novel network-level + technology, e.g., in the space of IoT. For many years, such IoT + deployments have relied, and often still do, on proprietary protocols + for reasons, such as increased efficiency, lack of standardization + incentives, and others. Utilizing the underlay deployment + configuration in Section 4.3.1, application gateways/proxies can + integrate such edge deployments into IP-based services, e.g., + utilizing CoAP-based [RFC7252] M2M platforms, such as oneM2M [oneM2M] + or others. + + Another area of increased edge network innovation is that of mobile + (access) networks, particularly in the context of the 5G mobile + networks. Network softwarization (using technologies like service + orchestration frameworks leveraging NFV and SDN concepts) are now + common in access networks and other network segments. Therefore, the + ICN-as-a-Slice deployment configuration in Section 4.4 provides a + suitable migration path for the integration of non-IP-based edge + networks into the overall system by virtue of realizing the relevant + (ICN) protocols in an access network slice. + + With the advent of SDN and NFV capabilities, so-called campus or + site-specific deployments could see the introduction of ICN islands + at the edge for scenarios such as gaming or deployments based on + Augmented Reality (AR) / Virtual Reality (VR), e.g., smart cities or + theme parks. + +5.4. Core Network Migration + + Migrating core networks of the Internet or mobile networks requires + not only significant infrastructure renewal but also the fulfillment + of the key performance requirements, particularly in terms of + throughput. For those 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 allow the introduction of native + ICN solutions within slices. This would allow for isolating the ICN + traffic while addressing the specific ICN performance benefits (such + as in-network multicast or caching) and constraints (such as the need + for specific network elements within such isolated slices). For ICN + solutions that natively work on top of SDN, the underlay deployment + configuration in Section 4.3.2 provides an additional migration path, + preserving the IP-based services and applications at the edge of the + network while realizing the core network routing through an ICN + solution (possibly itself realized in a slice of the SDN transport + network). + +6. Deployment Trial Experiences + + In this section, we will outline trial experiences, often conducted + within collaborative project efforts. Our focus here is on the + realization of the various deployment configurations identified in + Section 4; therefore, we categorize the trial experiences according + to these deployment configurations. While a large body of work + exists at the simulation or emulation level, we specifically exclude + these studies from our analysis to retain the focus on real-life + experiences. + +6.1. ICN-as-an-Overlay + +6.1.1. FP7 PURSUIT Efforts + + Although the FP7 PURSUIT [IEEE_Communications] efforts were generally + positioned as a Clean-slate ICN replacement of IP (Section 4.1), the + project realized its experimental testbed as an L2 VPN-based overlay + between several European, US, and Asian sites, following the overlay + deployment configuration presented in Section 4.2. Software-based + forwarders were utilized for the ICN message exchange, while native + ICN applications (e.g., for video transmissions) were showcased. At + the height of the project efforts, about 70+ nodes were active in the + (overlay) network with presentations given at several conferences, as + well as to the ICNRG. + +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 provides both 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, such as using UDP, HTTP, and even DTN + underlays. In its first prototypes and trials, NetInf was deployed + mostly in an HTTP embedding and in 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, leveraging NetInf's routing hint approach for + routing scalability [SAIL_Content_Delivery]. + +6.1.3. NDN Testbed + + The 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). However, 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]. ICN2020 has a specific focus to advance + ICN towards real-world deployments through applications, such as + video delivery, interactive videos, and social networks. The + federated testbed spans the USA, Europe, and Japan. Both NDN and + CCNx approaches are within the scope of the project. + + ICN2020 has released a set of interim public technical reports. The + report [ICN2020-Experiments] contains 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. 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. + +6.1.5. UMOBILE Efforts + + UMOBILE is another of the ICN research projects under the H2020 + research program [UMOBILE-overview]. The UMOBILE architecture + integrates the principles of DTN and ICN in a common framework to + support edge computing and mobile opportunistic wireless environments + (e.g., post-disaster scenarios and remote areas). The UMOBILE + architecture [UMOBILE-2] was developed on top of the NDN framework by + following the overlay deployment configuration of Section 4.2. + UMOBILE aims to extend Internet functionally by combining ICN and DTN + technologies. + + One of the key aspects of UMOBILE was the extension of the NDN + framework to locate network services (e.g., mobility management and + intermittent connectivity support) and user services (e.g., pervasive + content management) as close as possible to the end users to optimize + bandwidth utilization and resource management. Another aspect was + the evolution of the NDN framework to operate in challenging wireless + networks, namely in emergency scenarios [UMOBILE-3] and environments + with intermittent connectivity. To achieve this, the NDN framework + was leveraged with a new messaging application called Oi! + [UMOBILE-4] [UMOBILE-5], which supports intermittent wireless + networking. UMOBILE also implements a new data-centric wireless + routing protocol, DABBER [UMOBILE-6] [DABBER], which was designed + based on data reachability metrics that take availability of adjacent + wireless nodes and different data sources into consideration. The + contextual awareness of the wireless network operation is obtained + via a machine-learning agent running within the wireless nodes + [UMOBILE-7]. + + The consortium has completed several ICN deployment trials. In a + post-disaster scenario trial [UMOBILE-8], a special DTN face was + created to provide reachability to remote areas where there is no + typical Internet connection. Another trial was the ICN deployment + over the "Guifi.net" community network in the Barcelona region. This + trial focused on the evaluation of an ICN edge computing platform, + called PiCasso [UMOBILE-9]. In this trial, ten (10) Raspberry Pis + were deployed across Barcelona to create an ICN overlay network on + top of the existing IP routing protocol (e.g., qMp routing). This + trial showed that ICN can play a key role in improving data delivery + QoS and reducing the traffic in intermittent connectivity + environments (e.g., wireless community network). A third trial in + Italy was focused on displaying the capability of the UMOBILE + architecture to reach disconnected areas and assist responsible + authorities in emergencies, corresponding to an infrastructure + scenario. The demonstration encompassed 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 of the + H2020 research program. The efforts in the H2020 POINT and RIFE + projects follow the underlay deployment configuration in + Section 4.3.2; edge-based NAPs provide the IP/HTTP-level protocol + mapping onto ICN protocol exchanges, while the SDN underlay (or the + VPN-based L2 underlay) is used as a transport network. + + The multicast and service endpoint surrogate benefit in HTTP-based + scenarios, such as for HTTP-level streaming video delivery, and have + been demonstrated in the deployed POINT testbed with 80+ nodes being + utilized. Demonstrations of this capability have been given to the + ICNRG, and public demonstrations were also provided at events + [MWC_Demo]. The trial has also been accepted by the ETSI MEC group + as a public proof-of-concept demonstration. + + While the aforementioned demonstrations all use the overlay + deployment, H2020 also has performed ICN underlay trials. One such + trial involved commercial end users located in the PrimeTel network + in Cyprus with the use case centered on IPTV and HLS video + dissemination. Another trial was performed over the "Guifi.net" + community network in the Barcelona region, where the solution was + deployed in 40 households, providing general Internet connectivity to + the residents. Standard IPTV Set-Top Boxes(STBs), as well as HLS + video players, were utilized in accordance with the aim of this + deployment configuration, namely to provide application and service + migration. + +6.2.2. H2020 FLAME Efforts + + The H2020 Facility for Large-Scale Adaptive Media Experimentation + (FLAME) efforts concentrate on providing an experimental ground for + the aforementioned POINT/RIFE solution in initially two city-scale + locations, namely in Bristol and Barcelona. This trial followed the + underlay deployment configuration in Section 4.3.2, as per the POINT/ + RIFE approach. Experiments were conducted with the city/university + joint venture Bristol-is-Open (BIO) to ensure the readiness of the + city-scale SDN transport network for such experiments. Another trial + was for the ETSI MEC PoC. This trial showcased operational benefits + provided by the ICN underlay for the scenario of a location-based + game. These benefits aim at reduced network utilization through + improved video delivery performance (multicast of all captured videos + to the service surrogates deployed in the city at six locations), as + well as reduced latency through the play out of the video originating + from the local NAP, collocated with the Wi-Fi Access Point (AP) + instead of a remote server, i.e., 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, which includes the ICN capabilities, + integrated with NFV and SDN capabilities of the infrastructure. The + ultimate goal of these platform efforts is the full integration of + ICN into the overall media function platform for the provisioning of + advanced (media-centric) Internet services. + +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 within complex CDN server farms to leverage + ICN's superior in-network caching properties. This CDN based on + "island of ICN" is then used to service standard HTTP/IP-based + content retrieval requests coming from the general Internet. This + approach acknowledges that 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 + architecture proposed has not yet been tested experimentally but that + implementations are in process and expected in the 3-5 year time + frame. + +6.2.4. NDN IoT Trials + + [Baccelli] summarizes the trial of an NDN system adapted specifically + for a wireless IoT scenario. The trial was run with 60 nodes + distributed over several multistory buildings in a university campus + environment. 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 in terms of energy + consumption and for RAM and ROM footprints [Baccelli] [Anastasiades]. + For example, the binary file size reductions for NDN protocol stack + versus standard IP-based IoT protocol stack on given devices were 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 via a nationwide VPN-based + L2 underlay. The testbed uses the CCNx approach and is based on the + [CICN] open-source software. There are approximately 15 nodes spread + across the USA that connect to the testbed. The project's current + focus is to advance 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 meaning "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) and focuses on + the NFV MANO aspects to build an operational NDN network focusing on + important performance criteria, such as security, performance, and + interoperability. + + The data plane relies on an HTTP/NDN gateway [Marchal] that processes + HTTP traffic and transports it in an optimized way over NDN to + benefit from the properties of the NDN island (i.e., by mapping HTTP + semantics to NDN semantics within the NDN island). The testbed + carries real Web traffic of users and has been currently evaluated + with the top 1000 most popular websites. The users only need to set + the gateway as the web proxy. The control plane relies on a central + manager that uses machine-learning-based detection methods [Mai-1] + from the date gathered by distributed probes and applies orchestrated + countermeasures against NDN attacks [Nguyen-1] [Nguyen-2] [Mai-2] or + performance issues. A remediation can be, for example, the scale up + of a bottleneck component or the deployment of a security function, + like a firewall or a signature verification module. Test results + thus far have indicated that key attacks can be detected accurately. + For example, content poisoning attacks can be detected at up to 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 the ICN names are + mapped to IPv6 addresses and other ICN information is carried as + payload inside the IP packet. This allows standard (ICN-unaware) IP + routers to forward packets based on IPv6 info but enables ICN-aware + routers to apply ICN semantics. The intent is to enable rapid hybrid + deployments and seamless interconnection of IP and Hybrid ICN + domains. Hybrid ICN uses [CICN] open-source software. Initial tests + have been done with 150 clients consuming DASH videos, which showed + good scalability properties at the server side using the Hybrid ICN + transport [H-ICN_3] [H-ICN_2]. + +6.4. Summary of Deployment Trials + + In summary, there have been significant trials over the years with + all the major ICN protocol flavors (e.g., CCNx, NDN, and POINT) using + both the ICN-as-an-Overlay and ICN-as-an-Underlay deployment + configurations. The major limitations of the trials include the fact + that only a limited number of applications have been tested. + However, the tested applications include both native ICN and existing + IP-based applications (e.g., videoconferencing and IPTV). Another + limitation of the trials is that all of them involve less than 1k + users. + + Huawei and China Unicom have just started trials of the ICN-as- + a-Slice configuration to demonstrate ICN features of security, + mobility, and bandwidth efficiency over a wired infrastructure using + videoconferencing as the application scenario [Chakraborti]; also, + this prototype has been extended to demonstrate this over a 5G-NR + access. + + The Clean-slate ICN approach has obviously never been in trials, as + complete replacement of Internet infrastructure (e.g., existing + applications, TCP/IP protocol stack, IP routers, etc.) is no longer + considered a viable alternative. + + Finally, Hybrid ICN is a Composite-ICN approach that offers an + interesting alternative, as it allows ICN semantics to be embedded in + standard IPv6 packets so the packets can be routed through either IP + routers or Hybrid ICN routers. Note that some other trials, such as + the DOCTOR testbed (Section 6.2.6), could also be characterized as a + Composite-ICN approach, because it contains both ICN gateways (as in + ICN-as-an-Underlay) and virtualized infrastructure (as in ICN-as- + a-Slice). However, for the DOCTOR testbed, we have chosen to + characterize it as an ICN-as-an-Underlay configuration because that + is a 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 + addresses this open area by identifying key protocol functionality + that may be relevant for further standardization effort in the IETF. + The focus is specifically on identifying protocols that will + facilitate future interoperable ICN deployments correlating to the + scenarios identified in the deployment migration paths in Section 5. + The identified list of potential protocol functionality is not + exhaustive. + +7.1. Protocols for Application and Service Migration + + End-user applications and services need a standardized approach to + trigger ICN transactions. For example, in Internet and web + applications today, there are established socket APIs, communication + paradigms (such as REST), common libraries, and best practices. We + see a 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 issue in CDNs is to quickly find a location of a copy of the + object requested by an end user. In ICN, a Named Data Object (NDO) + is typically defined by its name. [RFC6920] defines a mechanism that + is 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(e.g., hash-digest-based names would normally not work), + and there is a lack of established conventions and standards. + + Another CDN issue for ICN is related to multicast distribution of + content. Existing CDNs have started using multicast mechanisms for + certain cases, such as for 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 that can + improve performance and availability in several scenarios. The ICN + in-network caching can augment managed CDN and improve its + performance. The details of the interplay between ICN caching and + managed CDN need further consideration. + +7.3. Protocols for Edge and Core Network Migration + + ICN provides the potential to redesign current edge and core network + computing approaches. Leveraging ICN's inherent security and its + ability to make name 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 in the + general Internet to ICN message exchanges in the ICN domain could be + used for the migration of application and services within deployments + at the network edge but also 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 if an approach like [RFC8613], + or some other approach, is suitable to preserve 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 and 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 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 support + of QoS in ICN networks. + + OAM is a crucial area that has not yet been fully addressed by the + ICN research community but which is obviously critical for future + deployments of ICN. 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 in the area + of ICN network path traceroute facility 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 the 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 Efforts + +8. Conclusion + + This document provides high-level deployment considerations for + current and future members of the ICN community. Specifically, the + major configurations of possible ICN deployments are identified 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 primarily fall + under the ICN-as-an-Overlay, ICN-as-an-Underlay, and Composite-ICN + configurations. + + In terms of deployment migration paths, ICN-as-an-Underlay offers a + clear migration path for CDN, edge, or core networks to go to an ICN + paradigm (e.g., for an IoT deployment) while leaving the critical + mass of existing end-user applications untouched. ICN-as-an-Overlay + is the easiest configuration to deploy rapidly, as it leaves the + underlying IP infrastructure essentially untouched. However, its + applicability for general deployment must be considered on a case-by- + case basis. (That is, can it support all required user + applications?). ICN-as-a-Slice is an attractive deployment option + for upcoming 5G systems (i.e., for 5G radio and core networks) that + will naturally support network slicing, but this still has to be + validated through more trial experiences. Composite-ICN, by its + nature, can combine some of the best characteristics of the other + configurations, but its applicability for general deployment must + again be considered on a case-by-case basis (i.e., can enough IP + routers be upgraded to support Composite-ICN functionality to provide + sufficient performance benefits?). + + There has been significant trial experience with all the major ICN + protocol flavors (e.g., CCNx, NDN, and POINT). However, only a + limited number of applications have been tested so far, and the + maximum number of users in any given trial has been less than 1k + users. It is recommended that future ICN deployments scale their + users gradually and closely monitor network performance as they go + above 1k users. A logical approach would be to increase the number + of users in a slowly increasing linear manner and monitor network + performance and stability, especially at every multiple of 1k users. + + Finally, this document describes a set of technical features in ICN + that warrant potential future IETF specification work. This will aid + initial and incremental deployments to proceed in an interoperable + manner. The fundamental details of the potential protocol + specification effort, however, are best left for future study by the + appropriate IETF WGs and/or BoFs. The ICNRG can aid this process in + the near and mid-term by continuing to examine key system issues like + QoS mechanisms, flexible naming schemes, and OAM support for ICN. + +9. IANA Considerations + + This document has no IANA actions. + +10. Security Considerations + + ICN was purposefully designed from the start to have certain + intrinsic security properties. The most well known of which are + authentication of delivered content and (optional) encryption of the + content. [RFC7945] has an extensive discussion of various aspects of + ICN security, including many that are relevant to deployments. + Specifically, [RFC7945] points out that ICN access control, privacy, + security of in-network caches, and protection against various network + attacks (e.g., DoS) have not yet been fully developed due to the lack + of a sufficient mass of deployments. [RFC7945] also points out + relevant advances occurring in the ICN research community that hold + promise to address each of the identified security gaps. Lastly, + [RFC7945] points out that as secure communications in the existing + Internet (e.g., HTTPS) become the norm, major gaps in ICN security + will inevitably slow down the adoption of ICN. + + In addition to the security findings of [RFC7945], this document has + highlighted that all anticipated ICN deployment configurations will + involve coexistence with existing Internet infrastructure and + applications. Thus, 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 alternative + would be to consider an approach similar to [RFC8613], which is used + to pass end-to-end encrypted content between HTTP and CoAP by an + application-layer security mechanism. Further investigation is + required to see if this approach is suitable to preserve ICN message + security through future protocol translation functions (e.g., ICN to + HTTP or CoAP to ICN) of gateways/proxies. + + Finally, the DOCTOR project discussed in Section 6.2.6 is an example + of an early deployment that is looking at specific attacks against + ICN infrastructure, in this case, 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 + + [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_nove + l_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>. + +Acknowledgments + + 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 very useful reviews and comments to the document. + + Special thanks to Dave Oran (ICNRG Co-chair) and Marie-Jose Montpetit + for their extensive and thoughtful reviews of the document. Their + reviews helped to immeasurably improve the document quality. + +Authors' Addresses + + 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.com |