Deployment Considerations for Information-Centric Networking (ICN)
draft-rahman-icnrg-deployment-guidelines-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Akbar Rahman , Dirk Trossen , Dirk Kutscher , Ravi Ravindran | ||
| Last updated | 2017-06-29 | ||
| Replaced by | draft-irtf-icnrg-deployment-guidelines, RFC 8763 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rahman-icnrg-deployment-guidelines-02
ICNRG A. Rahman
Internet-Draft D. Trossen
Intended status: Informational InterDigital Inc.
Expires: December 31, 2017 D. Kutscher
R. Ravindran
Huawei
June 29, 2017
Deployment Considerations for Information-Centric Networking (ICN)
draft-rahman-icnrg-deployment-guidelines-02
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. The major deployment
configurations for ICN are first described including the main 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 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 December 31, 2017.
Rahman, et al. Expires December 31, 2017 [Page 1]
Internet-Draft Deployment Considerations for ICN June 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
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. Wholesale Replacement . . . . . . . . . . . . . . . . . . 4
3.2. ICN-as-an-Overlay . . . . . . . . . . . . . . . . . . . . 4
3.3. ICN-as-an-Underlay . . . . . . . . . . . . . . . . . . . 5
3.3.1. Core Network . . . . . . . . . . . . . . . . . . . . 5
3.3.2. Edge Network . . . . . . . . . . . . . . . . . . . . 6
3.4. ICN-as-a-Slice . . . . . . . . . . . . . . . . . . . . . 6
4. Deployment Migration Paths . . . . . . . . . . . . . . . . . 7
4.1. Application and Service Migration . . . . . . . . . . . . 7
4.2. Content Delivery Network Migration . . . . . . . . . . . 8
4.3. Edge Network Migration . . . . . . . . . . . . . . . . . 8
4.4. Core Network Migration . . . . . . . . . . . . . . . . . 9
5. Deployment Trial Experiences . . . . . . . . . . . . . . . . 9
5.1. ICN-as-an-Overlay . . . . . . . . . . . . . . . . . . . . 9
5.1.1. FP7 PURSUIT Efforts . . . . . . . . . . . . . . . . . 9
5.1.2. FP7 SAIL Trial . . . . . . . . . . . . . . . . . . . 10
5.1.3. NDN Testbed . . . . . . . . . . . . . . . . . . . . . 10
5.1.4. ICN2020 Efforts . . . . . . . . . . . . . . . . . . . 10
5.2. ICN-as-an-Underlay . . . . . . . . . . . . . . . . . . . 11
5.2.1. H2020 POINT and RIFE Efforts . . . . . . . . . . . . 11
5.2.2. H2020 FLAME Efforts . . . . . . . . . . . . . . . . . 11
5.2.3. CableLabs Content Delivery System . . . . . . . . . . 12
6. Deployment Issues Requiring Further Standardization . . . . . 12
6.1. Protocols for Application and Service Migration . . . . . 13
6.2. Protocols for Content Delivery Network Migration . . . . 13
6.3. Protocols for Edge and Core Network Migration . . . . . . 13
6.4. Summary of ICN Protocol Gaps and Potential IETF Efforts . 14
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
Rahman, et al. Expires December 31, 2017 [Page 2]
Internet-Draft Deployment Considerations for ICN June 2017
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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. 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 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]. 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) integrated and interoperable with the rest of the Internet,
and (2) ready for useful work (e.g. transmission of end user video
and text) in a live environment.
Information-Centric Networking (ICN) - A data-centric network
architecture where accessing data by name is the essential network
primitive. See [ICNterm] 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
Rahman, et al. Expires December 31, 2017 [Page 3]
Internet-Draft Deployment Considerations for ICN June 2017
[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. 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 are not 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 ICN-specific forwarding and routing elements, such as NFD
(Named Data Networking Forwarding Daemon) [NFD], CCN routers
[Jacobson] or PURSUIT forwarding nodes [IEEE_Communications]. All
major ICN approaches have explored this option as one of their paths
to deployment.
While such replacement could be seen as exclusive for ICN
deployments, some ICN approaches [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 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
Rahman, et al. Expires December 31, 2017 [Page 4]
Internet-Draft Deployment Considerations for ICN June 2017
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 in [IEEE_Communications] which describes a recursive
layering process.
Another flavor of overlay would be embedding ICN semantics into
existing protocols. 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
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 by deploying application layer gateways at appropriate
locations, 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 reaping the
benefits of ICN in terms of multicast delivery, mobility support,
fast indirection due to location independence, in-network computing
and possibly more.
3.3.1. 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
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.
Rahman, et al. Expires December 31, 2017 [Page 5]
Internet-Draft Deployment Considerations for ICN June 2017
3.3.2. Edge Network
Native ICN networks may be found at the edge of the network, mostly
proposed for Internet of Things (IoT) deployments, which allows the
possibility of introducing new network architectures and protocols,
and in this context ICN can be a possible candidate considering its
suitability for IoT and fixed network scenarios
[I-D.zhang-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 us to evolve 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
an 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 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.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 services
with exclusive SLA requirements on transport level QoS and security.
These services could include both connectivity services like LTE-as-
a-service or OTT services like VoD or other IoT services. Such a
framework can also be used to realize ICN slices with its own control
and forwarding plane over which one or more end-user services can be
delivered.
An ICN slice can itself be overlaid over IP or can be underlaid using
generalized programmable data planes like P4/POF. Such a generalized
network slicing framework should be able to offer service slices to
be realized over both IP and ICN. Network slicing will rely heavily
on network softwarization and programmability using SDN/NFV
technologies for efficient utilization of available resources without
compromising on the slice requirements. 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
Rahman, et al. Expires December 31, 2017 [Page 6]
Internet-Draft Deployment Considerations for ICN June 2017
control plane that is targeted for adoption in future (e.g., 5th
generation mobile) network deployments. Finally, it should be noted
that ICN is not creating the network slice, but instead that the
slice is created to run a 5G-ICN instance [Ravindran].
At the level of the specific technologies involved, 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.
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 developers and service providers
o ISPs, 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)
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.
The underlay deployment configuration options presented in
Section 3.3.1 and Section 3.3.2 aim at providing some level of
Rahman, et al. Expires December 31, 2017 [Page 7]
Internet-Draft Deployment Considerations for ICN June 2017
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]
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 service interfaces as well as
operations in the network. With that, these approaches of deployment
are likely to aim at introducing new services capitalizing on those
ICN capabilities.
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 as well as reducing the load on
origin servers. Similar to the previous sub-section, the underlay
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 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.2, 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 5th generation
of mobile networks (often called "5G"). 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
Rahman, et al. Expires December 31, 2017 [Page 8]
Internet-Draft Deployment Considerations for ICN June 2017
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 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 optical transport, such as proposed by
major operators such as AT&T, 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.1 provides an additional migration path, preserving the
IP-based services and applications at the edge of the network, while
realizing the core network routing through an ICN solution (possibly
itself realized in a slice of the SDN transport network).
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 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 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.
Rahman, et al. Expires December 31, 2017 [Page 9]
Internet-Draft Deployment Considerations for ICN June 2017
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.
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 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.1.4. ICN2020 Efforts
ICN2020 is an ICN related research project funded by the EU as part
of the H2020 research and innovation program
(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 late 2016 and so has not yet published
results relating to deployment trials. The plan, however, is to
involve ICN testbeds in EU, Japan and the USA and federate them. The
GEANT testbed (https://www.geant.org/) is being considered as one
means to federate the different ICN testbeds in the overlay
deployment configuration of Section 3.2 over the public Internet.
Rahman, et al. Expires December 31, 2017 [Page 10]
Internet-Draft Deployment Considerations for ICN June 2017
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.1, 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, while 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
international deployment, both H2020 efforts plan ICN underlay trials
in the summer and fall of 2017. One such trial will involve
commercial 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.2.2. 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 underlay 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. A third trial of the aforementioned
ETSI MEC PoC is planned for mid 2017. This trial will showcase
operational benefits provided by the ICN underlay for the scenario of
Rahman, et al. Expires December 31, 2017 [Page 11]
Internet-Draft Deployment Considerations for ICN June 2017
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.1. 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.
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 December 31, 2017 [Page 12]
Internet-Draft Deployment Considerations for ICN June 2017
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 December 31, 2017 [Page 13]
Internet-Draft Deployment Considerations for ICN June 2017
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. 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
issues identified in this document to potential protocol efforts that
could address some aspects of the gap.
+--------------+----------------------------------------------------+
| ICN Gap | Potential Protocol Effort |
+--------------+----------------------------------------------------+
| 1-Support of | HTTP/CoAP support of ICN semantics |
| REST APIs | |
| | |
| 2-Naming | Dynamic naming of ICN data objects |
| | |
| 3-Multicast | Multicast enhancements for ICN |
| distribution | |
| | |
| 4-In-network | ICN Cache placement and sharing |
| caching | |
| | |
| 5-NFV/SDN | Integration of ICN with NFV/SDN |
| Support | |
| | |
| 6-ICN | Mapping of HTTP and other protocols onto ICN |
| mapping | message exchanges (and vice-versa) while |
| | preserving ICN message security |
| | |
+--------------+----------------------------------------------------+
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) wholesale replacement of
existing Internet infrastructure; (2) ICN-as-an-Overlay; (3) ICN-as-
an-Underlay; and (4) ICN-as-a-Slice. Existing ICN trial systems
Rahman, et al. Expires December 31, 2017 [Page 14]
Internet-Draft Deployment Considerations for ICN June 2017
mainly fall either under the ICN-as-an-Overlay or ICN-as-an-Underlay
configuration.
In terms of deployment migration paths, ICN-as-an-Underlay offers a
clear migration path for existing CDN, edge and core networks to go
to an ICN paradigm. 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. Finally, 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 ICN message flows at a
proxy in the ICN-as-an-Underlay configurations leaving the massive
number of existing end point applications/services untouched or
minimally impacted.
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 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,
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 real 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
Rahman, et al. Expires December 31, 2017 [Page 15]
Internet-Draft Deployment Considerations for ICN June 2017
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.2, the gateway/proxy that translates HTTP or CoAP
request/responses into ICN message exchanges will need to support a
model to preserve end-to-end security.
10. Acknowledgments
The authors want to thank Alex Afanasyev, Xavier de Foy, Hannu
Flinck, Dave Oran, and Prakash Suthar for their 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,
<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>.
[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>.
[DASH] DASH, "DASH Industry Forum", 2017, <http://dashif.org/>.
[Hybrid_ICN]
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>.
[I-D.ietf-bier-use-cases]
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
2017.
Rahman, et al. Expires December 31, 2017 [Page 16]
Internet-Draft Deployment Considerations for ICN June 2017
[I-D.irtf-icnrg-ccnxmessages]
marc.mosko@parc.com, m., Solis, I., and C. Wood, "CCNx
Messages in TLV Format", draft-irtf-icnrg-ccnxmessages-04
(work in progress), March 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-05 (work in progress), March 2017.
[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.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.zhang-icnrg-icniot]
Zhang, Y., Raychadhuri, D., Grieco, L., Baccelli, E.,
Burke, J., Ravindran, R., Wang, G., Lindgren, A., Ahlgren,
B., and O. Schelen, "Design Considerations for Applying
ICN to IoT", draft-zhang-icnrg-icniot-01 (work in
progress), June 2017.
[ICNterm] Wissingh, B., "Information-Centric Networking (ICN):
Terminology", 2017, <https://datatracker.ietf.org/doc/
draft-wissingh-icnrg-terminology/>.
[IEEE_Communications]
Trossen, D. and G. Parisis, "Designing and Realizing an
Information-Centric Internet", Information-Centric
Networking, IEEE Communications Magazine Special Issue,
2012.
Rahman, et al. Expires December 31, 2017 [Page 17]
Internet-Draft Deployment Considerations for ICN June 2017
[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.
[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>.
[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.
[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,
<http://www.rfc-editor.org/info/rfc6920>.
Rahman, et al. Expires December 31, 2017 [Page 18]
Internet-Draft Deployment Considerations for ICN June 2017
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <http://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,
<http://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,
<http://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,
<http://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,
<http://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 December 31, 2017 [Page 19]
Internet-Draft Deployment Considerations for ICN June 2017
[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>.
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/
Rahman, et al. Expires December 31, 2017 [Page 20]
Internet-Draft Deployment Considerations for ICN June 2017
Ravi Ravindrna
Huawei Research Center
2330 Central Expressway
Santa Clara 95050
USA
Email: ravi.ravindran@huawei.com
URI: http://www.Huawei.com/
Rahman, et al. Expires December 31, 2017 [Page 21]