<?xml version="1.0" encoding="UTF-8"?> encoding="utf-8"?>
<!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/public/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/bibxml3/reference.I-D.irtf-icnrg-icniot.xml'>
<!ENTITY I-D.irtf-icnrg-terminology SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.irtf-icnrg-terminology.xml'>
<!ENTITY I-D.irtf-icnrg-icn-lte-4g SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.irtf-icnrg-icn-lte-4g.xml'>
<!ENTITY I-D.irtf-icnrg-ccninfo SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/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/bibxml3/reference.I-D.ravi-icnrg-5gc-icn.xml'>
<!ENTITY I-D.moiseenko-icnrg-flowclass SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.moiseenko-icnrg-flowclass.xml'>
<!ENTITY I-D.anilj-icnrg-icn-qos SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.anilj-icnrg-icn-qos.xml'>
<!ENTITY I-D.mendes-icnrg-dabber SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/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"?> "rfc2629-xhtml.ent">

<rfc number="8763" consensus="true" xmlns:xi="http://www.w3.org/2001/XInclude" category="info"
     docName="draft-irtf-icnrg-deployment-guidelines-07"
     ipr="trust200902"> 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>
    <title abbrev="Deployment Considerations for ICN">
       Deployment Considerations for Information-Centric Networking (ICN)
    </title>

    <!-- AUTHORS -->
    <seriesInfo name="RFC" value="8763"/>

        <author fullname="Akbar Rahman" initials="A." surname="Rahman">
      <organization abbrev="InterDigital Communications, LLC">
        InterDigital Communications, LLC
      </organization>
      <address>
        <postal>
          <street>1000 Sherbrooke Street West, 10th floor</street>
          <city>Montreal</city>
          <code> H3A
          <code>H3A 3G4</code>
          <country>Canada</country>
        </postal>
        <email>Akbar.Rahman@InterDigital.com</email>
        <uri>http://www.InterDigital.com/</uri>
      </address>
    </author>
    <author fullname="Dirk Trossen" initials="D." surname="Trossen">
      <organization abbrev="InterDigital Europe, Ltd">
        InterDigital Europe, Ltd
      </organization> abbrev="Huawei">Huawei Technologies Duesseldorf GmbH</organization>
      <address>
        <postal>
          <street>64 Great Eastern Street, 1st Floor</street>
          <city>London</city>
          <code>EC2A 3QR</code>
          <country>United Kingdom</country>
          <street>Riesstrasse 25</street>
          <city>Munich</city>
          <code>80992</code>
          <country>Germany</country>
        </postal>
        <email>Dirk.Trossen@InterDigital.com</email>
        <uri>http://www.InterDigital.com/</uri>
        <email>dirk.trossen@huawei.com</email>
        <uri>http://www.huawei.com/</uri>
      </address>
    </author>

    <author fullname="Dirk Kutscher" initials="D." surname="Kutscher">
      <organization abbrev="University of Applied Sciences Emden/Leer"> abbrev="Emden University">
        University of Applied Sciences Emden/Leer
      </organization>
      <address>
        <postal>
          <street>Constantiapl. 4</street>
          <city>Emden</city>
          <code>26723</code>
          <country>Germany</country>
        </postal>
        <email>ietf@dkutscher.net</email>
        <uri>https://www.hs-emden-leer.de/en/</uri>
      </address>
    </author>
    <author fullname="Ravi Ravindran" initials="R." surname="Ravindran">
      <organization abbrev="Futurewei">
        Future
      <organization>
        Sterlite Technologies
      </organization>
      <address>
        <postal>
          <street>2330 Central Expressway</street>
          <street>5201 Greatamerica Pkwy</street>
          <city>Santa Clara</city>
          <code>95050</code>
          <country>USA</country>
          <code>95054</code>
          <country>United States of America</country>
        </postal>
        <email>ravi.ravindran@futurewei.com</email>
        <email>ravi.ravindran@gmail.com</email>
      </address>
    </author>

    <date month="September" year="2019" /> month="April" year="2020"/>
    <area>Internet Research Task Force (IRTF)</area>

    <workgroup>ICNRG</workgroup>
    <workgroup>Information-Centric Networking</workgroup>

    <abstract>
      <t>Information-Centric Networking (ICN) is now reaching technological
      maturity after many years of fundamental research and experimentation.
	  This document provides a number of deployment considerations in the
	  interest of helping the ICN community move forward to the next step
	  of live deployments. First, the major deployment configurations for
	  ICN are described described, including the key overlay and underlay approaches.  Then
	  Then, proposed deployment migration paths are outlined to address
	  major practical issues issues, such as network and application migration.
	  Next, selected ICN trial experiences are summarized. Finally,
	  protocol areas that require further standardization are identified
	  to facilitate future interoperable ICN deployments. This document is
	  a product of the Information-Centric Networking Research Group
	  (ICNRG).
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="sec:introduction" title="Introduction"> anchor="sec_introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The ICNRG charter identifies deployment guidelines as an important
      topic area for the ICN community. Specifically, the charter states
	  that defining concrete migration paths for ICN deployments which that
	  avoid forklift upgrades, upgrades and defining practical ICN interworking
	  configurations
	  with the existing Internet paradigm, paradigm are key topic areas that
	  require further investigation <xref target="ICNRGCharter" />.
	  format="default"/>. Also, it is well
	  understood that results and conclusions from any mid mid- to large-scale
	  ICN experiments in the live Internet will also provide useful
	  guidance for deployments.
      </t>
      <t>So far, outside of some preliminary investigations investigations, such as <xref
      target="I-D.paik-icn-deployment-considerations" />, format="default"/>,
      there has not been much
	  progress on this topic. This document attempts to fill some of
	  these gaps by defining clear deployment configurations for ICN, ICN and
	  associated
	  migration pathways for these configurations. Also, selected
	  deployment trial experiences of ICN technology are summarized.
	  Recommendations
	  are also made for potential future IETF standardization of key
	  protocol functionality that will facilitate interoperable ICN
	  deployments going forward.
      </t>
      <t>The major configurations of possible ICN deployments are identified
      in this document as (1) Clean-slate ICN replacement of existing Internet infrastructure;
      infrastructure,
	  (2) ICN-as-an-Overlay; ICN-as-an-Overlay, (3) ICN-as-an-Underlay; ICN-as-an-Underlay, (4) ICN-as-a-Slice; ICN-as-a-Slice,
	  and (5) Composite-ICN. Existing ICN trial systems primarily fall
	  under the ICN-as-an-Overlay, ICN-as-an-Underlay ICN-as-an-Underlay, and Composite-ICN
	  configurations. 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>This document represents the consensus of the Information-Centric
      Networking Research Group (ICNRG). It has been reviewed extensively by
      the Research Group
	  (RG) members active in the specific areas of work covered by the document.</t>
    </section>
    <section anchor="sec:terminology" title="Terminology">

<!--
      <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>
--> anchor="sec_terminology" numbered="true" toc="default">
      <name>Terminology</name>

      <t>
This document assumes readers are, in general, familiar with the terms and
concepts that are defined in <xref target="RFC7927" /> format="default"/> and
<xref target="I-D.irtf-icnrg-terminology" />. format="default"/>. In addition,
this document defines the following terminology:

        <list style="empty">

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

      </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 end-user
		  video and text) in a live environment, environment and (2) integrated
		  and interoperable
		  with the Internet. We consider the Internet in its widest
		  sense where it encompasses various access networks (e.g., WiFi, Mobile
		  Wi-Fi or mobile radio network),
		  service edge networks (e.g., for edge computing), transport
		  networks, CDNs, Content Distribution Networks (CDNs), core networks (e.g., Mobile mobile core network),
		  and back-end processing networks
		  (e.g., Data Centres). data centers). However, throughout the document we typically limit this document,
		  the discussion is typically limited to edge networks, core networks
		  networks, and CDNs CDNs, for simplicity.
</t>

          <t>Information-Centric simplicity.</dd>
        <dt>Information-Centric Networking (ICN) - A (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.
</t>

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

          <t>Software-Defined information.</dd>
		  <dt>Software-Defined Networking (SDN) -  A (SDN):</dt>

        <dd>A networking approach where the control and data plane planes for
      switches are separated, allowing for
	realizing
		  capabilities capabilities, such as traffic isolation and programmable
	forwarding actions. See <xref target="RFC7426" /> format="default"/> for
	further information.
</t>

        </list>

 </t> information.</dd>
      </dl>
    </section>
    <section anchor="sec:acronyms" title="Acronyms List">
		<t>
         <list style="empty">

            <t>API	- Application anchor="sec_acronyms" numbered="true" toc="default">
      <name>Abbreviations List</name>

      <dl newline="false" spacing="normal" indent="13">
        <dt>API:</dt>
        <dd>Application Programming Interface</t>
			<t>BIER	- Bit Indexed Interface</dd>
        <dt>BIER:</dt>
        <dd>Bit Index Explicit Replication</t>
			<t>BoF	- Birds Replication</dd>
        <dt>BoF:</dt>
        <dd>Birds of a Feather (session)</t>
			<t>CCN	- Content Centric Networking</t>
			<t>CCNx	- Content Centric Networking</t>
			<t>CDN	- Content (session)</dd>
        <dt>CCNx:</dt>
        <dd>Content-Centric Networking</dd>
        <dt>CDN:</dt>
        <dd>Content Distribution Network</t>
            <t>CoAP	- Constrained Network</dd>
        <dt>CoAP:</dt>
        <dd>Constrained Application Protocol</t>
			<t>DASH	- Dynamic Protocol</dd>
        <dt>DASH:</dt>
        <dd>Dynamic Adaptive Streaming over HTTP</t>
			<t>DiffServ	- Differentiated Services</t>
			<t>DoS	- Denial of Service</t>
			<t>DTN	- Delay Tolerant Networking</t>
			<t>ETSI	- European Telecommunication HTTP</dd>
        <dt>Diffserv:</dt>
        <dd>Differentiated Services</dd>
        <dt>DoS:</dt>
        <dd>Denial of Service</dd>
        <dt>DTN:</dt>
        <dd>Delay-Tolerant Networking</dd>
        <dt>ETSI:</dt>
        <dd>European Telecommunications Standards Institute</t>
			<t>EU	- European Union</t>
			<t>FP7	- 7th Institute</dd>
        <dt>EU:</dt>
        <dd>European Union</dd>
        <dt>FP7:</dt>
        <dd>7th Framework Programme for Research and Technological Development</t>
			<t>HLS	- HTTP Development</dd>
        <dt>HLS:</dt>
        <dd>HTTP Live Streaming</t>
			<t>HTTP	- Hyper Text Streaming</dd>
        <dt>HTTP:</dt>
        <dd>HyperText Transfer Protocol</t>
			<t>HTTPS- Hyper Text Protocol</dd>
        <dt>HTTPS:</dt>
        <dd>HyperText Transfer Protocol Secure</t>
			<t>H2020- Horizon Secure</dd>
        <dt>H2020:</dt>
        <dd>Horizon 2020 (research program)</t>
			<t>ICN	- Information-Centric Networking</t>
			<t>ICNRG- Information-Centric program)</dd>
        <dt>ICN:</dt>
        <dd>Information-Centric Networking</dd>
        <dt>ICNRG:</dt>
        <dd>Information-Centric Networking Research Group</t>
			<t>IETF	- Internet Group</dd>
        <dt>IETF:</dt>
        <dd>Internet Engineering Task Force</t>
			<t>IntServ	- Integrated Services</t>
			<t>IoT	- Internet of Things</t>
		    <t>IP	- Internet Protocol</t>
			<t>IPv4	- Internet Force</dd>
        <dt>IntServ:</dt>
        <dd>Integrated Services</dd>
        <dt>IoT:</dt>
        <dd>Internet of Things</dd>
        <dt>IP:</dt>
        <dd>Internet Protocol</dd>
        <dt>IPv4:</dt>
        <dd>Internet Protocol Version 4</t>
			<t>IPv6	- Internet 4</dd>
        <dt>IPv6:</dt>
        <dd>Internet Protocol Version 6</t>
			<t>IPTV	- Internet 6</dd>
        <dt>IPTV:</dt>
        <dd>Internet Protocol Television</t>
			<t>ISIS	- Intermediate Television</dd>
        <dt>IS-IS:</dt>
        <dd>Intermediate System to Intermediate System</t>
			<t>ISP	- Internet System</dd>
        <dt>ISP:</dt>
        <dd>Internet Service Provider</t>
			<t>k	- kilo (1000)</t>
			<t>L2	- Layer 2</t>
			<t>LTE	- Long Provider</dd>
        <dt>k:</dt>
        <dd>kilo (1000)</dd>
        <dt>L2:</dt>
        <dd>Layer 2</dd>
        <dt>LTE:</dt>
        <dd>Long Term Evolution (or 4th generation cellular system)</t>
			<t>MANO	- Management and Orchestration</t>
			<t>MEC	- Mobile system)</dd>
        <dt>MANO:</dt>
        <dd>Management and Orchestration</dd>
        <dt>MEC:</dt>
        <dd>Multi-access Edge Computing</t>
			<t>Mbps	- Megabits Computing</dd>
        <dt>Mbps:</dt>
        <dd>Megabits per second</t>
			<t>M2M	- Machine-to-Machine</t>
			<t>NAP	- Network second</dd>
        <dt>M2M:</dt>
        <dd>Machine-to-Machine</dd>
        <dt>NAP:</dt>
        <dd>Network Attachment Point</t>
			<t>NDN	- Named Point</dd>
        <dt>NDN:</dt>
        <dd>Named Data Networking</t>
			<t>NETCONF	- Network Networking</dd>
        <dt>NETCONF:</dt>
        <dd>Network Configuration Protocol</t>
			<t>NetInf	- Network Protocol</dd>
        <dt>NetInf:</dt>
        <dd>Network of Information </t>
			<t>NFD	- Named </dd>
        <dt>NFD:</dt>
        <dd>Named Data Networking Forwarding Daemon</t>
			<t>NFV	- Network Daemon</dd>
        <dt>NFV:</dt>
        <dd>Network Functions Virtualization</t>
			<t>NICT	- Virtualization</dd>
        <dt>NICT:</dt>
        <dd>Japan's National Institute of Information and Communications Technology of Japan</t>
			<t>NR	- New Technology</dd>
        <dt>NR:</dt>
        <dd>New Radio (access network for 5G)</t>
			<t>OAM	- Operations and Maintenance</t>
			<t>ONAP	- Open 5G)</dd>
        <dt>OAM:</dt>
        <dd>Operations, Administration, and Maintenance</dd>
        <dt>ONAP:</dt>
        <dd>Open Network Automation Platform</t>
			<t>OSPF	- Open Platform</dd>
        <dt>OSPF:</dt>
        <dd>Open Shortest Path First</t>
			<t>PoC	- Proof First</dd>
        <dt>PoC:</dt>
        <dd>Proof of Concept (demo)</t>
			<t>POINT- (demo)</dd>
        <dt>POINT:</dt>
        <dd> IP Over ICN – - the better IP (project)</t>
			<t>qMp	- Quick (project)</dd>
        <dt>qMp:</dt>
        <dd>Quick Mesh Project</t>
		    <t>QoS	- Quality of Service</t>
			<t>RAM	- Random Project</dd>
        <dt>QoS:</dt>
        <dd>Quality of Service</dd>
        <dt>RAM:</dt>
        <dd>Random Access Memory</t>
			<t>RAN	- Radio Memory</dd>
        <dt>RAN:</dt>
        <dd>Radio Access Network</t>
			<t>REST	- Representational Network</dd>
        <dt>REST:</dt>
        <dd>Representational State Transfer (architecture)</t>
			<t>RESTCONF	- Representational (architecture)</dd>
        <dt>RESTCONF:</dt>
        <dd>Representational State Transfer Configuration (protocol)</t>
			<t>RIFE	- Architecture (protocol)</dd>
        <dt>RIFE:</dt>
        <dd>Architecture for an Internet For Everybody (project)</t>
			<t>RIP	- Routing (project)</dd>
        <dt>RIP:</dt>
        <dd>Routing Information Protocol </t>
			<t>ROM	- Read Only Memory</t>
			<t>RSVP	- Resource </dd>
        <dt>ROM:</dt>
        <dd>Read-Only Memory</dd>
        <dt>RSVP:</dt>
        <dd>Resource Reservation Protocol</t>
			<t>RTP	- Real-time Protocol</dd>
        <dt>RTP:</dt>
        <dd>Real-time Transport Protocol</t>
			<t>SDN	- Software-Defined Networking</t>
			<t>SFC	- Service Protocol</dd>
        <dt>SDN:</dt>
        <dd>Software-Defined Networking</dd>
        <dt>SFC:</dt>
        <dd>Service Function Chaining</t>
			<t>SLA	- Service Chaining</dd>
        <dt>SLA:</dt>
        <dd>Service Level Agreement</t>
			<t>TCL	- Transport Agreement</dd>
        <dt>TCL:</dt>
        <dd>Transport Convergence Layer</t>
		    <t>TCP	- Transmission Layer</dd>
        <dt>TCP:</dt>
        <dd>Transmission Control Protocol</t>
			<t>UDP  - User Protocol</dd>
        <dt>UDP:</dt>
        <dd>User Datagram Protocol</t>
			<t>UMOBILE  - Universal Protocol</dd>
        <dt>UMOBILE:</dt>
        <dd>Universal Mobile-centric and Opportunistic Communications Architecture</t>
			<t>US	- United States</t>
			<t>USA	- United Architecture</dd>
        <dt>US:</dt>
        <dd>United States</dd>
        <dt>USA:</dt>
        <dd>United States of America</t>
			<t>VoD  - Video on Demand</t>
			<t>VPN  - Virtual America</dd>
        <dt>VoD:</dt>
        <dd>Video on Demand</dd>
        <dt>VPN:</dt>
        <dd>Virtual Private Network</t>
			<t>WG 	- Working Group</t>
			<t>YANG - Yet Network</dd>
        <dt>WG:</dt>
        <dd>Working Group</dd>
        <dt>YANG:</dt>
        <dd>Yet Another Next Generation (data modeling language)</t>
		    <t>5G	- Fifth language)</dd>
        <dt>5G:</dt>
        <dd>Fifth Generation (cellular network)</t>
			<t>6LoWPAN	-  IPv6 network)</dd>
        <dt>6LoWPAN:</dt>
        <dd>IPv6 over Low-Power Wireless Personal Area Networks</t>
         </list>
		 </t> Networks</dd>
      </dl>
    </section>
    <section anchor="sec:configurations" title="Deployment Configurations"> anchor="sec_configurations" numbered="true" toc="default">
      <name>Deployment Configurations</name>
      <t>In this section, we present various deployment options for ICN.
      These are presented as "configurations" that allow for studying these
      options
	further. While this document will outline experiences with various a number of
	these configurations (in <xref target="sec:trial_experiences" />), target="sec_trial_experiences"
	format="default"/>), we will
	not provide an in-depth technical or commercial evaluation for any of
	them - -- for this this, we refer to existing literature in this space space, such as
	<xref target="Tateson" />. format="default"/>.
      </t>
      <section anchor="sec:replacements" title="Clean-slate ICN"> 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
	goal to renew or replace the complete IP infrastructure of the
		Internet.
		As such, existing routing hardware as well as and
		ancillary services services, such as existing applications which that are
		typically tied directly to the TCP/IP protocol stack stack, are not
		taken for granted. For instance, a Clean-slate ICN deployment
		would see existing IP routers being replaced by ICN-specific
		forwarding and routing elements, such as NFD <xref
		target="NFD" />, CCN format="default"/>, CCNx routers <xref
		target="Jacobson" /> format="default"/>, or PURSUIT Publish-Subscribe
		Internet Technology (PURSUIT) forwarding nodes <xref
		target="IEEE_Communications" />. format="default"/>.
