path: root/doc/rfc/rfc8763.txt

Internet Research Task Force (IRTF)                            A. Rahman
Request for Comments: 8763              InterDigital Communications, LLC
Category: Informational                                       D. Trossen
ISSN: 2070-1721                                                   Huawei
                                                             D. Kutscher
                                                        Emden University
                                                            R. Ravindran
                                                   Sterlite Technologies
                                                              April 2020


   Deployment Considerations for Information-Centric Networking (ICN)

Abstract

   Information-Centric Networking (ICN) is now reaching technological
   maturity after many years of fundamental research and
   experimentation.  This document provides a number of deployment
   considerations in the interest of helping the ICN community move
   forward to the next step of live deployments.  First, the major
   deployment configurations for ICN are described, 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).

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Research Task Force
   (IRTF).  The IRTF publishes the 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.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8763.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  Abbreviations List
   4.  Deployment Configurations
     4.1.  Clean-Slate ICN
     4.2.  ICN-as-an-Overlay
     4.3.  ICN-as-an-Underlay
       4.3.1.  Edge Network
       4.3.2.  Core Network
     4.4.  ICN-as-a-Slice
     4.5.  Composite-ICN Approach
   5.  Deployment Migration Paths
     5.1.  Application and Service Migration
     5.2.  Content Delivery Network Migration
     5.3.  Edge Network Migration
     5.4.  Core Network Migration
   6.  Deployment Trial Experiences
     6.1.  ICN-as-an-Overlay
       6.1.1.  FP7 PURSUIT Efforts
       6.1.2.  FP7 SAIL Trial
       6.1.3.  NDN Testbed
       6.1.4.  ICN2020 Efforts
       6.1.5.  UMOBILE Efforts
     6.2.  ICN-as-an-Underlay
       6.2.1.  H2020 POINT and RIFE Efforts
       6.2.2.  H2020 FLAME Efforts
       6.2.3.  CableLabs Content Delivery System
       6.2.4.  NDN IoT Trials
       6.2.5.  NREN ICN Testbed
       6.2.6.  DOCTOR Testbed
     6.3.  Composite-ICN Approach
     6.4.  Summary of Deployment Trials
   7.  Deployment Issues Requiring Further Standardization
     7.1.  Protocols for Application and Service Migration
     7.2.  Protocols for Content Delivery Network Migration
     7.3.  Protocols for Edge and Core Network Migration
     7.4.  Summary of ICN Protocol Gaps and Potential Protocol Efforts
   8.  Conclusion
   9.  IANA Considerations
   10. Security Considerations
   11. Informative References
   Acknowledgments
   Authors' Addresses

