<?xml version="1.0"encoding="US-ASCII"?> <!-- This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml.resource.org. -->encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[<!-- One method to get references from the online citation libraries. There has to be one entity for each item to be referenced. An alternate method (rfc include) is described in the references. --> <!ENTITY RFC4601 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4601.xml"><!ENTITYRFC6395 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6395.xml">nbsp " "> <!ENTITYRFC5549 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5549.xml">zwsp "​"> <!ENTITYRFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">nbhy "‑"> <!ENTITYRFC2629 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">wj "⁠"> ]><?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 xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IRTF" category="info" consensus="true" 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)" -->number="9273" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="false" sortRefs="true" version="3"> <!--trust200902 --> <!-- ***** FRONT MATTER *****xml2rfc v2v3 conversion 3.13.0 --> <front><!-- The abbreviated title is used in the page header - it is only necessary if the full title is longer than 39 characters --><title abbrev="NC for CCNx/NDN">Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges </title><!-- add 'role="editor"' below for the editors if appropriate --> <!-- Another author who claims to be an editor --><seriesInfo name="RFC" value="9273"/> <author fullname="Kazuhisa Matsuzono" initials="K" surname="Matsuzono"> <organization abbrev="NICT">National Institute of Information and Communications Technology</organization> <address> <postal> <street>4-2-1 Nukui-Kitamachi</street><city>Koganei</city><region>Tokyo</region> <code>184-8795</code> <country>Japan</country> </postal> <email>matsuzono@nict.go.jp</email> </address> </author> <author initials="H" surname="Asaeda" fullname="Hitoshi Asaeda"> <organization abbrev="NICT">National Institute of Information and Communications Technology</organization> <address> <postal> <street>4-2-1 Nukui-Kitamachi</street><city>Koganei</city><region>Tokyo</region> <code>184-8795</code> <country>Japan</country> </postal> <email>asaeda@nict.go.jp</email> </address> </author> <author fullname="Cedric Westphal" initials="C" surname="Westphal"> <organization abbrev="Huawei">Huawei</organization> <address> <postal> <street>2330 Central Expressway</street> <city>Santa Clara</city> <region>California</region> <code>95050</code><country>USA</country><country>United States of America</country> </postal> <email>cedric.westphal@futurewei.com,</email> </address> </author> <date year="2022"/> <!-- If the month and year are both specified and are the current ones, xml2rfc 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 current 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, 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 files in a meta tag but they have no effect on text or nroff output. If you submit your draft to the RFC Editor, the keywords will be usedmonth="August"/> <workgroup>Coding forthe search engine. -->Efficient Network Communications</workgroup> <keyword>ICN</keyword> <keyword>CCNx</keyword> <keyword>NDN</keyword> <keyword>network coding</keyword> <keyword>in-network cache</keyword> <abstract> <t>This document describes the current research outcomes in Network Coding (NC) for Content-Centric Networking (CCNx) / Named Data Networking(NDN),(NDN) and clarifies the technical considerations and potential challenges for applying NC in CCNx/NDN. This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG) and the Information-Centric Networking Research Group (ICNRG).</t> </abstract> </front> <middle><!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --><sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>Information-Centric Networking(ICN)(ICN), in general, and Content-Centric Networking (CCNx) <xref target="Jacobson09"/>format="default"/> or Named Data Networking (NDN) <xref target="Zhang14"/>format="default"/>, in particular, have emerged as a novel communication paradigmadvocatingthat advocates for 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 the heterogenous networks they may be connected to. The CCNx/NDN architecture has introduced innovative ideas and has stimulated research in a variety of areas, such as in-network caching, name-based routing, multipath transport, and content security. One key benefit of requesting content by name is that it eliminates the requirement to establish a session between the client and a specific server, and the content can thereby be retrieved from multiple sources.</t> <t>In parallel, there has been a growing interest in both academia and industry for better understanding the fundamental aspects of Network Coding (NC) toward enhancing key system performancemetricsmetrics, such as data throughput, robustness and reduction in the required number of transmissions through connected networks, and redundant transmission on broadcast or point-to-multipoint connections. NC is a technique that is typically used for encoding packets to recover from lost source packets at thereceiver,receiver and for effectively obtaining the desired information in a fully distributed manner. In addition, in terms of security aspects, 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="Cai02"/>format="default"/> or protecting a wireless video stream while retaining the NC benefits <xref target="Lima10"/>format="default"/> <xref target="Vilela08"/>.</t>format="default"/>.</t> <t>From the perspective of the NC transport mechanism, NC can be divided into two major categories: coherentNC,NC andnon-coherentnoncoherent NC <xreftarget="Koetter08" />target="Koetter03" format="default"/> <xref target="Vyetrenko09"/>.format="default"/>. In coherent NC, the source and destination nodes know the exact network topology and the coding operations available at intermediate nodes. When multiple consumers are attempting to receive the samecontentcontent, such as live video streaming, coherent NC could enable optimal throughput by sending the content flow over the constructed optimal multicast trees <xref target="Wu04"/>.format="default"/>. However, it requires a fully adjustable and specific routingmechanism,mechanism and a large computational capacity for central coordination. In the case ofnon-coherentnoncoherent NC, which often uses Random Linear Coding (RLC), it is not necessary to know the network topology nor the intermediate coding operations <xref target="Ho06"/>.format="default"/>. Asnon-coherentnoncoherent NC works in a completely independent and decentralized 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 content, and may do this at the source 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 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 has already been 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 system performance in ICN <xref target="Montpetit12" />. NC provides CCNx/NDN with the highly beneficial potential of effectively disseminating information in a completely topology independent and decentralized manner.</t> --> <!--<t>NC combines multiple packets together with parts of the samecontent, 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 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. In fact, NC has already been 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 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 are needed to combine NC and CCNx/NDN owing to the unique features of CCNx/NDN (as described in <xref target="TecCons" />).</t> --> <t>NC combines multiple packets together with parts of the same content,content 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 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 allows 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 throughout 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 retrievenetwork codednetwork-coded packets directly from caches in thenetwork and this makesnetwork, making the combination of ICN and NC particularly effective. In fact, NC has already been implemented for information/content dissemination <xref target="Dimarkis10"/>format="default"/> <xref target="Gkantsidis05"/>format="default"/> <xref target="Seferoglu07"/>. Montpetit,format="default"/>. Montpetit etal.,al. first suggested that NC techniques be exploited to enhance key aspects of system performance in ICN <xreftarget="Montpetit12" />.target="Montpetit12"/>. Although CCNx/NDN excels to exploit the benefits of NC (as described in <xref target="Advantages"/>),format="default"/>), some technical considerations are needed to combine NC and CCNx/NDN owing to the unique features of CCNx/NDN (as described in <xref target="TecCons"/>).</t>format="default"/>).</t> <t>In this document, we consider how NC can be applied to the CCNx/NDN architecture 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 methods) 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 Coding for Efficient Network Communications Research Group (NWCRG) and the Information-Centric Networking Research Group (ICNRG). This document was read and reviewed by all the active research group members. It is not an IETF product and is not a standard.</t> </section><!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --><sectiontitle="Terminology"> <!-- <t>This section provides the terms related to NC and CCNx/NDN used in this document.</t> -->numbered="true" toc="default"> <name>Terminology</name> <sectiontitle="Definitions relatednumbered="true" toc="default"> <name>Definitions Related toNC">NC</name> <t>This section provides the terms related to NC used in this document, which are defined inRFC8406 [21] produced by NWCRG.</t> <!-- <t>The terms regarding NC used in this document are defined as follows. These are aligned with RFCsRFC 8406 <xref target="RFC8406" format="default"/> and produced by theFEC Framework (FECFRAME) IETF Working Groups as well as IRTF Coding for Efficient Network Communications Research 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 performed 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 the 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: ANWCRG.</t> <dl newline="true" spacing="normal"> <dt>Source Packet:</dt> <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 source that is used as input to encoding operations. For instance, areal-time transport protocolReal-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 sourcesymbols.</t> <t>Repair Packet: Asymbols.</dd> <dt>Repair Packet:</dt> <dd>A packet containing one or more coded symbols (also called repair symbol).CodedThe 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 case ofre-coding)recoding) source and/or coded symbols. When there is a single repair symbol per repair packet, a repair symbol corresponds to a repairpacket.</t> <!-- <t>Coded Packet, or Repair Packet: A packet containing one or more 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 (in 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 the rank of the linear system (also called degrees of freedom) at a receiver.</t> --> <t>Encodingpacket.</dd> <dt>Encoding versusRe-codingRecoding versusDecoding: EncodingDecoding:</dt> <dd>Encoding is an operation that takes source symbols as input and produces encoding symbols (source or coded symbols) as output.Re-codingRecoding is an operation that takes encoding symbols as input and produces encoding symbols as output. Decoding is an operation that takes encoding symbols as input and produces source symbols asoutput.</t> </list></t>output.</dd> </dl> <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 symbols (i.e., source and/or coded symbols) using a given set of coefficients and resulting in a repair symbol.</t> --> <t>Random<dl newline="true" spacing="normal"> <dt>Random Linear Coding(RLC): A(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 input symbols (i.e., source and/or coded symbols) using a given set of coefficients and results in a repairsymbol.</t> <t>Block Coding: Asymbol.</dd> <dt>Block Coding:</dt> <dd>A coding technique wherein the input flow(s) must be first segmented into a sequence ofblocks; encodingblocks. Encoding and decoding are performed independently on a per-blockbasis.</t> <!-- <t>Systematic Coding: A coding technique where source symbols are part of the output flow generated by a coding node.</t> --> <t>Slidingbasis.</dd> <dt>Sliding Window Coding or ConvolutionalCoding: ACoding:</dt> <dd>A general class of coding techniques that rely on a sliding encoding window.EncodingAn encoding window is a set of source (and coded in the case ofre-coding)recoding) symbols used as input to the coding operations. The set of symbols change over time, as the encoding window slides over the input flow(s). This is an alternative solution to blockcoding.</t> <t>Fixedcoding.</dd> <dt>Fixed or Elastic Sliding WindowCoding: ACoding:</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 that time, usually by using linear coding. The sliding window may be either of fixed size or of variable size overthetime (also known as "Elastic Sliding Window"). For instance, the size may depend on acknowledgments sent by the receiver(s) for a particular source symbol or source packet (received, decoded, ordecodable).</t> </list></t>decodable).</dd> </dl> <t>The terms regarding low-level coding aspects are defined as follows:</t><t><list style="symbols"> <!-- Coding Basics --> <t>Rank<dl newline= "true" spacing="normal"> <dt>Rank of the Linear System or Degrees ofFreedom: AtFreedom:</dt> <dd>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 "fullrank,"rank", wherein decoding is possible, or "partial rank", wherein only partial decoding ispossible.</t> <t>Generation,possible.</dd> <dt>Generation orBlock: WithBlock:</dt> <dd>With block codes, the set of source symbols of the input flow(s) that are logically grouped into ablock,block before doingencoding.</t> <t>Generation Size,encoding.</dd> <dt>Generation Size or BlockSize: WithSize:</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 single source symbol per sourcepacket.</t> <!-- <t>Generation ID, or Block ID: With block codes, the identifier of a block to which source and coded symbols belong. It is also known as "Source Block Number (SBN)".</t> --> <t>Coding Coefficient: Withpacket.</dd> <dt>Coding Coefficient:</dt> <dd>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 predefinedtable,table or using a predefined algorithm plus aseed.</t> <t>Coding Vector: Aseed.</dd> <dt>Coding Vector:</dt> <dd>A set of coding coefficients used to generate a certain coded symbol through linearcoding.</t> <t>Finite Field: Finitecoding.</dd> <dt>Finite Field:</dt> <dd>Finite fields, used in linear codes, have the desired property of having all elements (except zero) invertible for + and**, and no operation over any elements can result in an overflow or underflow. Examples of finite fields are prime fields{0..p^m-1},{0..p<sup>m-1</sup>}, where p is prime. Most used fields use p=2 and are called binary extension fields{0..2^m-1},{0..2<sup>m-1</sup>}, where m often equals 1,44, or 8 for practicalreasons.</t> <!-- <t>Finite Field size: The number of elements in a finite field. 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 nature of information contained in a feedback packet varies, depending on the use-case. It can provide reception and/or decoding statistics, or the list of available source packets received or decoded, or the list of lost source packets that should be retransmitted, or a number of additional coded packet needed to have a full rank linear system.</t> --> </list></t>reasons.</dd> </dl> </section> <sectiontitle="Definitions relatednumbered="true" toc="default"> <name>Definitions Related toCCNx/NDN">CCNx/NDN</name> <t>The terminology regarding CCNx/NDN used in this document is defined inRFC8793RFC 8793 <xreftarget="CCNxTerm" />target="RFC8793" format="default"/>, which was produced by the ICNRG. They are consistent with the relevant documents (<xreftarget="CCNxSema" />target="RFC8569" format="default"/> <xreftarget="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 Networking (ICNRG) IRTF Working Group<xref target="CCNxSema" /> <xref target="CCNxMsg" />.</t> <t><list style="symbols"> <t>Interest: A message requesting a content object with a matching name and other optional selectors for selecting from multiple objects having the same name prefix.</t> <t>Content Object: A unit of content data delivered through the CCNx/NDN network.</t> <t>Consumer: A node requesting a name (i.e., content). It initiates the name-based communication by sending an interest packet.</t> <t>Publisher: A node that provides content. It originally creates or owns a content.</t> <t>Router: An intermediate node between the consumer and producer that facilitates the name-based communication by forwarding interest and data packets.</t> <t>Forwarding Information Base (FIB): A lookup table in a content router containing the name prefix and corresponding destination interface for forwarding the interest packets.</t> <t>Pending Interest Table (PIT): A lookup table populated by the interest packets containing the name prefix of the requested data, and the outgoing interface used to forward the received data packets.</t> <t>Content Store (CS): A storage space for a router to cache content objects.</t> </list></t> -->target="RFC8609" format="default"/>).</t> </section> </section><!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --><sectiontitle="CCNx/NDN Basics"> <!-- <t>We briefly explain the key concepts of CCNx/NDN. Both protocols are similar in principle, but differ in some architecture and protocol choices. </t> -->numbered="true" toc="default"> <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 (defined inSection 3.4 of<xreftarget="CCNxTerm" />).target="RFC8793" section="3.4" sectionFormat="of" format="default"/>). The termof content object,"content object", which means a unit of content data, is an alias to data packet <xreftarget="CCNxTerm" />.target="RFC8793" format="default"/>. The ICN consumer (defined inSection 3.2 of<xreftarget="CCNxTerm" />)target="RFC8793" section="3.2" sectionFormat="of" format="default"/>) requests a content object by sending an interest that carries the name of 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 receive in return any data with a name matching this prefix).</t> --><t>Once an ICN forwarder (defined inSection 3.2 of<xreftarget="CCNxTerm" />)target="RFC8793" section="3.2" sectionFormat="of" format="default"/>) receives an interest, it performs a series oflookups: firstlookups. First, it checks if it has a copy of the requested content object available in the cachestoragestorage, called Content Store (CS) (defined inSection 3.3 of<xreftarget="CCNxTerm" />).target="RFC8793" section="3.3" sectionFormat="of" format="default"/>). 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 inSection 3.3 of<xreftarget="CCNxTerm" />)target="RFC8793" section="3.3" sectionFormat="of" format="default"/>) to check if there is already an outgoing interest 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 theinterest,interest and the interfaces from which it received the interest. This is later used to send the content object back, as interest packets do not carry a source 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 interest is discarded.</t> <t>After the PIT lookup, the interest undergoes a Forwarding Information Base (FIB) (defined inSection 3.3 of<xreftarget="CCNxTerm" />)target="RFC8793" section="3.3" sectionFormat="of" format="default"/>) lookup for selecting an outgoing interface. The FIB lists name prefixes and their corresponding forwarding interfaces in order to send the interesttowardstoward 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 that an interest issatisfied,satisfied and may store the data in their CS.</t> <t>Data packets carry some information for verifying data integrity and originauthentication, andauthentication and, in particular, that the data is indeed that which corresponds 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 inSection 3.2 of<xreftarget="CCNxTerm" />)target="RFC8793" section="3.2" sectionFormat="of" format="default"/>) that returns the content object is not aware of the network location of theconsumerconsumer, and the consumer is not aware of the network location of the node that provides the content. This, in theory, allows the interests to follow different paths within a network or even to be sent over completely different networks.</t> </section><!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --><sectiontitle="NC Basics">numbered="true" toc="default"> <name>NC Basics</name> <t> While the forwarding node simply relays received data packets in conventional IP communication networks, NC allows the node to combine some data packets that are already received into one or several output packets to be sent. In this 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> <t>For simplicity, let us consider an example case of end-to-end coding wherein a producer and consumer respectively perform encoding and decoding for a content object. This end-to-end coding is regarded as a special case of NC. The producer splits the content into several blocks called generations. Encoding and decoding are performed independently on a per-block (per-generation) basis. Let us assume that each generation consists of K original source packets of the same size. When the packets do not have the same size, zero padding is added. In order to generate one repair packet within a certain generation, the producer linearly combines K of the original source packets, where additions and multiplications are performed using a coding vector consisting of K coding coefficients that are randomly selected in a certain finite field. The producer may respond to interests to send the corresponding source packets and repair packets in the content flow (called systematic coding), where the repair packets are typically used for recovering lost source packets.</t> <t>Repair packets can also be used for performing encoding. If the forwarding nodes know each coding vector and generation identifier (hereinafter referred to as generation ID) of the received repair packets, they may perform an encoding operation (calledre-coding),recoding), which is the most distinctive feature of NC compared to other coding techniques.</t> <t>At the consumer, decoding is performed by solving a set of linear equations that are represented by the coding vectors of the received source and repair packets (possibly only repair packets) within a certain generation. In order to obtain all the source packets, the consumer requires K linearly independent equations. In other words, the consumer must receive at least K linearly independent data packets (called innovative packets). As receiving a linearly dependent data packet is not useful for decoding,re-codingrecoding should generate and provide innovative packets. One of the major benefits of RLC isthatthat, even for a small-sized finite field (e.g.,q=2^8),q=2<sup>8</sup>), the probability of generating linearly dependent packets is negligible <xref target="Wu04"/>.</t>format="default"/>.</t> </section><!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --><section anchor="Advantages"title="Advantagesnumbered="true" toc="default"> <name>Advantages of NC andCCNx/NDN">CCNx/NDN</name> <t>Combining NC and CCNx/NDN can contribute to effective large-scale content/information dissemination. They individually provide similarbenefitsbenefits, such as throughput/capacity gain and robustness enhancement. The difference between their approaches isthat,that the former considers content flow as algebraic information that is to be combined <xref target="Koetter03"/>,format="default"/>, while the latter focuses on the content/information itself at the networking layer. Because these approaches are complementary and their combination would be advantageous, it is natural to combine them.</t> <t>The name-based communication in CCNx/NDN enables consumers to obtain requested content objects without establishing and maintaining end-to-end communication channels between nodes. This feature facilitates the exploitation of the in-network cache and multipath/multisource retrieval and also supports consumer mobility without the need for updating the location information/identifier during handover <xref target="Jacobson09"/>.format="default"/>. Furthermore, the name-based communication intrinsically supports multicast communication because identical interests are aggregated at the forwarders.</t> <t>NC can enable the CCNx/NDN transport system to effectively distribute and cache the data associated with multipath data retrieval <xref target="Montpetit12"/>.format="default"/>. Exploiting multipath data retrieval and in-network caching with NC contributes to not only improving the cache hit rate but also expanding the anonymity set of each consumer (the set of potential routers that can serve a given consumer) <xref target="Wu16"/>.format="default"/>. The expansion makes it difficult for adversaries to infer the content consumed byothers,others and thus contributes to improving cache privacy. Others also have introduced some use cases of the application of NC in CCNx/NDN, such as the cases of content dissemination with in-network caching <xref target="Saltarin16"/>format="default"/> <xref target="Wang14"/>format="default"/> <xref target="Wang16"/>,format="default"/>, seamless consumer mobility <xref target="Ramakrishnan12"/>format="default"/> <xref target="Carofiglio16"/>,format="default"/>, and low-latency low-loss video streaming <xref target="Matsuzono17"/>.format="default"/>. In this context, it is well worth considering NC integration in CCNx/NDN.</t><!-- <t>CCNx/NDN does not provide reliable and robust content dissemination by default. However, NC can enable the CCNx/NDN transport system to effectively distribute and cache the data associated with multipath data retrieval <xref target="Montpetit12" />. Furthermore, NC can contribute to improving both the caching performance and cache privacy that CCNx/NDN newly introduces at the networking 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 dissemination with in-network caching <xref target="Saltarin16" /> <xref target="Wang14" /> <xref target="Wang16" />, seamless consumer mobility <xref target="Ramakrishnan12" /> <xref 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> --></section><!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --><section anchor="TecCons"title="Technical Considerations">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 anchor="Naming"title="Content 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 section, two possible naming schemes are presented.</t> <sectiontitle="Uniquenumbered="true" toc="default"> <name>Unique Naming for NCPackets">Packets</name> <t>Each source and repair packet (hereinafter referred to as NC packet) may have a uniquenamename, as each original content object has inCCNx/NDN,CCNx/NDN and as PIT and CS operations typically require a unique name for identifying the NC packet. 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 the 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-id""enc&nbhy;id", such as /CCNx.com/video-A/enc-id/g-id/1000, as defined in the FEC Framework (FECFRAME) <xref target="RFC6363"/>.format="default"/>. 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 contentobjects.<!--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 producer onto the content requester (described in <xref target="Consumer" />).--></t>objects. </t> <t>If a content-namingschemaschema, such as the one presentedaboveabove, 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 including only a generation ID (/CCNx.com/video-A/g-id). In the former case, exact name 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 coding vector from the data forwarder onto the consumer.</t> <t>In the latter case, partial name matching is required at the data forwarders. 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 CS (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-networkre-codingrecoding performed at forwarders, the consumer could also receive the modified NC packets. However, in contrast to the former case, the consumer may fail to obtain sufficient degrees of freedom (see <xref target="Router"/>).format="default"/>). 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 packets for the consumer (also called decoding matrix) as in <xref target="Montpetit12"/>.format="default"/>. This extension may incur an interest packet of significantly increased size, and it may thus be useful to use compression 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 regarding the interest packets that were satisfied previously(See(see <xref target="Router"/>).</t>format="default"/>).</t> </section> <sectiontitle="Non-Uniquenumbered="true" toc="default"> <name>Nonunique Naming for NCPackets">Packets</name> <t>An NC packet may have a name that indicates that it is an NCpacket,packet and move the coding information into a metadata field in the payload (i.e., the name includes the data type,sourcesource, or repair packet). This would not be beneficial for applications or services that may not need to understand the packet payload. 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 described in <xref target="Cache"/>,format="default"/>, a mechanism for managing the multiple innovative packets in the CS would also be required. In addition, extra computational overhead would be incurred when the payload is being encrypted.</t> </section> </section><!-- ========================================================== --><section anchor="Trans"title="Transport">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 interestretrievesretrieves, atmostmost, 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 invalidates existing congestion control approaches following this rule, and 3) it would reduce the efficiency of existing consumer mobility approaches. Thus, the following basic operation should be considered for applying NC to CCNx/NDN. Nevertheless, such security considerations must be addressed if this rule were to be violated.</t><!-- <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 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 should be considered for applying NC to CCNx/NDN. Nevertheless, such security considerations must be addressed if this rule were to be violated.</t> --><sectiontitle="Scopenumbered="true" toc="default"> <name>Scope ofNC">NC</name> <t>An open question is whether a data forwarder can perform in-networkre-codingrecoding with data packets that are being received intransit,transit or if only the data that matches an interest can be subject to NC operations. In the latter case, encoding orre-codingrecoding is performed to generate the NC packet at any forwarder that 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-codingrecoding occurs anywhere in the network where it is possible to modify the received NC packet and forward it. As CCNx/NDN comprises mechanisms for ensuring the integrity of the data during transfer, in-networkre-codingrecoding introduces complexities in the network that needs consideration for the integrity mechanisms to still work. Similarly, in-network caching of NC packets at forwarders may be valuable; however, the forwarders would require some mechanisms to validate the NC packets (see <xref target="Security"/>).</t>format="default"/>).</t> </section> <sectionanchor= "Consumer" title="Consumer Operation">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 producer) 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="default"/>), by issuing an interest specifying a unique name with g-id and the coding vector for an NC 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, the consumer is required to know the valid naming scheme. From a practical viewpoint, it is desirable for the consumer application to automatically construct the right name components without depending on any application specifications. To this end, the consumer application may retrieve and refer to a manifest <xreftarget="CCNxSema" />target="RFC8569" format="default"/> that enumerates the contentobjectsobjects, including NC packets, or may use some coding scheme specifier as a name component to construct the name components of interests to request innovative packets.</t><!-- <t>To obtain NC benefits (possibly associated with in-network caching), the consumer is required to issue interests that direct the forwarder (or producer) to respond with innovative packets if available. When issuing an interest specifying a unique name with g-id and the coding vector for a coded packet, the consumer could appropriately receive an innovative packet if it is available at some 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 end-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 sensor node) may want to receive only the source packets. As described in <xref target="Naming"/>,format="default"/>, because the NC packet can have a name that is explicitly different from source packets, issuing interests for retrieving source packets is possible.</t><!-- <t>Conversely, the consumer without decoding capability (e.g., specific sensor node) may want to receive only the source packets. As described in <xref target="Naming" />, because the coded packet can have a name that is explicitly different 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 packet.</t> --></section> <section anchor="Router"title="Forwarder Operation">numbered="true" toc="default"> <name>Forwarder Operation</name> <t>If the forwarder constantly responds to the incoming interests by returning non-innovative packets, the consumer(s) cannot decode and obtain the source packets. This issue could happen when 1) incoming interests for NC packets do not specify some codingparametersparameters, such as the coding vectors to be used, and 2) the forwarder does not have a sufficient number of linearly independent NC packets (possibly in the CS) to use forre-coding.recoding. In this case, the forwarder is required to determine whether or not it can generate innovative packets to be forwarded 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, generationIDID, and the incominginterface(s),interface(s) in order to record how 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 addition, some transport mechanism for in-network loss detection and recovery <xreftarget="Matsuzono17" /> <xreftarget="Carofiglio16"/>format="default"/><xref target="Matsuzono17" format="default"/> atforwardera forwarder, as well as a consumer-drivenmechanismmechanism, could be indispensable for enabling fast loss recovery andrealisingrealizing NC gains. If a forwarder cannot either return a matching innovative packet from its local content store, nor produceon-the-flyon 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 forwarder that can provide an innovative packet. In this context, to retrieve an innovative packet effectively and quickly, an appropriate setting of the FIB and efficientinterest forwardinginterest-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 and store them (if the full cache capacity are available), thus enabling a faster response to subsequent interests. Asre-codingrecoding or decoding results in an extra computational 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-tolerant application) and the forwarder situation, such as available cache space and computational capability.</t> </section> <sectiontitle="Producer Operation">numbered="true" toc="default"> <name>Producer Operation</name> <t>Before performing NC for specified content in CCNx/NDN, the producer is responsible for splitting the overall content into small content objects to avoid packet fragmentation that could cause unnecessary packet processing and degraded throughput. The size of the content objects should be within the allowable 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 contentobjects,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 cases; 1) consumers obtain the names of the coded packets through a certain mechanism, and send the corresponding interests toward the producer to obtain the coded 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 packet can be reduced as compared that in the latter case wherein additional NC operations 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 signature on the coded packets, data validation becomes possible throughout as in the case of normal CCNx/NDN operations. According to the application requirement for latency, such an NC operation strategy should be considered.</t> --><t>If the producer takes the lead in determining what coding vectors to use in generating the NC packets, there are three general strategies for naming and producing the NC packets:</t><t><list style="numbers"> <t>consumers<ol spacing="normal" type="1"> <li>Consumers themselves understand in detail the naming conventions used for NC packets and thereby can send the corresponding interests toward the producer to obtain NC packets whose coding parameters have already been determined by theproducer.</t> <t>theproducer.</li> <li>The producer determines the coding vectors and generates the NC packets after receiving interests specifying the packets the consumer wished toreceive.</t> <t>Thereceive.</li> <li>The naming scheme for specifying the coding vectors and corresponding NC packets is explicitly represented via a "Manifest" (e.g., FLIC <xreftarget="Draft-FLIC" />)target="I-D.irtf-icnrg-flic" format="default"/>) that can be obtained by the consumer and used to select among the available coding vectors and their correspondingpackets,packets and thereby send the correspondinginterests.</t> </list></t>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 themanifest,manifest and produce multiple manifests either in advance or on demand with different codingtradeoffstradeoffs, if so desired.</t> <t>A common benefit of the first two approaches to end-to-end coding isthatthat, if the producer adds a signature on the NC packets, data validation becomes possible throughout (as is the case with the CCNx/NDN operation in the absence of NC). The third approach of using a manifest trades off the additional latency 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> <sectiontitle="Backward Compatibility">numbered="true" toc="default"> <name>Backward Compatibility</name> <t>NC operations should be applied in addition to the regular ICNbehavior,behavior and should function alongside regular ICN operations. Hence, nodeswhichthat do not support NC should still be able to properly handle packets, not only in being able to forward the NCpackets,packets but also to cache these packets. An NC framework 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 behavior, and should function alongside regular ICN operations. Hence, nodes without supporting network coding should be able to properly handle NC packets (not only in forwarding the packets, but also in the caching mechanism). An NC framework 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 behavior. 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 smooth migration from one framework to the other.</t> --></section> </section><!-- ========================================================== --><section anchor="Cache"title="In-network Caching">numbered="true" toc="default"> <name>In-Network Caching</name> <t> Caching is a useful technique used for improving throughput and latency in various applications. In-network caching in CCNx/NDN essentially provides support at the network level and is highlybeneficialbeneficial, owing to the involved exploitation of NC for enabling effective multicast transmission <xref target="Ali16"/>,format="default"/>, multipath data retrieval <xref target="Saltarin16"/>format="default"/> <xref target="Ramakrishnan12"/>,format="default"/>, and fast loss recovery <xref target="Matsuzono17"/>.format="default"/>. However, there 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"/>format="default"/> <xref target="Podlipnig03"/>format="default"/> <xref target="Rossini13"/>.format="default"/>. It is thus crucial for forwarders to determine which content objects should be cached and which discarded. As delay-sensitive applications often do not require an in-network cache for a longperiodperiod, owing to their real-time constraints, forwarders have to know the necessity for caching received content objects to save the caching volume. In CCNx, this could be made possible by setting a Recommended Cache Time (RCT) in the optional header of the data packet at the producer side. The RCT serves as a guideline 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 object is not useful. Conversely, the forwarder 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 caching of the NC packets would require some mechanism to validate the NC packets (see <xref target="Security"/>).format="default"/>). In the case wherein the NC packets have the same name, it would also require some mechanism to identify them.</t> </section><!-- ========================================================== --><section anchor="Mobility"title="Seamlessnumbered="true" toc="default"> <name>Seamless ConsumerMobility">Mobility</name> <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 the content in parallel, by using multiple interfaces at the same time in an asynchronous 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 multiple copies, the consumer can perform a certain rate adaptation mechanism for video streaming <xref target="Ramakrishnan12"/>format="default"/> or congestion control for content acquisition <xref target="acm-mpath-cc"/>.</t>format="default"/>.</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 applies to consumer mobility events <xref target="Ramakrishnan12"/>,format="default"/>, wherein the consumer could receive additional degrees of freedom with any innovative packet if at least one available interface exists during the mobility event. Aninterest forwardinginterest-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><!-- <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 applies to consumer mobility events <xref target="Ramakrishnan12" />, wherein the consumer may connect between multiple access points (APs) before a consumer mobility 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 previous and next APs, and then finally only to the next APs. With CCNx, the consumer only sends interests on the available interfaces. By combining NC with CCNx/NDN, 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 receive duplicate data, but does not miss out any content either. The consumer would receive additional degrees of freedom with any innovative packet it receives on either interface. From this perspective, an interest forwarding strategy at the consumer (and possibly forwarder) for efficiently obtaining innovative packets should be considered for the consumer to achieve seamless consumer mobility.</t> --></section> </section><!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --><sectiontitle="Challenges">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><!-- ========================================================== --><sectiontitle="Adoptionnumbered="true" toc="default"> <name>Adoption of ConvolutionalCoding">Coding</name> <t>Several block coding approaches have been proposed thus far; however, there is still not sufficient discussion and application of the convolutional coding approach (e.g., sliding or elastic window coding) in CCNx/NDN. Convolutional coding is often appropriate for situations wherein a fully or partially reliable delivery of continuous data flows isrequired,required and especially when these data flows featurerealtimereal-time constraints. As in <xref target="Pierre11"/>,format="default"/>, on an end-to-end coding basis, it would be advantageous for continuous content 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 the information, and the consumer is required to send interests augmented with feedback information regarding the data reception and/or decoding status. As CCNx/NDNutilisesutilizes the hop-by-hop forwarding state, it would be worth discussing and investigating how convolutional coding can be applied in a hop-by-hop manner and what benefits might accrue. In particular, in the case wherein in-networkre-codingrecoding could occur at forwarders, both the encoding window and CS management would be required, and the corresponding feasibility and practicality should be considered.</t> </section><!-- ========================================================== --><sectiontitle="Ratenumbered="true" toc="default"> <name>Rate and CongestionControl">Control</name> <t>The addition of redundancy using repair packets may result in further network congestion and could adversely affect the overall throughput. In particular, in a situation wherein fair bandwidth sharing is more desirable, each streaming flow must adapt to the network conditions to fairly consume the available link bandwidth. It is thus necessary that each content flow cooperatively implement congestion control to adjust the consumed bandwidth <xreftarget="Draft-NWC-CC" />.target="RFC9265" format="default"/>. From this perspective, an effective deployment approach (e.g., a forwarder-supported approach that can provide benefits under partial deployment) is required.</t><!-- From this perspective, although a forwarder-supported approach would be effective, an effective deployment approach that provides benefits under partial deployment is required.</t> --><t>As described in <xref target="Mobility"/>,format="default"/>, NC can contribute to seamless consumer mobility by obtaining innovative packets without receiving duplicated packets through multipath data retrieval, and avoiding duplicated packets has congestion control benefits as well. It can be challenging to develop an effective rate and congestion control mechanism in order to achieve seamless consumer mobility while improving the overall throughput or latency by fully exploiting NC operations.</t><!-- <t>As described in <xref target="Mobility" />, NC can contribute to seamless consumer mobility by obtaining innovative packets without receiving duplicated packets through multipath data retrieval. It can be challenging to develop an effective rate and congestion control mechanism in order to achieve seamless consumer mobility while improving the overall throughput or latency by fully exploiting NC operations.</t> --></section><!-- ========================================================== --><sectiontitle="Security">numbered="true" toc="default"> <name>Security</name> <t>While CCNx/NDN introduces new security issues at the networking layer that are different from the IP network, such as a cachepoisoning andpoisoning, pollution attacks, and a DoS attack using interest packets, some security approaches are already provided <xref target="RFC7927"/>format="default"/> <xref target="RFC7945"/>.format="default"/>. The application of NC in CCNx/NDN brings two potential security aspects that need to be dealt with.</t> <t>The first is in-networkre-codingrecoding at forwarders. Some mechanism for ensuring the integrity of the NC packets newly produced by in-networkre-codingrecoding is required in order for consumers or other forwarders to receive valid NC packets. To this end, there are some possible approaches described in <xref target="Security"/>,format="default"/>, but there may be a more effective method with lower complexity and computation overhead.</t> <t>The second is that attackers maliciously request and inject NC packets, which could amplify some attacks. As NC packets are unpopular in general use, they could be targeted by a cache pollution attack that requests less popular content objects more frequently to undermine popularity-based caching by skewing the content popularity. Such an attack needs to be dealt with in order to maintain the in-network cache efficiency. By injecting invalid NC packets with the goal of filling the CSs at the forwarders with them, the cache poisoning attack could be effectual depending on the exact integrity coverage on NC packets. On the assumption that each NC packet has the valid signature, the straightforward approach would comprise the forwarders verifying the signature within the NC packets in transit and only transmitting and storing the validated NC packets. However, as performing a signature verification by the forwarders may be infeasible at line speed, some mechanisms should be considered for distributing and reducing the load of signatureverification, in order to maintain in-network cache benefits such as latency and network-load reduction. <!-- Furthermore, denial of service (DoS) attacks with the goal of imposing a higher computation load owing to the NC operations at forwarders and/or the producer 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 already 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 data packet for a specific name can be self-authenticated, can be validated on the 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 forwarders with the invalid content objects (cache poisoning attack). On the assumption that each coded packet has the valid signature, the straightforward approach would 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 signatureverificationby the forwarders may be infeasible at line speed, some mechanisms should be considered for distributing and reducing the load of signature verification,in order to maintain in-network cachebenefitsbenefits, such as latency and network-load reduction. </t><t>In addition, to maintain the in-network cache efficiency, forwarders with CS should take caution when caching validated coded packets. As coded packets are unpopular in general use, they could be targeted by a cache pollution attack that requests less popular content objects more frequently to undermine popularity-based caching by skewing the content popularity. Denial of Service (DoS) attacks 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, it would have to be protected (and validated) in order to prevent modifications by 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/NDN introduces. For instance, assuming that consumers can use multipath data retrieval and caching in CCNx/NDN with NC, cache privacy and anonymity set for consumers 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 issues as low computation overhead as possible while facilitating the NC operations in CCNx/NDN. From the perspective of both feasibility and practicability, more effective approaches with consideration of security would be required in order to accelerate the deployment of CCNx/NDN with NC.</t> --></section><!-- ========================================================== --><sectiontitle="Routing Scalability">numbered="true" toc="default"> <name>Routing Scalability</name> <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, the growth in the routing table size has become a concern. It is thus necessary to use a hierarchical naming scheme in order to improve the routing scalability by enabling the aggregation of the routing information.</t> <t>To realize the benefits of NC, consumers need to efficiently obtain innovative packets using multipath retrieval mechanisms of CCNx/NDN. This would require some efficient routing mechanism to appropriately set the FIB and also an efficientinterest forwardinginterest-forwarding strategy. Such routing coordination may create routing scalability issues. It would be challenging to achieve effective and scalable routing for interests requesting NCpackets as well as to simplify the 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 routing, the growth in the routing table size has become a concern. It is thus necessary to use a hierarchical naming scheme in order to improve the routing scalability by enabling the aggregation of the routing information. It is a challenge to enable consumers to efficiently obtain innovative packets using multipath retrieval in a fully distributed manner, and thus fully leverage NWC in CCNx/NDN to improve throughput or reduce latency. This would require some efficient routing mechanism to appropriately set the FIB and also an efficient interest forwarding strategy. Such routing coordination may create routing scalability issues. From another NWC perspective, as described in <xref target="Consumer" />, when issuing interests while specifying unique names for each coded packet, the consumers 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 routers to appropriately set the FIBs. In this context, it would be challenging to achieve effective and scalable routing for interests requesting coded packetspackets, as well as to simplify the routing process.</t>--></section><!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --></section> <section anchor="iana" numbered="true" toc="default"> <name>IANA Considerations</name> <t>This document has no IANA actions.</t> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>In-networkre-codingrecoding is a distinguishing feature of NC. Only valid NC packets produced by in-networkre-codingrecoding must be requested and utilized (and possibly stored). To this end, there exist some possible approaches. First, as a signature verification approach, the exploitation of multi-signature capability could be applied. This allows not only the original content producer but also some forwarders responsible for in-networkre-codingrecoding to have their own unique signing key. Each forwarder of the group signs a newly generated NC packet in order for other 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 caching. 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 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 <xreftarget="CCNxSema" />.target="RFC8569" format="default"/>. Only the requested 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 CS obeys in order to avoid amplifying invalid data; if an interest has aKeyID 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 interest may be treated as a cache miss and forwarded to the upstream forwarder(s). Third, as a certificate chain management approach (possibly without certificate authority), some mechanism such as <xref target="RiHopAuth" /> could be used to establish a trustworthy data delivery path. This approach adopts the hop-by-hop authentication mechanism, wherein forwarding-integrated hop-by-hop certificate collection 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 may lead to cache poisoning attacks that inject invalid coded packets to the network. To address this issue, there exist some possible approaches. First, as a signature verification approach, the exploitation of multi-signature capability could 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 for other nodes to be able to validate the data with the signature. The CS may verify the signature within the coded packet before storing it to avoid invalid data caching. 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 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 theKeyIdrestriction 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 CS obeys in order to avoid amplifying invalid data; if an interest has a KeyIDrestriction, 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 interest may be treated as a cache miss and forwarded to the upstream forwarder(s). Third, as a certificate chain management approach (possibly without certificate authority), somemechanismmechanism, such as <xref target="RiHopAuth"/>format="default"/>, could be used to establish a trustworthy data delivery path. This approach adopts the hop-by-hop authentication mechanism, wherein the forwarding-integrated hop-by-hop certificate collection is performed to provide suspension certificate chains such that the data retrieval is trustworthy.</t>--> <!-- cache pollution attack --><t>Depending on the adopted cachingstrategystrategy, such as cache replacement policies, forwarders should also take caution when storing and retaining the NC packets in theCSCS, as they could be targeted by cache pollution attacks. In order to mitigate the cache pollution attacks' impact, forwarders should check the content 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 change to the other cache replacement mechanism.</t><!-- DoS Attack --><t>The forwarders or producers require careful attention to the DoS attacksaimingaimed 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 rate-limiting approach. For instance, they could monitor the PIT size growth for NC packets per content to detect theattacks,attacks and limit the interest arrival rate when necessary. If the NC application wishes to secure an interest (considered as the NC actuator) in order to prevent such attacks, the application should consider using an encrypted wrapper and an explicit protocol. </t> </section><!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --> <section title="Acknowledgements"> <t>The authors would like to thank ICNRG and NWCRG members, especially Marie-Jose Montpetit, David Oran, Vincent Roca, and Thierry Turletti, for their valuable comments and suggestions on this document.</t> </section></middle><!-- *****BACK MATTER ***** --><back><!-- References split into informative and normative --> <!-- There are 2 ways to insert reference entries from the citation libraries: 1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown) 2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml") Both are cited textually in the same manner: by using xref elements. If you use the PI option, xml2rfc will, by default, try to find included files in the same directory as the including file. You can also define the XML_LIBRARY environment variable 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. --><references> <name>Informative References</name> <referenceanchor="CCNxSema" target="https://tools.ietf.org/html/rfc8569">anchor="Jacobson09"> <front><title>Content-Centric Networking (CCNx) Semantics</title><title>Networking Named Content</title> <author initials="V" surname="Jacobson" fullname="Van Jacobson"/> <author initials="D" surname="Smetters" fullname="Diana K. Smetters"/> <author initials="J" surname="Thornton" fullname="James D. Thornton"/> <author initials="M"surname="Mosko"/>surname="Plass" fullname="Michael F. Plass"/> <authorinitials="" surname="et al."/>initials="N" surname="Briggs" fullname="Nicholas H. Briggs"/> <author initials="R" surname="Braynard" fullname="Rebecca L. Braynard"/> <date month="December" year="2009"/> </front> <refcontent>Proc. CoNEXT, ACM</refcontent> <seriesInfo name="DOI" value="10.1145/1658939.1658941"/> </reference> <reference anchor="Zhang14"> <front> <title>Named data networking</title> <author initials="L" surname="Zhang" fullname="Lixia Zhang"/> <author initials="A" surname="Afanasyev" fullname="Alexander Afanasyev"/> <author initials="J" surname="Burke" fullname="Jeffrey Burke"/> <author initials="V" surname="Jacobson" fullname="Van Jacobson"/> <author initials="K" surname="Claffy" fullname="KC Claffy"/> <author initials="P" surname="Crowley" fullname="Patrick Crowley"/> <author initials="C" surname="Papadopoulos" fullname="Christos Papadopoulos"/> <author initials="L" surname="Wang" fullname="Lan Wang"/> <author initials="B" surname="Zhang" fullname="Beichuan Zhang"/> <date month="July"year="2019"/>year="2014"/> </front> <refcontent>ACM SIGCOMM Computer Communication Review, vol. 44, no. 3</refcontent> <seriesInfoname="RFC" value="8569"/>name="DOI" value="10.1145/2656877.2656887"/> </reference> <reference anchor="Gkantsidis06"> <front> <title>Cooperative Security for Network Coding File Distribution</title> <author initials="C"surname="Gkantsidis"/>surname="Gkantsidis" fullname="Christos Gkantsidis"/> <authorinitials="P. R." surname="Rodriguez"/>initials="P" surname="Rodriguez" fullname="P. Rodriguez Rodriguez"/> <date month="April" year="2006"/> </front> <refcontent>Proc. Infocom, IEEE</refcontent> <seriesInfoname="Proc. Infocom," value="IEEE"/>name="DOI" value="10.1109/INFOCOM.2006.233"/> </reference> <reference anchor="Cai02"> <front> <title>Secure network coding</title> <author initials="N"surname="Cai"/>surname="Cai" fullname="Ning Cai"/> <authorinitials="R. W" surname="Yeung"/>initials="R" surname="Yeung" fullname="Raymond W. Yeung"/> <date month="June" year="2002"/> </front><seriesInfo name="Proc.<refcontent>Proc. International Symposium on Information Theory(ISIT)," value="IEEE"/>(ISIT), IEEE</refcontent> <seriesInfo name="DOI" value="10.1109/ISIT.2002.1023595"/> </reference> <reference anchor="Lima10"> <front> <title>Secure Network Coding for Multi-Resolution Wireless Video Streaming</title> <author initials="L"surname="Lima"/>surname="Lima" fullname="Luisa Lima"/> <author initials="S"surname="Gheorghiu"/>surname="Gheorghiu" fullname="Steluta Gheorghiu"/> <author initials="J"surname="Barros"/>surname="Barros" fullname="Joao Barros"/> <author initials="M"surname="Medard"/>surname="Medard" fullname="Muriel Medard"/> <authorinitials="A. T." surname="Toledo"/>initials="A" surname="Toledo" fullname="Alberto Lopez Toledo"/> <date month="April" year="2010"/> </front><seriesInfo name="IEEE<refcontent>IEEE Journal of Selected Area(JSAC)," value="vol.(JSAC), vol. 28, no.3" />3</refcontent> <seriesInfo name="DOI" value="10.1109/JSAC.2010.100409"/> </reference> <reference anchor="Vilela08"> <front> <title>Lightweight security for network coding</title> <authorinitials="J.P." surname="Vilea"/>initials="J" surname="Vilea" fullname="Joao P. Vilela"/> <author initials="L"surname="Lima"/>surname="Lima" fullname="Luisa Lima"/> <author initials="J"surname="Barros"/>surname="Barros" fullname="Joao Barros"/> <date month="May" year="2008"/> </front> <refcontent>Proc. ICC, IEEE</refcontent> <seriesInfo name="DOI" value="10.48550/arXiv.0807.0610"/> </reference> <reference anchor="Koetter03"> <front> <title>An Algebraic Approach to Network Coding</title> <author initials="R" surname="Koetter" fullname="Ralf Koetter"/> <author initials="M" surname="Medard" fullname="Muriel Medard"/> <date month="October" year="2003"/> </front> <refcontent>IEEE/ACM Transactions on Networking, vol. 11, no. 5</refcontent> <seriesInfoname="Proc. ICC," value="IEEE"/>name="DOI" value="10.1109/TNET.2003.818197"/> </reference> <reference anchor="Vyetrenko09"> <front> <title>Rate regions for coherent and noncoherent multisource network error correction</title> <author initials="S" surname="Vyetrenko" fullname="Svitlana Vyetrenko"/> <author initials="T" surname="Ho" fullname="Tracey Ho"/> <author initials="M" surname="Effros" fullname="Michelle Effros"/> <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="Wu04"> <front> <title>A comparison of network coding and tree packing</title> <author initials="Y" surname="Wu" fullname="Yunnan Wu"/> <author initials="P" surname="Chou" fullname="Philip A. Chou"/> <author initials="K" surname="Jain" fullname="Kamal Jain"/> <date month="June" year="2004"/> </front> <refcontent>Proc. International Symposium on Information Theory (ISIT), IEEE</refcontent> <seriesInfo name="DOI" value="10.1109/ISIT.2004.1365182"/> </reference> <reference anchor="Ho06"> <front> <title>A Random Linear Network Coding Approach to Multicast</title> <author initials="T" surname="Ho" fullname="Tracey Ho"/> <author initials="M" surname="Medard" fullname="Muriel Medard"/> <author initials="R" surname="Koetter" fullname="Ralf Koetter"/> <author initials="D" surname="Karger" fullname="David Karger"/> <author initials="M" surname="Effros" fullname="Michelle Effros"/> <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</refcontent> <seriesInfo name="DOI" value="10.1109/TIT.2006.881746"/> </reference> <reference anchor="Dimarkis10"> <front> <title>Network Coding for Distributed Storage Systems</title> <author initials="A"surname="Dimarkis"/>surname="Dimarkis" fullname="Alexandros G. Dimakis"/> <author initials="P"surname="Godfrey"/>surname="Godfrey" fullname="P. Brighten Godfrey"/> <author initials="Y"surname="Wu"/>surname="Wu" fullname="Yunnan Wu"/> <author initials="M"surname="Wainwright"/>surname="Wainwright" fullname="Martin J. Wainwright"/> <author initials="K"surname="Ramchandran"/>surname="Ramchandran" fullname="Kannan Ramchandran"/> <date month="September" year="2010"/> </front><seriesInfo name="IEEE<refcontent>IEEE Trans. InformationTheory," value="vol.Theory, vol. 56,no.9"/>no.9</refcontent> <seriesInfo name="DOI" value="10.1109/TIT.2010.2054295"/> </reference> <reference anchor="Gkantsidis05"> <front> <title>Network coding for large scale content distribution</title> <author initials="C"surname="Gkantsidis"/>surname="Gkantsidis" fullname="Christos Gkantsidis"/> <author initials="P"surname="Rodriguez"/>surname="Rodriguez" fullname="Pablo Rodriguez"/> <date month="March" year="2005"/> </front> <refcontent>Proc. Infocom, IEEE</refcontent> <seriesInfoname="Proc. Infocom," value="IEEE"/>name="DOI" value="10.1109/INFCOM.2005.1498511"/> </reference> <reference anchor="Seferoglu07"> <front> <title>Opportunistic Network Coding for Video Streaming over Wireless</title> <author initials="H"surname="Seferoglu"/>surname="Seferoglu" fullname="Hulya Seferoglu"/> <author initials="A"surname="Markopoulou"/>surname="Markopoulou" fullname="Athina Markopoulou"/> <date month="November" year="2007"/> </front><seriesInfo name="Proc.<refcontent>Proc. Packet Video Workshop(PV)," value="IEEE"/>(PV), IEEE</refcontent> <seriesInfo name="DOI" value="10.1109/PACKET.2007.4397041"/> </reference> <reference anchor="Montpetit12"> <front> <title>Network Coding Meets Information-Centric Networking: An Architectural Case for Information Dispersion Through Native Network Coding</title> <authorinitials="M.J." surname="Montpetit"/>initials="M" surname="Montpetit" fullname="Marie-Jose Montpetit"/> <author initials="C"surname="Westphal"/>surname="Westphal" fullname="Cedric Westphal"/> <author initials="D"surname="Trossen"/>surname="Trossen" fullname="Dirk Trossen"/> <date month="June" year="2012"/> </front><seriesInfo name="Proc.<refcontent>Proc. Workshop on Emerging Name-Oriented Mobile Networking Design(NoM)," value="ACM"/>(NoM), ACM</refcontent> <seriesInfo name="DOI" value="10.1145/2248361.2248370"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8406.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8793.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8569.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8609.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7927.xml"/> <referenceanchor="Saltarin16">anchor="Wu16"> <front><title>NetCodCCN: a network coding approach<title>Privacy-Aware Multipath Video Caching forcontent-centric networks</title> <author initials="J" surname="Saltarin"/>Content-Centric Networks</title> <authorinitials="E" surname="Bourtsoulatze"/>initials="Q" surname="Wu" fullname="Qinghua Wu"/> <authorinitials="N" surname="Thomos"/>initials="Z" surname="Li" fullname="Zhenyu Li"/> <authorinitials="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 Seamless Mobility</title>initials="G" surname="Tyson" fullname="Gareth Tyson"/> <authorinitials="A" surname="Ramakrishnan"/>initials="S" surname="Uhlig" fullname="Steve Uhlig"/> <authorinitials="C" surname="Westphal"/>initials="M" surname="Kaafar" fullname="Mohamed Ali Kaafar"/> <authorinitials="J" surname="Saltarin"/>initials="G" surname="Xie" fullname="Gaogang Xie"/> <datemonth="December"month="June" year="2016"/> </front><seriesInfo name="Proc. International Symposium<refcontent>IEEE Journal onMultimedia (ISM)," value="IEEE"/>Selected Areas in Communications (JSAC), vol. 38, no. 8</refcontent> <seriesInfo name="DOI" value="10.1109/JSAC.2016.2577321"/> </reference> <referenceanchor="acm-mpath-cc">anchor="Saltarin16"> <front><title>MIRCC: Multipath-aware ICN Rate-based Congestion Control</title><title>NetCodCCN: a network coding approach for content-centric networks</title> <authorinitials="M" surname="Mahdian"/>initials="J" surname="Saltarin" fullname="Jonnahtan Saltarin"/> <authorinitials="S" surname="Arianfar"/>initials="E" surname="Bourtsoulatze" fullname="Eirina Bourtsoulatze"/> <authorinitials="J" surname="Gibson"/>initials="N" surname="Thomos" fullname="Nikolaos Thomos"/> <authorinitials="D" surname="Oran"/>initials="T" surname="Braun" fullname="Torsten Braun"/> <datemonth="September"month="April" year="2016"/> </front> <refcontent>Proc. Infocom, IEEE</refcontent> <seriesInfoname="Proc. Conference on Information-Centric Networking (ICN)," value="ACM"/>name="DOI" value="10.1109/INFOCOM.2016.7524382"/> </reference> <reference anchor="Wang14"> <front> <title>An Optimal Cache Management Framework for Information-Centric Networks with Network Coding</title> <author initials="J"surname="Wang"/>surname="Wang" fullname="Jin Wang"/> <author initials="J"surname="Ren"/>surname="Ren" fullname="Jing Ren"/> <author initials="K"surname="Lu"/>surname="Lu" fullname="Kejie Lu"/> <author initials="J"surname="Wang"/>surname="Wang" fullname="Jianping Wang"/> <author initials="S"surname="Liu"/>surname="Liu" fullname="Shucheng Liu"/> <author initials="C"surname="Westphal"/>surname="Westphal" fullname="Cedric Westphal"/> <date month="June" year="2014"/> </front><seriesInfo name="Proc.<refcontent>Proc. NetworkingConference," value="IFIP/IEEE"/>Conference, IFIP/IEEE</refcontent> <seriesInfo name="DOI" value="10.1109/IFIPNetworking.2014.6857127"/> </reference> <reference anchor="Wang16"> <front> <title>A Minimum Cost Cache Management Framework for Information-Centric Networks with Network Coding</title> <author initials="J"surname="Wang"/>surname="Wang" fullname="Jin Wang"/> <author initials="J"surname="Ren"/>surname="Ren" fullname="Jing Ren"/> <author initials="K"surname="Lu"/>surname="Lu" fullname="Kejie Lu"/> <author initials="J"surname="Wang"/>surname="Wang" fullname="Jianping Wang"/> <author initials="S"surname="Liu"/>surname="Liu" fullname="Shucheng Liu"/> <author initials="C"surname="Westphal"/>surname="Westphal" fullname="Cedric Westphal"/> <date month="August" year="2016"/> </front> <refcontent>Computer Networks, Elsevier</refcontent> <seriesInfoname="Computer Networks," value="Elsevier"/>name="DOI" value="10.1016/j.comnet.2016.08.004"/> </reference> <referenceanchor="Matsuzono17">anchor="Ramakrishnan12"> <front><title>Low Latency Low Loss<title>Adaptive Video Streamingusing In-Networkover CCN with Network Codingand Caching</title> <author initials="K" surname="Matsuzono"/> <author initials="H" surname="Asaeda"/> <author initials="T" surname="Turletti"/> <date month="May" year="2017"/> </front> <seriesInfo name="Proc. Infocom," value="IEEE"/> </reference> <reference anchor="Jacobson09"> <front> <title>Networking Named Content</title> <author initials="V" surname="Jacobson"/> <author initials="D.K." surname="Smetters"/> <author initials="J.D" surname="Thornton"/> <author initials="M.F" surname="Plass"/> <author initials="N.H." surname="Briggs"/> <author initials="R.L." surname="Braynard"/> <date month="December" year="2009"/> </front> <seriesInfo name="Proc. CoNEXT," value="ACM"/> </reference> <reference anchor="CCNxTerm" target="https://tools.ietf.org/html/rfc8793"> <front> <title>Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology</title> <author initials="B" surname="Wissingh"/> <author initials="" surname="et al."/> <date month="June" year="2020"/> </front> <seriesInfo name="RFC" value="8793"/> </reference> <reference anchor="CCNxMsg" target="https://tools.ietf.org/html/rfc8609"> <front> <title>Content-Centric Networking (CCNx) Messages in TLV Format</title> <author initials="M" surname="Mosko"/> <author initials="" surname="et al."/> <date month="July" year="2019"/> </front> <seriesInfo name="RFC" value="8609"/> </reference> <reference anchor="Zhang14"> <front> <title>Named data networking</title> <author initials="L" surname="Zhang"/>for Seamless Mobility</title> <author initials="A"surname="Afanasyev"/> <author initials="J" surname="Burke"/> <author initials="V" surname="Jacobson"/> <author initials="K" surname="Claffy"/> <author initials="P" surname="Crowley"/>surname="Ramakrishnan" fullname="Abinesh Ramakrishnan"/> <author initials="C"surname="Papadopoulos"/> <author initials="L" surname="Wang"/> <author initials="B" surname="Zhang"/> <date month="July" year="2014"/> </front> <seriesInfo name="ACM Comput. Commun. Rev.," value="vol. 44, no. 3"/> </reference> <!-- <reference anchor="NDNPacket" target="https://named-data.net/doc/NDN-packet-spec/current/"> <front> <title>NDN Packet Format Specification 0.3 documentation</title> <author initials="" surname="NDN Packet Format"/> <date month="Sept." year="2019"/> </front> </reference> --> <reference anchor="Koetter03"> <front> <title>An Algebraic Approach to Network Coding</title> <author initials="R" surname="Koetter"/>surname="Westphal" fullname="Cedric Westphal"/> <authorinitials="M" surname="Medard"/>initials="J" surname="Saltarin" fullname="Jonnahtan Saltarin"/> <datemonth="Oct." year="2003"/>month="December" year="2016"/> </front><seriesInfo name="IEEE/ACM Trans.<refcontent>Proc. International Symposium onNetworking," value="vol. 11, no 5"/> </reference> <reference anchor="I-D.irtf-nwcrg-network-coding-taxonomy" target="https://tools.ietf.org/html/rfc8406"> <front> <title>Taxonomy of Coding Techniques for Efficient Network Communications</title> <author initials="B" surname="Adamson"/> <author initials="" surname="et al."/> <date month="June" year="2018"/> </front>Multimedia (ISM), IEEE</refcontent> <seriesInfoname="RFC" value="8406"/>name="DOI" value="10.1109/ISM.2016.0054"/> </reference> <referenceanchor="Draft-NWC-CC">anchor="Carofiglio16"> <front><title>Coding and Congestion<title>Leveraging ICN In-network Control for Loss Detection and Recovery inTransport</title> <author initials="N" surname="Kuhn"/> <author initials="E" surname="Lochin"/> <author initials="F" surname="Michel"/> <author initials="M" surname="Welzl"/> <date month="June" year="2021"/> </front> <seriesInfo name="Work in Progress," value="draft-irtf-nwcrg-coding-and-congestion-09"/> </reference> <reference anchor="Draft-FLIC"> <front> <title>File-Like ICN Collections (FLIC)</title>Wireless Mobile networks</title> <authorinitials="C" surname="Tschudin"/>initials="G" surname="Carofiglio" fullname="Giovanna Carofiglio"/> <authorinitials="C" surname="Wood"/>initials="L" surname="Muscariello" fullname="Luca Muscariello"/> <author initials="M"surname="Mosko"/> <author initials="D" surname="Oran"/> <date month="Nov." year="2021"/> </front> <seriesInfo name="Work in Progress," value="draft-irtf-icnrg-flic-03"/> </reference> <reference anchor="RFC7927"> <front> <title> Information-Centric Networking (ICN) Research Challenges</title>surname="Papalini" fullname="Michele Papalini"/> <authorinitials="D" surname="Kutscher"/>initials="N" surname="Rozhnova" fullname="Natalya Rozhnova"/> <authorinitials="" surname="et al."/>initials="X" surname="Zeng" fullname="Xuan Zeng"/> <datemonth="July"month="September" year="2016"/> </front> <refcontent>Proc. of the 3rd ACM Conference on Information-Centric Networking</refcontent> <seriesInfoname="RFC" value="7927"/>name="DOI" value="10.1145/2984356.2984361"/> </reference> <referenceanchor="RFC7945">anchor="Matsuzono17"> <front><title> Information-Centric Networking: Evaluation<title>Low Latency Low Loss Streaming using In-Network Coding andSecurity Considerations</title>Caching</title> <author initials="K"surname="Pentikousis"/> <author initials="" surname="et al."/> <date month="July" year="2019"/> </front> <seriesInfo name="RFC" value="7945"/> </reference> <reference anchor="RFC6363"> <front> <title> Forward Error Correction (FEC) Framework</title>surname="Matsuzono" fullname="Kazuhisa Matsuzono"/> <authorinitials="M" surname="Watson"/>initials="H" surname="Asaeda" fullname="Hitoshi Asaeda"/> <authorinitials="" surname="et al."/>initials="T" surname="Turletti" fullname="Thierry Turletti"/> <datemonth="Oct." year="2011"/>month="May" year="2017"/> </front> <refcontent>Proc. Infocom, IEEE</refcontent> <seriesInfoname="RFC" value="6363"/>name="DOI" value="10.1109/INFOCOM.2017.8057026"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6363.xml"/> <reference anchor="Thomos12"> <front> <title>TowardoneOne Symbol Network Coding Vectors</title> <author initials="N"surname="Thomos"/>surname="Thomos" fullname="Nikolaos Thomos"/> <author initials="P"surname="Frossard"/>surname="Frossard" fullname="Pascal Frossard"/> <date month="November" year="2012"/> </front><seriesInfo name="IEEE<refcontent>IEEE Communicationsletters," value="vol.Letters, vol. 16, no.11"/>11</refcontent> <seriesInfo name="DOI" value="10.1109/LCOMM.2012.092812.121661"/> </reference> <reference anchor="Lucani14"> <front> <title>Fulcrum Network Codes: A Code for Fluid Allocation of Complexity</title> <authorinitials="D.E" surname="Lucani"/>initials="D" surname="Lucani" fullname="Daniel E. Lucani"/> <authorinitials="M.V." surname="Pedersen"/>initials="M" surname="Pedersen" fullname="Morten V. Pedersen"/> <author initials="D" surname="Ruano" fullname="Diego Ruano"/> <author initials="C" surname="Sørensen" fullname="Chres W. Sørensen"/> <author initials="J"surname="Heide"/>surname="Heide" fullname="Janus Heide"/> <authorinitials="F.H.P" surname="Fitzek"/>initials="F" surname="Fitzek" fullname="Frank H. P. Fitzek"/> <author initials="O" surname="Geil" fullname="Olav Geil"/> <date month="April" year="2014"/> </front> <seriesInfoname="" value="available at http://arxiv.org/abs/1404.6620"/>name="DOI" value="10.48550/arXiv.1404.6620"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.irtf-icnrg-flic.xml"/> <reference anchor="Ali16"> <front> <title>Coding for Caching: Fundamental Limits and Practical Challenges</title> <author initials="M" surname="Maddah-Ali" fullname="Mohammad Ali Maddah-Ali"/> <author initials="U" surname="Niesen" fullname="Urs Niesen"/> <date month="August" year="2016"/> </front> <refcontent>IEEE Communications Magazine, vol. 54, no. 8</refcontent> <seriesInfo name="DOI" value="10.1109/MCOM.2016.7537173"/> </reference> <reference anchor="Perino11"> <front> <title>A reality check for content centric networking</title> <author initials="D"surname="Perino"/>surname="Perino" fullname="Diego Perino"/> <author initials="M"surname="Varvello"/>surname="Varvello" fullname="Matteo Varvello"/> <date month="August" year="2011"/> </front><seriesInfo name="Proc.<refcontent>Proc. SIGCOMM Workshop on Information-centric networking(ICN'11)," value="ACM"/> </reference> <reference anchor="Wu16"> <front> <title>Privacy-Aware Multipath Video Caching for Content-Centric Networks</title> <author initials="Q" surname="Wu"/> <author initials="Z" surname="Li"/> <author initials="G" surname="Tyson"/> <author initials="S" surname="Uhlig"/> <author initials="M.A." surname="Kaafar"/> <author initials="G" surname="Xie"/> <date month="June" year="2016"/> </front> <seriesInfo name="IEEE Journal of Selected Area (JSAC)" value="vol. 38, no. 8"/> </reference> <reference anchor="RiHopAuth"> <front> <title>DCAuth: Data-Centric Authentication for Secure In-Network Big-Data Retrieval</title> <author initials="R" surname="Li"/> <author initials="H" surname="Asaeda"/> <author initials="J" surname="Wu"/> <date month="September" year="2018"/> </front>(ICN '11), ACM</refcontent> <seriesInfoname="IEEE Trans. on Network Science and Engineering" value="vol. 7, no. 1" /> </reference> <reference anchor="Wu04"> <front> <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"> <front> <title>A Random Linear Network Coding Approach to Multicast</title> <author initials="T" surname="Ho"/> <author initials="M" surname="Medard"/> <author initials="R" surname="Koetter"/> <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> <seriesInfo name="IEEE Trans. Information Theory," value="vol. 52, no.10"/>name="DOI" value="10.1145/2018584.2018596"/> </reference> <reference anchor="Podlipnig03"> <front> <title>A Survey of Web Cache Replacement Strategies</title> <author initials="S"surname="Podlipnig"/>surname="Podlipnig" fullname="Stefan Podlipnig"/> <authorinitials="L.B" surname="Osz"/>initials="L" surname="Böszörmenyi" fullname="Laszlo Böszörmenyi"/> <date month="December" year="2003"/> </front><seriesInfo name="Proc.<refcontent>Proc. ACM ComputingSurveys" value="vol.Surveys, vol. 35, no.4"/>4</refcontent> <seriesInfo name="DOI" value="10.1145/954339.954341"/> </reference> <reference anchor="Rossini13"> <front> <title>Evaluating CCN multi-path interest forwarding strategies</title> <author initials="G"surname="Rossini"/>surname="Rossini" fullname="Giuseppe Rossini"/> <author initials="D"surname="Rossi"/>surname="Rossi" fullname="Dario Rossi"/> <date month="April" year="2013"/> </front><seriesInfo name="Elsevier<refcontent>Elsevier ComputerCommunication," value="vol.36,Communications, vol. 36, no.7"/> </reference> <!-- <reference anchor="Chai12"> <front> <title>Cache Less for More in Information-centric Networks</title> <author initials="W.K." surname="Chai"/> <author initials="D" surname="He"/> <author initials="I" surname="Psaras"/> <author initials="G" surname="Pavlou"/> <date month="April" year="2013"/> </front>7</refcontent> <seriesInfoname="Journal Computer Communications," value="vol. 37. no. 7"/>name="DOI" value="10.1016/j.comcom.2013.01.008"/> </reference>--><referenceanchor="Carofiglio16">anchor="acm-mpath-cc"> <front><title>Leveraging<title>MIRCC: Multipath-aware ICNIn-network Control for Loss Detection and Recovery in Wireless Mobile networks</title> <author initials="G" surname="Carofiglio"/> <author initials="L" surname="Muscariello"/> <author initials="M" surname="Papalini"/> <author initials="N" surname="Rozhnova"/> <author initials="X" surname="Zeng"/> <date month="September" year="2016"/> </front> <seriesInfo name="Proc. ICN" value="ACM"/> </reference> <reference anchor="Ali16"> <front> <title>Coding for Caching: Fundamental Limits and Practical Challenges</title>Rate-based Congestion Control</title> <author initials="M"surname="Ali"/> <author initials="U" surname="Niesen"/> <date month="August" year="2016"/> </front> <seriesInfo name="IEEE Communications Magazine" value="vol. 54, no. 8"/> </reference> <reference anchor="Koetter08"> <front> <title>An algebraic approach to network coding</title> <author initials="R" surname="Koetter"/> <author initials="F.R" surname="Kschischang"/> <date month="October" year="2003"/> </front> <seriesInfo name="IEEE Trans. Netw." value="vol.11, no.5"/> </reference> <reference anchor="Vyetrenko09"> <front> <title>Rate regions for coherent and noncoherent multisource network error correction</title>surname="Mahdian"/> <author initials="S"surname="Vyetrenko"/> <author initials="T" surname="Ho"/> <author initials="M" surname="Effros"/>surname="Arianfar"/> <author initials="J"surname="Kliewer"/>surname="Gibson"/> <authorinitials="E" surname="Erez"/>initials="D" surname="Oran"/> <datemonth="July" year="2009"/>month="September" year="2016"/> </front><seriesInfo name="Proc. International Symposium<refcontent>Proc. Conference onInformation Theory (ISIT)," value="IEEE"/>Information-Centric Networking (ICN), ACM</refcontent> <seriesInfo name="DOI" value="10.1145/2984356.2984365"/> </reference> <reference anchor="Pierre11"> <front> <title>On-the-Fly Erasure Coding for Real-Time Video Applications</title> <authorinitials="P.U" surname="Tournoux"/>initials="P" surname="Tournoux" fullname="Pierre Ugo Tournoux"/> <author initials="E"surname="Lochin"/>surname="Lochin" fullname="Emmanuel Lochin"/> <author initials="J"surname="Lacan"/>surname="Lacan" fullname="Jérôme Lacan"/> <author initials="A"surname="Bouabdallah"/>surname="Bouabdallah" fullname="Amine Bouabdallah"/> <author initials="V"surname="Roca"/>surname="Roca" fullname="Vincent Roca"/> <date month="August" year="2011"/> </front> <refcontent>IEEE Transactions on Multimedia, vol. 13, no. 4</refcontent> <seriesInfoname="IEEEname="DOI" value="10.1109/TMM.2011.2126564"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9265.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7945.xml"/> <reference anchor="RiHopAuth"> <front> <title>DCAuth: Data-Centric Authentication for Secure In-Network Big-Data Retrieval</title> <author initials="R" surname="Li" fullname="Ruidong Li"/> <author initials="H" surname="Asaeda" fullname="Hitoshi Asaeda"/> <author initials="J" surname="Wu" fullname="Jie Wu"/> <date month="September" year="2018"/> </front> <refcontent>IEEE Trans.Multimeda" value="vol.13, no.4"/>on Network Science and Engineering, vol. 7, no. 1</refcontent> <seriesInfo name="DOI" value="10.1109/TNSE.2018.2872049"/> </reference> </references><!-- Change Log v00 2006-03-15 EBD Initial version v01 2006-04-03 EBD Moved PI location back<section numbered="false" toc="default"> <name>Acknowledgments</name> <t>The authors would like toposition 1 - v3.1 of XMLmind is better with them at this location. v02 2007-03-07 AH removed extraneous nested_list attribute, other minor corrections v03 2007-03-09 EBD Added comments on null IANA sectionsthank ICNRG andfixed heading capitalization. Modified comments around figure to reflect non-implementation of figure indent control. Put in reference using anchor="DOMINATION". Fixed up the date specificationNWCRG members, especially <contact fullname="Marie-Jose Montpetit"/>, <contact fullname="David Oran"/>, <contact fullname="Vincent Roca"/>, and <contact fullname="Thierry Turletti "/>, for their valuable commentsto reflect current truth. v04 2007-03-09 AH Major changes: shortened discussion of PIs, added discussion of rfc include. v05 2007-03-10 EBD Added preamble to C program example to tell about ABNFandalternative images. Removed meta-characters from comments (causes problems). v06 2010-04-01 TT Changed ipr attribute values to latest ones. Changed date to year only, to be consistent with the comments. Updated the IANA guidelines reference from the I-D to the finished RFC. -->suggestions on this document.</t> </section> </back> </rfc>