ICNRG                                                          A. Rahman
Internet-Draft                                                D. Trossen
Intended status: Informational                              InterDigital
Expires: September 12, 2017                                  D. Kutscher
                                                          March 11, 2017

    Deployment Configurations for Information-Centric Networks (ICN)


   This document provides technical deployment guidelines for the ICN
   community.  First, the possible deployment configurations for ICN are
   described including overlay and underlay approaches.  Then proposed
   deployment migration paths for these configurations are outlined to
   address the major issues facing ICN such as application migration,
   and core and edge network migration.  Next, selected ICN trial
   experiences are summarized.  Finally, recommendations are given for
   protocol areas that require further standardization to facilitate
   future ICN interoperable 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 http://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 September 12, 2017.

Copyright Notice

   Copyright (c) 2017 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
   (http://trustee.ietf.org/license-info) in effect on the date of

Rahman, et al.         Expires September 12, 2017               [Page 1]

Internet-Draft      Deployment Configurations for ICN         March 2017

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Deployment Configurations . . . . . . . . . . . . . . . . . .   4
     3.1.  Wholesale Replacement . . . . . . . . . . . . . . . . . .   4
     3.2.  ICN-as-an-Overlay . . . . . . . . . . . . . . . . . . . .   4
     3.3.  ICN-as-an-Underlay  . . . . . . . . . . . . . . . . . . .   5
       3.3.1.  HTTP/IP-over-ICN  . . . . . . . . . . . . . . . . . .   5
       3.3.2.  Native ICN with Application Gateways  . . . . . . . .   5
     3.4.  ICN-as-a-Slice  . . . . . . . . . . . . . . . . . . . . .   6
   4.  Deployment Migration Paths  . . . . . . . . . . . . . . . . .   6
     4.1.  Application and Service Migration . . . . . . . . . . . .   6
     4.2.  Content Delivery Network Migration  . . . . . . . . . . .   7
     4.3.  Edge Network Migration  . . . . . . . . . . . . . . . . .   7
     4.4.  Core Network Migration  . . . . . . . . . . . . . . . . .   8
   5.  Deployment Trial Experiences  . . . . . . . . . . . . . . . .   8
     5.1.  FP7 Pursuit Efforts . . . . . . . . . . . . . . . . . . .   8
     5.2.  H2020 POINT and RIFE Efforts  . . . . . . . . . . . . . .   8
     5.3.  H2020 FLAME Efforts . . . . . . . . . . . . . . . . . . .   9
     5.4.  FP7 SAIL Trial  . . . . . . . . . . . . . . . . . . . . .  10
     5.5.  NDN Testbed . . . . . . . . . . . . . . . . . . . . . . .  10
     5.6.  CableLabs Content Delivery System . . . . . . . . . . . .  10
   6.  Deployment Issues Requiring Further Standardization . . . . .  11
     6.1.  Protocols for Application and Service Migration . . . . .  11
     6.2.  Protocols for Content Delivery Network Migration  . . . .  11
     6.3.  Protocols for Edge and Core Network Migration . . . . . .  12
     6.4.  Summary of ICN Protocol Gaps and Potential IETF Efforts .  12
   7.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  13
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  14
   11. Informative References  . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

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

Rahman, et al.         Expires September 12, 2017               [Page 2]

Internet-Draft      Deployment Configurations for ICN         March 2017

   configurations with the existing Internet paradigm, are key topic
   areas that require further investigation.  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 draft 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 future IETF
   standardization of key protocol functionality that will facilitate
   interoperable ICN deployments going forward.

2.  Terminology

   The following key terms and concepts are defined:

      Information-Centric Networking (ICN) - ICN is an approach to
      evolve the Internet infrastructure (e.g. routers, caches, servers)
      towards accessing named data as a first-order network layer
      service.  In this approach, Named Data Objects (NDOs) are named
      and secured individually.  Hashing and/or Public-Key Cryptography
      are used to provide NDO authentication and integrity validation
      (amongst other services).  ICN's data-oriented security (instead
      of connection-based security) can enable several benefits: message
      authentication and optionally encryption are fundamental elements
      of the system, and the forwarding layer can be empowered to
      implement suitable forwarding strategies and additional
      functionality such as caching, local retransmissions, etc.

      Software-Defined Networking (SDN) - SDN is a network control and
      implementation architecture that disaggregates the network control
      and forwarding functions.  This enables programming network
      elements (e.g. routers, switches) that implement packet forwarding
      functions using a control abstraction, e.g., OpenFlow's Match-
      Action-based abstraction.  Corresponding controllers can have
      visibility and control of a larger set of SDN elements in a
      network deployment, which enables network programmability.  This
      can be used to achieve several objectives such as network
      virtualization, optimized forwarded, failure resilience, etc.

      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) integrated and interoperable with the rest of the Internet,

