ICNRG                                                          A. Rahman
Internet-Draft                                                D. Trossen
Intended status: Informational                         InterDigital Inc.
Expires: March 9, 2019                                       D. Kutscher
                                                            R. Ravindran
                                                                  Huawei
                                                       September 5, 2018


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

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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 9, 2019.








Rahman, et al.            Expires March 9, 2019                 [Page 1]


Internet-Draft      Deployment Considerations for ICN     September 2018


Copyright Notice

   Copyright (c) 2018 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Deployment Configurations . . . . . . . . . . . . . . . . . .   4
     3.1.  Clean-slate ICN . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  ICN-as-an-Overlay . . . . . . . . . . . . . . . . . . . .   5
     3.3.  ICN-as-an-Underlay  . . . . . . . . . . . . . . . . . . .   5
       3.3.1.  Edge Network  . . . . . . . . . . . . . . . . . . . .   6
       3.3.2.  Core Network  . . . . . . . . . . . . . . . . . . . .   6
     3.4.  ICN-as-a-Slice  . . . . . . . . . . . . . . . . . . . . .   7
     3.5.  Composite-ICN Approach  . . . . . . . . . . . . . . . . .   8
   4.  Deployment Migration Paths  . . . . . . . . . . . . . . . . .   8
     4.1.  Application and Service Migration . . . . . . . . . . . .   9
     4.2.  Content Delivery Network Migration  . . . . . . . . . . .   9
     4.3.  Edge Network Migration  . . . . . . . . . . . . . . . . .  10
     4.4.  Core Network Migration  . . . . . . . . . . . . . . . . .  10
   5.  Deployment Trial Experiences  . . . . . . . . . . . . . . . .  11
     5.1.  ICN-as-an-Overlay . . . . . . . . . . . . . . . . . . . .  11
       5.1.1.  FP7 PURSUIT Efforts . . . . . . . . . . . . . . . . .  11
       5.1.2.  FP7 SAIL Trial  . . . . . . . . . . . . . . . . . . .  11
       5.1.3.  NDN Testbed . . . . . . . . . . . . . . . . . . . . .  12
       5.1.4.  ICN2020 Efforts . . . . . . . . . . . . . . . . . . .  12
       5.1.5.  UMOBILE Efforts . . . . . . . . . . . . . . . . . . .  12
     5.2.  ICN-as-an-Underlay  . . . . . . . . . . . . . . . . . . .  14
       5.2.1.  H2020 POINT and RIFE Efforts  . . . . . . . . . . . .  14
       5.2.2.  H2020 FLAME Efforts . . . . . . . . . . . . . . . . .  14
       5.2.3.  CableLabs Content Delivery System . . . . . . . . . .  15
       5.2.4.  NDN IoT Trials  . . . . . . . . . . . . . . . . . . .  15
       5.2.5.  NREN ICN Testbed  . . . . . . . . . . . . . . . . . .  16
       5.2.6.  Doctor Testbed  . . . . . . . . . . . . . . . . . . .  16
     5.3.  Composite-ICN Approach  . . . . . . . . . . . . . . . . .  16
       5.3.1.  Hybrid ICN Trials . . . . . . . . . . . . . . . . . .  16



Rahman, et al.            Expires March 9, 2019                 [Page 2]


Internet-Draft      Deployment Considerations for ICN     September 2018


     5.4.  Summary of Deployment Trials  . . . . . . . . . . . . . .  17
   6.  Deployment Issues Requiring Further Standardization . . . . .  17
     6.1.  Protocols for Application and Service Migration . . . . .  18
     6.2.  Protocols for Content Delivery Network Migration  . . . .  18
     6.3.  Protocols for Edge and Core Network Migration . . . . . .  18
     6.4.  Summary of ICN Protocol Gaps and Potential Protocol
           Efforts . . . . . . . . . . . . . . . . . . . . . . . . .  19
   7.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  20
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  22
   11. Informative References  . . . . . . . . . . . . . . . . . . .  22
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  31
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33

1.  Introduction

   The ICNRG charter identifies deployment guidelines as an important
   topic area for the ICN community.  Specifically, the charter states
   that defining concrete migration paths for ICN deployments which
   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.

   However, so far outside of some preliminary investigations such as
   [I-D.paik-icn-deployment-considerations], 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.  Finally, recommendations are made for potential future
   IETF standardization of key protocol functionality that will
   facilitate interoperable ICN deployments going forward.

2.  Terminology

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

      Deployment - In the context of this document, deployment refers to
      the final stage of the process of setting up an ICN network that
      is (1) ready for useful work (e.g. transmission of end user video
      and text) in a live environment, and (2) integrated and



Rahman, et al.            Expires March 9, 2019                 [Page 3]


Internet-Draft      Deployment Considerations for ICN     September 2018


      interoperable with the Internet.  We consider the Internet in its
      widest sense where it encompasses various access networks (e.g.
      WiFi, 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 Centres).  However, through out
      the document we typically limit the discussion 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 [I-D.irtf-icnrg-terminology] for further
      information.

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

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

3.  Deployment Configurations

   In this section, we present various deployment options for ICN.
   These are presented as "configurations" that allow for studying these
   options further.  While this document will outline experiences with
   various of these configurations (in Section 5), 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].

3.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 (e.g., existing applications which are typically tied
   directly to the TCP/IP protocol stack, IP routers, etc.).  As such,
   existing routing hardware as well as ancillary services 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 (Named Data Networking Forwarding




Rahman, et al.            Expires March 9, 2019                 [Page 4]


Internet-Draft      Deployment Considerations for ICN     September 2018


   Daemon) [NFD], CCN routers [Jacobson] or 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, here SDN switches.
   Such SDN infrastructure upgrades, while being possibly utilized for a
   Clean-slate ICN deployment would not necessary be used exclusively
   for such deployments.  Different proposals have been made for various
   ICN approaches to enable the operation over an SDN transport
   [Reed][CONET][C_FLOW].