</t>
        <t>While such clean-slate replacement could be seen as exclusive for
	ICN deployments, some ICN approaches (e.g., <xref target="POINT" />)
	format="default"/>)
		also rely on the deployment of general infrastructure
		upgrades, in this case case, SDN switches. Different proposals have
		been made for various
		ICN approaches to enable the operation over an SDN transport
		<xref target="Reed" /><xref format="default"/> <xref target="CONET" /><xref
		format="default"/> <xref target="C_FLOW" />. format="default"/>.
</t>
      </section>
      <section anchor="sec:overlay" title="ICN-as-an-Overlay">

        <t>Similarly anchor="sec_overlay" numbered="true" toc="default">
        <name>ICN-as-an-Overlay</name>
        <t>Similar to other significant changes to the Internet routing
	fabric, particularly the transition from IPv4 to IPv6 or
		the introduction of IP multicast, this deployment
		configuration foresees the creation of an ICN overlay. Note
		that this overlay
		approach is sometimes, informally, also referred to as a
		tunneling approach.
                The overlay approach can be implemented directly
		such as ICN-over-UDP
		(e.g., ICN-over-UDP), as described in <xref target="CCNx_UDP" />.
		format="default"/>. Alternatively, the overlay can be
		accomplished via ICN-in-L2-in-IP as in <xref
		target="IEEE_Communications" /> format="default"/>, which
		describes a recursive layering process. Another approach used
		in the Network of Information (NetInf) is to define a
		convergence layer to map NetInf semantics to HTTP <xref
		target="I-D.kutscher-icnrg-netinf-proto" />. format="default"/>.
		Finally, <xref target="Overlay_ICN" /> format="default"/>
		describes an incremental approach to deploying an ICN
		architecture particularly well-suited well suited to
		SDN based
		SDN-based networks by also segregating ICN user user- and control plane
		control-plane traffic.
</t>

		<t>Regardless
        <t>However, regardless of the flavor, however, the overlay approach results in
	islands of ICN deployments over existing IP-based infrastructure.
		Furthermore, these ICN islands are typically connected to each
		other via ICN/IP tunnels. In certain scenarios scenarios, this requires
		interoperability between existing IP routing protocols (e.g.,
		OSPF, RIP, ISIS) or IS-IS) and ICN based ICN-based ones. ICN-as-an-Overlay can be
		deployed
		over the IP infrastructure in either edge or core networks.
		This overlay approach is thus very attractive for ICN
		experimentation
		and testing testing, as it allows rapid and easy deployment of ICN over
		existing IP networks.
</t>
      </section>
      <section anchor="sec:underlay" title="ICN-as-an-Underlay">

        <t>Proposals anchor="sec_underlay" numbered="true" toc="default">
        <name>ICN-as-an-Underlay</name>
        <t>Proposals, such as <xref target="POINT" /> format="default"/> and <xref
	target="White" /> format="default"/>, outline the deployment option of
	using an ICN underlay that would
		integrate with existing (external) IP-based networks by
		deploying application layer application-layer gateways at appropriate locations.
		The main reasons for
		such a configuration option is the introduction of ICN
		technology in given islands (e.g., inside a CDN or edge IoT
		network) to reap the benefits
		of native ICN ICN, in terms of underlying multicast delivery,
		mobility support, fast indirection due to location
		independence, in-network computing computing,
		and possibly more. The underlay approach thus results in
		islands of native ICN deployments which that are connected to the
		rest of the Internet
		through protocol conversion gateways or proxies. Routing
		domains are strictly separated. Outside of the ICN island,
		normal IP routing protocols
		apply. Within the ICN island, ICN based ICN-based routing schemes
		apply. The gateways transfer the semantic content of the
		messages (i.e., IP packet payload) between the two routing
		domains.
</t>
        <section anchor="sec:application_gateways" title="Edge Network"> anchor="sec_application_gateways" numbered="true" toc="default">
          <name>Edge Network</name>
          <t>Native ICN networks may be located at the edge of the network
	  where the introduction of new network
		architectures and protocols is easier in so-called greenfield
		deployments. In this context context, ICN is an attractive option
		for scenarios scenarios, such as IoT <xref target="I-D.irtf-icnrg-icniot" />.
		format="default"/>. The integration with the current IP
		protocol suite takes place at an
		application gateway/proxy at the edge network boundary, e.g.,
		translating incoming CoAP request/response transactions
		<xref target="RFC7252" /> format="default"/> into ICN message
		exchanges or vice versa.
</t>
          <t>The work in <xref target="VSER" /> format="default"/> positions ICN
	  as an edge service gateway driven by a generalized ICN based ICN-based service
	  orchestration
		system with its own compute and network virtualization
		controllers to manage an ICN infrastructure. The platform also
		offers service discovery
		capabilities to enable user applications to discover
		appropriate ICN service gateways. To exemplify a
		scenario in a use case scenario, case, the <xref target="VSER" /> format="default"/> platform
		shows the realization of a multi-party audio/video
		conferencing service over such a an edge cloud deployment of ICN
		routers realized over commodity hardware platforms.  This platform has also been extended to
		offer seamless mobility and mobility as a service that <xref
		target="VSER-Mob" /> format="default"/> features.
          </t>
        </section>
        <section anchor="sec:http_ip" title="Core Network"> anchor="sec_http_ip" numbered="true" toc="default">
          <name>Core Network</name>
          <t>In this sub-option, suboption, a core network would utilize edge-based
	  protocol mapping onto the native ICN underlay. For instance, <xref
	  target="POINT" /> format="default"/> proposes
		to map HTTP transactions, transactions or some other IP based transactions IP-based transactions,
		such as CoAP, directly onto an ICN-based message
		exchange. This mapping is realized at the
		NAP, such as realized for example, in access points or customer premise
		equipment, which which, in turn turn, provides a standard IP interface to
		existing user devices. The NAPs thus Thus, the NAP provides the apparent
		perception of an IP-based core network towards toward any external
		peering network.
</t>
          <t>The work in <xref target="White" /> format="default"/> proposes a
	  similar deployment configuration. There, the goal is to use ICN for
	  content distribution within CDN
		server farms. Specifically, the protocol mapping is realized
		at the ingress of the server farm where the HTTP-based
		retrieval request is served, while the
		response is delivered through a suitable egress node
		translation.
