<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" consensus="true" docName="draft-irtf-icnrg-deployment-guidelines-07" indexInclude="true" ipr="trust200902" number="8763" prepTime="2020-04-16T18:19:13" scripts="Common,Latin" sortRefs="true" submissionType="IRTF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-irtf-icnrg-deployment-guidelines-07" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8763" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Deployment Considerations for ICN">Deployment Considerations for Information-Centric Networking (ICN)</title>
    <seriesInfo name="RFC" value="8763" stream="IRTF"/>
    <author fullname="Akbar Rahman" initials="A." surname="Rahman">
      <organization abbrev="InterDigital Communications, LLC" showOnFrontPage="true">InterDigital Communications, LLC</organization>
      <address>
        <postal>
          <street>1000 Sherbrooke Street West, 10th floor</street>
          <city>Montreal</city>
          <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="Huawei" showOnFrontPage="true">Huawei Technologies Duesseldorf GmbH</organization>
      <address>
        <postal>
          <street>Riesstrasse 25</street>
          <city>Munich</city>
          <code>80992</code>
          <country>Germany</country>
        </postal>
        <email>dirk.trossen@huawei.com</email>
        <uri>http://www.huawei.com/</uri>
      </address>
    </author>
    <author fullname="Dirk Kutscher" initials="D." surname="Kutscher">
      <organization abbrev="Emden University" showOnFrontPage="true">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 showOnFrontPage="true">Sterlite Technologies</organization>
      <address>
        <postal>
          <street>5201 Greatamerica Pkwy</street>
          <city>Santa Clara</city>
          <code>95054</code>
          <country>United States of America</country>
        </postal>
        <email>ravi.ravindran@gmail.com</email>
      </address>
    </author>
    <date month="04" year="2020"/>
    <area>Internet Research Task Force (IRTF)</area>
    <workgroup>Information-Centric Networking</workgroup>
    <abstract pn="section-abstract">
      <t pn="section-abstract-1">Information-Centric Networking (ICN) is now reaching technological
      maturity after many years of fundamental research and experimentation. 
	  This document provides a number of deployment considerations in the
	  interest of helping the ICN community move forward to the next step
	  of live deployments. First, the major deployment configurations for
	  ICN are described, including the key overlay and underlay approaches.
	  Then, proposed deployment migration paths are outlined to address
	  major practical issues, such as network and application migration.
	  Next, selected ICN trial experiences are summarized. Finally,
	  protocol areas that require further standardization are identified
	  to facilitate future interoperable ICN deployments. This document is
	  a product of the Information-Centric Networking Research Group
	  (ICNRG).
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t pn="section-boilerplate.1-2">
            This document is a product of the Internet Research Task Force
            (IRTF).  The IRTF publishes the results of Internet-related
            research and development activities.  These results might not be
            suitable for deployment.  This RFC represents the consensus of the Information-Centric Networking
            Research Group of the Internet Research Task Force (IRTF).
            Documents approved for publication by the IRSG are not a
            candidate for any level of Internet Standard; see Section 2 of RFC
            7841.   
        </t>
        <t pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc8763" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t pn="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-abbreviations-list">Abbreviations List</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-deployment-configurations">Deployment Configurations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-clean-slate-icn">Clean-Slate ICN</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-icn-as-an-overlay">ICN-as-an-Overlay</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-icn-as-an-underlay">ICN-as-an-Underlay</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.3.2">
                  <li pn="section-toc.1-1.4.2.3.2.1">
                    <t pn="section-toc.1-1.4.2.3.2.1.1"><xref derivedContent="4.3.1" format="counter" sectionFormat="of" target="section-4.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-edge-network">Edge Network</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.2">
                    <t pn="section-toc.1-1.4.2.3.2.2.1"><xref derivedContent="4.3.2" format="counter" sectionFormat="of" target="section-4.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-core-network">Core Network</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-icn-as-a-slice">ICN-as-a-Slice</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.5">
                <t pn="section-toc.1-1.4.2.5.1"><xref derivedContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-composite-icn-approach">Composite-ICN Approach</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-deployment-migration-paths">Deployment Migration Paths</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-application-and-service-mig">Application and Service Migration</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-content-delivery-network-mi">Content Delivery Network Migration</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-edge-network-migration">Edge Network Migration</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-core-network-migration">Core Network Migration</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-deployment-trial-experience">Deployment Trial Experiences</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-icn-as-an-overlay-2">ICN-as-an-Overlay</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.1.2">
                  <li pn="section-toc.1-1.6.2.1.2.1">
                    <t pn="section-toc.1-1.6.2.1.2.1.1"><xref derivedContent="6.1.1" format="counter" sectionFormat="of" target="section-6.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fp7-pursuit-efforts">FP7 PURSUIT Efforts</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.1.2.2">
                    <t pn="section-toc.1-1.6.2.1.2.2.1"><xref derivedContent="6.1.2" format="counter" sectionFormat="of" target="section-6.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fp7-sail-trial">FP7 SAIL Trial</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.1.2.3">
                    <t pn="section-toc.1-1.6.2.1.2.3.1"><xref derivedContent="6.1.3" format="counter" sectionFormat="of" target="section-6.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ndn-testbed">NDN Testbed</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.1.2.4">
                    <t pn="section-toc.1-1.6.2.1.2.4.1"><xref derivedContent="6.1.4" format="counter" sectionFormat="of" target="section-6.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-icn2020-efforts">ICN2020 Efforts</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.1.2.5">
                    <t pn="section-toc.1-1.6.2.1.2.5.1"><xref derivedContent="6.1.5" format="counter" sectionFormat="of" target="section-6.1.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-umobile-efforts">UMOBILE Efforts</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-icn-as-an-underlay-2">ICN-as-an-Underlay</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.2.2">
                  <li pn="section-toc.1-1.6.2.2.2.1">
                    <t pn="section-toc.1-1.6.2.2.2.1.1"><xref derivedContent="6.2.1" format="counter" sectionFormat="of" target="section-6.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-h2020-point-and-rife-effort">H2020 POINT and RIFE Efforts</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.2.2.2">
                    <t pn="section-toc.1-1.6.2.2.2.2.1"><xref derivedContent="6.2.2" format="counter" sectionFormat="of" target="section-6.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-h2020-flame-efforts">H2020 FLAME Efforts</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.2.2.3">
                    <t pn="section-toc.1-1.6.2.2.2.3.1"><xref derivedContent="6.2.3" format="counter" sectionFormat="of" target="section-6.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cablelabs-content-delivery-">CableLabs Content Delivery System</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.2.2.4">
                    <t pn="section-toc.1-1.6.2.2.2.4.1"><xref derivedContent="6.2.4" format="counter" sectionFormat="of" target="section-6.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ndn-iot-trials">NDN IoT Trials</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.2.2.5">
                    <t pn="section-toc.1-1.6.2.2.2.5.1"><xref derivedContent="6.2.5" format="counter" sectionFormat="of" target="section-6.2.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-nren-icn-testbed">NREN ICN Testbed</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.2.2.6">
                    <t pn="section-toc.1-1.6.2.2.2.6.1"><xref derivedContent="6.2.6" format="counter" sectionFormat="of" target="section-6.2.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-doctor-testbed">DOCTOR Testbed</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-composite-icn-approach-2">Composite-ICN Approach</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-summary-of-deployment-trial">Summary of Deployment Trials</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-deployment-issues-requiring">Deployment Issues Requiring Further Standardization</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protocols-for-application-a">Protocols for Application and Service Migration</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protocols-for-content-deliv">Protocols for Content Delivery Network Migration</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protocols-for-edge-and-core">Protocols for Edge and Core Network Migration</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.4">
                <t pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-summary-of-icn-protocol-gap">Summary of ICN Protocol Gaps and Potential Protocol Efforts</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conclusion">Conclusion</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="sec_introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t pn="section-1-1">The ICNRG charter identifies deployment guidelines as an important
      topic area for the ICN community. Specifically, the charter states 
	  that defining concrete migration paths for ICN deployments that
	  avoid forklift upgrades and defining practical ICN interworking
	  configurations 
	  with the existing Internet paradigm are key topic areas that
	  require further investigation <xref target="ICNRGCharter" format="default" sectionFormat="of" derivedContent="ICNRGCharter"/>. Also, it is well 
	  understood that results and conclusions from any mid- to large-scale
	  ICN experiments in the live Internet will also provide useful
	  guidance for deployments.   
      </t>
      <t pn="section-1-2">So far, outside of some preliminary investigations, such as <xref target="I-D.paik-icn-deployment-considerations" format="default" sectionFormat="of" derivedContent="ICN-DEP-CON"/>,
      there has not been much  
	  progress on this topic. This document attempts to fill some of
	  these gaps by defining clear deployment configurations for ICN and
	  associated
	  migration pathways for these configurations. Also, selected
	  deployment trial experiences of ICN technology are summarized.
	  Recommendations 
	  are also made for potential future IETF standardization of key
	  protocol functionality that will facilitate interoperable ICN
	  deployments going forward.  
      </t>
      <t pn="section-1-3">The major configurations of possible ICN deployments are identified
      in this document as (1) Clean-slate ICN replacement of existing Internet
      infrastructure, 
	  (2) ICN-as-an-Overlay, (3) ICN-as-an-Underlay, (4) ICN-as-a-Slice,
	  and (5) Composite-ICN. Existing ICN trial systems primarily fall 
	  under the ICN-as-an-Overlay, ICN-as-an-Underlay, and Composite-ICN
	  configurations. Each of these deployment configurations have their
	  respective strengths and weaknesses. 
	  This document will aim to provide guidance for current and future
	  members of the ICN community when they consider deployment of ICN
	  technologies. 
      </t>
      <t pn="section-1-4">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" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t pn="section-2-1">