3.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 such as 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 [I-D.kutscher-icnrg-netinf-proto].
   Finally, [Overlay_ICN] describes an incremental approach to deploying
   an ICN architecture based on segregating ICN user and control plane
   traffic which is particularly well-suited to being overlaid on SDN
   based networks.

   Regardless of the flavor, however, the overlay approach results in
   islands of ICN deployments over existing IP-based infrastructure.
   Furthermore, these ICN islands are typically connected to each other
   via ICN/IP tunnels.  In certain scenarios this requires
   interoperability between existing IP routing protocols (e.g.  OSPF,
   RIP, ISIS) and ICN based ones.  ICN-as-an-Overlay can be deployed
   over 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.

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



Rahman, et al.            Expires March 9, 2019                 [Page 5]


Internet-Draft      Deployment Considerations for ICN     September 2018


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

3.3.1.  Edge Network

   Native ICN networks may be located at the edge of the network which
   allows the possibility of introducing new network architectures and
   protocols, and in this context ICN is an attractive option for newer
   deployments such as IoT [I-D.irtf-icnrg-icniot].  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.  Furthermore, ICN will allow
   enhancement of the role of gateways/proxies as ICN message security
   should be preserved through the protocol translation function of a
   gateway/proxy and thus offer a substantial gain.

   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 use case scenario, the [VSER]
   platform shows the realization of a multi-party audio/video
   conferencing service over such a edge cloud deployment of ICN routers
   realized over commodity hardware platforms.  This platform has also
   been extended to offer seamless mobility and mobility as a service
   [VSER-Mob] features.

3.3.2.  Core Network

   In this sub-option, 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 network attachment point, such as realized in access
   points or customer premise equipment, which in turn provides a
   standard IP interface to existing user devices.  Towards peering
   networks, such network attachment point turns into a modified border




Rahman, et al.            Expires March 9, 2019                 [Page 6]


Internet-Draft      Deployment Considerations for ICN     September 2018


   gateway/proxy, preserving the perception of an IP-based core network
   towards any peering network.

   The work in [White] proposes a similar deployment configuration.
   Here, the target is the use of ICN for content distribution within
   CDN server farms, i.e., 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.

3.4.  ICN-as-a-Slice

   The objective of Network slicing [NGMN]is to multiplex a general pool
   of compute, storage and bandwidth resources among multiple service
   networks with exclusive SLA requirements on transport level QoS and
   security.  This is enabled through NFV and SDN technology functions
   that enables 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 network
   enabling dynamic slicing of air interface spectrum resources among
   various services hence naturally extending itself to end points and
   also cloud resources, across multiple domains, to offer end-to-end
   guarantees.  These slices once instantiated could include a mix of
   connectivity services like LTE-as-a-service or OTT services like VoD
   or other IoT services through composition of a group of virtual and/
   or physical network functions at control, user and service plane
   level.  Such a framework can also be used to realize ICN slices with
   its own control, service and forwarding plane over which one or more
   end-user services can be delivered.

   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, or 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 [I-D.ravi-icnrg-5gc-icn].  Such a
   generalized network slicing framework should be able to offer service
   slices to be realized using both IP and ICN.  Coupled with the view
   of ICN functions as being "chained service functions" [RFC7665], an
   ICN deployment within such a slice could also be realized within the
   emerging orchestration 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 an 5G-ICN instance [Ravindran].





Rahman, et al.            Expires March 9, 2019                 [Page 7]


Internet-Draft      Deployment Considerations for ICN     September 2018


   At the level of the specific technologies involved, such as ONAP
   [ONAP] that can be used to orchestrate slices, the 5G-ICN slice
   requires compatibility for instance at the level of the forwarding/
   data plane depending on if it is realized as an overlay or using
   programmable data planes.  With SDN emerging for new network
   deployments, some ICN approaches will need to integrate with SDN as a
   data plane forwarding function, as briefly discussed in Section 3.1.
   Further cross domain ICN slices can also be realized using frameworks
   such as [ONAP].

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

4.  Deployment Migration Paths

   After outlining the various ICN deployment configurations in
   Section 3, we now focus on the various migration paths that will have
   importance to the various stakeholders that are usually involved in
   the deployment of a technology at (ultimately) large scale.  We can
   identify these stakeholders as:

   o  Application providers

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

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

   o  End device manufacturers and users

   Note that our presentation purely focuses on technological aspects of
   such migration.  Economic or regulatory aspects, such as studied in
   [Tateson], [Techno_Economic] and [Internet_Pricing] are left out of
   our discussion.





Rahman, et al.            Expires March 9, 2019                 [Page 8]


Internet-Draft      Deployment Considerations for ICN     September 2018