Rahman, et al.         Expires September 12, 2017               [Page 3]

Internet-Draft      Deployment Configurations for ICN         March 2017

      and (2) ready for useful work (e.g. transmission of end user video
      and text) in a live environment.

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 (in Section 5)
   experiences with various of these configurations, 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.  Wholesale Replacement

   ICN has often been described as a "clean-slate" approach with the
   goal to renew or replace the current IP routing fabric of the
   Internet.  As such, existing routing hardware as well as ancillary
   services have not been taken for granted.  This clean-slate view is
   reflected as deployment configurations we label as "wholesale
   replacement" of large part of the existing Internet infrastructure.
   For instance, such configuration would see existing IP routers being
   replaced by CCN routers [Jacobson] or Bloom-filter based forwarding
   elements [IEEE_Communications].  All major ICN flavors have explored
   this option as their path to deployment.

   While such replacement could be seen as exclusive for ICN
   deployments, some ICN propositions [POINT] rely on the deployment of
   infrastructure upgrades, here SDN switches.  Such upgrades, while
   being possibly utilized for a "clean slate" ICN deployment would not
   necessary be used exclusively for an ICN deployment.  Different
   proposals have been made for various ICN flavors 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 also
   referred to as a tunneling approach.  The overlay approach could be
   done directly such as ICN-over-UDP as described in [CCNx_UDP].
   Alternatively, the overlay could be done via ICN-in-L2-in-IP as
   described in [IEEE_Communications].

   Another flavor of overlay would be embedding ICN semantics into
   existing proposals.  A recently announced approach is [Hybrid_ICN]
   where the ICN names are mapped to IPv6 addresses.  Another approach
   used in the Network of Information (NetInf) is to define a

Rahman, et al.         Expires September 12, 2017               [Page 4]

Internet-Draft      Deployment Configurations for ICN         March 2017

   convergence layer to map NetInf semantics to HTTP
   [I-D.kutscher-icnrg-netinf-proto].  Regardless of the flavor,
   however, the overlay approach results in islands of ICN deployments
   over existing IP-based infrastructure.

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 IP-based
   services, while possibly still allowing for native ICN applications
   to emerge.  The main reasons for such configuration option is the
   backward-compatible introduction of ICN technology, while possibly
   reaping the benefits of ICN in terms of multicast delivery, mobility
   support, fast indirection due to location independence, and possibly

3.3.1.  HTTP/IP-over-ICN

   In this sub-option, a deployment configuration would utilize edge-
   based protocol mapping onto the native ICN underlay.  For instance,
   [POINT] proposes to map either raw IP packets or HTTP transactions
   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
   gateway, preserving the perception of an IP-based 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.3.2.  Native ICN with Application Gateways

   Native ICN networks may be found at the edge of the network, mostly
   proposed for Internet-of-Things deployments.  The integration with
   the current IP protocol suite takes place at an application gateway
   at the edge network boundary, e.g., translating incoming CoAP
   request/response transactions [RFC7252] into ICN message exchanges.
   However, ICN will allow us to evolve the role of gateways as ICN
   message security should be preserved through the protocol translation
   function of a gateway and thus offer a substantial gain.

