Movatterモバイル変換

[0]ホーム

	rfc9139xml2.original.xml	rfc9139.xml

	<?xml version="1.0"encoding="US-ASCII"?>	<?xml version="1.0"encoding="UTF-8"?>
	<!DOCTYPE rfcSYSTEM "rfc2629.dtd">	<!DOCTYPE rfc[
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>	<!ENTITY nbsp " ">
	<?rfc toc="yes"?>	<!ENTITY zwsp "">
	<?rfc symrefs="yes"?>	<!ENTITY nbhy "‑">
	<?rfc sortrefs="yes"?>	<!ENTITY wj "⁠">
	<?rfc compact="yes"?>	]>
	<?rfc comments="yes"?>
	<?rfc inline="yes"?>	<rfcxmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-irtf-icnrg-icnlow
	<?rfc linkmailto="no" ?>	pan-11" number="9139" ipr="trust200902"submissionType="IRTF" category="exp" con
	<?rfc rfcedstyle="yes"?>	sensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="t
	<?rfc-ext allow-markup-in-artwork="yes" ?>	rue" sortRefs="true" version="3">
	<?rfc-ext include-references-in-index="yes" ?>
	<rfccategory="exp" docName="draft-irtf-icnrg-icnlowpan-10" ipr="trust200902"	<!-- xml2rfc v2v3 conversion 3.9.1 -->
	submissionType="IRTF">
	<front>	<front>

	<title abbrev="ICN Adaptation to LoWPANs">ICN Adaptation to LoWPAN
	Networks (ICN LoWPAN)</title>


		<!--[rfced] Please ensure that the guidelines listed in Section 2.1 of RFC 5743
		have been adhered to in this document.
		-->

		<!--[rfced] The expansions of "ICN LoWPAN in the document title and Terminology
		section differs. May we update the title as follows?

		Original:
		ICN Adaptation to LoWPAN Networks (ICN LoWPAN)

		Perhaps:
		Information-Centric Networking (ICN) Adaptation to
		Low-Power Wireless Personal Area Networks (LoWPANs)
		-->

		<title abbrev="ICN Adaptation to LoWPANs">ICN
		Adaptation to LoWPAN Networks (ICN LoWPAN)</title>
		<seriesInfo name="RFC" value="9139"/>
		<!-- [rfced] Cenk, we have updated the spelling of your surname from "Gundogan"
		to "Gündogan" based on the information found at <https://inet.haw-hamburg.de/mem
		bers/cenk-gundogan>. Please let us know if any changes are necessary.
		-->
	<author fullname="Cenk Gundogan" initials="C." surname="Gundogan">	<author fullname="Cenk Gundogan" initials="C." surname="Gundogan">
	<organization abbrev="HAW Hamburg">HAW Hamburg</organization>	<organization abbrev="HAW Hamburg">HAW Hamburg</organization>


	<address>	<address>
	<postal>	<postal>
	<street>Berliner Tor 7</street>	<street>Berliner Tor 7</street>


	<city>Hamburg</city>	<city>Hamburg</city>


	<code>D-20099</code>	<code>D-20099</code>


	<country>Germany</country>	<country>Germany</country>
	</postal>	</postal>


	<phone>+4940428758067</phone>	<phone>+4940428758067</phone>


	<email>cenk.guendogan@haw-hamburg.de</email>	<email>cenk.guendogan@haw-hamburg.de</email>


	<uri>http://inet.haw-hamburg.de/members/cenk-gundogan</uri>	<uri>http://inet.haw-hamburg.de/members/cenk-gundogan</uri>
	</address>	</address>
	</author>	</author>


	<author fullname="Thomas C. Schmidt" initials="TC." surname="Schmidt">	<author fullname="Thomas C. Schmidt" initials="TC." surname="Schmidt">
	<organization abbrev="HAW Hamburg">HAW Hamburg</organization>	<organization abbrev="HAW Hamburg">HAW Hamburg</organization>


	<address>	<address>
	<postal>	<postal>
	<street>Berliner Tor 7</street>	<street>Berliner Tor 7</street>


	<city>Hamburg</city>	<city>Hamburg</city>


	<code>D-20099</code>	<code>D-20099</code>


	<country>Germany</country>	<country>Germany</country>
	</postal>	</postal>


	<email>t.schmidt@haw-hamburg.de</email>	<email>t.schmidt@haw-hamburg.de</email>


	<uri>http://inet.haw-hamburg.de/members/schmidt</uri>	<uri>http://inet.haw-hamburg.de/members/schmidt</uri>
	</address>	</address>
	</author>	</author>

		<!-- [rfced] Matthias, we have updated the spelling of your surname from "Waehli
		sch" to "Wählisch". Please let us know if this is not preferred.
		-->
		<!-- [rfced] FYI, We have updated the following URL because it was redirecting.
		Please let us know if any changes are necessary.


	<author fullname="MatthiasWaehlisch" initials="M."surname="Waehlisch">	Original:
		http://www.inf.fu-berlin.de/~waehl

		Current:
		https://www.mi.fu-berlin.de/en/inf/groups/ilab/members/waehlisch.html

		-->
		<author fullname="MatthiasWählisch" initials="M."surname="Wählisch">
	<organization abbrev="link-lab & FU Berlin">link-lab & FU	<organization abbrev="link-lab & FU Berlin">link-lab & FU
	Berlin</organization>	Berlin</organization>


	<address>	<address>
	<postal>	<postal>
	<street>Hoenower Str. 35</street>	<street>Hoenower Str. 35</street>


	<city>Berlin</city>	<city>Berlin</city>


	<code>D-10318</code>	<code>D-10318</code>


	<country>Germany</country>	<country>Germany</country>
	</postal>	</postal>


	<email>mw@link-lab.net</email>	<email>mw@link-lab.net</email>

		<uri>https://www.mi.fu-berlin.de/en/inf/groups/ilab/members/waehlisch.ht
	<uri>http://www.inf.fu-berlin.de/~waehl</uri>	ml</uri>
	</address>	</address>
	</author>	</author>


	<author fullname="Christopher Scherb" initials="C." surname="Scherb">	<author fullname="Christopher Scherb" initials="C." surname="Scherb">
	<organization abbrev="University of Basel">University of	<organization abbrev="University of Basel">University of
	Basel</organization>	Basel</organization>


	<address>	<address>
	<postal>	<postal>
	<street>Spiegelgasse 1</street>	<street>Spiegelgasse 1</street>


	<city>Basel</city>	<city>Basel</city>

		<code>4051</code>
	<code>CH-4051</code>

	<country>Switzerland</country>	<country>Switzerland</country>
	</postal>	</postal>


	<email>christopher.scherb@unibas.ch</email>	<email>christopher.scherb@unibas.ch</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Claudio Marxer" initials="C." surname="Marxer">	<author fullname="Claudio Marxer" initials="C." surname="Marxer">
	<organization abbrev="University of Basel">University of	<organization abbrev="University of Basel">University of
	Basel</organization>	Basel</organization>


	<address>	<address>
	<postal>	<postal>
	<street>Spiegelgasse 1</street>	<street>Spiegelgasse 1</street>


	<city>Basel</city>	<city>Basel</city>

		<code>4051</code>
	<code>CH-4051</code>

	<country>Switzerland</country>	<country>Switzerland</country>
	</postal>	</postal>


	<email>claudio.marxer@unibas.ch</email>	<email>claudio.marxer@unibas.ch</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Christian Tschudin" initials="C." surname="Tschudin">	<author fullname="Christian Tschudin" initials="C." surname="Tschudin">
	<organization abbrev="University of Basel">University of	<organization abbrev="University of Basel">University of
	Basel</organization>	Basel</organization>


	<address>	<address>
	<postal>	<postal>
	<street>Spiegelgasse 1</street>	<street>Spiegelgasse 1</street>


	<city>Basel</city>	<city>Basel</city>

		<code>4051</code>
	<code>CH-4051</code>

	<country>Switzerland</country>	<country>Switzerland</country>
	</postal>	</postal>


	<email>christian.tschudin@unibas.ch</email>	<email>christian.tschudin@unibas.ch</email>
	</address>	</address>
	</author>	</author>

		<date year="2021" month="November" />
		<workgroup>Information-Centric Networking</workgroup>


	<date/>	<!-- [rfced] Please insert any keywords (beyond those that appear in the title)
		for use on https://www.rfc-editor.org/search.
		-->


	<workgroup>ICN Research Group</workgroup>	<keyword>example</keyword>

	<abstract>	<abstract>

	<t>This document defines a convergence layer forCCNx andNDN over IEEE	<t>This document defines a convergence layer forContent-Centric Networkin
	802.15.4LoWPAN networks. A new frame format is specified to adapt CCNx	g
		(CCNx) andNamed Data Networking (NDN) over IEEE
		802.15.4Low-Power Wireless Personal Area Networks (LoWPANs). A
		new frame format is specified to adapt CCNx
	and NDN packets to the small MTU size of IEEE 802.15.4. For that,	and NDN packets to the small MTU size of IEEE 802.15.4. For that,
	syntactic and semantic changes to the TLV-based header formats are	syntactic and semantic changes to the TLV-based header formats are
	described. To support compatibility with other LoWPAN technologies that	described. To support compatibility with other LoWPAN technologies that
	may coexist on a wireless medium, the dispatching scheme provided by	may coexist on a wireless medium, the dispatching scheme provided by

	6LoWPAN is extended to include new dispatch types for CCNx and NDN.	IPv6 over LoWPAN (6LoWPAN) is extended
		to include new dispatch types for CCNx and NDN.
	Additionally, the fragmentation component of the 6LoWPAN	Additionally, the fragmentation component of the 6LoWPAN

	dispatching framework is applied toICN chunks. In its second part, the	dispatching framework is applied toInformation-Centric Network (ICN)
		chunks. In its second part, the
	document defines stateless and stateful compression schemes to improve	document defines stateless and stateful compression schemes to improve
	efficiency on constrained links. Stateless compression reduces TLV	efficiency on constrained links. Stateless compression reduces TLV
	expressions to static header fields for common use cases. Stateful	expressions to static header fields for common use cases. Stateful

	compression schemes elidestate local to the LoWPAN and replace names in	compression schemes elidestates local to the LoWPAN and replace names in
	data packets by short local identifiers.</t>	Data packets by short local identifiers.</t>

	<t>This document is a product of the IRTF Information-Centric	<t>This document is a product of the IRTF Information-Centric
	Networking Research Group (ICNRG).</t>	Networking Research Group (ICNRG).</t>
	</abstract>	</abstract>
	</front>	</front>


	<middle>	<middle>

	<section anchor="intro"title="Introduction">	<section anchor="intro"numbered="true" toc="default">
		<name>Introduction</name>
	<t>The Internet of Things (IoT) has been identified as a promising	<t>The Internet of Things (IoT) has been identified as a promising

	deployment area for Information Centric Networks (ICN), as	deployment area for Information-Centric Networking (ICN), as
	infrastructureless access to content, resilient forwarding, and	infrastructureless access to content, resilient forwarding, and

	in-network data replicationdemonstrated notable advantages over the	in-network data replicationdemonstrates notable advantages over the
	traditional host-to-host approach on the Internet <xref	traditional host-to-host approach on the Internet <xreftarget="NDN-EXP1"
	target="NDN-EXP1"/>, <xreftarget="NDN-EXP2"/>. Recentstudies <xref	format="default"/> <xreftarget="NDN-EXP2" format="default"/>. Recentstud
	target="NDN-MAC"/> have shown that an appropriate mapping tolink layer	ies <xref
	technologies has a large impact on the practical performance of an ICN.	target="NDN-MAC" format="default"/> have shown that an appropriate mapping
		to
		link-layer technologies has a large impact on the practical performance of
		an ICN.
	This will be even more relevant in the context of IoT communication	This will be even more relevant in the context of IoT communication
	where nodes often exchange messages via low-power wireless links under	where nodes often exchange messages via low-power wireless links under
	lossy conditions. In this memo, we address the base adaptation of data	lossy conditions. In this memo, we address the base adaptation of data

	chunks to such link layers for the ICN flavors NDN <xreftarget="NDN"/>	chunks to such link layers for the ICN flavors NDN <xreftarget="NDN"
	and CCNx <xreftarget="RFC8569"/>, <xref/>.</t>	format="default"/> and CCNx <xreftarget="RFC8569" format="default"/> <xre
		f
	<t>The IEEE 802.15.4 <xreftarget="ieee802.15.4"/> linklayer is used in	format="default"/>.</t>
	low-power and lossy networks (see<spanx>LLN</spanx> in	<t>The IEEE 802.15.4 <xreftarget="ieee802.15.4" format="default"/> linkl
	<xreftarget="RFC7228"/>), in which devices are typically	ayer is
	battery-operated and constrained in resources. Characteristics of LLNs	used in low-power and lossy networks (see<tt>LLN</tt> in
	include an unreliable environment,low bandwidth transmissions, and	<xreftarget="RFC7228" format="default"/>), in which devices are typically
	increased latencies. IEEE 802.15.4 admits a maximumphysical layer	battery operated and constrained in resources. Characteristics of LLNs
		include an unreliable environment,low-bandwidth transmissions, and
		increased latencies. IEEE 802.15.4 admits a maximumphysical-layer
	packet size of 127 bytes. The maximum frame header size is 25 bytes,	packet size of 127 bytes. The maximum frame header size is 25 bytes,
	which leaves 102 bytes for the payload. IEEE 802.15.4 security features	which leaves 102 bytes for the payload. IEEE 802.15.4 security features
	further reduce this payload length by up to 21 bytes, yielding a net of	further reduce this payload length by up to 21 bytes, yielding a net of

	81 bytes for CCNx or NDN packet headers,signatures and content.</t>	81 bytes for CCNx or NDN packet headers,signatures, and content.</t>
		<t>6LoWPAN <xreftarget="RFC4944" format="default"/> <xrefRFC4944"/><xref>, </xref> is a	"
	convergence layer that provides frame formats, headercompression and	format="default"/> is a
	adaptation layer fragmentation for IPv6 packets in IEEE 802.15.4 networks.	convergence layer that provides frame formats, headercompression, and
	The	adaptation-layer fragmentation for IPv6 packets in IEEE 802.15.4 networks.
		The
	6LoWPAN adaptation introduces a dispatching framework that prepends	6LoWPAN adaptation introduces a dispatching framework that prepends
	further information to 6LoWPAN packets, including a protocol identifier	further information to 6LoWPAN packets, including a protocol identifier
	for payload and meta information about fragmentation.</t>	for payload and meta information about fragmentation.</t>

		<t>Prevalent packet formatsbased on Type-Length-Value (TLV), such as in
	<t>PrevalentType-Length-Value (TLV) based packet formats such as in	CCNx andNDN, are designed to be generic and extensible. This leads to
	CCNx andNDN are designed to be generic and extensible. This leads to	headerverbosity, which is inappropriate in constrained environments of
	headerverbosity which is inappropriate in constrained environments of
	IEEE 802.15.4 links. This document presents ICN LoWPAN, a convergence	IEEE 802.15.4 links. This document presents ICN LoWPAN, a convergence
	layer for IEEE 802.15.4 motivated by 6LoWPAN. ICN LoWPAN compresses	layer for IEEE 802.15.4 motivated by 6LoWPAN. ICN LoWPAN compresses

	packet headers of CCNx as well as NDN and allows for an increased	packet headers of CCNx, as well as NDN, and allows for an increased
	effective payload size per packet. Additionally, reusing the dispatching	effective payload size per packet. Additionally, reusing the dispatching
	framework defined by 6LoWPAN enables compatibility between coexisting	framework defined by 6LoWPAN enables compatibility between coexisting

	wireless deployments of competing network technologies. This also allowst	wireless deployments of competing network technologies. This also allowsr
	o reuse	euse of
	theadaptation layer fragmentation scheme specified by 6LoWPAN for ICN LoW	theadaptation-layer fragmentation scheme specified by 6LoWPAN for ICN LoW
	PAN.</t>	PAN.</t>
		<t>ICN LoWPAN defines a morespace-efficient representation of CCNx and
	<t>ICN LoWPAN defines a morespace efficient representation of CCNx and
	NDN packet formats. This syntactic change is described for CCNx and NDN	NDN packet formats. This syntactic change is described for CCNx and NDN
	separately, as the header formats and TLV encodings differ notably. For	separately, as the header formats and TLV encodings differ notably. For
	further reductions, default header values suitable for constrained IoT	further reductions, default header values suitable for constrained IoT
	networks are selected in order to elide corresponding TLVs. Experimental	networks are selected in order to elide corresponding TLVs. Experimental

	evaluations of the ICN LoWPAN header compression schemes in <xref	evaluations of the ICN LoWPAN header compression schemes in <xreftarget="
	target="ICNLOWPAN"/> illustrate a reduced message overhead, a shortened	ICNLOWPAN" format="default"/> illustrate a reduced message overhead, a shortened
	message airtime, and an overall decline in power consumption for typical	message airtime, and an overall decline in power consumption for typical

	Class 2<xref/> devices compared touncompressed ICNmess	Class 2 devices<xref format="default"/> compared tounco
	ages.</t>	mpressed ICNmessages.</t>
		<t>In a typical IoT scenario (see <xreftarget="fig-iot_network" format="d
	<t>In a typical IoT scenario (see <xreftarget="fig-iot_network">	efault">
	</xref>), embedded devices are interconnected via a quasi-stationary	</xref>), embedded devices are interconnected via a quasi-stationary
	infrastructure using a border router (BR) that connects the constrained	infrastructure using a border router (BR) that connects the constrained

	LoWPAN network by someGateway with the public Internet. InICN based	LoWPAN network by somegateway with the public Internet. InICN-based
	IoT networks,non-local Interest and Data messages transparently travel	IoT networks,nonlocal Interest and Data messages transparently travel
	through the BR up and down between aGateway and the embedded devices	through the BR up and down between agateway and the embedded devices
	situated in the constrained LoWPAN.</t>	situated in the constrained LoWPAN.</t>

		<figureanchor="fig-iot_network">
	<figureanchor="fig-iot_network" title="IoT StubNetwork">	<name>IoT StubNetwork</name>
	<artworkalign="center"><![CDATA[	<artworkalign="center" name="" type="" alt=""><![CDATA[
	\|Gateway Services\|	\|Gateway Services\|
	-------------------------	-------------------------
	\|	\|
	,--------,	,--------,
	\| \|	\| \|
	\| BR \|	\| BR \|
	\| \|	\| \|
	'--------'	'--------'
	LoWPAN	LoWPAN
	O O	O O
	O	O
	O O embedded	O O embedded
	O O O devices	O O O devices
	O O	O O
	]]></artwork>	]]></artwork>
	</figure>	</figure>


	<t>	<t>

	The document has received fruitful reviews by members of the ICN community and the research group (seeAcknowledgments) for a period of twoyears.	The document has received fruitful reviews by members of the ICN community and the research group (seethe Acknowledgments section) for a period of twoyears.
	It is the consensus of ICNRG that this document should be published in the IRTF Stream of the RFC series.	It is the consensus of ICNRG that this document should be published in the IRTF Stream of the RFC series.
	This document does not constitute an IETF standard.	This document does not constitute an IETF standard.
	</t>	</t>
	</section>	</section>

		<section numbered="true" toc="default">
		<name>Terminology</name>
		<!--[rfced] Please note that we have added RFC 8174 to the Normative References
		section and updated the text in the Terminology section below. Additionally, the
		term "silently ignored" is not used in this document, so we have removed the te
		xt describing it. Please let us know if you have any concerns.


	<section title="Terminology">	Original:
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119<xref	document are to be interpreted as described in RFC 2119[RFC2119].
	/>. The use of the term, "silently ignore" is not	The use of the term, "silently ignore" is not defined in RFC 2119.
	defined in RFC 2119. However, the term is used in this document and can	However, the term is used in this document and can be similarly
	be similarlyconstrued.</t>	construed.

	<t>This document uses the terminology of <xref/>, <xref
	/>, and <xref/> for ICN entities.</t>


		Current:
		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
		"OPTIONAL" in this document are to be interpreted as described in
		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
		capitals, as shown here.
		-->
		<t>
		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
		be interpreted as
		described in BCP 14 <xref/> <xref/>
		when, and only when, they appear in all capitals, as shown here.
		</t>
		<t>This document uses the terminology of <xref format="de
		fault"/>, <xref format="default"/>, and <xref
		format="default"/> for ICN entities.</t>
	<t>The following terms are used in the document and defined as follows:	<t>The following terms are used in the document and defined as follows:

	<list hangIndent="14">	</t>
	<t hangText="ICN LoWPAN:">Information-Centric Networking over	<dl newline="false" spacing="normal" indent="14">
	Low-power Wireless Personal AreaNetwork</t>	<dt>ICN LoWPAN:</dt>
		<dd>Information-Centric Networking over
	<t hangText="LLN:">Low-Power and LossyNetwork</t>	Low-Power Wireless Personal AreaNetwork</dd>
		<dt>LLN:</dt>
	<t hangText="CCNx:">Content-Centric Networking Architecture</t>	<dd>Low-Power and LossyNetwork</dd>
		<dt>CCNx:</dt>
	<t hangText="NDN:">Named DataNetworking Architecture</t>	<dd>Content-Centric Networking</dd>
		<dt>NDN:</dt>
	<t hangText="byte:">synonym foroctet</t>	<dd>Named DataNetworking</dd>
		<dt>byte:</dt>
	<t hangText="nibble:">synonym for 4bits</t>	<dd>synonym foroctet</dd>
		<dt>nibble:</dt>
	<t hangText="time-value:">a time offset measured inseconds</t>	<dd>synonym for 4bits</dd>
		<dt>time-value:</dt>
	<t hangText="time-code:">an 8-bit encodedtime-value</t>	<dd>a time offset measured inseconds</dd>
	</list></t>	<dt>time-code:</dt>
		<dd>an 8-bit encodedtime-value</dd>
		</dl>
	</section>	</section>

		<section anchor="ICNLoWPAN"numbered="true" toc="default">
	<section anchor="ICNLoWPAN"title="Overview of ICNLoWPAN ">	<name>Overview of ICNLoWPAN</name>
	<sectiontitle="Link-Layer Convergence">	<sectionnumbered="true" toc="default">
		<name>Link-Layer Convergence</name>
	<t>ICN LoWPAN provides a convergence layer that maps ICN packets onto	<t>ICN LoWPAN provides a convergence layer that maps ICN packets onto
	constrained link-layer technologies. This includes features such as	constrained link-layer technologies. This includes features such as
	link-layer fragmentation, protocol separation on the link-layer level,	link-layer fragmentation, protocol separation on the link-layer level,
	and link-layer address mappings. The stack traversal is visualized in	and link-layer address mappings. The stack traversal is visualized in

	<xreftarget="fig.intro.hbh"/>.</t>	<xreftarget="fig.intro.hbh" format="default"/>.</t>
		<figureanchor="fig.intro.hbh">
	<figureanchor="fig.intro.hbh"	<name>ICN LoWPANConvergence Layer for IEEE802.15.4</name>
	title="ICN LoWPANconvergence layer for IEEE802.15.4">	<artworkalign="center" name="" type="" alt=""><![CDATA[
	<artworkalign="center"><![CDATA[
	Device 1 Device 2	Device 1 Device 2
	,------------------, Router ,------------------,	,------------------, Router ,------------------,
	\| Application . \| __________________ \| ,-> Application \|	\| Application . \| __________________ \| ,-> Application \|
	\|----------------\|-\| \| NDN / CCNx \| \|-\|----------------\|	\|----------------\|-\| \| NDN / CCNx \| \|-\|----------------\|
	\| NDN / CCNx \| \| \| ,--------------, \| \| \| NDN / CCNx \|	\| NDN / CCNx \| \| \| ,--------------, \| \| \| NDN / CCNx \|
	\|----------------\|-\| \|-\|--------------\|-\| \|-\|----------------\|	\|----------------\|-\| \|-\|--------------\|-\| \|-\|----------------\|
	\| ICN LoWPAN \| \| \| \| ICN LoWPAN \| \| \| \| ICN LoWPAN \|	\| ICN LoWPAN \| \| \| \| ICN LoWPAN \| \| \| \| ICN LoWPAN \|
	\|----------------\|-\| \|-\|--------------\|-\| \|-\|----------------\|	\|----------------\|-\| \|-\|--------------\|-\| \|-\|----------------\|

	\| Link-Layer \| \| \| \| Link-Layer \| \| \| \| Link-Layer \|	\| Link Layer \| \| \| \| Link Layer \| \| \| \| LinkLayer \|
	'----------------\|-' '-\|--------------\|-' '-\|----------------'	'----------------\|-' '-\|--------------\|-' '-\|----------------'
	'--------' '---------'	'--------' '---------'

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

		<t><xreftarget="sec.lowpan_adaptation" format="default"/> of thisdocum
	<t><xreftarget="sec.lowpan_adaptation"/> of thisdocument defines the	ent defines the
	convergence layer for IEEE 802.15.4.</t>	convergence layer for IEEE 802.15.4.</t>
	</section>	</section>

		<sectionnumbered="true" toc="default">
	<sectiontitle="Stateless HeaderCompression">	<name>Stateless HeaderCompression</name>
	<t>ICN LoWPAN also defines a stateless header compression scheme with	<t>ICN LoWPAN also defines a stateless header compression scheme with
	the main purpose of reducing header overhead of ICN packets. This is	the main purpose of reducing header overhead of ICN packets. This is

	of particular importance forlink-layers with small MTUs. The	of particular importance forlink layers with small MTUs. The
	stateless compression does not requirepre-configuration of global	stateless compression does not requirepreconfiguration ofa global
	state.</t>	state.</t>

		<!-- [rfced] Does adding the term "format" help with the readability of the fol
		lowing sentences?

		Current:
		The advantage of TLVs is its native support of variably structured data.
		The main disadvantage of TLVs is the verbosity that results from storing
		the type and length of the encoded data.


		Perhaps:
		The advantage of the TLV format is its support of variably structured data.
		The main disadvantage of the TLV format is the verbosity that results from
		storing the type and length of the encoded data.
		-->
	<t>The CCNx and NDN header formats are composed of Type-Length-Value	<t>The CCNx and NDN header formats are composed of Type-Length-Value
	(TLV) fields to encode header data. The advantage of TLVs is its	(TLV) fields to encode header data. The advantage of TLVs is its
	native support of variably structured data. The main disadvantage of	native support of variably structured data. The main disadvantage of
	TLVs is the verbosity that results from storing the type and length of	TLVs is the verbosity that results from storing the type and length of
	the encoded data.</t>	the encoded data.</t>


	<t>The stateless header compression scheme makes use of compact bit	<t>The stateless header compression scheme makes use of compact bit
	fields to indicate the presence of optional TLVs in the uncompressed	fields to indicate the presence of optional TLVs in the uncompressed
	packet. The order of set bits in the bit fields corresponds to the	packet. The order of set bits in the bit fields corresponds to the
	order of each TLV in the packet. Further compression is achieved by	order of each TLV in the packet. Further compression is achieved by
	specifying default values and reducing the range of certain header	specifying default values and reducing the range of certain header
	fields.</t>	fields.</t>

		<t><xreftarget="fig.TLV.compressed" format="default"/> demonstrates the
	<t><xreftarget="fig.TLV.compressed"/> demonstrates the stateless	stateless
	header compression idea. In this example, the first type of the first	header compression idea. In this example, the first type of the first
	TLV is removed and the corresponding bit in the bit field is set. The	TLV is removed and the corresponding bit in the bit field is set. The
	second TLV represents a fixed-length TLV (e.g., the Nonce TLV in NDN),	second TLV represents a fixed-length TLV (e.g., the Nonce TLV in NDN),

	so that thetype and the length fields are removed. The third TLV	so that theType and Length fields are removed. The third TLV
	represents a boolean TLV (e.g., the MustBeFresh selector in NDN) for	represents a boolean TLV (e.g., the MustBeFresh selector in NDN) for

	which thetype, length andthe value fields are elided.</t>	which theType, Length, andValue fields are elided.</t>
		<figureanchor="fig.TLV.compressed">
	<figureanchor="fig.TLV.compressed"	<name>Compression Using aCompact Bit Field -- Bits Encode theInclusi
	title="Compression using acompact bit field - bits encode thei	on of
	nclusion ofTLVs.">	TLVs</name>
	<artworkalign="center"><![CDATA[	<artworkalign="center" name="" type="" alt=""><![CDATA[
	Uncompressed:	Uncompressed:

	Variable-length TLV Fixed-length TLV Boolean TLV	Variable-length TLV Fixed-length TLV Boolean TLV
	,-----------------------,-----------------------,-------------,	,-----------------------,-----------------------,-------------,
	+-------+-------+-------+-------+-------+-------+------+------+	+-------+-------+-------+-------+-------+-------+------+------+
	\| TYP \| LEN \| VAL \| TYP \| LEN \| VAL \| TYP \| LEN \|	\| TYP \| LEN \| VAL \| TYP \| LEN \| VAL \| TYP \| LEN \|
	+-------+-------+-------+-------+-------+-------+------+------+	+-------+-------+-------+-------+-------+-------+------+------+

	Compressed:	Compressed:

	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+

	\| 1 \| 0 \| 1 \| 0 \| 0 \| 0 \| 0 \| 1 \| Bitfield	\| 1 \| 0 \| 1 \| 0 \| 0 \| 0 \| 0 \| 1 \| BitField
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+
	\| \| \|	\| \| \|
	,--' '----, '- Boolean Value	,--' '----, '- Boolean Value
	\| \|	\| \|
	+-------+-------+-------+	+-------+-------+-------+
	\| LEN \| VAL \| VAL \|	\| LEN \| VAL \| VAL \|
	+-------+-------+-------+	+-------+-------+-------+
	'---------------'-------'	'---------------'-------'
	Var-len Value Fixed-len Value	Var-len Value Fixed-len Value

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

		<t>Stateless TLV compression for NDN is defined in <xreftarget="sec.ndn
	<t>Stateless TLV compression for NDN is defined in <xref	" format="default"/>. <xreftarget="sec.ccnx" format="default"/> defines thesta
	target="sec.ndn"/>. <xreftarget="sec.ccnx"/> defines thestateless	teless
	TLV compression for CCNx.</t>	TLV compression for CCNx.</t>

		<t>The extensibility of this compression is described in <xreftarget="s
	<t>The extensibility of this compression is described in <xref	ec.dispatch.ext" format="default"/> and allows future documents to update the
	target="sec.dispatch.ext"/> and allows future documents to update the	compression rules outlined in thisdocument.</t>
	compression rules outlined in thismanuscript.</t>
	</section>	</section>

		<sectionnumbered="true" toc="default">
	<sectiontitle="Stateful HeaderCompression">	<name>Stateful HeaderCompression</name>
	<t>ICN LoWPAN further employs twoorthogonal stateful compression	<t>ICN LoWPAN further employs twoorthogonal, stateful compression
	schemes for packet sizereductions which are defined in <xref	schemes for packet sizereductions, which are defined in <xreftarget="s
	target="stateful.compression"/>. These mechanisms rely on shared	tateful.compression" format="default"/>. These mechanisms rely on shared
	contexts that are either distributed and maintained in the entire	contexts that are either distributed and maintained in the entire

	LoWPAN, or are generatedon-demand hop-wise on a particular	LoWPAN or are generatedon demand hop-wise on a particular
	Interest-data path.</t>	Interest-Data path.</t>
		<t>The shared context identification is defined in <xreftarget="statefu
	<t>The shared context identification is defined in <xref	l.compression.local" format="default"/>. The hop-wise name compression
	target="stateful.compression.local"/>. The hop-wise name compression	"en-route" is specified in <xreftarget="stateful.compression.en-route"
	"en-route" is specified in <xref	format="default"/>.</t>
	target="stateful.compression.en-route"/>.</t>
	</section>	</section>
	</section>	</section>

		<section anchor="sec.lowpan_adaptation"numbered="true" toc="default">
	<section anchor="sec.lowpan_adaptation"title="IEEE 802.15.4Adaptation">	<name>IEEE 802.15.4Adaptation</name>
	<section anchor="sec.lowpan_encap"title="LoWPAN Encapsulation">	<section anchor="sec.lowpan_encap"numbered="true" toc="default">
		<name>LoWPAN Encapsulation</name>
	<t>The IEEE 802.15.4 frame header does not provide a protocol	<t>The IEEE 802.15.4 frame header does not provide a protocol
	identifier for its payload. This causes problems of misinterpreting	identifier for its payload. This causes problems of misinterpreting
	frames when several network layers coexist on the same link. To	frames when several network layers coexist on the same link. To
	mitigate errors, 6LoWPAN defines dispatches as encapsulation headers	mitigate errors, 6LoWPAN defines dispatches as encapsulation headers

	for IEEE 802.15.4 frames (seeSection 5 of <xreftarget="RFC4944"/>).	for IEEE 802.15.4 frames (see <xreftarget="RFC4944" section="5" section
	Multiple LoWPAN encapsulation headers can precede the actualpayload	Format="of" format="default"/>).
		Multiple LoWPAN encapsulation headers can precede the actualpayload,
	and each encapsulation header is identified by a dispatch type.</t>	and each encapsulation header is identified by a dispatch type.</t>

		<!-- [rfced] In the following sentence, should "dispatch table" be instead "dispatch Page"?


	<t><xref/> further specifies dispatch pages to switch	Current:
	between different contexts. When a LoWPAN parser encounters a<spanx	When a LoWPAN parser encounters aPage switch
	>Page switch</spanx> LoWPAN encapsulation header,then all	LoWPAN encapsulation header, all following encapsulation headers are
	following encapsulation headers are interpreted by using a dispatch	interpreted by using a dispatchtable, as specified by the Page
	table as specified by the<spanx>Page switch</spanx>	switch header.
	header. Page0 and page 1 are reserved for 6LoWPAN. This document uses
	page TBD1 (<spanx>1111 TBD1 (0xFTBD1)</spanx>) for ICN LoWP
	AN.</t>

	<t>The base dispatch format (<xref/>) is used
	and extended by CCNx and NDN in <xref/> and <xref
	/>.</t>


	<figure anchor="fig.disp.base"	Perhaps:
	title="Base dispatch format for ICNLoWPAN">	When a LoWPAN parser encounters a Page switch
	<artworkalign="center"><![CDATA[	LoWPAN encapsulation header, all following encapsulation headers are
	0 1 2 ...	interpreted by using a dispatch Page, as specified by the Page
	+---+---+-----------	switch header.
	\|C \| P \| M \|	-->
	+---+---+-----------	<t><xref format="default"/> further specifies dispatch
	]]></artwork>	Pages to
		switch between different contexts. When a LoWPAN parser encounters a <tt>
		Page
		switch</tt> LoWPAN encapsulation header, all
		following encapsulation headers are interpreted by using a dispatch
		table, as specified by the <tt>Page switch</tt>
		header. Pages 0 and 1 are reserved for 6LoWPAN. This document uses
		Page 14 (<tt>1111 1110 (0xFE)</tt>) for ICN LoWPAN.</t>
		<t>The base dispatch format(<xref format="defaul
		t"/>) is
		used and extended by CCNx and NDN in Sections <xref form
		at="counter"/> and
		<xref format="counter"/>.</t>
		<figure anchor="fig.disp.base">
		<name>Base Dispatch Format for ICNLoWPAN</name>
		<artworkalign="center" name="" type="" alt=""><![CDATA[
		0 1 23 ...
		+---+---+---+---+---
		\|0 \| P \| M \|C \|
		+---+---+---+---+---
		]]></artwork>
	</figure>	</figure>

		<dl newline="true" spacing="normal" indent="4">
	<t><list hangIndent="4">	<dt>P: Protocol</dt>
	<t hangText="C: Compression"><list hangIndent="12">	<dd>
	<t hangText="0:">The message is uncompressed.</t>	<dl newline="false" spacing="normal" indent="4">
		<dt>0:</dt>
	<t hangText="1:">The message is compressed.</t>	<dd>The included protocol isNDN.</dd>
	</list></t>	<dt>1:</dt>
		<dd>The included protocol isCCNx.</dd>
	<t hangText="P: Protocol"><list hangIndent="12">	</dl>
	<t hangText="0:">The included protocol isNDN.</t>	</dd>
		<dt>M: MessageType</dt>
	<t hangText="1:">The included protocol isCCNx.</t>	<dd>
	</list></t>	<dl newline="false" spacing="normal" indent="4">
		<dt>0:</dt>
	<t hangText="M: MessageType"><list hangIndent="12"	<dd>The payload contains an Interestmessage.</dd>
	>	<dt>1:</dt>
	<t hangText="0:">The payload contains an Interestmessage.</t>	<dd>The payload contains a Datamessage.</dd>
		</dl>
	<t hangText="1:">The payload contains a Datamessage.</t>	</dd>
	</list></t>	<dt>C: Compression</dt>
	</list></t>	<dd>
		<dl newline="false" spacing="normal" indent="4">
		<dt>0:</dt>
		<dd>The message is uncompressed.</dd>
		<dt>1:</dt>
		<dd>The message is compressed.</dd>
		</dl>
		</dd>
		</dl>
	<t>ICN LoWPAN frames with compressed CCNx and NDN messages (C=1) use	<t>ICN LoWPAN frames with compressed CCNx and NDN messages (C=1) use

	the extended dispatch format in <xref	the extended dispatch format in <xreftarget="fig.disp.base.compr" forma
	target="fig.disp.base.compr"/>.</t>	t="default"/>.</t>
		<figureanchor="fig.disp.base.compr">
	<figureanchor="fig.disp.base.compr"	<name>Extended Dispatch Format forCompressed ICNLoWPAN</name>
	title="Extended dispatch format forcompressed ICNLoWPAN">	<artworkalign="center" name="" type="" alt=""><![CDATA[
	<artworkalign="center"><![CDATA[	0 1 2 3 ......
	0 1 2 34 ...	+---+---+---+---+...+---+---+
	+---+---+---+---+---+---	\|0 \| P \| M\| 1 \| \|CID\|EXT\|
	\|1 \| P \| M \|CID\|EXT\|	+---+---+---+---+...+---+---+
	+---+---+---+---+---+---	]]></artwork>
	]]></artwork>
	</figure>	</figure>

		<dl newline="true" spacing="normal" indent="4">
	<t><list hangIndent="4">	<dt>CID: ContextIdentifier</dt>
	<t hangText="CID: ContextIdentifier"><list hangIndent="12"	<dd>
	>	<dl newline="false" spacing="normal" indent="4">
	<t hangText="0:">No context identifiers arepresent.</t>	<dt>0:</dt>
		<dd>No context identifiers arepresent.</dd>
	<t hangText="1:">Context identifier(s) are present (see <xref	<dt>1:</dt>
	target="stateful.compression.local"/>).</t>	<dd>Context identifier(s) are present (see <xreftarget="stateful.
	</list></t>	compression.local" format="default"/>).</dd>
		</dl>
	<t hangText="EXT: Extension"><list hangIndent="12">	</dd>
	<t hangText="0:">No extension bytes arepresent.</t>	<dt>EXT: Extension</dt>
		<dd>
	<t hangText="1:">Extension byte(s) are present (see <xref	<dl newline="false" spacing="normal" indent="4">
	target="sec.dispatch.ext"/>).</t>	<dt>0:</dt>
	</list></t>	<dd>No extension bytes arepresent.</dd>
	</list></t>	<dt>1:</dt>
		<dd>Extension byte(s) are present (see <xreftarget="sec.dispatch.
	<t>The encapsulation format for ICN LoWPAN is displayed in <xref	ext" format="default"/>).</dd>
	target="fig.ICN-LoWPAN.header"/>.</t>	</dl>
		</dd>
	<figureanchor="fig.ICN-LoWPAN.header"	</dl>
	title="LoWPAN Encapsulation withICN-LoWPAN">	<t>The encapsulation format for ICN LoWPAN is displayed in <xreftarget=
	<artworkalign="center"><![CDATA[	"fig.ICN-LoWPAN.header" format="default"/>.</t>
		<figureanchor="fig.ICN-LoWPAN.header">
		<name>LoWPAN Encapsulation withICN LoWPAN</name>
		<artworkalign="center" name="" type="" alt=""><![CDATA[
	+------...------+------...-----+--------+-------...-------+-----...	+------...------+------...-----+--------+-------...-------+-----...
	\| IEEE 802.15.4 \| RFC4944 Disp.\| Page \| ICN LoWPAN Disp.\| Payl. /	\| IEEE 802.15.4 \| RFC4944 Disp.\| Page \| ICN LoWPAN Disp.\| Payl. /
	+------...------+------...-----+--------+-------...-------+-----...	+------...------+------...-----+--------+-------...-------+-----...

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

		<dl newline="false" spacing="normal" indent="16">
	<t><list hangIndent="16">	<dt>IEEE 802.15.4:</dt>
	<t hangText="IEEE 802.15.4:">The IEEE 802.15.4header.</t>	<dd>The IEEE 802.15.4header.</dd>
		<dt>RFC4944 Disp.:</dt>
	<t hangText="RFC4944 Disp.:">Optional additional dispatches	<dd>Optional additional dispatches
	defined inSection 5.1 of <xreftarget="RFC4944"/></t>	defined in <xreftarget="RFC4944" section="5.1" sectionFormat="of" f
		ormat="default"/>.</dd>
	<t hangText="Page:">Page Switch. TBD1 for ICNLoWPAN.</t>	<dt>Page:</dt>
		<dd><tt>Page switch</tt>. 14 for ICNLoWPAN.</dd>
	<t hangText="ICN LoWPAN:">Dispatches as defined in <xref	<dt>ICN LoWPAN:</dt>
	target="sec.ndn"/> and <xreftarget="sec.ccnx"/>.</t>	<dd>Dispatches as defined inSections <xreftarget="sec.ndn" format="c
		ounter"/> and <xreftarget="sec.ccnx" format="counter"/>.</dd>
	<t hangText="Payload:">The actual (un-)compressed CCNx or NDN	<dt>Payload:</dt>
	message.</t>	<dd>The actual (un-)compressed CCNx or NDN
	</list></t>	message.</dd>
		</dl>
	<section anchor="sec.dispatch.ext"title="Dispatch Extensions">	<section anchor="sec.dispatch.ext"numbered="true" toc="default">
		<name>Dispatch Extensions</name>
	<t>Extension bytes allow for the extensibility of the initial	<t>Extension bytes allow for the extensibility of the initial
	compression rule set. The base format for an extension byte is	compression rule set. The base format for an extension byte is

	depicted in <xreftarget="fig.ext.base"/>.</t>	depicted in <xreftarget="fig.ext.base" format="default"/>.</t>
		<figureanchor="fig.ext.base">
	<figureanchor="fig.ext.base"	<name>Base Format forDispatch Extensions</name>
	title="Base format fordispatch extensions.">	<artworkalign="center" name="" type="" alt=""><![CDATA[
	<artworkalign="center"><![CDATA[
	0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+
	\| - \| - \| - \| - \| - \| - \| - \|EXT\|	\| - \| - \| - \| - \| - \| - \| - \|EXT\|
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+

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

		<dl newline="true" spacing="normal" indent="4">
	<t><list hangIndent="4">	<dt>EXT: Extension</dt>
	<t hangText="EXT: Extension"><list hangIndent="12"	<dd>
	>	<dl newline="false" spacing="normal" indent="4">
	<t hangText="0:">No other extension bytefollows.</t>	<dt>0:</dt>
		<dd>No other extension bytefollows.</dd>
	<t hangText="1:">A further extension bytefollows.</t>	<dt>1:</dt>
	</list></t>	<dd>A further extension bytefollows.</dd>
	</list></t>	</dl>
		</dd>
		</dl>
	<t>Extension bytes are numbered according to their order. Future	<t>Extension bytes are numbered according to their order. Future

	documentsMUST follow the naming scheme <spanx>EXT_0, EXT_1, ...</spanx>,	documents<bcp14>MUST</bcp14> follow the naming scheme <tt>EXT_0, EXT_1, ...</tt>
	when updating or referring to a specific dispatch extension byte.	when updating or referring to a specific dispatch extension byte.
	Amendments that require an exchange of configurational parameters	Amendments that require an exchange of configurational parameters

	between devicesSHOULD use manifests to encodestructured data in a	between devices<bcp14>SHOULD</bcp14> use manifests to encodestructur
	well-defined format,as, e.g., outlined in <xref	ed data in a
	target="I-D.irtf-icnrg-flic"/>.</t>	well-defined format, e.g.,as outlined in <xreftarget="I-D.irtf-icnrg
		-flic" format="default"/>.</t>
	</section>	</section>
	</section>	</section>

		<section anchor="sec.Fragmentation"numbered="true" toc="default">
	<section anchor="sec.Fragmentation"title="Adaptation Layer Fragmentation"	<name>Adaptation-Layer Fragmentation</name>
	>
	<t>Small payload sizes in the LoWPAN require fragmentation for various	<t>Small payload sizes in the LoWPAN require fragmentation for various

	network layers. Therefore,Section 5.3 of <xref/>	network layers. Therefore,<xref section="5.3" sectionFormat="of" format="default"/>
	defines a protocol-independent fragmentation dispatch type, a	defines a protocol-independent fragmentation dispatch type, a
	fragmentation header for the first fragment, and a separate	fragmentation header for the first fragment, and a separate
	fragmentation header for subsequent fragments. ICN LoWPAN adopts this	fragmentation header for subsequent fragments. ICN LoWPAN adopts this

	fragmentation handling of <xreftarget="RFC4944"/>.</t>	fragmentation handling of <xreftarget="RFC4944" format="default"/>.</t>
		<t>Thefragmentation LoWPAN header can encapsulate other dispatch
	<t>TheFragmentation LoWPAN header can encapsulate other dispatch	headers. The order of dispatch types is defined in <xreftarget="RFC4944
	headers. The order of dispatch types is defined inSection 5 of <xref	" section="5" sectionFormat="of" format="default"/>. <xreftarget="fig.fr_first"
	target="RFC4944"/>. <xreftarget="fig.fr_first"/> shows the	format="default"/> shows the
	fragmentation scheme. The reassembled ICN LoWPAN frame does not	fragmentation scheme. The reassembled ICN LoWPAN frame does not

	contain any fragmentation headers and is depicted in <xref	contain any fragmentation headers and is depicted in <xreftarget="fig.f
	target="fig.fr_done"/>.</t>	r_done" format="default"/>.</t>
		<figureanchor="fig.fr_first">
	<figureanchor="fig.fr_first" title="Fragmentation scheme">	<name>Fragmentation Scheme</name>
	<artworkalign="center"><![CDATA[	<artworkalign="center" name="" type="" alt=""><![CDATA[
	+------...------+----...----+--------+------...-------+--------...	+------...------+----...----+--------+------...-------+--------...
	\| IEEE 802.15.4 \| Frag. 1st \| Page \| ICN LoWPAN \| Payload /	\| IEEE 802.15.4 \| Frag. 1st \| Page \| ICN LoWPAN \| Payload /
	+------...------+----...----+--------+------...-------+--------...	+------...------+----...----+--------+------...-------+--------...

	+------...------+----...----+--------...	+------...------+----...----+--------...
	\| IEEE 802.15.4 \| Frag. 2nd \| Payload /	\| IEEE 802.15.4 \| Frag. 2nd \| Payload /
	+------...------+----...----+--------...	+------...------+----...----+--------...

	.	.
	.	.
	.	.

	+------...------+----...----+--------...	+------...------+----...----+--------...
	\| IEEE 802.15.4 \| Frag. Nth \| Payload /	\| IEEE 802.15.4 \| Frag. Nth \| Payload /
	+------...------+----...----+--------...	+------...------+----...----+--------...

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

		<figureanchor="fig.fr_done">
	<figureanchor="fig.fr_done" title="Reassembled ICN LoWPANframe">	<name>Reassembled ICN LoWPANFrame</name>
	<artworkalign="center"><![CDATA[	<artworkalign="center" name="" type="" alt=""><![CDATA[
	+------...------+--------+------...-------+--------...	+------...------+--------+------...-------+--------...
	\| IEEE 802.15.4 \| Page \| ICN LoWPAN \| Payload /	\| IEEE 802.15.4 \| Page \| ICN LoWPAN \| Payload /
	+------...------+--------+------...-------+--------...	+------...------+--------+------...-------+--------...

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

		<t>The 6LoWPAN Fragment Forwarding(6LFF) <xreftarget="RFC8930" format=
	<t>The 6LoWPAN Fragment Forwarding(6FF) <xref	"default"/> is an alternative
	target="RFC8930"/> is an alternative
	approach that enables forwarding of fragments without	approach that enables forwarding of fragments without
	reassembling packets on every intermediate hop. By reusing the	reassembling packets on every intermediate hop. By reusing the

	6LoWPAN dispatching framework,6FF integrates into ICN LoWPAN	6LoWPAN dispatching framework,6LFF integrates into ICN LoWPAN
	asseamless as the conventional hop-wise	asseamlessly as the conventional hop-wise
	fragmentation.Experimental evaluations <xref	fragmentation.However, experimental evaluations <xreftarget="SFR-ICNLO
	target="SFR-ICNLOWPAN"/>, however, suggest that amore refined	WPAN"
		format="default"/> suggest that amore-refined
	integration can increase the cache utilization of forwarders	integration can increase the cache utilization of forwarders
	on a request path.</t>	on a request path.</t>
	</section>	</section>
	</section>	</section>

		<section anchor="sec.ndn"numbered="true" toc="default">
	<section anchor="sec.ndn"title="Space-efficient Message Encoding forNDN">	<name>Space-Efficient Message Encoding forNDN</name>
	<section anchor="sec.tlvencoding"title="TLV Encoding">	<section anchor="sec.tlvencoding"numbered="true" toc="default">
		<name>TLV Encoding</name>
	<t>The NDN packet format consists of TLV fields using the TLV encoding	<t>The NDN packet format consists of TLV fields using the TLV encoding

	that is described in <xref/>. Type and length	that is described in <xref format="default"/>. Type and Length
	fields are of variable size, where numbers greater than 252 are	fields are of variable size, where numbers greater than 252 are
	encoded using multiple bytes.</t>	encoded using multiple bytes.</t>

		<t>If the type or length number is less than<tt>253</tt>,
	<t>If the type or length number is less than<spanx>253</sp	then that number is encoded into the actualType orLength field. If
	anx>,	the number is greater or equals<tt>253</tt> and
	then that number is encoded into the actualtype orlength field. If	fits into 2 bytes, then theType orLength field is set to<tt>253</tt>
	the number is greater or equals<spanx>253</spanx> and	and the number is encoded in the next
	fits into 2 bytes, then thetype orlength field is set to<spanx
	>253</spanx> and the number is encoded in the next
	following 2 bytes in network byte order, i.e., from the most	following 2 bytes in network byte order, i.e., from the most
	significant byte (MSB) to the least significant byte (LSB). If the	significant byte (MSB) to the least significant byte (LSB). If the

	number is greater than 2 bytes and fits into 4 bytes, then thetype	number is greater than 2 bytes and fits into 4 bytes, then theType
	orlength field is set to<spanx>254</spanx> and the	orLength field is set to<tt>254</tt> and the
	number is encoded in the subsequent 4 bytes in network byte order.	number is encoded in the subsequent 4 bytes in network byte order.

	For larger numbers, thetype orlength field is set to<spanx	For larger numbers, theType orLength field is set to<tt>255</tt> and
	>255</spanx> and the number is encoded in the subsequent 8	the number is encoded in the subsequent 8
	bytes in network byte order.</t>	bytes in network byte order.</t>

		<t>In this specification, compressed NDN TLVs encodeType and
	<t>In this specification, compressed NDN TLVs encodetype and	Length fields using self-delimiting numeric values (SDNVs)
	length fields using self-delimiting numeric values (SDNVs)	<xreftarget="RFC6256" format="default"/> commonly known fromDelay-Tole
	<xreftarget="RFC6256"/> commonly known fromDTN protocols.	rant
		Networking (DTN) protocols.
	Instead of using the first byte as a marker for the number of	Instead of using the first byte as a marker for the number of
	following bytes, SDNVs use a single bit to indicate subsequent	following bytes, SDNVs use a single bit to indicate subsequent
	bytes.</t>	bytes.</t>

		<table anchor="tab.sdnvperformance"align="center">
	<texttable anchor="tab.sdnvperformance"	<name>NDN TLVEncoding Compared toSDNVs</name>
	title="NDN TLVencoding compared toSDNVs.">	<thead>
	<ttcol align="left">Value</ttcol>	<tr>
	<ttcol align="left" width="35%">NDN TLVencoding</ttcol>	<th align="left">Value</th>
	<ttcol align="left" width="40%">SDNV encoding</ttcol>	<th align="left">NDN TLVEncoding</th>
		<th align="left">SDNV Encoding</th>
	<c>0</c>	</tr>
	<c>0x00</c>	</thead>
	<c>0x00</c>	<tbody>
		<tr>
	<c>127</c>	<td align="left">0</td>
	<c>0x7F</c>	<td align="left">0x00</td>
	<c>0x7F</c>	<td align="left">0x00</td>
		</tr>
	<c>128</c>	<tr>
	<c>0x80</c>	<td align="left">127</td>
	<c>0x81 0x00</c>	<td align="left">0x7F</td>
		<td align="left">0x7F</td>
	<c>253</c>	</tr>
	<c>0xFD 0x00 0xFD</c>	<tr>
	<c>0x81 0x7D</c>	<td align="left">128</td>
		<td align="left">0x80</td>
	<c>2^14 -1</c>	<td align="left">0x81 0x00</td>
	<c>0xFD 0x3F0xFF</c>	</tr>
	<c>0xFF 0x7F</c>	<tr>
		<td align="left">253</td>
	<c>2^14</c>	<td align="left">0xFD 0x00 0xFD</td>
	<c>0xFD 0x400x00</c>	<td align="left">0x81 0x7D</td>
	<c>0x81 0x80 0x00</c>	</tr>
		<tr>
	<c>2^16</c>	<td align="left">2<sup>14</sup> -1</td>
	<c>0xFE 0x00 0x01 0x000x00</c>	<td align="left">0xFD 0x3F0xFF</td>
	<c>0x84 0x80 0x00</c>	<td align="left">0xFF 0x7F</td>
		</tr>
	<c>2^21 -1</c>	<tr>
	<c>0xFE 0x00 0x1F 0xFF0xFF</c>	<td align="left">2<sup>14</sup></td>
	<c>0xFF 0xFF 0x7F</c>	<td align="left">0xFD 0x400x00</td>
		<td align="left">0x81 0x80 0x00</td>
	<c>2^21</c>	</tr>
	<c>0xFE 0x00 0x20 0x000x00</c>	<tr>
	<c>0x81 0x80 0x800x00</c>	<td align="left">2<sup>16</sup></td>
		<td align="left">0xFE 0x00 0x01 0x000x00</td>
	<c>2^28 -1</c>	<td align="left">0x84 0x80 0x00</td>
	<c>0xFE 0x0F 0xFF 0xFF0xFF</c>	</tr>
	<c>0xFF 0xFF 0xFF0x7F</c>	<tr>
		<td align="left">2<sup>21</sup> -1</td>
	<c>2^28</c>	<td align="left">0xFE 0x00 0x1F 0xFF0xFF</td>
	<c>0xFE 0x1F 0x00 0x000x00</c>	<td align="left">0xFF 0xFF 0x7F</td>
	<c>0x81 0x80 0x80 0x800x00</c>	</tr>
		<tr>
	<c>2^32</c>	<td align="left">2<sup>21</sup></td>
	<c>0xFF 0x00 0x00 0x00 0x01 0x00 0x00 0x000x00</c>	<td align="left">0xFE 0x00 0x20 0x000x00</td>
	<c>0x90 0x80 0x80 0x800x00</c>	<td align="left">0x81 0x80 0x800x00</td>
		</tr>
	<c>2^35 -1</c>	<tr>
	<c>0xFF 0x00 0x00 0x00 0x07 0xFF 0xFF 0xFF0xFF</c>	<td align="left">2<sup>28</sup> -1</td>
	<c>0xFF 0xFF 0xFF 0xFF0x7F</c>	<td align="left">0xFE 0x0F 0xFF 0xFF0xFF</td>
		<td align="left">0xFF 0xFF 0xFF0x7F</td>
	<c>2^35</c>	</tr>
	<c>0xFF 0x00 0x00 0x00 0x08 0x00 0x00 0x000x00</c>	<tr>
	<c>0x81 0x80 0x80 0x80 0x800x00</c>	<td align="left">2<sup>28</sup></td>
	</texttable>	<td align="left">0xFE 0x1F 0x00 0x000x00</td>
		<td align="left">0x81 0x80 0x80 0x800x00</td>
		</tr>
		<tr>
		<td align="left">2<sup>32</sup></td>
		<td align="left">0xFF 0x00 0x00 0x00 0x01 0x00 0x00 0x000x00</td>
		<td align="left">0x90 0x80 0x80 0x800x00</td>
		</tr>
		<tr>
		<td align="left">2<sup>35</sup> -1</td>
		<td align="left">0xFF 0x00 0x00 0x00 0x07 0xFF 0xFF 0xFF0xFF</td>
		<td align="left">0xFF 0xFF 0xFF 0xFF0x7F</td>
		</tr>
		<tr>
		<td align="left">2<sup>35</sup></td>
		<td align="left">0xFF 0x00 0x00 0x00 0x08 0x00 0x00 0x000x00</td>
		<td align="left">0x81 0x80 0x80 0x80 0x800x00</td>
		</tr>
		</tbody>
		</table>
	<t>	<t>

	<xref/> compares the required	<xref format="default"/> compares the required
	bytes for encoding a few selected values using the NDN TLV	bytes for encoding a few selected values using the NDN TLV
	encoding and SDNVs. For values up to 127, both methods	encoding and SDNVs. For values up to 127, both methods
	require a single byte. Values in the range [128;252] encode	require a single byte. Values in the range [128;252] encode
	as one byte for the NDN TLV scheme, while SDNVs require two	as one byte for the NDN TLV scheme, while SDNVs require two
	bytes. Starting at value 253, SDNVs require a less or equal	bytes. Starting at value 253, SDNVs require a less or equal
	amount of bytes compared to the NDN TLV encoding.	amount of bytes compared to the NDN TLV encoding.
	</t>	</t>


	</section>	</section>

		<section anchor="sec.ndn.namecompression"numbered="true" toc="default">
	<section anchor="sec.ndn.namecompression"title="Name TLVCompression">	<name>Name TLVCompression</name>
	<t>This Name TLV compression encodeslength fields of two consecutive	<t>This Name TLV compression encodesLength fields of two consecutive
	NameComponent TLVs into one byte, using a nibble for each.	NameComponent TLVs into one byte, using a nibble for each.
	The most significant nibble indicates the length of an immediately following NameComponent TLV.	The most significant nibble indicates the length of an immediately following NameComponent TLV.
	The least significant nibble denotes the length of a subsequent NameComponent TLV.	The least significant nibble denotes the length of a subsequent NameComponent TLV.
	A length of 0 marks the end of the compressed Name TLV.	A length of 0 marks the end of the compressed Name TLV.

	The lastlength field of an encoded NameComponent is either 0x00 for a n	The lastLength field of an encoded NameComponent is either 0x00 for a n
	ame with an even number ofcomponents,	ame with an even number ofcomponents
	and 0xYF (Y> 0) if an odd number of components are present.	and 0xYF (Y> 0) if an odd number of components are present.
	This process limits the length of a NameComponent TLV to 15bytes, buta	This process limits the length of a NameComponent TLV to 15bytes butal
	llows for an unlimited number of components.	lows for an unlimited number of components.
	An example for this encoding is presented in <xreffig.ndnshortn
	co"/>.</t>	co" format="default"/>.</t>
		<figureanchor="fig.ndnshortnco">
	<figureanchor="fig.ndnshortnco"	<name>Name TLVCompression for/HAW/Room/481/Humid/99</name>
	title="Name TLVcompression for/HAW/Room/481/Humid/99">	<artworkalign="center" name="" type="" alt=""><![CDATA[
	<artworkalign="center"><![CDATA[
	Name: /HAW/Room/481/Humid/99	Name: /HAW/Room/481/Humid/99

	0 1 2 3	0 1 2 3
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\|0 0 1 1\|0 1 0 0\| H \| A \| W \|	\|0 0 1 1\|0 1 0 0\| H \| A \| W \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| R \| o \| o \| m \|	\| R \| o \| o \| m \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\|0 0 1 1\|0 1 0 1\| 4 \| 8 \| 1 \|	\|0 0 1 1\|0 1 0 1\| 4 \| 8 \| 1 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| H \| u \| m \| i \|	\| H \| u \| m \| i \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| d \|0 0 1 0\|0 0 0 0\| 9 \| 9 \|	\| d \|0 0 1 0\|0 0 0 0\| 9 \| 9 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

		<sectionnumbered="true" toc="default">
	<sectiontitle="Interest Messages">	<name>Interest Messages</name>
	<sectiontitle="Uncompressed InterestMessages">	<sectionnumbered="true" toc="default">
		<name>Uncompressed InterestMessages</name>
	<t>An uncompressed Interest message uses the base dispatch format	<t>An uncompressed Interest message uses the base dispatch format

	(see <xreftarget="fig.disp.base"/>) and sets theC flag to	(see <xreftarget="fig.disp.base" format="default"/>) and sets theC,
	<spanx>0</spanx> andthe P as well as the M	P, and M
	flag to<spanx>0</spanx> (<xref	flags to<tt>0</tt> (<xreftarget="fig.ndn.int.uncompr" format="defaul
	target="fig.ndn.int.uncompr"/>).	t"/>).
		<!--[rfced] As the last "N" in "NDN" stands for "Networking" may we remove "netw
		ork" from instances of "NDN network stack" (e.g., it reads as Named Data Network
		ing network stack)? Note that there are 2 instances.
		-->
	The Interest message is handed to the NDN network stack without modifications.</t>	The Interest message is handed to the NDN network stack without modifications.</t>

		<figureanchor="fig.ndn.int.uncompr">
	<figureanchor="fig.ndn.int.uncompr"	<name>Dispatch Format forUncompressed NDN InterestMessages</name>
	title="Dispatch format foruncompressed NDN Interestmessages"	<artworkalign="center" name="" type="" alt=""><![CDATA[
	>
	<artworkalign="center"><![CDATA[
	0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+
	\| 0 \| 0 \| 0 \| 0 \| 0 \| 0 \| 0 \| 0 \|	\| 0 \| 0 \| 0 \| 0 \| 0 \| 0 \| 0 \| 0 \|
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+

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

		<sectionnumbered="true" toc="default">
	<sectiontitle="Compressed InterestMessages">	<name>Compressed InterestMessages</name>
	<t>The compressed Interest message uses the extended dispatch format	<t>The compressed Interest message uses the extended dispatch format

	(<xreftarget="fig.disp.base.compr"/>) and sets the C flag to<spanx s	(<xreftarget="fig.disp.base.compr" format="default"/>) and sets the C
	tyle="verb">1</spanx>,	flag to
	the Pflag to <spanx>0</spanx> andthe Mflag to<spanx s	<tt>1</tt> and the P and Mflags to<tt>0</tt>.
	tyle="verb">0</spanx>.
	If an Interest message contains TLVs that are not mentioned in the	If an Interest message contains TLVs that are not mentioned in the

	following compression rules, then this messageMUST besent	following compression rules, then this message<bcp14>MUST</bcp14> besent
	uncompressed.</t>	uncompressed.</t>


	<t>This specification assumes that a HopLimit TLV is part of the	<t>This specification assumes that a HopLimit TLV is part of the

	original Interest message. If such HopLimit TLV is not present, it	original Interest message. If suchaHopLimit TLV is not present, it
	will be inserted with a default value of DEFAULT_NDN_HOPLIMIT prior to	will be inserted with a default value of DEFAULT_NDN_HOPLIMIT prior to
	the compression.</t>	the compression.</t>


	<t>In the default use case, the Interest message is compressed with	<t>In the default use case, the Interest message is compressed with

	the following minimal rule set:<list>	the following minimal rule set:</t>
	<t>The <spanx>Type</spanx> field of the outermost	<ol spacing="normal" type="1">
	MessageType TLV isremoved.</t>	<li>The <tt>Type</tt> field of the outermost
		MessageType TLV isremoved.</li>
	<t>The Name TLV is compressed according to <xref	<li>The Name TLV is compressed according to <xref
	target="sec.ndn.namecompression"/>. For this, all NameComponents	target="sec.ndn.namecompression" format="default"/>. For this, all
	are expected to be of type GenericNameComponent with a length	NameComponents are expected to be of type GenericNameComponent with a
	greater than 0. An ImplicitSha256DigestComponent or	length
	ParametersSha256DigestComponentMAY appear at the end of the	greater than 0. An ImplicitSha256DigestComponent or
	name. In any other case, the messageMUST be sent	ParametersSha256DigestComponent<bcp14>MAY</bcp14> appear at the end
	uncompressed.</t>	of the
		name. In any other case, the message<bcp14>MUST</bcp14> be sent
	<t>The Nonce TLV and InterestLifetime TLV are moved to	uncompressed.</li>
	the end of the compressedInterest as illustrated in	<li>The Nonce TLV and InterestLifetime TLV are moved to
	<xreftarget="fig.ndn.int.newformat"/>. The	the end of the compressedInterest, as illustrated in
	InterestLifetime is encoded as described in <xref	<xreftarget="fig.ndn.int.newformat" format="default"/>. The
	target="sec.compressedtime"/>. On	InterestLifetime is encoded as described in <xref
	decompression, this encoding may yield an	target="sec.compressedtime" format="default"/>. On
	Interestlifetime that is smaller than the original	decompression, this encoding may yield an
	value.</t>	InterestLifetime that is smaller than the original
		value.</li>
	<t>The Type and Length fields of Nonce TLV, HopLimitTLV and	<li>The Type and Length fields of Nonce TLV, HopLimitTLV, and
	InterestLifetime TLV are elided. The Nonce value has a length of	InterestLifetime TLV are elided. The Nonce value has a length of
	4bytes and the HopLimit value has a length of 1 byte. The	4bytes, and the HopLimit value has a length of 1 byte. The
	compressed InterestLifetime (<xreftarget="sec.compressedtime"/>)	compressed InterestLifetime (<xreftarget="sec.compressedtime"
	has a	format="default"/>) has a
	length of 1 byte. The presence of a Nonce and InterestLifetimeTLV	length of 1 byte. The presence of a NonceTLV and InterestLifetimeT
	is	LV is
	deduced from the remaining length to parse.	deduced from the remaining length to parse.
	A remaining length of<spanx>1</spanx> indicates the	A remaining length of<tt>1</tt> indicates the
	presence of anInerestLifetime, a length of<spanx>4<	presence of anInterestLifetime, a length of<tt>4</tt> indicates
	/spanx> indicates	the presence of a nonce, and a length of<tt>5</tt> indicates
	the presence of a nonce, and a length of<spanx>5</sp	the presence of bothTLVs.</li>
	anx> indicates	</ol>
	the presence of bothTLVs.</t>	<t>The compressed NDN LoWPAN Interest message is visualized in <xreft
	</list></t>	arget="fig.ndn.int.newformat" format="default"/>.</t>
		<figureanchor="fig.ndn.int.newformat">
	<t>The compressed NDN LoWPAN Interest message is visualized in <xref	<name>Compression of NDN LoWPAN InterestMessage</name>
	target="fig.ndn.int.newformat"/>.</t>	<artworkalign="center" name="" type="" alt=""><![CDATA[

	<figureanchor="fig.ndn.int.newformat"
	title="Compression of NDN LoWPAN InterestMessage">
	<artworkalign="center"><![CDATA[
	T = Type, L = Length, V = Value	T = Type, L = Length, V = Value
	Lc = Compressed Length, Vc = Compressed Value	Lc = Compressed Length, Vc = Compressed Value
	: = optional field, \| = mandatory field	: = optional field, \| = mandatory field

	+---------+---------+ +---------+	+---------+---------+ +---------+
	\| Msg T \| Msg L \| \| Msg Lc \|	\| Msg T \| Msg L \| \| Msg Lc \|
	+---------+---------+---------+ +---------+	+---------+---------+---------+ +---------+
	\| Name T \| Name L \| Name V \| \| Name Vc \|	\| Name T \| Name L \| Name V \| \| Name Vc \|
	+---------+---------+---------+ +---------+---------+	+---------+---------+---------+ +---------+---------+
	: CBPfx T : CBPfx L : : FWDH Lc : FWDH Vc :	: CBPfx T : CBPfx L : : FWDH Lc : FWDH Vc :

	skipping to change at line 827 ¶	skipping to change at line 847 ¶
	: FWDH T : FWDH L : FWDH V : : APM Lc : APM Vc :	: FWDH T : FWDH L : FWDH V : : APM Lc : APM Vc :
	+---------+---------+---------+ +---------+---------+	+---------+---------+---------+ +---------+---------+
	: NONCE T : NONCE L : NONCE V : : NONCE V :	: NONCE T : NONCE L : NONCE V : : NONCE V :
	+---------+---------+---------+ +---------+	+---------+---------+---------+ +---------+
	: ILT T : ILT L : ILT V : : ILT Vc :	: ILT T : ILT L : ILT V : : ILT Vc :
	+---------+---------+---------+ +---------+	+---------+---------+---------+ +---------+
	: HPL T : HPL L : HPL V :	: HPL T : HPL L : HPL V :
	+---------+---------+---------+	+---------+---------+---------+
	: APM T : APM L : APM V :	: APM T : APM L : APM V :
	+---------+---------+---------+	+---------+---------+---------+

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


	<t>Further TLV compression is indicated by the ICN LoWPAN dispatch	<t>Further TLV compression is indicated by the ICN LoWPAN dispatch

	in <xreftarget="fig.ndn.intcompr"/>.</t>	in <xreftarget="fig.ndn.intcompr" format="default"/>.</t>
		<figureanchor="fig.ndn.intcompr">
	<figureanchor="fig.ndn.intcompr"	<name>Dispatch Format forCompressed NDN InterestMessages</name>
	title="Dispatch format forcompressed NDN Interestmessages">	<artworkalign="center" name="" type="" alt=""><![CDATA[
	<artworkalign="center"><![CDATA[
	0 1	0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

	\|1 \| 0 \| 0 \|CID\|EXT\|PFX\|FRE\|FWD\|APM\|DIG\| RSV\|	\|0 \| 0 \| 0 \| 1 \|PFX\|FRE\|FWD\|APM\|DIG\| RSV \|CID\|EXT\|
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

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

		<dl newline="true" spacing="normal" indent="4">
	<t><list hangIndent="4">	<dt>PFX: CanBePrefixTLV</dt>
	<t hangText="CID: Context Identifier">See <xref	<dd>
	/>.</t>	<dl newline="false" spacing="normal" indent="4">
		<dt>0:</dt>
	<t hangText="EXT: Extension"><list hangIndent="8"	<dd>The uncompressed message does not include a
	>	CanBePrefixTLV.</dd>
	<t hangText="0:">No extension byte follows.</t>	<dt>1:</dt>
		<dd>The uncompressed message does include a
	<t hangText="1:">Extension byte <spanx>EXT_0</spa
	nx>
	follows immediately. See <xref
	/>.</t>
	</list></t>

	<t hangText="PFX: CanBePrefixTLV"><list hangIndent="12"
	>
	<t hangText="0:">The uncompressed message does not include a
	CanBePrefixTLV.</t>

	<t hangText="1:">The uncompressed message does include a
	CanBePrefix TLV and is removed from the compressed	CanBePrefix TLV and is removed from the compressed

	message.</t>	message.</dd>
	</list></t>	</dl>
		</dd>
	<t hangText="FRE: MustBeFreshTLV"><list hangIndent="12"	<dt>FRE: MustBeFreshTLV</dt>
	>	<dd>
	<t hangText="0:">The uncompressed message does not include a	<dl newline="false" spacing="normal" indent="4">
	MustBeFreshTLV.</t>	<dt>0:</dt>
		<dd>The uncompressed message does not include a
	<t hangText="1:">The uncompressed message does include a	MustBeFreshTLV.</dd>
		<dt>1:</dt>
		<dd>The uncompressed message does include a
	MustBeFresh TLV and is removed from the compressed	MustBeFresh TLV and is removed from the compressed

	message.</t>	message.</dd>
	</list></t>	</dl>
		</dd>
	<t hangText="FWD: ForwardingHintTLV"><list hangIndent="12"	<dt>FWD: ForwardingHintTLV</dt>
	>	<dd>
	<t hangText="0:">The uncompressed message does not include a	<dl newline="false" spacing="normal" indent="4">
	ForwardingHintTLV.</t>	<dt>0:</dt>
		<dd>The uncompressed message does not include a
	<t hangText="1:">The uncompressed message does include a	ForwardingHintTLV.</dd>
		<dt>1:</dt>
		<dd>The uncompressed message does include a
	ForwardingHint TLV. The Type field is removed from the	ForwardingHint TLV. The Type field is removed from the
	compressed message. Further, all link delegation types and	compressed message. Further, all link delegation types and
	link preference types are removed. All included names are	link preference types are removed. All included names are

	compressed according to <xref	compressed according to <xreftarget="sec.ndn.namecompression"
	target="sec.ndn.namecompression"/>. If any name is not	format="default"/>. If any name is not
	compressible, the messageMUST be sentuncompressed.</t>	compressible, the message<bcp14>MUST</bcp14> be sentuncompre
	</list></t>	ssed.</dd>
		</dl>
	<t hangText="APM: ApplicationParametersTLV"><list	</dd>
	hangIndent="12">	<dt>APM: ApplicationParametersTLV</dt>
	<t hangText="0:">The uncompressed message does not include	<dd>
	an ApplicationParametersTLV.</t>	<dl newline="false" spacing="normal" indent="4">
		<dt>0:</dt>
	<t hangText="1:">The uncompressed message does include an	<dd>The uncompressed message does not include
		an ApplicationParametersTLV.</dd>
		<dt>1:</dt>
		<dd>The uncompressed message does include an
	ApplicationParameters TLV. The Type field is removed from	ApplicationParameters TLV. The Type field is removed from

	the compressedmessage.</t>	the compressedmessage.</dd>
	</list></t>	</dl>
		</dd>
	<t hangText="DIG: ImplicitSha256DigestComponentTLV"><list	<dt>DIG: ImplicitSha256DigestComponentTLV</dt>
	hangIndent="12">	<dd>
	<t hangText="0:">The name does not include an	<dl newline="false" spacing="normal" indent="4">
	ImplicitSha256DigestComponent as the lastTLV.</t>	<dt>0:</dt>
		<dd>The name does not include an
	<t hangText="1:">The name does include an	ImplicitSha256DigestComponent as the lastTLV.</dd>
		<dt>1:</dt>
		<dd>The name does include an
	ImplicitSha256DigestComponent as the last TLV. The Type and	ImplicitSha256DigestComponent as the last TLV. The Type and

	Length fields areomitted.</t>	Length fields areomitted.</dd>
	</list></t>	</dl>
		</dd>
	<t hangText="RSV: Reserved">Must be set to0.</t>	<dt>RSV: Reserved</dt>
		<dd>Must be set to0.</dd>
	</list></t>	<dt>CID: Context Identifier</dt>
		<dd>See <xref format="default"/>.</dd>
		<dt>EXT: Extension</dt>
		<dd>
		<dl newline="false" spacing="normal" indent="4">
		<dt>0:</dt>
		<dd>No extension byte follows.</dd>
		<dt>1:</dt>
		<dd>Extension byte <tt>EXT_0</tt>
		follows immediately. See <xref
		format="default"/>.</dd>
		</dl>
		</dd>
		</dl>
	</section>	</section>

		<section anchor="sec.ndn.interest.ext0"numbered="true" toc="default">
	<section anchor="sec.ndn.interest.ext0"title="Dispatch Extension">	<name>Dispatch Extension</name>
	<t>The<spanx>EXT_0</spanx> byte follows the	<t>The<tt>EXT_0</tt> byte follows the
	description in <xreftarget="sec.dispatch.ext"/> and is illustrated	description in <xreftarget="sec.dispatch.ext" format="default"/> and
	in <xreftarget="fig.ndn.interest.ext0"/>.</t>	is illustrated
		in <xreftarget="fig.ndn.interest.ext0" format="default"/>.</t>
	<figureanchor="fig.ndn.interest.ext0" title="EXT_0 format">	<figureanchor="fig.ndn.interest.ext0">
	<artworkalign="center"><![CDATA[	<name>EXT_0 Format</name>
		<artworkalign="center" name="" type="" alt=""><![CDATA[
	0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+
	\| NCS \| RSV \|EXT\|	\| NCS \| RSV \|EXT\|
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+

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

		<dl newline="true" spacing="normal" indent="4">
	<t><list hangIndent="4">	<dt>NCS: Name CompressionStrategy</dt>
	<t hangText="NCS: Name CompressionStrategy"><list	<dd>
	hangIndent="12">	<dl newline="false" spacing="normal" indent="4">
	<t hangText="00:">Names are compressed with the default name	<dt>00:</dt>
	compression strategy (see <xref	<dd>Names are compressed with the default name
	target="sec.ndn.namecompression"/>).</t>	compression strategy (see <xreftarget="sec.ndn.namecompressio
		n" format="default"/>).</dd>
	<t hangText="01:">Reserved.</t>	<dt>01:</dt>
		<dd>Reserved.</dd>
	<t hangText="10:">Reserved.</t>	<dt>10:</dt>
		<dd>Reserved.</dd>
	<t hangText="11:">Reserved.</t>	<dt>11:</dt>
	</list></t>	<dd>Reserved.</dd>
		</dl>
	<t hangText="RSV: Reserved">Must be set to0.</t>	</dd>
		<dt>RSV: Reserved</dt>
	<t hangText="EXT: Extension"><list hangIndent="8"	<dd>Must be set to0.</dd>
	>	<dt>EXT: Extension</dt>
	<t hangText="0:">No extension bytefollows.</t>	<dd>
		<dl newline="false" spacing="normal" indent="4">
	<t hangText="1:">A further extension byte follows	<dt>0:</dt>
	immediately.</t>	<dd>No extension bytefollows.</dd>
	</list></t>	<dt>1:</dt>
	</list></t>	<dd>A further extension byte follows
		immediately.</dd>
		</dl>
		</dd>
		</dl>
	</section>	</section>
	</section>	</section>

		<sectionnumbered="true" toc="default">
	<sectiontitle="Data Messages">	<name>Data Messages</name>
	<sectiontitle="Uncompressed DataMessages">	<sectionnumbered="true" toc="default">
		<name>Uncompressed DataMessages</name>
	<t>An uncompressed Data message uses the base dispatch	<t>An uncompressed Data message uses the base dispatch

	format and sets the Cflag to <spanx>0</spanx>,	format and sets the Cand Pflags to<tt>0</tt> and the M flag
	the Pflag to<spanx>0</spanx> and the M flag	to<tt>1</tt> (<xreftarget="fig.ndn.data.uncompr" format="default"/>)
	to<spanx>1</spanx> (<xref	. The Data message is
	target="fig.ndn.data.uncompr"/>). The Data message is
	handed to the NDN network stack without modifications.</t>	handed to the NDN network stack without modifications.</t>

		<figureanchor="fig.ndn.data.uncompr">
	<figureanchor="fig.ndn.data.uncompr"	<name>Dispatch Format forUncompressed NDN DataMessages</name>
	title="Dispatch format foruncompressed NDN Datamessages">	<artworkalign="center" name="" type="" alt=""><![CDATA[
	<artworkalign="center"><![CDATA[
	0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+
	\| 0 \| 0 \| 1 \| 0 \| 0 \| 0 \| 0 \| 0 \|	\| 0 \| 0 \| 1 \| 0 \| 0 \| 0 \| 0 \| 0 \|
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+

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

		<sectionnumbered="true" toc="default">
	<sectiontitle="Compressed DataMessages">	<name>Compressed DataMessages</name>
	<t>The compressed Data message uses the extended dispatch	<t>The compressed Data message uses the extended dispatch

	format (<xreftarget="fig.disp.base.compr"/>) andsets the C	format (<xreftarget="fig.disp.base.compr" format="default"/>) andset
	as well as the M flags to<spanx>1</spanx>. The	s the C
	P flag is set to<spanx>0</spanx>. If a Data	and M flags to<tt>1</tt>. The
		P flag is set to<tt>0</tt>. If a Data
	message contains TLVs that are not mentioned in the	message contains TLVs that are not mentioned in the

	following compression rules, then this messageMUST besent	following compression rules, then this message<bcp14>MUST</bcp14> besent
	uncompressed.</t>	uncompressed.</t>


	<t>By default, the Data message is compressed with the following	<t>By default, the Data message is compressed with the following

	base rule set:<list>	base rule set:</t>
	<t>The <spanx>Type</spanx> field of the outermost	<ol spacing="normal" type="1">
	MessageType TLV isremoved.</t>	<li>The <tt>Type</tt> field of the outermost
		MessageType TLV isremoved.</li>
	<t>The Name TLV is compressed according to <xref	<li>The Name TLV is compressed according to <xreftarget="sec.ndn.na
	target="sec.ndn.namecompression"/>. For this, all NameComponents	mecompression" format="default"/>. For this, all NameComponents
	are expected to be of type GenericNameComponent and to have a	are expected to be of type GenericNameComponent and to have a

	length greater than 0. In any other case, the messageMUST be	length greater than 0. In any other case, the message<bcp14>MUST<
	sentuncompressed.</t>	/bcp14> be
		sentuncompressed.</li>
	<t>The MetaInfo TLV Type and Length fields are elided from the	<li>The MetaInfo TLV Type and Length fields are elided from the
	compressed Datamessage.</t>	compressed Datamessage.</li>
		<li>The FreshnessPeriod TLV<bcp14>MUST</bcp14> be moved to the end
	<t>The FreshnessPeriod TLVMUST be moved to the end of the	of the
	compressed Data message. Type and	compressed Data message. Type and

	Length fields areelided and the value is encoded as described	Length fields areelided, and the value is encoded as described
	in <xreftarget="sec.compressedtime"/> as a1-byte time-code. Ift	in <xreftarget="sec.compressedtime" format="default"/> as a1-byt
	he freshness period is not	e
	a valid time-value, then the messageMUST be sentuncompressed	time-code. Ifthe freshness period is not
		a valid time-value, then the message<bcp14>MUST</bcp14> be sentu
		ncompressed
	in order to preserve the security envelope of the Data message.	in order to preserve the security envelope of the Data message.
	The presence of a FreshnessPeriod TLV is deduced from the	The presence of a FreshnessPeriod TLV is deduced from the

	remainingone byte length toparse.</t>	remainingone-byte length toparse.</li>
		<li>The Type fields of the SignatureInfo TLV, SignatureTypeTLV,
	<t>The Type fields of the SignatureInfo TLV, SignatureTypeTLV	and SignatureValue TLV areremoved.</li>
	and SignatureValue TLV areremoved.</t>	</ol>
	</list></t>	<t>The compressed NDN LoWPAN Data message is visualized in <xreftarge
		t="fig.ndn.data.newformat" format="default"/>.</t>
	<t>The compressed NDN LoWPAN Data message is visualized in <xref	<figureanchor="fig.ndn.data.newformat">
	target="fig.ndn.data.newformat"/>.</t>	<name>Compression of NDN LoWPAN DataMessage</name>
		<artworkalign="center" name="" type="" alt=""><![CDATA[
	<figureanchor="fig.ndn.data.newformat"
	title="Compression of NDN LoWPAN DataMessage">
	<artworkalign="center"><![CDATA[
	T = Type, L = Length, V = Value	T = Type, L = Length, V = Value
	Lc = Compressed Length, Vc = Compressed Value	Lc = Compressed Length, Vc = Compressed Value
	: = optional field, \| = mandatory field	: = optional field, \| = mandatory field

	+---------+---------+ +---------+	+---------+---------+ +---------+
	\| Msg T \| Msg L \| \| Msg Lc \|	\| Msg T \| Msg L \| \| Msg Lc \|
	+---------+---------+---------+ +---------+	+---------+---------+---------+ +---------+
	\| Name T \| Name L \| Name V \| \| Name Vc \|	\| Name T \| Name L \| Name V \| \| Name Vc \|
	+---------+---------+---------+ +---------+---------+	+---------+---------+---------+ +---------+---------+
	: Meta T : Meta L : : CTyp Lc : CType V :	: Meta T : Meta L : : CTyp Lc : CType V :

	skipping to change at line 1044 ¶	skipping to change at line 1064 ¶
	: FBID T : FBID L : FBID V : \| Sig Lc \|	: FBID T : FBID L : FBID V : \| Sig Lc \|
	+---------+---------+---------+ +---------+---------+	+---------+---------+---------+ +---------+---------+
	: CONT T : CONT L : CONT V : \| SInf Lc \| SInf Vc \|	: CONT T : CONT L : CONT V : \| SInf Lc \| SInf Vc \|
	+---------+---------+---------+ +---------+---------+	+---------+---------+---------+ +---------+---------+
	\| Sig T \| Sig L \| \| SVal Lc \| SVal Vc \|	\| Sig T \| Sig L \| \| SVal Lc \| SVal Vc \|
	+---------+---------+---------+ +---------+---------+	+---------+---------+---------+ +---------+---------+
	\| SInf T \| SInf L \| SInf V \| : FrPr Vc :	\| SInf T \| SInf L \| SInf V \| : FrPr Vc :
	+---------+---------+---------+ +---------+	+---------+---------+---------+ +---------+
	\| SVal T \| SVal L \| SVal V \|	\| SVal T \| SVal L \| SVal V \|
	+---------+---------+---------+	+---------+---------+---------+

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


	<t>Further TLV compression is indicated by the ICN LoWPAN dispatch	<t>Further TLV compression is indicated by the ICN LoWPAN dispatch

	in <xreftarget="fig.ndn.datacompr"/>.</t>	in <xreftarget="fig.ndn.datacompr" format="default"/>.</t>
		<figureanchor="fig.ndn.datacompr">
	<figureanchor="fig.ndn.datacompr"	<name>Dispatch Format forCompressed NDN DataMessages</name>
	title="Dispatch format forcompressed NDN Datamessages">	<artworkalign="center" name="" type="" alt=""><![CDATA[
	<artworkalign="center"><![CDATA[
	0 1	0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

	\|1 \| 0 \| 1 \|CID\|EXT\|FBI\|CON\|KLO\| RSV\|	\|0 \| 0 \| 1 \| 1 \|FBI\|CON\|KLO\| RSV \|CID\|EXT\|
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

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

		<dl newline="true" spacing="normal" indent="4">
	<t><list hangIndent="4">	<dt>FBI: FinalBlockIdTLV</dt>
	<t hangText="CID: Context Identifier">See <xref	<dd>
	/>.</t>	<dl newline="false" spacing="normal" indent="4">
		<dt>0:</dt>
	<t hangText="EXT: Extension"><list hangIndent="8"	<dd>The uncompressed message does not include a
	>	FinalBlockIdTLV.</dd>
	<t hangText="0:">No extension byte follows.</t>	<dt>1:</dt>
		<dd>The uncompressed message does include a
	<t hangText="1:">Extension byte <spanx>EXT_0</spa	FinalBlockId, and it is encoded according to <xref
	nx>	target="sec.ndn.namecompression" format="default"/>. If theFin
	follows immediately. See <xref	alBlockId
	/>.</t>	TLV is not compressible, then the message<bcp14>MUST</bcp14> b
	</list></t>	e sent
		uncompressed.</dd>
	<t hangText="FBI: FinalBlockIdTLV"><list hangIndent="12"	</dl>
	>	</dd>
	<t hangText="0:">The uncompressed message does not include a	<dt>CON: ContentTypeTLV</dt>
	FinalBlockIdTLV.</t>	<dd>
		<dl newline="false" spacing="normal" indent="4">
	<t hangText="1:">The uncompressed message does include a	<dt>0:</dt>
	FinalBlockId and it is encoded according to <xref	<dd>The uncompressed message does not include a
	target="sec.ndn.namecompression"/>. If theFinalBlockId TLV	ContentTypeTLV.</dd>
	is not compressible, then the messageMUST be sent	<dt>1:</dt>
	uncompressed.</t>	<dd>The uncompressed message does include a
	</list></t>

	<t hangText="CON: ContentTypeTLV"><list hangIndent="12"
	>
	<t hangText="0:">The uncompressed message does not include a
	ContentTypeTLV.</t>

	<t hangText="1:">The uncompressed message does include a
	ContentType TLV. The Type field is removed from the	ContentType TLV. The Type field is removed from the

	compressedmessage.</t>	compressedmessage.</dd>
	</list></t>	</dl>
		</dd>
	<t hangText="KLO: KeyLocatorTLV"><list hangIndent="12"	<dt>KLO: KeyLocatorTLV</dt>
	>	<dd>
	<t hangText="0:">If the included SignatureType requires a	<dl newline="false" spacing="normal" indent="4">
		<dt>0:</dt>
		<dd>If the included SignatureType requires a
	KeyLocator TLV, then the KeyLocator represents a name and is	KeyLocator TLV, then the KeyLocator represents a name and is
	compressed according to <xref	compressed according to <xref

	target="sec.ndn.namecompression"/>. If the name is not	target="sec.ndn.namecompression" format="default"/>. If the
	compressible, then the messageMUST be sent	name is not compressible, then the message
	uncompressed.</t>	<bcp14>MUST</bcp14> be sentuncompressed.</dd>
		<dt>1:</dt>
	<t hangText="1:">If the included SignatureType requires a	<dd>If the included SignatureType requires a
	KeyLocator TLV, then the KeyLocator represents a KeyDigest.	KeyLocator TLV, then the KeyLocator represents a KeyDigest.
	The Type field of this KeyDigest isremoved.</t>	The Type field of this KeyDigest isremoved.</dd>
	</list></t>	</dl>
		</dd>
		<dt>RSV: Reserved</dt>
		<dd>Must be set to 0.</dd>
		<dt>CID: Context Identifier</dt>
		<dd>See <xref format="default"/>.</dd>
		<dt>EXT: Extension</dt>
		<dd>
		<dl newline="false" spacing="normal" indent="4">
		<dt>0:</dt>
		<dd>No extension byte follows.</dd>
		<dt>1:</dt>
		<dd>Extension byte <tt>EXT_0</tt>
		follows immediately. See <xref
		format="default"/>.</dd>
		</dl>
		</dd>


	<t hangText="RSV: Reserved">Must be set to 0.</t>	</dl>
	</list></t>
	</section>	</section>

		<section anchor="sec.ndn.data.ext0"numbered="true" toc="default">
	<section anchor="sec.ndn.data.ext0"title="Dispatch Extension">	<name>Dispatch Extension</name>
	<t>The<spanx>EXT_0</spanx> byte follows the	<t>The<tt>EXT_0</tt> byte follows the
	description in <xreftarget="sec.dispatch.ext"/> and is illustrated	description in <xreftarget="sec.dispatch.ext" format="default"/> and
	in <xreftarget="fig.ndn.data.ext0"/>.</t>	is illustrated
		in <xreftarget="fig.ndn.data.ext0" format="default"/>.</t>
	<figureanchor="fig.ndn.data.ext0" title="EXT_0 format">	<figureanchor="fig.ndn.data.ext0">
	<artworkalign="center"><![CDATA[	<name>EXT_0 Format</name>
		<artworkalign="center" name="" type="" alt=""><![CDATA[
	0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+
	\| NCS \| RSV \|EXT\|	\| NCS \| RSV \|EXT\|
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+

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

		<dl newline="true" spacing="normal" indent="4">
	<t><list hangIndent="4">	<dt>NCS: Name CompressionStrategy</dt>
	<t hangText="NCS: Name CompressionStrategy"><list	<dd>
	hangIndent="12">	<dl newline="false" spacing="normal" indent="4">
	<t hangText="00:">Names are compressed with the default name	<dt>00:</dt>
	compression strategy (see <xref	<dd>Names are compressed with the default name
	target="sec.ndn.namecompression"/>).</t>	compression strategy (see <xreftarget="sec.ndn.namecompressio
		n" format="default"/>).</dd>
	<t hangText="01:">Reserved.</t>	<dt>01:</dt>
		<dd>Reserved.</dd>
	<t hangText="10:">Reserved.</t>	<dt>10:</dt>
		<dd>Reserved.</dd>
	<t hangText="11:">Reserved.</t>	<dt>11:</dt>
	</list></t>	<dd>Reserved.</dd>
		</dl>
	<t hangText="RSV: Reserved">Must be set to0.</t>	</dd>
		<dt>RSV: Reserved</dt>
	<t hangText="EXT: Extension"><list hangIndent="8"	<dd>Must be set to0.</dd>
	>	<dt>EXT: Extension</dt>
	<t hangText="0:">No extension bytefollows.</t>	<dd>
		<dl newline="false" spacing="normal" indent="4">
	<t hangText="1:">A further extension byte follows	<dt>0:</dt>
	immediately.</t>	<dd>No extension bytefollows.</dd>
	</list></t>	<dt>1:</dt>
	</list></t>	<dd>A further extension byte follows
		immediately.</dd>
		</dl>
		</dd>
		</dl>
	</section>	</section>
	</section>	</section>
	</section>	</section>

		<section anchor="sec.ccnx"numbered="true" toc="default">
	<section anchor="sec.ccnx"	<name>Space-Efficient Message Encoding forCCNx</name>
	title="Space-efficient Message Encoding forCCNx">	<sectionnumbered="true" toc="default">
	<sectiontitle="TLV Encoding">	<name>TLV Encoding</name>
	<t>The generic CCNx TLV encoding is described in <xref	<t>The generic CCNx TLV encoding is described in <xreftarget="RFC8609"
	target="RFC8609"/>. Type and Length fields attain the common fixed	format="default"/>. Type and Length fields attain the common fixed
	length of 2 bytes.</t>	length of 2 bytes.</t>

		<t>The TLV encoding for CCNx LoWPAN is changed to the morespace-efficie
	<t>The TLV encoding for CCNx LoWPAN is changed to the morespace	nt
	efficient encoding described in <xreftarget="sec.tlvencoding"/>.	encoding described in <xreftarget="sec.tlvencoding" format="default"/>.
	Hence NDN and CCNx use the same compressed format for writing	Hence, NDN and CCNx use the same compressed format for writing
	TLVs.</t>	TLVs.</t>
	</section>	</section>

		<sectionnumbered="true" toc="default">
	<sectiontitle="Name TLVCompression">	<name>Name TLVCompression</name>
	<t>Name TLVs are compressed using the scheme already defined in <xref	<t>Name TLVs are compressed using the scheme already defined in <xrefta
	target="sec.ndn.namecompression"/> for NDN. If a Name TLVcontains	rget="sec.ndn.namecompression" format="default"/> for NDN. If a Name TLVcontain
		s
	T_IPID, T_APP, or organizational TLVs, then the name remains	T_IPID, T_APP, or organizational TLVs, then the name remains
	uncompressed.</t>	uncompressed.</t>
	</section>	</section>

		<sectionnumbered="true" toc="default">
	<sectiontitle="Interest Messages">	<name>Interest Messages</name>
	<sectiontitle="Uncompressed InterestMessages">	<sectionnumbered="true" toc="default">
		<name>Uncompressed InterestMessages</name>
	<t>An uncompressed Interest message uses the base dispatch format	<t>An uncompressed Interest message uses the base dispatch format

	(see <xreftarget="fig.disp.base"/>) and sets the Cas well as the Mf	(see <xreftarget="fig.disp.base" format="default"/>) and sets the Ca
	lag to<spanx>0</spanx>.	nd Mflags to<tt>0</tt>.
	The P flag is set to<spanx>1</spanx> (<xreftarget="fig.	The P flag is set to<tt>1</tt> (<xreftarget="fig.ccnx.int.uncompr" f
	ccnx.int.uncompr"/>).	ormat="default"/>).
	The Interest message is handed to the CCNx network stack without modifications.</t>	The Interest message is handed to the CCNx network stack without modifications.</t>

		<figureanchor="fig.ccnx.int.uncompr">
	<figureanchor="fig.ccnx.int.uncompr"	<name>Dispatch Format forUncompressed CCNx InterestMessages</name>
	title="Dispatch format foruncompressed CCNx Interestmessages	<artworkalign="center" name="" type="" alt=""><![CDATA[
	">
	<artworkalign="center"><![CDATA[
	0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+
	\| 0 \| 1 \| 0 \| 0 \| 0 \| 0 \| 0 \| 0 \|	\| 0 \| 1 \| 0 \| 0 \| 0 \| 0 \| 0 \| 0 \|
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+

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

		<section anchor="sec.ccnxintcompbaseheader"numbered="true" toc="default
	<section anchor="sec.ccnxintcompbaseheader"	">
	title="Compressed InterestMessages">	<name>Compressed InterestMessages</name>
	<t>The compressed Interest message uses the extended dispatch format	<t>The compressed Interest message uses the extended dispatch format

	(<xreftarget="fig.disp.base.compr"/>) and sets the C and P flags to<	(<xreftarget="fig.disp.base.compr" format="default"/>) and sets the C
	spanx	and P flags to<tt>1</tt>. The M flag is set to<tt>0</tt>.
	>1</spanx>. The M flag is set to<spanx>0</sp
	anx>.
	If an Interest message contains TLVs that are not mentioned in the	If an Interest message contains TLVs that are not mentioned in the

	following compression rules, then this messageMUST besent	following compression rules, then this message<bcp14>MUST</bcp14> besent
	uncompressed.</t>	uncompressed.</t>


	<t>In the default use case, the Interest message is compressed with	<t>In the default use case, the Interest message is compressed with

	the following minimal rule set:<list>	the following minimal rule set:</t>
	<t>The Type and Length fields of the CCNx Message TLV are elided	<ol spacing="normal" type="1">
	and are obtained from theFixed Header ondecompression.</t>	<li>The version is elided from the fixed header and assumed to be
	</list></t>	1.</li>
		<li>The Type and Length fields of the CCNx Message TLV are elided
		and are obtained from thefixed header ondecompression.</li>
		</ol>
	<t>The compressed CCNx LoWPAN Interest message is visualized in	<t>The compressed CCNx LoWPAN Interest message is visualized in

	<xreftarget="fig.ccnx.int.newformat"/>.</t>	<xreftarget="fig.ccnx.int.newformat" format="default"/>.</t>
		<figureanchor="fig.ccnx.int.newformat">
	<figureanchor="fig.ccnx.int.newformat"	<name>Compression of CCNx LoWPAN InterestMessage</name>
	title="Compression of CCNx LoWPAN InterestMessage">	<artworkalign="center" name="" type="" alt=""><![CDATA[
	<artworkalign="center"><![CDATA[
	T = Type, L = Length, V = Value	T = Type, L = Length, V = Value
	Lc = Compressed Length, Vc = Compressed Value	Lc = Compressed Length, Vc = Compressed Value
	: = optional field, \| = mandatory field	: = optional field, \| = mandatory field

	+-----------------------------+ +-------------------------+	+-----------------------------+ +-------------------------+
	\| Uncompr. Fixed Header \| \| Compr. Fixed Header \|	\| Uncompr. Fixed Header \| \| Compr. Fixed Header \|
	+-----------------------------+ +-------------------------+	+-----------------------------+ +-------------------------+
	+---------+---------+---------+ +---------+	+---------+---------+---------+ +---------+
	: ILT T : ILT L : ILT V : : ILT Vc :	: ILT T : ILT L : ILT V : : ILT Vc :
	+---------+---------+---------+ +---------+	+---------+---------+---------+ +---------+

	skipping to change at line 1242 ¶	skipping to change at line 1267 ¶
	: KIDR T : KIDR L : KIDR V : : OBHR Vc :	: KIDR T : KIDR L : KIDR V : : OBHR Vc :
	+---------+---------+---------+ +---------+---------+	+---------+---------+---------+ +---------+---------+
	: OBHR T : OBHR L : OBHR V : : PAYL Lc : PAYL V :	: OBHR T : OBHR L : OBHR V : : PAYL Lc : PAYL V :
	+---------+---------+---------+ +---------+---------+	+---------+---------+---------+ +---------+---------+
	: PAYL T : PAYL L : PAYL V : : VALG Lc : VALG Vc :	: PAYL T : PAYL L : PAYL V : : VALG Lc : VALG Vc :
	+---------+---------+---------+ +---------+---------+	+---------+---------+---------+ +---------+---------+
	: VALG T : VALG L : VALG V : : VPAY Lc : VPAY V :	: VALG T : VALG L : VALG V : : VPAY Lc : VPAY V :
	+---------+---------+---------+ +---------+---------+	+---------+---------+---------+ +---------+---------+
	: VPAY T : VPAY L : VPAY V :	: VPAY T : VPAY L : VPAY V :
	+---------+---------+---------+	+---------+---------+---------+

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


	<t>Further TLV compression is indicated by the ICN LoWPAN dispatch	<t>Further TLV compression is indicated by the ICN LoWPAN dispatch

	in <xreftarget="fig.ccnx.intcompr"/>.</t>	in <xreftarget="fig.ccnx.intcompr" format="default"/>.</t>
		<figureanchor="fig.ccnx.intcompr">
	<figureanchor="fig.ccnx.intcompr"	<name>Dispatch Format forCompressed CCNx InterestMessages</name>
	title="Dispatch format forcompressed CCNx Interestmessages">	<artworkalign="center" name="" type="" alt=""><![CDATA[
	<artworkalign="center"><![CDATA[
	0 1	0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

	\|1 \| 1 \| 0 \|CID\|EXT\|VER\|FLG\|PTY\|HPL\|FRS\|PAY\|ILT\|MGH\|KIR\|CHR\|VAL\|	\|0 \| 1 \| 0 \| 1 \|FLG\|PTY\|HPL\|FRS\|PAY\|ILT\|MGH\|KIR\|CHR\|VAL\|CID\|EXT\|
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

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

		<dl newline="true" spacing="normal" indent="4">
	<t><list hangIndent="4">	<dt>FLG: Flags field in the fixedheader</dt>
	<t hangText="CID: Context Identifier">See <xref	<dd>
	/>.</t>	<dl newline="false" spacing="normal" indent="4">
		<dt>0:</dt>
	<t hangText="EXT: Extension"><list hangIndent="8"	<dd>The Flags field equals 0 and is removed
	>	from the Interestmessage.</dd>
	<t hangText="0:">No extension byte follows.</t>	<dt>1:</dt>
		<dd>The Flags field appears in the fixedheader.</dd>
	<t hangText="1:">Extension byte <spanx>EXT_0</spa	</dl>
	nx>	</dd>
	follows immediately. See <xref	<dt>PTY: PacketType field in the fixedheader</dt>
	/>.</t>	<dd>
	</list></t>	<dl newline="false" spacing="normal" indent="4">
		<dt>0:</dt>
	<t	<dd>The PacketType field is elided and assumed
	hangText="VER: CCNx protocol version in the fixed header"><list	to be<tt>PT_INTEREST</tt>.</dd>
	hangIndent="8">	<dt>1:</dt>
	<t hangText="0:">The Version field equals 1 and is removed	<dd>The PacketType field is elided and assumed
	from the fixed header.</t>	to be<tt>PT_RETURN</tt>.</dd>
		</dl>
	<t hangText="1:">The Version field appears in the fixed header	</dd>
	.</t>	<dt>HPL: HopLimit field in the fixedheader</dt>
	</list></t>	<dd>
		<dl newline="false" spacing="normal" indent="4">
	<t hangText="FLG: Flags field in the fixedheader"><list	<dt>0:</dt>
	hangIndent="8">	<dd>The HopLimit field appears in the fixedheader.</dd>
	<t hangText="0:">The Flags field equals 0 and is removed	<dt>1:</dt>
	from the Interestmessage.</t>	<dd>The HopLimit field is elided and assumed to
		be<tt>1</tt>.</dd>
	<t hangText="1:">The Flags field appears in the fixedheader.<	</dl>
	/t>	</dd>
	</list></t>	<dt>FRS: Reserved field in the fixedheader</dt>
		<dd>
	<t hangText="PTY: PacketType field in the fixedheader"><list	<dl newline="false" spacing="normal" indent="4">
	hangIndent="8">	<dt>0:</dt>
	<t hangText="0:">The PacketType field is elided and assumed	<dd>The Reserved field appears in the fixedheader.</dd>
	to be<spanx>PT_INTEREST</spanx>.</t>	<dt>1:</dt>
		<dd>The Reserved field is elided and assumed to
	<t hangText="1:">The PacketType field is elided and assumed	be<tt>0</tt>.</dd>
	to be<spanx>PT_RETURN</spanx>.</t>	</dl>
	</list></t>	</dd>
		<dt>PAY: Optional PayloadTLV</dt>
	<t hangText="HPL: HopLimit field in the fixedheader"><list	<dd>
	hangIndent="8">	<dl newline="false" spacing="normal" indent="4">
	<t hangText="0:">The HopLimit field appears in the fixedheade	<dt>0:</dt>
	r.</t>	<dd>The Payload TLV isabsent.</dd>
		<dt>1:</dt>
	<t hangText="1:">The HopLimit field is elided and assumed to	<dd>The Payload TLV ispresent, and theType
	be<spanx>1</spanx>.</t>	field iselided.</dd>
	</list></t>	</dl>
		</dd>
	<t hangText="FRS: Reserved field in the fixedheader"><list	<dt>ILT: Optionalhop-by-hop InterestLifetimeTLV</dt>
	hangIndent="8">	<dd>
	<t hangText="0:">The Reserved field appears in the fixedheade	<t>See <xreftarget="sec.ccnxhbhint" format="default"/> for further
	r.</t>	details

	<t hangText="1:">The Reserved field is elided and assumed to
	be<spanx>0</spanx>.</t>
	</list></t>

	<t hangText="PAY: Optional PayloadTLV"><list hangIndent="8"
	>
	<t hangText="0:">The Payload TLV isabsent.</t>

	<t hangText="1:">The Payload TLV ispresent and thetype
	field iselided.</t>
	</list></t>

	<t
	hangText="ILT: OptionalHop-By-Hop InterestLifetimeTLV"><list
	hangIndent="8">
	<t>See <xreftarget="sec.ccnxhbhint"/> for further details
	on the ordering of hop-by-hop TLVs.</t>	on the ordering of hop-by-hop TLVs.</t>

		<dl newline="false" spacing="normal" indent="4">
	<t hangText="0:">No InterestLifetime TLV is present in the	<dt>0:</dt>
	Interestmessage.</t>	<dd>No InterestLifetime TLV is present in the
		Interestmessage.</dd>
	<t hangText="1:">An InterestLifetime TLV is present	<dt>1:</dt>
		<dd>An InterestLifetime TLV is present
	with a fixed length of 1 byte and is encoded as	with a fixed length of 1 byte and is encoded as

	described in <xref	described in <xreftarget="sec.compressedtime" format="default
	target="sec.compressedtime"/>. Thetype	"/>. The
	andlength fields areelided.</t>	Type andLength fields areelided.</dd>
	</list></t>	</dl>
		</dd>
	<t hangText="MGH: OptionalHop-By-Hop MessageHashTLV"><list	<dt>MGH: Optionalhop-by-hop MessageHashTLV</dt>
	hangIndent="8">	<dd>
	<t>See <xreftarget="sec.ccnxhbhint"/> forfurther details	<t>See <xreftarget="sec.ccnxhbhint" format="default"/> forfurt
	on the ordering of hop-by-hop TLVs.</t>	her
		details on the ordering of hop-by-hop TLVs.</t>
	<t>This TLV is expected to contain a T_SHA-256 TLV. If	<t>This TLV is expected to contain a T_SHA-256 TLV. If
	another hash is contained, then the InterestMUST be sent	another hash is contained, then the Interest<bcp14>MUST</bcp1
		4> be sent
	uncompressed.</t>	uncompressed.</t>

		<dl newline="false" spacing="normal" indent="4">
	<t hangText="0:">The MessageHash TLV isabsent.</t>	<dt>0:</dt>
		<dd>The MessageHash TLV isabsent.</dd>
	<t hangText="1:">A T_SHA-256 TLV ispresent and thetype as	<dt>1:</dt>
	well as the length fields are removed. Thelength field is	<dd>A T_SHA-256 TLV ispresent, and theType and
		Length fields are removed. TheLength field is
	assumed to represent 32 bytes. The outer Message Hash TLV	assumed to represent 32 bytes. The outer Message Hash TLV

	isomitted.</t>	isomitted.</dd>
	</list></t>	</dl>
		</dd>
	<t hangText="KIR: Optional KeyIdRestrictionTLV"><list	<dt>KIR: Optional KeyIdRestrictionTLV</dt>
	hangIndent="8">	<dd>
	<t>This TLV is expected to contain a T_SHA-256 TLV. If	<t>This TLV is expected to contain a T_SHA-256 TLV. If
	another hash is contained, then the InterestMUST be sent	another hash is contained, then the Interest<bcp14>MUST</bcp1
		4> be sent
	uncompressed.</t>	uncompressed.</t>

		<dl newline="false" spacing="normal" indent="4">
	<t hangText="0:">The KeyIdRestriction TLV isabsent.</t>	<dt>0:</dt>
		<dd>The KeyIdRestriction TLV isabsent.</dd>
	<t hangText="1:">A T_SHA-256 TLV ispresent and thetype as	<dt>1:</dt>
	well as the length fields are removed. Thelength field is	<dd>A T_SHA-256 TLV ispresent, and theType and
		Length fields are removed. TheLength field is
	assumed to represent 32 bytes. The outer KeyIdRestriction	assumed to represent 32 bytes. The outer KeyIdRestriction

	TLV isomitted.</t>	TLV isomitted.</dd>
	</list></t>	</dl>
		</dd>
	<t	<dt>CHR: Optional ContentObjectHashRestrictionTLV</dt>
	hangText="CHR: Optional ContentObjectHashRestrictionTLV"><list	<dd>
	hangIndent="8">	<t>This TLV is expected to contain a T_SHA-256 TLV. If
	<t>This TLV is expected to contain a T_SHA-256 TLV. If	another hash is contained, then the Interest<bcp14>MUST</bcp1
	another hash is contained, then the InterestMUST be sent	4> be sent
	uncompressed.</t>	uncompressed.</t>

		<dl newline="false" spacing="normal" indent="4">
		<dt>0:</dt>
		<dd>The ContentObjectHashRestriction TLV is
		absent.</dd>
		<dt>1:</dt>
		<dd>A T_SHA-256 TLV is present, and the Type and Length fields a
		re
		removed. The Length field is assumed to represent 32 bytes. The o
		uter
		ContentObjectHashRestriction TLV is omitted.</dd>
		</dl>
		</dd>
		<dt>VAL: Optional ValidationAlgorithm and ValidationPayload
		TLVs</dt>
		<dd>
		<dl newline="false" spacing="normal" indent="4">
		<dt>0:</dt>
		<dd>No validation-related TLVs are present in
		the Interest message.</dd>
		<dt>1:</dt>
		<dd>Validation-related TLVs are present in the
		Interest message. An additional byte follows immediately
		that handles validation-related TLV compressions and is
		described in <xref
		format="default"/>.</dd>
		</dl>
		</dd>
		<dt>CID: Context Identifier</dt>
		<dd><t>See <xref
		format="default"/>.</t></dd>
		<dt>EXT: Extension</dt>
		<dd>
		<dl newline="false" spacing="normal" indent="4">
		<dt>0:</dt>
		<dd>No extension byte follows.</dd>
		<dt>1:</dt>
		<dd>Extension byte <tt>EXT_0</tt>
		follows immediately. See <xref
		format="default"/>.</dd>
		</dl>
		</dd>


	<t hangText="0:">The ContentObjectHashRestriction TLV is	</dl>
	absent.</t>	<section anchor="sec.ccnxhbhint" toc="exclude" numbered="true">
		<name>Hop-By-Hop Header TLVs Compression</name>
	<t hangText="1:">A T_SHA-256 TLV is present and thetype as	<t>Hop-by-hop header TLVs are unordered. For an Interest message,
	well as thelength fields areremoved. The length field is	two optional hop-by-hop header TLVs are defined in <xref
	assumed to represent 32 bytes. The outer
	ContentObjectHashRestriction TLV is omitted.</t>	format="default"/>, but several more can be defined in higher-level
	</list></t>	specifications. For thecompression specified in the
		previous section, thehop-by-hop TLVs areordered as follows:
		</t>
		<ol spacing="normal" type="1">
		<li>InterestLifetime TLV</li>
		<li>Message Hash TLV</li>
		</ol>
		<!-- [rfced] Does listing the TLVs improve the readability of the sentence?
		Should the following TLVs be in 'camel case'? "Message Hash" and "Recommended Ca
		che Time"


	<t	Current (Sections 6.3.2.1 and6.4.2.1):
	hangText="VAL: Optional ValidationAlgorithm andValidationPayload	Note: Other hop-by-hop header TLVsthan those two remain uncompressed
	TLVs"><list	in theencoded message, and they appear in the same order as in the
	hangIndent="8">	original message but after the InterestLifetime TLV and Message Hash
	<t hangText="0:">No validation related TLVsare present in	TLV.
	theInterest message.</t>


	<t hangText="1:">Validation related TLVs are present in the	...
	Interest message. An additional byte follows immediately
	that handles validation related TLV compressions and is
	described in <xref/>.</t>
	</list></t>


	</list></t>	Note: Other hop-by-hop header TLVs than those two remain uncompressed
		in the encoded message, and they appear in the same order as in the
		original message but after the Recommended Cache Time TLV and Message
		Hash TLV.


	<section anchor="sec.ccnxhbhint"	Perhaps:
	title="Hop-By-Hop Header TLVsCompression" toc="exclude">	Note: All hop-by-hop header TLVsother than the InterestLifetime and
	<t>Hop-By-Hop Header TLVsare unordered. For an Interest message,	MessageHash TLVsremain uncompressed in the encoded message,and they
	two optional Hop-By-Hop Header TLVsare defined in <xref	appear after the InterestLifetime and MessageHash TLVs in thesame
	/>, but several more can be defined inhigher	order as in theoriginal message.
	level specifications. For thecompression specified in the
	previous section, the Hop-By-Hop TLVs are ordered as follows:
	<list>
	<t>Interest Lifetime TLV</t>


	<t>Message Hash TLV</t>	...
	</list></t>


	<t>Note: OtherHop-By-Hop Header TLVs than those two remain	Note: All hop-by-hop header TLVs other than the RecommendedCacheTime
	uncompressed in the encodedmessage and they appear in the	and MessageHash TLVs remain uncompressed in the encoded message, and
	same order as in the originalmessage, but after theInterest Lifeti	they appear after the RecommendedCacheTime and MessageHash TLVs in
	me TLV and Message Hash TLV.</t>	the same order as in the original message.
		-->
		<t>Note: Otherhop-by-hop header TLVs than those two remain
		uncompressed in the encodedmessage, and they appear in the
		same order as in the originalmessage but after theInterestLifetime
		TLV and Message Hash TLV.</t>
	</section>	</section>

		<section anchor="sec.ccnx.intval"toc="exclude" numbered="true">
	<section anchor="sec.ccnx.intval"title="Validation" toc="exclude">	<name>Validation</name>
	<figureanchor="fig.ccnx.dispatchintval"	<figureanchor="fig.ccnx.dispatchintval">
	title="Dispatch forInterset Validations">	<name>Dispatch forInterest Validations</name>
	<artworkalign="center"><![CDATA[	<artworkalign="center" name="" type="" alt=""><![CDATA[
	0 1 2 3 4 5 6 7 8	0 1 2 3 4 5 6 7 8
	+-------+-------+-------+-------+-------+-------+-------+-------+	+-------+-------+-------+-------+-------+-------+-------+-------+
	\| ValidationAlg \| KeyID \| RSV \|	\| ValidationAlg \| KeyID \| RSV \|
	+-------+-------+-------+-------+-------+-------+-------+-------+	+-------+-------+-------+-------+-------+-------+-------+-------+

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

		<dl newline="true" spacing="normal" indent="4">
	<t><list hangIndent="4">	<dt>ValidationAlg: Optional ValidationAlgorithmTLV</dt>
	<t	<dd>
	hangText="ValidationALg: Optional ValidationAlgorithmTLV"><list	<dl newline="false" spacing="normal" indent="8">
	hangIndent="8">	<dt>0000:</dt>
	<t hangText="0000:">An uncompressed ValidationAlgorithm	<dd>An uncompressed ValidationAlgorithm
	TLV isincluded.</t>	TLV isincluded.</dd>
		<dt>0001:</dt>
	<t hangText="0001:">A T_CRC32C ValidationAlgorithm TLV is	<dd>A T_CRC32C ValidationAlgorithm TLV is
	assumed, but no ValidationAlgorithm TLV isincluded.</t>	assumed, but no ValidationAlgorithm TLV isincluded.</dd>
		<dt>0010:</dt>
	<t hangText="0010:">A T_CRC32C ValidationAlgorithm TLV is	<dd>A T_CRC32C ValidationAlgorithm TLV is
	assumed, but no ValidationAlgorithm TLV is included.	assumed, but no ValidationAlgorithm TLV is included.

	Additionally, a Sigtime TLV is inlined without atype and	Additionally, a Sigtime TLV is inlined without aType and
	alength field.</t>	aLength field.</dd>
		<dt>0011:</dt>
	<t hangText="0011:">A T_HMAC-SHA256 ValidationAlgorithm	<dd>A T_HMAC-SHA256 ValidationAlgorithm
	TLV is assumed, but no ValidationAlgorithm TLV is	TLV is assumed, but no ValidationAlgorithm TLV is

	included.</t>	included.</dd>
		<dt>0100:</dt>
	<t hangText="0100:">A T_HMAC-SHA256 ValidationAlgorithm	<dd>A T_HMAC-SHA256 ValidationAlgorithm
	TLV is assumed, but no ValidationAlgorithm TLV is included.	TLV is assumed, but no ValidationAlgorithm TLV is included.

	Additionally, a Sigtime TLV is inlined without atype and	Additionally, a Sigtime TLV is inlined without aType and
	alength field.</t>	aLength field.</dd>
		<dt>0101:</dt>
	<t hangText="0101:">Reserved.</t>	<dd>Reserved.</dd>
		<dt>0110:</dt>
	<t hangText="0110:">Reserved.</t>	<dd>Reserved.</dd>
		<dt>0111:</dt>
	<t hangText="0111:">Reserved.</t>	<dd>Reserved.</dd>
		<dt>1000:</dt>
	<t hangText="1000:">Reserved.</t>	<dd>Reserved.</dd>
		<dt>1001:</dt>
	<t hangText="1001:">Reserved.</t>	<dd>Reserved.</dd>
		<dt>1010:</dt>
	<t hangText="1010:">Reserved.</t>	<dd>Reserved.</dd>
		<dt>1011:</dt>
	<t hangText="1011:">Reserved.</t>	<dd>Reserved.</dd>
		<dt>1100:</dt>
	<t hangText="1100:">Reserved.</t>	<dd>Reserved.</dd>
		<dt>1101:</dt>
	<t hangText="1101:">Reserved.</t>	<dd>Reserved.</dd>
		<dt>1110:</dt>
	<t hangText="1110:">Reserved.</t>	<dd>Reserved.</dd>
		<dt>1111:</dt>
	<t hangText="1111:">Reserved.</t>	<dd>Reserved.</dd>
	</list></t>	</dl>
		</dd>
	<t	<dt>KeyID: Optional KeyID TLV within theValidationAlgorithm TLV</
	hangText="KeyID: Optional KeyID TLV within theValidationAlgorit	dt>
	hm TLV"><list	<dd>
	hangIndent="8">	<dl newline="false" spacing="normal" indent="4">
	<t hangText="00:">The KeyId TLV isabsent.</t>	<dt>00:</dt>
		<dd>The KeyID TLV isabsent.</dd>
	<t hangText="01:">The KeyId TLV is present and	<dt>01:</dt>
	uncompressed.</t>	<dd>The KeyID TLV is present and
		uncompressed.</dd>
	<t hangText="10:">A T_SHA-256 TLV ispresent and thetype	<dt>10:</dt>
	field as well as the length fields are removed. Thelength	<dd>A T_SHA-256 TLV ispresent, and theType
	field is assumed to represent 32 bytes. The outerKeyId	and Length fields are removed. TheLength
	TLV isomitted.</t>	field is assumed to represent 32 bytes. The outerKeyID
		TLV isomitted.</dd>
	<t hangText="11:">A T_SHA-512 TLV ispresent and thetype	<dt>11:</dt>
	field as well as the length fields are removed. Thelength	<dd>A T_SHA-512 TLV ispresent, and theType
	field is assumed to represent 64 bytes. The outerKeyId	and Length fields are removed. TheLength
	TLV isomitted.</t>	field is assumed to represent 64 bytes. The outerKeyID
	</list></t>	TLV isomitted.</dd>
		</dl>
	<t hangText="RSV: Reserved">Must be set to0.</t>	</dd>
		<dt>RSV: Reserved</dt>
	</list></t>	<dd>Must be set to0.</dd>
		</dl>
	<t>The ValidationPayload TLV is present if the ValidationAlgorithm	<t>The ValidationPayload TLV is present if the ValidationAlgorithm

	TLV is present. Thetype field is omitted.</t>	TLV is present. TheType field is omitted.</t>
	</section>	</section>
	</section>	</section>

		<section anchor="sec.ccnx.interest.ext0"numbered="true" toc="default">
	<section anchor="sec.ccnx.interest.ext0"title="Dispatch Extension">	<name>Dispatch Extension</name>
	<t>The<spanx>EXT_0</spanx> byte follows the	<t>The<tt>EXT_0</tt> byte follows the
	description in <xreftarget="sec.dispatch.ext"/> and is illustrated	description in <xreftarget="sec.dispatch.ext" format="default"/> and
	in <xreftarget="fig.ccnx.interest.ext0"/>.</t>	is illustrated
		in <xreftarget="fig.ccnx.interest.ext0" format="default"/>.</t>
	<figureanchor="fig.ccnx.interest.ext0" title="EXT_0 format">	<figureanchor="fig.ccnx.interest.ext0">
	<artworkalign="center"><![CDATA[	<name>EXT_0 Format</name>
		<artworkalign="center" name="" type="" alt=""><![CDATA[
	0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+
	\| NCS \| RSV \|EXT\|	\| NCS \| RSV \|EXT\|
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+

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

		<dl newline="true" spacing="normal" indent="4">
	<t><list hangIndent="4">	<dt>NCS: Name CompressionStrategy</dt>
	<t hangText="NCS: Name CompressionStrategy"><list	<dd>
	hangIndent="12">	<dl newline="false" spacing="normal" indent="4">
	<t hangText="00:">Names are compressed with the default name	<dt>00:</dt>
	compression strategy (see <xref	<dd>Names are compressed with the default name
	target="sec.ndn.namecompression"/>).</t>	compression strategy (see <xreftarget="sec.ndn.namecompressio
		n" format="default"/>).</dd>
	<t hangText="01:">Reserved.</t>	<dt>01:</dt>
		<dd>Reserved.</dd>
	<t hangText="10:">Reserved.</t>	<dt>10:</dt>
		<dd>Reserved.</dd>
	<t hangText="11:">Reserved.</t>	<dt>11:</dt>
	</list></t>	<dd>Reserved.</dd>
		</dl>
	<t hangText="RSV: Reserved">Must be set to0.</t>	</dd>
		<dt>RSV: Reserved</dt>
	<t hangText="EXT: Extension"><list hangIndent="8"	<dd>Must be set to0.</dd>
	>	<dt>EXT: Extension</dt>
	<t hangText="0:">No extension bytefollows.</t>	<dd>
		<dl newline="false" spacing="normal" indent="4">
	<t hangText="1:">A further extension byte follows	<dt>0:</dt>
	immediately.</t>	<dd>No extension bytefollows.</dd>
	</list></t>	<dt>1:</dt>
	</list></t>	<dd>A further extension byte follows
		immediately.</dd>
		</dl>
		</dd>
		</dl>
	</section>	</section>
	</section>	</section>

		<sectionnumbered="true" toc="default">
	<sectiontitle="Content Objects">	<name>Content Objects</name>
	<sectiontitle="Uncompressed ContentObjects">	<sectionnumbered="true" toc="default">
	<t>An uncompressed Contentobject uses the base dispatch format (see	<name>Uncompressed ContentObjects</name>
	<xreftarget="fig.disp.base"/>) and sets the C flagto <spanx>0</spanx>, the P and M flags to	<xreftarget="fig.disp.base" format="default"/>) and sets the C flagt
	<spanx>1</spanx> (<xreftarget="fig.ccnx.data.uncompr"/>)	o
	.	<tt>0</tt> and the P and M flags to
	The Contentobject is handed to the CCNx network stack without modific	<tt>1</tt> (<xreftarget="fig.ccnx.data.uncompr" format="default"/>).
	ations.</t>	The ContentObject is handed to the CCNx network stack without modific
		ations.</t>
	<figureanchor="fig.ccnx.data.uncompr"	<figureanchor="fig.ccnx.data.uncompr">
	title="Dispatch format foruncompressed CCNx Contentobjects">	<name>Dispatch Format forUncompressed CCNx ContentObjects</name>
	<artworkalign="center"><![CDATA[	<artworkalign="center" name="" type="" alt=""><![CDATA[
	0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+
	\| 0 \| 1 \| 1 \| 0 \| 0 \| 0 \| 0 \| 0 \|	\| 0 \| 1 \| 1 \| 0 \| 0 \| 0 \| 0 \| 0 \|
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+

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

		<sectionnumbered="true" toc="default">
	<sectiontitle="Compressed ContentObjects">	<name>Compressed ContentObjects</name>
	<t>The compressed Contentobject uses the extended dispatch format	<t>The compressed ContentObject uses the extended dispatch format
	(<xreftarget="fig.disp.base.compr"/>) and sets theC, P,as well as t	(<xreftarget="fig.disp.base.compr" format="default"/>) and sets theC
	he Mflag to<spanx>1</spanx>.	, P,and M
	If a Contentobject contains TLVs that are notmentioned in thefollow	flags to<tt>1</tt>. If a ContentObject contains TLVs that are notmen
	ing compression	tioned in
	rules, then this messageMUST be sent uncompressed.</t>	thefollowing compression
		rules, then this message<bcp14>MUST</bcp14> be sent uncompressed.</t>
	<t>By default, the Contentobject is compressed with the following	<t>By default, the ContentObject is compressed with the following
	base rule set:<list>	base rule set:</t>
	<t>The PacketType field is elided from theFixed Header.</t>	<ol spacing="normal" type="1">
		<li>The version is elided from the fixed header and assumed to be
	<t>The Type and Length fields of the CCNx Message TLV are elided	1.</li>
	and are obtained from theFixed Header ondecompression.</t>	<li>The PacketType field is elided from thefixed header.</li>
	</list></t>	<li>The Type and Length fields of the CCNx Message TLV are elided
		and are obtained from thefixed header ondecompression.</li>
	<t>The compressed CCNx LoWPAN Data message is visualized in <xref	</ol>
	target="fig.ccnx.data.newformat"/>.</t>	<t>The compressed CCNx LoWPAN Data message is visualized in <xreftarg
		et="fig.ccnx.data.newformat" format="default"/>.</t>
	<figureanchor="fig.ccnx.data.newformat"	<figureanchor="fig.ccnx.data.newformat">
	title="Compression of CCNx LoWPAN DataMessage">	<name>Compression of CCNx LoWPAN DataMessage</name>
	<artworkalign="center"><![CDATA[	<artworkalign="center" name="" type="" alt=""><![CDATA[
	T = Type, L = Length, V = Value	T = Type, L = Length, V = Value
	Lc = Compressed Length, Vc = Compressed Value	Lc = Compressed Length, Vc = Compressed Value
	: = optional field, \| = mandatory field	: = optional field, \| = mandatory field

	+-----------------------------+ +-------------------------+	+-----------------------------+ +-------------------------+
	\| Uncompr. Fixed Header \| \| Compr. Fixed Header \|	\| Uncompr. Fixed Header \| \| Compr. Fixed Header \|
	+-----------------------------+ +-------------------------+	+-----------------------------+ +-------------------------+
	+---------+---------+---------+ +---------+	+---------+---------+---------+ +---------+
	: RCT T : RCT L : RCT V : : RCT Vc :	: RCT T : RCT L : RCT V : : RCT Vc :
	+---------+---------+------.--+ +---------+	+---------+---------+------.--+ +---------+

	skipping to change at line 1609 ¶	skipping to change at line 1668 ¶
	: PTYP T : PTYP L : PTYP V : : PAYL Lc : PAYL V :	: PTYP T : PTYP L : PTYP V : : PAYL Lc : PAYL V :
	+---------+---------+---------+ +---------+---------+	+---------+---------+---------+ +---------+---------+
	: EXPT T : EXPT L : EXPT V : : VALG Lc : VALG Vc :	: EXPT T : EXPT L : EXPT V : : VALG Lc : VALG Vc :
	+---------+---------+---------+ +---------+---------+	+---------+---------+---------+ +---------+---------+
	: PAYL T : PAYL L : PAYL V : : VPAY Lc : VPAY V :	: PAYL T : PAYL L : PAYL V : : VPAY Lc : VPAY V :
	+---------+---------+---------+ +---------+---------+	+---------+---------+---------+ +---------+---------+
	: VALG T : VALG L : VALG V :	: VALG T : VALG L : VALG V :
	+---------+---------+---------+	+---------+---------+---------+
	: VPAY T : VPAY L : VPAY V :	: VPAY T : VPAY L : VPAY V :
	+---------+---------+---------+	+---------+---------+---------+

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


	<t>Further TLV compression is indicated by the ICN LoWPAN dispatch	<t>Further TLV compression is indicated by the ICN LoWPAN dispatch

	in <xreftarget="fig.ccnx.datacompr"/>.</t>	in <xreftarget="fig.ccnx.datacompr" format="default"/>.</t>
		<figureanchor="fig.ccnx.datacompr">
	<figureanchor="fig.ccnx.datacompr"	<name>Dispatch Format forCompressed CCNx ContentObjects</name>
	title="Dispatch format forcompressed CCNx Contentobjects">	<artworkalign="center" name="" type="" alt=""><![CDATA[
	<artworkalign="center"><![CDATA[
	0 1	0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

	\|1 \| 1 \| 1 \|CID\|EXT\|VER\|FLG\|FRS\|PAY\|RCT\|MGH\| PLTYP \|EXP\|VAL\|RSV\|	\|0 \| 1 \| 1 \| 1 \|FLG\|FRS\|PAY\|RCT\|MGH\| PLTYP \|EXP\|VAL\|RSV\|CID\|EXT\|
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

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

		<dl newline="true" spacing="normal" indent="4">
	<t><list hangIndent="4">	<dt>FLG: Flags field in the fixedheader</dt>
	<t hangText="CID: Context Identifier">See <xref	<dd>See <xreftarget="sec.ccnxintcompbaseheader"
	/>.</t>	format="default"/>.</dd>
		<dt>FRS: Reserved field in the fixedheader</dt>
	<t hangText="EXT: Extension"><list hangIndent="8"	<dd>See <xreftarget="sec.ccnxintcompbaseheader"
	>	format="default"/>.</dd>
	<t hangText="0:">No extension byte follows.</t>	<dt>PAY: Optional PayloadTLV</dt>
		<dd>See <xreftarget="sec.ccnxintcompbaseheader"
	<t hangText="1:">Extension byte <spanx>EXT_0</spa	format="default"/>.</dd>
	nx>	<dt>RCT: Optionalhop-by-hop Recommended Cache Time TLV</dt>
	follows immediately. See <xref	<dd>
	/>.</t>	<dl newline="false" spacing="normal" indent="4">
	</list></t>	<dt>0:</dt>
		<dd>The Recommended Cache Time TLV is
	<t	absent.</dd>
	hangText="VER: CCNx protocol version in the fixed header"><list	<dt>1:</dt>
	hangIndent="8">	<dd>The Recommended Cache Time TLV ispresent,
	<t hangText="0:">The Version field equals 1 and is removed	and theType and Length fields areelided.</dd>
	from the fixed header.</t>	</dl>
		</dd>
	<t hangText="1:">The Version field appears in the fixed header	<dt>MGH: Optionalhop-by-hop MessageHashTLV</dt>
	.</t>	<dd>
	</list></t>	<t>See <xreftarget="sec.ccnxhbhdata" format="default"/> for
		further details on the ordering of hop-by-hop TLVs.</t>
	<t hangText="FLG: Flags field in the fixedheader">See <xref	<t>This TLV is expected to contain a T_SHA-256 TLV. If
	target="sec.ccnxintcompbaseheader"/>.</t>	another hash is contained, then the Content Object
		<bcp14>MUST</bcp14> be sent uncompressed.</t>
	<t hangText="FRS: Reserved field in the fixedheader">See <xref	<dl newline="false" spacing="normal" indent="4">
	target="sec.ccnxintcompbaseheader"/>.</t>	<dt>0:</dt>
		<dd>The MessageHash TLV isabsent.</dd>
	<t hangText="PAY: Optional PayloadTLV">See <xref	<dt>1:</dt>
	target="sec.ccnxintcompbaseheader"/>.</t>	<dd>A T_SHA-256 TLV ispresent, and theType and
		Length fields are removed. TheLength field is
	<t
	hangText="RCT: OptionalHop-By-Hop RecommendedCacheTime TLV"><list
	hangIndent="8">
	<t hangText="0:">The Recommended Cache Time TLV is
	absent.</t>

	<t hangText="1:">The Recommended Cache Time TLV ispresent
	and thetype as well as the length fields areelided.</t>
	</list></t>

	<t hangText="MGH: OptionalHop-By-Hop MessageHashTLV"><list
	hangIndent="8">
	<t>See <xreftarget="sec.ccnxhbhdata"/> for further details
	on the ordering of hop-by-hop TLVs.</t>

	<t>This TLV is expected to contain a T_SHA-256 TLV. If
	another hash is contained, then the Content ObjectMUST be
	sent uncompressed.</t>

	<t hangText="0:">The MessageHash TLV isabsent.</t>

	<t hangText="1:">A T_SHA-256 TLV ispresent and thetype as
	well as the length fields are removed. Thelength field is
	assumed to represent 32 bytes. The outer Message Hash TLV	assumed to represent 32 bytes. The outer Message Hash TLV

	isomitted.</t>	isomitted.</dd>
	</list></t>	</dl>
		</dd>
	<t><list hangIndent="4">	<dt/>
	<t hangText="PLTYP: Optional PayloadTypeTLV"><list	<dd>
	hangIndent="8">	<dl newline="true" spacing="normal" indent="4">
	<t hangText="00:">The PayloadType TLV isabsent.</t>	<dt>PLTYP: Optional PayloadTypeTLV</dt>
		<dd>
	<t hangText="01:">The PayloadType TLV isabsent and	<dl newline="false" spacing="normal" indent="4">
	T_PAYLOADTYPE_DATA isassumed.</t>	<dt>00:</dt>
		<dd>The PayloadType TLV isabsent.</dd>
	<t hangText="10:">The PayloadType TLV isabsent and	<dt>01:</dt>
	T_PAYLOADTYPE_KEY isassumed.</t>	<dd>The PayloadType TLV isabsent, and
		T_PAYLOADTYPE_DATA isassumed.</dd>
	<t hangText="11:">The PayloadType TLV is present and	<dt>10:</dt>
	uncompressed.</t>	<dd>The PayloadType TLV isabsent, and
	</list></t>	T_PAYLOADTYPE_KEY isassumed.</dd>
	</list></t>	<dt>11:</dt>
		<dd>The PayloadType TLV is present and
	<t hangText="EXP: Optional ExpiryTimeTLV"><list hangIndent="8"	uncompressed.</dd>
	>	</dl>
	<t hangText="0:">The ExpiryTime TLV isabsent.</t>	</dd>
		</dl>
	<t hangText="1:">The ExpiryTime TLV ispresent and thetype	</dd>
	as well as the length fields areelided.</t>	<dt>EXP: Optional ExpiryTimeTLV</dt>
	</list></t>	<dd>
		<dl newline="false" spacing="normal" indent="4">
	<t	<dt>0:</dt>
	hangText="VAL: Optional ValidationAlgorithm and ValidationPayload	<dd>The ExpiryTime TLV isabsent.</dd>
	TLVs">See	<dt>1:</dt>
	<xreftarget="sec.ccnxintcompbaseheader"/>.</t>	<dd>The ExpiryTime TLV ispresent, and theType
		and Length fields areelided.</dd>
	<t hangText="RSV: Reserved">Must be set to0.</t>	</dl>
		</dd>
	</list></t>	<dt>VAL: Optional ValidationAlgorithm and ValidationPayload
		TLVs</dt>
	<section anchor="sec.ccnxhbhdata"	<dd>See
	title="Hop-By-Hop Header TLVs Compression" toc="exclude">	<xreftarget="sec.ccnxintcompbaseheader" format="default"/>.</dd>
	<t>Hop-By-Hop Header TLVs are unordered. For a Content Object	<dt>RSV: Reserved</dt>
	message, two optional Hop-By-Hop Header TLVs are defined in <xref	<dd>Must be set to0.</dd>
	target="RFC8609"/>, but several more can be defined in higher	<dt>CID: Context Identifier</dt>
	level specifications. For the compression specified in the	<dd>See <xreftarget="fig.disp.base.compr" format="default"/>.</dd>
	previous section, the Hop-By-Hop TLVs are ordered as follows:	<dt>EXT: Extension</dt>
	<list>	<dd>
	<t>Recommended Cache Time TLV</t>	<dl newline="false" spacing="normal" indent="4">
		<dt>0:</dt>
	<t>Message Hash TLV</t>	<dd>No extension byte follows.</dd>
	</list></t>	<dt>1:</dt>
		<dd>Extension byte <tt>EXT_0</tt>
		follows immediately. See <xref for
		mat="default"/>.</dd>
		</dl>
		</dd>


	<t>Note: OtherHop-By-Hop Header TLVs than those two remain	</dl>
	uncompressed in the encodedmessage and they appear in the	<section anchor="sec.ccnxhbhdata" toc="exclude" numbered="true">
	same order as in the originalmessage, but after the RecommendedCac	<name>Hop-By-Hop Header TLVs Compression</name>
	he Time TLV and Message Hash TLV.</t>	<t>Hop-by-hop header TLVs are unordered. For a Content Object
		message, two optional hop-by-hop header TLVs are defined in
		<xref format="default"/>, but several more can be de
		fined in
		higher-level specifications. For the compression specified in the
		previous section, the hop-by-hop TLVs are ordered as follows:
		</t>
		<ol spacing="normal" type="1">
		<li>Recommended Cache Time TLV</li>
		<li>Message Hash TLV</li>
		</ol>
		<t>Note: Otherhop-by-hop header TLVs than those two remain
		uncompressed in the encodedmessage, and they appear in the
		same order as in the originalmessage but after the RecommendedCach
		e Time TLV and Message Hash TLV.</t>
	</section>	</section>
	</section>	</section>

		<section anchor="sec.ccnx.data.ext0"numbered="true" toc="default">
	<section anchor="sec.ccnx.data.ext0"title="Dispatch Extension">	<name>Dispatch Extension</name>
	<t>The<spanx>EXT_0</spanx> byte follows the	<t>The<tt>EXT_0</tt> byte follows the
	description in <xreftarget="sec.dispatch.ext"/> and is illustrated	description in <xreftarget="sec.dispatch.ext" format="default"/> and
	in <xreftarget="fig.ccnx.data.ext0"/>.</t>	is illustrated
		in <xreftarget="fig.ccnx.data.ext0" format="default"/>.</t>
	<figureanchor="fig.ccnx.data.ext0" title="EXT_0 format">	<figureanchor="fig.ccnx.data.ext0">
	<artworkalign="center"><![CDATA[	<name>EXT_0 Format</name>
		<artworkalign="center" name="" type="" alt=""><![CDATA[
	0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+
	\| NCS \| RSV \|EXT\|	\| NCS \| RSV \|EXT\|
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+

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

		<dl newline="true" spacing="normal" indent="4">
	<t><list hangIndent="4">	<dt>NCS: Name CompressionStrategy</dt>
	<t hangText="NCS: Name CompressionStrategy"><list	<dd>
	hangIndent="12">	<dl newline="false" spacing="normal" indent="4">
	<t hangText="00:">Names are compressed with the default name	<dt>00:</dt>
	compression strategy (see <xref	<dd>Names are compressed with the default name
	target="sec.ndn.namecompression"/>).</t>	compression strategy (see <xreftarget="sec.ndn.namecompressio
		n" format="default"/>).</dd>
	<t hangText="01:">Reserved.</t>	<dt>01:</dt>
		<dd>Reserved.</dd>
	<t hangText="10:">Reserved.</t>	<dt>10:</dt>
		<dd>Reserved.</dd>
	<t hangText="11:">Reserved.</t>	<dt>11:</dt>
	</list></t>	<dd>Reserved.</dd>
		</dl>
	<t hangText="RSV: Reserved">Must be set to0.</t>	</dd>
		<dt>RSV: Reserved</dt>
	<t hangText="EXT: Extension"><list hangIndent="8"	<dd>Must be set to0.</dd>
	>	<dt>EXT: Extension</dt>
	<t hangText="0:">No extension bytefollows.</t>	<dd>
		<dl newline="false" spacing="normal" indent="4">
	<t hangText="1:">A further extension byte follows	<dt>0:</dt>
	immediately.</t>	<dd>No extension bytefollows.</dd>
	</list></t>	<dt>1:</dt>
	</list></t>	<dd>A further extension byte follows
		immediately.</dd>
		</dl>
		</dd>
		</dl>
	</section>	</section>
	</section>	</section>
	</section>	</section>

		<sectionanchor="sec.compressedtime" numbered="true" toc="default">
	<sectiontitle="Compressed TimeEncoding" anchor="sec.compressedtime">	<name>Compressed TimeEncoding</name>
	<t>	<t>
	This document adopts the 8-bit compact time representation for	This document adopts the 8-bit compact time representation for

	relativetime values described inSection 5 of <xref	relativetime-values described in <xreftarget="RFC5497" section="5" sec
	target="RFC5497"/> with the constant factor<spanx	tionFormat="of" format="default"/> with the constant factor<tt>C</tt> set to<t
	>C</spanx> set to<spanx>C :=	t>C :=
	1/32</spanx>.	1/32</tt>.
	</t>	</t>


	<t>	<t>

	Valid time offsets in CCNx and NDN reach from a few	Valid time offsets in CCNx and NDN range from a few
	milliseconds (e.g., lifetime of low-latency Interests) to	milliseconds (e.g., lifetime of low-latency Interests) to
	several years (e.g., content freshness periods in caches).	several years (e.g., content freshness periods in caches).
	Therefore, this document adds two modifications to the	Therefore, this document adds two modifications to the
	compression algorithm.	compression algorithm.
	</t>	</t>


	<t>	<t>
	The first modification is the inclusion of a subnormal form	The first modification is the inclusion of a subnormal form

	<xref/> for time-codes with exponent	<xref format="default"/> for time-codes with exponent
	0 to provide an increased precision and a gradual underflow	0 to provide an increased precision and a gradual underflow
	for the smallest numbers. The formula is changed as	for the smallest numbers. The formula is changed as

	follows (a :=mantissa; b := exponent):	follows (a :=mantissa, b := exponent):

	<list>
	<t hangText="Subnormal (b == 0):"> (0 + a/8) * 2 * C
	</t>
	<t hangText="Normalized (b > 0):"> (1 + a/8) * 2^b * C (see <xref t
	arget="RFC5497"/>)
	</t>
	</list>

	This configuration allows for the following ranges:


	<list>
	<t>Minimum subnormal number: 0 seconds</t>
	<t>2nd minimum subnormal number: ~0.007812 seconds</t>
	<t>Maximum subnormal number: ~0.054688 seconds</t>
	<t>Minimum normalized number: ~0.062500 seconds</t>
	<t>2nd minimum normalized number: ~0.070312 seconds</t>
	<t>Maximum normalized number: ~3.99 years</t>
	</list>
	</t>	</t>

		<dl newline="false" spacing="normal">
		<dt>Subnormal (b == 0):</dt>
		<dd> (0 + a/8) * 2 * C
		</dd>
		<dt>Normalized (b > 0):</dt>
		<dd> (1 + a/8) * 2<sup>b</sup> * C (see <xref format="d
		efault"/>)
		</dd>
		</dl>
		<t>This configuration allows for the following ranges:</t>
		<ul spacing="compact">
		<li>Minimum subnormal number: 0 seconds</li>
		<li>2nd minimum subnormal number: ~0.007812 seconds</li>
		<li>Maximum subnormal number: ~0.054688 seconds</li>
		<li>Minimum normalized number: ~0.062500 seconds</li>
		<li>2nd minimum normalized number: ~0.070312 seconds</li>
		<li>Maximum normalized number: ~3.99 years</li>
		</ul>
	<t>	<t>
	The second modification only applies to uncompressible time	The second modification only applies to uncompressible time
	offsets that are outside any security envelope. An invalid	offsets that are outside any security envelope. An invalid

	time-valueMUST be set to the largest valid time-value that is	time-value<bcp14>MUST</bcp14> be set to the largest valid time-value that is
	smaller than the invalid input value before compression.	smaller than the invalid input value before compression.
	</t>	</t>
	</section>	</section>

		<section anchor="stateful.compression"numbered="true" toc="default">
	<section anchor="stateful.compression"title="Stateful HeaderCompression">	<name>Stateful HeaderCompression</name>
	<t>Stateful header compression in ICN LoWPAN enables packet size	<t>Stateful header compression in ICN LoWPAN enables packet size
	reductions in two ways. First, common information that is shared	reductions in two ways. First, common information that is shared

	throughout the local LoWPAN may be memorized in context state at all	throughout the local LoWPAN may be memorized inthecontext state at all
	nodes and omitted from communication. Second, redundancy in a single	nodes and omitted from communication. Second, redundancy in a single

	Interest-data exchange may be removed from ICN stateful forwarding on a	Interest-Data exchange may be removed from ICN stateful forwarding on a
	hop-by-hopbases and memorized in en-route state tables.</t>	hop-by-hopbasis and memorized in en-route state tables.</t>
		<section anchor="stateful.compression.local"numbered="true" toc="default"
	<section anchor="stateful.compression.local"title="LoWPAN-local State">	>
	<t>Acontext identifier (CID) is a byte that refers to a particular	<name>LoWPAN-Local State</name>
	conceptual context between network devices andMAY beused to replace	<t>AContext Identifier (CID) is a byte that refers to a particular
		conceptual context between network devices and<bcp14>MAY</bcp14> beuse
		d to replace
	frequently appearing information, such as name prefixes, suffixes, or	frequently appearing information, such as name prefixes, suffixes, or
	meta information, such as Interest lifetime.</t>	meta information, such as Interest lifetime.</t>

		<figureanchor="fig.cid">
	<figureanchor="fig.cid" title="Context Identifier.">	<name>Context Identifier</name>
	<artworkalign="center"><![CDATA[	<artworkalign="center" name="" type="" alt=""><![CDATA[
	0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+
	\| X \| ContextID \|	\| X \| ContextID \|
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+

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

		<t>The 7-bit ContextID is alocally scoped unique identifier that
	<t>The 7-bit ContextID is alocally-scoped unique identifier that	representsthe contextual state shared betweenthe sender and receivero
	represents contextual state shared between sender and receiverof the	f the
	corresponding frame (see <xreftarget="fig.cid"/>).	corresponding frame (see <xreftarget="fig.cid" format="default"/>).
	Ifset the most significant bit indicates the presence of another,subse	Ifset, the most significant bit indicates the presence of another,subs
	quent	equent
	ContextID byte (see <xreftarget="fig.cid.chain"/>).</t>	ContextID byte (see <xreftarget="fig.cid.chain" format="default"/>).</t
		>
	<t>Context state shared between senders and receivers is removedfrom th	<t>The context state shared between senders and receivers is removedfro
	e	m the
	compressed packet prior tosending, and reinserted after reception	compressed packet prior tosending and reinserted after reception
	prior to passing to the upper stack.</t>	prior to passing to the upper stack.</t>


	<t>The actual information in a context and how it is encoded are out of scope of this document.	<t>The actual information in a context and how it is encoded are out of scope of this document.
	The initial distribution and maintenance of shared context is out	The initial distribution and maintenance of shared context is out

	of scope of this document. Frames containing unknown or invalid CIDsMUST be silently discarded.</t>	of scope of this document. Frames containing unknown or invalid CIDs<bcp14>MUST</bcp14> be silently discarded.</t>
	</section>	</section>

		<section anchor="stateful.compression.en-route"numbered="true" toc="defau
	<section anchor="stateful.compression.en-route"title="En-route State">	lt">
		<name>En-Route State</name>
	<t>In CCNx and NDN, Name TLVs are included in Interest messages, and	<t>In CCNx and NDN, Name TLVs are included in Interest messages, and

	they return indata messages. Returning Name TLVs either equal the	they return inData messages. Returning Name TLVs either equal the
	original NameTLV, orthey contain the original Name TLV as a prefix.	original NameTLV or contain the original Name TLV as a prefix.
	ICN LoWPAN reduces this redundancy in responses by replacing Name TLVs	ICN LoWPAN reduces this redundancy in responses by replacing Name TLVs
	with single bytes that represent link-local HopIDs. HopIDs are	with single bytes that represent link-local HopIDs. HopIDs are

	carried as Context Identifiers (see <xrefstateful.compression.l
	ocal"/>) of link-localscope as shown in <xref	ocal" format="default"/>) of link-localscope, as shown in <xreftarget="fig.hop
	target="fig.hopid"/>.</t>	id" format="default"/>.</t>
		<figureanchor="fig.hopid">
	<figureanchor="fig.hopid" title="Context Identifier asHopID.">	<name>Context Identifier asHopID</name>
	<artworkalign="center"><![CDATA[	<artworkalign="center" name="" type="" alt=""><![CDATA[
	0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+
	\| X \| HopID \|	\| X \| HopID \|
	+---+---+---+---+---+---+---+---+	+---+---+---+---+---+---+---+---+

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

		<!-- [rfced] In the following sentence, should "replacing the name by" be "replacing the Name TLV with"?


		Current:
		An ICN LoWPAN node that
		forwards without replacing the name by a HopID (without en-route
		compression) MUST invalidate the HopID by setting all ID bits to
		zero.

		Perhaps:
		An ICN LoWPAN node that
		forwards without replacing the Name TLV with a HopID (without
		en-route compression) MUST invalidate the HopID by setting all
		ID bits to zero.
		-->
	<t>A HopID is valid if not all ID bits are set to zero and invalid	<t>A HopID is valid if not all ID bits are set to zero and invalid
	otherwise. This yields 127 distinct HopIDs. If this range (1...127) is	otherwise. This yields 127 distinct HopIDs. If this range (1...127) is

	exhausted, the messagesMUST be sent without en-route state	exhausted, the messages<bcp14>MUST</bcp14> be sent without en-route state
	compression until new HopIDs are available. An ICN LoWPAN node that	compression until new HopIDs are available. An ICN LoWPAN node that
	forwards without replacing the name by a HopID (without en-route	forwards without replacing the name by a HopID (without en-route

	compression)MUST invalidate the HopID by setting all ID-bits to	compression)<bcp14>MUST</bcp14> invalidate the HopID by setting all IDbits to
	zero.</t>	zero.</t>


	<t>While an Interest is traversing, a forwarder generates an ephemeral	<t>While an Interest is traversing, a forwarder generates an ephemeral

	HopID that is tied to aPIT entry. Each HopIDMUST be unique within	HopID that is tied to aPending Interest Table (PIT) entry. Each HopID
		<bcp14>MUST</bcp14> be unique within
	the local PIT and only exists during the lifetime of a PIT entry. To	the local PIT and only exists during the lifetime of a PIT entry. To
	maintain HopIDs, the local PIT is extended by two new columns: HIDi	maintain HopIDs, the local PIT is extended by two new columns: HIDi
	(inbound HopIDs) and HIDo (outbound HopIDs).</t>	(inbound HopIDs) and HIDo (outbound HopIDs).</t>


	<t>HopIDs are included in Interests and stored on the next hop with	<t>HopIDs are included in Interests and stored on the next hop with
	the resulting PIT entry in the HIDi column. The HopID is replaced with	the resulting PIT entry in the HIDi column. The HopID is replaced with
	a newly generated local HopID before the Interest is forwarded. This	a newly generated local HopID before the Interest is forwarded. This

	new HopID is stored in the HIDo column of the local PIT (see <xref	new HopID is stored in the HIDo column of the local PIT (see <xreftarge
	target="fig.enroute-a"/>). <figureanchor="fig.enroute-a"	t="fig.enroute-a" format="default"/>). </t>
	title="Setting compression state en-route (Interest).">	<figureanchor="fig.enroute-a">
	<artworkalign="center"><![CDATA[	<name>Setting Compression State En-Route (Interest)</name>
		<artworkalign="center" name="" type="" alt=""><![CDATA[
	PIT of B PIT Extension PIT of C PIT Extension	PIT of B PIT Extension PIT of C PIT Extension
	+--------+------++------+------+ +--------+------++------+------+	+--------+------++------+------+ +--------+------++------+------+
	\| Prefix \| Face \|\| HIDi \| HIDo \| \| Prefix \| Face \|\| HIDi \| HIDo \|	\| Prefix \| Face \|\| HIDi \| HIDo \| \| Prefix \| Face \|\| HIDi \| HIDo \|
	+========+======++======+======+ +========+======++======+======+	+========+======++======+======+ +========+======++======+======+
	\| /p0 \| F_A \|\| h_A \| h_B \| \| /p0 \| F_A \|\| h_A \| \|	\| /p0 \| F_A \|\| h_A \| h_B \| \| /p0 \| F_A \|\| h_A \| \|
	+--------+------++------+------+ +--------+------++------+------+	+--------+------++------+------+ +--------+------++------+------+
	^ \| ^	^ \| ^
	store \| '----------------------, ,---' store	store \| '----------------------, ,---' store
	\| send v \|	\| send v \|
	,---, /p0, h_A ,---, /p0, h_B ,---,	,---, /p0, h_A ,---, /p0, h_B ,---,
	\| A \| ------------------------> \| B \| ------------------------> \| C \|	\| A \| ------------------------> \| B \| ------------------------> \| C \|
	'---' '---' '---'	'---' '---' '---'

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

	<t>Responses include HopIDs that were obtained from Interests. If the	<t>Responses include HopIDs that were obtained from Interests. If the
	returning Name TLV equals the original Name TLV, then the name is	returning Name TLV equals the original Name TLV, then the name is

	entirely elided. Otherwise, only the matching name prefix is elided and	entirely elided. Otherwise, only the matching name prefix is elided, and
	the distinct name suffix is included along with	the distinct name suffix is included along with
	the HopID. When a response is forwarded, the contained HopID is	the HopID. When a response is forwarded, the contained HopID is
	extracted and used to match against the correct PIT entry by	extracted and used to match against the correct PIT entry by
	performing a lookup on the HIDo column. The HopID is then replaced	performing a lookup on the HIDo column. The HopID is then replaced
	with the corresponding HopID from the HIDi column prior to forwarding	with the corresponding HopID from the HIDi column prior to forwarding

	the response (<xreftarget="fig.enroute-b"/>). <figure	the response (<xreftarget="fig.enroute-b" format="default"/>). </t>
	anchor="fig.enroute-b"	<figureanchor="fig.enroute-b">
	title="Eliding Name TLVsusing en-route state (data).">	<name>Eliding Name TLVsUsing En-Route State (Data)</name>
	<artworkalign="center"><![CDATA[	<artworkalign="center" name="" type="" alt=""><![CDATA[
	PIT of B PIT Extension PIT of C PIT Extension	PIT of B PIT Extension PIT of C PIT Extension
	+--------+------++------+------+ +--------+------++------+------+	+--------+------++------+------+ +--------+------++------+------+
	\| Prefix \| Face \|\| HIDi \| HIDo \| \| Prefix \| Face \|\| HIDi \| HIDo \|	\| Prefix \| Face \|\| HIDi \| HIDo \| \| Prefix \| Face \|\| HIDi \| HIDo \|
	+========+======++======+======+ +========+======++======+======+	+========+======++======+======+ +========+======++======+======+
	\| /p0 \| F_A \|\| h_A \| h_B \| \| /p0 \| F_A \|\| h_A \| \|	\| /p0 \| F_A \|\| h_A \| h_B \| \| /p0 \| F_A \|\| h_A \| \|
	+--------+------++------+------+ +--------+------++------+------+	+--------+------++------+------+ +--------+------++------+------+
	\| ^ \|	\| ^ \|
	send \| '----------------------, ,---' send	send \| '----------------------, ,---' send
	v match \| v	v match \| v
	,---, h_A ,---, h_B ,---,	,---, h_A ,---, h_B ,---,
	\| A \| <------------------------ \| B \| <------------------------ \| C \|	\| A \| <------------------------ \| B \| <------------------------ \| C \|
	'---' '---' '---'	'---' '---' '---'

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

	<t>It should be noted that each forwarder of an Interest in an ICN	<t>It should be noted that each forwarder of an Interest in an ICN
	LoWPAN network can individually decide whether to participate in	LoWPAN network can individually decide whether to participate in

	en-route compression or not. However, an ICN LoWPAN nodeSHOULD use	en-route compression or not. However, an ICN LoWPAN node<bcp14>SHOULD</bcp14> use
	en-route compression whenever the stateful compression mechanism is	en-route compression whenever the stateful compression mechanism is
	activated.</t>	activated.</t>


	<t>Note also that the extensions of the PIT data structure are	<t>Note also that the extensions of the PIT data structure are
	required only at ICN LoWPAN nodes, while regular NDN/CCNx forwarders	required only at ICN LoWPAN nodes, while regular NDN/CCNx forwarders
	outside of an ICN LoWPAN domain do not need to implement these	outside of an ICN LoWPAN domain do not need to implement these
	extensions.</t>	extensions.</t>
	</section>	</section>

		<sectionnumbered="true" toc="default">
	<sectiontitle="Integrating Stateful HeaderCompression">	<name>Integrating Stateful HeaderCompression</name>
	<t>A CID appears whenever the CID flag is set (see <xref	<t>A CID appears whenever the CID flag is set (see <xreftarget="fig.dis
	target="fig.disp.base.compr"/>). The CID is appended to the last ICN	p.base.compr" format="default"/>). The CID is appended to the last ICN
	LoWPAN dispatchbyte as shown in <xreftarget="fig.cid.loc"/>.</t>	LoWPAN dispatchbyte, as shown in <xreftarget="fig.cid.loc" format="def
		ault"/>.</t>
	<figureanchor="fig.cid.loc"	<figureanchor="fig.cid.loc">
	title="LoWPAN Encapsulation with ICN LoWPAN andCIDs">	<name>LoWPAN Encapsulation with ICN LoWPAN andCIDs</name>
	<artworkalign="center"><![CDATA[	<artworkalign="center" name="" type="" alt=""><![CDATA[
	...-------+--------+-------...-------+--...-+-------...	...-------+--------+-------...-------+--...-+-------...
	/ ... \| Page \| ICN LoWPAN Disp.\| CIDs \| Payload /	/ ... \| Page \| ICN LoWPAN Disp.\| CIDs \| Payload /
	...-------+--------+-------...-------+--...-+-------...	...-------+--------+-------...-------+--...-+-------...

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

		<!-- [rfced] In the second sentence, should "to use" be "the use of"?


	<t>Multiple CIDs are chained together, with the most significant bit	Current:
	indicating the presence of a subsequent CID(<xref	Multiple CIDs are chained together, with the most significant bit
	/>). This allows to use multiple shared contextsi	indicating the presence of a subsequent CID(Figure 33). This allows
	n compressedmessages.</t>	to use multiple shared contextsin compressedmessages.


		Perhaps:
		...This allows the use of multiple shared contexts in compressed messages.
		-->
		<t>Multiple CIDs are chained together, with the most significant bit
		indicating the presence of a subsequent CID (<xref format="default"/>). This allows to use multiple shared contexts in compressed
		messages.</t>
	<t>The HopID is always included as the very first CID.</t>	<t>The HopID is always included as the very first CID.</t>

		<figureanchor="fig.cid.chain">
	<figureanchor="fig.cid.chain"	<name>Chaining ofContext Identifiers</name>
	title="Chaining ofcontext identifiers.">	<artworkalign="center" name="" type="" alt=""><![CDATA[
	<artworkalign="center"><![CDATA[	+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+	\|1\| CID / HopID \| --> \|1\| CID \| --> \|0\| CID \|
	\|1\| CID / HopID \| --> \|1\| CID \| --> \|0\| CID \|	+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+	]]></artwork>
	]]></artwork>
	</figure>	</figure>


	<t/>
	</section>	</section>
	</section>	</section>

		<section anchor="sec.ndn.constvars"numbered="true" toc="default">
	<section anchor="sec.ndn.constvars"	<name>ICN LoWPAN Constants andVariables</name>
	title="ICN LoWPAN Constants andVariables">	<t>This is a summary of all ICN LoWPAN constants and variables.</t>
	<t>This is a summary of all ICN LoWPAN constants and variables.<list	<dl newline="false" spacing="normal" indent="8">
	hangIndent="8">	<dt>DEFAULT_NDN_HOPLIMIT:</dt>
	<t hangText="DEFAULT_NDN_HOPLIMIT:">255</t>	<dd>255</dd>
	</list></t>	</dl>
	</section>	</section>

		<section anchor="implementationnotice"numbered="true" toc="default">
	<section anchor="implementationnotice"	<name>Implementation Report andGuidance</name>
	title="Implementation Report andGuidance">	<!-- [rfced] RFC 7942 recommends deleting the implementation status section bef
		ore publishing as an RFC. Please let us know if any changes to Section 10 "Imple
		mentation Report and Guidance" are necessary.
		-->
	<t>The ICN LoWPAN scheme defined in this document has been implemented as	<t>The ICN LoWPAN scheme defined in this document has been implemented as

	an extension of the NDN/CCNx software stack <xreftarget="CCN-LITE"/> in	an extension of the NDN/CCNx software stack <xreftarget="CCN-LITE" format
	its IoT version on RIOT <xreftarget="RIOT"/>. Anexperimental	="default"/> in
	evaluation for NDN over ICNLOWPAN with varying configurations has been	its IoT version on RIOT <xreftarget="RIOT" format="default"/>. Anexperim
	performed in <xreftarget="ICNLOWPAN"/>. Energyprofilings and	ental
	processing time measurements indicate significant energy savings,while	evaluation for NDN over ICNLoWPAN with varying configurations has been
		performed in <xreftarget="ICNLOWPAN" format="default"/>. Energyprofilin
		g and
		processing time measurements indicate significant energy savings,and the
	amortized costs for processing show no penalties.</t>	amortized costs for processing show no penalties.</t>

		<sectionnumbered="true" toc="default">
	<sectiontitle="Preferred Configuration">	<name>Preferred Configuration</name>
	<t>The header compression performance depends on certain aspects and	<t>The header compression performance depends on certain aspects and

	configurations. It works best for the following cases:<list	configurations. It works best for the following cases:</t>
	>	<ul spacing="normal">
		<li>Signed time offsetscompress, per <xreftarget="sec.compressedtime
	<t>Signed time offsetscompress as per <xref	"
	target="sec.compressedtime"/> without the need for	format="default"/>, without the need forrounding.</li>
	rounding.</t>	<li>The contextual state (e.g., prefixes) isdistributed such that
		long names can be elided from Interest andData messages.</li>
	<t>Contextual state (e.g., prefixes) isdistributed, such that	<li>Frequently used TLV type numbers for CCNx and NDN stay
	long names can be elided from Interest anddata messages.</t>	in the lower range (<255).</li>
		</ul>
	<t>Frequently used TLV type numbers for CCNx and NDN stay	<t>
	in the lower range (<255).</t>	Name components are of typeGenericNameComponent and are limited to a
	</list>
	Name components are ofGenericNameComponent type and are limited to a
	length of 15 bytes to enable compression for all messages.</t>	length of 15 bytes to enable compression for all messages.</t>
	</section>	</section>

		<sectionnumbered="true" toc="default">
	<sectiontitle="Further ExperimentalDeployments">	<name>Further ExperimentalDeployments</name>
	<t>An investigation of ICN LoWPAN in large-scale deployments	<t>An investigation of ICN LoWPAN in large-scale deployments
	with varying traffic patterns using larger samples of the	with varying traffic patterns using larger samples of the
	different board types available remains as future work. This	different board types available remains as future work. This
	document will be revised to progress it to the Standards	document will be revised to progress it to the Standards
	Track, once sufficient operational experience has been	Track, once sufficient operational experience has been
	acquired. Experience reports are encouraged, particularly in	acquired. Experience reports are encouraged, particularly in
	the following areas:	the following areas:

	<list>	</t>
	<t>The name compression scheme (<xref	<ul spacing="normal">
	target="sec.ndn.namecompression"/>) is optimized for short	<li>The name compression scheme (<xreftarget="sec.ndn.namecompression
	name components ofGenericNameComponent type. An empirical	" format="default"/>) is optimized for short
		name components oftype GenericNameComponent. An empirical
	study on name lengths in different deployments of selected	study on name lengths in different deployments of selected
	use cases, such as smart home, smart city, and industrial	use cases, such as smart home, smart city, and industrial
	IoT can provide meaningful reports on necessary name	IoT can provide meaningful reports on necessary name
	component types and lengths. A conclusive outcome helps to	component types and lengths. A conclusive outcome helps to
	understand whether and how extension mechanisms are needed	understand whether and how extension mechanisms are needed

	(<xreftarget="sec.ndn.interest.ext0"/>). As apreliminary	(<xreftarget="sec.ndn.interest.ext0" format="default"/>). As aprelim
	analysis, <xreftarget="ICNLOWPAN"/> investigates the	inary
		analysis, <xreftarget="ICNLOWPAN" format="default"/> investigates the
	effectiveness of the proposed compression scheme with URLs	effectiveness of the proposed compression scheme with URLs

	obtained from the WWW. Studies onCoAP <xref	obtained from the WWW. Studies on deploymentsof Constrained Applicati
	/> deployments can offeradditional insights	on Protocol (CoAP) <xref format="default"/> can offeradditiona
	on naming schemes in theIoT.</t>	l insights
		on naming schemes in theIoT.</li>
	<t>The fragmentation scheme (<xref	<li>The fragmentation scheme (<xreftarget="sec.Fragmentation" format=
	target="sec.Fragmentation"/>) inherited from 6LoWPAN allows	"default"/>) inherited from 6LoWPAN allows
	for a transparent, hop-wise reassembly of CCNx or NDN	for a transparent, hop-wise reassembly of CCNx or NDN

	packets. Fragment forwarding <xref	packets. Fragment forwarding <xreftarget="RFC8930" format="default"/>
	target="RFC8930"/> with selective	with selective
	fragment recovery <xref	fragment recovery <xreftarget="RFC8931" format="default"/> canimprov
	target="RFC8931"/> canimprove the	e the
	end-to-end latency andreliability, while it reduces buffer	end-to-end latency andreliability while it reduces buffer
	requirements on forwarders. Initial evaluations(<xref	requirements on forwarders. Initial evaluations<xrefSFR-ICNLOWPAN"/>) show that a naive integration of	OWPAN"
		format="default"/> show that a naive integration of
	these upcoming fragmentation features into ICN LoWPAN	these upcoming fragmentation features into ICN LoWPAN
	renders the hop-wise content replication inoperative, since	renders the hop-wise content replication inoperative, since

	Interest anddata messages are reassembled end-to-end. More	Interest andData messages are reassembled end-to-end. More
	deployment experiences are necessary to gauge the	deployment experiences are necessary to gauge the
	feasibility of different fragmentation schemes in ICN	feasibility of different fragmentation schemes in ICN
	LoWPAN.	LoWPAN.

	</t>	</li>
		<li>The context state (<xreftarget="stateful.compression.local"
	<t>Context state (<xref	format="default"/>) holds information
	target="stateful.compression.local"/>) holds information
	that is shared between a set of devices in a LoWPAN. Fixed	that is shared between a set of devices in a LoWPAN. Fixed
	name prefixes and suffixes are good candidates to be	name prefixes and suffixes are good candidates to be
	distributed to all nodes in order to elide them from request	distributed to all nodes in order to elide them from request
	and response messages. More experience and a deeper	and response messages. More experience and a deeper
	inspection of currently available and upcoming protocol	inspection of currently available and upcoming protocol

	features is necessary to identify other protocolfields.</t>	features is necessary to identify other protocolfields.</li>
		<li>The distribution and synchronization ofthe contextual state
	<t>The distribution and synchronization of contextual state	can potentially be adopted from <xreftarget="RFC6775" section="7.2" s
	can potentially be adopted fromSection 7.2 of <xref	ectionFormat="of" format="default"/> but requires further evaluations. While
	target="RFC6775"/>, but requires further evaluations. While
	6LoWPAN uses the Neighbor Discovery protocol to disseminate	6LoWPAN uses the Neighbor Discovery protocol to disseminate
	state, CCNx and NDN deployments are missing out on a	state, CCNx and NDN deployments are missing out on a
	standard mechanism to bootstrap and manage	standard mechanism to bootstrap and manage

	configurations.</t>	configurations.</li>
		<li>The stateful en-route compression (<xreftarget="stateful.compress
	<t>The stateful en-route compression (<xref	ion.en-route" format="default"/>) supports a limited
	target="stateful.compression.en-route"/>) supports a limited
	number of 127 distinct HopIDs that can be simultaneously in	number of 127 distinct HopIDs that can be simultaneously in
	use on a single node. Complex deployment scenarios that make	use on a single node. Complex deployment scenarios that make
	use of multiple, concurrent requests can provide a better	use of multiple, concurrent requests can provide a better

	insight on the number of open requests stored in thePending	insight on the number of open requests stored in the
	Interest Table of memory-constrained devices. This number	PIT of memory-constrained devices. This number
	can serve as anupper-bound and determines whether the HopID	can serve as anupper bound and determines whether the HopID
	length needs to be resized to fit more HopIDsto the cost of	length needs to be resized to fit more HopIDsat the cost of
	additional headeroverhead.</t>	additional headeroverhead.</li>
		<li>Multiple implementations that generate and deploy the
	<t>Multiple implementations that generate and deploy the
	compression options of this memo in different ways will also	compression options of this memo in different ways will also
	add to the experience and understanding of the benefits and	add to the experience and understanding of the benefits and
	limitations of the proposed schemes. Different reports can	limitations of the proposed schemes. Different reports can

	help to illuminateonthe complexity of implementing ICN	help to illuminate the complexity of implementing ICN
	LoWPAN for constrained devices, as well as on maintaining	LoWPAN for constrained devices, as well as on maintaining

	interoperability with otherimplementations.</t>	interoperability with otherimplementations.</li>
	</list>	</ul>
	</t>

	</section>	</section>
	</section>	</section>

		<section anchor="security.considerations"numbered="true" toc="default">
	<section anchor="security.considerations"title="Security Considerations">	<name>Security Considerations</name>
	<t>Main memory is typically a scarce resource of constrained networked	<t>Main memory is typically a scarce resource of constrained networked

	devices. Fragmentation as described in this memo preserves fragments and	devices. Fragmentation, as described in this memo, preserves fragments and
	purges them only after a packet is reassembled, which requires a	purges them only after a packet is reassembled, which requires a
	buffering of all fragments. This scheme is able to handle fragments for	buffering of all fragments. This scheme is able to handle fragments for
	distinctive packets simultaneously, which can lead to overflowing packet	distinctive packets simultaneously, which can lead to overflowing packet
	buffers that cannot hold all necessary fragments for packet reassembly.	buffers that cannot hold all necessary fragments for packet reassembly.
	Implementers are thus urged to make use of appropriate buffer	Implementers are thus urged to make use of appropriate buffer
	replacement strategies for fragments. Minimal fragment forwarding	replacement strategies for fragments. Minimal fragment forwarding

	<xreftarget="RFC8930"/> can potentially prevent fragment buffersaturatio	<xreftarget="RFC8930" format="default"/> can potentially prevent fragment
	n in forwarders.</t>	buffersaturation in forwarders.</t>

	<t>The stateful header compression generates ephemeral HopIDs for	<t>The stateful header compression generates ephemeral HopIDs for
	incoming and outgoing Interests and consumes them on returning Data	incoming and outgoing Interests and consumes them on returning Data
	packets. Forged Interests can deplete the number of available HopIDs,	packets. Forged Interests can deplete the number of available HopIDs,
	thus leading to a denial of compression service for subsequent content	thus leading to a denial of compression service for subsequent content
	requests.</t>	requests.</t>


	<t>To further alleviate the problems caused by forged fragments or	<t>To further alleviate the problems caused by forged fragments or
	Interest initiations, proper protective mechanisms for accessing the	Interest initiations, proper protective mechanisms for accessing the

	link-layer should be deployed. IEEE 802.15.4, e.g., provides capabilities to protect frames and restrict them to a point-to-point link, or a group of devices.</t>	link layer should be deployed. IEEE 802.15.4, e.g., provides capabilities to protect frames and restrict them to a point-to-point link or a group of devices.</t>
	</section>	</section>

		<section anchor="iana"numbered="true" toc="default">
	<section anchor="iana"title="IANA Considerations">	<name>IANA Considerations</name>
	<sectiontitle="Reserving Space in the 6LoWPAN Dispatch Type FieldRegistr	<sectionnumbered="true" toc="default">
	y">	<name>Updates to the 6LoWPAN Dispatch Type FieldRegistry</name>
	<t>IANA has assigned dispatch valuesof the <spanx>6LoWPAN	<t>IANA has assigned dispatch values for ICNLoWPAN in the "Dispatch Typ
	Dispatch Type Field</spanx>	e Field"
	registry <xref/><xref/> with Page	subregistry <xref format="default"/> <xref format="default"/> of
	target="tab.iana.dispatches"/> representsupdates to the registry.</t>	the "IPv6 Low Power Personal Area Network Parameters" registry.
		<xreftarget="tab.iana.dispatches" format="default"/> representsthe upd
	<texttable anchor="tab.iana.dispatches"	ates to the registry.</t>
	title="Dispatch types for NDN and CCNx withpage TBD1.">	<table anchor="tab.iana.dispatches"align="center">
	<ttcol align="center">BitPattern</ttcol>	<name>Dispatch Types for NDN and CCNxDispatch Types withPage 14</nam
		e>
	<ttcol align="center">Page</ttcol>	<thead>
		<tr>
	<ttcol align="left">HeaderType</ttcol>	<th align="center">BitPattern</th>
		<th align="center">Page</th>
	<c>00 000000</c>	<th align="left">HeaderType</th>
		<th align="left">Reference</th>
	<c>TBD1</c>	</tr>
		</thead>
	<c>Uncompressed NDN Interestmessages</c>	<tbody>
		<tr>
	<c>00 100000</c>	<td align="center">00 000000</td>
		<td align="center">14</td>
	<c>TBD1</c>	<td align="left">Uncompressed NDN Interestmessages</td>
		<td align="left">RFC 9139</td>
	<c>Uncompressed NDNData messages</c>	</tr>
		<tr>
	<c>01 000000</c>	<td align="center">00 01xxxx</td>
		<td align="center">14</td>
	<c>TBD1</c>	<td align="left">Compressed NDN Interestmessages</td>
		<td align="left">RFC 9139</td>
	<c>Uncompressed CCNx Interestmessages</c>	</tr>
		<tr>
	<c>01 100000</c>	<td align="center">00 100000</td>
		<td align="center">14</td>
	<c>TBD1</c>	<td align="left">Uncompressed NDNData messages</td>
		<td align="left">RFC 9139</td>
	<c>Uncompressed CCNx Content Object messages</c>	</tr>
		<tr>
	<c>10 0xxxxx</c>	<td align="center">00 11xxxx</td>
		<td align="center">14</td>
	<c>TBD1</c>	<td align="left">Compressed NDN Datamessages</td>
		<td align="left">RFC 9139</td>
	<c>Compressed NDNInterest messages</c>	</tr>
		<tr>
	<c>10 1xxxxx</c>	<td align="center">01 000000</td>
		<td align="center">14</td>
	<c>TBD1</c>	<td align="left">Uncompressed CCNx Interest messages</td>
		<td align="left">RFC 9139</td>
	<c>Compressed NDN Datamessages</c>	</tr>
		<tr>
	<c>11 0xxxxx</c>	<td align="center">01 01xxxx</td>
		<td align="center">14</td>
	<c>TBD1</c>	<td align="left">Compressed CCNx Interestmessages</td>
		<td align="left">RFC 9139</td>
	<c>Compressed CCNx Interestmessages</c>	</tr>
		<tr>
	<c>11 1xxxxx</c>	<td align="center">01 100000</td>
		<td align="center">14</td>
	<c>TBD1</c>	<td align="left">Uncompressed CCNx Content Object messages</td>
		<td align="left">RFC 9139</td>
	<c>Compressed CCNx Content Objectmessages</c>	</tr>
	</texttable>	<tr>
		<td align="center">01 11xxxx</td>
		<td align="center">14</td>
		<td align="left">Compressed CCNx Content Objectmessages</td>
		<td align="left">RFC 9139</td>
		</tr>
		</tbody>
		</table>
	</section>	</section>
	</section>	</section>
	</middle>	</middle>


	<back>	<back>

	<references title="Normative References">
	<?rfc include="reference.RFC.2119"?>

	<?rfc include="reference.RFC.4944"?>

	<?rfc include="reference.RFC.5497"?>

	<?rfc include="reference.RFC.6256"?>

	<?rfc include="reference.RFC.6282"?>


	<?rfc include="reference.RFC.6775"?>	<displayreference to="ICNRG-FLIC"/>

	<reference anchor="ieee802.15.4"
	>
	<front>
	<title>IEEE Std. 802.15.4-2015</title>

	<author surname="IEEE Computer Society"/>

	<date month="April" year="2016"/>
	</front>
	</reference>

	<reference anchor="IEEE.754.2019"
	>
	<front>
	<title>Standard for Floating-Point Arithmetic</title>
	<author initials="" fullname=""
	surname="Institute of Electrical and Electronics Engineers, C/
	MSC - Microprocessor Standards Committee"/>
	<date month="June" year="2019"/>
	</front>
	</reference>

	</references>

	<references title="Informative References">
	<?rfc include="reference.RFC.7252"?>

	<?rfc include="reference.RFC.7476"?>

	<?rfc include="reference.RFC.7927"?>


	<?rfc include="reference.RFC.7945"?>	<references>
		<name>References</name>
		<references>
		<name>Normative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2119.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8174.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4944.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5497.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6256.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6282.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6775.xml"/>


	<?rfc include="reference.RFC.7228"?>	<!-- [rfced] The following reference has be superceded by a 2020 version. Should it be updated to reflect this?


	<!--<?rfc include="reference.RFC.7400"?>-->	Original:
		[ieee802.15.4]
		"IEEE Std. 802.15.4-2015", April 2016,
		<https://standards.ieee.org/findstds/
		standard/802.15.4-2015.html>.
		-->


	<?rfc include="reference.RFC.8025"?>	<reference anchor="ieee802.15.4">
		<front>
		<title>IEEE Standard for Low-Rate Wireless
		Networks</title>
		<author><organization>IEEE</organization></author>
		</front>
		<seriesInfo name="IEEE Std" value="802.15.4-2015"/>
		</reference>


	<?rfc include="reference.RFC.8609"?>	<reference anchor="IEEE.754.2019">
		<front>
		<title>IEEE Standard for Floating-Point Arithmetic</title>
		<author><organization>IEEE</organization></author>
		</front>
		<seriesInfo name="IEEE Std" value="754-2019"/>
		</reference>
		</references>


	<?rfc include="reference.RFC.8569"?>	<references>
		<name>Informative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7252.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7476.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7927.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7945.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7228.xml"/>
		<!--<?rfc include="reference.RFC.7400"?>-->


	<?rfc include="reference.RFC.8930"?>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8025.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8609.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8569.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8930.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8931.xml"/>


	<?rfc include="reference.RFC.8931"?>	<!-- [I-D.irtf-icnrg-flic] IESG state Expired, long way used to capture editor info -->


	<?rfc include="reference.I-D.draft-irtf-icnrg-flic-02"?>	<reference anchor="I-D.irtf-icnrg-flic">
		<front>
		<title>File-Like ICN Collections (FLIC)</title>
		<author initials="C." surname="Tschudin" fullname="Christian Tschudin">
		<organization>University of Basel</organization>
		</author>
		<author initials="C." surname="Wood" fullname="Christopher A. Wood">
		<organization>University of California Irvine</organization>
		</author>
		<author initials="M." surname="Mosko" fullname="Marc Mosko">
		<organization>PARC, Inc.</organization>
		</author>
		<author initials="D." surname="Oran" fullname="David R. Oran" role="editor">
		<organization>Network Systems Research & Design</organization>
		</author>
		<date month="November" day="4" year="2019"/>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-flic-02"/>
		<format type="TXT"/>
		</reference>


	<reference anchor="CCN-LITE">	<!-- [rfced] We are having trouble accessing the URL from the reference below.
	<front>	Please review.
	<title>CCN-lite: A lightweight CCNx and NDN implementation</title>


	<author/>	[CCN-LITE]
		"CCN-lite: A lightweight CCNx and NDN implementation",
		<http://ccn-lite.net/>.
		-->


	<date/>	<reference anchor="CCN-LITE">
	</front>	<front>
	</reference>	<title>CCN-lite: A lightweight CCNx and NDN implementation</title>
		<author/>
		</front>
		</reference>


	<reference anchor="RIOT"	<reference anchor="RIOT"target="https://doi.org/10.1109/JIOT.2018.28150
	target="https://doi.org/10.1109/JIOT.2018.2815038">	38">
	<front>	<front>
	<title>RIOT:an Open Source Operating System forLow-end Embedded	<title>RIOT:An Open Source Operating System forLow-End Embedded
	Devices in the IoT</title>	Devices in the IoT</title>

		<author initials="E." surname="Baccelli">
		<organization>INRIA</organization>
		</author>
		<author initials="C." surname="Gündoğan">
		<organization>HAW Hamburg</organization>
		</author>
		<author initials="O." surname="Hahm">
		<organization>INRIA and FU Berlin</organization>
		</author>
		<author initials="P." surname="Kietzmann">
		<organization>HAW Hamburg</organization>
		</author>
		<author initials="MS." surname="Lenders">
		<organization>FU Berlin</organization>
		</author>
		<author initials="H." surname="Petersen">
		<organization>FU Berlin</organization>
		</author>
		<author initials="K." surname="Schleiser">
		<organization>INRIA and FU Berlin</organization>
		</author>
		<author initials="TC." surname="Schmidt">
		<organization>HAW Hamburg</organization>
		</author>
		<author initials="M." surname="Wählisch">
		<organization>FU Berlin</organization>
		</author>
		<date month="December" year="2018"/>
		</front>
		<refcontent>IEEE Internet of Things Journal Vol. 5, No. 6, p.
		4428-4440</refcontent>
		</reference>


	<author initials="E." surname="Baccelli">	<reference anchor="NDN-EXP1"target="http://dx.doi.org/10.1145/2660129.2
	<organization>INRIA</organization>	660144">
	</author>	<front>
		<title>Informationcentric networking in the IoT:experiments with
	<author initials="C." surname="Gundogan">	NDN in thewild</title>
	<organization>HAW Hamburg</organization>	<author initials="E." surname="Baccelli">
	</author>	<organization>INRIA</organization>
		</author>
	<author initials="O." surname="Hahm">	<author initials="C." surname="Mehlis">
	<organization>INRIA and FU Berlin</organization>	<organization>FU Berlin</organization>
	</author>	</author>
		<author initials="O." surname="Hahm">
	<author initials="P." surname="Kietzmann">	<organization>INRIA</organization>
	<organization>HAW Hamburg</organization>	</author>
	</author>	<author initials="TC." surname="Schmidt">
		<organization>HAW Hamburg</organization>
	<author initials="MS." surname="Lenders">	</author>
	<organization>FU Berlin</organization>	<author initials="M."surname="Wählisch">
	</author>	<organization>FU Berlin</organization>
		</author>
	<author initials="H." surname="Petersen">	<date month="September" year="2014"/>
	<organization>FU Berlin</organization>	</front>
	</author>	<refcontent>Proc. of 1st ACM Conf. on Information-CentricNetworking (
		ICN-2014)
	<author initials="K." surname="Schleiser">	ACM DL, pp.77-86</refcontent>
	<organization>INRIA and FU Berlin</organization>	</reference>
	</author>

	<author initials="TC." surname="Schmidt">
	<organization>HAW Hamburg</organization>
	</author>

	<author initials="M." surname="Waehlisch">
	<organization>FU Berlin</organization>
	</author>

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

	<seriesInfo name="IEEE Internet of Things Journal"
	value="Vol. 5, No. 6, p. 4428-4440"/>
	</reference>

	<reference anchor="NDN-EXP1"
	target="http://dx.doi.org/10.1145/2660129.2660144">
	<front>
	<title>InformationCentric Networking in the IoT:Experiments with
	NDN in theWild</title>

	<author initials="E." surname="Baccelli">
	<organization>INRIA</organization>
	</author>

	<author initials="C." surname="Mehlis">
	<organization>FU Berlin</organization>
	</author>

	<author initials="O." surname="Hahm">
	<organization>INRIA</organization>
	</author>

	<author initials="TC." surname="Schmidt">
	<organization>HAW Hamburg</organization>
	</author>

	<author initials="M."surname="Waehlisch">
	<organization>FU Berlin</organization>
	</author>

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

	<seriesInfo name="Proc. of 1st ACM Conf. on Information-CentricNetworki
	ng (ICN-2014)"
	value="ACM DL, pp.77-86"/>
	</reference>


	<reference anchor="NDN-EXP2"	<reference anchor="NDN-EXP2"target="https://doi.org/10.1145/3267955.326
	target="https://doi.org/10.1145/3267955.3267967">	7967">
	<front>	<front>
	<title>NDN, CoAP, and MQTT:A Comparative Measurement Study in the	<title>NDN, CoAP, and MQTT:a comparative measurement study in the
	IoT</title>	IoT</title>

		<author initials="C." surname="Gündoğan">
		<organization>HAW Hamburg</organization>
		</author>
		<author initials="P." surname="Kietzmann">
		<organization>HAW Hamburg</organization>
		</author>
		<author initials="M." surname="Lenders">
		<organization>FU Berlin</organization>
		</author>
		<author initials="H." surname="Petersen">
		<organization>FU Berlin</organization>
		</author>
		<author initials="TC." surname="Schmidt">
		<organization>HAW Hamburg</organization>
		</author>
		<author initials="M." surname="Wählisch">
		<organization>FU Berlin</organization>
		</author>
		<date month="September" year="2018"/>
		</front>
		<refcontent>Proc. of 5th ACM Conf. on Information-Centric Networking (
		ICN-2018)
		ACM DL, pp. 159-171</refcontent>
		</reference>


	<author initials="C." surname="Gundogan">	<reference anchor="NDN-MAC"target="https://doi.org/10.1145/3125719.3125
	<organization>HAW Hamburg</organization>	737">
	</author>	<front>
		<title>Theneed for aname to MACaddress mapping in NDN:towards
	<author initials="P." surname="Kietzmann">	quantifying theresource gain</title>
	<organization>HAW Hamburg</organization>	<author initials="P." surname="Kietzmann">
	</author>	<organization>HAW Hamburg</organization>
		</author>
	<author initials="M." surname="Lenders">	<author initials="C."surname="Gündoğan">
	<organization>FU Berlin</organization>	<organization>HAW Hamburg</organization>
	</author>	</author>
		<author initials="TC." surname="Schmidt">
	<author initials="H." surname="Petersen">	<organization>HAW Hamburg</organization>
	<organization>FU Berlin</organization>	</author>
	</author>	<author initials="O." surname="Hahm">
		<organization>riot-os.org</organization>
	<author initials="TC." surname="Schmidt">	</author>
	<organization>HAW Hamburg</organization>	<author initials="M."surname="Wählisch">
	</author>	<organization>FU Berlin</organization>
		</author>
	<author initials="M." surname="Waehlisch">	<date month="September" year="2017"/>
	<organization>FU Berlin</organization>	</front>
	</author>	<refcontent>Proc. of 4th ACM Conf. on Information-CentricNetworking (
		ICN-2017)
	<date month="September" year="2018"/>	ACM DL, pp.36-42</refcontent>
	</front>	</reference>

	<seriesInfo name="Proc. of 5th ACM Conf. on Information-Centric Networki
	ng (ICN-2018)"
	value="ACM DL, pp. 159-171"/>
	</reference>

	<reference anchor="NDN-MAC"
	target="https://doi.org/10.1145/3125719.3125737">
	<front>
	<title>TheNeed for aName to MACAddress Mapping in NDN:Towards
	Quantifying theResource Gain</title>

	<author initials="P." surname="Kietzmann">
	<organization>HAW Hamburg</organization>
	</author>

	<author initials="C."surname="Gundogan">
	<organization>HAW Hamburg</organization>
	</author>

	<author initials="TC." surname="Schmidt">
	<organization>HAW Hamburg</organization>
	</author>

	<author initials="O." surname="Hahm">
	<organization>riot-os.org</organization>
	</author>

	<author initials="M."surname="Waehlisch">
	<organization>FU Berlin</organization>
	</author>

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

	<seriesInfo name="Proc. of 4th ACM Conf. on Information-CentricNetworki
	ng (ICN-2017)"
	value="ACM DL, pp.36-42"/>
	</reference>


	<reference anchor="SFR-ICNLOWPAN"	<reference anchor="SFR-ICNLOWPAN"target="https://doi.org/10.1145/340565
	target="https://doi.org/10.1145/3405656.3418719">	6.3418719">
	<front>	<front>
	<title>Connecting the Dots: Selective Fragment Recovery in	<title>Connecting the Dots: Selective Fragment Recovery in
	ICNLoWPAN</title>	ICNLoWPAN</title>

		<author initials="M." surname="Lenders">
		<organization>FU Berlin</organization>
		</author>
		<author initials="C." surname="Gündoğan">
		<organization>HAW Hamburg</organization>
		</author>
		<author initials="TC." surname="Schmidt">
		<organization>HAW Hamburg</organization>
		</author>
		<author initials="M." surname="Wählisch">
		<organization>FU Berlin</organization>
		</author>
		<date month="September" year="2020"/>
		</front>
		<refcontent>Proc. of 7th ACM Conf. on Information-Centric Networking (
		ICN-2020)
		ACM DL, pp. 70-76</refcontent>
		</reference>


	<author initials="M." surname="Lenders">	<reference anchor="NDN"target="https://doi.org/10.1145/1658939.1658941"
	<organization>FU Berlin</organization>	>
	</author>	<front>
		<title>Networkingnamed content</title>
	<author initials="C." surname="Gundogan">	<author initials="V." surname="Jacobson"/>
	<organization>HAW Hamburg</organization>	<author initials="D." surname="Smetters"/>
	</author>	<author initials="J." surname="Thornton"/>
		<author initials="M." surname="Plass"/>
	<author initials="TC." surname="Schmidt">	<author initials="N." surname="Briggs"/>
	<organization>HAW Hamburg</organization>	<author initials="R." surname="Braynard"/>
	</author>	<datemonth="December" year="2009"/>
		</front>
	<author initials="M." surname="Waehlisch">	<refcontent>5th Int. Conf. on emerging Networking Experiments andTech
	<organization>FU Berlin</organization>	nologies
	</author>	(ACM CoNEXT)</refcontent>
		</reference>
	<date month="September" year="2020"/>
	</front>

	<seriesInfo name="Proc. of 7th ACM Conf. on Information-Centric Networki
	ng (ICN-2020)"
	value="ACM DL, pp. 70-76"/>
	</reference>

	<reference anchor="NDN"target="https://doi.org/10.1145/1658939.1658941">
	<front>
	<title>NetworkingNamed Content</title>

	<author initials="V." surname="Jacobson"/>

	<author initials="D." surname="Smetters"/>

	<author initials="J." surname="Thornton"/>

	<author initials="M." surname="Plass"/>

	<date year="2009"/>
	</front>

	<seriesInfo name="5th Int. Conf. on emerging Networking Experiments and
	Technologies"
	value="(ACM CoNEXT)"/>
	</reference>

	<reference anchor="NDN-PACKET-SPEC"
	>
	<front>
	<title>NDN Packet Format Specification</title>

	<author/>

	<date/>
	</front>
	</reference>

	<reference anchor="TLV-ENC-802.15.4"
	>
	<front>
	<title>CCN and NDN TLV encodings in 802.15.4 packets</title>


	<author/>	<reference anchor="NDN-PACKET-SPEC">
		<front>
		<title>NDN Packet Format Specification</title>
		<author/>
		</front>
		</reference>


	<date/>	<reference anchor="TLV-ENC-802.15.4">
	</reference>	<front>
		<title>CCN and NDN TLV encodings in 802.15.4 packets</title>
		<author initials="M." surname="Mosko"/>
		<author initials="C." surname="Tschudin"/>
		<date month="January" year="2015"/>
		</front>
		</reference>


	<reference anchor="WIRE-FORMAT-CONSID"	<reference anchor="WIRE-FORMAT-CONSID"target="https://datatracker.ietf.
	target="https://datatracker.ietf.org/meeting/interim-2015-icnrg	org/meeting/interim-2015-icnrg-01/materials/slides-interim-2015-icnrg-1-8">
	-01/materials/slides-interim-2015-icnrg-1-8">	<front>
	<front>	<title>CCN/NDN Protocol Wire Format and Functionality
	<title>CCN/NDN Protocol Wire Format and Functionality
	Considerations</title>	Considerations</title>

		<author initials="G." surname="Wang"/>
		<author initials="C." surname="Tschudin"/>
		<author initials="R." surname="Ravindran"/>
		<date month="January" year="2015"/>
		</front>
		</reference>


	<author/>	<reference anchor="ICNLOWPAN"target="https://doi.org/10.23919/IFIPNetwo
		rking.2019.8816850">
	<date/>	<front>
	</front>	<title>ICNLoWPAN- Named-Data Networking in Low Power IoT
	</reference>

	<reference anchor="ICNLOWPAN"target="https://doi.org/10.23919/IFIPNetwork
	ing.2019.8816850">
	<front>
	<title>ICNLoWPAN-- Named-Data Networking in Low Power IoT
	Networks</title>	Networks</title>

		<author initials="C."surname="Gündogan">
	<author initials="C."surname="Gundogan">	<organization>HAW Hamburg</organization>
	<organization>HAW Hamburg</organization>	</author>
	</author>	<author initials="P." surname="Kietzmann">
		<organization>HAW Hamburg</organization>
	<author initials="P." surname="Kietzmann">	</author>
	<organization>HAW Hamburg</organization>	<author initials="TC." surname="Schmidt">
	</author>	<organization>HAW Hamburg</organization>
		</author>
	<author initials="TC." surname="Schmidt">	<author initials="M."surname="Wählisch">
	<organization>HAW Hamburg</organization>	<organization>FU Berlin</organization>
	</author>	</author>
		<date month="May" year="2019"/>
	<author initials="M."surname="Waehlisch">	</front>
	<organization>FU Berlin</organization>	<refcontent>Proc. of18th IFIP NetworkingConference</refcontent>
	</author>	</reference>
		</references>
	<date month="May" year="2019"/>
	</front>

	<seriesInfo name="Proc. of18th" value="IFIP NetworkingConference"/>
	</reference>
	</references>	</references>

		<section anchor="sec.EstimatedSizeReduction"numbered="true" toc="default">
	<section anchor="sec.EstimatedSizeReduction"	<name>Estimated SizeReduction</name>
	title="Estimated SizeReduction">	<t>In thefollowing, a theoretical evaluation is given to estimate the
	<t>In thefollowing a theoretical evaluation is given to estimate the
	gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages.</t>	gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages.</t>

		<t>We assume that<tt>n</tt> is the number of name
	<t>We assume that<spanx>n</spanx> is the number of name	components; <tt>comps_n</tt> denotes the sum of n
	components, <spanx>comps_n</spanx> denotes the sum of n
	name component lengths. We also assume that the length of each name	name component lengths. We also assume that the length of each name
	component is lower than 16 bytes. The length of the content is given by	component is lower than 16 bytes. The length of the content is given by

	<spanx>clen</spanx>. The lengths of TLV componentsis	<tt>clen</tt>. The lengths of TLV componentsare
	specific to the CCNx or NDN encoding and outlined below.</t>	specific to the CCNx or NDN encoding andare outlined below.</t>
		<sectionnumbered="true" toc="default">
	<sectiontitle="NDN">	<name>NDN</name>
	<t>The NDN TLV encoding has variable-sized TLV fields. For simplicity,	<t>The NDN TLV encoding has variable-sized TLV fields. For simplicity,

	the1 byte form of each TLV component is assumed. A typical TLV	the1-byte form of each TLV component is assumed. A typical TLV
	component therefore is of size 2(type field +length field) + the	component therefore is of size 2(Type field +Length field) + the
	actual value.</t>	actual value.</t>

		<sectionnumbered="true" toc="default">
	<sectiontitle="Interest">	<name>Interest</name>
	<t><xreftarget="fig.Size.NDN.interest.uncompressed"/> depicts the	<t><xreftarget="fig.Size.NDN.interest.uncompressed" format="default"/
		> depicts the
	size requirements for a basic, uncompressed NDN Interest containing	size requirements for a basic, uncompressed NDN Interest containing

	a CanBePrefix TLV, a MustBeFresh TLV,a InterestLifetime TLV set to	a CanBePrefix TLV, a MustBeFresh TLV,an InterestLifetime TLV set to
	4seconds and a HopLimit TLV set to 6. Numbers below represent the	4seconds, and a HopLimit TLV set to 6. Numbers below represent the
	amount of bytes.</t>	amount of bytes.</t>

		<figureanchor="fig.Size.NDN.interest.uncompressed">
	<figureanchor="fig.Size.NDN.interest.uncompressed"	<name>Estimated Size of anUncompressed NDNInterest</name>
	title="Estimated size of anuncompressed NDNInterest">	<artworkalign="center" name="" type="" alt=""><![CDATA[
	<artworkalign="center"><![CDATA[
	------------------------------------,	------------------------------------,
	Interest TLV = 2 \|	Interest TLV = 2 \|
	---------------------, \|	---------------------, \|
	Name \| 2 + \|	Name \| 2 + \|
	NameComponents = 2n + \|	NameComponents = 2n + \|
	\| comps_n \|	\| comps_n \|
	---------------------' = 21 + 2n + comps_n	---------------------' = 21 + 2n + comps_n
	CanBePrefix = 2 \|	CanBePrefix = 2 \|
	MustBeFresh = 2 \|	MustBeFresh = 2 \|
	Nonce = 6 \|	Nonce = 6 \|
	InterestLifetime = 4 \|	InterestLifetime = 4 \|
	HopLimit = 3 \|	HopLimit = 3 \|
	------------------------------------'	------------------------------------'

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

		<t><xreftarget="fig.Size.NDN.interest.compressed" format="default"/>
	<t><xreftarget="fig.Size.NDN.interest.compressed"/> depicts the	depicts the
	size requirements after compression.</t>	size requirements after compression.</t>

		<figureanchor="fig.Size.NDN.interest.compressed">
	<figureanchor="fig.Size.NDN.interest.compressed"	<name>Estimated Size of aCompressed NDNInterest</name>
	title="Estimated size of acompressed NDNInterest">	<artworkalign="center" name="" type="" alt=""><![CDATA[
	<artworkalign="center"><![CDATA[
	------------------------------------,	------------------------------------,
	Dispatch Page Switch = 1 \|	Dispatch Page Switch = 1 \|

	NDN Interset Dispatch = 2 \|	NDN Interest Dispatch = 2 \|
	Interest TLV = 1 \|	Interest TLV = 1 \|
	-----------------------, \|	-----------------------, \|
	Name \| \|	Name \| \|
	NameComponents = n/2 + = 10 + n/2 + comps_n	NameComponents = n/2 + = 10 + n/2 + comps_n
	\| comps_n \|	\| comps_n \|
	-----------------------' \|	-----------------------' \|
	Nonce = 4 \|	Nonce = 4 \|
	HopLimit = 1 \|	HopLimit = 1 \|
	InterestLifetime = 1 \|	InterestLifetime = 1 \|
	------------------------------------'	------------------------------------'

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

		<t>The size differenceis 11 + 1.5n bytes.</t>
	<t>The size differenceis: <vspace/> 11 + 1.5n bytes.</t>	<t>For the name<tt>/DE/HH/HAW/BT7</tt>, the

	<t>For the name<spanx>/DE/HH/HAW/BT7</spanx>, the
	total size gain is 17 bytes, which is 43% of the uncompressed	total size gain is 17 bytes, which is 43% of the uncompressed
	packet.</t>	packet.</t>
	</section>	</section>

		<sectionnumbered="true" toc="default">
	<sectiontitle="Data">	<name>Data</name>
	<t><xreftarget="fig.Size.NDN.Data.uncompressed"/> depicts the size	<t><xreftarget="fig.Size.NDN.Data.uncompressed" format="default"/> de
		picts the size
	requirements for a basic, uncompressed NDN Data containing a	requirements for a basic, uncompressed NDN Data containing a
	FreshnessPeriod as MetaInfo. A FreshnessPeriod of 1 minute is	FreshnessPeriod as MetaInfo. A FreshnessPeriod of 1 minute is

	assumed and the value is encoded using 1 byte. An HMACWithSha256 is	assumed, and the value is encoded using 1 byte. An HMACWithSha256 is
	assumed as signature. The key locator is assumed to contain a Name	assumed asa signature. The key locator is assumed to contain a Name
	TLV of length klen.</t>	TLV of length klen.</t>

		<figureanchor="fig.Size.NDN.Data.uncompressed">
	<figureanchor="fig.Size.NDN.Data.uncompressed"	<name>Estimated Size of anUncompressed NDNData</name>
	title="Estimated size of anuncompressed NDNData">	<artworkalign="center" name="" type="" alt=""><![CDATA[
	<artworkalign="center"><![CDATA[
	------------------------------------,	------------------------------------,
	Data TLV = 2 \|	Data TLV = 2 \|
	---------------------, \|	---------------------, \|
	Name \| 2 + \|	Name \| 2 + \|
	NameComponents = 2n + \|	NameComponents = 2n + \|
	\| comps_n \|	\| comps_n \|
	---------------------' \|	---------------------' \|
	---------------------, \|	---------------------, \|
	MetaInfo \| \|	MetaInfo \| \|
	FreshnessPeriod = 6 \|	FreshnessPeriod = 6 \|

	skipping to change at line 2640 ¶	skipping to change at line 2641 ¶
	---------------------' \| clen + klen	---------------------' \| clen + klen
	Content = 2 + clen \|	Content = 2 + clen \|
	---------------------, \|	---------------------, \|
	SignatureInfo \| \|	SignatureInfo \| \|
	SignatureType \| \|	SignatureType \| \|
	KeyLocator = 41 + klen \|	KeyLocator = 41 + klen \|
	SignatureValue \| \|	SignatureValue \| \|
	DigestSha256 \| \|	DigestSha256 \| \|
	---------------------' \|	---------------------' \|
	------------------------------------'	------------------------------------'

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

		<t><xreftarget="fig.Size.NDN.Data.compressed" format="default"/> depi
	<t><xreftarget="fig.Size.NDN.Data.compressed"/> depicts the size	cts the size
	requirements for the compressed version of the above Data	requirements for the compressed version of the above Data
	packet.</t>	packet.</t>

		<figureanchor="fig.Size.NDN.Data.compressed">
	<figureanchor="fig.Size.NDN.Data.compressed"	<name>Estimated Size of aCompressed NDNData</name>
	title="Estimated size of acompressed NDNData">	<artworkalign="center" name="" type="" alt=""><![CDATA[
	<artworkalign="center"><![CDATA[
	------------------------------------,	------------------------------------,
	Dispatch Page Switch = 1 \|	Dispatch Page Switch = 1 \|
	NDN Data Dispatch = 2 \|	NDN Data Dispatch = 2 \|
	-----------------------, \|	-----------------------, \|
	Name \| \|	Name \| \|
	NameComponents = n/2 + \|	NameComponents = n/2 + \|
	\| comps_n = 38 + n/2 + comps_n +	\| comps_n = 38 + n/2 + comps_n +
	-----------------------' \| clen + klen	-----------------------' \| clen + klen
	Content = 1 + clen \|	Content = 1 + clen \|
	KeyLocator = 1 + klen \|	KeyLocator = 1 + klen \|
	DigestSha256 = 32 \|	DigestSha256 = 32 \|
	FreshnessPeriod = 1 \|	FreshnessPeriod = 1 \|
	------------------------------------'	------------------------------------'

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

		<t>The size differenceis 15 + 1.5n bytes.</t>
	<t>The size differenceis: <vspace/> 15 + 1.5n bytes.</t>	<t>For the name<tt>/DE/HH/HAW/BT7</tt>, the

	<t>For the name<spanx>/DE/HH/HAW/BT7</spanx>, the
	total size gain is 21 bytes.</t>	total size gain is 21 bytes.</t>
	</section>	</section>
	</section>	</section>

		<sectionnumbered="true" toc="default">
	<sectiontitle="CCNx">	<name>CCNx</name>
	<t>The CCNx TLV encoding defines a 2-byte encoding fortype and	<t>The CCNx TLV encoding defines a 2-byte encoding forType and
	length fields, summing up to 4 bytes in total without a value.</t>	Length fields, summing up to 4 bytes in total without a value.</t>
		<sectionnumbered="true" toc="default">
	<sectiontitle="Interest">	<name>Interest</name>
	<t><xreftarget="fig.Size.CCNx.interest.uncompressed"/> depicts the	<t><xreftarget="fig.Size.CCNx.interest.uncompressed" format="default"
	size requirements for a basic, uncompressed CCNx Interest. No	/> depicts
	Hop-By-Hop TLVs are included, the protocol version is assumed to be	the size requirements for a basic, uncompressed CCNx Interest. No
	1 and thereserved field is assumed to be 0. A KeyIdRestriction TLV	hop-by-hop TLVs are included, the protocol version is assumed to be
		1, and theReserved field is assumed to be 0. A KeyIdRestriction TLV
	with T_SHA-256 is included to limit the responses to Content Objects	with T_SHA-256 is included to limit the responses to Content Objects
	containing the specific key.</t>	containing the specific key.</t>

		<figureanchor="fig.Size.CCNx.interest.uncompressed">
	<figureanchor="fig.Size.CCNx.interest.uncompressed"	<name>Estimated Size of anUncompressed CCNxInterest</name>
	title="Estimated size of anuncompressed CCNxInterest">	<artworkalign="center" name="" type="" alt=""><![CDATA[
	<artworkalign="center"><![CDATA[
	------------------------------------,	------------------------------------,
	Fixed Header = 8 \|	Fixed Header = 8 \|
	Message = 4 \|	Message = 4 \|
	---------------------, \|	---------------------, \|
	Name \| 4 + = 56 + 4n + comps_n	Name \| 4 + = 56 + 4n + comps_n
	NameSegments = 4n + \|	NameSegments = 4n + \|
	\| comps_n \|	\| comps_n \|
	---------------------' \|	---------------------' \|
	KeyIdRestriction = 40 \|	KeyIdRestriction = 40 \|
	------------------------------------'	------------------------------------'

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

		<t><xreftarget="fig.Size.CCNx.interest.compressed" format="default"/>
	<t><xreftarget="fig.Size.CCNx.interest.compressed"/> depicts the	depicts the size requirements after compression.</t>
	size requirements after compression.</t>	<figureanchor="fig.Size.CCNx.interest.compressed">
		<name>Estimated Size of aCompressed CCNxInterest</name>
	<figureanchor="fig.Size.CCNx.interest.compressed"	<artworkalign="center" name="" type="" alt=""><![CDATA[
	title="Estimated size of acompressed CCNxInterest">
	<artworkalign="center"><![CDATA[
	------------------------------------,	------------------------------------,
	Dispatch Page Switch = 1 \|	Dispatch Page Switch = 1 \|
	CCNx Interest Dispatch = 2 \|	CCNx Interest Dispatch = 2 \|
	Fixed Header = 3 \|	Fixed Header = 3 \|
	-----------------------, \|	-----------------------, \|
	Name \| = 38 + n/2 + comps_n	Name \| = 38 + n/2 + comps_n
	NameSegments = n/2 + \|	NameSegments = n/2 + \|
	\| comps_n \|	\| comps_n \|
	-----------------------' \|	-----------------------' \|
	T_SHA-256 = 32 \|	T_SHA-256 = 32 \|
	------------------------------------'	------------------------------------'

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

		<t>The size differenceis 18 + 3.5n bytes.</t>
	<t>The size differenceis: <vspace/> 18 + 3.5n bytes.</t>	<t>For the name<tt>/DE/HH/HAW/BT7</tt>, the size

	<t>For the name<spanx>/DE/HH/HAW/BT7</spanx>, the size
	is reduced by 53 bytes, which is 53% of the uncompressed	is reduced by 53 bytes, which is 53% of the uncompressed
	packet.</t>	packet.</t>
	</section>	</section>

		<sectionnumbered="true" toc="default">
	<sectiontitle="Content Object">	<name>Content Object</name>
	<t><xreftarget="fig.Size.CCNx.Data.uncompressed"/> depicts the size	<t><xreftarget="fig.Size.CCNx.Data.uncompressed" format="default"/>
		depicts the size
	requirements for a basic, uncompressed CCNx Content Object	requirements for a basic, uncompressed CCNx Content Object
	containing an ExpiryTime Message TLV, an HMAC_SHA-256 signature, the	containing an ExpiryTime Message TLV, an HMAC_SHA-256 signature, the

	signaturetime and a hash of the shared secret key. In the fixed	signaturetime, and a hash of the shared secret key. In the fixed
	header, the protocol version is assumed to be 1 and thereserved	header, the protocol version is assumed to be 1 and theReserved
	field is assumed to be 0</t>	field is assumed to be 0</t>

		<figureanchor="fig.Size.CCNx.Data.uncompressed">
	<figureanchor="fig.Size.CCNx.Data.uncompressed"	<name>Estimated Size of anUncompressed CCNx ContentObject</name>
	title="Estimated size of anuncompressed CCNx ContentObject">	<artworkalign="center" name="" type="" alt=""><![CDATA[
	<artworkalign="center"><![CDATA[
	------------------------------------,	------------------------------------,
	Fixed Header = 8 \|	Fixed Header = 8 \|
	Message = 4 \|	Message = 4 \|
	---------------------, \|	---------------------, \|
	Name \| 4 + \|	Name \| 4 + \|
	NameSegments = 4n + \|	NameSegments = 4n + \|
	\| comps_n \|	\| comps_n \|
	---------------------' \|	---------------------' \|
	ExpiryTime = 12 = 124 + 4n + comps_n + clen	ExpiryTime = 12 = 124 + 4n + comps_n + clen
	Payload = 4 + clen \|	Payload = 4 + clen \|
	---------------------, \|	---------------------, \|
	ValidationAlgorithm \| \|	ValidationAlgorithm \| \|
	T_HMAC-256 = 56 \|	T_HMAC-256 = 56 \|

	KeyId \| \|	KeyID \| \|
	SignatureTime \| \|	SignatureTime \| \|
	---------------------' \|	---------------------' \|
	ValidationPayload = 36 \|	ValidationPayload = 36 \|
	------------------------------------'	------------------------------------'

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

		<t><xreftarget="fig.Size.CCNx.Data.compressed" format="default"/>
	<t><xreftarget="fig.Size.CCNx.Data.compressed"/> depicts the size	depicts the size
	requirements for a basic, compressed CCNx Data.</t>	requirements for a basic, compressed CCNx Data.</t>

		<figureanchor="fig.Size.CCNx.Data.compressed">
	<figureanchor="fig.Size.CCNx.Data.compressed"	<name>Estimated Size of aCompressed CCNx DataObject</name>
	title="Estimated size of acompressed CCNx DataObject">	<artworkalign="center" name="" type="" alt=""><![CDATA[
	<artworkalign="center"><![CDATA[
	------------------------------------,	------------------------------------,
	Dispatch Page Switch = 1 \|	Dispatch Page Switch = 1 \|
	CCNx Content Dispatch = 3 \|	CCNx Content Dispatch = 3 \|
	Fixed Header = 2 \|	Fixed Header = 2 \|
	-----------------------, \|	-----------------------, \|
	Name \| \|	Name \| \|
	NameSegments = n/2 + \|	NameSegments = n/2 + \|
	\| comps_n = 89 + n/2 + comps_n + clen	\| comps_n = 89 + n/2 + comps_n + clen
	-----------------------' \|	-----------------------' \|
	ExpiryTime = 8 \|	ExpiryTime = 8 \|
	Payload = 1 + clen \|	Payload = 1 + clen \|
	T_HMAC-SHA256 = 32 \|	T_HMAC-SHA256 = 32 \|
	SignatureTime = 8 \|	SignatureTime = 8 \|
	ValidationPayload = 34 \|	ValidationPayload = 34 \|
	------------------------------------'	------------------------------------'

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

		<t>The size differenceis 35 + 3.5n bytes.</t>
	<t>The size differenceis: <vspace/> 35 + 3.5n bytes.</t>	<t>For the name<tt>/DE/HH/HAW/BT7</tt>, the size

	<t>For the name<spanx>/DE/HH/HAW/BT7</spanx>, the size
	is reduced by 70 bytes, which is 40% of the uncompressed packet	is reduced by 70 bytes, which is 40% of the uncompressed packet
	containing a 4-byte payload.</t>	containing a 4-byte payload.</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>

		<sectionnumbered="false" toc="default">
	<sectionnumbered="no" title="Acknowledgments">	<name>Acknowledgments</name>
	<t>This work was stimulated by fruitful discussions in the ICNRG	<t>This work was stimulated by fruitful discussions in the ICNRG

	research groupand the communities of RIOT and CCNlite. We would like to	and the communities of RIOT and CCNlite. We would like to
	thank all active members for constructive thoughts and feedback. In	thank all active members for constructive thoughts and feedback. In
	particular, the authors would like to thank (in alphabetical order)	particular, the authors would like to thank (in alphabetical order)

	Peter Kietzmann, Dirk Kutscher, Martine Lenders, Colin Perkins, Junxiao Sh	<contact fullname="Peter Kietzmann"/>, <contact fullname="Dirk Kutscher"/>
	i. The	,
		<contact fullname="Martine Lenders"/>, <contact fullname="Colin Perkins"/>
		,
		and <contact fullname="Junxiao Shi"/>. The
	hop-wise stateful name compression was brought up in a discussion by	hop-wise stateful name compression was brought up in a discussion by

	Dave Oran, which is gratefully acknowledged. Larger parts of this work	<contact fullname="Dave Oran"/>, which is gratefully acknowledged.
	are inspired by <xreftarget="RFC4944"/> and <xreftarget="RFC6282"/>.	Larger parts of this work
	Specialmentioning goes toMark Mosko as well asG.Q. Wang andRavi	are inspired by <xreftarget="RFC4944" format="default"/> and
	Ravindran as their previous work in <xreftarget="TLV-ENC-802.15.4"/>	<xreftarget="RFC6282" format="default"/>.
	and <xreftarget="WIRE-FORMAT-CONSID"/> provided a goodbase for our	Specialmention goes to<contact fullname="Mark Mosko"/>, as well as
		<contact fullname="G.Q. Wang"/> and<contact fullname="Ravi Ravindran"/>,
		as their previous work in <xreftarget="TLV-ENC-802.15.4" format="default"
		/>
		and <xreftarget="WIRE-FORMAT-CONSID" format="default"/> provided a goodb
		ase for our
	discussions on stateless header compression mechanisms.	discussions on stateless header compression mechanisms.

	Many thanks also toCarsten Bormann andLars Eggert, who contributedin-de	Many thanks also to<contact fullname="Carsten Bormann"/> and
	pth commentsduring the IRSG review.	<contact fullname="Lars Eggert"/>, who contributedin-depth commentsdurin
		g
		the IRSG review.
	This work was supported in part by the German Federal Ministry of Research and	This work was supported in part by the German Federal Ministry of Research and
	Education within the projects I3 and RAPstore.</t>	Education within the projects I3 and RAPstore.</t>
	</section>	</section>


		<!--[rfced] Throughout the text, the following terminology appears to be used in
		consistently. Please review these occurences and let us know if/how they may be
		made consistent.

		context state vs. contextual state
		ContextID vs. CID
		Sigtime vs. SignatureTime

		Ranges are also formatted inconsistently:
		"range (1...127)" vs "range [128;252]"
		-->

		<!-- [rfced] Please review the "Inclusive Language" portion of the online Style
		Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let
		us know if any changes are needed. For example, please consider whether "traditi
		onal" or "native" should be updated for clarity.

		While the NIST website <https://www.nist.gov/nist-research-library/nist-technica
		l-series-publications-author-instructions#table1> indicates that "traditional" i
		s potentially biased, it is also ambiguous. "Tradition" is a subjective term, a
		s it is not the same for everyone.
		-->
	</back>	</back>
	</rfc>	</rfc>

End of changes. 365 change blocks.
	1971 lines changed or deleted	2132 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available fromhttp://tools.ietf.org/tools/rfcdiff/

[8]ページ先頭