wdiff rfc8763.original rfc8763.txt

ICNRG

Internet Research Task Force (IRTF) A. Rahman
Internet-Draft
Request for Comments: 8763 InterDigital Communications, LLC
Intended status:
Category: Informational D. Trossen
Expires: March 6, 2020 InterDigital Europe, Ltd
ISSN: 2070-1721 Huawei
D. Kutscher
Emden University of Applied Sciences Emden/Leer
R. Ravindran
Futurewei
September 3, 2019
Sterlite Technologies
April 2020

Deployment Considerations for Information-Centric Networking (ICN)
draft-irtf-icnrg-deployment-guidelines-07

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 described, including the key
overlay and underlay approaches. Then Then, proposed deployment migration
paths are outlined to address major practical issues 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 Internet-Draft document is submitted in full conformance with 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
provisions results of BCP 78 Internet-related research
and BCP 79.

Internet-Drafts are working documents 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 Engineering Research 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
(IRTF). Documents approved for publication by the IRSG are not a maximum
candidate for any level of six months 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 updated, replaced, or obsoleted by other documents obtained 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 6, 2020.
https://www.rfc-editor.org/info/rfc8763.

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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Acronyms Abbreviations List . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Deployment Configurations . . . . . . . . . . . . . . . . . . 8
4.1. Clean-slate Clean-Slate ICN . . . . . . . . . . . . . . . . . . . . . 8
4.2. ICN-as-an-Overlay . . . . . . . . . . . . . . . . . . . . 8
4.3. ICN-as-an-Underlay . . . . . . . . . . . . . . . . . . . 9
4.3.1. Edge Network . . . . . . . . . . . . . . . . . . . . 9
4.3.2. Core Network . . . . . . . . . . . . . . . . . . . . 10
4.4. ICN-as-a-Slice . . . . . . . . . . . . . . . . . . . . . 10
4.5. Composite-ICN Approach . . . . . . . . . . . . . . . . . 11
5. Deployment Migration Paths . . . . . . . . . . . . . . . . . 12
5.1. Application and Service Migration . . . . . . . . . . . . 12
5.2. Content Delivery Network Migration . . . . . . . . . . . 13
5.3. Edge Network Migration . . . . . . . . . . . . . . . . . 13
5.4. Core Network Migration . . . . . . . . . . . . . . . . . 14
6. Deployment Trial Experiences . . . . . . . . . . . . . . . . 14
6.1. ICN-as-an-Overlay . . . . . . . . . . . . . . . . . . . . 15
6.1.1. FP7 PURSUIT Efforts . . . . . . . . . . . . . . . . . 15
6.1.2. FP7 SAIL Trial . . . . . . . . . . . . . . . . . . . 15
6.1.3. NDN Testbed . . . . . . . . . . . . . . . . . . . . . 15
6.1.4. ICN2020 Efforts . . . . . . . . . . . . . . . . . . . 16
6.1.5. UMOBILE Efforts . . . . . . . . . . . . . . . . . . . 16
6.2. ICN-as-an-Underlay . . . . . . . . . . . . . . . . . . . 17
6.2.1. H2020 POINT and RIFE Efforts . . . . . . . . . . . . 17
6.2.2. H2020 FLAME Efforts . . . . . . . . . . . . . . . . . 18
6.2.3. CableLabs Content Delivery System . . . . . . . . . . 18
6.2.4. NDN IoT Trials . . . . . . . . . . . . . . . . . . . 19
6.2.5. NREN ICN Testbed . . . . . . . . . . . . . . . . . . 19
6.2.6. Doctor DOCTOR Testbed . . . . . . . . . . . . . . . . . . . 19
6.3. Composite-ICN Approach . . . . . . . . . . . . . . . . . 20
6.4. Summary of Deployment Trials . . . . . . . . . . . . . . 20
7. Deployment Issues Requiring Further Standardization . . . . . 21
7.1. Protocols for Application and Service Migration . . . . . 21
7.2. Protocols for Content Delivery Network Migration . . . . 21
7.3. Protocols for Edge and Core Network Migration . . . . . . 22
7.4. Summary of ICN Protocol Gaps and Potential Protocol Efforts . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
12. Informative References . . . . . . . . . . . . . . . . . . . 26
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 35
Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37

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 that avoid
forklift upgrades, upgrades and defining practical ICN interworking
configurations with the existing Internet paradigm, paradigm are key topic
areas that require further investigation [ICNRGCharter]. Also, it is
well understood that results and conclusions from any mid mid- to large-
scale ICN experiments in the live Internet will also provide useful
guidance for deployments.

So far, outside of some preliminary investigations investigations, such as
[I-D.paik-icn-deployment-considerations],
[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, 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; infrastructure, (2) ICN-as-an-Overlay; ICN-as-an-Overlay, (3) ICN-as-an-
Underlay;
Underlay, (4) ICN-as-a-Slice; ICN-as-a-Slice, and (5) Composite-ICN. Existing ICN
trial systems primarily fall under the ICN-as-an-Overlay, ICN-as-an-
Underlay
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
[I-D.irtf-icnrg-terminology]. [ICN-TERM]. In
addition, this document defines the following terminology:

Deployment - In the context of this document, deployment refers to
the

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 end-user video
and text) in a live environment, 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.,
WiFi, Mobile
Wi-Fi or mobile radio network), service edge networks (e.g., for
edge computing), transport networks, CDNs, Content Distribution Networks
(CDNs), core networks (e.g., Mobile mobile core network), and back-end
processing networks (e.g., Data
Centres). data centers). However, throughout the document we typically limit
this document, the discussion is typically limited to edge
networks, core networks networks, and CDNs CDNs, for simplicity.

Information-Centric Networking (ICN) - (ICN):
A data-centric network architecture where accessing data by name
is the essential network primitive. See [I-D.irtf-icnrg-terminology] [ICN-TERM] for further
information.

Network Functions Virtualization (NFV):
A networking approach where network functions (e.g., firewalls, firewalls or
load balancers) are modularized as software logic that can run on
general purpose
hardware, and thus hardware and, thus, are specifically decoupled
from the previous generation of proprietary and dedicated
hardware. See
[I-D.irtf-nfvrg-gaps-network-virtualization] [RFC8568] for further information.

Software-Defined Networking (SDN) - (SDN):
A networking approach where the control and data plane planes for
switches are separated, allowing for realizing capabilities capabilities, such
as traffic isolation and programmable forwarding actions. See
[RFC7426] for further information.

