rfc8763xml2.original.xml   rfc8763.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc7927 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7927.xml'>
<!ENTITY rfc7252 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7252.xml'>
<!ENTITY rfc7665 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7665.xml'>
<!ENTITY rfc6920 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.6920.xml'>
<!ENTITY rfc8075 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8075.xml'>
<!ENTITY rfc7945 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7945.xml'>
<!ENTITY rfc7426 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7426.xml'>
<!ENTITY rfc8613 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8613.xml'>
<!ENTITY I-D.ietf-bier-multicast-http-response SYSTEM 'http://xml.resource.org/p
ublic/rfc/bibxml3/reference.I-D.ietf-bier-multicast-http-response.xml'>
<!ENTITY I-D.irtf-nfvrg-gaps-network-virtualization SYSTEM 'http://xml.resource.
org/public/rfc/bibxml3/reference.I-D.irtf-nfvrg-gaps-network-virtualization.xml'
>
<!ENTITY I-D.irtf-icnrg-ccnxmessages SYSTEM 'http://xml.resource.org/public/rfc/
bibxml3/reference.I-D.irtf-icnrg-ccnxmessages.xml'>
<!ENTITY I-D.irtf-icnrg-icniot SYSTEM 'http://xml.resource.org/public/rfc/bibxml
3/reference.I-D.irtf-icnrg-icniot.xml'>
<!ENTITY I-D.irtf-icnrg-terminology SYSTEM 'http://xml.resource.org/public/rfc/b
ibxml3/reference.I-D.irtf-icnrg-terminology.xml'>
<!ENTITY I-D.irtf-icnrg-icn-lte-4g SYSTEM 'http://xml.resource.org/public/rfc/bi
bxml3/reference.I-D.irtf-icnrg-icn-lte-4g.xml'>
<!ENTITY I-D.irtf-icnrg-ccninfo SYSTEM 'http://xml.resource.org/public/rfc/bibxm
l3/reference.I-D.irtf-icnrg-ccninfo.xml'>
<!ENTITY I-D.irtf-icnrg-ccnxsemantics SYSTEM 'http://xml.resource.org/public/rfc
/bibxml3/reference.I-D.irtf-icnrg-ccnxsemantics.xml'>
<!ENTITY I-D.paik-icn-deployment-considerations SYSTEM 'http://xml.resource.org/
public/rfc/bibxml3/reference.I-D.paik-icn-deployment-considerations.xml'>
<!ENTITY I-D.kutscher-icnrg-netinf-proto SYSTEM 'http://xml.resource.org/public/
rfc/bibxml3/reference.I-D.kutscher-icnrg-netinf-proto.xml'>
<!ENTITY I-D.ravi-icnrg-5gc-icn SYSTEM 'http://xml.resource.org/public/rfc/bibxm
l3/reference.I-D.ravi-icnrg-5gc-icn.xml'>
<!ENTITY I-D.moiseenko-icnrg-flowclass SYSTEM 'http://xml.resource.org/public/rf
c/bibxml3/reference.I-D.moiseenko-icnrg-flowclass.xml'>
<!ENTITY I-D.anilj-icnrg-icn-qos SYSTEM 'http://xml.resource.org/public/rfc/bibx
ml3/reference.I-D.anilj-icnrg-icn-qos.xml'>
<!ENTITY I-D.mendes-icnrg-dabber SYSTEM 'http://xml.resource.org/public/rfc/bibx
ml3/reference.I-D.mendes-icnrg-dabber.xml'>
]>
<!-- How to Reference in main body
e.g. in <xref target="RFC8075" />
e.g. in <xref target="I-D.irtf-nfvrg-gaps-network-virtualization" />
e.g. in <xref target="I-D.mosko-icnrg-ccnxurischeme" />
e.g. in <xref target="SAIL_NetInf" />
e.g. and the 5GEx project (https://www.5gex.eu/)
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-irtf-icnrg-deployment-guidelines-07" <rfc number="8763" consensus="true" xmlns:xi="http://www.w3.org/2001/XInclude" c
ipr="trust200902"> ategory="info"
docName="draft-irtf-icnrg-deployment-guidelines-07" ipr="trust200902"
obsoletes="" updates="" submissionType="IRTF" xml:lang="en"
tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true"
version="3">
<!-- xml2rfc v2v3 conversion 2.39.0 -->
<front> <front>
<title abbrev="Deployment Considerations for ICN"> <title abbrev="Deployment Considerations for ICN">
Deployment Considerations for Information-Centric Networking (ICN) Deployment Considerations for Information-Centric Networking (ICN)
</title> </title>
<seriesInfo name="RFC" value="8763"/>
<!-- AUTHORS --> <author fullname="Akbar Rahman" initials="A." surname="Rahman">
<author fullname="Akbar Rahman"
initials="A."
surname="Rahman">
<organization abbrev="InterDigital Communications, LLC"> <organization abbrev="InterDigital Communications, LLC">
InterDigital Communications, LLC InterDigital Communications, LLC
</organization> </organization>
<address> <address>
<postal> <postal>
<street>1000 Sherbrooke Street West, 10th floor</street> <street>1000 Sherbrooke Street West, 10th floor</street>
<city>Montreal</city> <city>Montreal</city>
<code> H3A 3G4</code> <code>H3A 3G4</code>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>Akbar.Rahman@InterDigital.com</email> <email>Akbar.Rahman@InterDigital.com</email>
<uri>http://www.InterDigital.com/</uri> <uri>http://www.InterDigital.com/</uri>
</address> </address>
</author> </author>
<author fullname="Dirk Trossen" initials="D." surname="Trossen">
<author fullname="Dirk Trossen" <organization abbrev="Huawei">Huawei Technologies Duesseldorf GmbH</organi
initials="D." zation>
surname="Trossen">
<organization abbrev="InterDigital Europe, Ltd">
InterDigital Europe, Ltd
</organization>
<address> <address>
<postal> <postal>
<street>64 Great Eastern Street, 1st Floor</street> <street>Riesstrasse 25</street>
<city>London</city> <city>Munich</city>
<code>EC2A 3QR</code> <code>80992</code>
<country>United Kingdom</country> <country>Germany</country>
</postal> </postal>
<email>Dirk.Trossen@InterDigital.com</email> <email>dirk.trossen@huawei.com</email>
<uri>http://www.InterDigital.com/</uri> <uri>http://www.huawei.com/</uri>
</address> </address>
</author> </author>
<author fullname="Dirk Kutscher" <author fullname="Dirk Kutscher" initials="D." surname="Kutscher">
initials="D." <organization abbrev="Emden University">
surname="Kutscher">
<organization abbrev="University of Applied Sciences Emden/Leer">
University of Applied Sciences Emden/Leer University of Applied Sciences Emden/Leer
</organization> </organization>
<address> <address>
<postal> <postal>
<street>Constantiapl. 4</street> <street>Constantiapl. 4</street>
<city>Emden</city> <city>Emden</city>
<code>26723</code> <code>26723</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>ietf@dkutscher.net</email> <email>ietf@dkutscher.net</email>
<uri>https://www.hs-emden-leer.de/en/</uri> <uri>https://www.hs-emden-leer.de/en/</uri>
</address> </address>
</author> </author>
<author fullname="Ravi Ravindran" initials="R." surname="Ravindran">
<author fullname="Ravi Ravindran" <organization>
initials="R." Sterlite Technologies
surname="Ravindran">
<organization abbrev="Futurewei">
Future Technologies
</organization> </organization>
<address> <address>
<postal> <postal>
<street>2330 Central Expressway</street> <street>5201 Greatamerica Pkwy</street>
<city>Santa Clara</city> <city>Santa Clara</city>
<code>95050</code> <code>95054</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>ravi.ravindran@futurewei.com</email> <email>ravi.ravindran@gmail.com</email>
</address> </address>
</author> </author>
<date month="September" year="2019" /> <date month="April" year="2020"/>
<area>Internet Research Task Force (IRTF)</area> <area>Internet Research Task Force (IRTF)</area>
<workgroup>Information-Centric Networking</workgroup>
<workgroup>ICNRG</workgroup>
<abstract> <abstract>
<t>Information-Centric Networking (ICN) is now reaching technological
<t>Information-Centric Networking (ICN) is now reaching technological matu maturity after many years of fundamental research and experimentation.
rity after many years of fundamental research and experimentation. This document provides a number of deployment considerations in the
This document provides a number of deployment considerations in the int interest of helping the ICN community move forward to the next step
erest of helping the ICN community move forward to the next step of of live deployments. First, the major deployment configurations for
live deployments. First, the major deployment configurations for ICN a ICN are described, including the key overlay and underlay approaches.
re described including the key overlay and underlay approaches. Then Then, proposed deployment migration paths are outlined to address
proposed deployment migration paths are outlined to address major pract major practical issues, such as network and application migration.
ical issues such as network and application migration. Next, selected Next, selected ICN trial experiences are summarized. Finally,
ICN trial experiences are summarized. Finally, protocol areas that req protocol areas that require further standardization are identified
uire further standardization are identified to facilitate future to facilitate future interoperable ICN deployments. This document is
interoperable ICN deployments. This document is a product of the Info a product of the Information-Centric Networking Research Group
rmation-Centric Networking Research Group (ICNRG). (ICNRG).
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sec_introduction" numbered="true" toc="default">
<section anchor="sec:introduction" title="Introduction"> <name>Introduction</name>
<t>The ICNRG charter identifies deployment guidelines as an important
<t>The ICNRG charter identifies deployment guidelines as an important topi topic area for the ICN community. Specifically, the charter states
c area for the ICN community. Specifically, the charter states that defining concrete migration paths for ICN deployments that
that defining concrete migration paths for ICN deployments which avoid avoid forklift upgrades and defining practical ICN interworking
forklift upgrades, and defining practical ICN interworking configurations configurations
with the existing Internet paradigm, are key topic areas that require f with the existing Internet paradigm are key topic areas that
urther investigation <xref target="ICNRGCharter" />. Also, it is well require further investigation <xref target="ICNRGCharter"
understood that results and conclusions from any mid to large-scale ICN format="default"/>. Also, it is well
experiments in the live Internet will also provide useful guidance for deployme understood that results and conclusions from any mid- to large-scale
nts. ICN experiments in the live Internet will also provide useful
</t> guidance for deployments.
<t>So far, outside of some preliminary investigations such as <xref tar
get="I-D.paik-icn-deployment-considerations" />, there has not been much
progress on this topic. This document attempts to fill some of these g
aps by defining clear deployment configurations for ICN, and associated
migration pathways for these configurations. Also, selected deployment
trial experiences of ICN technology are summarized. Recommendations
are also made for potential future IETF standardization of key protocol
functionality that will facilitate interoperable ICN deployments going forward.
</t> </t>
<t>So far, outside of some preliminary investigations, such as <xref
<t>The major configurations of possible ICN deployments are identified target="I-D.paik-icn-deployment-considerations" format="default"/>,
in this document as (1) Clean-slate ICN replacement of existing Internet infrast there has not been much
ructure; progress on this topic. This document attempts to fill some of
(2) ICN-as-an-Overlay; (3) ICN-as-an-Underlay; (4) ICN-as-a-Slice; and these gaps by defining clear deployment configurations for ICN and
(5) Composite-ICN. Existing ICN trial systems primarily fall associated
under the ICN-as-an-Overlay, ICN-as-an-Underlay and Composite-ICN confi migration pathways for these configurations. Also, selected
gurations. Each of these deployment configurations have their respective streng deployment trial experiences of ICN technology are summarized.
ths and weaknesses. Recommendations
This document will aim to provide guidance for current and future membe are also made for potential future IETF standardization of key
rs of the ICN community when they consider deployment of ICN technologies. protocol functionality that will facilitate interoperable ICN
deployments going forward.
</t>
<t>The major configurations of possible ICN deployments are identified
in this document as (1) Clean-slate ICN replacement of existing Internet
infrastructure,
(2) ICN-as-an-Overlay, (3) ICN-as-an-Underlay, (4) ICN-as-a-Slice,
and (5) Composite-ICN. Existing ICN trial systems primarily fall
under the ICN-as-an-Overlay, ICN-as-an-Underlay, and Composite-ICN
configurations. Each of these deployment configurations have their
respective strengths and weaknesses.
This document will aim to provide guidance for current and future
members of the ICN community when they consider deployment of ICN
technologies.
</t> </t>
<t>This document represents the consensus of the Information-Centric Ne <t>This document represents the consensus of the Information-Centric
tworking Research Group (ICNRG). It has been reviewed extensively by the Resear Networking Research Group (ICNRG). It has been reviewed extensively by
ch Group the Research Group
(RG) members active in the specific areas of work covered by the docume nt.</t> (RG) members active in the specific areas of work covered by the docume nt.</t>
</section> </section>
<section anchor="sec_terminology" numbered="true" toc="default">
<section anchor="sec:terminology" title="Terminology"> <name>Terminology</name>
<!--
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in
<xref target='RFC2119'>.
</t>
<t> <t>
This document assumes readers are, in general, familiar with the terms and conce This document assumes readers are, in general, familiar with the terms and
pts that are defined in <xref target="RFC7927" /> and <xref target="I-D.irtf-icn concepts that are defined in <xref target="RFC7927" format="default"/> and
rg-terminology" />. In addition, this document defines the following terminolog <xref target="I-D.irtf-icnrg-terminology" format="default"/>. In addition,
y: this document defines the following terminology:
<list style="empty">
<t>Deployment - In the context of this document, deployment refers to
the final stage of the process of setting up an ICN network that is
(1) ready for useful work (e.g., transmission of end user video
and text) in a live environment, and (2) integrated and interoperable
with the Internet. We consider the Internet in its widest sens
e where it encompasses various access networks (e.g., WiFi, Mobile radio network
),
service edge networks (e.g., for edge computing), transport net
works, CDNs, core networks (e.g., Mobile core network), and back-end processing
networks
(e.g., Data Centres). However, throughout the document we typi
cally limit the discussion to edge networks, core networks and CDNs for simplici
ty.
</t>
<t>Information-Centric Networking (ICN) - A data-centric network archi
tecture where accessing data by name is the essential network primitive.
See <xref target="I-D.irtf-icnrg-terminology" /> for further in
formation.
</t>
<t>Network Functions Virtualization (NFV): A networking approac
h where network functions (e.g., firewalls, load balancers) are modularized
as software logic that can run on general purpose hardware, and
thus are specifically decoupled from the previous generation of proprietary
and dedicated hardware. See <xref target="I-D.irtf-nfvrg-gaps-n
etwork-virtualization" /> for further information.
</t>
<t>Software-Defined Networking (SDN) - A networking approach where th
e control and data plane for switches are separated, allowing for realizing
capabilities such as traffic isolation and programmable forward
ing actions. See <xref target="RFC7426" /> for further information.
</t>
</list>
</t> </t>
<dl newline="true" spacing="normal">
<dt>Deployment:</dt>
<dd>The final stage of the process of setting up an ICN network that is
(1) ready for useful work (e.g., transmission of end-user
video and text) in a live environment and (2) integrated
and interoperable
with the Internet. We consider the Internet in its widest
sense where it encompasses various access networks (e.g.,
Wi-Fi or mobile radio network),
service edge networks (e.g., for edge computing), transport
networks, Content Distribution Networks (CDNs), core networks (
e.g., mobile core network),
and back-end processing networks
(e.g., data centers). However, throughout this document,
the discussion is typically limited to edge networks, core
networks, and CDNs, for simplicity.</dd>
<dt>Information-Centric Networking (ICN):</dt>
<dd>A data-centric network
architecture where accessing data by name is the essential network
primitive.
See <xref target="I-D.irtf-icnrg-terminology"
format="default"/> for further information.</dd>
<dt>Network Functions Virtualization (NFV):</dt>
<dd>A networking approach
where network functions (e.g., firewalls or load balancers) are
modularized
as software logic that can run on general purpose hardware
and, thus, are specifically decoupled from the previous
generation of proprietary
and dedicated hardware. See <xref
target="RFC8568"
format="default"/> for further information.</dd>
<dt>Software-Defined Networking (SDN):</dt>
<dd>A networking approach where the control and data planes for
switches are separated, allowing for
realizing capabilities, such as traffic isolation and programmable
forwarding actions. See <xref target="RFC7426" format="default"/> for
further information.</dd>
</dl>
</section> </section>
<section anchor="sec_acronyms" numbered="true" toc="default">
<name>Abbreviations List</name>
<section anchor="sec:acronyms" title="Acronyms List"> <dl newline="false" spacing="normal" indent="13">
<t> <dt>API:</dt>
<list style="empty"> <dd>Application Programming Interface</dd>
<dt>BIER:</dt>
<t>API - Application Programming Interface</t> <dd>Bit Index Explicit Replication</dd>
<t>BIER - Bit Indexed Explicit Replication</t> <dt>BoF:</dt>
<t>BoF - Birds of a Feather (session)</t> <dd>Birds of a Feather (session)</dd>
<t>CCN - Content Centric Networking</t> <dt>CCNx:</dt>
<t>CCNx - Content Centric Networking</t> <dd>Content-Centric Networking</dd>
<t>CDN - Content Distribution Network</t> <dt>CDN:</dt>
<t>CoAP - Constrained Application Protocol</t> <dd>Content Distribution Network</dd>
<t>DASH - Dynamic Adaptive Streaming over HTTP</t> <dt>CoAP:</dt>
<t>DiffServ - Differentiated Services</t> <dd>Constrained Application Protocol</dd>
<t>DoS - Denial of Service</t> <dt>DASH:</dt>
<t>DTN - Delay Tolerant Networking</t> <dd>Dynamic Adaptive Streaming over HTTP</dd>
<t>ETSI - European Telecommunication Standards Institute< <dt>Diffserv:</dt>
/t> <dd>Differentiated Services</dd>
<t>EU - European Union</t> <dt>DoS:</dt>
<t>FP7 - 7th Framework Programme for Research and Techno <dd>Denial of Service</dd>
logical Development</t> <dt>DTN:</dt>
<t>HLS - HTTP Live Streaming</t> <dd>Delay-Tolerant Networking</dd>
<t>HTTP - Hyper Text Transfer Protocol</t> <dt>ETSI:</dt>
<t>HTTPS- Hyper Text Transfer Protocol Secure</t> <dd>European Telecommunications Standards Institute</dd>
<t>H2020- Horizon 2020 (research program)</t> <dt>EU:</dt>
<t>ICN - Information-Centric Networking</t> <dd>European Union</dd>
<t>ICNRG- Information-Centric Networking Research Group</ <dt>FP7:</dt>
t> <dd>7th Framework Programme for Research and Technological Development</
<t>IETF - Internet Engineering Task Force</t> dd>
<t>IntServ - Integrated Services</t> <dt>HLS:</dt>
<t>IoT - Internet of Things</t> <dd>HTTP Live Streaming</dd>
<t>IP - Internet Protocol</t> <dt>HTTP:</dt>
<t>IPv4 - Internet Protocol Version 4</t> <dd>HyperText Transfer Protocol</dd>
<t>IPv6 - Internet Protocol Version 6</t> <dt>HTTPS:</dt>
<t>IPTV - Internet Protocol Television</t> <dd>HyperText Transfer Protocol Secure</dd>
<t>ISIS - Intermediate System to Intermediate System</t> <dt>H2020:</dt>
<t>ISP - Internet Service Provider</t> <dd>Horizon 2020 (research program)</dd>
<t>k - kilo (1000)</t> <dt>ICN:</dt>
<t>L2 - Layer 2</t> <dd>Information-Centric Networking</dd>
<t>LTE - Long Term Evolution (or 4th generation cellular <dt>ICNRG:</dt>
system)</t> <dd>Information-Centric Networking Research Group</dd>
<t>MANO - Management and Orchestration</t> <dt>IETF:</dt>
<t>MEC - Mobile Edge Computing</t> <dd>Internet Engineering Task Force</dd>
<t>Mbps - Megabits per second</t> <dt>IntServ:</dt>
<t>M2M - Machine-to-Machine</t> <dd>Integrated Services</dd>
<t>NAP - Network Attachment Point</t> <dt>IoT:</dt>
<t>NDN - Named Data Networking</t> <dd>Internet of Things</dd>
<t>NETCONF - Network Configuration Protocol</t> <dt>IP:</dt>
<t>NetInf - Network of Information </t> <dd>Internet Protocol</dd>
<t>NFD - Named Data Networking Forwarding Daemon</t> <dt>IPv4:</dt>
<t>NFV - Network Functions Virtualization</t> <dd>Internet Protocol Version 4</dd>
<t>NICT - National Institute of Information and Communica <dt>IPv6:</dt>
tions Technology of Japan</t> <dd>Internet Protocol Version 6</dd>
<t>NR - New Radio (access network for 5G)</t> <dt>IPTV:</dt>
<t>OAM - Operations and Maintenance</t> <dd>Internet Protocol Television</dd>
<t>ONAP - Open Network Automation Platform</t> <dt>IS-IS:</dt>
<t>OSPF - Open Shortest Path First</t> <dd>Intermediate System to Intermediate System</dd>
<t>PoC - Proof of Concept (demo)</t> <dt>ISP:</dt>
<t>POINT- IP Over ICN – the better IP (project)</t> <dd>Internet Service Provider</dd>
<t>qMp - Quick Mesh Project</t> <dt>k:</dt>
<t>QoS - Quality of Service</t> <dd>kilo (1000)</dd>
<t>RAM - Random Access Memory</t> <dt>L2:</dt>
<t>RAN - Radio Access Network</t> <dd>Layer 2</dd>
<t>REST - Representational State Transfer (architecture)< <dt>LTE:</dt>
/t> <dd>Long Term Evolution (or 4th generation cellular system)</dd>
<t>RESTCONF - Representational State Transfer Configu <dt>MANO:</dt>
ration (protocol)</t> <dd>Management and Orchestration</dd>
<t>RIFE - Architecture for an Internet For Everybody (pro <dt>MEC:</dt>
ject)</t> <dd>Multi-access Edge Computing</dd>
<t>RIP - Routing Information Protocol </t> <dt>Mbps:</dt>
<t>ROM - Read Only Memory</t> <dd>Megabits per second</dd>
<t>RSVP - Resource Reservation Protocol</t> <dt>M2M:</dt>
<t>RTP - Real-time Transport Protocol</t> <dd>Machine-to-Machine</dd>
<t>SDN - Software-Defined Networking</t> <dt>NAP:</dt>
<t>SFC - Service Function Chaining</t> <dd>Network Attachment Point</dd>
<t>SLA - Service Level Agreement</t> <dt>NDN:</dt>
<t>TCL - Transport Convergence Layer</t> <dd>Named Data Networking</dd>
<t>TCP - Transmission Control Protocol</t> <dt>NETCONF:</dt>
<t>UDP - User Datagram Protocol</t> <dd>Network Configuration Protocol</dd>
<t>UMOBILE - Universal Mobile-centric and Opportunistic <dt>NetInf:</dt>
Communications Architecture</t> <dd>Network of Information </dd>
<t>US - United States</t> <dt>NFD:</dt>
<t>USA - United States of America</t> <dd>Named Data Networking Forwarding Daemon</dd>
<t>VoD - Video on Demand</t> <dt>NFV:</dt>
<t>VPN - Virtual Private Network</t> <dd>Network Functions Virtualization</dd>
<t>WG - Working Group</t> <dt>NICT:</dt>
<t>YANG - Yet Another Next Generation (data modeling lang <dd>Japan's National Institute of Information and Communications Technol
uage)</t> ogy</dd>
<t>5G - Fifth Generation (cellular network)</t> <dt>NR:</dt>
<t>6LoWPAN - IPv6 over Low-Power Wireless Personal <dd>New Radio (access network for 5G)</dd>
Area Networks</t> <dt>OAM:</dt>
</list> <dd>Operations, Administration, and Maintenance</dd>
</t> <dt>ONAP:</dt>
<dd>Open Network Automation Platform</dd>
<dt>OSPF:</dt>
<dd>Open Shortest Path First</dd>
<dt>PoC:</dt>
<dd>Proof of Concept (demo)</dd>
<dt>POINT:</dt>
<dd> IP Over ICN - the better IP (project)</dd>
<dt>qMp:</dt>
<dd>Quick Mesh Project</dd>
<dt>QoS:</dt>
<dd>Quality of Service</dd>
<dt>RAM:</dt>
<dd>Random Access Memory</dd>
<dt>RAN:</dt>
<dd>Radio Access Network</dd>
<dt>REST:</dt>
<dd>Representational State Transfer (architecture)</dd>
<dt>RESTCONF:</dt>
<dd>Representational State Transfer Configuration (protocol)</dd>
<dt>RIFE:</dt>
<dd>Architecture for an Internet For Everybody (project)</dd>
<dt>RIP:</dt>
<dd>Routing Information Protocol </dd>
<dt>ROM:</dt>
<dd>Read-Only Memory</dd>
<dt>RSVP:</dt>
<dd>Resource Reservation Protocol</dd>
<dt>RTP:</dt>
<dd>Real-time Transport Protocol</dd>
<dt>SDN:</dt>
<dd>Software-Defined Networking</dd>
<dt>SFC:</dt>
<dd>Service Function Chaining</dd>
<dt>SLA:</dt>
<dd>Service Level Agreement</dd>
<dt>TCL:</dt>
<dd>Transport Convergence Layer</dd>
<dt>TCP:</dt>
<dd>Transmission Control Protocol</dd>
<dt>UDP:</dt>
<dd>User Datagram Protocol</dd>
<dt>UMOBILE:</dt>
<dd>Universal Mobile-centric and Opportunistic Communications Architectu
re</dd>
<dt>US:</dt>
<dd>United States</dd>
<dt>USA:</dt>
<dd>United States of America</dd>
<dt>VoD:</dt>
<dd>Video on Demand</dd>
<dt>VPN:</dt>
<dd>Virtual Private Network</dd>
<dt>WG:</dt>
<dd>Working Group</dd>
<dt>YANG:</dt>
<dd>Yet Another Next Generation (data modeling language)</dd>
<dt>5G:</dt>
<dd>Fifth Generation (cellular network)</dd>
<dt>6LoWPAN:</dt>
<dd>IPv6 over Low-Power Wireless Personal Area Networks</dd>
</dl>
</section> </section>
<section anchor="sec_configurations" numbered="true" toc="default">
<section anchor="sec:configurations" title="Deployment Configurations"> <name>Deployment Configurations</name>
<t>In this section, we present various deployment options for ICN.
<t>In this section, we present various deployment options for ICN. These These are presented as "configurations" that allow for studying these
are presented as "configurations" that allow for studying these options options
further. While this document will outline experiences with various of th further. While this document will outline experiences with a number of
ese configurations (in <xref target="sec:trial_experiences" />), we will these configurations (in <xref target="sec_trial_experiences"
not provide an in-depth technical or commercial evaluation for any of the format="default"/>), we will
m - for this we refer to existing literature in this space such as <xref target= not provide an in-depth technical or commercial evaluation for any of
"Tateson" />. them -- for this, we refer to existing literature in this space, such as
</t> <xref target="Tateson" format="default"/>.
</t>
<section anchor="sec:replacements" title="Clean-slate ICN"> <section anchor="sec_replacements" numbered="true" toc="default">
<name>Clean-Slate ICN</name>
<t>ICN has often been described as a "clean-slate" approach with the goa <t>ICN has often been described as a "clean-slate" approach with the
l to renew or replace the complete IP infrastructure of the goal to renew or replace the complete IP infrastructure of the
Internet. As such, existing routing hardware as well as ancillar Internet.
y services such as existing applications which are typically tied directly As such, existing routing hardware and
to the TCP/IP protocol stack are not taken for granted. For inst ancillary services, such as existing applications that are
ance, a Clean-slate ICN deployment would see existing IP routers being typically tied directly to the TCP/IP stack, are not
replaced by ICN-specific forwarding and routing elements, such as taken for granted. For instance, a Clean-slate ICN deployment
NFD <xref target="NFD" />, CCN routers would see existing IP routers being replaced by ICN-specific
<xref target="Jacobson" /> or PURSUIT forwarding nodes <xref targ forwarding and routing elements, such as NFD <xref
et="IEEE_Communications" />. target="NFD" format="default"/>, CCNx routers <xref
target="Jacobson" format="default"/>, or Publish-Subscribe
Internet Technology (PURSUIT) forwarding nodes <xref
target="IEEE_Communications" format="default"/>.
</t> </t>
<t>While such clean-slate replacement could be seen as exclusive for
<t>While such clean-slate replacement could be seen as exclusive for ICN ICN deployments, some ICN approaches (e.g., <xref target="POINT"
deployments, some ICN approaches (e.g., <xref target="POINT" />) format="default"/>)
also rely on the deployment of general infrastructure upgrades, i also rely on the deployment of general infrastructure
n this case SDN switches. Different proposals have been made for various upgrades, in this case, SDN switches. Different proposals have
ICN approaches to enable the operation over an SDN transport <xre been made for various
f target="Reed" /><xref target="CONET" /><xref target="C_FLOW" />. ICN approaches to enable the operation over an SDN transport
<xref target="Reed" format="default"/> <xref target="CONET"
format="default"/> <xref target="C_FLOW" format="default"/>.
</t> </t>
</section> </section>
<section anchor="sec_overlay" numbered="true" toc="default">
<section anchor="sec:overlay" title="ICN-as-an-Overlay"> <name>ICN-as-an-Overlay</name>
<t>Similar to other significant changes to the Internet routing
<t>Similarly to other significant changes to the Internet routing fabric fabric, particularly the transition from IPv4 to IPv6 or
, particularly the transition from IPv4 to IPv6 or the introduction of IP multicast, this deployment
the introduction of IP multicast, this deployment configuration f configuration foresees the creation of an ICN overlay. Note
oresees the creation of an ICN overlay. Note that this overlay that this overlay
approach is sometimes, informally, also referred to as a tunnelin approach is sometimes, informally, also referred to as a
g approach. The overlay approach can be implemented directly tunneling approach.
such as ICN-over-UDP as described in <xref target="CCNx_UDP" />. The overlay approach can be implemented directly
Alternatively, the overlay can be accomplished via ICN-in-L2-in-IP (e.g., ICN-over-UDP), as described in <xref target="CCNx_UDP"
as in <xref target="IEEE_Communications" /> which describes a rec format="default"/>. Alternatively, the overlay can be
ursive layering process. Another approach used in the Network of accomplished via ICN-in-L2-in-IP as in <xref
Information (NetInf) is to define a convergence layer to map NetI target="IEEE_Communications" format="default"/>, which
nf semantics to HTTP <xref target="I-D.kutscher-icnrg-netinf-proto" />. describes a recursive layering process. Another approach used
Finally, <xref target="Overlay_ICN" /> describes an incremental a in the Network of Information (NetInf) is to define a
pproach to deploying an ICN architecture particularly well-suited to convergence layer to map NetInf semantics to HTTP <xref
SDN based networks by also segregating ICN user and control plane target="I-D.kutscher-icnrg-netinf-proto" format="default"/>.
traffic. Finally, <xref target="Overlay_ICN" format="default"/>
describes an incremental approach to deploying an ICN
architecture particularly well suited to
SDN-based networks by also segregating ICN user- and
control-plane traffic.
</t> </t>
<t>However, regardless of the flavor, the overlay approach results in
<t>Regardless of the flavor, however, the overlay approach result islands of ICN deployments over existing IP-based infrastructure.
s in islands of ICN deployments over existing IP-based infrastructure. Furthermore, these ICN islands are typically connected to each
Furthermore, these ICN islands are typically connected to each ot other via ICN/IP tunnels. In certain scenarios, this requires
her via ICN/IP tunnels. In certain scenarios this requires interoperability between existing IP routing protocols (e.g.,
interoperability between existing IP routing protocols (e.g., OSP OSPF, RIP, or IS-IS) and ICN-based ones. ICN-as-an-Overlay can be
F, RIP, ISIS) and ICN based ones. ICN-as-an-Overlay can be deployed deployed
over the IP infrastructure in either edge or core networks. This over the IP infrastructure in either edge or core networks.
overlay approach is thus very attractive for ICN experimentation This overlay approach is thus very attractive for ICN
and testing as it allows rapid and easy deployment of ICN over ex experimentation
isting IP networks. and testing, as it allows rapid and easy deployment of ICN over
existing IP networks.
</t> </t>
</section> </section>
<section anchor="sec_underlay" numbered="true" toc="default">
<section anchor="sec:underlay" title="ICN-as-an-Underlay"> <name>ICN-as-an-Underlay</name>
<t>Proposals, such as <xref target="POINT" format="default"/> and <xref
<t>Proposals such as <xref target="POINT" /> and <xref target="White" /> target="White" format="default"/>, outline the deployment option of
outline the deployment option of using an ICN underlay that would using an ICN underlay that would
integrate with existing (external) IP-based networks by deploying integrate with existing (external) IP-based networks by
application layer gateways at appropriate locations. The main reasons for deploying application-layer gateways at appropriate locations.
such a configuration option is the introduction of ICN technology The main reasons for
in given islands (e.g., inside a CDN or edge IoT network) to reap the benefits such a configuration option is the introduction of ICN
of native ICN in terms of underlying multicast delivery, mobility technology in given islands (e.g., inside a CDN or edge IoT
support, fast indirection due to location independence, in-network computing network) to reap the benefits
and possibly more. The underlay approach thus results in islands of native ICN, in terms of underlying multicast delivery,
of native ICN deployments which are connected to the rest of the Internet mobility support, fast indirection due to location
through protocol conversion gateways or proxies. Routing domains independence, in-network computing,
are strictly separated. Outside of the ICN island, normal IP routing protocols and possibly more. The underlay approach thus results in
apply. Within the ICN island, ICN based routing schemes apply. islands of native ICN deployments that are connected to the
The gateways transfer the semantic content of the messages (i.e., IP packet payl rest of the Internet
oad) through protocol conversion gateways or proxies. Routing
between the two routing domains. 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.
</t> </t>
<section anchor="sec_application_gateways" numbered="true" toc="default"
<section anchor="sec:application_gateways" title="Edge Network"> >
<name>Edge Network</name>
<t>Native ICN networks may be located at the edge of the network where t <t>Native ICN networks may be located at the edge of the network
he introduction of new network where the introduction of new network
architectures and protocols is easier in so-called greenfield dep architectures and protocols is easier in so-called greenfield
loyments. In this context ICN is an attractive option deployments. In this context, ICN is an attractive option
for scenarios such as IoT <xref target="I-D.irtf-icnrg-icniot" /> for scenarios, such as IoT <xref target="I-D.irtf-icnrg-icniot"
. The integration with the current IP protocol suite takes place at an format="default"/>. The integration with the current IP
application gateway/proxy at the edge network boundary, e.g., tra protocol suite takes place at an
nslating incoming CoAP request/response transactions application gateway/proxy at the edge network boundary, e.g.,
<xref target="RFC7252" /> into ICN message exchanges or vice vers translating incoming CoAP request/response transactions
a. <xref target="RFC7252" format="default"/> into ICN message
exchanges or vice versa.
</t> </t>
<t>The work in <xref target="VSER" format="default"/> positions ICN
<t>The work in <xref target="VSER" /> positions ICN as an edge se as an edge service gateway driven by a generalized ICN-based service
rvice gateway driven by a generalized ICN based service orchestration orchestration
system with its own compute and network virtualization controller system with its own compute and network virtualization
s to manage an ICN infrastructure. The platform also offers service discovery controllers to manage an ICN infrastructure. The platform also
capabilities to enable user applications to discover appropriate offers service discovery
ICN service gateways. To exemplify a use case scenario, the <xref target="VSER" capabilities to enable user applications to discover
/> platform appropriate ICN service gateways. To exemplify a
shows the realization of a multi-party audio/video conferencing s scenario in a use case, the <xref target="VSER" format="default"/
ervice over such a edge cloud deployment of ICN routers realized over commodity > platform
hardware platforms. This platform has also been extended to offer shows the realization of a multi-party audio/video
seamless mobility and mobility as a service <xref target="VSER-Mob" /> features conferencing service over such an edge cloud deployment of ICN
. routers realized over commodity hardware platforms. This platfor
</t> m has also been extended to
offer seamless mobility as a service that <xref
</section> target="VSER-Mob" format="default"/> features.
</t>
<section anchor="sec:http_ip" title="Core Network"> </section>
<section anchor="sec_http_ip" numbered="true" toc="default">
<t>In this sub-option, a core network would utilize edge-based protocol <name>Core Network</name>
mapping onto the native ICN underlay. For instance, <xref target="POINT" /> prop <t>In this suboption, a core network would utilize edge-based
oses protocol mapping onto the native ICN underlay. For instance, <xref
to map HTTP transactions, or some other IP based transactions suc target="POINT" format="default"/> proposes
h as CoAP, directly onto an ICN-based message exchange. This mapping is realized to map HTTP transactions or some other IP-based transactions,
at the such as CoAP, directly onto an ICN-based message
NAP, such as realized in access points or customer premise equipm exchange. This mapping is realized at the
ent, which in turn provides a standard IP interface to existing NAP, for example, in access points or customer premise
user devices. The NAPs thus provides the apparent perception of a equipment, which, in turn, provides a standard IP interface to
n IP-based core network towards any external peering network. existing user devices. Thus, the NAP provides the apparent
perception of an IP-based core network toward any external
peering network.
</t> </t>
<t>The work in <xref target="White" format="default"/> proposes a
<t>The work in <xref target="White" /> proposes a similar deployment con similar deployment configuration. There, the goal is to use ICN for
figuration. There, the goal is to use ICN for content distribution within CDN content distribution within CDN
server farms. Specifically, the protocol mapping is realized at server farms. Specifically, the protocol mapping is realized
the ingress of the server farm where the HTTP-based retrieval request is served, at the ingress of the server farm where the HTTP-based
while the retrieval request is served, while the
response is delivered through a suitable egress node translation. response is delivered through a suitable egress node
translation.
</t> </t>
</section>
</section> </section>
</section> <section anchor="sec_icn_slice" numbered="true" toc="default">
<name>ICN-as-a-Slice</name>
<section anchor="sec:icn_slice" title="ICN-as-a-Slice"> <t> The objective of network slicing <xref target="NGMN-5G"
format="default"/> is to multiplex a general pool of compute, storage,
<t> The objective of Network slicing <xref target="NGMN-5G"/> is to mult and bandwidth resources among multiple service networks with exclusive SL
iplex a general pool of compute, storage and bandwidth A
resources among multiple service networks with exclusive SLA requ requirements on transport and compute-level QoS and security. This is
irements on transport and compute level QoS and security. This is enabled through NFV and SDN technology functions that enable
enabled through NFV and SDN technology functions that enables fun functional decomposition (hence, modularity, independent scalability
ctional decomposition hence modularity, independent scalability of control, and/or the user-plane functions), agility, and service-drive
of control and/or the user-plane functions, agility and service d n
riven programmability. Network slicing is often associated with programmability. Network slicing is often associated with 5G but is
5G but is clearly not limited to such systems. However, from a 5 clearly not limited to such systems. However, from a 5G perspective,
G perspective, the definition of slicing includes access network the definition of slicing includes access networks enabling dynamic
enabling dynamic slicing the spectrum resources among various ser slicing of the spectrum resources among various services, hence naturally
vices hence naturally extending itself to end extending itself to end points and cloud resources across
points and also cloud resources across multiple domains, to offer multiple domains, to offer end-to-end guarantees.
end-to-end guarantees. These slices once instantiated Once instantiated, these slices
could include a mix of connectivity services like LTE-as-a-servic could include a mix of connectivity services (e.g.,
e or OTT services like VoD or other IoT services through LTE-as-a-service), Over-the-Top (OTT) services (e.g., VoD), or
composition of a group of virtual and/or physical network functio other IoT services through composition of a group of virtual
ns at control, user and service plane level. Such a framework and/or physical network functions at the control-, user-, and
can also be used to realize ICN slices with its own control and f service-plane levels. Such a framework
orwarding plane over which one or more end-user can also be used to realize ICN slices with its own control
services can be delivered <xref target="NGMN-Network-Slicing"/>.< and forwarding plane, over which one or more end-user
/t> services can be delivered <xref target="NGMN-Network-Slicing"
format="default"/>.</t>
<t>The 5G next generation architecture <xref target="fiveG-23501" <t>The 5G next generation architecture <xref target="fiveG-23501"
/> provides the flexibility to deploy the ICN-as-a-Slice format="default"/> provides the flexibility to deploy the
over either the edge (RAN), Mobile core network, or the ICN-as-a- ICN-as-a-Slice over either the edge (RAN) or mobile core network; otherwi
Slice may be deployed end-to-end. Further discussions on se,
extending the architecture presented in <xref target="fiveG-23501 the ICN-as-a-Slice may be deployed end to end. Further discussions on
"/> and the corresponding procedures extending the architecture presented in <xref target="fiveG-23501"
in <xref target="fiveG-23502"/> to support ICN has been provided format="default"/> and the corresponding procedures in <xref
in <xref target="I-D.ravi-icnrg-5gc-icn" />. The draft elaborates target="fiveG-23502" format="default"/> to support ICN has been
on two possible approaches to enable ICN. First, as an edge servi provided in <xref target="I-D.ravi-icnrg-5gc-icn"
ce using the local data network format="default"/>.
(LDN) feature in 5G using UPF classification functions to fast ha
ndover to the ICN forwarder; the other is as a native deployment
using the non-IP PDU support that would allow new network layer P
DU to be handed over to ICN UPFs collocated with the gNB functions,
without invoking any IP functions. While the former deployment wo
uld still rely on 3GPP based mobility functions, the later would
allow mobility to be handled natively by ICN. However both these
deployment modes should benefit from other ICN features such as
in-network caching and computing. Associated with this ICN user p
lan enablement, control plane extensions are also proposed
leveraging 5GC’s interface to other application functions (AF) to
allow new network service level programmability. Such a
generalized network slicing framework should be able to offer ser
vice slices over both IP and ICN. Coupled
with the view of ICN functions as being "chained service function
s" <xref target="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 not
ed that ICN is not creating the network slice, but
instead that the slice is created to run an 5G-ICN instance <xref
target="Ravindran"/>.</t>
<t>At the level of the specific technologies involved, such as ON
AP <xref target="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 f
or new network deployments, some ICN approaches will need to
integrate with SDN as a data plane forwarding function, as briefl
y discussed in <xref target="sec:replacements" />. Further
cross domain ICN slices can also be realized using frameworks suc
h as <xref target="ONAP"/>.
</t>
The document elaborates on two possible approaches to
enable ICN: (1) as an edge service using the local data network (LDN)
feature in 5G using User Plane Function (UPF) classification
functions to fast
handover to the ICN forwarder and (2) as a native deployment
using the non-IP Protocol Data Unit (PDU) support that would allo
w new network
layer PDU to be handed over to ICN UPFs collocated with the
Generation NodeB (gNB) functions without invoking any IP
functions. While the
former deployment would still rely on 3GPP-based mobility
functions, the later would
allow mobility to be handled natively by ICN. However, both
these deployment modes should benefit from other ICN features,
such as in-network caching and computing. Associated with this
ICN user-plane enablement, control-plane extensions are also
proposed leveraging 5th Generation Core Network (5GC)'s
interface to other application functions (AFs)
to allow new network service-level programmability. Such a
generalized network slicing framework should be able to offer
service slices over both IP and ICN. Coupled
with the view of ICN functions as being "service
function chaining" <xref target="RFC7665" format="default"/>, an
ICN
deployment within such
a slice could also be realized within the emerging control
plane that is targeted for adoption in future
(e.g., 5G mobile) network deployments. Finally, it should be
noted that ICN is not creating the network slice but
instead that the slice is created to run a 5G-ICN instance
<xref target="Ravindran" format="default"/>.</t>
<t>At the level of the specific technologies involved, such as ONAP
<xref target="ONAP" format="default"/> (which can be used to orchestrate
slices),
the 5G-ICN slice requires compatibility, for instance, at the
level of the forwarding/data plane depending on if it is
realized as
an overlay or using programmable data planes. With SDN
emerging for new network deployments, some ICN approaches will
need to
integrate as a data-plane forwarding function with SDN, as
briefly discussed in <xref target="sec_replacements"
format="default"/>. Further
cross-domain ICN slices can also be realized using frameworks,
such as <xref target="ONAP" format="default"/>.</t>
</section> </section>
<section anchor="sec_hybrid" numbered="true" toc="default">
<section anchor="sec:hybrid" title="Composite-ICN Approach"> <name>Composite-ICN Approach</name>
<t>Some deployments do not clearly correspond to any of the previously
<t>Some deployments do not clearly correspond to any of the previously defined basic configurations of
defined basic configurations of (1) Clean-slate ICN, (2) ICN-as-an-Overlay, (3) ICN-as-an-Underlay,
(1) Clean-slate ICN; (2) ICN-as-an-Overlay; (3) ICN-as-an-Underlay; and and (4) ICN-as-a-Slice. Or, a deployment
(4) ICN-as-a-Slice. Or, a deployment may contain a composite mixture of the properties of these basic
may contain a composite mixture of the properties of these basic config configurations. For example, the Hybrid ICN
urations. For example, the Hybrid ICN <xref target="H-ICN_1" format="default"/> approach carries ICN names
<xref target="H-ICN_1" /> approach carries ICN names in existing IPv6 h in existing IPv6 headers and does not have distinct gateways
eaders and does not have distinct gateways or tunnels connecting ICN islands or any other distinct feature
or tunnels connecting ICN islands, or any other distinct feature identi identified in the previous basic configurations.
fied in the previous basic configurations. So we categorize Hybrid ICN and other approaches that do not
So we categorize Hybrid ICN, and other approaches that do not clearly c clearly correspond to one of the other basic
orrespond to one of the other basic configurations as a Composite-ICN approach.</t>
configurations, as a Composite-ICN approach.</t>
</section> </section>
</section>
</section> <section anchor="sec_migration" numbered="true" toc="default">
<name>Deployment Migration Paths</name>
<section anchor="sec:migration" title="Deployment Migration Paths"> <t>We now focus on the various migration paths that will have importance
to the various stakeholders that are usually involved
<t>We now focus on the various migration paths that will have importance in the deployment of ICN networks. We can identify these stakeholders
to the various stakeholders that are usually involved as:
in the deployment of ICN networks. We can identify these stakeholders as: </t>
<list style="symbols"> <ul spacing="normal">
<t>Application providers</t> <li>application providers</li>
<t>ISPs and service providers, both as core as well as access network <li>ISPs and service providers, both as core and access network
providers, and also ICN network providers</t> providers, as well as ICN network providers</li>
<t>CDN providers (due to the strong relation of the ICN proposition to <li>CDN providers (due to the strong relation of the ICN proposition
content delivery)</t> to content delivery)</li>
<t>End device manufacturers and users</t> <li>end-device manufacturers and users</li>
</list> </ul>
Our focus is on technological aspects of such migration. Economic or regu <t>
latory aspects, such as studied in <xref target="Tateson" />, Our focus is on technological aspects of such migration. Economic or
<xref target="Techno_Economic" /> and <xref target="Internet_Pricing" /> regulatory aspects, such as those studied in <xref target="Tateson"
are left out of our discussion. format="default"/>,
<xref target="Techno_Economic" format="default"/>, and <xref
target="Internet_Pricing" format="default"/>, are left out of our
discussion.
</t> </t>
<section anchor="sec_apps_service" numbered="true" toc="default">
<section anchor="sec:apps_service" title="Application and Service Migratio <name>Application and Service Migration</name>
n"> <t>The Internet supports a multitude of applications and services
using the many protocols defined over the packet-level IP
<t>The Internet supports a multitude of applications and services using service. HTTP provides
the many protocols defined over the packet level IP service. HTTP provides one convergence point for these services with many web
one convergence point for these services with many Web developmen development frameworks based on the semantics provided by it.
t frameworks based on the semantics provided by it. In recent years, even services such as video delivery have
In recent years, even services such as video delivery have been m been migrating from the traditional RTP-over-UDP delivery to
igrating from the traditional RTP-over-UDP delivery to the various HTTP-level the various HTTP-level
streaming solutions, such as DASH <xref target="DASH" /> and othe streaming solutions, such as DASH <xref target="DASH"
rs. Nonetheless, many non-HTTP services exist, all of which need consideration format="default"/> 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. when migrating from the IP-based Internet to an ICN-based one.
</t> </t>
<t>The underlay deployment configuration option presented in <xref
<t>The underlay deployment configuration option presented in <xre target="sec_underlay" format="default"/> aims at providing some level
f target ="sec:underlay" /> aims at providing some level of compatibility of compatibility
to the existing ecosystem through a proxy based message flow mapp to the existing ecosystem through a proxy-based message flow
ing mechanism (e.g., mapping of existing HTTP/TCP/IP message flows to mapping mechanism (e.g., mapping of existing HTTP/TCP/IP
HTTP/ICN message flows). A related approach of mapping TCP/IP to message flows to
TCP/ICN message flows is described in <xref target="Moiseenko" />. HTTP/ICN message flows). A related approach of mapping TCP/IP
Another approach described in <xref target="Marchal" /> uses HTTP to TCP/ICN message flows is described in <xref
/NDN gateways and focuses in particular on the right strategy to map target="Moiseenko" format="default"/>.
HTTP to NDN to guarantee a high level of compatibility with HTTP Another approach described in <xref target="Marchal"
while enabling an efficient caching of Data in the ICN island. The choice format="default"/> uses HTTP/NDN gateways and focuses, in
of approach is a design decision based on how to configure the pr particular, on the right strategy to map
otocol stack. For example, the approach HTTP to NDN to guarantee a high level of compatibility with
described in <xref target="Moiseenko" /> carries the TCP layer in HTTP while enabling an efficient caching of data in the ICN
to the ICN underlay. While the <xref target="Marchal" /> approach island. The choice
terminates both HTTP and TCP at the edge of the ICN underlay and of approach is a design decision based on how to configure the
maps these functionalities onto existing ICN functionalities. protocol stack. For example, the approach
described in <xref target="Moiseenko" format="default"/>
carries the TCP layer into the ICN underlay, while the <xref
target="Marchal" format="default"/> approach
terminates both HTTP and TCP at the edge of the ICN underlay
and maps these functionalities onto existing ICN
functionalities.
</t> </t>
<t>Alternatively, ICN-as-an-Overlay (<xref target="sec_overlay"
<t>Alternatively, ICN as an overlay (<xref target="sec:overlay" / format="default"/>) and ICN-as-a-Slice (<xref
>), as well as ICN-as-a-Slice (<xref target="sec:icn_slice" />), allow for the target="sec_icn_slice" format="default"/>) allow for the
introduction of the full capabilities of ICN through new applicat introduction of the full capabilities of ICN through new
ion/service interfaces as well as operations in the network. With that, these application/service interfaces, as well as operations in the
approaches of deployment are likely to aim at introducing new app network. With that, these
lication/services capitalizing on those ICN capabilities, such as in-network 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. multicast and/or caching.
</t> </t>
<t>Finally, <xref target="I-D.irtf-icnrg-icn-lte-4g"
<t>Finally, <xref target="I-D.irtf-icnrg-icn-lte-4g" /> outlines format="default"/> outlines a dual-stack end-user device approach that
a dual-stack end user device approach that is applicable for all deployment is applicable for all deployment
configurations. Specifically, it introduces middleware layers (c configurations. Specifically, it introduces middleware layers
alled the TCL) in the device that will dynamically adapt existing applications (called the TCL) in the device that will dynamically adapt
to either an underlying ICN protocol stack or standard IP protoco existing applications
l stack. This involves end device to either an underlying ICN protocol stack or standard IP
signalling with the network to determine which protocol stack ins protocol stack. This involves end device
tance and associated middleware adaptation layers to utilize for a given signaling with the network to determine which protocol stack
application transaction. instance and associated middleware adaptation layers to
utilize for a given application transaction.
</t> </t>
</section> </section>
<section anchor="sec_cdn_migration" numbered="true" toc="default">
<section anchor="sec:cdn_migration" title="Content Delivery Network Migrat <name>Content Delivery Network Migration</name>
ion"> <t>A significant number of services and applications are devoted to
content delivery in some form, e.g., as video delivery, social media
<t>A significant number of services and applications are devoted to cont platforms,
ent delivery in some form, either as video delivery, social media platforms, and many others. CDNs are deployed to assist these services
and many others. CDNs are deployed to assist these services throu through localizing the content requests and therefore reducing
gh localizing the content requests and therefore reducing latency and possibly latency and possibly
increase utilization of available bandwidth as well as reducing t increasing utilization of available bandwidth, as well as
he load on origin servers. Similar to the previous sub-section, the underlay dep reducing the load on origin servers. Similar to the previous
loyment subsection, the underlay deployment
configuration presented in <xref target ="sec:underlay" /> aim at configuration presented in <xref target="sec_underlay"
providing a migration path for existing format="default"/> aims at providing a migration path for
CDNs. This is also highlighted in a BIER use case document <xref existing
target="I-D.ietf-bier-multicast-http-response" />, specifically with potential b CDNs. This is also highlighted in a BIER use-case document
enefits in <xref target="I-D.ietf-bier-multicast-http-response"
terms of utilizing multicast in the delivery of content but also format="default"/>, specifically with potential benefits
reducing load on origin as well as delegation server. We return to this benefit in
in terms of utilizing multicast in the delivery of content but
the trial experiences in <xref target="sec:trial_experiences" />. also reducing load on origin and delegation servers. We
return to this benefit in
the trial experiences in <xref target="sec_trial_experiences"
format="default"/>.
</t> </t>
</section> </section>
<section anchor="sec_edge_migration" numbered="true" toc="default">
<name>Edge Network Migration</name>
<t>Edge networks often see the deployment of novel network-level
technology, e.g., in the space of IoT. For many years, such
IoT deployments have relied,
and often still do, on proprietary protocols for reasons, such
as increased efficiency, lack of standardization incentives,
and others.
<section anchor="sec:edge_migration" title="Edge Network Migration"> Utilizing the
underlay deployment configuration in <xref
<t>Edge networks often see the deployment of novel network level technol target="sec_application_gateways" format="default"/>,
ogy, e.g., in the space of IoT. Such IoT deployments have for many years relied, application gateways/proxies can integrate such edge
and often still do, on proprietary protocols for reasons such as deployments
increased efficiency, lack of standardization incentives and others. Utilizing t into IP-based services, e.g., utilizing CoAP-based <xref
he target="RFC7252" format="default"/> M2M platforms, such
underlay deployment configuration in <xref target="sec:applicatio as oneM2M <xref target="oneM2M" format="default"/> or others.
n_gateways" />, application gateways/proxies can integrate such edge deployments
into IP-based services, e.g., utilizing CoAP <xref target="RFC725
2" /> based M2M platforms such as oneM2M <xref target="oneM2M" /> or others.
</t> </t>
<t>Another area of increased edge network innovation is that of mobile
(access) networks, particularly in the context of the 5G mobile
networks.
<t>Another area of increased edge network innovation is that of mobile ( Network softwarization (using technologies like service
access) networks, particularly in the context of the 5G Mobile networks. orchestration frameworks leveraging NFV and SDN concepts) are
With the proliferation of network softwarization (using technolog now common in access networks and other network segments.
ies like service orchestration frameworks leveraging NFV and SDN concepts) acces Therefore, the ICN-as-a-Slice deployment configuration in
s <xref target="sec_icn_slice" format="default"/> provides a
networks and other network segments, the ICN-as-a-Slice deploymen suitable migration path for the integration of non-IP-based
t configuration in <xref target="sec:icn_slice" /> provides a suitable migration edge networks into the overall system by virtue of
path realizing the relevant (ICN) protocols in an access network
for integration non-IP-based edge networks into the overall syste slice.
m through virtue of realizing the relevant (ICN) protocols in an access network
slice.
</t> </t>
<t>With the advent of SDN and NFV capabilities, so-called campus or
<t>With the advent of SDN and NFV capabilities, so-called campus site-specific deployments could see the introduction of ICN islands at
or site-specific deployments could see the introduction of ICN islands at the ed the edge for scenarios such as gaming or deployments based on Augmented R
ge eality
for scenarios such as gaming or AR/VR-based deployments for, e.g. (AR) / Virtual Reality (VR), e.g., smart cities or
, smart cities or theme parks.</t> theme parks.</t>
</section>
</section> <section anchor="sec_core_migration" numbered="true" toc="default">
<name>Core Network Migration</name>
<section anchor="sec:core_migration" title="Core Network Migration"> <t>Migrating core networks of the Internet or mobile networks requires
not only significant infrastructure renewal but also the fulfillment
<t>Migrating core networks of the Internet or Mobile networks requires n of the key performance requirements, particularly in terms of
ot only significant infrastructure renewal but also the fulfillment throughput. For those parts of the core network that would
of the key performance requirements, particularly in terms of thr migrate to an
oughput. For those parts of the core network that would migrate to an SDN-based optical transport, the ICN-as-a-Slice deployment
SDN-based optical transport the ICN-as-a-Slice deployment configu configuration in <xref target="sec_icn_slice"
ration in <xref target="sec:icn_slice" /> would allow the introduction format="default"/> would allow the introduction
of native ICN solutions within slices. This would allow for isola of native ICN solutions within slices. This would allow for
ting the ICN traffic while addressing the specific ICN performance benefits, isolating the ICN traffic while addressing the specific ICN
such as in-network multicast or caching, and constraints, such as performance benefits
the need for specific network elements within such isolated slices. (such as in-network multicast or caching) and constraints (such
For ICN solutions that natively work on top of SDN, the underlay as the need for specific network elements within such isolated
deployment configuration in <xref target="sec:http_ip" /> provides an slices).
additional migration path, preserving the IP-based services and a For ICN solutions that natively work on top of SDN, the
pplications at the edge of the network, while realizing the core network underlay deployment configuration in <xref
routing through an ICN solution (possibly itself realized in a sl target="sec_http_ip" format="default"/> provides an
ice of the SDN transport network). 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).
</t> </t>
</section> </section>
</section>
</section> <section anchor="sec_trial_experiences" numbered="true" toc="default">
<name>Deployment Trial Experiences</name>
<section anchor="sec:trial_experiences" title="Deployment Trial Experiences"> <t>In this section, we will outline trial experiences, often conducted
within collaborative project efforts. Our focus here is on the
<t>In this section, we will outline trial experiences, often conducted w realization
ithin collaborative project efforts. Our focus here is on the realization of the various deployment configurations identified in <xref
of the various deployment configurations identified in <xref targ target="sec_configurations" format="default"/>; therefore, we
et="sec:configurations" />, and we therefore categorize the trial experiences ac categorize the trial experiences according
cording to these deployment configurations. While a large body of
to these deployment configurations. While a large body of work e work exists at the simulation or emulation level, we
xists at the simulation or emulation level, we specifically exclude these studie specifically exclude these studies
s from our analysis to retain the focus on real-life
from our analysis to retain the focus on real life experiences. experiences.
</t> </t>
<section anchor="sec_overlay_deployment" numbered="true" toc="default">
<section anchor="sec:overlay_deployment" title="ICN-as-an-Overlay"> <name>ICN-as-an-Overlay</name>
<section anchor="sec_pursuit" numbered="true" toc="default">
<section anchor="sec:pursuit" title="FP7 PURSUIT Efforts"> <name>FP7 PURSUIT Efforts</name>
<t>Although the FP7 PURSUIT <xref target="IEEE_Communications"
<t>Although the FP7 PURSUIT <xref target="IEEE_Communications" /> effort format="default"/> efforts were generally positioned as a
s were generally positioned as a Clean-slate ICN replacement of IP Clean-slate ICN replacement of IP
(<xref target="sec:replacements" />), the project realized its ex (<xref target="sec_replacements" format="default"/>), the
perimental test bed as an L2 VPN-based overlay between several European, US project realized its experimental testbed as an L2 VPN-based
as well as Asian sites, following the overlay deployment configur overlay between several European, US,
ation presented in <xref target="sec:overlay" />. Software-based forwarders were and Asian sites, following the overlay deployment
utilized for the ICN message exchange, while native ICN applicati configuration presented in <xref target="sec_overlay"
ons, e.g., for video transmissions, were showcased. At the height of the project format="default"/>. Software-based forwarders were
efforts, about 70+ nodes were active in the (overlay) network wit utilized for the ICN message exchange, while native ICN
h presentations given at several conferences as well as to the ICNRG. 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.
</t> </t>
</section>
</section> <section anchor="sec_sail" numbered="true" toc="default">
<name>FP7 SAIL Trial</name>
<section anchor="sec:sail" title="FP7 SAIL Trial"> <t> The Network of Information (NetInf) is the approach to ICN
developed by the EU FP7 Scalable and Adaptive Internet Solutions
<t> The Network of Information (NetInf) is the approach to ICN developed (SAIL) project <xref target="SAIL" format="default"/>.
by the EU FP7 SAIL project <xref target="SAIL" />. NetInf provides both name-based forwarding with CCNx-like
NetInf provides both name-based forwarding with CCNx-like semanti semantics and name resolution (for indirection and
cs and name resolution (for indirection and late-binding). late binding).
The NetInf architecture supports different deployment options thr The NetInf architecture supports different deployment options
ough its convergence layer such as using UDP, HTTP, and even DTN underlays. through its convergence layer, such as using UDP, HTTP, and
In its first prototypes and trials, NetInf was deployed mostly in even DTN underlays.
an HTTP embedding and in a UDP overlay following the overlay deployment configu In its first prototypes and trials, NetInf was deployed mostly
ration in in an HTTP embedding and in a UDP overlay following the
<xref target="sec:overlay" />. Reference <xref target="SAIL_Proto overlay deployment configuration in
typing" /> describes several trials including a stadium environment and <xref target="sec_overlay" format="default"/>. <xref
a multi-site testbed, leveraging NetInf’s Routing Hint approach f target="SAIL_Prototyping" format="default"/> describes several
or routing scalability <xref target="SAIL_Content_Delivery" />. trials, including a stadium environment and
a multi-site testbed, leveraging NetInf's routing hint
approach for routing scalability <xref
target="SAIL_Content_Delivery" format="default"/>.
</t> </t>
</section>
</section> <section anchor="sec_ndn" numbered="true" toc="default">
<name>NDN Testbed</name>
<section anchor="sec:ndn" title="NDN Testbed"> <t>The Named Data Networking (NDN) is one of the research projects
of the National Science Foundation (NSF) of the USA as part of the
<t>The Named Data Networking (NDN) is one of the research projects of th Future
e National Science Foundation (NSF) of the USA as part of the Future Internet Architecture (FIA) Program. The original NDN
Internet Architecture (FIA) Program. The original NDN proposal w proposal was positioned as a Clean-slate ICN replacement of IP
as positioned as a Clean-slate ICN replacement of IP (<xref target="sec:replacem (<xref target="sec_replacements" format="default"/>).
ents" />). However, in several trials, NDN generally follows the overlay
However, in several trials, NDN generally follows the overlay dep deployment configuration of <xref target="sec_overlay"
loyment configuration of <xref target="sec:overlay" /> to connect institutions o format="default"/> to connect institutions over
ver the public Internet across several continents. The use cases
the public Internet across several continents. The use cases cov covered in the trials include real-time videoconferencing,
ered in the trials include real-time video-conferencing, geo-locating, and inter geolocating, and interfacing
facing to consumer applications. Typical trials involve up to 100
to consumer applications. Typical trials involve up to 100 NDN e NDN-enabled nodes <xref target="NDN-testbed"
nabled nodes <xref target="NDN-testbed" /> <xref target="Jangam" />. format="default"/> <xref target="Jangam" format="default"/>.
</t> </t>
</section>
</section> <section anchor="sec_ccn" numbered="true" toc="default">
<name>ICN2020 Efforts</name>
<section anchor="sec:ccn" title="ICN2020 Efforts"> <t>ICN2020 is an ICN-related project of the EU H2020 research
program and NICT <xref target="ICN2020-overview" format="default"/>.
<t>ICN2020 is an ICN related project of the EU H2020 research program an ICN2020 has a specific focus to advance ICN towards real-world
d NICT <xref target="ICN2020-overview" />. deployments through applications, such as video delivery,
ICN2020 has a specific focus to advance ICN towards real-world de interactive videos, and social
ployments through applications such as video delivery, interactive videos and so networks. The federated testbed spans the USA, Europe, and
cial Japan. Both NDN and CCNx approaches are within the scope of the
networks. The federated testbed spans the USA, Europe and Japan. project.
Both NDN and CCN approaches are within the scope of the project.
</t> </t>
<t>ICN2020 has released a set of interim public technical reports.
<t>ICN2020 has released a set of interim public technical reports The report <xref target="ICN2020-Experiments"
<xref target="ICN2020" />. format="default"/> contains a detailed description of the
The report <xref target="ICN2020-Experiments" /> contains a detai progress made in both local
led description of the progress made in both local testbeds and federated testbeds. The plan for the
testbeds as well as federated testbeds. The plan for the federat federated testbed includes integrating the NDN testbed,
ed testbed includes integrating the NDN testbed, the CUTEi testbed <xref target="RFC7945" format="default"/>
the CUTEi testbed <xref target="RFC7945" /> <xref target="CUTEi" <xref target="CUTEi" format="default"/>, and the GEANT testbed
/> and the GEANT testbed <xref target="GEANT" /> <xref target="GEANT" format="default"/>
to create an overlay deployment configuration of <xref target="se to create an overlay deployment configuration of <xref
c:overlay" /> over the public Internet. The total target="sec_overlay" format="default"/> over the public
network contains 37 nodes. Since video was an important applicat Internet. The total
ion typical throughput was measured in certain scenarios network contains 37 nodes. Since video was an important
and found to be in the order of 70 Mbps per node. application, typical throughput was measured in certain
scenarios and found to be in the order of 70 Mbps per node.
</t> </t>
</section>
</section> <section anchor="sec_umobile" numbered="true" toc="default">
<name>UMOBILE Efforts</name>
<section anchor="sec:umobile" title="UMOBILE Efforts"> <t>UMOBILE is another of the ICN research projects under the H2020
research program <xref target="UMOBILE-overview"
<t>UMOBILE is another of the ICN research projects under the H2020 resea format="default"/>.
rch program <xref target="UMOBILE-overview" />. The UMOBILE architecture integrates the principles of DTN and
The UMOBILE architecture integrates the principles of DTN and ICN ICN in a common framework to support edge computing and
in a common framework to support edge computing and mobile opportunistic wireless environments (e.g.,
mobile opportunistic wireless environments (e.g., post-disaster s post-disaster scenarios and remote areas). The UMOBILE
cenarios and remote areas). The UMOBILE architecture architecture
<xref target="UMOBILE-2" /> was developed on top of the NDN frame <xref target="UMOBILE-2" format="default"/> was developed on
work by following the overlay deployment configuration of top of the NDN framework by following the overlay deployment
<xref target="sec:overlay" />. UMOBILE aims to extend Internet fu configuration of
nctionally by combining ICN and DTN technologies. <xref target="sec_overlay" format="default"/>. UMOBILE aims to
extend Internet functionally by combining ICN and DTN
technologies.
</t> </t>
<t>One of the key aspects of UMOBILE was the extension of the NDN
<t>One of the key aspects of UMOBILE was the extension of the NDN framework to locate network services (e.g., mobility management and
framework to locate network services (e.g., mobility management, intermittent connectivity support) and user services (e.g.,
intermittent connectivity support) and user services (e.g., perva pervasive content management) as close as possible to the
sive content management) as close as possible to the end-users to optimize bandw end users to optimize bandwidth
idth utilization and resource management. Another aspect was the
utilization and resource management. Another aspect was the evolu evolution of the NDN framework to operate in challenging
tion of the NDN framework to operate in challenging wireless networks, namely in wireless networks, namely in emergency
emergency scenarios <xref target="UMOBILE-3" format="default"/> and
scenarios <xref target="UMOBILE-3" /> and environments with inter environments with intermittent connectivity. To achieve this,
mittent connectivity. To achieve this, the NDN framework was leveraged with a the NDN framework was leveraged with a
new messaging application called Oi! <xref target="UMOBILE-4" /> new messaging application called Oi! <xref target="UMOBILE-4"
<xref target="UMOBILE-5" /> that supports intermittent wireless networking. format="default"/> <xref target="UMOBILE-5" format="default"/>,
UMOBILE also implements a new data-centric wireless routing proto which supports intermittent wireless networking.
col, DABBER <xref target="UMOBILE-6" /> <xref target="I-D.mendes-icnrg-dabber" / UMOBILE also implements a new data-centric wireless routing
>, which was protocol, DABBER <xref target="UMOBILE-6" format="default"/>
designed based on data reachability metrics that take into consid <xref target="I-D.mendes-icnrg-dabber" format="default"/>,
eration availability of adjacent wireless nodes and different data which was
sources. The contextual-awareness of the wireless network operati designed based on data reachability metrics that take
on is obtained via a machine learning agent running within availability of adjacent wireless nodes and different data
the wireless nodes <xref target="UMOBILE-7" />. sources into consideration. The contextual awareness of the
wireless network operation is obtained via a machine-learning
agent running within the wireless nodes <xref
target="UMOBILE-7" format="default"/>.
</t> </t>
<t>The consortium has completed several ICN deployment trials. In a
<t>The consortium has completed several ICN deployment trails. In post-disaster scenario trial <xref target="UMOBILE-8"
a post disaster scenario trial <xref target="UMOBILE-8" />, format="default"/>,
a special DTN face was created to provide reachability to remote a special DTN face was created to provide reachability to
areas where there is no typical Internet remote areas where there is no typical Internet
connection. Another trail was the ICN deployment over the "Guifi. connection. Another trial was the ICN deployment over the
net" community network in the Barcelona region. This trial "Guifi.net" community network in the Barcelona region. This
focused on the evaluation of ICN edge computing platform, called trial
PiCasso <xref target="UMOBILE-9" />. In this focused on the evaluation of an ICN edge computing platform,
trial, ten (10) raspberry Pis were deployed across Barcelona to c called PiCasso <xref target="UMOBILE-9" format="default"/>. In
reate an ICN overlay network on top of the existing IP routing protocol this
(e.g., qMp routing). This trial showed that ICN can play a key ro trial, ten (10) Raspberry Pis were deployed across Barcelona
le in improving data delivery QoS as well as to create an ICN overlay network on top of the existing IP
reducing the traffic in intermittent connectivity environments (e routing protocol
.g., wireless community network). A third trial in Italy was focused (e.g., qMp routing). This trial showed that ICN can play a key
on displaying the capability of the UMOBILE architecture to reach role in improving data delivery QoS and
disconnected areas and assist responsible authorities in emergencies, reducing the traffic in intermittent connectivity environments
corresponding to an infrastructure scenario. The demonstration en (e.g., wireless community network). A third trial in Italy was
compassed seven (7) end-user devices, one (1) access-point, and one (1) gateway. focused
on displaying the capability of the UMOBILE architecture to
reach disconnected areas and assist responsible authorities in
emergencies,
corresponding to an infrastructure scenario. The demonstration
encompassed seven (7) end-user devices, one (1) access point,
and one (1) gateway.
</t> </t>
</section>
</section> </section>
<section anchor="sec_underlay_deployment" numbered="true" toc="default">
</section> <name>ICN-as-an-Underlay</name>
<section anchor="sec_point_rife" numbered="true" toc="default">
<section anchor="sec:underlay_deployment" title="ICN-as-an-Underlay"> <name>H2020 POINT and RIFE Efforts</name>
<t>POINT and RIFE are two more ICN-related research projects of the
<section anchor="sec:point_rife" title="H2020 POINT and RIFE Efforts"> H2020 research program.
The efforts in the H2020 POINT and RIFE projects follow the
<t>POINT and RIFE are two more ICN related research projects of the H202 underlay deployment configuration in
0 research program. <xref target="sec_http_ip" format="default"/>; edge-based NAPs
The efforts in the H2020 POINT+RIFE projects follow the underlay provide the IP/HTTP-level protocol mapping onto
deployment configuration in ICN protocol exchanges, while the SDN underlay (or the
<xref target="sec:http_ip" />, edge-based NAPs provide the IP/HTT VPN-based L2 underlay) is used as a transport network.
P-level protocol mapping onto
ICN protocol exchanges, while the SDN underlay (or the VPN-based
L2 underlay) is used as a transport network.
</t> </t>
<t>The multicast and service endpoint surrogate benefit in
<t>The multicast as well as service endpoint surrogate benefits in HTTP- HTTP-based scenarios, such as for
based scenarios, such as for HTTP-level streaming video delivery, and have been demonstrated i
HTTP-level streaming video delivery, have been demonstrated in th n
e deployed POINT test bed with the deployed POINT testbed with
80+ nodes being utilized. Demonstrations of this capability have 80+ nodes being utilized. Demonstrations of this capability
been given to the ICNRG, have been given to the ICNRG,
and public demonstrations were also provided at events <xref targ and public demonstrations were also provided at events <xref
et="MWC_Demo" />. The trial has also been accepted by the ETSI MEC target="MWC_Demo" format="default"/>. The trial has also been
accepted by the ETSI MEC
group as a public proof-of-concept demonstration. group as a public proof-of-concept demonstration.
</t> </t>
<t>While the aforementioned demonstrations all use the overlay
<t>While the afore-mentioned demonstrations all use the overlay deployme deployment, H2020 also has performed ICN underlay trials. One such
nt, H2020 also has performed ICN underlay trials. One such trial involved commercial end users located in the PrimeTel
trial involved commercial end users located in the Primetel netwo network in Cyprus with the use case centered on IPTV and HLS
rk in Cyprus with the use case centered on IPTV and HLS video video
dissemination. Another trial was performed over the "Guifi.net" c dissemination. Another trial was performed over the
ommunity network in the Barcelona region, where the solution "Guifi.net" community network in the Barcelona region, where
was deployed in 40 households, providing general Internet connect the solution
ivity to the residents. Standard IPTV STBs as well as HLS video was deployed in 40 households, providing general Internet
players were utilized in accordance with the aim of this deployme connectivity to the residents. Standard IPTV Set-Top
nt configuration, namely to provide application and service migration. Boxes(STBs), as well as HLS video
players, were utilized in accordance with the aim of this
deployment configuration, namely to provide application and
service migration.
</t> </t>
</section>
</section> <section anchor="sec_flame" numbered="true" toc="default">
<name>H2020 FLAME Efforts</name>
<section anchor="sec:flame" title="H2020 FLAME Efforts"> <t>The H2020 Facility for Large-Scale Adaptive Media Experimentation
(FLAME) efforts concentrate on providing an experimental
<t>The H2020 FLAME efforts concentrate on providing an experimental grou ground for the aforementioned POINT/RIFE
nd for the aforementioned POINT/RIFE solution in initially two city-scale locations, namely in
solution in initially two city-scale locations, namely in Bristol Bristol and Barcelona. This trial followed the
and Barcelona. This trial followed the underlay deployment configuration in <xref
underlay deployment configuration in <xref target="sec:http_ip" / target="sec_http_ip" format="default"/>, as per the POINT/RIFE
> as per POINT/RIFE approach. Experiments approach. Experiments
were conducted with the city/university joint venture Bristol-is- were conducted with the city/university joint venture
Open (BIO), to ensure the readiness of the Bristol-is-Open (BIO) to ensure the readiness of the
city-scale SDN transport network for such experiments. Another tr city-scale SDN transport network for such experiments. Another
ial was for the ETSI MEC PoC. This trial trial was for the ETSI MEC PoC. This trial
showcased operational benefits provided by the ICN underlay for t showcased operational benefits provided by the ICN underlay
he scenario of a location-based game. These for the scenario of a location-based game. These
benefits aim at reduced network utilization through improved vide benefits aim at reduced network utilization through improved
o delivery performance video delivery performance
(multicast of all captured videos to the service surrogates deplo (multicast of all captured videos to the service surrogates
yed in the city at six locations) deployed in the city at six locations),
as well as reduced latency through the playout of the video origi as well as reduced latency through the play out of the video
nating from the local NAP, collocated with the originating from the local NAP, collocated with the
WiFi AP instead of a remote server, i.e., the playout latency was Wi-Fi Access Point (AP) instead of a remote server, i.e., the pla
bounded by the maximum single hop latency. yout latency
was bounded by the maximum single-hop latency.
</t> </t>
<t> Twenty three (23) large-scale media service experiments are planned <t> Twenty three (23) large-scale media service experiments are
as part of the H2020 FLAME efforts planned as part of the H2020 FLAME efforts
in the area of Future Media Internet (FMI). The platform, whi in the area of Future Media Internet (FMI). The platform,
ch includes the ICN capabilities integrated with NFV which includes the ICN capabilities, integrated with NFV
and SDN capabilities of the infrastructure. The ultimate goal of and SDN capabilities of the infrastructure. The ultimate goal
these platform efforts is the full of these platform efforts is the full
integration of ICN into the overall media function platform for t integration of ICN into the overall media function platform
he provisioning of advanced for the provisioning of advanced
(media-centric) Internet services. (media-centric) Internet services.
</t> </t>
</section>
</section> <section anchor="sec_cablelabs" numbered="true" toc="default">
<name>CableLabs Content Delivery System</name>
<section anchor="sec:cablelabs" title="CableLabs Content Delivery System"> <t>The CableLabs ICN work reported in <xref target="White"
format="default"/> proposes an underlay deployment configuration
<t>The Cablelabs ICN work reported in <xref target="White" /> proposes a based on <xref target="sec_http_ip" format="default"/>.
n underlay deployment configuration based on <xref target="sec:http_ip" />. The use case is ICN for content distribution within complex
The use case is ICN for content distribution within complex CDN s CDN server farms to leverage ICN's superior in-network caching
erver farms to leverage ICN's superior in-network caching properties. properties.
This "island of ICN" based CDN is then used to service standard H This CDN based on "island of ICN" is then used to service
TTP/IP-based content retrieval request coming from the general Internet. standard HTTP/IP-based content retrieval requests coming from
This approach acknowledges that whole scale replacement (see <xre the general Internet.
f target="sec:replacements" />) of existing HTTP/IP end user applications This approach acknowledges that whole scale replacement (see
and related Web infrastructure is a difficult proposition. <xref <xref target="sec_replacements" format="default"/>) of
target="White" /> is clear that the architecture proposed had not yet existing HTTP/IP end-user applications
been tested experimentally but that implementations were in proce and related web infrastructure is a difficult proposition.
ss and expected in the 3-5 year time frame. <xref target="White" format="default"/> is clear that the
architecture proposed has not yet
been tested experimentally but that implementations are in
process and expected in the 3-5 year time frame.
</t> </t>
</section>
</section> <section anchor="sec_NDN_IoT" numbered="true" toc="default">
<name>NDN IoT Trials</name>
<section anchor="sec:NDN_IoT" title="NDN IoT Trials"> <t><xref target="Baccelli" format="default"/> summarizes the trial
of an NDN system adapted specifically for a wireless IoT scenario.
<t><xref target="Baccelli" /> summarizes the trial of an NDN system adap The trial was run with
ted specifically for a wireless IoT scenario. The trial was run with 60 nodes distributed over several multistory buildings in a
60 nodes distributed over several multi-story buildings in a univ university campus environment. The NDN protocols were
ersity campus environment. The NDN protocols were optimized to run directly optimized to run directly
over 6LoWPAN wireless link layers. The performance of the NDN ba over 6LoWPAN wireless link layers. The performance of the
sed IoT system was then compared to an equivalent system running standard IP NDN-based IoT system was then compared to an equivalent system
based IoT protocols. It was found that the NDN based IoT system running standard IP-based IoT protocols. It was found that
was superior in several respects including in terms of energy consumption, and the NDN-based IoT
for RAM and ROM footprints <xref target="Baccelli" /> <xref targe system was superior in several respects, including in terms of
t="Anastasiades" />. For example, the binary file size reductions for energy consumption and
NDN protocol stack versus standard IP based IoT protocol stack on for RAM and ROM footprints <xref target="Baccelli"
given devices were up to 60% less for ROM size and up to 80% less for RAM size. format="default"/> <xref target="Anastasiades"
format="default"/>. For example, the binary file size
reductions for
NDN protocol stack versus standard IP-based IoT protocol stack
on given devices were up to 60% less for ROM size and up to
80% less for RAM size.
</t> </t>
</section>
</section> <section anchor="sec_NREN" numbered="true" toc="default">
<name>NREN ICN Testbed</name>
<section anchor="sec:NREN" title="NREN ICN Testbed"> <t>The National Research and Education Network (NREN) ICN Testbed is
a project sponsored by Cisco, Internet2, and the US Research and
<t>The National Research and Education Network (NREN) ICN Testbed is a p Education
roject sponsored by Cisco, Internet2, and the US Research and Education community. Participants include universities and US federal
community. Participants include universities and US federal gover government entities that connect via a nationwide VPN-based
nment entities that connect via a nation-wide VPN-based L2 underlay. The testbed L2 underlay. The testbed
uses the CCN approach and is based on the <xref target="CICN" /> uses the CCNx approach and is based on the <xref target="CICN"
open source software. There are approximately 15 nodes spread across the USA whi format="default"/> open-source software. There are
ch approximately 15 nodes spread across the USA that
connect to the testbed. The project's current focus is to advanc connect to the testbed. The project's current focus is to
e data-intensive science and network research by improving data movement, search advance data-intensive science and network research by
ability, improving data movement, searchability,
and accessibility. and accessibility.
</t> </t>
</section>
</section> <section anchor="sec_Doctor" numbered="true" toc="default">
<name>DOCTOR Testbed</name>
<section anchor="sec:Doctor" title="Doctor Testbed"> <t>The DOCTOR project is a French research project meaning
"Deployment and Securisation of new Functionalities in Virtualized
<t>The Doctor project is a French research project meaning "Deployment a Networking Environments".
nd Securisation of new Functionalities in Virtualized Networking Environments". The project aims to run NDN over virtualized NFV
The project aims to run NDN over virtualized NFV infrastructure < infrastructure <xref target="Doctor" format="default"/> (based
xref target="Doctor" /> (based on Docker technology) and focuses on the NFV MANO on Docker technology) and focuses on the NFV MANO aspects
aspects to build an operational NDN network focusing on important
to build an operational NDN network focusing on important perform performance criteria, such as security, performance, and
ance criteria such as security, performance and interoperability. interoperability.
</t> </t>
<t>The data plane relies on an HTTP/NDN gateway <xref
<t>The data-plane relies on a HTTP/NDN gateway <xref target="Mar target="Marchal" format="default"/> that processes HTTP traffic and
chal" /> that processes HTTP traffic and transports it in an optimized way over transports it in an optimized way over NDN to
NDN to benefit from the properties of the NDN island (i.e., by
benefit from the properties of the NDN-island (i.e., by mapping mapping HTTP semantics to NDN semantics within the
HTTP semantics to NDN semantics within the NDN-island). The testbed carries NDN island). The testbed carries
real Web traffic of users, and has been currently evaluated with real Web traffic of users and has been currently evaluated
the top-1000 most popular Web sites. The users only need to set the gateway with the top 1000 most popular websites. The users only
as the Web proxy. The control-plane relies on a central manager need to set the gateway
which uses machine learning based detection methods <xref target="Mai-1" /> as the web proxy. The control plane relies on a central
from the date gathered by distributed probes and applies orchest manager that uses machine-learning-based detection methods
rated counter-measures against NDN attacks <xref target="Nguyen-1" /> <xref target="Mai-1" format="default"/>
<xref target="Nguyen-2" /> <xref target="Mai-2" /> or performanc from the date gathered by distributed probes and applies
e issues. A remediation can be, for example, the scale-up of a bottleneck orchestrated countermeasures against NDN attacks <xref
component, or the deployment of a security function like a firew target="Nguyen-1" format="default"/>
all or a signature verification module. Test results thus far have indicated <xref target="Nguyen-2" format="default"/> <xref target="Mai-2"
that key attacks can be detected accurately. For example, conte format="default"/> or performance issues. A remediation can be,
nt poisioning attacks can be detected at up to over 95% accuracy (with less than for example, the scale up of a bottleneck
0.01% false positives) <xref target="Nguyen-3" />. component or the deployment of a security function, like a
firewall or a signature verification module. Test results
thus far have indicated
that key attacks can be detected accurately. For example,
content poisoning attacks can be detected at up to over 95%
accuracy (with less than 0.01% false positives) <xref
target="Nguyen-3" format="default"/>.
</t> </t>
</section>
</section> </section>
<section anchor="sec_Other_configs" numbered="true" toc="default">
<name>Composite-ICN Approach</name>
<t>Hybrid ICN <xref target="H-ICN_1" format="default"/> <xref
target="H-ICN_2" format="default"/> 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 <xref target="CICN" format="default"/> open-source
software.
</section> Initial tests have been done with 150 clients consuming DASH videos,
which showed good scalability properties at the server side using the
<section anchor="sec:Other_configs" title="Composite-ICN Approach"> Hybrid ICN transport <xref target="H-ICN_3" format="default"/> <xref
<t>Hybrid ICN <xref target="H-ICN_1" /> <xref target="H-ICN_2" /> is an target="H-ICN_2" format="default"/>.</t>
approach where the ICN names are mapped to IPv6 addresses, and other ICN informa </section>
tion <section anchor="sec_trial_summary" numbered="true" toc="default">
is carried as payload inside the IP packet. This allows standard <name>Summary of Deployment Trials</name>
(ICN-unaware) IP routers to forward packets based on IPv6 info, but enables ICN <t>In summary, there have been significant trials over the years with
-aware all the major ICN protocol flavors (e.g., CCNx, NDN, and POINT) using bot
routers to apply ICN semantics. The intent is to enable rapid hyb h
rid deployments and seamless interconnection of IP and Hybrid ICN domains. Hybri the ICN-as-an-Overlay and ICN-as-an-Underlay deployment
d ICN configurations. The major limitations of the trials include
uses <xref target="CICN" /> open source software. Initial tests the fact that only a limited
have been done with 150 clients consuming DASH videos which showed good scalabil number of applications have been tested. However, the tested
ity applications include both native ICN and existing IP-based
properties at the Server Side using the Hybrid ICN transport <xre applications
f target="H-ICN_3" /> <xref target="H-ICN_2" />.</t> (e.g., videoconferencing and IPTV). Another limitation of
</section> the trials is that all of them involve less than 1k users.</t>
<t>Huawei and China Unicom have just started trials of the ICN-as-a-Slic
<section anchor="sec:trial_summary" title="Summary of Deployment Trials"> e configuration to demonstrate
<t>In summary, there have been significant trials over the years ICN features of security, mobility, and bandwidth efficiency
with all the major ICN protocol flavors (e.g., CCN, NDN, POINT) using both over a wired infrastructure using videoconferencing
the ICN-as-an-Overlay and ICN-as-an-Underlay deployment configura as the application scenario <xref target="Chakraborti"
tions. The major limitations of the trials include the fact that only a limited format="default"/>; also, this prototype has been extended to
number of applications have been tested. However, the tested app demonstrate this over a 5G-NR access.</t>
lications include both native ICN and existing IP based applications <t>The Clean-slate ICN approach has obviously never been in trials, as
(e.g., video-conferencing and IPTV). Another limitation of the t complete replacement of Internet
rials is that all of them involve less than 1k users.</t> infrastructure (e.g., existing applications, TCP/IP protocol
stack, IP routers, etc.) is no longer considered a viable
<t> The ICN-as-a-Slice configuration has just started being t alternative.</t>
rialled by Huawei and China Unicom to demonstrate <t>Finally, Hybrid ICN is a Composite-ICN approach that offers an
ICN features of security, mobility and bandwidth efficiency over interesting alternative, as it allows ICN semantics to be embedded in
a wired infrastructure using video conferencing standard
as the application scenario <xref target="Chakraborti" />, also t IPv6 packets so the packets can be routed through either IP
his prototype has been extended to demonstrate this over a 5G-NR access.</t> routers or Hybrid ICN routers. Note that some other trials,
such as the
<t>The Clean-slate ICN approach has obviously never been trialled DOCTOR testbed (<xref target="sec_Doctor" format="default"/>),
as complete replacement of Internet could also be characterized as a Composite-ICN approach,
infrastructure (e.g., existing applications, TCP/IP protocol stac because it contains both ICN gateways
k, IP routers, etc.) is no longer considered a viable alternative.</t> (as in ICN-as-an-Underlay) and virtualized infrastructure (as
in ICN-as-a-Slice). However, for the DOCTOR testbed, we have
<t>Finally, Hybrid ICN is a Composite-ICN approach that offers an chosen to characterize
interesting alternative as it allows ICN semantics to be embedded in standard it as an ICN-as-an-Underlay configuration because that is a
IPv6 packets so the packets can be routed through either IP route dominant characteristic.
rs or Hybrid ICN routers. Note that some other trials such as the
Doctor testbed (<xref target="sec:Doctor" />) could also be chara
cterized 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 domin
ant characteristic.
</t> </t>
</section>
</section> </section>
<section anchor="sec_standards" numbered="true" toc="default">
</section> <name>Deployment Issues Requiring Further Standardization</name>
<t><xref target="RFC7927"
<section anchor="sec:standards" title="Deployment Issues Requiring Further Stand format="default">"Information-Centric Networking (ICN) Research Challenges
ardization"> "</xref>
describes key ICN principles and technical research topics. As the
<t>The ICN Research Challenges <xref target="RFC7927" /> describes key I title suggests,
CN principles and technical research topics. As the title suggests, <xref target="RFC7927" format="default"/> is research oriented
<xref target="RFC7927" /> is research oriented without a specific without a specific focus on deployment or standardization
focus on deployment or standardization issues. This section addresses this issues. This section addresses this
open area by identifying key protocol functionality that that may open area by identifying key protocol functionality that
be relevant for further standardization effort in IETF. The focus is specifica may be relevant for further standardization effort in
lly the IETF.
on identifying protocols that will facilitate future interoperabl The focus is specifically
e ICN deployments correlating to the scenarios identified in the deployment on identifying protocols that will facilitate future
migration paths in <xref target="sec:migration" />. The identifi interoperable ICN deployments correlating to the scenarios
ed list of potential protocol functionality is not exhaustive. identified in the deployment
migration paths in <xref target="sec_migration"
format="default"/>. The identified list of potential protocol
functionality is not exhaustive.
</t> </t>
<section anchor="sec_standards_apps" numbered="true" toc="default">
<section anchor="sec:standards_apps" title="Protocols for Application and Servi <name>Protocols for Application and Service Migration</name>
ce Migration"> <t>End-user applications and services need a standardized approach to
trigger ICN transactions. For example, in Internet and web
<t>End user applications and services need a standardized approach to tr applications
igger ICN transactions. For example, in Internet and Web applications today, there are established socket APIs, communication
today, there are established socket APIs, communication paradigms paradigms (such as REST), common libraries, and best
such as REST, common libraries, and best practices. We see a need to study practices. We see a need to study
application requirements in an ICN environment further and, at th application requirements in an ICN environment further and, at
e same time, develop new APIs and best practices that can take advantage of ICN the same time, develop new APIs and best practices that can
take advantage of ICN
communication characteristics. communication characteristics.
</t> </t>
</section> </section>
<section anchor="sec_standards_cdn" numbered="true" toc="default">
<name>Protocols for Content Delivery Network Migration</name>
<t>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. <xref target="RFC6920"
format="default"/> 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 <xref target="RFC8609" format="default"/> and
<xref target="RFC8569" format="default"/>. Naming dynamically
generated data requires different approaches(e.g.,
hash-digest-based names would normally not work), and there is
a lack of established conventions and standards.
<section anchor="sec:standards_cdn" title="Protocols for Content Delivery Netwo </t>
rk Migration"> <t>Another CDN issue for ICN is related to multicast distribution of
content.
<t>A key issue in CDNs is to quickly find a location of a copy of the ob Existing CDNs have started using multicast mechanisms for
ject requested by an end user. In ICN, a Named Data Object (NDO) is certain cases, such as for broadcasting streaming TV. However, a
typically defined by its name. <xref target="RFC6920" /> defines s
a mechanism that is suitable for static naming of ICN data objects. Other discussed in <xref target="sec_point_rife" format="default"/>,
ways of encoding and representing ICN names have been described i certain ICN approaches provide
n <xref target="I-D.irtf-icnrg-ccnxmessages" /> and substantial improvements over IP multicast, such as the
<xref target="I-D.irtf-icnrg-ccnxsemantics" />. Naming dynamical implicit support for multicast retrieval of content in all ICN
ly generated data requires different approaches (e.g., hash digest flavors.
based names would normally not work), and there is lack of establ
ished conventions and standards.
</t>
<t>Another CDN issue for ICN is related to multicast distribution of con
tent. Existing CDNs have started using multicast mechanisms for
certain cases such as for broadcast streaming TV. However, as di
scussed in <xref target="sec:point_rife" />, certain ICN approaches provide
substantial improvements over IP multicast, such as the implicit
support for multicast retrieval of content in all ICN flavours.
</t> </t>
<t>Caching is an implicit feature in many ICN architectures that can
<t>Caching is an implicit feature in many ICN architectures that can imp improve performance and availability in several scenarios. The ICN
rove performance and availability in several scenarios. The ICN in-network caching can augment managed CDN and improve its
in-network caching can augment managed CDN and improve its perfor performance. The details of the interplay between ICN caching
mance. The details of the interplay between ICN caching and managed CDN and managed CDN need further consideration.
need further consideration.
</t> </t>
</section> </section>
<section anchor="sec_standards_edge_core" numbered="true" toc="default">
<section anchor="sec:standards_edge_core" title="Protocols for Edge and Core Ne <name>Protocols for Edge and Core Network Migration</name>
twork Migration"> <t>ICN provides the potential to redesign current edge and core
network computing approaches. Leveraging ICN's inherent security and
<t>ICN provides the potential to redesign current edge and core network its ability
computing approaches. Leveraging ICN’s inherent security and its ability to make name data and dynamic computation results available
to make name data and dynamic computation results available indep independent of location can enable a lightweight insertion
endent of location, can enable a light-weight insertion of traffic of traffic
into the network without relying on redirection of DNS requests. into the network without relying on redirection of DNS
For this, proxies that translate from commonly used protocols in the general requests. For this, proxies that translate from commonly used
Internet to ICN message exchanges in the ICN domain could be used protocols in the general
for the migration of application and services within deployments at the network Internet to ICN message exchanges in the ICN domain could be
edge but also in core networks. This is similar to existing appro used for the migration of application and services within
aches for IoT scenarios where a proxy translates CoAP request/responses to other deployments at the network
message formats. For example, <xref target="RFC8075" /> specifie edge but also in core networks. This is similar to existing
s proxy mapping between CoAP and HTTP protocols. Also, <xref target="RFC8613" / approaches for IoT scenarios where a proxy translates CoAP
> request/responses to other
is an example of how to pass end-to-end encrypted content between message formats. For example, <xref target="RFC8075"
HTTP and COAP by an application layer security mechanism. Further work is requ format="default"/> specifies proxy mapping between CoAP and
ired HTTP protocols. Also, <xref target="RFC8613"
to identify if an <xref target="RFC8613" />-like approach, or som format="default"/>
e other approach, is suitable to preserve ICN message security through future pr is an example of how to pass end-to-end encrypted content
otocol between HTTP and CoAP by an application-layer security
mechanism. Further work is required
to identify if an approach like <xref target="RFC8613"
format="default"/>, or some other approach, is
suitable to preserve ICN message security through future
protocol
translation functions of gateways/proxies. translation functions of gateways/proxies.
</t> </t>
<t>Interaction and interoperability between existing IP routing
<t>Interaction and interoperability between existing IP routing p protocols (e.g., OSPF, RIP, or IS-IS) and ICN routing
rotocols (e.g., OSPF, RIP, ISIS) and ICN routing approaches(e.g., NFD, CCN route approaches (e.g.,
rs) NFD and CCNx routers)
are expected especially in the overlay approach. Another importa are expected, especially in the overlay approach. Another
nt topic is the integration of ICN into networks that support virtualized infras important topic is the integration of ICN into networks that
tructure support virtualized infrastructure
in the form of NFV/SDN and most likely utilizing SFC as a key pro in the form of NFV/SDN and most likely utilize SFC as a key
tocol. Further work is required to validate this idea and document best practic protocol. Further work is required to validate this idea and
es. document best practices.
</t> </t>
<t>There are several existing approaches to supporting QoS in IP
<t>There are several existing approaches to supporting QoS in IP networks, including Diffserv, IntServ, and RSVP. Some initial ideas
networks including DiffServ, IntServ and RSVP. Some initial ideas for QoS supp for QoS support in ICN
ort in ICN networks are outlined in <xref
networks are outlined in <xref target="I-D.moiseenko-icnrg-flowcl target="I-D.moiseenko-icnrg-flowclass" format="default"/>,
ass" /> which proposes a flow classification based approach to enable functions which proposes an approach based on flow
such ICN classification to enable
rate control and cache control. Also <xref target="I-D.anilj-icn functions, such ICN
rg-icn-qos" /> proposes how to use DiffServ DSCP codes to support QoS for ICN ba rate control and cache control. Also, <xref
sed data target="I-D.anilj-icnrg-icn-qos" format="default"/> proposes
path delivery. Further work is required to identify the best app how to use Diffserv Differentiated Services Code Point (DSCP)
roaches for support of QoS in ICN networks. codes to support QoS for ICN-based data
path delivery. Further work is required to identify the best
approaches for support of QoS in ICN networks.
</t> </t>
<t>OAM is a crucial area that has not yet been fully addressed by the
<t>OAM is a crucial area that has not yet been fully addressed by the ICN ICN research community but which is obviously critical for future
research community, but which is obviously critical for future deployments of IC deployments of ICN.
N. Potential areas that need investigation include whether the YANG
Potential areas that need investigation include whether the YANG data m data modeling approach and associated NETCONF/RESTCONF protocols
odelling approach and associated NETCONF/RESTCONF protocols need any specific up need any specific updates
dates for ICN support. Another open area is how to measure and benchmark
for ICN support. Another open area is how to measure and benchmark perf performance of ICN networks comparable to the sophisticated
ormance of ICN networks comparable to the sophisticated techniques that exist fo techniques that exist for standard
r standard IP networks, virtualized networks, and data centers. It should be
IP networks, virtualized networks and data centers. It should be noted noted that some initial progress has been made in the area of ICN
that some initial progress has been made in the area of ICN network path tracer network path traceroute
oute facility with approaches, such as CCNxinfo <xref
facility with approaches such as CCNinfo <xref target="I-D.irtf-icnrg-c target="I-D.irtf-icnrg-ccninfo" format="default"/> <xref
cninfo" /> <xref target="Contrace" />. target="Contrace" format="default"/>.
</t> </t>
</section> </section>
<section anchor="sec_ICN_Challenges_Summary_Gaps" numbered="true" toc="def
<section anchor="sec:ICN_Challenges_Summary_Gaps" ault">
title="Summary of ICN Protocol Gaps and Potential Protocol Efforts" <name>Summary of ICN Protocol Gaps and Potential Protocol Efforts</name>
> <t>Without claiming completeness, <xref
target="tab_mapping_protocol_effort" format="default"/> maps the open
<t>Without claiming completeness, <xref target="tab:mapping_protocol_eff ICN issues identified in this document to potential protocol efforts
ort"/> maps the open ICN issues identified in this document to potential protoco that could address some aspects of the gap.
l
efforts that could address some aspects of the gap.
</t> </t>
<table anchor="tab_mapping_protocol_effort" align="center">
<texttable anchor="tab:mapping_protocol_effort" <name>Mapping of ICN Gaps to Potential Protocol Efforts</name>
title="Mapping of ICN Gaps to Potential <thead>
Protocol Efforts"> <tr>
<ttcol align="left">ICN Gap</ttcol> <th align="left">ICN Gap</th>
<ttcol align="left">Potential Protocol Effort</ttcol> <th align="left">Potential Protocol Effort</th>
<c>1-Support of</c> </tr>
<c>HTTP/CoAP support of ICN semantics</c> </thead>
<c>REST APIs</c> <tbody>
<c> </c> <tr>
<c> </c> <td align="left">1-Support of REST APIs</td>
<c> </c> <td align="left">HTTP/CoAP support of ICN semantics</td>
</tr>
<c>2-Naming</c> <tr>
<c>Dynamic naming of ICN data objects</c> <td align="left">2-Naming</td>
<c> </c> <td align="left">Dynamic naming of ICN data objects</td>
<c> </c> </tr>
<tr>
<c>3-Routing</c> <td align="left">3-Routing</td>
<c>Interactions between IP and ICN routing protocols</c> <td align="left">Interactions between IP and ICN routing protocols
<c> </c> </td>
<c> </c> </tr>
<tr>
<c>4-Multicast</c> <td align="left">4-Multicast distribution</td>
<c>Multicast enhancements for ICN</c> <td align="left">Multicast enhancements for ICN</td>
<c>distribution</c> </tr>
<c> </c> <tr>
<c> </c> <td align="left">5-In-network caching</td>
<c> </c> <td align="left">ICN cache placement and sharing</td>
</tr>
<c>5-In-network</c> <tr>
<c>ICN Cache placement and sharing</c> <td align="left">6-NFV/SDN support</td>
<c>caching</c> <td align="left">Integration of ICN with NFV/SDN and including
<c> </c> possible impacts to SFC</td>
<c> </c> </tr>
<c> </c> <tr>
<td align="left">7-ICN mapping</td>
<c>6-NFV/SDN</c> <td align="left">Mapping of HTTP and other protocols onto ICN
<c>Integration of ICN with NFV/SDN and including</c> message exchanges (and vice versa) while preserving ICN message
<c>support</c> security</td>
<c>possible impacts to SFC</c> </tr>
<c> </c> <tr>
<c> </c> <td align="left">8-QoS support</td>
<td align="left">Support of ICN QoS via mechanisms, such as
<c>7-ICN</c> Diffserv and flow classification</td>
<c>Mapping of HTTP and other protocols onto ICN</c> </tr>
<c>mapping</c> <tr>
<c>message exchanges (and vice-versa) while preserving <td align="left">9-OAM support</td>
ICN message security</c> <td align="left">YANG data models, NETCONF/RESTCONF protocols, and
<c> </c> network-performance measurements</td>
<c> </c> </tr>
</tbody>
<c>8-QoS</c> </table>
<c>Support of ICN QoS via mechanisms such as DiffServ</c> </section>
<c>support</c>
<c> and flow classification </c>
<c> </c>
<c> </c>
<c>9-OAM</c>
<c>YANG models, NETCONF/RESTCONF protocols,</c>
<c>support</c>
<c> and network performance measurements </c>
<c> </c>
<c> </c>
</texttable>
</section> </section>
<section anchor="sec_conclusion" numbered="true" toc="default">
</section> <name>Conclusion</name>
<t>This document provides high-level deployment considerations for
<section anchor="sec:conclusion" title="Conclusion"> current and future members of the ICN community. Specifically, the
major configurations of possible ICN deployments are identified as
<t>This document provides high level deployment considerations for curr (1) Clean-slate ICN replacement of existing Internet infrastructure,
ent and future members of the ICN community. Specifically, the (2) ICN-as-an-Overlay, (3) ICN-as-an-Underlay, (4) ICN-as-a-Slice,
major configurations of possible ICN deployments are identified as (1) and (5) Composite-ICN. Existing ICN trial systems primarily fall
Clean-slate ICN replacement of existing Internet infrastructure; under the ICN-as-an-Overlay, ICN-as-an-Underlay, and Composite-ICN
(2) ICN-as-an-Overlay; (3) ICN-as-an-Underlay; (4) ICN-as-a-Slice; and configurations.
(5) Composite-ICN. Existing ICN trial systems primarily fall </t>
under the ICN-as-an-Overlay, ICN-as-an-Underlay and Composite-ICN confi <t>In terms of deployment migration paths, ICN-as-an-Underlay offers a
gurations. clear migration path for CDN, edge, or core networks to go to an
</t> ICN paradigm (e.g., for an IoT deployment) while leaving the
critical mass of existing end-user applications untouched.
<t>In terms of deployment migration paths, ICN-as-an-Underlay offers a ICN-as-an-Overlay is
clear migration path for CDN, edge or core networks to go to an the easiest configuration to deploy rapidly, as it leaves the
ICN paradigm (e.g., for an IoT deployment) while leaving the critical m underlying IP infrastructure essentially untouched. However, its
ass of existing end user applications untouched. ICN-as-an-Overlay is applicability for general deployment must be considered on a
the easiest configuration to deploy rapidly as it leaves the underlying case-by-case basis. (That is, can it support all required user
IP infrastructure essentially untouched. However, its applications?).
applicability for general deployment must be considered on a case by ca ICN-as-a-Slice is an attractive deployment option for upcoming 5G
se basis (e.g., can it support all required user applications). systems (i.e., for 5G radio and core networks) that will naturally
ICN-as-a-Slice is an attractive deployment option for up coming 5G syst support network slicing, but this still has to be validated through
ems (i.e., for 5G radio and core networks) which will naturally more trial experiences. Composite-ICN, by its nature, can combine
support network slicing, but this still has to be validated through mor some of the best characteristics of the other configurations, but
e trial experiences. Composite-ICN, by its nature, can combine its applicability for general deployment must again be considered
some of the best characteristics of the other configurations, but its a on a case-by-case basis (i.e., can enough IP routers be upgraded to
pplicability for general deployment must again be considered support Composite-ICN functionality to provide sufficient
on a case by case basis (e.g., can enough IP routers be upgraded to sup performance benefits?).
port Composite-ICN functionality to provide sufficient </t>
performance benefits). <t>There has been significant trial experience with all the major ICN
</t> protocol flavors (e.g., CCNx, NDN, and POINT). However, only a limited
number of applications have been tested so far, and the maximum
<t>There has been significant trial experience with all the major ICN p number of users in any given trial has been less than 1k users. It
rotocol flavors (e.g., CCN, NDN, POINT). However, only a limited is
number of applications have been tested so far, and the maximum number recommended that future ICN deployments scale their users gradually
of users in any given trial has been less than 1k users. It is and closely monitor network performance as they go above 1k users.
recommended that future ICN deployments scale their users gradually and A logical approach would be to increase the number of users in a
closely monitor network performance as they go above 1k users. slowly increasing linear manner and monitor network performance and
A logical approach would be to increase the number of users in a slowly stability, especially at every multiple of 1k users.
increasing linear manner and monitor network performance and </t>
stability especially at every multiple of 1k users. <t>Finally, this document describes a set of technical features in ICN
</t> that warrant potential future IETF specification work. This will
aid initial and incremental deployments to proceed in an
<t>Finally, this document describes a set of technical features in ICN tha interoperable manner. The fundamental details of the potential
t warrant potential future IETF specification work. This will protocol specification
aid initial and incremental deployments to proceed in an interoperable effort, however, are best left for future study by the appropriate
manner. The fundamental details of the potential protocol specification IETF WGs and/or BoFs. The ICNRG can aid this process in the
effort, however, are best left for future study by the appropriate IETF near and mid-term by continuing to examine key system issues like
WGs and/or BoFs. The ICNRG can aid this process in the QoS mechanisms, flexible naming schemes, and OAM support for ICN.
near and mid-term by continuing to examine key system issues like QoS m
echanisms, flexible naming schemes and OAM support for ICN.
</t> </t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document has no IANA actions.
<t>This document requests no IANA actions.
</t> </t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>ICN was purposefully designed from the start to have certain
<t>ICN was purposefully designed from the start to have certain intrinsic intrinsic security properties. The most well known of which are
security properties. The most well known of which are authentication authentication
of delivered content and (optional) encryption of the content. <xref ta of delivered content and (optional) encryption of the content. <xref
rget="RFC7945" /> has an extensive discussion of various aspects of ICN security target="RFC7945" format="default"/> has an extensive discussion of
including many which are relevant to deployments. Specifically, <xref various aspects of ICN security,
target="RFC7945" /> points out that ICN access control, privacy, security including many that are relevant to deployments. Specifically,
of in-network caches, and protection against various network attacks (e <xref target="RFC7945" format="default"/> points out that ICN access
.g., DoS) have not yet been fully developed due to the lack of a sufficient control, privacy, security
mass of deployments. <xref target="RFC7945" /> also points out relevan of in-network caches, and protection against various network attacks
t advances occurring in the ICN research community that hold promise to address (e.g., DoS) have not yet been fully developed due to the lack of a
each of the identified security gaps. Lastly, <xref target="RFC7945" / sufficient
> points out that as secure communications in the existing Internet (e.g., HTTPS mass of deployments. <xref target="RFC7945" format="default"/> also
) points out relevant advances occurring in the ICN research community
becomes the norm, that major gaps in ICN security will inevitably slow that hold promise to address
down the adoption of ICN. each of the identified security gaps. Lastly, <xref
</t> target="RFC7945" format="default"/> points out that as secure
communications in the existing Internet (e.g., HTTPS)
<t>In addition to the security findings of <xref target="RFC7945" />, t become the norm, major gaps in ICN security will inevitably
his document has highlighted that all anticipated ICN deployment configurations slow down the adoption of ICN.
will involve co-existence with existing Internet infrastructure and app </t>
lications. Thus even the basic authentication and encryption properties of ICN <t>In addition to the security findings of <xref target="RFC7945"
content will need to account for interworking with non-ICN content to p format="default"/>, this document has highlighted that all anticipated
reserve end-to-end security. For example, in the edge network underlay deployme ICN deployment configurations
nt will involve coexistence with existing Internet infrastructure and
configuration described in <xref target="sec:application_gateways" />, applications. Thus, even the basic authentication and encryption
the gateway/proxy that translates HTTP or CoAP request/responses into ICN messag properties of ICN
e content will need to account for interworking with non-ICN content
exchanges will need to support a security model to preserve end-to-end to preserve end-to-end security. For example, in the edge network
security. One alternative would be to consider an approach similiar to underlay deployment
<xref target="RFC8613" /> which is used to pass end-to-end encrypted co configuration described in <xref target="sec_application_gateways"
ntent between HTTP and COAP by an application layer security mechanism. Further format="default"/>, the gateway/proxy that translates HTTP or CoAP
investigation is required to see if this approach is suitable to preser request/responses into ICN message
ve ICN message security through future protocol translation functions exchanges will need to support a security model to preserve
(e.g., ICN to HTTP, or COAP to ICN) of gateways/proxies. end-to-end security. One alternative would be to consider an
</t> approach similar to
<xref target="RFC8613" format="default"/>, which is used to pass
<t>Finally, the Doctor project discussed in <xref target="sec:Doctor" / end-to-end encrypted content between HTTP and CoAP by an
> is an example of an early deployment that is looking at specific attacks again application-layer security mechanism. Further
st investigation is required to see if this approach is suitable to
ICN infrastructure. In this case, looking at Interest Flooding Attacks preserve ICN message security through future protocol translation
<xref target="Nguyen-2" /> and Content Poisoning Attacks <xref target="Nguyen-1 functions (e.g., ICN to HTTP or CoAP to ICN) of gateways/proxies.
" /> </t>
<xref target="Mai-2" /> <xref target="Nguyen-3" /> and evaluation of po <t>Finally, the DOCTOR project discussed in <xref target="sec_Doctor"
tential counter-measures based on MANO orchestrated actions on the format="default"/> is an example of an early deployment that is looking
virtualized infrastructure <xref target="Mai-1" /> . at specific attacks against
</t> ICN infrastructure, in this case, looking at Interest Flooding
Attacks <xref target="Nguyen-2" format="default"/> and Content
Poisoning Attacks <xref target="Nguyen-1" format="default"/>
<xref target="Mai-2" format="default"/> <xref target="Nguyen-3"
format="default"/> and evaluating potential countermeasures based
on MANO-orchestrated actions on the virtualized infrastructure <xref
target="Mai-1" format="default"/>.
</t>
</section> </section>
</middle>
<back>
<section anchor="Acknowledgments" title="Acknowledgments"> <displayreference target="I-D.ietf-bier-multicast-http-response"
to="BIER"/>
<displayreference target="I-D.irtf-icnrg-icniot" to="ICN-IoT"/>
<displayreference target="I-D.irtf-icnrg-terminology" to="ICN-TERM"/>
<displayreference target="I-D.irtf-icnrg-icn-lte-4g" to="ICN-LTE-4G"/>
<displayreference target="I-D.irtf-icnrg-ccninfo" to="CNNinfo"/>
<displayreference target="I-D.paik-icn-deployment-considerations"
to="ICN-DEP-CON"/>
<displayreference target="I-D.kutscher-icnrg-netinf-proto" to="NetInf"/>
<displayreference target="I-D.ravi-icnrg-5gc-icn" to="ICN-5GC"/>
<displayreference target="I-D.moiseenko-icnrg-flowclass"
to="FLOW-CLASS"/>
<displayreference target="I-D.anilj-icnrg-icn-qos" to="ICN-QoS"/>
<displayreference target="I-D.mendes-icnrg-dabber" to="DABBER"/>
<t>The authors want to thank Alex Afanasyev, Hitoshi Asaeda, Giovanna Caro <references>
figlio, Xavier de Foy, Guillaume Doyen, Hannu Flinck, Anil Jangam, Michael Kowal <name>Informative References</name>
,
Adisorn Lertsinsrubtavee, Paulo Mendes, Luca Muscariello, Thomas Schmid
t, Jan Seedorf, Eve Schooler, Samar Shailendra, Milan Stolic, Prakash Suthar,
Atsushi Mayutan, and Lixia Zhang for their very useful reviews and comm
ents to the document.
</t>
<t>Special thanks to Dave Oran (ICNRG co-chair) and Marie-Jose Montpeti <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
t for their extensive and thoughtful reviews of the document. Their reviews hel ce.RFC.7927.xml"/>
ped <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
to immeasurably improve the document quality.</t> ce.RFC.7252.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7665.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6920.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8075.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7945.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7426.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8613.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8609.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8569.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8568.xml"/>
<!-- draft-ietf-bier-multicast-http-response-03: I-D Exists -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-
D.ietf-bier-multicast-http-response.xml"/>
<!-- draft-irtf-icnrg-icniot-03: Expired -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-
D.irtf-icnrg-icniot.xml"/>
<!-- draft-irtf-icnrg-terminology-08: I-D Exists -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-
D.irtf-icnrg-terminology.xml"/>
<!-- draft-irtf-icnrg-icn-lte-4g-05: I-D Exits -->
<reference anchor='I-D.irtf-icnrg-icn-lte-4g'>
<front>
<title>Native Deployment of ICN in LTE, 4G Mobile Networks</title>
<author initials='P' surname='Suthar' fullname='Prakash Suthar'>
<organization />
</author>
<author initials='M' surname='Stolic' fullname='Milan Stolic'>
<organization />
</author>
<author initials='A' surname='Jangam' fullname='Anil Jangam' role="editor">
<organization />
</author>
<author initials='D' surname='Trossen' fullname='Dirk Trossen'>
<organization />
</author>
<author initials='R' surname='Ravindran' fullname='Ravi Ravindran'>
<organization />
</author>
<date month='November' day='4' year='2019' />
</front>
<seriesInfo name='Internet-Draft' value='draft-irtf-icnrg-icn-lte-4g-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-irtf-icnrg-icn-lte-4g-
05.txt' />
</reference>
</section> <!-- draft-irtf-icnrg-ccninfo-02: Expired -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D
.irtf-icnrg-ccninfo.xml"/>
<!-- draft-paik-icn-deployment-considerations-00: Expired -->
<reference anchor='I-D.paik-icn-deployment-considerations'>
<front>
<title>Deployment Considerations for Information-Centric Networking</title>
<author initials='E' surname='Paik' fullname='EunKyoung Paik'>
<organization />
</author>
<author initials='W' surname='Yun' fullname='Won-Dong Yun'>
<organization />
</author>
<author initials='T' surname='Kwon' fullname='Taekyoung Kwon'>
<organization />
</author>
<author initials='H' surname='Choi' fullname='Hoon-gyu Choi'>
<organization />
</author>
<date month='July' day='15' year='2013' />
</front>
<seriesInfo name='Internet-Draft' value='draft-paik-icn-deployment-consideration
s-00' />
</middle> </reference>
<back> <!-- draft-kutscher-icnrg-netinf-proto-01: Expired -->
<!-- Example <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-
<references title="Normative References"> D.kutscher-icnrg-netinf-proto.xml"/>
&I-D.ietf-core-http-mapping; <!-- draft-ravi-icnrg-5gc-icn-04: Expired -->
</references> <reference anchor='I-D.ravi-icnrg-5gc-icn'>
<front>
<title>Enabling ICN in 3GPP's 5G NextGen Core Architecture</title>
<author initials='R' surname='Ravindran' fullname='Ravi Ravindran'>
<organization />
</author>
<author initials='P' surname='Suthar' fullname='Prakash Suthar'>
<organization />
</author>
<author initials='D' surname='Trossen' fullname='Dirk Trossen'>
<organization />
</author>
<author initials='C' surname='Wang' fullname='Chonggang Wang'>
<organization />
</author>
<author initials='G' surname='White' fullname='Greg White'>
<organization />
</author>
<date month='May' day='31' year='2019' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ravi-icnrg-5gc-icn-04' />
--> </reference>
<references title="Informative References">
<!---->
&rfc7927;
&rfc7252;
&rfc7665;
&rfc6920;
&rfc8075;
&rfc7945;
&rfc7426;
&rfc8613;
&I-D.ietf-bier-multicast-http-response; <!-- draft-moiseenko-icnrg-flowclass-05: I-D Exists -->
&I-D.irtf-nfvrg-gaps-network-virtualization; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-
&I-D.irtf-icnrg-icniot; D.moiseenko-icnrg-flowclass.xml"/>
&I-D.irtf-icnrg-ccnxmessages; <!-- draft-anilj-icnrg-icn-qos-00: Expired -->
&I-D.irtf-icnrg-terminology; <reference anchor='I-D.anilj-icnrg-icn-qos'>
&I-D.irtf-icnrg-icn-lte-4g; <front>
&I-D.irtf-icnrg-ccninfo; <title>Supporting QoS aware Data Delivery in Information Centric Networks</title
&I-D.irtf-icnrg-ccnxsemantics; >
<author initials='A' surname='Jangam' fullname='Anil Jangam'>
<organization />
</author>
<author initials='P' surname='Suthar' fullname='Prakash Suthar'>
<organization />
</author>
<author initials='M' surname='Stolic' fullname='Milan Stolic'>
<organization />
</author>
<date month='July' day='14' year='2018' />
</front>
<seriesInfo name='Internet-Draft' value='draft-anilj-icnrg-icn-qos-00' />
&I-D.paik-icn-deployment-considerations; </reference>
&I-D.kutscher-icnrg-netinf-proto;
&I-D.ravi-icnrg-5gc-icn;
&I-D.moiseenko-icnrg-flowclass;
&I-D.anilj-icnrg-icn-qos;
&I-D.mendes-icnrg-dabber;
<reference anchor="Tateson" target="http://www.psirp.org/files/Delivera <!-- draft-mendes-icnrg-dabber-03: I-D Exists -->
bles/FP7-INFSO-ICT-216173-PSIRP-D4.6_FinalReportOnDeplIncBusinessModels.pdf"> <xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.mendes-ic
nrg-dabber.xml"/>
<reference anchor="Tateson" target="http://www.psirp.org/files/Deliverable
s/FP7-INFSO-ICT-216173-PSIRP-D4.6_FinalReportOnDeplIncBusinessModels.pdf">
<front> <front>
<title>Final Evaluation Report on Deployment Incentives and Business M odels</title> <title>Final Evaluation Report on Deployment Incentives and Business M odels</title>
<author initials="J." surname="Tateson" /> <author>
<author initials="" surname="et al." /> <organization>Tateson, J., et al.</organization>
<date year="2010"/> </author>
<date month="May" year="2010"/>
</front> </front>
<seriesInfo name="Version" value="1.0"/>
<refcontent>PSIRP</refcontent>
</reference> </reference>
<reference anchor="Jacobson"> <reference anchor="Jacobson">
<front> <front>
<title>Networking Named Content</title> <title>Networking Named Content</title>
<author initials="V." surname="Jacobson" /> <author>
<author initials="" surname="et al." /> <organization>Jacobson, V., et al.</organization>
<date year="2009"/> </author>
<date month="December" year="2009"/>
</front> </front>
<seriesInfo name="Proceedings of ACM Context," value=""/> <seriesInfo name="DOI" value="10.1145/1658939.1658941"/>
<refcontent>CoNEXT '09: Proceedings of the 5th international
conference on Emerging networking experiments and technologies</refconten
t>
</reference> </reference>
<reference anchor="fiveG-23501"> <reference anchor="fiveG-23501">
<front> <front>
<title>Technical Specification Group Services and System Aspects; Syst <title>System Architecture for the 5G System</title>
em Architecture for the 5G System (Rel.15)</title> <author>
<author initials="" surname="3gpp-23.501" /> <organization>3GPP</organization>
<date year="2017"/> </author>
<date month="December" year="2017"/>
</front> </front>
<seriesInfo name="3GPP" value=""/> <seriesInfo name="3GPP" value="TS 23.501"/>
<refcontent>Release 15</refcontent>
</reference> </reference>
<reference anchor="IEEE_Communications"> <reference anchor="IEEE_Communications">
<front> <front>
<title>Designing and Realizing an Information-Centric Internet</title> <title>Designing and realizing an information-centric internet</title>
<author initials="D." surname="Trossen" /> <author initials="D." surname="Trossen" fullname="Dirk Trossen">
<author initials="G." surname="Parisis" /> <organization/>
<date year="2012"/> </author>
<author initials="G." surname="Parisis" fullname="George Parisis">
<organization/>
</author>
<date/>
</front> </front>
<seriesInfo name="Information-Centric Networking," value="IEEE Communica <seriesInfo name="DOI" value="10.1109/MCOM.2012.6231280"/>
tions Magazine Special Issue"/> <refcontent>IEEE Communications Magazine, Volume 50, Issue 7</refcontent>
</reference> </reference>
<reference anchor="VSER"> <reference anchor="VSER">
<front> <front>
<title>Towards software defined ICN based edge-cloud services</title> <title>Towards software defined ICN based edge-cloud services</title>
<author initials="R." surname="Ravindran" /> <author>
<author initials="" surname="et al." /> <organization>Ravindran, R., et al.</organization>
<date year="IEEE Internation Conference on CloudNetworking(CloudNet), </author>
2013"/> <date/>
</front> </front>
<seriesInfo name="CloudNetworking(CloudNet)," value="IEEE Internation Co <seriesInfo name="DOI" value="10.1109/CloudNet.2013.6710583"/>
nference on"/> <refcontent>2013 IEEE 2nd International Conference on Cloud Networking (C
loudNet)</refcontent>
</reference> </reference>
<reference anchor="VSER-Mob"> <reference anchor="VSER-Mob">
<front> <front>
<title>Seamless Mobility as a Service in Information-centric Networks< <title>Seamless Producer Mobility as a Service in Information-centric
/title> Networks</title>
<author initials="A." surname="Azgin" /> <author>
<author initials="" surname="et al." /> <organization>Azgin, A., et al.</organization>
<date year="ACM ICN Sigcomm, IC5G Workshop, 2016"/> </author>
<date month="September" year="2016"/>
</front> </front>
<seriesInfo name="DOI" value="10.1145/2984356.2988521"/>
<refcontent>ACM-ICN '16: Proceedings of the 3rd ACM Conference on
Information-Centric Networking</refcontent>
</reference> </reference>
<reference anchor="POINT"> <reference anchor="POINT">
<front> <front>
<title>POINT: IP Over ICN - The Better IP?</title> <title>IP over ICN - The better IP?</title>
<author initials="D." surname="Trossen" /> <author>
<author initials="" surname="et al." /> <organization>Trossen, D., et al.</organization>
<date year="2015"/> </author>
<date month="June" year="2015"/>
</front> </front>
<seriesInfo name="European Conference on Networks and Communications (Eu <seriesInfo name="DOI" value="10.1109/EuCNC.2015.7194109"/>
CNC)," value=""/> <refcontent>2015 European Conference on Networks and Communications (EuCN
C)</refcontent>
</reference> </reference>
<reference anchor="MWC_Demo" target="http://www.interdigital.com/downloa d/56d5c71bd616f892ba001861"> <reference anchor="MWC_Demo" target="http://www.interdigital.com/download/ 56d5c71bd616f892ba001861">
<front> <front>
<title>InterDigital Demo at Mobile World Congress (MWC)</title> <title>InterDigital Demo at Mobile World Congress (MWC)</title>
<author initials="" surname="InterDigital" /> <author><organization>InterDigital</organization>
</author>
<date year="2016"/> <date year="2016"/>
</front> </front>
</reference> </reference>
<reference anchor="Reed"> <reference anchor="Reed">
<front> <front>
<title>Stateless Multicast Switching in Software Defined Networks</tit <title>Stateless multicast switching in software defined networks</tit
le> le>
<author initials="M.J." surname="Reed" /> <author>
<author initials="" surname="et al." /> <organization>Reed, M., et al.</organization>
<date year="2016"/> </author>
<date month="May" year="2016"/>
</front> </front>
<seriesInfo name="ICC 2016," value="Kuala Lumpur, Malaysia"/> <seriesInfo name="DOI" value="10.1109/ICC.2016.7511036"/>
<refcontent>2016 IEEE International Conference on Communications (ICC)<
/refcontent>
</reference> </reference>
<reference anchor="White" target="http://www.cablelabs.com/wp-content/up loads/2016/02/Content-Delivery-with-Content-Centric-Networking-Feb-2016.pdf"> <reference anchor="White" target="http://www.cablelabs.com/wp-content/uplo ads/2016/02/Content-Delivery-with-Content-Centric-Networking-Feb-2016.pdf">
<front> <front>
<title>Content Delivery with Content Centric Networking, CableLabs Whi <title>Content Delivery with Content-Centric Networking</title>
te Paper</title> <author initials="G." surname="White" fullname="Greg White">
<author initials="G." surname="White" /> <organization/>
<author initials="G." surname="Rutz" /> </author>
<date year="2016"/> <author initials="G." surname="Rutz" fullname="Greg Rutz">
<organization/>
</author>
<date month="February" year="2016"/>
</front> </front>
</reference> </reference>
<reference anchor="Techno_Economic"> <reference anchor="Techno_Economic">
<front> <front>
<title>Techno-Economics Aspects of Information-Centric Networking</tit le> <title>Techno-Economics Aspects of Information-Centric Networking</tit le>
<author initials="D." surname="Trossen" /> <author initials="D." surname="Trossen" fullname="Dirk Trossen">
<author initials="A." surname="Kostopolous" /> <organization/>
<date year="2012"/> </author>
<author initials="A." surname="Kostopoulos" fullname="Alexandros Kosto
poulos">
<organization/>
</author>
<date month="June" year="2012"/>
</front> </front>
<seriesInfo name="Journal for Information Policy," value="Volume 2"/> <seriesInfo name="Journal for Information Policy" value=""/>
<refcontent>Volume 2</refcontent>
<seriesInfo name="DOI" value="10.5325/jinfopoli.2.2012.0026"/>
</reference> </reference>
<reference anchor="Internet_Pricing"> <reference anchor="Internet_Pricing">
<front> <front>
<title>Not Paying the Truck Driver: Differentiated Pricing for the Fut <title>Not paying the truck driver: differentiated pricing for the fut
ure Internet</title> ure internet</title>
<author initials="D." surname="Trossen" /> <author initials="D." surname="Trossen" fullname="Dirk Trossen">
<author initials="G." surname="Biczok" /> <organization/>
<date year="2010"/> </author>
<author initials="G." surname="Biczok" fullname="Gergely Biczok">
<organization/>
</author>
<date month="November" year="2010"/>
</front> </front>
<seriesInfo name="ReArch Workshop in conjunction with ACM Context," valu <seriesInfo name="ReArch '10:" value="Proceedings of the
e="December"/> Re-Architecting the Internet Workshop"/>
<seriesInfo name="DOI" value="10.1145/1921233.1921235"/>
<refcontent>ReARCH '10: Proceedings of the Re-Architecting the
Internet Workshop</refcontent>
</reference> </reference>
<reference anchor="oneM2M" target="http://www.onem2m.org/"> <reference anchor="oneM2M" target="http://www.onem2m.org/">
<front> <front>
<title>oneM2M Service Layer Standards for M2M and IoT</title> <title>oneM2M Service Layer Standards for M2M and IoT</title>
<author initials="" surname="OneM2M" /> <author><organization>OneM2M</organization>
<date year="2017"/> </author>
<date year="2017"/>
</front> </front>
</reference> </reference>
<reference anchor="ONAP" target="https://www.onap.org/"> <reference anchor="ONAP" target="https://www.onap.org/">
<front> <front>
<title>Open Network Automation Platform</title> <title>Open Network Automation Platform</title>
<author initials="" surname="ONAP" /> <author><organization>ONAP</organization>
<date year="2017"/> </author>
</front> </front>
</reference> </reference>
<reference anchor="CONET" target="http://netgroup.uniroma2.it/Stefano_Sa lsano/papers/salsano-icc12-wshop-sdn.pdf"> <reference anchor="CONET" target="http://netgroup.uniroma2.it/Stefano_Sals ano/papers/salsano-icc12-wshop-sdn.pdf">
<front> <front>
<title>CONET Project: Supporting Information-Centric Functionality in <title>Supporting Information-Centric Functionality in Software Define
Software Defined Networks</title> d Networks</title>
<author initials="L." surname="Veltri" /> <author>
<author initials="" surname="et al." /> <organization>Veltri, L., et al.</organization>
<date year="2012"/> </author>
<date month="November" year="2012"/>
</front> </front>
<seriesInfo name="Workshop on Software Defined Networks," value=""/> <seriesInfo name="DOI" value="10.1109/ICC.2012.6364916"/>
<refcontent>2012 IEEE International Conference on Communications (ICC)</r
efcontent>
</reference> </reference>
<reference anchor="C_FLOW" target="http://opennetsummit.org/archives/apr 12/site/pdf/snu.pdf"> <reference anchor="C_FLOW" target="https://ieeexplore.ieee.org/document/67 99480">
<front> <front>
<title>C_FLOW: Content-Oriented Networking over OpenFlow</title> <title>C_flow: An efficient content delivery framework with OpenFlow</
<author initials="J." surname="Suh" /> title>
<author initials="" surname="et al." /> <author>
<date year="2012"/> <organization>D. Chang, et al.</organization>
</author>
<date month="February" year="2014"/>
</front> </front>
<seriesInfo name="Open Networking Summit," value="April"/> <refcontent>The International Conference on Information
Networking 2014 (ICOIN2014)</refcontent>
<refcontent>pp. 270-275</refcontent>
<seriesInfo name="DOI" value="10.1109/ICOIN.2014.6799480" />
</reference> </reference>
<reference anchor="H-ICN_1" target="http://blogs.cisco.com/sp/cisco-ann ounces-important-steps-toward-adoption-of-information-centric-networking"> <reference anchor="H-ICN_1" target="http://blogs.cisco.com/sp/cisco-announ ces-important-steps-toward-adoption-of-information-centric-networking">
<front> <front>
<title>Hybrid ICN: Cisco Announces Important Steps toward Adoption of <title>Cisco Announces Important Steps toward Adoption of Information-
Information-Centric Networking</title> Centric Networking</title>
<author initials="" surname="Cisco" /> <author>
<date year="2017"/> <organization>Cisco</organization>
</author>
<date month="February" year="2017"/>
</front> </front>
</reference> </reference>
<reference anchor="H-ICN_2" target="https://www.cisco.com/c/dam/en/us/so lutions/collateral/service-provider/ultra-services-platform/mwc17-hicn-video-wp. pdf"> <reference anchor="H-ICN_2" target="https://www.cisco.com/c/dam/en/us/solu tions/collateral/service-provider/ultra-services-platform/mwc17-hicn-video-wp.pd f">
<front> <front>
<title>Mobile Video Delivery with Hybrid ICN: IP-Integrated ICN Soluti <title>Mobile Video Delivery with Hybrid ICN: IP-integrated ICN Soluti
on for 5G</title> on for 5G</title>
<author initials="" surname="Cisco" /> <author>
<date year="2017"/> <organization>Cisco</organization>
</author>
</front> </front>
</reference> </reference>
<reference anchor="CCNx_UDP" target="https://www.ietf.org/proceedings/in terim-2015-icnrg-04/slides/slides-interim-2015-icnrg-4-5.pdf"> <reference anchor="CCNx_UDP" target="https://www.ietf.org/proceedings/inte rim-2015-icnrg-04/slides/slides-interim-2015-icnrg-4-5.pdf">
<front> <front>
<title>CCNx Over UDP</title> <title>CCNx Over UDP</title>
<author initials="" surname="PARC" /> <author>
<date year="2015"/> <organization>PARC</organization>
</author>
</front> </front>
</reference> </reference>
<reference anchor="SAIL_Prototyping" target="http://www.sail-project.eu/ wp-content/uploads/2013/05/SAIL_DB4_v1.1_Final_Public.pdf"> <reference anchor="SAIL_Prototyping" target="http://www.sail-project.eu/wp -content/uploads/2013/05/SAIL_DB4_v1.1_Final_Public.pdf">
<front> <front>
<title>SAIL Prototyping and Evaluation</title> <title>Prototyping and Evaluation</title>
<author initials="" surname="FP7" /> <author>
<date year="2013"/> <organization>FP7</organization>
</author>
<date month="March" year="2013"/>
</front> </front>
<seriesInfo name="Objective" value="FP7-ICT-2009-5-257448/D.B.4"/>
</reference> </reference>
<reference anchor="DASH" target="http://dashif.org/"> <reference anchor="DASH" target="http://dashif.org/">
<front> <front>
<title>DASH Industry Forum</title> <title>DASH Industry Forum</title>
<author initials="" surname="DASH" /> <author>
<date year="2017"/> <organization>DASH</organization>
</author>
</front> </front>
</reference> </reference>
<reference anchor="NGMN-5G" target="https://www.ngmn.org/fileadmin/ngmn/cont ent/images/news/ngmn_news/NGMN_5G_White_Paper_V1_0.pdf"> <reference anchor="NGMN-5G" target="https://www.ngmn.org/wp-content/upload s/NGMN_5G_White_Paper_V1_0.pdf">
<front> <front>
<title>NGMN 5G White Paper</title> <title>5G White Paper</title>
<author initials="" surname="NGMN" /> <author>
<date year="2015"/> <organization>NGMN Alliance</organization>
</author>
<date month="February" year="2015"/>
</front> </front>
</reference> </reference>
<reference anchor="Ravindran" target="https://arxiv.org/abs/1610.01182" > <reference anchor="Ravindran" target="https://arxiv.org/abs/1610.01182">
<front> <front>
<title>5G-ICN : Delivering ICN Services over 5G using Network Slicing< /title> <title>5G-ICN : Delivering ICN Services over 5G using Network Slicing< /title>
<author initials="R." surname="Ravindran" /> <author>
<author initials="" surname="et al." /> <organization>Ravindran, R., et al.</organization>
<date year="IEEE Communication Magazine, May, 2016"/> </author>
<date month="October" year="2016"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/MCOM.2017.1600938"/>
<refcontent>IEEE Communications Magazine, Volume 55, Issue 5</refcontent>
</reference> </reference>
<reference anchor="Moiseenko" target="http://conferences2.sigcomm.org/a cm-icn/2016/proceedings/p112-moiseenko.pdf"> <reference anchor="Moiseenko" target="http://conferences2.sigcomm.org/acm- icn/2016/proceedings/p112-moiseenko.pdf">
<front> <front>
<title>TCP/ICN : Carrying TCP over Content Centric and Named Data Netw <title>TCP/ICN: Carrying TCP over Content Centric and Named Data Netwo
orks</title> rks</title>
<author initials="I." surname="Moiseenko" /> <author initials="I." surname="Moiseenko" fullname="Ilya Moiseenko">
<author initials="D." surname="Oran" /> <organization/>
<date year="2016"/> </author>
<author initials="D." surname="Oran" fullname="Dave Oran">
<organization/>
</author>
<date month="September" year="2016"/>
</front> </front>
<seriesInfo name="DOI" value="10.1145/2984356.2984357"/>
<refcontent>ACM-ICN '16: Proceedings of the 3rd ACM Conference on
Information-Centric Networking</refcontent>
</reference> </reference>
<reference anchor="NFD" target="https://named-data.net/doc/NFD/current /"> <reference anchor="NFD" target="https://named-data.net/doc/NFD/current/">
<front> <front>
<title>NFD - Named Data Networking Forwarding Daemon</title> <title>NFD - Named Data Networking Forwarding Daemon</title>
<author initials="" surname="NDN" /> <author>
<date year="2017"/> <organization>NDN</organization>
</author>
</front> </front>
</reference> </reference>
<reference anchor="ICNRGCharter" target="https://datatracker.ietf.org/d oc/charter-irtf-icnrg/"> <reference anchor="ICNRGCharter" target="https://datatracker.ietf.org/doc/ charter-irtf-icnrg/">
<front> <front>
<title>Information-Centric Networking Research Group Charter</title> <title>Information-Centric Networking Research Group Charter</title>
<author initials="" surname="NDN" /> <author>
<date year="2013"/> <organization>IRTF</organization>
</author>
</front> </front>
</reference> </reference>
<reference anchor="Baccelli" target="http://conferences2.sigcomm.org/acm -icn/2014/papers/p77.pdf"> <reference anchor="Baccelli" target="http://conferences2.sigcomm.org/acm-i cn/2014/papers/p77.pdf">
<front> <front>
<title>Information Centric Networking in the IoT: Experiments with NDN in the Wild</title> <title>Information Centric Networking in the IoT: Experiments with NDN in the Wild</title>
<author initials="E." surname="Baccelli" /> <author>
<author initials="" surname="et al." /> <organization>Baccelli, E., et al.</organization>
<date year="2014"/> </author>
</front> <date month="September" year="2014"/>
<seriesInfo name="ACM 20164," value="Paris, France"/>
</reference>
<reference anchor="Anastasiades" target="http://boris.unibe.ch/83683/1/
16anastasiades_c.pdf">
<front>
<title>Information-centric communication in mobile and wireless networ
ks</title>
<author initials="C" surname="Anastasiades" />
<date year="PhD Dissertation, 2016"/>
</front> </front>
<seriesInfo name="DOI" value="10.1145/2660129.2660144"/>
<refcontent>ACM-ICN '14: Proceedings of the 1st ACM Conference on
Information-Centric Networking</refcontent>
</reference> </reference>
<reference anchor="Jangam" target="https://dl.acm.org/citation.cfm?id=3 132351"> <reference anchor="Anastasiades" target="http://boris.unibe.ch/83683/1/16a nastasiades_c.pdf">
<front> <front>
<title>Porting and Simulation of Named-data Link State Routing Protoco <title>Information-centric communication in mobile and wireless networ
l into ndnSIM</title> ks</title>
<author initials="A." surname="Jangam" /> <author initials="C" surname="Anastasiades" fullname="Carlos
<author initials="" surname="et al." /> Anastasiades">
<date year="2017"/> <organization/>
</author>
<date month="June" year="2016"/>
</front> </front>
<seriesInfo name="ACM DIVANet'17," value="Miami Beach, USA"/> <seriesInfo name="DOI" value=" 10.7892/boris.83683"/>
<refcontent>PhD Dissertation</refcontent>
</reference> </reference>
<reference anchor="ICN2020" target="http://www.icn2020.org/dissemination /deliverables-public/"> <reference anchor="Jangam" target="https://dl.acm.org/citation.cfm?id=3132 351">
<front> <front>
<title>ICN2020 Deliverables</title> <title>nlsrSIM: Porting and Simulation of Named-data Link State
<author initials="" surname="ICN2020" /> Routing Protocol into ndnSIM</title>
<date year="2017"/> <author>
<organization>Jangam, A., et al.</organization>
</author>
<date month="November" year="2017"/>
</front> </front>
<seriesInfo name="DOI" value="10.1145/3132340.3132351"/>
<refcontent>DIVANet '17: Proceedings of the 6th ACM Symposium on
Development and Analysis of Intelligent Vehicular Networks and Applicat
ions</refcontent>
</reference> </reference>
<reference anchor="CUTEi"> <reference anchor="CUTEi">
<front> <front>
<title>Container-Based Unified Testbed for Information Centric Network ing</title> <title>Container-Based Unified Testbed for Information Centric Network ing</title>
<author initials="H." surname="Asaeda" /> <author initials="H." surname="Asaeda" fullname="Hitoshi Asaeda">
<author initials="N." surname="Choi" /> <organization/>
<date year="2014"/> </author>
<author initials="R." surname="Li" fullname="Ruidong Li">
<organization/>
</author>
<author initials="N." surname="Choi" fullname="Nakjung Choi">
<organization/>
</author>
<date month="November" year="2014"/>
</front> </front>
<seriesInfo name="IEEE Network, Vol.28, No.6" value=""/> <seriesInfo name="DOI" value="10.1109/MNET.2014.6963806"/>
<refcontent>IEEE Network Volume 28, Issue:6</refcontent>
</reference> </reference>
<reference anchor="Overlay_ICN" target="https://www.researchgate.net/pu blication/282779666_A_novel_overlay_architecture_for_Information_Centric_Network ing"> <reference anchor="Overlay_ICN" target="https://www.researchgate.net/publi cation/282779666_A_novel_overlay_architecture_for_Information_Centric_Networking ">
<front> <front>
<title>A Novel Overlay Architecture for F Networking</title> <title>A novel overlay architecture for Information Centric Networking
<author initials="S." surname="Shailendra" /> </title>
<author initials="" surname="et al." /> <author>
<date year="2016"/> <organization>Shailendra, S.,et al.</organization>
</author>
<date month="April" year="2016"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/NCC.2015.7084921"/>
<refcontent>2015 21st National Conference on Communications, NCC 2015</re
fcontent>
</reference> </reference>
<reference anchor="Contrace"> <reference anchor="Contrace">
<front> <front>
<title>Contrace: A Tool for Measuring and Tracing Content-Centric Netw <title>Contrace: a tool for measuring and tracing content-centric netw
orks</title> orks</title>
<author initials="H." surname="Asaeda" /> <author>
<author initials="" surname="et al." /> <organization>Asaeda, H., et al.</organization>
<date year="2015"/> </author>
<date month="March" year="2015"/>
</front> </front>
<seriesInfo name="IEEE Communications Magazine, Vol.53, No.3" v <seriesInfo name="DOI" value="10.1109/MCOM.2015.7060502"/>
alue=""/> <refcontent> IEEE Communications Magazine, Volume 53, Issue 3</refcontent
>
</reference> </reference>
<reference anchor="fiveG-23502"> <reference anchor="fiveG-23502">
<front> <front>
<title>Technical Specification Group Services and System Aspects; Proc <title>Procedures for the 5G System (5GS)</title>
edures for the 5G System (Rel.15)</title> <author>
<author initials="" surname="3gpp-23.502" /> <organization>3GPP</organization>
<date year="2017"/> </author>
</front> </front>
<seriesInfo name="3GPP" value=""/> <seriesInfo name="3GPP" value="TS 23.502"/>
<refcontent>Release 15</refcontent>
</reference> </reference>
<reference anchor="CICN" target="https://wiki.fd.io/view/Cicn"> <reference anchor="CICN" target="https://wiki.fd.io/view/Cicn">
<front> <front>
<title>Community Information-Centric Networking (CICN)</title> <title>Cicn</title>
<author initials="" surname="CICN" /> <author>
<date year="2017"/> <organization>fd.io</organization>
</author>
</front> </front>
</reference> </reference>
<reference anchor="Mai-1" target="http://www.mallouli.com/recherche/publ ications/noms2018-1.pdf"> <reference anchor="Mai-1" target="https://ieeexplore.ieee.org/document/840 1591">
<front> <front>
<title>Implementation of Content Poisoning Attack Detection and Reacti <title>Implementation of content poisoning attack detection and
on in Virtualized NDN Networks</title> reaction in virtualized NDN networks</title>
<author initials="H.L." surname="Mai" /> <author>
<author initials="" surname="et al." /> <organization>Mai, H., et al.</organization>
<date year="21st Conference on Innovation in Clouds, Internet a </author>
nd Networks, ICIN 2018 (demo paper) IEEE, 2018"/> <date month="July" year="2018"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/ICIN.2018.8401591"/>
<refcontent>2018 21st Conference on Innovation in Clouds, Internet and
Networks and Workshops (ICIN)</refcontent>
</reference> </reference>
<reference anchor="Mai-2"> <reference anchor="Mai-2">
<front> <front>
<title>Towards a Security Monitoring Plane for Named Data Networking: <title>Towards a Security Monitoring Plane for Named Data
Application to Content Poisoning Attack</title> Networking: Application to Content Poisoning Attack</title>
<author initials="H.L." surname="Mai" /> <author>
<author initials="" surname="et al." /> <organization>Mai, H., et al.</organization>
<date year="Proceedings of the 2018 IEEE/IFIP Symposium on Netw </author>
ork Operations and Management (NOMS) IEEE, 2018"/> <date month="July" year="2018"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/NOMS.2018.8406246"/>
<refcontent>NOMS 2018 - 2018 IEEE/IFIP Network Operations Management
Symposium</refcontent>
</reference> </reference>
<reference anchor="Marchal" target="http://www.mallouli.com/recherche/pu blications/noms2018-1.pdf"> <reference anchor="Marchal" target="http://www.mallouli.com/recherche/publ ications/noms2018-1.pdf">
<front> <front>
<title>Leveraging NFV for the Deployment of NDN: Application to HTTP T raffic Transport</title> <title>Leveraging NFV for the Deployment of NDN: Application to HTTP T raffic Transport</title>
<author initials="X." surname="Marchal" /> <author>
<author initials="" surname="et al." /> <organization>Marchal, X., et al.</organization>
<date year="Proceedings of the 2018 IEEE/IFIP Symposium on Netw </author>
ork Operations and Management (NOMS), 2018"/> <date month="July" year="2018"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/NOMS.2018.8406206"/>
<refcontent>NOMS 2018 - 2018 IEEE/IFIP Network Operations and
Management Symposium</refcontent>
</reference> </reference>
<reference anchor="Nguyen-1"> <reference anchor="Nguyen-1">
<front> <front>
<title>Content Poisoning in Named Data Networking: Comprehensive Chara <title>Content Poisoning in Named Data Networking: Comprehensive
cterization of real Deployment</title> characterization of real deployment</title>
<author initials="T.N." surname="Nguyen" /> <author>
<author initials="" surname="et al." /> <organization>Nguyen, T., et al.</organization>
<date year="Proceedings of the 15th IEEE/IFIP International Sym </author>
posium on Integrated Network Management, 2017"/> <date month="July" year="2017"/>
</front> </front>
<seriesInfo name="DOI" value="10.23919/INM.2017.7987266"/>
<refcontent>2017 IFIP/IEEE Symposium on Integrated Network and Service
Management (IM)</refcontent>
</reference> </reference>
<reference anchor="Nguyen-2"> <reference anchor="Nguyen-2">
<front> <front>
<title>An Optimal Statistical Test for Robust Detection against Intere <title>An optimal statistical test for robust detection against
st Flooding Attacks in CCN</title> interest flooding attacks in CCN</title>
<author initials="T.N." surname="Nguyen" /> <author initials="T." surname="Nguyen" fullname="Tan Nguyen">
<author initials="R." surname="Cogranne" /> <organization/>
<author initials="G." surname="Doyen" /> </author>
<date year="Proceedings of the 14th IEEE/IFIP International Sym <author initials="R." surname="Cogranne" fullname="Remi Cogranne">
posium on Integrated Network Management, 2015"/> <organization/>
</author>
<author initials="G." surname="Doyen" fullname="Guillaume Doyen">
<organization/>
</author>
<date month="July" year="2015"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/INM.2015.7140299"/>
<refcontent>2015 IFIP/IEEE International Symposium on Integrated
Network Management (IM)</refcontent>
</reference> </reference>
<reference anchor="Nguyen-3"> <reference anchor="Nguyen-3">
<front> <front>
<title>A Security Monitoring Plane for Named Data Networking Deploymen t</title> <title>A Security Monitoring Plane for Named Data Networking Deploymen t</title>
<author initials="T.N." surname="Nguyen" /> <author>
<author initials="" surname="et al." /> <organization>Nguyen, T., et al.</organization>
<date year="IEEE Communications Magazine, Nov 2018"/> </author>
<date month="November" year="2018"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/MCOM.2018.1701135"/>
<refcontent>IEEE Communications Magazine, Volume: 56, Issue 11</refconten
t>
</reference> </reference>
<reference anchor="Doctor" target="http://www.doctor-project.org/index.h tm"> <reference anchor="Doctor" target="http://www.doctor-project.org/index.htm ">
<front> <front>
<title>Deployment and Securisation of new Functionalities in Virtualiz <title>Deployment and securisation of new functionalities in
ed Networking Environments (Doctor)</title> virtualized networking environments</title>
<author initials="" surname="Doctor" /> <author>
<date year="2017"/> <organization>DOCTOR</organization>
</author>
</front> </front>
</reference> </reference>
<reference anchor="H-ICN_3" target="https://datatracker.ietf.org/meeting /interim-2018-icnrg-01/materials/slides-interim-2018-icnrg-01-sessa-hybrid-icn-h icn-luca-muscariello"> <reference anchor="H-ICN_3" target="https://datatracker.ietf.org/meeting/i nterim-2018-icnrg-01/materials/slides-interim-2018-icnrg-01-sessa-hybrid-icn-hic n-luca-muscariello">
<front> <front>
<title>Hybrid Information-Centric Networking: ICN inside the Internet Protocol</title> <title>Hybrid Information-Centric Networking: ICN inside the Internet Protocol</title>
<author initials="L." surname="Muscariello" /> <author>
<author initials="" surname="et al." /> <organization>Muscariello, L., et al</organization>
<date year="2018"/> </author>
</front> <date month="March" year="2018"/>
</reference>
<reference anchor="H-ICN_4" target="https://datatracker.ietf.org/meeting
/interim-2018-icnrg-01/materials/slides-interim-2018-icnrg-01-sessa-hicn-socket-
library-for-http-luca-muscariello">
<front>
<title>(h)ICN Socket Library for HTTP: Leveraging (h)ICN socket librar
y for carrying HTTP messages</title>
<author initials="M." surname="Sardara" />
<author initials="" surname="et al." />
<date year="2018"/>
</front> </front>
<refcontent>ICNRG Interim Meeting</refcontent>
</reference> </reference>
<reference anchor="UMOBILE-2"> <reference anchor="UMOBILE-2">
<front> <front>
<title>Connecting the Edges: A Universal, Mobile-Centric, and Opportun <title>Connecting the Edges: A Universal, Mobile-Centric, and
istic Communications Architecture</title> Opportunistic Communications Architecture</title>
<author initials="C." surname="Sarros" /> <author>
<author initials="" surname="et al." /> <organization>Sarros, C., et al.</organization>
<date year="IEEE Communications Magazine, vol. 56, February 201 </author>
8"/> <date month="February" year="2018"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/MCOM.2018.1700325"/>
<refcontent>IEEE Communications Magazine, Volume 56, Issue 2</refcontent>
</reference> </reference>
<reference anchor="UMOBILE-3"> <reference anchor="UMOBILE-3">
<front> <front>
<title>Named-data Emergency Network Services</title> <title>Named-data Emergency Network Services</title>
<author initials="M." surname="Tavares" /> <author initials="M." surname="Tavares" fullname="Miguel Tavares">
<author initials="O." surname="Aponte" /> <organization/>
<author initials="P." surname="Mendes" /> </author>
<date year="Proc. of ACM MOBISYS, Munich, Germany, June 2018"/> <author initials="O." surname="Aponte" fullname="Omar Aponte">
<organization/>
</author>
<author initials="P." surname="Mendes" fullname="Paulo Mendes">
<organization/>
</author>
<date month="June" year="2018"/>
</front> </front>
<seriesInfo name="DOI" value="10.1145/3210240.3210809"/>
<refcontent>MobiSys '18: Proceedings of the 16th Annual International
Conference on Mobile Systems, Applications, and Services</refcontent>
</reference> </reference>
<reference anchor="UMOBILE-4"> <reference anchor="UMOBILE-4">
<front> <front>
<title>Oi! - Opportunistic Data Transmission Based on Wi-Fi Direct</ti tle> <title>Oi! - Opportunistic Data Transmission Based on Wi-Fi Direct</ti tle>
<author initials="L." surname="Lopes" /> <author>
<author initials="" surname="et al." /> <organization>Amaral, L., et al.</organization>
<date year="Proc. of IEEE INFOCOM, San Francisco, USA, April 20 </author>
16"/> <date month="April" year="2016"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/INFCOMW.2016.7562142"/>
<refcontent>2016 IEEE Conference on Computer Communications Workshops
(INFOCOM WKSHPS)</refcontent>
</reference> </reference>
<reference anchor="UMOBILE-5"> <reference anchor="UMOBILE-5">
<front> <front>
<title>Named-Data Networking in Opportunistic Networks</title> <title>Demo: named-data networking in opportunistic network</title>
<author initials="S." surname="Dynerowicz" /> <author initials="S." surname="Dynerowicz" fullname="Seweryn
<author initials="P." surname="Mendes" /> Dynerowicz">
<date year="Proc. of ACM ICN, Berlin, Germany, September 2017" <organization/>
/> </author>
<author initials="P." surname="Mendes" fullname="Paulo Mendes">
<organization/>
</author>
<date month="September" year="2017"/>
</front> </front>
<seriesInfo name="DOI" value="10.1145/3125719.3132107"/>
<refcontent>ICN '17: Proceedings of the 4th ACM Conference on
Information-Centric Networking</refcontent>
</reference> </reference>
<reference anchor="UMOBILE-6"> <reference anchor="UMOBILE-6">
<front> <front>
<title>Information-centric Routing for Opportunistic Wireless Networks <title>Information-centric routing for opportunistic wireless networks
</title> </title>
<author initials="P." surname="Mendes" /> <author><organization>Mendes, P.,et al.</organization>
<author initials="" surname="et al." /> </author>
<date year="Proc. of ACM ICN, Boston, USA, September 2018"/> <date month="September" year="2018"/>
</front> </front>
<seriesInfo name="DOI" value="10.1145/3267955.3269011"/>
<refcontent>ICN '18: Proceedings of the 5th ACM Conference on
Information-Centric Networking</refcontent>
</reference> </reference>
<reference anchor="UMOBILE-7"> <reference anchor="UMOBILE-7">
<front> <front>
<title>The UMOBILE Contextual Manager Service. Technical Report. Techn <title>D4.5 Report on Data Collection and Inference Models</title>
ical Report Senception 001, 2018 <author initials="R." surname="Sofia" fullname="Rute C. Sofia"/>
(base for UMOBILE deliverable D4.5 - Report on Data Collection <date month="September" year="2017"/>
and Inference Models</title>
<author initials="R" surname="Sofia" />
<date year="2018"/>
</front> </front>
<refcontent>Deliverable</refcontent>
</reference> </reference>
<reference anchor="UMOBILE-8"> <reference anchor="UMOBILE-8">
<front> <front>
<title>ICN-based edge service deployment in challenged networks</title > <title>ICN-based edge service deployment in challenged networks</title >
<author initials="C." surname="Sarros" /> <author>
<author initials="" surname="et al." /> <organization>Sarros, C., et al.</organization>
<date year="Proceedings of the 4th ACM Conference on Informatio </author>
n-Centric Networking (ICN '17). ACM, New York, NY, USA, 2017 "/> <date month="September" year="2017"/>
</front> </front>
<seriesInfo name="DOI" value="10.1145/3125719.3132096"/>
<refcontent>ICN '17: Proceedings of the 4th ACM Conference on
Information-Centric Networking</refcontent>
</reference> </reference>
<reference anchor="UMOBILE-9"> <reference anchor="UMOBILE-9">
<front> <front>
<title>Information-Centric Multi-Access Edge Computing Platform for Co <title>Information-Centric Multi-Access Edge Computing Platform for
mmunity Mesh Networks</title> Community Mesh Networks</title>
<author initials="A." surname="Lertsinsrubtavee" /> <author><organization>Lertsinsrubtavee, A., et al.</organization>
<author initials="" surname="et al." /> </author>
<date year="Proceedings of the 1st ACM SIGCAS Conference on Com <date month="June" year="2018"/>
puting and Sustainable Societies (COMPASS '18). ACM, New York, NY, USA, 2018 "/>
</front> </front>
<seriesInfo name="DOI" value="10.1145/3209811.3209867"/>
<refcontent>COMPASS '18: Proceedings of the 1st ACM SIGCAS Conference
on Computing and Sustainable Societies</refcontent>
</reference> </reference>
<reference anchor="SAIL" target="http://www.sail-project.eu/"> <reference anchor="SAIL" target="http://www.sail-project.eu/">
<front> <front>
<title>Scalable and Adaptive Internet Solutions (SAIL)</title> <title>Scalable and Adaptive Internet Solutions (SAIL)</title>
<author initials="" surname="SAIL" /> <author>
<date year="2013"/> <organization>SAIL</organization>
</author>
</front> </front>
</reference> </reference>
<reference anchor="NDN-testbed" target="https://named-data.net/ndn-test bed/"> <reference anchor="NDN-testbed" target="https://named-data.net/ndn-testbed /">
<front> <front>
<title>Named Data Networking (NDN) Testbed</title> <title>NDN Testbed</title>
<author initials="" surname="NDN Testbed" /> <author>
<date year="2010"/> <organization>NDN</organization>
</author>
</front> </front>
</reference> </reference>
<reference anchor="ICN2020-overview" target="http://www.icn2020.org/"> <reference anchor="ICN2020-overview" target="http://www.icn2020.org/">
<front> <front>
<title>ICN2020 Project Overview</title> <title>ICN2020 Project Overview</title>
<author initials="" surname="ICN2020" /> <author>
<date year="2016"/> <organization>ICN2020</organization>
</author>
</front> </front>
</reference> </reference>
<reference anchor="GEANT" target="https://www.geant.org/"> <reference anchor="GEANT" target="https://www.geant.org/">
<front> <front>
<title>GEANT Overview</title> <title>GEANT</title>
<author initials="" surname="GEANT" /> <author>
<date year="2016"/> <organization>GEANT</organization>
</author>
</front> </front>
</reference> </reference>
<reference anchor="UMOBILE-overview" target="http://www.umobile-project .eu/"> <reference anchor="UMOBILE-overview" target="http://www.umobile-project.eu /">
<front> <front>
<title>Universal Mobile-centric and Opportunistic Communications Archi <title>Universal, mobile-centric and opportunistic communications arch
tecture (UMOBILE)</title> itecture</title>
<author initials="" surname="UMOBILE" /> <author>
<date year="2018"/> <organization>UMOBILE</organization>
</author>
</front> </front>
</reference> </reference>
<reference anchor="NGMN-Network-Slicing" target="https://www.ngmn.org/f ileadmin/user_upload/160113_Network_Slicing_v1_0.pdf"> <reference anchor="NGMN-Network-Slicing" target="https://www.ngmn.org/wp-c ontent/uploads/160113_NGMN_Network_Slicing_v1_0.pdf">
<front> <front>
<title>NGMN Description of Network Slicing Concept</title> <title>Description of Network Slicing Concept</title>
<author initials="" surname="NGMN" /> <author>
<date year="2016"/> <organization>NGMN Alliance</organization>
</author>
<date month="January" year="2016"/>
</front> </front>
<refcontent>NGMN 5G P1</refcontent>
<refcontent>Requirements &amp; Architecture</refcontent>
<refcontent>Work Stream End-to-End Architecture</refcontent>
<refcontent>Version 1.0</refcontent>
</reference> </reference>
<reference anchor="Chakraborti"> <reference anchor="Chakraborti">
<front> <front>
<title>Design and Evaluation of a Multi-source Multi-destination Real- time Application on Content Centric Network</title> <title>Design and Evaluation of a Multi-source Multi-destination Real- time Application on Content Centric Network</title>
<author initials="A." surname="Chakraborti" /> <author>
<author initials="" surname="et al." /> <organization>Chakraborti, A., et al.</organization>
<date year="2018"/> </author>
<date month="August" year="2018"/>
</front> </front>
<seriesInfo name="IEEE, HoT ICN, 2018" value=""/> <seriesInfo name="DOI" value="10.1109/HOTICN.2018.8605980"/>
<refcontent>2018 1st IEEE International Conference on Hot
Information-Centric Networking (HotICN)</refcontent>
</reference> </reference>
<reference anchor="SAIL_Content_Delivery" target="https://sail-project.e u/wp-content/uploads/2012/06/SAIL_DB2_v1_0_final-Public.pdf"> <reference anchor="SAIL_Content_Delivery" target="https://sail-project.eu/ wp-content/uploads/2012/06/SAIL_DB2_v1_0_final-Public.pdf">
<front> <front>
<title>SAIL Content Delivery and Operations</title> <title>NetInf Content Delivery and Operations</title>
<author initials="" surname="FP7" /> <author>
<date year="2013"/> <organization>FP7</organization>
</author>
<date month="January" year="2013"/>
</front> </front>
<seriesInfo name="Objective" value="FP7-ICT-2009-5-257448/D-3.2"/>
</reference> </reference>
<reference anchor="ICN2020-Experiments" target="http://www.icn2020.org/d issemination/deliverables-public/"> <reference anchor="ICN2020-Experiments" target="https://projects.gwdg.de/a ttachments/6840/D4.1-PU.pdf">
<front> <front>
<title>Deliverable D4.1: 1st yearly report on Testbed and Experiments <title>D4.1: 1st Yearly WP4 Report &amp; Demonstration</title>
(WP4)</title> <author>
<author initials="" surname="ICN2020" /> <organization>ICN2020</organization>
<date year="2017"/> </author>
<date month="August" year="2017"/>
</front> </front>
</reference> </reference>
</references> </references>
<!-- section anchor="Appendix A" title="Change Log" --> <section anchor="Acknowledgments" numbered="false" toc="default">
<section title="Change Log"> <name>Acknowledgments</name>
<t>The authors want to thank <contact fullname="Alex Afanasyev"/>,
<t>[Note to RFC Editor: Please remove this section before publication.]</t> <contact fullname="Hitoshi Asaeda"/>, <contact fullname="Giovanna
<t>Changes from draft-irtf-rev-06 to draft-irtf-rev-07: Carofiglio"/>, <contact fullname="Xavier de Foy"/>, <contact
<list style="symbols"> fullname="Guillaume Doyen"/>, <contact fullname="Hannu Flinck"/>,
<t>Added reference to OSCORE (RFC 8613) which is a way of pass <contact fullname="Anil Jangam"/>, <contact fullname="Michael Kowal"/>,
ing <contact fullname="Adisorn Lertsinsrubtavee"/>, <contact fullname="Paulo
end-to-end encrypted content between HTTP and COAP without inv Mendes"/>, <contact fullname="Luca Muscariello"/>, <contact
alidating encryption. Thus it fullname="Thomas Schmidt"/>, <contact fullname="Jan Seedorf"/>, <contact
can be a potential model for HTTP to ICN, or COAP to ICN, to c fullname="Eve Schooler"/>, <contact fullname="Samar Shailendra"/>,
onsider in the future.</t> <contact fullname="Milan Stolic"/>, <contact fullname="Prakash Suthar"/>,
<t>Updated affiliation information for author Ravi Ravindran.< <contact fullname="Atsushi Mayutan"/>, and <contact fullname="Lixia
/t> Zhang"/> for their very useful reviews and comments to the document.
</list> </t>
</t> <t>Special thanks to <contact fullname="Dave Oran"/> (ICNRG Co-chair)
and <contact fullname="Marie-Jose Montpetit"/> for their extensive and
<t>Changes from draft-irtf-rev-05 to draft-irtf-rev-06: thoughtful reviews of the document. Their reviews helped to
<list style="symbols"> immeasurably improve the document quality.</t>
<t>Various updates to ensure that draft complies with RFC 5743
(Definition of an Internet Research
Task Force (IRTF) Document Stream) section 2.1.</t>
</list>
</t>
<t>Changes from draft-irtf-rev-04 to draft-irtf-rev-05:
<list style="symbols">
<t>Addressed detailed review comments from Marie-Jose Montpeti
t.</t>
</list>
</t>
<t>Changes from draft-irtf-rev-03 to draft-irtf-rev-04:
<list style="symbols">
<t>Added text from Paulo Mendes and Adisorn Lertsinsrubtavee o
n UMOBILE Trial Experiences.</t>
<t>Incorporated off-line editorial comments from Hitoshi Asaed
a and Anil Jangam.</t>
</list>
</t>
<t>Changes from draft-irtf-rev-02 to draft-irtf-rev-03:
<list style="symbols">
<t>Editorial update of description and references of Doctor te
stbed as per comments from Guillaume Doyen.</t>
<t>Ran IETF spell checker tool and corrected various spelling
errors.</t>
</list>
</t>
<t>Changes from draft-irtf-rev-01 to draft-irtf-rev-02:
<list style="symbols">
<t>Updated description of Doctor testbed as per comments from
Guillaume Doyen. Also referenced Doctor testbed from the Security Consideration
s section.</t>
<t>Added "Composite-ICN" configuration to cover the Hybrid ICN
and similar configurations which do not clearly fit in one of the other basic c
onfigurations.</t>
<t>Updated description of the ICN-as-a-Slice configuration to
clarify that it may also apply to non-5G systems.</t>
</list>
</t>
<t>Changes from draft-irtf-rev-00 to draft-irtf-rev-01:
<list style="symbols">
<t>Added text from Michael Kowal describing NREN ICN Testbed.<
/t>
<t>Added text from Guillaume Doyen describing Doctor Project.<
/t>
<t>Updated text on Hybrid ICN based on input from Luca Muscari
ello.</t>
</list>
</t>
<t>Changes from draft-rahman-rev-05 to draft-irtf-rev-00:
<list style="symbols">
<t>Changed draft status from individual draft-rahman-icnrg-dep
loyment-guidelines-05 to RG adopted draft-irtf-icnrg-deployment-guidelines-00.</
t>
</list>
</t>
<t>Changes from rev-04 to rev-05:
<list style="symbols">
<t>Added this Change Log in Appendix A.</t>
<t>Removed references to Hybrid ICN from section 3.2 (ICN-as-an-Ov
erlay definition). Instead, consolidated all Hybrid ICN info in the
Deployment Trial Experiences under a new subsection 5.3 (Other
Configurations).</t>
<t>Updated ICN2020 description in Section 5.1.4 with text received
from Mayutan Arumaithurai and Hitoshi Asaeda.</t>
<t>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 the entire M
obile network.</t>
<t>Added several new references in various sections.</t>
<t>Various minor editorial updates.</t>
</list>
</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 265 change blocks. 
1793 lines changed or deleted 2029 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/