</t>
        </section>
      </section>
      <section anchor="sec:icn_slice" title="ICN-as-a-Slice"> anchor="sec_icn_slice" numbered="true" toc="default">
        <name>ICN-as-a-Slice</name>
        <t> The objective of Network network slicing <xref target="NGMN-5G"/> target="NGMN-5G"
	format="default"/> is to multiplex a general pool of compute, storage storage,
	and bandwidth resources among multiple service networks with exclusive SLA
	requirements on transport and compute level compute-level QoS and security. This is
	enabled through NFV and SDN technology functions that enables enable
	functional decomposition hence (hence, modularity, independent scalability
        of control control, and/or the user-plane functions, agility functions), agility, and service driven service-driven
	programmability. Network slicing is often associated with 5G but is
	clearly not limited to such systems. However, from a 5G perspective,
	the definition of slicing includes access network networks enabling dynamic
	slicing of the spectrum resources among various services services, hence naturally
	extending itself to end points and also cloud resources across
	multiple domains, to offer end-to-end guarantees. These
                Once instantiated, these slices once instantiated
		could include a mix of connectivity services like LTE-as-a-service or OTT (e.g.,
		LTE-as-a-service), Over-the-Top (OTT) services like VoD (e.g., VoD), or
		other IoT services through composition of a group of virtual
		and/or physical network functions at control, user the control-, user-, and service plane level.
		service-plane levels. Such a framework
		can also be used to realize ICN slices with its own control
		and forwarding plane plane, over which one or more end-user
		services can be delivered <xref target="NGMN-Network-Slicing"/>.</t> target="NGMN-Network-Slicing"
		format="default"/>.</t>
        <t>The 5G next generation architecture <xref target="fiveG-23501"/> target="fiveG-23501"
	format="default"/> provides the flexibility to deploy the
	ICN-as-a-Slice over either the edge (RAN), Mobile core network, (RAN) or mobile core network; otherwise,
	the ICN-as-a-Slice may be deployed end-to-end. end to end. Further discussions on
	extending the architecture presented in <xref target="fiveG-23501"/> target="fiveG-23501"
	format="default"/>  and the corresponding procedures in <xref target="fiveG-23502"/>
	target="fiveG-23502" format="default"/>  to support ICN has been
	provided in <xref target="I-D.ravi-icnrg-5gc-icn" />.
	format="default"/>.

	The draft document elaborates on two possible approaches to
	enable ICN. First, ICN: (1) as an edge service using the local data network (LDN)
		feature in 5G using UPF User Plane Function (UPF) classification
		functions to fast
		handover to the ICN forwarder; the other is forwarder and (2) as a native deployment
		using the non-IP PDU Protocol Data Unit (PDU) support that would allow new network
		layer PDU to be handed over to ICN UPFs collocated with the gNB functions,
		Generation NodeB (gNB) functions without invoking any IP
		functions. While the
		former deployment would still rely on 3GPP based 3GPP-based mobility
		functions, the later would
		allow mobility to be handled natively by ICN. However However, both
		these deployment modes should benefit from other ICN features features,
		such as in-network caching and computing. Associated with this
		ICN user plan user-plane enablement, control plane control-plane extensions are also
		proposed leveraging 5GC’s 5th Generation Core Network (5GC)'s
		interface to other application functions (AF) (AFs)
		to allow new network service level service-level programmability. Such a
		generalized network slicing framework should be able to offer
		service slices over both IP and ICN. Coupled
		with the view of ICN functions as being "chained service functions" "service
		function chaining" <xref target="RFC7665"/>, 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, slice but
		instead that the slice is created to run an a 5G-ICN instance
	<xref target="Ravindran"/>.</t> target="Ravindran" format="default"/>.</t>
        <t>At the level of the specific technologies involved, such as ONAP
	<xref target="ONAP"/> that target="ONAP" format="default"/> (which can be used to orchestrate slices,
	slices),
		the 5G-ICN slice requires compatibility compatibility, for instance instance, at the
		level of the forwarding/data plane depending on if it is
		realized as
		an overlay or using programmable data planes. With SDN
		emerging for new network deployments, some ICN approaches will
		need to
		integrate with SDN as a data plane data-plane forwarding function, function with SDN, as
		briefly discussed in <xref target="sec:replacements" />. target="sec_replacements"
		format="default"/>. Further
		cross domain
		cross-domain ICN slices can also be realized using frameworks frameworks,
		such as <xref target="ONAP"/>.
		</t> target="ONAP" format="default"/>.</t>
      </section>
      <section anchor="sec:hybrid" title="Composite-ICN Approach"> anchor="sec_hybrid" numbered="true" toc="default">
        <name>Composite-ICN Approach</name>
        <t>Some deployments do not clearly correspond to any of the previously
	defined basic configurations of
	  (1) Clean-slate ICN; ICN, (2) ICN-as-an-Overlay; ICN-as-an-Overlay, (3) ICN-as-an-Underlay; ICN-as-an-Underlay,
	  and (4) ICN-as-a-Slice. Or, a deployment
	  may contain a composite mixture of the properties of these basic
	  configurations. For example, the Hybrid ICN
	  <xref target="H-ICN_1" /> format="default"/> approach carries ICN names
	  in existing IPv6 headers and does not have distinct gateways
	  or tunnels connecting ICN islands, islands or any other distinct feature
	  identified in the previous basic configurations.
	  So we categorize Hybrid ICN, ICN and other approaches that do not
	  clearly correspond to one of the other basic
	  configurations,
	  configurations as a Composite-ICN approach.</t>
      </section>
    </section>
    <section anchor="sec:migration" title="Deployment anchor="sec_migration" numbered="true" toc="default">
      <name>Deployment Migration Paths"> Paths</name>
      <t>We now focus on the various migration paths that will have importance
      to the various stakeholders that are usually involved
	in the deployment of ICN networks. We can identify these stakeholders
	as:
        <list style="symbols">
          <t>Application providers</t>
          <t>ISPs
      </t>
      <ul spacing="normal">
        <li>application providers</li>
        <li>ISPs and service providers, both as core as well as and access network
	providers, and also as well as ICN network providers</t>
          <t>CDN providers</li>
        <li>CDN providers (due to the strong relation of the ICN proposition
	to content delivery)</t>
		  <t>End device delivery)</li>
        <li>end-device manufacturers and users</t>
        </list> users</li>
      </ul>
      <t>
	Our focus is on technological aspects of such migration. Economic or
	regulatory aspects, such as those studied in <xref target="Tateson" />,
	format="default"/>,
	<xref target="Techno_Economic" /> format="default"/>, and <xref
	target="Internet_Pricing" /> format="default"/>, are left out of our
	discussion.
</t>
      <section anchor="sec:apps_service" title="Application anchor="sec_apps_service" numbered="true" toc="default">
        <name>Application and Service Migration"> Migration</name>
        <t>The Internet supports a multitude of applications and services
	using the many protocols defined over the packet level packet-level IP
	service. HTTP provides
		one convergence point for these services with many Web web
		development frameworks based on the semantics provided by it.
		In recent years, even services such as video delivery have
		been migrating from the traditional RTP-over-UDP delivery to
		the various HTTP-level
		streaming solutions, such as DASH <xref target="DASH" />
		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.
</t>
        <t>The underlay deployment configuration option presented in <xref target ="sec:underlay" />
	target="sec_underlay" format="default"/> aims at providing some level
	of compatibility
		to the existing ecosystem through a proxy based proxy-based message flow
		mapping mechanism (e.g., mapping of existing HTTP/TCP/IP
		message flows to
		HTTP/ICN message flows). A related approach of mapping TCP/IP
		to TCP/ICN message flows is described in <xref
		target="Moiseenko" />. format="default"/>.
		Another approach described in <xref target="Marchal" />
		format="default"/> uses HTTP/NDN gateways and focuses focuses, in particular
		particular, on the right strategy to map
		HTTP to NDN to guarantee a high level of compatibility with
		HTTP while enabling an efficient caching of Data data in the ICN
		island. The choice
		of approach is a design decision based on how to configure the
		protocol stack. For example, the approach
		described in <xref target="Moiseenko" /> format="default"/>
		carries the TCP layer into the ICN underlay.  While 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>Alternatively, ICN as an overlay ICN-as-an-Overlay (<xref target="sec:overlay" />), as well as target="sec_overlay"
	format="default"/>) and ICN-as-a-Slice (<xref target="sec:icn_slice" />),
	target="sec_icn_slice" format="default"/>) allow for the
		introduction of the full capabilities of ICN through new
		application/service interfaces interfaces, as well as operations in the
		network. With that, these
		approaches of deployment are likely to aim at introducing new
		application/services capitalizing on those ICN capabilities,
		such as in-network
		multicast and/or caching.
</t>
        <t>Finally, <xref target="I-D.irtf-icnrg-icn-lte-4g" />
	format="default"/> outlines a dual-stack end user end-user device approach that
	is applicable for all deployment
		configurations. Specifically, it introduces middleware layers
		(called the TCL) in the device that will dynamically adapt
		existing applications
		to either an underlying ICN protocol stack or standard IP
		protocol stack. This involves end device
		signalling
		signaling with the network to determine which protocol stack
		instance and associated middleware adaptation layers to
		utilize for a given application transaction.
</t>
      </section>
      <section anchor="sec:cdn_migration" title="Content anchor="sec_cdn_migration" numbered="true" toc="default">
        <name>Content Delivery Network Migration"> Migration</name>
        <t>A significant number of services and applications are devoted to
	content delivery in some form, either e.g., as video delivery, social media
	platforms,
		and many others. CDNs are deployed to assist these services
		through localizing the content requests and therefore reducing
		latency and possibly
		increase
		increasing utilization of available bandwidth bandwidth, as well as
		reducing the load on origin servers. Similar to the previous sub-section,
		subsection, the underlay deployment
		configuration presented in <xref target ="sec:underlay" /> aim target="sec_underlay"
		format="default"/> aims at providing a migration path for
		existing
		CDNs. This is also highlighted in a BIER use case use-case document
		<xref target="I-D.ietf-bier-multicast-http-response" />,
		      format="default"/>, specifically with potential benefits
		in
		terms of utilizing multicast in the delivery of content but
		also reducing load on origin as well as and delegation server. servers. We
		return to this benefit in
		the trial experiences in <xref target="sec:trial_experiences" />. target="sec_trial_experiences"
		format="default"/>.
</t>
      </section>
      <section anchor="sec:edge_migration" title="Edge anchor="sec_edge_migration" numbered="true" toc="default">
        <name>Edge Network Migration"> Migration</name>
        <t>Edge networks often see the deployment of novel network level network-level
	technology, e.g., in the space of IoT. Such For many years, such
	IoT deployments have for many years relied,
		and often still do, on proprietary protocols for reasons reasons, such
		as increased efficiency, lack of standardization incentives incentives,
		and others.

		Utilizing the
		underlay deployment configuration in <xref target="sec:application_gateways" />,
		target="sec_application_gateways" format="default"/>,
		application gateways/proxies can integrate such edge
		deployments
		into IP-based services, e.g., utilizing CoAP CoAP-based <xref
		target="RFC7252" /> based format="default"/> M2M platforms platforms, such
		as oneM2M <xref target="oneM2M" /> format="default"/> or others.
</t>
        <t>Another area of increased edge network innovation is that of mobile
	(access) networks, particularly in the context of the 5G Mobile mobile
	networks.
		With the proliferation of network

	Network softwarization (using technologies like service
	orchestration frameworks leveraging NFV and SDN concepts) are
	now common in access networks and other network segments, segments.
	Therefore, the ICN-as-a-Slice deployment configuration in
	<xref target="sec:icn_slice" /> target="sec_icn_slice" format="default"/> provides a
	suitable migration path for the integration of non-IP-based
	edge networks into the overall system through by virtue of
	realizing the relevant (ICN) protocols in an access network
	slice.
</t>
        <t>With the advent of SDN and NFV capabilities, so-called campus or
	site-specific deployments could see the introduction of ICN islands at
	the edge for scenarios such as gaming or AR/VR-based deployments for, based on Augmented Reality
	(AR) / Virtual Reality (VR), e.g., smart cities or
	theme parks.</t>
      </section>
      <section anchor="sec:core_migration" title="Core anchor="sec_core_migration" numbered="true" toc="default">
        <name>Core Network Migration"> Migration</name>
        <t>Migrating core networks of the Internet or Mobile mobile networks requires
	not only significant infrastructure renewal but also the fulfillment
		of the key performance requirements, particularly in terms of
		throughput. For those parts of the core network that would
		migrate to an
		SDN-based optical transport transport, the ICN-as-a-Slice deployment
		configuration in <xref target="sec:icn_slice" /> target="sec_icn_slice"
		format="default"/>  would allow the introduction
		of native ICN solutions within slices. This would allow for
		isolating the ICN traffic while addressing the specific ICN
		performance benefits,
		such benefits
		(such as in-network multicast or caching, caching) and constraints, such constraints (such
		as the need for specific network elements within such isolated slices.
		slices).
		For ICN solutions that natively work on top of SDN, the
		underlay deployment configuration in <xref target="sec:http_ip" />
		target="sec_http_ip" format="default"/> provides an
		additional migration path, preserving the IP-based services
		and applications at the edge of the network, network while realizing
		the core network
		routing through an ICN solution (possibly itself realized in a
		slice of the SDN transport network).
</t>
      </section>
    </section>
    <section anchor="sec:trial_experiences" title="Deployment anchor="sec_trial_experiences" numbered="true" toc="default">
      <name>Deployment Trial Experiences"> Experiences</name>
      <t>In this section, we will outline trial experiences, often conducted
      within collaborative project efforts. Our focus here is on the
      realization
		of the various deployment configurations identified in <xref target="sec:configurations" />, and
		target="sec_configurations" format="default"/>; therefore, we therefore
		categorize the trial experiences according
		to these deployment configurations. While a large body of
		work exists at the simulation or emulation level, we
		specifically exclude these studies
		from our analysis to retain the focus on real life real-life
		experiences.
</t>
      <section anchor="sec:overlay_deployment" title="ICN-as-an-Overlay">

    <section anchor="sec:pursuit" title="FP7 anchor="sec_overlay_deployment" numbered="true" toc="default">
        <name>ICN-as-an-Overlay</name>
        <section anchor="sec_pursuit" numbered="true" toc="default">
          <name>FP7 PURSUIT Efforts"> Efforts</name>
          <t>Although the FP7 PURSUIT <xref target="IEEE_Communications" />
	  format="default"/> efforts were generally positioned as a
	  Clean-slate ICN replacement of IP
		(<xref target="sec:replacements" />), target="sec_replacements" format="default"/>), the
		project realized its experimental test bed testbed as an L2 VPN-based
		overlay between several European, US
		as well as US,
		and Asian sites, following the overlay deployment
		configuration presented in <xref target="sec:overlay" />. target="sec_overlay"
		format="default"/>. Software-based forwarders were
		utilized for the ICN message exchange, while native ICN applications, e.g.,
		applications (e.g., for video transmissions, transmissions) were
		showcased. At the height of the project
		efforts, about 70+ nodes were active in the (overlay) network
		with presentations given at several conferences conferences, as well as to
		the ICNRG.
</t>
        </section>
        <section anchor="sec:sail" title="FP7 anchor="sec_sail" numbered="true" toc="default">
          <name>FP7 SAIL Trial"> Trial</name>
          <t> The Network of Information (NetInf) is the approach to ICN
	  developed by the EU FP7 SAIL Scalable and Adaptive Internet Solutions
	  (SAIL) project <xref target="SAIL" />. format="default"/>.
		NetInf provides both name-based forwarding with CCNx-like
		semantics and name resolution (for indirection and late-binding).
		late binding).
		The NetInf architecture supports different deployment options
		through its convergence layer layer, such as using UDP, HTTP, and
		even DTN underlays.
		In its first prototypes	and trials, NetInf was deployed mostly
		in an HTTP embedding and in a UDP overlay following the
		overlay deployment configuration in
		<xref target="sec:overlay" />. Reference target="sec_overlay" format="default"/>. <xref
		target="SAIL_Prototyping" /> format="default"/> describes several trials
		trials, including a stadium environment and
		a multi-site testbed, leveraging NetInf’s Routing Hint NetInf's routing hint
		approach for routing scalability <xref
		target="SAIL_Content_Delivery" />. format="default"/>.