3. Acronyms Abbreviations List

API -

API: Application Programming Interface

BIER -

BIER: Bit Indexed Index Explicit Replication

BoF -

BoF: Birds of a Feather (session)

CCN - Content Centric Networking

CCNx - Content Centric

CCNx: Content-Centric Networking

CDN -

CDN: Content Distribution Network

CoAP -

CoAP: Constrained Application Protocol

DASH -

DASH: Dynamic Adaptive Streaming over HTTP

DiffServ -

Diffserv: Differentiated Services

DoS -

DoS: Denial of Service

DTN - Delay Tolerant

DTN: Delay-Tolerant Networking

ETSI -

ETSI: European Telecommunication Telecommunications Standards Institute

EU -

EU: European Union

FP7 -

FP7: 7th Framework Programme for Research and Technological
Development

HLS -

HLS: HTTP Live Streaming

HTTP - Hyper Text

HTTP: HyperText Transfer Protocol

HTTPS- Hyper Text

HTTPS: HyperText Transfer Protocol Secure

H2020-

H2020: Horizon 2020 (research program)

ICN -

ICN: Information-Centric Networking

ICNRG-

ICNRG: Information-Centric Networking Research Group

IETF -

IETF: Internet Engineering Task Force

IntServ -

IntServ: Integrated Services

IoT -

IoT: Internet of Things
IP -

IP: Internet Protocol

IPv4 -

IPv4: Internet Protocol Version 4

IPv6 -

IPv6: Internet Protocol Version 6

IPTV -

IPTV: Internet Protocol Television

ISIS -

IS-IS: Intermediate System to Intermediate System

ISP -

ISP: Internet Service Provider

k -

k: kilo (1000)

L2 -

L2: Layer 2

LTE -

LTE: Long Term Evolution (or 4th generation cellular system)

MANO -

MANO: Management and Orchestration

MEC - Mobile

MEC: Multi-access Edge Computing

Mbps -

Mbps: Megabits per second

M2M -

M2M: Machine-to-Machine

NAP -

NAP: Network Attachment Point

NDN -

NDN: Named Data Networking

NETCONF -

NETCONF: Network Configuration Protocol

NetInf -

NetInf: Network of Information

NFD -

NFD: Named Data Networking Forwarding Daemon

NFV -

NFV: Network Functions Virtualization

NICT -

NICT: Japan's National Institute of Information and
Communications Technology of Japan

NR -

NR: New Radio (access network for 5G)

OAM - Operations

OAM: Operations, Administration, and Maintenance

ONAP -

ONAP: Open Network Automation Platform

OSPF -

OSPF: Open Shortest Path First
PoC -

PoC: Proof of Concept (demo)

POINT-

POINT: IP Over ICN - the better IP (project)

qMp -

qMp: Quick Mesh Project

QoS -

QoS: Quality of Service

RAM -

RAM: Random Access Memory

RAN -

RAN: Radio Access Network

REST -

REST: Representational State Transfer (architecture)

RESTCONF -

RESTCONF: Representational State Transfer Configuration (protocol)

RIFE -

RIFE: Architecture for an Internet For Everybody (project)

RIP -

RIP: Routing Information Protocol

ROM - Read Only

ROM: Read-Only Memory

RSVP -

RSVP: Resource Reservation Protocol

RTP -

RTP: Real-time Transport Protocol

SDN -

SDN: Software-Defined Networking

SFC -

SFC: Service Function Chaining

SLA -

SLA: Service Level Agreement

TCL -

TCL: Transport Convergence Layer

TCP -

TCP: Transmission Control Protocol

UDP -

UDP: User Datagram Protocol

UMOBILE -

UMOBILE: Universal Mobile-centric and Opportunistic
Communications Architecture

US -

US: United States

USA -

USA: United States of America

VoD -

VoD: Video on Demand
VPN -

VPN: Virtual Private Network

WG -

WG: Working Group

YANG -

YANG: Yet Another Next Generation (data modeling language)

5G -

5G: Fifth Generation (cellular network)

6LoWPAN -

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
various 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
this, we refer to existing literature in this space space, such as
[Tateson].

4.1. Clean-slate 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 as well as and ancillary
services services,
such as existing applications which that are typically tied directly to the
TCP/IP protocol stack stack, are not taken for granted. For instance, a Clean-slate
ICN deployment would see existing IP routers being replaced by ICN-specific ICN-
specific forwarding and routing elements, such as NFD [NFD], CCN CCNx
routers [Jacobson] [Jacobson], or PURSUIT 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 case, SDN
switches. Different proposals have been made for various ICN
approaches to enable the operation over an SDN transport
[Reed][CONET][C_FLOW]. [Reed]
[CONET] [C_FLOW].

4.2. ICN-as-an-Overlay

Similarly

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 (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] [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]. [NetInf]. Finally, [Overlay_ICN]
describes an incremental approach to deploying an ICN architecture
particularly well-suited well suited to SDN based SDN-based networks by also segregating
ICN user user- and control plane control-plane traffic.

Regardless

However, 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 scenarios, this requires
interoperability between existing IP routing protocols (e.g., OSPF,
RIP, ISIS) or IS-IS) and ICN based 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
testing, as it allows rapid and easy deployment of ICN over existing
IP networks.

4.3. ICN-as-an-Underlay

Proposals