Rahman, et al.         Expires September 12, 2017               [Page 5]

Internet-Draft      Deployment Configurations for ICN         March 2017

3.4.  ICN-as-a-Slice

   With the advent of network slicing, i.e., the ability to isolate
   network resources exclusively towards a specific set of network
   functions, the deployment of ICN within such isolated slice is
   emerging as another deployment configuration.  Coupled with the view
   of ICN functions as being "chained service functions" [RFC7665], an
   ICN deployment within such a slice could be realized within the
   emerging control plane that is targeted for adoption in future (e.g.,
   5th generation mobile) network deployments.  Nonetheless, at the
   level of the specific technologies involved, this requires
   compatibility for instance at the level of the forwarding/data plane.
   With SDN emerging as a novel data plane for new network deployments,
   ICN flavors will need to integrate with SDN as a data plane
   forwarding function, as briefly discussed in Section 3.1.

4.  Deployment Migration Paths

   After outlining the various ICN deployment configurations in
   Section 3, we now focus on the various migration paths that might
   have an 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 developers and service providers

   o  ISPs, both as core as well as access network providers

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

   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.

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.

Rahman, et al.         Expires September 12, 2017               [Page 6]

Internet-Draft      Deployment Configurations for ICN         March 2017

   The configuration options presented in Section 3.3.1 and
   Section 3.3.2 aim at providing some level of backward compatibility
   to this existing ecosystem.  Alternatively, introducing ICN as an
   overlay (Section 3.2) as well as within-a-slice (Section 3.4) aims at
   introducing the full capabilities of ICN through new service
   interfaces as well as operations in the network.  The overlay and
   within-a-slice approaches of deployment are likely to be more
   disruptive at the application and service level, however more new
   services are expected to be introduced based on such an approach.

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
   content requests and therefore reducing latency and possibly increase
   utilization of available bandwidth.  Similar to the previous sub-
   section, the deployment configurations presented in Section 3.3.1 and
   Section 3.3.2 aim at providing a migration path for existing CDNs.
   This is also highlighted in the BIER WG use case draft
   [I-D.ietf-bier-use-cases], specifically with potential benefits in
   terms of utilizing multicast in the delivery of content.  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 the Internet of Things (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 deployment
   configuration in Section 3.3.2, application gateways 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 mobile
   (access) networks, particularly in the context of the 5th generation
   of mobile networks (often called "5G").  With the proliferation of
   SDN-based transport for access networks, the 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.

Rahman, et al.         Expires September 12, 2017               [Page 7]

Internet-Draft      Deployment Configurations for ICN         March 2017

4.4.  Core Network Migration

   Migrating the core network of the Internet 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 transport, such as proposed by major
   operators such as AT&T, the deployment configuration in Section 3.4
   could see the introduction of native ICN solutions within slices
   provided by the SDN-enabled transport network.  For ICN solutions
   that natively work on top of SDN, Section 3.3.1 provides an
   additional migration, 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).

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.  While a body of work exists at the simulation or
   emulation level, we specifically exclude these studies from our
   presentation to retain the focus on real experiences.  We recognize
   that this section is unlikely to be comprehensive.  We will therefore
   continue to solicit input from ICNRG members for other deployment
   experiences to complete this section.

5.1.  FP7 Pursuit Efforts

   Although the FP7 PURSUIT [IEEE_Communications] efforts were generally
   positioned as a wholesale 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 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.2.  H2020 POINT and RIFE Efforts

   The efforts in the H2020 POINT+RIFE projects follow the deployment
   configuration in Section 3.3.1, although utilizing an overlay
   deployment to provide multi-national connectivity.  However, pure
   SDN-based deployments do exist at various project partner sites,
   e.g., at Essex University, without any overlaying being realized.