This document assumes readers are, in general, familiar with the terms and
concepts that are defined in <xref target="RFC7927" format="default" sectionFormat="of" derivedContent="RFC7927"/> and
<xref target="I-D.irtf-icnrg-terminology" format="default" sectionFormat="of" derivedContent="ICN-TERM"/>. In addition,
this document defines the following terminology: 
		 
      </t>
      <dl newline="true" spacing="normal" pn="section-2-2">
        <dt pn="section-2-2.1">Deployment:</dt>
        <dd pn="section-2-2.2">The final stage of the process of setting up an ICN network that is 
		  (1) ready for useful work (e.g., transmission of end-user
		  video and text) in a live environment and (2) integrated
		  and interoperable
		  with the Internet. We consider the Internet in its widest
		  sense where it encompasses various access networks (e.g.,
		  Wi-Fi or mobile radio network),
		  service edge networks (e.g., for edge computing), transport
		  networks, Content Distribution Networks (CDNs), core networks (e.g., mobile core network),
		  and back-end processing networks
		  (e.g., data centers). However, throughout this document, 
		  the discussion is typically limited to edge networks, core
		  networks, and CDNs, for simplicity.</dd>
        <dt pn="section-2-2.3">Information-Centric Networking (ICN):</dt>
        <dd pn="section-2-2.4">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" sectionFormat="of" derivedContent="ICN-TERM"/> for further information.</dd>
        <dt pn="section-2-2.5">Network Functions Virtualization (NFV):</dt>
        <dd pn="section-2-2.6">A networking approach
	where network functions (e.g., firewalls or load balancers) are
	modularized 
		  as software logic that can run on general purpose hardware
		  and, thus, are specifically decoupled from the previous
		  generation of proprietary 
		  and dedicated hardware. See <xref target="RFC8568" format="default" sectionFormat="of" derivedContent="RFC8568"/> for further information.</dd>
        <dt pn="section-2-2.7">Software-Defined Networking (SDN):</dt>
        <dd pn="section-2-2.8">A networking approach where the control and data planes for
      switches are separated, allowing for
	realizing capabilities, such as traffic isolation and programmable
	forwarding actions. See <xref target="RFC7426" format="default" sectionFormat="of" derivedContent="RFC7426"/> for
	further information.</dd>
      </dl>
    </section>
    <section anchor="sec_acronyms" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-abbreviations-list">Abbreviations List</name>
      <dl newline="false" spacing="normal" indent="13" pn="section-3-1">
        <dt pn="section-3-1.1">API:</dt>
        <dd pn="section-3-1.2">Application Programming Interface</dd>
        <dt pn="section-3-1.3">BIER:</dt>
        <dd pn="section-3-1.4">Bit Index Explicit Replication</dd>
        <dt pn="section-3-1.5">BoF:</dt>
        <dd pn="section-3-1.6">Birds of a Feather (session)</dd>
        <dt pn="section-3-1.7">CCNx:</dt>
        <dd pn="section-3-1.8">Content-Centric Networking</dd>
        <dt pn="section-3-1.9">CDN:</dt>
        <dd pn="section-3-1.10">Content Distribution Network</dd>
        <dt pn="section-3-1.11">CoAP:</dt>
        <dd pn="section-3-1.12">Constrained Application Protocol</dd>
        <dt pn="section-3-1.13">DASH:</dt>
        <dd pn="section-3-1.14">Dynamic Adaptive Streaming over HTTP</dd>
        <dt pn="section-3-1.15">Diffserv:</dt>
        <dd pn="section-3-1.16">Differentiated Services</dd>
        <dt pn="section-3-1.17">DoS:</dt>
        <dd pn="section-3-1.18">Denial of Service</dd>
        <dt pn="section-3-1.19">DTN:</dt>
        <dd pn="section-3-1.20">Delay-Tolerant Networking</dd>
        <dt pn="section-3-1.21">ETSI:</dt>
        <dd pn="section-3-1.22">European Telecommunications Standards Institute</dd>
        <dt pn="section-3-1.23">EU:</dt>
        <dd pn="section-3-1.24">European Union</dd>
        <dt pn="section-3-1.25">FP7:</dt>
        <dd pn="section-3-1.26">7th Framework Programme for Research and Technological Development</dd>
        <dt pn="section-3-1.27">HLS:</dt>
        <dd pn="section-3-1.28">HTTP Live Streaming</dd>
        <dt pn="section-3-1.29">HTTP:</dt>
        <dd pn="section-3-1.30">HyperText Transfer Protocol</dd>
        <dt pn="section-3-1.31">HTTPS:</dt>
        <dd pn="section-3-1.32">HyperText Transfer Protocol Secure</dd>
        <dt pn="section-3-1.33">H2020:</dt>
        <dd pn="section-3-1.34">Horizon 2020 (research program)</dd>
        <dt pn="section-3-1.35">ICN:</dt>
        <dd pn="section-3-1.36">Information-Centric Networking</dd>
        <dt pn="section-3-1.37">ICNRG:</dt>
        <dd pn="section-3-1.38">Information-Centric Networking Research Group</dd>
        <dt pn="section-3-1.39">IETF:</dt>
        <dd pn="section-3-1.40">Internet Engineering Task Force</dd>
        <dt pn="section-3-1.41">IntServ:</dt>
        <dd pn="section-3-1.42">Integrated Services</dd>
        <dt pn="section-3-1.43">IoT:</dt>
        <dd pn="section-3-1.44">Internet of Things</dd>
        <dt pn="section-3-1.45">IP:</dt>
        <dd pn="section-3-1.46">Internet Protocol</dd>
        <dt pn="section-3-1.47">IPv4:</dt>
        <dd pn="section-3-1.48">Internet Protocol Version 4</dd>
        <dt pn="section-3-1.49">IPv6:</dt>
        <dd pn="section-3-1.50">Internet Protocol Version 6</dd>
        <dt pn="section-3-1.51">IPTV:</dt>
        <dd pn="section-3-1.52">Internet Protocol Television</dd>
        <dt pn="section-3-1.53">IS-IS:</dt>
        <dd pn="section-3-1.54">Intermediate System to Intermediate System</dd>
        <dt pn="section-3-1.55">ISP:</dt>
        <dd pn="section-3-1.56">Internet Service Provider</dd>
        <dt pn="section-3-1.57">k:</dt>
        <dd pn="section-3-1.58">kilo (1000)</dd>
        <dt pn="section-3-1.59">L2:</dt>
        <dd pn="section-3-1.60">Layer 2</dd>
        <dt pn="section-3-1.61">LTE:</dt>
        <dd pn="section-3-1.62">Long Term Evolution (or 4th generation cellular system)</dd>
        <dt pn="section-3-1.63">MANO:</dt>
        <dd pn="section-3-1.64">Management and Orchestration</dd>
        <dt pn="section-3-1.65">MEC:</dt>
        <dd pn="section-3-1.66">Multi-access Edge Computing</dd>
        <dt pn="section-3-1.67">Mbps:</dt>
        <dd pn="section-3-1.68">Megabits per second</dd>
        <dt pn="section-3-1.69">M2M:</dt>
        <dd pn="section-3-1.70">Machine-to-Machine</dd>
        <dt pn="section-3-1.71">NAP:</dt>
        <dd pn="section-3-1.72">Network Attachment Point</dd>
        <dt pn="section-3-1.73">NDN:</dt>
        <dd pn="section-3-1.74">Named Data Networking</dd>
        <dt pn="section-3-1.75">NETCONF:</dt>
        <dd pn="section-3-1.76">Network Configuration Protocol</dd>
        <dt pn="section-3-1.77">NetInf:</dt>
        <dd pn="section-3-1.78">Network of Information </dd>
        <dt pn="section-3-1.79">NFD:</dt>
        <dd pn="section-3-1.80">Named Data Networking Forwarding Daemon</dd>
        <dt pn="section-3-1.81">NFV:</dt>
        <dd pn="section-3-1.82">Network Functions Virtualization</dd>
        <dt pn="section-3-1.83">NICT:</dt>
        <dd pn="section-3-1.84">Japan's National Institute of Information and Communications Technology</dd>
        <dt pn="section-3-1.85">NR:</dt>
        <dd pn="section-3-1.86">New Radio (access network for 5G)</dd>
        <dt pn="section-3-1.87">OAM:</dt>
        <dd pn="section-3-1.88">Operations, Administration, and Maintenance</dd>
        <dt pn="section-3-1.89">ONAP:</dt>
        <dd pn="section-3-1.90">Open Network Automation Platform</dd>
        <dt pn="section-3-1.91">OSPF:</dt>
        <dd pn="section-3-1.92">Open Shortest Path First</dd>
        <dt pn="section-3-1.93">PoC:</dt>
        <dd pn="section-3-1.94">Proof of Concept (demo)</dd>
        <dt pn="section-3-1.95">POINT:</dt>
        <dd pn="section-3-1.96"> IP Over ICN - the better IP (project)</dd>
        <dt pn="section-3-1.97">qMp:</dt>
        <dd pn="section-3-1.98">Quick Mesh Project</dd>
        <dt pn="section-3-1.99">QoS:</dt>
        <dd pn="section-3-1.100">Quality of Service</dd>
        <dt pn="section-3-1.101">RAM:</dt>
        <dd pn="section-3-1.102">Random Access Memory</dd>
        <dt pn="section-3-1.103">RAN:</dt>
        <dd pn="section-3-1.104">Radio Access Network</dd>
        <dt pn="section-3-1.105">REST:</dt>
        <dd pn="section-3-1.106">Representational State Transfer (architecture)</dd>
        <dt pn="section-3-1.107">RESTCONF:</dt>
        <dd pn="section-3-1.108">Representational State Transfer Configuration (protocol)</dd>
        <dt pn="section-3-1.109">RIFE:</dt>
        <dd pn="section-3-1.110">Architecture for an Internet For Everybody (project)</dd>
        <dt pn="section-3-1.111">RIP:</dt>
        <dd pn="section-3-1.112">Routing Information Protocol </dd>
        <dt pn="section-3-1.113">ROM:</dt>
        <dd pn="section-3-1.114">Read-Only Memory</dd>
        <dt pn="section-3-1.115">RSVP:</dt>
        <dd pn="section-3-1.116">Resource Reservation Protocol</dd>
        <dt pn="section-3-1.117">RTP:</dt>
        <dd pn="section-3-1.118">Real-time Transport Protocol</dd>
        <dt pn="section-3-1.119">SDN:</dt>
        <dd pn="section-3-1.120">Software-Defined Networking</dd>
        <dt pn="section-3-1.121">SFC:</dt>
        <dd pn="section-3-1.122">Service Function Chaining</dd>
        <dt pn="section-3-1.123">SLA:</dt>
        <dd pn="section-3-1.124">Service Level Agreement</dd>
        <dt pn="section-3-1.125">TCL:</dt>
        <dd pn="section-3-1.126">Transport Convergence Layer</dd>
        <dt pn="section-3-1.127">TCP:</dt>
        <dd pn="section-3-1.128">Transmission Control Protocol</dd>
        <dt pn="section-3-1.129">UDP:</dt>
        <dd pn="section-3-1.130">User Datagram Protocol</dd>
        <dt pn="section-3-1.131">UMOBILE:</dt>
        <dd pn="section-3-1.132">Universal Mobile-centric and Opportunistic Communications Architecture</dd>
        <dt pn="section-3-1.133">US:</dt>
        <dd pn="section-3-1.134">United States</dd>
        <dt pn="section-3-1.135">USA:</dt>
        <dd pn="section-3-1.136">United States of America</dd>
        <dt pn="section-3-1.137">VoD:</dt>
        <dd pn="section-3-1.138">Video on Demand</dd>
        <dt pn="section-3-1.139">VPN:</dt>
        <dd pn="section-3-1.140">Virtual Private Network</dd>
        <dt pn="section-3-1.141">WG:</dt>
        <dd pn="section-3-1.142">Working Group</dd>
        <dt pn="section-3-1.143">YANG:</dt>
        <dd pn="section-3-1.144">Yet Another Next Generation (data modeling language)</dd>
        <dt pn="section-3-1.145">5G:</dt>
        <dd pn="section-3-1.146">Fifth Generation (cellular network)</dd>
        <dt pn="section-3-1.147">6LoWPAN:</dt>
        <dd pn="section-3-1.148">IPv6 over Low-Power Wireless Personal Area Networks</dd>
      </dl>
    </section>
    <section anchor="sec_configurations" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-deployment-configurations">Deployment Configurations</name>
      <t pn="section-4-1">In this section, we present various deployment options for ICN.
      These are presented as "configurations" that allow for studying these
      options 
	further. While this document will outline experiences with a number of
	these configurations (in <xref target="sec_trial_experiences" format="default" sectionFormat="of" derivedContent="Section 6"/>), we will 
	not provide an in-depth technical or commercial evaluation for any of
	them -- for this, we refer to existing literature in this space, such as
	<xref target="Tateson" format="default" sectionFormat="of" derivedContent="Tateson"/>. 
      </t>
      <section anchor="sec_replacements" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-clean-slate-icn">Clean-Slate ICN</name>
        <t pn="section-4.1-1">ICN has often been described as a "clean-slate" approach with the
	goal to renew or replace the complete IP infrastructure of the 
		Internet. 
		As such, existing routing hardware and
		ancillary services, such as existing applications that are
		typically tied directly to the TCP/IP stack, are not
		taken for granted. For instance, a Clean-slate ICN deployment
		would see existing IP routers being replaced by ICN-specific
		forwarding and routing elements, such as NFD <xref target="NFD" format="default" sectionFormat="of" derivedContent="NFD"/>, CCNx routers <xref target="Jacobson" format="default" sectionFormat="of" derivedContent="Jacobson"/>, or Publish-Subscribe
		Internet Technology (PURSUIT) forwarding nodes <xref target="IEEE_Communications" format="default" sectionFormat="of" derivedContent="IEEE_Communications"/>. 
</t>
        <t pn="section-4.1-2">While such clean-slate replacement could be seen as exclusive for
	ICN deployments, some ICN approaches (e.g., <xref target="POINT" format="default" sectionFormat="of" derivedContent="POINT"/>) 
		also rely on the deployment of general infrastructure
		upgrades, in this case, SDN switches. Different proposals have
		been made for various 
		ICN approaches to enable the operation over an SDN transport
		<xref target="Reed" format="default" sectionFormat="of" derivedContent="Reed"/> <xref target="CONET" format="default" sectionFormat="of" derivedContent="CONET"/> <xref target="C_FLOW" format="default" sectionFormat="of" derivedContent="C_FLOW"/>. 
</t>
      </section>
      <section anchor="sec_overlay" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-icn-as-an-overlay">ICN-as-an-Overlay</name>
        <t pn="section-4.2-1">Similar to other significant changes to the Internet routing
	fabric, particularly the transition from IPv4 to IPv6 or 
		the introduction of IP multicast, this deployment
		configuration foresees the creation of an ICN overlay. Note
		that this overlay 
		approach is sometimes, informally, also referred to as a
		tunneling approach. 
                The overlay approach can be implemented directly 
		(e.g., ICN-over-UDP), as described in <xref target="CCNx_UDP" format="default" sectionFormat="of" derivedContent="CCNx_UDP"/>. Alternatively, the overlay can be
		accomplished via ICN-in-L2-in-IP as in <xref target="IEEE_Communications" format="default" sectionFormat="of" derivedContent="IEEE_Communications"/>, which
		describes a recursive layering process. Another approach used
		in the Network of Information (NetInf) is to define a
		convergence layer to map NetInf semantics to HTTP <xref target="I-D.kutscher-icnrg-netinf-proto" format="default" sectionFormat="of" derivedContent="NetInf"/>.   
		Finally, <xref target="Overlay_ICN" format="default" sectionFormat="of" derivedContent="Overlay_ICN"/>
		describes an incremental approach to deploying an ICN
		architecture particularly well suited to  
		SDN-based networks by also segregating ICN user- and
		control-plane traffic.  
</t>
        <t pn="section-4.2-2">However, regardless of the flavor, the overlay approach results in
	islands of ICN deployments over existing IP-based infrastructure. 
		Furthermore, these ICN islands are typically connected to each
		other via ICN/IP tunnels. In certain scenarios, this requires 
		interoperability between existing IP routing protocols (e.g.,
		OSPF, RIP, or IS-IS) and ICN-based ones. ICN-as-an-Overlay can be
		deployed 
		over the IP infrastructure in either edge or core networks.
		This overlay approach is thus very attractive for ICN
		experimentation 
		and testing, as it allows rapid and easy deployment of ICN over
		existing IP networks.   
</t>
      </section>
      <section anchor="sec_underlay" numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-icn-as-an-underlay">ICN-as-an-Underlay</name>
        <t pn="section-4.3-1">Proposals, such as <xref target="POINT" format="default" sectionFormat="of" derivedContent="POINT"/> and <xref target="White" format="default" sectionFormat="of" derivedContent="White"/>, outline the deployment option of
	using an ICN underlay that would 
		integrate with existing (external) IP-based networks by
		deploying application-layer gateways at appropriate locations.
		The main reasons for 
		such a configuration option is the introduction of ICN
		technology in given islands (e.g., inside a CDN or edge IoT
		network) to reap the benefits 
		of native ICN, in terms of underlying multicast delivery,
		mobility support, fast indirection due to location
		independence, in-network computing, 
		and possibly more. The underlay approach thus results in
		islands of native ICN deployments that are connected to the
		rest of the Internet 
		through protocol conversion gateways or proxies. Routing
		domains are strictly separated. Outside of the ICN island,
		normal IP routing protocols 
		apply. Within the ICN island, ICN-based routing schemes
		apply. The gateways transfer the semantic content of the
		messages (i.e., IP packet payload) between the two routing
		domains. 
</t>
        <section anchor="sec_application_gateways" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.1">
          <name slugifiedName="name-edge-network">Edge Network</name>
          <t pn="section-4.3.1-1">Native ICN networks may be located at the edge of the network
	  where the introduction of new network 
		architectures and protocols is easier in so-called greenfield
		deployments. In this context, ICN is an attractive option 
		for scenarios, such as IoT <xref target="I-D.irtf-icnrg-icniot" format="default" sectionFormat="of" derivedContent="ICN-IoT"/>. The integration with the current IP
		protocol suite takes place at an  
		application gateway/proxy at the edge network boundary, e.g.,
		translating incoming CoAP request/response transactions 
		<xref target="RFC7252" format="default" sectionFormat="of" derivedContent="RFC7252"/> into ICN message
		exchanges or vice versa. 
</t>
          <t pn="section-4.3.1-2">The work in <xref target="VSER" format="default" sectionFormat="of" derivedContent="VSER"/> positions ICN
	  as an edge service gateway driven by a generalized ICN-based service
	  orchestration 
		system with its own compute and network virtualization
		controllers to manage an ICN infrastructure. The platform also
		offers service discovery 
		capabilities to enable user applications to discover
		appropriate ICN service gateways. To exemplify a
		scenario in a use case, the <xref target="VSER" format="default" sectionFormat="of" derivedContent="VSER"/> platform 
		shows the realization of a multi-party audio/video
		conferencing service over such an edge cloud deployment of ICN
		routers realized over commodity hardware platforms.  This platform has also been extended to
		offer seamless mobility as a service that <xref target="VSER-Mob" format="default" sectionFormat="of" derivedContent="VSER-Mob"/> features. 
          </t>
        </section>
        <section anchor="sec_http_ip" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.2">
          <name slugifiedName="name-core-network">Core Network</name>
          <t pn="section-4.3.2-1">In this suboption, a core network would utilize edge-based
	  protocol mapping onto the native ICN underlay. For instance, <xref target="POINT" format="default" sectionFormat="of" derivedContent="POINT"/> proposes 
		to map HTTP transactions or some other IP-based transactions,
		such as CoAP, directly onto an ICN-based message
		exchange. This mapping is realized at the
		NAP, for example, in access points or customer premise
		equipment, which, in turn, provides a standard IP interface to
		existing user devices. Thus, the NAP provides the apparent
		perception of an IP-based core network toward any external
		peering network.  