Proposals, such as [POINT] and [White] [White], outline the deployment option
of using an ICN underlay that would integrate with existing
(external) IP-based networks by deploying application layer 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 ICN,
in terms of underlying multicast delivery, mobility support, fast
indirection due to location independence, in-network computing computing, and
possibly more. The underlay approach thus results in islands of
native ICN deployments which 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 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 context, ICN is an
attractive option for scenarios scenarios, such as IoT [I-D.irtf-icnrg-icniot]. [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 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 scenario, case, the [VSER]
platform shows the realization of a multi-party audio/video
conferencing service over such a an 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 that
[VSER-Mob] features.

4.3.2. Core Network

In this sub-option, suboption, a core network would utilize edge-based protocol
mapping onto the native ICN underlay. For instance, [POINT] proposes
to map HTTP transactions, transactions or some other IP based transactions IP-based transactions, such as
CoAP, directly onto an ICN-based message exchange. This mapping is
realized at the NAP, such as realized for example, in access points or customer
premise equipment, which which, in turn turn, provides a standard IP interface
to existing user devices. The NAPs thus Thus, the NAP provides the apparent
perception of an IP-based core network towards 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 network slicing [NGMN-5G] is to multiplex a general
pool of compute, storage storage, and bandwidth resources among multiple
service networks with exclusive SLA requirements on transport and
compute level
compute-level QoS and security. This is enabled through NFV and SDN
technology functions that enables enable functional decomposition hence (hence,
modularity, independent scalability of control control, and/or the user-plane
functions, agility
functions), agility, and service driven 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 networks enabling dynamic slicing of the
spectrum resources among various services services, hence naturally extending
itself to end points and also cloud resources across multiple domains, to
offer end-to-end guarantees. These Once instantiated, these slices once instantiated could
include a mix of connectivity services like LTE-as-a-service or OTT (e.g., LTE-as-a-service),
Over-the-Top (OTT) services
like VoD (e.g., VoD), or other IoT services
through composition of a group of virtual and/or physical network
functions at control, user the control-, user-, and
service plane level. service-plane levels. Such a
framework can also be used to realize ICN slices with its own control
and forwarding plane 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),
Mobile core network, (RAN)
or mobile core network; otherwise, the ICN-as-a-Slice may be deployed end-to-
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]. [ICN-5GC]. The draft
document elaborates on two possible approaches to enable ICN. First, ICN: (1) as
an edge service using the local data network (LDN) feature in 5G
using
UPF User Plane Function (UPF) classification functions to fast
handover to the ICN forwarder;
the other is forwarder and (2) as a native deployment using
the non-IP PDU Protocol Data Unit (PDU) support that would allow new
network layer PDU to be handed over to ICN UPFs collocated with the gNB functions,
Generation NodeB (gNB) functions without invoking any IP functions.
While the former deployment would still rely on 3GPP based 3GPP-based mobility
functions, the later would allow mobility to be handled natively by
ICN. However However, both these deployment modes should benefit from other
ICN features features, such as in-network caching and computing. Associated
with this ICN user plan user-plane enablement, control plane control-plane extensions are
also proposed leveraging 5GC's 5th Generation Core Network (5GC)'s
interface to other application functions
(AF) (AFs) to allow new network service level
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 "chained service functions" "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, slice but instead that the slice is created to run an 5G-ICN a 5G-
ICN instance [Ravindran].

At the level of the specific technologies involved, such as ONAP
[ONAP] that (which can be used to orchestrate slices, slices), the 5G-ICN slice
requires compatibility compatibility, for instance 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 data-
plane forwarding function, function with SDN, as briefly discussed in
Section 4.1. Further cross domain cross-domain ICN slices can also be realized
using frameworks 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; ICN, (2) ICN-as-an-
Overlay;
Overlay, (3) ICN-as-an-Underlay; 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, islands or any other distinct
feature identified in the previous basic configurations. So we
categorize Hybrid ICN, ICN and other approaches that do not clearly
correspond to one of the other basic configurations, 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:

o Application

* application providers

* ISPs and service providers, both as core as well as and access network
providers, and also as well as ICN network providers

* CDN providers (due to the strong relation of the ICN proposition
to content delivery)

o End device

* 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]
[Techno_Economic], and [Internet_Pricing] [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 packet-level IP service. HTTP
provides one convergence point for these services with many Web 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 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 focuses, in particular 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 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 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 ICN-as-an-Overlay (Section 4.2), as well as ICN-as-
a-Slice 4.2) and ICN-as-a-Slice
(Section 4.4), 4.4) allow for the introduction of the full capabilities of
ICN through new application/service interfaces 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, [I-D.irtf-icnrg-icn-lte-4g] [ICN-LTE-4G] outlines a dual-stack end user 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 signalling 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, either 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 increase increasing utilization of available
bandwidth
bandwidth, as well as reducing the load on origin servers. Similar
to the previous sub-section, subsection, the underlay deployment configuration
presented in Section 4.3 aim aims at providing a migration path for
existing CDNs. This is also highlighted in a BIER use case use-case document
[I-D.ietf-bier-multicast-http-response],
[BIER], specifically with potential benefits in terms of utilizing
multicast in the delivery of content but also reducing load on origin as well as
and delegation server. 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 network-level
technology, e.g., in the space of IoT. Such For many years, such IoT
deployments have for
many years relied, and often still do, on proprietary protocols
for
reasons reasons, such as increased efficiency, lack of standardization
incentives
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 CoAP-based [RFC7252] based M2M platforms 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 mobile
networks. With the proliferation of network Network softwarization (using technologies like service
orchestration frameworks leveraging NFV and SDN concepts) are now
common in access networks and other network segments, segments. Therefore, the ICN-as-
a-Slice
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 through 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 AR/VR-based deployments
for, 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 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 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 benefits (such
as in-network multicast or caching, caching) and constraints, such constraints (such as the need
for specific network elements within such isolated slices. 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,
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, and 4; therefore, 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 analysis to retain the focus on real
life 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 test bed testbed as an L2 VPN-based overlay
between several European, US as well as US, and Asian sites, following the overlay
deployment configuration presented in Section 4.2. Software-
based Software-based
forwarders were utilized for the ICN message exchange, while native
ICN applications, e.g., applications (e.g., for video transmissions, 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 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 SAIL 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). late binding).
The NetInf architecture supports different deployment options through
its convergence layer 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. Reference [SAIL_Prototyping]
describes several trials trials, including a stadium environment and a
multi-site testbed, leveraging NetInf's Routing Hint 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 video-conferencing,
geo-locating, videoconferencing,
geolocating, and interfacing to consumer applications. Typical
trials involve up to 100 NDN enabled NDN-enabled nodes [NDN-testbed] [Jangam].

6.1.4. ICN2020 Efforts

ICN2020 is an ICN related 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 applications, such as
video delivery, interactive videos videos, and social networks. The
federated testbed spans the USA, Europe Europe, and Japan. Both NDN and CCN
CCNx approaches are within the scope of the project.

