rfc9139.form.xml   rfc9139.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- [CS] updated by Chris 09/14/21 -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-irtf-icnrg-icnlow pan-10" number="0000" ipr="trust200902" submissionType="IRTF" category="exp" con sensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="t rue" sortRefs="true" version="3"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-irtf-icnrg-icnlow pan-11" number="9139" ipr="trust200902" submissionType="IRTF" category="exp" con sensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="t rue" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.9.1 --> <!-- xml2rfc v2v3 conversion 3.9.1 -->
<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
<seriesInfo name="RFC" value="0000"/> 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>
skipping to change at line 46 skipping to change at line 59
<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>
<author fullname="Matthias Waehlisch" initials="M." surname="Waehlisch"> <!-- [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.
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>http://www.inf.fu-berlin.de/~waehl</uri> <uri>https://www.mi.fu-berlin.de/en/inf/groups/ilab/members/waehlisch.ht 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>4051</code>
skipping to change at line 99 skipping to change at line 123
<address> <address>
<postal> <postal>
<street>Spiegelgasse 1</street> <street>Spiegelgasse 1</street>
<city>Basel</city> <city>Basel</city>
<code>4051</code> <code>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="September" /> <date year="2021" month="November" />
<workgroup>ICN Research Group</workgroup> <workgroup>Information-Centric Networking</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in the title) <!-- [rfced] Please insert any keywords (beyond those that appear in the title)
for use on https://www.rfc-editor.org/search. --> for use on https://www.rfc-editor.org/search.
-->
-&gt;
<keyword>example</keyword> <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" numbered="true" toc="default"> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name> <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 target="NDN-EXP1" traditional host-to-host approach on the Internet <xref target="NDN-EXP1"
format="default"/>, <xref target="NDN-EXP2" format="default"/>. Recent studies < format="default"/> <xref target="NDN-EXP2" format="default"/>. Recent stud
xref target="NDN-MAC" format="default"/> have shown that an appropriate mapping ies <xref
to link layer target="NDN-MAC" format="default"/> have shown that an appropriate mapping
technologies has a large impact on the practical performance of an ICN. 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" form chunks to such link layers for the ICN flavors NDN <xref target="NDN"
at="default"/> format="default"/> and CCNx <xref target="RFC8569" format="default"/> <xre
and CCNx <xref target="RFC8569" format="default"/>, <xref target="RFC8609" f
format="default"/>.</t> target="RFC8609" format="default"/>.</t>
<t>The IEEE 802.15.4 <xref target="ieee802.15.4" format="default"/> link l <t>The IEEE 802.15.4 <xref target="ieee802.15.4" format="default"/> link l
ayer is used in ayer is
low-power and lossy networks (see <tt>LLN</tt> in used in low-power and lossy networks (see <tt>LLN</tt> in
<xref target="RFC7228" format="default"/>), in which devices are typically <xref target="RFC7228" format="default"/>), in which devices are typically
battery-operated and constrained in resources. Characteristics of LLNs battery operated and constrained in resources. Characteristics of LLNs
include an unreliable environment, low bandwidth transmissions, and include an unreliable environment, low-bandwidth transmissions, and
increased latencies. IEEE 802.15.4 admits a maximum physical layer 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" format="default"/> <xref target="RFC6282
format="default">, </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 Type-Length-Value (TLV) based packet formats such as in <t>Prevalent packet formats based on Type-Length-Value (TLV), 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 target=" ICNLOWPAN" format="default"/> illustrate a reduced message overhead, a shortened evaluations of the ICN LoWPAN header compression schemes in <xref target=" 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" format="default"/> devices compared to unco mpressed ICN messages.</t> Class 2 devices <xref target="RFC7228" format="default"/> compared to unco mpressed ICN messages.</t>
<t>In a typical IoT scenario (see <xref target="fig-iot_network" format="d efault"> <t>In a typical IoT scenario (see <xref target="fig-iot_network" format="d 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">
<name>IoT Stub Network</name> <name>IoT Stub Network</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
|Gateway Services| |Gateway Services|
------------------------- -------------------------
| |
,--------, ,--------,
| | | |
| BR | | BR |
skipping to change at line 200 skipping to change at line 233
'--------' '--------'
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"> <section numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <!--[rfced] Please note that we have added RFC 8174 to the Normative References
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", section and updated the text in the Terminology section below. Additionally, the
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED< term "silently ignored" is not used in this document, so we have removed the te
/bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this xt describing it. Please let us know if you have any concerns.
document are to be interpreted as described in RFC 2119 <xref target="RFC2
119" format="default"/>. The use of the term, "silently ignore" is not Original:
defined in RFC 2119. However, the term is used in this document and can The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
be similarly construed.</t> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
The use of the term, "silently ignore" is not defined in RFC 2119.
However, the term is used in this document and can be similarly
construed.
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>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:
</t> </t>
<dl newline="false" spacing="normal" indent="14"> <dl newline="false" spacing="normal" indent="14">
<dt>ICN LoWPAN:</dt> <dt>ICN LoWPAN:</dt>
<dd>Information-Centric Networking over <dd>Information-Centric Networking over
Low-power Wireless Personal Area Network</dd> Low-Power Wireless Personal Area Network</dd>
<dt>LLN:</dt> <dt>LLN:</dt>
<dd>Low-Power and Lossy Network</dd> <dd>Low-Power and Lossy Network</dd>
<dt>CCNx:</dt> <dt>CCNx:</dt>
<dd>Content-Centric Networking Architecture</dd> <dd>Content-Centric Networking</dd>
<dt>NDN:</dt> <dt>NDN:</dt>
<dd>Named Data Networking Architecture</dd> <dd>Named Data Networking</dd>
<dt>byte:</dt> <dt>byte:</dt>
<dd>synonym for octet</dd> <dd>synonym for octet</dd>
<dt>nibble:</dt> <dt>nibble:</dt>
<dd>synonym for 4 bits</dd> <dd>synonym for 4 bits</dd>
<dt>time-value:</dt> <dt>time-value:</dt>
<dd>a time offset measured in seconds</dd> <dd>a time offset measured in seconds</dd>
<dt>time-code:</dt> <dt>time-code:</dt>
<dd>an 8-bit encoded time-value</dd> <dd>an 8-bit encoded time-value</dd>
</dl> </dl>
</section> </section>
<section anchor="ICNLoWPAN" numbered="true" toc="default"> <section anchor="ICNLoWPAN" numbered="true" toc="default">
<name>Overview of ICN LoWPAN</name> <name>Overview of ICN LoWPAN</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Link-Layer Convergence</name> <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" format="default"/>.</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> <name>ICN LoWPAN Convergence Layer for IEEE 802.15.4</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![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 ent defines the <t><xref target="sec.lowpan_adaptation" format="default"/> of this docum 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 numbered="true" toc="default">
<name>Stateless Header Compression</name> <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 stateless <t><xref target="fig.TLV.compressed" format="default"/> demonstrates the 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 inclusio <name>Compression Using a Compact Bit Field -- Bits Encode the Inclusi
n of on of
TLVs.</name> TLVs</name>
<artwork align="center" name="" type="" alt=""><![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 " format="default"/>. <xref target="sec.ccnx" format="default"/> defines the sta teless <t>Stateless TLV compression for NDN is defined in <xref target="sec.ndn " format="default"/>. <xref target="sec.ccnx" format="default"/> defines the sta teless
TLV compression for CCNx.</t> TLV compression for CCNx.</t>
<t>The extensibility of this compression is described in <xref target="s ec.dispatch.ext" format="default"/> and allows future documents to update the <t>The extensibility of this compression is described in <xref target="s ec.dispatch.ext" format="default"/> and allows future documents to update the
compression rules outlined in this manuscript.</t> compression rules outlined in this document.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Stateful Header Compression</name> <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 target="st schemes for packet size reductions, which are defined in <xref target="s
ateful.compression" format="default"/>. 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 l.compression.local" format="default"/>. The hop-wise name compression <t>The shared context identification is defined in <xref target="statefu l.compression.local" format="default"/>. The hop-wise name compression
"en-route" is specified in <xref target="stateful.compression.en-route" format="default"/>.</t> "en-route" is specified in <xref target="stateful.compression.en-route" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="sec.lowpan_adaptation" numbered="true" toc="default"> <section anchor="sec.lowpan_adaptation" numbered="true" toc="default">
<name>IEEE 802.15.4 Adaptation</name> <name>IEEE 802.15.4 Adaptation</name>
<section anchor="sec.lowpan_encap" numbered="true" toc="default"> <section anchor="sec.lowpan_encap" numbered="true" toc="default">
<name>LoWPAN Encapsulation</name> <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 <xref target="RFC4944" section="5" section Format="of" format="default"/>). for IEEE 802.15.4 frames (see <xref target="RFC4944" section="5" section Format="of" format="default"/>).
Multiple LoWPAN encapsulation headers can precede the actual payload 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>
<t><xref target="RFC8025" format="default"/> further specifies dispatch <!-- [rfced] In the following sentence, should "dispatch table" be instead "disp
pages to switch atch Page"?
between different contexts. When a LoWPAN parser encounters a <tt>Page s
witch</tt> LoWPAN encapsulation header, then all Current:
When a LoWPAN parser encounters a Page switch
LoWPAN encapsulation header, all following encapsulation headers are
interpreted by using a dispatch table, as specified by the Page
switch header.
Perhaps:
When a LoWPAN parser encounters a Page switch
LoWPAN encapsulation header, all following encapsulation headers are
interpreted by using a dispatch Page, as specified by the Page
switch header.
-->
<t><xref target="RFC8025" format="default"/> further specifies dispatch
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 following encapsulation headers are interpreted by using a dispatch
table as specified by the <tt>Page switch</tt> table, as specified by the <tt>Page switch</tt>
header. Page 0 and page 1 are reserved for 6LoWPAN. This document uses header. Pages 0 and 1 are reserved for 6LoWPAN. This document uses
page TBD1 (<tt>1111 TBD1 (0xFTBD1)</tt>) for ICN LoWPAN.</t> Page 14 (<tt>1111 1110 (0xFE)</tt>) for ICN LoWPAN.</t>
<t>The base dispatch format (<xref target="fig.disp.base" format="defaul <t>The base dispatch format (<xref target="fig.disp.base" format="defaul
t"/>) is used t"/>) is
and extended by CCNx and NDN in <xref target="sec.ndn" format="default"/ used and extended by CCNx and NDN in Sections <xref target="sec.ndn" form
> and <xref target="sec.ccnx" format="default"/>.</t> at="counter"/> and
<xref target="sec.ccnx" format="counter"/>.</t>
<figure anchor="fig.disp.base"> <figure anchor="fig.disp.base">
<name>Base dispatch format for ICN LoWPAN</name> <name>Base Dispatch Format for ICN LoWPAN</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 ... 0 1 2 3 ...
+---+---+----------- +---+---+---+---+---
| C | P | M | | 0 | P | M | C |
+---+---+----------- +---+---+---+---+---
]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="true" spacing="normal" indent="4"> <dl newline="true" spacing="normal" indent="4">
<dt>C: Compression</dt>
<dd>
<t><br/></t>
<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>
<dt>P: Protocol</dt> <dt>P: Protocol</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>The included protocol is NDN.</dd> <dd>The included protocol is NDN.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>The included protocol is CCNx.</dd> <dd>The included protocol is CCNx.</dd>
</dl> </dl>
</dd> </dd>
<dt>M: Message Type</dt> <dt>M: Message Type</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>The payload contains an Interest message.</dd> <dd>The payload contains an Interest message.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>The payload contains a Data message.</dd> <dd>The payload contains a Data message.</dd>
</dl> </dl>
</dd> </dd>
<dt>C: Compression</dt>
<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> </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 target="fig.disp.base.compr" forma t="default"/>.</t> the extended dispatch format in <xref target="fig.disp.base.compr" forma t="default"/>.</t>
<figure anchor="fig.disp.base.compr"> <figure anchor="fig.disp.base.compr">
<name>Extended dispatch format for compressed ICN LoWPAN</name> <name>Extended Dispatch Format for Compressed ICN LoWPAN</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 4 ... 0 1 2 3 ... ...
+---+---+---+---+---+--- +---+---+---+---+...+---+---+
| 1 | P | M |CID|EXT| | 0 | P | M | 1 | |CID|EXT|
+---+---+---+---+---+--- +---+---+---+---+...+---+---+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="true" spacing="normal" indent="4"> <dl newline="true" spacing="normal" indent="4">
<dt>CID: Context Identifier</dt> <dt>CID: Context Identifier</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>No context identifiers are present.</dd> <dd>No context identifiers are present.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>Context identifier(s) are present (see <xref target="stateful. compression.local" format="default"/>).</dd> <dd>Context identifier(s) are present (see <xref target="stateful. compression.local" format="default"/>).</dd>
</dl> </dl>
</dd> </dd>
<dt>EXT: Extension</dt> <dt>EXT: Extension</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>No extension bytes are present.</dd> <dd>No extension bytes are present.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>Extension byte(s) are present (see <xref target="sec.dispatch. ext" format="default"/>).</dd> <dd>Extension byte(s) are present (see <xref target="sec.dispatch. ext" format="default"/>).</dd>
</dl> </dl>
</dd> </dd>
</dl> </dl>
<t>The encapsulation format for ICN LoWPAN is displayed in <xref target= "fig.ICN-LoWPAN.header" format="default"/>.</t> <t>The encapsulation format for ICN LoWPAN is displayed in <xref target= "fig.ICN-LoWPAN.header" format="default"/>.</t>
<figure anchor="fig.ICN-LoWPAN.header"> <figure anchor="fig.ICN-LoWPAN.header">
<name>LoWPAN Encapsulation with ICN-LoWPAN</name> <name>LoWPAN Encapsulation with ICN LoWPAN</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <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"> <dl newline="false" spacing="normal" indent="16">
<dt>IEEE 802.15.4:</dt> <dt>IEEE 802.15.4:</dt>
<dd>The IEEE 802.15.4 header.</dd> <dd>The IEEE 802.15.4 header.</dd>
<dt>RFC4944 Disp.:</dt> <dt>RFC4944 Disp.:</dt>
<dd>Optional additional dispatches <dd>Optional additional dispatches
defined in <xref target="RFC4944" section="5.1" sectionFormat="of" f ormat="default"/></dd> defined in <xref target="RFC4944" section="5.1" sectionFormat="of" f ormat="default"/>.</dd>
<dt>Page:</dt> <dt>Page:</dt>
<dd>Page Switch. TBD1 for ICN LoWPAN.</dd> <dd><tt>Page switch</tt>. 14 for ICN LoWPAN.</dd>
<dt>ICN LoWPAN:</dt> <dt>ICN LoWPAN:</dt>
<dd>Dispatches as defined in <xref target="sec.ndn" format="default"/> and <xref target="sec.ccnx" format="default"/>.</dd> <dd>Dispatches as defined in Sections <xref target="sec.ndn" format="c ounter"/> and <xref target="sec.ccnx" format="counter"/>.</dd>
<dt>Payload:</dt> <dt>Payload:</dt>
<dd>The actual (un-)compressed CCNx or NDN <dd>The actual (un-)compressed CCNx or NDN
message.</dd> message.</dd>
</dl> </dl>
<section anchor="sec.dispatch.ext" numbered="true" toc="default"> <section anchor="sec.dispatch.ext" numbered="true" toc="default">
<name>Dispatch Extensions</name> <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" format="default"/>.</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> <name>Base Format for Dispatch Extensions</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![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"> <dl newline="true" spacing="normal" indent="4">
<dt>EXT: Extension</dt> <dt>EXT: Extension</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>No other extension byte follows.</dd> <dd>No other extension byte follows.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>A further extension byte follows.</dd> <dd>A further extension byte follows.</dd>
</dl> </dl>
</dd> </dd>
</dl> </dl>
<t>Extension bytes are numbered according to their order. Future <t>Extension bytes are numbered according to their order. Future
documents <bcp14>MUST</bcp14> follow the naming scheme <tt>EXT_0, EXT_ 1, ...</tt>, 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 <bcp14>SHOULD</bcp14> use manifests to encode structur ed data in a between devices <bcp14>SHOULD</bcp14> use manifests to encode structur ed data in a
well-defined format, as, e.g., outlined in <xref target="I-D.irtf-icnr g-flic" format="default"/>.</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" numbered="true" toc="default">
<name>Adaptation Layer Fragmentation</name> <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, <xref target="RFC4944" section="5.3" sectionF ormat="of" format="default"/> 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" format="default"/>.</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 " section="5" sectionFormat="of" format="default"/>. <xref target="fig.fr_first" format="default"/> shows the headers. The order of dispatch types is defined in <xref target="RFC4944 " section="5" sectionFormat="of" format="default"/>. <xref target="fig.fr_first" 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 target="fig.f r_done" format="default"/>.</t> contain any fragmentation headers and is depicted in <xref target="fig.f r_done" format="default"/>.</t>
<figure anchor="fig.fr_first"> <figure anchor="fig.fr_first">
<name>Fragmentation scheme</name> <name>Fragmentation Scheme</name>
<artwork align="center" name="" type="" alt=""><![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">
<name>Reassembled ICN LoWPAN frame</name> <name>Reassembled ICN LoWPAN Frame</name>
<artwork align="center" name="" type="" alt=""><![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 (6FF) <xref target="RFC8930" format=" default"/> is an alternative <t>The 6LoWPAN Fragment Forwarding (6LFF) <xref target="RFC8930" format= "default"/> 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 target="SFR-ICNLOWPAN" for fragmentation. However, experimental evaluations <xref target="SFR-ICNLO
mat="default"/>, 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" numbered="true" toc="default">
<name>Space-efficient Message Encoding for NDN</name> <name>Space-Efficient Message Encoding for NDN</name>
<section anchor="sec.tlvencoding" numbered="true" toc="default"> <section anchor="sec.tlvencoding" numbered="true" toc="default">
<name>TLV Encoding</name> <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" format="default"/>. 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 <tt>253</tt>,
then that number is encoded into the actual type or length field. If then that number is encoded into the actual Type or Length field. If
the number is greater or equals <tt>253</tt> and the number is greater or equals <tt>253</tt> and
fits into 2 bytes, then the type or length field is set to <tt>253</tt> and the number is encoded in the next fits into 2 bytes, then the Type or Length field is set to <tt>253</tt> 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 <tt>254</tt> 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 <tt>255</tt> and the number is encoded in the subsequent 8 For larger numbers, the Type or Length field is set to <tt>255</tt> and 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 DTN protoc <xref target="RFC6256" format="default"/> commonly known from Delay-Tole
ols. 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"> <table anchor="tab.sdnvperformance" align="center">
<name>NDN TLV encoding compared to SDNVs.</name> <name>NDN TLV Encoding Compared to SDNVs</name>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left">Value</th>
<th align="left">NDN TLV encoding</th> <th align="left">NDN TLV Encoding</th>
<th align="left">SDNV encoding</th> <th align="left">SDNV Encoding</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0</td> <td align="left">0</td>
<td align="left">0x00</td> <td align="left">0x00</td>
<td align="left">0x00</td> <td align="left">0x00</td>
</tr> </tr>
<tr> <tr>
<td align="left">127</td> <td align="left">127</td>
skipping to change at line 587 skipping to change at line 663
<td align="left">128</td> <td align="left">128</td>
<td align="left">0x80</td> <td align="left">0x80</td>
<td align="left">0x81 0x00</td> <td align="left">0x81 0x00</td>
</tr> </tr>
<tr> <tr>
<td align="left">253</td> <td align="left">253</td>
<td align="left">0xFD 0x00 0xFD</td> <td align="left">0xFD 0x00 0xFD</td>
<td align="left">0x81 0x7D</td> <td align="left">0x81 0x7D</td>
</tr> </tr>
<tr> <tr>
<td align="left">2^14 - 1</td> <td align="left">2<sup>14</sup> - 1</td>
<td align="left">0xFD 0x3F 0xFF</td> <td align="left">0xFD 0x3F 0xFF</td>
<td align="left">0xFF 0x7F</td> <td align="left">0xFF 0x7F</td>
</tr> </tr>
<tr> <tr>
<td align="left">2^14</td> <td align="left">2<sup>14</sup></td>
<td align="left">0xFD 0x40 0x00</td> <td align="left">0xFD 0x40 0x00</td>
<td align="left">0x81 0x80 0x00</td> <td align="left">0x81 0x80 0x00</td>
</tr> </tr>
<tr> <tr>
<td align="left">2^16</td> <td align="left">2<sup>16</sup></td>
<td align="left">0xFE 0x00 0x01 0x00 0x00</td> <td align="left">0xFE 0x00 0x01 0x00 0x00</td>
<td align="left">0x84 0x80 0x00</td> <td align="left">0x84 0x80 0x00</td>
</tr> </tr>
<tr> <tr>
<td align="left">2^21 - 1</td> <td align="left">2<sup>21</sup> - 1</td>
<td align="left">0xFE 0x00 0x1F 0xFF 0xFF</td> <td align="left">0xFE 0x00 0x1F 0xFF 0xFF</td>
<td align="left">0xFF 0xFF 0x7F</td> <td align="left">0xFF 0xFF 0x7F</td>
</tr> </tr>
<tr> <tr>
<td align="left">2^21</td> <td align="left">2<sup>21</sup></td>
<td align="left">0xFE 0x00 0x20 0x00 0x00</td> <td align="left">0xFE 0x00 0x20 0x00 0x00</td>
<td align="left">0x81 0x80 0x80 0x00</td> <td align="left">0x81 0x80 0x80 0x00</td>
</tr> </tr>
<tr> <tr>
<td align="left">2^28 - 1</td> <td align="left">2<sup>28</sup> - 1</td>
<td align="left">0xFE 0x0F 0xFF 0xFF 0xFF</td> <td align="left">0xFE 0x0F 0xFF 0xFF 0xFF</td>
<td align="left">0xFF 0xFF 0xFF 0x7F</td> <td align="left">0xFF 0xFF 0xFF 0x7F</td>
</tr> </tr>
<tr> <tr>
<td align="left">2^28</td> <td align="left">2<sup>28</sup></td>
<td align="left">0xFE 0x1F 0x00 0x00 0x00</td> <td align="left">0xFE 0x1F 0x00 0x00 0x00</td>
<td align="left">0x81 0x80 0x80 0x80 0x00</td> <td align="left">0x81 0x80 0x80 0x80 0x00</td>
</tr> </tr>
<tr> <tr>
<td align="left">2^32</td> <td align="left">2<sup>32</sup></td>
<td align="left">0xFF 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00</td> <td align="left">0xFF 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00</td>
<td align="left">0x90 0x80 0x80 0x80 0x00</td> <td align="left">0x90 0x80 0x80 0x80 0x00</td>
</tr> </tr>
<tr> <tr>
<td align="left">2^35 - 1</td> <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 0x00 0x00 0x00 0x07 0xFF 0xFF 0xFF 0xFF</td>
<td align="left">0xFF 0xFF 0xFF 0xFF 0x7F</td> <td align="left">0xFF 0xFF 0xFF 0xFF 0x7F</td>
</tr> </tr>
<tr> <tr>
<td align="left">2^35</td> <td align="left">2<sup>35</sup></td>
<td align="left">0xFF 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00</td> <td align="left">0xFF 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00</td>
<td align="left">0x81 0x80 0x80 0x80 0x80 0x00</td> <td align="left">0x81 0x80 0x80 0x80 0x80 0x00</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
<xref target="tab.sdnvperformance" format="default"/> compares the req uired <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" numbered="true" toc="default">
<name>Name TLV Compression</name> <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 ame with an even number of components, The last Length field of an encoded NameComponent is either 0x00 for a n ame with an even number of components
and 0xYF (Y &gt; 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 llows for an unlimited number of components. This process limits the length of a NameComponent TLV to 15 bytes but al lows for an unlimited number of components.
An example for this encoding is presented in <xref target="fig.ndnshortn co" format="default"/>.</t> An example for this encoding is presented in <xref target="fig.ndnshortn co" format="default"/>.</t>
<figure anchor="fig.ndnshortnco"> <figure anchor="fig.ndnshortnco">
<name>Name TLV compression for /HAW/Room/481/Humid/99</name> <name>Name TLV Compression for /HAW/Room/481/Humid/99</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 685 skipping to change at line 761
| 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 numbered="true" toc="default">
<name>Interest Messages</name> <name>Interest Messages</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Uncompressed Interest Messages</name> <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" format="default"/>) and sets the C f (see <xref target="fig.disp.base" format="default"/>) and sets the C,
lag to P, and M
<tt>0</tt> and the P as well as the M flags to <tt>0</tt> (<xref target="fig.ndn.int.uncompr" format="defaul
flag to <tt>0</tt> (<xref target="fig.ndn.int.uncompr" format="default 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> <name>Dispatch Format for Uncompressed NDN Interest Messages</name>
<artwork align="center" name="" type="" alt=""><![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 | 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 numbered="true" toc="default">
<name>Compressed Interest Messages</name> <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" format="default"/>) and sets the C (<xref target="fig.disp.base.compr" format="default"/>) and sets the C
flag to <tt>1</tt>, flag to
the P flag to <tt>0</tt> and the M flag to <tt>0</tt>. <tt>1</tt> and the P and M flags to <tt>0</tt>.
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 <bcp14>MUST</bcp14> 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: </t> the following minimal rule set: </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>The <tt>Type</tt> field of the outermost <li>The <tt>Type</tt> field of the outermost
MessageType TLV is removed.</li> MessageType TLV is removed.</li>
<li>The Name TLV is compressed according to <xref target="sec.ndn.na <li>The Name TLV is compressed according to <xref
mecompression" format="default"/>. 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 <bcp14>MAY</bcp14> appear at the e greater than 0. An ImplicitSha256DigestComponent or
nd of the ParametersSha256DigestComponent <bcp14>MAY</bcp14> appear at the end
name. In any other case, the message <bcp14>MUST</bcp14> be sent of the
uncompressed.</li> name. In any other case, the message <bcp14>MUST</bcp14> be sent
uncompressed.</li>
<li>The Nonce TLV and InterestLifetime TLV are moved to <li>The Nonce TLV and InterestLifetime TLV are moved to
the end of the compressed Interest as illustrated in the end of the compressed Interest, as illustrated in
<xref target="fig.ndn.int.newformat" format="default"/>. The <xref target="fig.ndn.int.newformat" format="default"/>. The
InterestLifetime is encoded as described in <xref target="sec.comp InterestLifetime is encoded as described in <xref
ressedtime" format="default"/>. On target="sec.compressedtime" format="default"/>. On
decompression, this encoding may yield an decompression, this encoding may yield an
Interestlifetime that is smaller than the original InterestLifetime that is smaller than the original
value.</li> value.</li>
<li>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" for compressed InterestLifetime (<xref target="sec.compressedtime"
mat="default"/>) 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 <tt>1</tt> indicates the A remaining length of <tt>1</tt> indicates the
presence of an InerestLifetime, a length of <tt>4</tt> indicates presence of an InterestLifetime, a length of <tt>4</tt> indicates
the presence of a nonce, and a length of <tt>5</tt> indicates the presence of a nonce, and a length of <tt>5</tt> indicates
the presence of both TLVs.</li> the presence of both TLVs.</li>
</ol> </ol>
<t>The compressed NDN LoWPAN Interest message is visualized in <xref t arget="fig.ndn.int.newformat" format="default"/>.</t> <t>The compressed NDN LoWPAN Interest message is visualized in <xref t arget="fig.ndn.int.newformat" format="default"/>.</t>
<figure anchor="fig.ndn.int.newformat"> <figure anchor="fig.ndn.int.newformat">
<name>Compression of NDN LoWPAN Interest Message</name> <name>Compression of NDN LoWPAN Interest Message</name>
<artwork align="center" name="" type="" alt=""><![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
+---------+---------+ +---------+ +---------+---------+ +---------+
skipping to change at line 772 skipping to change at line 852
+---------+---------+---------+ +---------+ +---------+---------+---------+ +---------+
: 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" format="default"/>.</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> <name>Dispatch Format for Compressed NDN Interest Messages</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![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"> <dl newline="true" spacing="normal" indent="4">
<dt>CID: Context Identifier</dt>
<dd>See <xref target="fig.disp.base.compr" format="default"/>.</dd>
<dt>EXT: Extension</dt>
<dd>
<t><br/></t>
<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>
<dt>PFX: CanBePrefix TLV</dt> <dt>PFX: CanBePrefix TLV</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>The uncompressed message does not include a <dd>The uncompressed message does not include a
CanBePrefix TLV.</dd> CanBePrefix TLV.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>The uncompressed message does include a <dd>The uncompressed message does include a
CanBePrefix TLV and is removed from the compressed CanBePrefix TLV and is removed from the compressed
message.</dd> message.</dd>
</dl> </dl>
</dd> </dd>
<dt>FRE: MustBeFresh TLV</dt> <dt>FRE: MustBeFresh TLV</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>The uncompressed message does not include a <dd>The uncompressed message does not include a
MustBeFresh TLV.</dd> MustBeFresh TLV.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>The uncompressed message does include a <dd>The uncompressed message does include a
MustBeFresh TLV and is removed from the compressed MustBeFresh TLV and is removed from the compressed
message.</dd> message.</dd>
</dl> </dl>
</dd> </dd>
<dt>FWD: ForwardingHint TLV</dt> <dt>FWD: ForwardingHint TLV</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>The uncompressed message does not include a <dd>The uncompressed message does not include a
ForwardingHint TLV.</dd> ForwardingHint TLV.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>The uncompressed message does include a <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 target="sec.ndn.namecompression" format="default"/>. If any name is not compressed according to <xref target="sec.ndn.namecompression" format="default"/>. If any name is not
compressible, the message <bcp14>MUST</bcp14> be sent uncompre ssed.</dd> compressible, the message <bcp14>MUST</bcp14> be sent uncompre ssed.</dd>
</dl> </dl>
</dd> </dd>
<dt>APM: ApplicationParameters TLV</dt> <dt>APM: ApplicationParameters TLV</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>The uncompressed message does not include <dd>The uncompressed message does not include
an ApplicationParameters TLV.</dd> an ApplicationParameters TLV.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>The uncompressed message does include an <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.</dd> the compressed message.</dd>
</dl> </dl>
</dd> </dd>
<dt>DIG: ImplicitSha256DigestComponent TLV</dt> <dt>DIG: ImplicitSha256DigestComponent TLV</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>The name does not include an <dd>The name does not include an
ImplicitSha256DigestComponent as the last TLV.</dd> ImplicitSha256DigestComponent as the last TLV.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>The name does include an <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.</dd> Length fields are omitted.</dd>
</dl> </dl>
</dd> </dd>
<dt>RSV: Reserved</dt> <dt>RSV: Reserved</dt>
<dd>Must be set to 0.</dd> <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.interest.ext0"
format="default"/>.</dd>
</dl>
</dd>
</dl> </dl>
</section> </section>
<section anchor="sec.ndn.interest.ext0" numbered="true" toc="default"> <section anchor="sec.ndn.interest.ext0" numbered="true" toc="default">
<name>Dispatch Extension</name> <name>Dispatch Extension</name>
<t>The <tt>EXT_0</tt> byte follows the <t>The <tt>EXT_0</tt> byte follows the
description in <xref target="sec.dispatch.ext" format="default"/> and is illustrated description in <xref target="sec.dispatch.ext" format="default"/> and is illustrated
in <xref target="fig.ndn.interest.ext0" format="default"/>.</t> in <xref target="fig.ndn.interest.ext0" format="default"/>.</t>
<figure anchor="fig.ndn.interest.ext0"> <figure anchor="fig.ndn.interest.ext0">
<name>EXT_0 format</name> <name>EXT_0 Format</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <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"> <dl newline="true" spacing="normal" indent="4">
<dt>NCS: Name Compression Strategy</dt> <dt>NCS: Name Compression Strategy</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>00:</dt> <dt>00:</dt>
<dd>Names are compressed with the default name <dd>Names are compressed with the default name
compression strategy (see <xref target="sec.ndn.namecompressio n" format="default"/>).</dd> compression strategy (see <xref target="sec.ndn.namecompressio n" format="default"/>).</dd>
<dt>01:</dt> <dt>01:</dt>
<dd>Reserved.</dd> <dd>Reserved.</dd>
<dt>10:</dt> <dt>10:</dt>
<dd>Reserved.</dd> <dd>Reserved.</dd>
<dt>11:</dt> <dt>11:</dt>
<dd>Reserved.</dd> <dd>Reserved.</dd>
</dl> </dl>
</dd> </dd>
<dt>RSV: Reserved</dt> <dt>RSV: Reserved</dt>
<dd>Must be set to 0.</dd> <dd>Must be set to 0.</dd>
<dt>EXT: Extension</dt> <dt>EXT: Extension</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>No extension byte follows.</dd> <dd>No extension byte follows.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>A further extension byte follows <dd>A further extension byte follows
immediately.</dd> immediately.</dd>
</dl> </dl>
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Data Messages</name> <name>Data Messages</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Uncompressed Data Messages</name> <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 <tt>0</tt>, format and sets the C and P flags to <tt>0</tt> and the M flag
the P flag to <tt>0</tt> and the M flag
to <tt>1</tt> (<xref target="fig.ndn.data.uncompr" format="default"/>) . The Data message is to <tt>1</tt> (<xref target="fig.ndn.data.uncompr" format="default"/>) . 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> <name>Dispatch Format for Uncompressed NDN Data Messages</name>
<artwork align="center" name="" type="" alt=""><![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 | 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 numbered="true" toc="default">
<name>Compressed Data Messages</name> <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" format="default"/>) and set s the C format (<xref target="fig.disp.base.compr" format="default"/>) and set s the C
as well as the M flags to <tt>1</tt>. The and M flags to <tt>1</tt>. The
P flag is set to <tt>0</tt>. If a Data 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 <bcp14>MUST</bcp14> 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: </t> base rule set: </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>The <tt>Type</tt> field of the outermost <li>The <tt>Type</tt> field of the outermost
MessageType TLV is removed.</li> MessageType TLV is removed.</li>
<li>The Name TLV is compressed according to <xref target="sec.ndn.na mecompression" format="default"/>. For this, all NameComponents <li>The Name TLV is compressed according to <xref target="sec.ndn.na 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 <bcp14>MUST< /bcp14> be length greater than 0. In any other case, the message <bcp14>MUST< /bcp14> be
sent uncompressed.</li> sent uncompressed.</li>
<li>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.</li> compressed Data message.</li>
<li>The FreshnessPeriod TLV <bcp14>MUST</bcp14> be moved to the end of the <li>The FreshnessPeriod TLV <bcp14>MUST</bcp14> be moved to the end 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" format="default"/> as a 1-byt in <xref target="sec.compressedtime" format="default"/> as a 1-byt
e time-code. If the freshness period is not e
time-code. If the freshness period is not
a valid time-value, then the message <bcp14>MUST</bcp14> be sent u ncompressed 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.</li> remaining one-byte length to parse.</li>
<li>The Type fields of the SignatureInfo TLV, SignatureType TLV <li>The Type fields of the SignatureInfo TLV, SignatureType TLV,
and SignatureValue TLV are removed.</li> and SignatureValue TLV are removed.</li>
</ol> </ol>
<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 targe t="fig.ndn.data.newformat" format="default"/>.</t>
<figure anchor="fig.ndn.data.newformat"> <figure anchor="fig.ndn.data.newformat">
<name>Compression of NDN LoWPAN Data Message</name> <name>Compression of NDN LoWPAN Data Message</name>
<artwork align="center" name="" type="" alt=""><![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
skipping to change at line 997 skipping to change at line 1069
+---------+---------+---------+ +---------+---------+ +---------+---------+---------+ +---------+---------+
| 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" format="default"/>.</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> <name>Dispatch Format for Compressed NDN Data Messages</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![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"> <dl newline="true" spacing="normal" indent="4">
<dt>CID: Context Identifier</dt>
<dd>See <xref target="fig.disp.base.compr" format="default"/>.</dd>
<dt>EXT: Extension</dt>
<dd>
<t><br/></t>
<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" form
at="default"/>.</dd>
</dl>
</dd>
<dt>FBI: FinalBlockId TLV</dt> <dt>FBI: FinalBlockId TLV</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>The uncompressed message does not include a <dd>The uncompressed message does not include a
FinalBlockId TLV.</dd> FinalBlockId TLV.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>The uncompressed message does include a <dd>The uncompressed message does include a
FinalBlockId and it is encoded according to <xref target="sec. FinalBlockId, and it is encoded according to <xref
ndn.namecompression" format="default"/>. If the FinalBlockId TLV target="sec.ndn.namecompression" format="default"/>. If the Fin
is not compressible, then the message <bcp14>MUST</bcp14> be s alBlockId
ent TLV is not compressible, then the message <bcp14>MUST</bcp14> b
e sent
uncompressed.</dd> uncompressed.</dd>
</dl> </dl>
</dd> </dd>
<dt>CON: ContentType TLV</dt> <dt>CON: ContentType TLV</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>The uncompressed message does not include a <dd>The uncompressed message does not include a
ContentType TLV.</dd> ContentType TLV.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>The uncompressed message does include a <dd>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.</dd> compressed message.</dd>
</dl> </dl>
</dd> </dd>
<dt>KLO: KeyLocator TLV</dt> <dt>KLO: KeyLocator TLV</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>If the included SignatureType requires a <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 target="sec.ndn.namecompression" compressed according to <xref
format="default"/>. If the name is not target="sec.ndn.namecompression" format="default"/>. If the
compressible, then the message <bcp14>MUST</bcp14> be sent name is not compressible, then the message
uncompressed.</dd> <bcp14>MUST</bcp14> be sent uncompressed.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>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.</dd> The Type field of this KeyDigest is removed.</dd>
</dl> </dl>
</dd> </dd>
<dt>RSV: Reserved</dt> <dt>RSV: Reserved</dt>
<dd>Must be set to 0.</dd> <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>
</dl> </dl>
</section> </section>
<section anchor="sec.ndn.data.ext0" numbered="true" toc="default"> <section anchor="sec.ndn.data.ext0" numbered="true" toc="default">
<name>Dispatch Extension</name> <name>Dispatch Extension</name>
<t>The <tt>EXT_0</tt> byte follows the <t>The <tt>EXT_0</tt> byte follows the
description in <xref target="sec.dispatch.ext" format="default"/> and is illustrated description in <xref target="sec.dispatch.ext" format="default"/> and is illustrated
in <xref target="fig.ndn.data.ext0" format="default"/>.</t> in <xref target="fig.ndn.data.ext0" format="default"/>.</t>
<figure anchor="fig.ndn.data.ext0"> <figure anchor="fig.ndn.data.ext0">
<name>EXT_0 format</name> <name>EXT_0 Format</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <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"> <dl newline="true" spacing="normal" indent="4">
<dt>NCS: Name Compression Strategy</dt> <dt>NCS: Name Compression Strategy</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>00:</dt> <dt>00:</dt>
<dd>Names are compressed with the default name <dd>Names are compressed with the default name
compression strategy (see <xref target="sec.ndn.namecompressio n" format="default"/>).</dd> compression strategy (see <xref target="sec.ndn.namecompressio n" format="default"/>).</dd>
<dt>01:</dt> <dt>01:</dt>
<dd>Reserved.</dd> <dd>Reserved.</dd>
<dt>10:</dt> <dt>10:</dt>
<dd>Reserved.</dd> <dd>Reserved.</dd>
<dt>11:</dt> <dt>11:</dt>
<dd>Reserved.</dd> <dd>Reserved.</dd>
</dl> </dl>
</dd> </dd>
<dt>RSV: Reserved</dt> <dt>RSV: Reserved</dt>
<dd>Must be set to 0.</dd> <dd>Must be set to 0.</dd>
<dt>EXT: Extension</dt> <dt>EXT: Extension</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>No extension byte follows.</dd> <dd>No extension byte follows.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>A further extension byte follows <dd>A further extension byte follows
immediately.</dd> immediately.</dd>
</dl> </dl>
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sec.ccnx" numbered="true" toc="default"> <section anchor="sec.ccnx" numbered="true" toc="default">
<name>Space-efficient Message Encoding for CCNx</name> <name>Space-Efficient Message Encoding for CCNx</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>TLV Encoding</name> <name>TLV Encoding</name>
<t>The generic CCNx TLV encoding is described in <xref target="RFC8609" <t>The generic CCNx TLV encoding is described in <xref target="RFC8609"
format="default"/>. 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 <t>The TLV encoding for CCNx LoWPAN is changed to the more space-efficie
efficient encoding described in <xref target="sec.tlvencoding" format="d nt
efault"/>. 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 numbered="true" toc="default">
<name>Name TLV Compression</name> <name>Name TLV Compression</name>
<t>Name TLVs are compressed using the scheme already defined in <xref ta rget="sec.ndn.namecompression" format="default"/> for NDN. If a Name TLV contain s <t>Name TLVs are compressed using the scheme already defined in <xref ta 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 numbered="true" toc="default">
<name>Interest Messages</name> <name>Interest Messages</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Uncompressed Interest Messages</name> <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" format="default"/>) and sets the C a s well as the M flag to <tt>0</tt>. (see <xref target="fig.disp.base" format="default"/>) and sets the C a nd M flags to <tt>0</tt>.
The P flag is set to <tt>1</tt> (<xref target="fig.ccnx.int.uncompr" f ormat="default"/>). The P flag is set to <tt>1</tt> (<xref target="fig.ccnx.int.uncompr" f 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> <name>Dispatch Format for Uncompressed CCNx Interest Messages</name>
<artwork align="center" name="" type="" alt=""><![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 | 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" numbered="true" toc="default ">
<name>Compressed Interest Messages</name> <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" format="default"/>) and sets the C and P flags to <tt>1</tt>. The M flag is set to <tt>0</tt>. (<xref target="fig.disp.base.compr" format="default"/>) and sets the C and P flags to <tt>1</tt>. The M flag is set to <tt>0</tt>.
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 <bcp14>MUST</bcp14> 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: </t> the following minimal rule set: </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>The version is elided from the fixed header and assumed to be
1.</li>
<li>The Type and Length fields of the CCNx Message TLV are elided <li>The Type and Length fields of the CCNx Message TLV are elided
and are obtained from the Fixed Header on decompression.</li> and are obtained from the fixed header on decompression.</li>
</ol> </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" format="default"/>.</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> <name>Compression of CCNx LoWPAN Interest Message</name>
<artwork align="center" name="" type="" alt=""><![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
skipping to change at line 1199 skipping to change at line 1272
+---------+---------+---------+ +---------+---------+ +---------+---------+---------+ +---------+---------+
: 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" format="default"/>.</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> <name>Dispatch Format for Compressed CCNx Interest Messages</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![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"> <dl newline="true" spacing="normal" indent="4">
<dt>CID: Context Identifier</dt>
<dd><t>See <xref target="fig.disp.base.compr" format="default"/>.</t
></dd>
<dt>EXT: Extension</dt>
<dd>
<t><br/></t>
<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>
<dt>VER: CCNx protocol version in the fixed header</dt>
<dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4">
<dt>0:</dt>
<dd>The Version field equals 1 and is removed
from the fixed header.</dd>
<dt>1:</dt>
<dd>The Version field appears in the fixed header.</dd>
</dl>
</dd>
<dt>FLG: Flags field in the fixed header</dt> <dt>FLG: Flags field in the fixed header</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>The Flags field equals 0 and is removed <dd>The Flags field equals 0 and is removed
from the Interest message.</dd> from the Interest message.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>The Flags field appears in the fixed header.</dd> <dd>The Flags field appears in the fixed header.</dd>
</dl> </dl>
</dd> </dd>
<dt>PTY: PacketType field in the fixed header</dt> <dt>PTY: PacketType field in the fixed header</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>The PacketType field is elided and assumed <dd>The PacketType field is elided and assumed
to be <tt>PT_INTEREST</tt>.</dd> to be <tt>PT_INTEREST</tt>.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>The PacketType field is elided and assumed <dd>The PacketType field is elided and assumed
to be <tt>PT_RETURN</tt>.</dd> to be <tt>PT_RETURN</tt>.</dd>
</dl> </dl>
</dd> </dd>
<dt>HPL: HopLimit field in the fixed header</dt> <dt>HPL: HopLimit field in the fixed header</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>The HopLimit field appears in the fixed header.</dd> <dd>The HopLimit field appears in the fixed header.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>The HopLimit field is elided and assumed to <dd>The HopLimit field is elided and assumed to
be <tt>1</tt>.</dd> be <tt>1</tt>.</dd>
</dl> </dl>
</dd> </dd>
<dt>FRS: Reserved field in the fixed header</dt> <dt>FRS: Reserved field in the fixed header</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>The Reserved field appears in the fixed header.</dd> <dd>The Reserved field appears in the fixed header.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>The Reserved field is elided and assumed to <dd>The Reserved field is elided and assumed to
be <tt>0</tt>.</dd> be <tt>0</tt>.</dd>
</dl> </dl>
</dd> </dd>
<dt>PAY: Optional Payload TLV</dt> <dt>PAY: Optional Payload TLV</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>The Payload TLV is absent.</dd> <dd>The Payload TLV is absent.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>The Payload TLV is present and the type <dd>The Payload TLV is present, and the Type
field is elided.</dd> field is elided.</dd>
</dl> </dl>
</dd> </dd>
<dt>ILT: Optional Hop-By-Hop InterestLifetime TLV</dt> <dt>ILT: Optional hop-by-hop InterestLifetime TLV</dt>
<dd> <dd>
<t><br/></t>
<t>See <xref target="sec.ccnxhbhint" format="default"/> for further details <t>See <xref target="sec.ccnxhbhint" format="default"/> 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"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>No InterestLifetime TLV is present in the <dd>No InterestLifetime TLV is present in the
Interest message.</dd> Interest message.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>An InterestLifetime TLV is present <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 target="sec.compressedtime" format="default described in <xref target="sec.compressedtime" format="default
"/>. The type "/>. The
and length fields are elided.</dd> Type and Length fields are elided.</dd>
</dl> </dl>
</dd> </dd>
<dt>MGH: Optional Hop-By-Hop MessageHash TLV</dt> <dt>MGH: Optional hop-by-hop MessageHash TLV</dt>
<dd> <dd>
<t><br/></t>
<t>See <xref target="sec.ccnxhbhint" format="default"/> for furt her <t>See <xref target="sec.ccnxhbhint" format="default"/> for furt her
details on the ordering of hop-by-hop TLVs.</t> 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 <bcp14>MUST</bcp1 4> 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"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>The MessageHash TLV is absent.</dd> <dd>The MessageHash TLV is absent.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>A T_SHA-256 TLV is present and the type as <dd>A T_SHA-256 TLV is present, and the Type and
well as the length fields are removed. The length field is 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.</dd> is omitted.</dd>
</dl> </dl>
</dd> </dd>
<dt>KIR: Optional KeyIdRestriction TLV</dt> <dt>KIR: Optional KeyIdRestriction TLV</dt>
<dd> <dd>
<t><br/></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 <bcp14>MUST</bcp1 4> 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"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>The KeyIdRestriction TLV is absent.</dd> <dd>The KeyIdRestriction TLV is absent.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>A T_SHA-256 TLV is present and the type as <dd>A T_SHA-256 TLV is present, and the Type and
well as the length fields are removed. The length field is 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.</dd> TLV is omitted.</dd>
</dl> </dl>
</dd> </dd>
<dt>CHR: Optional ContentObjectHashRestriction TLV</dt> <dt>CHR: Optional ContentObjectHashRestriction TLV</dt>
<dd> <dd>
<t><br/></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 <bcp14>MUST</bcp1 4> 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"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>The ContentObjectHashRestriction TLV is <dd>The ContentObjectHashRestriction TLV is
absent.</dd> absent.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>A T_SHA-256 TLV is present and the type as <dd>A T_SHA-256 TLV is present, and the Type and Length fields a
well as the length fields are removed. The length field is re
assumed to represent 32 bytes. The outer removed. The Length field is assumed to represent 32 bytes. The o
ContentObjectHashRestriction TLV is omitted.</dd> uter
ContentObjectHashRestriction TLV is omitted.</dd>
</dl> </dl>
</dd> </dd>
<dt>VAL: Optional ValidationAlgorithm and ValidationPayload TLVs</dt <dt>VAL: Optional ValidationAlgorithm and ValidationPayload
> TLVs</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>No validation related TLVs are present in <dd>No validation-related TLVs are present in
the Interest message.</dd> the Interest message.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>Validation related TLVs are present in the <dd>Validation-related TLVs are present in the
Interest message. An additional byte follows immediately Interest message. An additional byte follows immediately
that handles validation related TLV compressions and is that handles validation-related TLV compressions and is
described in <xref target="sec.ccnx.intval" format="default"/> described in <xref target="sec.ccnx.intval"
.</dd> format="default"/>.</dd>
</dl> </dl>
</dd> </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>
</dl> </dl>
<section anchor="sec.ccnxhbhint" toc="exclude" numbered="true"> <section anchor="sec.ccnxhbhint" toc="exclude" numbered="true">
<name>Hop-By-Hop Header TLVs Compression</name> <name>Hop-By-Hop Header TLVs Compression</name>
<t>Hop-By-Hop Header TLVs are unordered. For an Interest message, <t>Hop-by-hop header TLVs are unordered. For an Interest message,
two optional Hop-By-Hop Header TLVs are defined in <xref target="RFC two optional hop-by-hop header TLVs are defined in <xref
8609" format="default"/>, but several more can be defined in higher target="RFC8609"
level specifications. For the compression specified in the format="default"/>, but several more can be defined in higher-level
previous section, the Hop-By-Hop TLVs are ordered as follows: specifications. For the compression specified in the
previous section, the hop-by-hop TLVs are ordered as follows:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>Interest Lifetime TLV</li> <li>InterestLifetime TLV</li>
<li>Message Hash TLV</li> <li>Message Hash TLV</li>
</ol> </ol>
<t>Note: Other Hop-By-Hop Header TLVs than those two remain <!-- [rfced] Does listing the TLVs improve the readability of the sentence?
uncompressed in the encoded message and they appear in the Should the following TLVs be in 'camel case'? "Message Hash" and "Recommended Ca
same order as in the original message, but after the Interest Lifeti che Time"
me TLV and Message Hash TLV.</t>
Current (Sections 6.3.2.1 and 6.4.2.1):
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.
...
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.
Perhaps:
Note: All hop-by-hop header TLVs other than the InterestLifetime and
MessageHash TLVs remain uncompressed in the encoded message, and they
appear after the InterestLifetime and MessageHash TLVs in the same
order as in the original message.
...
Note: All hop-by-hop header TLVs other than the RecommendedCacheTime
and MessageHash TLVs remain uncompressed in the encoded message, and
they appear after the RecommendedCacheTime and MessageHash TLVs in
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" toc="exclude" numbered="true">
<name>Validation</name> <name>Validation</name>
<figure anchor="fig.ccnx.dispatchintval"> <figure anchor="fig.ccnx.dispatchintval">
<name>Dispatch for Interset Validations</name> <name>Dispatch for Interest Validations</name>
<artwork align="center" name="" type="" alt=""><![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"> <dl newline="true" spacing="normal" indent="4">
<dt>ValidationALg: Optional ValidationAlgorithm TLV</dt> <dt>ValidationAlg: Optional ValidationAlgorithm TLV</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="8"> <dl newline="false" spacing="normal" indent="8">
<dt>0000:</dt> <dt>0000:</dt>
<dd>An uncompressed ValidationAlgorithm <dd>An uncompressed ValidationAlgorithm
TLV is included.</dd> TLV is included.</dd>
<dt>0001:</dt> <dt>0001:</dt>
<dd>A T_CRC32C ValidationAlgorithm TLV is <dd>A T_CRC32C ValidationAlgorithm TLV is
assumed, but no ValidationAlgorithm TLV is included.</dd> assumed, but no ValidationAlgorithm TLV is included.</dd>
<dt>0010:</dt> <dt>0010:</dt>
<dd>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.</dd> a Length field.</dd>
<dt>0011:</dt> <dt>0011:</dt>
<dd>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.</dd> included.</dd>
<dt>0100:</dt> <dt>0100:</dt>
<dd>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.</dd> a Length field.</dd>
<dt>0101:</dt> <dt>0101:</dt>
<dd>Reserved.</dd> <dd>Reserved.</dd>
<dt>0110:</dt> <dt>0110:</dt>
<dd>Reserved.</dd> <dd>Reserved.</dd>
<dt>0111:</dt> <dt>0111:</dt>
<dd>Reserved.</dd> <dd>Reserved.</dd>
<dt>1000:</dt> <dt>1000:</dt>
<dd>Reserved.</dd> <dd>Reserved.</dd>
<dt>1001:</dt> <dt>1001:</dt>
<dd>Reserved.</dd> <dd>Reserved.</dd>
skipping to change at line 1448 skipping to change at line 1533
<dt>1101:</dt> <dt>1101:</dt>
<dd>Reserved.</dd> <dd>Reserved.</dd>
<dt>1110:</dt> <dt>1110:</dt>
<dd>Reserved.</dd> <dd>Reserved.</dd>
<dt>1111:</dt> <dt>1111:</dt>
<dd>Reserved.</dd> <dd>Reserved.</dd>
</dl> </dl>
</dd> </dd>
<dt>KeyID: Optional KeyID TLV within the ValidationAlgorithm TLV</ dt> <dt>KeyID: Optional KeyID TLV within the ValidationAlgorithm TLV</ dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>00:</dt> <dt>00:</dt>
<dd>The KeyId TLV is absent.</dd> <dd>The KeyID TLV is absent.</dd>
<dt>01:</dt> <dt>01:</dt>
<dd>The KeyId TLV is present and <dd>The KeyID TLV is present and
uncompressed.</dd> uncompressed.</dd>
<dt>10:</dt> <dt>10:</dt>
<dd>A T_SHA-256 TLV is present and the type <dd>A T_SHA-256 TLV is present, and the Type
field as well as the length fields are removed. The length and Length fields are removed. The Length
field is assumed to represent 32 bytes. The outer KeyId field is assumed to represent 32 bytes. The outer KeyID
TLV is omitted.</dd> TLV is omitted.</dd>
<dt>11:</dt> <dt>11:</dt>
<dd>A T_SHA-512 TLV is present and the type <dd>A T_SHA-512 TLV is present, and the Type
field as well as the length fields are removed. The length and Length fields are removed. The Length
field is assumed to represent 64 bytes. The outer KeyId field is assumed to represent 64 bytes. The outer KeyID
TLV is omitted.</dd> TLV is omitted.</dd>
</dl> </dl>
</dd> </dd>
<dt>RSV: Reserved</dt> <dt>RSV: Reserved</dt>
<dd>Must be set to 0.</dd> <dd>Must be set to 0.</dd>
</dl> </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" numbered="true" toc="default">
<name>Dispatch Extension</name> <name>Dispatch Extension</name>
<t>The <tt>EXT_0</tt> byte follows the <t>The <tt>EXT_0</tt> byte follows the
description in <xref target="sec.dispatch.ext" format="default"/> and is illustrated description in <xref target="sec.dispatch.ext" format="default"/> and is illustrated
in <xref target="fig.ccnx.interest.ext0" format="default"/>.</t> in <xref target="fig.ccnx.interest.ext0" format="default"/>.</t>
<figure anchor="fig.ccnx.interest.ext0"> <figure anchor="fig.ccnx.interest.ext0">
<name>EXT_0 format</name> <name>EXT_0 Format</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <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"> <dl newline="true" spacing="normal" indent="4">
<dt>NCS: Name Compression Strategy</dt> <dt>NCS: Name Compression Strategy</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>00:</dt> <dt>00:</dt>
<dd>Names are compressed with the default name <dd>Names are compressed with the default name
compression strategy (see <xref target="sec.ndn.namecompressio n" format="default"/>).</dd> compression strategy (see <xref target="sec.ndn.namecompressio n" format="default"/>).</dd>
<dt>01:</dt> <dt>01:</dt>
<dd>Reserved.</dd> <dd>Reserved.</dd>
<dt>10:</dt> <dt>10:</dt>
<dd>Reserved.</dd> <dd>Reserved.</dd>
<dt>11:</dt> <dt>11:</dt>
<dd>Reserved.</dd> <dd>Reserved.</dd>
</dl> </dl>
</dd> </dd>
<dt>RSV: Reserved</dt> <dt>RSV: Reserved</dt>
<dd>Must be set to 0.</dd> <dd>Must be set to 0.</dd>
<dt>EXT: Extension</dt> <dt>EXT: Extension</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>No extension byte follows.</dd> <dd>No extension byte follows.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>A further extension byte follows <dd>A further extension byte follows
immediately.</dd> immediately.</dd>
</dl> </dl>
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Content Objects</name> <name>Content Objects</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Uncompressed Content Objects</name> <name>Uncompressed Content Objects</name>
<t>An uncompressed Content object uses the base dispatch format (see <t>An uncompressed Content Object uses the base dispatch format (see
<xref target="fig.disp.base" format="default"/>) and sets the C flag t <xref target="fig.disp.base" format="default"/>) and sets the C flag t
o <tt>0</tt>, the P and M flags to o
<tt>0</tt> and the P and M flags to
<tt>1</tt> (<xref target="fig.ccnx.data.uncompr" format="default"/>). <tt>1</tt> (<xref target="fig.ccnx.data.uncompr" format="default"/>).
The Content object is handed to the CCNx network stack without modific 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">
<name>Dispatch format for uncompressed CCNx Content objects</name> <name>Dispatch Format for Uncompressed CCNx Content Objects</name>
<artwork align="center" name="" type="" alt=""><![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 numbered="true" toc="default">
<name>Compressed Content Objects</name> <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" format="default"/>) and sets the C (<xref target="fig.disp.base.compr" format="default"/>) and sets the C
, P, as well as the M flag to <tt>1</tt>. , 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
the following compression
rules, then this message <bcp14>MUST</bcp14> be sent uncompressed.</t> 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: </t> base rule set: </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>The PacketType field is elided from the Fixed Header.</li> <li>The version is elided from the fixed header and assumed to be
1.</li>
<li>The PacketType field is elided from the fixed header.</li>
<li>The Type and Length fields of the CCNx Message TLV are elided <li>The Type and Length fields of the CCNx Message TLV are elided
and are obtained from the Fixed Header on decompression.</li> and are obtained from the fixed header on decompression.</li>
</ol> </ol>
<t>The compressed CCNx LoWPAN Data message is visualized in <xref targ et="fig.ccnx.data.newformat" format="default"/>.</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">
<name>Compression of CCNx LoWPAN Data Message</name> <name>Compression of CCNx LoWPAN Data Message</name>
<artwork align="center" name="" type="" alt=""><![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
+-----------------------------+ +-------------------------+ +-----------------------------+ +-------------------------+
skipping to change at line 1587 skipping to change at line 1673
+---------+---------+---------+ +---------+---------+ +---------+---------+---------+ +---------+---------+
: 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" format="default"/>.</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> <name>Dispatch Format for Compressed CCNx Content Objects</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![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"> <dl newline="true" spacing="normal" indent="4">
<dt>CID: Context Identifier</dt>
<dd>See <xref target="fig.disp.base.compr" format="default"/>.</dd>
<dt>EXT: Extension</dt>
<dd>
<t><br/></t>
<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.data.ext0" for
mat="default"/>.</dd>
</dl>
</dd>
<dt>VER: CCNx protocol version in the fixed header</dt>
<dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4">
<dt>0:</dt>
<dd>The Version field equals 1 and is removed
from the fixed header.</dd>
<dt>1:</dt>
<dd>The Version field appears in the fixed header.</dd>
</dl>
</dd>
<dt>FLG: Flags field in the fixed header</dt> <dt>FLG: Flags field in the fixed header</dt>
<dd>See <xref target="sec.ccnxintcompbaseheader" format="default"/>. <dd>See <xref target="sec.ccnxintcompbaseheader"
</dd> format="default"/>.</dd>
<dt>FRS: Reserved field in the fixed header</dt> <dt>FRS: Reserved field in the fixed header</dt>
<dd>See <xref target="sec.ccnxintcompbaseheader" format="default"/>. <dd>See <xref target="sec.ccnxintcompbaseheader"
</dd> format="default"/>.</dd>
<dt>PAY: Optional Payload TLV</dt> <dt>PAY: Optional Payload TLV</dt>
<dd>See <xref target="sec.ccnxintcompbaseheader" format="default"/>. <dd>See <xref target="sec.ccnxintcompbaseheader"
</dd> format="default"/>.</dd>
<dt>RCT: Optional Hop-By-Hop RecommendedCacheTime TLV</dt> <dt>RCT: Optional hop-by-hop Recommended Cache Time TLV</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>The Recommended Cache Time TLV is <dd>The Recommended Cache Time TLV is
absent.</dd> absent.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>The Recommended Cache Time TLV is present <dd>The Recommended Cache Time TLV is present,
and the type as well as the length fields are elided.</dd> and the Type and Length fields are elided.</dd>
</dl> </dl>
</dd> </dd>
<dt>MGH: Optional Hop-By-Hop MessageHash TLV</dt> <dt>MGH: Optional hop-by-hop MessageHash TLV</dt>
<dd> <dd>
<t><br/></t> <t>See <xref target="sec.ccnxhbhdata" format="default"/> for
<t>See <xref target="sec.ccnxhbhdata" format="default"/> for furthe further details on the ordering of hop-by-hop TLVs.</t>
r
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 Content Object <bcp14>MUST</bc another hash is contained, then the Content Object
p14> be <bcp14>MUST</bcp14> be sent uncompressed.</t>
sent uncompressed.</t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>The MessageHash TLV is absent.</dd> <dd>The MessageHash TLV is absent.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>A T_SHA-256 TLV is present and the type as <dd>A T_SHA-256 TLV is present, and the Type and
well as the length fields are removed. The length field is 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.</dd> is omitted.</dd>
</dl> </dl>
</dd> </dd>
<dt/> <dt/>
<dd> <dd>
<dl newline="true" spacing="normal" indent="4"> <dl newline="true" spacing="normal" indent="4">
<dt>PLTYP: Optional PayloadType TLV</dt> <dt>PLTYP: Optional PayloadType TLV</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>00:</dt> <dt>00:</dt>
<dd>The PayloadType TLV is absent.</dd> <dd>The PayloadType TLV is absent.</dd>
<dt>01:</dt> <dt>01:</dt>
<dd>The PayloadType TLV is absent and <dd>The PayloadType TLV is absent, and
T_PAYLOADTYPE_DATA is assumed.</dd> T_PAYLOADTYPE_DATA is assumed.</dd>
<dt>10:</dt> <dt>10:</dt>
<dd>The PayloadType TLV is absent and <dd>The PayloadType TLV is absent, and
T_PAYLOADTYPE_KEY is assumed.</dd> T_PAYLOADTYPE_KEY is assumed.</dd>
<dt>11:</dt> <dt>11:</dt>
<dd>The PayloadType TLV is present and <dd>The PayloadType TLV is present and
uncompressed.</dd> uncompressed.</dd>
</dl> </dl>
</dd> </dd>
</dl> </dl>
</dd> </dd>
<dt>EXP: Optional ExpiryTime TLV</dt> <dt>EXP: Optional ExpiryTime TLV</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>The ExpiryTime TLV is absent.</dd> <dd>The ExpiryTime TLV is absent.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>The ExpiryTime TLV is present and the type <dd>The ExpiryTime TLV is present, and the Type
as well as the length fields are elided.</dd> and Length fields are elided.</dd>
</dl> </dl>
</dd> </dd>
<dt>VAL: Optional ValidationAlgorithm and ValidationPayload TLVs</dt <dt>VAL: Optional ValidationAlgorithm and ValidationPayload
> TLVs</dt>
<dd>See <dd>See
<xref target="sec.ccnxintcompbaseheader" format="default"/>.</dd> <xref target="sec.ccnxintcompbaseheader" format="default"/>.</dd>
<dt>RSV: Reserved</dt> <dt>RSV: Reserved</dt>
<dd>Must be set to 0.</dd> <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.ccnx.data.ext0" for
mat="default"/>.</dd>
</dl>
</dd>
</dl> </dl>
<section anchor="sec.ccnxhbhdata" toc="exclude" numbered="true"> <section anchor="sec.ccnxhbhdata" toc="exclude" numbered="true">
<name>Hop-By-Hop Header TLVs Compression</name> <name>Hop-By-Hop Header TLVs Compression</name>
<t>Hop-By-Hop Header TLVs are unordered. For a Content Object <t>Hop-by-hop header TLVs are unordered. For a Content Object
message, two optional Hop-By-Hop Header TLVs are defined in <xref ta message, two optional hop-by-hop header TLVs are defined in
rget="RFC8609" format="default"/>, but several more can be defined in higher <xref target="RFC8609" format="default"/>, but several more can be de
level specifications. For the compression specified in the fined in
previous section, the Hop-By-Hop TLVs are ordered as follows: higher-level specifications. For the compression specified in the
previous section, the hop-by-hop TLVs are ordered as follows:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>Recommended Cache Time TLV</li> <li>Recommended Cache Time TLV</li>
<li>Message Hash TLV</li> <li>Message Hash TLV</li>
</ol> </ol>
<t>Note: Other Hop-By-Hop Header TLVs than those two remain <t>Note: Other hop-by-hop header TLVs than those two remain
uncompressed in the encoded message and they appear in the uncompressed in the encoded message, and they appear in the
same order as in the original message, but after the Recommended Cac same order as in the original message but after the Recommended Cach
he Time TLV and Message Hash TLV.</t> 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" numbered="true" toc="default">
<name>Dispatch Extension</name> <name>Dispatch Extension</name>
<t>The <tt>EXT_0</tt> byte follows the <t>The <tt>EXT_0</tt> byte follows the
description in <xref target="sec.dispatch.ext" format="default"/> and is illustrated description in <xref target="sec.dispatch.ext" format="default"/> and is illustrated
in <xref target="fig.ccnx.data.ext0" format="default"/>.</t> in <xref target="fig.ccnx.data.ext0" format="default"/>.</t>
<figure anchor="fig.ccnx.data.ext0"> <figure anchor="fig.ccnx.data.ext0">
<name>EXT_0 format</name> <name>EXT_0 Format</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <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"> <dl newline="true" spacing="normal" indent="4">
<dt>NCS: Name Compression Strategy</dt> <dt>NCS: Name Compression Strategy</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>00:</dt> <dt>00:</dt>
<dd>Names are compressed with the default name <dd>Names are compressed with the default name
compression strategy (see <xref target="sec.ndn.namecompressio n" format="default"/>).</dd> compression strategy (see <xref target="sec.ndn.namecompressio n" format="default"/>).</dd>
<dt>01:</dt> <dt>01:</dt>
<dd>Reserved.</dd> <dd>Reserved.</dd>
<dt>10:</dt> <dt>10:</dt>
<dd>Reserved.</dd> <dd>Reserved.</dd>
<dt>11:</dt> <dt>11:</dt>
<dd>Reserved.</dd> <dd>Reserved.</dd>
</dl> </dl>
</dd> </dd>
<dt>RSV: Reserved</dt> <dt>RSV: Reserved</dt>
<dd>Must be set to 0.</dd> <dd>Must be set to 0.</dd>
<dt>EXT: Extension</dt> <dt>EXT: Extension</dt>
<dd> <dd>
<t><br/></t>
<dl newline="false" spacing="normal" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>0:</dt> <dt>0:</dt>
<dd>No extension byte follows.</dd> <dd>No extension byte follows.</dd>
<dt>1:</dt> <dt>1:</dt>
<dd>A further extension byte follows <dd>A further extension byte follows
immediately.</dd> immediately.</dd>
</dl> </dl>
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sec.compressedtime" numbered="true" toc="default"> <section anchor="sec.compressedtime" numbered="true" toc="default">
<name>Compressed Time Encoding</name> <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 <xref target="RFC5497" section="5" sec tionFormat="of" format="default"/> with the constant factor <tt>C</tt> set to <t t>C := relative time-values described in <xref target="RFC5497" section="5" sec tionFormat="of" format="default"/> with the constant factor <tt>C</tt> set to <t t>C :=
1/32</tt>. 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" format="default"/> for time-codes with expo nent <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):
</t> </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Subnormal (b == 0):</dt> <dt>Subnormal (b == 0):</dt>
<dd> (0 + a/8) * 2 * C <dd> (0 + a/8) * 2 * C
</dd> </dd>
<dt>Normalized (b &gt; 0):</dt> <dt>Normalized (b &gt; 0):</dt>
<dd> (1 + a/8) * 2^b * C (see <xref target="RFC5497" format="default"/>) <dd> (1 + a/8) * 2<sup>b</sup> * C (see <xref target="RFC5497" format="d efault"/>)
</dd> </dd>
</dl> </dl>
<t> <t>This configuration allows for the following ranges:</t>
<ul spacing="compact">
This configuration allows for the following ranges: <li>Minimum subnormal number: 0 seconds</li>
<li>2nd minimum subnormal number: ~0.007812 seconds</li>
</t> <li>Maximum subnormal number: ~0.054688 seconds</li>
<dl newline="false" spacing="compact"> <li>Minimum normalized number: ~0.062500 seconds</li>
<dt>Minimum subnormal number:</dt> <li>2nd minimum normalized number: ~0.070312 seconds</li>
<dd>0 seconds</dd> <li>Maximum normalized number: ~3.99 years</li>
<dt>2nd minimum subnormal number:</dt> </ul>
<dd>~0.007812 seconds</dd>
<dt>Maximum subnormal number:</dt>
<dd>~0.054688 seconds</dd>
<dt>Minimum normalized number:</dt>
<dd>~0.062500 seconds</dd>
<dt>2nd minimum normalized number:</dt>
<dd>~0.070312 seconds</dd>
<dt>Maximum normalized number:</dt>
<dd>~3.99 years</dd>
</dl>
<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 <bcp14>MUST</bcp14> be set to the largest valid time-value th at 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" numbered="true" toc="default">
<name>Stateful Header Compression</name> <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" numbered="true" toc="default" >
<name>LoWPAN-local State</name> <name>LoWPAN-Local State</name>
<t>A context identifier (CID) is a byte that refers to a particular <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 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">
<name>Context Identifier.</name> <name>Context Identifier</name>
<artwork align="center" name="" type="" alt=""><![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 contextual state shared between sender and receiver of the represents the contextual state shared between the sender and receiver o
f the
corresponding frame (see <xref target="fig.cid" format="default"/>). corresponding frame (see <xref target="fig.cid" format="default"/>).
If set the most significant bit indicates the presence of another, subse quent If set, the most significant bit indicates the presence of another, subs equent
ContextID byte (see <xref target="fig.cid.chain" format="default"/>).</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 <bc p14>MUST</bcp14> 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 lt"> <section anchor="stateful.compression.en-route" numbered="true" toc="defau lt">
<name>En-route State</name> <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 ocal" format="default"/>) of link-local scope as shown in <xref target="fig.hopi d" format="default"/>.</t> carried as Context Identifiers (see <xref target="stateful.compression.l ocal" format="default"/>) of link-local scope, as shown in <xref target="fig.hop id" format="default"/>.</t>
<figure anchor="fig.hopid"> <figure anchor="fig.hopid">
<name>Context Identifier as HopID.</name> <name>Context Identifier as HopID</name>
<artwork align="center" name="" type="" alt=""><![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 <bcp14>MUST</bcp14> be sent without en-route sta te 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) <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> be uni HopID that is tied to a Pending Interest Table (PIT) entry. Each HopID
que within <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 targe t="fig.enroute-a" format="default"/>). </t> new HopID is stored in the HIDo column of the local PIT (see <xref targe t="fig.enroute-a" format="default"/>). </t>
<figure anchor="fig.enroute-a"> <figure anchor="fig.enroute-a">
<name>Setting compression state en-route (Interest).</name> <name>Setting Compression State En-Route (Interest)</name>
<artwork align="center" name="" type="" alt=""><![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 | |
+--------+------++------+------+ +--------+------++------+------+ +--------+------++------+------+ +--------+------++------+------+
^ | ^ ^ | ^
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> </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" format="default"/>). </t> the response (<xref target="fig.enroute-b" format="default"/>). </t>
<figure anchor="fig.enroute-b"> <figure anchor="fig.enroute-b">
<name>Eliding Name TLVs using en-route state (data).</name> <name>Eliding Name TLVs Using En-Route State (Data)</name>
<artwork align="center" name="" type="" alt=""><![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
skipping to change at line 1939 skipping to change at line 2018
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 numbered="true" toc="default">
<name>Integrating Stateful Header Compression</name> <name>Integrating Stateful Header Compression</name>
<t>A CID appears whenever the CID flag is set (see <xref target="fig.dis p.base.compr" format="default"/>). The CID is appended to the last ICN <t>A CID appears whenever the CID flag is set (see <xref target="fig.dis p.base.compr" format="default"/>). The CID is appended to the last ICN
LoWPAN dispatch byte as shown in <xref target="fig.cid.loc" format="defa ult"/>.</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">
<name>LoWPAN Encapsulation with ICN LoWPAN and CIDs</name> <name>LoWPAN Encapsulation with ICN LoWPAN and CIDs</name>
<artwork align="center" name="" type="" alt=""><![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"?
Current:
Multiple CIDs are chained together, with the most significant bit
indicating the presence of a subsequent CID (Figure 33). This allows
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 <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> 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> <name>Chaining of Context Identifiers</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1| CID / HopID | --> |1| CID | --> |0| CID | |1| CID / HopID | --> |1| CID | --> |0| CID |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="sec.ndn.constvars" numbered="true" toc="default"> <section anchor="sec.ndn.constvars" numbered="true" toc="default">
<name>ICN LoWPAN Constants and Variables</name> <name>ICN LoWPAN Constants and Variables</name>
<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. </t>
<dl newline="false" spacing="normal" indent="8"> <dl newline="false" spacing="normal" indent="8">
<dt>DEFAULT_NDN_HOPLIMIT:</dt> <dt>DEFAULT_NDN_HOPLIMIT:</dt>
<dd>255</dd> <dd>255</dd>
</dl> </dl>
</section> </section>
<section anchor="implementationnotice" numbered="true" toc="default"> <section anchor="implementationnotice" numbered="true" toc="default">
<name>Implementation Report and Guidance</name> <name>Implementation Report and Guidance</name>
<!-- [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" format ="default"/> in an extension of the NDN/CCNx software stack <xref target="CCN-LITE" format ="default"/> in
its IoT version on RIOT <xref target="RIOT" format="default"/>. An experim ental its IoT version on RIOT <xref target="RIOT" format="default"/>. An experim ental
evaluation for NDN over ICN LOWPAN with varying configurations has been evaluation for NDN over ICN LoWPAN with varying configurations has been
performed in <xref target="ICNLOWPAN" format="default"/>. Energy profiling performed in <xref target="ICNLOWPAN" format="default"/>. Energy profilin
s and g and
processing time measurements indicate significant energy savings, while 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 numbered="true" toc="default">
<name>Preferred Configuration</name> <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: </t> configurations. It works best for the following cases: </t>
<ul spacing="normal"> <ul spacing="normal">
<li>Signed time offsets compress as per <xref target="sec.compressedti <li>Signed time offsets compress, per <xref target="sec.compressedtime
me" format="default"/> without the need for "
rounding.</li> format="default"/>, without the need for rounding.</li>
<li>Contextual state (e.g., prefixes) is distributed, such that <li>The contextual state (e.g., prefixes) is distributed such that
long names can be elided from Interest and data messages.</li> long names can be elided from Interest and Data messages.</li>
<li>Frequently used TLV type numbers for CCNx and NDN stay <li>Frequently used TLV type numbers for CCNx and NDN stay
in the lower range (&lt; 255).</li> in the lower range (&lt; 255).</li>
</ul> </ul>
<t> <t>
Name components are of GenericNameComponent type and are limited to a Name components are of type GenericNameComponent 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 numbered="true" toc="default">
<name>Further Experimental Deployments</name> <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:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The name compression scheme (<xref target="sec.ndn.namecompression " format="default"/>) is optimized for short <li>The name compression scheme (<xref target="sec.ndn.namecompression " format="default"/>) is optimized for short
name components of GenericNameComponent type. An empirical 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" format="default"/>). As a prelim inary (<xref target="sec.ndn.interest.ext0" format="default"/>). As a prelim inary
analysis, <xref target="ICNLOWPAN" format="default"/> investigates the 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 target="RFC7252" format=" default"/> deployments can offer additional insights obtained from the WWW. Studies on deployments of Constrained Applicati on Protocol (CoAP) <xref target="RFC7252" format="default"/> can offer additiona l insights
on naming schemes in the IoT.</li> on naming schemes in the IoT.</li>
<li>The fragmentation scheme (<xref target="sec.Fragmentation" format= "default"/>) inherited from 6LoWPAN allows <li>The fragmentation scheme (<xref target="sec.Fragmentation" format= "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 target="RFC8930" format="default"/> with selective packets. Fragment forwarding <xref target="RFC8930" format="default"/> with selective
fragment recovery <xref target="RFC8931" format="default"/> can improv e the fragment recovery <xref target="RFC8931" format="default"/> can improv 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 target="SFR-ICN requirements on forwarders. Initial evaluations <xref target="SFR-ICNL
LOWPAN" format="default"/>) 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.
</li> </li>
<li>Context state (<xref target="stateful.compression.local" format="d <li>The context state (<xref target="stateful.compression.local"
efault"/>) holds information format="default"/>) 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.</li> features is necessary to identify other protocol fields.</li>
<li>The distribution and synchronization of contextual state <li>The distribution and synchronization of the contextual state
can potentially be adopted from <xref target="RFC6775" section="7.2" s can potentially be adopted from <xref target="RFC6775" section="7.2" s
ectionFormat="of" format="default"/>, but requires further evaluations. While ectionFormat="of" format="default"/> 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.</li> configurations.</li>
<li>The stateful en-route compression (<xref target="stateful.compress ion.en-route" format="default"/>) supports a limited <li>The stateful en-route compression (<xref target="stateful.compress ion.en-route" format="default"/>) 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.</li> additional header overhead.</li>
<li>Multiple implementations that generate and deploy the <li>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.</li> interoperability with other implementations.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="security.considerations" numbered="true" toc="default"> <section anchor="security.considerations" numbered="true" toc="default">
<name>Security Considerations</name> <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" format="default"/> can potentially prevent fragment buffer saturation in forwarders.</t> <xref target="RFC8930" format="default"/> can potentially prevent fragment 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" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Reserving Space in the 6LoWPAN Dispatch Type Field Registry</name> <name>Updates to the 6LoWPAN Dispatch Type Field Registry</name>
<t>IANA has assigned dispatch values of the <tt>6LoWPAN Dispatch Type Fi <t>IANA has assigned dispatch values for ICN LoWPAN in the "Dispatch Typ
eld</tt> e Field"
registry <xref target="RFC4944" format="default"/><xref target="RFC8025" subregistry <xref target="RFC4944" format="default"/> <xref target="RFC8
format="default"/> with Page 025" format="default"/> of
TBD1 for ICN LoWPAN. <xref target="tab.iana.dispatches" format="default" the "IPv6 Low Power Personal Area Network Parameters" registry.
/> represents updates to the registry.</t> <xref target="tab.iana.dispatches" format="default"/> represents the upd
ates to the registry.</t>
<table anchor="tab.iana.dispatches" align="center"> <table anchor="tab.iana.dispatches" align="center">
<name>Dispatch types for NDN and CCNx with page TBD1.</name> <name>Dispatch Types for NDN and CCNx Dispatch Types with Page 14</nam e>
<thead> <thead>
<tr> <tr>
<th align="center">Bit Pattern</th> <th align="center">Bit Pattern</th>
<th align="center">Page</th> <th align="center">Page</th>
<th align="left">Header Type</th> <th align="left">Header Type</th>
<th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">00 000000</td> <td align="center">00 000000</td>
<td align="center">TBD1</td> <td align="center">14</td>
<td align="left">Uncompressed NDN Interest messages</td> <td align="left">Uncompressed NDN Interest messages</td>
<td align="left">RFC 9139</td>
</tr> </tr>
<tr> <tr>
<td align="center">00 100000</td> <td align="center">00 01xxxx</td>
<td align="center">TBD1</td> <td align="center">14</td>
<td align="left">Uncompressed NDN Data messages</td> <td align="left">Compressed NDN Interest messages</td>
<td align="left">RFC 9139</td>
</tr> </tr>
<tr> <tr>
<td align="center">01 000000</td> <td align="center">00 100000</td>
<td align="center">TBD1</td> <td align="center">14</td>
<td align="left">Uncompressed CCNx Interest messages</td> <td align="left">Uncompressed NDN Data messages</td>
<td align="left">RFC 9139</td>
</tr> </tr>
<tr> <tr>
<td align="center">01 100000</td> <td align="center">00 11xxxx</td>
<td align="center">TBD1</td> <td align="center">14</td>
<td align="left">Uncompressed CCNx Content Object messages</td> <td align="left">Compressed NDN Data messages</td>
<td align="left">RFC 9139</td>
</tr> </tr>
<tr> <tr>
<td align="center">10 0xxxxx</td> <td align="center">01 000000</td>
<td align="center">TBD1</td> <td align="center">14</td>
<td align="left">Compressed NDN Interest messages</td> <td align="left">Uncompressed CCNx Interest messages</td>
<td align="left">RFC 9139</td>
</tr> </tr>
<tr> <tr>
<td align="center">10 1xxxxx</td> <td align="center">01 01xxxx</td>
<td align="center">TBD1</td> <td align="center">14</td>
<td align="left">Compressed NDN Data messages</td> <td align="left">Compressed CCNx Interest messages</td>
<td align="left">RFC 9139</td>
</tr> </tr>
<tr> <tr>
<td align="center">11 0xxxxx</td> <td align="center">01 100000</td>
<td align="center">TBD1</td> <td align="center">14</td>
<td align="left">Compressed CCNx Interest messages</td> <td align="left">Uncompressed CCNx Content Object messages</td>
<td align="left">RFC 9139</td>
</tr> </tr>
<tr> <tr>
<td align="center">11 1xxxxx</td> <td align="center">01 11xxxx</td>
<td align="center">TBD1</td> <td align="center">14</td>
<td align="left">Compressed CCNx Content Object messages</td> <td align="left">Compressed CCNx Content Object messages</td>
<td align="left">RFC 9139</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.irtf-icnrg-flic" to="ICNRG-FLIC"/> <displayreference target="I-D.irtf-icnrg-flic" to="ICNRG-FLIC"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <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.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.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.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.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.6282.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.6775.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.6775.xml"/>
<!-- [rfced] [ieee802.15.4] The URL below is correct. The full title is "IEEE 80 <!-- [rfced] The following reference has be superceded by a 2020 version. Should
2.15.4-2015 - IEEE Standard for Low-Rate Wireless Networks" --> it be updated to reflect this?
Original:
[ieee802.15.4]
"IEEE Std. 802.15.4-2015", April 2016,
<https://standards.ieee.org/findstds/
standard/802.15.4-2015.html>.
-->
-&gt;
<reference anchor="ieee802.15.4" target="https://standards.ieee.org/find stds/standard/802.15.4-2015.html"> <reference anchor="ieee802.15.4" target="https://standards.ieee.org/find stds/standard/802.15.4-2015.html">
<front> <front>
<title>IEEE Std. 802.15.4-2015</title> <title>IEEE Standard for Low-Rate Wireless
<author surname="IEEE Computer Society"/> Networks</title>
<date month="April" year="2016"/> <author><organization>IEEE</organization></author>
</front> </front>
<seriesInfo name="IEEE Std" value="802.15.4-2015"/>
</reference> </reference>
<!-- [rfced] [IEEE.754.2019] The URL below is correct. The full title is "IEEE
754-2019 - IEEE Standard for Floating-Point Arithmetic" -->
<reference anchor="IEEE.754.2019" target="https://standards.ieee.org/con tent/ieee-standards/en/standard/754-2019.html"> <reference anchor="IEEE.754.2019" target="https://standards.ieee.org/con tent/ieee-standards/en/standard/754-2019.html">
<front> <front>
<title>Standard for Floating-Point Arithmetic</title> <title>IEEE Standard for Floating-Point Arithmetic</title>
<author initials="" fullname="" surname="Institute of Electrical and <author><organization>IEEE</organization></author>
Electronics Engineers, C/MSC - Microprocessor Standards Committee"/>
<date month="June" year="2019"/>
</front> </front>
<seriesInfo name="IEEE Std" value="754-2019"/>
</reference> </reference>
</references> </references>
<references> <references>
<name>Informative References</name> <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.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.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.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.7945.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7228.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.7400"?>-->
<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.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.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.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.8930.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8931.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8931.xml"/>
<!-- [rfced] [I-D.irtf-icnrg-flic] IESG state Expired --> <!-- [I-D.irtf-icnrg-flic] IESG state Expired, long way used to capture editor i nfo -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D <reference anchor="I-D.irtf-icnrg-flic">
.irtf-icnrg-flic.xml"/> <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>
<!-- [rfced] [CCN-LITE] Please review. Server timed out when trying to connect. <!-- [rfced] We are having trouble accessing the URL from the reference below.
Unable to find another URL --> Please review.
[CCN-LITE]
"CCN-lite: A lightweight CCNx and NDN implementation",
<http://ccn-lite.net/>.
-->
-&gt;
<reference anchor="CCN-LITE" target="http://ccn-lite.net/"> <reference anchor="CCN-LITE" target="http://ccn-lite.net/">
<front> <front>
<title>CCN-lite: A lightweight CCNx and NDN implementation</title> <title>CCN-lite: A lightweight CCNx and NDN implementation</title>
<author/> <author/>
<date/>
</front> </front>
</reference> </reference>
<!-- [rfced] [RIOT] The URL below is correct. Also found URL https://ieeexplore
.ieee.org/abstract/document/8315125 -->
<reference anchor="RIOT" target="https://doi.org/10.1109/JIOT.2018.28150 38"> <reference anchor="RIOT" target="https://doi.org/10.1109/JIOT.2018.28150 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"> <author initials="E." surname="Baccelli">
<organization>INRIA</organization> <organization>INRIA</organization>
</author> </author>
<author initials="C." surname="Gundogan"> <author initials="C." surname="Gündoğan">
<organization>HAW Hamburg</organization> <organization>HAW Hamburg</organization>
</author> </author>
<author initials="O." surname="Hahm"> <author initials="O." surname="Hahm">
<organization>INRIA and FU Berlin</organization> <organization>INRIA and FU Berlin</organization>
</author> </author>
<author initials="P." surname="Kietzmann"> <author initials="P." surname="Kietzmann">
<organization>HAW Hamburg</organization> <organization>HAW Hamburg</organization>
</author> </author>
<author initials="MS." surname="Lenders"> <author initials="MS." surname="Lenders">
<organization>FU Berlin</organization> <organization>FU Berlin</organization>
</author> </author>
<author initials="H." surname="Petersen"> <author initials="H." surname="Petersen">
<organization>FU Berlin</organization> <organization>FU Berlin</organization>
</author> </author>
<author initials="K." surname="Schleiser"> <author initials="K." surname="Schleiser">
<organization>INRIA and FU Berlin</organization> <organization>INRIA and FU Berlin</organization>
</author> </author>
<author initials="TC." surname="Schmidt"> <author initials="TC." surname="Schmidt">
<organization>HAW Hamburg</organization> <organization>HAW Hamburg</organization>
</author> </author>
<author initials="M." surname="Waehlisch"> <author initials="M." surname="Wählisch">
<organization>FU Berlin</organization> <organization>FU Berlin</organization>
</author> </author>
<date month="December" year="2018"/> <date month="December" year="2018"/>
</front> </front>
<seriesInfo name="IEEE Internet of Things Journal" value="Vol. 5, No. <refcontent>IEEE Internet of Things Journal Vol. 5, No. 6, p.
6, p. 4428-4440"/> 4428-4440</refcontent>
</reference> </reference>
<!-- [rfced] [NDN-EXP1] The URL below is correct. Also found URL https://dl.acm
.org/doi/10.1145/2660129.2660144 -->
<reference anchor="NDN-EXP1" target="http://dx.doi.org/10.1145/2660129.2 660144"> <reference anchor="NDN-EXP1" target="http://dx.doi.org/10.1145/2660129.2 660144">
<front> <front>
<title>Information Centric Networking in the IoT: Experiments with <title>Information centric networking in the IoT: experiments with
NDN in the Wild</title> NDN in the wild</title>
<author initials="E." surname="Baccelli"> <author initials="E." surname="Baccelli">
<organization>INRIA</organization> <organization>INRIA</organization>
</author> </author>
<author initials="C." surname="Mehlis"> <author initials="C." surname="Mehlis">
<organization>FU Berlin</organization> <organization>FU Berlin</organization>
</author> </author>
<author initials="O." surname="Hahm"> <author initials="O." surname="Hahm">
<organization>INRIA</organization> <organization>INRIA</organization>
</author> </author>
<author initials="TC." surname="Schmidt"> <author initials="TC." surname="Schmidt">
<organization>HAW Hamburg</organization> <organization>HAW Hamburg</organization>
</author> </author>
<author initials="M." surname="Waehlisch"> <author initials="M." surname="Wählisch">
<organization>FU Berlin</organization> <organization>FU Berlin</organization>
</author> </author>
<date month="September" year="2014"/> <date month="September" year="2014"/>
</front> </front>
<seriesInfo name="Proc. of 1st ACM Conf. on Information-Centric Networ <refcontent>Proc. of 1st ACM Conf. on Information-Centric Networking (
king (ICN-2014)" value="ACM DL, pp. 77-86"/> ICN-2014)
ACM DL, pp. 77-86</refcontent>
</reference> </reference>
<!-- [rfced] [NDN-EXP2] The URL below is correct. Also found URL https://dl.acm
.org/doi/10.1145/3267955.3267967 -->
<reference anchor="NDN-EXP2" target="https://doi.org/10.1145/3267955.326 7967"> <reference anchor="NDN-EXP2" target="https://doi.org/10.1145/3267955.326 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="Gundogan"> <author initials="C." surname="Gündoğan">
<organization>HAW Hamburg</organization> <organization>HAW Hamburg</organization>
</author> </author>
<author initials="P." surname="Kietzmann"> <author initials="P." surname="Kietzmann">
<organization>HAW Hamburg</organization> <organization>HAW Hamburg</organization>
</author> </author>
<author initials="M." surname="Lenders"> <author initials="M." surname="Lenders">
<organization>FU Berlin</organization> <organization>FU Berlin</organization>
</author> </author>
<author initials="H." surname="Petersen"> <author initials="H." surname="Petersen">
<organization>FU Berlin</organization> <organization>FU Berlin</organization>
</author> </author>
<author initials="TC." surname="Schmidt"> <author initials="TC." surname="Schmidt">
<organization>HAW Hamburg</organization> <organization>HAW Hamburg</organization>
</author> </author>
<author initials="M." surname="Waehlisch"> <author initials="M." surname="Wählisch">
<organization>FU Berlin</organization> <organization>FU Berlin</organization>
</author> </author>
<date month="September" year="2018"/> <date month="September" year="2018"/>
</front> </front>
<seriesInfo name="Proc. of 5th ACM Conf. on Information-Centric Networ <refcontent>Proc. of 5th ACM Conf. on Information-Centric Networking (
king (ICN-2018)" value="ACM DL, pp. 159-171"/> ICN-2018)
ACM DL, pp. 159-171</refcontent>
</reference> </reference>
<!-- [rfced] [NDN-MAC] The URL below is correct. Also found URL https://dl.acm.
org/doi/10.1145/3125719.3125737. Please note the different capitalization of th
e title "The need for a name to MAC address mapping in NDN: towards quantifying
the resource gain" -->
<reference anchor="NDN-MAC" target="https://doi.org/10.1145/3125719.3125 737"> <reference anchor="NDN-MAC" target="https://doi.org/10.1145/3125719.3125 737">
<front> <front>
<title>The Need for a Name to MAC Address Mapping in NDN: Towards <title>The need for a name to MAC address mapping in NDN: towards
Quantifying the Resource Gain</title> quantifying the resource gain</title>
<author initials="P." surname="Kietzmann"> <author initials="P." surname="Kietzmann">
<organization>HAW Hamburg</organization> <organization>HAW Hamburg</organization>
</author> </author>
<author initials="C." surname="Gundogan"> <author initials="C." surname="Gündoğan">
<organization>HAW Hamburg</organization> <organization>HAW Hamburg</organization>
</author> </author>
<author initials="TC." surname="Schmidt"> <author initials="TC." surname="Schmidt">
<organization>HAW Hamburg</organization> <organization>HAW Hamburg</organization>
</author> </author>
<author initials="O." surname="Hahm"> <author initials="O." surname="Hahm">
<organization>riot-os.org</organization> <organization>riot-os.org</organization>
</author> </author>
<author initials="M." surname="Waehlisch"> <author initials="M." surname="Wählisch">
<organization>FU Berlin</organization> <organization>FU Berlin</organization>
</author> </author>
<date month="September" year="2017"/> <date month="September" year="2017"/>
</front> </front>
<seriesInfo name="Proc. of 4th ACM Conf. on Information-Centric Networ <refcontent>Proc. of 4th ACM Conf. on Information-Centric Networking (
king (ICN-2017)" value="ACM DL, pp. 36-42"/> ICN-2017)
ACM DL, pp. 36-42</refcontent>
</reference> </reference>
<!-- [rfced] [SFR-ICNLOWPAN] The URL below is correct. Also found URL https://d
l.acm.org/doi/10.1145/3405656.3418719 -->
<reference anchor="SFR-ICNLOWPAN" target="https://doi.org/10.1145/340565 6.3418719"> <reference anchor="SFR-ICNLOWPAN" target="https://doi.org/10.1145/340565 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"> <author initials="M." surname="Lenders">
<organization>FU Berlin</organization> <organization>FU Berlin</organization>
</author> </author>
<author initials="C." surname="Gundogan"> <author initials="C." surname="Gündoğan">
<organization>HAW Hamburg</organization> <organization>HAW Hamburg</organization>
</author> </author>
<author initials="TC." surname="Schmidt"> <author initials="TC." surname="Schmidt">
<organization>HAW Hamburg</organization> <organization>HAW Hamburg</organization>
</author> </author>
<author initials="M." surname="Waehlisch"> <author initials="M." surname="Wählisch">
<organization>FU Berlin</organization> <organization>FU Berlin</organization>
</author> </author>
<date month="September" year="2020"/> <date month="September" year="2020"/>
</front> </front>
<seriesInfo name="Proc. of 7th ACM Conf. on Information-Centric Networ <refcontent>Proc. of 7th ACM Conf. on Information-Centric Networking (
king (ICN-2020)" value="ACM DL, pp. 70-76"/> ICN-2020)
ACM DL, pp. 70-76</refcontent>
</reference> </reference>
<!-- [rfced] [NDN] The URL below is correct. Also found URL https://dl.acm.org/
doi/10.1145/1658939.1658941. Please review - two authors are missing Nicholas H
. Briggs and Rebecca L. Braynard -->
<reference anchor="NDN" target="https://doi.org/10.1145/1658939.1658941" > <reference anchor="NDN" target="https://doi.org/10.1145/1658939.1658941" >
<front> <front>
<title>Networking Named Content</title> <title>Networking named content</title>
<author initials="V." surname="Jacobson"/> <author initials="V." surname="Jacobson"/>
<author initials="D." surname="Smetters"/> <author initials="D." surname="Smetters"/>
<author initials="J." surname="Thornton"/> <author initials="J." surname="Thornton"/>
<author initials="M." surname="Plass"/> <author initials="M." surname="Plass"/>
<date year="2009"/> <author initials="N." surname="Briggs"/>
<author initials="R." surname="Braynard"/>
<date month="December" year="2009"/>
</front> </front>
<seriesInfo name="5th Int. Conf. on emerging Networking Experiments an <refcontent>5th Int. Conf. on emerging Networking Experiments and Tech
d Technologies" value="(ACM CoNEXT)"/> nologies
(ACM CoNEXT)</refcontent>
</reference> </reference>
<!-- [rfced] [NDN-PACKET-SPEC] The URL below is correct -->
<reference anchor="NDN-PACKET-SPEC" target="https://named-data.net/doc/N DN-packet-spec/0.3/"> <reference anchor="NDN-PACKET-SPEC" target="https://named-data.net/doc/N DN-packet-spec/0.3/">
<front> <front>
<title>NDN Packet Format Specification</title> <title>NDN Packet Format Specification</title>
<author/> <author/>
<date/>
</front> </front>
</reference> </reference>
<!-- [rfced] [TLV-ENC-802.15.4] The URL below is correct -->
<reference anchor="TLV-ENC-802.15.4" target="https://datatracker.ietf.or g/meeting/interim-2015-icnrg-01/materials/slides-interim-2015-icnrg-1-2"> <reference anchor="TLV-ENC-802.15.4" target="https://datatracker.ietf.or g/meeting/interim-2015-icnrg-01/materials/slides-interim-2015-icnrg-1-2">
<front> <front>
<title>CCN and NDN TLV encodings in 802.15.4 packets</title> <title>CCN and NDN TLV encodings in 802.15.4 packets</title>
<author/> <author initials="M." surname="Mosko"/>
<date/> <author initials="C." surname="Tschudin"/>
<date month="January" year="2015"/>
</front> </front>
</reference> </reference>
<!-- [rfced] [WIRE-FORMAT-CONSID] The URL below is correct-->
<reference anchor="WIRE-FORMAT-CONSID" target="https://datatracker.ietf. org/meeting/interim-2015-icnrg-01/materials/slides-interim-2015-icnrg-1-8"> <reference anchor="WIRE-FORMAT-CONSID" target="https://datatracker.ietf. org/meeting/interim-2015-icnrg-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/> <author initials="G." surname="Wang"/>
<date/> <author initials="C." surname="Tschudin"/>
<author initials="R." surname="Ravindran"/>
<date month="January" year="2015"/>
</front> </front>
</reference> </reference>
<!-- [rfced] [ICNLOWPAN] The URL below is correct -->
<reference anchor="ICNLOWPAN" target="https://doi.org/10.23919/IFIPNetwo rking.2019.8816850"> <reference anchor="ICNLOWPAN" target="https://doi.org/10.23919/IFIPNetwo rking.2019.8816850">
<front> <front>
<title>ICNLoWPAN -- Named-Data Networking in Low Power IoT <title>ICNLoWPAN - Named-Data Networking in Low Power IoT
Networks</title> Networks</title>
<author initials="C." surname="Gundogan"> <author initials="C." surname="Gündogan">
<organization>HAW Hamburg</organization> <organization>HAW Hamburg</organization>
</author> </author>
<author initials="P." surname="Kietzmann"> <author initials="P." surname="Kietzmann">
<organization>HAW Hamburg</organization> <organization>HAW Hamburg</organization>
</author> </author>
<author initials="TC." surname="Schmidt"> <author initials="TC." surname="Schmidt">
<organization>HAW Hamburg</organization> <organization>HAW Hamburg</organization>
</author> </author>
<author initials="M." surname="Waehlisch"> <author initials="M." surname="Wählisch">
<organization>FU Berlin</organization> <organization>FU Berlin</organization>
</author> </author>
<date month="May" year="2019"/> <date month="May" year="2019"/>
</front> </front>
<seriesInfo name="Proc. of 18th" value="IFIP Networking Conference"/> <refcontent>Proc. of 18th IFIP Networking Conference</refcontent>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="sec.EstimatedSizeReduction" numbered="true" toc="default"> <section anchor="sec.EstimatedSizeReduction" numbered="true" toc="default">
<name>Estimated Size Reduction</name> <name>Estimated Size Reduction</name>
<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 <tt>n</tt> is the number of name
components, <tt>comps_n</tt> denotes the sum of n components; <tt>comps_n</tt> 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
<tt>clen</tt>. 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 numbered="true" toc="default">
<name>NDN</name> <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 numbered="true" toc="default">
<name>Interest</name> <name>Interest</name>
<t><xref target="fig.Size.NDN.interest.uncompressed" format="default"/ > 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> <name>Estimated Size of an Uncompressed NDN Interest</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![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"/> depicts the <t><xref target="fig.Size.NDN.interest.compressed" format="default"/> 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> <name>Estimated Size of a Compressed NDN Interest</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![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 11 + 1.5n bytes.</t>
<t>For the name <tt>/DE/HH/HAW/BT7</tt>, the <t>For the name <tt>/DE/HH/HAW/BT7</tt>, 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 numbered="true" toc="default">
<name>Data</name> <name>Data</name>
<t><xref target="fig.Size.NDN.Data.uncompressed" format="default"/> de picts 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> <name>Estimated Size of an Uncompressed NDN Data</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
------------------------------------, ------------------------------------,
Data TLV = 2 | Data TLV = 2 |
---------------------, | ---------------------, |
Name | 2 + | Name | 2 + |
NameComponents = 2n + | NameComponents = 2n + |
| comps_n | | comps_n |
---------------------' | ---------------------' |
---------------------, | ---------------------, |
MetaInfo | | MetaInfo | |
skipping to change at line 2523 skipping to change at line 2647
SignatureValue | | SignatureValue | |
DigestSha256 | | DigestSha256 | |
---------------------' | ---------------------' |
------------------------------------' ------------------------------------'
]]></artwork> ]]></artwork>
</figure> </figure>
<t><xref target="fig.Size.NDN.Data.compressed" format="default"/> depi cts the size <t><xref target="fig.Size.NDN.Data.compressed" format="default"/> depi 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> <name>Estimated Size of a Compressed NDN Data</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![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 15 + 1.5n bytes.</t>
<t>For the name <tt>/DE/HH/HAW/BT7</tt>, the <t>For the name <tt>/DE/HH/HAW/BT7</tt>, 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 numbered="true" toc="default">
<name>CCNx</name> <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 numbered="true" toc="default">
<name>Interest</name> <name>Interest</name>
<t><xref target="fig.Size.CCNx.interest.uncompressed" format="default" <t><xref target="fig.Size.CCNx.interest.uncompressed" format="default"
/> depicts the /> depicts
size requirements for a basic, uncompressed CCNx Interest. No the size requirements for a basic, uncompressed CCNx Interest. No
Hop-By-Hop TLVs are included, the protocol version is assumed to be 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 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> <name>Estimated Size of an Uncompressed CCNx Interest</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![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" format="default"/>
depicts the depicts the size requirements after compression.</t>
size requirements after compression.</t>
<figure anchor="fig.Size.CCNx.interest.compressed"> <figure anchor="fig.Size.CCNx.interest.compressed">
<name>Estimated size of a compressed CCNx Interest</name> <name>Estimated Size of a Compressed CCNx Interest</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![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 18 + 3.5n bytes.</t>
<t>For the name <tt>/DE/HH/HAW/BT7</tt>, the size <t>For the name <tt>/DE/HH/HAW/BT7</tt>, 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 numbered="true" toc="default">
<name>Content Object</name> <name>Content Object</name>
<t><xref target="fig.Size.CCNx.Data.uncompressed" format="default"/> d <t><xref target="fig.Size.CCNx.Data.uncompressed" format="default"/>
epicts the size 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> <name>Estimated Size of an Uncompressed CCNx Content Object</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![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"/> dep <t><xref target="fig.Size.CCNx.Data.compressed" format="default"/>
icts 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> <name>Estimated Size of a Compressed CCNx Data Object</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![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 35 + 3.5n bytes.</t>
<t>For the name <tt>/DE/HH/HAW/BT7</tt>, the size <t>For the name <tt>/DE/HH/HAW/BT7</tt>, 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="false" toc="default">
<name>Acknowledgments</name> <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" format="default"/> and <xref target Larger parts of this work
="RFC6282" format="default"/>. are inspired by <xref target="RFC4944" format="default"/> and
Special mentioning goes to Mark Mosko as well as G.Q. Wang and Ravi <xref target="RFC6282" format="default"/>.
Ravindran as their previous work in <xref target="TLV-ENC-802.15.4" format Special mention goes to <contact fullname="Mark Mosko"/>, as well as
="default"/> <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 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. 338 change blocks. 
691 lines changed or deleted 831 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/