</t>
          <t pn="section-4.3.2-2">The work in <xref target="White" format="default" sectionFormat="of" derivedContent="White"/> proposes a
	  similar deployment configuration. There, the goal is to use ICN for
	  content distribution within CDN 
		server farms. Specifically, the protocol mapping is realized
		at the ingress of the server farm where the HTTP-based
		retrieval request is served, while the 
		response is delivered through a suitable egress node
		translation.
</t>
        </section>
      </section>
      <section anchor="sec_icn_slice" numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-icn-as-a-slice">ICN-as-a-Slice</name>
        <t pn="section-4.4-1"> The objective of network slicing <xref target="NGMN-5G" format="default" sectionFormat="of" derivedContent="NGMN-5G"/> is to multiplex a general pool of compute, storage,
	and bandwidth resources among multiple service networks with exclusive SLA
	requirements on transport and compute-level QoS and security. This is
	enabled through NFV and SDN technology functions that enable
	functional decomposition (hence, modularity, independent scalability 
        of control, and/or the user-plane functions), agility, and service-driven
	programmability. Network slicing is often associated with 5G but is
	clearly not limited to such systems. However, from a 5G perspective,
	the definition of slicing includes access networks enabling dynamic
	slicing of the spectrum resources among various services, hence naturally
	extending itself to end points and cloud resources across
	multiple domains, to offer end-to-end guarantees. 
                Once instantiated, these slices  
		could include a mix of connectivity services (e.g.,
		LTE-as-a-service), Over-the-Top (OTT) services (e.g., VoD), or
		other IoT services through composition of a group of virtual
		and/or physical network functions at the control-, user-, and
		service-plane levels. Such a framework
		can also be used to realize ICN slices with its own control
		and forwarding plane, over which one or more end-user 
		services can be delivered <xref target="NGMN-Network-Slicing" format="default" sectionFormat="of" derivedContent="NGMN-Network-Slicing"/>.</t>
        <t pn="section-4.4-2">The 5G next generation architecture <xref target="fiveG-23501" format="default" sectionFormat="of" derivedContent="fiveG-23501"/> provides the flexibility to deploy the
	ICN-as-a-Slice over either the edge (RAN) or mobile core network; otherwise,
	the ICN-as-a-Slice may be deployed end to end. Further discussions on
	extending the architecture presented in <xref target="fiveG-23501" format="default" sectionFormat="of" derivedContent="fiveG-23501"/>  and the corresponding procedures in <xref target="fiveG-23502" format="default" sectionFormat="of" derivedContent="fiveG-23502"/>  to support ICN has been
	provided in <xref target="I-D.ravi-icnrg-5gc-icn" format="default" sectionFormat="of" derivedContent="ICN-5GC"/>. 


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


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

	Network softwarization (using technologies like service
	orchestration frameworks leveraging NFV and SDN concepts) are
	now common in access networks and other network segments.
	Therefore, the ICN-as-a-Slice deployment configuration in
	<xref target="sec_icn_slice" format="default" sectionFormat="of" derivedContent="Section 4.4"/> provides a
	suitable migration path for the integration of non-IP-based
	edge networks into the overall system by virtue of
	realizing the relevant (ICN) protocols in an access network
	slice.
</t>
        <t pn="section-5.3-3">With the advent of SDN and NFV capabilities, so-called campus or
	site-specific deployments could see the introduction of ICN islands at
	the edge for scenarios such as gaming or deployments based on Augmented Reality
	(AR) / Virtual Reality (VR), e.g., smart cities or
	theme parks.</t>
      </section>
      <section anchor="sec_core_migration" numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-core-network-migration">Core Network Migration</name>
        <t pn="section-5.4-1">Migrating core networks of the Internet or mobile networks requires
	not only significant infrastructure renewal but also the fulfillment 
		of the key performance requirements, particularly in terms of
		throughput. For those parts of the core network that would
		migrate to an 
		SDN-based optical transport, the ICN-as-a-Slice deployment
		configuration in <xref target="sec_icn_slice" format="default" sectionFormat="of" derivedContent="Section 4.4"/>  would allow the introduction 
		of native ICN solutions within slices. This would allow for
		isolating the ICN traffic while addressing the specific ICN
		performance benefits 
		(such as in-network multicast or caching) and constraints (such
		as the need for specific network elements within such isolated
		slices). 
		For ICN solutions that natively work on top of SDN, the
		underlay deployment configuration in <xref target="sec_http_ip" format="default" sectionFormat="of" derivedContent="Section 4.3.2"/> provides an 
		additional migration path, preserving the IP-based services
		and applications at the edge of the network while realizing
		the core network 
		routing through an ICN solution (possibly itself realized in a
		slice of the SDN transport network). 
</t>
      </section>
    </section>
    <section anchor="sec_trial_experiences" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-deployment-trial-experience">Deployment Trial Experiences</name>
      <t pn="section-6-1">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" format="default" sectionFormat="of" derivedContent="Section 4"/>; therefore, we
		categorize the trial experiences according  
		to these deployment configurations. While a large body of
		work exists at the simulation or emulation level, we
		specifically exclude these studies 
		from our analysis to retain the focus on real-life
		experiences. 
</t>
      <section anchor="sec_overlay_deployment" numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-icn-as-an-overlay-2">ICN-as-an-Overlay</name>
        <section anchor="sec_pursuit" numbered="true" toc="include" removeInRFC="false" pn="section-6.1.1">
          <name slugifiedName="name-fp7-pursuit-efforts">FP7 PURSUIT Efforts</name>
          <t pn="section-6.1.1-1">Although the FP7 PURSUIT <xref target="IEEE_Communications" format="default" sectionFormat="of" derivedContent="IEEE_Communications"/> efforts were generally positioned as a
	  Clean-slate ICN replacement of IP 
		(<xref target="sec_replacements" format="default" sectionFormat="of" derivedContent="Section 4.1"/>), the
		project realized its experimental testbed as an L2 VPN-based
		overlay between several European, US, 
		and Asian sites, following the overlay deployment
		configuration presented in <xref target="sec_overlay" format="default" sectionFormat="of" derivedContent="Section 4.2"/>. Software-based forwarders were 
		utilized for the ICN message exchange, while native ICN
		applications (e.g., for video transmissions) were
		showcased. At the height of the project 
		efforts, about 70+ nodes were active in the (overlay) network
		with presentations given at several conferences, as well as to
		the ICNRG. 
</t>
        </section>
        <section anchor="sec_sail" numbered="true" toc="include" removeInRFC="false" pn="section-6.1.2">
          <name slugifiedName="name-fp7-sail-trial">FP7 SAIL Trial</name>
          <t pn="section-6.1.2-1"> The Network of Information (NetInf) is the approach to ICN
	  developed by the EU FP7 Scalable and Adaptive Internet Solutions
	  (SAIL) project <xref target="SAIL" format="default" sectionFormat="of" derivedContent="SAIL"/>.
		NetInf provides both name-based forwarding with CCNx-like
		semantics and name resolution (for indirection and
		late binding).  
		The NetInf architecture supports different deployment options
		through its convergence layer, such as using UDP, HTTP, and
		even DTN underlays. 
		In its first prototypes	and trials, NetInf was deployed mostly
		in an HTTP embedding and in a UDP overlay following the
		overlay deployment configuration in
		<xref target="sec_overlay" format="default" sectionFormat="of" derivedContent="Section 4.2"/>. <xref target="SAIL_Prototyping" format="default" sectionFormat="of" derivedContent="SAIL_Prototyping"/> describes several
		trials, including a stadium environment and 
		a multi-site testbed, leveraging NetInf's routing hint
		approach for routing scalability <xref target="SAIL_Content_Delivery" format="default" sectionFormat="of" derivedContent="SAIL_Content_Delivery"/>. 
		

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

</t>
          <t pn="section-6.1.5-3">The consortium has completed several ICN deployment trials. In a
	  post-disaster scenario trial <xref target="UMOBILE-8" format="default" sectionFormat="of" derivedContent="UMOBILE-8"/>, 
		a special DTN face was created to provide reachability to
		remote areas where there is no typical Internet 
		connection. Another trial was the ICN deployment over the
		"Guifi.net" community network in the Barcelona region. This
		trial 
		focused on the evaluation of an ICN edge computing platform,
		called PiCasso <xref target="UMOBILE-9" format="default" sectionFormat="of" derivedContent="UMOBILE-9"/>. In
		this  
		trial, ten (10) Raspberry Pis were deployed across Barcelona
		to create an ICN overlay network on top of the existing IP
		routing protocol 
		(e.g., qMp routing). This trial showed that ICN can play a key
		role in improving data delivery QoS and
		reducing the traffic in intermittent connectivity environments
		(e.g., wireless community network). A third trial in Italy was
		focused  
		on displaying the capability of the UMOBILE architecture to
		reach disconnected areas and assist responsible authorities in
		emergencies, 
		corresponding to an infrastructure scenario. The demonstration
		encompassed seven (7) end-user devices, one (1) access point,
		and one (1) gateway. 
</t>
        </section>
      </section>
      <section anchor="sec_underlay_deployment" numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-icn-as-an-underlay-2">ICN-as-an-Underlay</name>
        <section anchor="sec_point_rife" numbered="true" toc="include" removeInRFC="false" pn="section-6.2.1">
          <name slugifiedName="name-h2020-point-and-rife-effort">H2020 POINT and RIFE Efforts</name>
          <t pn="section-6.2.1-1">POINT and RIFE are two more ICN-related research projects of the
	  H2020 research program.
		The efforts in the H2020 POINT and RIFE projects follow the
		underlay deployment configuration in 
		<xref target="sec_http_ip" format="default" sectionFormat="of" derivedContent="Section 4.3.2"/>; edge-based NAPs
		provide the IP/HTTP-level protocol mapping onto 
		ICN protocol exchanges, while the SDN underlay (or the
		VPN-based L2 underlay) is used as a transport network.  
</t>
          <t pn="section-6.2.1-2">The multicast and service endpoint surrogate benefit in
	  HTTP-based scenarios, such as for 
		HTTP-level streaming video delivery, and have been demonstrated in
		the deployed POINT testbed with 
		80+ nodes being utilized. Demonstrations of this capability
		have been given to the ICNRG, 
		and public demonstrations were also provided at events <xref target="MWC_Demo" format="default" sectionFormat="of" derivedContent="MWC_Demo"/>. The trial has also been
		accepted by the ETSI MEC 
		group as a public proof-of-concept demonstration.
</t>
          <t pn="section-6.2.1-3">While the aforementioned demonstrations all use the overlay
	  deployment, H2020 also has performed ICN underlay trials. One such 
		trial involved commercial end users located in the PrimeTel
		network in Cyprus with the use case centered on IPTV and HLS
		video 
		dissemination. Another trial was performed over the
		"Guifi.net" community network in the Barcelona region, where
		the solution 
		was deployed in 40 households, providing general Internet
		connectivity to the residents. Standard IPTV Set-Top
		Boxes(STBs), as well as HLS video
		players, were utilized in accordance with the aim of this
		deployment configuration, namely to provide application and
		service migration.  
</t>
        </section>
        <section anchor="sec_flame" numbered="true" toc="include" removeInRFC="false" pn="section-6.2.2">
          <name slugifiedName="name-h2020-flame-efforts">H2020 FLAME Efforts</name>
          <t pn="section-6.2.2-1">The H2020 Facility for Large-Scale Adaptive Media Experimentation
	  (FLAME) efforts concentrate on providing an experimental
	  ground for the aforementioned POINT/RIFE 
		solution in initially two city-scale locations, namely in
		Bristol and Barcelona. This trial followed the 
		underlay deployment configuration in <xref target="sec_http_ip" format="default" sectionFormat="of" derivedContent="Section 4.3.2"/>, as per the POINT/RIFE
		approach.  Experiments 
		were conducted with the city/university joint venture
		Bristol-is-Open (BIO) to ensure the readiness of the 
		city-scale SDN transport network for such experiments. Another
		trial was for the ETSI MEC PoC. This trial 
		showcased operational benefits provided by the ICN underlay
		for the scenario of a location-based game. These 
		benefits aim at reduced network utilization through improved
		video delivery performance 
		(multicast of all captured videos to the service surrogates
		deployed in the city at six locations), 
		as well as reduced latency through the play out of the video
		originating from the local NAP, collocated with the 
		Wi-Fi Access Point (AP) instead of a remote server, i.e., the playout latency
		was bounded by the maximum single-hop latency. 
</t>
          <t pn="section-6.2.2-2"> Twenty three (23) large-scale media service experiments are
	  planned as part of the H2020 FLAME efforts 
		in the area of Future Media Internet (FMI). The platform,
		which includes the ICN capabilities, integrated with NFV 
		and SDN capabilities of the infrastructure. The ultimate goal
		of these platform efforts is the full 
		integration of ICN into the overall media function platform
		for the provisioning of advanced 
		(media-centric) Internet services.
</t>
        </section>
        <section anchor="sec_cablelabs" numbered="true" toc="include" removeInRFC="false" pn="section-6.2.3">
          <name slugifiedName="name-cablelabs-content-delivery-">CableLabs Content Delivery System</name>
          <t pn="section-6.2.3-1">The CableLabs ICN work reported in <xref target="White" format="default" sectionFormat="of" derivedContent="White"/> proposes an underlay deployment configuration
	  based on <xref target="sec_http_ip" format="default" sectionFormat="of" derivedContent="Section 4.3.2"/>. 
		The use case is ICN for content distribution within complex
		CDN server farms to leverage ICN's superior in-network caching
		properties. 
		This CDN based on "island of ICN" is then used to service
		standard HTTP/IP-based content retrieval requests coming from
		the general Internet. 
		This approach acknowledges that whole scale replacement (see
		<xref target="sec_replacements" format="default" sectionFormat="of" derivedContent="Section 4.1"/>) of
		existing HTTP/IP end-user applications 
		and related web infrastructure is a difficult proposition.
		<xref target="White" format="default" sectionFormat="of" derivedContent="White"/> is clear that the
		architecture proposed has not yet 
		been tested experimentally but that implementations are in
		process and expected in the 3-5 year time frame. 