ICN2020 has released a set of interim public technical reports
[ICN2020]. reports. The
report [ICN2020-Experiments] contains a detailed description of the
progress made in both local testbeds as well as and federated testbeds. The
plan for the federated testbed includes integrating the NDN testbed,
the CUTEi testbed [RFC7945] [CUTEi] [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 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, management and
intermittent connectivity support) and user services (e.g., pervasive
content management) as close as possible to the end-users 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] that [UMOBILE-5], which supports intermittent wireless
networking. UMOBILE also implements a new data-centric wireless
routing protocol, DABBER [UMOBILE-6] [I-D.mendes-icnrg-dabber], [DABBER], which was designed
based on data reachability metrics that take into
consideration availability of adjacent
wireless nodes and different data sources. sources into consideration. The contextual-awareness
contextual awareness of the wireless network operation is obtained
via a machine learning machine-learning agent running within the wireless nodes
[UMOBILE-7].

The consortium has completed several ICN deployment trails. trials. In a
post disaster
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 trail 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 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 as well as 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, 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 ICN-related research projects of the
H2020 research program. The efforts in the H2020 POINT+RIFE POINT and RIFE
projects follow the underlay deployment configuration in
Section 4.3.2, edge-
based 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 as well as and service endpoint surrogate benefits benefit in HTTP-
based HTTP-based
scenarios, such as for HTTP-level streaming video delivery, and have
been demonstrated in the deployed POINT test bed 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 afore-mentioned 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 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 STBs Set-Top Boxes(STBs), as well as HLS
video players 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 FLAME 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 4.3.2, as per POINT/RIFE the POINT/
RIFE approach. Experiments were conducted with the city/
university city/university
joint venture Bristol-is-Open (BIO), (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) locations), as
well as reduced latency through the
playout play out of the video originating
from the local NAP, collocated with the WiFi AP Wi-Fi Access Point (AP)
instead of a remote server, i.e., the playout latency was bounded by
the maximum single hop 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 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 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"
based CDN is then used to service standard HTTP/IP-based
content retrieval request requests coming from the general Internet. This
approach acknowledges that whole scale replacement (see Section 4.1)
of existing HTTP/IP end user end-user applications and related Web web
infrastructure is a difficult proposition. [White] is clear that the
architecture proposed had has not yet been tested experimentally but that
implementations were 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 multi-story 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 NDN-based IoT
system was then compared to an equivalent system running standard IP IP-
based IoT protocols. It was found that the NDN based NDN-based IoT system was
superior in several respects respects, including in terms of energy
consumption,
consumption and for RAM and ROM footprints [Baccelli] [Anastasiades].
For example, the binary file size reductions for NDN protocol stack
versus standard IP based 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 nation-wide nationwide VPN-based
L2 underlay. The testbed uses the CCN CCNx approach and is based on the
[CICN] open source open-source software. There are approximately 15 nodes spread
across the USA which 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 DOCTOR Testbed

The Doctor 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 criteria, such as security, performance performance, and
interoperability.

The data-plane data plane relies on a 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 NDN island (i.e., by mapping HTTP
semantics to NDN semantics within the NDN-island). NDN island). The testbed
carries real Web traffic of users, users and has been currently evaluated
with the top-1000 top 1000 most popular Web sites. websites. The users only need to set
the gateway as the Web web proxy. The control-plane control plane relies on a central
manager which that uses machine learning based machine-learning-based detection methods [Mai-1]
from the date gathered by distributed probes and applies orchestrated
counter-measures
countermeasures against NDN attacks [Nguyen-1] [Nguyen-2] [Mai-2] or
performance issues. A remediation can be, for example, the scale-up scale up
of a bottleneck component, component or the deployment of a security function 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 poisioning 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, 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, 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 open-source software. Initial tests
have been done with 150 clients consuming DASH videos videos, which showed
good scalability properties at the Server Side 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., CCN, 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
IP-based applications (e.g., video-conferencing videoconferencing and IPTV). Another
limitation of the trials is that all of them involve less than 1k
users.

The ICN-as-a-Slice configuration has just started being trialled by

Huawei and China Unicom have just started trials of the ICN-as-
a-Slice configuration to demonstrate ICN features of security,
mobility
mobility, and bandwidth efficiency over a wired infrastructure using
video conferencing
videoconferencing as the application scenario [Chakraborti], also [Chakraborti]; also,
this prototype has been extended to demonstrate this over a 5G-NR
access.

The Clean-slate ICN approach has obviously never been trialled 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 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 trials, such as
the Doctor DOCTOR testbed (Section 6.2.6) 6.2.6), could also be characterized as a
Composite-ICN approach 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 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

The ICN

"Information-Centric Networking (ICN) Research Challenges 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 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

End-user applications and services need a standardized approach to
trigger ICN transactions. For example, in Internet and Web web
applications today, there are established socket APIs, communication
paradigms such (such as REST, 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
[I-D.irtf-icnrg-ccnxmessages] [RFC8609]
and [I-D.irtf-icnrg-ccnxsemantics]. [RFC8569]. Naming dynamically generated data requires different approaches
(e.g., hash digest based
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 cases, such as for broadcast 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 flavours. 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, location can enable a light-weight 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 CoAP by an application layer application-layer security mechanism.
Further work is required to identify if an
[RFC8613]-like approach, 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, ISIS) or IS-IS) and ICN routing approaches(e.g.,
NFD, CCN approaches
(e.g., NFD and CCNx routers) are expected 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 NFV/
SDN and most likely utilizing 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
networks, including DiffServ, IntServ Diffserv, IntServ, and RSVP. Some initial ideas
for QoS support in ICN networks are outlined in
[I-D.moiseenko-icnrg-flowclass] [FLOW-CLASS], which
proposes a an approach based on flow classification
based approach to enable functions
functions, such ICN rate control and cache control. Also [I-D.anilj-icnrg-icn-qos] Also, [ICN-QoS]
proposes how to use DiffServ
DSCP Diffserv Differentiated Services Code Point
(DSCP) codes to support QoS for ICN based 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, community but which is obviously critical for future
deployments of ICN. Potential areas that need investigation include
whether the YANG data modelling 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 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 approaches, such as
CCNinfo [I-D.irtf-icnrg-ccninfo]
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.

+--------------+----------------------------------------------------+

Table 1: Mapping of ICN Gaps to Potential Protocol Efforts

8. Conclusion

This document provides high level 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; infrastructure,
(2) ICN-as-an-Overlay; ICN-as-an-Overlay, (3) ICN-as-an-Underlay; ICN-as-an-Underlay, (4) ICN-as-a-Slice; ICN-as-a-Slice,
and (5) Composite-ICN. Existing ICN trial systems primarily fall
under the ICN-as-an-Overlay, ICN-as-an-Underlay 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 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 end-user applications untouched. ICN-as-an-Overlay
is the easiest configuration to deploy rapidly rapidly, as it leaves the
underlying IP infrastructure essentially untouched. However, its
applicability for general deployment must be considered on a case-by-
case by
case basis (e.g., basis. (That is, can it support all required user applications).
applications?). ICN-as-a-Slice is an attractive deployment option
for up coming upcoming 5G systems (i.e., for 5G radio and core networks) which 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 case-by-case basis (e.g., (i.e., can enough IP
routers be upgraded to support Composite-ICN functionality to provide
sufficient performance
benefits). benefits?).

There has been significant trial experience with all the major ICN
protocol flavors (e.g., CCN, 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 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 schemes, and OAM support for ICN.

9. IANA Considerations

This document requests 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 security, including many which 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) becomes become 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 coexistence with existing Internet infrastructure and
applications. Thus 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 similiar similar to [RFC8613] [RFC8613], which is used
to pass end-to-end encrypted content between HTTP and COAP CoAP by an
application layer
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,
HTTP or COAP CoAP to ICN) of gateways/proxies.

