[icnrg] Review of draft-irtf-icnrg-deployment-guidelines

Marie-Jose Montpetit <marie@mjmontpetit.com> Thu, 14 February 2019 14:25 UTC

From: Marie-Jose Montpetit <marie@mjmontpetit.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9C604394-D25F-45B9-9F62-E493B3A8652B"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: <5192C6A0-E661-4AC8-831E-51FC4DB02E4C@mjmontpetit.com>
Date: Thu, 14 Feb 2019 09:25:04 -0500
Cc: David Oran <daveoran@orandom.net>
To: icnrg <icnrg@irtf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/W781F4cEPqrtx17sCJcqqq2-hKs>
Subject: [icnrg] Review of draft-irtf-icnrg-deployment-guidelines
Precedence: list

Hi everyone:

here is my review of the draft-irtf-icnrg-deployment-guidelines

https://datatracker.ietf.org/doc/draft-irtf-icnrg-deployment-guidelines/ <https://datatracker.ietf.org/doc/draft-irtf-icnrg-deployment-guidelines/>

General comments:
- The document is generally well written and informative; it does suffer from the problems of integrating work from different places and a quick review to even the voices would be good.
- The draft covers a lot of material but in sometimes different levels of details. Maybe it’s unavoidable.
- The tone is sometimes more advocacy than a description. I will point out specific examples.
- While it’s taken into account that the reader is “conversant in ICN” many times ICN capabilities are mentioned but not specified. Maybe a reference to specific material could help.
- Since this is about deployment, pointers to existing code bases would be good.
- While the large number of references is possibly necessary to cover all the material it would be interesting to have a number of those considered essential and then the others.

Detailed comments (with <mjm>)
Deployment Considerations for Information-Centric Networking (ICN)
draft-irtf-icnrg-deployment-guidelines-04

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
<mjm> 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
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
<mjm> throughout

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.
<mjm> I suggest that ahead of section 2 a summary of the recommendations/guidelines be presented so that the reader get a sense of what is coming.

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.).
<mjm> I know what you mean but the e.g. part is misleading. I would actually take the e.g. out as the next paragraph defines what it means.

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
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.
<mjm> in this case 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.
<mjm> this is restating the previous sentence and could be removed

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,
<mjm> Similarly

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.
<mjm> over the IP infrastructure

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.,
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.
<mjm> this is where the uneveness of the details is particularly evident; for the other deployment options it was a paragraph; here we get subsections. I agree that there was much more underlays than the others but it kills the document flow. Maybe extend the summary and push some of the details in an appendix?

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].
<mjm> needs rewriting; also new network architectures such as what?

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.
<mjm> define CoAP or provide an acronyms list

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.
<mjm> gain of what?

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
gateway/proxy, preserving the perception of an IP-based core network
towards any peering network.
<mjm> last sentence needs rewriting

The work in [White] proposes a similar deployment configuration.
Here, the target is the use of ICN for content distribution within
<mjm> There, the goal is to use ICN

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.
<mjm> can slicing be summarized with a reference?

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].
<mjm> there is a while draft on 5G ICN - I would summarize that section

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.
<mjm> needs rewriting

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
<mjm> is presentation the right word here?

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.
<mjm> The internet supports a multitude of applications and services using the many protocols defined over the packet level IP service.

HTTP provides one convergence point for these
services with many Web development frameworks based on the semantics
provided by 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.