</t>
        </section>
        <section anchor="sec:ndn" title="NDN Testbed"> anchor="sec_ndn" numbered="true" toc="default">
          <name>NDN Testbed</name>
          <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
	  Future
		Internet Architecture (FIA) Program. The original NDN
		proposal was positioned as a Clean-slate ICN replacement of IP
		(<xref target="sec:replacements" />). target="sec_replacements" format="default"/>).
		However, in several trials, NDN generally follows the overlay
		deployment configuration of <xref target="sec:overlay" /> target="sec_overlay"
		format="default"/> to connect institutions over
		the public Internet across several continents. The use cases
		covered in the trials include real-time video-conferencing, geo-locating, videoconferencing,
		geolocating, and interfacing
		to consumer applications. Typical trials involve up to 100 NDN enabled
		NDN-enabled nodes <xref target="NDN-testbed" />
		format="default"/> <xref target="Jangam" />. format="default"/>.
</t>
        </section>
        <section anchor="sec:ccn" title="ICN2020 Efforts"> anchor="sec_ccn" numbered="true" toc="default">
          <name>ICN2020 Efforts</name>
          <t>ICN2020 is an ICN related ICN-related project of the EU H2020 research
	  program and NICT <xref target="ICN2020-overview" />. format="default"/>.
		ICN2020 has a specific focus to advance ICN towards real-world
		deployments through applications applications, such as video delivery,
		interactive videos videos, and social
		networks. The federated testbed spans the USA, Europe Europe, and
		Japan. Both NDN and CCN CCNx approaches are within the scope of the
		project.
</t>
          <t>ICN2020 has released a set of interim public technical reports <xref target="ICN2020" />. reports.
		The report <xref target="ICN2020-Experiments" />
		format="default"/> contains a detailed description of the
		progress made in both local
		testbeds as well as and federated testbeds. The plan for the
		federated testbed includes integrating the NDN testbed,
		the CUTEi testbed <xref target="RFC7945" /> format="default"/>
		<xref target="CUTEi" /> format="default"/>, and the GEANT testbed
		<xref target="GEANT" /> format="default"/>
		to create an overlay deployment configuration of <xref target="sec:overlay" />
		target="sec_overlay" format="default"/> over the public
		Internet. The total
		network contains 37 nodes. Since video was an important application
		application, typical throughput was measured in certain
		scenarios and found to be in the order of 70 Mbps per node.
</t>
        </section>
        <section anchor="sec:umobile" title="UMOBILE Efforts"> anchor="sec_umobile" numbered="true" toc="default">
          <name>UMOBILE Efforts</name>
          <t>UMOBILE is another of the ICN research projects under the H2020
	  research program <xref target="UMOBILE-overview" />.
	  format="default"/>.
		The UMOBILE architecture integrates the principles of DTN and
		ICN in a common framework to support edge computing and
		mobile opportunistic wireless environments (e.g.,
		post-disaster scenarios and remote areas). The UMOBILE
		architecture
		<xref target="UMOBILE-2" /> format="default"/> was developed on
		top of the NDN framework by following the overlay deployment
		configuration of
		<xref target="sec:overlay" />. target="sec_overlay" format="default"/>. UMOBILE aims to
		extend Internet functionally by combining ICN and DTN
		technologies.
</t>
          <t>One of the key aspects of UMOBILE was the extension of the NDN
	  framework to locate network services (e.g., mobility management, management and
		intermittent connectivity support) and user services (e.g.,
		pervasive content management) as close as possible to the end-users
		end users to optimize bandwidth
		utilization and resource management. Another aspect was the
		evolution of the NDN framework to operate in challenging
		wireless networks, namely in emergency
		scenarios <xref target="UMOBILE-3" /> format="default"/> and
		environments with intermittent connectivity. To achieve this,
		the NDN framework was leveraged with a
		new messaging application called Oi! <xref target="UMOBILE-4" />
		format="default"/> <xref target="UMOBILE-5" /> that format="default"/>,
		which supports intermittent wireless networking.
		UMOBILE also implements a new data-centric wireless routing
		protocol, DABBER <xref target="UMOBILE-6" /> format="default"/>
		<xref target="I-D.mendes-icnrg-dabber" />, format="default"/>,
		which was
		designed based on data reachability metrics that take into consideration
		availability of adjacent wireless nodes and different data
		sources.
		sources into consideration. The contextual-awareness contextual awareness of the
		wireless network operation is obtained via a machine learning machine-learning
		agent running within the wireless nodes <xref
		target="UMOBILE-7" />. format="default"/>.

</t>
          <t>The consortium has completed several ICN deployment trails. trials. In a post disaster
	  post-disaster scenario trial <xref target="UMOBILE-8" />,
	  format="default"/>,
		a special DTN face was created to provide reachability to
		remote areas where there is no typical Internet
		connection. Another trail trial was the ICN deployment over the
		"Guifi.net" community network in the Barcelona region. This
		trial
		focused on the evaluation of an ICN edge computing platform,
		called PiCasso <xref target="UMOBILE-9" />. format="default"/>. In
		this
		trial, ten (10) raspberry Raspberry Pis were deployed across Barcelona
		to create an ICN overlay network on top of the existing IP
		routing protocol
		(e.g., qMp routing). This trial showed that ICN can play a key
		role in improving data delivery QoS as well as and
		reducing the traffic in intermittent connectivity environments
		(e.g., wireless community network). A third trial in Italy was
		focused
		on displaying the capability of the UMOBILE architecture to
		reach disconnected areas and assist responsible authorities in
		emergencies,
		corresponding to an infrastructure scenario. The demonstration
		encompassed seven (7) end-user devices, one (1) access-point, access point,
		and one (1) gateway.
</t>
        </section>
      </section>
      <section anchor="sec:underlay_deployment" title="ICN-as-an-Underlay">

    <section anchor="sec:point_rife" title="H2020 anchor="sec_underlay_deployment" numbered="true" toc="default">
        <name>ICN-as-an-Underlay</name>
        <section anchor="sec_point_rife" numbered="true" toc="default">
          <name>H2020 POINT and RIFE Efforts"> Efforts</name>
          <t>POINT and RIFE are two more ICN related ICN-related research projects of the
	  H2020 research program.
		The efforts in the H2020 POINT+RIFE POINT and RIFE projects follow the
		underlay deployment configuration in
		<xref target="sec:http_ip" />, target="sec_http_ip" format="default"/>; edge-based NAPs
		provide the IP/HTTP-level protocol mapping onto
		ICN protocol exchanges, while the SDN underlay (or the
		VPN-based L2 underlay) is used as a transport network.
</t>
          <t>The multicast as well as and service endpoint surrogate benefits benefit in
	  HTTP-based scenarios, such as for
		HTTP-level streaming video delivery, and have been demonstrated in
		the deployed POINT test bed testbed with
		80+ nodes being utilized. Demonstrations of this capability
		have been given to the ICNRG,
		and public demonstrations were also provided at events <xref
		target="MWC_Demo" />. format="default"/>. The trial has also been
		accepted by the ETSI MEC
		group as a public proof-of-concept demonstration.
</t>
          <t>While the afore-mentioned aforementioned demonstrations all use the overlay
	  deployment, H2020 also has performed ICN underlay trials. One such
		trial involved commercial end users located in the Primetel PrimeTel
		network in Cyprus with the use case centered on IPTV and HLS
		video
		dissemination. Another trial was performed over the
		"Guifi.net" community network in the Barcelona region, where
		the solution
		was deployed in 40 households, providing general Internet
		connectivity to the residents. Standard IPTV STBs Set-Top
		Boxes(STBs), as well as HLS video
		players
		players, were utilized in accordance with the aim of this
		deployment configuration, namely to provide application and
		service migration.
</t>
        </section>
        <section anchor="sec:flame" title="H2020 anchor="sec_flame" numbered="true" toc="default">
          <name>H2020 FLAME Efforts"> Efforts</name>
          <t>The H2020 FLAME Facility for Large-Scale Adaptive Media Experimentation
	  (FLAME) efforts concentrate on providing an experimental
	  ground for the aforementioned POINT/RIFE
		solution in initially two city-scale locations, namely in
		Bristol and Barcelona. This trial followed the
		underlay deployment configuration in <xref target="sec:http_ip" />
		target="sec_http_ip" format="default"/>, as per the POINT/RIFE
		approach.  Experiments
		were conducted with the city/university joint venture
		Bristol-is-Open (BIO), (BIO) to ensure the readiness of the
		city-scale SDN transport network for such experiments. Another
		trial was for the ETSI MEC PoC. This trial
		showcased operational benefits provided by the ICN underlay
		for the scenario of a location-based game. These
		benefits aim at reduced network utilization through improved
		video delivery performance
		(multicast of all captured videos to the service surrogates
		deployed in the city at six locations) locations),
		as well as reduced latency through the playout play out of the video
		originating from the local NAP, collocated with the
		WiFi AP
		Wi-Fi Access Point (AP) instead of a remote server, i.e., the playout latency
		was bounded by the maximum single hop single-hop latency.
</t>
          <t> Twenty three (23) large-scale media service experiments are
	  planned as part of the H2020 FLAME efforts
		in the area of Future Media Internet (FMI). The platform,
		which includes the ICN capabilities capabilities, integrated with NFV
		and SDN capabilities of the infrastructure. The ultimate goal
		of these platform efforts is the full
		integration of ICN into the overall media function platform
		for the provisioning of advanced
		(media-centric) Internet services.
</t>
        </section>
        <section anchor="sec:cablelabs" title="CableLabs anchor="sec_cablelabs" numbered="true" toc="default">
          <name>CableLabs Content Delivery System"> System</name>
          <t>The Cablelabs CableLabs ICN work reported in <xref target="White" />
	  format="default"/> proposes an underlay deployment configuration
	  based on <xref target="sec:http_ip" />. target="sec_http_ip" format="default"/>.
		The use case is ICN for content distribution within complex
		CDN server farms to leverage ICN's superior in-network caching
		properties.
		This CDN based on "island of ICN" based CDN is then used to service
		standard HTTP/IP-based content retrieval request requests coming from
		the general Internet.
		This approach acknowledges that whole scale replacement (see
		<xref target="sec:replacements" />) target="sec_replacements" format="default"/>) of
		existing HTTP/IP end user end-user applications
		and related Web web infrastructure is a difficult proposition.
		<xref target="White" /> format="default"/> is clear that the
		architecture proposed had has not yet
		been tested experimentally but that implementations were are in
		process and expected in the 3-5 year time frame.
</t>
        </section>
        <section anchor="sec:NDN_IoT" title="NDN anchor="sec_NDN_IoT" numbered="true" toc="default">
          <name>NDN IoT Trials"> Trials</name>
          <t><xref target="Baccelli" /> format="default"/> summarizes the trial
	  of an NDN system adapted specifically for a wireless IoT scenario.
	  The trial was run with
		60 nodes distributed over several multi-story multistory buildings in a
		university campus environment. The NDN protocols were
		optimized to run directly
		over 6LoWPAN wireless link layers. The performance of the NDN based
		NDN-based IoT system was then compared to an equivalent system
		running standard IP
		based IP-based IoT protocols. It was found that
		the NDN based NDN-based IoT
		system was superior in several respects respects, including in terms of
		energy consumption, consumption and
		for RAM and ROM footprints <xref target="Baccelli" />
		format="default"/> <xref target="Anastasiades" />.
		format="default"/>. For example, the binary file size
		reductions for
		NDN protocol stack versus standard IP based IP-based IoT protocol stack
		on given devices were up to 60% less for ROM size and up to
		80% less for RAM size.

</t>
        </section>
        <section anchor="sec:NREN" title="NREN anchor="sec_NREN" numbered="true" toc="default">
          <name>NREN ICN Testbed"> Testbed</name>
          <t>The National Research and Education Network (NREN) ICN Testbed is
	  a project sponsored by Cisco, Internet2, and the US Research and
	  Education
		community. Participants include universities and US federal
		government entities that connect via a nation-wide nationwide VPN-based
		L2 underlay. The testbed
		uses the CCN CCNx approach and is based on the <xref target="CICN" /> open source
		format="default"/> open-source software. There are
		approximately 15 nodes spread across the USA which that
		connect to the testbed. The project's current focus is to
		advance data-intensive science and network research by
		improving data movement, searchability,
		and accessibility.

</t>
        </section>
        <section anchor="sec:Doctor" title="Doctor Testbed"> anchor="sec_Doctor" numbered="true" toc="default">
          <name>DOCTOR Testbed</name>
          <t>The Doctor DOCTOR project is a French research project meaning
	  "Deployment and Securisation of new Functionalities in Virtualized
	  Networking Environments".
		The project aims to run NDN over virtualized NFV
		infrastructure <xref target="Doctor" /> format="default"/> (based
		on Docker technology) and focuses on the NFV MANO aspects
		to build an operational NDN network focusing on important
		performance criteria criteria, such as security, performance performance, and
		interoperability.

</t>
          <t>The data-plane data plane relies on a an HTTP/NDN gateway <xref
	  target="Marchal" /> format="default"/> that processes HTTP traffic and
	  transports it in an optimized way over NDN to
		 benefit from the properties of the NDN-island NDN island (i.e., by
		 mapping HTTP semantics to NDN semantics within the NDN-island).
		 NDN island). The testbed carries
		 real Web traffic of users, users and has been currently evaluated
		 with the top-1000 top 1000 most popular Web sites. websites. The users only
		 need to set the gateway
		 as the Web web proxy. The control-plane control plane relies on a central
		 manager which that uses machine learning based machine-learning-based detection methods
		 <xref target="Mai-1" /> format="default"/>
		 from the date gathered by distributed probes and applies
		 orchestrated counter-measures countermeasures against NDN attacks <xref
		 target="Nguyen-1" /> format="default"/>
            <xref target="Nguyen-2" /> format="default"/> <xref target="Mai-2" />
	    format="default"/> or performance issues. A remediation can be,
	    for example, the scale-up scale up of a bottleneck
		 component,
		 component or the deployment of a security function function, like a
		 firewall or a signature verification module. Test results
		 thus far have indicated
		 that key attacks can be detected accurately. For example,
		 content poisioning poisoning attacks can be detected at up to over 95%
		 accuracy (with less than 0.01% false positives) <xref
		 target="Nguyen-3" />. format="default"/>.
</t>
        </section>
      </section>
      <section anchor="sec:Other_configs" title="Composite-ICN Approach"> 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, addresses and other ICN information
		is carried as payload inside the IP packet. This allows
		standard (ICN-unaware) IP routers to forward packets based on
		IPv6 info, info but enables ICN-aware
		routers to apply ICN semantics. The intent is to enable rapid
		hybrid deployments and seamless interconnection of IP and
		Hybrid ICN domains. Hybrid ICN
		uses <xref target="CICN" /> open source format="default"/> open-source
		software.

        Initial tests have been done with 150 clients consuming DASH videos videos,