1.  Introduction

   The ICNRG charter identifies deployment guidelines as an important
   topic area for the ICN community.  Specifically, the charter states
   that defining concrete migration paths for ICN deployments that avoid
   forklift upgrades and defining practical ICN interworking
   configurations with the existing Internet paradigm are key topic
   areas that require further investigation [ICNRGCharter].  Also, it is
   well understood that results and conclusions from any mid- to large-
   scale ICN experiments in the live Internet will also provide useful
   guidance for deployments.

   So far, outside of some preliminary investigations, such as
   [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.

   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.

   This document represents the consensus of the Information-Centric
   Networking Research Group (ICNRG).  It has been reviewed extensively
   by the Research Group (RG) members active in the specific areas of
   work covered by the document.

2.  Terminology

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

   Deployment:
      The final stage of the process of setting up an ICN network that
      is (1) ready for useful work (e.g., transmission of end-user 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.

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

   Network Functions Virtualization (NFV):
      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 [RFC8568] for further information.

   Software-Defined Networking (SDN):
      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
      [RFC7426] for further information.

3.  Abbreviations List

   API:         Application Programming Interface

   BIER:        Bit Index Explicit Replication

   BoF:         Birds of a Feather (session)

   CCNx:        Content-Centric Networking

   CDN:         Content Distribution Network

   CoAP:        Constrained Application Protocol

   DASH:        Dynamic Adaptive Streaming over HTTP

   Diffserv:    Differentiated Services

   DoS:         Denial of Service

   DTN:         Delay-Tolerant Networking

   ETSI:        European Telecommunications Standards Institute

   EU:          European Union

   FP7:         7th Framework Programme for Research and Technological
                Development

   HLS:         HTTP Live Streaming

   HTTP:        HyperText Transfer Protocol

   HTTPS:       HyperText Transfer Protocol Secure

   H2020:       Horizon 2020 (research program)

   ICN:         Information-Centric Networking

   ICNRG:       Information-Centric Networking Research Group

   IETF:        Internet Engineering Task Force

   IntServ:     Integrated Services

   IoT:         Internet of Things

   IP:          Internet Protocol

   IPv4:        Internet Protocol Version 4

   IPv6:        Internet Protocol Version 6

   IPTV:        Internet Protocol Television

   IS-IS:       Intermediate System to Intermediate System

   ISP:         Internet Service Provider

   k:           kilo (1000)

   L2:          Layer 2

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

   MANO:        Management and Orchestration

   MEC:         Multi-access Edge Computing

   Mbps:        Megabits per second

   M2M:         Machine-to-Machine

   NAP:         Network Attachment Point

   NDN:         Named Data Networking

   NETCONF:     Network Configuration Protocol

   NetInf:      Network of Information

   NFD:         Named Data Networking Forwarding Daemon

   NFV:         Network Functions Virtualization

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

   NR:          New Radio (access network for 5G)

   OAM:         Operations, Administration, and Maintenance

   ONAP:        Open Network Automation Platform

   OSPF:        Open Shortest Path First

   PoC:         Proof of Concept (demo)

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

   qMp:         Quick Mesh Project

   QoS:         Quality of Service

   RAM:         Random Access Memory

   RAN:         Radio Access Network

   REST:        Representational State Transfer (architecture)

   RESTCONF:    Representational State Transfer Configuration (protocol)

   RIFE:        Architecture for an Internet For Everybody (project)

   RIP:         Routing Information Protocol

   ROM:         Read-Only Memory

   RSVP:        Resource Reservation Protocol

   RTP:         Real-time Transport Protocol

   SDN:         Software-Defined Networking

   SFC:         Service Function Chaining

   SLA:         Service Level Agreement

   TCL:         Transport Convergence Layer

   TCP:         Transmission Control Protocol

   UDP:         User Datagram Protocol

   UMOBILE:     Universal Mobile-centric and Opportunistic
                Communications Architecture

   US:          United States

   USA:         United States of America

   VoD:         Video on Demand

   VPN:         Virtual Private Network

   WG:          Working Group

   YANG:        Yet Another Next Generation (data modeling language)

   5G:          Fifth Generation (cellular network)

   6LoWPAN:     IPv6 over Low-Power Wireless Personal Area Networks

4.  Deployment Configurations

   In this section, we present various deployment options for ICN.
   These are presented as "configurations" that allow for studying these
   options further.  While this document will outline experiences with a
   number of these configurations (in Section 6), we will not provide an
   in-depth technical or commercial evaluation for any of them -- for
   this, we refer to existing literature in this space, such as
   [Tateson].

4.1.  Clean-Slate ICN

   ICN has often been described as a "clean-slate" approach with the
   goal to renew or replace the complete IP infrastructure of the
   Internet.  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 [NFD], CCNx
   routers [Jacobson], or Publish-Subscribe Internet Technology
   (PURSUIT) forwarding nodes [IEEE_Communications].

   While such clean-slate replacement could be seen as exclusive for ICN
   deployments, some ICN approaches (e.g., [POINT]) also rely on the
   deployment of general infrastructure upgrades, in this case, SDN
   switches.  Different proposals have been made for various ICN
   approaches to enable the operation over an SDN transport [Reed]
   [CONET] [C_FLOW].

4.2.  ICN-as-an-Overlay

   Similar to other significant changes to the Internet routing fabric,
   particularly the transition from IPv4 to IPv6 or the introduction of
   IP multicast, this deployment configuration foresees the creation of
   an ICN overlay.  Note that this overlay approach is sometimes,
   informally, also referred to as a tunneling approach.  The overlay
   approach can be implemented directly (e.g., ICN-over-UDP), as
   described in [CCNx_UDP].  Alternatively, the overlay can be
   accomplished via ICN-in-L2-in-IP as in [IEEE_Communications], 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 [NetInf].  Finally, [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.

   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.

4.3.  ICN-as-an-Underlay

   Proposals, such as [POINT] and [White], outline the deployment option
   of using an ICN underlay that would integrate with existing
   (external) IP-based networks by deploying application-layer gateways
   at appropriate locations.  The main reasons for such a configuration
   option is the introduction of ICN technology in given islands (e.g.,
   inside a CDN or edge IoT network) to reap the benefits of native ICN,
   in terms of underlying multicast delivery, mobility support, fast
   indirection due to location independence, in-network computing, and
   possibly more.  The underlay approach thus results in islands of
   native ICN deployments 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.

4.3.1.  Edge Network

   Native ICN networks may be located at the edge of the network where
   the introduction of new network architectures and protocols is easier
   in so-called greenfield deployments.  In this context, ICN is an
   attractive option for scenarios, such as IoT [ICN-IoT].  The
   integration with the current IP protocol suite takes place at an
   application gateway/proxy at the edge network boundary, e.g.,
   translating incoming CoAP request/response transactions [RFC7252]
   into ICN message exchanges or vice versa.

   The work in [VSER] positions ICN as an edge service gateway driven by
   a generalized ICN-based 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 [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
   [VSER-Mob] features.

4.3.2.  Core Network

   In this suboption, a core network would utilize edge-based protocol
   mapping onto the native ICN underlay.  For instance, [POINT] proposes
   to map HTTP transactions or some other IP-based transactions, such as
   CoAP, directly onto an ICN-based message exchange.  This mapping is
   realized at the 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.

   The work in [White] proposes a similar deployment configuration.
   There, the goal is to use ICN for content distribution within CDN
   server farms.  Specifically, the protocol mapping is realized at the
   ingress of the server farm where the HTTP-based retrieval request is
   served, while the response is delivered through a suitable egress
   node translation.

4.4.  ICN-as-a-Slice

   The objective of network slicing [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 [NGMN-Network-Slicing].

   The 5G next generation architecture [fiveG-23501] provides the
   flexibility to deploy the ICN-as-a-Slice over either the edge (RAN)
   or mobile core network; otherwise, the ICN-as-a-Slice may be deployed
   end to end.  Further discussions on extending the architecture
   presented in [fiveG-23501] and the corresponding procedures in
   [fiveG-23502] to support ICN has been provided in [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" [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 [Ravindran].

   At the level of the specific technologies involved, such as ONAP
   [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
   Section 4.1.  Further cross-domain ICN slices can also be realized
   using frameworks, such as [ONAP].

4.5.  Composite-ICN Approach

   Some deployments do not clearly correspond to any of the previously
   defined basic configurations of (1) Clean-slate ICN, (2) ICN-as-an-
   Overlay, (3) ICN-as-an-Underlay, and (4) ICN-as-a-Slice.  Or, a
   deployment may contain a composite mixture of the properties of these
   basic configurations.  For example, the Hybrid ICN [H-ICN_1] approach
   carries ICN names in existing IPv6 headers and does not have distinct
   gateways or tunnels connecting ICN islands or any other distinct
   feature identified in the previous basic configurations.  So we
   categorize Hybrid ICN and other approaches that do not clearly
   correspond to one of the other basic configurations as a Composite-
   ICN approach.

5.  Deployment Migration Paths

   We now focus on the various migration paths that will have importance
   to the various stakeholders that are usually involved in the
   deployment of ICN networks.  We can identify these stakeholders as:

   *  application providers

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

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

   *  end-device manufacturers and users

   Our focus is on technological aspects of such migration.  Economic or
   regulatory aspects, such as those studied in [Tateson],
   [Techno_Economic], and [Internet_Pricing], are left out of our
   discussion.

5.1.  Application and Service Migration

   The Internet supports a multitude of applications and services using
   the many protocols defined over the packet-level 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 [DASH] and others.
   Nonetheless, many non-HTTP services exist, all of which need
   consideration when migrating from the IP-based Internet to an ICN-
   based one.

   The underlay deployment configuration option presented in Section 4.3
   aims at providing some level of compatibility to the existing
   ecosystem through a proxy-based message flow mapping mechanism (e.g.,
   mapping of existing HTTP/TCP/IP message flows to HTTP/ICN message
   flows).  A related approach of mapping TCP/IP to TCP/ICN message
   flows is described in [Moiseenko].  Another approach described in
   [Marchal] uses HTTP/NDN gateways and focuses, 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 [Moiseenko] carries the TCP layer into the ICN underlay,
   while the [Marchal] approach terminates both HTTP and TCP at the edge
   of the ICN underlay and maps these functionalities onto existing ICN
   functionalities.

   Alternatively, ICN-as-an-Overlay (Section 4.2) and ICN-as-a-Slice
   (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.

   Finally, [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.

5.2.  Content Delivery Network Migration

   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 Section 4.3 aims at providing a migration path for
   existing CDNs.  This is also highlighted in a BIER use-case document
   [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 Section 6.

5.3.  Edge Network Migration

   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 Section 4.3.1, application gateways/proxies can
   integrate such edge deployments into IP-based services, e.g.,
   utilizing CoAP-based [RFC7252] M2M platforms, such as oneM2M [oneM2M]
   or others.

   Another area of increased edge network innovation is that of mobile
   (access) networks, particularly in the context of the 5G mobile
   networks.  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 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.

   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.

5.4.  Core Network Migration

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

6.  Deployment Trial Experiences

   In this section, we will outline trial experiences, often conducted
   within collaborative project efforts.  Our focus here is on the
   realization of the various deployment configurations identified in
   Section 4; 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.

6.1.  ICN-as-an-Overlay

6.1.1.  FP7 PURSUIT Efforts

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

6.1.2.  FP7 SAIL Trial

   The Network of Information (NetInf) is the approach to ICN developed
   by the EU FP7 Scalable and Adaptive Internet Solutions (SAIL) project
   [SAIL].  NetInf provides both name-based forwarding with CCNx-like
   semantics and name resolution (for indirection and late binding).
   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 Section 4.2.  [SAIL_Prototyping]
   describes several trials, including a stadium environment and a
   multi-site testbed, leveraging NetInf's routing hint approach for
   routing scalability [SAIL_Content_Delivery].

6.1.3.  NDN Testbed

   The Named Data Networking (NDN) is one of the research projects of
   the National Science Foundation (NSF) of the USA as part of the
   Future Internet Architecture (FIA) Program.  The original NDN
   proposal was positioned as a Clean-slate ICN replacement of IP
   (Section 4.1).  However, in several trials, NDN generally follows the
   overlay deployment configuration of Section 4.2 to connect
   institutions over the public Internet across several continents.  The
   use cases covered in the trials include real-time videoconferencing,
   geolocating, and interfacing to consumer applications.  Typical
   trials involve up to 100 NDN-enabled nodes [NDN-testbed] [Jangam].

6.1.4.  ICN2020 Efforts

   ICN2020 is an ICN-related project of the EU H2020 research program
   and NICT [ICN2020-overview].  ICN2020 has a specific focus to advance
   ICN towards real-world deployments through applications, 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.

   ICN2020 has released a set of interim public technical reports.  The
   report [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 [RFC7945] [CUTEi], and the GEANT testbed [GEANT] to
   create an overlay deployment configuration of Section 4.2 over the
   public Internet.  The total network contains 37 nodes.  Since video
   was an important application, typical throughput was measured in
   certain scenarios and found to be in the order of 70 Mbps per node.

6.1.5.  UMOBILE Efforts

   UMOBILE is another of the ICN research projects under the H2020
   research program [UMOBILE-overview].  The UMOBILE architecture
   integrates the principles of DTN and ICN in a common framework to
   support edge computing and mobile opportunistic wireless environments
   (e.g., post-disaster scenarios and remote areas).  The UMOBILE
   architecture [UMOBILE-2] was developed on top of the NDN framework by
   following the overlay deployment configuration of Section 4.2.
   UMOBILE aims to extend Internet functionally by combining ICN and DTN
   technologies.

   One of the key aspects of UMOBILE was the extension of the NDN
   framework to locate network services (e.g., mobility management 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 [UMOBILE-3] and environments
   with intermittent connectivity.  To achieve this, the NDN framework
   was leveraged with a new messaging application called Oi!
   [UMOBILE-4] [UMOBILE-5], which supports intermittent wireless
   networking.  UMOBILE also implements a new data-centric wireless
   routing protocol, DABBER [UMOBILE-6] [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
   [UMOBILE-7].

   The consortium has completed several ICN deployment trials.  In a
   post-disaster scenario trial [UMOBILE-8], a special DTN face was
   created to provide reachability to remote areas where there is no
   typical Internet connection.  Another trial was the ICN deployment
   over the "Guifi.net" community network in the Barcelona region.  This
   trial focused on the evaluation of an ICN edge computing platform,
   called PiCasso [UMOBILE-9].  In this trial, ten (10) Raspberry 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.

6.2.  ICN-as-an-Underlay

6.2.1.  H2020 POINT and RIFE Efforts

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

   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
   [MWC_Demo].  The trial has also been accepted by the ETSI MEC group
   as a public proof-of-concept demonstration.

   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.

6.2.2.  H2020 FLAME Efforts

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

   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.

6.2.3.  CableLabs Content Delivery System

   The CableLabs ICN work reported in [White] proposes an underlay
   deployment configuration based on Section 4.3.2.  The use case is ICN
   for content distribution within complex CDN server farms to leverage
   ICN's superior in-network caching properties.  This CDN based on
   "island of ICN" 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 Section 4.1)
   of existing HTTP/IP end-user applications and related web
   infrastructure is a difficult proposition.  [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.

6.2.4.  NDN IoT Trials

   [Baccelli] summarizes the trial of an NDN system adapted specifically
   for a wireless IoT scenario.  The trial was run with 60 nodes
   distributed over several 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 [Baccelli] [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.

6.2.5.  NREN ICN Testbed

   The National Research and Education Network (NREN) ICN Testbed is a
   project sponsored by Cisco, Internet2, and the US Research and
   Education community.  Participants include universities and US
   federal government entities that connect via a nationwide VPN-based
   L2 underlay.  The testbed uses the CCNx approach and is based on the
   [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.

6.2.6.  DOCTOR Testbed

   The DOCTOR project is a French research project meaning "Deployment
   and Securisation of new Functionalities in Virtualized Networking
   Environments".  The project aims to run NDN over virtualized NFV
   infrastructure [Doctor] (based on Docker technology) and focuses on
   the NFV MANO aspects to build an operational NDN network focusing on
   important performance criteria, such as security, performance, and
   interoperability.

   The data plane relies on an HTTP/NDN gateway [Marchal] that processes
   HTTP traffic and transports it in an optimized way over NDN to
   benefit from the properties of the NDN island (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 [Mai-1]
   from the date gathered by distributed probes and applies orchestrated
   countermeasures against NDN attacks [Nguyen-1] [Nguyen-2] [Mai-2] or
   performance issues.  A remediation can be, for example, the scale up
   of a bottleneck component or the deployment of a security function,
   like a firewall or a signature verification module.  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) [Nguyen-3].

6.3.  Composite-ICN Approach

   Hybrid ICN [H-ICN_1] [H-ICN_2] is an approach where the ICN names are
   mapped to IPv6 addresses and other ICN information is carried as
   payload inside the IP packet.  This allows standard (ICN-unaware) IP
   routers to forward packets based on IPv6 info but enables ICN-aware
   routers to apply ICN semantics.  The intent is to enable rapid hybrid
   deployments and seamless interconnection of IP and Hybrid ICN
   domains.  Hybrid ICN uses [CICN] open-source software.  Initial tests
   have been done with 150 clients consuming DASH videos, which showed
   good scalability properties at the server side using the Hybrid ICN
   transport [H-ICN_3] [H-ICN_2].

6.4.  Summary of Deployment Trials

   In summary, there have been significant trials over the years with
   all the major ICN protocol flavors (e.g., 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.

   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 [Chakraborti]; also,
   this prototype has been extended to demonstrate this over a 5G-NR
   access.

   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.

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

7.  Deployment Issues Requiring Further Standardization

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

7.1.  Protocols for Application and Service Migration

   End-user 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.

7.2.  Protocols for Content Delivery Network Migration

   A key issue in CDNs is to quickly find a location of a copy of the
   object requested by an end user.  In ICN, a Named Data Object (NDO)
   is typically defined by its name.  [RFC6920] defines a mechanism that
   is suitable for static naming of ICN data objects.  Other ways of
   encoding and representing ICN names have been described in [RFC8609]
   and [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.

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

   Caching is an implicit feature in many ICN architectures that can
   improve performance and availability in several scenarios.  The ICN
   in-network caching can augment managed CDN and improve its
   performance.  The details of the interplay between ICN caching and
   managed CDN need further consideration.

7.3.  Protocols for Edge and Core Network Migration

   ICN provides the potential to redesign current edge and core network
   computing approaches.  Leveraging ICN's inherent security and its
   ability to make name data and dynamic computation results available
   independent of location 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, [RFC8075]
   specifies proxy mapping between CoAP and HTTP protocols.  Also,
   [RFC8613] is an example of how to pass end-to-end encrypted content
   between HTTP and CoAP by an application-layer security mechanism.
   Further work is required to identify if an approach like [RFC8613],
   or some other approach, is suitable to preserve ICN message security
   through future protocol translation functions of gateways/proxies.

   Interaction and interoperability between existing IP routing
   protocols (e.g., OSPF, RIP, 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.

   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 [FLOW-CLASS], which
   proposes an approach based on flow classification to enable
   functions, such ICN rate control and cache control.  Also, [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.

   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 [CNNinfo] [Contrace].

7.4.  Summary of ICN Protocol Gaps and Potential Protocol Efforts

   Without claiming completeness, Table 1 maps the open ICN issues
   identified in this document to potential protocol efforts that could
   address some aspects of the gap.

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

         Table 1: Mapping of ICN Gaps to Potential Protocol Efforts

8.  Conclusion

   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.

   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?).

   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.

   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.

9.  IANA Considerations

   This document has no IANA actions.

10.  Security Considerations

   ICN was purposefully designed from the start to have certain
   intrinsic security properties.  The most well known of which are
   authentication of delivered content and (optional) encryption of the
   content.  [RFC7945] has an extensive discussion of various aspects of
   ICN security, including many that are relevant to deployments.
   Specifically, [RFC7945] points out that ICN access control, privacy,
   security of in-network caches, and protection against various network
   attacks (e.g., DoS) have not yet been fully developed due to the lack
   of a sufficient mass of deployments.  [RFC7945] also points out
   relevant advances occurring in the ICN research community that hold
   promise to address each of the identified security gaps.  Lastly,
   [RFC7945] points out that as secure communications in the existing
   Internet (e.g., HTTPS) become the norm, major gaps in ICN security
   will inevitably slow down the adoption of ICN.

   In addition to the security findings of [RFC7945], this document has
   highlighted that all anticipated ICN deployment configurations will
   involve 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
   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 [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.

   Finally, the DOCTOR project discussed in Section 6.2.6 is an example
   of an early deployment that is looking at specific attacks against
   ICN infrastructure, in this case, looking at Interest Flooding
   Attacks [Nguyen-2] and Content Poisoning Attacks [Nguyen-1] [Mai-2]
   [Nguyen-3] and evaluating potential countermeasures based on MANO-
   orchestrated actions on the virtualized infrastructure [Mai-1].

11.  Informative References

   [Anastasiades]
              Anastasiades, C., "Information-centric communication in
              mobile and wireless networks", PhD Dissertation,
              DOI 10.7892/boris.83683, June 2016,
              <http://boris.unibe.ch/83683/1/16anastasiades_c.pdf>.

   [Baccelli] Baccelli, E., et al., "Information Centric Networking in
              the IoT: Experiments with NDN in the Wild", ACM-ICN '14:
              Proceedings of the 1st ACM Conference on Information-
              Centric Networking, DOI 10.1145/2660129.2660144, September
              2014, <http://conferences2.sigcomm.org/acm-
              icn/2014/papers/p77.pdf>.

   [BIER]     Trossen, D., Rahman, A., Wang, C., and T. Eckert,
              "Applicability of BIER Multicast Overlay for Adaptive
              Streaming Services", Work in Progress, Internet-Draft,
              draft-ietf-bier-multicast-http-response-03, 4 February
              2020, <https://tools.ietf.org/html/draft-ietf-bier-
              multicast-http-response-03>.

   [CCNx_UDP] PARC, "CCNx Over UDP", <https://www.ietf.org/proceedings/
              interim-2015-icnrg-04/slides/slides-interim-2015-icnrg-
              4-5.pdf>.

   [Chakraborti]
              Chakraborti, A., et al., "Design and Evaluation of a
              Multi-source Multi-destination Real-time Application on
              Content Centric Network", 2018 1st IEEE International
              Conference on Hot Information-Centric Networking (HotICN),
              DOI 10.1109/HOTICN.2018.8605980, August 2018,
              <https://doi.org/10.1109/HOTICN.2018.8605980>.

   [CICN]     fd.io, "Cicn", <https://wiki.fd.io/view/Cicn>.

   [CNNinfo]  Asaeda, H., Ooka, A., and X. Shao, "CCNinfo: Discovering
              Content and Network Information in Content-Centric
              Networks", Work in Progress, Internet-Draft, draft-irtf-
              icnrg-ccninfo-04, 22 March 2020,
              <https://tools.ietf.org/html/draft-irtf-icnrg-ccninfo-04>.

   [CONET]    Veltri, L., et al., "Supporting Information-Centric
              Functionality in Software Defined Networks", 2012 IEEE
              International Conference on Communications (ICC),
              DOI 10.1109/ICC.2012.6364916, November 2012,
              <http://netgroup.uniroma2.it/Stefano_Salsano/papers/
              salsano-icc12-wshop-sdn.pdf>.

   [Contrace] Asaeda, H., et al., "Contrace: a tool for measuring and
              tracing content-centric networks", IEEE Communications
              Magazine, Volume 53, Issue 3,
              DOI 10.1109/MCOM.2015.7060502, March 2015,
              <https://doi.org/10.1109/MCOM.2015.7060502>.

   [CUTEi]    Asaeda, H., Li, R., and N. Choi, "Container-Based Unified
              Testbed for Information Centric Networking", IEEE Network
              Volume 28, Issue:6, DOI 10.1109/MNET.2014.6963806,
              November 2014,
              <https://doi.org/10.1109/MNET.2014.6963806>.

   [C_FLOW]   D. Chang, et al., "C_flow: An efficient content delivery
              framework with OpenFlow", The International Conference on
              Information Networking 2014 (ICOIN2014), pp. 270-275,
              DOI 10.1109/ICOIN.2014.6799480, February 2014,
              <https://ieeexplore.ieee.org/document/6799480>.

   [DABBER]   Mendes, P., Sofia, R., Tsaoussidis, V., and C. Borrego,
              "Information-centric Routing for Opportunistic Wireless
              Networks", Work in Progress, Internet-Draft, draft-mendes-
              icnrg-dabber-04, 14 March 2020,
              <https://tools.ietf.org/html/draft-mendes-icnrg-dabber-
              04>.

   [DASH]     DASH, "DASH Industry Forum", <http://dashif.org/>.

   [Doctor]   DOCTOR, "Deployment and securisation of new
              functionalities in virtualized networking environments",
              <http://www.doctor-project.org/index.htm>.

   [fiveG-23501]
              3GPP, "System Architecture for the 5G System", Release 15,
              3GPP TS 23.501, December 2017.

   [fiveG-23502]
              3GPP, "Procedures for the 5G System (5GS)", Release 15,
              3GPP TS 23.502.

   [FLOW-CLASS]
              Moiseenko, I. and D. Oran, "Flow Classification in
              Information Centric Networking", Work in Progress,
              Internet-Draft, draft-moiseenko-icnrg-flowclass-05, 20
              January 2020, <https://tools.ietf.org/html/draft-
              moiseenko-icnrg-flowclass-05>.

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

   [H-ICN_1]  Cisco, "Cisco Announces Important Steps toward Adoption of
              Information-Centric Networking", February 2017,
              <http://blogs.cisco.com/sp/cisco-announces-important-
              steps-toward-adoption-of-information-centric-networking>.

   [H-ICN_2]  Cisco, "Mobile Video Delivery with Hybrid ICN: IP-
              integrated ICN Solution for 5G",
              <https://www.cisco.com/c/dam/en/us/solutions/collateral/
              service-provider/ultra-services-platform/mwc17-hicn-video-
              wp.pdf>.

   [H-ICN_3]  Muscariello, L., et al, "Hybrid Information-Centric
              Networking: ICN inside the Internet Protocol", ICNRG
              Interim Meeting, March 2018,
              <https://datatracker.ietf.org/meeting/interim-2018-icnrg-
              01/materials/slides-interim-2018-icnrg-01-sessa-hybrid-
              icn-hicn-luca-muscariello>.

   [ICN-5GC]  Ravindran, R., Suthar, P., Trossen, D., Wang, C., and G.
              White, "Enabling ICN in 3GPP's 5G NextGen Core
              Architecture", Work in Progress, Internet-Draft, draft-
              ravi-icnrg-5gc-icn-04, 31 May 2019,
              <https://tools.ietf.org/html/draft-ravi-icnrg-5gc-icn-04>.

   [ICN-DEP-CON]
              Paik, E., Yun, W., Kwon, T., and H. Choi, "Deployment
              Considerations for Information-Centric Networking", Work
              in Progress, Internet-Draft, draft-paik-icn-deployment-
              considerations-00, 15 July 2013,
              <https://tools.ietf.org/html/draft-paik-icn-deployment-
              considerations-00>.

   [ICN-IoT]  Ravindran, R., Zhang, Y., Grieco, L., Lindgren, A., Burke,
              J., Ahlgren, B., and A. Azgin, "Design Considerations for
              Applying ICN to IoT", Work in Progress, Internet-Draft,
              draft-irtf-icnrg-icniot-03, 2 May 2019,
              <https://tools.ietf.org/html/draft-irtf-icnrg-icniot-03>.

   [ICN-LTE-4G]
              Suthar, P., Stolic, M., Jangam, A., Ed., Trossen, D., and
              R. Ravindran, "Native Deployment of ICN in LTE, 4G Mobile
              Networks", Work in Progress, Internet-Draft, draft-irtf-
              icnrg-icn-lte-4g-05, 4 November 2019,
              <https://tools.ietf.org/html/draft-irtf-icnrg-icn-lte-4g-
              05>.

   [ICN-QoS]  Jangam, A., Suthar, P., and M. Stolic, "Supporting QoS
              aware Data Delivery in Information Centric Networks", Work
              in Progress, Internet-Draft, draft-anilj-icnrg-icn-qos-00,
              14 July 2018, <https://tools.ietf.org/html/draft-anilj-
              icnrg-icn-qos-00>.

   [ICN-TERM] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran,
              D., and C. Tschudin, "Information-Centric Networking
              (ICN): CCNx and NDN Terminology", Work in Progress,
              Internet-Draft, draft-irtf-icnrg-terminology-08, 17
              January 2020, <https://tools.ietf.org/html/draft-irtf-
              icnrg-terminology-08>.

   [ICN2020-Experiments]
              ICN2020, "D4.1: 1st Yearly WP4 Report & Demonstration",
              August 2017,
              <https://projects.gwdg.de/attachments/6840/D4.1-PU.pdf>.

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

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

   [IEEE_Communications]
              Trossen, D. and G. Parisis, "Designing and realizing an
              information-centric internet", IEEE Communications
              Magazine, Volume 50, Issue 7,
              DOI 10.1109/MCOM.2012.6231280,
              <https://doi.org/10.1109/MCOM.2012.6231280>.

   [Internet_Pricing]
              Trossen, D. and G. Biczok, "Not paying the truck driver:
              differentiated pricing for the future internet", ReARCH
              '10: Proceedings of the Re-Architecting the Internet
              Workshop, ReArch '10: Proceedings of the Re-Architecting
              the Internet Workshop, DOI 10.1145/1921233.1921235,
              November 2010, <https://doi.org/10.1145/1921233.1921235>.

   [Jacobson] Jacobson, V., et al., "Networking Named Content", CoNEXT
              '09: Proceedings of the 5th international conference on
              Emerging networking experiments and technologies,
              DOI 10.1145/1658939.1658941, December 2009,
              <https://doi.org/10.1145/1658939.1658941>.

   [Jangam]   Jangam, A., et al., "nlsrSIM: Porting and Simulation of
              Named-data Link State Routing Protocol into ndnSIM",
              DIVANet '17: Proceedings of the 6th ACM Symposium on
              Development and Analysis of Intelligent Vehicular Networks
              and Applications, DOI 10.1145/3132340.3132351, November
              2017, <https://dl.acm.org/citation.cfm?id=3132351>.

   [Mai-1]    Mai, H., et al., "Implementation of content poisoning
              attack detection and reaction in virtualized NDN
              networks", 2018 21st Conference on Innovation in Clouds,
              Internet and Networks and Workshops (ICIN),
              DOI 10.1109/ICIN.2018.8401591, July 2018,
              <https://ieeexplore.ieee.org/document/8401591>.

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

   [Marchal]  Marchal, X., et al., "Leveraging NFV for the Deployment of
              NDN: Application to HTTP Traffic Transport", NOMS 2018 -
              2018 IEEE/IFIP Network Operations and Management
              Symposium, DOI 10.1109/NOMS.2018.8406206, July 2018,
              <http://www.mallouli.com/recherche/publications/
              noms2018-1.pdf>.

   [Moiseenko]
              Moiseenko, I. and D. Oran, "TCP/ICN: Carrying TCP over
              Content Centric and Named Data Networks", ACM-ICN '16:
              Proceedings of the 3rd ACM Conference on Information-
              Centric Networking, DOI 10.1145/2984356.2984357, September
              2016, <http://conferences2.sigcomm.org/acm-
              icn/2016/proceedings/p112-moiseenko.pdf>.

   [MWC_Demo] InterDigital, "InterDigital Demo at Mobile World Congress
              (MWC)", 2016, <http://www.interdigital.com/
              download/56d5c71bd616f892ba001861>.

   [NDN-testbed]
              NDN, "NDN Testbed", <https://named-data.net/ndn-testbed/>.

   [NetInf]   Kutscher, D., Farrell, S., and E. Davies, "The NetInf
              Protocol", Work in Progress, Internet-Draft, draft-
              kutscher-icnrg-netinf-proto-01, 10 February 2013,
              <https://tools.ietf.org/html/draft-kutscher-icnrg-netinf-
              proto-01>.

   [NFD]      NDN, "NFD - Named Data Networking Forwarding Daemon",
              <https://named-data.net/doc/NFD/current/>.

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

   [NGMN-Network-Slicing]
              NGMN Alliance, "Description of Network Slicing Concept",
              NGMN 5G P1, Requirements & Architecture, Work Stream End-
              to-End Architecture, Version 1.0, January 2016,
              <https://www.ngmn.org/wp-content/
              uploads/160113_NGMN_Network_Slicing_v1_0.pdf>.

   [Nguyen-1] Nguyen, T., et al., "Content Poisoning in Named Data
              Networking: Comprehensive characterization of real
              deployment", 2017 IFIP/IEEE Symposium on Integrated
              Network and Service Management (IM),
              DOI 10.23919/INM.2017.7987266, July 2017,
              <https://doi.org/10.23919/INM.2017.7987266>.

   [Nguyen-2] Nguyen, T., Cogranne, R., and G. Doyen, "An optimal
              statistical test for robust detection against interest
              flooding attacks in CCN", 2015 IFIP/IEEE International
              Symposium on Integrated Network Management (IM),
              DOI 10.1109/INM.2015.7140299, July 2015,
              <https://doi.org/10.1109/INM.2015.7140299>.

   [Nguyen-3] Nguyen, T., et al., "A Security Monitoring Plane for Named
              Data Networking Deployment", IEEE Communications Magazine,
              Volume: 56, Issue 11, DOI 10.1109/MCOM.2018.1701135,
              November 2018,
              <https://doi.org/10.1109/MCOM.2018.1701135>.

   [ONAP]     ONAP, "Open Network Automation Platform",
              <https://www.onap.org/>.

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

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

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

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

   [Reed]     Reed, M., et al., "Stateless multicast switching in
              software defined networks", 2016 IEEE International
              Conference on Communications (ICC),
              DOI 10.1109/ICC.2016.7511036, May 2016,
              <https://doi.org/10.1109/ICC.2016.7511036>.

   [RFC6920]  Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
              Keranen, A., and P. Hallam-Baker, "Naming Things with
              Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
              <https://www.rfc-editor.org/info/rfc6920>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/info/rfc7252>.

   [RFC7426]  Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
              Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
              Defined Networking (SDN): Layers and Architecture
              Terminology", RFC 7426, DOI 10.17487/RFC7426, January
              2015, <https://www.rfc-editor.org/info/rfc7426>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/info/rfc7665>.

   [RFC7927]  Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
              Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
              "Information-Centric Networking (ICN) Research
              Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
              <https://www.rfc-editor.org/info/rfc7927>.

   [RFC7945]  Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S.,
              and G. Boggia, "Information-Centric Networking: Evaluation
              and Security Considerations", RFC 7945,
              DOI 10.17487/RFC7945, September 2016,
              <https://www.rfc-editor.org/info/rfc7945>.

   [RFC8075]  Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
              E. Dijk, "Guidelines for Mapping Implementations: HTTP to
              the Constrained Application Protocol (CoAP)", RFC 8075,
              DOI 10.17487/RFC8075, February 2017,
              <https://www.rfc-editor.org/info/rfc8075>.

   [RFC8568]  Bernardos, CJ., Rahman, A., Zuniga, JC., Contreras, LM.,
              Aranda, P., and P. Lynch, "Network Virtualization Research
              Challenges", RFC 8568, DOI 10.17487/RFC8568, April 2019,
              <https://www.rfc-editor.org/info/rfc8568>.

   [RFC8569]  Mosko, M., Solis, I., and C. Wood, "Content-Centric
              Networking (CCNx) Semantics", RFC 8569,
              DOI 10.17487/RFC8569, July 2019,
              <https://www.rfc-editor.org/info/rfc8569>.

   [RFC8609]  Mosko, M., Solis, I., and C. Wood, "Content-Centric
              Networking (CCNx) Messages in TLV Format", RFC 8609,
              DOI 10.17487/RFC8609, July 2019,
              <https://www.rfc-editor.org/info/rfc8609>.

   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
              <https://www.rfc-editor.org/info/rfc8613>.

   [SAIL]     SAIL, "Scalable and Adaptive Internet Solutions (SAIL)",
              <http://www.sail-project.eu/>.

   [SAIL_Content_Delivery]
              FP7, "NetInf Content Delivery and Operations",
              Objective FP7-ICT-2009-5-257448/D-3.2, January 2013,
              <https://sail-project.eu/wp-content/uploads/2012/06/
              SAIL_DB2_v1_0_final-Public.pdf>.

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

   [Tateson]  Tateson, J., et al., "Final Evaluation Report on
              Deployment Incentives and Business Models", PSIRP,
              Version 1.0, May 2010,
              <http://www.psirp.org/files/Deliverables/FP7-INFSO-ICT-
              216173-PSIRP-D4.6_FinalReportOnDeplIncBusinessModels.pdf>.

   [Techno_Economic]
              Trossen, D. and A. Kostopoulos, "Techno-Economics Aspects
              of Information-Centric Networking", Volume 2, Journal for
              Information Policy , DOI 10.5325/jinfopoli.2.2012.0026,
              June 2012,
              <https://doi.org/10.5325/jinfopoli.2.2012.0026>.

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

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

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

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

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

   [UMOBILE-7]
              Sofia, R., "D4.5 Report on Data Collection and Inference
              Models", Deliverable, September 2017.

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

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

   [UMOBILE-overview]
              UMOBILE, "Universal, mobile-centric and opportunistic
              communications architecture",
              <http://www.umobile-project.eu/>.

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

   [VSER-Mob] Azgin, A., et al., "Seamless Producer Mobility as a
              Service in Information-centric Networks", ACM-ICN '16:
              Proceedings of the 3rd ACM Conference on Information-
              Centric Networking, DOI 10.1145/2984356.2988521, September
              2016, <https://doi.org/10.1145/2984356.2988521>.

   [White]    White, G. and G. Rutz, "Content Delivery with Content-
              Centric Networking", February 2016,
              <http://www.cablelabs.com/wp-content/uploads/2016/02/
              Content-Delivery-with-Content-Centric-Networking-Feb-
              2016.pdf>.

Acknowledgments

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

   Special thanks to Dave Oran (ICNRG Co-chair) and Marie-Jose Montpetit
   for their extensive and thoughtful reviews of the document.  Their
   reviews helped to immeasurably improve the document quality.

Authors' Addresses

   Akbar Rahman
   InterDigital Communications, LLC
   1000 Sherbrooke Street West, 10th floor
   Montreal  H3A 3G4
   Canada

   Email: Akbar.Rahman@InterDigital.com
   URI:   http://www.InterDigital.com/


   Dirk Trossen
   Huawei Technologies Duesseldorf GmbH
   Riesstrasse 25
   80992 Munich
   Germany

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


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

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


   Ravi Ravindran
   Sterlite Technologies
   5201 Greatamerica Pkwy
   Santa Clara,  95054
   United States of America

   Email: ravi.ravindran@gmail.com