Diff: rfc9531.original.xml

	rfc9531.original.xml	rfc9531.xml

	<?xml version='1.0' encoding='utf-8'?>	<?xml version="1.0" encoding="UTF-8"?>
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>


	<rfc xmlns:xi="http://www.w3.org/2001/XInclude"	<!DOCTYPE rfc [
	category="exp"	<!ENTITY nbsp " ">
	docName="draft-irtf-icnrg-pathsteering-07"	<!ENTITY zwsp "">
	ipr="trust200902"	<!ENTITY nbhy "‑">
	submissionType="IRTF"	<!ENTITY wj "⁠">
	xml:lang="en"	]>
	tocInclude="true"
	tocDepth="4"
	symRefs="true"
	sortRefs="true"
	version="3">


	<front>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IRTF" category
	<title abbrev="ICN Path Steering">Path Steering in CCNx and NDN</title>	="exp" consensus="true" docName="draft-irtf-icnrg-pathsteering-07" number="
	<seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-pathsteering-07"/>	9531" ipr="trust200902" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="tr
		ue" sortRefs="true" updates="" obsoletes="" version="3">


		<front>
		<title abbrev="ICN Path Steering">Path Steering in Content-Centric
		Networking (CCNx) and Named Data Networking (NDN)</title>
		<seriesInfo name="RFC" value="9531"/>
	<author fullname="Ilya Moiseenko" surname="I. Moiseenko">	<author fullname="Ilya Moiseenko" surname="I. Moiseenko">
	<organization>Apple, Inc.</organization>	<organization>Apple, Inc.</organization>
	<address>	<address>
	<postal>	<postal>
	<street/>	<street/>
	<city>Cupertino</city>	<city>Cupertino</city>
	<region>CA</region>	<region>CA</region>
	<code/>	<code/>

	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<phone/>	<phone/>
	<email>iliamo@mailbox.org</email>	<email>iliamo@mailbox.org</email>
	</address>	</address>
	</author>	</author>

	<author fullname="Dave Oran" surname="D. Oran">	<author fullname="Dave Oran" surname="D. Oran">
	<organization>Network Systems Research and Design</organization>	<organization>Network Systems Research and Design</organization>
	<address>	<address>
	<postal>	<postal>
	<street>4 Shady Hill Square</street>	<street>4 Shady Hill Square</street>
	<city>Cambridge</city>	<city>Cambridge</city>
	<region>MA</region>	<region>MA</region>
	<code>02138</code>	<code>02138</code>

	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<phone/>	<phone/>
	<email>daveoran@orandom.net</email>	<email>daveoran@orandom.net</email>
	</address>	</address>
	</author>	</author>


	<date year="2023"/>	<date year="2024" month="February"/>

	<!-- Meta-data Declarations -->

	<area>IRTF</area>
	<workgroup>ICNRG</workgroup>


		<workgroup>Information-Centric Networking</workgroup>
	<keyword>ICN</keyword>	<keyword>ICN</keyword>

	<abstract>	<abstract>

	<t>Path Steering is a mechanism to discover paths to the producers of ICN	<t>Path steering is a mechanism to discover paths to the producers of
	content objects and steer subsequent Interest messages along a previously discov	Information-Centric Networking (ICN) Content Objects and steer subsequent
	ered path. It has various uses, including the operation of state-of-the-art mult	Interest messages along a
	ipath congestion control algorithms and for network measurement and management.	previously discovered path. It has various uses, including the operation
	This specification derives directly from the design published in <em>Path Switch	of state-of-the-art multi-path congestion control algorithms and for
	ing in Content Centric and Named Data Networks</em> (4th ACM Conference on Infor	network measurement and management. This specification derives directly
	mation-Centric Networking - ICN'17) and therefore does not recapitulate the desi	from the design published in "Path Switching in Content Centric and
	gn motivations, implementation details, or evaluation of the scheme. Some techni	Named Data Networks" (4th ACM Conference on Information-Centric
	cal details are different however, and where there are differences, the design d	Networking) and, therefore, does not recapitulate the design
	ocumented here is to be considered definitive.</t>	motivations, implementation details, or evaluation of the
		scheme. However, some technical details are different, and where there
		are differences, the design documented here is to be considered
		definitive.</t>


	<t>This document is a product of the IRTF Information-Centric Networking R	<t>This document is a product of the IRTF Information-Centric Networking
	esearch Group (ICNRG). It is not an IETF product and is not an Internet Standard	Research Group (ICNRG). It is not an IETF product and is not an Internet
	.</t>	Standard.</t>
	</abstract>	</abstract>
	</front>	</front>

	<middle>	<middle>
	<section anchor="intro" numbered="true" toc="default">	<section anchor="intro" numbered="true" toc="default">
	<name>Introduction</name>	<name>Introduction</name>


	<t>Path Steering is a mechanism to discover paths to the producers of ICN	<t>Path steering is a mechanism to discover paths to the producers of
	content objects and steer subsequent Interest messages along a previously discov	ICN Content Objects and steer subsequent Interest messages along a
	ered path. It has various uses, including the operation of state-of-the-art mult	previously discovered path. It has various uses, including the operation
	ipath congestion control algorithms and for network measurement and management.	of state-of-the-art multi-path congestion control algorithms and for
	This specification derives directly from the design published in <xref target="M	network measurement and management. This specification derives directly
	oiseenko2017"/> and therefore does not recapitulate the design motivations, impl	from the design published in <xref target="Moiseenko2017"/> and,
	ementation details, or evaluation of the scheme. That publication should be cons	therefore, does not recapitulate the design motivations, implementation
	idered a normative reference as it is not likely a reader will be able to unders	details, or evaluation of the scheme. That publication should be
	tand all elements of this design without first having read the reference. Some t	considered a normative reference as it is not likely a reader will be
	echnical details are different however, and where there are differences, the des	able to understand all elements of this design without first having read
	ign documented here is to be considered definitive.</t>	the reference. However, some technical details are different, and where
		there are differences, the design documented here is to be considered
		definitive.</t>


	<t>Path discovery and subsequent path steering in ICN networks is facilita	<t>Path discovery and subsequent path steering in ICN networks is
	ted by the symmetry of forward and reverse paths in the CCNx and NDN architectur	facilitated by the symmetry of forward and reverse paths in the Content-Ce
	es. Path discovery is achieved by a consumer endpoint transmitting an ordinary I	ntric Networking (CCNx) and
	nterest message and receiving a Content (Data) message containing an end-to-end	Named Data Networking (NDN) architectures. Path discovery is achieved by a
	path label constructed on the reverse path by the forwarding plane. Path steerin	consumer endpoint
	g is achieved by a consumer endpoint including a path label in the Interest mess	transmitting an ordinary Interest message and receiving a Content (Data)
	age, which is forwarded to each nexthop through the corresponding egress interfa	message containing an end-to-end path label constructed on the reverse
	ces in conjunction with longest name prefix match (LNPM) lookup in the Forwardin	path by the forwarding plane. Path steering is achieved by a consumer
	g Information Base (FIB).</t>	endpoint including a path label in the Interest message, which is
		forwarded to each nexthop through the corresponding egress interfaces in
		conjunction with Longest Name Prefix Match (LNPM) lookup in the
		Forwarding Information Base (FIB).</t>


	<t>This document is a product of the IRTF Information-Centric Networking R	<t>This document is a product of the IRTF Information-Centric Networking
	esearch Group (ICNRG). It was supported by the ICNRG participants during its dev	Research Group (ICNRG). It was supported by the ICNRG participants
	elopment and through Research Group last call. It has received detailed review b	during its development and through Research Group Last Call. It has
	y experts in both the CCNx and NDN communities.</t>	received detailed review by experts in both the CCNx and NDN
		communities.</t>

	<section anchor="experimenting">	<section anchor="experimenting">

	<name>Path Steering as an experimental extension to ICN protocol architec tures</name>	<name>Path Steering as an Experimental Extension to ICN Protocol Architec tures</name>
	<t>There are a number of important use cases to justify extending ICN arc hitectures such as <xref target="RFC8569" format="default">CCNx</xref> or <xref target="NDN" format="default">NDN</xref> to provide these capabilities. These ar e summarized as follows:</t>	<t>There are a number of important use cases to justify extending ICN arc hitectures such as <xref target="RFC8569" format="default">CCNx</xref> or <xref target="NDN" format="default">NDN</xref> to provide these capabilities. These ar e summarized as follows:</t>


	<ul spacing="normal">	<ul spacing="normal">
	<li>Support the discovery, monitoring and troubleshooting of mult	<li>Support the discovery, monitoring, and troubleshooting of
	i-path network connectivity based on names and name prefixes. Analogous function	multi-path network connectivity, based on names and name
	s have been shown to be a crucial operational capability in multicast and multi-	prefixes. Analogous functions have been shown to be a crucial
	path topologies for IP. The canonical tools are the well-known <em>traceroute</e	operational capability in multicast and multi-path topologies for
	m> and <em>ping</em>. For point-to-multipoint MPLS the more recent <xref target=	IP. The canonical tools are the well-known <em>traceroute</em> and
	"RFC8029" format="default">tree trace</xref> protocol is used. Equivalent diagno	<em>ping</em>. For point-to-multipoint MPLS, the more recent MPLS <xre
	stic functions have been defined for CCNx through the <xref target="I-D.irtf-icn	f
	rg-icnping" format="default">ICN Ping</xref> and <xref target="I-D.irtf-icnrg-ic	target="RFC8029" format="default">traceroute</xref> protocol is
	ntraceroute" format="default">ICN Traceroute</xref> specifications, both of whic	used. Equivalent diagnostic functions have been defined for CCNx
	h are capable of exploiting path steering if available.</li>	through the <xref target="RFC9508" format="default">ICN Ping</xref>
		and <xref target="RFC9507" format="default">ICN Traceroute</xref>
		specifications; both of which are capable of exploiting path
		steering, if available.</li>


	<li>Perform accurate online measurement of network performance, w	<li>Perform accurate online measurement of network performance,
	hich generally requires multiple consecutive packets follow the same path under	which generally requires multiple consecutive packets to follow the
	control of an application.</li>	same path under control of an application.</li>


	<li>Improve the performance and flexibility of multi-path congest	<li>Improve the performance and flexibility of multi-path congestion
	ion control algorithms. Congestion control schemes such as <xref target="Mahdian	control algorithms. Congestion control schemes, such as <xref
	2016" format="default"/> and <xref target="Song2018" format="default"/> depend o	target="Mahdian2016" format="default"/> and <xref target="Song2018"
	n the ability of a consumer to explicitly steer packets onto individual paths in	format="default"/>, depend on the ability of a consumer to explicitly
	a multi-path and/or multi-destination topology.</li>	steer packets onto individual paths in a multi-path and/or
		multi-destination topology.</li>


	<li>A consumer endpoint can mitigate content poisoning attacks by	<li>Allow a consumer endpoint to mitigate content poisoning attacks by
	directing its Interests onto the network paths that bypass poisoned caches.</li	directing its Interests onto the network paths that bypass poisoned
	>	caches.</li>
	</ul>	</ul>

	<t>The path discovery machinery described here may (and likely will) disc over paths with varying properties. <xref target="RFC9217"/> discusses a number of open questions in path aware networking, among which is how to assess and exp loit paths having different properties. Experimenting with ICN path steering may be helpful in further elucidating these questions and perhaps shedding light on which path properties are most useful for the use cases cited above.</t>


	<t>One nuance compared to other path aware networking approaches is that	<t>The path discovery machinery described here may (and likely will)
	ICN path steering piggybacks path discovery on the base ICN data exchange, rathe	discover paths with varying properties. <xref target="RFC9217"/>
	r than having a separate path advertisement or discovery mechanism. That means w	discusses a number of open questions in path-aware networking, among
	hen the recorded path comes back in an ICN Data message response, the properties	which is how to assess and exploit paths having different
	of the path are known only implicitly to the consumer as opposed to being expli	properties. Experimenting with ICN path steering may be helpful in
	citly labeled. That makes the question of what properties a consumer uses to cho	further elucidating these questions and perhaps shedding light on
	ose a path one of observation or measurement rather than advance selection based	which path properties are most useful for the use cases cited
	on an explicit advertised property (e.g <xref target="I-D.dekater-panrg-scion-	above.</t>
	overview">SCION</xref>).</t>


	<t>The utility and overall technical quality of this path steering capabi	<t>One nuance compared to other path-aware networking approaches is
	lity can be assessed by how well it enables the above use cases and what perform	that ICN path steering piggybacks path discovery on the base ICN data
	ance and robustness effects it has on the underlying ICN protocols and their use	exchange rather than having a separate path advertisement or discovery
	in various applications. A few of the open questions that should be addressed t	mechanism. That means when the recorded path comes back in an ICN Data
	hrough experimentation with path steering include:</t>	message response, the properties of the path are known only implicitly
	<ul>	to the consumer as opposed to being explicitly labeled. That makes
	<li>how much more accurate and useful are measurements of RTT, pa	the question of what properties a consumer uses to choose a path one
	cket loss, etc. through ping and traceroute when utilizing path steering?</li>	of observation or measurement rather than advance selection based on
	<li>how much is the performance and robustness of multi-path forw	an explicit, advertised property (e.g., <xref
	arding enhanced by the use of this explicit path steering capability?</li>	target="I-D.dekater-panrg-scion-overview">SCION</xref>).</t>

		<t>The utility and overall technical quality of this path steering
		capability can be assessed by how well it enables the above use cases
		and what performance and robustness effects it has on the underlying
		ICN protocols and their use in various applications. A few of the open
		questions that should be addressed through experimentation with path
		steering include:</t>
		<ul spacing="normal">
		<li>How much more accurate and useful are measurements of RTT,
		packet loss, etc. through ping and traceroute when utilizing path
		steering?</li>
		<li>How much is the performance and robustness of multi-path
		forwarding enhanced by the use of this explicit path steering
		capability?</li>
	</ul>	</ul>


	</section>	</section>

	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Requirements Language</name>	<name>Requirements Language</name>

	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	document are to be interpreted as described in BCP 14	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	when, they appear in all capitals, as shown here.</t>	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
		are to be interpreted as described in BCP 14 <xref
		target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
		appear in all capitals, as shown here.
		</t>
	</section>	</section>

	<section>	<section>
	<name>Terminology</name>	<name>Terminology</name>

	<t>This document uses the general ICN terms that are defined in <xref tar	<t>This document uses the general ICN terms that are defined in <xref
	get="RFC8793"/>. In addition we define the following terms specific to path stee	target="RFC8793"/>. In addition, we define the following terms
	ring:</t>	specific to path steering:</t>
	<dl>	<dl newline="false" spacing="normal">
	<dt>Path Discovery:</dt>	<dt>Path Discovery:</dt>

	<dd>The process of sending an Interest requesting discovery of a pat	<dd>The process of sending an Interest message requesting discovery
	h and if successful, receiving a Data containing a Path Label for the path the c	of a
	orresponding Interest traversed</dd>	path and, if successful, receiving a Data message containing a path
		label
		for the path the corresponding Interest traversed.</dd>

	<dt>Path Steering:</dt>	<dt>Path Steering:</dt>

	<dd>The process of sending an Interest message containing the Path L	<dd>The process of sending an Interest message containing the path
	abel of a previously discovered path in order that the forwarders use that path	label of a previously discovered path so that the forwarders
	when forwarding that particular Interest message.</dd>	use that path when forwarding that particular Interest
		message.</dd>

	<dt>Path Label:</dt>	<dt>Path Label:</dt>

	<dd>An optional field in the packet indicating a particular path fro	<dd>An optional field in the packet indicating a particular path
	m a consumer to either a producer, or a forwarder cache that can respond with th	from a consumer to either a producer or a forwarder cache that
	e requested item. In an Interest message, the Path Label gets built up hop by ho	can respond with the requested item. In an Interest message, the
	p as the interest traverses a path. In a Data message, the Path Label carries th	path label gets built up hop by hop as the Interest traverses a
	e full path information back to the consumer for use in one or more subsequent I	path. In a Data message, the path label carries the full path
	nterest messages.</dd>	information back to the consumer for use in one or more subsequent
		Interest messages.</dd>

	<dt>Nexthop Label:</dt>	<dt>Nexthop Label:</dt>

	<dd>One entry in a Path Label representing the next hop for the corr	<dd>One entry in a path label representing the next hop for the
	esponding forwarder to use when a path-steered Interest message arrives at that	corresponding forwarder to use when a path-steered Interest
	forwarder. A sequence of Nexthop Labels constitutes a full Path Label.</dd>	message arrives at that forwarder. A sequence of Nexthop Labels
		constitutes a full path label.</dd>
	</dl>	</dl>


	</section>	</section>

	</section>	</section>
	<section anchor="design" numbered="true" toc="default">	<section anchor="design" numbered="true" toc="default">

	<name>Essential elements of ICN path discovery and path steering</name>	<name>Essential Elements of ICN Path Discovery and Path Steering</name>


	<t>We elucidate the design using <xref target="RFC8569" format="default">C	<t>We elucidate the design using <xref target="RFC8569"
	CNx semantics</xref> and extend its <xref target="RFC8609" format="default">Pack	format="default">CCNx semantics</xref> and extend its <xref
	et Encoding</xref> as defined in <xref target="CCNx-encoding" format="default"/>	target="RFC8609" format="default">CCNx Message Formats</xref> defined in S
	. While the terminology is slightly different, this design can be applied also t	ection
	o NDN, by extending its bespoke <xref target="NDNTLV" format="default">packet en	<xref target="RFC8609" section="3.2" sectionFormat="bare"/>. While the ter
	codings</xref> (See <xref target="NDN-encoding" format="default"/>).</t>	minology
		is slightly different, this design can also be applied to NDN by
		extending its bespoke <xref target="NDNTLV" format="default">packet
		encodings</xref> (see <xref target="NDN-encoding"
		format="default"/>).</t>

	<section anchor="discovery" numbered="true" toc="default">	<section anchor="discovery" numbered="true" toc="default">
	<name>Path Discovery</name>	<name>Path Discovery</name>


	<t><em>End-to-end Path Discovery</em> for CCNx is achieved by creating a	<t><em>End-to-end Path Discovery</em> for CCNx is achieved by creating
	<em>path label</em> and placing it as a hop-by-hop TLV in a CCNx Content (Data)	a <em>path label</em> and placing it as a hop-by-hop TLV in a CCNx
	message. The path label is constructed hop-by-hop as the message traverses the	Content (Data) message. The path label is constructed hop by hop as
	reverse path of transit CCNx forwarders as shown in the first example in <xref t	the message traverses the reverse path of transit CCNx forwarders, as
	arget="pathsteeringoverview"/>. The path label is updated by adding to the exist	shown in the first example in <xref
	ing path label the nexthop label of the interface at which the Content (Data) me	target="pathsteeringoverview"/>. The path label is updated by adding
	ssage has arrived. Eventually, when the Content(Data) message arrives at the con	the Nexthop Label of the interface at which
	sumer, the path label identifies the complete path the Content (Data) message to	the Content (Data) message has arrived to the existing path label. Event
	ok to reach the consumer. As shown in the second example in the figure, when mul	ually, when the
	tiple paths are available, subsequent Interests may be able to discover additio	Content (Data) message arrives at the consumer, the path label
	nal paths by omitting a path steering TLV and obtaining a new path label on the	identifies the complete path the Content (Data) message took to reach
	returning interest.</t>	the consumer. As shown in the second example in <xref
		target="pathsteeringoverview"/>, when multiple paths are available,
		subsequent Interests may be able to discover additional paths by
		omitting a path steering TLV and obtaining a new path label on the
		returning Interest.</t>

	<figure anchor="pathsteeringoverview">	<figure anchor="pathsteeringoverview">

	<name>Basic example of path discovery and steering</name>	<name>Basic Example of Path Discovery and Steering</name>
	<artwork name="Path Discovery 1" type="" align="left" alt=""><![CDATA[	<artwork name="Path Discovery 1" type="" align="left" alt=""><![CDATA[
	Discover and use first path:	Discover and use first path:

	Consumer Interest 1 ___ Interest 2	Consumer Interest 1 ___ Interest 2
	\| \| ^ \|	\| \| ^ \|
	\| \| \| \|	\| \| \| \|
	\| \| \| \|	\| \| \| \|
	Forwarder 1 v \| V	Forwarder 1 v \| V
	\| (nexthop 1) (nexthop 1) ^ (nexthop 1)	\| (nexthop 1) (nexthop 1) ^ (nexthop 1)
	\| \| \| \|	\| \| \| \|

	skipping to change at line 171 ¶	skipping to change at line 290 ¶
	\ / \| \| \|	\ / \| \| \|
	\ / \| \| \|	\ / \| \| \|
	\ / \| \| \|	\ / \| \| \|
	\ / \| \| \|	\ / \| \| \|
	\ / v \| v	\ / v \| v
	Producer ___ Data 1 ___	Producer ___ Data 1 ___
	or	or
	Content Store	Content Store
	]]></artwork>	]]></artwork>


	<artwork name="Path Discovery 2" type="" align="left" alt=""><![CDATA[	<artwork name="Path Discovery 2" type="" align="left" alt=""><![CDATA[

	Discover and use second path:	Discover and use second path:

	Consumer Interest 3 ___ Interest 4	Consumer Interest 3 ___ Interest 4
	\| \| ^ \|	\| \| ^ \|
	\| \| \| \|	\| \| \| \|
	\| \| \| \|	\| \| \| \|
	Forwarder 1 v \| V	Forwarder 1 v \| V
	\| (nexthop 1) (nexthop 1) ^ (nexthop 1)	\| (nexthop 1) (nexthop 1) ^ (nexthop 1)
	\| \| \| \|	\| \| \| \|
	\| \| \| \|	\| \| \| \|

	skipping to change at line 200 ¶	skipping to change at line 320 ¶
	(nexthop 5)\ / (nexthop 4) (nexthop 5) ^ (nexthop 5)	(nexthop 5)\ / (nexthop 4) (nexthop 5) ^ (nexthop 5)
	\ / \| \| \|	\ / \| \| \|
	\ / \| \| \|	\ / \| \| \|
	\ / \| \| \|	\ / \| \| \|
	\ / \| \| \|	\ / \| \| \|
	\ / \| \| \|	\ / \| \| \|
	\ / v \| v	\ / v \| v
	Producer ___ Data 2 ___	Producer ___ Data 2 ___
	or	or
	Content Store	Content Store

	]]></artwork>	]]></artwork>
	</figure>	</figure>

	</section>	</section>

	<section anchor="steering" numbered="true" toc="default">	<section anchor="steering" numbered="true" toc="default">
	<name>Path Steering</name>	<name>Path Steering</name>

	<t>Due to the symmetry of forward and reverse paths in CCNx, a consumer	<t>Due to the symmetry of forward and reverse paths in CCNx, a
	application can reuse a discovered path label to fetch the same or similar (e.g.	consumer application can reuse a discovered path label to fetch the
	next chunk, or next Application Data Unit, or next pointer in a <xref target="I	same or a similar (e.g., next chunk, next Application Data Unit, or
	-D.irtf-icnrg-flic" format="default">Manifest</xref>) Content (Data) message ove	next pointer in a <xref target="I-D.irtf-icnrg-flic"
	r the discovered network path. This <em>Path Steering</em> is achieved by proces	format="default">Manifest</xref>) Content (Data) message over the
	sing the Interest message's path label at each transit ICN forwarder and forward	discovered network path. This <em>path steering</em> is achieved by
	ing the Interest through the specified nexthop among those identified as feasibl	processing the Interest message's path label at each transit ICN
	e by LNPM FIB lookup (<xref target="pathsteeringdataplane"/>).</t>	forwarder and forwarding the Interest through the specified nexthop
		among those identified as feasible by LNPM FIB lookup (<xref
		target="pathsteeringdataplane"/>).</t>

	<figure anchor="pathsteeringdataplane">	<figure anchor="pathsteeringdataplane">

	<name>Path Steering CCNx / NDN data plane</name>	<name>Path Steering CCNx/NDN Data Plane</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	----------------------------------------------------------------------	----------------------------------------------------------------------
	FORWARD PATH	FORWARD PATH
	----------------------------------------------------------------------	----------------------------------------------------------------------

	Interest +---------+ +-----+ (path label) +--------+ (match) Interest	Interest +---------+ +-----+ (path label) +--------+ (match) Interest
	-------->\| Content \|->\| PIT \| ------------>\| Label \|---------------->	-------->\| Content \|->\| PIT \| ------------>\| Label \|---------------->
	\| Store \| +-----+ \| Lookup \|	\| Store \| +-----+ \| Lookup \|
	+---------+ \| \ (no path label) +--------+	+---------+ \| \ (no path label) +--------+
	\| \| \ \|\(path label mismatch)	\| \| \ \|\(path label mismatch)
	Data \| \| \ \| \	Data \| \| \ \| \
	<---------+ v \ \| \	<---------+ v \ \| \
	aggregate \ \| \	aggregate \ \| \
	\ \| \	\ \| \
	\ \| +-----+ Interest	\ \| +-----+ Interest
	+--------------\|---->\| FIB \| -------->	+--------------\|---->\| FIB \| -------->
	\| +-----+	\| +-----+

	Interest-Return (NACK) v \| (no route)	InterestReturn (NACK) v \| (no route)
	<----------------------------------------------+<-------+	<----------------------------------------------+<-------+

	----------------------------------------------------------------------	----------------------------------------------------------------------
	REVERSE PATH	REVERSE PATH
	----------------------------------------------------------------------	----------------------------------------------------------------------


	Interest-return(NACK) +-----+(update path label) Interest-Return(NACK)	InterestReturn(NACK) +-----+(update path label) InterestReturn(NACK)
	<---------------------\| \|<----------------------------------------	<---------------------\| \|<----------------------------------------
	\| \|	\| \|
	Data +---------+ \| PIT \| (update path label) Data	Data +---------+ \| PIT \| (update path label) Data
	<------\| Content \|<---\| \|<----------------------------------------	<------\| Content \|<---\| \|<----------------------------------------
	\| Store \| \| \|	\| Store \| \| \|
	+---------+ +-----+	+---------+ +-----+
	\|	\|
	\| (no match)	\| (no match)
	v	v
	]]></artwork>	]]></artwork>
	</figure>	</figure>
	</section>	</section>

	<section anchor="error-processing" numbered="true" toc="default">	<section anchor="error-processing" numbered="true" toc="default">

	<name>Handling Path Steering errors</name>	<name>Handling Path Steering Errors</name>
	<t>Over time, the state of interfaces and the FIB on forwarders may chan	<t>Over time, the state of interfaces and the FIB on forwarders may
	ge such that, at any particular forwarder, a given nexthop is no longer valid fo	change such that, at any particular forwarder, a given nexthop is no
	r a given prefix. In this case, the path label will point to a now-invalid nexth	longer valid for a given prefix. In this case, the path label will
	op. This is detected by failure to find a match between the decoded nexthop ID a	point to a now-invalid nexthop. This is detected by failure to find a
	nd the nexthops of the FIB entry after LNPM FIB lookup.</t>	match between the decoded nexthop ID and the nexthops of the FIB entry
		after LNPM FIB lookup.</t>


	<t>On detecting an invalid path label, the forwarder SHOULD respond to t	<t>On detecting an invalid path label, the forwarder
	he Interest with an Interest-Return. We therefore define a new <em>Invalid path	<bcp14>SHOULD</bcp14> respond to the Interest with an
	label</em> response code for the Interest Return message and include the current	InterestReturn. Therefore, we define a new <em>invalid path
	path label as a hop-by-hop header. Each transit forwarder processing the Intere	label</em> response code for the InterestReturn message and include
	st-Return message updates the path label in the same manner as Content (Data) me	the current path label as a hop-by-hop header. Each transit forwarder
	ssages, so that the consumer receiving the Interest-Return (NACK) can easily ide	processing the InterestReturn message updates the path label in the
	ntify which path label is no longer valid.</t>	same manner as Content (Data) messages so that the consumer receiving
		the InterestReturn (NACK) can easily identify which path label is no
		longer valid.</t>


	<t>A consumer may alternatively request that a forwarder detectin	<t>A consumer may alternatively request that a forwarder detecting the
	g the inconsistency forward the Interest by means of normal LNPM FIB lookup rath	inconsistency forward the Interest by means of normal LNPM FIB lookup
	er than returning an error. The consumer endpoint, if it cares, can keep enough	rather than return an error. The consumer endpoint, if it cares,
	information about outstanding Interests to determine if the path label sent with	can keep enough information about outstanding Interests to determine
	the Interest fails to match the path label in the corresponding returned Conten	if the path label sent with the Interest fails to match the path label
	t (Data), and use that information to replace stale path labels. It does so by s	in the corresponding returned Content (Data) and use that information
	etting the FALLBACK MODE flag of the path label TLV in its Interest message.</t>	to replace stale path labels. It does so by setting the FALLBACK_MODE
		flag of the path label TLV in its Interest message.</t>
	</section>	</section>

	<section anchor="Interest-Aggregation">	<section anchor="Interest-Aggregation">
	<name>Interactions with Interest Aggregation</name>	<name>Interactions with Interest Aggregation</name>


	<t>If two or more Interests matching the same PIT entry arrive at a forwa	<t>If two or more Interests matching the same Pending Interest Table
	rder, under current behavior they will be aggregated whether or not they carry i	(PIT) entry arrive at a forwarder, under current behavior, they will
	dentical Path Labels TLVs. This may or may not be appropriate. For example,	be aggregated whether or not they carry identical path label
	multiple Interests with different MODES (e.g. one with DISCOVERY MODE and	TLVs. This may or may not be appropriate. For example, multiple
	one without) will get aggregated, and the behavior of the forwarder might there	Interests with different modes (e.g., one with DISCOVERY_MODE and one
	fore be dependent on the arrival order of those Interests. In particular,</t>	without) will get aggregated; therefore, the behavior of the forwarder
	<ul>	might be dependent on the arrival order of those Interests. In
	<li>If the DISCOVERY MODE Interest arrives first, it will be forw	particular:</t>
	arded and potentially discover a new path, while the other Interest would be agg	<ul spacing="normal">
	regated. If that Interest carried no Path Label, its behavior is essentially unc	<li>If the DISCOVERY_MODE Interest arrives first, it will be
	hanged, but if it carried a non DISCOVERY MODE Path Label, the consumer's intent	forwarded and potentially discover a new path, while the other
	for the Interest to traverse the specified path will be ignored and it is indet	Interest will be aggregated. If that Interest carried no path
	erminate if the chosen path will actually be used.</li>	label, its behavior is essentially unchanged, but if it carried a
	<li>If the two Interests arrive in the reverse order, the DISCOVE	path label without specifying DISCOVERY_MODE, the consumer's intent
	RY MODE Interest will be aggregated and the consumer issuing it does not achieve	for the Interest to traverse the specified path will be ignored, and
	its desire to discover a new path.</li>	it is indeterminate if the chosen path will actually be used.</li>
		<li>If the two Interests arrive in the reverse order, the DISCOVERY
		MODE Interest will be aggregated, and the consumer issuing it will
		not achieve its desire to discover a new path.</li>
	</ul>	</ul>

	<t>Multiple Interests intended to discover paths (i.e. by carrying the DI SCOVERY MODE flag defined in <xref target="label-encoding"/>) might also be aggr egated by a forwarder. This limits the ability to discover multiple paths in par allel and instead must be discovered incrementally in subsequent exchanges. In o ther words, aggregated Interests will all discover only one single path carried by one single Data packet. This has implications for management applications lik e <xref target="I-D.irtf-icnrg-icntraceroute">Traceroute</xref> which would like ly perform much better if they discover paths in parallel. Hence, it is RECOMME NDED when employing Path Steering that such applications craft their Interests w ith unique name suffixes in order to avoid being aggregated.</t>


	<aside><t>While path steering still operates correctly if DISCOVE	<t>Multiple Interests intended to discover paths (i.e., by carrying
	RY MODE Interests are aggregated, after further experimentation it may be approp	the DISCOVERY_MODE flag defined in <xref target="Path-label-types"/>)
	riate to advise that:</t>	might also be aggregated by a forwarder. This limits the ability to
	<ul>	discover multiple paths in parallel and, instead, must be discovered
	<li>a forwarder SHOULD NOT aggregate Interests carrying d	incrementally in subsequent exchanges. In other words, aggregated
	ifferent Path Labels, and</li>	Interests will all discover only one single path carried by one single
	<li>SHOULD apply a rate limit to DISCOVERY MODE Interests	Data packet. This has implications for management applications, like
	in order to limit redundant traffic.</li>	<xref target="RFC9507">traceroute</xref>, which would likely perform
	</ul></aside>	much better if they discover paths in parallel. Hence, when employing pat
		h steering, it is
		<bcp14>RECOMMENDED</bcp14> that such
		applications craft their Interests with unique name suffixes in order
		to avoid being aggregated.</t>

		<aside><t>While path steering still operates correctly if DISCOVERY
		MODE Interests are aggregated, after further experimentation, it may be
		appropriate to advise that a forwarder:</t>
		<ul spacing="normal">
		<li><bcp14>SHOULD NOT</bcp14> aggregate Interests carrying different
		path labels and</li>
		<li><bcp14>SHOULD</bcp14> apply a rate limit to DISCOVERY_MODE
		Interests in order to limit redundant traffic.</li>
		</ul>
		</aside>

	</section>	</section>

	<section anchor="label-encoding" numbered="true" toc="default">	<section anchor="label-encoding" numbered="true" toc="default">

	<name>How to represent the Path Label</name>	<name>How to Represent the Path Label</name>


	<t><xref target="Moiseenko2017" format="default"/> presents various opti	<t><xref target="Moiseenko2017" format="default"/> presents various
	ons for how to represent a path label, with different tradeoffs in flexibility,	options for how to represent a path label, with different trade-offs in
	performance and space efficiency. For this specification, we choose the <em>Poly	flexibility, performance, and space efficiency. For this
	nomial encoding</em> which achieves reasonable space efficiency at the cost of e	specification, we choose the <em>polynomial encoding</em>, which
	stablishing a hard limit on the length of paths that can be represented.</t>	achieves reasonable space efficiency at the cost of establishing a
	<t>The polynomial encoding utilizes a fixed-size bit array. Each transit	hard limit on the length of paths that can be represented.</t>
	ICN forwarder is allocated a fixed sized portion of the bit array. This design	<t>The polynomial encoding utilizes a fixed-size bit array. Each
	allocates 12 bits (i.e. 4095 as a <em>generator polynomial</em>) to each interme	transit ICN forwarder is allocated a fixed-size portion of the bit
	diate ICN forwarder. This matches the scalability of today's commercial routers	array. This design allocates 12 bits (i.e., 4095 as a <em>generator
	that support up to 4096 physical and logical interfaces and usually do not have	polynomial</em>) to each intermediate ICN forwarder. This matches the
	more than a few hundred active ones.</t>	scalability of today's commercial routers that support up to 4096
		physical and logical interfaces and usually do not have more than a
		few hundred active ones.</t>

	<figure>	<figure>

	<name>Fixed size path label</name>	<name>Fixed-Size Path Label</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	+------------------------------------------------------------------+	+------------------------------------------------------------------+

	\| Path Label bitmap \|	\| path label bitmap \|
	+----------+-----------------+-----------------+-------------------+	+----------+-----------------+-----------------+-------------------+

	\| index \| nexthop label \| nexthop label \| \|	\| index \| Nexthop Label \| Nexthop Label \| \|
	+----------+-----------------+-----------------+-------------------+	+----------+-----------------+-----------------+-------------------+
	\|<- 8bit ->\|<---- 12bit ---->\|<---- 12bit ---->\|<----------------->\|	\|<- 8bit ->\|<---- 12bit ---->\|<---- 12bit ---->\|<----------------->\|
	]]></artwork>	]]></artwork>
	</figure>	</figure>


	<t>A forwarder that receives a Content (Data) message encodes the nextho p label in the next available slot and increments label index. Conversely, a for warder that receives an Interest message reads the current nexthop label and dec rements label index. Therefore, the extra computation required at each hop to fo rward either an interest or Content Object message with a path label is minimize d and constitutes a fairly trivial additional overhead compared to FIB lookup an d other required operations.</t>	<t>A forwarder that receives a Content (Data) message encodes the Nextho p Label in the next available slot and increments the label index. Conversely, a forwarder that receives an Interest message reads the current Nexthop Label and decrements the label index. Therefore, the extra computation required at each h op to forward either an Interest or Content Object message with a path label is minimized and constitutes a fairly trivial additional overhead compared to FIB l ookup and other required operations.</t>


	<t>This approach results in individual path label TLV instances being of	<t>This approach results in individual path label TLV instances being
	fixed pre-computed size. While this places a hard upper bound on the maximum nu	of fixed pre-computed size. While this places a hard upper bound on
	mber of network hops that can be represented, this is not a significant a practi	the maximum number of network hops that can be represented, this is
	cal problem in NDN and CCNx, since the size can be pre-set during Content(Data)	not a significant practical problem in NDN and CCNx, since the size
	message encoding based on the exact number of network hops traversed by the Inte	can be preset during Content (Data) message encoding based on the
	rest message. Even long paths of 24 hops will fit in a path label bitmap of 36 b	exact number of network hops traversed by the Interest message. Even
	ytes if nexthop label is encoded in 12 bits.</t>	long paths of 24 hops will fit in a path label bitmap of 36 bytes if
		the Nexthop Label is encoded in 12 bits.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="encoding" numbered="true" toc="default">	<section anchor="encoding" numbered="true" toc="default">

	<name>Mapping to CCNx and NDN packet encodings</name>	<name>Mapping to CCNx and NDN Packet Encodings</name>
	<section anchor="Path-label-types" numbered="true" toc="default">	<section anchor="Path-label-types" numbered="true" toc="default">

	<name>Path label TLV</name>	<name>Path Label TLV</name>
	<t> A Path label TLV is the tuple: {[Flags], [Path Label Hop Count], [Ne	<t> A path label TLV is the tuple: {[Flags], [Path Label Hop Count],
	xthop Label],	[Nexthop Label], [path label bitmap]}.</t>
	[Path label bitmap]}.</t>
	<table anchor="pathlabelflags" align="left">	<table anchor="pathlabelflags" align="left">

	<name>Path label flags</name>	<name>Path Label Flags</name>
	<thead>	<thead>
	<tr>	<tr>
	<th align="center">Flag</th>	<th align="center">Flag</th>
	<th align="center">Value (hex)</th>	<th align="center">Value (hex)</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>
	<td align="center">DISCOVERY_MODE</td>	<td align="center">DISCOVERY_MODE</td>
	<td align="center">0x00</td>	<td align="center">0x00</td>

	skipping to change at line 333 ¶	skipping to change at line 533 ¶
	<tr>	<tr>
	<td align="center">STRICT_MODE</td>	<td align="center">STRICT_MODE</td>
	<td align="center">0x02</td>	<td align="center">0x02</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="center">Unassigned</td>	<td align="center">Unassigned</td>
	<td align="center">0x03-0xFF</td>	<td align="center">0x03-0xFF</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>

		<t>The Path Label Hop Count (PLHC) <bcp14>MUST</bcp14> be incremented
		by NDN and CCNx forwarders if the Interest packet carries a path label
		and the DISCOVERY_MODE flag is set. A producer node or a forwarder with
		a
		cached Data packet <bcp14>MUST</bcp14> use the PLHC in calculation of a
		path label bitmap size that is suitable for encoding the entire path to
		the
		consumer. The PLHC <bcp14>MUST</bcp14> be set to zero in newly created
		Data or InterestReturn (NACK) packets. A consumer node
		<bcp14>MUST</bcp14> reuse the PLHC together with the path label bitmap
		(PLB) in order to correctly forward the Interest(s) along the
		corresponding network path.</t>


	<t>The Path Label Hop Count (PLHC) MUST be incremented by NDN and CCNx f	<t>If an NDN or CCNx forwarder supports path labeling, the Nexthop
	orwarders if the Interest packet carries a path label and DISCOVERY mode flag	Label <bcp14>MUST</bcp14> be used to determine the correct egress
	is set. A producer node or a forwarder with cached data packet MUST use PLHC in	interface for an Interest packet carrying either the FALLBACK_MODE or th
	calculation of a path label bitmap size suitable for encoding the entire path t	e
	o the consumer. The Path Label Hop Count (PLHC) MUST be set to zero in newly cre	STRICT_MODE flag. If any particular NDN or CCNx forwarder is
	ated Data or Interest-Return (NACK) packets. A consumer node MUST reuse Path Lab	configured to decrypt path labels of Interest packets (see <xref
	el Hop Count (PLHC) together with the Path label bitmap (PLB) in order to correc	target="security" format="title"/>), then the forwarder
	tly forward the Interest(s) along the corresponding network path.</t>	<bcp14>MUST</bcp14>:

	<t>If an NDN or CCNx forwarder supports path labeling, the Nexthop label
	MUST be used to determine the correct egress interface for an Interest packet
	carrying either the FALLBACK MODE or STRICT MODE flag. If any particular NDN or
	CCNx forwarder is configured to decrypt path labels of Interest packets (Section
	<xref target="security">Security Considerations</xref>), then the forwarder MUS
	T
	</t>	</t>
	<ol spacing="normal" type="1">	<ol spacing="normal" type="1">
	<li>decrypt the path label with its own symmetric key,</li>	<li>decrypt the path label with its own symmetric key,</li>

	<li>update the nexthop label with outermost label in the path label,</	<li>update the Nexthop Label with outermost label in the path
	li>	label,</li>
	<li>decrement Path Label Hop Count (PLHC), and</li>	<li>decrement the PLHC, and</li>
	<li>remove the outermost label from the path label.</li>	<li>remove the outermost label from the path label.</li>
	</ol>	</ol>


	<t>If any particular NDN or CCNx forwarder is NOT configured to decrypt	<t>If any particular NDN or CCNx forwarder is NOT configured to
	path labels of Interest packets, then path label decryption SHOULD NOT be perfor	decrypt path labels of Interest packets, then path label decryption
	med.</t>	<bcp14>SHOULD NOT</bcp14> be performed.</t>


	<t> The Nexthop label MUST be ignored by NDN and CCNx forwarders if pres	<t> The Nexthop Label <bcp14>MUST</bcp14> be ignored by NDN and CCNx
	ent in Data or Interest-Return (NACK) packets. If any particular NDN or CCNx for	forwarders if it is present in Data or InterestReturn (NACK) packets. If
	warder is configured to encrypt path labels of Data and Interest-Return (NACK) p	any particular NDN or CCNx forwarder is configured to encrypt path
	ackets (Section <xref target="security">Security Considerations</xref>), then th	labels of Data and InterestReturn (NACK) packets (see <xref
	e forwarder MUST encrypt existing path label with its own symmetric key, append	target="security" format="title"/>), then the forwarder
	the nexthop label of the ingress interface to the path label, and increment Path	<bcp14>MUST</bcp14> encrypt the existing path label with its own symmetr
	Label Hop Count (PLHC). If any particular NDN or CCNx forwarder is NOT configur	ic
	ed to encrypt path labels of Interest packets, then path label encryption SHOULD	key, append the Nexthop Label of the ingress interface to the path
	NOT be performed.</t>	label, and increment the PLHC. If any particular NDN or CCNx forwarder i
		s
		NOT configured to encrypt path labels of Interest packets, then path
		label encryption <bcp14>SHOULD NOT</bcp14> be performed.</t>


	<t>NDN and CCNx forwarders MUST fallback to longest name prefix match (L	<t>NDN and CCNx forwarders <bcp14>MUST</bcp14> fall back to Longest
	NPM) FIB lookup if an Interest packet carries an invalid nexthop label and the F	Name Prefix Match (LNPM) FIB lookup if an Interest packet carries an
	ALLBACK MODE flag is set.</t>	invalid Nexthop Label and the FALLBACK_MODE flag is set.</t>


	<t>CCNx forwarders MUST respond with an Interest Return packet specifyin	<t>CCNx forwarders <bcp14>MUST</bcp14> respond with an InterestReturn
	g a T_RETURN_INVALID_PATH_LABEL code if Interest packet carries an invalid path	packet specifying a T_RETURN_INVALID_PATH_LABEL code if the Interest
	label and the STRICT MODE flag is set. This is a new Interrest return code defin	packet carries an invalid path label and the STRICT_MODE flag is set.
	ed herein (see <xref target="IANA"/> for the value allocation).</t>	This is a new InterestReturn code defined herein (see <xref target="IANA"
		/> for the value allocation).</t>


	<t>CCNx forwarders MUST respond with an Interest Return packet specifyin g the existing T_RETURN_MALFORMED_INTEREST code if the Interest packet carries a path label TLV with both FALLBACK MODE and STRICT MODE flags set.</t>	<t>CCNx forwarders <bcp14>MUST</bcp14> respond with an InterestReturn pa cket specifying the existing T_RETURN_MALFORMED_INTEREST code if the Interest pa cket carries a path label TLV with both the FALLBACK_MODE and STRICT_MODE flags set.</t>

	</section>	</section>
	<section anchor="CCNx-encoding" numbered="true" toc="default">	<section anchor="CCNx-encoding" numbered="true" toc="default">

	<name>Path label encoding for CCNx</name>	<name>Path Label Encoding for CCNx</name>
	<t>Path Label is an optional Hop-by-Hop header TLV that can be present i	<t>Path label is an optional hop-by-hop header TLV that can be present i
	n CCNx Interest, InterestReturn and Content Object packets.</t>	n CCNx Interest, InterestReturn, and Content Object packets.</t>

	<figure>	<figure>

	<name>Path label Hop-by-Hop header TLV for CCNx</name>	<name>Path Label Hop-by-Hop Header TLV for CCNx</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[

	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+---------------+---------------+---------------+---------------+	+---------------+---------------+---------------+---------------+
	\| T_PATH_LABEL \| Length + 4 \|	\| T_PATH_LABEL \| Length + 4 \|
	+---------------+---------------+---------------+---------------+	+---------------+---------------+---------------+---------------+
	\| Flags \| Path Label \| Nexthop Label \|	\| Flags \| Path Label \| Nexthop Label \|
	\| \| Hop Count \| \|	\| \| Hop Count \| \|
	+---------------+---------------+---------------+---------------+	+---------------+---------------+---------------+---------------+
	/ /	/ /
	/ Path label bitmap (Length octets) /	/ Path label bitmap (Length octets) /
	/ /	/ /
	+---------------+---------------+---------------+---------------+	+---------------+---------------+---------------+---------------+
	]]></artwork>	]]></artwork>
	</figure>	</figure>
	</section>	</section>

	<section anchor="NDN-encoding" numbered="true" toc="default">	<section anchor="NDN-encoding" numbered="true" toc="default">

	<name>Path label encoding for NDN</name>	<name>Path Label Encoding for NDN</name>
	<t>Path Label is an optional TLV for NDN Interest and Data packets which
	is carried in the <xref target="NDNLPv2">NDN Link Adaptation Protocol</xref> us	<t>Path label is an optional TLV for NDN Interest and Data packets.
	ed to wrap NDN packets for carriage over various link layer protocols. NDNLPv2 w	It is carried in the <xref target="NDNLPv2">NDN Link Adaptation
	as chosen over the NDN packet itself since it can carry hop-by-hop information t	Protocol</xref>, which is used to wrap NDN packets for carriage over
	hat potentially mutates at each hop and therefore cannot be included in the secu	various link layer protocols. NDNLPv2 was chosen over the NDN packet
	red hash computation or the signature of NDN packets. Further, it can be used in	itself since it can carry hop-by-hop information that potentially
	stead of the existing <tt>NextHopFaceId</tt> TLV since it not only can specify t	mutates at each hop and, therefore, cannot be included in the secured
	he single outgoing face for a consumer, but manages the selection and forwarding	hash computation or the signature of NDN packets. Further, it can be
	over an entire path. The Path Label TLV in NDNLPv2 is defined below:</t>	used instead of the existing <tt>NextHopFaceId</tt> TLV since it not
		only can specify the single outgoing face for a consumer but manages
		the selection and forwarding over an entire path. The path label TLV
		in NDNLPv2 is defined below:</t>

	<figure>	<figure>

	<name>Path label TLV for NDN</name>	<name>Path Label TLV for NDN</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	PathLabel = PATH-LABEL-TYPE TLV-LENGTH	PathLabel = PATH-LABEL-TYPE TLV-LENGTH
	PathLabelFlags	PathLabelFlags
	PathLabelBitmap	PathLabelBitmap

	PathLabelFlags = PATH-LABEL-FLAGS-TYPE	PathLabelFlags = PATH-LABEL-FLAGS-TYPE
	TLV-LENGTH ; == 1	TLV-LENGTH ; == 1
	OCTET	OCTET

	NexthopLabel = PATH-LABEL-NEXTHOP-LABEL-TYPE	NexthopLabel = PATH-LABEL-NEXTHOP-LABEL-TYPE

	skipping to change at line 407 ¶	skipping to change at line 650 ¶
	TLV-LENGTH ; == 1	TLV-LENGTH ; == 1
	OCTET	OCTET

	PathLabelBitmap = PATH-LABEL-BITMAP-TYPE	PathLabelBitmap = PATH-LABEL-BITMAP-TYPE
	TLV-LENGTH ; == 64	TLV-LENGTH ; == 64
	64 OCTET	64 OCTET
	]]></artwork>	]]></artwork>
	</figure>	</figure>

	<table anchor="pathlabelTLVs" align="left">	<table anchor="pathlabelTLVs" align="left">

	<name>TLV-TYPE number assignments for NDN</name>	<name>TLV-TYPE Number Assignments for NDN</name>
	<thead>	<thead>
	<tr>	<tr>
	<th align="center">Flag</th>	<th align="center">Flag</th>
	<th align="center">(Suggested) Value (hex)</th>	<th align="center">(Suggested) Value (hex)</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>
	<td align="left">T_PATH_LABEL</td>	<td align="left">T_PATH_LABEL</td>
	<td align="center">0x0A</td>	<td align="center">0x0A</td>

	skipping to change at line 442 ¶	skipping to change at line 685 ¶
	<td align="left">T_PATH_LABEL_HOP_COUNT</td>	<td align="left">T_PATH_LABEL_HOP_COUNT</td>
	<td align="center">0x0F</td>	<td align="center">0x0F</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>
	</section>	</section>
	</section>	</section>

	<section anchor="IANA" numbered="true" toc="default">	<section anchor="IANA" numbered="true" toc="default">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>

	<t>IANA is requested to make the following assignments:</t>	<t>IANA has made the following assignments:</t>

	<ol spacing="normal" type="1">	<ol spacing="normal" type="1">

	<li> Please assign the value 0x000A (if still available) for T_PATH_LABE	<li>The value 0x000A has been assigned to
	L in the <strong>CCNx Hop-by-Hop Types</strong> registry established by <xref ta	T_PATH_LABEL in the "CCNx Hop-by-Hop Types" registry,
	rget="RFC8609"/>.</li>	established by <xref target="RFC8609"/>.</li>
	<!--> <li>Please assign the TLV types specified in <xref target="pathlabe	<li>The value 0x0A has been assigned to
	lTLVs"/> in the <strong>CCNx Hop-by-Hop type</strong> registry established by <x	T_RETURN_INVALID_PATH_LABEL in the "CCNx Interest Return Code
	ref target="RFC8609"/>.</li> -->	Types" registry, established by <xref target="RFC8609"/>.</li>

	<li>Please assign the value 0x0A (if still available) for the T_RETURN_I
	NVALID_PATH_LABEL in the <strong>CCNx Interest Return Code Types"</strong> regis
	try established by <xref target="RFC8609"/>.</li>
	<!--> <li>Please create the <strong>CCNx Path Label Flags</strong> regist
	ry and assign the values listed in <xref target="pathlabelflags"/>. The registra
	tion procedure for this registry should be "Specification Required" as defined i
	n <xref target="RFC8126"/>.</li> -->
	</ol>	</ol>
	</section>	</section>

	<section anchor="security"><name>Security Considerations</name>	<section anchor="security"><name>Security Considerations</name>

	<t>A path is invalidated by renumbering nexthop label(s). A malicious cons	<t>A path is invalidated by renumbering one or more Nexthop Labels. A mali
	umer can attempt to mount an attack by transmitting Interests with path labels w	cious
	hich differ only in a single now-invalid nexthop label in order to <em>brute for	consumer can attempt to mount an attack by transmitting Interests with
	ce</em> a valid nexthop label. If such an attack succeeds, a malicious consumer	path labels that differ only in a single now-invalid Nexthop Label in
	would be capable of steering Interests over a network path that may not match th	order to <em>brute-force</em> a valid Nexthop Label. If such an attack
	e paths computed by the routing algorithm or learned adaptively by the forwarder	succeeds, a malicious consumer would be capable of steering Interests
	s.</t>	over a network path that may not match the paths computed by the routing
		algorithm or learned adaptively by the forwarders.</t>


	<t>When a label lookup fails, by default an <em>Invalid path label</em> In	<t>When a label lookup fails, by default, an <em>invalid path label</em>
	terest-Return (NACK) message is returned to the consumer. This contains a path l	InterestReturn (NACK) message is returned to the consumer. This
	abel identical to the one included in the corresponding Interest message. A mali	contains a path label identical to the one included in the corresponding
	cious consumer can therefore analyze the message's Hop Count field to infer whic	Interest message. Therefore, a malicious consumer can analyze the
	h specific nexthop label had failed and direct an attack to influence path steer	message's Hop Count field to infer which specific Nexthop Label had
	ing at that hop. This threat can be mitigated by the following countermeasures:<	failed and direct an attack to influence path steering at that hop. This
	/t>	threat can be mitigated by the following countermeasures:</t>

	<ul spacing="normal">	<ul spacing="normal">

	<li>A nexthop label of larger size is harder to crack. If nexthop labels are not allocated in a predictable fashion by the routers, brute forcing a 32-b it nexthop label requires on average O(2^31) Interests. However, this specificat ion uses nexthop labels with much less entropy (12 bits), so depending on comput ational hardness is not workable.</li>


	<li>An ICN forwarder can periodically update nexthop labels to limit the	<li>A Nexthop Label that is larger in size is harder to crack. If Nextho
	maximum lifetime of paths. It is RECOMMENDED that forwarders update path labels	p
	at least every few minutes.</li>	Labels are not allocated in a predictable fashion by the routers,
		brute-forcing a 32-bit Nexthop Label requires on average O(2<sup>31</sup
		>)
		Interests. However, this specification uses Nexthop Labels with much
		less entropy (12 bits), so depending on computational hardness is not
		workable.</li>


	<li>A void Hop Count field in an <em>Invalid path label</em> Interest-Re	<li>An ICN forwarder can periodically update Nexthop Labels to limit
	turn (NACK) message would not give out the information on which specific nexthop	the maximum lifetime of paths. It is <bcp14>RECOMMENDED</bcp14> that
	label had failed. An attacker might need to brute force all nexthop labels in a	forwarders update path labels at least every few minutes.</li>
	ll combinations. However, some useful diagnostic capability is lost by obscuring
	the hop count. For example the locus of routing churn is harder to pin down thr	<li>A void Hop Count field in an <em>invalid path label</em>
	ough analysis of path-steered pings or traceroutes. A forwarder MAY choose to in	InterestReturn (NACK) message would not give out the information on
	validate the hop count in addition to changing nexthop labels periodically as ab	which a specific Nexthop Label had failed. An attacker might need to
	ove.</li>	brute-force all Nexthop Labels in all combinations. However, some
		useful diagnostic capability is lost by obscuring the hop count. For
		example, the locus of routing churn is harder to pin down through
		analysis of path-steered pings or traceroutes. A forwarder
		<bcp14>MAY</bcp14> choose to invalidate the hop count in addition to
		changing Nexthop Labels periodically as described above.</li>
	</ul>	</ul>


	<t>Because ICN forwarders maintain per-face state and forwarding state for	<t>Because ICN forwarders maintain per-face state and forwarding state
	Interest messages, state inflation attacks are a general concern. The addition	for Interest messages, state inflation attacks are a general
	of path steering capabilities in Interest and Data messages does not, however, c	concern. The addition of path steering capabilities in Interest and Data
	onstitute a meaningful increase in susceptibility to such attacks. This is becau	messages does not, however, constitute a meaningful increase in
	se:</t>	susceptibility to such attacks. This is because:</t>
	<ul>	<ul spacing="normal">
	<li>The labels that identify each forwarding face is state O(numb
	er of faces) and constitutes a small increase to the existing state needed to r
	epresent a face.</li>
	<li>Interest message data is placed in the PIT. The path steering
	header does in fact inflate the size of the Interest message and hence the PIT
	state, but not by an amount that is a concern. The forwarder needs to protect ag
	ainst state inflation attacks on the PIT in general, and an attacker can mount o
	ne as or more easily just by issuing interests with long names and/or by includi
	ng Interest payload data.</li>
	</ul>


	<t>ICN protocols can be susceptible to a variety of cache poisoning attack	<li>The labels that identify each forwarding face is state O(number of
	s, where a colluding consumer and producer arrange for bogus content (with eithe	faces) and constitutes a small increase to the existing state needed
	r invalid or inappropriate signatures) to populate forwarder caches. These are g	to represent a face.</li>
	enerally confined to on-path attacks. It is also theoretically possible to launc	<li>Interest message data is placed in the PIT. The path steering
	h a similar attack without a cooperating producer such that the caches of on-pat	header does, in fact, inflate the size of the Interest message and,
	h routers become poisoned with the content from off-path routers (i.e. physical	hence, the PIT state but not by an amount that is a concern. The
	connectivity, but no route in a FIB for a given prefix). We estimate that withou	forwarder needs to protect against state inflation attacks on the PIT
	t any prior knowledge of the network topology, the complexity of this type of at	in general, and an attacker can mount one just as or more easily by
	tack is in the ballpark of Breadth-First-Search and Depth-First-Search algorithm	issuing Interests with long names and/or by including Interest payload
	s with the additional burden of transmitting 2^31 Interests in order to crack a	data.</li>
	nexthop label on each hop.	</ul>


	Relatively short periodic update of nexthop labels and anti- <em>label sc	<t>ICN protocols can be susceptible to a variety of cache poisoning
	an</em> heuristics implemented in the ICN forwarder may successfully mitigate th	attacks, where a colluding consumer and producer arrange for bogus
	is type of attack.</t>	content (with either invalid or inappropriate signatures) to populate
		forwarder caches. These are generally confined to on-path attacks. It is
		also theoretically possible to launch a similar attack without a
		cooperating producer such that the caches of on-path routers become
		poisoned with the content from off-path routers (i.e., physical
		connectivity but no route in a FIB for a given prefix). We estimate
		that, without any prior knowledge of the network topology, the
		complexity of this type of attack is in the ballpark of
		Breadth-First-Search and Depth-First-Search algorithms with the
		additional burden of transmitting 2<sup>31</sup> Interests in order to
		crack a Nexthop Label on each hop. A relatively short periodic update
		of Nexthop Labels, together with heuristics implemented in the ICN
		forwarder to foil <em>label scans</em>, may successfully mitigate this
		type of attack.</t>

	<section anchor="encryptpathlabel">	<section anchor="encryptpathlabel">

	<name>Cryptographic protection of a path label</name>	<name>Cryptographic Protection of a Path Label</name>
	<t>If the countermeasures listed above do not provide sufficient protect	<t>If the countermeasures listed above do not provide sufficient
	ion against malicious mis-steering of Interests, the path label can be made opaq	protection against malicious mis-steering of Interests, the path label
	ue to the consumer endpoint via hop-by-hop symmetric cryptography applied to the	can be made opaque to the consumer endpoint via hop-by-hop symmetric
	path labels (<xref target="pathlabelcryptoprocess"/>). This method is viable du	cryptography applied to the path labels (<xref
	e to the symmetry of forward and reverse paths in CCNx and NDN architectures com	target="pathlabelcryptoprocess"/>). This method is viable due to the
	bined with ICN path steering requiring only reads/writes of the topmost nexthop	symmetry of forward and reverse paths in CCNx and NDN architectures
	label (i.e. active nexthop label) in the path label. This way a path steering ca	combined with ICN path steering requiring only reads and writes of the
	pable ICN forwarder receiving a Data (Content) message encrypts the current path	topmost Nexthop Label (i.e., active Nexthop Label) in the path
	label with its own non-shared symmetric key prior to adding a new nexthop label	label. This way, a path-steering-capable ICN forwarder receiving a
	to the path label. The Data (Content) message is forwarded downstream with unen	Content (Data) message encrypts the current path label with its own
	crypted topmost (i.e active) nexthop label and encrypted remaining content of th	non-shared symmetric key prior to adding a new Nexthop Label to the
	e path label. As a result, a consumer endpoint receives a Data (Content) message	path label. The Content (Data) message is forwarded downstream with an
	with a unique path label exposing only the topmost nexthop label as cleartext.	unencrypted topmost (i.e., active) Nexthop Label and the remaining
	A path steering forwarder receiving an Interest message performs label lookup u	encrypted content of the path label. As a result, a consumer endpoint
	sing the topmost nexthop label, decrypts the path label with its own non-shared	receives a Content (Data) message with a unique path label exposing
	symmetric key, and forwards the message upstream.</t>	only the topmost Nexthop Label as cleartext. A path steering forwarder
		receiving an Interest message performs label lookup using the topmost
		Nexthop Label, decrypts the path label with its own non-shared
		symmetric key, and forwards the message upstream.</t>


	<t>Cryptographic protection of a path label does not require any key neg otiation among ICN forwarders, and is no more expensive than MACsec or IPsec. It is also quite possible that strict hop-by-hop path label encryption is not nece ssary and path label encryption only on the border routers of the trusted admini strative or routing domains may suffice.</t>	<t>Cryptographic protection of a path label does not require any key neg otiation among ICN forwarders and is no more expensive than Media Access Control Security (MACsec) or IPsec. It is also quite possible that strict hop-by-hop pa th label encryption is not necessary and path label encryption only on the borde r routers of the trusted administrative or routing domains may suffice.</t>

	<figure anchor="pathlabelcryptoprocess">	<figure anchor="pathlabelcryptoprocess">

	<name>Path label protection with hop-by-hop symmetric cryptography</na me>	<name>Path Label Protection with Hop-by-Hop Symmetric Cryptography</na me>
	<artwork name="" type="" align="left" alt=""><![CDATA[	<artwork name="" type="" align="left" alt=""><![CDATA[
	Producer	Producer
	\| ^	\| ^
	\| \|	\| \|
	Path Label TLV \| \| Path Label TLV	Path Label TLV \| \| Path Label TLV
	+-----------------------+ \| \| +-----------------------+	+-----------------------+ \| \| +-----------------------+
	\|nexthop label=456 \| v \| \|nexthop label=456 \|	\|nexthop label=456 \| v \| \|nexthop label=456 \|
	\|encrypted path label={}\| Forwarder 3 \|encrypted path label={}\|	\|encrypted path label={}\| Forwarder 3 \|encrypted path label={}\|
	+-----------------------+ \| ^ +-----------------------+	+-----------------------+ \| ^ +-----------------------+
	\| \|	\| \|

	skipping to change at line 541 ¶	skipping to change at line 857 ¶
	\| \|	\| \|
	v \|	v \|
	Consumer	Consumer
	]]></artwork>	]]></artwork>
	</figure>	</figure>
	</section>	</section>
	</section>	</section>
	</middle>	</middle>

	<back>	<back>


		<displayreference target="I-D.irtf-icnrg-flic" to="FLIC"/>
		<displayreference target="I-D.dekater-panrg-scion-overview" to="SCION"/>

	<references><name>References</name>	<references><name>References</name>
	<references><name>Normative References</name>	<references><name>Normative References</name>

	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxm
	l/reference.RFC.2119.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.x
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxm	ml"/>
	l/reference.RFC.8174.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.x
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer	ml"/>
	ence.RFC.8569.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8569.x
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer	ml"/>
	ence.RFC.8609.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8609.x
	<!--> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/	ml"/>
	reference.RFC.8126.xml"/> -->

	<reference anchor="Moiseenko2017" target="https://conferences.sigcomm.or g/acm-icn/2017/proceedings/icn17-2.pdf">	<reference anchor="Moiseenko2017" target="https://conferences.sigcomm.or g/acm-icn/2017/proceedings/icn17-2.pdf">
	<front>	<front>

	<title>Path Switching in Content Centric and Named Data Networks, in 4th ACM Conference on Information-Centric Networking (ICN 2017)</title>	<title>Path Switching in Content Centric and Named Data Networks</ti tle>
	<seriesInfo name="DOI" value="10.1145/3125719.3125721"/>	<seriesInfo name="DOI" value="10.1145/3125719.3125721"/>
	<author surname="Moiseenko" initials="I."/>	<author surname="Moiseenko" initials="I."/>
	<author surname="Oran" initials="D."/>	<author surname="Oran" initials="D."/>
	<date year="2017" month="September"/>	<date year="2017" month="September"/>
	</front>	</front>

		<refcontent>Proceedings of the 4th ACM Conference on
		Information-Centric Networking, Pages 66-76</refcontent>
		<seriesInfo name="DOI" value="10.1145/3125719.3125721"/>
	</reference>	</reference>

	</references>


		</references>
	<references>	<references>
	<name>Informative References</name>	<name>Informative References</name>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	029.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8029.x
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8	ml"/>
	793.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8793.x
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9	ml"/>
	217.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9217.x
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.	ml"/>
	irtf-icnrg-icnping.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.	<reference anchor="RFC9508" target="https://www.rfc-editor.org/info/rfc9508">
	irtf-icnrg-icntraceroute.xml"/>	<front>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.	<title>Information-Centric Networking (ICN) Ping Protocol Specification</title>
	irtf-icnrg-flic.xml"/>	<author initials='S' surname='Mastorakis' fullname='Spyridon Mastorakis'>
		<organization />
		</author>
		<author initials='D' surname='Oran' fullname='David Oran'>
		<organization />
		</author>
		<author initials='J' surname='Gibson' fullname='Jim Gibson'>
		<organization />
		</author>
		<author initials='I' surname='Moiseenko' fullname='Ilya Moiseenko'>
		<organization />
		</author>
		<author initials='R' surname='Droms' fullname='Ralph Droms'>
		<organization />
		</author>
		<date year='2024' month='February'/>
		</front>
		<seriesInfo name="RFC" value="9508"/>
		<seriesInfo name="DOI" value="10.17487/RFC9508"/>
		</reference>

		<reference anchor="RFC9507" target="https://www.rfc-editor.org/info/rfc9507">
		<front>
		<title>Information-Centric Networking (ICN) Traceroute Protocol Specification</t
		itle>
		<author initials='S' surname='Mastorakis' fullname='Spyridon Mastorakis'>
		<organization />
		</author>
		<author initials='D' surname='Oran' fullname='David Oran'>
		<organization />
		</author>
		<author initials='I' surname='Moiseenko' fullname='Ilya Moiseenko'>
		<organization />
		</author>
		<author initials='J' surname='Gibson' fullname='Jim Gibson'>
		<organization />
		</author>
		<author initials='R' surname='Droms' fullname='Ralph Droms'>
		<organization />
		</author>
		<date year='2024' month='February'/>
		</front>
		<seriesInfo name="RFC" value="9507"/>
		<seriesInfo name="DOI" value="10.17487/RFC9507"/>
		</reference>

		<reference anchor="I-D.irtf-icnrg-flic">
		<front>
		<title>File-Like ICN Collections (FLIC)</title>
		<author fullname="Christian Tschudin" initials="C." surname="Tschudin">
		<organization>University of Basel</organization>
		</author>
		<author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
		<organization>Cloudflare</organization>
		</author>
		<author fullname="Marc E. Mosko" initials="M." surname="Mosko">
		<organization>PARC, Inc.</organization>
		</author>
		<author fullname="David Oran" initials="D." surname="Oran" role="editor">
		<organization>Network Systems Research & Design</organization>
		</author>
		<date day="22" month="October" year="2023"/>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-flic-05"/>
		</reference>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D. dekater-panrg-scion-overview.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D. dekater-panrg-scion-overview.xml"/>

	<reference anchor="Mahdian2016" target="http://conferences2.sigcomm.org/ acm-icn/2016/proceedings/p1-mahdian.pdf">	<reference anchor="Mahdian2016" target="http://conferences2.sigcomm.org/ acm-icn/2016/proceedings/p1-mahdian.pdf">
	<front>	<front>

	<title>MIRCC: Multipath-aware ICN Rate-based Congestion Control, in	<title>MIRCC: Multipath-aware ICN Rate-based Congestion Control</tit
	Proceedings of the 3rd ACM Conference on Information-Centric Networking</title>	le>
	<seriesInfo name="DOI" value="10.1145/2984356.2984365"/>
	<author surname="Mahdian" initials="M."/>	<author surname="Mahdian" initials="M."/>
	<author surname="Arianfar" initials="S."/>	<author surname="Arianfar" initials="S."/>
	<author surname="Gibson" initials="J."/>	<author surname="Gibson" initials="J."/>
	<author surname="Oran" initials="D."/>	<author surname="Oran" initials="D."/>

	<date year="2022"/>	<date month="September" year="2016"/>
	</front>	</front>

		<refcontent>Proceedings of the 3rd ACM Conference on
		Information-Centric Networking, Pages 1-10</refcontent>
		<seriesInfo name="DOI" value="10.1145/2984356.2984365"/>
	</reference>	</reference>


	<reference anchor="Song2018" target="https://conferences.sigcomm.org/acm -icn/2018/proceedings/icn18-final62.pdf">	<reference anchor="Song2018" target="https://conferences.sigcomm.org/acm -icn/2018/proceedings/icn18-final62.pdf">
	<front>	<front>

	<title>SMIC: Subflow-level Multi-path Interest Control for Informati	<title>SMIC: Subflow-level Multi-path Interest Control for Informati
	on Centric Networking, in 5th ACM Conference on Information-Centric Networking</	on Centric Networking</title>
	title>
	<seriesInfo name="DOI" value="10.1145/3267955.3267971"/>
	<author surname="Song" initials="J."/>	<author surname="Song" initials="J."/>
	<author surname="Lee" initials="M."/>	<author surname="Lee" initials="M."/>
	<author surname="Kwon" initials="T."/>	<author surname="Kwon" initials="T."/>

	<date year="2018"/>	<date month="September" year="2018"/>
	</front>	</front>

		<refcontent>Proceedings of the 5th ACM Conference on Information-Centri
		c Networking, Pages 77-87</refcontent>
		<seriesInfo name="DOI" value="10.1145/3267955.3267971"/>
	</reference>	</reference>


	<reference anchor="NDN" target="https://named-data.net/project/execsumma ry/">	<reference anchor="NDN" target="https://named-data.net/project/execsumma ry/">
	<front>	<front>

	<title>Named Data Networking</title>	<title>Named Data Networking: Executive Summary</title>
	<author surname="NDN team"/>	<author>
	<date>various</date>	<organization>NDN</organization>
		</author>
	</front>	</front>
	</reference>	</reference>


	<reference anchor="NDNLPv2" target="https://redmine.named-data.net/proje cts/nfd/wiki/NDNLPv2">	<reference anchor="NDNLPv2" target="https://redmine.named-data.net/proje cts/nfd/wiki/NDNLPv2">
	<front>	<front>

	<title>Named Data Networking Link Adaptation Protocol v2</title>	<title>NDNLPv2</title>
	<author surname="NDN team"/>	<author>
	<date>various</date>	<organization>NFD</organization>
		</author>
	</front>	</front>
	</reference>	</reference>


	<reference anchor="NDNTLV" target="https://named-data.net/doc/NDN-packet -spec/current/">	<reference anchor="NDNTLV" target="https://named-data.net/doc/NDN-packet -spec/current/">
	<front>	<front>

	<title>NDN Packet Format Specification 0.3.</title>	<title>NDN Packet Format Specification v0.3</title>
	<author surname="NDN Project Team"/>	<author>
	<date year="2022"/>	<organization>NDN</organization>
		</author>
	</front>	</front>
	</reference>	</reference>
	</references>	</references>
	</references>	</references>

	<!-- Change Log
	v00 2022-10-13 DRO Initial version replacing draft-oran-icnrg-pathsteering-07
	v02 2023-05-18 DRO Updated basedon IRSG review Comments
	-->
	</back>	</back>


	</rfc>	</rfc>

End of changes. 104 change blocks.
	427 lines changed or deleted	594 lines changed or added
This html diff was produced by rfcdiff 1.48.