rfc9273xml2.original.xml   rfc9273.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc, <!DOCTYPE rfc [
which is available here: http://xml.resource.org. --> <!ENTITY nbsp "&#160;">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY zwsp "&#8203;">
<!-- One method to get references from the online citation libraries. <!ENTITY nbhy "&#8209;">
There has to be one entity for each item to be referenced. <!ENTITY wj "&#8288;">
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC4601 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4601.xml">
<!ENTITY RFC6395 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6395.xml">
<!ENTITY RFC5549 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5549.xml">
<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2629.xml">
<!ENTITY RFC5378 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5378.xml">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="no"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-irtf-nwcrg-nwc-ccn-reqs-09" ipr="trust200902
">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- trust200902 -->
<!-- ***** FRONT MATTER ***** -->
<front> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IRTF" category="
<!-- The abbreviated title is used in the page header - it is only necessary info" consensus="true" docName="draft-irtf-nwcrg-nwc-ccn-reqs-09" number="9273"
if the ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDep
full title is longer than 39 characters --> th="4" symRefs="false" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.13.0 -->
<front>
<title abbrev="NC for CCNx/NDN">Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges <title abbrev="NC for CCNx/NDN">Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges
</title> </title>
<seriesInfo name="RFC" value="9273"/>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Kazuhisa Matsuzono" initials="K" surname="Matsuzono"> <author fullname="Kazuhisa Matsuzono" initials="K" surname="Matsuzono">
<organization abbrev="NICT">National Institute of Information and Communic ations Technology</organization> <organization abbrev="NICT">National Institute of Information and Communic ations Technology</organization>
<address> <address>
<postal> <postal>
<street>4-2-1 Nukui-Kitamachi</street> <street>4-2-1 Nukui-Kitamachi</street>
<city>Koganei</city> <region>Tokyo</region> <region>Tokyo</region>
<code>184-8795</code> <code>184-8795</code>
<country>Japan</country> <country>Japan</country>
</postal> </postal>
<email>matsuzono@nict.go.jp</email> <email>matsuzono@nict.go.jp</email>
</address> </address>
</author> </author>
<author initials="H" surname="Asaeda" fullname="Hitoshi Asaeda"> <author initials="H" surname="Asaeda" fullname="Hitoshi Asaeda">
<organization abbrev="NICT">National Institute of Information and Communic ations Technology</organization> <organization abbrev="NICT">National Institute of Information and Communic ations Technology</organization>
<address> <address>
<postal> <postal>
<street>4-2-1 Nukui-Kitamachi</street> <street>4-2-1 Nukui-Kitamachi</street>
<city>Koganei</city> <region>Tokyo</region> <region>Tokyo</region>
<code>184-8795</code> <code>184-8795</code>
<country>Japan</country> <country>Japan</country>
</postal> </postal>
<email>asaeda@nict.go.jp</email> <email>asaeda@nict.go.jp</email>
</address> </address>
</author> </author>
<author fullname="Cedric Westphal" initials="C" surname="Westphal">
<author fullname="Cedric Westphal" initials="C" surname="Westphal">
<organization abbrev="Huawei">Huawei</organization> <organization abbrev="Huawei">Huawei</organization>
<address> <address>
<postal> <postal>
<street>2330 Central Expressway</street> <street>2330 Central Expressway</street>
<city>Santa Clara</city> <region>California</region> <city>Santa Clara</city>
<code>95050</code> <region>California</region>
<country>USA</country> <code>95050</code>
</postal> <country>United States of America</country>
<email>cedric.westphal@futurewei.com,</email> </postal>
<email>cedric.westphal@futurewei.com,</email>
</address> </address>
</author> </author>
<date year="2022" month="August"/>
<date year="2022" />
<!-- If the month and year are both specified and are the current ones, xml2r
fc will fill in the current day for you. If only the current year is specified,
xml2rfc will fill in the current day and month for you. If the year is not the c
urrent one, it is necessary to specify at least a month (xml2rfc assumes day="1"
if not specified for the purpose of calculating the expiry date). With drafts
it is normally sufficient to specify just the year. -->
<!-- Meta-data Declarations -->
<area>IRTF</area>
<workgroup>NWCRG and ICNRG </workgroup>
<!-- WG name at the upperleft corner of the doc, <workgroup>Coding for Efficient Network Communications</workgroup>
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<!-- Keywords will be incorporated into HTML output <keyword>ICN</keyword>
files in a meta tag but they have no effect on text or nroff <keyword>CCNx</keyword>
output. If you submit your draft to the RFC Editor, the <keyword>NDN</keyword>
keywords will be used for the search engine. --> <keyword>network coding</keyword>
<keyword>in-network cache</keyword>
<abstract> <abstract>
<t>This document describes the current research outcomes in Network Coding <t>This document describes the current research outcomes in Network Coding
(NC) for Content-Centric Networking (CCNx) / Named Data Networking (NDN), and cl (NC) for Content-Centric Networking (CCNx) / Named Data Networking (NDN) and cl
arifies the technical considerations and potential challenges for applying NC in arifies the technical considerations and potential challenges for applying NC in
CCNx/NDN. This document is the product of the Coding for Efficient Network Comm CCNx/NDN. This document is the product of the Coding for Efficient Network Comm
unications Research Group (NWCRG) and the Information-Centric Networking Researc unications Research Group (NWCRG) and the Information-Centric Networking Researc
h Group (ICNRG).</t> h Group (ICNRG).</t>
</abstract> </abstract>
</front> </front>
<middle>
<middle>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section title="Introduction">
<t>Information-Centric Networking (ICN) in general, and Content-Centric Ne
tworking (CCNx) <xref target="Jacobson09" /> or Named Data Networking (NDN) <xre
f target="Zhang14" /> in particular, have emerged as a novel communication parad
igm advocating the retrieval of data based on their names. This paradigm pushes
content awareness into the network layer. It is expected to enable consumers to
obtain the content they desire in a straightforward and efficient manner from th
e heterogenous networks they may be connected to. The CCNx/NDN architecture has
introduced innovative ideas and has stimulated research in a variety of areas, s
uch as in-network caching, name-based routing, multipath transport, and content
security. One key benefit of requesting content by name is that it eliminates th
e requirement to establish a session between the client and a specific server, a
nd the content can thereby be retrieved from multiple sources.</t>
<t>In parallel, there has been a growing interest in both academia and ind
ustry for better understanding the fundamental aspects of Network Coding (NC) to
ward enhancing key system performance metrics such as data throughput, robustnes
s and reduction in the required number of transmissions through connected networ
ks, and redundant transmission on broadcast or point-to-multipoint connections.
NC is a technique that is typically used for encoding packets to recover from lo
st source packets at the receiver, and for effectively obtaining the desired inf
ormation in a fully distributed manner. In addition, in terms of security aspect
s, NC can be managed using a practical security scheme that deals with pollution
attacks <xref target="Gkantsidis06" />, and can be utilized for preventing eave
sdroppers from obtaining meaningful information <xref target="Cai02" /> or prote
cting a wireless video stream while retaining the NC benefits <xref target="Lima
10" /> <xref target="Vilela08" />.</t>
<t>From the perspective of the NC transport mechanism, NC can be divided i
nto two major categories: coherent NC, and non-coherent NC <xref target="Koetter
08" /> <xref target="Vyetrenko09" />. In coherent NC, the source and destinatio
n nodes know the exact network topology and the coding operations available at i
ntermediate nodes. When multiple consumers are attempting to receive the same co
ntent such as live video streaming, coherent NC could enable optimal throughput
by sending the content flow over the constructed optimal multicast trees <xref t
arget="Wu04" />. However, it requires a fully adjustable and specific routing me
chanism, and a large computational capacity for central coordination. In the cas
e of non-coherent NC, which often uses Random Linear Coding (RLC), it is not nec
essary to know the network topology nor the intermediate coding operations <xref
target="Ho06" />. As non-coherent NC works in a completely independent and dece
ntralized manner, this approach is more feasible in terms of eliminating such a
central coordination.</t>
<!-- <t>NC combines multiple packets together with parts of the same cont
ent, and may do this at the source or at other nodes in the network. Network cod
ed packets are not associated with a specific server, as they may have been comb
ined within the network. As NC is focused on what information should be encoded
in a network packet instead of the specific host at which it has been generated,
it is in line with the architecture of the CCNx/NDN core networking layer. NC h
as already been implemented for information/content dissemination <xref target="
Dimarkis10" /> <xref target="Gkantsidis05" /> <xref target="Seferoglu07" />. Mon
tpetit, et al., first suggested that NC techniques be exploited to enhance key a
spects of system performance in ICN <xref target="Montpetit12" />. NC provides C
CNx/NDN with the highly beneficial potential of effectively disseminating inform
ation in a completely topology independent and decentralized manner.</t> -->
<!-- <t>NC combines multiple packets together with parts of the same cont
ent, and may do this at the source and/or at other nodes in the network. Network
coded packets are not associated with a specific server, as they may have been
combined within the network. As NC is focused on what information should be enco
ded in a network packet instead of the specific host at which it has been genera
ted, it is in line with the architecture of the CCNx/NDN core networking layer.
In fact, NC has already been implemented for information/content dissemination <
xref target="Dimarkis10" /> <xref target="Gkantsidis05" /> <xref target="Seferog
lu07" />. Montpetit, et al., first suggested that NC techniques be exploited to
enhance key aspects of system performance in ICN <xref target="Montpetit12" />.
Although CCNx/NDN is excellent with the NC technology to exploit the NC benefits
(as described in <xref target="Advantages" />), some technical considerations a
re needed to combine NC and CCNx/NDN owing to the unique features of CCNx/NDN (a
s described in <xref target="TecCons" />).</t>
-->
<t>NC combines multiple packets together with parts of the same content,
and may do this at the source and/or at other nodes in the network. Network code
d packets are not associated with a specific server, as they may have been combi
ned within the network. As NC is focused on what information should be encoded i
n a network packet instead of the specific host at which it has been generated,
it is in line with the architecture of the CCNx/NDN core networking layer. NC al
lows for recovery of missing packets by encoding the information across several
packets. ICN is synergistic with NC, as it allows for caching of data packets th
roughout the network. In a typical network that uses NC, the sender must transmi
t enough packets to retrieve the original data. ICN offers an opportunity to ret
rieve network coded packets directly from caches in the network and this makes t
he combination of ICN and NC particularly effective. In fact, NC has already bee
n implemented for information/content dissemination <xref target="Dimarkis10" />
<xref target="Gkantsidis05" /> <xref target="Seferoglu07" />. Montpetit, et al.
, first suggested that NC techniques be exploited to enhance key aspects of syst
em performance in ICN <xref target="Montpetit12" />. Although CCNx/NDN excels to
exploit the benefits of NC (as described in <xref target="Advantages" />), some
technical considerations are needed to combine NC and CCNx/NDN owing to the uni
que features of CCNx/NDN (as described in <xref target="TecCons" />).</t>
<t>In this document, we consider how NC can be applied to the CCNx/NDN ar
chitecture and describe the technical considerations and potential challenges fo
r making CCNx/NDN-based communications better using the NC technology. It should
be noted that the presentation of specific solutions (e.g., NC optimization met
hods) for enhancing CCNx/NDN performance metrics by exploiting NC is outside the
scope of this document.</t>
<t>This document represents the collaborative work and consensus of the C
oding for Efficient Network Communications Research Group (NWCRG) and the Inform
ation-Centric Networking Research Group (ICNRG). It is not an IETF product and i
s not a standard.</t>
</section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section title="Terminology">
<!-- <t>This section provides the terms related to NC and CCNx/NDN used i
n this document.</t>
-->
<section title="Definitions related to NC">
<t>This section provides the terms related to NC used in this document, w
hich are defined in RFC8406 [21] produced by NWCRG.</t>
<!-- <t>The terms regarding NC used in this document are defined as follo
ws. These are aligned with RFCs produced by the FEC Framework (FECFRAME) IETF Wo
rking Groups as well as IRTF Coding for Efficient Network Communications Researc
h Group (NWCRG)<xref target="I-D.irtf-nwcrg-network-coding-taxonomy" />.</t>
-->
<!--
<t>The definitions of the general terms used are as follows:</t>
-->
<t><list style="symbols">
<!-- general definitions -->
<!-- <t>End-to-End Coding: A system where coding is performed at
the source or (coding) middlebox, and decoding is performed at the destination(s
) or (decoding) middlebox. There is no re-coding operation at intermediate nodes
.</t> -->
<!-- <t>Network Coding (NC): A system where coding can be perform
ed at the source as well as at intermediate forwarding nodes (all or a subset of
them). End-to-End coding is regarded as a special case of network coding.</t> -
->
<!-- <t>Source Symbol: A unit of data originating from the source
that is used as input to encoding operations.</t> -->
<!-- <t>Coded Symbol, or Repair Symbol: A unit of data that is th
e result of a coding operation, applied either to source symbols or (in case of
re-coding) source and/or coded symbols.</t> -->
<t>Source Packet: A packet originating from the source that contr
ibutes to one or more source symbols. The source symbol is a unit of data origin
ating from the source that is used as input to encoding operations. For instance
, a real-time transport protocol (RTP) packet as a whole can constitute a source
symbol. In other situations (e.g., to address variable size packets), a single
RTP packet may contribute to various source symbols.</t>
<t>Repair Packet: A packet containing one or more coded symbols (
also called repair symbol). Coded symbol or repair symbol is a unit of data that
is the result of a coding operation, applied either to source symbols or (in ca
se of re-coding) source and/or coded symbols. When there is a single repair symb
ol per repair packet, a repair symbol corresponds to a repair packet.</t>
<!--
<t>Coded Packet, or Repair Packet: A packet containing one or mor
e coded symbols (also called repair symbol). The coded symbol is a unit of data
that is the result of a coding operation, applied either to source symbols or (i
n case of re-coding) source and/or coded symbols. When there is a single coded
symbol per coded packet, a coded symbol corresponds to a coded packet.</t>
<!--
<t>Innovative Packet: A source or repair packet that increases th
e rank of the linear system (also called degrees of freedom) at a receiver.</t>
-->
<t>Encoding versus Re-coding versus Decoding: Encoding is an oper
ation that takes source symbols as input and produces encoding symbols (source o
r coded symbols) as output. Re-coding is an operation that takes encoding symbol
s as input and produces encoding symbols as output. Decoding is an operation tak
es encoding symbols as input and produces source symbols as output.</t>
</list></t>
<t>The terms regarding coding types are defined as follows:</t>
<t><list style="symbols">
<!-- Coding Types -->
<!-- <t>Linear Coding: Linear combination of a set of input symbo
ls (i.e., source and/or coded symbols) using a given set of coefficients and res
ulting in a repair symbol.</t> -->
<t>Random Linear Coding (RLC): A particular form of linear coding
using a set of random coding coefficients. Linear coding performs linear combin
ation of a set of input symbols (i.e., source and/or coded symbols) using a give
n set of coefficients and results in a repair symbol.</t>
<t>Block Coding: A coding technique wherein the input flow(s) mus
t be first segmented into a sequence of blocks; encoding and decoding are perfor
med independently on a per-block basis.</t>
<!-- <t>Systematic Coding: A coding technique where source symbol
s are part of the output flow generated by a coding node.</t> -->
<t>Sliding Window Coding or Convolutional Coding: A general class
of coding techniques that rely on a sliding encoding window. Encoding window is
a set of source (and coded in the case of re-coding) symbols used as input to t
he coding operations. The set of symbols change over time, as the encoding windo
w slides over the input flow(s). This is an alternative solution to block coding
.</t>
<t>Fixed or Elastic Sliding Window Coding: A coding technique tha
t generates coded symbol(s) on the fly, from the set of source symbols present i
n the sliding encoding window at that time, usually by using linear coding. The
sliding window may be either of fixed size or of variable size over the time (a
lso known as "Elastic Sliding Window"). For instance, the size may depend on ac
knowledgments sent by the receiver(s) for a particular source symbol or source p
acket (received, decoded, or decodable).</t>
</list></t>
<t>The terms regarding low-level coding aspects are defined as follows:</
t>
<t><list style="symbols">
<!-- Coding Basics -->
<t>Rank of the Linear System or Degrees of Freedom: At a receiver
, the number of linearly independent equations of the linear system. It is also
known as "Degrees of Freedom". The system may be of "full rank," wherein decodin
g is possible, or "partial rank", wherein only partial decoding is possible.</t>
<t>Generation, or Block: With block codes, the set of source symb
ols of the input flow(s) that are logically grouped into a block, before doing e
ncoding.</t>
<t>Generation Size, or Block Size: With block codes, the number o
f source symbols belonging to a block. It is equivalent to the number of source
packets when there is a single source symbol per source packet.</t>
<!--
<t>Generation ID, or Block ID: With block codes, the identifier o
f a block to which source and coded symbols belong. It is also known as "Source
Block Number (SBN)".</t>
-->
<t>Coding Coefficient: With linear coding, this is a coefficient
in a certain finite field. This coefficient may be chosen in different ways: for
instance, randomly, in a predefined table, or using a predefined algorithm plus
a seed.</t>
<t>Coding Vector: A set of coding coefficients used to generate a
certain coded symbol through linear coding.</t>
<t>Finite Field: Finite fields, used in linear codes, have the de
sired property of having all elements (except zero) invertible for + and * and n
o operation over any elements can result in an overflow or underflow. Examples o
f finite fields are prime fields {0..p^m-1}, where p is prime. Most used fields
use p=2 and are called binary extension fields {0..2^m-1}, where m often equals
1, 4 or 8 for practical reasons.</t>
<!-- <t>Finite Field size: The number of elements in a finite fie
ld. For example the binary extension field {0..2^m-1} has size q=2^m.</t> -->
<!-- <t>Feedback: Feedback information sent by a decoding node to
a node (or from a receiver to a source in case of end-to-end coding). The natu
re of information contained in a feedback packet varies, depending on the use-ca
se. It can provide reception and/or decoding statistics, or the list of availab
le source packets received or decoded, or the list of lost source packets that s
hould be retransmitted, or a number of additional coded packet needed to have a
full rank linear system.</t> -->
</list></t>
</section>
<section title="Definitions related to CCNx/NDN">
<t>The terminology regarding CCNx/NDN used in this document is defined in
RFC8793 <xref target="CCNxTerm" /> produced by ICNRG. They are consistent with
the relevant documents (<xref target="CCNxSema" /> <xref target="CCNxMsg" />).</
t>
<!--
<t>The terms regarding CCNx/NDN used in this document are defined
below. They are consistent with the RFCs produced by the Information-Centric Ne
tworking (ICNRG) IRTF Working Group<xref target="CCNxSema" /> <xref target="CCNx
Msg" />.</t>
<t><list style="symbols">
<t>Interest: A message requesting a content object with a matchin
g name and other optional selectors for selecting from multiple objects having t
he same name prefix.</t>
<t>Content Object: A unit of content data delivered through the C
CNx/NDN network.</t>
<t>Consumer: A node requesting a name (i.e., content). It initiat
es the name-based communication by sending an interest packet.</t>
<t>Publisher: A node that provides content. It originally creates <section numbered="true" toc="default">
or owns a content.</t> <name>Introduction</name>
<t>Information-Centric Networking (ICN), in general, and Content-Centric N
etworking (CCNx) <xref target="Jacobson09" format="default"/> or Named Data Netw
orking (NDN) <xref target="Zhang14" format="default"/>, in particular, have emer
ged as a novel communication paradigm that advocates for the retrieval of data b
ased on their names. This paradigm pushes content awareness into the network lay
er. It is expected to enable consumers to obtain the content they desire in a st
raightforward and efficient manner from the heterogenous networks they may be co
nnected to. The CCNx/NDN architecture has introduced innovative ideas and has st
imulated research in a variety of areas, such as in-network caching, name-based
routing, multipath transport, and content security. One key benefit of requestin
g content by name is that it eliminates the requirement to establish a session b
etween the client and a specific server, and the content can thereby be retrieve
d from multiple sources.</t>
<t>In parallel, there has been a growing interest in both academia and ind
ustry for better understanding the fundamental aspects of Network Coding (NC) to
ward enhancing key system performance metrics, such as data throughput, robustne
ss and reduction in the required number of transmissions through connected netwo
rks, and redundant transmission on broadcast or point-to-multipoint connections.
NC is a technique that is typically used for encoding packets to recover from l
ost source packets at the receiver and for effectively obtaining the desired inf
ormation in a fully distributed manner. In addition, in terms of security aspect
s, NC can be managed using a practical security scheme that deals with pollution
attacks <xref target="Gkantsidis06" format="default"/> and can be utilized for
preventing eavesdroppers from obtaining meaningful information <xref target="Cai
02" format="default"/> or protecting a wireless video stream while retaining the
NC benefits <xref target="Lima10" format="default"/> <xref target="Vilela08" fo
rmat="default"/>.</t>
<t>From the perspective of the NC transport mechanism, NC can be divided i
nto two major categories: coherent NC and noncoherent NC <xref target="Koetter03
" format="default"/> <xref target="Vyetrenko09" format="default"/>. In coherent
NC, the source and destination nodes know the exact network topology and the co
ding operations available at intermediate nodes. When multiple consumers are att
empting to receive the same content, such as live video streaming, coherent NC c
ould enable optimal throughput by sending the content flow over the constructed
optimal multicast trees <xref target="Wu04" format="default"/>. However, it requ
ires a fully adjustable and specific routing mechanism and a large computational
capacity for central coordination. In the case of noncoherent NC, which often u
ses Random Linear Coding (RLC), it is not necessary to know the network topology
nor the intermediate coding operations <xref target="Ho06" format="default"/>.
As noncoherent NC works in a completely independent and decentralized manner, th
is approach is more feasible in terms of eliminating such a central coordination
.</t>
<t>NC combines multiple packets together with parts of the same content an
d may do this at the source and/or at other nodes in the network. Network coded
packets are not associated with a specific server, as they may have been combine
d within the network. As NC is focused on what information should be encoded in
a network packet instead of the specific host at which it has been generated, it
is in line with the architecture of the CCNx/NDN core networking layer. NC allo
ws for recovery of missing packets by encoding the information across several pa
ckets. ICN is synergistic with NC, as it allows for caching of data packets thro
ughout the network. In a typical network that uses NC, the sender must transmit
enough packets to retrieve the original data. ICN offers an opportunity to retri
eve network-coded packets directly from caches in the network, making the combin
ation of ICN and NC particularly effective. In fact, NC has already been impleme
nted for information/content dissemination <xref target="Dimarkis10" format="def
ault"/> <xref target="Gkantsidis05" format="default"/> <xref target="Seferoglu07
" format="default"/>. Montpetit et al. first suggested that NC techniques be ex
ploited to enhance key aspects of system performance in ICN <xref target="Montpe
tit12"/>. Although CCNx/NDN excels to exploit the benefits of NC (as described i
n <xref target="Advantages" format="default"/>), some technical considerations a
re needed to combine NC and CCNx/NDN owing to the unique features of CCNx/NDN (a
s described in <xref target="TecCons" format="default"/>).</t>
<t>In this document, we consider how NC can be applied to the CCNx/NDN arc
hitecture and describe the technical considerations and potential challenges for
making CCNx/NDN-based communications better using the NC technology. It should
be noted that the presentation of specific solutions (e.g., NC optimization meth
ods) for enhancing CCNx/NDN performance metrics by exploiting NC is outside the
scope of this document.</t>
<t>This document represents the collaborative work and consensus of the Co
ding for Efficient Network Communications Research Group (NWCRG) and the Informa
tion-Centric Networking Research Group (ICNRG). This document was read and revie
wed by all the active research group members. It is not an IETF product and is n
ot a standard.</t>
</section>
<t>Router: An intermediate node between the consumer and producer <section numbered="true" toc="default">
that facilitates the name-based communication by forwarding interest and data p <name>Terminology</name>
ackets.</t>
<t>Forwarding Information Base (FIB): A lookup table in a content <section numbered="true" toc="default">
router containing the name prefix and corresponding destination interface for f <name>Definitions Related to NC</name>
orwarding the interest packets.</t> <t>This section provides the terms related to NC used in this document,
which are defined in RFC 8406 <xref target="RFC8406" format="default"/> and prod
uced by the NWCRG.</t>
<t>Pending Interest Table (PIT): A lookup table populated by the <dl newline="true" spacing="normal">
interest packets containing the name prefix of the requested data, and the outgo <dt>Source Packet:</dt>
ing interface used to forward the received data packets.</t> <dd>A packet originating from the source that contributes to one or
more source symbols. The source symbol is a unit of data originating from the s
ource that is used as input to encoding operations. For instance, a Real-time Tr
ansport Protocol (RTP) packet as a whole can constitute a source symbol. In othe
r situations (e.g., to address variable size packets), a single RTP packet may c
ontribute to various source symbols.</dd>
<dt>Repair Packet:</dt>
<dd>A packet containing one or more coded symbols (also calle
d repair symbol). The coded symbol or repair symbol is a unit of data that is th
e result of a coding operation, applied either to source symbols or (in case of
recoding) source and/or coded symbols. When there is a single repair symbol per
repair packet, a repair symbol corresponds to a repair packet.</dd>
<dt>Encoding versus Recoding versus Decoding:</dt>
<dd>Encoding is an operation that takes source symbols as inp
ut and produces encoding symbols (source or coded symbols) as output. Recoding i
s an operation that takes encoding symbols as input and produces encoding symbol
s as output. Decoding is an operation that takes encoding symbols as input and p
roduces source symbols as output.</dd>
</dl>
<t>The terms regarding coding types are defined as follows:</t>
<dl newline="true" spacing="normal">
<dt>Random Linear Coding (RLC):</dt>
<dd>A particular form of linear coding using a set of random
coding coefficients. Linear coding performs a linear combination of a set of inp
ut symbols (i.e., source and/or coded symbols) using a given set of coefficients
and results in a repair symbol.</dd>
<dt>Block Coding:</dt>
<dd>A coding technique wherein the input flow(s) must be firs
t segmented into a sequence of blocks. Encoding and decoding are performed indep
endently on a per-block basis.</dd>
<t>Content Store (CS): A storage space for a router to cache cont <dt>Sliding Window Coding or Convolutional Coding:</dt>
ent objects.</t> <dd>A general class of coding techniques that rely on a
sliding encoding window. An encoding window is a set of source (and coded in th
e case of recoding) symbols used as input to the coding operations. The set of s
ymbols change over time, as the encoding window slides over the input flow(s). T
his is an alternative solution to block coding.</dd>
<dt>Fixed or Elastic Sliding Window Coding:</dt>
<dd>A coding technique that generates coded symbol(s) on the
fly, from the set of source symbols present in the sliding encoding window at th
at time, usually by using linear coding. The sliding window may be either of fi
xed size or of variable size over time (also known as "Elastic Sliding Window").
For instance, the size may depend on acknowledgments sent by the receiver(s) f
or a particular source symbol or source packet (received, decoded, or decodable)
.</dd>
</dl>
<t>The terms regarding low-level coding aspects are defined as follows:<
/t>
<dl newline= "true" spacing="normal">
<dt>Rank of the Linear System or Degrees of Freedom:</dt>
<dd>At a receiver, the number of linearly independent equatio
ns of the linear system. It is also known as "Degrees of Freedom". The system ma
y be of "full rank", wherein decoding is possible, or "partial rank", wherein on
ly partial decoding is possible.</dd>
<dt>Generation or Block:</dt>
<dd>With block codes, the set of source symbols of the input
flow(s) that are logically grouped into a block before doing encoding.</dd>
<dt>Generation Size or Block Size:</dt>
<dd>With block codes, the number of source symbols belonging
to a block. It is equivalent to the number of source packets when there is a sin
gle source symbol per source packet.</dd>
</list></t> <dt>Coding Coefficient:</dt>
--> <dd>With linear coding, this is a coefficient in a certain fi
nite field. This coefficient may be chosen in different ways: for instance, rand
omly, in a predefined table or using a predefined algorithm plus a seed.</dd>
<dt>Coding Vector:</dt>
<dd>A set of coding coefficients used to generate a certain c
oded symbol through linear coding.</dd>
<dt>Finite Field:</dt>
<dd>Finite fields, used in linear codes, have the desired pro
perty of having all elements (except zero) invertible for + and *, and no operat
ion over any elements can result in an overflow or underflow. Examples of finite
fields are prime fields {0..p<sup>m-1</sup>}, where p is prime. Most used fiel
ds use p=2 and are called binary extension fields {0..2<sup>m-1</sup>}, where m
often equals 1, 4, or 8 for practical reasons.</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>Definitions Related to CCNx/NDN</name>
<t>The terminology regarding CCNx/NDN used in this document is defined i
n RFC 8793 <xref target="RFC8793" format="default"/>, which was produced by the
ICNRG. They are consistent with the relevant documents (<xref target="RFC8569" f
ormat="default"/> <xref target="RFC8609" format="default"/>).</t>
</section> </section>
</section> </section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --> <section numbered="true" toc="default">
<section title="CCNx/NDN Basics"> <name>CCNx/NDN Basics</name>
<t>We briefly explain the key concepts of CCNx/NDN. In a CCNx/NDN network,
<!-- there are two types of packets at the network level: interest and data packet (
<t>We briefly explain the key concepts of CCNx/NDN. Both protocols are si defined in <xref target="RFC8793" section="3.4" sectionFormat="of" format="defau
milar in principle, but differ in some architecture and protocol choices. </t> lt"/>). The term "content object", which means a unit of content data, is an ali
<t>We briefly explain the key concepts of CCNx/NDN. In a CCNx/NDN network as to data packet <xref target="RFC8793" format="default"/>. The ICN consumer (d
, there are two types of packets at the network level: interest and data packet efined in <xref target="RFC8793" section="3.2" sectionFormat="of" format="defaul
(defined in Section 3.4 of <xref target="CCNxTerm" />). The term of content obje t"/>) requests a content object by sending an interest that carries the name of
ct, which means a unit of content data, is an alias to data packet <xref target= the data.</t>
"CCNxTerm" />. The ICN consumer (defined in Section 3.2 of <xref target="CCNxTer
m" />) requests a content object by sending an interest that carries the name o
f the data.</t>
<!--
One difference to note here between CCNx and NDN is that
in CCNx <xref target="CCNxMsg" />, the interest is required to carry a full name
, while in NDN <xref target="NDNPacket" />, it may carry a name prefix (and rece
ive in return any data with a name matching this prefix).</t> -->
<t>Once an ICN forwarder (defined in Section 3.2 of <xref target="CCNxTer
m" />) receives an interest, it performs a series of lookups: first it checks if
it has a copy of the requested content object available in the cache storage ca
lled Content Store (CS) (defined in Section 3.3 of <xref target="CCNxTerm" />).
If it does, it returns the data, and the transaction is considered to have been
successfully completed.</t>
<t>If it does not have a copy of the requested content object in the CS,
it performs a lookup of the Pending Interest Table (PIT) (defined in Section 3.3
of <xref target="CCNxTerm" />) to check if there is already an outgoing interes
t for the same content object. If there is no such interest, then it creates an
entry in the PIT that lists the name included in the interest, and the interface
s from which it received the interest. This is later used to send the content ob
ject back, as interest packets do not carry a source field that identifies the c
onsumer. If there is already a PIT entry for this name, it is updated with the i
ncoming interface of this new interest, and the interest is discarded.</t>
<t>After the PIT lookup, the interest undergoes a Forwarding Information
Base (FIB) (defined in Section 3.3 of <xref target="CCNxTerm" />) lookup for sel
ecting an outgoing interface. The FIB lists name prefixes and their correspondin
g forwarding interfaces in order to send the interest towards a forwarder that p
ossesses a copy of the requested data.</t>
<t>Once a copy of the data is retrieved, it is sent back to the consumer(
s) using the trail of PIT entries; forwarders remove the PIT state every time th
at an interest is satisfied, and may store the data in their CS.</t>
<t>Data packets carry some information for verifying data integrity and o
rigin authentication, and in particular, that the data is indeed that which corr
esponds to the name <xref target="RFC7927" />. This is necessary because authent
ication of the object is crucial in CCNx/NDN. However, this step is optional at
forwarders in order to speed up the processing.</t>
<t>The key aspect of CCNx/NDN is that the consumer of the content does no
t establish a session with a specific server. Indeed, the forwarder or producer
(defined in Section 3.2 of <xref target="CCNxTerm" />) that returns the content
object is not aware of the network location of the consumer and the consumer is
not aware of the network location of the node that provides the content. This, i
n theory, allows the interests to follow different paths within a network or eve
n to be sent over completely different networks.</t>
<t>Once an ICN forwarder (defined in <xref target="RFC8793" section="3.2"
sectionFormat="of" format="default"/>) receives an interest, it performs a serie
s of lookups. First, it checks if it has a copy of the requested content object
available in the cache storage, called Content Store (CS) (defined in <xref targ
et="RFC8793" section="3.3" sectionFormat="of" format="default"/>). If it does, i
t returns the data, and the transaction is considered to have been successfully
completed.</t>
<t>If it does not have a copy of the requested content object in the CS, i
t performs a lookup of the Pending Interest Table (PIT) (defined in <xref target
="RFC8793" section="3.3" sectionFormat="of" format="default"/>) to check if ther
e is already an outgoing interest for the same content object. If there is no su
ch interest, then it creates an entry in the PIT that lists the name included in
the interest and the interfaces from which it received the interest. This is la
ter used to send the content object back, as interest packets do not carry a sou
rce field that identifies the consumer. If there is already a PIT entry for this
name, it is updated with the incoming interface of this new interest, and the i
nterest is discarded.</t>
<t>After the PIT lookup, the interest undergoes a Forwarding Information B
ase (FIB) (defined in <xref target="RFC8793" section="3.3" sectionFormat="of" fo
rmat="default"/>) lookup for selecting an outgoing interface. The FIB lists name
prefixes and their corresponding forwarding interfaces in order to send the int
erest toward a forwarder that possesses a copy of the requested data.</t>
<t>Once a copy of the data is retrieved, it is sent back to the consumer(s
) using the trail of PIT entries; forwarders remove the PIT state every time tha
t an interest is satisfied and may store the data in their CS.</t>
<t>Data packets carry some information for verifying data integrity and or
igin authentication and, in particular, that the data is indeed that which corre
sponds to the name <xref target="RFC7927" format="default"/>. This is necessary
because authentication of the object is crucial in CCNx/NDN. However, this step
is optional at forwarders in order to speed up the processing.</t>
<t>The key aspect of CCNx/NDN is that the consumer of the content does not
establish a session with a specific server. Indeed, the forwarder or producer (
defined in <xref target="RFC8793" section="3.2" sectionFormat="of" format="defau
lt"/>) that returns the content object is not aware of the network location of t
he consumer, and the consumer is not aware of the network location of the node t
hat provides the content. This, in theory, allows the interests to follow differ
ent paths within a network or even to be sent over completely different networks
.</t>
</section> </section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --> <section numbered="true" toc="default">
<section title="NC Basics"> <name>NC Basics</name>
<t> While the forwarding node simply relays received data packets in conv <t> While the forwarding node simply relays received data packets in conve
entional IP communication networks, NC allows the node to combine some data pack ntional IP communication networks, NC allows the node to combine some data packe
ets that are already received into one or several output packets to be sent. In ts that are already received into one or several output packets to be sent. In t
this section, we simply describe the basic operations of NC. Herein, we focus on his section, we simply describe the basic operations of NC. Herein, we focus on
RLC in a block coding manner that is well known as a major coding technique.</t RLC in a block coding manner that is well known as a major coding technique.</t>
> <t>For simplicity, let us consider an example case of end-to-end coding wh
erein a producer and consumer respectively perform encoding and decoding for a c
<t>For simplicity, let us consider an example case of end-to-end coding w ontent object. This end-to-end coding is regarded as a special case of NC. The p
herein a producer and consumer respectively perform encoding and decoding for a roducer splits the content into several blocks called generations. Encoding and
content object. This end-to-end coding is regarded as a special case of NC. The decoding are performed independently on a per-block (per-generation) basis. Let
producer splits the content into several blocks called generations. Encoding and us assume that each generation consists of K original source packets of the same
decoding are performed independently on a per-block (per-generation) basis. Let size. When the packets do not have the same size, zero padding is added. In ord
us assume that each generation consists of K original source packets of the sam er to generate one repair packet within a certain generation, the producer linea
e size. When the packets do not have the same size, zero padding is added. In or rly combines K of the original source packets, where additions and multiplicatio
der to generate one repair packet within a certain generation, the producer line ns are performed using a coding vector consisting of K coding coefficients that
arly combines K of the original source packets, where additions and multiplicati are randomly selected in a certain finite field. The producer may respond to int
ons are performed using a coding vector consisting of K coding coefficients that erests to send the corresponding source packets and repair packets in the conten
are randomly selected in a certain finite field. The producer may respond to in t flow (called systematic coding), where the repair packets are typically used f
terests to send the corresponding source packets and repair packets in the conte or recovering lost source packets.</t>
nt flow (called systematic coding), where the repair packets are typically used <t>Repair packets can also be used for performing encoding. If the forward
for recovering lost source packets.</t> ing nodes know each coding vector and generation identifier (hereinafter referre
d to as generation ID) of the received repair packets, they may perform an encod
<t>Repair packets can also be used for performing encoding. If the forwar ing operation (called recoding), which is the most distinctive feature of NC com
ding nodes know each coding vector and generation identifier (hereinafter referr pared to other coding techniques.</t>
ed to as generation ID) of the received repair packets, they may perform an enco <t>At the consumer, decoding is performed by solving a set of linear equat
ding operation (called re-coding), which is the most distinctive feature of NC c ions that are represented by the coding vectors of the received source and repai
ompared to other coding techniques.</t> r packets (possibly only repair packets) within a certain generation. In order t
o obtain all the source packets, the consumer requires K linearly independent eq
<t>At the consumer, decoding is performed by solving a set of linear equa uations. In other words, the consumer must receive at least K linearly independe
tions that are represented by the coding vectors of the received source and repa nt data packets (called innovative packets). As receiving a linearly dependent d
ir packets (possibly only repair packets) within a certain generation. In order ata packet is not useful for decoding, recoding should generate and provide inno
to obtain all the source packets, the consumer requires K linearly independent e vative packets. One of the major benefits of RLC is that, even for a small-sized
quations. In other words, the consumer must receive at least K linearly independ finite field (e.g., q=2<sup>8</sup>), the probability of generating linearly de
ent data packets (called innovative packets). As receiving a linearly dependent pendent packets is negligible <xref target="Wu04" format="default"/>.</t>
data packet is not useful for decoding, re-coding should generate and provide in
novative packets. One of major benefits of RLC is that even for a small-sized fi
nite field (e.g., q=2^8), the probability of generating linearly dependent packe
ts is negligible <xref target="Wu04" />.</t>
</section> </section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --> <section anchor="Advantages" numbered="true" toc="default">
<name>Advantages of NC and CCNx/NDN</name>
<section anchor="Advantages" title="Advantages of NC and CCNx/NDN"> <t>Combining NC and CCNx/NDN can contribute to effective large-scale conte
nt/information dissemination. They individually provide similar benefits, such a
<t>Combining NC and CCNx/NDN can contribute to effective large-scale conten s throughput/capacity gain and robustness enhancement. The difference between th
t/information dissemination. They individually provide similar benefits such as eir approaches is that the former considers content flow as algebraic informatio
throughput/capacity gain and robustness enhancement. The difference between thei n that is to be combined <xref target="Koetter03" format="default"/>, while the
r approaches is that, the former considers content flow as algebraic information latter focuses on the content/information itself at the networking layer. Becaus
that is to be combined <xref target="Koetter03" />, while the latter focuses on e these approaches are complementary and their combination would be advantageous
the content/information itself at the networking layer. Because these approache , it is natural to combine them.</t>
s are complementary and their combination would be advantageous, it is natural t <t>The name-based communication in CCNx/NDN enables consumers to obtain re
o combine them.</t> quested content objects without establishing and maintaining end-to-end communic
ation channels between nodes. This feature facilitates the exploitation of the i
<t>The name-based communication in CCNx/NDN enables consumers to n-network cache and multipath/multisource retrieval and also supports consumer m
obtain requested content objects without establishing and maintaining end-to-end obility without the need for updating the location information/identifier during
communication channels between nodes. This feature facilitates the exploitation handover <xref target="Jacobson09" format="default"/>. Furthermore, the name-ba
of the in-network cache and multipath/multisource retrieval and also supports c sed communication intrinsically supports multicast communication because identic
onsumer mobility without the need for updating the location information/identifi al interests are aggregated at the forwarders.</t>
er during handover <xref target="Jacobson09" />. Furthermore, the name-based com <t>NC can enable the CCNx/NDN transport system to effectively distribute a
munication intrinsically supports multicast communication because identical inte nd cache the data associated with multipath data retrieval <xref target="Montpet
rests are aggregated at the forwarders.</t> it12" format="default"/>. Exploiting multipath data retrieval and in-network cac
hing with NC contributes to not only improving the cache hit rate but also expan
<t>NC can enable the CCNx/NDN transport system to effecti ding the anonymity set of each consumer (the set of potential routers that can s
vely distribute and cache the data associated with multipath data retrieval <xre erve a given consumer) <xref target="Wu16" format="default"/>. The expansion mak
f target="Montpetit12" />. Exploiting multipath data retrieval and in-network ca es it difficult for adversaries to infer the content consumed by others and thus
ching with NC contributes to not only improving the cache hit rate but also expa contributes to improving cache privacy. Others also have introduced some use ca
nding the anonymity set of each consumer (the set of potential routers that can ses of the application of NC in CCNx/NDN, such as the cases of content dissemina
serve a given consumer) <xref target="Wu16" />. The expansion makes it difficult tion with in-network caching <xref target="Saltarin16" format="default"/> <xref
for adversaries to infer the content consumed by others, and thus contributes t target="Wang14" format="default"/> <xref target="Wang16" format="default"/>, sea
o improving cache privacy. Others also have introduced some use cases of the app mless consumer mobility <xref target="Ramakrishnan12" format="default"/> <xref t
lication of NC in CCNx/NDN, such as the cases of content dissemination with in-n arget="Carofiglio16" format="default"/>, and low-latency low-loss video streamin
etwork caching <xref target="Saltarin16" /> <xref target="Wang14" /> <xref targe g <xref target="Matsuzono17" format="default"/>. In this context, it is well wor
t="Wang16" />, seamless consumer mobility <xref target="Ramakrishnan12" /> <xref th considering NC integration in CCNx/NDN.</t>
target="Carofiglio16" />, and low-latency low-loss video streaming <xref target
="Matsuzono17" />. In this context, it is well worth considering NC integration
in CCNx/NDN.</t>
<!--
<t>CCNx/NDN does not provide reliable and robust content dissemin
ation by default. However, NC can enable the CCNx/NDN transport system to effect
ively distribute and cache the data associated with multipath data retrieval <xr
ef target="Montpetit12" />. Furthermore, NC can contribute to improving both the
caching performance and cache privacy that CCNx/NDN newly introduces at the net
working layer <xref target="Wu16" />. Others also have introduced some use cases
of the application of NC in CCNx/NDN, such as the cases of content disseminatio
n with in-network caching <xref target="Saltarin16" /> <xref target="Wang14" />
<xref target="Wang16" />, seamless consumer mobility <xref target="Ramakrishnan1
2" /> <xref target="Carofiglio16" />, and low-latency low-loss video streaming <
xref target="Matsuzono17" />. In this context, it is well worth considering NC i
ntegration in CCNx/NDN.</t>
</section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<section anchor="TecCons" title="Technical Considerations">
<t>This section presents the considerations for CCNx/NDN with NC in terms o
f network architecture and protocol. This document focuses on NC when employed i
n a block coding manner.</t>
<!-- ========================================================== -->
<section anchor="Naming" title="Content Naming">
<t>Naming content objects is as important for CCNx/NDN as naming hosts is
in the current-day Internet <xref target="RFC7927" />. In this section, two pos
sible naming schemes are presented.</t>
<section title="Unique Naming for NC Packets">
<t>Each source and repair packet (hereinafter referred to as NC packet) m
ay have a unique name as each original content object has in CCNx/NDN, as PIT an
d CS operations typically require a unique name for identifying the NC packet. A
s a method of naming an NC packet that takes into account the feature of block c
oding, the coding vector and the generation ID can be used as a part of the cont
ent object name. As in <xref target="Saltarin16" />, when the generation ID is "
g-id", generation size is 4, and coding vector is (1,0,0,0), the name could be /
CCNx.com/video-A/g-id/1000. Some other identifiers and/or parameters related to
the encoding scheme can also be used as name components. For instance, the encod
ing ID specifying the coding scheme may be used with "enc-id" such as /CCNx.com/
video-A/enc-id/g-id/1000, as defined in the FEC Framework (FECFRAME) <xref targe
t="RFC6363" />. This naming scheme is simple and can support the delivery of NC
packets with exactly the same operations in the PIT/CS as those for the content
objects.<!--Since such a naming way enables consumer to specify coded packets to
receive, it could shift the generation of the coding vector from the content pr
oducer onto the content requester (described in <xref target="Consumer" />).--><
/t>
<t>If a content-naming schema such as the one presented above is used, an
interest requesting an NC packet may have the full name including a generation
ID and coding vector (/CCNx.com/video-A/g-id/1000) or only the name prefix inclu
ding only a generation ID (/CCNx.com/video-A/g-id). In the former case, exact na
me matching to the PIT is simply performed at data forwarders (as in CCNx/NDN).
The consumer is able to specify and retrieve an innovative packet necessary for
the consumer to decode successfully. This could shift the generation of the codi
ng vector from the data forwarder onto the consumer.</t>
<t>In the latter case, partial name matching is required at the data forw
arders. As the interest with only the prefix name matches any NC packet with the
same prefix, the consumer could immediately obtain an NC packet from a nearby C
S (in-network cache) without knowing the coding vectors of the cached NC packets
in advance. In the case wherein NC packets in transit are modified by in-networ
k re-coding performed at forwarders, the consumer could also receive the modifie
d NC packets. However, in contrast to the former case, the consumer may fail to
obtain sufficient degrees of freedom (see <xref target="Router" />). To address
this issue, a new TLV type in an interest message may be required for specifying
further coding information in order to limit the NC packets to be received. For
instance, this is enabled by specifying the coding vectors of innovative packet
s for the consumer (also called decoding matrix) as in <xref target="Montpetit12
" />. This extension may incur an interest packet of significantly increased siz
e, and it may thus be useful to use compression techniques for coding vectors <x
ref target="Thomos12" /> <xref target="Lucani14" />. Without such coding informa
tion provided by the interest, the forwarder would be required to maintain some
records regarding the interest packets that were satisfied previously (See <xref
target="Router" />).</t>
</section>
<section title="Non-Unique Naming for NC Packets">
<t>An NC packet may have a name that indicates that it is an NC packet,
and move the coding information into a metadata field in the payload (i.e., the
name includes the data type, source or repair packet). This would not be benefic
ial for applications or services that may not need to understand the packet payl
oad. Owing to the possibility that multiple NC packets may have the same name, s
ome mechanism is required for the consumer to obtain innovative packets. As desc
ribed in <xref target="Cache" />, a mechanism for managing the multiple innovati
ve packets in the CS would also be required. In addition, extra computational ov
erhead would be incurred when the payload is being encrypted.</t>
</section>
</section>
<!-- ========================================================== -->
<section anchor="Trans" title="Transport">
<t>The pull-based request-response feature of CCNx/NDN is a fundamental p
rinciple of its transport layer; one interest retrieves at most one data packet.
This means that a forwarder or producer cannot inject unrequested data packets
on its own initiative. It is believed that it is important that this rule not be
violated, as 1) it would open denial-of-service (DoS) attacks, 2) it invalidate
s existing congestion control approaches following this rule, and 3) it would re
duce the efficiency of existing consumer mobility approaches. Thus, the followin
g basic operation should be considered for applying NC to CCNx/NDN. Nevertheless
, such security considerations must be addressed if this rule were to be violate
d.</t>
<!--
<t>The pull-based request-response feature of CCNx/NDN is a fundamental p
rinciple of its transport layer; one interest retrieves at most one data packet.
It is believed that it is important that this rule not be violated, as it would
open denial-of-service (DoS) attacks, and thus, the following basic operation s
hould be considered for applying NC to CCNx/NDN. Nevertheless, such security con
siderations must be addressed if this rule were to be violated.</t>
<section title="Scope of NC">
<t>An open question is whether data forwarder can perform in-network re-
coding with data packets that are being received in transit, or if only the data
that matches an interest can be subject to NC operations. In the latter case, e
ncoding or re-coding is performed to generate the NC packet at any forwarder tha
t is able to respond to the interest. This could occur when each NC packet has a
unique name and interest has the full name. On the other hand, if interest has
a partial name without any coding vector information or multiple NC packets have
the same name, the former case may occur; re-coding occurs anywhere in the netw
ork where it is possible to modify the received NC packet and forward it. As CCN
x/NDN comprises mechanisms for ensuring the integrity of the data during transfe
r, in-network re-coding introduces complexities in the network that needs consid
eration for the integrity mechanisms to still work. Similarly, in-network cachin
g of NC packets at forwarders may be valuable; however, the forwarders would req
uire some mechanisms to validate the NC packets (see <xref target="Security" />)
.</t>
</section>
<section anchor= "Consumer" title="Consumer Operation">
<t>To obtain NC benefits (possibly associated with in-network caching), t
he consumer is required to issue interests that direct the forwarder (or produce
r) to respond with innovative packets if available. In the case where each NC pa
cket may have a unique name (as described in <xref target="Naming" />), by issui
ng an interest specifying a unique name with g-id and the coding vector for an N
C packet, the consumer could appropriately receive an innovative packet if it is
available at some forwarders.</t>
<t>In order to specify the exact name of the NC packet to be retrieved, t
he consumer is required to know the valid naming scheme. From a practical viewpo
int, it is desirable for the consumer application to automatically construct the
right name components without depending on any application specifications. To t
his end, the consumer application may retrieve and refer to a manifest <xref tar
get="CCNxSema" /> that enumerates the content objects including NC packets, or m
ay use some coding scheme specifier as a name component to construct the name co
mponents of interests to request innovative packets.</t>
<!--
<t>To obtain NC benefits (possibly associated with in-network caching), t
he consumer is required to issue interests that direct the forwarder (or produce
r) to respond with innovative packets if available. When issuing an interest spe
cifying a unique name with g-id and the coding vector for a coded packet, the co
nsumer could appropriately receive an innovative packet if it is available at so
me forwarders. However, the consumer is required to know the naming structure in
order to specify the exact name of the coded packet to be retrieved. In this en
d-to-end coding case, if the consumer wants to adjust some coding parameters at
the producer, some specific scheme would be required to be used.</t>
<t>Conversely, the consumer without decoding capability (e.g., specific s
ensor node) may want to receive only the source packets. As described in <xref t
arget="Naming" />, because the NC packet can have a name that is explicitly diff
erent from source packets, issuing interests for retrieving source packets is po
ssible.</t>
<!--
<t>Conversely, the consumer without decoding capability (e.g., specific s
ensor node) may want to receive only the source packets. As described in <xref t
arget="Naming" />, because the coded packet can have a name that is explicitly d
ifferent from source packets, issuing interests for retrieving source packets is
possible. In NDN, if the interest has only the name prefix, as in the case of /
NDN.com/file-A, without any selectors, a forwarder may return a matching coded p
acket.</t>
</section>
<section anchor="Router" title="Forwarder Operation">
<t>If the forwarder constantly responds to the incoming interests by retu
rning non-innovative packets, the consumer(s) cannot decode and obtain the sourc
e packets. This issue could happen when 1) incoming interests for NC packets do
not specify some coding parameters such as the coding vectors to be used, and 2)
the forwarder does not have a sufficient number of linearly independent NC pack
ets (possibly in the CS) to use for re-coding. In this case, the forwarder is re
quired to determine whether or not it can generate innovative packets to be forw
arded to the interface(s) at which the interests arrived. An approach to deal wi
th this issue is that the forwarder maintains a tally of the interests for a spe
cific name, generation ID and the incoming interface(s), in order to record how
many degrees of freedom have already been provided <xref target="Saltarin16" />.
As such a scheme requires state management (and potentially timers) in forwarde
rs, scalability and practicality must be considered. In addition, some transport
mechanism for in-network loss detection and recovery <xref target="Matsuzono17"
/> <xref target="Carofiglio16" /> at forwarder as well as a consumer-driven mec
hanism could be indispensable for enabling fast loss recovery and realising NC g
ains. If a forwarder cannot either return a matching innovative packet from its
local content store, nor produce on-the-fly a recoded packet that is innovative,
it is important that the forwarder not simply return a non-innovative packet bu
t instead do a forwarding lookup in its FIB and forward the interest toward the
producer or upstream forwarder that can provide an innovative packet. In this co
ntext, to retrieve innovative packet effectively and quickly, an appropriate set
ting of the FIB and efficient interest forwarding strategies should also be cons
idered.</t>
<t>In another possible case, when receiving interests only for source pac
kets, the forwarder may attempt to decode and obtain all the source packets and
store them (if the full cache capacity are available), thus enabling a faster re
sponse to subsequent interests. As re-coding or decoding results in an extra com
putational overhead, the forwarder is required to determine how to respond to re
ceived interests according to the use case (e.g., a delay-sensitive or delay-tol
erant application) and the forwarder situation, such as available cache space an
d computational capability.</t>
</section>
<section title="Producer Operation">
<t>Before performing NC for specified content in CCNx/NDN, the producer i
s responsible for splitting the overall content into small content objects to av
oid packet fragmentation that could cause unnecessary packet processing and degr
aded throughput. The size of the content objects should be within the allowable
packet size in order to avoid packet fragmentation in CCNx/NDN network. The prod
ucer performs the encoding operation for a set of the small content objects, and
the naming process for the NC packets.</t>
<!--
<t>If the producer takes the lead in determining the used coding vectors
and generating the coding packets, there exist two possible end-to-end coding ca
ses; 1) consumers obtain the names of the coded packets through a certain mechan
ism, and send the corresponding interests toward the producer to obtain the code
d packets that have already been generated at the producer; and 2) the producer
determines the coding vectors after receiving the interests specifying them. In
the former case, although the consumers cannot flexibly specify a coding vector
for generating the coded packet to obtain, the latency for obtaining the coded p
acket can be reduced as compared that in the latter case wherein additional NC o
perations are required to be performed after receiving the interests. The common
benefit in such end-to-end coding cases is that if the producer adds a signatur
e on the coded packets, data validation becomes possible throughout as in the ca
se of normal CCNx/NDN operations. According to the application requirement for l
atency, such an NC operation strategy should be considered.</t>
-->
<t>If the producer takes the lead in determining what coding vectors to u
se in generating the NC packets, there are three general strategies for naming a
nd producing the NC packets:</t>
<t><list style="numbers">
<t>consumers themselves understand in detail the naming conventions used
for NC packets and thereby can send the corresponding interests toward the produ
cer to obtain NC packets whose coding parameters have already been determined by
the producer.</t>
<t>the producer determines the coding vectors and generates the NC packet
s after receiving interests specifying the packets the consumer wished to receiv
e.</t>
<t>The naming scheme for specifying the coding vectors and corresponding
NC packets is explicitly represented via a "Manifest" (e.g., FLIC <xref target="
Draft-FLIC" />) that can be obtained by the consumer and used to select among th
e available coding vectors and their corresponding packets, and thereby send the
corresponding interests.</t>
</list></t>
<t>In the first case, although the consumers cannot flexibly specify a co
ding vector for generating the NC packet to obtain, the latency for obtaining th
e NC packet is less than in the latter two cases. For the second case, there is
a latency penalty for the additional NC operations performed after receiving the
interests. For the third case, the NC packets to be included in the manifest mu
st be pre-computed by the producer (since the manifest references NC packets by
their hashes,
not their names), but the producer can select which to include the manifest, and
produce multiple manifests either in advance or on demand with different coding
tradeoffs if so desired.</t>
<t>A common benefit the first two approaches to end-to-end coding is that
if the producer adds a signature on the NC packets, data validation becomes pos
sible throughout (as is the case with CCNx/NDN operation in the absence of NC).
The third approach of using a manifest trades off the additional latency incurre
d by the need to fetch the manifest against the efficiency of needing a signatur
e only on the manifest and not on each individual NC packet.</t>
</section>
<section title="Backward Compatibility">
<t>NC operations should be applied in addition to the regular ICN behavio
r, and should function alongside regular ICN operations. Hence, nodes which do n
ot support NC should still be able to properly handle packets, not only in being
able to forward the NC packets, but also to cache these packets. An NC framewor
k should be compatible with a regular framework in order to facilitate backward
compatibility and smooth migration from one framework to the other.</t>
<!-- <t>NC operations should be applied in addition to the regular ICN be
havior, and should function alongside regular ICN operations. Hence, nodes witho
ut supporting network coding should be able to properly handle NC packets (not o
nly in forwarding the packets, but also in the caching mechanism). An NC framewo
rk should be compatible with a regular framework in order to facilitate backward
compatibility and smooth migration from one framework to the other.</t>
-->
<!-- <t>NC operations should be applied in addition to the regular ICN b
ehavior. Hence, nodes should be able to not support network coding (not only in
forwarding the packets, but also in the caching mechanism). NC operations should
function alongside regular ICN operations. An NC framework should be compatible
with a regular framework in order to facilitate backward compatibility and smoo
th migration from one framework to the other.</t> -->
</section>
</section>
<!-- ========================================================== -->
<section anchor="Cache" title="In-network Caching">
<t> Caching is a useful technique used for improving throughput a
nd latency in various applications. In-network caching in CCNx/NDN essentially p
rovides support at network level and is highly beneficial owing to the involved
exploitation of NC for enabling effective multicast transmission <xref target="A
li16" />, multipath data retrieval <xref target="Saltarin16" /> <xref target="Ra
makrishnan12" />, fast loss recovery <xref target="Matsuzono17" />. However, the
re remain several issues to be considered.</t>
<t> There generally exist limitations in the CS capacity, and the
caching policy affects the consumer's performance <xref target="Perino11" /> <x
ref target="Podlipnig03" /> <xref target="Rossini13" />. It is thus crucial for
forwarders to determine which content objects should be cached and which discard
ed. As delay-sensitive applications often do not require an in-network cache for
a long period owing to their real-time constraints, forwarders have to know the
necessity for caching received content objects to save the caching volume. In C
CNx, this could be made possible by setting a Recommended Cache Time (RCT) in th
e optional header of the data packet at the producer side. The RCT serves as a g
uideline for the CS cache in determining how long to retain the content object.
When the RCT is set as zero, the forwarder recognizes that caching the content o
bject is not useful. Conversely, the forwarder may cache it when the RCT has a g
reater value. In NDN, the TLV type of FreshnessPeriod could be used.</t>
<t>One key aspect of in-network caching is whether or not forward
ers can cache NC packets in their CS. They may be caching the NC packets without
having the ability to perform a validation of the content objects. Therefore, t
he caching of the NC packets would require some mechanism to validate the NC pac
kets (see <xref target="Security" />). In the case wherein the NC packets have t
he same name, it would also require some mechanism to identify them.</t>
</section>
<!-- ========================================================== -->
<section anchor="Mobility" title="Seamless Consumer Mobility">
<t>A key feature of CCNx/NDN is that it is sessionless, which enables the
consumer and forwarder to send multiple interests toward different copies of th
e content in parallel, by using multiple interfaces at the same time in an async
hronous manner. Through the multipath data retrieval, the consumer could obtain
the content from multiple copies that are distributed while using the aggregate
capacity of multiple interfaces. For the link between the consumer and the multi
ple copies, the consumer can perform a certain rate adaptation mechanism for vid
eo streaming <xref target="Ramakrishnan12" /> or congestion control for content
acquisition <xref target="acm-mpath-cc" />.</t>
<t> NC adds a reliability layer to CCNx in a distributed and asynchronous
manner, because NC provides a mechanism for ensuring that the interests sent to
multiple copies of the content in parallel retrieve innovative packets, even in
the case of packet losses on some of the paths/networks to these copies. This a
pplies to consumer mobility events <xref target="Ramakrishnan12" />, wherein the
consumer could receive additional degrees of freedom with any innovative packet
if at least one available interface exists during the mobility event. An intere
st forwarding strategy at the consumer (and possibly forwarder) for efficiently
obtaining innovative packets would be required for the consumer to achieve seaml
ess consumer mobility.</t>
<!--
<t> NC adds a reliability layer to CCNx in a distributed and asynchronous
manner, because NC provides a mechanism for ensuring that the interests sent to
multiple copies of the content in parallel retrieve innovative packets, even in
the case of packet losses on some of the paths/networks to these copies. This a
pplies to consumer mobility events <xref target="Ramakrishnan12" />, wherein the
consumer may connect between multiple access points (APs) before a consumer mob
ility event (make-before-break handoff). In the case of such a consumer mobility
event, the consumer is first connected to the previous AP, then to both the pre
vious and next APs, and then finally only to the next APs. With CCNx, the consum
er only sends interests on the available interfaces. By combining NC with CCNx/N
DN, the requesting of coded packets ensures that during the phase wherein it is
connected to the previous and the next APs at the same time, it would not receiv
e duplicate data, but does not miss out any content either. The consumer would r
eceive additional degrees of freedom with any innovative packet it receives on e
ither interface. From this perspective, an interest forwarding strategy at the c
onsumer (and possibly forwarder) for efficiently obtaining innovative packets sh
ould be considered for the consumer to achieve seamless consumer mobility.</t>
</section>
</section> </section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --> <section anchor="TecCons" numbered="true" toc="default">
<name>Technical Considerations</name>
<t>This section presents the considerations for CCNx/NDN with NC in terms
of network architecture and protocol. This document focuses on NC when employed
in a block coding manner.</t>
<section title="Challenges"> <section anchor="Naming" numbered="true" toc="default">
<name>Content Naming</name>
<t>Naming content objects is as important for CCNx/NDN as naming hosts is
in the current-day Internet <xref target="RFC7927" format="default"/>. In this s
ection, two possible naming schemes are presented.</t>
<t>This section presents several primary challenges and research items to be <section numbered="true" toc="default">
considered when applying NC in CCNx/NDN.</t> <name>Unique Naming for NC Packets</name>
<t>Each source and repair packet (hereinafter referred to as NC packet
) may have a unique name, as each original content object has in CCNx/NDN and as
PIT and CS operations typically require a unique name for identifying the NC pa
cket. As a method of naming an NC packet that takes into account the feature of
block coding, the coding vector and the generation ID can be used as a part of t
he content object name. As in <xref target="Saltarin16" format="default"/>, when
the generation ID is "g-id", generation size is 4, and coding vector is (1,0,0,
0), the name could be /CCNx.com/video-A/g-id/1000. Some other identifiers and/or
parameters related to the encoding scheme can also be used as name components.
For instance, the encoding ID specifying the coding scheme may be used with "enc
&nbhy;id", such as /CCNx.com/video-A/enc-id/g-id/1000, as defined in the FEC Fra
mework (FECFRAME) <xref target="RFC6363" format="default"/>. This naming scheme
is simple and can support the delivery of NC packets with exactly the same opera
tions in the PIT/CS as those for the content objects.
</t>
<t>If a content-naming schema, such as the one presented above, is use
d, an interest requesting an NC packet may have the full name including a genera
tion ID and coding vector (/CCNx.com/video-A/g-id/1000) or only the name prefix
including only a generation ID (/CCNx.com/video-A/g-id). In the former case, exa
ct name matching to the PIT is simply performed at data forwarders (as in CCNx/N
DN). The consumer is able to specify and retrieve an innovative packet necessary
for the consumer to decode successfully. This could shift the generation of the
coding vector from the data forwarder onto the consumer.</t>
<t>In the latter case, partial name matching is required at the data f
orwarders. As the interest with only the prefix name matches any NC packet with
the same prefix, the consumer could immediately obtain an NC packet from a nearb
y CS (in-network cache) without knowing the coding vectors of the cached NC pack
ets in advance. In the case wherein NC packets in transit are modified by in-net
work recoding performed at forwarders, the consumer could also receive the modif
ied NC packets. However, in contrast to the former case, the consumer may fail t
o obtain sufficient degrees of freedom (see <xref target="Router" format="defaul
t"/>). To address this issue, a new TLV type in an interest message may be requi
red for specifying further coding information in order to limit the NC packets t
o be received. For instance, this is enabled by specifying the coding vectors of
innovative packets for the consumer (also called decoding matrix) as in <xref t
arget="Montpetit12" format="default"/>. This extension may incur an interest pac
ket of significantly increased size, and it may thus be useful to use compressio
n techniques for coding vectors <xref target="Thomos12" format="default"/> <xref
target="Lucani14" format="default"/>. Without such coding information provided
by the interest, the forwarder would be required to maintain some records regard
ing the interest packets that were satisfied previously (see <xref target="Route
r" format="default"/>).</t>
</section>
<section numbered="true" toc="default">
<name>Nonunique Naming for NC Packets</name>
<t>An NC packet may have a name that indicates that it is an NC packet
and move the coding information into a metadata field in the payload (i.e., the
name includes the data type, source, or repair packet). This would not be benef
icial for applications or services that may not need to understand the packet pa
yload. Owing to the possibility that multiple NC packets may have the same name,
some mechanism is required for the consumer to obtain innovative packets. As de
scribed in <xref target="Cache" format="default"/>, a mechanism for managing the
multiple innovative packets in the CS would also be required. In addition, extr
a computational overhead would be incurred when the payload is being encrypted.<
/t>
</section>
</section>
<section anchor="Trans" numbered="true" toc="default">
<name>Transport</name>
<t>The pull-based request-response feature of CCNx/NDN is a fundamental
principle of its transport layer; one interest retrieves, at most, one data pack
et. This means that a forwarder or producer cannot inject unrequested data packe
ts on its own initiative. It is believed that it is important that this rule not
be violated, as 1) it would open denial-of-service (DoS) attacks, 2) it invalid
ates existing congestion control approaches following this rule, and 3) it would
reduce the efficiency of existing consumer mobility approaches. Thus, the follo
wing basic operation should be considered for applying NC to CCNx/NDN. Neverthel
ess, such security considerations must be addressed if this rule were to be viol
ated.</t>
<!-- ========================================================== --> <section numbered="true" toc="default">
<section title="Adoption of Convolutional Coding"> <name>Scope of NC</name>
<t>Several block coding approaches have been proposed thus far; however, <t>An open question is whether a data forwarder can perform in-network
there is still not sufficient discussion and application of the convolutional c recoding with data packets that are being received in transit or if only the da
oding approach (e.g., sliding or elastic window coding) in CCNx/NDN. Convolution ta that matches an interest can be subject to NC operations. In the latter case,
al coding is often appropriate for situations wherein a fully or partially relia encoding or recoding is performed to generate the NC packet at any forwarder th
ble delivery of continuous data flows is required, and especially when these dat at is able to respond to the interest. This could occur when each NC packet has
a flows feature realtime constraints. As in <xref target="Pierre11" />, on an en a unique name and interest has the full name. On the other hand, if interest has
d-to-end coding basis, it would be advantageous for continuous content flow to a a partial name without any coding vector information or multiple NC packets hav
dopt sliding window coding in CCNx/NDN. In this case, the producer is required t e the same name, the former case may occur; recoding occurs anywhere in the netw
o appropriately set coding parameters and let the consumer know the information, ork where it is possible to modify the received NC packet and forward it. As CCN
and the consumer is required to send interests augmented with feedback informat x/NDN comprises mechanisms for ensuring the integrity of the data during transfe
ion regarding the data reception and/or decoding status. As CCNx/NDN utilises ho r, in-network recoding introduces complexities in the network that needs conside
p-by-hop forwarding state, it would be worth discussing and investigating how co ration for the integrity mechanisms to still work. Similarly, in-network caching
nvolutional coding can be applied in a hop-by-hop manner and what benefits might of NC packets at forwarders may be valuable; however, the forwarders would requ
accrue. In particular, in the case wherein in-network re-coding could occur at ire some mechanisms to validate the NC packets (see <xref target="Security" form
forwarders, both the encoding window and CS management would be required, and th at="default"/>).</t>
e corresponding feasibility and practicality should be considered.</t> </section>
</section> <section anchor="Consumer" numbered="true" toc="default">
<name>Consumer Operation</name>
<t>To obtain NC benefits (possibly associated with in-network caching)
, the consumer is required to issue interests that direct the forwarder (or prod
ucer) to respond with innovative packets if available. In the case where each NC
packet may have a unique name (as described in <xref target="Naming" format="de
fault"/>), by issuing an interest specifying a unique name with g-id and the cod
ing vector for an NC packet, the consumer could appropriately receive an innovat
ive packet if it is available at some forwarders.</t>
<t>In order to specify the exact name of the NC packet to be retrieved
, the consumer is required to know the valid naming scheme. From a practical vie
wpoint, it is desirable for the consumer application to automatically construct
the right name components without depending on any application specifications. T
o this end, the consumer application may retrieve and refer to a manifest <xref
target="RFC8569" format="default"/> that enumerates the content objects, includi
ng NC packets, or may use some coding scheme specifier as a name component to co
nstruct the name components of interests to request innovative packets.</t>
<t>Conversely, the consumer without decoding capability (e.g., specifi
c sensor node) may want to receive only the source packets. As described in <xre
f target="Naming" format="default"/>, because the NC packet can have a name that
is explicitly different from source packets, issuing interests for retrieving s
ource packets is possible.</t>
<!-- ========================================================== --> </section>
<section title="Rate and Congestion Control"> <section anchor="Router" numbered="true" toc="default">
<t>The addition of redundancy using repair packets may result in further <name>Forwarder Operation</name>
network congestion and could adversely affect the overall throughput. In particu <t>If the forwarder constantly responds to the incoming interests by r
lar, in a situation wherein fair bandwidth sharing is more desirable, each strea eturning non-innovative packets, the consumer(s) cannot decode and obtain the so
ming flow must adapt to the network conditions to fairly consume the available l urce packets. This issue could happen when 1) incoming interests for NC packets
ink bandwidth. It is thus necessary that each content flow cooperatively impleme do not specify some coding parameters, such as the coding vectors to be used, an
nt congestion control to adjust the consumed bandwidth <xref target="Draft-NWC-C d 2) the forwarder does not have a sufficient number of linearly independent NC
C" />. From this perspective, an effective deployment approach (e.g., a forwarde packets (possibly in the CS) to use for recoding. In this case, the forwarder is
r-supported approach that can provide benefits under partial deployment) is requ required to determine whether or not it can generate innovative packets to be f
ired.</t> orwarded to the interface(s) at which the interests arrived. An approach to deal
with this issue is that the forwarder maintains a tally of the interests for a
specific name, generation ID, and the incoming interface(s) in order to record h
ow many degrees of freedom have already been provided <xref target="Saltarin16"
format="default"/>. As such a scheme requires state management (and potentially
timers) in forwarders, scalability and practicality must be considered. In addit
ion, some transport mechanism for in-network loss detection and recovery <xref t
arget="Carofiglio16" format="default"/><xref target="Matsuzono17" format="defaul
t"/> at a forwarder, as well as a consumer-driven mechanism, could be indispensa
ble for enabling fast loss recovery and realizing NC gains. If a forwarder canno
t either return a matching innovative packet from its local content store, nor p
roduce on the fly a recoded packet that is innovative, it is important that the
forwarder not simply return a non-innovative packet but instead do a forwarding
lookup in its FIB and forward the interest toward the producer or upstream forwa
rder that can provide an innovative packet. In this context, to retrieve an inno
vative packet effectively and quickly, an appropriate setting of the FIB and eff
icient interest-forwarding strategies should also be considered.</t>
<t>In another possible case, when receiving interests only for source
packets, the forwarder may attempt to decode and obtain all the source packets a
nd store them (if the full cache capacity are available), thus enabling a faster
response to subsequent interests. As recoding or decoding results in an extra c
omputational overhead, the forwarder is required to determine how to respond to
received interests according to the use case (e.g., a delay-sensitive or delay-t
olerant application) and the forwarder situation, such as available cache space
and computational capability.</t>
</section>
<section numbered="true" toc="default">
<name>Producer Operation</name>
<t>Before performing NC for specified content in CCNx/NDN, the produce
r is responsible for splitting the overall content into small content objects to
avoid packet fragmentation that could cause unnecessary packet processing and d
egraded throughput. The size of the content objects should be within the allowab
le packet size in order to avoid packet fragmentation in a CCNx/NDN network. The
producer performs the encoding operation for a set of the small content objects
and the naming process for the NC packets.</t>
<t>If the producer takes the lead in determining what coding vectors t
o use in generating the NC packets, there are three general strategies for namin
g and producing the NC packets:</t>
<ol spacing="normal" type="1">
<li>Consumers themselves understand in detail the naming conventions u
sed for NC packets and thereby can send the corresponding interests toward the p
roducer to obtain NC packets whose coding parameters have already been determine
d by the producer.</li>
<li>The producer determines the coding vectors and generates the NC pa
ckets after receiving interests specifying the packets the consumer wished to re
ceive.</li>
<li>The naming scheme for specifying the coding vectors and correspond
ing NC packets is explicitly represented via a "Manifest" (e.g., FLIC <xref targ
et="I-D.irtf-icnrg-flic" format="default"/>) that can be obtained by the consume
r and used to select among the available coding vectors and their corresponding
packets and thereby send the corresponding interests.</li>
</ol>
<t>In the first case, although the consumers cannot flexibly specify a
coding vector for generating the NC packet to obtain, the latency for obtaining
the NC packet is less than in the latter two cases. For the second case, there
is a latency penalty for the additional NC operations performed after receiving
the interests. For the third case, the NC packets to be included in the manifest
must be pre-computed by the producer (since the manifest references NC packets
by their hashes,
not their names), but the producer can select which to include in the manifest a
nd produce multiple manifests either in advance or on demand with different codi
ng tradeoffs, if so desired.</t>
<t>A common benefit of the first two approaches to end-to-end coding i
s that, if the producer adds a signature on the NC packets, data validation beco
mes possible throughout (as is the case with the CCNx/NDN operation in the absen
ce of NC). The third approach of using a manifest trades off the additional late
ncy incurred by the need to fetch the manifest against the efficiency of needing
a signature only on the manifest and not on each individual NC packet.</t>
</section>
<section numbered="true" toc="default">
<name>Backward Compatibility</name>
<t>NC operations should be applied in addition to the regular ICN behavi
or and should function alongside regular ICN operations. Hence, nodes that do no
t support NC should still be able to properly handle packets, not only in being
able to forward the NC packets but also to cache these packets. An NC framework
should be compatible with a regular framework in order to facilitate backward co
mpatibility and smooth migration from one framework to the other.</t>
</section>
</section>
<!-- From this perspective, although a forwarder-supported approach would <section anchor="Cache" numbered="true" toc="default">
be effective, an effective deployment approach that provides benefits under par <name>In-Network Caching</name>
tial deployment is required.</t> --> <t> Caching is a useful technique used for improving throughput and late
ncy in various applications. In-network caching in CCNx/NDN essentially provides
support at the network level and is highly beneficial, owing to the involved ex
ploitation of NC for enabling effective multicast transmission <xref target="Ali
16" format="default"/>, multipath data retrieval <xref target="Saltarin16" forma
t="default"/> <xref target="Ramakrishnan12" format="default"/>, and fast loss re
covery <xref target="Matsuzono17" format="default"/>. However, there remain seve
ral issues to be considered.</t>
<t> There generally exist limitations in the CS capacity, and the cachin
g policy affects the consumer's performance <xref target="Perino11" format="defa
ult"/> <xref target="Podlipnig03" format="default"/> <xref target="Rossini13" fo
rmat="default"/>. It is thus crucial for forwarders to determine which content o
bjects should be cached and which discarded. As delay-sensitive applications oft
en do not require an in-network cache for a long period, owing to their real-tim
e constraints, forwarders have to know the necessity for caching received conten
t objects to save the caching volume. In CCNx, this could be made possible by se
tting a Recommended Cache Time (RCT) in the optional header of the data packet a
t the producer side. The RCT serves as a guideline for the CS cache in determini
ng how long to retain the content object. When the RCT is set as zero, the forwa
rder recognizes that caching the content object is not useful. Conversely, the f
orwarder may cache it when the RCT has a greater value. In NDN, the TLV type of
FreshnessPeriod could be used.</t>
<t>One key aspect of in-network caching is whether or not forwarders can
cache NC packets in their CS. They may be caching the NC packets without having
the ability to perform a validation of the content objects. Therefore, the cach
ing of the NC packets would require some mechanism to validate the NC packets (s
ee <xref target="Security" format="default"/>). In the case wherein the NC packe
ts have the same name, it would also require some mechanism to identify them.</t
>
</section>
<t>As described in <xref target="Mobility" />, NC can contribute to seaml <section anchor="Mobility" numbered="true" toc="default">
ess consumer mobility by obtaining innovative packets without receiving duplicat <name>Seamless Consumer Mobility</name>
ed packets through multipath data retrieval, and avoiding duplicated packets has <t>A key feature of CCNx/NDN is that it is sessionless, which enables th
congestion control benefits as well. It can be challenging to develop an effect e consumer and forwarder to send multiple interests toward different copies of t
ive rate and congestion control mechanism in order to achieve seamless consumer he content in parallel, by using multiple interfaces at the same time in an asyn
mobility while improving the overall throughput or latency by fully exploiting N chronous manner. Through the multipath data retrieval, the consumer could obtain
C operations.</t> the content from multiple copies that are distributed while using the aggregate
<!-- <t>As described in <xref target="Mobility" />, NC can contribute to capacity of multiple interfaces. For the link between the consumer and the mult
seamless consumer mobility by obtaining innovative packets without receiving dup iple copies, the consumer can perform a certain rate adaptation mechanism for vi
licated packets through multipath data retrieval. It can be challenging to devel deo streaming <xref target="Ramakrishnan12" format="default"/> or congestion con
op an effective rate and congestion control mechanism in order to achieve seamle trol for content acquisition <xref target="acm-mpath-cc" format="default"/>.</t>
ss consumer mobility while improving the overall throughput or latency by fully <t> NC adds a reliability layer to CCNx in a distributed and asynchronou
exploiting NC operations.</t> --> s manner, because NC provides a mechanism for ensuring that the interests sent t
o multiple copies of the content in parallel retrieve innovative packets, even i
n the case of packet losses on some of the paths/networks to these copies. This
applies to consumer mobility events <xref target="Ramakrishnan12" format="defaul
t"/>, wherein the consumer could receive additional degrees of freedom with any
innovative packet if at least one available interface exists during the mobility
event. An interest-forwarding strategy at the consumer (and possibly forwarder)
for efficiently obtaining innovative packets would be required for the consumer
to achieve seamless consumer mobility.</t>
</section>
</section>
<section numbered="true" toc="default">
<name>Challenges</name>
<t>This section presents several primary challenges and research items to
be considered when applying NC in CCNx/NDN.</t>
<section numbered="true" toc="default">
<name>Adoption of Convolutional Coding</name>
<t>Several block coding approaches have been proposed thus far; however, t
here is still not sufficient discussion and application of the convolutional cod
ing approach (e.g., sliding or elastic window coding) in CCNx/NDN. Convolutional
coding is often appropriate for situations wherein a fully or partially reliabl
e delivery of continuous data flows is required and especially when these data f
lows feature real-time constraints. As in <xref target="Pierre11" format="defaul
t"/>, on an end-to-end coding basis, it would be advantageous for continuous con
tent flow to adopt sliding window coding in CCNx/NDN. In this case, the producer
is required to appropriately set coding parameters and let the consumer know th
e information, and the consumer is required to send interests augmented with fee
dback information regarding the data reception and/or decoding status. As CCNx/N
DN utilizes the hop-by-hop forwarding state, it would be worth discussing and in
vestigating how convolutional coding can be applied in a hop-by-hop manner and w
hat benefits might accrue. In particular, in the case wherein in-network recodin
g could occur at forwarders, both the encoding window and CS management would be
required, and the corresponding feasibility and practicality should be consider
ed.</t>
</section>
<section numbered="true" toc="default">
<name>Rate and Congestion Control</name>
<t>The addition of redundancy using repair packets may result in further n
etwork congestion and could adversely affect the overall throughput. In particul
ar, in a situation wherein fair bandwidth sharing is more desirable, each stream
ing flow must adapt to the network conditions to fairly consume the available li
nk bandwidth. It is thus necessary that each content flow cooperatively implemen
t congestion control to adjust the consumed bandwidth <xref target="RFC9265" for
mat="default"/>. From this perspective, an effective deployment approach (e.g.,
a forwarder-supported approach that can provide benefits under partial deploymen
t) is required.</t>
<t>As described in <xref target="Mobility" format="default"/>, NC can
contribute to seamless consumer mobility by obtaining innovative packets withou
t receiving duplicated packets through multipath data retrieval, and avoiding du
plicated packets has congestion control benefits as well. It can be challenging
to develop an effective rate and congestion control mechanism in order to achiev
e seamless consumer mobility while improving the overall throughput or latency b
y fully exploiting NC operations.</t>
</section> </section>
<section numbered="true" toc="default">
<!-- ========================================================== --> <name>Security</name>
<section title="Security"> <t>While CCNx/NDN introduces new security issues at the networking layer t
hat are different from the IP network, such as a cache poisoning, pollution atta
<t>While CCNx/NDN introduces new security issues at the networking layer cks, and a DoS attack using interest packets, some security approaches are alrea
that are different from the IP network, such as a cache poisoning and pollution dy provided <xref target="RFC7927" format="default"/> <xref target="RFC7945" for
attacks, a DoS attack using interest packets, some security approaches are alrea mat="default"/>. The application of NC in CCNx/NDN brings two potential security
dy provided <xref target="RFC7927" /> <xref target="RFC7945" />. The application aspects that need to be dealt with.</t>
of NC in CCNx/NDN brings two potential security aspects that need to be dealt w <t>The first is in-network recoding at forwarders. Some mechanism for ensu
ith.</t> ring the integrity of the NC packets newly produced by in-network recoding is re
quired in order for consumers or other forwarders to receive valid NC packets. T
<t>The first is in-network re-coding at forwarders. Some mechanism for en o this end, there are some possible approaches described in <xref target="Securi
suring the integrity of the NC packets newly produced by in-network re-coding is ty" format="default"/>, but there may be a more effective method with lower comp
required in order for consumers or other forwarders to receive valid NC packets lexity and computation overhead.</t>
. To this end, there are some possible approaches described in <xref target="Sec <t>The second is that attackers maliciously request and inject NC packets,
urity" />, but there may be more effective method with lower complexity and comp which could amplify some attacks. As NC packets are unpopular in general use, t
utation overhead.</t> hey could be targeted by a cache pollution attack that requests less popular con
tent objects more frequently to undermine popularity-based caching by skewing th
<t>The second is that attackers maliciously request and inject NC packets e content popularity. Such an attack needs to be dealt with in order to maintain
, which could amplify some attacks. the in-network cache efficiency. By injecting invalid NC packets with the goal
As NC packets are unpopular in general use, they could be targeted by a cache po of filling the CSs at the forwarders with them, the cache poisoning attack could
llution attack that requests less popular content objects more frequently to und be effectual depending on the exact integrity coverage on NC packets. On the as
ermine popularity-based caching by skewing the content popularity. Such an attac sumption that each NC packet has the valid signature, the straightforward approa
k needs to be dealt with in order to maintain the in-network cache efficiency. ch would comprise the forwarders verifying the signature within the NC packets i
By injecting invalid NC packets with the goal of filling the CSs at the forwarde n transit and only transmitting and storing the validated NC packets. However, a
rs with them, the cache poisoning attack could be effectual depending on the exa s performing a signature verification by the forwarders may be infeasible at lin
ct integrity coverage on NC packets. e speed, some mechanisms should be considered for distributing and reducing the
On the assumption that each NC packet has the valid signature, the straightforwa load of signature verification in order to maintain in-network cache benefits, s
rd approach would comprise the forwarders verifying the signature within the NC uch as latency and network-load reduction.
packets in transit and only transmitting and storing the validated NC packets. H </t>
owever, as performing a signature verification by the forwarders may be infeasib
le at line speed, some mechanisms should be considered for distributing and redu
cing the load of signature verification, in order to maintain in-network cache b
enefits such as latency and network-load reduction.
<!-- Furthermore, denial of service (DoS) attacks with the goal of imposing a hi
gher computation load owing to the NC operations at forwarders and/or the produc
er should be effectively detected and dealt with.--> <!--Denial of Service (DoS)
attacks may also target the routers and/or the publisher performing NC in order
to impose a higher computation load owing to the NC operations. --></t>
<!--
<t>While CCNx/NDN introduces new security issues at the networking layer
that are different from the IP network, such as a cache poisoning and pollution
attacks, a DoS attack using interest packets, some security approaches are alrea
dy provided <xref target="RFC7927" /> <xref target="RFC7945" />. The application
of NC in CCNx/NDN has various impacts on the security mechanisms of CCNx/NDN.</
t>
<t>CCNx/NDN is designed to detect modification of the data packets; the d
ata packet for a specific name can be self-authenticated, can be validated on th
e delivery path, and may also be cached at untrusted forwarders. NC may bring up
a security issue related to data integrity when performing in-network re-coding
, as attackers could inject invalid data packets, and fill the CSs at the forwar
ders with the invalid content objects (cache poisoning attack). On the assumptio
n that each coded packet has the valid signature, the straightforward approach w
ould comprise the forwarders verifying the signature within the coded packets in
transit and only transmitting and storing the validated coded packets. However,
as performing a signature verification by the forwarders may be infeasible at l
ine speed, some mechanisms should be considered for distributing and reducing th
e load of signature verification, in order to maintain in-network cache benefits
such as latency and network-load reduction. </t>
<t>In addition, to maintain the in-network cache efficiency, forwarders w
ith CS should take caution when caching validated coded packets. As coded packet
s are unpopular in general use, they could be targeted by a cache pollution atta
ck that requests less popular content objects more frequently to undermine popul
arity-based caching by skewing the content popularity. Denial of Service (DoS) a
ttacks may also target the forwarders and/or the producer performing NC in order
to impose a higher computation load owing to the NC operations. NC also offers
a new surface of attack; if the coding vector is exposed at the network layer, i
t would have to be protected (and validated) in order to prevent modifications b
y an attacker (and allow for verification) on the path of the packet.</t>
<t>On the other hand, NC could be used to mitigate privacy issues CCNx/ND
N introduces. For instance, assuming that consumers can use multipath data retri
eval and caching in CCNx/NDN with NC, cache privacy and anonymity set for consum
ers can be improved in addition to caching performance owing to the diversity of
the caching content objects along different paths <xref target="Wu16" />.</t>
<t>In this context, it can be a challenge that coping with the security i
ssues as low computation overhead as possible while facilitating the NC operatio
ns in CCNx/NDN. From the perspective of both feasibility and practicability, mor
e effective approaches with consideration of security would be required in order
to accelerate the deployment of CCNx/NDN with NC.</t>
</section> </section>
<section numbered="true" toc="default">
<!-- ========================================================== --> <name>Routing Scalability</name>
<section title="Routing Scalability"> <t>In CCNx/NDN, a name-based routing protocol without a resolution process
streamlines the routing process and reduces the overall latency. In IP routing,
<t>In CCNx/NDN, a name-based routing protocol without a resolutio the growth in the routing table size has become a concern. It is thus necessary
n process streamlines the routing process and reduces the overall latency. In IP to use a hierarchical naming scheme in order to improve the routing scalability
routing, the growth in the routing table size has become a concern. It is thus by enabling the aggregation of the routing information.</t>
necessary to use a hierarchical naming scheme in order to improve the routing sc <t>To realize the benefits of NC, consumers need to efficiently obtain inn
alability by enabling the aggregation of the routing information.</t> ovative packets using multipath retrieval mechanisms of CCNx/NDN. This would req
<t>To realize the benefits of NC, consumers need to efficiently o uire some efficient routing mechanism to appropriately set the FIB and also an e
btain innovative packets using multipath retrieval mechanisms of CCNx/NDN. This fficient interest-forwarding strategy. Such routing coordination may create rout
would require some efficient routing mechanism to appropriately set the FIB and ing scalability issues. It would be challenging to achieve effective and scalabl
also an efficient interest forwarding strategy. Such routing coordination may cr e routing for interests requesting NC packets, as well as to simplify the routin
eate routing scalability issues. It would be challenging to achieve effective an g process.</t>
d scalable routing for interests requesting NC packets as well as to simplify th </section>
e routing process.</t>
<!-- <t>In CCNx/NDN, a name-based routing protocol without a resolution
process streamlines the routing process and reduces the overall latency. In IP r
outing, the growth in the routing table size has become a concern. It is thus ne
cessary to use a hierarchical naming scheme in order to improve the routing scal
ability by enabling the aggregation of the routing information. It is a challeng
e to enable consumers to efficiently obtain innovative packets using multipath r
etrieval in a fully distributed manner, and thus fully leverage NWC in CCNx/NDN
to improve throughput or reduce latency. This would require some efficient routi
ng mechanism to appropriately set the FIB and also an efficient interest forward
ing strategy. Such routing coordination may create routing scalability issues. F
rom another NWC perspective, as described in <xref target="Consumer" />, when is
suing interests while specifying unique names for each coded packet, the consume
rs are required to know in advance how to specify the names of the coded packet
through some specific name-resolution scheme, and it may be necessary for router
s to appropriately set the FIBs. In this context, it would be challenging to ach
ieve effective and scalable routing for interests requesting coded packets as we
ll as to simplify the routing process.</t> -->
</section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
</section> </section>
<section anchor="Security" title="Security Considerations">
<t>In-network re-coding is a distinguishing feature of NC. Only valid NC
packets produced by in-network re-coding must be requested and utilized (and pos
sibly stored). To this end, there exist some possible approaches. First, as a si
gnature verification approach, the exploitation of multi-signature capability co
uld be applied. This allows not only the original content producer but also some
forwarders responsible for in-network re-coding to have their own unique signin
g key. Each forwarder of the group signs newly generated NC packet in order for
other nodes to be able to validate the data with the signature. The CS may verif
y the signature within the NC packet before storing it to avoid invalid data cac
hing. Second, as a consumer-dependent approach, the consumer puts a restriction
on the matching rule using only the name of the requested data. The interest amb
iguity can be clarified by specifying both the name and the key identifier (the
producer's public key digest) used for matching to the requested data. This KeyI
d restriction is built in the CCNx design <xref target="CCNxSema" />. Only the r
equested data packet satisfying the interest with the KeyId restriction would be
forwarded and stored in the CS, thus resulting in a reduction in the chances of
cache poisoning. Moreover, in the CCNx design, there exists the rule that the C
S obeys in order to avoid amplifying invalid data; if an interest has a KeyID re
striction, the CS must not reply unless it knows that the signature on the match
ing content object is correct. If the CS cannot verify the signature, the intere
st may be treated as a cache miss and forwarded to the upstream forwarder(s). Th
ird, as a certificate chain management approach (possibly without certificate au
thority), some mechanism such as <xref target="RiHopAuth" /> could be used to es
tablish a trustworthy data delivery path. This approach adopts the hop-by-hop au
thentication mechanism, wherein forwarding-integrated hop-by-hop certificate col
lection is performed to provide suspension certificate chains such that the data
retrieval is trustworthy.</t>
<!-- data integrity, cache poisoning
<t>In-network re-coding is a distinguishing feature of NC; however, it ma
y lead to cache poisoning attacks that inject invalid coded packets to the netwo
rk. To address this issue, there exist some possible approaches. First, as a sig
nature verification approach, the exploitation of multi-signature capability cou
ld be applied. This allows not only the original content producer but also some
forwarders responsible for in-network re-coding to have their own unique signing
key. Each forwarder of the group signs newly generated coded packet in order fo
r other nodes to be able to validate the data with the signature. The CS may ver
ify the signature within the coded packet before storing it to avoid invalid dat
a caching. Second, as a consumer-dependent approach, the consumer puts a restric
tion on the matching rule using only the name of the requested data. The interes
t ambiguity can be clarified by specifying both the name and the key identifier
(the producer's public key digest) used for matching to the requested data. This
KeyId restriction is built in the CCNx design <xref target="CCNxSema" />. Only
the requested data packet satisfying the interest with the KeyId restriction wou
ld be forwarded and stored in the CS, thus resulting in a reduction in the chanc
es of cache poisoning. Moreover, in the CCNx design, there exists the rule that
the CS obeys in order to avoid amplifying invalid data; if an interest has a Key
ID restriction, the CS must not reply unless it knows that the signature on the
matching content object is correct. If the CS cannot verify the signature, the i
nterest may be treated as a cache miss and forwarded to the upstream forwarder(s
). Third, as a certificate chain management approach (possibly without certifica
te authority), some mechanism such as <xref target="RiHopAuth" /> could be used
to establish a trustworthy data delivery path. This approach adopts the hop-by-h
op authentication mechanism, wherein forwarding-integrated hop-by-hop certificat
e collection is performed to provide suspension certificate chains such that the
data retrieval is trustworthy.</t>
<!-- cache pollution attack -->
<t>Depending on the adopted caching strategy such as cache replacement po
licies, forwarders should also take caution when storing and retaining the NC pa
ckets in the CS as they could be targeted by cache pollution attacks. In order t
o mitigate the cache pollution attacks' impact, forwarders should check the cont
ent request frequencies to detect the attack and may limit requests by ignoring
some of the consecutive requests. The forwarders can then decide to apply or cha
nge to the other cache replacement mechanism.</t>
<!-- DoS Attack -->
<t>The forwarders or producers require careful attention to the DoS attac
ks aiming at provoking the high load of NC operations by using the interests for
NC packets. In order to mitigate such attacks, the forwarders could adopt a rat
e-limiting approach. For instance, they could monitor the PIT size growth for NC
packets per content to detect the attacks, and limit the interest arrival rate
when necessary. If the NC application wishes to secure an interest (considered a
s the NC actuator) in order to prevent such attacks, the application should cons
ider using an encrypted wrapper and an explicit protocol.
</t>
<section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section> </section>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --> <section anchor="Security" numbered="true" toc="default">
<section title="Acknowledgements"> <name>Security Considerations</name>
<t>The authors would like to thank ICNRG and NWCRG members, especially Ma <t>In-network recoding is a distinguishing feature of NC. Only valid NC pa
rie-Jose Montpetit, David Oran, Vincent Roca, and Thierry Turletti, for their va ckets produced by in-network recoding must be requested and utilized (and possib
luable comments and suggestions on this document.</t> ly stored). To this end, there exist some possible approaches. First, as a signa
ture verification approach, the exploitation of multi-signature capability could
be applied. This allows not only the original content producer but also some fo
rwarders responsible for in-network recoding to have their own unique signing ke
y. Each forwarder of the group signs a newly generated NC packet in order for ot
her nodes to be able to validate the data with the signature. The CS may verify
the signature within the NC packet before storing it to avoid invalid data cachi
ng. Second, as a consumer-dependent approach, the consumer puts a restriction on
the matching rule using only the name of the requested data. The interest ambig
uity can be clarified by specifying both the name and the key identifier (the pr
oducer's public key digest) used for matching to the requested data. This KeyId
restriction is built in the CCNx design <xref target="RFC8569" format="default"/
>. Only the requested data packet satisfying the interest with the KeyId restric
tion would be forwarded and stored in the CS, thus resulting in a reduction in t
he chances of cache poisoning. Moreover, in the CCNx design, there exists the ru
le that the CS obeys in order to avoid amplifying invalid data; if an interest h
as a KeyId restriction, the CS must not reply unless it knows that the signature
on the matching content object is correct. If the CS cannot verify the signatur
e, the interest may be treated as a cache miss and forwarded to the upstream for
warder(s). Third, as a certificate chain management approach (possibly without c
ertificate authority), some mechanism, such as <xref target="RiHopAuth" format="
default"/>, could be used to establish a trustworthy data delivery path. This ap
proach adopts the hop-by-hop authentication mechanism, wherein the forwarding-in
tegrated hop-by-hop certificate collection is performed to provide suspension ce
rtificate chains such that the data retrieval is trustworthy.</t>
<t>Depending on the adopted caching strategy, such as cache replacement po
licies, forwarders should also take caution when storing and retaining the NC pa
ckets in the CS, as they could be targeted by cache pollution attacks. In order
to mitigate the cache pollution attacks' impact, forwarders should check the con
tent request frequencies to detect the attack and may limit requests by ignoring
some of the consecutive requests. The forwarders can then decide to apply or ch
ange to the other cache replacement mechanism.</t>
<t>The forwarders or producers require careful attention to the DoS attack
s aimed at provoking the high load of NC operations by using the interests for N
C packets. In order to mitigate such attacks, the forwarders could adopt a rate-
limiting approach. For instance, they could monitor the PIT size growth for NC p
ackets per content to detect the attacks and limit the interest arrival rate whe
n necessary. If the NC application wishes to secure an interest (considered as t
he NC actuator) in order to prevent such attacks, the application should conside
r using an encrypted wrapper and an explicit protocol.
</t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split into informative and normative --> <references>
<name>Informative References</name>
<!-- There are 2 ways to insert reference entries from the citation libraries <reference anchor="Jacobson09">
: <front>
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here ( <title>Networking Named Content</title>
as shown) <author initials="V" surname="Jacobson" fullname="Van Jacobson"/>
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml <author initials="D" surname="Smetters" fullname="Diana K. Smetters"/>
"?> here <author initials="J" surname="Thornton" fullname="James D. Thornton"/>
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x <author initials="M" surname="Plass" fullname="Michael F. Plass"/>
ml") <author initials="N" surname="Briggs" fullname="Nicholas H. Briggs"/>
<author initials="R" surname="Braynard" fullname="Rebecca L. Braynard"/>
Both are cited textually in the same manner: by using xref elements. <date month="December" year="2009"/>
If you use the PI option, xml2rfc will, by default, try to find included fil </front>
es in the same <refcontent>Proc. CoNEXT, ACM</refcontent>
directory as the including file. You can also define the XML_LIBRARY environ <seriesInfo name="DOI" value="10.1145/1658939.1658941"/>
ment variable </reference>
with a value containing a set of directories to search. These can be either
in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<!--
<references title="Normative References"> -->
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml"?-->
<!-- &RFC2119; -->
<!--
</references> -->
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<!-- A reference written by by an organization not a person. -->
<reference anchor="CCNxSema" target="https://tools.ietf.org/html/rfc8569
">
<front>
<title>Content-Centric Networking (CCNx) Semantics</title>
<author initials="M" surname="Mosko"/>
<author initials="" surname="et al."/>
<date month="July" year="2019"/>
</front>
<seriesInfo name="RFC" value="8569"/>
</reference>
<reference anchor="Gkantsidis06">
<front>
<title>Cooperative Security for Network Coding File Distribution</title
>
<author initials="C" surname="Gkantsidis"/>
<author initials="P. R." surname="Rodriguez"/>
<date month="April" year="2006"/>
</front>
<seriesInfo name="Proc. Infocom," value="IEEE"/>
</reference>
<reference anchor="Cai02">
<front>
<title>Secure network coding</title>
<author initials="N" surname="Cai"/>
<author initials="R. W" surname="Yeung"/>
<date month="June" year="2002"/>
</front>
<seriesInfo name="Proc. International Symposium on Information Theory (IS
IT)," value="IEEE"/>
</reference>
<reference anchor="Lima10">
<front>
<title>Secure Network Coding for Multi-Resolution Wireless Video Stream
ing</title>
<author initials="L" surname="Lima"/>
<author initials="S" surname="Gheorghiu"/>
<author initials="J" surname="Barros"/>
<author initials="M" surname="Medard"/>
<author initials="A. T." surname="Toledo"/>
<date month="April" year="2010"/>
</front>
<seriesInfo name="IEEE Journal of Selected Area (JSAC)," value="vol. 28,
no. 3" />
</reference>
<reference anchor="Vilela08">
<front>
<title>Lightweight security for network coding</title>
<author initials="J.P." surname="Vilea"/>
<author initials="L" surname="Lima"/>
<author initials="J" surname="Barros"/>
<date month="May" year="2008"/>
</front>
<seriesInfo name="Proc. ICC," value="IEEE"/>
</reference>
<reference anchor="Dimarkis10">
<front>
<title>Network Coding for Distributed Storage Systems</title>
<author initials="A" surname="Dimarkis"/>
<author initials="P" surname="Godfrey"/>
<author initials="Y" surname="Wu"/>
<author initials="M" surname="Wainwright"/>
<author initials="K" surname="Ramchandran"/>
<date month="September" year="2010"/>
</front>
<seriesInfo name="IEEE Trans. Information Theory," value="vol. 56, no.9"/
>
</reference>
<reference anchor="Gkantsidis05">
<front>
<title>Network coding for large scale content distribution</title>
<author initials="C" surname="Gkantsidis"/>
<author initials="P" surname="Rodriguez"/>
<date month="March" year="2005"/>
</front>
<seriesInfo name="Proc. Infocom," value="IEEE"/>
</reference>
<reference anchor="Seferoglu07">
<front>
<title>Opportunistic Network Coding for Video Streaming over Wireless</
title>
<author initials="H" surname="Seferoglu"/>
<author initials="A" surname="Markopoulou"/>
<date month="November" year="2007"/>
</front>
<seriesInfo name="Proc. Packet Video Workshop (PV)," value="IEEE"/>
</reference>
<reference anchor="Montpetit12">
<front>
<title>Network Coding Meets Information-Centric Networking: An Architec
tural Case for Information Dispersion Through Native Network Coding</title>
<author initials="M.J." surname="Montpetit"/>
<author initials="C" surname="Westphal"/>
<author initials="D" surname="Trossen"/>
<date month="June" year="2012"/>
</front>
<seriesInfo name="Proc. Workshop on Emerging Name-Oriented Mobile Network
ing Design (NoM)," value="ACM"/>
</reference>
<reference anchor="Saltarin16">
<front>
<title>NetCodCCN: a network coding approach for content-centric network
s</title>
<author initials="J" surname="Saltarin"/>
<author initials="E" surname="Bourtsoulatze"/>
<author initials="N" surname="Thomos"/>
<author initials="T" surname="Braun"/>
<date month="April" year="2016"/>
</front>
<seriesInfo name="Proc. Infocom," value="IEEE"/>
</reference>
<reference anchor="Ramakrishnan12">
<front>
<title>Adaptive Video Streaming over CCN with Network Coding for Seamle
ss Mobility</title>
<author initials="A" surname="Ramakrishnan"/>
<author initials="C" surname="Westphal"/>
<author initials="J" surname="Saltarin"/>
<date month="December" year="2016"/>
</front>
<seriesInfo name="Proc. International Symposium on Multimedia (ISM)," val
ue="IEEE"/>
</reference>
<reference anchor="acm-mpath-cc"> <reference anchor="Zhang14">
<front> <front>
<title>MIRCC: Multipath-aware ICN Rate-based Congestion Control</title> <title>Named data networking</title>
<author initials="M" surname="Mahdian"/> <author initials="L" surname="Zhang" fullname="Lixia Zhang"/>
<author initials="S" surname="Arianfar"/> <author initials="A" surname="Afanasyev" fullname="Alexander Afanasyev"/>
<author initials="J" surname="Gibson"/> <author initials="J" surname="Burke" fullname="Jeffrey Burke"/>
<author initials="D" surname="Oran"/> <author initials="V" surname="Jacobson" fullname="Van Jacobson"/>
<date month="September" year="2016"/> <author initials="K" surname="Claffy" fullname="KC Claffy"/>
</front> <author initials="P" surname="Crowley" fullname="Patrick Crowley"/>
<seriesInfo name="Proc. Conference on Information-Centric Networking (ICN <author initials="C" surname="Papadopoulos" fullname="Christos Papadopoulos
)," value="ACM"/> "/>
</reference> <author initials="L" surname="Wang" fullname="Lan Wang"/>
<author initials="B" surname="Zhang" fullname="Beichuan Zhang"/>
<date month="July" year="2014"/>
</front>
<refcontent>ACM SIGCOMM Computer Communication Review, vol. 44, no. 3</refcon
tent>
<seriesInfo name="DOI" value="10.1145/2656877.2656887"/>
</reference>
<reference anchor="Wang14"> <reference anchor="Gkantsidis06">
<front> <front>
<title>An Optimal Cache Management Framework for Information-Centric Ne <title>Cooperative Security for Network Coding File Distribution</titl
tworks with Network Coding</title> e>
<author initials="J" surname="Wang"/> <author initials="C" surname="Gkantsidis" fullname="Christos Gkantsidi
<author initials="J" surname="Ren"/> s"/>
<author initials="K" surname="Lu"/> <author initials="P" surname="Rodriguez" fullname="P. Rodriguez Rodrig
<author initials="J" surname="Wang"/> uez"/>
<author initials="S" surname="Liu"/> <date month="April" year="2006"/>
<author initials="C" surname="Westphal"/> </front>
<date month="June" year="2014"/> <refcontent>Proc. Infocom, IEEE</refcontent>
</front> <seriesInfo name="DOI" value="10.1109/INFOCOM.2006.233"/>
<seriesInfo name="Proc. Networking Conference," value="IFIP/IEEE"/> </reference>
</reference>
<reference anchor="Wang16"> <reference anchor="Cai02">
<front> <front>
<title>A Minimum Cost Cache Management Framework for Information-Centri <title>Secure network coding</title>
c Networks with Network Coding</title> <author initials="N" surname="Cai" fullname="Ning Cai"/>
<author initials="J" surname="Wang"/> <author initials="R" surname="Yeung" fullname="Raymond W. Yeung"/>
<author initials="J" surname="Ren"/> <date month="June" year="2002"/>
<author initials="K" surname="Lu"/> </front>
<author initials="J" surname="Wang"/> <refcontent>Proc. International Symposium on Information Theory (ISIT),
<author initials="S" surname="Liu"/> IEEE</refcontent>
<author initials="C" surname="Westphal"/> <seriesInfo name="DOI" value="10.1109/ISIT.2002.1023595"/>
<date month="August" year="2016"/> </reference>
</front>
<seriesInfo name="Computer Networks," value="Elsevier"/>
</reference>
<reference anchor="Matsuzono17"> <reference anchor="Lima10">
<front> <front>
<title>Low Latency Low Loss Streaming using In-Network Coding and Cachi <title>Secure Network Coding for Multi-Resolution Wireless Video Strea
ng</title> ming</title>
<author initials="K" surname="Matsuzono"/> <author initials="L" surname="Lima" fullname="Luisa Lima"/>
<author initials="H" surname="Asaeda"/> <author initials="S" surname="Gheorghiu" fullname="Steluta Gheorghiu"/
<author initials="T" surname="Turletti"/> >
<date month="May" year="2017"/> <author initials="J" surname="Barros" fullname="Joao Barros"/>
</front> <author initials="M" surname="Medard" fullname="Muriel Medard"/>
<seriesInfo name="Proc. Infocom," value="IEEE"/> <author initials="A" surname="Toledo" fullname="Alberto Lopez Toledo"/
</reference> >
<date month="April" year="2010"/>
</front>
<refcontent>IEEE Journal of Selected Area (JSAC), vol. 28, no. 3</refcon
tent>
<seriesInfo name="DOI" value="10.1109/JSAC.2010.100409"/>
</reference>
<reference anchor="Jacobson09"> <reference anchor="Vilela08">
<front> <front>
<title>Networking Named Content</title> <title>Lightweight security for network coding</title>
<author initials="V" surname="Jacobson"/> <author initials="J" surname="Vilea" fullname="Joao P. Vilela"/>
<author initials="D.K." surname="Smetters"/> <author initials="L" surname="Lima" fullname="Luisa Lima"/>
<author initials="J.D" surname="Thornton"/> <author initials="J" surname="Barros" fullname="Joao Barros"/>
<author initials="M.F" surname="Plass"/> <date month="May" year="2008"/>
<author initials="N.H." surname="Briggs"/> </front>
<author initials="R.L." surname="Braynard"/> <refcontent>Proc. ICC, IEEE</refcontent>
<date month="December" year="2009"/> <seriesInfo name="DOI" value="10.48550/arXiv.0807.0610"/>
</front> </reference>
<seriesInfo name="Proc. CoNEXT," value="ACM"/>
</reference>
<reference anchor="CCNxTerm" target="https://tools.ietf.org/html/rfc8793"> <reference anchor="Koetter03">
<front> <front>
<title>Information-Centric Networking (ICN): Content-Centric Networking <title>An Algebraic Approach to Network Coding</title>
(CCNx) and Named Data Networking (NDN) Terminology</title> <author initials="R" surname="Koetter" fullname="Ralf Koetter"/>
<author initials="B" surname="Wissingh"/> <author initials="M" surname="Medard" fullname="Muriel Medard"/>
<author initials="" surname="et al."/> <date month="October" year="2003"/>
<date month="June" year="2020"/> </front>
</front> <refcontent>IEEE/ACM Transactions on Networking, vol. 11, no. 5</refcon
<seriesInfo name="RFC" value="8793"/> tent>
</reference> <seriesInfo name="DOI" value="10.1109/TNET.2003.818197"/>
</reference>
<reference anchor="CCNxMsg" target="https://tools.ietf.org/html/rfc8609"> <reference anchor="Vyetrenko09">
<front> <front>
<title>Content-Centric Networking (CCNx) Messages in TLV Format</title> <title>Rate regions for coherent and noncoherent multisource network
<author initials="M" surname="Mosko"/> error correction</title>
<author initials="" surname="et al."/> <author initials="S" surname="Vyetrenko" fullname="Svitlana Vyetrenko
<date month="July" year="2019"/> "/>
</front> <author initials="T" surname="Ho" fullname="Tracey Ho"/>
<seriesInfo name="RFC" value="8609"/> <author initials="M" surname="Effros" fullname="Michelle Effros"/>
</reference> <author initials="J" surname="Kliewer" fullname="Joerg Kliewer"/>
<author initials="E" surname="Erez" fullname="Elona Erez"/>
<date month="June" year="2009"/>
</front>
<refcontent>Proc. International Symposium on Information Theory (ISIT),
IEEE</refcontent>
<seriesInfo name="DOI" value="10.1109/ISIT.2009.5206077"/>
</reference>
<reference anchor="Zhang14"> <reference anchor="Wu04">
<front> <front>
<title>Named data networking</title> <title>A comparison of network coding and tree packing</title>
<author initials="L" surname="Zhang"/> <author initials="Y" surname="Wu" fullname="Yunnan Wu"/>
<author initials="A" surname="Afanasyev"/> <author initials="P" surname="Chou" fullname="Philip A. Chou"/>
<author initials="J" surname="Burke"/> <author initials="K" surname="Jain" fullname="Kamal Jain"/>
<author initials="V" surname="Jacobson"/> <date month="June" year="2004"/>
<author initials="K" surname="Claffy"/> </front>
<author initials="P" surname="Crowley"/> <refcontent>Proc. International Symposium on Information Theory (ISIT),
<author initials="C" surname="Papadopoulos"/> IEEE</refcontent>
<author initials="L" surname="Wang"/> <seriesInfo name="DOI" value="10.1109/ISIT.2004.1365182"/>
<author initials="B" surname="Zhang"/> </reference>
<date month="July" year="2014"/>
</front>
<seriesInfo name="ACM Comput. Commun. Rev.," value="vol. 44, no. 3"/>
</reference>
<!-- <reference anchor="Ho06">
<reference anchor="NDNPacket" target="https://named-data.net/doc/NDN-packet <front>
-spec/current/"> <title>A Random Linear Network Coding Approach to Multicast</title>
<front> <author initials="T" surname="Ho" fullname="Tracey Ho"/>
<title>NDN Packet Format Specification 0.3 documentation</title> <author initials="M" surname="Medard" fullname="Muriel Medard"/>
<author initials="" surname="NDN Packet Format"/> <author initials="R" surname="Koetter" fullname="Ralf Koetter"/>
<date month="Sept." year="2019"/> <author initials="D" surname="Karger" fullname="David Karger"/>
</front> <author initials="M" surname="Effros" fullname="Michelle Effros"/>
</reference> <author initials="J" surname="Shi" fullname="Jun Shi"/>
<author initials="B" surname="Leong" fullname="Ben Leong"/>
<date month="October" year="2006"/>
</front>
<refcontent>IEEE Trans. on Information Theory, vol. 52, no. 10</refcont
ent>
<seriesInfo name="DOI" value="10.1109/TIT.2006.881746"/>
</reference>
<reference anchor="Koetter03"> <reference anchor="Dimarkis10">
<front> <front>
<title>An Algebraic Approach to Network Coding</title> <title>Network Coding for Distributed Storage Systems</title>
<author initials="R" surname="Koetter"/> <author initials="A" surname="Dimarkis" fullname="Alexandros G. Dimaki
<author initials="M" surname="Medard"/> s"/>
<date month="Oct." year="2003"/> <author initials="P" surname="Godfrey" fullname="P. Brighten Godfrey"/
</front> >
<seriesInfo name="IEEE/ACM Trans. on Networking," value="vol. 11, no 5"/> <author initials="Y" surname="Wu" fullname="Yunnan Wu"/>
</reference> <author initials="M" surname="Wainwright" fullname="Martin J. Wainwrig
ht"/>
<author initials="K" surname="Ramchandran" fullname="Kannan Ramchandra
n"/>
<date month="September" year="2010"/>
</front>
<refcontent>IEEE Trans. Information Theory, vol. 56, no.9</refcontent>
<seriesInfo name="DOI" value="10.1109/TIT.2010.2054295"/>
</reference>
<reference anchor="I-D.irtf-nwcrg-network-coding-taxonomy" target="https:// <reference anchor="Gkantsidis05">
tools.ietf.org/html/rfc8406"> <front>
<front> <title>Network coding for large scale content distribution</title>
<title>Taxonomy of Coding Techniques for Efficient Network Communicatio <author initials="C" surname="Gkantsidis" fullname="Christos Gkantsidi
ns</title> s"/>
<author initials="B" surname="Adamson"/> <author initials="P" surname="Rodriguez" fullname="Pablo Rodriguez"/>
<author initials="" surname="et al."/> <date month="March" year="2005"/>
<date month="June" year="2018"/> </front>
</front> <refcontent>Proc. Infocom, IEEE</refcontent>
<seriesInfo name="RFC" value="8406"/> <seriesInfo name="DOI" value="10.1109/INFCOM.2005.1498511"/>
</reference> </reference>
<reference anchor="Draft-NWC-CC"> <reference anchor="Seferoglu07">
<front> <front>
<title>Coding and Congestion Control in Transport</title> <title>Opportunistic Network Coding for Video Streaming over Wireless<
<author initials="N" surname="Kuhn"/> /title>
<author initials="E" surname="Lochin"/> <author initials="H" surname="Seferoglu" fullname="Hulya Seferoglu"/>
<author initials="F" surname="Michel"/> <author initials="A" surname="Markopoulou" fullname="Athina Markopoulo
<author initials="M" surname="Welzl"/> u"/>
<date month="June" year="2021"/> <date month="November" year="2007"/>
</front> </front>
<seriesInfo name="Work in Progress," value="draft-irtf-nwcrg-coding-and-c <refcontent>Proc. Packet Video Workshop (PV), IEEE</refcontent>
ongestion-09"/> <seriesInfo name="DOI" value="10.1109/PACKET.2007.4397041"/>
</reference> </reference>
<reference anchor="Draft-FLIC"> <reference anchor="Montpetit12">
<front> <front>
<title>File-Like ICN Collections (FLIC)</title> <title>Network Coding Meets Information-Centric Networking: An Archite
<author initials="C" surname="Tschudin"/> ctural Case for Information Dispersion Through Native Network Coding</title>
<author initials="C" surname="Wood"/> <author initials="M" surname="Montpetit" fullname="Marie-Jose Montpeti
<author initials="M" surname="Mosko"/> t"/>
<author initials="D" surname="Oran"/> <author initials="C" surname="Westphal" fullname="Cedric Westphal"/>
<date month="Nov." year="2021"/> <author initials="D" surname="Trossen" fullname="Dirk Trossen"/>
</front> <date month="June" year="2012"/>
<seriesInfo name="Work in Progress," value="draft-irtf-icnrg-flic-03"/> </front>
</reference> <refcontent>Proc. Workshop on Emerging Name-Oriented Mobile Networking D
esign (NoM), ACM</refcontent>
<seriesInfo name="DOI" value="10.1145/2248361.2248370"/>
</reference>
<reference anchor="RFC7927"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.840
<front> 6.xml"/>
<title> Information-Centric Networking (ICN) Research Challenges</title <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.879
> 3.xml"/>
<author initials="D" surname="Kutscher"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.856
<author initials="" surname="et al."/> 9.xml"/>
<date month="July" year="2016"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.860
</front> 9.xml"/>
<seriesInfo name="RFC" value="7927"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.792
</reference> 7.xml"/>
<reference anchor="RFC7945"> <reference anchor="Wu16">
<front> <front>
<title> Information-Centric Networking: Evaluation and Security Conside <title>Privacy-Aware Multipath Video Caching for Content-Centric Netwo
rations</title> rks</title>
<author initials="K" surname="Pentikousis"/> <author initials="Q" surname="Wu" fullname="Qinghua Wu"/>
<author initials="" surname="et al."/> <author initials="Z" surname="Li" fullname="Zhenyu Li"/>
<date month="July" year="2019"/> <author initials="G" surname="Tyson" fullname="Gareth Tyson"/>
</front> <author initials="S" surname="Uhlig" fullname="Steve Uhlig"/>
<seriesInfo name="RFC" value="7945"/> <author initials="M" surname="Kaafar" fullname="Mohamed Ali Kaafar"/>
</reference> <author initials="G" surname="Xie" fullname="Gaogang Xie"/>
<date month="June" year="2016"/>
</front>
<refcontent>IEEE Journal on Selected Areas in Communications (JSAC), vol
. 38, no. 8</refcontent>
<seriesInfo name="DOI" value="10.1109/JSAC.2016.2577321"/>
</reference>
<reference anchor="RFC6363"> <reference anchor="Saltarin16">
<front> <front>
<title> Forward Error Correction (FEC) Framework</title> <title>NetCodCCN: a network coding approach for content-centric networ
<author initials="M" surname="Watson"/> ks</title>
<author initials="" surname="et al."/> <author initials="J" surname="Saltarin" fullname="Jonnahtan Saltarin"/
<date month="Oct." year="2011"/> >
</front> <author initials="E" surname="Bourtsoulatze" fullname="Eirina Bourtsou
<seriesInfo name="RFC" value="6363"/> latze"/>
</reference> <author initials="N" surname="Thomos" fullname="Nikolaos Thomos"/>
<author initials="T" surname="Braun" fullname="Torsten Braun"/>
<date month="April" year="2016"/>
</front>
<refcontent>Proc. Infocom, IEEE</refcontent>
<seriesInfo name="DOI" value="10.1109/INFOCOM.2016.7524382"/>
</reference>
<reference anchor="Thomos12"> <reference anchor="Wang14">
<front> <front>
<title>Toward one Symbol Network Coding Vectors</title> <title>An Optimal Cache Management Framework for Information-Centric N
<author initials="N" surname="Thomos"/> etworks with Network Coding</title>
<author initials="P" surname="Frossard"/> <author initials="J" surname="Wang" fullname="Jin Wang"/>
<date month="November" year="2012"/> <author initials="J" surname="Ren" fullname="Jing Ren"/>
</front> <author initials="K" surname="Lu" fullname="Kejie Lu"/>
<seriesInfo name="IEEE Communications letters," value="vol. 16, no. 11"/> <author initials="J" surname="Wang" fullname="Jianping Wang"/>
</reference> <author initials="S" surname="Liu" fullname="Shucheng Liu"/>
<author initials="C" surname="Westphal" fullname="Cedric Westphal"/>
<date month="June" year="2014"/>
</front>
<refcontent>Proc. Networking Conference, IFIP/IEEE</refcontent>
<seriesInfo name="DOI" value="10.1109/IFIPNetworking.2014.6857127"/>
</reference>
<reference anchor="Lucani14"> <reference anchor="Wang16">
<front> <front>
<title>Fulcrum Network Codes: A Code for Fluid Allocation of Complexity <title>A Minimum Cost Cache Management Framework for Information-Centr
</title> ic Networks with Network Coding</title>
<author initials="D.E" surname="Lucani"/> <author initials="J" surname="Wang" fullname="Jin Wang"/>
<author initials="M.V." surname="Pedersen"/> <author initials="J" surname="Ren" fullname="Jing Ren"/>
<author initials="J" surname="Heide"/> <author initials="K" surname="Lu" fullname="Kejie Lu"/>
<author initials="F.H.P" surname="Fitzek"/> <author initials="J" surname="Wang" fullname="Jianping Wang"/>
<date month="April" year="2014"/> <author initials="S" surname="Liu" fullname="Shucheng Liu"/>
</front> <author initials="C" surname="Westphal" fullname="Cedric Westphal"/>
<seriesInfo name="" value="available at http://arxiv.org/abs/1404.6620"/> <date month="August" year="2016"/>
</reference> </front>
<refcontent>Computer Networks, Elsevier</refcontent>
<seriesInfo name="DOI" value="10.1016/j.comnet.2016.08.004"/>
</reference>
<reference anchor="Perino11"> <reference anchor="Ramakrishnan12">
<front> <front>
<title>A reality check for content centric networking</title> <title>Adaptive Video Streaming over CCN with Network Coding for Seaml
<author initials="D" surname="Perino"/> ess Mobility</title>
<author initials="M" surname="Varvello"/> <author initials="A" surname="Ramakrishnan" fullname="Abinesh Ramakris
<date month="August" year="2011"/> hnan"/>
</front> <author initials="C" surname="Westphal" fullname="Cedric Westphal"/>
<seriesInfo name="Proc. SIGCOMM Workshop on Information-centric networki <author initials="J" surname="Saltarin" fullname="Jonnahtan Saltarin"/
ng (ICN'11)," value="ACM"/> >
</reference> <date month="December" year="2016"/>
</front>
<refcontent>Proc. International Symposium on Multimedia (ISM), IEEE</ref
content>
<seriesInfo name="DOI" value="10.1109/ISM.2016.0054"/>
</reference>
<reference anchor="Wu16"> <reference anchor="Carofiglio16">
<front> <front>
<title>Privacy-Aware Multipath Video Caching for Content-Centric Networ <title>Leveraging ICN In-network Control for Loss Detection and Recov
ks</title> ery in Wireless Mobile networks</title>
<author initials="Q" surname="Wu"/> <author initials="G" surname="Carofiglio" fullname="Giovanna Carofigl
<author initials="Z" surname="Li"/> io"/>
<author initials="G" surname="Tyson"/> <author initials="L" surname="Muscariello" fullname="Luca Muscariello
<author initials="S" surname="Uhlig"/> "/>
<author initials="M.A." surname="Kaafar"/> <author initials="M" surname="Papalini" fullname="Michele Papalini"/>
<author initials="G" surname="Xie"/> <author initials="N" surname="Rozhnova" fullname="Natalya Rozhnova"/>
<date month="June" year="2016"/> <author initials="X" surname="Zeng" fullname="Xuan Zeng"/>
</front> <date month="September" year="2016"/>
<seriesInfo name="IEEE Journal of Selected Area (JSAC)" value="vol. 38, n </front>
o. 8"/> <refcontent>Proc. of the 3rd ACM Conference on Information-Centric Netw
</reference> orking</refcontent>
<seriesInfo name="DOI" value="10.1145/2984356.2984361"/>
</reference>
<reference anchor="RiHopAuth"> <reference anchor="Matsuzono17">
<front> <front>
<title>DCAuth: Data-Centric Authentication for Secure In-Network Big-Da <title>Low Latency Low Loss Streaming using In-Network Coding and Cac
ta Retrieval</title> hing</title>
<author initials="R" surname="Li"/> <author initials="K" surname="Matsuzono" fullname="Kazuhisa Matsuzono
<author initials="H" surname="Asaeda"/> "/>
<author initials="J" surname="Wu"/> <author initials="H" surname="Asaeda" fullname="Hitoshi Asaeda"/>
<date month="September" year="2018"/> <author initials="T" surname="Turletti" fullname="Thierry Turletti"/>
</front> <date month="May" year="2017"/>
<seriesInfo name="IEEE Trans. on Network Science and Engineering" value=" </front>
vol. 7, no. 1" /> <refcontent>Proc. Infocom, IEEE</refcontent>
</reference> <seriesInfo name="DOI" value="10.1109/INFOCOM.2017.8057026"/>
</reference>
<reference anchor="Wu04"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.63
<front> 63.xml"/>
<title>A comparison of network coding and tree packing</title>
<author initials="Y" surname="Wu"/>
<author initials="P.A" surname="Chou"/>
<author initials="K" surname="Jain"/>
<date month="June" year="2004"/>
</front>
<seriesInfo name="Proc. ISIT," value="IEEE"/>
</reference>
<reference anchor="Ho06"> <reference anchor="Thomos12">
<front> <front>
<title>A Random Linear Network Coding Approach to Multicast</title> <title>Toward One Symbol Network Coding Vectors</title>
<author initials="T" surname="Ho"/> <author initials="N" surname="Thomos" fullname="Nikolaos Thomos"/>
<author initials="M" surname="Medard"/> <author initials="P" surname="Frossard" fullname="Pascal Frossard"/>
<author initials="R" surname="Koetter"/> <date month="November" year="2012"/>
<author initials="R" surname="Karger"/>
<author initials="D.R." surname="Effros"/>
<author initials="M" surname="Shi"/>
<author initials="B" surname="Leong"/>
<date month="October" year="2006"/>
</front> </front>
<seriesInfo name="IEEE Trans. Information Theory," value="vol. 52, no.1 <refcontent>IEEE Communications Letters, vol. 16, no. 11</refcontent>
0"/> <seriesInfo name="DOI" value="10.1109/LCOMM.2012.092812.121661"/>
</reference> </reference>
<reference anchor="Podlipnig03"> <reference anchor="Lucani14">
<front> <front>
<title>A Survey of Web Cache Replacement Strategies</title> <title>Fulcrum Network Codes: A Code for Fluid Allocation of Complexi
<author initials="S" surname="Podlipnig"/> ty</title>
<author initials="L.B" surname="Osz"/> <author initials="D" surname="Lucani" fullname="Daniel E. Lucani"/>
<date month="December" year="2003"/> <author initials="M" surname="Pedersen" fullname="Morten V. Pedersen"
</front> />
<seriesInfo name="Proc. ACM Computing Surveys" value="vol. 35, no. 4"/> <author initials="D" surname="Ruano" fullname="Diego Ruano"/>
</reference> <author initials="C" surname="Sørensen" fullname="Chres W. Sørensen"/>
<author initials="J" surname="Heide" fullname="Janus Heide"/>
<author initials="F" surname="Fitzek" fullname="Frank H. P. Fitzek"/>
<author initials="O" surname="Geil" fullname="Olav Geil"/>
<date month="April" year="2014"/>
</front>
<seriesInfo name="DOI" value="10.48550/arXiv.1404.6620"/>
</reference>
<reference anchor="Rossini13"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.i
<front> rtf-icnrg-flic.xml"/>
<title>Evaluating CCN multi-path interest forwarding strategies</title>
<author initials="G" surname="Rossini"/>
<author initials="D" surname="Rossi"/>
<date month="April" year="2013"/>
</front>
<seriesInfo name="Elsevier Computer Communication," value="vol.36, no. 7"
/>
</reference>
<!-- <reference anchor="Ali16">
<reference anchor="Chai12"> <front>
<front> <title>Coding for Caching: Fundamental Limits and Practical Challenge
<title>Cache Less for More in Information-centric Networks</title> s</title>
<author initials="W.K." surname="Chai"/> <author initials="M" surname="Maddah-Ali" fullname="Mohammad Ali Madd
<author initials="D" surname="He"/> ah-Ali"/>
<author initials="I" surname="Psaras"/> <author initials="U" surname="Niesen" fullname="Urs Niesen"/>
<author initials="G" surname="Pavlou"/> <date month="August" year="2016"/>
<date month="April" year="2013"/> </front>
</front> <refcontent>IEEE Communications Magazine, vol. 54, no. 8</refcontent>
<seriesInfo name="Journal Computer Communications," value="vol. 37. no. 7 <seriesInfo name="DOI" value="10.1109/MCOM.2016.7537173"/>
"/> </reference>
</reference> -->
<reference anchor="Carofiglio16"> <reference anchor="Perino11">
<front> <front>
<title>Leveraging ICN In-network Control for Loss Detection and Rec <title>A reality check for content centric networking</title>
overy in Wireless Mobile networks</title> <author initials="D" surname="Perino" fullname="Diego Perino"/>
<author initials="G" surname="Carofiglio"/> <author initials="M" surname="Varvello" fullname="Matteo Varvello"/>
<author initials="L" surname="Muscariello"/> <date month="August" year="2011"/>
<author initials="M" surname="Papalini"/>
<author initials="N" surname="Rozhnova"/>
<author initials="X" surname="Zeng"/>
<date month="September" year="2016"/>
</front> </front>
<seriesInfo name="Proc. ICN" value="ACM"/> <refcontent>Proc. SIGCOMM Workshop on Information-centric networking (I
</reference> CN '11), ACM</refcontent>
<seriesInfo name="DOI" value="10.1145/2018584.2018596"/>
</reference>
<reference anchor="Ali16"> <reference anchor="Podlipnig03">
<front> <front>
<title>Coding for Caching: Fundamental Limits and Practical Challen <title>A Survey of Web Cache Replacement Strategies</title>
ges</title> <author initials="S" surname="Podlipnig" fullname="Stefan Podlipnig"/
<author initials="M" surname="Ali"/> >
<author initials="U" surname="Niesen"/> <author initials="L" surname="Böszörmenyi" fullname="Laszlo Böszörmen
<date month="August" year="2016"/> yi"/>
<date month="December" year="2003"/>
</front> </front>
<seriesInfo name="IEEE Communications Magazine" value="vol. 54, no. 8"/ <refcontent>Proc. ACM Computing Surveys, vol. 35, no. 4</refcontent>
> <seriesInfo name="DOI" value="10.1145/954339.954341"/>
</reference> </reference>
<reference anchor="Koetter08"> <reference anchor="Rossini13">
<front> <front>
<title>An algebraic approach to network coding</title> <title>Evaluating CCN multi-path interest forwarding strategies</titl
<author initials="R" surname="Koetter"/> e>
<author initials="F.R" surname="Kschischang"/> <author initials="G" surname="Rossini" fullname="Giuseppe Rossini"/>
<date month="October" year="2003"/> <author initials="D" surname="Rossi" fullname="Dario Rossi"/>
</front> <date month="April" year="2013"/>
<seriesInfo name="IEEE Trans. Netw." value="vol.11, no.5"/> </front>
</reference> <refcontent>Elsevier Computer Communications, vol. 36, no. 7</refconten
t>
<seriesInfo name="DOI" value="10.1016/j.comcom.2013.01.008"/>
</reference>
<reference anchor="Vyetrenko09"> <reference anchor="acm-mpath-cc">
<front> <front>
<title>Rate regions for coherent and noncoherent multisource network er <title>MIRCC: Multipath-aware ICN Rate-based Congestion Control</title
ror correction</title> >
<author initials="S" surname="Vyetrenko"/> <author initials="M" surname="Mahdian"/>
<author initials="T" surname="Ho"/> <author initials="S" surname="Arianfar"/>
<author initials="M" surname="Effros"/> <author initials="J" surname="Gibson"/>
<author initials="J" surname="Kliewer"/> <author initials="D" surname="Oran"/>
<author initials="E" surname="Erez"/> <date month="September" year="2016"/>
<date month="July" year="2009"/> </front>
</front> <refcontent>Proc. Conference on Information-Centric Networking (ICN), AC
<seriesInfo name="Proc. International Symposium on Information Theory (IS M</refcontent>
IT)," value="IEEE"/> <seriesInfo name="DOI" value="10.1145/2984356.2984365"/>
</reference> </reference>
<reference anchor="Pierre11"> <reference anchor="Pierre11">
<front> <front>
<title>On-the-Fly Erasure Coding for Real-Time Video Applications</titl <title>On-the-Fly Erasure Coding for Real-Time Video Applications</title>
e> <author initials="P" surname="Tournoux" fullname="Pierre Ugo Tournoux"/>
<author initials="P.U" surname="Tournoux"/> <author initials="E" surname="Lochin" fullname="Emmanuel Lochin"/>
<author initials="E" surname="Lochin"/> <author initials="J" surname="Lacan" fullname="Jérôme Lacan"/>
<author initials="J" surname="Lacan"/> <author initials="A" surname="Bouabdallah" fullname="Amine Bouabdallah"/>
<author initials="A" surname="Bouabdallah"/> <author initials="V" surname="Roca" fullname="Vincent Roca"/>
<author initials="V" surname="Roca"/> <date month="August" year="2011"/>
<date month="August" year="2011"/> </front>
</front> <refcontent>IEEE Transactions on Multimedia, vol. 13, no. 4</refcontent>
<seriesInfo name="IEEE Trans. Multimeda" value="vol.13, no.4"/> <seriesInfo name="DOI" value="10.1109/TMM.2011.2126564"/>
</reference> </reference>
</references>
<!-- Change Log <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.926 5.xml"/>
v00 2006-03-15 EBD Initial version <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.794 5.xml"/>
v01 2006-04-03 EBD Moved PI location back to position 1 - <reference anchor="RiHopAuth">
v3.1 of XMLmind is better with them at this location. <front>
v02 2007-03-07 AH removed extraneous nested_list attribute, <title>DCAuth: Data-Centric Authentication for Secure In-Network Big-D
other minor corrections ata Retrieval</title>
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading cap <author initials="R" surname="Li" fullname="Ruidong Li"/>
italization. <author initials="H" surname="Asaeda" fullname="Hitoshi Asaeda"/>
Modified comments around figure to reflect non-implementati <author initials="J" surname="Wu" fullname="Jie Wu"/>
on of <date month="September" year="2018"/>
figure indent control. Put in reference using anchor="DOMI </front>
NATION". <refcontent>IEEE Trans. on Network Science and Engineering, vol. 7, no.
Fixed up the date specification comments to reflect current 1</refcontent>
truth. <seriesInfo name="DOI" value="10.1109/TNSE.2018.2872049"/>
v04 2007-03-09 AH Major changes: shortened discussion of PIs, </reference>
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and
alternative
images. Removed meta-characters from comments (causes probl
ems).
v06 2010-04-01 TT Changed ipr attribute values to latest ones. Changed date </references>
to <section numbered="false" toc="default">
year only, to be consistent with the comments. Updated the <name>Acknowledgments</name>
IANA guidelines reference from the I-D to the finished RFC. <t>The authors would like to thank ICNRG and NWCRG members, especially <co
--> ntact fullname="Marie-Jose Montpetit"/>, <contact fullname="David Oran"/>, <cont
act fullname="Vincent Roca"/>, and <contact fullname="Thierry Turletti "/>, for
their valuable comments and suggestions on this document.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 82 change blocks. 
1755 lines changed or deleted 1172 lines changed or added

This html diff was produced by rfcdiff 1.48.