Rahman, et al.         Expires September 12, 2017               [Page 8]

Internet-Draft      Deployment Configurations for ICN         March 2017

   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 2015 and 2016, respectively, while public demonstrations
   were 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 Munich in September 2016."

   While the mentioned demonstrations all use the overlay international
   deployment, both H2020 efforts plan pure ICN underlay trials in the
   summer and fall of 2017.  One such trial will involve real end users
   located in the Primetel network in Cyprus with the use case centered
   on IPTV and HLS video dissemination.  Another trial is planned for
   fall 2017 in the community network of "guifi.net" in the Barcelona
   region, where the solution will be deployed in 40 households,
   providing general Internet connectivity to the residents.  Standard
   IPTV STBs as well as HLS video players will be utilized in accordance
   with the aim of this deployment configuration, namely to provide
   application and service migration.

5.3.  H2020 FLAME Efforts

   Starting in January 2017, the H2020 FLAME efforts aims at providing
   an experimental ground for the aforementioned POINT/RIFE solution in
   initially two city-scale locations, namely in Bristol and Barcelona.
   This trial will again follow the deployment configuration in
   Section 3.3.1 as per POINT/RIFE approach.  Currently, experiments are
   ongoing,conducted by the city/university joint venture Bristol-is-
   Open (BIO), to ensure the readiness of the city-scale SDN transport
   network for such experiments.  At the time of initial publication of
   this draft in March 2017, the deployment of the ICN underlay onto the
   SDN transport network will be finalized with the aim of running the
   third trial of the aforementioned ETSI MEC PoC in the network during
   April/May of 2017.  This third trial will showcase 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.

Rahman, et al.         Expires September 12, 2017               [Page 9]

Internet-Draft      Deployment Configurations for ICN         March 2017

   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.4.  FP7 SAIL Trial

   The Network of Information (NetInf) is the approach to Information-
   Centric Networking developed by the 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
   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.