</t>
        </section>
        <section anchor="sec_NDN_IoT" numbered="true" toc="include" removeInRFC="false" pn="section-6.2.4">
          <name slugifiedName="name-ndn-iot-trials">NDN IoT Trials</name>
          <t pn="section-6.2.4-1"><xref target="Baccelli" format="default" sectionFormat="of" derivedContent="Baccelli"/> summarizes the trial
	  of an NDN system adapted specifically for a wireless IoT scenario.
	  The trial was run with 
		60 nodes distributed over several multistory buildings in a
		university campus environment. The NDN protocols were
		optimized to run directly 
		over 6LoWPAN wireless link layers. The performance of the
		NDN-based IoT system was then compared to an equivalent system
		running standard IP-based IoT protocols. It was found that
		the NDN-based IoT 
		system was superior in several respects, including in terms of
		energy consumption and 
		for RAM and ROM footprints <xref target="Baccelli" format="default" sectionFormat="of" derivedContent="Baccelli"/> <xref target="Anastasiades" format="default" sectionFormat="of" derivedContent="Anastasiades"/>. For example, the binary file size
		reductions for 
		NDN protocol stack versus standard IP-based IoT protocol stack
		on given devices were up to 60% less for ROM size and up to
		80% less for RAM size. 
		
          
</t>
        </section>
        <section anchor="sec_NREN" numbered="true" toc="include" removeInRFC="false" pn="section-6.2.5">
          <name slugifiedName="name-nren-icn-testbed">NREN ICN Testbed</name>
          <t pn="section-6.2.5-1">The National Research and Education Network (NREN) ICN Testbed is
	  a project sponsored by Cisco, Internet2, and the US Research and
	  Education 
		community. Participants include universities and US federal
		government entities that connect via a nationwide VPN-based
		L2 underlay. The testbed 
		uses the CCNx approach and is based on the <xref target="CICN" format="default" sectionFormat="of" derivedContent="CICN"/> open-source software. There are
		approximately 15 nodes spread across the USA that
		connect to the testbed. The project's current focus is to
		advance data-intensive science and network research by
		improving data movement, searchability, 
		and accessibility.  
          
</t>
        </section>
        <section anchor="sec_Doctor" numbered="true" toc="include" removeInRFC="false" pn="section-6.2.6">
          <name slugifiedName="name-doctor-testbed">DOCTOR Testbed</name>
          <t pn="section-6.2.6-1">The DOCTOR project is a French research project meaning
	  "Deployment and Securisation of new Functionalities in Virtualized
	  Networking Environments". 
		The project aims to run NDN over virtualized NFV
		infrastructure <xref target="Doctor" format="default" sectionFormat="of" derivedContent="Doctor"/> (based
		on Docker technology) and focuses on the NFV MANO aspects 
		to build an operational NDN network focusing on important
		performance criteria, such as security, performance, and
		interoperability. 		 
          
</t>
          <t pn="section-6.2.6-2">The data plane relies on an HTTP/NDN gateway <xref target="Marchal" format="default" sectionFormat="of" derivedContent="Marchal"/> that processes HTTP traffic and
	  transports it in an optimized way over NDN to 
		 benefit from the properties of the NDN island (i.e., by
		 mapping HTTP semantics to NDN semantics within the
		 NDN island). The testbed carries 
		 real Web traffic of users and has been currently evaluated
		 with the top 1000 most popular websites. The users only
		 need to set the gateway 
		 as the web proxy. The control plane relies on a central
		 manager that uses machine-learning-based detection methods
		 <xref target="Mai-1" format="default" sectionFormat="of" derivedContent="Mai-1"/> 
		 from the date gathered by distributed probes and applies
		 orchestrated countermeasures against NDN attacks <xref target="Nguyen-1" format="default" sectionFormat="of" derivedContent="Nguyen-1"/>
            <xref target="Nguyen-2" format="default" sectionFormat="of" derivedContent="Nguyen-2"/> <xref target="Mai-2" format="default" sectionFormat="of" derivedContent="Mai-2"/> or performance issues. A remediation can be,
	    for example, the scale up of a bottleneck 
		 component or the deployment of a security function, like a
		 firewall or a signature verification module. Test results
		 thus far have indicated 
		 that key attacks can be detected accurately. For example,
		 content poisoning attacks can be detected at up to over 95%
		 accuracy (with less than 0.01% false positives) <xref target="Nguyen-3" format="default" sectionFormat="of" derivedContent="Nguyen-3"/>.
</t>
        </section>
      </section>
      <section anchor="sec_Other_configs" numbered="true" toc="include" removeInRFC="false" pn="section-6.3">
        <name slugifiedName="name-composite-icn-approach-2">Composite-ICN Approach</name>
        <t pn="section-6.3-1">Hybrid ICN <xref target="H-ICN_1" format="default" sectionFormat="of" derivedContent="H-ICN_1"/> <xref target="H-ICN_2" format="default" sectionFormat="of" derivedContent="H-ICN_2"/> is an approach where the ICN names
	are mapped to IPv6 addresses and other ICN information 
		is carried as payload inside the IP packet. This allows
		standard (ICN-unaware) IP routers to forward packets based on
		IPv6 info but enables ICN-aware 
		routers to apply ICN semantics. The intent is to enable rapid
		hybrid deployments and seamless interconnection of IP and
		Hybrid ICN domains. Hybrid ICN 
		uses <xref target="CICN" format="default" sectionFormat="of" derivedContent="CICN"/> open-source
		software.
		
        Initial tests have been done with 150 clients consuming DASH videos,
which showed good scalability properties at the server side using the
	Hybrid ICN transport <xref target="H-ICN_3" format="default" sectionFormat="of" derivedContent="H-ICN_3"/> <xref target="H-ICN_2" format="default" sectionFormat="of" derivedContent="H-ICN_2"/>.</t>
      </section>
      <section anchor="sec_trial_summary" numbered="true" toc="include" removeInRFC="false" pn="section-6.4">
        <name slugifiedName="name-summary-of-deployment-trial">Summary of Deployment Trials</name>
        <t pn="section-6.4-1">In summary, there have been significant trials over the years with
	all the major ICN protocol flavors (e.g., CCNx, NDN, and POINT) using both 
		the ICN-as-an-Overlay and ICN-as-an-Underlay deployment
		configurations. The major limitations of the trials include
		the fact that only a limited 
		number of applications have been tested. However, the tested
		applications include both native ICN and existing IP-based
		applications 
		(e.g., videoconferencing and IPTV). Another limitation of
	the trials is that all of them involve less than 1k users.</t>
        <t pn="section-6.4-2">Huawei and China Unicom have just started trials of the ICN-as-a-Slice configuration to demonstrate 
		ICN features of security, mobility, and bandwidth efficiency
		over a wired infrastructure using videoconferencing 
		as the application scenario <xref target="Chakraborti" format="default" sectionFormat="of" derivedContent="Chakraborti"/>; also, this prototype has been extended to
	demonstrate this over a 5G-NR access.</t>
        <t pn="section-6.4-3">The Clean-slate ICN approach has obviously never been in trials, as
	complete replacement of Internet 
		infrastructure (e.g., existing applications, TCP/IP protocol
	stack, IP routers, etc.) is no longer considered a viable
	alternative.</t>
        <t pn="section-6.4-4">Finally, Hybrid ICN is a Composite-ICN approach that offers an
	interesting alternative, as it allows ICN semantics to be embedded in
	standard 
		IPv6 packets so the packets can be routed through either IP
		routers or Hybrid ICN routers. Note that some other trials,
		such as the 
		DOCTOR testbed (<xref target="sec_Doctor" format="default" sectionFormat="of" derivedContent="Section 6.2.6"/>),
		could also be characterized as a Composite-ICN approach,
		because it contains both ICN gateways 
		(as in ICN-as-an-Underlay) and virtualized infrastructure (as
		in ICN-as-a-Slice). However, for the DOCTOR testbed, we have
		chosen to characterize 
		it as an ICN-as-an-Underlay configuration because that is a
		dominant characteristic. 
</t>
      </section>
    </section>
    <section anchor="sec_standards" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-deployment-issues-requiring">Deployment Issues Requiring Further Standardization</name>
      <t pn="section-7-1"><xref target="RFC7927" format="default" sectionFormat="of" derivedContent="RFC7927">"Information-Centric Networking (ICN) Research Challenges"</xref>
      describes key ICN principles and technical research topics. As the
      title suggests,  
		<xref target="RFC7927" format="default" sectionFormat="of" derivedContent="RFC7927"/> is research oriented
		without a specific focus on deployment or standardization
		issues. This section addresses this 
		open area by identifying key protocol functionality that
		may be relevant for further standardization effort in
		the IETF.
		The focus is specifically 
		on identifying protocols that will facilitate future
		interoperable ICN deployments correlating to the scenarios
		identified in the deployment 
		migration paths in <xref target="sec_migration" format="default" sectionFormat="of" derivedContent="Section 5"/>. The identified list of potential protocol
		functionality is not exhaustive. 

</t>
      <section anchor="sec_standards_apps" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-protocols-for-application-a">Protocols for Application and Service Migration</name>
        <t pn="section-7.1-1">End-user applications and services need a standardized approach to
	trigger ICN transactions. For example, in Internet and web
	applications 
		today, there are established socket APIs, communication
		paradigms (such as REST), common libraries, and best
		practices. We see a need to study 
		application requirements in an ICN environment further and, at
		the same time, develop new APIs and best practices that can
		take advantage of ICN 
		communication characteristics. 

</t>
      </section>
      <section anchor="sec_standards_cdn" numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-protocols-for-content-deliv">Protocols for Content Delivery Network Migration</name>
        <t pn="section-7.2-1">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" sectionFormat="of" derivedContent="RFC6920"/> defines a mechanism that is suitable for
		static naming of ICN data objects. Other 
		ways of encoding and representing ICN names have been
		described in <xref target="RFC8609" format="default" sectionFormat="of" derivedContent="RFC8609"/> and 
		<xref target="RFC8569" format="default" sectionFormat="of" derivedContent="RFC8569"/>. Naming dynamically
		generated data requires different approaches(e.g.,
		hash-digest-based names would normally not work), and there is
		a lack of established conventions and standards.  

        </t>
        <t pn="section-7.2-2">Another CDN issue for ICN is related to multicast distribution of
	content.
                Existing CDNs have started using multicast mechanisms for 
		certain cases, such as for broadcasting streaming TV.  However, as
		discussed in <xref target="sec_point_rife" format="default" sectionFormat="of" derivedContent="Section 6.2.1"/>,
		certain ICN approaches provide 
		substantial improvements over IP multicast, such as the
		implicit support for multicast retrieval of content in all ICN
		flavors.		 
</t>
        <t pn="section-7.2-3">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" numbered="true" toc="include" removeInRFC="false" pn="section-7.3">
        <name slugifiedName="name-protocols-for-edge-and-core">Protocols for Edge and Core Network Migration</name>
        <t pn="section-7.3-1">ICN provides the potential to redesign current edge and core
	network computing approaches. Leveraging ICN's inherent security and
	its ability 
		to make name data and dynamic computation results available
		independent of location can enable a lightweight insertion
		of traffic  
		into the network without relying on redirection of DNS
		requests. For this, proxies that translate from commonly used
		protocols in the general 
		Internet to ICN message exchanges in the ICN domain could be
		used for the migration of application and services within
		deployments at the network 
		edge but also in core networks. This is similar to existing
		approaches for IoT scenarios where a proxy translates CoAP
		request/responses to other 
		message formats. For example, <xref target="RFC8075" format="default" sectionFormat="of" derivedContent="RFC8075"/> specifies proxy mapping between CoAP and
		HTTP protocols. Also, <xref target="RFC8613" format="default" sectionFormat="of" derivedContent="RFC8613"/> 
		is an example of how to pass end-to-end encrypted content
		between HTTP and CoAP by an application-layer security
		mechanism. Further work is required
		to identify if an approach like <xref target="RFC8613" format="default" sectionFormat="of" derivedContent="RFC8613"/>, or some other approach, is
		suitable to preserve ICN message security through future
		protocol 
		translation functions of gateways/proxies.
</t>
        <t pn="section-7.3-2">Interaction and interoperability between existing IP routing
	protocols (e.g., OSPF, RIP, or IS-IS) and ICN routing
	approaches (e.g.,
	NFD and CCNx routers) 
		are expected, especially in the overlay approach. Another
		important topic is the integration of ICN into networks that
		support virtualized infrastructure 
		in the form of NFV/SDN and most likely utilize SFC as a key
		protocol. Further work is required to validate this idea and
		document best practices.  
</t>
        <t pn="section-7.3-3">There are several existing approaches to supporting QoS in IP
	networks, including Diffserv, IntServ, and RSVP. Some initial ideas
	for QoS support in ICN 
		networks are outlined in <xref target="I-D.moiseenko-icnrg-flowclass" format="default" sectionFormat="of" derivedContent="FLOW-CLASS"/>,
		which proposes an approach based on flow
		classification to enable
		functions, such ICN 
		rate control and cache control. Also, <xref target="I-D.anilj-icnrg-icn-qos" format="default" sectionFormat="of" derivedContent="ICN-QoS"/> proposes
		how to use Diffserv Differentiated Services Code Point (DSCP)
		codes to support QoS for ICN-based data 
		path delivery. Further work is required to identify the best
		approaches for support of QoS in ICN networks. 
</t>
        <t pn="section-7.3-4">OAM is a crucial area that has not yet been fully addressed by the
	ICN research community but which is obviously critical for future
	deployments of ICN. 
	  Potential areas that need investigation include whether the YANG
	  data modeling approach and associated NETCONF/RESTCONF protocols
	  need any specific updates 
	  for ICN support. Another open area is how to measure and benchmark
	  performance of ICN networks comparable to the sophisticated
	  techniques that exist for standard 
	  IP networks, virtualized networks, and data centers. It should be
	  noted that some initial progress has been made in the area of ICN
	  network path traceroute 
	  facility with approaches, such as CCNxinfo <xref target="I-D.irtf-icnrg-ccninfo" format="default" sectionFormat="of" derivedContent="CNNinfo"/> <xref target="Contrace" format="default" sectionFormat="of" derivedContent="Contrace"/>. 
</t>
      </section>
      <section anchor="sec_ICN_Challenges_Summary_Gaps" numbered="true" toc="include" removeInRFC="false" pn="section-7.4">
        <name slugifiedName="name-summary-of-icn-protocol-gap">Summary of ICN Protocol Gaps and Potential Protocol Efforts</name>
        <t pn="section-7.4-1">Without claiming completeness, <xref target="tab_mapping_protocol_effort" format="default" sectionFormat="of" derivedContent="Table 1"/> maps the open
	ICN issues identified in this document to potential protocol efforts
	that could address some aspects of the gap.