Finally, the Doctor 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 infrastructure, in this case, looking at Interest Flooding
Attacks [Nguyen-2] and Content Poisoning Attacks [Nguyen-1] [Mai-2]
[Nguyen-3] and evaluation of evaluating potential counter-measures countermeasures based on MANO MANO-
orchestrated actions on the virtualized infrastructure [Mai-1] . [Mai-1].

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

12. 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. and E., et al., "Information Centric Networking in
the IoT: Experiments with NDN in the Wild", ACM-ICN '14:
Proceedings of the 1st ACM
20164, Paris, France, Conference on Information-
Centric Networking, DOI 10.1145/2660129.2660144, September
2014,
<http://conferences2.sigcomm.org/acm-icn/2014/papers/
p77.pdf>.

[C_FLOW] Suh, J. <http://conferences2.sigcomm.org/acm-
icn/2014/papers/p77.pdf>.

[BIER] Trossen, D., Rahman, A., Wang, C., and et al., "C_FLOW: Content-Oriented Networking
over OpenFlow", Open Networking Summit, April, 2012,
<http://opennetsummit.org/archives/apr12/site/pdf/
snu.pdf>. 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", 2015,
<https://www.ietf.org/proceedings/interim-2015-icnrg-
04/slides/slides-interim-2015-icnrg-4-5.pdf>. <https://www.ietf.org/proceedings/
interim-2015-icnrg-04/slides/slides-interim-2015-icnrg-
4-5.pdf>.

[Chakraborti]
Chakraborti, A. and A., et al., "Design and Evaluation of a
Multi-source Multi-destination Real-time Application on
Content Centric Network", IEEE, HoT ICN, 2018 , 2018.

[CICN] CICN, "Community 1st IEEE International
Conference on Hot Information-Centric Networking (CICN)",
2017, (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. and L., et al., "CONET Project: Supporting "Supporting Information-Centric
Functionality in Software Defined Networks", Workshop 2012 IEEE
International Conference on Software Defined Networks, , 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. and H., et al., "Contrace: A Tool a tool for Measuring measuring and
Tracing Content-Centric Networks",
tracing content-centric networks", IEEE Communications
Magazine, Vol.53, No.3 , 2015. Volume 53, Issue 3,
DOI 10.1109/MCOM.2015.7060502, March 2015,
<https://doi.org/10.1109/MCOM.2015.7060502>.

[CUTEi] Asaeda, H. H., Li, R., and N. Choi, "Container-Based Unified
Testbed for Information Centric Networking", IEEE Network, Vol.28,
No.6 , 2014. 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", 2017, <http://dashif.org/>.

[Doctor] Doctor, DOCTOR, "Deployment and Securisation securisation of new
Functionalities
functionalities in Virtualized Networking Environments
(Doctor)", 2017, virtualized networking environments",
<http://www.doctor-project.org/index.htm>.

[fiveG-23501]
3gpp-23.501, "Technical Specification Group Services and
System Aspects; System
3GPP, "System Architecture for the 5G System
(Rel.15)", System", Release 15,
3GPP , TS 23.501, December 2017.

[fiveG-23502]
3gpp-23.502, "Technical Specification Group Services and
System Aspects; Procedures
3GPP, "Procedures for the 5G System (Rel.15)", (5GS)", Release 15,
3GPP , 2017.

[GEANT] GEANT, "GEANT Overview", 2016, <https://www.geant.org/>.

[H-ICN_1] Cisco, "Hybrid ICN: Cisco Announces Important Steps TS 23.502.

[FLOW-CLASS]
Moiseenko, I. and D. Oran, "Flow Classification in
Information Centric Networking", Work in Progress,
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
integrated ICN Solution for 5G", 2017,
<https://www.cisco.com/c/dam/en/us/solutions/collateral/
service-provider/ultra-services-platform/
mwc17-hicn-video-wp.pdf>.
service-provider/ultra-services-platform/mwc17-hicn-video-
wp.pdf>.

[H-ICN_3] Muscariello, L. and L., et al., 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>.

[H-ICN_4] Sardara, M. and et al., "(h)ICN Socket Library for HTTP:
Leveraging (h)ICN socket library for carrying HTTP
messages", 2018, <https://datatracker.ietf.org/meeting/
interim-2018-icnrg-01/materials/slides-interim-2018-icnrg-
01-sessa-hicn-socket-library-for-http-luca-muscariello>.

[I-D.anilj-icnrg-icn-qos]
Jangam, A., suthar,

[ICN-5GC] Ravindran, R., Suthar, P., and M. Stolic, "Supporting QoS
aware Data Delivery in Information Centric Networks",
draft-anilj-icnrg-icn-qos-00 (work in progress), July
2018.

[I-D.ietf-bier-multicast-http-response] Trossen, D., Rahman, A., Wang, C., and T. Eckert,
"Applicability of BIER Multicast Overlay for Adaptive
Streaming Services", draft-ietf-bier-multicast-http-
response-01 (work in progress), June 2019.

[I-D.irtf-icnrg-ccninfo]
Asaeda, H., Ooka, A., and X. Shao, "CCNinfo: Discovering
Content and Network Information in Content-Centric
Networks", draft-irtf-icnrg-ccninfo-02 (work in progress),
July 2019.

[I-D.irtf-icnrg-ccnxmessages]
Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV
Format", draft-irtf-icnrg-ccnxmessages-09 (work G.
White, "Enabling ICN in
progress), January 2019.