5.5.  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 wholesale 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 several
   hundred NDN enabled nodes (https://named-data.net/ndn-testbed/).

5.6.  CableLabs Content Delivery System

   The work in [White] proposes a deployment configuration based on
   Section 3.3.1.  The use case is ICN for content distribution within
   CDN server farms (which can be quite large and complex) to leverage
   ICNs 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

Rahman, et al.         Expires September 12, 2017              [Page 10]

Internet-Draft      Deployment Configurations for ICN         March 2017

   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.

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 will address this open area by
   identifying key protocol functionality that that we deem 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 required
   protocol functionality is not exhaustive.

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, certain ICN approaches provide substantial
   improvements over IP multicast, such as the implicit support for
   multicast retrieval of content in all ICN flavours.

Rahman, et al.         Expires September 12, 2017              [Page 11]

Internet-Draft      Deployment Configurations for ICN         March 2017

   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, gateways 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 gateway translates CoAP request/responses to other message
   formats.  For example, [RFC8075] specifies gateway mapping between
   CoAP and HTTP protocols.  However, as mentioned previously, ICN will
   allow us to evolve the role of gateways as ICN message security
   should be preserved through the protocol translation function of a
   gateway and thus offer a substantial gain.  Another area is
   integration of ICN into networks that support virtualized
   infrastructure in the form of NFV/SDN.  Further work is required to
   validate this idea and document best practices.

6.4.  Summary of ICN Protocol Gaps and Potential IETF Efforts

   Without claiming completeness, Table 1 maps the open the open ICN
   deployment protocol issues identified in this document to potential
   IETF groups that could address some aspects of them.  An example of a
   specific gap that the group could potentially address is identified
   in parenthesis beside the group name.

Rahman, et al.         Expires September 12, 2017              [Page 12]

Internet-Draft      Deployment Configurations for ICN         March 2017

   | ICN Protocol | Potential IETF Group                               |
   | Gaps         |                                                    |
   | 1-Support of | HTTPBIS and CORE WG                                |
   | REST APIs    | (HTTP/CoAP support of ICN semantics)               |
   |              |                                                    |
   | 2-Naming     | New BoF/WG                                         |
   |              | (Dynamic naming of ICN data objects)               |
   |              |                                                    |
   | 3-Multicast  | BIER or new BoF/WG                                 |
   | distribution | (Multicast enhancements for ICN)                   |
   |              |                                                    |
   | 4-In-network | New BoF/WG                                         |
   | caching      | (Cache placement and sharing)                      |
   |              |                                                    |
   | 5-NFV/SDN    | SFC or New BoF/WG                                  |
   | Support      | (Integration of ICN with NFV/SDN)                  |
   |              |                                                    |
   | 6-ICN        | New BoF/WG                                         |
   | mapping      | (Mapping of HTTP and other protocols onto ICN      |
   |              | message exchanges while preserving ICN message     |
   |              | security)                                          |
   |              |                                                    |

      Table 1: Mapping of ICN Protocol Gaps to Potential IETF Groups

7.  Conclusion

   This documents describes a set of technical features in ICN that
   warrant future specification work.  For initial and incremental
   deployment it can be useful to address some of these features and
   corresponding specification work items in existing IETF working
   groups.  In this document, we have proposed a corresponding mapping
   of topics to WGs.  The fundamental protocols specifications may still
   be best addressed by a specific WG.

8.  IANA Considerations

   This document requests no IANA actions.

9.  Security Considerations


Rahman, et al.         Expires September 12, 2017              [Page 13]

Internet-Draft      Deployment Configurations for ICN         March 2017

10.  Acknowledgments

   The authors want to thank Xavier de Foy for his very useful reviews
   and comments to the document.

11.  Informative References

   [C_FLOW]   Suh, J. and et al., "C_FLOW: Content-Oriented Networking
              over OpenFlow", Open Networking Summit, April, 2012,

              PARC, , "CCNx Over UDP", 2015,

   [CONET]    Veltri, L. and et al., "CONET Project: Supporting
              Information-Centric Functionality in Software Defined
              Networks", Workshop on Software Defined Networks, , 2012,

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

              Cisco, , "Hybrid ICN: Cisco Announces Important Steps
              toward Adoption of Information-Centric Networking", 2017,

              Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A.,
              Przygienda, T., arkadiy.gulko@thomsonreuters.com, a.,
              Robinson, D., Arya, V., and C. Bestler, "BIER Use Cases",
              draft-ietf-bier-use-cases-04 (work in progress), January

              marc.mosko@parc.com, m., Solis, I., and c. cwood@parc.com,
              "CCNx Messages in TLV Format", draft-irtf-icnrg-
              ccnxmessages-03 (work in progress), June 2016.

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

Rahman, et al.         Expires September 12, 2017              [Page 14]

Internet-Draft      Deployment Configurations for ICN         March 2017

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

              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

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

              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, V. and et al., "Networking Named Content",
              Proceedings of ACM Context, , 2009.

              InterDigital, , "InterDigital Demo at Mobile World
              Congress (MWC)", 2016, <http://www.interdigital.com/

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

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

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

Rahman, et al.         Expires September 12, 2017              [Page 15]

Internet-Draft      Deployment Configurations for ICN         March 2017

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,

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

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

              FP7, , "SAIL Prototyping and Evaluation", 2013,

   [Tateson]  Tateson, J. and et al., "Final Evaluation Report on
              Deployment Incentives and Business Models", 2010,

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

   [White]    White, G. and G. Rutz, "Content Delivery with Content
              Centric Networking, CableLabs White Paper", 2010,

Authors' Addresses

Rahman, et al.         Expires September 12, 2017              [Page 16]

Internet-Draft      Deployment Configurations for ICN         March 2017

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

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

   Dirk Trossen
   InterDigital Communications, LLC
   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

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

Rahman, et al.         Expires September 12, 2017              [Page 17]