4.1.  Application and Service Migration

   The internet is full of applications and services, utilizing the
   innovation capabilities of 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 the hypertext transfer protocol.  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 options presented in
   Section 3.3.2 and Section 3.3.1 aim at providing some level of
   backward compatibility to this existing ecosystem through a proxy
   based message flow mapping mechanism (e.g., mapping of existing
   HTTP/TCP/IP message flows to HTTP/TCP/IP/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 over NDN to guarantee a high level of
   compatibility with HTTP while enabling an efficient caching of Data
   in the ICN island.

   Alternatively, ICN as an overlay (Section 3.2), as well as ICN-as-
   a-Slice (Section 3.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.

   Finally, [I-D.irtf-icnrg-icn-lte-4g] outlines a dual-stack end user
   device approach that is applicable for all deployment configurations.
   Specifically, [I-D.irtf-icnrg-icn-lte-4g] introduces middleware
   layers (called the Transport Convergence Layer, TCL) in the device
   that will dynamically adapt existing applications to either an
   underlying ICN protocol stack or standard IP protocol stack.  This
   involves end device signalling with the network to determine which
   protocol stack instance and associated middleware adaptation layers
   to utilize for a given application transaction.

4.2.  Content Delivery Network Migration

   A significant number of services and applications are devoted to
   content delivery in some form, either as video delivery services,
   social media platforms, and many others.  Content delivery networks
   (CDNs) are deployed to assist these services through localizing the



Rahman, et al.            Expires March 9, 2019                 [Page 9]


Internet-Draft      Deployment Considerations for ICN     September 2018


   content requests and therefore reducing latency and possibly increase
   utilization of available bandwidth as well as reducing the load on
   origin servers.  Similar to the previous sub-section, the underlay
   deployment configurations presented in Section 3.3.2 and
   Section 3.3.1 aim at providing a migration path for existing CDNs.
   This is also highlighted in the BIER WG use case document
   [I-D.ietf-bier-use-cases], specifically with potential benefits in
   terms of utilizing multicast in the delivery of content but also
   reducing load on origin as well as delegation server.  We return to
   this benefit in the trial experiences in Section 5.

4.3.  Edge Network Migration

   Edge networks often see the deployment of novel network level
   technology, e.g., in the space of IoT.  Such IoT deployments have for
   many years 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 3.3.1, application gateways/proxies can
   integrate such edge deployments into IP-based services, e.g.,
   utilizing CoAP [RFC7252] based machine-to-machine (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.  With the proliferation of network softwarization (using
   technologies like service orchestration frameworks leveraging NFV and
   SDN concepts) access networks and other network segments, the ICN-as-
   a-Slice deployment configuration in Section 3.4 provides a suitable
   migration path for integration non-IP-based edge networks into the
   overall system through virtue of realizing the relevant (ICN)
   protocols in an access network slice.

4.4.  Core Network Migration

   Migrating core networks (e.g., of the Internet or Mobile core
   network) requires not only significant infrastructure renewal but
   also the fulfillment of the significant performance requirements,
   particularly in terms of throughput.  For those parts of the core
   network that would see a migration to an SDN-based optical transport
   the ICN-as-a-Slice deployment configuration in Section 3.4 could see
   the introduction of native ICN solutions within slices provided by
   the SDN-enabled transport network or as virtual network functions,
   allowing for isolating the ICN traffic while addressing the specific
   ICN performance benefits and constraints within such isolated slice.
   For ICN solutions that natively work on top of SDN, the underlay
   deployment configuration in Section 3.3.2 provides an additional
   migration path, preserving the IP-based services and applications at



Rahman, et al.            Expires March 9, 2019                [Page 10]


Internet-Draft      Deployment Considerations for ICN     September 2018


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

5.  Deployment Trial Experiences

   In this section, we will outline trial experiences, often conducted
   within international collaborative project efforts.  Our focus here
   is on the realization of the various deployment configurations in
   Section 3, and we therefore categorize the trial experiences
   according to these deployment configurations.  While a large body of
   work exists at the simulation or emulation level, we specifically
   exclude these studies from our presentation to retain the focus on
   real life experiences.

5.1.  ICN-as-an-Overlay

5.1.1.  FP7 PURSUIT Efforts

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

5.1.2.  FP7 SAIL Trial

   The Network of Information (NetInf) is the approach to Information-
   Centric Networking developed by the European Union (EU) FP7 SAIL
   project (http://www.sail-project.eu/).  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
   abstraction.  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 3.2.  Reference
   [SAIL_NetInf] describes several trials including a stadium
   environment large crowd scenario and a multi-site testbed, leveraging
   NetInf's Routing Hint approach for routing scalability.







Rahman, et al.            Expires March 9, 2019                [Page 11]


Internet-Draft      Deployment Considerations for ICN     September 2018


5.1.3.  NDN Testbed

   The Named Data Networking (NDN) is one of the research projects
   funded by the National Science Foundation (NSF) of the USA as part of
   the Future Internet Architecture Program.  The original NDN proposal
   was positioned as a Clean-slate ICN replacement of IP (Section 3.1).
   However, in several trials, NDN generally follows the overlay
   deployment configuration of Section 3.2 to connect institutions over
   the public Internet across several continents.  The use cases covered
   in the trials include real-time video-conferencing, geo-locating, and
   interfacing to consumer applications.  Typical trials involve up to
   100 NDN enabled nodes (https://named-data.net/ndn-testbed/) [Jangam].

5.1.4.  ICN2020 Efforts

   ICN2020 is an ICN related research project funded by the EU and Japan
   as part of the H2020 research and innovation program and NICT
   (http://www.icn2020.org/).  ICN2020 has a specific focus to advance
   ICN towards real-world deployments through innovative applications
   and global scale experimentation.  Both NDN and CCN approaches are
   within the scope of the project.

   ICN2020 was kicked off in July 2016 and at the end of the first year
   released a set of public technical reports [ICN2020].  The report
   titled "Deliverable D4.1: 1st yearly report on Testbed and
   Experiments (WP4)" contains a detailed description of the progress
   made in both local testbeds as well as federated testbeds.  The plan
   for the federated testbed includes integrating the NDN testbed, the
   CUTEi testbed [RFC7945] [CUTEi] and the GEANT testbed
   (https://www.geant.org/) to create an overlay deployment
   configuration of Section 3.2 over the public Internet.

5.1.5.  UMOBILE Efforts

   UMOBILE (universal mobile-centric and opportunistic communications
   architecture) is one of the ICN research projects under the H2020
   framework program (http://www.umobile-project.eu/).  The UMOBILE
   architecture integrates the principles of Delay Tolerant Networking
   (DTN) and ICN in a common framework to support edge computation 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 3.2.  UMOBILE aims to advance
   networking technologies and architectures.  In particular, extending
   Internet functionally - by combining ICN and DTN technologies;
   geographically - by allowing for inter-networking over remote and
   isolated areas; and social aspects - by allowing low-cost access and
   free user-to-user networking.



Rahman, et al.            Expires March 9, 2019                [Page 12]


Internet-Draft      Deployment Considerations for ICN     September 2018


   One of the innovative aspects of UMOBILE was the extension of the NDN
   framework to encompass push network services (e.g., mobility
   management, intermittent connectivity support) and user services
   (e.g., pervasive content management) as close as possible to the end-
   users to optimise bandwidth utilization and resource management.
   Another innovation was the evolution of the NDN framework to operate
   in wireless networks, namely in emergency scenarios [UMOBILE-3],
   using secure, reliable wireless services able to operate even with
   intermittent connectivity.  To achieve such a goal, the NDN framework
   was leveraged with a messaging system based on a new application,
   called Oi!  [UMOBILE-4], which uses two methods of push communication
   based on a new branch of NDN Android, called NDN-OPP [UMOBILE-5] that
   supports intermittent wireless networking.  NDN-OPP implements a new
   data-centric wireless routing protocol, DABBER [UMOBILE-6]
   [I-D.mendes-icnrg-dabber], which was designed based on data
   reachability metrics that take into consideration availability and
   centrality of adjacent wireless nodes, as well as the availability of
   different data sources.  The contextual-awareness about the operation
   of the wireless network is obtained in a self-learning approach, by a
   software-based agent, the Contextual Manager, running within the
   wireless node [UMOBILE-7].

   During the project time (Feb 2015 - Apr 2018), the consortium
   completed some couple of significant ICN deployment trails.  One of
   that was related to the post disaster scenario.  In this trial
   [UMOBILE-8], a special DTN face was created to provide reachability
   to remote area where there is no typical Internet connection.
   Another trail was the ICN deployment over the Guifi.net community
   network.  This trial focused on the evaluation of ICN edge computing
   platform, called PiCasso [UMOBILE-9] which is a part of UMOBILE
   project.  In this trial, ten(10) raspberry Pis were deployed across
   the Sants area of Barcelona to create an ICN overlay network on top
   of the existing IP routing protocol (e.g., qMp routing).  Through the
   evaluation of this trail, it shows that ICN plays a key role in
   improving the quality of service delivery as well as reducing the
   traffic consumption in the intermittent connectivity environment
   (e.g., wireless community network).  A third trial was focused on
   displaying the capability of the UMOBILE architecture to reach
   disconnected areas and assist responsible authorities in challenged
   events, corresponding to an infrastructure scenario.  This trial was
   conducted in April 2018 in Italy, with the patronage of the Civil
   Protection Department of Umbria Region.  In an outdoor demonstration,
   it was shown how to overcome a low or missing connectivity, thus
   allowing users to communicate, especially in emergency situations as
   the one simulated during the demo.  The demonstration encompasses
   seven (7) end-user devices, one (1) access-point, and one (1)
   gateway.  An extended demonstration to the Portuguese Civil




Rahman, et al.            Expires March 9, 2019                [Page 13]


Internet-Draft      Deployment Considerations for ICN     September 2018


   protection authority in March 2018, included also an UAV carrying a
   UMOBILE raspberry Pi that served as relay and carrier of information.

5.2.  ICN-as-an-Underlay

5.2.1.  H2020 POINT and RIFE Efforts

   POINT and RIFE are two more ICN related research projects funded by
   the EU as part of the H2020 effort.  The efforts in the H2020
   POINT+RIFE projects follow the underlay deployment configuration in
   Section 3.3.2, although this is mixed with utilizing an overlay
   deployment to provide multi-national connectivity.  However, underlay
   SDN-based deployments do exist at various project partner sites,
   e.g., at Essex University, without any overlaying being realized.
   Edge-based network attachment points (NAPs) provide the IP/HTTP-level
   protocol mapping onto ICN protocol exchanges, while the SDN underlay
   (or the VPN-based L2 underlay) is used as a transport network.

   The multicast as well as service endpoint surrogate benefits in HTTP-
   based scenarios, such as for HTTP-level streaming video delivery,
   have been demonstrated in the deployed POINT test bed with 80+ nodes
   being utilized.  Demonstrations of this capability have been given to
   the ICNRG in 2016, and public demonstrations were also provided at
   events such as Mobile World Congress in 2016 [MWC_Demo].  The trial
   has also been accepted by the ETSI MEC group as a proof-of-concept
   with a demonstration at the ETSI MEC World Congress in 2016.

   While the afore-mentioned 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 in the community network
   of "guifi.net" in the Barcelona region, where the solution was
   deployed in 40 households, providing general Internet connectivity to
   the residents.  Standard IPTV 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.

5.2.2.  H2020 FLAME Efforts

   The H2020 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 3.3.2 as
   per 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



Rahman, et al.            Expires March 9, 2019                [Page 14]


Internet-Draft      Deployment Considerations for ICN     September 2018


   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
   playout of the video originating from the local NAP instead of a
   remote server.

   Ensuring the technology readiness and the early trialing of the ICN
   capabilities lays the ground for the goal of the H2020 FLAME efforts
   to conduct 23 large-scale experiments in the area of Future Media
   Internet (FMI) throughout 2018 and 2019.  Standard media service
   functions as well as applications will ultimately utilize the ICN
   underlay in the delivery of their experience.  The platform, which
   includes the ICN capabilities, will utilize concepts of SFC,
   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.

5.2.3.  CableLabs Content Delivery System

   The work in [White] proposes an underlay deployment configuration
   based on Section 3.3.2.  The use case is ICN for content distribution
   within CDN server farms (which can be quite large and complex) to
   leverage ICN's superior in-network caching properties.  This "island
   of ICN" based CDN is then used to service standard HTTP/IP-based
   content retrieval request coming from the general Internet.  This
   approach acknowledges that whole scale replacement (see Section 3.1)
   of existing HTTP/IP end user applications and related Web
   infrastructure is a difficult proposition.  [White] does not yet
   provide results but indicated that experiments will be forthcoming.

5.2.4.  NDN IoT Trials

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






Rahman, et al.            Expires March 9, 2019                [Page 15]


Internet-Draft      Deployment Considerations for ICN     September 2018


5.2.5.  NREN ICN Testbed

   The National Research and Education Network (NREN) ICN Testbed is a
   project sponsored by Cisco, Internet2, and the U.S.  Research and
   Education community.  Participants include universities and US
   federal government entities that connect via a nation-wide VPN-based
   L2 underlay.  The testbed uses the CCN approach and is based on the
   [CICN] open source software.  There are approximately 15 nodes spread
   across the USA which 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.

5.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 Management and Orchestration (MANO) aspects to build an
   operational NDN network regarding essential criteria such as
   security, performance and interoperability.

   The data-plane relies on a 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.  The testbed carries
   real Web traffic of users, and has been currently evaluated with the
   top-1000 most popular Web sites.  The users only need to set the
   gateway as the Web proxy.  The control-plane relies on a central
   manager which uses machine learning based detection methods [Mai-1]
   from the date gathered by distributed probes and applies orchestrated
   counter-measures 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.  The end target
   of the project is to have a future complete testbed where the
   developed concepts will be implemented, monitored and validated.

5.3.  Composite-ICN Approach

5.3.1.  Hybrid ICN Trials

   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



Rahman, et al.            Expires March 9, 2019                [Page 16]


Internet-Draft      Deployment Considerations for ICN     September 2018


   have been done with 150 clients consuming DASH (HTTP) videos which
   showed good scalability properties at the Server Side using the
   Hybrid ICN transport [H-ICN_3] [H-ICN_2].

5.4.  Summary of Deployment Trials

   In summary, there have been significant trials over the years with
   all the major ICN protocol flavors (e.g., CCN, NDN, 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. video-conferencing and IPTV).  Another
   limitation of the trials is that all of them involve less than 1000
   users maximum.

   The ICN-as-a-Slice configuration still has not be trialled primarily
   due to the fact that 5G standards are still in flux and not expected
   to be stable before the 2019 time frame.  The Clean-slate ICN
   approach has obviously never been trialled 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 and 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 5.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.

6.  Deployment Issues Requiring Further Standardization

   The 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 that may be relevant for
   further standardization effort in 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 4.  The identified list of potential
   protocol functionality is not exhaustive.




Rahman, et al.            Expires March 9, 2019                [Page 17]


Internet-Draft      Deployment Considerations for ICN     September 2018


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

6.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.  There already exists [RFC6920]
   that is suitable for static naming of ICN data objects.  Other ways
   of encoding and representing ICN names have been described in
   [I-D.irtf-icnrg-ccnxmessages] and [I-D.mosko-icnrg-ccnxurischeme].
   Naming dynamically generated data requires different approaches (for
   example, hash digest based names would normally not work), and there
   is 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 broadcast streaming TV.  However, as
   discussed in Section 5.2.1, certain ICN approaches provide
   substantial improvements over IP multicast, such as the implicit
   support for multicast retrieval of content in all ICN flavours.

   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.

6.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 secure, yet light-weight
   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.



Rahman, et al.            Expires March 9, 2019                [Page 18]


Internet-Draft      Deployment Considerations for ICN     September 2018


   For example, [RFC8075] specifies proxy mapping between CoAP and HTTP
   protocols.  However, as mentioned previously, ICN will allow us to
   evolve the role of gateways/proxies as ICN message security should be
   preserved through the protocol translation function of a thus offer a
   substantial gain.

   Interaction and interoperability between existing IP routing
   protocols (e.g., OSPF, RIP, ISIS) and ICN routing approaches(e.g.,
   NFD, CCN routers) are expected especially in the overlay approach.
   Another important topic is integration of ICN into networks that
   support virtualized infrastructure in the form of NFV/SDN and most
   likely utilizing Service Function Chaining (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 Differentiated Services (DiffServ), Integrated
   Services (IntServ) and Resource Reservation Protocol (RSVP).  Some
   initial ideas for QoS support in ICN networks are outlined in
   [I-D.moiseenko-icnrg-flowclass] which proposes a flow classification
   based approach to enable functions such ICN rate control and cache
   control.  Also [I-D.anilj-icnrg-icn-qos] proposes how to use DiffServ
   DSCP codes to support QoS for ICN based data path delivery.  Further
   work is required to identify the best approaches and alternatives for
   support of QoS in ICN networks .

   Operations and Maintenance (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 modelling
   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 CCNinfo [I-D.asaeda-icnrg-ccninfo] [Contrace].

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








Rahman, et al.            Expires March 9, 2019                [Page 19]


Internet-Draft      Deployment Considerations for ICN     September 2018


   +--------------+----------------------------------------------------+
   | 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 including      |
   | support      | possible impacts to SFC                            |
   |              |                                                    |
   | 7-ICN        | Mapping of HTTP and other protocols onto ICN       |
   | mapping      | message exchanges (and vice-versa) while           |
   |              | preserving ICN message security                    |
   |              |                                                    |
   | 8-QoS        | Support of ICN QoS via mechanisms such as DiffServ |
   | support      | and flow classification                            |
   |              |                                                    |
   | 9-OAM        | YANG models, NETCONF/RESTCONF protocols,           |
   | support      | and network performance measurements               |
   |              |                                                    |
   +--------------+----------------------------------------------------+

        Table 1: Mapping of ICN Gaps to Potential Protocol Efforts

7.  Conclusion

   This document provides high level deployment considerations for 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 and core networks to go to an ICN
   paradigm (e.g., for an IoT deployment).  ICN-as-an-Overlay is
   probably the easiest configuration to deploy rapidly as it leaves the
   underlying IP infrastructure essentially untouched.  However its



Rahman, et al.            Expires March 9, 2019                [Page 20]


Internet-Draft      Deployment Considerations for ICN     September 2018


   applicability for general deployment must be considered on a case by
   case basis (e.g., based on if it can run all required applications or
   other similar criteria).  ICN-as-a-Slice is an attractive deployment
   option for future 5G systems (i.e., for 5G radio and core networks)
   which will naturally support network slicing, but this still has to
   be validated through actual 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 be
   considered on a case by case basis.

   For the crucial issue of existing application and service migration
   to ICN, various mapping schemes are possible to mitigate impacts.
   For example, HTTP/TCP/IP flows may be mapped to/from ICN message
   flows at proxies in the ICN-as-an-Underlay configurations leaving the
   massive number of existing end point applications/services untouched
   or minimally impacted.  Also dual stack end user devices that include
   middleware to allow applications to communicate in both ICN mode and
   standard IP mode are an attractive proposition for gradual and
   geographically discontinuous introduction for all deployment
   configurations.

   There has been significant trial experience with all the major ICN
   protocol flavors (e.g., CCN, NDN, 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 1000 users.  It
   is recommended that future ICN deployments scale their users
   gradually and closely monitor network performance as they go above
   1000 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.

8.  IANA Considerations

   This document requests no IANA actions.

9.  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 which are relevant to deployments.
   Specifically, [RFC7945] points out that ICN access control, privacy,



Rahman, et al.            Expires March 9, 2019                [Page 21]


Internet-Draft      Deployment Considerations for ICN     September 2018


   security of in-network caches, and protection against various network
   attacks (e.g.  DoS) have not yet been fully developed due to the lack
   of a sufficient mass of deployments.  [RFC7945] also points out
   relevant advances occurring in the ICN research community that hold
   promise to address each of the identified security gaps.  Lastly,
   [RFC7945] points out that as secure communications in the existing
   Internet (e.g.  HTTPS) becomes the norm, that major gaps in ICN
   security will inevitably slow down the adoption of ICN.

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

   Finally, the Doctor project discussed in Section 5.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]
   and evaluation of potential counter-measures based on MANO
   orchestrated actions on the virtualized infrastructure [Mai-1] .

10.  Acknowledgments

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

11.  Informative References

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








Rahman, et al.            Expires March 9, 2019                [Page 22]


Internet-Draft      Deployment Considerations for ICN     September 2018


   [Baccelli]
              Baccelli, E. and et al., "Information Centric Networking
              in the IoT: Experiments with NDN in the Wild", ACM
              20164, Paris, France, 2014,
              <http://conferences2.sigcomm.org/acm-icn/2014/papers/
              p77.pdf>.

   [C_FLOW]   Suh, J. and et al., "C_FLOW: Content-Oriented Networking
              over OpenFlow", Open Networking Summit, April, 2012,
              <http://opennetsummit.org/archives/apr12/site/pdf/
              snu.pdf>.

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

   [CICN]     CICN, "Community Information-Centric Networking (CICN)",
              2017, <https://wiki.fd.io/view/Cicn>.

   [CONET]    Veltri, L. and et al., "CONET Project: Supporting
              Information-Centric Functionality in Software Defined
              Networks", Workshop on Software Defined Networks, , 2012,
              <http://netgroup.uniroma2.it/Stefano_Salsano/papers/
              salsano-icc12-wshop-sdn.pdf>.

   [Contrace]
              Asaeda, H. and et al., "Contrace: A Tool for Measuring and
              Tracing Content-Centric Networks", IEEE Communications
              Magazine, Vol.53, No.3 , 2015.

   [CUTEi]    Asaeda, H. and N. Choi, "Container-Based Unified Testbed
              for Information Centric Networking", IEEE Network, Vol.28,
              No.6 , 2014.

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

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

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





Rahman, et al.            Expires March 9, 2019                [Page 23]


Internet-Draft      Deployment Considerations for ICN     September 2018


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

   [H-ICN_1]  Cisco, "Hybrid ICN: Cisco Announces Important Steps toward
              Adoption of Information-Centric Networking", 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", 2017,
              <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. and et al., "Hybrid Information-Centric
              Networking: ICN inside the Internet Protocol", 2018,
              <https://datatracker.ietf.org/meeting/interim-2018-icnrg-
              01/materials/slides-interim-2018-icnrg-01-sessa-hybrid-
              icn-hicn-luca-muscariello>.

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

   [I-D.anilj-icnrg-icn-qos]
              Jangam, A., suthar, P., and M. Stolic, "Supporting QoS
              aware Data Delivery in Information Centric Networks",
              draft-anilj-icnrg-icn-qos-00 (work in progress), July
              2018.

   [I-D.asaeda-icnrg-ccninfo]
              Asaeda, H. and X. Shao, "CCNinfo: Discovering Content and
              Network Information in Content-Centric Networks", draft-
              asaeda-icnrg-ccninfo-01 (work in progress), June 2018.

   [I-D.ietf-bier-use-cases]
              Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A.,
              Przygienda, T., Gulko, A., Robinson, D., Arya, V., and C.
              Bestler, "BIER Use Cases", draft-ietf-bier-use-cases-07
              (work in progress), July 2018.







Rahman, et al.            Expires March 9, 2019                [Page 24]


Internet-Draft      Deployment Considerations for ICN     September 2018


   [I-D.irtf-icnrg-ccnxmessages]
              Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV
              Format", draft-irtf-icnrg-ccnxmessages-08 (work in
              progress), July 2018.

   [I-D.irtf-icnrg-icn-lte-4g]
              suthar, P., Stolic, M., Jangam, A., Trossen, D., and R.
              Ravindran, "Native Deployment of ICN in LTE, 4G Mobile
              Networks", draft-irtf-icnrg-icn-lte-4g-01 (work in
              progress), July 2018.

   [I-D.irtf-icnrg-icniot]
              Ravindran, R., Zhang, Y., Grieco, L., Lindgren, A.,
              Raychadhuri, D., Baccelli, E., Burke, J., Wang, G.,
              Ahlgren, B., and O. Schelen, "Design Considerations for
              Applying ICN to IoT", draft-irtf-icnrg-icniot-01 (work in
              progress), February 2018.

   [I-D.irtf-icnrg-terminology]
              Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran,
              D., and C. Tschudin, "Information-Centric Networking
              (ICN): CCN and NDN Terminology", draft-irtf-icnrg-
              terminology-00 (work in progress), December 2017.

   [I-D.irtf-nfvrg-gaps-network-virtualization]
              Bernardos, C., Rahman, A., Zuniga, J., Contreras, L.,
              Aranda, P., and P. Lynch, "Network Virtualization Research
              Challenges", draft-irtf-nfvrg-gaps-network-
              virtualization-10 (work in progress), September 2018.

   [I-D.kutscher-icnrg-netinf-proto]
              Kutscher, D., Farrell, S., and E. Davies, "The NetInf
              Protocol", draft-kutscher-icnrg-netinf-proto-01 (work in
              progress), February 2013.

   [I-D.mendes-icnrg-dabber]
              Mendes, P., Sofia, R., Tsaoussidis, V., Diamantopoulos,
              S., and C. Sarros, "Information-centric Routing for
              Opportunistic Wireless Networks", draft-mendes-icnrg-
              dabber-01 (work in progress), August 2018.

   [I-D.moiseenko-icnrg-flowclass]
              Moiseenko, I. and D. Oran, "Flow Classification in
              Information Centric Networking", draft-moiseenko-icnrg-
              flowclass-02 (work in progress), July 2018.






Rahman, et al.            Expires March 9, 2019                [Page 25]


Internet-Draft      Deployment Considerations for ICN     September 2018


   [I-D.mosko-icnrg-ccnxurischeme]
              marc.mosko@parc.com, m. and c. cwood@parc.com, "The CCNx
              URI Scheme", draft-mosko-icnrg-ccnxurischeme-01 (work in
              progress), April 2016.

   [I-D.paik-icn-deployment-considerations]
              Paik, E., Yun, W., Kwon, T., and h.
              hgchoi@mmlab.snu.ac.kr, "Deployment Considerations for
              Information-Centric Networking", draft-paik-icn-
              deployment-considerations-00 (work in progress), July
              2013.

   [I-D.ravi-icnrg-5gc-icn]
              Ravindran, R., suthar, P., Trossen, D., and G. White,
              "Enabling ICN in 3GPP's 5G NextGen Core Architecture",
              draft-ravi-icnrg-5gc-icn-02 (work in progress), July 2018.

   [ICN2020]  ICN2020, "ICN2020 Deliverables", 2017,
              <http://www.icn2020.org/dissemination/
              deliverables-public/>.

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

   [IEEE_Communications]
              Trossen, D. and G. Parisis, "Designing and Realizing an
              Information-Centric Internet", Information-Centric
              Networking, IEEE Communications Magazine Special Issue,
              2012.

   [Internet_Pricing]
              Trossen, D. and G. KBiczok, "Not Paying the Truck Driver:
              Differentiated Pricing for the Future Internet", ReArch
              Workshop in conjunction with ACM Context, December, 2010.

   [Jacobson]
              Jacobson, V. and et al., "Networking Named Content",
              Proceedings of ACM Context, , 2009.

   [Jangam]   Jangam, A. and et al., "Porting and Simulation of Named-
              data Link State Routing Protocol into ndnSIM", ACM
              DIVANet'17, Miami Beach, USA, 2017,
              <http://symposium.nsercdiva.com/2017/program.html>.






Rahman, et al.            Expires March 9, 2019                [Page 26]


Internet-Draft      Deployment Considerations for ICN     September 2018


   [Mai-1]    Mai, H., Aouadj, M., Doyen, G., Kondo, D., Marchal, X.,
              Cholez, T., Montes de Oca, E., and W. Mallouli,
              "Implementation of Content Poisoning Attack Detection and
              Reaction in Virtualized NDN Networks", 21st Conference on
              Innovation in Clouds, Internet and Networks, ICIN 2018
              (demo paper) IEEE, 2018,
              <http://www.mallouli.com/recherche/publications/
              noms2018-1.pdf>.

   [Mai-2]    Mai, H., Nguyen, T., Doyen, G., Cogranne, R., Mallouli,
              W., Montes de Oca, E., and O. Festor, "Towards a Security
              Monitoring Plane for Named Data Networking: Application to
              Content Poisoning Attack", Proceedings of the 2018 IEEE/
              IFIP Symposium on Network Operations and Management (NOMS)
              IEEE, 2018.

   [Marchal]  Marchal, X., El Aoun, M., Mathieu, B., Cholez, T., Doyen,
              G., Mallouli, W., and O. Festor, "Leveraging NFV for the
              Deployment of NDN: Application to HTTP Traffic Transport",
              Proceedings of the 2018 IEEE/IFIP Symposium on Network
              Operations and Management (NOMS), 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", 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>.

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

   [NGMN]     NGMN, "NGMN 5g Initiative White Paper", 2015,
              <https://www.ngmn.org/uploads/media/
              NGMN_5G_White_Paper_V1_0.pdf>.

   [Nguyen-1]
              Nguyen, T., Marchal, X., Doyen, G., Cholez, T., and R.
              Cogranne, "Content Poisoning in Named Data Networking:
              Comprehensive Characterization of real Deployment",
              Proceedings of the 15th IEEE/IFIP International Symposium
              on Integrated Network Management, 2017.



Rahman, et al.            Expires March 9, 2019                [Page 27]


Internet-Draft      Deployment Considerations for ICN     September 2018


   [Nguyen-2]
              Nguyen, T., Cogranne, R., and G. Doyen, "An Optimal
              Statistical Test for Robust Detection against Interest
              Flooding Attacks in CCN", Proceedings of the 14th IEEE/
              IFIP International Symposium on Integrated Network
              Management, 2015.

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

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

   [Overlay_ICN]
              Shailendra, S. and et al., "A Novel Overlay Architecture
              for Information Centric Networking", 2016,
              <https://www.researchgate.net/publication/282779666_A_nove
              l_overlay_architecture_for_Information_Centric_Networking>
              .

   [POINT]    Trossen, D. and et al., "POINT: IP Over ICN - The Better
              IP?", European Conference on Networks and Communications
              (EuCNC), , 2015.

   [Ravindran]
              Ravindran, R., Chakraborti, A., Amin, S., Azgin, A., and
              G. Wang, "5G-ICN : Delivering ICN Services over 5G using
              Network Slicing", IEEE Communication Magazine, May, 2016,
              <https://arxiv.org/abs/1610.01182>.

   [Reed]     Reed, M. and et al., "Stateless Multicast Switching in
              Software Defined Networks", ICC 2016, Kuala Lumpur,
              Malaysia, 2016.

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








Rahman, et al.            Expires March 9, 2019                [Page 28]


Internet-Draft      Deployment Considerations for ICN     September 2018


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

   [SAIL_NetInf]
              FP7, "SAIL Prototyping and Evaluation", 2013,
              <http://www.sail-project.eu/wp-content/uploads/2013/05/
              SAIL_DB4_v1.1_Final_Public.pdf>.

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

   [Techno_Economic]
              Trossen, D. and A. Kostopolous, "Techno-Economics Aspects
              of Information-Centric Networking", Journal for
              Information Policy, Volume 2, 2012.








Rahman, et al.            Expires March 9, 2019                [Page 29]


Internet-Draft      Deployment Considerations for ICN     September 2018


   [UMOBILE-2]
              Sarros, C., Diamantopoulos, S., Rene, S., Psaras, I.,
              Lertsinsrubtavee, A., Molina-Jimenez, C., Mendes, P.,
              Sofia, R., Sathiaseelan, A., Pavlou, G., Crowcroft, J.,
              and V. Tsaoussidis, "Connecting the Edges: A Universal,
              Mobile-Centric, and Opportunistic Communications
              Architecture", IEEE Communications Magazine, vol. 56,
              February 2018.

   [UMOBILE-3]
              Tavares, M., Aponte, O., and P. Mendes, "Named-data
              Emergency Network Services", Proc. of ACM MOBISYS, Munich,
              Germany, June 2018.

   [UMOBILE-4]
              Lopes, L., Sofia, R., Mendes, P., and W. Moreira, "Oi! -
              Opportunistic Data Transmission Based on Wi-Fi Direct",
              Proc. of IEEE INFOCOM, San Francisco, USA, April 2016.

   [UMOBILE-5]
              Dynerowicz, S. and P. Mendes, "Named-Data Networking in
              Opportunistic Networks", Proc. of ACM ICN, Berlin,
              Germany, September 2017.

   [UMOBILE-6]
              Mendes, P., Sofia, R., Tsaoussidis, V., Diamantopoulos,
              S., and C. Sarros, "Information-centric Routing for
              Opportunistic Wireless Networks", Proc. of ACM ICN,
              Boston, USA, September 2018.

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

   [UMOBILE-8]
              Sarros, C., Lertsinsrubtavee, A., Molina-Jimenez, C.,
              Prasopoulos, K., Diamantopoulos, S., Vardalis, D., and A.
              Sathiaseelan, "ICN-based edge service deployment in
              challenged networks", Proceedings of the 4th ACM
              Conference on Information-Centric Networking (ICN '17).
              ACM, New York, NY, USA, 2017 .








Rahman, et al.            Expires March 9, 2019                [Page 30]


Internet-Draft      Deployment Considerations for ICN     September 2018


   [UMOBILE-9]
              Lertsinsrubtavee, A., Selimi, M., Sathiaseelan, A., Cerda-
              Alabern, L., Navarro, L., and J. Crowcroft, "Information-
              Centric Multi-Access Edge Computing Platform for Community
              Mesh Networks", Proceedings of the 1st ACM SIGCAS
              Conference on Computing and Sustainable Societies (COMPASS
              '18). ACM, New York, NY, USA, 2018 .

   [VSER]     Ravindran, R., Liu, X., Chakraborti, A., Zhang, X., and G.
              Wang, "Towards software defined ICN based edge-cloud
              services", CloudNetworking(CloudNet), IEEE Internation
              Conference on, IEEE Internation Conference on
              CloudNetworking(CloudNet), 2013.

   [VSER-Mob]
              Azgin, A., Ravindran, R., Chakraborti, A., and G. Wang,
              "Seamless Mobility as a Service in Information-centric
              Networks", ACM ICN Sigcomm, IC5G Workshop, 2016.

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

Appendix A.  Change Log

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

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

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

   o  Incorporated off-line editorial comments from Hitoshi Asaeda and
      Anil Jangam.

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

   o  Editorial update of description and references of Doctor testbed
      as per comments from Guillaume Doyen.

   o  Ran IETF spell checker tool and corrected various spelling errors.

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






Rahman, et al.            Expires March 9, 2019                [Page 31]


Internet-Draft      Deployment Considerations for ICN     September 2018


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

   o  Added "Composite-ICN" configuration to cover the Hybrid ICN and
      similar configurations which do not clearly fit in one of the
      other basic configurations.

   o  Updated description of the ICN-as-a-Slice configuration to clarify
      that it may also apply to non-5G systems.

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

   o  Added text from Michael Kowal describing NREN ICN Testbed.

   o  Added text from Guillaume Doyen describing Doctor Project.

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

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

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

   Changes from rev-04 to rev-05:

   o  Added this Change Log in Appendix A.

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

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

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

   o  Added several new references in various sections.

   o  Various minor editorial updates.






Rahman, et al.            Expires March 9, 2019                [Page 32]


Internet-Draft      Deployment Considerations for ICN     September 2018


Authors' Addresses

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

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


   Dirk Trossen
   InterDigital Inc.
   64 Great Eastern Street, 1st Floor
   London  EC2A 3QR
   United Kingdom

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


   Dirk Kutscher
   Huawei German Research Center
   Riesstrasse 25
   Munich  80992
   Germany

   Email: ietf@dkutscher.net
   URI:   http://www.Huawei.com/


   Ravi Ravindran
   Huawei Research Center
   2330 Central Expressway
   Santa Clara  95050
   USA

   Email: ravi.ravindran@huawei.com
   URI:   http://www.Huawei.com/











Rahman, et al.            Expires March 9, 2019                [Page 33]