ICNRG A. Rahman
Internet-Draft D. Trossen
Intended status: Informational InterDigital Inc.
Expires: March 9, 2019 D. Kutscher
R. Ravindran
September 5, 2018

Deployment Considerations for Information-Centric Networking (ICN)


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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on March 9, 2019.

Copyright Notice

Copyright (c) 2018 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

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 which 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.

However, so far outside of some preliminary investigations such as [I-D.paik-icn-deployment-considerations], 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. Finally, recommendations are made for potential future IETF standardization of key protocol functionality that will facilitate interoperable ICN deployments going forward.

2. Terminology

This document assumes readers are, in general, familiar with the terms and concepts that are defined in [RFC7927] and [I-D.irtf-icnrg-terminology]. In addition, this document defines the following terminology:

3. 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 various of these configurations (in Section 5), 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].

3.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 (e.g., existing applications which are typically tied directly to the TCP/IP protocol stack, IP routers, etc.). As such, existing routing hardware as well as ancillary services 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 (Named Data Networking Forwarding Daemon) [NFD], CCN routers [Jacobson] or 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, here SDN switches. Such SDN infrastructure upgrades, while being possibly utilized for a Clean-slate ICN deployment would not necessary be used exclusively for such deployments. Different proposals have been made for various ICN approaches to enable the operation over an SDN transport [Reed][CONET][C_FLOW].

3.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 such as 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 [I-D.kutscher-icnrg-netinf-proto]. Finally, [Overlay_ICN] describes an incremental approach to deploying an ICN architecture based on segregating ICN user and control plane traffic which is particularly well-suited to being overlaid on SDN based networks.

Regardless of the flavor, however, 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, ISIS) and ICN based ones. ICN-as-an-Overlay can be deployed over 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.

3.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 which 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.

3.3.1. Edge Network

Native ICN networks may be located at the edge of the network which allows the possibility of introducing new network architectures and protocols, and in this context ICN is an attractive option for newer deployments such as IoT [I-D.irtf-icnrg-icniot]. 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. Furthermore, ICN will allow enhancement of the role of gateways/proxies as ICN message security should be preserved through the protocol translation function of a gateway/proxy and thus offer a substantial gain.

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 use case scenario, the [VSER] platform shows the realization of a multi-party audio/video conferencing service over such a edge cloud deployment of ICN routers realized over commodity hardware platforms. This platform has also been extended to offer seamless mobility and mobility as a service [VSER-Mob] features.

3.3.2. Core Network

In this sub-option, 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 network attachment point, such as realized in access points or customer premise equipment, which in turn provides a standard IP interface to existing user devices. Towards peering networks, such network attachment point turns into a modified border gateway/proxy, preserving the perception of an IP-based core network towards any peering network.

The work in [White] proposes a similar deployment configuration. Here, the target is the use of ICN for content distribution within CDN server farms, i.e., 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.

3.4. ICN-as-a-Slice

The objective of Network slicing [NGMN]is to multiplex a general pool of compute, storage and bandwidth resources among multiple service networks with exclusive SLA requirements on transport level QoS and security. This is enabled through NFV and SDN technology functions that enables 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 network enabling dynamic slicing of air interface spectrum resources among various services hence naturally extending itself to end points and also cloud resources, across multiple domains, to offer end-to-end guarantees. These slices once instantiated could include a mix of connectivity services like LTE-as-a-service or OTT services like VoD or other IoT services through composition of a group of virtual and/or physical network functions at control, user and service plane level. Such a framework can also be used to realize ICN slices with its own control, service and forwarding plane over which one or more end-user services can be delivered.

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, or 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 [I-D.ravi-icnrg-5gc-icn]. Such a generalized network slicing framework should be able to offer service slices to be realized using both IP and ICN. Coupled with the view of ICN functions as being "chained service functions" [RFC7665], an ICN deployment within such a slice could also be realized within the emerging orchestration 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 an 5G-ICN instance [Ravindran].

At the level of the specific technologies involved, such as ONAP [ONAP] that 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 with SDN as a data plane forwarding function, as briefly discussed in Section 3.1. Further cross domain ICN slices can also be realized using frameworks such as [ONAP].

3.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.

4. Deployment Migration Paths

After outlining the various ICN deployment configurations in Section 3, we now focus on the various migration paths that will have importance to the various stakeholders that are usually involved in the deployment of a technology at (ultimately) large scale. We can identify these stakeholders as: [Tateson], [Techno_Economic] and [Internet_Pricing] are left out of our discussion.

Note that our presentation purely focuses on technological aspects of such migration. Economic or regulatory aspects, such as studied in