[I-D.irtf-icnrg-ccnxsemantics]
Mosko, M., Solis, I., and C. Wood, "CCNx Semantics",
draft-irtf-icnrg-ccnxsemantics-10 (work 3GPP's 5G NextGen Core
Architecture", Work in progress),
January 2019.

[I-D.irtf-icnrg-icn-lte-4g]
suthar, P., Stolic, M., Jangam, A., Trossen, D., 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 R.
Ravindran, "Native Deployment of ICN in LTE, 4G Mobile
Networks", draft-irtf-icnrg-icn-lte-4g-03 (work H. Choi, "Deployment
Considerations for Information-Centric Networking", Work
in
progress), March 2019.

[I-D.irtf-icnrg-icniot] 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", draft-irtf-icnrg-icniot-03 (work Work in
progress), Progress, Internet-Draft,
draft-irtf-icnrg-icniot-03, 2 May 2019.

[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", draft-irtf-icnrg-
terminology-04 (work in progress), June 2019.

[I-D.irtf-nfvrg-gaps-network-virtualization]
Bernardos, C., Rahman, A., Zuniga, J., Contreras, L.,
Aranda, 2019,
<https://tools.ietf.org/html/draft-irtf-icnrg-icniot-03>.

[ICN-LTE-4G]
Suthar, P., and P. Lynch, "Network Virtualization Research
Challenges", draft-irtf-nfvrg-gaps-network-
virtualization-10 (work in progress), September 2018.

[I-D.kutscher-icnrg-netinf-proto]
Kutscher, Stolic, M., Jangam, A., Ed., Trossen, D., Farrell, S., and E. Davies, "The NetInf
Protocol", draft-kutscher-icnrg-netinf-proto-01 (work
R. Ravindran, "Native Deployment of ICN in
progress), February 2013.

[I-D.mendes-icnrg-dabber]
Mendes, P., Sofia, R., Tsaoussidis, V., Diamantopoulos,
S., Sarros, C., Borrego, C., and J. Borrell, "Information-
centric Routing for Opportunistic Wireless LTE, 4G Mobile
Networks",
draft-mendes-icnrg-dabber-02 (work Work in progress), February
2019.

[I-D.moiseenko-icnrg-flowclass]
Moiseenko, I. 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 D. Oran, "Flow Classification M. Stolic, "Supporting QoS
aware Data Delivery in Information Centric Networking", draft-moiseenko-icnrg-
flowclass-04 (work in progress), July 2019.

[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", draft-paik-icn-
deployment-considerations-00 (work Networks", Work
in progress), Progress, Internet-Draft, draft-anilj-icnrg-icn-qos-00,
14 July
2013.

[I-D.ravi-icnrg-5gc-icn]
Ravindran, R., suthar, P., Trossen, D., Wang, 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 G.
White, "Enabling ICN in 3GPP's 5G NextGen Core
Architecture", draft-ravi-icnrg-5gc-icn-04 (work C. Tschudin, "Information-Centric Networking
(ICN): CCNx and NDN Terminology", Work in
progress), May 2019.

[ICN2020] ICN2020, "ICN2020 Deliverables", 2017,
<http://www.icn2020.org/dissemination/
deliverables-public/>. Progress,
January 2020, <https://tools.ietf.org/html/draft-irtf-
icnrg-terminology-08>.

[ICN2020-Experiments]
ICN2020, "Deliverable D4.1: "D4.1: 1st yearly report on Testbed
and Experiments (WP4)", Yearly WP4 Report & Demonstration",
August 2017,
<http://www.icn2020.org/dissemination/
deliverables-public/>.
<https://projects.gwdg.de/attachments/6840/D4.1-PU.pdf>.

[ICN2020-overview]
ICN2020, "ICN2020 Project Overview", 2016,
<http://www.icn2020.org/>.

[ICNRGCharter]
NDN,
IRTF, "Information-Centric Networking Research Group
Charter", 2013,
<https://datatracker.ietf.org/doc/charter-irtf-icnrg/>.

[IEEE_Communications]
Trossen, D. and G. Parisis, "Designing and Realizing realizing an
Information-Centric Internet", Information-Centric
Networking,
information-centric internet", IEEE Communications Magazine Special Issue,
2012.
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 paying the Truck Driver:
Differentiated Pricing truck driver:
differentiated pricing for the Future Internet", future internet", ReARCH
'10: Proceedings of the Re-Architecting the Internet
Workshop, ReArch
Workshop in conjunction with ACM Context, December, 2010. '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. and V., et al., "Networking Named Content", CoNEXT
'09: Proceedings of ACM Context, , 2009. 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. and A., et al., "Porting "nlsrSIM: Porting and Simulation of Named-
data
Named-data Link State Routing Protocol into ndnSIM",
DIVANet '17: Proceedings of the 6th ACM
DIVANet'17, Miami Beach, USA, 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. and H., et al., "Implementation of Content Poisoning
Attack Detection content poisoning
attack detection and Reaction reaction in Virtualized virtualized NDN
Networks",
networks", 2018 21st Conference on Innovation in Clouds,
Internet and Networks, ICIN 2018 (demo paper) IEEE, Networks and Workshops (ICIN),
DOI 10.1109/ICIN.2018.8401591, July 2018,
<http://www.mallouli.com/recherche/publications/
noms2018-1.pdf>.
<https://ieeexplore.ieee.org/document/8401591>.

[Mai-2] Mai, H. and H., et al., "Towards a Security Monitoring Plane for
Named Data Networking: Application to Content Poisoning
Attack", Proceedings of the NOMS 2018 - 2018 IEEE/IFIP
Symposium on Network Operations and
Management (NOMS)
IEEE, 2018. Symposium, DOI 10.1109/NOMS.2018.8406246, July
2018, <https://doi.org/10.1109/NOMS.2018.8406246>.

[Marchal] Marchal, X. and X., et al., "Leveraging NFV for the Deployment of
NDN: Application to HTTP Traffic Transport",
Proceedings of the NOMS 2018 -
2018 IEEE/IFIP Symposium on Network Operations and Management (NOMS),
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 : "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>. <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 Testbed, "Named Data Networking (NDN)
NDN, "NDN Testbed", 2010, <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",
2017,
<https://named-data.net/doc/NFD/current/>.