which showed good scalability properties at the Server Side server side using the
	Hybrid ICN transport <xref target="H-ICN_3" /> format="default"/> <xref
	target="H-ICN_2" />.</t> format="default"/>.</t>
      </section>
      <section anchor="sec:trial_summary" title="Summary anchor="sec_trial_summary" numbered="true" toc="default">
        <name>Summary of Deployment Trials"> Trials</name>
        <t>In summary, there have been significant trials over the years with
	all the major ICN protocol flavors (e.g., CCN, CCNx, NDN, and POINT) using both
		the ICN-as-an-Overlay and ICN-as-an-Underlay deployment
		configurations. The major limitations of the trials include
		the fact that only a limited
		number of applications have been tested. However, the tested
		applications include both native ICN and existing IP based IP-based
		applications
		(e.g., video-conferencing videoconferencing and IPTV). Another limitation of
	the trials is that all of them involve less than 1k users.</t>

		<t>	The ICN-as-a-Slice configuration has just started being trialled by Huawei
        <t>Huawei and China Unicom have just started trials of the ICN-as-a-Slice configuration to demonstrate
		ICN features of security, mobility mobility, and bandwidth efficiency
		over a wired infrastructure using video conferencing videoconferencing
		as the application scenario <xref target="Chakraborti" />, also
		format="default"/>; also, this prototype has been extended to
	demonstrate this over a 5G-NR access.</t>
        <t>The Clean-slate ICN approach has obviously never been trialled in trials, as
	complete replacement of Internet
		infrastructure (e.g., existing applications, TCP/IP protocol
	stack, IP routers, etc.) is no longer considered a viable
	alternative.</t>
        <t>Finally, Hybrid ICN is a Composite-ICN approach that offers an
	interesting alternative alternative, as it allows ICN semantics to be embedded in
	standard
		IPv6 packets so the packets can be routed through either IP
		routers or Hybrid ICN routers. Note that some other trials trials,
		such as the
		Doctor
		DOCTOR testbed (<xref target="sec:Doctor" />) target="sec_Doctor" format="default"/>),
		could also be characterized as a Composite-ICN approach approach,
		because it contains both ICN gateways
		(as in ICN-as-an-Underlay) and virtualized infrastructure (as
		in ICN-as-a-Slice). However, for the Doctor testbed DOCTOR testbed, we have
		chosen to characterize
		it as an ICN-as-an-Underlay configuration because that is a
		dominant characteristic.
</t>
      </section>
    </section>
    <section anchor="sec:standards" title="Deployment anchor="sec_standards" numbered="true" toc="default">
      <name>Deployment Issues Requiring Further Standardization">

        <t>The ICN Research Challenges <xref Standardization</name>
      <t><xref target="RFC7927" />
      format="default">"Information-Centric Networking (ICN) Research Challenges"</xref>
      describes key ICN principles and technical research topics. As the
      title suggests,
		<xref target="RFC7927" /> format="default"/> is research oriented
		without a specific focus on deployment or standardization
		issues. This section addresses this
		open area by identifying key protocol functionality that that
		may be relevant for further standardization effort in
		the IETF.
		The focus is specifically
		on identifying protocols that will facilitate future
		interoperable ICN deployments correlating to the scenarios
		identified in the deployment
		migration paths in <xref target="sec:migration" />. target="sec_migration"
		format="default"/>. The identified list of potential protocol
		functionality is not exhaustive.

</t>
      <section anchor="sec:standards_apps" title="Protocols anchor="sec_standards_apps" numbered="true" toc="default">
        <name>Protocols for Application and Service Migration">

        <t>End user Migration</name>
        <t>End-user applications and services need a standardized approach to
	trigger ICN transactions. For example, in Internet and Web web
	applications
		today, there are established socket APIs, communication
		paradigms such (such as REST, REST), common libraries, and best
		practices. We see a need to study
		application requirements in an ICN environment further and, at
		the same time, develop new APIs and best practices that can
		take advantage of ICN
		communication characteristics.

</t>
      </section>
      <section anchor="sec:standards_cdn" title="Protocols anchor="sec_standards_cdn" numbered="true" toc="default">
        <name>Protocols for Content Delivery Network Migration"> 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="I-D.irtf-icnrg-ccnxmessages" /> target="RFC8609" format="default"/> and
		<xref target="I-D.irtf-icnrg-ccnxsemantics" />. target="RFC8569" format="default"/>. Naming dynamically
		generated data requires different approaches (e.g., hash digest
		based approaches(e.g.,
		hash-digest-based names would normally not work), and there is
		a lack of established conventions and standards.

        </t>
        <t>Another CDN issue for ICN is related to multicast distribution of
	content.
                Existing CDNs have started using multicast mechanisms for
		certain cases cases, such as for broadcast broadcasting streaming TV.  However, as
		discussed in <xref target="sec:point_rife" />, target="sec_point_rife" format="default"/>,
		certain ICN approaches provide
		substantial improvements over IP multicast, such as the
		implicit support for multicast retrieval of content in all ICN flavours.
		flavors.
</t>
        <t>Caching is an implicit feature in many ICN architectures that can
	improve performance and availability in several scenarios. The ICN
		in-network caching can augment managed CDN and improve its
		performance. The details of the interplay between ICN caching
		and managed CDN need further consideration.

</t>
      </section>
      <section anchor="sec:standards_edge_core" title="Protocols anchor="sec_standards_edge_core" numbered="true" toc="default">
        <name>Protocols for Edge and Core Network Migration"> Migration</name>
        <t>ICN provides the potential to redesign current edge and core
	network computing approaches. Leveraging ICN’s ICN's inherent security and
	its ability
		to make name data and dynamic computation results available
		independent of location, location can enable a light-weight lightweight insertion
		of traffic
		into the network without relying on redirection of DNS
		requests. For this, proxies that translate from commonly used
		protocols in the general
		Internet to ICN message exchanges in the ICN domain could be
		used for the migration of application and services within
		deployments at the network
		edge but also in core networks. This is similar to existing
		approaches for IoT scenarios where a proxy translates CoAP
		request/responses to other
		message formats. For example, <xref target="RFC8075" />
		format="default"/> specifies proxy mapping between CoAP and
		HTTP protocols. Also, <xref target="RFC8613" />
		format="default"/>
		is an example of how to pass end-to-end encrypted content
		between HTTP and COAP CoAP by an application layer application-layer security
		mechanism. Further work is required
		to identify if an approach like <xref target="RFC8613" />-like approach,
		format="default"/>, or some other approach, is
		suitable to preserve ICN message security through future
		protocol
		translation functions of gateways/proxies.
</t>
        <t>Interaction and interoperability between existing IP routing
	protocols (e.g., OSPF, RIP, ISIS) or IS-IS) and ICN routing approaches(e.g., NFD, CCN
	approaches (e.g.,
	NFD and CCNx routers)
		are expected expected, especially in the overlay approach. Another
		important topic is the integration of ICN into networks that
		support virtualized infrastructure
		in the form of NFV/SDN and most likely utilizing utilize SFC as a key
		protocol. Further work is required to validate this idea and
		document best practices.
</t>
        <t>There are several existing approaches to supporting QoS in IP networks
	networks, including DiffServ, IntServ Diffserv, IntServ, and RSVP. Some initial ideas
	for QoS support in ICN
		networks are outlined in <xref
		target="I-D.moiseenko-icnrg-flowclass" /> format="default"/>,
		which proposes a an approach based on flow
		classification based approach to enable functions
		functions, such ICN
		rate control and cache control.  Also Also, <xref
		target="I-D.anilj-icnrg-icn-qos" /> format="default"/> proposes
		how to use DiffServ DSCP Diffserv Differentiated Services Code Point (DSCP)
		codes to support QoS for ICN based ICN-based data
		path delivery. Further work is required to identify the best
		approaches for support of QoS in ICN networks.
</t>
        <t>OAM is a crucial area that has not yet been fully addressed by the
	ICN research community, community but which is obviously critical for future
	deployments of ICN.
	  Potential areas that need investigation include whether the YANG
	  data modelling modeling approach and associated NETCONF/RESTCONF protocols
	  need any specific updates
	  for ICN support. Another open area is how to measure and benchmark
	  performance of ICN networks comparable to the sophisticated
	  techniques that exist for standard
	  IP networks, virtualized networks networks, and data centers. It should be
	  noted that some initial progress has been made in the area of ICN
	  network path traceroute
	  facility with approaches approaches, such as CCNinfo CCNxinfo <xref
	  target="I-D.irtf-icnrg-ccninfo" /> format="default"/> <xref
	  target="Contrace" />. format="default"/>.
</t>
      </section>
      <section anchor="sec:ICN_Challenges_Summary_Gaps"
             title="Summary anchor="sec_ICN_Challenges_Summary_Gaps" numbered="true" toc="default">
        <name>Summary of ICN Protocol Gaps and Potential Protocol Efforts"> Efforts</name>
        <t>Without claiming completeness, <xref target="tab:mapping_protocol_effort"/>
	target="tab_mapping_protocol_effort" format="default"/> maps the open
	ICN issues identified in this document to potential protocol efforts
	that could address some aspects of the gap.
</t>

        <texttable anchor="tab:mapping_protocol_effort"
                   title="Mapping
        <table anchor="tab_mapping_protocol_effort" align="center">
          <name>Mapping of ICN Gaps to Potential Protocol Efforts">
          <ttcol Efforts</name>
          <thead>
            <tr>
              <th align="left">ICN Gap</ttcol>
          <ttcol Gap</th>
              <th align="left">Potential Protocol Effort</ttcol>
            <c>1-Support of</c>
			  <c>HTTP/CoAP Effort</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">1-Support of REST APIs</td>
              <td align="left">HTTP/CoAP support of ICN semantics</c>
		    <c>REST APIs</c>
              <c> </c>
		    <c> </c>
              <c> </c>

            <c>2-Naming</c>
              <c>Dynamic semantics</td>
            </tr>
            <tr>
              <td align="left">2-Naming</td>
              <td align="left">Dynamic naming of ICN data objects</c>
            <c> </c>
              <c> </c>

            <c>3-Routing</c>
              <c>Interactions objects</td>
            </tr>
            <tr>
              <td align="left">3-Routing</td>
              <td align="left">Interactions between IP and ICN routing protocols</c>
            <c> </c>
              <c> </c>

            <c>4-Multicast</c>
              <c>Multicast protocols</td>
            </tr>
            <tr>
              <td align="left">4-Multicast distribution</td>
              <td align="left">Multicast enhancements for ICN</c>
            <c>distribution</c>
              <c> </c>
		    <c> </c>
              <c> </c>

            <c>5-In-network</c>
              <c>ICN Cache ICN</td>
            </tr>
            <tr>
              <td align="left">5-In-network caching</td>
              <td align="left">ICN cache placement and sharing</c>
            <c>caching</c>
              <c> </c>
		    <c> </c>
              <c> </c>

            <c>6-NFV/SDN</c>
              <c>Integration sharing</td>
            </tr>
            <tr>
              <td align="left">6-NFV/SDN support</td>
              <td align="left">Integration of ICN with NFV/SDN and including</c>
            <c>support</c>
              <c>possible including
	      possible impacts to SFC</c>
		    <c> </c>
              <c> </c>

            <c>7-ICN</c>
              <c>Mapping SFC</td>
            </tr>
            <tr>
              <td align="left">7-ICN mapping</td>
              <td align="left">Mapping of HTTP and other protocols onto ICN</c>
            <c>mapping</c>
			  <c>message ICN
	      message exchanges (and vice-versa) vice versa) while preserving ICN message security</c>
		    <c> </c>
              <c> </c>

            <c>8-QoS</c>
              <c>Support
	      security</td>
            </tr>
            <tr>
              <td align="left">8-QoS support</td>
              <td align="left">Support of ICN QoS via mechanisms mechanisms, such as DiffServ</c>
            <c>support</c>
			  <c>
	      Diffserv and flow classification </c>
		    <c> </c>
              <c> </c>

            <c>9-OAM</c>
              <c>YANG classification</td>
            </tr>
            <tr>
              <td align="left">9-OAM support</td>
              <td align="left">YANG data models, NETCONF/RESTCONF protocols,</c>
            <c>support</c>
			  <c> protocols, and network performance measurements </c>
		    <c> </c>
              <c> </c>

        </texttable>
	      network-performance measurements</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="sec:conclusion" title="Conclusion"> anchor="sec_conclusion" numbered="true" toc="default">
      <name>Conclusion</name>
      <t>This document provides high level high-level deployment considerations for
      current and future members of the ICN community. Specifically, the
	  major configurations of possible ICN deployments are identified as
	  (1) Clean-slate ICN replacement of existing Internet infrastructure; infrastructure,
	  (2) ICN-as-an-Overlay; ICN-as-an-Overlay, (3) ICN-as-an-Underlay; ICN-as-an-Underlay, (4) ICN-as-a-Slice; ICN-as-a-Slice,
	  and (5) Composite-ICN. Existing ICN trial systems primarily fall
	  under the ICN-as-an-Overlay, ICN-as-an-Underlay ICN-as-an-Underlay, and Composite-ICN
	  configurations.
      </t>
      <t>In terms of deployment migration paths, ICN-as-an-Underlay offers a
      clear migration path for CDN, edge edge, or core networks to go to an
	  ICN paradigm (e.g., for an IoT deployment) while leaving the
	  critical mass of existing end user end-user applications untouched.
	  ICN-as-an-Overlay is
	  the easiest configuration to deploy rapidly rapidly, as it leaves the
	  underlying IP infrastructure essentially untouched. However, its
	  applicability for general deployment must be considered on a case by case basis (e.g.,
	  case-by-case basis. (That is, can it support all required user applications).
	  applications?).
	  ICN-as-a-Slice is an attractive deployment option for up coming upcoming 5G
	  systems (i.e., for 5G radio and core networks) which that will naturally
	  support network slicing, but this still has to be validated through
	  more trial experiences. Composite-ICN, by its nature, can combine
	  some of the best characteristics of the other configurations, but
	  its applicability for general deployment must again be considered
	  on a case by case case-by-case basis (e.g., (i.e., can enough IP routers be upgraded to
	  support Composite-ICN functionality to provide sufficient
	  performance benefits). benefits?).
      </t>
      <t>There has been significant trial experience with all the major ICN
      protocol flavors (e.g., CCN, CCNx, NDN, and POINT). However, only a limited
	  number of applications have been tested so far, and the maximum
	  number of users in any given trial has been less than 1k users. It
	  is
	  recommended that future ICN deployments scale their users gradually
	  and closely monitor network performance as they go above 1k users.
	  A logical approach would be to increase the number of users in a
	  slowly increasing linear manner and monitor network performance and
	  stability
	  stability, especially at every multiple of 1k users.
      </t>
      <t>Finally, this document describes a set of technical features in ICN
      that warrant potential future IETF specification work. This will
	  aid initial and incremental deployments to proceed in an
	  interoperable manner. The fundamental details of the potential
	  protocol specification
	  effort, however, are best left for future study by the appropriate
	  IETF WGs and/or BoFs. The ICNRG can aid this process in the
	  near and mid-term by continuing to examine key system issues like
	  QoS mechanisms, flexible naming schemes schemes, and OAM support for ICN.
      </t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document requests has no IANA actions.
      </t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>ICN was purposefully designed from the start to have certain
      intrinsic security properties. The most well known of which are
      authentication
	  of delivered content and (optional) encryption of the content. <xref
	  target="RFC7945" /> format="default"/> has an extensive discussion of
	  various aspects of ICN security security,
	  including many which that are relevant to deployments. Specifically,
	  <xref target="RFC7945" /> format="default"/> points out that ICN access
	  control, privacy, security
	  of in-network caches, and protection against various network attacks
	  (e.g., DoS) have not yet been fully developed due to the lack of a
	  sufficient
	  mass of deployments.  <xref target="RFC7945" /> format="default"/> also
	  points out relevant advances occurring in the ICN research community
	  that hold promise to address
	  each of the identified security gaps. Lastly, <xref
	  target="RFC7945" /> format="default"/> points out that as secure
	  communications in the existing Internet (e.g., HTTPS)
	  becomes
	  become the norm, that major gaps in ICN security will inevitably
	  slow down the adoption of ICN.
      </t>
      <t>In addition to the security findings of <xref target="RFC7945" />,
      format="default"/>, this document has highlighted that all anticipated
      ICN deployment configurations
	  will involve co-existence coexistence with existing Internet infrastructure and
	  applications.  Thus Thus, even the basic authentication and encryption
	  properties of ICN
	  content will need to account for interworking with non-ICN content
	  to preserve end-to-end security. For example, in the edge network
	  underlay deployment
	  configuration described in <xref target="sec:application_gateways" />, target="sec_application_gateways"
	  format="default"/>, the gateway/proxy that translates HTTP or CoAP
	  request/responses into ICN message
	  exchanges will need to support a security model to preserve
	  end-to-end security. One alternative would be to consider an
	  approach similiar similar to
	  <xref target="RFC8613" /> format="default"/>, which is used to pass
	  end-to-end encrypted content between HTTP and COAP CoAP by an application layer
	  application-layer security mechanism. Further
	  investigation is required to see if this approach is suitable to
	  preserve ICN message security through future protocol translation
	  functions (e.g., ICN to HTTP, HTTP or COAP CoAP to ICN) of gateways/proxies.
      </t>
      <t>Finally, the Doctor DOCTOR project discussed in <xref target="sec:Doctor" /> target="sec_Doctor"
      format="default"/> is an example of an early deployment that is looking
      at specific attacks against
	  ICN infrastructure.  In infrastructure, in this case, looking at Interest Flooding
	  Attacks <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 evaluation of evaluating potential counter-measures countermeasures based
	on MANO orchestrated MANO-orchestrated actions on the virtualized infrastructure <xref
	target="Mai-1" /> .
	  </t>

    </section>

    <section anchor="Acknowledgments" title="Acknowledgments">

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

	  <t>Special thanks to Dave Oran (ICNRG co-chair) and Marie-Jose Montpetit for their extensive and thoughtful reviews of the document.  Their reviews helped
	  to immeasurably improve the document quality.</t>
    </section>
  </middle>
  <back>

