< draft-irtf-nwcrg-nwc-ccn-reqs-06.txt		draft-irtf-nwcrg-nwc-ccn-reqs-07.txt >
	Network Coding Research Group K. Matsuzono		Network Coding Research Group K. Matsuzono
	Internet-Draft H. Asaeda		Internet-Draft H. Asaeda
	Intended status: Informational NICT		Intended status: Informational NICT
	Expires: January 28, 2022 C. Westphal		Expires: April 27, 2022 C. Westphal
	Huawei		Huawei
	July 27, 2021		October 24, 2021
	Network Coding for Content-Centric Networking / Named Data Networking:		Network Coding for Content-Centric Networking / Named Data Networking:
	Considerations and Challenges		Considerations and Challenges
	draft-irtf-nwcrg-nwc-ccn-reqs-06		draft-irtf-nwcrg-nwc-ccn-reqs-07
	Abstract		Abstract
	This document describes the current research outcomes in Network		This document describes the current research outcomes in Network
	Coding (NC) for Content-Centric Networking (CCNx) / Named Data		Coding (NC) for Content-Centric Networking (CCNx) / Named Data
	Networking (NDN), and clarifies the technical considerations and		Networking (NDN), and clarifies the technical considerations and
	potential challenges for applying NC in CCNx/NDN. This document is		potential challenges for applying NC in CCNx/NDN. This document is
	the product of the Coding for Efficient Network Communications		the product of the Coding for Efficient Network Communications
	Research Group (NWCRG) and the Information-Centric Networking		Research Group (NWCRG) and the Information-Centric Networking
	Research Group (ICNRG).		Research Group (ICNRG).
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 28, 2022.		This Internet-Draft will expire on April 27, 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 16 ¶		skipping to change at page 2, line 16 ¶
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Definitions related to NC . . . . . . . . . . . . . . . . 4		2.1. Definitions related to NC . . . . . . . . . . . . . . . . 4
	2.2. Definitions related to CCNx/NDN . . . . . . . . . . . . . 6		2.2. Definitions related to CCNx/NDN . . . . . . . . . . . . . 6
	3. CCNx/NDN Basics . . . . . . . . . . . . . . . . . . . . . . . 7		3. CCNx/NDN Basics . . . . . . . . . . . . . . . . . . . . . . . 6
	4. NC Basics . . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. NC Basics . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Advantages of NC and CCNx/NDN . . . . . . . . . . . . . . . . 9		5. Advantages of NC and CCNx/NDN . . . . . . . . . . . . . . . . 8
	6. Technical Considerations . . . . . . . . . . . . . . . . . . 10		6. Technical Considerations . . . . . . . . . . . . . . . . . . 9
	6.1. Content Naming . . . . . . . . . . . . . . . . . . . . . 10		6.1. Content Naming . . . . . . . . . . . . . . . . . . . . . 9
	6.2. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11		6.2. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11
	6.2.1. Scope of NC . . . . . . . . . . . . . . . . . . . . . 11		6.2.1. Scope of NC . . . . . . . . . . . . . . . . . . . . . 11
	6.2.2. Consumer Operation . . . . . . . . . . . . . . . . . 12		6.2.2. Consumer Operation . . . . . . . . . . . . . . . . . 11
	6.2.3. Router Operation . . . . . . . . . . . . . . . . . . 12		6.2.3. Forwarder Operation . . . . . . . . . . . . . . . . . 12
	6.2.4. Publisher Operation . . . . . . . . . . . . . . . . . 13		6.2.4. Producer Operation . . . . . . . . . . . . . . . . . 13
	6.2.5. Backward Compatibility . . . . . . . . . . . . . . . 14		6.2.5. Backward Compatibility . . . . . . . . . . . . . . . 14
	6.3. In-network Caching . . . . . . . . . . . . . . . . . . . 14		6.3. In-network Caching . . . . . . . . . . . . . . . . . . . 14
	6.4. Seamless Consumer Mobility . . . . . . . . . . . . . . . 14		6.4. Seamless Consumer Mobility . . . . . . . . . . . . . . . 15
	7. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 15		7. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 15
	7.1. Adoption of Convolutional Coding . . . . . . . . . . . . 15		7.1. Adoption of Convolutional Coding . . . . . . . . . . . . 15
	7.2. Rate and Congestion Control . . . . . . . . . . . . . . . 16		7.2. Rate and Congestion Control . . . . . . . . . . . . . . . 16
	7.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 16		7.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 16
	7.4. Routing Scalability . . . . . . . . . . . . . . . . . . . 17		7.4. Routing Scalability . . . . . . . . . . . . . . . . . . . 17
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 18		8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	9. Informative References . . . . . . . . . . . . . . . . . . . 19		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
			10. Informative References . . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	Information-Centric Networking (ICN) in general, and Content-Centric		Information-Centric Networking (ICN) in general, and Content-Centric
	Networking (CCNx) [16] or Named Data Networking (NDN) [18] in		Networking (CCNx) [16] or Named Data Networking (NDN) [19] in
	particular, have emerged as a novel communication paradigm advocating		particular, have emerged as a novel communication paradigm advocating
	the retrieval of data based on their names. This paradigm pushes		the retrieval of data based on their names. This paradigm pushes
	content awareness into the network layer. It is expected to enable		content awareness into the network layer. It is expected to enable
	consumers to obtain the content they desire in a straightforward and		consumers to obtain the content they desire in a straightforward and
	efficient manner from the heterogenous networks they may be connected		efficient manner from the heterogenous networks they may be connected
	to. The CCNx/NDN architecture has introduced innovative ideas and		to. The CCNx/NDN architecture has introduced innovative ideas and
	has stimulated research in a variety of areas, such as in-network		has stimulated research in a variety of areas, such as in-network
	caching, name-based routing, multipath transport, content security.		caching, name-based routing, multipath transport, content security.
	One key benefit of requesting content by name is that it eliminates		One key benefit of requesting content by name is that it eliminates
	the requirement of establishing a session between the client and a		the requirement of establishing a session between the client and a
	specific server, and the content can thereby be retrieved from		specific server, and the content can thereby be retrieved from
	multiple sources.		multiple sources.
	In parallel, there has been a growing interest in both academia and		In parallel, there has been a growing interest in both academia and
	industry for better understanding the fundamental aspects of Network		industry for better understanding the fundamental aspects of Network
	Coding (NC) toward enhancing key system-performance metrics such as		Coding (NC) toward enhancing key system performance metrics such as
	data throughput, robustness and reduction in the required number of		data throughput, robustness and reduction in the required number of
	transmissions through connected networks, and point-to-multipoint		transmissions through connected networks, and redundant transmission
	connections. NC is a technique that is typically used for encoding		on broadcast or point-to-multipoint connections. NC is a technique
	packets for recovering lost source packets at the receiver, and for		that is typically used for encoding packets to recover from lost
	effectively obtaining the desired information in a fully distributed		source packets at the receiver, and for effectively obtaining the
	manner. In addition, NC can be used for security enhancements [2]		desired information in a fully distributed manner. In addition, NC
	[3] [4] [5].		can be used for security enhancements [2] [3] [4] [5].
	From the perspective of the NC transport mechanism, NC can be		From the perspective of the NC transport mechanism, NC can be divided
	categorized into two major categories: coherent NC, and non-coherent		into two major categories: coherent NC, and non-coherent NC [39]. In
	NC [37]. In coherent NC, the source and destination nodes know the		coherent NC, the source and destination nodes know the exact network
	exact network topology and the coding operations at intermediate		topology and the coding operations at intermediate nodes. When
	nodes. When multiple consumers are attempting to receive the same		multiple consumers are attempting to receive the same content such as
	content such as live video streaming, coherent NC could enable		live video streaming, coherent NC could enable optimal throughput by
	optimal throughput sending the content flow over the constructed		sending the content flow over the constructed optimal multicast trees
	optimal multicast trees [31]. However, it requires a fully		[33]. However, it requires a fully adjustable and specific routing
	adjustable and specific routing mechanism, and a large computational		mechanism, and a large computational capacity for central
	capacity for central coordination. In the case of non-coherent NC,		coordination. In the case of non-coherent NC, that often comprises
	that often comprises the use of Random Linear Coding (RLC), it is not		the use of Random Linear Coding (RLC), it is not necessary to know
	necessary to know the network topology nor the intermediate coding		the network topology nor the intermediate coding operations [34]. As
	operations [32]. As non-coherent NC works in a completely		non-coherent NC works in a completely independent and decentralized
	independent and decentralized manner, this approach is more feasible		manner, this approach is more feasible especially in the large-scale
	especially in the large-scale use cases.		use cases.
	NC combines multiple packets together with parts of the same content,		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.		and may do this at the source or at other nodes in the network.
	Network coded packets are not connected to a specific server, as they		Network coded packets are not associated with a specific server, as
	may have been combined within the network. As NC is focused on what		they may have been combined within the network. As NC is focused on
	information should be encoded in a network packet instead of the		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		specific host at which it has been generated, it is in line with the
	CCNx/NDN core networking layer. NC has already been implemented for		architecture of the CCNx/NDN core networking layer. NC has already
	information/content dissemination [6] [7] [8]. Montpetit, et al.,		been implemented for information/content dissemination [6] [7] [8].
	first suggested that NC techniques be exploited to enhance key system		Montpetit, et al., first suggested that NC techniques be exploited to
	performances in ICN [9]. NC provides CCNx/NDN with the highly		enhance key aspects of system performance in ICN [9]. NC provides
	beneficial potential of effectively disseminating information in a		CCNx/NDN with the highly beneficial potential of effectively
	completely independent and decentralized manner.		disseminating information in a completely topology independent and
			decentralized manner.
	In this document, we consider how NC can be applied to the CCNx/NDN		In this document, we consider how NC can be applied to the CCNx/NDN
	architecture and describe the technical considerations and potential		architecture and describe the technical considerations and potential
	challenges for making CCNx/NDN-based communications better using the		challenges for making CCNx/NDN-based communications better using the
	NC technology. It should be noted that the presentation of specific		NC technology. It should be noted that the presentation of specific
	solutions (e.g., NC optimization methods) for enhancing CCNx/NDN		solutions (e.g., NC optimization methods) for enhancing CCNx/NDN
	performance metrics by exploiting NC is outside the scope of this		performance metrics by exploiting NC is outside the scope of this
	document.		document.
	This document represents the collaborative work and consensus of the		This document represents the collaborative work and consensus of the
	Coding for Efficient Network Communications Research Group (NWCRG)		Coding for Efficient Network Communications Research Group (NWCRG)
	and the Information-Centric Networking Research Group (ICNRG). It is		and the Information-Centric Networking Research Group (ICNRG). It is
	not an IETF product and is not a standard.		not an IETF product and is not a standard.
	2. Terminology		2. Terminology
	This section provides the terminology definitions related to NC and		This section provides the terms related to NC and CCNx/NDN used in
	CCNx/NDN used in this document.		this document.
	2.1. Definitions related to NC		2.1. Definitions related to NC
	The terminologies regarding NC used in this document are defined as		The terms regarding NC used in this document are defined as follows.
	follows. These are aligned with RFCs produced by the FEC Framework		These are aligned with RFCs produced by the FEC Framework (FECFRAME)
	(FECFRAME) IETF Working Groups as well as IRTF Coding for Efficient		IETF Working Groups as well as IRTF Coding for Efficient Network
	Network Communications Research Group (NWCRG)[21].		Communications Research Group (NWCRG)[22].
	The definitions of the general terminologies used are as follows:
	o Source Packet: A packet originating from the source that		o Source Packet: A packet originating from the source that
	contributes to one or more source symbols. The source symbol is a		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		unit of data originating from the source that is used as input to
	encoding operations. For instance, a real-time transport protocol		encoding operations. For instance, a real-time transport protocol
	(RTP) packet as a whole can constitute a source symbol. In other		(RTP) packet as a whole can constitute a source symbol. In other
	situations (e.g., to address variable size packets), a single RTP		situations (e.g., to address variable size packets), a single RTP
	packet may contribute to various source symbols.		packet may contribute to various source symbols.
	o Coded Packet, or Repair Packet: A packet containing one or more		o Coded Packet, or Repair Packet: A packet containing one or more
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	rank of the linear system (also called degrees of freedom) at a		rank of the linear system (also called degrees of freedom) at a
	receiver.		receiver.
	o Encoding versus Re-coding versus Decoding: Encoding is an		o Encoding versus Re-coding versus Decoding: Encoding is an
	operation that takes source symbols as input and produces encoding		operation that takes source symbols as input and produces encoding
	symbols (source or coded symbols) as output. Re-coding is an		symbols (source or coded symbols) as output. Re-coding is an
	operation that takes encoding symbols as input and produces		operation that takes encoding symbols as input and produces
	encoding symbols as output. Decoding is an operation takes		encoding symbols as output. Decoding is an operation takes
	encoding symbols as input and produces source symbols as output.		encoding symbols as input and produces source symbols as output.
	The terminology definitions regarding coding types are as follows:		The terms regarding coding types are defined as follows:
	o Random Linear Coding (RLC): Particular case of linear coding using		o Random Linear Coding (RLC): A particular form of linear coding
	a set of random coding coefficients. Linear coding linearly		using a set of random coding coefficients. Linear coding linearly
	combines a set of input source and/or coded symbols using a given		combines a set of input source and/or coded symbols using a given
	set of coefficients and resulting in a coded symbol. Many linear		set of coefficients and resulting in a coded symbol. Many linear
	codes exist that differ from the way coding coefficients are drawn		codes exist that differ from the way coding coefficients are drawn
	from a finite field of a given size.		from a finite field of a given size.
	o Block Coding: Coding technique wherein the input flow(s) must be		o Block Coding: A coding technique wherein the input flow(s) must be
	first segmented into a sequence of blocks; encoding and decoding		first segmented into a sequence of blocks; encoding and decoding
	are performed independently on a per-block basis.		are performed independently on a per-block basis.
	o Sliding Window Coding or Convolutional Coding: General class of		o Sliding Window Coding or Convolutional Coding: A general class of
	coding techniques that rely on a sliding encoding window.		coding techniques that rely on a sliding encoding window.
	Encoding window is a set of source (and coded in the case of re-		Encoding window is a set of source (and coded in the case of re-
	coding) symbols used as input to the coding operations. The set		coding) symbols used as input to the coding operations. The set
	of symbols change over time, as the encoding window slides over		of symbols change over time, as the encoding window slides over
	the input flow(s). This is an alternative solution to block		the input flow(s). This is an alternative solution to block
	coding.		coding.
	o Fixed or Elastic Sliding Window Coding: Coding technique that		o Fixed or Elastic Sliding Window Coding: A coding technique that
	generates coded symbol(s) on the fly, from the set of source		generates coded symbol(s) on the fly, from the set of source
	symbols present in the sliding encoding window at that time,		symbols present in the sliding encoding window at that time,
	usually by using linear coding. The sliding window may be either		usually by using linear coding. The sliding window may be either
	of fixed size or of variable size over the time (also known as		of fixed size or of variable size over the time (also known as
	"Elastic Sliding Window"). For instance, the size may depend on		"Elastic Sliding Window"). For instance, the size may depend on
	acknowledgments sent by the receiver(s) for a particular source		acknowledgments sent by the receiver(s) for a particular source
	symbol or source packet (received, decoded, or decodable).		symbol or source packet (received, decoded, or decodable).
	The terminology definitions regarding low-level coding aspects are as		The terms regarding low-level coding aspects are defined as follows:
	follows:
	o Rank of the Linear System or Degrees of Freedom: At a receiver,		o Rank of the Linear System or Degrees of Freedom: At a receiver,
	the number of linearly independent equations of the linear system.		the number of linearly independent equations of the linear system.
	It is also known as "Degrees of Freedom". The system may be of		It is also known as "Degrees of Freedom". The system may be of
	"full rank," wherein decoding is possible, or "partial rank",		"full rank," wherein decoding is possible, or "partial rank",
	wherein only partial decoding is possible.		wherein only partial decoding is possible.
	o Generation, or Block: With block codes, the set of source symbols		o Generation, or Block: With block codes, the set of source symbols
	of the input flow(s) that are logically grouped into a block,		of the input flow(s) that are logically grouped into a block,
	before doing encoding.		before doing encoding.
	skipping to change at page 6, line 19 ¶		skipping to change at page 6, line 19 ¶
	o Coding Coefficient: With linear coding, this is a coefficient in a		o Coding Coefficient: With linear coding, this is a coefficient in a
	certain finite field. This coefficient may be chosen in different		certain finite field. This coefficient may be chosen in different
	ways: for instance, randomly, in a predefined table, or using a		ways: for instance, randomly, in a predefined table, or using a
	predefined algorithm plus a seed.		predefined algorithm plus a seed.
	o Coding Vector: A set of coding coefficients used to generate a		o Coding Vector: A set of coding coefficients used to generate a
	certain coded symbol through linear coding.		certain coded symbol through linear coding.
	o Finite Field: Finite fields, used in linear codes, have the		o Finite Field: Finite fields, used in linear codes, have the
	desired property of having all elements (except zero) invertible		desired property of having all elements (except zero) invertible
	for + and * and all operations over any elements do not result in		for + and * and no operation over any elements can result in an
	an overflow or underflow. Examples of finite fields are prime		overflow or underflow. Examples of finite fields are prime fields
	fields {0..p^m-1}, where p is prime. Most used fields use p=2 and		{0..p^m-1}, where p is prime. Most used fields use p=2 and are
	are called binary extension fields {0..2^m-1}, where m often		called binary extension fields {0..2^m-1}, where m often equals 1,
	equals 1, 4 or 8 for practical reasons.		4 or 8 for practical reasons.
	o Finite Field size: The number of elements in a finite field. For		o 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.		example the binary extension field {0..2^m-1} has size q=2^m.
	2.2. Definitions related to CCNx/NDN		2.2. Definitions related to CCNx/NDN
	The terminologies regarding CCNx/NDN used in this document are		The terminologies regarding CCNx/NDN used in this document are
	defined below. They are consistent with the RFCs produced by the		defined in RFC8793 [17] produced by ICNRG. They are consistent with
	Information-Centric Networking (ICNRG) IRTF Working Group[1] [17].		the relevant documents ([1][18]).
	o 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.
	o Content Object: A unit of content data delivered through the CCNx/
	NDN network.
	o Consumer: A node requesting a name (i.e., content). It initiates
	the name-based communication by sending an interest packet.
	o Publisher: A node that provides content. It originally creates or
	owns a content.
	o Router: An intermediate node between the consumer and producer
	that facilitates the name-based communication by forwarding
	interest and data packets.
	o Forwarding Information Base (FIB): A lookup table in a content
	router containing the name prefix and corresponding destination
	interface for forwarding the interest packets.
	o 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.
	o Content Store (CS): A storage space for a router to cache content
	objects.
	3. CCNx/NDN Basics		3. CCNx/NDN Basics
	We briefly explain the key concepts of CCNx/NDN. Both protocols are		We briefly explain the key concepts of CCNx/NDN. Both protocols are
	similar in principle, and also different in terms of some		similar in principle, but differ in some architecture and protocol
	implementation choices.		choices.
	In a CCNx network, there are two types of packets at the network		In a CCNx network, there are two types of packets at the network
	level: interest and data. The consumer requests a content object by		level: interest and data packet (defined in Section 3.4 of [17]).
	sending an interest that carries the name of the data. One		The term of content object, which means a unit of content data, is an
	difference to note here between CCNx and NDN is that in CCNx [17],		alias to data packet [17]. The ICN consumer (defined in Section 3.2
	the interest is required to carry a full name, while in NDN [19], it		of [17]) requests a content object by sending an interest that
	may carry a name prefix (and receive in return any data with a name		carries the name of the data. One difference to note here between
	matching this prefix).		CCNx and NDN is that in CCNx [18], the interest is required to carry
			a full name, while in NDN [20], it may carry a name prefix (and
			receive in return any data with a name matching this prefix).
	Once a router receives an interest, it performs a series of lookups:		Once an ICN forwarder (defined in Section 3.2 of [17]) receives an
	first it checks if it has a copy of the requested content object		interest, it performs a series of lookups: first it checks if it has
	available in the Content Store (CS). If it does, it returns the		a copy of the requested content object available in the Content Store
			(CS) (defined in Section 3.3 of [17]). If it does, it returns the
	data, and the transaction is considered to have been successfully		data, and the transaction is considered to have been successfully
	completed.		completed.
	If it does not have a copy of the requested content object in the CS,		If it does not have a copy of the requested content object in the CS,
	it performs a lookup of the PIT to check if there is already an		it performs a lookup of the Pending Interest Table (PIT) (defined in
	outgoing interest for the same content object. If there is no such		Section 3.3 of [17]) to check if there is already an outgoing
	interest, then it creates an entry in the PIT that lists the name		interest for the same content object. If there is no such interest,
	included in the interest, and the interfaces from which it received		then it creates an entry in the PIT that lists the name included in
	the interest. This is later used to send the content object back, as		the interest, and the interfaces from which it received the interest.
	interest packets do not carry a source field that identifies the		This is later used to send the content object back, as interest
	consumer. If there is already a PIT entry for this name, it is		packets do not carry a source field that identifies the consumer. If
	updated with the incoming interface of this new interest, and the		there is already a PIT entry for this name, it is updated with the
	interest is discarded.		incoming interface of this new interest, and the interest is
			discarded.
	After the PIT lookup, the interest undergoes a FIB lookup for		After the PIT lookup, the interest undergoes a Forwarding Information
	selecting an outgoing interface. The FIB lists name prefixes and		Base (FIB) (defined in Section 3.3 of [17]) lookup for selecting an
	their corresponding forwarding interfaces in order to send the		outgoing interface. The FIB lists name prefixes and their
	interface towards a router that possesses a copy of the requested		corresponding forwarding interfaces in order to send the interest
	data.		towards a forwarder that possesses a copy of the requested data.
	Once a copy of the data is retrieved, it is sent back to the		Once a copy of the data is retrieved, it is sent back to the
	consumer(s) using the trail of PIT entries; routers remove the PIT		consumer(s) using the trail of PIT entries; forwarders remove the PIT
	state every time that an interest is satisfied, and may store the		state every time that an interest is satisfied, and may store the
	data in their CS.		data in their CS.
	Data packets carry some information for validating the data, and in		Data packets carry some information for validating the data, and in
	particular, that the data is indeed that which corresponds to the		particular, that the data is indeed that which corresponds to the
	name. This is necessary because authentication of the object is		name. This is necessary because authentication of the object is
	crucial in CCNx/NDN. However, this step is optional at routers in		crucial in CCNx/NDN. However, this step is optional at forwarders in
	order to speed up the processing.		order to speed up the processing.
	The key aspect of CCNx/NDN is that the consumer of the content does		The key aspect of CCNx/NDN is that the consumer of the content does
	not establish a session with a specific server. Indeed, the router		not establish a session with a specific server. Indeed, the
	or publisher that returns the content object is not aware of the		forwarder or producer (defined in Section 3.2 of [17]) that returns
	network location of the consumer and the consumer is not aware of the		the content object is not aware of the network location of the
	network location of the node that provides the content. This, in		consumer and the consumer is not aware of the network location of the
	theory, allows the interests to follow different paths within a		node that provides the content. This, in theory, allows the
	network or even to be sent over completely different networks.		interests to follow different paths within a network or even to be
			sent over completely different networks.
	4. NC Basics		4. NC Basics
	While the forwarding node simply relays received data packets in		While the forwarding node simply relays received data packets in
	conventional IP communication networks, NC allows the node to combine		conventional IP communication networks, NC allows the node to combine
	some data packets that are already received into one or several		some data packets that are already received into one or several
	output packets to be sent. In this section, we simply describe the		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		basic operations of NC. Herein, we focus on RLC in a block coding
	manner that is well known as a major coding technique.		manner that is well known as a major coding technique.
	For simplicity, let us consider an example case of end-to-end coding		For simplicity, let us consider an example case of end-to-end coding
	wherein a publisher and consumer perform encoding and decoding for a		wherein a producer and consumer respectively perform encoding and
	content. This end-to-end coding is regarded as a special case of NC.		decoding for a content object. This end-to-end coding is regarded as
	The publisher splits the content into several blocks called		a special case of NC. The producer splits the content into several
	generations. Encoding and decoding are performed independently on a		blocks called generations. Encoding and decoding are performed
	per-block (per-generation) basis. Let us assume that each generation		independently on a per-block (per-generation) basis. Let us assume
	consists of K original source packets of the same size. When the		that each generation consists of K original source packets of the
	packets do not have the same size, zero padding is added. In order		same size. When the packets do not have the same size, zero padding
	to generate one coded packet within a certain generation, the		is added. In order to generate one coded packet within a certain
	publisher linearly combines K of the original source packets, where		generation, the producer linearly combines K of the original source
	additions and multiplications are performed using a coding vector		packets, where additions and multiplications are performed using a
	consisting of K coding coefficients that are randomly selected in a		coding vector consisting of K coding coefficients that are randomly
	certain finite field. The publisher may send some or all of the		selected in a certain finite field. The producer may respond to
	source packets as well as coded packets in the content flow (called		interests to send the corresponding source packets and coded packets
	systematic coding), where the coded packets (also called repair		in the content flow (called systematic coding), where the coded
	packets) are typically used for repairing lost source packets.		packets (also called repair packets) are typically used for repairing
			lost source packets.
	Coded packets can also be used for performing encoding. If the		Coded packets can also be used for performing encoding. If the
	forwarding nodes know each coding vector and generation identifier of		forwarding nodes know each coding vector and generation identifier of
	the received coded packets, they may perform an encoding operation		the received coded packets, they may perform an encoding operation
	(called re-coding), which is the most prominent operation in NC.		(called re-coding), which is the most distinctie feature of NC
			compared to other coding techniques.
	At the consumer, decoding is performed by solving a set of linear		At the consumer, decoding is performed by solving a set of linear
	equations that are represented by the coding vectors of the received		equations that are represented by the coding vectors of the received
	coded packets within a certain generation. In order to obtain all		coded packets within a certain generation. In order to obtain all
	the source packets, the consumer requires K linearly independent		the source packets, the consumer requires K linearly independent
	equations. In other words, the consumer must receive at least K		equations. In other words, the consumer must receive at least K
	linearly independent data packets (called innovative packets). As		linearly independent data packets (called innovative packets). As
	receiving a linearly dependent data packet is not useful for		receiving a linearly dependent data packet is not useful for
	decoding, re-coding should generate and provide innovative packets.		decoding, re-coding should generate and provide innovative packets.
	One of major benefits of RLC is that even for a small-sized finite		One of major benefits of RLC is that even for a small-sized finite
	field (e.g., q=2^8), the probability of generating linearly dependent		field (e.g., q=2^8), the probability of generating linearly dependent
	packets is negligible [31].		packets is negligible [33].
	5. Advantages of NC and CCNx/NDN		5. Advantages of NC and CCNx/NDN
	NC and CCNx/NDN can contribute to effective large-scale content/		Combining NC and CCNx/NDN can contribute to effective large-scale
	information dissemination. They both provide similar benefits such		content/information dissemination. They individually provide similar
	as throughput/capacity gain and robustness enhancement. The		benefits such as throughput/capacity gain and robustness enhancement.
	difference between their approaches is that, the former considers		The difference between their approaches is that, the former considers
	content flow as algebraic information that is to be combined [20],		content flow as algebraic information that is to be combined [21],
	while the latter focuses on the content/information itself at the		while the latter focuses on the content/information itself at the
	networking layer. Because these approaches are complementary and		networking layer. Because these approaches are complementary and
	their combination would be advantageous, it is natural to combine		their combination would be advantageous, it is natural to combine
	them.		them.
	The name-based communication in CCNx/NDN enables consumers to obtain		The name-based communication in CCNx/NDN enables consumers to obtain
	requested content objects without establishing and maintaining		requested content objects without establishing and maintaining end-
	continuous end-to-end communication channels between nodes. This		to-end communication channels between nodes. This feature
	feature facilitates the exploitation of the in-network cache and		facilitates the exploitation of the in-network cache and multipath/
	multipath/multisource retrieval and also supports consumer mobility		multisource retrieval and also supports consumer mobility without the
	without the need for updating the location information/identifier		need for updating the location information/identifier during handover
	during handover [16]. Furthermore, the name-based communication		[16]. Furthermore, the name-based communication intrinsically
	intrinsically supports multicast communication because identical		supports multicast communication because identical interests are
	interests are aggregated at the routers.		aggregated at the forwarders.
	CCNx/NDN does not provide reliable and robust content dissemination		NC can enable the CCNx/NDN transport system to effectively distribute
	by default. However, NC can enable the CCNx/NDN transport system to		and cache the data associated with multipath data retrieval [9].
	effectively distribute and cache the data associated with multipath		Exploiting multipath data retrieval and in-network caching with NC
	data retrieval [9]. Furthermore, NC can contribute to improving both		contributes to not only improving the cache hit rate but also
	the caching performance and cache privacy that CCNx/NDN newly		expanding the anonymity set of each consumer (the set of potential
	introduces at the networking layer [29]. Others also have introduced		routers that can serve a given consumer) [31]. The expansion makes
	some use cases of the application of NC in CCNx/NDN, such as the		it difficult for adversaries to infer the content consumed by others,
	cases of content dissemination with in-network caching [10] [13]		and thus contributes to improving cache privacy. Others also have
	[14], seamless consumer mobility [11] [35], and low-latency low-loss		introduced some use cases of the application of NC in CCNx/NDN, such
	video streaming [15]. In this context, it is well worth considering		as the cases of content dissemination with in-network caching [10]
	NC integration in CCNx/NDN.		[13] [14], seamless consumer mobility [11] [37], and low-latency low-
			loss video streaming [15]. In this context, it is well worth
			considering NC integration in CCNx/NDN.
	6. Technical Considerations		6. Technical Considerations
	This section presents the considerations for CCNx/NDN with NC in		This section presents the considerations for CCNx/NDN with NC in
	terms of network architecture and protocol. This document focuses on		terms of network architecture and protocol. This document focuses on
	NC in a block coding manner.		NC when employed in a block coding manner.
	6.1. Content Naming		6.1. Content Naming
	Naming content objects is as important for CCNx/NDN as naming hosts		Naming content objects is as important for CCNx/NDN as naming hosts
	is in the current-day Internet [23]. In this section, two possible		is in the current-day Internet [25]. In this section, two possible
	naming schemes are presented.		naming schemes are presented.
	Each coded packet may have a unique name as content objects (original		Each coded packet may have a unique name as content objects (original
	source packets) has in CCNx/NDN, as PIT/CS operations typically		source packets) has in CCNx/NDN, as PIT/CS operations typically
	require a unique name for identifying the coded packet. As a method		require a unique name for identifying the coded packet. As a method
	of naming a coded packet, the coding vector and the identifier of the		of naming a coded packet, the coding vector and the identifier of the
	generation (also called block) can be used as a part of the content		generation (also called block) can be used as a part of the content
	object name. As in [10], when the generation ID is "g-id",		object name. As in [10], when the generation ID is "g-id",
	generation size is 4, and coding vector is (1,0,0,0), the name could		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		be /CCNx.com/video-A/g-id/1000. Some other identifiers and/or
	parameters related to the encoding scheme can also be used as the		parameters related to the encoding scheme can also be used as name
	name components. For instance, the encoding ID specifying the coding		components. For instance, the encoding ID specifying the coding
	scheme may be used with "enc-id" such as /CCNx.com/video-A/enc-id/		scheme may be used with "enc-id" such as /CCNx.com/video-A/enc-id/
	g-id/1000, as defined in the FEC Framework (FECFRAME) [25]. This		g-id/1000, as defined in the FEC Framework (FECFRAME) [27]. This
	naming scheme is simple and can support the delivery of coded packets		naming scheme is simple and can support the delivery of coded packets
	with exactly the same operations in the PIT/CS as those for the		with exactly the same operations in the PIT/CS as those for the
	content objects.		content objects.
	If a content-naming schema such as the one presented above is used,		If a content-naming schema such as the one presented above is used,
	an interest requesting a coded packet may have the full name		an interest requesting a coded packet may have the full name
	including a generation id and coding vector (/CCNx.com/video-A/		including a generation id and coding vector (/CCNx.com/video-A/
	g-id/1000) or only the name prefix including only a generation id		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		(/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). The		the PIT is simply performed at data forwarders (as in CCNx). The
	consumer is enabled to specify and retrieval an innovative packet		consumer is enabled to specify and retrieve an innovative packet
	necessary for the consumer. This could shift the generation of the		necessary for the consumer to decode successfully. This could shift
	coding vector from the data forwarder onto the consumer.		the generation of the coding vector from the data forwarder onto the
			consumer.
	In the latter case, partial name matching is required at the data		In the latter case, partial name matching is required at the data
	forwarders (as in the case of NDN). As the interest with only the		forwarders (as in the case of NDN). As the interest with only the
	prefix name matches any coded packet with the generation ID, the		prefix name matches any coded packet with the generation ID, the
	consumer could immediately obtain an coded packet from a nearby CS		consumer could immediately obtain an coded packet from a nearby CS
	(in-network cache) without knowing the coding vectors of the cached		(in-network cache) without knowing the coding vectors of the cached
	coded packets in advance. In the case wherein coded packets in		coded packets in advance. In the case wherein coded packets in
	transit are modified by in-network re-coding performed at routers,		transit are modified by in-network re-coding performed at forwarders,
	the consumer could also receive the modified coded packets. However,		the consumer could also receive the modified coded packets. However,
	in contrast to the former case, the consumer may fail to obtain		in contrast to the former case, the consumer may fail to obtain
	sufficient degrees of freedom (see Section 6.2.3). To address this		sufficient degrees of freedom (see Section 6.2.3). To address this
	issue, a new TLV type of interest message may be required for		issue, a new TLV type in an interest message may be required for
	specifying further coding information in order to limit the coded		specifying further coding information in order to limit the coded
	packets to be received. For instance, this is enabled by specifying		packets to be received. For instance, this is enabled by specifying
	the coding vectors of innovative packets for the consumer (also		the coding vectors of innovative packets for the consumer (also
	called decoding matrix) as in [9]. This extension may incur an		called decoding matrix) as in [9]. This extension may incur an
	interest packet of significantly increased size, and it may thus be		interest packet of significantly increased size, and it may thus be
	useful to use compression techniques for coding vectors [26] [27].		useful to use compression techniques for coding vectors [28] [29].
	Without such coding information provided by the interest, the		Without such coding information provided by the interest, the
	forwarder would be required to maintain some records regarding the		forwarder would be required to maintain some records regarding the
	interest packets that were satisfied previously (See Section 6.2.3).		interest packets that were satisfied previously (See Section 6.2.3).
	A coded packet may have a name that indicates that it is a coded		A coded packet may have a name that indicates that it is a coded
	packet, and move the coding information into a metadata field in the		packet, and move the coding information into a metadata field in the
	payload (i.e., the name includes the data type, source or coded		payload (i.e., the name includes the data type, source or coded
	packet). This would not be beneficial for applications or services		packet). This would not be beneficial for applications or services
	that may not need to understand the packet payload. Owing to the		that may not need to understand the packet payload. Owing to the
	possibility that multiple coded packets may have the same name, some		possibility that multiple coded packets may have the same name, some
	mechanism is required for the consumer to obtain innovative packets.		mechanism is required for the consumer to obtain innovative packets.
	As described in Section 6.3, a mechanism for managing the multiple		As described in Section 6.3, a mechanism for managing the multiple
	innovative packets in the CS would also be required. In addition,		innovative packets in the CS would also be required. In addition,
	extra computational overhead would be incurred when the payload is		extra computational overhead would be incurred when the payload is
	being encrypted.		being encrypted.
	6.2. Transport		6.2. Transport
	The pull-based request--response feature of CCNx/NDN is a fundamental		The pull-based request-response feature of CCNx/NDN is a fundamental
	principle of its transport layer; one interest retrieves at most one		principle of its transport layer; one interest retrieves at most one
	data packet. It is believed that it is important that this rule not		data packet. This property prevents consumer or forwarder to inject
	be violated, as it would open denial-of -service (Dos) attacks, and		large amounts of unrequested data into the network. It is believed
	thus, the following basic operation should be considered for applying		that it is important that this rule not be violated, as 1) it would
	NC to CCNx/NDN. Nevertheless, such security considerations should be		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.		addressed if this rule were to be violated.
	6.2.1. Scope of NC		6.2.1. Scope of NC
	It should be discussed whether data forwarder can perform in-network		An open question is whether data forwarder can perform in-network re-
	re-coding with data packets that are being received in transit, or if		coding with data packets that are being received in transit, or if
	only the data that matches an interest can be subject to NC		only the data that matches an interest can be subject to NC
	operations. In the latter case, encoding or re-coding is performed		operations. In the latter case, encoding or re-coding is performed
	to generate the coded packet at any forwarder that is able to respond		to generate the coded packet at any forwarder that is able to respond
	to the interest. This could occur when each coded packet has a		to the interest. This could occur when each coded packet has a
	unique name and interest has the full name. On the other hand, if		unique name and interest has the full name. On the other hand, if
	interest has a partial name without any coding vector information or		interest has a partial name without any coding vector information or
	coded packets have a same name, the former case may occur; re-coding		coded packets have a same name, the former case may occur; re-coding
	occurs anywhere in the network where it is possible to modify the		occurs anywhere in the network where it is possible to modify the
	received coded packet and forward it. As CCNx/NDN comprises		received coded packet and forward it. As CCNx/NDN comprises
	mechanisms for ensuring the integrity of the data during transfer,		mechanisms for ensuring the integrity of the data during transfer,
	in-network re-coding introduces complexities in the network that		in-network re-coding introduces complexities in the network that
	would require the consideration of the integrity mechanisms to still		needs consideration for the integrity mechanisms to still work.
	work. Similarly, in-network caching of coded packets at routers may		Similarly, in-network caching of coded packets at forwarders may be
	be valuable; however, the routers would require some mechanisms to		valuable; however, the forwarders would require some mechanisms to
	validate the coded packets (see Section 8).		validate the coded packets (see Section 8).
	6.2.2. Consumer Operation		6.2.2. Consumer Operation
	To obtain NC benefits (possibly associated with in-network caching),		To obtain NC benefits (possibly associated with in-network caching),
	the consumer is required to issue interests that direct the router		the consumer is required to issue interests that direct the forwarder
	(or publisher) to forward innovative packets if available. When		(or producer) to respond with innovative packets if available. In
	issuing an interest specifying a unique name with g-id and the coding		the case where each coded packet may have a unique name (as described
	vector for a coded packet, the consumer could appropriately receive		in Section 6.1), by issuing an interest specifying a unique name with
	an innovative packet if it is available at some forwarders. However,		g-id and the coding vector for a coded packet, the consumer could
	the consumer is required to know the naming structure (through a		appropriately receive an innovative packet if it is available at some
	specific name resolution scheme for instance) in order to specify the		forwarders.
	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		In order to specify the exact name of the coded packet to be
	at the publisher, some specific scheme would be required to be used.		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 [1]
			that enumerates the content objects including coded packets, or may
			use some coding scheme specifier as a name component to construct the
			name components of interests to request innovative packets.
	Conversely, the consumer without decoding capability (e.g., specific		Conversely, the consumer without decoding capability (e.g., specific
	sensor node) may want to receive only the source packets. As		sensor node) may want to receive only the source packets. As
	described in Section 6.1, because the coded packet can have a name		described in Section 6.1, because the coded packet can have a name
	that is explicitly different from source packets, issuing interests		that is explicitly different from source packets, issuing interests
	for retrieving source packets is possible. In NDN, if the interest		for retrieving source packets is possible.
	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.
	6.2.3. Router Operation		6.2.3. Forwarder Operation
	If the router constantly responds to the incoming interests by		If the forwarder constantly responds to the incoming interests by
	returning non-innovative packets, the consumer(s) cannot decode and		returning non-innovative packets, the consumer(s) cannot decode and
	obtain the source packets for all time. This issue could happen when		obtain the source packets for all time. This issue could happen when
	1) incoming interests for coded packets do not specify some coding		1) incoming interests for coded packets do not specify some coding
	parameters such as the coding vectors to be used, and 2) the router		parameters such as the coding vectors to be used, and 2) the
	does not have a sufficient number of linearly independent source or		forwarder does not have a sufficient number of linearly independent
	coded packets (possibly in the CS) to use for re-coding. In this		source or coded packets (possibly in the CS) to use for re-coding.
	case, the router is required to determine whether or not it can		In this case, the forwarder is required to determine whether or not
	generate innovative packets to be forwarded to the interface(s) at		it can generate innovative packets to be forwarded to the
	which the interests arrived. An approach to deal with this issue is		interface(s) at which the interests arrived. An approach to deal
	that the router maintains a tally of the interests for a specific		with this issue is that the forwarder maintains a tally of the
	name, generation ID and the incoming interface(s), in order to record		interests for a specific name, generation ID and the incoming
	how many degrees of freedom have already been provided [10]. As such		interface(s), in order to record how many degrees of freedom have
	a scheme requires state management (and potentially timers) in		already been provided [10]. As such a scheme requires state
	routers, scalability and practicality should be considered. In		management (and potentially timers) in forwarders, scalability and
	addition, some transport mechanism of in-network loss detection and		practicality must be considered. In addition, some transport
	recovery [15] [35] at router as well as a consumer-driven mechanism		mechanism for in-network loss detection and recovery [15] [37] at
	could be indispensable for enabling fast loss recovery and enhancing		forwarder as well as a consumer-driven mechanism could be
	NC gains. After determining that an innovative packet cannot be		indispensable for enabling fast loss recovery and realising NC gains.
	provided, according to the FIB, the router relays the received		If a forwarder cannot either return a matching innovative packet from
	interests to the upstream router(s) or publisher to obtain innovative		its local content store, nor produce on-the-fly a recoded packet that
	packets. In this context, to retrieve innovative packet effectively		is innovative, it is important that the forwarder not simply return a
	and quickly, an appropriate setting of the FIB and efficient interest		non-innovative packet but instead do a forwarding lookup in its FIB
	forwarding strategies should also be considered.		and forward the Interest toward the producer or upstream forwarder
			that can provide an innovative packet. In this context, to retrieve
			innovative packet effectively and quickly, an appropriate setting of
			the FIB and efficient interest forwarding strategies should also be
			considered.
	In another possible case, when receiving interests only for source		In another possible case, when receiving interests only for source
	packets, the router may attempt to decode and obtain all the source		packets, the forwarder may attempt to decode and obtain all the
	packets and store them (if the full cache capacity are available),		source packets and store them (if the full cache capacity are
	thus enabling a faster response to the interests. As re-coding or		available), thus enabling a faster response to the interests. As re-
	decoding results in an extra computational overhead, the router is		coding or decoding results in an extra computational overhead, the
	required to determine how to respond to received interests according		forwarder is required to determine how to respond to received
	to the use case (e.g., a delay-sensitive or delay-tolerant		interests according to the use case (e.g., a delay-sensitive or
	application) and the router situation, such as available cache space		delay-tolerant application) and the forwarder situation, such as
	and computational capability.		available cache space and computational capability.
	6.2.4. Publisher Operation		6.2.4. Producer Operation
	Before performing NC for specified content in CCNx/NDN, the publisher		Before performing NC for specified content in CCNx/NDN, the producer
	is responsible for splitting the overall content into small content		is responsible for splitting the overall content into small content
	objects to avoid packet fragmentation that could cause unnecessary		objects to avoid packet fragmentation that could cause unnecessary
	packet processing and degraded throughput. The size of the content		packet processing and degraded throughput. The size of the content
	objects should be within the allowable packet size in order to avoid		objects should be within the allowable packet size in order to avoid
	packet fragmentation in CCNx/NDN network. The publisher performs the		packet fragmentation in CCNx/NDN network. The producer performs the
	encoding operation for a set of the small content objects, and the		encoding operation for a set of the small content objects, and the
	naming process for the coded packets.		naming process for the coded packets.
	If the producer takes the lead in determining the used coding vectors		If the producer takes the lead in determining what coding vectors to
	and generating the coding packets, there exists two possible end-to-		use in generating the coding packets, there are three general
	end coding cases; 1) consumers obtain the names of the coded packets		strategies for naming and producing the coded packets:
	through a certain mechanism, and send the corresponding interests
	toward the publisher to obtain the coded packets that have already		1. consumers themselves understand in detail the naming conventions
	been generated at the publisher; and 2) the publisher determines the		used for coded packets and thereby can send the corresponding
	coding vectors after receiving the interests specifying them. In the		interests toward the producer to obtain coded packets whose
	former case, although the consumers cannot flexibly specify a coding		coding parameters have already been determined by the producer.
	vector for generating the coded packet to obtain, the latency for
	obtaining the coded packet can be reduced as compared that in the		2. the producer determines the coding vectors and generates the
	latter case wherein additional NC operations are required to be		coded packets after receiving interests specifying the packets
	performed after receiving the interests. The common benefit in such		the consumer wished to receive.
	end-to-end coding cases is that if the publisher adds a signature on
	the coded packets, data validation becomes possible throughout as in		3. The naming scheme for specifying the coding vectors and
	the case of normal CCNx/NDN operations. According to the application		corresponding coded packets is explicitly represented via a
	requirement for latency, such an NC operation strategy should be		"Manifest" (e.g., FLIC [24]) that can be obtained by the consumer
	considered.		and used to select among the available coding vectors and their
			corresponding packets, and thereby send the corresponding
			interests.
			In the first case, although the consumers cannot flexibly specify a
			coding vector for generating the coded packet to obtain, the latency
			for obtaining the coded 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 coded packets to be included in the manifest must be pre-
			computed by the producer (since the manifest references coded packets
			by their hashes, not their names), but the producer can select which
			to include the manifest, and produce multiple manifests either in
			advance or on demand with different coding tradeoffs if so desired.
			A common benefit the first two approaches to end-to-end coding is
			that if the producer adds a signature on the coded packets, data
			validation becomes possible throughout (as is the case with CCNx/NDN
			operation in the absence of NC). The third approach of using a
			manifest trades off the additional latency incurred by the need to
			fetch the manifest against the efficiency of needing a signature only
			on the manifest and not on each individual coded packet.
	6.2.5. Backward Compatibility		6.2.5. Backward Compatibility
	NC operations should be applied in addition to the regular network		NC operations should be applied in addition to the regular network
	behavior. Hence, nodes should be able to not support network coding		behavior. Hence, nodes should be able to not support network coding
	(not only in forwarding the packets, but also in the caching		(not only in forwarding the packets, but also in the caching
	mechanism). NC operations should function alongside regular network		mechanism). NC operations should function alongside regular network
	operations. An NC framework should be compatible with a regular		operations. An NC framework should be compatible with a regular
	framework in order to facilitate backward compatibility and smooth		framework in order to facilitate backward compatibility and smooth
	migration from one framework to the other.		migration from one framework to the other.
	6.3. In-network Caching		6.3. In-network Caching
	Caching is a useful technique used for improving throughput and		Caching is a useful technique used for improving throughput and
	latency in various applications. In-network caching in CCNx/NDN		latency in various applications. In-network caching in CCNx/NDN
	essentially provides support at network level and is highly		essentially provides support at network level and is highly
	beneficial owing to the involved exploitation of NC for enabling		beneficial owing to the involved exploitation of NC for enabling
	effective multicast transmission [36], multipath data retrieval [10]		effective multicast transmission [38], multipath data retrieval [10]
	[11], fast loss recovery [15]. However, there remain several issues		[11], fast loss recovery [15]. However, there remain several issues
	to be considered.		to be considered.
	There generally exist limitations in the CS capacity, and the caching		There generally exist limitations in the CS capacity, and the caching
	policy affects the consumer's performances [28] [33] [34]. It is		policy affects the consumer's performance [30] [35] [36]. It is thus
	thus crucial for routers to determine which content objects should be		crucial for forwarders to determine which content objects should be
	cached and discarded. As delay-sensitive applications often do not		cached and which discarded. As delay-sensitive applications often do
	require an in-network cache for a long period owing to their real-		not require an in-network cache for a long period owing to their
	time constraints, routers have to know the necessity for caching		real-time constraints, forwarders have to know the necessity for
	received content objects to save the caching volume. In CCNx, this		caching received content objects to save the caching volume. In
	could be made possible by setting a Recommended Cache Time (RCT) in		CCNx, this could be made possible by setting a Recommended Cache Time
	the optional header of the data packet at the publisher side. The		(RCT) in the optional header of the data packet at the producer side.
	RCT serves as a guideline for the CS cache in determining how long to		The RCT serves as a guideline for the CS cache in determining how
	retain the content object. When the RCT is set as zero, the router		long to retain the content object. When the RCT is set as zero, the
	recognizes that caching the content object is meaningless.		forwarder recognizes that caching the content object is not useful.
	Conversely, the router may cache it when the RCT has a greater value.		Conversely, the forwarder may cache it when the RCT has a greater
	In NDN, the TLV type of FreshnessPeriod could be used.		value. In NDN, the TLV type of FreshnessPeriod could be used.
	One key aspect of in-network caching is whether or not routers can		One key aspect of in-network caching is whether or not forwarders can
	cache coded packets in their CS. They may be caching the coded		cache coded packets in their CS. They may be caching the coded
	packets without having the ability to perform a validation of the		packets without having the ability to perform a validation of the
	content objects. Therefore, the caching of the coded packets would		content objects. Therefore, the caching of the coded packets would
	require some mechanism to validate the coded packets (see Section 8).		require some mechanism to validate the coded packets (see Section 8).
	In the case wherein the coded packets have the same name, it would		In the case wherein the coded packets have the same name, it would
	also require some mechanism to identify them.		also require some mechanism to identify them.
	6.4. Seamless Consumer Mobility		6.4. Seamless Consumer Mobility
	A key feature of CCNx/NDN is that it is sessionless, which enables		A key feature of CCNx/NDN is that it is sessionless, which enables
	the consumer and router to send multiple interests to different		the consumer and forwarder to send multiple interests toward
	copies of the content in parallel, by using multiple interfaces at		different copies of the content in parallel, by using multiple
	the same time in an asynchronous manner. Through the multipath data		interfaces at the same time in an asynchronous manner. Through the
	retrieval, the consumer could obtain the content from multiple copies		multipath data retrieval, the consumer could obtain the content from
	that are distributed while using the aggregate capacity of multiple		multiple copies that are distributed while using the aggregate
	interfaces used. For the link between the consumer and the multiple		capacity of multiple interfaces. For the link between the consumer
	copies, the consumer can perform a certain rate adaptation mechanism		and the multiple copies, the consumer can perform a certain rate
	for video streaming [11] or congestion control for content		adaptation mechanism for video streaming [11] or congestion control
	acquisition [12].		for content acquisition [12].
	NC adds a reliability layer network to CCNx in a distributed and		NC adds a reliability layer to CCNx in a distributed and asynchronous
	asynchronous manner, because NC provides a mechanism for ensuring		manner, because NC provides a mechanism for ensuring that the
	that the interests sent to multiple copies of the content in parallel		interests sent to multiple copies of the content in parallel retrieve
	retrieve innovative packets, even in the case of packet losses on		innovative packets, even in the case of packet losses on some of the
	some of the paths/networks to these copies. This obviously applies		paths/networks to these copies. This applies to consumer mobility
	to consumer mobility events [11], wherein the consumer may connect		events [11], wherein the consumer could receive additional degrees of
	between multiple access points (APs) before a consumer mobility event		freedom with any innovative packet if at least one available
	(make-before-break handoff). In the case of such a consumer mobility		interface exists during the mobility event. An interest forwarding
	event, the consumer is first connected to the previous AP, then to		strategy at the consumer (and possibly forwarder) for efficiently
	both the previous and next APs, and then finally only to the next		obtaining innovative packets would be required for the consumer to
	APs. With CCNx, the consumer only sends interests on the available		achieve seamless consumer mobility.
	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 router) for efficiently obtaining innovative packets should
	be considered for the consumer to achieve seamless consumer mobility.
	7. Challenges		7. Challenges
	This section presents several primary challenges and research items		This section presents several primary challenges and research items
	to be considered when applying NC in CCNx/NDN.		to be considered when applying NC in CCNx/NDN.
	7.1. Adoption of Convolutional Coding		7.1. Adoption of Convolutional Coding
	Several block coding approaches have been proposed thus far; however,		Several block coding approaches have been proposed thus far; however,
	there is still no sufficient discussion and application of the		there is still not sufficient discussion and application of the
	convolutional coding approach (e.g., sliding or elastic window		convolutional coding approach (e.g., sliding or elastic window
	coding) in CCNx/NDN. Convolutional coding is often appropriate for		coding) in CCNx/NDN. Convolutional coding is often appropriate for
	situations wherein a fully or partially reliable delivery of		situations wherein a fully or partially reliable delivery of
	continuous data flows is required, and especially when these data		continuous data flows is required, and especially when these data
	flows feature realtime constraints. As in [38], on an end-to-end		flows feature realtime constraints. As in [40], on an end-to-end
	coding basis, it would be advantageous for continuous content flow to		coding basis, it would be advantageous for continuous content flow to
	adopt sliding window coding in CCNx/NDN. In this case, the publisher		adopt sliding window coding in CCNx/NDN. In this case, the producer
	is required to appropriately set coding parameters and let the		is required to appropriately set coding parameters and let the
	consumer know the information, and the consumer is required to send		consumer know the information, and the consumer is required to send
	interest (i.e., feedback information) regarding the data reception		interests augmented with feedback information regarding the data
	and/or decoding status. As CCNx/NDN advocates hop-by-hop		reception and/or decoding status. As CCNx/NDN utilises hop-by-hop
	communication, it would be worth discussing and investigating how		forwarding state, it would be worth discussing and investigating how
	convolutional coding can be applied in a hop-by-hop manner and its		convolutional coding can be applied in a hop-by-hop manner and what
	benefits. In particular, in the case wherein in-network re-coding		benefits might accrue. In particular, in the case wherein in-network
	could occur at routers, both the encoding window and CS management		re-coding could occur at forwarders, both the encoding window and CS
	would be required, and the corresponding feasibility and practicality		management would be required, and the corresponding feasibility and
	should be considered.		practicality should be considered.
	7.2. Rate and Congestion Control		7.2. Rate and Congestion Control
	The addition of redundancy using repair packets may result in further		The addition of redundancy using repair packets may result in further
	network congestion and could adversely affect the overall throughput		network congestion and could adversely affect the overall throughput.
	performance. In particular, in a situation wherein fair bandwidth		In particular, in a situation wherein fair bandwidth sharing is more
	sharing is more desirable, each streaming flow must adapt to the		desirable, each streaming flow must adapt to the network conditions
	network conditions to fairly consume the available link bandwidth.		to fairly consume the available link bandwidth. It is thus necessary
	It is thus necessary that each content flow cooperatively implements		that each content flow cooperatively implement congestion control to
	congestion control to adjust the consumed bandwidth to stabilize the		adjust the consumed bandwidth [23]. From this perspective, although
	network condition (i.e., to achieve a low packet loss rate, delay,		a forwarder-supported approach would be effective, an effective
	and jitter) [22]. From this perspective, although a router-supported		deployment approach that provides benefits under partial deployment
	approach would be effective, an effective deployment scenario is		is required.
	required.
	As described in Section 6.4, NC can contribute to seamless consumer		As described in Section 6.4, NC can contribute to seamless consumer
	mobility by obtaining innovative packets without receiving duplicated		mobility by obtaining innovative packets without receiving duplicated
	packets through multipath data retrieval. It can be challenging to		packets through multipath data retrieval. It can be challenging to
	develop an effective rate and congestion control mechanism in order		develop an effective rate and congestion control mechanism in order
	to achieve seamless consumer mobility while improving the overall		to achieve seamless consumer mobility while improving the overall
	throughput or latency by fully exploiting NC operations.		throughput or latency by fully exploiting NC operations.
	7.3. Security		7.3. Security
	While CCNx/NDN introduces new security issues at the networking layer		While CCNx/NDN introduces new security issues at the networking layer
	that are different from the IP network, such as a cache poisoning and		that are different from the IP network, such as a cache poisoning and
	pollution attack, a DoS attack using interest packets, some security		pollution attacks, a DoS attack using interest packets, some security
	approaches are already provided [23] [24]. The application of NC in		approaches are already provided [25] [26]. The application of NC in
	CCNx/NDN impacts the security mechanisms of CCNx/NDN.		CCNx/NDN brings two potential security aspects that need to be dealt
			with.
	CCNx/NDN is designed to prevent 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
	routers. 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 routers 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 routers verifying the signature within
	the coded packets in transit and only transmitting and storing the
	validated coded packets. However, as performing a signature
	verification by the routers 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 cache
	benefits such as latency and network-load reduction.
	In addition, to maintain the in-network cache efficiency, routers
	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 routers and/or the publisher 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.
	On the other hand, NC could be used to mitigate privacy issues CCNx/		The first is in-network re-coding at forwarders. Some mechanism for
	NDN introduces. For instance, assuming that consumers can use		ensuring the integrity of the coded packets newly produced by in-
	multipath data retrieval and caching in CCNx/NDN with NC, cache		network re-coding is required in order for consumers or other
	privacy and anonymity set for consumers can be improved in addition		forwarders to deal with valid coded packets. To this end, there are
	to caching performance owing to the diversity of the caching content		some possible approaches described in Section 8, but there may be
	objects along different paths.		more effective method with lower complexity and computation overhead.
	In this context, it can be a challenge that coping with the security		The second is that attackers maliciously request and inject coded
	issues as low computation overhead as possible while facilitating the		packets, which could amplify some attacks. As coded packets are
	NC operations in CCNx/NDN. From the perspective of both feasibility		unpopular in general use, they could be targeted by a cache pollution
	and practicability, more effective approaches with consideration of		attack that requests less popular content objects more frequently to
	security would be required in order to accelerate the deployment of		undermine popularity-based caching by skewing the content popularity.
	CCNx/NDN with NC.		Such an attack needs to be dealt with in order to maintain the in-
			network cache efficiency. By injecting invalid coded 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 coded packets. 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 signature verification by 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 cache benefits such as
			latency and network-load reduction.
	7.4. Routing Scalability		7.4. Routing Scalability
	In CCNx/NDN, a name-based routing protocol without a resolution		In CCNx/NDN, a name-based routing protocol without a resolution
	process streamlines the routing process and reduces the overall		process streamlines the routing process and reduces the overall
	latency. In IP routing, the growth in the routing table size has		latency. In IP routing, the growth in the routing table size has
	become a concern. It is thus necessary to use a hierarchical naming		become a concern. It is thus necessary to use a hierarchical naming
	scheme in order to improve the routing scalability by enabling the		scheme in order to improve the routing scalability by enabling the
	aggregation of the routing information.		aggregation of the routing information.
	It is required to enable consumers to efficiently obtain innovative		To realize the benefits of NC, consumers need to efficiently obtain
	packets using multipath retrieval in a fully distributed manner, and		innovative packets using multipath retrieval mechanisms of CCNx/NDN.
	thus fully leverage NC in CCNx/NDN to improve throughput or reduce		This would require some efficient routing mechanism to appropriately
	latency. This would require some efficient routing mechanism to		set the FIB and also an efficient interest forwarding strategy. Such
	appropriately set the FIB and also an efficient interest forwarding		routing coordination may create routing scalability issues. It would
	strategy. Such routing coordination may create routing scalability		be challenging to achieve effective and scalable routing for
	issues. It would be challenging to achieve effective and scalable		interests requesting coded packets as well as to simplify the routing
	routing for interests requesting coded packets as well as to simplify		process.
	the routing process.
	8. Security Considerations		8. Security Considerations
	In-network re-coding is a prominent operation of NC; however, it may		In-network re-coding is a distinguishing feature of NC. Only valid
	lead to cache poisoning attacks that inject invalid coded packets to		coded packets produced by in-network re-coding must be requested and
	the network. To address this issue, there exist some possible		utilized (and possibly stored). To this end, there exist some
	approaches. First, as a signature verification approach, the		possible approaches. First, as a signature verification approach,
	exploitation of multi-signature capability could be applied. This		the exploitation of multi-signature capability could be applied.
	allows not only the original content publisher but also some routers		This allows not only the original content producer but also some
	responsible for in-network re-coding to have their own unique signing		forwarders responsible for in-network re-coding to have their own
	key. Each router of the group signs newly generated coded packet in		unique signing key. Each forwarder of the group signs newly
	order for other nodes to be able to validate the data with the		generated coded packet in order for other nodes to be able to
	signature. The CS may verify the signature within the coded packet		validate the data with the signature. The CS may verify the
	before storing it to avoid invalid data caching. Second, as a		signature within the coded packet before storing it to avoid invalid
	consumer-dependent approach, the consumer puts a restriction on the		data caching. Second, as a consumer-dependent approach, the consumer
	matching rule using only the name of the requested data. The		puts a restriction on the matching rule using only the name of the
	interest ambiguity can be clarified by specifying both the name and		requested data. The interest ambiguity can be clarified by
	the key identifier (the publisher's public key digest) used for		specifying both the name and the key identifier (the producer's
	matching to the requested data. This KeyId restriction is built in		public key digest) used for matching to the requested data. This
	the CCNx design [1]. Only the requested data packet satisfying the		KeyId restriction is built in the CCNx design [1]. Only the
	interest with the KeyId restriction would be forwarded and stored in		requested data packet satisfying the interest with the KeyId
	the CS, thus resulting in a reduction in the chances of cache		restriction would be forwarded and stored in the CS, thus resulting
	poisoning. Moreover, in the CCNx design, there exists the rule that		in a reduction in the chances of cache poisoning. Moreover, in the
	the CS obeys in order to avoid amplifying invalid data; if an		CCNx design, there exists the rule that the CS obeys in order to
	interest has a KeyID restriction, the CS must not reply unless it		avoid amplifying invalid data; if an interest has a KeyID
	knows that the signature on the matching content object is correct.		restriction, the CS must not reply unless it knows that the signature
	If the CS cannot verify the signature, the interest may be treated as		on the matching content object is correct. If the CS cannot verify
	a cache miss and forwarded to the upstream router(s). Third, as a		the signature, the interest may be treated as a cache miss and
	certificate chain management approach (possibly without certificate		forwarded to the upstream forwarder(s). Third, as a certificate
	authority), some mechanism such as [30] could be used to establish a		chain management approach (possibly without certificate authority),
	trustworthy data delivery path. This approach adopts the hop-by-hop		some mechanism such as [32] 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		authentication mechanism, wherein forwarding-integrated hop-by-hop
	certificate collection is performed to provide suspension certificate		certificate collection is performed to provide suspension certificate
	chains such that the data retrieval is trustworthy.		chains such that the data retrieval is trustworthy.
	Depending on the adopted caching strategy such as cache replacement		Depending on the adopted caching strategy such as cache replacement
	policies, routers should also take caution when storing and retaining		policies, forwarders should also take caution when storing and
	the coded packets in the CS as they could be targeted by cache		retaining the coded packets in the CS as they could be targeted by
	pollution attacks. In order to mitigate the cache pollution attacks'		cache pollution attacks. In order to mitigate the cache pollution
	impact, routers should check the content request frequencies to		attacks' impact, forwarders should check the content request
	detect the attack and may limit requests by ignoring some of the		frequencies to detect the attack and may limit requests by ignoring
	consecutive requests. The routers can then decide to apply or change		some of the consecutive requests. The forwarders can then decide to
	to the other cache replacement mechanism.		apply or change to the other cache replacement mechanism.
	The routers or publishers require careful attention to the DoS		The forwarders or producers require careful attention to the DoS
	attacks aiming at provoking the high load of NC operations by using		attacks aiming at provoking the high load of NC operations by using
	the interests for coded packets. In order to mitigate such attacks,		the interests for coded packets. In order to mitigate such attacks,
	the routers could adopt a rate-limiting approach. For instance, they		the forwarders could adopt a rate-limiting approach. For instance,
	could monitor the PIT size growth for coded data per content to		they could monitor the PIT size growth for coded data per content to
	detect the attacks, and limit the interest arrival rate when		detect the attacks, and limit the interest arrival rate when
	necessary. If the NC application wishes to secure an interest		necessary. If the NC application wishes to secure an interest
	(considered as the NC actuator) in order to prevent such attacks, the		(considered as the NC actuator) in order to prevent such attacks, the
	application should consider using an encrypted wrapper and an		application should consider using an encrypted wrapper and an
	explicit protocol.		explicit protocol.
	9. Informative References		9. Acknowledgements
			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.
			10. Informative References
	[1] Mosko, M. and et al., "Content-Centric Networking (CCNx)		[1] Mosko, M. and et al., "Content-Centric Networking (CCNx)
	Semantics", RFC 8569, July 2019,		Semantics", RFC 8569, July 2019,
	<https://tools.ietf.org/html/rfc8569>.		<https://tools.ietf.org/html/rfc8569>.
	[2] Cai, N. and R. Yeung, "Secure network coding", Proc.		[2] Cai, N. and R. Yeung, "Secure network coding", Proc.
	International Symposium on Information Theory		International Symposium on Information Theory
	(ISIT), IEEE, June 2002.		(ISIT), IEEE, June 2002.
	[3] Lima, L., Gheorghiu, S., Barros, J., Medard, M., and A.		[3] Lima, L., Gheorghiu, S., Barros, J., Medard, M., and A.
	skipping to change at page 20, line 43 ¶		skipping to change at page 20, line 37 ¶
	Computer Networks, Elsevier, August 2016.		Computer Networks, Elsevier, August 2016.
	[15] Matsuzono, K., Asaeda, H., and T. Turletti, "Low Latency		[15] Matsuzono, K., Asaeda, H., and T. Turletti, "Low Latency
	Low Loss Streaming using In-Network Coding and Caching",		Low Loss Streaming using In-Network Coding and Caching",
	Proc. Infocom, IEEE, May 2017.		Proc. Infocom, IEEE, May 2017.
	[16] Jacobson, V., Smetters, D., Thornton, J., Plass, M.,		[16] Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
	Briggs, N., and R. Braynard, "Networking Named Content",		Briggs, N., and R. Braynard, "Networking Named Content",
	Proc. CoNEXT, ACM, December 2009.		Proc. CoNEXT, ACM, December 2009.
	[17] Mosko, M. and et al., "Content-Centric Networking (CCNx)		[17] Wissingh, B. and et al., "Information-Centric Networking
			(ICN): Content-Centric Networking (CCNx) and Named Data
			Networking (NDN) Terminology", RFC 8793, June 2020,
			<https://tools.ietf.org/html/rfc8793>.
			[18] Mosko, M. and et al., "Content-Centric Networking (CCNx)
	Messages in TLV Format", RFC 8609, July 2019,		Messages in TLV Format", RFC 8609, July 2019,
	<https://tools.ietf.org/html/rfc8609>.		<https://tools.ietf.org/html/rfc8609>.
	[18] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., Claffy,		[19] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., Claffy,
	K., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang,		K., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang,
	"Named data networking", ACM Comput. Commun. Rev., vol.		"Named data networking", ACM Comput. Commun. Rev., vol.
	44, no. 3, July 2014.		44, no. 3, July 2014.
	[19] NDN Packet Format, "NDN Packet Format Specification 0.3		[20] NDN Packet Format, "NDN Packet Format Specification 0.3
	documentation", Sept. 2019,		documentation", Sept. 2019,
	<https://named-data.net/doc/NDN-packet-spec/current/>.		<https://named-data.net/doc/NDN-packet-spec/current/>.
	[20] Koetter, R. and M. Medard, "An Algebraic Approach to		[21] Koetter, R. and M. Medard, "An Algebraic Approach to
	Network Coding", IEEE/ACM Trans. on Networking, vol. 11,		Network Coding", IEEE/ACM Trans. on Networking, vol. 11,
	no 5, Oct. 2003.		no 5, Oct. 2003.
	[21] Adamson, B. and et al., "Taxonomy of Coding Techniques for		[22] Adamson, B. and et al., "Taxonomy of Coding Techniques for
	Efficient Network Communications", RFC 8406, June 2018,		Efficient Network Communications", RFC 8406, June 2018,
	<https://tools.ietf.org/html/rfc8406>.		<https://tools.ietf.org/html/rfc8406>.
	[22] Kuhn, N. and et al., "Coding and Congestion Control in		[23] Kuhn, N., Lochin, E., Michel, F., and M. Welzl, "Coding
	Transport", Work in Progress, draft-irtf-nwcrg-coding-and-		and Congestion Control in Transport", Work in Progress,
	congestion-04, Oct. 2020.		draft-irtf-nwcrg-coding-and-congestion-09, June 2021.
	[23] Kutscher, D. and et al., "Information-Centric Networking		[24] Tschudin, C., Wood, C., Mosko, M., and D. Oran, "File-Like
			ICN Collections (FLIC)", Work in Progress, draft-irtf-
			icnrg-flic-02, Nov. 2019.
			[25] Kutscher, D. and et al., "Information-Centric Networking
	(ICN) Research Challenges", RFC 7927, July 2016.		(ICN) Research Challenges", RFC 7927, July 2016.
	[24] Pentikousis, K. and et al., "Information-Centric		[26] Pentikousis, K. and et al., "Information-Centric
	Networking: Evaluation and Security Considerations",		Networking: Evaluation and Security Considerations",
	RFC 7945, July 2019.		RFC 7945, July 2019.
	[25] Watson, M. and et al., "Forward Error Correction (FEC)		[27] Watson, M. and et al., "Forward Error Correction (FEC)
	Framework", RFC 6363, Oct. 2011.		Framework", RFC 6363, Oct. 2011.
	[26] Thomos, N. and P. Frossard, "Toward one Symbol Network		[28] Thomos, N. and P. Frossard, "Toward one Symbol Network
	Coding Vectors", IEEE Communications letters, vol. 16, no.		Coding Vectors", IEEE Communications letters, vol. 16, no.
	11, November 2012.		11, November 2012.
	[27] Lucani, D., Pedersen, M., Heide, J., and F. Fitzek,		[29] Lucani, D., Pedersen, M., Heide, J., and F. Fitzek,
	"Fulcrum Network Codes: A Code for Fluid Allocation of		"Fulcrum Network Codes: A Code for Fluid Allocation of
	Complexity", available at http://arxiv.org/abs/1404.6620,		Complexity", available at http://arxiv.org/abs/1404.6620,
	April 2014.		April 2014.
	[28] Perino, D. and M. Varvello, "A reality check for content		[30] Perino, D. and M. Varvello, "A reality check for content
	centric networking", Proc. SIGCOMM Workshop on		centric networking", Proc. SIGCOMM Workshop on
	Information-centric networking (ICN'11), ACM, August 2011.		Information-centric networking (ICN'11), ACM, August 2011.
	[29] Wu, Q., Li, Z., Tyson, G., Uhlig, S., Kaafar, M., and G.		[31] Wu, Q., Li, Z., Tyson, G., Uhlig, S., Kaafar, M., and G.
	Xie, "Privacy-Aware Multipath Video Caching for Content-		Xie, "Privacy-Aware Multipath Video Caching for Content-
	Centric Networks", IEEE Journal of Selected Area		Centric Networks", IEEE Journal of Selected Area
	(JSAC) vol. 38, no. 8, June 2016.		(JSAC) vol. 38, no. 8, June 2016.
	[30] Li, R., Asaeda, H., and J. Wu, "DCAuth: Data-Centric		[32] Li, R., Asaeda, H., and J. Wu, "DCAuth: Data-Centric
	Authentication for Secure In-Network Big-Data Retrieval",		Authentication for Secure In-Network Big-Data Retrieval",
	IEEE Trans. on Network Science and Engineering vol. 7, no.		IEEE Trans. on Network Science and Engineering vol. 7, no.
	1, September 2018.		1, September 2018.
	[31] Wu, Y., Chou, P., and K. Jain, "A comparison of network		[33] Wu, Y., Chou, P., and K. Jain, "A comparison of network
	coding and tree packing", Proc. ISIT, IEEE, June 2004.		coding and tree packing", Proc. ISIT, IEEE, June 2004.
	[32] Ho, T., Medard, M., Koetter, R., Karger, R., Effros, D.,		[34] Ho, T., Medard, M., Koetter, R., Karger, R., Effros, D.,
	Shi, M., and B. Leong, "A Random Linear Network Coding		Shi, M., and B. Leong, "A Random Linear Network Coding
	Approach to Multicast", IEEE Trans. Information		Approach to Multicast", IEEE Trans. Information
	Theory, vol. 52, no.10, October 2006.		Theory, vol. 52, no.10, October 2006.
	[33] Podlipnig, S. and L. Osz, "A Survey of Web Cache		[35] Podlipnig, S. and L. Osz, "A Survey of Web Cache
	Replacement Strategies", Proc. ACM Computing Surveys vol.		Replacement Strategies", Proc. ACM Computing Surveys vol.
	35, no. 4, December 2003.		35, no. 4, December 2003.
	[34] Rossini, G. and D. Rossi, "Evaluating CCN multi-path		[36] Rossini, G. and D. Rossi, "Evaluating CCN multi-path
	interest forwarding strategies", Elsevier Computer		interest forwarding strategies", Elsevier Computer
	Communication, vol.36, no. 7, April 2013.		Communication, vol.36, no. 7, April 2013.
	[35] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova,		[37] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova,
	N., and X. Zeng, "Leveraging ICN In-network Control for		N., and X. Zeng, "Leveraging ICN In-network Control for
	Loss Detection and Recovery in Wireless Mobile networks",		Loss Detection and Recovery in Wireless Mobile networks",
	Proc. ICN ACM, September 2016.		Proc. ICN ACM, September 2016.
	[36] Ali, M. and U. Niesen, "Coding for Caching: Fundamental		[38] Ali, M. and U. Niesen, "Coding for Caching: Fundamental
	Limits and Practical Challenges", IEEE Communications		Limits and Practical Challenges", IEEE Communications
	Magazine vol. 54, no. 8, August 2016.		Magazine vol. 54, no. 8, August 2016.
	[37] Koetter, R. and F. Kschischang, "An algebraic approach to		[39] Koetter, R. and F. Kschischang, "An algebraic approach to
	network coding", IEEE Trans. Netw. vol.11, no.5, October		network coding", IEEE Trans. Netw. vol.11, no.5, October
	2008.		2008.
	[38] Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and		[40] Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and
	V. Roca, "On-the-Fly Erasure Coding for Real-Time Video		V. Roca, "On-the-Fly Erasure Coding for Real-Time Video
	Applications", IEEE Trans. Multimeda vol.13, no.4, August		Applications", IEEE Trans. Multimeda vol.13, no.4, August
	2011.		2011.
	Authors' Addresses		Authors' Addresses
	Kazuhisa Matsuzono		Kazuhisa Matsuzono
	National Institute of Information and Communications Technology		National Institute of Information and Communications Technology
	4-2-1 Nukui-Kitamachi		4-2-1 Nukui-Kitamachi
	Koganei, Tokyo 184-8795		Koganei, Tokyo 184-8795
End of changes. 101 change blocks.
	438 lines changed or deleted		441 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/