[NGMN-5G] NGMN, "NGMN 5G NGMN Alliance, "5G White Paper", February 2015,
<https://www.ngmn.org/fileadmin/ngmn/content/images/news/
ngmn_news/NGMN_5G_White_Paper_V1_0.pdf>.
<https://www.ngmn.org/wp-content/uploads/
NGMN_5G_White_Paper_V1_0.pdf>.

[NGMN-Network-Slicing]
NGMN, "NGMN Description
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/fileadmin/
user_upload/160113_Network_Slicing_v1_0.pdf>.
<https://www.ngmn.org/wp-content/
uploads/160113_NGMN_Network_Slicing_v1_0.pdf>.

[Nguyen-1] Nguyen, T. and T., et al., "Content Poisoning in Named Data
Networking: Comprehensive Characterization characterization of real
Deployment", Proceedings of the 15th IEEE/IFIP
International
deployment", 2017 IFIP/IEEE Symposium on Integrated
Network Management,
2017. 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 optimal
statistical test for Robust Detection robust detection against Interest
Flooding Attacks interest
flooding attacks in CCN", Proceedings of the 14th IEEE/
IFIP 2015 IFIP/IEEE International
Symposium on Integrated Network
Management, 2015. Management (IM),
DOI 10.1109/INM.2015.7140299, July 2015,
<https://doi.org/10.1109/INM.2015.7140299>.

[Nguyen-3] Nguyen, T. and T., et al., "A Security Monitoring Plane for Named
Data Networking Deployment", IEEE Communications Magazine, Nov 2018.
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", 2017,
<https://www.onap.org/>.

[oneM2M] OneM2M, "oneM2M Service Layer Standards for M2M and IoT",
2017, <http://www.onem2m.org/>.

[Overlay_ICN]
Shailendra, S. and et S.,et al., "A Novel Overlay Architecture novel overlay architecture for F
Information Centric Networking", 2015 21st National
Conference on Communications, NCC 2015,
DOI 10.1109/NCC.2015.7084921, April 2016, <https://www.researchgate.net/pub
lication/282779666_A_novel_overlay_architecture_for_Inform
ation_Centric_Networking>.
<https://www.researchgate.net/publication/282779666_A_nove
l_overlay_architecture_for_Information_Centric_Networking>
.

[POINT] Trossen, D. and D., et al., "POINT: IP Over "IP over ICN - The Better better IP?", 2015
European Conference on Networks and Communications
(EuCNC), , 2015. DOI 10.1109/EuCNC.2015.7194109, June 2015,
<https://doi.org/10.1109/EuCNC.2015.7194109>.

[Ravindran]
Ravindran, R. and R., et al., "5G-ICN : Delivering ICN Services
over 5G using Network Slicing", IEEE
Communication Communications
Magazine, May, Volume 55, Issue 5,
DOI 10.1109/MCOM.2017.1600938, October 2016,
<https://arxiv.org/abs/1610.01182>.

[Reed] Reed, M. and M., et al., "Stateless Multicast Switching multicast switching in
Software Defined Networks", ICC
software defined networks", 2016 IEEE International
Conference on Communications (ICC),
DOI 10.1109/ICC.2016.7511036, May 2016, Kuala Lumpur,
Malaysia, 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)",
2013,
<http://www.sail-project.eu/>.

[SAIL_Content_Delivery]
FP7, "SAIL "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, "SAIL Prototyping "Prototyping and Evaluation", Objective FP7-ICT-
2009-5-257448/D.B.4, March 2013,
<http://www.sail-project.eu/wp-content/uploads/2013/05/ <http://www.sail-
project.eu/wp-content/uploads/2013/05/
SAIL_DB4_v1.1_Final_Public.pdf>.

[Tateson] Tateson, J. and 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. Kostopolous, Kostopoulos, "Techno-Economics Aspects
of Information-Centric Networking", Volume 2, Journal for
Information Policy, Volume 2, 2012. Policy , DOI 10.5325/jinfopoli.2.2012.0026,
June 2012,
<https://doi.org/10.5325/jinfopoli.2.2012.0026>.

[UMOBILE-2]
Sarros, C. and C., et al., "Connecting the Edges: A Universal,
Mobile-Centric, and Opportunistic Communications
Architecture", IEEE Communications Magazine, vol. Volume 56,
Issue 2, DOI 10.1109/MCOM.2018.1700325, February 2018. 2018,
<https://doi.org/10.1109/MCOM.2018.1700325>.

[UMOBILE-3]
Tavares, M., Aponte, O., and P. Mendes, "Named-data
Emergency Network Services", Proc. MobiSys '18: Proceedings of ACM MOBISYS, Munich,
Germany,
the 16th Annual International Conference on Mobile
Systems, Applications, and Services,
DOI 10.1145/3210240.3210809, June 2018. 2018,
<https://doi.org/10.1145/3210240.3210809>.

[UMOBILE-4]
Lopes, L. and
Amaral, L., et al., "Oi! - Opportunistic Data Transmission
Based on Wi-Fi Direct", Proc. of 2016 IEEE
INFOCOM, San Francisco, USA, Conference on Computer
Communications Workshops (INFOCOM WKSHPS),
DOI 10.1109/INFCOMW.2016.7562142, April 2016. 2016,
<https://doi.org/10.1109/INFCOMW.2016.7562142>.

[UMOBILE-5]
Dynerowicz, S. and P. Mendes, "Named-Data Networking "Demo: named-data networking
in
Opportunistic Networks", Proc. opportunistic network", ICN '17: Proceedings of the 4th
ACM ICN, Berlin,
Germany, Conference on Information-Centric Networking,
DOI 10.1145/3125719.3132107, September 2017. 2017,
<https://doi.org/10.1145/3125719.3132107>.

[UMOBILE-6]
Mendes, P. and et P.,et al., "Information-centric Routing routing for
Opportunistic Wireless Networks", Proc.
opportunistic wireless networks", ICN '18: Proceedings of
the 5th ACM ICN,
Boston, USA, Conference on Information-Centric Networking,
DOI 10.1145/3267955.3269011, September 2018. 2018,
<https://doi.org/10.1145/3267955.3269011>.