</t>
        <table anchor="tab_mapping_protocol_effort" align="center" pn="table-1">
          <name slugifiedName="name-mapping-of-icn-gaps-to-pote">Mapping of ICN Gaps to Potential Protocol Efforts</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">ICN Gap</th>
              <th align="left" colspan="1" rowspan="1">Potential Protocol Effort</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">1-Support of REST APIs</td>
              <td align="left" colspan="1" rowspan="1">HTTP/CoAP support of ICN semantics</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">2-Naming</td>
              <td align="left" colspan="1" rowspan="1">Dynamic naming of ICN data objects</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">3-Routing</td>
              <td align="left" colspan="1" rowspan="1">Interactions between IP and ICN routing protocols</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">4-Multicast distribution</td>
              <td align="left" colspan="1" rowspan="1">Multicast enhancements for ICN</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">5-In-network caching</td>
              <td align="left" colspan="1" rowspan="1">ICN cache placement and sharing</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">6-NFV/SDN support</td>
              <td align="left" colspan="1" rowspan="1">Integration of ICN with NFV/SDN and including
	      possible impacts to SFC</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">7-ICN mapping</td>
              <td align="left" colspan="1" rowspan="1">Mapping of HTTP and other protocols onto ICN
	      message exchanges (and vice versa) while preserving ICN message
	      security</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">8-QoS support</td>
              <td align="left" colspan="1" rowspan="1">Support of ICN QoS via mechanisms, such as
	      Diffserv and flow classification</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">9-OAM support</td>
              <td align="left" colspan="1" rowspan="1">YANG data models, NETCONF/RESTCONF protocols, and
	      network-performance measurements</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="sec_conclusion" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-conclusion">Conclusion</name>
      <t pn="section-8-1">This document provides high-level deployment considerations for
      current and future members of the ICN community. Specifically, the 
	  major configurations of possible ICN deployments are identified as
	  (1) Clean-slate ICN replacement of existing Internet infrastructure, 
	  (2) ICN-as-an-Overlay, (3) ICN-as-an-Underlay, (4) ICN-as-a-Slice,
	  and (5) Composite-ICN. Existing ICN trial systems primarily fall 
	  under the ICN-as-an-Overlay, ICN-as-an-Underlay, and Composite-ICN
	  configurations.    
      </t>
      <t pn="section-8-2">In terms of deployment migration paths, ICN-as-an-Underlay offers a
      clear migration path for CDN, edge, or core networks to go to an 
	  ICN paradigm (e.g., for an IoT deployment) while leaving the
	  critical mass of existing end-user applications untouched.
	  ICN-as-an-Overlay is 
	  the easiest configuration to deploy rapidly, as it leaves the
	  underlying IP infrastructure essentially untouched. However, its 
	  applicability for general deployment must be considered on a
	  case-by-case basis. (That is, can it support all required user
	  applications?). 
	  ICN-as-a-Slice is an attractive deployment option for upcoming 5G
	  systems (i.e., for 5G radio and core networks) that will naturally 
	  support network slicing, but this still has to be validated through
	  more trial experiences. Composite-ICN, by its nature, can combine 
	  some of the best characteristics of the other configurations, but
	  its applicability for general deployment must again be considered 
	  on a case-by-case basis (i.e., can enough IP routers be upgraded to
	  support Composite-ICN functionality to provide sufficient 
	  performance benefits?).
      </t>
      <t pn="section-8-3">There has been significant trial experience with all the major ICN
      protocol flavors (e.g., CCNx, NDN, and POINT). However, only a limited  
	  number of applications have been tested so far, and the maximum
	  number of users in any given trial has been less than 1k users. It
	  is 
	  recommended that future ICN deployments scale their users gradually
	  and closely monitor network performance as they go above 1k users. 
	  A logical approach would be to increase the number of users in a
	  slowly increasing linear manner and monitor network performance and 
	  stability, especially at every multiple of 1k users.
      </t>
      <t pn="section-8-4">Finally, this document describes a set of technical features in ICN
      that warrant potential future IETF specification work. This will 
	  aid initial and incremental deployments to proceed in an
	  interoperable manner. The fundamental details of the potential
	  protocol specification 
	  effort, however, are best left for future study by the appropriate
	  IETF WGs and/or BoFs. The ICNRG can aid this process in the 
	  near and mid-term by continuing to examine key system issues like
	  QoS mechanisms, flexible naming schemes, and OAM support for ICN. 
      </t>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t pn="section-9-1">This document has no IANA actions.
      </t>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t pn="section-10-1">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" sectionFormat="of" derivedContent="RFC7945"/> has an extensive discussion of
	  various aspects of ICN security,
	  including many that are relevant to deployments. Specifically,
	  <xref target="RFC7945" format="default" sectionFormat="of" derivedContent="RFC7945"/> points out that ICN access
	  control, privacy, security 
	  of in-network caches, and protection against various network attacks
	  (e.g., DoS) have not yet been fully developed due to the lack of a
	  sufficient 
	  mass of deployments.  <xref target="RFC7945" format="default" sectionFormat="of" derivedContent="RFC7945"/> 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" sectionFormat="of" derivedContent="RFC7945"/> points out that as secure
	  communications in the existing Internet (e.g., HTTPS) 
	  become the norm, major gaps in ICN security will inevitably
	  slow down the adoption of ICN.
      </t>
      <t pn="section-10-2">In addition to the security findings of <xref target="RFC7945" format="default" sectionFormat="of" derivedContent="RFC7945"/>, this document has highlighted that all anticipated
      ICN deployment configurations 
	  will involve coexistence with existing Internet infrastructure and
	  applications. Thus, even the basic authentication and encryption
	  properties of ICN 
	  content will need to account for interworking with non-ICN content
	  to preserve end-to-end security. For example, in the edge network
	  underlay deployment 
	  configuration described in <xref target="sec_application_gateways" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>, the gateway/proxy that translates HTTP or CoAP
	  request/responses into ICN message 
	  exchanges will need to support a security model to preserve
	  end-to-end security. One alternative would be to consider an
	  approach similar to  
	  <xref target="RFC8613" format="default" sectionFormat="of" derivedContent="RFC8613"/>, which is used to pass
	  end-to-end encrypted content between HTTP and CoAP by an
	  application-layer security mechanism. Further  
	  investigation is required to see if this approach is suitable to
	  preserve ICN message security through future protocol translation
	  functions (e.g., ICN to HTTP or CoAP to ICN) of gateways/proxies.
      </t>
      <t pn="section-10-3">Finally, the DOCTOR project discussed in <xref target="sec_Doctor" format="default" sectionFormat="of" derivedContent="Section 6.2.6"/> is an example of an early deployment that is looking
      at specific attacks against 
	  ICN infrastructure, in this case, looking at Interest Flooding
	  Attacks <xref target="Nguyen-2" format="default" sectionFormat="of" derivedContent="Nguyen-2"/> and Content
	  Poisoning Attacks <xref target="Nguyen-1" format="default" sectionFormat="of" derivedContent="Nguyen-1"/>
        <xref target="Mai-2" format="default" sectionFormat="of" derivedContent="Mai-2"/> <xref target="Nguyen-3" format="default" sectionFormat="of" derivedContent="Nguyen-3"/> and evaluating potential countermeasures based
	on MANO-orchestrated actions on the virtualized infrastructure <xref target="Mai-1" format="default" sectionFormat="of" derivedContent="Mai-1"/>.  
      </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 pn="section-11">
      <name slugifiedName="name-informative-references">Informative References</name>
      <reference anchor="Anastasiades" target="http://boris.unibe.ch/83683/1/16anastasiades_c.pdf" quoteTitle="true" derivedAnchor="Anastasiades">
        <front>
          <title>Information-centric communication in mobile and wireless networks</title>
          <author initials="C" surname="Anastasiades" fullname="Carlos         Anastasiades">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="June" year="2016"/>
        </front>
        <seriesInfo name="DOI" value="10.7892/boris.83683"/>
        <refcontent>PhD Dissertation</refcontent>
      </reference>
      <reference anchor="Baccelli" target="http://conferences2.sigcomm.org/acm-icn/2014/papers/p77.pdf" quoteTitle="true" derivedAnchor="Baccelli">
        <front>
          <title>Information Centric Networking in the IoT: Experiments with NDN in the Wild</title>
          <author>
            <organization showOnFrontPage="true">Baccelli, E., et al.</organization>
          </author>
          <date month="September" year="2014"/>
        </front>
        <seriesInfo name="DOI" value="10.1145/2660129.2660144"/>
        <refcontent>ACM-ICN '14: Proceedings of the 1st ACM Conference on
	Information-Centric Networking</refcontent>
      </reference>
      <reference anchor="I-D.ietf-bier-multicast-http-response" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-bier-multicast-http-response-03" derivedAnchor="BIER">
        <front>
          <title>Applicability of BIER Multicast Overlay for Adaptive Streaming Services</title>
          <author initials="D" surname="Trossen" fullname="Dirk Trossen">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A" surname="Rahman" fullname="Akbar Rahman">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C" surname="Wang" fullname="Chonggang Wang">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="T" surname="Eckert" fullname="Toerless Eckert">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="February" day="4" year="2020"/>
          <abstract>
            <t>HTTP Level multicast, using BIER, is described as a use case in the BIER Use Cases document.  HTTP Level Multicast is used in today's video streaming and delivery services such as HLS, AR/VR etc., generally realized over IP Multicast as well as other use cases such as software update delivery.  A realization of "HTTP Multicast" over "IP Multicast" is described for the video delivery use case.  IP multicast is commonly used for IPTV services.  DVB and BBF is also developing a reference architecture for IP Multicast service.  A few problems with IP Multicast, such as waste of transmission bandwidth, increase in signaling when there are few users are described. Realization over BIER, through a BIER Multicast Overlay Layer, is described as an alternative.  How BIER Multicast Overlay operation improves over IP Multicast, such as reduction in signaling, dynamic creation of multicast groups to reduce signaling and bandwidth wastage is described.  We conclude with few next steps.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-bier-multicast-http-response-03"/>
        <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-bier-multicast-http-response-03.txt"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="CCNx_UDP" target="https://www.ietf.org/proceedings/interim-2015-icnrg-04/slides/slides-interim-2015-icnrg-4-5.pdf" quoteTitle="true" derivedAnchor="CCNx_UDP">
        <front>
          <title>CCNx Over UDP</title>
          <author>
            <organization showOnFrontPage="true">PARC</organization>
          </author>
        </front>
      </reference>
      <reference anchor="Chakraborti" quoteTitle="true" target="https://doi.org/10.1109/HOTICN.2018.8605980" derivedAnchor="Chakraborti">
        <front>
          <title>Design and Evaluation of a Multi-source Multi-destination Real-time Application on Content Centric Network</title>
          <author>
            <organization showOnFrontPage="true">Chakraborti, A., et al.</organization>
          </author>
          <date month="August" year="2018"/>
        </front>
        <seriesInfo name="DOI" value="10.1109/HOTICN.2018.8605980"/>
        <refcontent>2018 1st IEEE International Conference on Hot
	  Information-Centric Networking (HotICN)</refcontent>
      </reference>
      <reference anchor="CICN" target="https://wiki.fd.io/view/Cicn" quoteTitle="true" derivedAnchor="CICN">
        <front>
          <title>Cicn</title>
          <author>
            <organization showOnFrontPage="true">fd.io</organization>
          </author>
        </front>
      </reference>
      <reference anchor="I-D.irtf-icnrg-ccninfo" quoteTitle="true" target="https://tools.ietf.org/html/draft-irtf-icnrg-ccninfo-04" derivedAnchor="CNNinfo">
        <front>
          <title>CCNinfo: Discovering Content and Network Information in Content-Centric Networks</title>
          <author initials="H" surname="Asaeda" fullname="Hitoshi Asaeda">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A" surname="Ooka" fullname="Atsushi Ooka">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="X" surname="Shao" fullname="Xun Shao">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="March" day="22" year="2020"/>
          <abstract>
            <t>This document describes a mechanism named "CCNinfo" that discovers information about the network topology and in-network cache in Content-Centric Networks (CCN).  CCNinfo investigates: 1) the CCN routing path information per name prefix, 2) the Round-Trip Time (RTT) between the content forwarder and consumer, and 3) the states of in-network cache per name prefix.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-ccninfo-04"/>
        <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-irtf-icnrg-ccninfo-04.txt"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="CONET" target="http://netgroup.uniroma2.it/Stefano_Salsano/papers/salsano-icc12-wshop-sdn.pdf" quoteTitle="true" derivedAnchor="CONET">
        <front>
          <title>Supporting Information-Centric Functionality in Software Defined Networks</title>
          <author>
            <organization showOnFrontPage="true">Veltri, L., et al.</organization>
          </author>
          <date month="November" year="2012"/>
        </front>
        <seriesInfo name="DOI" value="10.1109/ICC.2012.6364916"/>
        <refcontent>2012 IEEE International Conference on Communications (ICC)</refcontent>
      </reference>
      <reference anchor="Contrace" quoteTitle="true" target="https://doi.org/10.1109/MCOM.2015.7060502" derivedAnchor="Contrace">
        <front>
          <title>Contrace: a tool for measuring and tracing content-centric networks</title>
          <author>
            <organization showOnFrontPage="true">Asaeda, H., et al.</organization>
          </author>
          <date month="March" year="2015"/>
        </front>
        <seriesInfo name="DOI" value="10.1109/MCOM.2015.7060502"/>
        <refcontent> IEEE Communications Magazine, Volume 53, Issue 3</refcontent>
      </reference>
      <reference anchor="CUTEi" quoteTitle="true" target="https://doi.org/10.1109/MNET.2014.6963806" derivedAnchor="CUTEi">
        <front>
          <title>Container-Based Unified Testbed for Information Centric Networking</title>
          <author initials="H." surname="Asaeda" fullname="Hitoshi Asaeda">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="R." surname="Li" fullname="Ruidong Li">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="N." surname="Choi" fullname="Nakjung Choi">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="November" year="2014"/>
        </front>
        <seriesInfo name="DOI" value="10.1109/MNET.2014.6963806"/>
        <refcontent>IEEE Network Volume 28, Issue:6</refcontent>
      </reference>
      <reference anchor="C_FLOW" target="https://ieeexplore.ieee.org/document/6799480" quoteTitle="true" derivedAnchor="C_FLOW">
        <front>
          <title>C_flow: An efficient content delivery framework with OpenFlow</title>
          <author>
            <organization showOnFrontPage="true">D. Chang, et al.</organization>
          </author>
          <date month="February" year="2014"/>
        </front>
        <refcontent>The International Conference on Information
	Networking 2014 (ICOIN2014)</refcontent>
        <refcontent>pp. 270-275</refcontent>
        <seriesInfo name="DOI" value="10.1109/ICOIN.2014.6799480"/>
      </reference>
      <reference anchor="I-D.mendes-icnrg-dabber" quoteTitle="true" target="https://tools.ietf.org/html/draft-mendes-icnrg-dabber-04" derivedAnchor="DABBER">
        <front>
          <title>Information-centric Routing for Opportunistic Wireless Networks</title>
          <author initials="P" surname="Mendes" fullname="Paulo Mendes">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="R" surname="Sofia" fullname="Rute Sofia">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="V" surname="Tsaoussidis" fullname="Vassilis Tsaoussidis">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C" surname="Borrego" fullname="Carlos Borrego">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="March" day="14" year="2020"/>
          <abstract>
            <t>This draft describes the Data reAchaBility BasEd Routing (DABBER) protocol, which aims to extend the operation of distributed Information Centric Networking frameworks to opportunistic wireless networks such as Delay Tolerant Networks.  By "opportunistic wireless networks" it is meant multi-hop wireless networks where finding an end-to-end path between any pair of nodes at any moment in time may be a challenge.  The goal is to assist in better defining opportunities for the transmission of Interest and Data packets in a store-carry-and-forward manner, based on a combination of proactive and reactive approaches.  The document presents an architectural overview of DABBER followed by the specification of the proactive approach based on the dissemination of name-prefix information, and the reactive approach based on the encounters probability.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-mendes-icnrg-dabber-04"/>
        <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-mendes-icnrg-dabber-04.txt"/>
        <format type="PDF" target="http://www.ietf.org/internet-drafts/draft-mendes-icnrg-dabber-04.pdf"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="DASH" target="http://dashif.org/" quoteTitle="true" derivedAnchor="DASH">
        <front>
          <title>DASH Industry Forum</title>
          <author>
            <organization showOnFrontPage="true">DASH</organization>
          </author>
        </front>
      </reference>
      <reference anchor="Doctor" target="http://www.doctor-project.org/index.htm" quoteTitle="true" derivedAnchor="Doctor">
        <front>
          <title>Deployment and securisation of new functionalities in virtualized networking environments</title>
          <author>
            <organization showOnFrontPage="true">DOCTOR</organization>
          </author>
        </front>
      </reference>
      <reference anchor="fiveG-23501" quoteTitle="true" derivedAnchor="fiveG-23501">
        <front>
          <title>System Architecture for the 5G System</title>
          <author>
            <organization showOnFrontPage="true">3GPP</organization>
          </author>
          <date month="December" year="2017"/>
        </front>
        <seriesInfo name="3GPP" value="TS 23.501"/>
        <refcontent>Release 15</refcontent>
      </reference>
      <reference anchor="fiveG-23502" quoteTitle="true" derivedAnchor="fiveG-23502">
        <front>
          <title>Procedures for the 5G System (5GS)</title>
          <author>
            <organization showOnFrontPage="true">3GPP</organization>
          </author>
        </front>
        <seriesInfo name="3GPP" value="TS 23.502"/>
        <refcontent>Release 15</refcontent>
      </reference>
      <reference anchor="I-D.moiseenko-icnrg-flowclass" quoteTitle="true" target="https://tools.ietf.org/html/draft-moiseenko-icnrg-flowclass-05" derivedAnchor="FLOW-CLASS">
        <front>
          <title>Flow Classification in Information Centric Networking</title>
          <author initials="I" surname="Moiseenko" fullname="Ilya Moiseenko">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="D" surname="Oran" fullname="David Oran">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="January" day="20" year="2020"/>
          <abstract>
            <t>For the ubiquitous and highly important Internet protocols (TCP, UDP, IP), flows are conventionally identified by the "5-tuple" of source and destination IP addresses, source and destination port, and protocol type in an IP packet.  Information Centric Networking (ICN) is a new paradigm where network communications are accomplished by requesting named content, instead of sending packets to destination addresses.  This document describes mechanisms allowing ICN forwarders, consumers, producers and other ICN nodes to encode, decode, and process equivalence class identifiers (flows) at any desired granularity of a routable name prefix and beyond the routable name prefix.  This document is a product of the IRTF Information- Centric Networking Research Group (ICNRG).</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-moiseenko-icnrg-flowclass-05"/>
        <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-moiseenko-icnrg-flowclass-05.txt"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="GEANT" target="https://www.geant.org/" quoteTitle="true" derivedAnchor="GEANT">
        <front>
          <title>GEANT</title>
          <author>
            <organization showOnFrontPage="true">GEANT</organization>
          </author>
        </front>
      </reference>
      <reference anchor="H-ICN_1" target="http://blogs.cisco.com/sp/cisco-announces-important-steps-toward-adoption-of-information-centric-networking" quoteTitle="true" derivedAnchor="H-ICN_1">
        <front>
          <title>Cisco Announces Important Steps toward Adoption of Information-Centric Networking</title>
          <author>
            <organization showOnFrontPage="true">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" quoteTitle="true" derivedAnchor="H-ICN_2">
        <front>
          <title>Mobile Video Delivery with Hybrid ICN: IP-integrated ICN Solution for 5G</title>
          <author>
            <organization showOnFrontPage="true">Cisco</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" quoteTitle="true" derivedAnchor="H-ICN_3">
        <front>
          <title>Hybrid Information-Centric Networking: ICN inside the Internet Protocol</title>
          <author>
            <organization showOnFrontPage="true">Muscariello, L., et al</organization>
          </author>
          <date month="March" year="2018"/>
        </front>
        <refcontent>ICNRG Interim Meeting</refcontent>
      </reference>
      <reference anchor="I-D.ravi-icnrg-5gc-icn" quoteTitle="true" target="https://tools.ietf.org/html/draft-ravi-icnrg-5gc-icn-04" derivedAnchor="ICN-5GC">
        <front>
          <title>Enabling ICN in 3GPP's 5G NextGen Core Architecture</title>
          <author initials="R" surname="Ravindran" fullname="Ravi Ravindran">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="P" surname="Suthar" fullname="Prakash Suthar">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="D" surname="Trossen" fullname="Dirk Trossen">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C" surname="Wang" fullname="Chonggang Wang">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="G" surname="White" fullname="Greg White">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="May" day="31" year="2019"/>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ravi-icnrg-5gc-icn-04"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="I-D.paik-icn-deployment-considerations" quoteTitle="true" target="https://tools.ietf.org/html/draft-paik-icn-deployment-considerations-00" derivedAnchor="ICN-DEP-CON">
        <front>
          <title>Deployment Considerations for Information-Centric Networking</title>
          <author initials="E" surname="Paik" fullname="EunKyoung Paik">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="W" surname="Yun" fullname="Won-Dong Yun">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="T" surname="Kwon" fullname="Taekyoung Kwon">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="H" surname="Choi" fullname="Hoon-gyu Choi">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="July" day="15" year="2013"/>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-paik-icn-deployment-considerations-00"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="I-D.irtf-icnrg-icniot" quoteTitle="true" target="https://tools.ietf.org/html/draft-irtf-icnrg-icniot-03" derivedAnchor="ICN-IoT">
        <front>
          <title>Design Considerations for Applying ICN to IoT</title>
          <author initials="R" surname="Ravindran" fullname="Ravi Ravindran">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="Y" surname="Zhang" fullname="Yanyong Zhang">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="L" surname="Grieco" fullname="Luigi Grieco">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A" surname="Lindgren" fullname="Anders Lindgren">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="J" surname="Burke" fullname="Jeff Burke">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="B" surname="Ahlgren" fullname="Bengt Ahlgren">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A" surname="Azgin" fullname="Aytac Azgin">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="May" day="2" year="2019"/>
          <abstract>
            <t>The Internet of Things (IoT) promises to connect billions of objects to the Internet.  After deploying many stand-alone IoT systems in different domains, the current trend is to develop a common, "thin waist" of protocols to enable a horizontally unified IoT architecture.  The objective of such an architecture is to make resource objects securely accessible to applications across organizations and domains.  Towards this goal, quite a few proposals have been made to build an application-layer based unified IoT platform on top of today's host-centric Internet.  However, there is a fundamental mismatch between the host-centric nature of today's Internet and the mostly information-centric nature of the IoT domain. To address this mismatch, the common set of protocols and network services offered by an information-centric networking (ICN) architecture can be leveraged to realize an ICN-based IoT (or ICN- IoT) architecture that can take advantage of the salient features of ICN such as naming, security, mobility, compute and efficient content and service delivery support offered by it.  In this draft, we summarize the general IoT demands, and ICN features that support these requirements, and then discuss the challenges to realize an ICN-based IoT framework.  Beyond this, the goal of this draft is not to offer any specific ICN-IoT architectural proposal.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-icniot-03"/>
        <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-irtf-icnrg-icniot-03.txt"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="I-D.irtf-icnrg-icn-lte-4g" quoteTitle="true" target="https://tools.ietf.org/html/draft-irtf-icnrg-icn-lte-4g-05" derivedAnchor="ICN-LTE-4G">
        <front>
          <title>Native Deployment of ICN in LTE, 4G Mobile Networks</title>
          <author initials="P" surname="Suthar" fullname="Prakash Suthar">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="M" surname="Stolic" fullname="Milan Stolic">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A" surname="Jangam" fullname="Anil Jangam" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="D" surname="Trossen" fullname="Dirk Trossen">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="R" surname="Ravindran" fullname="Ravi Ravindran">
            <organization showOnFrontPage="true"/>
          </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"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="I-D.anilj-icnrg-icn-qos" quoteTitle="true" target="https://tools.ietf.org/html/draft-anilj-icnrg-icn-qos-00" derivedAnchor="ICN-QoS">
        <front>
          <title>Supporting QoS aware Data Delivery in Information Centric Networks</title>
          <author initials="A" surname="Jangam" fullname="Anil Jangam">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="P" surname="Suthar" fullname="Prakash Suthar">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="M" surname="Stolic" fullname="Milan Stolic">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="July" day="14" year="2018"/>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-anilj-icnrg-icn-qos-00"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="I-D.irtf-icnrg-terminology" quoteTitle="true" target="https://tools.ietf.org/html/draft-irtf-icnrg-terminology-08" derivedAnchor="ICN-TERM">
        <front>
          <title>Information-Centric Networking (ICN): CCNx and NDN Terminology</title>
          <author initials="B" surname="Wissingh" fullname="Bastiaan Wissingh">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C" surname="Wood" fullname="Christopher Wood">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A" surname="Afanasyev" fullname="Alex Afanasyev">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="L" surname="Zhang" fullname="Lixia Zhang">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="D" surname="Oran" fullname="David Oran">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C" surname="Tschudin" fullname="Christian Tschudin">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="January" day="17" year="2020"/>
          <abstract>
            <t>Information Centric Networking (ICN) is a novel paradigm where network communications are accomplished by requesting named content, instead of sending packets to destination addresses.  Named Data Networking (NDN) and Content-Centric Networking (CCNx) are two prominent ICN architectures.  This document provides an overview of the terminology and definitions that have been used in describing concepts in these two implementations of ICN.  While there are other ICN architectures, they are not part of the NDN and CCNx concepts and as such are out of scope for this document.  This document is a product of the Information-Centric Networking Research Group (ICNRG).</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-terminology-08"/>
        <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-irtf-icnrg-terminology-08.txt"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="ICN2020-Experiments" target="https://projects.gwdg.de/attachments/6840/D4.1-PU.pdf" quoteTitle="true" derivedAnchor="ICN2020-Experiments">
        <front>
          <title>D4.1: 1st Yearly WP4 Report &amp; Demonstration</title>
          <author>
            <organization showOnFrontPage="true">ICN2020</organization>
          </author>
          <date month="August" year="2017"/>
        </front>
      </reference>
      <reference anchor="ICN2020-overview" target="http://www.icn2020.org/" quoteTitle="true" derivedAnchor="ICN2020-overview">
        <front>
          <title>ICN2020 Project Overview</title>
          <author>
            <organization showOnFrontPage="true">ICN2020</organization>
          </author>
        </front>
      </reference>
      <reference anchor="ICNRGCharter" target="https://datatracker.ietf.org/doc/charter-irtf-icnrg/" quoteTitle="true" derivedAnchor="ICNRGCharter">
        <front>
          <title>Information-Centric Networking Research Group Charter</title>
          <author>
            <organization showOnFrontPage="true">IRTF</organization>
          </author>
        </front>
      </reference>
      <reference anchor="IEEE_Communications" quoteTitle="true" target="https://doi.org/10.1109/MCOM.2012.6231280" derivedAnchor="IEEE_Communications">
        <front>
          <title>Designing and realizing an information-centric internet</title>
          <author initials="D." surname="Trossen" fullname="Dirk Trossen">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="G." surname="Parisis" fullname="George Parisis">
            <organization showOnFrontPage="true"/>
          </author>
          <date/>
        </front>
        <seriesInfo name="DOI" value="10.1109/MCOM.2012.6231280"/>
        <refcontent>IEEE Communications Magazine, Volume 50, Issue 7</refcontent>
      </reference>
      <reference anchor="Internet_Pricing" quoteTitle="true" target="https://doi.org/10.1145/1921233.1921235" derivedAnchor="Internet_Pricing">
        <front>
          <title>Not paying the truck driver: differentiated pricing for the future internet</title>
          <author initials="D." surname="Trossen" fullname="Dirk Trossen">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="G." surname="Biczok" fullname="Gergely Biczok">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="November" year="2010"/>
        </front>
        <seriesInfo name="ReArch '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="Jacobson" quoteTitle="true" target="https://doi.org/10.1145/1658939.1658941" derivedAnchor="Jacobson">
        <front>
          <title>Networking Named Content</title>
          <author>
            <organization showOnFrontPage="true">Jacobson, V., et al.</organization>
          </author>
          <date month="December" year="2009"/>
        </front>
        <seriesInfo name="DOI" value="10.1145/1658939.1658941"/>
        <refcontent>CoNEXT '09: Proceedings of the 5th international
	conference on Emerging networking experiments and technologies</refcontent>
      </reference>
      <reference anchor="Jangam" target="https://dl.acm.org/citation.cfm?id=3132351" quoteTitle="true" derivedAnchor="Jangam">
        <front>
          <title>nlsrSIM: Porting and Simulation of Named-data Link State Routing Protocol into ndnSIM</title>
          <author>
            <organization showOnFrontPage="true">Jangam, A., et al.</organization>
          </author>
          <date month="November" year="2017"/>
        </front>
        <seriesInfo name="DOI" value="10.1145/3132340.3132351"/>
        <refcontent>DIVANet '17: Proceedings of the 6th ACM Symposium on
	  Development and Analysis of Intelligent Vehicular Networks and Applications</refcontent>
      </reference>
      <reference anchor="Mai-1" target="https://ieeexplore.ieee.org/document/8401591" quoteTitle="true" derivedAnchor="Mai-1">
        <front>
          <title>Implementation of content poisoning attack detection and reaction in virtualized NDN networks</title>
          <author>
            <organization showOnFrontPage="true">Mai, H., et al.</organization>
          </author>
          <date 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 and Workshops (ICIN)</refcontent>
      </reference>
      <reference anchor="Mai-2" quoteTitle="true" target="https://doi.org/10.1109/NOMS.2018.8406246" derivedAnchor="Mai-2">
        <front>
          <title>Towards a Security Monitoring Plane for Named Data Networking: Application to Content Poisoning Attack</title>
          <author>
            <organization showOnFrontPage="true">Mai, H., et al.</organization>
          </author>
          <date month="July" year="2018"/>
        </front>
        <seriesInfo name="DOI" value="10.1109/NOMS.2018.8406246"/>
        <refcontent>NOMS 2018 - 2018 IEEE/IFIP Network Operations Management
	Symposium</refcontent>
      </reference>
      <reference anchor="Marchal" target="http://www.mallouli.com/recherche/publications/noms2018-1.pdf" quoteTitle="true" derivedAnchor="Marchal">
        <front>
          <title>Leveraging NFV for the Deployment of NDN: Application to HTTP Traffic Transport</title>
          <author>
            <organization showOnFrontPage="true">Marchal, X., et al.</organization>
          </author>
          <date month="July" year="2018"/>
        </front>
        <seriesInfo name="DOI" value="10.1109/NOMS.2018.8406206"/>
        <refcontent>NOMS 2018 - 2018 IEEE/IFIP Network Operations and
	Management Symposium</refcontent>
      </reference>
      <reference anchor="Moiseenko" target="http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p112-moiseenko.pdf" quoteTitle="true" derivedAnchor="Moiseenko">
        <front>
          <title>TCP/ICN: Carrying TCP over Content Centric and Named Data Networks</title>
          <author initials="I." surname="Moiseenko" fullname="Ilya Moiseenko">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="D." surname="Oran" fullname="Dave Oran">
            <organization showOnFrontPage="true"/>
          </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="MWC_Demo" target="http://www.interdigital.com/download/56d5c71bd616f892ba001861" quoteTitle="true" derivedAnchor="MWC_Demo">
        <front>
          <title>InterDigital Demo at Mobile World Congress (MWC)</title>
          <author>
            <organization showOnFrontPage="true">InterDigital</organization>
          </author>
          <date year="2016"/>
        </front>
      </reference>
      <reference anchor="NDN-testbed" target="https://named-data.net/ndn-testbed/" quoteTitle="true" derivedAnchor="NDN-testbed">
        <front>
          <title>NDN Testbed</title>
          <author>
            <organization showOnFrontPage="true">NDN</organization>
          </author>
        </front>
      </reference>
      <reference anchor="I-D.kutscher-icnrg-netinf-proto" quoteTitle="true" target="https://tools.ietf.org/html/draft-kutscher-icnrg-netinf-proto-01" derivedAnchor="NetInf">
        <front>
          <title>The NetInf Protocol</title>
          <author initials="D" surname="Kutscher" fullname="Dirk Kutscher">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="S" surname="Farrell" fullname="Stephen Farrell">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="E" surname="Davies" fullname="Elwyn Davies">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="February" day="10" year="2013"/>
          <abstract>
            <t>This document defines a conceptual protocol and corresponding node requirements for NetInf nodes in a NetInf network.  A NetInf network offers an information-centric paradigm that supports the creation, location, exchange and storage of Named Data Objects (NDOs).  NetInf nodes can provide different services to other NetInf nodes, e.g., forwarding requests for information objects, delivering corresponding response messages, name resolution services etc.  This (abstract) protocol is intended to be run over some "convergence layer" that handles transport issues.  Two "wire" formats are defined, one that uses HTTP for message transfer and one layered on UDP.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-kutscher-icnrg-netinf-proto-01"/>
        <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-kutscher-icnrg-netinf-proto-01.txt"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="NFD" target="https://named-data.net/doc/NFD/current/" quoteTitle="true" derivedAnchor="NFD">
        <front>
          <title>NFD - Named Data Networking Forwarding Daemon</title>
          <author>
            <organization showOnFrontPage="true">NDN</organization>
          </author>
        </front>
      </reference>
      <reference anchor="NGMN-5G" target="https://www.ngmn.org/wp-content/uploads/NGMN_5G_White_Paper_V1_0.pdf" quoteTitle="true" derivedAnchor="NGMN-5G">
        <front>
          <title>5G White Paper</title>
          <author>
            <organization showOnFrontPage="true">NGMN Alliance</organization>
          </author>
          <date month="February" year="2015"/>
        </front>
      </reference>
      <reference anchor="NGMN-Network-Slicing" target="https://www.ngmn.org/wp-content/uploads/160113_NGMN_Network_Slicing_v1_0.pdf" quoteTitle="true" derivedAnchor="NGMN-Network-Slicing">
        <front>
          <title>Description of Network Slicing Concept</title>
          <author>
            <organization showOnFrontPage="true">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="Nguyen-1" quoteTitle="true" target="https://doi.org/10.23919/INM.2017.7987266" derivedAnchor="Nguyen-1">
        <front>
          <title>Content Poisoning in Named Data Networking: Comprehensive characterization of real deployment</title>
          <author>
            <organization showOnFrontPage="true">Nguyen, T., et al.</organization>
          </author>
          <date month="July" year="2017"/>
        </front>
        <seriesInfo name="DOI" value="10.23919/INM.2017.7987266"/>
        <refcontent>2017 IFIP/IEEE Symposium on Integrated Network and Service
	Management (IM)</refcontent>
      </reference>
      <reference anchor="Nguyen-2" quoteTitle="true" target="https://doi.org/10.1109/INM.2015.7140299" derivedAnchor="Nguyen-2">
        <front>
          <title>An optimal statistical test for robust detection against interest flooding attacks in CCN</title>
          <author initials="T." surname="Nguyen" fullname="Tan Nguyen">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="R." surname="Cogranne" fullname="Remi Cogranne">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="G." surname="Doyen" fullname="Guillaume Doyen">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="July" year="2015"/>
        </front>
        <seriesInfo name="DOI" value="10.1109/INM.2015.7140299"/>
        <refcontent>2015 IFIP/IEEE International Symposium on Integrated
	Network Management (IM)</refcontent>
      </reference>
      <reference anchor="Nguyen-3" quoteTitle="true" target="https://doi.org/10.1109/MCOM.2018.1701135" derivedAnchor="Nguyen-3">
        <front>
          <title>A Security Monitoring Plane for Named Data Networking Deployment</title>
          <author>
            <organization showOnFrontPage="true">Nguyen, T., et al.</organization>
          </author>
          <date month="November" year="2018"/>
        </front>
        <seriesInfo name="DOI" value="10.1109/MCOM.2018.1701135"/>
        <refcontent>IEEE Communications Magazine, Volume: 56, Issue 11</refcontent>
      </reference>
      <reference anchor="ONAP" target="https://www.onap.org/" quoteTitle="true" derivedAnchor="ONAP">
        <front>
          <title>Open Network Automation Platform</title>
          <author>
            <organization showOnFrontPage="true">ONAP</organization>
          </author>
        </front>
      </reference>
      <reference anchor="oneM2M" target="http://www.onem2m.org/" quoteTitle="true" derivedAnchor="oneM2M">
        <front>
          <title>oneM2M Service Layer Standards for M2M and IoT</title>
          <author>
            <organization showOnFrontPage="true">OneM2M</organization>
          </author>
          <date year="2017"/>
        </front>
      </reference>
      <reference anchor="Overlay_ICN" target="https://www.researchgate.net/publication/282779666_A_novel_overlay_architecture_for_Information_Centric_Networking" quoteTitle="true" derivedAnchor="Overlay_ICN">
        <front>
          <title>A novel overlay architecture for Information Centric Networking</title>
          <author>
            <organization showOnFrontPage="true">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="POINT" quoteTitle="true" target="https://doi.org/10.1109/EuCNC.2015.7194109" derivedAnchor="POINT">
        <front>
          <title>IP over ICN - The better IP?</title>
          <author>
            <organization showOnFrontPage="true">Trossen, D., et al.</organization>
          </author>
          <date month="June" year="2015"/>
        </front>
        <seriesInfo name="DOI" value="10.1109/EuCNC.2015.7194109"/>
        <refcontent>2015 European Conference on Networks and Communications (EuCNC)</refcontent>
      </reference>
      <reference anchor="Ravindran" target="https://arxiv.org/abs/1610.01182" quoteTitle="true" derivedAnchor="Ravindran">
        <front>
          <title>5G-ICN : Delivering ICN Services over 5G using Network Slicing</title>
          <author>
            <organization showOnFrontPage="true">Ravindran, R., et al.</organization>
          </author>
          <date 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="Reed" quoteTitle="true" target="https://doi.org/10.1109/ICC.2016.7511036" derivedAnchor="Reed">
        <front>
          <title>Stateless multicast switching in software defined networks</title>
          <author>
            <organization showOnFrontPage="true">Reed, M., et al.</organization>
          </author>
          <date month="May" year="2016"/>
        </front>
        <seriesInfo name="DOI" value="10.1109/ICC.2016.7511036"/>
        <refcontent>2016 IEEE International Conference on Communications (ICC)</refcontent>
      </reference>
      <reference anchor="RFC6920" target="https://www.rfc-editor.org/info/rfc6920" quoteTitle="true" derivedAnchor="RFC6920">
        <front>
          <title>Naming Things with Hashes</title>
          <author initials="S." surname="Farrell" fullname="S. Farrell">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="D." surname="Kutscher" fullname="D. Kutscher">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C." surname="Dannewitz" fullname="C. Dannewitz">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="B." surname="Ohlman" fullname="B. Ohlman">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A." surname="Keranen" fullname="A. Keranen">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="P." surname="Hallam-Baker" fullname="P. Hallam-Baker">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2013" month="April"/>
          <abstract>
            <t>This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function.  It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it.  The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="6920"/>
        <seriesInfo name="DOI" value="10.17487/RFC6920"/>
      </reference>
      <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252" quoteTitle="true" derivedAnchor="RFC7252">
        <front>
          <title>The Constrained Application Protocol (CoAP)</title>
          <author initials="Z." surname="Shelby" fullname="Z. Shelby">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="K." surname="Hartke" fullname="K. Hartke">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C." surname="Bormann" fullname="C. Bormann">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2014" month="June"/>
          <abstract>
            <t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t>
            <t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7252"/>
        <seriesInfo name="DOI" value="10.17487/RFC7252"/>
      </reference>
      <reference anchor="RFC7426" target="https://www.rfc-editor.org/info/rfc7426" quoteTitle="true" derivedAnchor="RFC7426">
        <front>
          <title>Software-Defined Networking (SDN): Layers and Architecture Terminology</title>
          <author initials="E." surname="Haleplidis" fullname="E. Haleplidis" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="K." surname="Pentikousis" fullname="K. Pentikousis" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="S." surname="Denazis" fullname="S. Denazis">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="J." surname="Hadi Salim" fullname="J. Hadi Salim">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="D." surname="Meyer" fullname="D. Meyer">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="O." surname="Koufopavlou" fullname="O. Koufopavlou">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2015" month="January"/>
          <abstract>
            <t>Software-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces.  SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane.  This separation allows faster innovation cycles at both planes as experience has already shown.  However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other.  This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7426"/>
        <seriesInfo name="DOI" value="10.17487/RFC7426"/>
      </reference>
      <reference anchor="RFC7665" target="https://www.rfc-editor.org/info/rfc7665" quoteTitle="true" derivedAnchor="RFC7665">
        <front>
          <title>Service Function Chaining (SFC) Architecture</title>
          <author initials="J." surname="Halpern" fullname="J. Halpern" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C." surname="Pignataro" fullname="C. Pignataro" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2015" month="October"/>
          <abstract>
            <t>This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network.  It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF.  This document does not propose solutions, protocols, or extensions to existing protocols.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7665"/>
        <seriesInfo name="DOI" value="10.17487/RFC7665"/>
      </reference>
      <reference anchor="RFC7927" target="https://www.rfc-editor.org/info/rfc7927" quoteTitle="true" derivedAnchor="RFC7927">
        <front>
          <title>Information-Centric Networking (ICN) Research Challenges</title>
          <author initials="D." surname="Kutscher" fullname="D. Kutscher" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="S." surname="Eum" fullname="S. Eum">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="K." surname="Pentikousis" fullname="K. Pentikousis">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="I." surname="Psaras" fullname="I. Psaras">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="D." surname="Corujo" fullname="D. Corujo">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="D." surname="Saucez" fullname="D. Saucez">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="T." surname="Schmidt" fullname="T. Schmidt">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="M." surname="Waehlisch" fullname="M. Waehlisch">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2016" month="July"/>
          <abstract>
            <t>This memo describes research challenges for Information-Centric Networking (ICN), an approach to evolve the Internet infrastructure to directly support information distribution by introducing uniquely named data as a core Internet principle.  Data becomes independent from location, application, storage, and means of transportation, enabling or enhancing a number of desirable features, such as security, user mobility, multicast, and in-network caching. Mechanisms for realizing these benefits is the subject of ongoing research in the IRTF and elsewhere.  This document describes current research challenges in ICN, including naming, security, routing, system scalability, mobility management, wireless networking, transport services, in-network caching, and network management.</t>
            <t>This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7927"/>
        <seriesInfo name="DOI" value="10.17487/RFC7927"/>
      </reference>
      <reference anchor="RFC7945" target="https://www.rfc-editor.org/info/rfc7945" quoteTitle="true" derivedAnchor="RFC7945">
        <front>
          <title>Information-Centric Networking: Evaluation and Security Considerations</title>
          <author initials="K." surname="Pentikousis" fullname="K. Pentikousis" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="B." surname="Ohlman" fullname="B. Ohlman">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="E." surname="Davies" fullname="E. Davies">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="S." surname="Spirou" fullname="S. Spirou">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="G." surname="Boggia" fullname="G. Boggia">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2016" month="September"/>
          <abstract>
            <t>This document presents a number of considerations regarding evaluating Information-Centric Networking (ICN) and sheds some light on the impact of ICN on network security.  It also surveys the evaluation tools currently available to researchers in the ICN area and provides suggestions regarding methodology and metrics.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7945"/>
        <seriesInfo name="DOI" value="10.17487/RFC7945"/>
      </reference>
      <reference anchor="RFC8075" target="https://www.rfc-editor.org/info/rfc8075" quoteTitle="true" derivedAnchor="RFC8075">
        <front>
          <title>Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)</title>
          <author initials="A." surname="Castellani" fullname="A. Castellani">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="S." surname="Loreto" fullname="S. Loreto">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A." surname="Rahman" fullname="A. Rahman">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="T." surname="Fossati" fullname="T. Fossati">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="E." surname="Dijk" fullname="E. Dijk">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2017" month="February"/>
          <abstract>
            <t>This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the Constrained Application Protocol (CoAP).  This will enable an HTTP client to access resources on a CoAP server through the proxy.  This document describes how an HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response.  This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8075"/>
        <seriesInfo name="DOI" value="10.17487/RFC8075"/>
      </reference>
      <reference anchor="RFC8568" target="https://www.rfc-editor.org/info/rfc8568" quoteTitle="true" derivedAnchor="RFC8568">
        <front>
          <title>Network Virtualization Research Challenges</title>
          <author initials="CJ." surname="Bernardos" fullname="CJ. Bernardos">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A." surname="Rahman" fullname="A. Rahman">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="JC." surname="Zuniga" fullname="JC. Zuniga">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="LM." surname="Contreras" fullname="LM. Contreras">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="P." surname="Aranda" fullname="P. Aranda">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="P." surname="Lynch" fullname="P. Lynch">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2019" month="April"/>
          <abstract>
            <t>This document describes open research challenges for network virtualization.  Network virtualization is following a similar path as previously taken by cloud computing.  Specifically, cloud computing popularized migration of computing functions (e.g., applications) and storage from local, dedicated, physical resources to remote virtual functions accessible through the Internet.  In a similar manner, network virtualization is encouraging migration of networking functions from dedicated physical hardware nodes to a virtualized pool of resources.  However, network virtualization can be considered to be a more complex problem than cloud computing as it not only involves virtualization of computing and storage functions but also involves abstraction of the network itself.  This document describes current research and engineering challenges in network virtualization including the guarantee of quality of service, performance improvement, support for multiple domains, network slicing, service composition, device virtualization, privacy and security, separation of control concerns, network function placement, and testing.  In addition, some proposals are made for new activities in the IETF and IRTF that could address some of these challenges. This document is a product of the Network Function Virtualization Research Group (NFVRG).</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8568"/>
        <seriesInfo name="DOI" value="10.17487/RFC8568"/>
      </reference>
      <reference anchor="RFC8569" target="https://www.rfc-editor.org/info/rfc8569" quoteTitle="true" derivedAnchor="RFC8569">
        <front>
          <title>Content-Centric Networking (CCNx) Semantics</title>
          <author initials="M." surname="Mosko" fullname="M. Mosko">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="I." surname="Solis" fullname="I. Solis">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C." surname="Wood" fullname="C. Wood">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2019" month="July"/>
          <abstract>
            <t>This document describes the core concepts of the Content-Centric Networking (CCNx) architecture and presents a network protocol based on two messages: Interests and Content Objects.  It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation.  This architecture and protocol specification is independent of a specific wire encoding.</t>
            <t>The protocol also uses a control message called an Interest Return, whereby one system can return an Interest message to the previous hop due to an error condition.  This indicates to the previous hop that the current system will not respond to the Interest.</t>
            <t>This document is a product of the Information-Centric Networking Research Group (ICNRG).  The document received wide review among ICNRG participants.  Two full implementations are in active use and have informed the technical maturity of the protocol specification.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8569"/>
        <seriesInfo name="DOI" value="10.17487/RFC8569"/>
      </reference>
      <reference anchor="RFC8609" target="https://www.rfc-editor.org/info/rfc8609" quoteTitle="true" derivedAnchor="RFC8609">
        <front>
          <title>Content-Centric Networking (CCNx) Messages in TLV Format</title>
          <author initials="M." surname="Mosko" fullname="M. Mosko">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="I." surname="Solis" fullname="I. Solis">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C." surname="Wood" fullname="C. Wood">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2019" month="July"/>
          <abstract>
            <t>Content-Centric Networking (CCNx) is a network protocol that uses a hierarchical name to forward requests and to match responses to requests.  This document specifies the encoding of CCNx messages in a TLV packet format, including the TLV types used by each message element and the encoding of each value.  The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification.</t>
            <t>This document is a product of the Information Centric Networking research group (ICNRG).  The document received wide review among ICNRG participants and has two full implementations currently in active use, which have informed the technical maturity of the protocol specification.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8609"/>
        <seriesInfo name="DOI" value="10.17487/RFC8609"/>
      </reference>
      <reference anchor="RFC8613" target="https://www.rfc-editor.org/info/rfc8613" quoteTitle="true" derivedAnchor="RFC8613">
        <front>
          <title>Object Security for Constrained RESTful Environments (OSCORE)</title>
          <author initials="G." surname="Selander" fullname="G. Selander">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="J." surname="Mattsson" fullname="J. Mattsson">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="F." surname="Palombini" fullname="F. Palombini">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="L." surname="Seitz" fullname="L. Seitz">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2019" month="July"/>
          <abstract>
            <t>This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE).  OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.</t>
            <t>Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration.  Therefore, this document updates RFC 7252.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8613"/>
        <seriesInfo name="DOI" value="10.17487/RFC8613"/>
      </reference>
      <reference anchor="SAIL" target="http://www.sail-project.eu/" quoteTitle="true" derivedAnchor="SAIL">
        <front>
          <title>Scalable and Adaptive Internet Solutions (SAIL)</title>
          <author>
            <organization showOnFrontPage="true">SAIL</organization>
          </author>
        </front>
      </reference>
      <reference anchor="SAIL_Content_Delivery" target="https://sail-project.eu/wp-content/uploads/2012/06/SAIL_DB2_v1_0_final-Public.pdf" quoteTitle="true" derivedAnchor="SAIL_Content_Delivery">
        <front>
          <title>NetInf Content Delivery and Operations</title>
          <author>
            <organization showOnFrontPage="true">FP7</organization>
          </author>
          <date month="January" year="2013"/>
        </front>
        <seriesInfo name="Objective" value="FP7-ICT-2009-5-257448/D-3.2"/>
      </reference>
      <reference anchor="SAIL_Prototyping" target="http://www.sail-project.eu/wp-content/uploads/2013/05/SAIL_DB4_v1.1_Final_Public.pdf" quoteTitle="true" derivedAnchor="SAIL_Prototyping">
        <front>
          <title>Prototyping and Evaluation</title>
          <author>
            <organization showOnFrontPage="true">FP7</organization>
          </author>
          <date month="March" year="2013"/>
        </front>
        <seriesInfo name="Objective" value="FP7-ICT-2009-5-257448/D.B.4"/>
      </reference>
      <reference anchor="Tateson" target="http://www.psirp.org/files/Deliverables/FP7-INFSO-ICT-216173-PSIRP-D4.6_FinalReportOnDeplIncBusinessModels.pdf" quoteTitle="true" derivedAnchor="Tateson">
        <front>
          <title>Final Evaluation Report on Deployment Incentives and Business Models</title>
          <author>
            <organization showOnFrontPage="true">Tateson, J., et al.</organization>
          </author>
          <date month="May" year="2010"/>
        </front>
        <seriesInfo name="Version" value="1.0"/>
        <refcontent>PSIRP</refcontent>
      </reference>
      <reference anchor="Techno_Economic" quoteTitle="true" target="https://doi.org/10.5325/jinfopoli.2.2012.0026" derivedAnchor="Techno_Economic">
        <front>
          <title>Techno-Economics Aspects of Information-Centric Networking</title>
          <author initials="D." surname="Trossen" fullname="Dirk Trossen">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A." surname="Kostopoulos" fullname="Alexandros Kostopoulos">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="June" year="2012"/>
        </front>
        <seriesInfo name="Journal for Information Policy" value=""/>
        <refcontent>Volume 2</refcontent>
        <seriesInfo name="DOI" value="10.5325/jinfopoli.2.2012.0026"/>
      </reference>
      <reference anchor="UMOBILE-2" quoteTitle="true" target="https://doi.org/10.1109/MCOM.2018.1700325" derivedAnchor="UMOBILE-2">
        <front>
          <title>Connecting the Edges: A Universal, Mobile-Centric, and Opportunistic Communications Architecture</title>
          <author>
            <organization showOnFrontPage="true">Sarros, C., et al.</organization>
          </author>
          <date month="February" year="2018"/>
        </front>
        <seriesInfo name="DOI" value="10.1109/MCOM.2018.1700325"/>
        <refcontent>IEEE Communications Magazine, Volume 56, Issue 2</refcontent>
      </reference>
      <reference anchor="UMOBILE-3" quoteTitle="true" target="https://doi.org/10.1145/3210240.3210809" derivedAnchor="UMOBILE-3">
        <front>
          <title>Named-data Emergency Network Services</title>
          <author initials="M." surname="Tavares" fullname="Miguel Tavares">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="O." surname="Aponte" fullname="Omar Aponte">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="P." surname="Mendes" fullname="Paulo Mendes">
            <organization showOnFrontPage="true"/>
          </author>
          <date 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" quoteTitle="true" target="https://doi.org/10.1109/INFCOMW.2016.7562142" derivedAnchor="UMOBILE-4">
        <front>
          <title>Oi! - Opportunistic Data Transmission Based on Wi-Fi Direct</title>
          <author>
            <organization showOnFrontPage="true">Amaral, L., et al.</organization>
          </author>
          <date 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" quoteTitle="true" target="https://doi.org/10.1145/3125719.3132107" derivedAnchor="UMOBILE-5">
        <front>
          <title>Demo: named-data networking in opportunistic network</title>
          <author initials="S." surname="Dynerowicz" fullname="Seweryn               Dynerowicz">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="P." surname="Mendes" fullname="Paulo Mendes">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="September" year="2017"/>
        </front>
        <seriesInfo name="DOI" value="10.1145/3125719.3132107"/>
        <refcontent>ICN '17: Proceedings of the 4th ACM Conference on
	Information-Centric Networking</refcontent>
      </reference>
      <reference anchor="UMOBILE-6" quoteTitle="true" target="https://doi.org/10.1145/3267955.3269011" derivedAnchor="UMOBILE-6">
        <front>
          <title>Information-centric routing for opportunistic wireless networks</title>
          <author>
            <organization showOnFrontPage="true">Mendes, P.,et al.</organization>
          </author>
          <date month="September" year="2018"/>
        </front>
        <seriesInfo name="DOI" value="10.1145/3267955.3269011"/>
        <refcontent>ICN '18: Proceedings of the 5th ACM Conference on
	Information-Centric Networking</refcontent>
      </reference>
      <reference anchor="UMOBILE-7" quoteTitle="true" derivedAnchor="UMOBILE-7">
        <front>
          <title>D4.5 Report on Data Collection and Inference Models</title>
          <author initials="R." surname="Sofia" fullname="Rute C. Sofia"/>
          <date month="September" year="2017"/>
        </front>
        <refcontent>Deliverable</refcontent>
      </reference>
      <reference anchor="UMOBILE-8" quoteTitle="true" target="https://doi.org/10.1145/3125719.3132096" derivedAnchor="UMOBILE-8">
        <front>
          <title>ICN-based edge service deployment in challenged networks</title>
          <author>
            <organization showOnFrontPage="true">Sarros, C., et al.</organization>
          </author>
          <date 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</refcontent>
      </reference>
      <reference anchor="UMOBILE-9" quoteTitle="true" target="https://doi.org/10.1145/3209811.3209867" derivedAnchor="UMOBILE-9">
        <front>
          <title>Information-Centric Multi-Access Edge Computing Platform for Community Mesh Networks</title>
          <author>
            <organization showOnFrontPage="true">Lertsinsrubtavee, A., et al.</organization>
          </author>
          <date 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</refcontent>
      </reference>
      <reference anchor="UMOBILE-overview" target="http://www.umobile-project.eu/" quoteTitle="true" derivedAnchor="UMOBILE-overview">
        <front>
          <title>Universal, mobile-centric and opportunistic communications architecture</title>
          <author>
            <organization showOnFrontPage="true">UMOBILE</organization>
          </author>
        </front>
      </reference>
      <reference anchor="VSER" quoteTitle="true" target="https://doi.org/10.1109/CloudNet.2013.6710583" derivedAnchor="VSER">
        <front>
          <title>Towards software defined ICN based edge-cloud services</title>
          <author>
            <organization showOnFrontPage="true">Ravindran, R., et al.</organization>
          </author>
          <date/>
        </front>
        <seriesInfo name="DOI" value="10.1109/CloudNet.2013.6710583"/>
        <refcontent>2013 IEEE 2nd International Conference on Cloud Networking (CloudNet)</refcontent>
      </reference>
      <reference anchor="VSER-Mob" quoteTitle="true" target="https://doi.org/10.1145/2984356.2988521" derivedAnchor="VSER-Mob">
        <front>
          <title>Seamless Producer Mobility as a Service in Information-centric Networks</title>
          <author>
            <organization showOnFrontPage="true">Azgin, A., et al.</organization>
          </author>
          <date 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="White" target="http://www.cablelabs.com/wp-content/uploads/2016/02/Content-Delivery-with-Content-Centric-Networking-Feb-2016.pdf" quoteTitle="true" derivedAnchor="White">
        <front>
          <title>Content Delivery with Content-Centric Networking</title>
          <author initials="G." surname="White" fullname="Greg White">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="G." surname="Rutz" fullname="Greg Rutz">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="February" year="2016"/>
        </front>
      </reference>
    </references>
    <section anchor="Acknowledgments" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t pn="section-appendix.a-1">The authors want to 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 their very useful reviews and comments to the document. 
      </t>
      <t pn="section-appendix.a-2">Special thanks to <contact fullname="Dave Oran"/> (ICNRG Co-chair)
      and <contact fullname="Marie-Jose Montpetit"/> for their extensive and
      thoughtful reviews of the document. Their reviews helped to
      immeasurably improve the document quality.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Akbar Rahman" initials="A." surname="Rahman">
        <organization abbrev="InterDigital Communications, LLC" showOnFrontPage="true">InterDigital Communications, LLC</organization>
        <address>
          <postal>
            <street>1000 Sherbrooke Street West, 10th floor</street>
            <city>Montreal</city>
            <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="Huawei" showOnFrontPage="true">Huawei Technologies Duesseldorf GmbH</organization>
        <address>
          <postal>
            <street>Riesstrasse 25</street>
            <city>Munich</city>
            <code>80992</code>
            <country>Germany</country>
          </postal>
          <email>dirk.trossen@huawei.com</email>
          <uri>http://www.huawei.com/</uri>
        </address>
      </author>
      <author fullname="Dirk Kutscher" initials="D." surname="Kutscher">
        <organization abbrev="Emden University" showOnFrontPage="true">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 showOnFrontPage="true">Sterlite Technologies</organization>
        <address>
          <postal>
            <street>5201 Greatamerica Pkwy</street>
            <city>Santa Clara</city>
            <code>95054</code>
            <country>United States of America</country>
          </postal>
          <email>ravi.ravindran@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>