rfc9139xml2.original.xml   rfc9139.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc [
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!ENTITY nbsp "&#160;">
<?rfc toc="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc symrefs="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc sortrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc compact="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?> <rfc xmlns: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" ?>
<rfc category="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="Matthias Waehlisch" 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="Matthias Wählisch" initials="M." surname="Wählisch">
<organization abbrev="link-lab &amp; FU Berlin">link-lab &amp; FU <organization abbrev="link-lab &amp; FU Berlin">link-lab &amp; 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 for CCNx and NDN over IEEE <t>This document defines a convergence layer for Content-Centric Networkin
802.15.4 LoWPAN networks. A new frame format is specified to adapt CCNx g
(CCNx) and Named Data Networking (NDN) over IEEE
802.15.4 Low-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 to ICN chunks. In its second part, the dispatching framework is applied to Information-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 elide state local to the LoWPAN and replace names in compression schemes elide states 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 replication demonstrated notable advantages over the in-network data replication demonstrates notable advantages over the
traditional host-to-host approach on the Internet <xref traditional host-to-host approach on the Internet <xref target="NDN-EXP1"
target="NDN-EXP1"/>, <xref target="NDN-EXP2"/>. Recent studies <xref format="default"/> <xref target="NDN-EXP2" format="default"/>. Recent stud
target="NDN-MAC"/> have shown that an appropriate mapping to link 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 <xref target="NDN"/> chunks to such link layers for the ICN flavors NDN <xref target="NDN"
and CCNx <xref target="RFC8569"/>, <xref target="RFC8609"/>.</t> format="default"/> and CCNx <xref target="RFC8569" format="default"/> <xre
f
<t>The IEEE 802.15.4 <xref target="ieee802.15.4"/> link layer is used in target="RFC8609" format="default"/>.</t>
low-power and lossy networks (see <spanx style="verb">LLN</spanx> in <t>The IEEE 802.15.4 <xref target="ieee802.15.4" format="default"/> link l
<xref target="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 <xref target="RFC7228" format="default"/>), in which devices are typically
increased latencies. IEEE 802.15.4 admits a maximum physical 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 maximum physical-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 <xref target="RFC4944" format="default"/> <xref target="RFC6282
<t>6LoWPAN <xref target="RFC4944"/><xref target="RFC6282">, </xref> is a "
convergence layer that provides frame formats, header compression and format="default"/> is a
adaptation layer fragmentation for IPv6 packets in IEEE 802.15.4 networks. convergence layer that provides frame formats, header compression, 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 formats based on Type-Length-Value (TLV), such as in
<t>Prevalent Type-Length-Value (TLV) based packet formats such as in CCNx and NDN, are designed to be generic and extensible. This leads to
CCNx and NDN are designed to be generic and extensible. This leads to header verbosity, which is inappropriate in constrained environments of
header verbosity 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 allows t wireless deployments of competing network technologies. This also allows r
o reuse euse of
the adaptation layer fragmentation scheme specified by 6LoWPAN for ICN LoW the adaptation-layer fragmentation scheme specified by 6LoWPAN for ICN LoW
PAN.</t> PAN.</t>
<t>ICN LoWPAN defines a more space-efficient representation of CCNx and
<t>ICN LoWPAN defines a more space 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 <xref target="
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 target="RFC7228"/> devices compared to uncompressed ICN mess Class 2 devices <xref target="RFC7228" format="default"/> compared to unco
ages.</t> mpressed ICN messages.</t>
<t>In a typical IoT scenario (see <xref target="fig-iot_network" format="d
<t>In a typical IoT scenario (see <xref target="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 some Gateway with the public Internet. In ICN based LoWPAN network by some gateway with the public Internet. In ICN-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 a Gateway and the embedded devices through the BR up and down between a gateway and the embedded devices
situated in the constrained LoWPAN.</t> situated in the constrained LoWPAN.</t>
<figure anchor="fig-iot_network">
<figure anchor="fig-iot_network" title="IoT Stub Network"> <name>IoT Stub Network</name>
<artwork align="center"><![CDATA[ <artwork align="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 communi ty and the research group (see Acknowledgments) for a period of two years. The document has received fruitful reviews by members of the ICN communi ty and the research group (see the Acknowledgments section) for a period of two years.
It is the consensus of ICNRG that this document should be published in t he IRTF Stream of the RFC series. It is the consensus of ICNRG that this document should be published in t he 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].
target="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 similarly construed.</t> construed.
<t>This document uses the terminology of <xref target="RFC7476"/>, <xref
target="RFC7927"/>, and <xref target="RFC7945"/> 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&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>This document uses the terminology of <xref target="RFC7476" format="de
fault"/>, <xref target="RFC7927" format="default"/>, and <xref target="RFC7945"
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" style="hanging"> </t>
<t hangText="ICN LoWPAN:">Information-Centric Networking over <dl newline="false" spacing="normal" indent="14">
Low-power Wireless Personal Area Network</t> <dt>ICN LoWPAN:</dt>
<dd>Information-Centric Networking over
<t hangText="LLN:">Low-Power and Lossy Network</t> Low-Power Wireless Personal Area Network</dd>
<dt>LLN:</dt>
<t hangText="CCNx:">Content-Centric Networking Architecture</t> <dd>Low-Power and Lossy Network</dd>
<dt>CCNx:</dt>
<t hangText="NDN:">Named Data Networking Architecture</t> <dd>Content-Centric Networking</dd>
<dt>NDN:</dt>
<t hangText="byte:">synonym for octet</t> <dd>Named Data Networking</dd>
<dt>byte:</dt>
<t hangText="nibble:">synonym for 4 bits</t> <dd>synonym for octet</dd>
<dt>nibble:</dt>
<t hangText="time-value:">a time offset measured in seconds</t> <dd>synonym for 4 bits</dd>
<dt>time-value:</dt>
<t hangText="time-code:">an 8-bit encoded time-value</t> <dd>a time offset measured in seconds</dd>
</list></t> <dt>time-code:</dt>
<dd>an 8-bit encoded time-value</dd>
</dl>
</section> </section>
<section anchor="ICNLoWPAN" numbered="true" toc="default">
<section anchor="ICNLoWPAN" title="Overview of ICN LoWPAN "> <name>Overview of ICN LoWPAN</name>
<section title="Link-Layer Convergence"> <section numbered="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
<xref target="fig.intro.hbh"/>.</t> <xref target="fig.intro.hbh" format="default"/>.</t>
<figure anchor="fig.intro.hbh">
<figure anchor="fig.intro.hbh" <name>ICN LoWPAN Convergence Layer for IEEE 802.15.4</name>
title="ICN LoWPAN convergence layer for IEEE 802.15.4"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="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 | | | | Link Layer |
'----------------|-' '-|--------------|-' '-|----------------' '----------------|-' '-|--------------|-' '-|----------------'
'--------' '---------' '--------' '---------'
]]></artwork> ]]></artwork>
</figure> </figure>
<t><xref target="sec.lowpan_adaptation" format="default"/> of this docum
<t><xref target="sec.lowpan_adaptation"/> of this document defines the ent defines the
convergence layer for IEEE 802.15.4.</t> convergence layer for IEEE 802.15.4.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Stateless Header Compression"> <name>Stateless Header Compression</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 for link-layers with small MTUs. The of particular importance for link layers with small MTUs. The
stateless compression does not require pre-configuration of global stateless compression does not require preconfiguration of a 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><xref target="fig.TLV.compressed" format="default"/> demonstrates the
<t><xref target="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 the type and the length fields are removed. The third TLV so that the Type 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 the type, length and the value fields are elided.</t> which the Type, Length, and Value fields are elided.</t>
<figure anchor="fig.TLV.compressed">
<figure anchor="fig.TLV.compressed" <name>Compression Using a Compact Bit Field -- Bits Encode the Inclusi
title="Compression using a compact bit field - bits encode the i on of
nclusion of TLVs."> TLVs</name>
<artwork align="center"><![CDATA[ <artwork align="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 | Bit field | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | Bit Field
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | | | |
,--' '----, '- 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 <xref target="sec.ndn
<t>Stateless TLV compression for NDN is defined in <xref " format="default"/>. <xref target="sec.ccnx" format="default"/> defines the sta
target="sec.ndn"/>. <xref target="sec.ccnx"/> defines the stateless teless
TLV compression for CCNx.</t> TLV compression for CCNx.</t>
<t>The extensibility of this compression is described in <xref target="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 this document.</t>
compression rules outlined in this manuscript.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Stateful Header Compression"> <name>Stateful Header Compression</name>
<t>ICN LoWPAN further employs two orthogonal stateful compression <t>ICN LoWPAN further employs two orthogonal, stateful compression
schemes for packet size reductions which are defined in <xref schemes for packet size reductions, which are defined in <xref target="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 generated on-demand hop-wise on a particular LoWPAN or are generated on demand hop-wise on a particular
Interest-data path.</t> Interest-Data path.</t>
<t>The shared context identification is defined in <xref target="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 <xref target="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.4 Adaptation"> <name>IEEE 802.15.4 Adaptation</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 (see Section 5 of <xref target="RFC4944"/>). for IEEE 802.15.4 frames (see <xref target="RFC4944" section="5" section
Multiple LoWPAN encapsulation headers can precede the actual payload Format="of" format="default"/>).
Multiple LoWPAN encapsulation headers can precede the actual payload,
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 "disp atch Page"?
<t><xref target="RFC8025"/> further specifies dispatch pages to switch Current:
between different contexts. When a LoWPAN parser encounters a <spanx When a LoWPAN parser encounters a Page switch
style="verb">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 dispatch table, as specified by the Page
table as specified by the <spanx style="verb">Page switch</spanx> switch header.
header. Page 0 and page 1 are reserved for 6LoWPAN. This document uses
page TBD1 (<spanx style="verb">1111 TBD1 (0xFTBD1)</spanx>) for ICN LoWP
AN.</t>
<t>The base dispatch format (<xref target="fig.disp.base"/>) is used
and extended by CCNx and NDN in <xref target="sec.ndn"/> and <xref
target="sec.ccnx"/>.</t>
<figure anchor="fig.disp.base" Perhaps:
title="Base dispatch format for ICN LoWPAN"> When a LoWPAN parser encounters a Page switch
<artwork align="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 target="RFC8025" 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 target="fig.disp.base" format="defaul
t"/>) is
used and extended by CCNx and NDN in Sections <xref target="sec.ndn" form
at="counter"/> and
<xref target="sec.ccnx" format="counter"/>.</t>
<figure anchor="fig.disp.base">
<name>Base Dispatch Format for ICN LoWPAN</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 ...
+---+---+---+---+---
| 0 | P | M | C |
+---+---+---+---+---
]]></artwork>
</figure> </figure>
<dl newline="true" spacing="normal" indent="4">
<t><list hangIndent="4" style="hanging"> <dt>P: Protocol</dt>
<t hangText="C: Compression"><list hangIndent="12" style="hanging"> <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 is NDN.</dd>
</list></t> <dt>1:</dt>
<dd>The included protocol is CCNx.</dd>
<t hangText="P: Protocol"><list hangIndent="12" style="hanging"> </dl>
<t hangText="0:">The included protocol is NDN.</t> </dd>
<dt>M: Message Type</dt>
<t hangText="1:">The included protocol is CCNx.</t> <dd>
</list></t> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt>
<t hangText="M: Message Type"><list hangIndent="12" <dd>The payload contains an Interest message.</dd>
style="hanging"> <dt>1:</dt>
<t hangText="0:">The payload contains an Interest message.</t> <dd>The payload contains a Data message.</dd>
</dl>
<t hangText="1:">The payload contains a Data message.</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 <xref target="fig.disp.base.compr" forma
target="fig.disp.base.compr"/>.</t> t="default"/>.</t>
<figure anchor="fig.disp.base.compr">
<figure anchor="fig.disp.base.compr" <name>Extended Dispatch Format for Compressed ICN LoWPAN</name>
title="Extended dispatch format for compressed ICN LoWPAN"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[ 0 1 2 3 ... ...
0 1 2 3 4 ... +---+---+---+---+...+---+---+
+---+---+---+---+---+--- | 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" style="hanging"> <dt>CID: Context Identifier</dt>
<t hangText="CID: Context Identifier"><list hangIndent="12" <dd>
style="hanging"> <dl newline="false" spacing="normal" indent="4">
<t hangText="0:">No context identifiers are present.</t> <dt>0:</dt>
<dd>No context identifiers are present.</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 <xref target="stateful.
</list></t> compression.local" format="default"/>).</dd>
</dl>
<t hangText="EXT: Extension"><list hangIndent="12" style="hanging"> </dd>
<t hangText="0:">No extension bytes are present.</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 are present.</dd>
</list></t> <dt>1:</dt>
<dd>Extension byte(s) are present (see <xref target="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>
<figure anchor="fig.ICN-LoWPAN.header" </dl>
title="LoWPAN Encapsulation with ICN-LoWPAN"> <t>The encapsulation format for ICN LoWPAN is displayed in <xref target=
<artwork align="center"><![CDATA[ "fig.ICN-LoWPAN.header" format="default"/>.</t>
<figure anchor="fig.ICN-LoWPAN.header">
<name>LoWPAN Encapsulation with ICN LoWPAN</name>
<artwork align="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" style="hanging"> <dt>IEEE 802.15.4:</dt>
<t hangText="IEEE 802.15.4:">The IEEE 802.15.4 header.</t> <dd>The IEEE 802.15.4 header.</dd>
<dt>RFC4944 Disp.:</dt>
<t hangText="RFC4944 Disp.:">Optional additional dispatches <dd>Optional additional dispatches
defined in Section 5.1 of <xref target="RFC4944"/></t> defined in <xref target="RFC4944" section="5.1" sectionFormat="of" f
ormat="default"/>.</dd>
<t hangText="Page:">Page Switch. TBD1 for ICN LoWPAN.</t> <dt>Page:</dt>
<dd><tt>Page switch</tt>. 14 for ICN LoWPAN.</dd>
<t hangText="ICN LoWPAN:">Dispatches as defined in <xref <dt>ICN LoWPAN:</dt>
target="sec.ndn"/> and <xref target="sec.ccnx"/>.</t> <dd>Dispatches as defined in Sections <xref target="sec.ndn" format="c
ounter"/> and <xref target="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 <xref target="fig.ext.base"/>.</t> depicted in <xref target="fig.ext.base" format="default"/>.</t>
<figure anchor="fig.ext.base">
<figure anchor="fig.ext.base" <name>Base Format for Dispatch Extensions</name>
title="Base format for dispatch extensions."> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="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" style="hanging"> <dt>EXT: Extension</dt>
<t hangText="EXT: Extension"><list hangIndent="12" <dd>
style="hanging"> <dl newline="false" spacing="normal" indent="4">
<t hangText="0:">No other extension byte follows.</t> <dt>0:</dt>
<dd>No other extension byte follows.</dd>
<t hangText="1:">A further extension byte follows.</t> <dt>1:</dt>
</list></t> <dd>A further extension byte follows.</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
documents MUST follow the naming scheme <spanx style="verb">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 devices SHOULD use manifests to encode structured data in a between devices <bcp14>SHOULD</bcp14> use manifests to encode structur
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 <xref target="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 target="RFC4944"/> network layers. Therefore, <xref target="RFC4944" section="5.3" sectionF ormat="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 <xref target="RFC4944"/>.</t> fragmentation handling of <xref target="RFC4944" format="default"/>.</t>
<t>The fragmentation LoWPAN header can encapsulate other dispatch
<t>The Fragmentation LoWPAN header can encapsulate other dispatch headers. The order of dispatch types is defined in <xref target="RFC4944
headers. The order of dispatch types is defined in Section 5 of <xref " section="5" sectionFormat="of" format="default"/>. <xref target="fig.fr_first"
target="RFC4944"/>. <xref target="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 <xref target="fig.f
target="fig.fr_done"/>.</t> r_done" format="default"/>.</t>
<figure anchor="fig.fr_first">
<figure anchor="fig.fr_first" title="Fragmentation scheme"> <name>Fragmentation Scheme</name>
<artwork align="center"><![CDATA[ <artwork align="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>
<figure anchor="fig.fr_done">
<figure anchor="fig.fr_done" title="Reassembled ICN LoWPAN frame"> <name>Reassembled ICN LoWPAN Frame</name>
<artwork align="center"><![CDATA[ <artwork align="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) <xref target="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
as seamless as the conventional hop-wise as seamlessly as the conventional hop-wise
fragmentation. Experimental evaluations <xref fragmentation. However, experimental evaluations <xref target="SFR-ICNLO
target="SFR-ICNLOWPAN"/>, however, suggest that a more refined WPAN"
format="default"/> suggest that a more-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 for NDN"> <name>Space-Efficient Message Encoding for NDN</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 target="NDN-PACKET-SPEC"/>. Type and length that is described in <xref target="NDN-PACKET-SPEC" 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 style="verb">253</sp then that number is encoded into the actual Type or Length field. If
anx>, the number is greater or equals <tt>253</tt> and
then that number is encoded into the actual type or length field. If fits into 2 bytes, then the Type or Length field is set to <tt>253</tt>
the number is greater or equals <spanx style="verb">253</spanx> and and the number is encoded in the next
fits into 2 bytes, then the type or length field is set to <spanx
style="verb">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 the type number is greater than 2 bytes and fits into 4 bytes, then the Type
or length field is set to <spanx style="verb">254</spanx> and the or Length 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, the type or length field is set to <spanx For larger numbers, the Type or Length field is set to <tt>255</tt> and
style="verb">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 encode Type and
<t>In this specification, compressed NDN TLVs encode type and Length fields using self-delimiting numeric values (SDNVs)
length fields using self-delimiting numeric values (SDNVs) <xref target="RFC6256" format="default"/> commonly known from Delay-Tole
<xref target="RFC6256"/> commonly known from DTN 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 TLV Encoding Compared to SDNVs</name>
title="NDN TLV encoding compared to SDNVs."> <thead>
<ttcol align="left">Value</ttcol> <tr>
<ttcol align="left" width="35%">NDN TLV encoding</ttcol> <th align="left">Value</th>
<ttcol align="left" width="40%">SDNV encoding</ttcol> <th align="left">NDN TLV Encoding</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 0x3F 0xFF</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 0x40 0x00</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 0x00 0x00</c> <td align="left">0xFD 0x3F 0xFF</td>
<c>0x84 0x80 0x00</c> <td align="left">0xFF 0x7F</td>
</tr>
<c>2^21 - 1</c> <tr>
<c>0xFE 0x00 0x1F 0xFF 0xFF</c> <td align="left">2<sup>14</sup></td>
<c>0xFF 0xFF 0x7F</c> <td align="left">0xFD 0x40 0x00</td>
<td align="left">0x81 0x80 0x00</td>
<c>2^21</c> </tr>
<c>0xFE 0x00 0x20 0x00 0x00</c> <tr>
<c>0x81 0x80 0x80 0x00</c> <td align="left">2<sup>16</sup></td>
<td align="left">0xFE 0x00 0x01 0x00 0x00</td>
<c>2^28 - 1</c> <td align="left">0x84 0x80 0x00</td>
<c>0xFE 0x0F 0xFF 0xFF 0xFF</c> </tr>
<c>0xFF 0xFF 0xFF 0x7F</c> <tr>
<td align="left">2<sup>21</sup> - 1</td>
<c>2^28</c> <td align="left">0xFE 0x00 0x1F 0xFF 0xFF</td>
<c>0xFE 0x1F 0x00 0x00 0x00</c> <td align="left">0xFF 0xFF 0x7F</td>
<c>0x81 0x80 0x80 0x80 0x00</c> </tr>
<tr>
<c>2^32</c> <td align="left">2<sup>21</sup></td>
<c>0xFF 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00</c> <td align="left">0xFE 0x00 0x20 0x00 0x00</td>
<c>0x90 0x80 0x80 0x80 0x00</c> <td align="left">0x81 0x80 0x80 0x00</td>
</tr>
<c>2^35 - 1</c> <tr>
<c>0xFF 0x00 0x00 0x00 0x07 0xFF 0xFF 0xFF 0xFF</c> <td align="left">2<sup>28</sup> - 1</td>
<c>0xFF 0xFF 0xFF 0xFF 0x7F</c> <td align="left">0xFE 0x0F 0xFF 0xFF 0xFF</td>
<td align="left">0xFF 0xFF 0xFF 0x7F</td>
<c>2^35</c> </tr>
<c>0xFF 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00</c> <tr>
<c>0x81 0x80 0x80 0x80 0x80 0x00</c> <td align="left">2<sup>28</sup></td>
</texttable> <td align="left">0xFE 0x1F 0x00 0x00 0x00</td>
<td align="left">0x81 0x80 0x80 0x80 0x00</td>
</tr>
<tr>
<td align="left">2<sup>32</sup></td>
<td align="left">0xFF 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00</td>
<td align="left">0x90 0x80 0x80 0x80 0x00</td>
</tr>
<tr>
<td align="left">2<sup>35</sup> - 1</td>
<td align="left">0xFF 0x00 0x00 0x00 0x07 0xFF 0xFF 0xFF 0xFF</td>
<td align="left">0xFF 0xFF 0xFF 0xFF 0x7F</td>
</tr>
<tr>
<td align="left">2<sup>35</sup></td>
<td align="left">0xFF 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00</td>
<td align="left">0x81 0x80 0x80 0x80 0x80 0x00</td>
</tr>
</tbody>
</table>
<t> <t>
<xref target="tab.sdnvperformance"/> compares the required <xref target="tab.sdnvperformance" format="default"/> compares the req uired
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 TLV Compression"> <name>Name TLV Compression</name>
<t>This Name TLV compression encodes length fields of two consecutive <t>This Name TLV compression encodes Length 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 follo wing NameComponent TLV. The most significant nibble indicates the length of an immediately follo wing NameComponent TLV.
The least significant nibble denotes the length of a subsequent NameComp onent TLV. The least significant nibble denotes the length of a subsequent NameComp onent 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 last length field of an encoded NameComponent is either 0x00 for a n The last Length field of an encoded NameComponent is either 0x00 for a n
ame with an even number of components, ame with an even number of components
and 0xYF (Y > 0) if an odd number of components are present. and 0xYF (Y &gt; 0) if an odd number of components are present.
This process limits the length of a NameComponent TLV to 15 bytes, but a This process limits the length of a NameComponent TLV to 15 bytes but al
llows for an unlimited number of components. lows for an unlimited number of components.
An example for this encoding is presented in <xref target="fig.ndnshortn An example for this encoding is presented in <xref target="fig.ndnshortn
co"/>.</t> co" format="default"/>.</t>
<figure anchor="fig.ndnshortnco">
<figure anchor="fig.ndnshortnco" <name>Name TLV Compression for /HAW/Room/481/Humid/99</name>
title="Name TLV compression for /HAW/Room/481/Humid/99"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="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>
<section numbered="true" toc="default">
<section title="Interest Messages"> <name>Interest Messages</name>
<section title="Uncompressed Interest Messages"> <section numbered="true" toc="default">
<name>Uncompressed Interest Messages</name>
<t>An uncompressed Interest message uses the base dispatch format <t>An uncompressed Interest message uses the base dispatch format
(see <xref target="fig.disp.base"/>) and sets the C flag to (see <xref target="fig.disp.base" format="default"/>) and sets the C,
<spanx style="verb">0</spanx> and the P as well as the M P, and M
flag to <spanx style="verb">0</spanx> (<xref flags to <tt>0</tt> (<xref target="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 modifi cations.</t> The Interest message is handed to the NDN network stack without modifi cations.</t>
<figure anchor="fig.ndn.int.uncompr">
<figure anchor="fig.ndn.int.uncompr" <name>Dispatch Format for Uncompressed NDN Interest Messages</name>
title="Dispatch format for uncompressed NDN Interest messages" <artwork align="center" name="" type="" alt=""><![CDATA[
>
<artwork align="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>
<section numbered="true" toc="default">
<section title="Compressed Interest Messages"> <name>Compressed Interest Messages</name>
<t>The compressed Interest message uses the extended dispatch format <t>The compressed Interest message uses the extended dispatch format
(<xref target="fig.disp.base.compr"/>) and sets the C flag to <spanx s (<xref target="fig.disp.base.compr" format="default"/>) and sets the C
tyle="verb">1</spanx>, flag to
the P flag to <spanx style="verb">0</spanx> and the M flag to <spanx s <tt>1</tt> and the P and M flags 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 message MUST be sent following compression rules, then this message <bcp14>MUST</bcp14> be sent
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 such a HopLimit 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 style="numbers"> the following minimal rule set: </t>
<t>The <spanx style="verb">Type</spanx> field of the outermost <ol spacing="normal" type="1">
MessageType TLV is removed.</t> <li>The <tt>Type</tt> field of the outermost
MessageType TLV is removed.</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
ParametersSha256DigestComponent MAY appear at the end of the greater than 0. An ImplicitSha256DigestComponent or
name. In any other case, the message MUST 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 compressed Interest as illustrated in <li>The Nonce TLV and InterestLifetime TLV are moved to
<xref target="fig.ndn.int.newformat"/>. The the end of the compressed Interest, as illustrated in
InterestLifetime is encoded as described in <xref <xref target="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, HopLimit TLV and <li>The Type and Length fields of Nonce TLV, HopLimit TLV, and
InterestLifetime TLV are elided. The Nonce value has a length of InterestLifetime TLV are elided. The Nonce value has a length of
4 bytes and the HopLimit value has a length of 1 byte. The 4 bytes, and the HopLimit value has a length of 1 byte. The
compressed InterestLifetime (<xref target="sec.compressedtime"/>) compressed InterestLifetime (<xref target="sec.compressedtime"
has a format="default"/>) has a
length of 1 byte. The presence of a Nonce and InterestLifetime TLV length of 1 byte. The presence of a Nonce TLV and InterestLifetime T
is LV is
deduced from the remaining length to parse. deduced from the remaining length to parse.
A remaining length of <spanx style="verb">1</spanx> indicates the A remaining length of <tt>1</tt> indicates the
presence of an InerestLifetime, a length of <spanx style="verb">4< presence of an InterestLifetime, 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 style="verb">5</sp the presence of both TLVs.</li>
anx> indicates </ol>
the presence of both TLVs.</t> <t>The compressed NDN LoWPAN Interest message is visualized in <xref t
</list></t> arget="fig.ndn.int.newformat" format="default"/>.</t>
<figure anchor="fig.ndn.int.newformat">
<t>The compressed NDN LoWPAN Interest message is visualized in <xref <name>Compression of NDN LoWPAN Interest Message</name>
target="fig.ndn.int.newformat"/>.</t> <artwork align="center" name="" type="" alt=""><![CDATA[
<figure anchor="fig.ndn.int.newformat"
title="Compression of NDN LoWPAN Interest Message">
<artwork align="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 <xref target="fig.ndn.intcompr"/>.</t> in <xref target="fig.ndn.intcompr" format="default"/>.</t>
<figure anchor="fig.ndn.intcompr">
<figure anchor="fig.ndn.intcompr" <name>Dispatch Format for Compressed NDN Interest Messages</name>
title="Dispatch format for compressed NDN Interest messages"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="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" style="hanging"> <dt>PFX: CanBePrefix TLV</dt>
<t hangText="CID: Context Identifier">See <xref <dd>
target="fig.disp.base.compr"/>.</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
style="hanging"> CanBePrefix TLV.</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 style="verb">EXT_0</spa
nx>
follows immediately. See <xref
target="sec.ndn.interest.ext0"/>.</t>
</list></t>
<t hangText="PFX: CanBePrefix TLV"><list hangIndent="12"
style="hanging">
<t hangText="0:">The uncompressed message does not include a
CanBePrefix TLV.</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: MustBeFresh TLV"><list hangIndent="12" <dt>FRE: MustBeFresh TLV</dt>
style="hanging"> <dd>
<t hangText="0:">The uncompressed message does not include a <dl newline="false" spacing="normal" indent="4">
MustBeFresh TLV.</t> <dt>0:</dt>
<dd>The uncompressed message does not include a
<t hangText="1:">The uncompressed message does include a MustBeFresh TLV.</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: ForwardingHint TLV"><list hangIndent="12" <dt>FWD: ForwardingHint TLV</dt>
style="hanging"> <dd>
<t hangText="0:">The uncompressed message does not include a <dl newline="false" spacing="normal" indent="4">
ForwardingHint TLV.</t> <dt>0:</dt>
<dd>The uncompressed message does not include a
<t hangText="1:">The uncompressed message does include a ForwardingHint TLV.</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 <xref target="sec.ndn.namecompression"
target="sec.ndn.namecompression"/>. If any name is not format="default"/>. If any name is not
compressible, the message MUST be sent uncompressed.</t> compressible, the message <bcp14>MUST</bcp14> be sent uncompre
</list></t> ssed.</dd>
</dl>
<t hangText="APM: ApplicationParameters TLV"><list </dd>
hangIndent="12" style="hanging"> <dt>APM: ApplicationParameters TLV</dt>
<t hangText="0:">The uncompressed message does not include <dd>
an ApplicationParameters TLV.</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 ApplicationParameters TLV.</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 compressed message.</t> the compressed message.</dd>
</list></t> </dl>
</dd>
<t hangText="DIG: ImplicitSha256DigestComponent TLV"><list <dt>DIG: ImplicitSha256DigestComponent TLV</dt>
hangIndent="12" style="hanging"> <dd>
<t hangText="0:">The name does not include an <dl newline="false" spacing="normal" indent="4">
ImplicitSha256DigestComponent as the last TLV.</t> <dt>0:</dt>
<dd>The name does not include an
<t hangText="1:">The name does include an ImplicitSha256DigestComponent as the last TLV.</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 are omitted.</t> Length fields are omitted.</dd>
</list></t> </dl>
</dd>
<t hangText="RSV: Reserved">Must be set to 0.</t> <dt>RSV: Reserved</dt>
<dd>Must be set to 0.</dd>
</list></t> <dt>CID: Context Identifier</dt>
<dd>See <xref target="fig.disp.base.compr" 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 target="sec.ndn.interest.ext0"
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 style="verb">EXT_0</spanx> byte follows the <t>The <tt>EXT_0</tt> byte follows the
description in <xref target="sec.dispatch.ext"/> and is illustrated description in <xref target="sec.dispatch.ext" format="default"/> and
in <xref target="fig.ndn.interest.ext0"/>.</t> is illustrated
in <xref target="fig.ndn.interest.ext0" format="default"/>.</t>
<figure anchor="fig.ndn.interest.ext0" title="EXT_0 format"> <figure anchor="fig.ndn.interest.ext0">
<artwork align="center"><![CDATA[ <name>EXT_0 Format</name>
<artwork align="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" style="hanging"> <dt>NCS: Name Compression Strategy</dt>
<t hangText="NCS: Name Compression Strategy"><list <dd>
hangIndent="12" style="hanging"> <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 <xref target="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 to 0.</t> </dd>
<dt>RSV: Reserved</dt>
<t hangText="EXT: Extension"><list hangIndent="8" <dd>Must be set to 0.</dd>
style="hanging"> <dt>EXT: Extension</dt>
<t hangText="0:">No extension byte follows.</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 byte follows.</dd>
</list></t> <dt>1:</dt>
</list></t> <dd>A further extension byte follows
immediately.</dd>
</dl>
</dd>
</dl>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Data Messages"> <name>Data Messages</name>
<section title="Uncompressed Data Messages"> <section numbered="true" toc="default">
<name>Uncompressed Data Messages</name>
<t>An uncompressed Data message uses the base dispatch <t>An uncompressed Data message uses the base dispatch
format and sets the C flag to <spanx style="verb">0</spanx>, format and sets the C and P flags to <tt>0</tt> and the M flag
the P flag to <spanx style="verb">0</spanx> and the M flag to <tt>1</tt> (<xref target="fig.ndn.data.uncompr" format="default"/>)
to <spanx style="verb">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>
<figure anchor="fig.ndn.data.uncompr">
<figure anchor="fig.ndn.data.uncompr" <name>Dispatch Format for Uncompressed NDN Data Messages</name>
title="Dispatch format for uncompressed NDN Data messages"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="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>
<section numbered="true" toc="default">
<section title="Compressed Data Messages"> <name>Compressed Data Messages</name>
<t>The compressed Data message uses the extended dispatch <t>The compressed Data message uses the extended dispatch
format (<xref target="fig.disp.base.compr"/>) and sets the C format (<xref target="fig.disp.base.compr" format="default"/>) and set
as well as the M flags to <spanx style="verb">1</spanx>. The s the C
P flag is set to <spanx style="verb">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 message MUST be sent following compression rules, then this message <bcp14>MUST</bcp14> be sent
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 style="numbers"> base rule set: </t>
<t>The <spanx style="verb">Type</spanx> field of the outermost <ol spacing="normal" type="1">
MessageType TLV is removed.</t> <li>The <tt>Type</tt> field of the outermost
MessageType TLV is removed.</li>
<t>The Name TLV is compressed according to <xref <li>The Name TLV is compressed according to <xref target="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 message MUST be length greater than 0. In any other case, the message <bcp14>MUST<
sent uncompressed.</t> /bcp14> be
sent uncompressed.</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 Data message.</t> compressed Data message.</li>
<li>The FreshnessPeriod TLV <bcp14>MUST</bcp14> be moved to the end
<t>The FreshnessPeriod TLV MUST be moved to the end of the of the
compressed Data message. Type and compressed Data message. Type and
Length fields are elided and the value is encoded as described Length fields are elided, and the value is encoded as described
in <xref target="sec.compressedtime"/> as a 1-byte time-code. If t in <xref target="sec.compressedtime" format="default"/> as a 1-byt
he freshness period is not e
a valid time-value, then the message MUST be sent uncompressed time-code. If the freshness period is not
a valid time-value, then the message <bcp14>MUST</bcp14> be sent u
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
remaining one byte length to parse.</t> remaining one-byte length to parse.</li>
<li>The Type fields of the SignatureInfo TLV, SignatureType TLV,
<t>The Type fields of the SignatureInfo TLV, SignatureType TLV and SignatureValue TLV are removed.</li>
and SignatureValue TLV are removed.</t> </ol>
</list></t> <t>The compressed NDN LoWPAN Data message is visualized in <xref targe
t="fig.ndn.data.newformat" format="default"/>.</t>
<t>The compressed NDN LoWPAN Data message is visualized in <xref <figure anchor="fig.ndn.data.newformat">
target="fig.ndn.data.newformat"/>.</t> <name>Compression of NDN LoWPAN Data Message</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
<figure anchor="fig.ndn.data.newformat"
title="Compression of NDN LoWPAN Data Message">
<artwork align="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 <xref target="fig.ndn.datacompr"/>.</t> in <xref target="fig.ndn.datacompr" format="default"/>.</t>
<figure anchor="fig.ndn.datacompr">
<figure anchor="fig.ndn.datacompr" <name>Dispatch Format for Compressed NDN Data Messages</name>
title="Dispatch format for compressed NDN Data messages"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="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" style="hanging"> <dt>FBI: FinalBlockId TLV</dt>
<t hangText="CID: Context Identifier">See <xref <dd>
target="fig.disp.base.compr"/>.</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
style="hanging"> FinalBlockId TLV.</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 style="verb">EXT_0</spa FinalBlockId, and it is encoded according to <xref
nx> target="sec.ndn.namecompression" format="default"/>. If the Fin
follows immediately. See <xref alBlockId
target="sec.ndn.data.ext0"/>.</t> TLV is not compressible, then the message <bcp14>MUST</bcp14> b
</list></t> e sent
uncompressed.</dd>
<t hangText="FBI: FinalBlockId TLV"><list hangIndent="12" </dl>
style="hanging"> </dd>
<t hangText="0:">The uncompressed message does not include a <dt>CON: ContentType TLV</dt>
FinalBlockId TLV.</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 the FinalBlockId TLV ContentType TLV.</dd>
is not compressible, then the message MUST be sent <dt>1:</dt>
uncompressed.</t> <dd>The uncompressed message does include a
</list></t>
<t hangText="CON: ContentType TLV"><list hangIndent="12"
style="hanging">
<t hangText="0:">The uncompressed message does not include a
ContentType TLV.</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
compressed message.</t> compressed message.</dd>
</list></t> </dl>
</dd>
<t hangText="KLO: KeyLocator TLV"><list hangIndent="12" <dt>KLO: KeyLocator TLV</dt>
style="hanging"> <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 message MUST be sent name is not compressible, then the message
uncompressed.</t> <bcp14>MUST</bcp14> be sent uncompressed.</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 is removed.</t> The Type field of this KeyDigest is removed.</dd>
</list></t> </dl>
</dd>
<dt>RSV: Reserved</dt>
<dd>Must be set to 0.</dd>
<dt>CID: Context Identifier</dt>
<dd>See <xref target="fig.disp.base.compr" 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 target="sec.ndn.data.ext0"
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 style="verb">EXT_0</spanx> byte follows the <t>The <tt>EXT_0</tt> byte follows the
description in <xref target="sec.dispatch.ext"/> and is illustrated description in <xref target="sec.dispatch.ext" format="default"/> and
in <xref target="fig.ndn.data.ext0"/>.</t> is illustrated
in <xref target="fig.ndn.data.ext0" format="default"/>.</t>
<figure anchor="fig.ndn.data.ext0" title="EXT_0 format"> <figure anchor="fig.ndn.data.ext0">
<artwork align="center"><![CDATA[ <name>EXT_0 Format</name>
<artwork align="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" style="hanging"> <dt>NCS: Name Compression Strategy</dt>
<t hangText="NCS: Name Compression Strategy"><list <dd>
hangIndent="12" style="hanging"> <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 <xref target="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 to 0.</t> </dd>
<dt>RSV: Reserved</dt>
<t hangText="EXT: Extension"><list hangIndent="8" <dd>Must be set to 0.</dd>
style="hanging"> <dt>EXT: Extension</dt>
<t hangText="0:">No extension byte follows.</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 byte follows.</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 for CCNx</name>
title="Space-efficient Message Encoding for CCNx"> <section numbered="true" toc="default">
<section title="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 <xref target="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 more space-efficie
<t>The TLV encoding for CCNx LoWPAN is changed to the more space nt
efficient encoding described in <xref target="sec.tlvencoding"/>. encoding described in <xref target="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>
<section numbered="true" toc="default">
<section title="Name TLV Compression"> <name>Name TLV Compression</name>
<t>Name TLVs are compressed using the scheme already defined in <xref <t>Name TLVs are compressed using the scheme already defined in <xref ta
target="sec.ndn.namecompression"/> for NDN. If a Name TLV contains rget="sec.ndn.namecompression" format="default"/> for NDN. If a Name TLV contain
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>
<section numbered="true" toc="default">
<section title="Interest Messages"> <name>Interest Messages</name>
<section title="Uncompressed Interest Messages"> <section numbered="true" toc="default">
<name>Uncompressed Interest Messages</name>
<t>An uncompressed Interest message uses the base dispatch format <t>An uncompressed Interest message uses the base dispatch format
(see <xref target="fig.disp.base"/>) and sets the C as well as the M f (see <xref target="fig.disp.base" format="default"/>) and sets the C a
lag to <spanx style="verb">0</spanx>. nd M flags to <tt>0</tt>.
The P flag is set to <spanx style="verb">1</spanx> (<xref target="fig. The P flag is set to <tt>1</tt> (<xref target="fig.ccnx.int.uncompr" f
ccnx.int.uncompr"/>). ormat="default"/>).
The Interest message is handed to the CCNx network stack without modif ications.</t> The Interest message is handed to the CCNx network stack without modif ications.</t>
<figure anchor="fig.ccnx.int.uncompr">
<figure anchor="fig.ccnx.int.uncompr" <name>Dispatch Format for Uncompressed CCNx Interest Messages</name>
title="Dispatch format for uncompressed CCNx Interest messages <artwork align="center" name="" type="" alt=""><![CDATA[
">
<artwork align="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 Interest Messages"> <name>Compressed Interest Messages</name>
<t>The compressed Interest message uses the extended dispatch format <t>The compressed Interest message uses the extended dispatch format
(<xref target="fig.disp.base.compr"/>) and sets the C and P flags to < (<xref target="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>.
style="verb">1</spanx>. The M flag is set to <spanx style="verb">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 message MUST be sent following compression rules, then this message <bcp14>MUST</bcp14> be sent
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 style="numbers"> 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 the Fixed Header on decompression.</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 the fixed header on decompression.</li>
</ol>
<t>The compressed CCNx LoWPAN Interest message is visualized in <t>The compressed CCNx LoWPAN Interest message is visualized in
<xref target="fig.ccnx.int.newformat"/>.</t> <xref target="fig.ccnx.int.newformat" format="default"/>.</t>
<figure anchor="fig.ccnx.int.newformat">
<figure anchor="fig.ccnx.int.newformat" <name>Compression of CCNx LoWPAN Interest Message</name>
title="Compression of CCNx LoWPAN Interest Message"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="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 <xref target="fig.ccnx.intcompr"/>.</t> in <xref target="fig.ccnx.intcompr" format="default"/>.</t>
<figure anchor="fig.ccnx.intcompr">
<figure anchor="fig.ccnx.intcompr" <name>Dispatch Format for Compressed CCNx Interest Messages</name>
title="Dispatch format for compressed CCNx Interest messages"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="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" style="hanging"> <dt>FLG: Flags field in the fixed header</dt>
<t hangText="CID: Context Identifier">See <xref <dd>
target="fig.disp.base.compr"/>.</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
style="hanging"> from the Interest message.</dd>
<t hangText="0:">No extension byte follows.</t> <dt>1:</dt>
<dd>The Flags field appears in the fixed header.</dd>
<t hangText="1:">Extension byte <spanx style="verb">EXT_0</spa </dl>
nx> </dd>
follows immediately. See <xref <dt>PTY: PacketType field in the fixed header</dt>
target="sec.ccnx.interest.ext0"/>.</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" style="hanging"> <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 fixed header</dt>
</list></t> <dd>
<dl newline="false" spacing="normal" indent="4">
<t hangText="FLG: Flags field in the fixed header"><list <dt>0:</dt>
hangIndent="8" style="hanging"> <dd>The HopLimit field appears in the fixed header.</dd>
<t hangText="0:">The Flags field equals 0 and is removed <dt>1:</dt>
from the Interest message.</t> <dd>The HopLimit field is elided and assumed to
be <tt>1</tt>.</dd>
<t hangText="1:">The Flags field appears in the fixed header.< </dl>
/t> </dd>
</list></t> <dt>FRS: Reserved field in the fixed header</dt>
<dd>
<t hangText="PTY: PacketType field in the fixed header"><list <dl newline="false" spacing="normal" indent="4">
hangIndent="8" style="hanging"> <dt>0:</dt>
<t hangText="0:">The PacketType field is elided and assumed <dd>The Reserved field appears in the fixed header.</dd>
to be <spanx style="verb">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 style="verb">PT_RETURN</spanx>.</t> </dl>
</list></t> </dd>
<dt>PAY: Optional Payload TLV</dt>
<t hangText="HPL: HopLimit field in the fixed header"><list <dd>
hangIndent="8" style="hanging"> <dl newline="false" spacing="normal" indent="4">
<t hangText="0:">The HopLimit field appears in the fixed heade <dt>0:</dt>
r.</t> <dd>The Payload TLV is absent.</dd>
<dt>1:</dt>
<t hangText="1:">The HopLimit field is elided and assumed to <dd>The Payload TLV is present, and the Type
be <spanx style="verb">1</spanx>.</t> field is elided.</dd>
</list></t> </dl>
</dd>
<t hangText="FRS: Reserved field in the fixed header"><list <dt>ILT: Optional hop-by-hop InterestLifetime TLV</dt>
hangIndent="8" style="hanging"> <dd>
<t hangText="0:">The Reserved field appears in the fixed heade <t>See <xref target="sec.ccnxhbhint" format="default"/> for further
r.</t> details
<t hangText="1:">The Reserved field is elided and assumed to
be <spanx style="verb">0</spanx>.</t>
</list></t>
<t hangText="PAY: Optional Payload TLV"><list hangIndent="8"
style="hanging">
<t hangText="0:">The Payload TLV is absent.</t>
<t hangText="1:">The Payload TLV is present and the type
field is elided.</t>
</list></t>
<t
hangText="ILT: Optional Hop-By-Hop InterestLifetime TLV"><list
hangIndent="8" style="hanging">
<t>See <xref target="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>
Interest message.</t> <dd>No InterestLifetime TLV is present in the
Interest message.</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 <xref target="sec.compressedtime" format="default
target="sec.compressedtime"/>. The type "/>. The
and length fields are elided.</t> Type and Length fields are elided.</dd>
</list></t> </dl>
</dd>
<t hangText="MGH: Optional Hop-By-Hop MessageHash TLV"><list <dt>MGH: Optional hop-by-hop MessageHash TLV</dt>
hangIndent="8" style="hanging"> <dd>
<t>See <xref target="sec.ccnxhbhint"/> for further details <t>See <xref target="sec.ccnxhbhint" format="default"/> for furt
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 Interest MUST 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 is absent.</t> <dt>0:</dt>
<dd>The MessageHash TLV is absent.</dd>
<t hangText="1:">A T_SHA-256 TLV is present and the type as <dt>1:</dt>
well as the length fields are removed. The length field is <dd>A T_SHA-256 TLV is present, and the Type and
Length fields are removed. The Length field is
assumed to represent 32 bytes. The outer Message Hash TLV assumed to represent 32 bytes. The outer Message Hash TLV
is omitted.</t> is omitted.</dd>
</list></t> </dl>
</dd>
<t hangText="KIR: Optional KeyIdRestriction TLV"><list <dt>KIR: Optional KeyIdRestriction TLV</dt>
hangIndent="8" style="hanging"> <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 Interest MUST 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 is absent.</t> <dt>0:</dt>
<dd>The KeyIdRestriction TLV is absent.</dd>
<t hangText="1:">A T_SHA-256 TLV is present and the type as <dt>1:</dt>
well as the length fields are removed. The length field is <dd>A T_SHA-256 TLV is present, and the Type and
Length fields are removed. The Length field is
assumed to represent 32 bytes. The outer KeyIdRestriction assumed to represent 32 bytes. The outer KeyIdRestriction
TLV is omitted.</t> TLV is omitted.</dd>
</list></t> </dl>
</dd>
<t <dt>CHR: Optional ContentObjectHashRestriction TLV</dt>
hangText="CHR: Optional ContentObjectHashRestriction TLV"><list <dd>
hangIndent="8" style="hanging"> <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 Interest MUST 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 target="sec.ccnx.intval"
format="default"/>.</dd>
</dl>
</dd>
<dt>CID: Context Identifier</dt>
<dd><t>See <xref target="fig.disp.base.compr"
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 target="sec.ccnx.interest.ext0"
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 the type as <t>Hop-by-hop header TLVs are unordered. For an Interest message,
well as the length fields are removed. The length field is two optional hop-by-hop header TLVs are defined in <xref
assumed to represent 32 bytes. The outer target="RFC8609"
ContentObjectHashRestriction TLV is omitted.</t> format="default"/>, but several more can be defined in higher-level
</list></t> 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>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 and 6.4.2.1):
hangText="VAL: Optional ValidationAlgorithm and ValidationPayload Note: Other hop-by-hop header TLVs than those two remain uncompressed
TLVs"><list in the encoded message, and they appear in the same order as in the
hangIndent="8" style="hanging"> original message but after the InterestLifetime TLV and Message Hash
<t hangText="0:">No validation related TLVs are present in TLV.
the Interest 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 target="sec.ccnx.intval"/>.</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 TLVs Compression" toc="exclude"> Note: All hop-by-hop header TLVs other than the InterestLifetime and
<t>Hop-By-Hop Header TLVs are unordered. For an Interest message, MessageHash TLVs remain uncompressed in the encoded message, and they
two optional Hop-By-Hop Header TLVs are defined in <xref appear after the InterestLifetime and MessageHash TLVs in the same
target="RFC8609"/>, but several more can be defined in higher order as in the original message.
level specifications. For the compression specified in the
previous section, the Hop-By-Hop TLVs are ordered as follows:
<list style="numbers">
<t>Interest Lifetime TLV</t>
<t>Message Hash TLV</t> ...
</list></t>
<t>Note: Other Hop-By-Hop Header TLVs than those two remain Note: All hop-by-hop header TLVs other than the RecommendedCacheTime
uncompressed in the encoded message and they appear in the and MessageHash TLVs remain uncompressed in the encoded message, and
same order as in the original message, but after the Interest 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: 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 InterestLifetime
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>
<figure anchor="fig.ccnx.dispatchintval" <figure anchor="fig.ccnx.dispatchintval">
title="Dispatch for Interset Validations"> <name>Dispatch for Interest Validations</name>
<artwork align="center"><![CDATA[ <artwork align="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" style="hanging"> <dt>ValidationAlg: Optional ValidationAlgorithm TLV</dt>
<t <dd>
hangText="ValidationALg: Optional ValidationAlgorithm TLV"><list <dl newline="false" spacing="normal" indent="8">
hangIndent="8" style="hanging"> <dt>0000:</dt>
<t hangText="0000:">An uncompressed ValidationAlgorithm <dd>An uncompressed ValidationAlgorithm
TLV is included.</t> TLV is included.</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 is included.</t> assumed, but no ValidationAlgorithm TLV is included.</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 a type and Additionally, a Sigtime TLV is inlined without a Type and
a length field.</t> a Length 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 a type and Additionally, a Sigtime TLV is inlined without a Type and
a length field.</t> a Length 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 the ValidationAlgorithm TLV</
hangText="KeyID: Optional KeyID TLV within the ValidationAlgorit dt>
hm TLV"><list <dd>
hangIndent="8" style="hanging"> <dl newline="false" spacing="normal" indent="4">
<t hangText="00:">The KeyId TLV is absent.</t> <dt>00:</dt>
<dd>The KeyID TLV is absent.</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 is present and the type <dt>10:</dt>
field as well as the length fields are removed. The length <dd>A T_SHA-256 TLV is present, and the Type
field is assumed to represent 32 bytes. The outer KeyId and Length fields are removed. The Length
TLV is omitted.</t> field is assumed to represent 32 bytes. The outer KeyID
TLV is omitted.</dd>
<t hangText="11:">A T_SHA-512 TLV is present and the type <dt>11:</dt>
field as well as the length fields are removed. The length <dd>A T_SHA-512 TLV is present, and the Type
field is assumed to represent 64 bytes. The outer KeyId and Length fields are removed. The Length
TLV is omitted.</t> field is assumed to represent 64 bytes. The outer KeyID
</list></t> TLV is omitted.</dd>
</dl>
<t hangText="RSV: Reserved">Must be set to 0.</t> </dd>
<dt>RSV: Reserved</dt>
</list></t> <dd>Must be set to 0.</dd>
</dl>
<t>The ValidationPayload TLV is present if the ValidationAlgorithm <t>The ValidationPayload TLV is present if the ValidationAlgorithm
TLV is present. The type field is omitted.</t> TLV is present. The Type 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 style="verb">EXT_0</spanx> byte follows the <t>The <tt>EXT_0</tt> byte follows the
description in <xref target="sec.dispatch.ext"/> and is illustrated description in <xref target="sec.dispatch.ext" format="default"/> and
in <xref target="fig.ccnx.interest.ext0"/>.</t> is illustrated
in <xref target="fig.ccnx.interest.ext0" format="default"/>.</t>
<figure anchor="fig.ccnx.interest.ext0" title="EXT_0 format"> <figure anchor="fig.ccnx.interest.ext0">
<artwork align="center"><![CDATA[ <name>EXT_0 Format</name>
<artwork align="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" style="hanging"> <dt>NCS: Name Compression Strategy</dt>
<t hangText="NCS: Name Compression Strategy"><list <dd>
hangIndent="12" style="hanging"> <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 <xref target="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 to 0.</t> </dd>
<dt>RSV: Reserved</dt>
<t hangText="EXT: Extension"><list hangIndent="8" <dd>Must be set to 0.</dd>
style="hanging"> <dt>EXT: Extension</dt>
<t hangText="0:">No extension byte follows.</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 byte follows.</dd>
</list></t> <dt>1:</dt>
</list></t> <dd>A further extension byte follows
immediately.</dd>
</dl>
</dd>
</dl>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Content Objects"> <name>Content Objects</name>
<section title="Uncompressed Content Objects"> <section numbered="true" toc="default">
<t>An uncompressed Content object uses the base dispatch format (see <name>Uncompressed Content Objects</name>
<xref target="fig.disp.base"/>) and sets the C flag to <spanx style="v <t>An uncompressed Content Object uses the base dispatch format (see
erb">0</spanx>, the P and M flags to <xref target="fig.disp.base" format="default"/>) and sets the C flag t
<spanx style="verb">1</spanx> (<xref target="fig.ccnx.data.uncompr"/>) o
. <tt>0</tt> and the P and M flags to
The Content object is handed to the CCNx network stack without modific <tt>1</tt> (<xref target="fig.ccnx.data.uncompr" format="default"/>).
ations.</t> The Content Object is handed to the CCNx network stack without modific
ations.</t>
<figure anchor="fig.ccnx.data.uncompr" <figure anchor="fig.ccnx.data.uncompr">
title="Dispatch format for uncompressed CCNx Content objects"> <name>Dispatch Format for Uncompressed CCNx Content Objects</name>
<artwork align="center"><![CDATA[ <artwork align="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>
<section numbered="true" toc="default">
<section title="Compressed Content Objects"> <name>Compressed Content Objects</name>
<t>The compressed Content object uses the extended dispatch format <t>The compressed Content Object uses the extended dispatch format
(<xref target="fig.disp.base.compr"/>) and sets the C, P, as well as t (<xref target="fig.disp.base.compr" format="default"/>) and sets the C
he M flag to <spanx style="verb">1</spanx>. , P, and M
If a Content object contains TLVs that are not mentioned in the follow flags to <tt>1</tt>. If a Content Object contains TLVs that are not men
ing compression tioned in
rules, then this message MUST be sent uncompressed.</t> the following compression
rules, then this message <bcp14>MUST</bcp14> be sent uncompressed.</t>
<t>By default, the Content object is compressed with the following <t>By default, the Content Object is compressed with the following
base rule set: <list style="numbers"> base rule set: </t>
<t>The PacketType field is elided from the Fixed 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 the Fixed Header on decompression.</t> <li>The PacketType field is elided from the fixed header.</li>
</list></t> <li>The Type and Length fields of the CCNx Message TLV are elided
and are obtained from the fixed header on decompression.</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 <xref targ
et="fig.ccnx.data.newformat" format="default"/>.</t>
<figure anchor="fig.ccnx.data.newformat" <figure anchor="fig.ccnx.data.newformat">
title="Compression of CCNx LoWPAN Data Message"> <name>Compression of CCNx LoWPAN Data Message</name>
<artwork align="center"><![CDATA[ <artwork align="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 <xref target="fig.ccnx.datacompr"/>.</t> in <xref target="fig.ccnx.datacompr" format="default"/>.</t>
<figure anchor="fig.ccnx.datacompr">
<figure anchor="fig.ccnx.datacompr" <name>Dispatch Format for Compressed CCNx Content Objects</name>
title="Dispatch format for compressed CCNx Content objects"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="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" style="hanging"> <dt>FLG: Flags field in the fixed header</dt>
<t hangText="CID: Context Identifier">See <xref <dd>See <xref target="sec.ccnxintcompbaseheader"
target="fig.disp.base.compr"/>.</t> format="default"/>.</dd>
<dt>FRS: Reserved field in the fixed header</dt>
<t hangText="EXT: Extension"><list hangIndent="8" <dd>See <xref target="sec.ccnxintcompbaseheader"
style="hanging"> format="default"/>.</dd>
<t hangText="0:">No extension byte follows.</t> <dt>PAY: Optional Payload TLV</dt>
<dd>See <xref target="sec.ccnxintcompbaseheader"
<t hangText="1:">Extension byte <spanx style="verb">EXT_0</spa format="default"/>.</dd>
nx> <dt>RCT: Optional hop-by-hop Recommended Cache Time TLV</dt>
follows immediately. See <xref <dd>
target="sec.ccnx.data.ext0"/>.</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" style="hanging"> <dd>The Recommended Cache Time TLV is present,
<t hangText="0:">The Version field equals 1 and is removed and the Type and Length fields are elided.</dd>
from the fixed header.</t> </dl>
</dd>
<t hangText="1:">The Version field appears in the fixed header <dt>MGH: Optional hop-by-hop MessageHash TLV</dt>
.</t> <dd>
</list></t> <t>See <xref target="sec.ccnxhbhdata" format="default"/> for
further details on the ordering of hop-by-hop TLVs.</t>
<t hangText="FLG: Flags field in the fixed header">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 fixed header">See <xref <dl newline="false" spacing="normal" indent="4">
target="sec.ccnxintcompbaseheader"/>.</t> <dt>0:</dt>
<dd>The MessageHash TLV is absent.</dd>
<t hangText="PAY: Optional Payload TLV">See <xref <dt>1:</dt>
target="sec.ccnxintcompbaseheader"/>.</t> <dd>A T_SHA-256 TLV is present, and the Type and
Length fields are removed. The Length field is
<t
hangText="RCT: Optional Hop-By-Hop RecommendedCacheTime TLV"><list
hangIndent="8" style="hanging">
<t hangText="0:">The Recommended Cache Time TLV is
absent.</t>
<t hangText="1:">The Recommended Cache Time TLV is present
and the type as well as the length fields are elided.</t>
</list></t>
<t hangText="MGH: Optional Hop-By-Hop MessageHash TLV"><list
hangIndent="8" style="hanging">
<t>See <xref target="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 Object MUST be
sent uncompressed.</t>
<t hangText="0:">The MessageHash TLV is absent.</t>
<t hangText="1:">A T_SHA-256 TLV is present and the type as
well as the length fields are removed. The length field is
assumed to represent 32 bytes. The outer Message Hash TLV assumed to represent 32 bytes. The outer Message Hash TLV
is omitted.</t> is omitted.</dd>
</list></t> </dl>
</dd>
<t><list hangIndent="4" style="hanging"> <dt/>
<t hangText="PLTYP: Optional PayloadType TLV"><list <dd>
hangIndent="8" style="hanging"> <dl newline="true" spacing="normal" indent="4">
<t hangText="00:">The PayloadType TLV is absent.</t> <dt>PLTYP: Optional PayloadType TLV</dt>
<dd>
<t hangText="01:">The PayloadType TLV is absent and <dl newline="false" spacing="normal" indent="4">
T_PAYLOADTYPE_DATA is assumed.</t> <dt>00:</dt>
<dd>The PayloadType TLV is absent.</dd>
<t hangText="10:">The PayloadType TLV is absent and <dt>01:</dt>
T_PAYLOADTYPE_KEY is assumed.</t> <dd>The PayloadType TLV is absent, and
T_PAYLOADTYPE_DATA is assumed.</dd>
<t hangText="11:">The PayloadType TLV is present and <dt>10:</dt>
uncompressed.</t> <dd>The PayloadType TLV is absent, and
</list></t> T_PAYLOADTYPE_KEY is assumed.</dd>
</list></t> <dt>11:</dt>
<dd>The PayloadType TLV is present and
<t hangText="EXP: Optional ExpiryTime TLV"><list hangIndent="8" uncompressed.</dd>
style="hanging"> </dl>
<t hangText="0:">The ExpiryTime TLV is absent.</t> </dd>
</dl>
<t hangText="1:">The ExpiryTime TLV is present and the type </dd>
as well as the length fields are elided.</t> <dt>EXP: Optional ExpiryTime TLV</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 is absent.</dd>
TLVs">See <dt>1:</dt>
<xref target="sec.ccnxintcompbaseheader"/>.</t> <dd>The ExpiryTime TLV is present, and the Type
and Length fields are elided.</dd>
<t hangText="RSV: Reserved">Must be set to 0.</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"> <xref target="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 to 0.</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 <xref target="fig.disp.base.compr" format="default"/>.</dd>
previous section, the Hop-By-Hop TLVs are ordered as follows: <dt>EXT: Extension</dt>
<list style="numbers"> <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 target="sec.ccnx.data.ext0" for
mat="default"/>.</dd>
</dl>
</dd>
<t>Note: Other Hop-By-Hop Header TLVs than those two remain </dl>
uncompressed in the encoded message and they appear in the <section anchor="sec.ccnxhbhdata" toc="exclude" numbered="true">
same order as in the original message, but after the Recommended Cac <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 target="RFC8609" 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: 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 Cach
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 style="verb">EXT_0</spanx> byte follows the <t>The <tt>EXT_0</tt> byte follows the
description in <xref target="sec.dispatch.ext"/> and is illustrated description in <xref target="sec.dispatch.ext" format="default"/> and
in <xref target="fig.ccnx.data.ext0"/>.</t> is illustrated
in <xref target="fig.ccnx.data.ext0" format="default"/>.</t>
<figure anchor="fig.ccnx.data.ext0" title="EXT_0 format"> <figure anchor="fig.ccnx.data.ext0">
<artwork align="center"><![CDATA[ <name>EXT_0 Format</name>
<artwork align="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" style="hanging"> <dt>NCS: Name Compression Strategy</dt>
<t hangText="NCS: Name Compression Strategy"><list <dd>
hangIndent="12" style="hanging"> <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 <xref target="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 to 0.</t> </dd>
<dt>RSV: Reserved</dt>
<t hangText="EXT: Extension"><list hangIndent="8" <dd>Must be set to 0.</dd>
style="hanging"> <dt>EXT: Extension</dt>
<t hangText="0:">No extension byte follows.</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 byte follows.</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.compressedtime" numbered="true" toc="default">
<section title="Compressed Time Encoding" anchor="sec.compressedtime"> <name>Compressed Time Encoding</name>
<t> <t>
This document adopts the 8-bit compact time representation for This document adopts the 8-bit compact time representation for
relative time values described in Section 5 of <xref relative time-values described in <xref target="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
style="verb">C</spanx> set to <spanx style="verb">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 target="IEEE.754.2019"/> for time-codes with exponent <xref target="IEEE.754.2019" format="default"/> for time-codes with expo nent
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 style="hanging">
<t hangText="Subnormal (b == 0):"> (0 + a/8) * 2 * C
</t>
<t hangText="Normalized (b &gt; 0):"> (1 + a/8) * 2^b * C (see <xref t
arget="RFC5497"/>)
</t>
</list>
This configuration allows for the following ranges:
<list style="symbols">
<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 &gt; 0):</dt>
<dd> (1 + a/8) * 2<sup>b</sup> * C (see <xref target="RFC5497" 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-value MUST be set to the largest valid time-value that is time-value <bcp14>MUST</bcp14> be set to the largest valid time-value th at 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 Header Compression"> <name>Stateful Header Compression</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 in the context 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-hop bases and memorized in en-route state tables.</t> hop-by-hop basis 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>A context identifier (CID) is a byte that refers to a particular <name>LoWPAN-Local State</name>
conceptual context between network devices and MAY be used to replace <t>A Context Identifier (CID) is a byte that refers to a particular
conceptual context between network devices and <bcp14>MAY</bcp14> be use
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>
<figure anchor="fig.cid">
<figure anchor="fig.cid" title="Context Identifier."> <name>Context Identifier</name>
<artwork align="center"><![CDATA[ <artwork align="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 a locally scoped unique identifier that
<t>The 7-bit ContextID is a locally-scoped unique identifier that represents the contextual state shared between the sender and receiver o
represents contextual state shared between sender and receiver of the f the
corresponding frame (see <xref target="fig.cid"/>). corresponding frame (see <xref target="fig.cid" format="default"/>).
If set the most significant bit indicates the presence of another, subse If set, the most significant bit indicates the presence of another, subs
quent equent
ContextID byte (see <xref target="fig.cid.chain"/>).</t> ContextID byte (see <xref target="fig.cid.chain" format="default"/>).</t
>
<t>Context state shared between senders and receivers is removed from th <t>The context state shared between senders and receivers is removed fro
e m the
compressed packet prior to sending, and reinserted after reception compressed packet prior to sending 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 CIDs MUS T be silently discarded.</t> of scope of this document. Frames containing unknown or invalid CIDs <bc p14>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 in data messages. Returning Name TLVs either equal the they return in Data messages. Returning Name TLVs either equal the
original Name TLV, or they contain the original Name TLV as a prefix. original Name TLV 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 <xref target="stateful.compression.l carried as Context Identifiers (see <xref target="stateful.compression.l
ocal"/>) of link-local scope as shown in <xref ocal" format="default"/>) of link-local scope, as shown in <xref target="fig.hop
target="fig.hopid"/>.</t> id" format="default"/>.</t>
<figure anchor="fig.hopid">
<figure anchor="fig.hopid" title="Context Identifier as HopID."> <name>Context Identifier as HopID</name>
<artwork align="center"><![CDATA[ <artwork align="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 "repla cing 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 messages MUST be sent without en-route state exhausted, the messages <bcp14>MUST</bcp14> be sent without en-route sta te
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 ID bits 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 a PIT entry. Each HopID MUST be unique within HopID that is tied to a Pending 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 <xref targe
target="fig.enroute-a"/>). <figure anchor="fig.enroute-a" t="fig.enroute-a" format="default"/>). </t>
title="Setting compression state en-route (Interest)."> <figure anchor="fig.enroute-a">
<artwork align="center"><![CDATA[ <name>Setting Compression State En-Route (Interest)</name>
<artwork align="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 (<xref target="fig.enroute-b"/>). <figure the response (<xref target="fig.enroute-b" format="default"/>). </t>
anchor="fig.enroute-b" <figure anchor="fig.enroute-b">
title="Eliding Name TLVs using en-route state (data)."> <name>Eliding Name TLVs Using En-Route State (Data)</name>
<artwork align="center"><![CDATA[ <artwork align="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 node SHOULD 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>
<section numbered="true" toc="default">
<section title="Integrating Stateful Header Compression"> <name>Integrating Stateful Header Compression</name>
<t>A CID appears whenever the CID flag is set (see <xref <t>A CID appears whenever the CID flag is set (see <xref target="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 dispatch byte as shown in <xref target="fig.cid.loc"/>.</t> LoWPAN dispatch byte, as shown in <xref target="fig.cid.loc" format="def
ault"/>.</t>
<figure anchor="fig.cid.loc" <figure anchor="fig.cid.loc">
title="LoWPAN Encapsulation with ICN LoWPAN and CIDs"> <name>LoWPAN Encapsulation with ICN LoWPAN and CIDs</name>
<artwork align="center"><![CDATA[ <artwork align="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
target="fig.cid.chain"/>). This allows to use multiple shared contexts i indicating the presence of a subsequent CID (Figure 33). This allows
n compressed messages.</t> to use multiple shared contexts in compressed messages.
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 target="fig.cid.chain
" 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>
<figure anchor="fig.cid.chain">
<figure anchor="fig.cid.chain" <name>Chaining of Context Identifiers</name>
title="Chaining of context identifiers."> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="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 and Variables</name>
title="ICN LoWPAN Constants and Variables"> <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" style="hanging"> <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 and Guidance</name>
title="Implementation Report and Guidance"> <!-- [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 <xref target="CCN-LITE"/> in an extension of the NDN/CCNx software stack <xref target="CCN-LITE" format
its IoT version on RIOT <xref target="RIOT"/>. An experimental ="default"/> in
evaluation for NDN over ICN LOWPAN with varying configurations has been its IoT version on RIOT <xref target="RIOT" format="default"/>. An experim
performed in <xref target="ICNLOWPAN"/>. Energy profilings and ental
processing time measurements indicate significant energy savings, while evaluation for NDN over ICN LoWPAN with varying configurations has been
performed in <xref target="ICNLOWPAN" format="default"/>. Energy profilin
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>
<section numbered="true" toc="default">
<section title="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>
style="symbols"> <ul spacing="normal">
<li>Signed time offsets compress, per <xref target="sec.compressedtime
<t>Signed time offsets compress as per <xref "
target="sec.compressedtime"/> without the need for format="default"/>, without the need for rounding.</li>
rounding.</t> <li>The contextual state (e.g., prefixes) is distributed such that
long names can be elided from Interest and Data messages.</li>
<t>Contextual state (e.g., prefixes) is distributed, such that <li>Frequently used TLV type numbers for CCNx and NDN stay
long names can be elided from Interest and data messages.</t> in the lower range (&lt; 255).</li>
</ul>
<t>Frequently used TLV type numbers for CCNx and NDN stay <t>
in the lower range (&lt; 255).</t> Name components are of type GenericNameComponent and are limited to a
</list>
Name components are of GenericNameComponent 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>
<section numbered="true" toc="default">
<section title="Further Experimental Deployments"> <name>Further Experimental Deployments</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 style="symbols"> </t>
<t>The name compression scheme (<xref <ul spacing="normal">
target="sec.ndn.namecompression"/>) is optimized for short <li>The name compression scheme (<xref target="sec.ndn.namecompression
name components of GenericNameComponent type. An empirical " format="default"/>) is optimized for short
name components of type 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
(<xref target="sec.ndn.interest.ext0"/>). As a preliminary (<xref target="sec.ndn.interest.ext0" format="default"/>). As a prelim
analysis, <xref target="ICNLOWPAN"/> investigates the inary
analysis, <xref target="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 on CoAP <xref obtained from the WWW. Studies on deployments of Constrained Applicati
target="RFC7252"/> deployments can offer additional insights on Protocol (CoAP) <xref target="RFC7252" format="default"/> can offer additiona
on naming schemes in the IoT.</t> l insights
on naming schemes in the IoT.</li>
<t>The fragmentation scheme (<xref <li>The fragmentation scheme (<xref target="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 <xref target="RFC8930" format="default"/>
target="RFC8930"/> with selective with selective
fragment recovery <xref fragment recovery <xref target="RFC8931" format="default"/> can improv
target="RFC8931"/> can improve the e the
end-to-end latency and reliability, while it reduces buffer end-to-end latency and reliability while it reduces buffer
requirements on forwarders. Initial evaluations (<xref requirements on forwarders. Initial evaluations <xref target="SFR-ICNL
target="SFR-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 and data messages are reassembled end-to-end. More Interest and Data 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 (<xref target="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 protocol fields.</t> features is necessary to identify other protocol fields.</li>
<li>The distribution and synchronization of the contextual state
<t>The distribution and synchronization of contextual state can potentially be adopted from <xref target="RFC6775" section="7.2" s
can potentially be adopted from Section 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 (<xref target="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 the Pending 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 an upper-bound and determines whether the HopID can serve as an upper bound and determines whether the HopID
length needs to be resized to fit more HopIDs to the cost of length needs to be resized to fit more HopIDs at the cost of
additional header overhead.</t> additional header overhead.</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 illuminate on the 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 other implementations.</t> interoperability with other implementations.</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
<xref target="RFC8930"/> can potentially prevent fragment buffer saturatio <xref target="RFC8930" format="default"/> can potentially prevent fragment
n in forwarders.</t> buffer saturation 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 devi ces.</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 devic es.</t>
</section> </section>
<section anchor="iana" numbered="true" toc="default">
<section anchor="iana" title="IANA Considerations"> <name>IANA Considerations</name>
<section title="Reserving Space in the 6LoWPAN Dispatch Type Field Registr <section numbered="true" toc="default">
y"> <name>Updates to the 6LoWPAN Dispatch Type Field Registry</name>
<t>IANA has assigned dispatch values of the <spanx style="verb">6LoWPAN <t>IANA has assigned dispatch values for ICN LoWPAN in the "Dispatch Typ
Dispatch Type Field</spanx> e Field"
registry <xref target="RFC4944"/><xref target="RFC8025"/> with Page subregistry <xref target="RFC4944" format="default"/> <xref target="RFC8
TBD1 for ICN LoWPAN. <xref 025" format="default"/> of
target="tab.iana.dispatches"/> represents updates to the registry.</t> the "IPv6 Low Power Personal Area Network Parameters" registry.
<xref target="tab.iana.dispatches" format="default"/> represents the upd
<texttable anchor="tab.iana.dispatches" ates to the registry.</t>
title="Dispatch types for NDN and CCNx with page TBD1."> <table anchor="tab.iana.dispatches" align="center">
<ttcol align="center">Bit Pattern</ttcol> <name>Dispatch Types for NDN and CCNx Dispatch Types with Page 14</nam
e>
<ttcol align="center">Page</ttcol> <thead>
<tr>
<ttcol align="left">Header Type</ttcol> <th align="center">Bit Pattern</th>
<th align="center">Page</th>
<c>00 000000</c> <th align="left">Header Type</th>
<th align="left">Reference</th>
<c>TBD1</c> </tr>
</thead>
<c>Uncompressed NDN Interest messages</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 Interest messages</td>
<td align="left">RFC 9139</td>
<c>Uncompressed NDN Data 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 Interest messages</td>
<td align="left">RFC 9139</td>
<c>Uncompressed CCNx Interest messages</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 NDN Data 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 Data messages</td>
<td align="left">RFC 9139</td>
<c>Compressed NDN Interest 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 Data messages</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 Interest messages</td>
<td align="left">RFC 9139</td>
<c>Compressed CCNx Interest messages</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 Object messages</c> </tr>
</texttable> <tr>
<td align="center">01 11xxxx</td>
<td align="center">14</td>
<td align="left">Compressed CCNx Content Object messages</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 target="I-D.irtf-icnrg-flic" to="ICNRG-FLIC"/>
<reference anchor="ieee802.15.4"
target="https://standards.ieee.org/findstds/standard/802.15.4-2
015.html">
<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"
target="https://standards.ieee.org/content/ieee-standards/en/st
andard/754-2019.html">
<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" target="https://standards.ieee.org/find
stds/standard/802.15.4-2015.html">
<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" target="https://standards.ieee.org/con
tent/ieee-standards/en/standard/754-2019.html">
<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 i nfo -->
<?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 &amp; Design</organization>
</author>
<date month="November" day="4" year="2019"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-flic-02"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-irtf-icnrg-flic
-02.txt"/>
</reference>
<reference anchor="CCN-LITE" target="http://ccn-lite.net/"> <!-- [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" target="http://ccn-lite.net/">
</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 for Low-end Embedded <title>RIOT: An Open Source Operating System for Low-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>Information centric networking in the IoT: experiments with
<author initials="C." surname="Gundogan"> NDN in the wild</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-Centric Networking (
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>Information Centric Networking in the IoT: Experiments with
NDN in the Wild</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-Centric Networki
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>The need for a name to MAC address mapping in NDN: towards
<author initials="P." surname="Kietzmann"> quantifying the resource 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-Centric Networking (
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>The Need for a Name to MAC Address Mapping in NDN: Towards
Quantifying the Resource 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-Centric Networki
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>Networking named 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> <date month="December" year="2009"/>
</front>
<author initials="M." surname="Waehlisch"> <refcontent>5th Int. Conf. on emerging Networking Experiments and Tech
<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>Networking Named 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"
target="https://named-data.net/doc/NDN-packet-spec/0.3/">
<front>
<title>NDN Packet Format Specification</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="TLV-ENC-802.15.4"
target="https://datatracker.ietf.org/meeting/interim-2015-icnrg
-01/materials/slides-interim-2015-icnrg-1-2">
<front>
<title>CCN and NDN TLV encodings in 802.15.4 packets</title>
<author/> <reference anchor="NDN-PACKET-SPEC" target="https://named-data.net/doc/N
DN-packet-spec/0.3/">
<front>
<title>NDN Packet Format Specification</title>
<author/>
</front>
</reference>
<date/> <reference anchor="TLV-ENC-802.15.4" target="https://datatracker.ietf.or
</front> g/meeting/interim-2015-icnrg-01/materials/slides-interim-2015-icnrg-1-2">
</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. of 18th IFIP Networking Conference</refcontent>
</author> </reference>
</references>
<date month="May" year="2019"/>
</front>
<seriesInfo name="Proc. of 18th" value="IFIP Networking Conference"/>
</reference>
</references> </references>
<section anchor="sec.EstimatedSizeReduction" numbered="true" toc="default">
<section anchor="sec.EstimatedSizeReduction" <name>Estimated Size Reduction</name>
title="Estimated Size Reduction"> <t>In the following, a theoretical evaluation is given to estimate the
<t>In the following 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 style="verb">n</spanx> is the number of name components; <tt>comps_n</tt> denotes the sum of n
components, <spanx style="verb">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 style="verb">clen</spanx>. The lengths of TLV components is <tt>clen</tt>. The lengths of TLV components are
specific to the CCNx or NDN encoding and outlined below.</t> specific to the CCNx or NDN encoding and are outlined below.</t>
<section numbered="true" toc="default">
<section title="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,
the 1 byte form of each TLV component is assumed. A typical TLV the 1-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>
<section numbered="true" toc="default">
<section title="Interest"> <name>Interest</name>
<t><xref target="fig.Size.NDN.interest.uncompressed"/> depicts the <t><xref target="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
4 seconds and a HopLimit TLV set to 6. Numbers below represent the 4 seconds, and a HopLimit TLV set to 6. Numbers below represent the
amount of bytes.</t> amount of bytes.</t>
<figure anchor="fig.Size.NDN.interest.uncompressed">
<figure anchor="fig.Size.NDN.interest.uncompressed" <name>Estimated Size of an Uncompressed NDN Interest</name>
title="Estimated size of an uncompressed NDN Interest"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="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><xref target="fig.Size.NDN.interest.compressed" format="default"/>
<t><xref target="fig.Size.NDN.interest.compressed"/> depicts the depicts the
size requirements after compression.</t> size requirements after compression.</t>
<figure anchor="fig.Size.NDN.interest.compressed">
<figure anchor="fig.Size.NDN.interest.compressed" <name>Estimated Size of a Compressed NDN Interest</name>
title="Estimated size of a compressed NDN Interest"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="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 difference is 11 + 1.5n bytes.</t>
<t>The size difference is: <vspace/> 11 + 1.5n bytes.</t> <t>For the name <tt>/DE/HH/HAW/BT7</tt>, the
<t>For the name <spanx style="verb">/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>
<section numbered="true" toc="default">
<section title="Data"> <name>Data</name>
<t><xref target="fig.Size.NDN.Data.uncompressed"/> depicts the size <t><xref target="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 as a signature. The key locator is assumed to contain a Name
TLV of length klen.</t> TLV of length klen.</t>
<figure anchor="fig.Size.NDN.Data.uncompressed">
<figure anchor="fig.Size.NDN.Data.uncompressed" <name>Estimated Size of an Uncompressed NDN Data</name>
title="Estimated size of an uncompressed NDN Data"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="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><xref target="fig.Size.NDN.Data.compressed" format="default"/> depi
<t><xref target="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>
<figure anchor="fig.Size.NDN.Data.compressed">
<figure anchor="fig.Size.NDN.Data.compressed" <name>Estimated Size of a Compressed NDN Data</name>
title="Estimated size of a compressed NDN Data"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="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 difference is 15 + 1.5n bytes.</t>
<t>The size difference is: <vspace/> 15 + 1.5n bytes.</t> <t>For the name <tt>/DE/HH/HAW/BT7</tt>, the
<t>For the name <spanx style="verb">/DE/HH/HAW/BT7</spanx>, the
total size gain is 21 bytes.</t> total size gain is 21 bytes.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="CCNx"> <name>CCNx</name>
<t>The CCNx TLV encoding defines a 2-byte encoding for type and <t>The CCNx TLV encoding defines a 2-byte encoding for Type 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>
<section numbered="true" toc="default">
<section title="Interest"> <name>Interest</name>
<t><xref target="fig.Size.CCNx.interest.uncompressed"/> depicts the <t><xref target="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 the reserved field is assumed to be 0. A KeyIdRestriction TLV hop-by-hop TLVs are included, the protocol version is assumed to be
1, and the Reserved 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>
<figure anchor="fig.Size.CCNx.interest.uncompressed">
<figure anchor="fig.Size.CCNx.interest.uncompressed" <name>Estimated Size of an Uncompressed CCNx Interest</name>
title="Estimated size of an uncompressed CCNx Interest"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="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><xref target="fig.Size.CCNx.interest.compressed" format="default"/>
<t><xref target="fig.Size.CCNx.interest.compressed"/> depicts the depicts the size requirements after compression.</t>
size requirements after compression.</t> <figure anchor="fig.Size.CCNx.interest.compressed">
<name>Estimated Size of a Compressed CCNx Interest</name>
<figure anchor="fig.Size.CCNx.interest.compressed" <artwork align="center" name="" type="" alt=""><![CDATA[
title="Estimated size of a compressed CCNx Interest">
<artwork align="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 difference is 18 + 3.5n bytes.</t>
<t>The size difference is: <vspace/> 18 + 3.5n bytes.</t> <t>For the name <tt>/DE/HH/HAW/BT7</tt>, the size
<t>For the name <spanx style="verb">/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>
<section numbered="true" toc="default">
<section title="Content Object"> <name>Content Object</name>
<t><xref target="fig.Size.CCNx.Data.uncompressed"/> depicts the size <t><xref target="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
signature time and a hash of the shared secret key. In the fixed signature time, and a hash of the shared secret key. In the fixed
header, the protocol version is assumed to be 1 and the reserved header, the protocol version is assumed to be 1 and the Reserved
field is assumed to be 0</t> field is assumed to be 0</t>
<figure anchor="fig.Size.CCNx.Data.uncompressed">
<figure anchor="fig.Size.CCNx.Data.uncompressed" <name>Estimated Size of an Uncompressed CCNx Content Object</name>
title="Estimated size of an uncompressed CCNx Content Object"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="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><xref target="fig.Size.CCNx.Data.compressed" format="default"/>
<t><xref target="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>
<figure anchor="fig.Size.CCNx.Data.compressed">
<figure anchor="fig.Size.CCNx.Data.compressed" <name>Estimated Size of a Compressed CCNx Data Object</name>
title="Estimated size of a compressed CCNx Data Object"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="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 difference is 35 + 3.5n bytes.</t>
<t>The size difference is: <vspace/> 35 + 3.5n bytes.</t> <t>For the name <tt>/DE/HH/HAW/BT7</tt>, the size
<t>For the name <spanx style="verb">/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>
<section numbered="false" toc="default">
<section numbered="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 group and 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 <xref target="RFC4944"/> and <xref target="RFC6282"/>. Larger parts of this work
Special mentioning goes to Mark Mosko as well as G.Q. Wang and Ravi are inspired by <xref target="RFC4944" format="default"/> and
Ravindran as their previous work in <xref target="TLV-ENC-802.15.4"/> <xref target="RFC6282" format="default"/>.
and <xref target="WIRE-FORMAT-CONSID"/> provided a good base for our Special mention goes to <contact fullname="Mark Mosko"/>, as well as
<contact fullname="G.Q. Wang"/> and <contact fullname="Ravi Ravindran"/>,
as their previous work in <xref target="TLV-ENC-802.15.4" format="default"
/>
and <xref target="WIRE-FORMAT-CONSID" format="default"/> provided a good b
ase for our
discussions on stateless header compression mechanisms. discussions on stateless header compression mechanisms.
Many thanks also to Carsten Bormann and Lars Eggert, who contributed in-de Many thanks also to <contact fullname="Carsten Bormann"/> and
pth comments during the IRSG review. <contact fullname="Lars Eggert"/>, who contributed in-depth comments durin
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 from http://tools.ietf.org/tools/rfcdiff/