<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"/>

<references>
      <name>Informative References</name>

      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7927.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6920.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8075.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7945.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7426.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8613.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8609.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8569.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8568.xml"/>
<!-- Example
    <references title="Normative References">
	  &I-D.ietf-core-http-mapping;
    </references> 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 -->
    <references title="Informative References">
      <!---->
      &rfc7927;
	  &rfc7252;
	  &rfc7665;
	  &rfc6920;
	  &rfc8075;
	  &rfc7945;
	  &rfc7426;
	  &rfc8613;

	  &I-D.ietf-bier-multicast-http-response;
	  &I-D.irtf-nfvrg-gaps-network-virtualization;
	  &I-D.irtf-icnrg-icniot;
	  &I-D.irtf-icnrg-ccnxmessages;
	  &I-D.irtf-icnrg-terminology;
	  &I-D.irtf-icnrg-icn-lte-4g;
	  &I-D.irtf-icnrg-ccninfo;
	  &I-D.irtf-icnrg-ccnxsemantics;

	  &I-D.paik-icn-deployment-considerations;
	  &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/Deliverables/FP7-INFSO-ICT-216173-PSIRP-D4.6_FinalReportOnDeplIncBusinessModels.pdf"> anchor='I-D.irtf-icnrg-icn-lte-4g'>
<front>
          <title>Final Evaluation Report on
<title>Native Deployment Incentives and Business Models</title> of ICN in LTE, 4G Mobile Networks</title>
<author initials="J." surname="Tateson" initials='P' surname='Suthar' fullname='Prakash Suthar'>
    <organization />
</author>
<author initials="" surname="et al." initials='M' surname='Stolic' fullname='Milan Stolic'>
    <organization />
          <date year="2010"/>
        </front>
      </reference>

      <reference anchor="Jacobson">
        <front>
          <title>Networking Named Content</title>
</author>
<author initials="V." surname="Jacobson" initials='A' surname='Jangam' fullname='Anil Jangam' role="editor">
    <organization />
</author>
<author initials="" surname="et al." initials='D' surname='Trossen' fullname='Dirk Trossen'>
    <organization />
          <date year="2009"/>
        </front>
</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>

<!-- 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-considerations-00' />

</reference>

<!-- draft-kutscher-icnrg-netinf-proto-01: Expired -->
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.kutscher-icnrg-netinf-proto.xml"/>
<!-- draft-ravi-icnrg-5gc-icn-04: Expired -->
<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>

<!-- draft-moiseenko-icnrg-flowclass-05: I-D Exists -->
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.moiseenko-icnrg-flowclass.xml"/>
<!-- draft-anilj-icnrg-icn-qos-00: Expired -->
<reference anchor='I-D.anilj-icnrg-icn-qos'>
<front>
<title>Supporting QoS aware Data Delivery in Information Centric Networks</title>
<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' />

</reference>