[UMOBILE-7]
Sofia, R., "The UMOBILE Contextual Manager Service.
Technical Report. Technical Report Senception 001, 2018
(base for UMOBILE deliverable D4.5 - "D4.5 Report on Data Collection and Inference
Models", 2018. Deliverable, September 2017.

[UMOBILE-8]
Sarros, C. and C., et al., "ICN-based edge service deployment in
challenged networks", ICN '17: Proceedings of the 4th ACM
Conference on Information-Centric Networking (ICN '17).
ACM, New York, NY, USA, 2017 . Networking,
DOI 10.1145/3125719.3132096, September 2017,
<https://doi.org/10.1145/3125719.3132096>.

[UMOBILE-9]
Lertsinsrubtavee, A. and A., et al., "Information-Centric
Multi-Access Multi-
Access Edge Computing Platform for Community Mesh
Networks", COMPASS '18: Proceedings of the 1st ACM SIGCAS
Conference on Computing and Sustainable Societies (COMPASS '18). ACM,
New York, NY, USA, 2018 . Societies,
DOI 10.1145/3209811.3209867, June 2018,
<https://doi.org/10.1145/3209811.3209867>.

[UMOBILE-overview]
UMOBILE, "Universal Mobile-centric "Universal, mobile-centric and Opportunistic
Communications Architecture (UMOBILE)", 2018, opportunistic
communications architecture",
<http://www.umobile-project.eu/>.

[VSER] Ravindran, R. and R., et al., "Towards software defined ICN based
edge-cloud services",
CloudNetworking(CloudNet), IEEE Internation Conference on, 2013 IEEE Internation 2nd International
Conference on CloudNetworking(CloudNet),
2013. Cloud Networking (CloudNet),
DOI 10.1109/CloudNet.2013.6710583,
<https://doi.org/10.1109/CloudNet.2013.6710583>.

[VSER-Mob] Azgin, A. and A., et al., "Seamless Producer Mobility as a
Service in Information-centric Networks", ACM-ICN '16:
Proceedings of the 3rd ACM ICN Sigcomm, IC5G
Workshop, 2016. 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, CableLabs White Paper", 2016,
<http://www.cablelabs.com/wp-content/uploads/2016/02/
Content-Delivery-with-Content-Centric-Networking-Feb-
2016.pdf>.

Appendix A. Change Log

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

Changes from draft-irtf-rev-06 to draft-irtf-rev-07:

o Added reference to OSCORE (RFC 8613) which is a way of passing
end-to-end encrypted content between HTTP and COAP without
invalidating encryption. Thus it can be a potential model for
HTTP to ICN, or COAP to ICN, to consider in the future.

o Updated affiliation information for author Ravi Ravindran.

Changes from draft-irtf-rev-05 to draft-irtf-rev-06:

o Various updates to ensure that draft complies "Content Delivery with RFC 5743
(Definition of an Internet Research Task Force (IRTF) Document
Stream) section 2.1.

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

o Addressed detailed review comments from Marie-Jose Montpetit.

Changes from draft-irtf-rev-03 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 draft-irtf-rev-04:

o Added text from Paulo Mendes and Adisorn Lertsinsrubtavee on
UMOBILE Trial Experiences.

o Incorporated off-line editorial comments from thank Alex Afanasyev, Hitoshi Asaeda and Asaeda, Giovanna
Carofiglio, Xavier de Foy, Guillaume Doyen, Hannu Flinck, Anil Jangam.

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

o Editorial update of description
Jangam, Michael Kowal, Adisorn Lertsinsrubtavee, Paulo Mendes, Luca
Muscariello, Thomas Schmidt, Jan Seedorf, Eve Schooler, Samar
Shailendra, Milan Stolic, Prakash Suthar, Atsushi Mayutan, and references of Doctor testbed
as per comments from Guillaume Doyen.

o Ran IETF spell checker tool Lixia
Zhang for their very useful reviews and corrected various spelling errors.

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

o Updated description of Doctor testbed as per comments from
Guillaume Doyen. Also referenced Doctor testbed from the Security
Considerations section.

o Added "Composite-ICN" configuration to cover the Hybrid ICN document.

Special thanks to Dave Oran (ICNRG Co-chair) and
similar configurations which do not clearly fit in one of the
other basic configurations.

o Updated description Marie-Jose Montpetit
for their extensive and thoughtful reviews of the ICN-as-a-Slice configuration to clarify
that it may also apply to non-5G systems.

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

o Added text from Michael Kowal describing NREN ICN Testbed.

o Added text from Guillaume Doyen describing Doctor Project.

o Updated text on Hybrid ICN based on input from Luca Muscariello.

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

o Changed draft status from individual draft-rahman-icnrg-
deployment-guidelines-05 to RG adopted draft-irtf-icnrg-
deployment-guidelines-00.

Changes from rev-04 to rev-05:

o Added this Change Log in Appendix A.

o Removed references document. Their
reviews helped to Hybrid ICN from section 3.2 (ICN-as-an-
Overlay definition). Instead, consolidated all Hybrid ICN info in
the Deployment Trial Experiences under a new subsection 5.3 (Other
Configurations).

o Updated ICN2020 description in Section 5.1.4 with text received
from Mayutan Arumaithurai and Hitoshi Asaeda.

o Clarified in ICN-as-a-Slice description (section 3.4) that it may
be deployed on either the Edge (RAN) or Core Network, or the ICN-
as-a-Slice may be deployed end-to-end through immeasurably improve the entire Mobile
network.

o Added several new references in various sections.

o Various minor editorial updates. 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
InterDigital Europe, Ltd
64 Great Eastern Street, 1st Floor
London EC2A 3QR
United Kingdom
Huawei Technologies Duesseldorf GmbH
Riesstrasse 25
80992 Munich
Germany

Email: Dirk.Trossen@InterDigital.com dirk.trossen@huawei.com
URI: http://www.InterDigital.com/ http://www.huawei.com/

Dirk Kutscher
University of Applied Sciences Emden/Leer
Constantiapl. 4
Emden
26723 Emden
Germany

Email: ietf@dkutscher.net
URI: https://www.hs-emden-leer.de/en/

Ravi Ravindran
Future
Sterlite Technologies
2330 Central Expressway
5201 Greatamerica Pkwy
Santa Clara 95050
USA Clara, 95054
United States of America

Email: ravi.ravindran@futurewei.com ravi.ravindran@gmail.com