<mjm> Is this necessary?

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
<mjm> compatibility to the`

existing ecosystem through a proxy
based message flow mapping mechanism (e.g., mapping of existing
HTTP/TCP/IP message flows to HTTP/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.
<mjm> would be great to have a comment on which option is more performing?

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.
<mjm> like what?

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
<mjm> specifically it introduces - note: the reference names are really long and really impact the reading flow

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,
<mjm> video delivery,

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.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.
<mjm> this would bebefit from re-writing for clarity.

4.3. Edge Network Migration

<mjm> this section is IoT and 5G not really Edge Network in general; there are many edge network applications such as gaming and AR/VR who are neither IOT not strictly 5G who can greatly benefit from ICN; this should be mentioned here

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
<mjm> Is there anything new here compared to what was presented in section 3?

Migrating core networks (e.g., of the Internet or Mobile core
network)
<mjm> the e.g. is not necessary

requires not only significant infrastructure renewal but
also the fulfillment of the significant performance requirements,
particularly in terms of throughput.
<mjm> repetition of “significant"

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
<mjm> the work see is repeated

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.
<mjm> what benefits and what constraints?

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
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.
<mjm> is the international nature of the projects important? Are there any other kind these days?

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.
<mjm> presentation?

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
<mjm> sites, 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.

<mjm> name at least one conference

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/).
<mjm> put the URL in the references? And is the use of the present tense correct? I had the impression NetInf was in the past now.

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
<mjm> options such as?

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,
<mjm> stadium environment and a multi-site testbed

leveraging
NetInf's Routing Hint approach for routing scalability.
<mjm> reference for Hint?

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.
<mjm> the Future Internet Architecture (FIA) 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].
<mjm> put the URL in the references

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/).
<mjm> put the URL in the references

ICN2020 has a specific focus to advance
ICN towards real-world deployments through innovative applications
and global scale experimentation.
<mjm> marketing talk… what applications and define global scale

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.
<mjm> and the advantages were? can some salient results presented? Anything since 2016?

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/).
<mjm> usual: put the URL in the references

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.
<mjm> again advocacy speech - what were/are the advantages of NDN here?

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
<mjm> push/pull is a big discussion in ICN so why encompassing push?

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

<mjm> refer to my general comment about un-eveness of details. This goes in details that is not common in the other sections. Some harmonizing is necessary

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
protection authority in March 2018, included also an UAV carrying a
UMOBILE raspberry Pi that served as relay and carrier of information.
<mjm> see above on advocacy and level of details

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.
<mjm> so what is really being done? Rewrite to avoid confusing the reader

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.
<mjm> can that be summarized? impressive maybe but out of scope for a document you mentioned was not going to have commercial implications

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
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.
<mjm> Please rewrite and provide numbers for the latency reduction or a least a reference to them

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.
<mjm> see comment above - this sadly seems to come from a EU description of the project

5.2.3. CableLabs Content Delivery System

The work in [White]
<mjm> The Cablelabs ICN work reported 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)
<mjm> the text in parentheses is kind of useless

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.
<mjm> can this be re-written to reflect 2019 and also survive the test of time? what are the plans for the next 2 or even 5 years?

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].
<mjm> numbers please?

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.
<mjm> status as of Feb 2019?

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
<mjm> NDN network focusing on important performance 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.
<mjm> what does optimize means here and what are 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.

<mjm> What is the timeframe for the project? What will it be in 2 years?

5.3. Composite-ICN Approach
<mjm> if hybrid ICN is the only composite why having a subsection?

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
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.
<mjm> less than 1000 users.

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.

<mjm> can plans be at least mentioned?

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.
<mjm> and 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.
<mjm> this is repetitive from the previous sections

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.
<mjm> this should be in the previous section

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.

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.
<mjm> ICN communication characteristics such as?

6.2. Protocols for Content Delivery Network Migration
<mjm> If you talk to CDN providers they claim that a lot of the ICN/NDN functionality is already embedded in their own protocols. A discussion on how can all be orchestrated would be interesting in this section.

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.
<mjm> Re-write

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
<mjm> this section is like a power point presentation… time for subsections? Or put is as a list?

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,
<mjm> secure how?

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.
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.
<mjm> ICN will allow to evolve - not clear how the message security is preserved when you use a translation interface

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
<mjm> topic is the integration

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 .
<mjm> typo: networks. Not typo: QoS was central to many recent ICNRG meetings and this paragraph should at least make recommendations to these best approaches.

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.
<mjm> this is a great table and maybe should lead the section instead of closing it?

Table 1: Mapping of ICN Gaps to Potential Protocol Efforts

7. Conclusion

This document provides high level deployment considerations for the
ICN community.
<mjm> and future members of the ICN community?

Specifically, the major configurations of possible
ICN deployments are identified as (1) Clean-slate ICN replacement of
existing Internet infrastructure; (2) ICN-as-an-Overlay; (3) ICN-as-
an-Underlay; (4) ICN-as-a-Slice; and (5) Composite-ICN. Existing ICN
trial systems primarily fall under the ICN-as-an-Overlay, ICN-as-an-
Underlay and Composite-ICN configurations.

In terms of deployment migration paths, ICN-as-an-Underlay offers a
clear migration path for CDN, edge 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
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.
<mjm> Impact here and below is not clearly defined.

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.
<mjm> this is obvious. Any inkling of the number of nodes necessary for a true testbed? For example this draft talks extensively of international collaborations but as of last year there were no NDN nodes in Canada. What are the plans?

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.
<mjm> Will this still be the same in 2 years?

8. IANA Considerations

This document requests no IANA actions.

9. Security Considerations
<mjm> this is really important.

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 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.
<mjm> yes and of course what higher layer applications are ready to expose

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.
<mjm> model such as?

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
<mjm> please check spellings and lower case naming; also decide on a way to decline the authors names and be consistent

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

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

[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>.
<mjm> MSardra or Sardara M.

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

<mjm> Suthar

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

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

<mjm> Suthar?

[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.
<mjm> You have et al. in other references - still work in progress in 2019?

[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.
<mjm> See above - still work in progress in 2019?

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

<mjm> See above - still work in progress in 2019?

[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.
<mjm> See above - still work in progress in 2019?

[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.
<mjm> See above - still work in progress in 2019?

[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.
<mjm> See above - still work in progress in 2019?

[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.
<mjm> See above - still work in progress in 2019?

[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.
<mjm> Suthar? - still work in progress in 2019?

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

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

[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>.
<mjm> Use et al.?

[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>.
<mjm> Use et al.?

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

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

[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>.
<mjm> Use et al.?

[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>.
<mjm> Use et al.?

[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>.
<mjm> Use et al.?

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

[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.
<mjm> a strong case to use et al.?

[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 .
<mjm> Use et al.?

[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 .
<mjm> Use et al.?

[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.
<mjm> Use et al.?

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

Marie-Jose Montpetit, Ph.D.
mariejo@mit.edu
marie@mjmontpetit.com
+1-781-526-2661
@SocialTVMIT

[icnrg] Review of draft-irtf-icnrg-deployment-gui… Marie-Jose Montpetit