<!-- draft-mendes-icnrg-dabber-03: I-D Exists -->
    <xi:include
	href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.mendes-icnrg-dabber.xml"/>

      <reference anchor="Tateson" target="http://www.psirp.org/files/Deliverables/FP7-INFSO-ICT-216173-PSIRP-D4.6_FinalReportOnDeplIncBusinessModels.pdf">
        <front>
          <title>Final Evaluation Report on Deployment Incentives and Business Models</title>
          <author>
	  <organization>Tateson, J., et al.</organization>
          </author>
          <date month="May" year="2010"/>
        </front>
        <seriesInfo name="Version" value="1.0"/>
	<refcontent>PSIRP</refcontent>
      </reference>

      <reference anchor="Jacobson">
        <front>
          <title>Networking Named Content</title>
          <author>
            <organization>Jacobson, V., et al.</organization>
          </author>
          <date month="December" year="2009"/>
        </front>
        <seriesInfo name="Proceedings name="DOI" value="10.1145/1658939.1658941"/>
	<refcontent>CoNEXT '09: Proceedings of ACM Context," value=""/> the 5th international
	conference on Emerging networking experiments and technologies</refcontent>
      </reference>

     <reference anchor="fiveG-23501">
        <front>
          <title>Technical Specification Group Services and System Aspects; System
          <title>System Architecture for the 5G System (Rel.15)</title>
          <author initials="" surname="3gpp-23.501" /> System</title>
          <author>
            <organization>3GPP</organization>
          </author>
          <date month="December" year="2017"/>
        </front>
        <seriesInfo name="3GPP" value=""/> value="TS 23.501"/>
        <refcontent>Release 15</refcontent>
      </reference>

      <reference anchor="IEEE_Communications">
        <front>
          <title>Designing and Realizing realizing an Information-Centric Internet</title> information-centric internet</title>
          <author initials="D." surname="Trossen" /> fullname="Dirk Trossen">
	    <organization/>
          </author>
          <author initials="G." surname="Parisis" />
          <date year="2012"/> fullname="George Parisis">
	    <organization/>
          </author>
          <date/>
        </front>
        <seriesInfo name="Information-Centric Networking," value="IEEE name="DOI" value="10.1109/MCOM.2012.6231280"/>
	<refcontent>IEEE Communications Magazine Special Issue"/> Magazine, Volume 50, Issue 7</refcontent>
      </reference>

      <reference anchor="VSER">
        <front>
          <title>Towards software defined ICN based edge-cloud services</title>
          <author initials="R." surname="Ravindran" />
		  <author initials="" surname="et al." />
          <date year="IEEE Internation Conference on CloudNetworking(CloudNet), 2013"/>
          <author>
	    <organization>Ravindran, R., et al.</organization>
          </author>
          <date/>
        </front>
        <seriesInfo name="CloudNetworking(CloudNet)," value="IEEE Internation name="DOI" value="10.1109/CloudNet.2013.6710583"/>
	<refcontent>2013 IEEE 2nd International Conference on"/> on Cloud Networking (CloudNet)</refcontent>
      </reference>

      <reference anchor="VSER-Mob">
        <front>
          <title>Seamless Producer Mobility as a Service in Information-centric Networks</title>
          <author initials="A." surname="Azgin" />
		  <author initials="" surname="et al." />
          <author>
	  <organization>Azgin, A., et al.</organization>
	  </author>
          <date year="ACM ICN Sigcomm, IC5G Workshop,  2016"/> month="September" year="2016"/>
        </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 anchor="POINT">
        <front>
          <title>POINT: IP Over
          <title>IP over ICN - The Better better IP?</title>
          <author initials="D." surname="Trossen" />
		  <author initials="" surname="et al." />
          <author>
	    <organization>Trossen, D., et al.</organization>
	  </author>
          <date month="June" year="2015"/>
        </front>
        <seriesInfo name="European name="DOI" value="10.1109/EuCNC.2015.7194109"/>
	<refcontent>2015 European Conference on Networks and Communications (EuCNC)," value=""/> (EuCNC)</refcontent>
      </reference>

      <reference anchor="MWC_Demo" target="http://www.interdigital.com/download/56d5c71bd616f892ba001861">
        <front>
          <title>InterDigital Demo at Mobile World Congress (MWC)</title>
          <author initials="" surname="InterDigital" />
          <author><organization>InterDigital</organization>
          </author>
          <date year="2016"/>
        </front>
      </reference>

      <reference anchor="Reed">
        <front>
          <title>Stateless Multicast Switching multicast switching in Software Defined Networks</title>
          <author initials="M.J." surname="Reed" />
		  <author initials="" surname="et al." /> software defined networks</title>
          <author>
	    <organization>Reed, M., et al.</organization>
	  </author>
          <date month="May" year="2016"/>
        </front>
          <seriesInfo name="ICC 2016," value="Kuala Lumpur, Malaysia"/> name="DOI" value="10.1109/ICC.2016.7511036"/>
	  <refcontent>2016 IEEE International Conference on Communications (ICC)</refcontent>
      </reference>

      <reference anchor="White" target="http://www.cablelabs.com/wp-content/uploads/2016/02/Content-Delivery-with-Content-Centric-Networking-Feb-2016.pdf">
        <front>
          <title>Content Delivery with Content Centric Networking, CableLabs White Paper</title> Content-Centric Networking</title>
          <author initials="G." surname="White" /> fullname="Greg White">
	    <organization/>
          </author>
          <author initials="G." surname="Rutz" /> fullname="Greg Rutz">
	    <organization/>
	  </author>
          <date month="February" year="2016"/>
        </front>
      </reference>

      <reference anchor="Techno_Economic">
        <front>
          <title>Techno-Economics Aspects of Information-Centric Networking</title>
          <author initials="D." surname="Trossen" /> fullname="Dirk Trossen">
	    <organization/>
	  </author>
          <author initials="A." surname="Kostopolous" /> surname="Kostopoulos" fullname="Alexandros Kostopoulos">
	    <organization/>
	  </author>
          <date month="June" year="2012"/>
        </front>
        <seriesInfo name="Journal for Information Policy," value="Volume 2"/> Policy" value=""/>
	<refcontent>Volume 2</refcontent>
        <seriesInfo name="DOI" value="10.5325/jinfopoli.2.2012.0026"/>
      </reference>

      <reference anchor="Internet_Pricing">
        <front>
          <title>Not Paying paying the Truck Driver: Differentiated Pricing truck driver: differentiated pricing for the Future Internet</title> future internet</title>
          <author initials="D." surname="Trossen" />
		  <author fullname="Dirk Trossen">
	    <organization/>
	  </author>
          <author initials="G." surname="Biczok" /> fullname="Gergely Biczok">
	    <organization/>
	  </author>
          <date month="November" year="2010"/>
        </front>
	<seriesInfo name="ReArch Workshop in conjunction with ACM Context," value="December"/> '10:" value="Proceedings of the
	  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 anchor="oneM2M" target="http://www.onem2m.org/">
        <front>
          <title>oneM2M Service Layer Standards for M2M and IoT</title>
          <author initials="" surname="OneM2M" />
          <author><organization>OneM2M</organization>
          </author>
	  <date year="2017"/>
        </front>
      </reference>

      <reference anchor="ONAP" target="https://www.onap.org/">
        <front>
          <title>Open Network Automation Platform</title>
          <author initials="" surname="ONAP" />
          <date year="2017"/>
          <author><organization>ONAP</organization>
          </author>
        </front>
      </reference>

      <reference anchor="CONET" target="http://netgroup.uniroma2.it/Stefano_Salsano/papers/salsano-icc12-wshop-sdn.pdf">
        <front>
          <title>CONET Project: Supporting
          <title>Supporting Information-Centric Functionality in Software Defined Networks</title>
          <author initials="L." surname="Veltri" />
		  <author initials="" surname="et al." />
          <author>
	    <organization>Veltri, L., et al.</organization>
          </author>
	  <date month="November" year="2012"/>
        </front>
        <seriesInfo name="Workshop name="DOI" value="10.1109/ICC.2012.6364916"/>
	<refcontent>2012 IEEE International Conference on Software Defined Networks," value=""/> Communications (ICC)</refcontent>
      </reference>

      <reference anchor="C_FLOW" target="http://opennetsummit.org/archives/apr12/site/pdf/snu.pdf"> target="https://ieeexplore.ieee.org/document/6799480">
        <front>
          <title>C_FLOW: Content-Oriented Networking over
          <title>C_flow: An efficient content delivery framework with OpenFlow</title>
          <author initials="J." surname="Suh" />
		  <author initials="" surname="et al." />
          <author>
	    <organization>D. Chang, et al.</organization>
	  </author>
          <date year="2012"/> month="February" year="2014"/>
        </front>
        <seriesInfo name="Open
	<refcontent>The International Conference on Information
	Networking Summit," value="April"/> 2014 (ICOIN2014)</refcontent>
	<refcontent>pp. 270-275</refcontent>
	<seriesInfo name="DOI" value="10.1109/ICOIN.2014.6799480" />
      </reference>

      <reference anchor="H-ICN_1" target="http://blogs.cisco.com/sp/cisco-announces-important-steps-toward-adoption-of-information-centric-networking">
        <front>
          <title>Hybrid ICN: Cisco
          <title>Cisco Announces Important Steps toward Adoption of Information-Centric Networking</title>
          <author initials="" surname="Cisco" />
          <author>
	    <organization>Cisco</organization>
	  </author>
          <date month="February" year="2017"/>
        </front>
      </reference>

      <reference anchor="H-ICN_2" target="https://www.cisco.com/c/dam/en/us/solutions/collateral/service-provider/ultra-services-platform/mwc17-hicn-video-wp.pdf">
        <front>
          <title>Mobile Video Delivery with Hybrid ICN: IP-Integrated IP-integrated ICN Solution for 5G</title>
          <author initials="" surname="Cisco" />
          <date year="2017"/>
          <author>
	      <organization>Cisco</organization>
	  </author>
        </front>
      </reference>

      <reference anchor="CCNx_UDP" target="https://www.ietf.org/proceedings/interim-2015-icnrg-04/slides/slides-interim-2015-icnrg-4-5.pdf">
        <front>
          <title>CCNx Over UDP</title>
          <author initials="" surname="PARC" />
          <date year="2015"/>
          <author>
	    <organization>PARC</organization>
	  </author>
        </front>
      </reference>

      <reference anchor="SAIL_Prototyping" target="http://www.sail-project.eu/wp-content/uploads/2013/05/SAIL_DB4_v1.1_Final_Public.pdf">
        <front>
          <title>SAIL Prototyping
          <title>Prototyping and Evaluation</title>
          <author initials="" surname="FP7" />
          <author>
	    <organization>FP7</organization>
	  </author>
          <date month="March" year="2013"/>
        </front>
	<seriesInfo name="Objective" value="FP7-ICT-2009-5-257448/D.B.4"/>
      </reference>

      <reference anchor="DASH" target="http://dashif.org/">
        <front>
          <title>DASH Industry Forum</title>
          <author initials="" surname="DASH" />
          <date year="2017"/>
          <author>
	    <organization>DASH</organization>
	  </author>
        </front>
      </reference>

      <reference anchor="NGMN-5G" target="https://www.ngmn.org/fileadmin/ngmn/content/images/news/ngmn_news/NGMN_5G_White_Paper_V1_0.pdf"> target="https://www.ngmn.org/wp-content/uploads/NGMN_5G_White_Paper_V1_0.pdf">
        <front>
          <title>NGMN 5G
          <title>5G White Paper</title>
          <author initials="" surname="NGMN" />
          <author>
	    <organization>NGMN Alliance</organization>
	  </author>
          <date month="February" year="2015"/>
        </front>
      </reference>

      <reference anchor="Ravindran" target="https://arxiv.org/abs/1610.01182">
        <front>
          <title>5G-ICN : Delivering ICN Services over 5G using Network Slicing</title>
          <author initials="R." surname="Ravindran" />
		  <author initials="" surname="et al." />
          <author>
	    <organization>Ravindran, R., et al.</organization>
	  </author>
          <date year="IEEE Communication Magazine, May, 2016"/> month="October" year="2016"/>
        </front>
	<seriesInfo name="DOI" value="10.1109/MCOM.2017.1600938"/>
	<refcontent>IEEE Communications Magazine, Volume 55, Issue 5</refcontent>
      </reference>

      <reference anchor="Moiseenko" target="http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p112-moiseenko.pdf">
        <front>
          <title>TCP/ICN :
          <title>TCP/ICN: Carrying TCP over Content Centric and Named Data Networks</title>
          <author initials="I." surname="Moiseenko" /> fullname="Ilya Moiseenko">
	    <organization/>
	  </author>
          <author initials="D." surname="Oran" /> fullname="Dave Oran">
	    <organization/>
	  </author>
          <date month="September" year="2016"/>
        </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 anchor="NFD" target="https://named-data.net/doc/NFD/current/">
        <front>
          <title>NFD - Named Data Networking Forwarding Daemon</title>
          <author initials="" surname="NDN" />
          <date year="2017"/>
          <author>
	    <organization>NDN</organization>
	  </author>
        </front>
      </reference>

      <reference anchor="ICNRGCharter" target="https://datatracker.ietf.org/doc/charter-irtf-icnrg/">
        <front>
          <title>Information-Centric Networking Research Group Charter</title>
          <author initials="" surname="NDN" />
          <date year="2013"/>
          <author>
	    <organization>IRTF</organization>
	  </author>
        </front>
      </reference>

      <reference anchor="Baccelli" target="http://conferences2.sigcomm.org/acm-icn/2014/papers/p77.pdf">
        <front>
          <title>Information Centric Networking in the IoT: Experiments with NDN in the Wild</title>
          <author initials="E." surname="Baccelli" />
		  <author initials="" surname="et al." />
          <author>
	  <organization>Baccelli, E., et al.</organization>
	  </author>
          <date month="September" year="2014"/>
        </front>
	<seriesInfo name="ACM 20164," value="Paris, France"/> name="DOI" value="10.1145/2660129.2660144"/>
	<refcontent>ACM-ICN '14: Proceedings of the 1st ACM Conference on
	Information-Centric Networking</refcontent>
      </reference>

      <reference anchor="Anastasiades" target="http://boris.unibe.ch/83683/1/16anastasiades_c.pdf">
        <front>
          <title>Information-centric communication in mobile and wireless networks</title>
          <author initials="C" surname="Anastasiades" /> fullname="Carlos
								Anastasiades">
	    <organization/>
	  </author>
          <date year="PhD Dissertation, 2016"/> month="June" year="2016"/>
        </front>
	<seriesInfo name="DOI" value=" 10.7892/boris.83683"/>
	<refcontent>PhD Dissertation</refcontent>
      </reference>

      <reference anchor="Jangam" target="https://dl.acm.org/citation.cfm?id=3132351">
        <front>
          <title>Porting
          <title>nlsrSIM: Porting and Simulation of Named-data Link State
	  Routing Protocol into ndnSIM</title>
          <author initials="A." surname="Jangam" />
		  <author initials="" surname="et al." />
          <author>
	    <organization>Jangam, A., et al.</organization>
	  </author>
          <date month="November" year="2017"/>
        </front>
          <seriesInfo name="ACM DIVANet'17," value="Miami Beach, USA"/>
      </reference>

	 <reference anchor="ICN2020" target="http://www.icn2020.org/dissemination/deliverables-public/">
        <front>
          <title>ICN2020 Deliverables</title>
          <author initials="" surname="ICN2020" />
          <date year="2017"/>
        </front> 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 Applications</refcontent>
      </reference>

      <reference anchor="CUTEi">
        <front>
          <title>Container-Based Unified Testbed for Information Centric Networking</title>
          <author initials="H." surname="Asaeda" /> fullname="Hitoshi Asaeda">
	    <organization/>
	  </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>
          <seriesInfo name="IEEE Network, Vol.28, No.6" value=""/> name="DOI" value="10.1109/MNET.2014.6963806"/>
	  <refcontent>IEEE Network Volume 28, Issue:6</refcontent>
      </reference>

      <reference anchor="Overlay_ICN" target="https://www.researchgate.net/publication/282779666_A_novel_overlay_architecture_for_Information_Centric_Networking">
        <front>
          <title>A Novel Overlay Architecture novel overlay architecture for F Information Centric Networking</title>
          <author initials="S." surname="Shailendra" />
		  <author initials="" surname="et al." />
          <author>
	    <organization>Shailendra, S.,et al.</organization>
	  </author>
          <date month="April" year="2016"/>
        </front>
	<seriesInfo name="DOI" value="10.1109/NCC.2015.7084921"/>
	<refcontent>2015 21st National Conference on Communications, NCC 2015</refcontent>
      </reference>

      <reference anchor="Contrace">
        <front>
          <title>Contrace: A Tool a tool for Measuring measuring and Tracing Content-Centric Networks</title>
          <author initials="H." surname="Asaeda" />
		  <author initials="" surname="et al." /> tracing content-centric networks</title>
          <author>
	      <organization>Asaeda, H., et al.</organization>
	    </author>
          <date month="March" year="2015"/>
        </front>
	<seriesInfo name="IEEE name="DOI" value="10.1109/MCOM.2015.7060502"/>
	<refcontent> IEEE Communications Magazine, Vol.53, No.3" value=""/> Volume 53, Issue 3</refcontent>
      </reference>

      <reference anchor="fiveG-23502">
        <front>
          <title>Technical Specification Group Services and System Aspects; Procedures
          <title>Procedures for the 5G System (Rel.15)</title>
          <author initials="" surname="3gpp-23.502" />
          <date year="2017"/> (5GS)</title>
          <author>
	  <organization>3GPP</organization>
	</author>
        </front>
	<seriesInfo name="3GPP" value=""/> value="TS 23.502"/>
	<refcontent>Release 15</refcontent>
      </reference>

      <reference anchor="CICN" target="https://wiki.fd.io/view/Cicn">
        <front>
          <title>Community Information-Centric Networking (CICN)</title>
          <author initials="" surname="CICN" />
          <date year="2017"/>
          <title>Cicn</title>
          <author>
	    <organization>fd.io</organization>
	  </author>
        </front>
      </reference>

      <reference anchor="Mai-1" target="http://www.mallouli.com/recherche/publications/noms2018-1.pdf"> target="https://ieeexplore.ieee.org/document/8401591">
        <front>
          <title>Implementation of Content Poisoning Attack Detection content poisoning attack detection and Reaction
	  reaction in Virtualized virtualized NDN Networks</title>
          <author initials="H.L." surname="Mai" />
		  <author initials="" surname="et al." /> networks</title>
          <author>
	  <organization>Mai, H., et al.</organization>
	  </author>
          <date year="21st month="July" year="2018"/>
        </front>
	<seriesInfo name="DOI" value="10.1109/ICIN.2018.8401591"/>
	<refcontent>2018 21st Conference on Innovation in Clouds, Internet and Networks, ICIN 2018 (demo paper) IEEE, 2018"/>
        </front>
	Networks and Workshops (ICIN)</refcontent>
      </reference>

      <reference anchor="Mai-2">
        <front>
          <title>Towards a Security Monitoring Plane for Named Data
	  Networking: Application to Content Poisoning Attack</title>
          <author initials="H.L." surname="Mai" />
		  <author initials="" surname="et al." />
          <author>
	    <organization>Mai, H., et al.</organization>
	  </author>
          <date year="Proceedings of the month="July" year="2018"/>
        </front>
	<seriesInfo name="DOI" value="10.1109/NOMS.2018.8406246"/>
	<refcontent>NOMS 2018 - 2018 IEEE/IFIP Symposium on Network Operations and Management (NOMS) IEEE, 2018"/>
        </front>
	Symposium</refcontent>
      </reference>

      <reference anchor="Marchal" target="http://www.mallouli.com/recherche/publications/noms2018-1.pdf">
        <front>
          <title>Leveraging NFV for the Deployment of NDN: Application to HTTP Traffic Transport</title>
          <author initials="X." surname="Marchal" />
		  <author initials="" surname="et al." />
          <author>
	    <organization>Marchal, X., et al.</organization>
	  </author>
          <date year="Proceedings of the month="July" year="2018"/>
        </front>
	<seriesInfo name="DOI" value="10.1109/NOMS.2018.8406206"/>
	<refcontent>NOMS 2018 - 2018 IEEE/IFIP Symposium on Network Operations and
	Management (NOMS),  2018"/>
        </front> Symposium</refcontent>
      </reference>

      <reference anchor="Nguyen-1">
        <front>
          <title>Content Poisoning in Named Data Networking: Comprehensive Characterization
	  characterization of real Deployment</title>
 		  <author initials="T.N." surname="Nguyen" />
		  <author initials="" surname="et al." /> deployment</title>
          <author>
	    <organization>Nguyen, T., et al.</organization>
	  </author>
          <date year="Proceedings of the 15th IEEE/IFIP International month="July" year="2017"/>
        </front>
	<seriesInfo name="DOI" value="10.23919/INM.2017.7987266"/>
	<refcontent>2017 IFIP/IEEE Symposium on Integrated Network Management, 2017"/>
        </front> and Service
	Management (IM)</refcontent>
      </reference>

      <reference anchor="Nguyen-2">
        <front>
          <title>An Optimal Statistical Test optimal statistical test for Robust Detection robust detection against Interest Flooding Attacks
	  interest flooding attacks in CCN</title>
          <author initials="T.N." initials="T." surname="Nguyen" /> fullname="Tan Nguyen">
	    <organization/>
	  </author>
          <author initials="R." surname="Cogranne" /> fullname="Remi Cogranne">
	    <organization/>
	  </author>
          <author initials="G." surname="Doyen" /> fullname="Guillaume Doyen">
	    <organization/>
	  </author>
          <date year="Proceedings of the 14th IEEE/IFIP month="July" year="2015"/>
        </front>
	<seriesInfo name="DOI" value="10.1109/INM.2015.7140299"/>
	<refcontent>2015 IFIP/IEEE International Symposium on Integrated
	Network Management, 2015"/>
        </front> Management (IM)</refcontent>
      </reference>

      <reference anchor="Nguyen-3">
        <front>
          <title>A Security Monitoring Plane for Named Data Networking Deployment</title>
 		  <author initials="T.N." surname="Nguyen" />
		  <author initials="" surname="et al." />
          <author>
	    <organization>Nguyen, T., et al.</organization>
	  </author>
          <date year="IEEE month="November" year="2018"/>
        </front>
	<seriesInfo name="DOI" value="10.1109/MCOM.2018.1701135"/>
	<refcontent>IEEE Communications Magazine, Nov 2018"/>
        </front> Volume: 56, Issue 11</refcontent>
      </reference>

      <reference anchor="Doctor" target="http://www.doctor-project.org/index.htm">
        <front>
          <title>Deployment and Securisation securisation of new Functionalities functionalities in Virtualized Networking Environments (Doctor)</title>
          <author initials="" surname="Doctor" />
          <date year="2017"/>
	  virtualized networking environments</title>
          <author>
	    <organization>DOCTOR</organization>
	  </author>
        </front>
      </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-hicn-luca-muscariello">
        <front>
          <title>Hybrid Information-Centric Networking: ICN inside the Internet Protocol</title>
          <author initials="L." surname="Muscariello" />
		  <author initials="" surname="et al." />
          <date year="2018"/>
        </front>
      </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 library for carrying HTTP messages</title>
          <author initials="M." surname="Sardara" />
		  <author initials="" surname="et al." />
          <author>
	    <organization>Muscariello, L., et al</organization>
          </author>
          <date month="March" year="2018"/>
        </front>
	<refcontent>ICNRG Interim Meeting</refcontent>
      </reference>

      <reference anchor="UMOBILE-2">
        <front>
          <title>Connecting the Edges: A Universal, Mobile-Centric, and
	  Opportunistic Communications Architecture</title>
 		  <author initials="C." surname="Sarros" />
		  <author initials="" surname="et al." />
          <author>
	    <organization>Sarros, C., et al.</organization>
	  </author>
          <date year="IEEE month="February" year="2018"/>
        </front>
	<seriesInfo name="DOI" value="10.1109/MCOM.2018.1700325"/>
	<refcontent>IEEE Communications Magazine, vol. Volume 56, February 2018"/>
        </front> Issue 2</refcontent>
      </reference>

      <reference anchor="UMOBILE-3">
        <front>
          <title>Named-data Emergency Network Services</title>
          <author initials="M." surname="Tavares" /> fullname="Miguel Tavares">
	    <organization/>
	  </author>
          <author initials="O." surname="Aponte" /> fullname="Omar Aponte">
	    <organization/>
	  </author>
          <author initials="P." surname="Mendes" /> fullname="Paulo Mendes">
	    <organization/>
	  </author>
          <date year="Proc. of ACM MOBISYS, Munich, Germany, June 2018"/> month="June" year="2018"/>
        </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 anchor="UMOBILE-4">
        <front>
          <title>Oi! - Opportunistic Data Transmission Based on Wi-Fi Direct</title>
 		  <author initials="L." surname="Lopes" />
		  <author initials="" surname="et al." />
          <author>
	    <organization>Amaral, L., et al.</organization>
	  </author>
          <date year="Proc. of IEEE INFOCOM, San Francisco, USA, April 2016"/> month="April" year="2016"/>
        </front>
	<seriesInfo name="DOI" value="10.1109/INFCOMW.2016.7562142"/>
	<refcontent>2016 IEEE Conference on Computer Communications Workshops
	(INFOCOM WKSHPS)</refcontent>
      </reference>

      <reference anchor="UMOBILE-5">
        <front>
          <title>Named-Data Networking
          <title>Demo: named-data networking in Opportunistic Networks</title> opportunistic network</title>
          <author initials="S." surname="Dynerowicz" /> fullname="Seweryn
							       Dynerowicz">
	    <organization/>
	  </author>
          <author initials="P." surname="Mendes" /> fullname="Paulo Mendes">
	    <organization/>
	  </author>
          <date year="Proc. month="September" year="2017"/>
        </front>
	<seriesInfo name="DOI" value="10.1145/3125719.3132107"/>
	<refcontent>ICN '17: Proceedings of the 4th ACM ICN, Berlin, Germany, September 2017"/>
        </front> Conference on
	Information-Centric Networking</refcontent>
      </reference>

      <reference anchor="UMOBILE-6">
        <front>
          <title>Information-centric Routing routing for Opportunistic Wireless Networks</title>
 	      <author initials="P." surname="Mendes" />
		  <author initials="" surname="et al." /> opportunistic wireless networks</title>
          <author><organization>Mendes, P.,et al.</organization>
	  </author>
          <date year="Proc. month="September" year="2018"/>
        </front>
	<seriesInfo name="DOI" value="10.1145/3267955.3269011"/>
	<refcontent>ICN '18: Proceedings of the 5th ACM ICN, Boston, USA, September 2018"/>
        </front> Conference on
	Information-Centric Networking</refcontent>
      </reference>

      <reference anchor="UMOBILE-7">
        <front>
          <title>The UMOBILE Contextual Manager Service. Technical Report. Technical Report Senception 001, 2018
		  (base for UMOBILE deliverable D4.5 -
          <title>D4.5 Report on Data Collection and Inference Models</title>
          <author initials="R" initials="R." surname="Sofia" /> fullname="Rute C. Sofia"/>
          <date year="2018"/> month="September" year="2017"/>
        </front>
	<refcontent>Deliverable</refcontent>
      </reference>

      <reference anchor="UMOBILE-8">
        <front>
          <title>ICN-based edge service deployment in challenged networks</title>
 		  <author initials="C." surname="Sarros" />
		  <author initials="" surname="et al." />
          <author>
	    <organization>Sarros, C., et al.</organization>
	  </author>
          <date year="Proceedings month="September" year="2017"/>
        </front>
	<seriesInfo name="DOI" value="10.1145/3125719.3132096"/>
	<refcontent>ICN '17: Proceedings of the 4th ACM Conference on
	Information-Centric Networking (ICN '17). ACM, New York, NY, USA, 2017 "/>
        </front> Networking</refcontent>
      </reference>

      <reference anchor="UMOBILE-9">
        <front>
          <title>Information-Centric Multi-Access Edge Computing Platform for
	  Community Mesh Networks</title>
		  <author initials="A." surname="Lertsinsrubtavee" />
		  <author initials="" surname="et al." />
          <author><organization>Lertsinsrubtavee, A., et al.</organization>
	  </author>
          <date year="Proceedings month="June" year="2018"/>
        </front>
	<seriesInfo name="DOI" value="10.1145/3209811.3209867"/>
	<refcontent>COMPASS '18: Proceedings of the 1st ACM SIGCAS Conference
	on Computing and Sustainable Societies (COMPASS '18). ACM, New York, NY, USA, 2018 "/>
        </front> Societies</refcontent>
      </reference>

      <reference anchor="SAIL" target="http://www.sail-project.eu/">
        <front>
          <title>Scalable and Adaptive Internet Solutions (SAIL)</title>
          <author initials="" surname="SAIL" />
          <date year="2013"/>
          <author>
	    <organization>SAIL</organization>
	  </author>
        </front>
      </reference>

      <reference anchor="NDN-testbed" target="https://named-data.net/ndn-testbed/">
        <front>
          <title>Named Data Networking (NDN)
          <title>NDN Testbed</title>
          <author initials="" surname="NDN Testbed" />
          <date year="2010"/>
          <author>
	    <organization>NDN</organization>
	  </author>
        </front>
      </reference>

      <reference anchor="ICN2020-overview" target="http://www.icn2020.org/">
        <front>
          <title>ICN2020 Project Overview</title>
          <author initials="" surname="ICN2020" />
          <date year="2016"/>
          <author>
	    <organization>ICN2020</organization>
	  </author>
        </front>
      </reference>

      <reference anchor="GEANT" target="https://www.geant.org/">
        <front>
          <title>GEANT Overview</title>
          <author initials="" surname="GEANT" />
          <date year="2016"/>
          <title>GEANT</title>
          <author>
	    <organization>GEANT</organization>
	  </author>
        </front>
      </reference>

      <reference anchor="UMOBILE-overview" target="http://www.umobile-project.eu/">
        <front>
          <title>Universal Mobile-centric
          <title>Universal, mobile-centric and Opportunistic Communications Architecture (UMOBILE)</title>
          <author initials="" surname="UMOBILE" />
          <date year="2018"/> opportunistic communications architecture</title>
          <author>
	    <organization>UMOBILE</organization>
	  </author>
        </front>
      </reference>

      <reference anchor="NGMN-Network-Slicing" target="https://www.ngmn.org/fileadmin/user_upload/160113_Network_Slicing_v1_0.pdf"> target="https://www.ngmn.org/wp-content/uploads/160113_NGMN_Network_Slicing_v1_0.pdf">
        <front>
          <title>NGMN Description
          <title>Description of Network Slicing Concept</title>
          <author initials="" surname="NGMN" />
          <author>
	    <organization>NGMN Alliance</organization>
	  </author>
	  <date month="January" year="2016"/>
        </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 anchor="Chakraborti">
        <front>
          <title>Design and Evaluation of a Multi-source Multi-destination Real-time Application on Content Centric Network</title>
          <author initials="A." surname="Chakraborti" />
		  <author initials="" surname="et al." />
          <author>
	    <organization>Chakraborti, A., et al.</organization>
	  </author>
          <date month="August" year="2018"/>
        </front>
          <seriesInfo name="IEEE, HoT ICN, 2018" value=""/> name="DOI" value="10.1109/HOTICN.2018.8605980"/>
	  <refcontent>2018 1st IEEE International Conference on Hot
	  Information-Centric Networking (HotICN)</refcontent>
      </reference>

      <reference anchor="SAIL_Content_Delivery" target="https://sail-project.eu/wp-content/uploads/2012/06/SAIL_DB2_v1_0_final-Public.pdf">
        <front>
          <title>SAIL
          <title>NetInf Content Delivery and Operations</title>
          <author initials="" surname="FP7" />
          <author>
	    <organization>FP7</organization>
	  </author>
          <date month="January" year="2013"/>
        </front>
	<seriesInfo name="Objective" value="FP7-ICT-2009-5-257448/D-3.2"/>
      </reference>

      <reference anchor="ICN2020-Experiments" target="http://www.icn2020.org/dissemination/deliverables-public/"> target="https://projects.gwdg.de/attachments/6840/D4.1-PU.pdf">
        <front>
          <title>Deliverable D4.1:
          <title>D4.1: 1st yearly report on Testbed and Experiments (WP4)</title>
          <author initials="" surname="ICN2020" /> Yearly WP4 Report &amp; Demonstration</title>
          <author>
	    <organization>ICN2020</organization>
	  </author>
          <date month="August" year="2017"/>
        </front>
      </reference>
    </references>

  <!-- section anchor="Appendix A" title="Change Log" -->

    <section title="Change Log">

     <t>[Note to RFC Editor: Please remove this section before publication.]</t>
	 	 	<t>Changes from draft-irtf-rev-06 to draft-irtf-rev-07:
	    <list style="symbols">
		   <t>Added reference to OSCORE (RFC 8613) which is a way of passing
		   end-to-end encrypted content between HTTP and COAP without invalidating encryption.  Thus it
		   can be a potential model for HTTP to ICN, or COAP to ICN, anchor="Acknowledgments" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors want to consider in the future.</t>
		   <t>Updated affiliation information thank <contact fullname="Alex Afanasyev"/>,
      <contact fullname="Hitoshi Asaeda"/>, <contact fullname="Giovanna
      Carofiglio"/>, <contact fullname="Xavier de Foy"/>, <contact
      fullname="Guillaume Doyen"/>, <contact fullname="Hannu Flinck"/>,
      <contact fullname="Anil Jangam"/>, <contact fullname="Michael Kowal"/>,
      <contact fullname="Adisorn Lertsinsrubtavee"/>, <contact fullname="Paulo
      Mendes"/>, <contact fullname="Luca Muscariello"/>, <contact
      fullname="Thomas Schmidt"/>, <contact fullname="Jan Seedorf"/>, <contact
      fullname="Eve Schooler"/>, <contact fullname="Samar Shailendra"/>,
      <contact fullname="Milan Stolic"/>, <contact fullname="Prakash Suthar"/>,
      <contact fullname="Atsushi Mayutan"/>, and <contact fullname="Lixia
      Zhang"/> for author Ravi Ravindran.</t>
	 	</list>
		</t>

	 	<t>Changes from draft-irtf-rev-05 to draft-irtf-rev-06:
	    <list style="symbols">
		   <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 Montpetit.</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 on UMOBILE Trial Experiences.</t>
		   <t>Incorporated off-line editorial comments from Hitoshi Asaeda 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 their very useful reviews and references of Doctor testbed 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 Considerations section.</t>
		   <t>Added "Composite-ICN" configuration document.
      </t>
      <t>Special thanks to cover the Hybrid ICN <contact fullname="Dave Oran"/> (ICNRG Co-chair)
      and similar configurations which do not clearly fit in one of the other basic configurations.</t>
		   <t>Updated description <contact fullname="Marie-Jose Montpetit"/> for their extensive and
      thoughtful reviews of the ICN-as-a-Slice configuration to clarify that it may also apply to non-5G systems.</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 Muscariello.</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-deployment-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 document. Their reviews helped to Hybrid ICN from section 3.2 (ICN-as-an-Overlay definition). Instead, consolidated all Hybrid ICN info in the
		   Deployment Trial Experiences under a new subsection 5.3 (Other Configurations).</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
      immeasurably improve the entire Mobile network.</t>
		   <t>Added several new references in various sections.</t>
		   <t>Various minor editorial updates.</t>
	    </list>
	    </t> document quality.</t>
    </section>

  </back>
</rfc>