4.1. Application and Service Migration

The internet is full of applications and services, utilizing the innovation capabilities of 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 the hypertext transfer protocol. 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 options presented in Section 3.3.2 and Section 3.3.1 aim at providing some level of backward compatibility to this existing ecosystem through a proxy based message flow mapping mechanism (e.g., mapping of existing HTTP/TCP/IP message flows to HTTP/TCP/IP/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 over NDN to guarantee a high level of compatibility with HTTP while enabling an efficient caching of Data in the ICN island.

Alternatively, ICN as an overlay (Section 3.2), as well as ICN-as-a-Slice (Section 3.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.

Finally, [I-D.irtf-icnrg-icn-lte-4g] outlines a dual-stack end user device approach that is applicable for all deployment configurations. Specifically, [I-D.irtf-icnrg-icn-lte-4g] introduces middleware layers (called the Transport Convergence Layer, 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 signalling with the network to determine which protocol stack instance and associated middleware adaptation layers to utilize for a given application transaction.

4.2. Content Delivery Network Migration

A significant number of services and applications are devoted to content delivery in some form, either as video delivery services, social media platforms, and many others. Content delivery networks (CDNs) are deployed to assist these services through localizing the content requests and therefore reducing latency and possibly increase utilization of available bandwidth as well as reducing the load on origin servers. Similar to the previous sub-section, the underlay deployment configurations presented in Section 3.3.2 and Section 3.3.1 aim at providing a migration path for existing CDNs. This is also highlighted in the BIER WG use case document [I-D.ietf-bier-use-cases], specifically with potential benefits in terms of utilizing multicast in the delivery of content but also reducing load on origin as well as delegation server. We return to this benefit in the trial experiences in Section 5.

4.3. Edge Network Migration

Edge networks often see the deployment of novel network level technology, e.g., in the space of IoT. Such IoT deployments have for many years 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 3.3.1, application gateways/proxies can integrate such edge deployments into IP-based services, e.g., utilizing CoAP [RFC7252] based machine-to-machine (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. With the proliferation of network softwarization (using technologies like service orchestration frameworks leveraging NFV and SDN concepts) access networks and other network segments, the ICN-as-a-Slice deployment configuration in Section 3.4 provides a suitable migration path for integration non-IP-based edge networks into the overall system through virtue of realizing the relevant (ICN) protocols in an access network slice.

4.4. Core Network Migration

Migrating core networks (e.g., of the Internet or Mobile core network) requires not only significant infrastructure renewal but also the fulfillment of the significant performance requirements, particularly in terms of throughput. For those parts of the core network that would see a migration to an SDN-based optical transport the ICN-as-a-Slice deployment configuration in Section 3.4 could see the introduction of native ICN solutions within slices provided by the SDN-enabled transport network or as virtual network functions, allowing for isolating the ICN traffic while addressing the specific ICN performance benefits and constraints within such isolated slice. For ICN solutions that natively work on top of SDN, the underlay deployment configuration in Section 3.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).

5. Deployment Trial Experiences

In this section, we will outline trial experiences, often conducted within international collaborative project efforts. Our focus here is on the realization of the various deployment configurations in Section 3, and we therefore 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 presentation to retain the focus on real life experiences.

5.1. ICN-as-an-Overlay

5.1.1. FP7 PURSUIT Efforts

Although the FP7 PURSUIT [IEEE_Communications] efforts were generally positioned as a Clean-slate ICN replacement of IP (Section 3.1), the project realized its experimental test bed as an L2 VPN-based overlay between several European, US as well as Asian sites, i.e., following the overlay deployment configuration presented in Section 3.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.

5.1.2. FP7 SAIL Trial

The Network of Information (NetInf) is the approach to Information-Centric Networking developed by the European Union (EU) FP7 SAIL project (http://www.sail-project.eu/). 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 abstraction. 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 3.2. Reference [SAIL_NetInf] describes several trials including a stadium environment large crowd scenario and a multi-site testbed, leveraging NetInf’s Routing Hint approach for routing scalability.

5.1.3. NDN Testbed

The Named Data Networking (NDN) is one of the research projects funded by the National Science Foundation (NSF) of the USA as part of the Future Internet Architecture Program. The original NDN proposal was positioned as a Clean-slate ICN replacement of IP (Section 3.1). However, in several trials, NDN generally follows the overlay deployment configuration of Section 3.2 to connect institutions over the public Internet across several continents. The use cases covered in the trials include real-time video-conferencing, geo-locating, and interfacing to consumer applications. Typical trials involve up to 100 NDN enabled nodes (https://named-data.net/ndn-testbed/) [Jangam].

5.1.4. ICN2020 Efforts

ICN2020 is an ICN related research project funded by the EU and Japan as part of the H2020 research and innovation program and NICT (http://www.icn2020.org/). ICN2020 has a specific focus to advance ICN towards real-world deployments through innovative applications and global scale experimentation. Both NDN and CCN approaches are within the scope of the project.

ICN2020 was kicked off in July 2016 and at the end of the first year released a set of public technical reports [ICN2020]. The report titled "Deliverable D4.1: 1st yearly report on Testbed and Experiments (WP4)" contains a detailed description of the progress made in both local testbeds as well as federated testbeds. The plan for the federated testbed includes integrating the NDN testbed, the CUTEi testbed [RFC7945] [CUTEi] and the GEANT testbed (https://www.geant.org/) to create an overlay deployment configuration of Section 3.2 over the public Internet.

5.1.5. UMOBILE Efforts

UMOBILE (universal mobile-centric and opportunistic communications architecture) is one of the ICN research projects under the H2020 framework program (http://www.umobile-project.eu/). The UMOBILE architecture integrates the principles of Delay Tolerant Networking (DTN) and ICN in a common framework to support edge computation 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 3.2. UMOBILE aims to advance networking technologies and architectures. In particular, extending Internet functionally – by combining ICN and DTN technologies; geographically – by allowing for inter-networking over remote and isolated areas; and social aspects – by allowing low-cost access and free user-to-user networking.

One of the innovative aspects of UMOBILE was the extension of the NDN framework to encompass push network services (e.g., mobility management, intermittent connectivity support) and user services (e.g., pervasive content management) as close as possible to the end-users to optimise bandwidth utilization and resource management. Another innovation was the evolution of the NDN framework to operate in wireless networks, namely in emergency scenarios [UMOBILE-3], using secure, reliable wireless services able to operate even with intermittent connectivity. To achieve such a goal, the NDN framework was leveraged with a messaging system based on a new application, called Oi! [UMOBILE-4], which uses two methods of push communication based on a new branch of NDN Android, called NDN-OPP [UMOBILE-5] that supports intermittent wireless networking. NDN-OPP implements a new data-centric wireless routing protocol, DABBER [UMOBILE-6] [I-D.mendes-icnrg-dabber], which was designed based on data reachability metrics that take into consideration availability and centrality of adjacent wireless nodes, as well as the availability of different data sources. The contextual-awareness about the operation of the wireless network is obtained in a self-learning approach, by a software-based agent, the Contextual Manager, running within the wireless node [UMOBILE-7].

During the project time (Feb 2015 - Apr 2018), the consortium completed some couple of significant ICN deployment trails. One of that was related to the post disaster scenario. In this trial [UMOBILE-8], a special DTN face was created to provide reachability to remote area where there is no typical Internet connection. Another trail was the ICN deployment over the Guifi.net community network. This trial focused on the evaluation of ICN edge computing platform, called PiCasso [UMOBILE-9] which is a part of UMOBILE project. In this trial, ten(10) raspberry Pis were deployed across the Sants area of Barcelona to create an ICN overlay network on top of the existing IP routing protocol (e.g., qMp routing). Through the evaluation of this trail, it shows that ICN plays a key role in improving the quality of service delivery as well as reducing the traffic consumption in the intermittent connectivity environment (e.g., wireless community network). A third trial was focused on displaying the capability of the UMOBILE architecture to reach disconnected areas and assist responsible authorities in challenged events, corresponding to an infrastructure scenario. This trial was conducted in April 2018 in Italy, with the patronage of the Civil Protection Department of Umbria Region. In an outdoor demonstration, it was shown how to overcome a low or missing connectivity, thus allowing users to communicate, especially in emergency situations as the one simulated during the demo. The demonstration encompasses seven (7) end-user devices, one (1) access-point, and one (1) gateway. An extended demonstration to the Portuguese Civil protection authority in March 2018, included also an UAV carrying a UMOBILE raspberry Pi that served as relay and carrier of information.

5.2. ICN-as-an-Underlay

5.2.1. H2020 POINT and RIFE Efforts

POINT and RIFE are two more ICN related research projects funded by the EU as part of the H2020 effort. The efforts in the H2020 POINT+RIFE projects follow the underlay deployment configuration in Section 3.3.2, although this is mixed with utilizing an overlay deployment to provide multi-national connectivity. However, underlay SDN-based deployments do exist at various project partner sites, e.g., at Essex University, without any overlaying being realized. Edge-based network attachment points (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 as well as service endpoint surrogate benefits in HTTP-based scenarios, such as for HTTP-level streaming video delivery, have been demonstrated in the deployed POINT test bed with 80+ nodes being utilized. Demonstrations of this capability have been given to the ICNRG in 2016, and public demonstrations were also provided at events such as Mobile World Congress in 2016 [MWC_Demo]. The trial has also been accepted by the ETSI MEC group as a proof-of-concept with a demonstration at the ETSI MEC World Congress in 2016.

While the afore-mentioned 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 in the community network of "guifi.net" in the Barcelona region, where the solution was deployed in 40 households, providing general Internet connectivity to the residents. Standard IPTV 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.

5.2.2. H2020 FLAME Efforts

The H2020 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 3.3.2 as per 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 playout of the video originating from the local NAP instead of a remote server.

Ensuring the technology readiness and the early trialing of the ICN capabilities lays the ground for the goal of the H2020 FLAME efforts to conduct 23 large-scale experiments in the area of Future Media Internet (FMI) throughout 2018 and 2019. Standard media service functions as well as applications will ultimately utilize the ICN underlay in the delivery of their experience. The platform, which includes the ICN capabilities, will utilize concepts of SFC, 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.

5.2.3. CableLabs Content Delivery System

The work in [White] proposes an underlay deployment configuration based on Section 3.3.2. The use case is ICN for content distribution within CDN server farms (which can be quite large and complex) to leverage ICN's superior in-network caching properties. This "island of ICN" based CDN is then used to service standard HTTP/IP-based content retrieval request coming from the general Internet. This approach acknowledges that whole scale replacement (see Section 3.1) of existing HTTP/IP end user applications and related Web infrastructure is a difficult proposition. [White] does not yet provide results but indicated that experiments will be forthcoming.

5.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 multi-story 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].

5.2.5. NREN ICN Testbed

The National Research and Education Network (NREN) ICN Testbed is a project sponsored by Cisco, Internet2, and the U.S. Research and Education community. Participants include universities and US federal government entities that connect via a nation-wide VPN-based L2 underlay. The testbed uses the CCN approach and is based on the [CICN] open source software. There are approximately 15 nodes spread across the USA which 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.

5.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 Management and Orchestration (MANO) aspects to build an operational NDN network regarding essential criteria such as security, performance and interoperability.

The data-plane relies on a 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. The testbed carries real Web traffic of users, and has been currently evaluated with the top-1000 most popular Web sites. The users only need to set the gateway as the Web proxy. The control-plane relies on a central manager which uses machine learning based detection methods [Mai-1] from the date gathered by distributed probes and applies orchestrated counter-measures 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. The end target of the project is to have a future complete testbed where the developed concepts will be implemented, monitored and validated.

5.3. Composite-ICN Approach

5.3.1. Hybrid ICN Trials

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 (HTTP) videos which showed good scalability properties at the Server Side using the Hybrid ICN transport [H-ICN_3] [H-ICN_2].

5.4. Summary of Deployment Trials

In summary, there have been significant trials over the years with all the major ICN protocol flavors (e.g., CCN, NDN, 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. video-conferencing and IPTV). Another limitation of the trials is that all of them involve less than 1000 users maximum.

The ICN-as-a-Slice configuration still has not be trialled primarily due to the fact that 5G standards are still in flux and not expected to be stable before the 2019 time frame. The Clean-slate ICN approach has obviously never been trialled 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 and 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 5.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.

6. Deployment Issues Requiring Further Standardization

The 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 that may be relevant for further standardization effort in 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 4. The identified list of potential protocol functionality is not exhaustive.

6.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.

6.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. There already exists [RFC6920] that is suitable for static naming of ICN data objects. Other ways of encoding and representing ICN names have been described in [I-D.irtf-icnrg-ccnxmessages] and [I-D.mosko-icnrg-ccnxurischeme]. Naming dynamically generated data requires different approaches (for example, hash digest based names would normally not work), and there is 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 broadcast streaming TV. However, as discussed in Section 5.2.1, certain ICN approaches provide substantial improvements over IP multicast, such as the implicit support for multicast retrieval of content in all ICN flavours.

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.

6.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 secure, yet light-weight 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. However, as mentioned previously, ICN will allow us to evolve the role of gateways/proxies as ICN message security should be preserved through the protocol translation function of a thus offer a substantial gain.

Interaction and interoperability between existing IP routing protocols (e.g., OSPF, RIP, ISIS) and ICN routing approaches(e.g., NFD, CCN routers) are expected especially in the overlay approach. Another important topic is integration of ICN into networks that support virtualized infrastructure in the form of NFV/SDN and most likely utilizing Service Function Chaining (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 Differentiated Services (DiffServ), Integrated Services (IntServ) and Resource Reservation Protocol (RSVP). Some initial ideas for QoS support in ICN networks are outlined in [I-D.moiseenko-icnrg-flowclass] which proposes a flow classification based approach to enable functions such ICN rate control and cache control. Also [I-D.anilj-icnrg-icn-qos] proposes how to use DiffServ DSCP codes to support QoS for ICN based data path delivery. Further work is required to identify the best approaches and alternatives for support of QoS in ICN networks .

Operations and Maintenance (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 modelling 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 CCNinfo [I-D.asaeda-icnrg-ccninfo] [Contrace].

6.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.

Mapping of ICN Gaps to Potential Protocol Efforts
ICN Gap Potential Protocol Effort
1-Support of HTTP/CoAP support of ICN semantics
2-Naming Dynamic naming of ICN data objects
3-Routing Interactions between IP and ICN routing protocols
4-Multicast Multicast enhancements for ICN
5-In-network ICN Cache placement and sharing
6-NFV/SDN Integration of ICN with NFV/SDN and including
support possible impacts to SFC
7-ICN Mapping of HTTP and other protocols onto ICN
mapping message exchanges (and vice-versa) while preserving ICN message security
8-QoS Support of ICN QoS via mechanisms such as DiffServ
support and flow classification
9-OAM YANG models, NETCONF/RESTCONF protocols,
support and network performance measurements

7. Conclusion

This document provides high level deployment considerations for 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 and core networks to go to an ICN paradigm (e.g., for an IoT deployment). ICN-as-an-Overlay is probably 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 (e.g., based on if it can run all required applications or other similar criteria). ICN-as-a-Slice is an attractive deployment option for future 5G systems (i.e., for 5G radio and core networks) which will naturally support network slicing, but this still has to be validated through actual 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 be considered on a case by case basis.

For the crucial issue of existing application and service migration to ICN, various mapping schemes are possible to mitigate impacts. For example, HTTP/TCP/IP flows may be mapped to/from ICN message flows at proxies in the ICN-as-an-Underlay configurations leaving the massive number of existing end point applications/services untouched or minimally impacted. Also dual stack end user devices that include middleware to allow applications to communicate in both ICN mode and standard IP mode are an attractive proposition for gradual and geographically discontinuous introduction for all deployment configurations.

There has been significant trial experience with all the major ICN protocol flavors (e.g., CCN, NDN, 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 1000 users. It is recommended that future ICN deployments scale their users gradually and closely monitor network performance as they go above 1000 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.

8. IANA Considerations

This document requests no IANA actions.

9. 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 which 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) becomes the norm, that 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 co-existence 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 3.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.

Finally, the Doctor project discussed in Section 5.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] and evaluation of potential counter-measures based on MANO orchestrated actions on the virtualized infrastructure [Mai-1] .

10. Acknowledgments

The authors want to thank Alex Afanasyev, Mayutan Arumaithurai, Hitoshi Asaeda, Giovanna Carofiglio, Xavier de Foy, Guillaume Doyen, Hannu Flinck, Anil Jangam, Michael Kowal, Adisorn Lertsinsrubtavee, Paulo Mendes, Luca Muscariello, Dave Oran, Thomas Schmidt, Jan Seedorf, Eve Schooler, Samar Shailendra, Milan Stolic, Prakash Suthar, Atsushi Tagami, and Lixia Zhang for their very useful reviews, comments and input to the document.

11. Informative References

[Anastasiades] Anastasiades, C., "Information-centric communication in mobile and wireless networks", PhD Dissertation, 2016.
[Baccelli] Baccelli, E. and et al., "Information Centric Networking in the IoT: Experiments with NDN in the Wild", ACM 20164, Paris, France, 2014.
[C_FLOW] Suh, J. and et al., "C_FLOW: Content-Oriented Networking over OpenFlow", Open Networking Summit, April, 2012.
[CCNx_UDP] PARC, "CCNx Over UDP", 2015.
[CICN] CICN, "Community Information-Centric Networking (CICN)", 2017.
[CONET] Veltri, L. and et al., "CONET Project: Supporting Information-Centric Functionality in Software Defined Networks", Workshop on Software Defined Networks, , 2012.
[Contrace] Asaeda, H. and et al., "Contrace: A Tool for Measuring and Tracing Content-Centric Networks", IEEE Communications Magazine, Vol.53, No.3 , 2015.
[CUTEi] Asaeda, H. and N. Choi, "Container-Based Unified Testbed for Information Centric Networking", IEEE Network, Vol.28, No.6 , 2014.
[DASH] DASH, "DASH Industry Forum", 2017.
[Doctor] Doctor, "Deployment and Securisation of new Functionalities in Virtualized Networking Environments (Doctor)", 2017.
[fiveG-23501] 3gpp-23.501, "Technical Specification Group Services and System Aspects; System Architecture for the 5G System (Rel.15)", 3GPP , 2017.
[fiveG-23502] 3gpp-23.502, "Technical Specification Group Services and System Aspects; Procedures for the 5G System (Rel.15)", 3GPP , 2017.
[H-ICN_1] Cisco, "Hybrid ICN: Cisco Announces Important Steps toward Adoption of Information-Centric Networking", 2017.
[H-ICN_2] Cisco, "Mobile Video Delivery with Hybrid ICN: IP-Integrated ICN Solution for 5G", 2017.
[H-ICN_3] Muscariello, L. and et al., "Hybrid Information-Centric Networking: ICN inside the Internet Protocol", 2018.
[H-ICN_4] MSardara, M. and et al., "(h)ICN Socket Library for HTTP: Leveraging (h)ICN socket library for carrying HTTP messages", 2018.
[I-D.anilj-icnrg-icn-qos] Jangam, A., suthar, P. and M. Stolic, "Supporting QoS aware Data Delivery in Information Centric Networks", Internet-Draft draft-anilj-icnrg-icn-qos-00, July 2018.
[I-D.asaeda-icnrg-ccninfo] Asaeda, H. and X. Shao, "CCNinfo: Discovering Content and Network Information in Content-Centric Networks", Internet-Draft draft-asaeda-icnrg-ccninfo-01, June 2018.
[I-D.ietf-bier-use-cases] Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., Przygienda, T., Gulko, A., Robinson, D., Arya, V. and C. Bestler, "BIER Use Cases", Internet-Draft draft-ietf-bier-use-cases-07, July 2018.
[I-D.irtf-icnrg-ccnxmessages] Mosko, M., Solis, I. and C. Wood, "CCNx Messages in TLV Format", Internet-Draft draft-irtf-icnrg-ccnxmessages-08, July 2018.
[I-D.irtf-icnrg-icn-lte-4g] suthar, P., Stolic, M., Jangam, A., Trossen, D. and R. Ravindran, "Native Deployment of ICN in LTE, 4G Mobile Networks", Internet-Draft draft-irtf-icnrg-icn-lte-4g-01, July 2018.
[I-D.irtf-icnrg-icniot] Ravindran, R., Zhang, Y., Grieco, L., Lindgren, A., Raychadhuri, D., Baccelli, E., Burke, J., Wang, G., Ahlgren, B. and O. Schelen, "Design Considerations for Applying ICN to IoT", Internet-Draft draft-irtf-icnrg-icniot-01, February 2018.
[I-D.irtf-icnrg-terminology] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, D. and C. Tschudin, "Information-Centric Networking (ICN): CCN and NDN Terminology", Internet-Draft draft-irtf-icnrg-terminology-00, December 2017.
[I-D.irtf-nfvrg-gaps-network-virtualization] Bernardos, C., Rahman, A., Zuniga, J., Contreras, L., Aranda, P. and P. Lynch, "Network Virtualization Research Challenges", Internet-Draft draft-irtf-nfvrg-gaps-network-virtualization-10, September 2018.
[I-D.kutscher-icnrg-netinf-proto] Kutscher, D., Farrell, S. and E. Davies, "The NetInf Protocol", Internet-Draft draft-kutscher-icnrg-netinf-proto-01, February 2013.
[I-D.mendes-icnrg-dabber] Mendes, P., Sofia, R., Tsaoussidis, V., Diamantopoulos, S. and C. Sarros, "Information-centric Routing for Opportunistic Wireless Networks", Internet-Draft draft-mendes-icnrg-dabber-01, August 2018.
[I-D.moiseenko-icnrg-flowclass] Moiseenko, I. and D. Oran, "Flow Classification in Information Centric Networking", Internet-Draft draft-moiseenko-icnrg-flowclass-02, July 2018.
[I-D.mosko-icnrg-ccnxurischeme] marc.mosko@parc.com, m. and c. cwood@parc.com, "The CCNx URI Scheme", Internet-Draft draft-mosko-icnrg-ccnxurischeme-01, April 2016.
[I-D.paik-icn-deployment-considerations] Paik, E., Yun, W., Kwon, T. and h. hgchoi@mmlab.snu.ac.kr, "Deployment Considerations for Information-Centric Networking", Internet-Draft draft-paik-icn-deployment-considerations-00, July 2013.
[I-D.ravi-icnrg-5gc-icn] Ravindran, R., suthar, P., Trossen, D. and G. White, "Enabling ICN in 3GPP's 5G NextGen Core Architecture", Internet-Draft draft-ravi-icnrg-5gc-icn-02, July 2018.
[ICN2020] ICN2020, "ICN2020 Deliverables", 2017.
[ICNRGCharter] NDN, "Information-Centric Networking Research Group Charter", 2013.
[IEEE_Communications] Trossen, D. and G. Parisis, "Designing and Realizing an Information-Centric Internet", Information-Centric Networking, IEEE Communications Magazine Special Issue, 2012.
[Internet_Pricing] Trossen, D. and G. KBiczok, "Not Paying the Truck Driver: Differentiated Pricing for the Future Internet", ReArch Workshop in conjunction with ACM Context, December, 2010.
[Jacobson] Jacobson, V. and et al., "Networking Named Content", Proceedings of ACM Context, , 2009.
[Jangam] Jangam, A. and et al., "Porting and Simulation of Named-data Link State Routing Protocol into ndnSIM", ACM DIVANet'17, Miami Beach, USA, 2017.
[Mai-1] Mai, H., Aouadj, M., Doyen, G., Kondo, D., Marchal, X., Cholez, T., Montes de Oca, E. and W. Mallouli, "Implementation of Content Poisoning Attack Detection and Reaction in Virtualized NDN Networks", 21st Conference on Innovation in Clouds, Internet and Networks, ICIN 2018 (demo paper) IEEE, 2018.
[Mai-2] Mai, H., Nguyen, T., Doyen, G., Cogranne, R., Mallouli, W., Montes de Oca, E. and O. Festor, "Towards a Security Monitoring Plane for Named Data Networking: Application to Content Poisoning Attack", Proceedings of the 2018 IEEE/IFIP Symposium on Network Operations and Management (NOMS) IEEE, 2018.
[Marchal] Marchal, X., El Aoun, M., Mathieu, B., Cholez, T., Doyen, G., Mallouli, W. and O. Festor, "Leveraging NFV for the Deployment of NDN: Application to HTTP Traffic Transport", Proceedings of the 2018 IEEE/IFIP Symposium on Network Operations and Management (NOMS), 2018.
[Moiseenko] Moiseenko, I. and D. Oran, "TCP/ICN : Carrying TCP over Content Centric and Named Data Networks", 2016.
[MWC_Demo] InterDigital, "InterDigital Demo at Mobile World Congress (MWC)", 2016.
[NFD] NDN, "NFD - Named Data Networking Forwarding Daemon", 2017.
[NGMN] NGMN, "NGMN 5g Initiative White Paper", 2015.
[Nguyen-1] Nguyen, T., Marchal, X., Doyen, G., Cholez, T. and R. Cogranne, "Content Poisoning in Named Data Networking: Comprehensive Characterization of real Deployment", Proceedings of the 15th IEEE/IFIP International Symposium on Integrated Network Management, 2017.
[Nguyen-2] Nguyen, T., Cogranne, R. and G. Doyen, "An Optimal Statistical Test for Robust Detection against Interest Flooding Attacks in CCN", Proceedings of the 14th IEEE/IFIP International Symposium on Integrated Network Management, 2015.
[ONAP] ONAP, "Open Network Automation Platform", 2017.
[oneM2M] OneM2M, "oneM2M Service Layer Standards for M2M and IoT", 2017.
[Overlay_ICN] Shailendra, S. and et al., "A Novel Overlay Architecture for Information Centric Networking", 2016.
[POINT] Trossen, D. and et al., "POINT: IP Over ICN - The Better IP?", European Conference on Networks and Communications (EuCNC), , 2015.
[Ravindran] Ravindran, R., Chakraborti, A., Amin, S., Azgin, A. and G. Wang, "5G-ICN : Delivering ICN Services over 5G using Network Slicing", IEEE Communication Magazine, May, 2016.
[Reed] Reed, M. and et al., "Stateless Multicast Switching in Software Defined Networks", ICC 2016, Kuala Lumpur, Malaysia, 2016.
[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.
[RFC7252] Shelby, Z., Hartke, K. and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014.
[RFC7426] Haleplidis, E., Pentikousis, K., 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.
[RFC7665] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015.
[RFC7927] Kutscher, D., 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.
[RFC7945] Pentikousis, K., Ohlman, B., Davies, E., Spirou, S. and G. Boggia, "Information-Centric Networking: Evaluation and Security Considerations", RFC 7945, DOI 10.17487/RFC7945, September 2016.
[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.
[SAIL_NetInf] FP7, "SAIL Prototyping and Evaluation", 2013.
[Tateson] Tateson, J. and et al., "Final Evaluation Report on Deployment Incentives and Business Models", 2010.
[Techno_Economic] Trossen, D. and A. Kostopolous, "Techno-Economics Aspects of Information-Centric Networking", Journal for Information Policy, Volume 2, 2012.
[UMOBILE-2] Sarros, C., Diamantopoulos, S., Rene, S., Psaras, I., Lertsinsrubtavee, A., Molina-Jimenez, C., Mendes, P., Sofia, R., Sathiaseelan, A., Pavlou, G., Crowcroft, J. and V. Tsaoussidis, "Connecting the Edges: A Universal, Mobile-Centric, and Opportunistic Communications Architecture", IEEE Communications Magazine, vol. 56, February 2018.
[UMOBILE-3] Tavares, M., Aponte, O. and P. Mendes, "Named-data Emergency Network Services", Proc. of ACM MOBISYS, Munich, Germany, June 2018.
[UMOBILE-4] Lopes, L., Sofia, R., Mendes, P. and W. Moreira, "Oi! - Opportunistic Data Transmission Based on Wi-Fi Direct", Proc. of IEEE INFOCOM, San Francisco, USA, April 2016.
[UMOBILE-5] Dynerowicz, S. and P. Mendes, "Named-Data Networking in Opportunistic Networks", Proc. of ACM ICN, Berlin, Germany, September 2017.
[UMOBILE-6] Mendes, P., Sofia, R., Tsaoussidis, V., Diamantopoulos, S. and C. Sarros, "Information-centric Routing for Opportunistic Wireless Networks", Proc. of ACM ICN, Boston, USA, September 2018.
[UMOBILE-7] Sofia, R., "The UMOBILE Contextual Manager Service. Technical Report. Technical Report Senception 001, 2018 (base for UMOBILE deliverable D4.5 - Report on Data Collection and Inference Models", 2018.
[UMOBILE-8] Sarros, C., Lertsinsrubtavee, A., Molina-Jimenez, C., Prasopoulos, K., Diamantopoulos, S., Vardalis, D. and A. Sathiaseelan, "ICN-based edge service deployment in challenged networks", Proceedings of the 4th ACM Conference on Information-Centric Networking (ICN '17). ACM, New York, NY, USA, 2017 .
[UMOBILE-9] Lertsinsrubtavee, A., Selimi, M., Sathiaseelan, A., Cerdà-Alabern, L., Navarro, L. and J. Crowcroft, "Information-Centric Multi-Access Edge Computing Platform for Community Mesh Networks", Proceedings of the 1st ACM SIGCAS Conference on Computing and Sustainable Societies (COMPASS '18). ACM, New York, NY, USA, 2018 .
[VSER] Ravindran, R., Liu, X., Chakraborti, A., Zhang, X. and G. Wang, "Towards software defined ICN based edge-cloud services", CloudNetworking(CloudNet), IEEE Internation Conference on, IEEE Internation Conference on CloudNetworking(CloudNet), 2013.
[VSER-Mob] Azgin, A., Ravindran, R., Chakraborti, A. and G. Wang, "Seamless Mobility as a Service in Information-centric Networks", ACM ICN Sigcomm, IC5G Workshop, 2016.
[White] White, G. and G. Rutz, "Content Delivery with Content Centric Networking, CableLabs White Paper", 2010.

Appendix A. Change Log

[Note to RFC Editor: Please remove this section before publication.]

Changes from draft-irtf-rev-03 to draft-irtf-rev-04:

Changes from draft-irtf-rev-02 to draft-irtf-rev-03:

Changes from draft-irtf-rev-01 to draft-irtf-rev-02:

Changes from draft-irtf-rev-00 to draft-irtf-rev-01:

Changes from draft-rahman-rev-05 to draft-irtf-rev-00:

Changes from rev-04 to rev-05:

Authors' Addresses

Akbar Rahman InterDigital Inc. 1000 Sherbrooke Street West, 10th floor Montreal, H3A 3G4 Canada EMail: Akbar.Rahman@InterDigital.com URI: http://www.InterDigital.com/
Dirk Trossen InterDigital Inc. 64 Great Eastern Street, 1st Floor London, EC2A 3QR United Kingdom EMail: Dirk.Trossen@InterDigital.com URI: http://www.InterDigital.com/
Dirk Kutscher Huawei German Research Center Riesstrasse 25 Munich, 80992 Germany EMail: ietf@dkutscher.net URI: http://www.Huawei.com/
Ravi Ravindran Huawei Research Center 2330 Central Expressway Santa Clara, 95050 USA EMail: ravi.ravindran@huawei.com URI: http://www.Huawei.com/