Movatterモバイル変換

[0]ホーム
URL:

 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-icnlowpan-10" number="0000" ipr="trust200902" submissionType="IRTF" category="exp" consensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3"><rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-irtf-icnrg-icnlowpan-11" number="9139" ipr="trust200902" submissionType="IRTF" category="exp" consensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true" 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 46skipping 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="MatthiasWaehlisch" 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="MatthiasWä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.html</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 99skipping 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 forCCNx andNDN over IEEE <t>This document defines a convergence layer forContent-Centric Networkin
802.15.4LoWPAN networks. A new frame format is specified to adapt CCNxg
(CCNx) andNamed Data Networking (NDN) over IEEE
802.15.4Low-Power Wireless Personal Area Networks (LoWPANs). A
new frame format is specified to adapt CCNx
and NDN packets to the small MTU size of IEEE 802.15.4. For that, and NDN packets to the small MTU size of IEEE 802.15.4. For that,
syntactic and semantic changes to the TLV-based header formats are syntactic and semantic changes to the TLV-based header formats are
described. To support compatibility with other LoWPAN technologies that described. To support compatibility with other LoWPAN technologies that
may coexist on a wireless medium, the dispatching scheme provided by may coexist on a wireless medium, the dispatching scheme provided by
6LoWPAN is extended to include new dispatch types for CCNx and NDN.IPv6 over LoWPAN (6LoWPAN) is extended
to include new dispatch types for CCNx and NDN.
Additionally, the fragmentation component of the 6LoWPAN Additionally, the fragmentation component of the 6LoWPAN
dispatching framework is applied toICN chunks. In its second part, the dispatching framework is applied toInformation-Centric Network (ICN)
chunks. In its second part, the
document defines stateless and stateful compression schemes to improve document defines stateless and stateful compression schemes to improve
efficiency on constrained links. Stateless compression reduces TLV efficiency on constrained links. Stateless compression reduces TLV
expressions to static header fields for common use cases. Stateful expressions to static header fields for common use cases. Stateful
compression schemes elidestate local to the LoWPAN and replace names in compression schemes elidestates local to the LoWPAN and replace names in
data packets by short local identifiers.</t>Data packets by short local identifiers.</t>
<t>This document is a product of the IRTF Information-Centric <t>This document is a product of the IRTF Information-Centric
Networking Research Group (ICNRG).</t> Networking Research Group (ICNRG).</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" 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 replicationdemonstrated notable advantages over the in-network data replicationdemonstrates notable advantages over the
traditional host-to-host approach on the Internet <xref traditional host-to-host approach on the Internet <xref
format="default"/>, <xref format="default"/>. Recentstudies <format="default"/> <xref format="default"/>. Recentstud
xref format="default"/> have shown that an appropriate mappingies <xref
tolink layer 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 <xrefform chunks to such link layers for the ICN flavors NDN <xref
at="default"/>format="default"/> and CCNx <xrefformat="default"/> <xre
and CCNx <xrefformat="default"/>, <xreff
format="default"/>.</t> format="default"/>.</t>
<t>The IEEE 802.15.4 <xref format="default"/> link l <t>The IEEE 802.15.4 <xref format="default"/> link l
ayer is used inayer is
low-power and lossy networks (see <tt>LLN</tt> in used in low-power and lossy networks (see <tt>LLN</tt> in
<xref format="default"/>), in which devices are typically <xref format="default"/>), in which devices are typically
battery-operated and constrained in resources. Characteristics of LLNsbattery 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 maximumphysical layer increased latencies. IEEE 802.15.4 admits a maximumphysical-layer
packet size of 127 bytes. The maximum frame header size is 25 bytes, packet size of 127 bytes. The maximum frame header size is 25 bytes,
which leaves 102 bytes for the payload. IEEE 802.15.4 security features which leaves 102 bytes for the payload. IEEE 802.15.4 security features
further reduce this payload length by up to 21 bytes, yielding a net of further reduce this payload length by up to 21 bytes, yielding a net of
81 bytes for CCNx or NDN packet headers,signatures and content.</t> 81 bytes for CCNx or NDN packet headers,signatures, and content.</t>
<t>6LoWPAN <xrefformat="default"/><xref <t>6LoWPAN <xrefformat="default"/> <xrefdefault">, </xref> is a"
convergence layer that provides frame formats, headercompression and format="default"/> is a
adaptation layer fragmentation for IPv6 packets in IEEE 802.15.4 networks. convergence layer that provides frame formats, headercompression, and
Theadaptation-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>PrevalentType-Length-Value (TLV) based packet formats such as in <t>Prevalent packet formatsbased on Type-Length-Value (TLV), such as in
CCNx andNDN are designed to be generic and extensible. This leads to CCNx andNDN, are designed to be generic and extensible. This leads to
headerverbosity which is inappropriate in constrained environments of headerverbosity, which is inappropriate in constrained environments of
IEEE 802.15.4 links. This document presents ICN LoWPAN, a convergence IEEE 802.15.4 links. This document presents ICN LoWPAN, a convergence
layer for IEEE 802.15.4 motivated by 6LoWPAN. ICN LoWPAN compresses layer for IEEE 802.15.4 motivated by 6LoWPAN. ICN LoWPAN compresses
packet headers of CCNx as well as NDN and allows for an increased packet headers of CCNx, as well as NDN, and allows for an increased
effective payload size per packet. Additionally, reusing the dispatching effective payload size per packet. Additionally, reusing the dispatching
framework defined by 6LoWPAN enables compatibility between coexisting framework defined by 6LoWPAN enables compatibility between coexisting
wireless deployments of competing network technologies. This also allowst wireless deployments of competing network technologies. This also allowsr
o reuseeuse of
theadaptation layer fragmentation scheme specified by 6LoWPAN for ICN LoW theadaptation-layer fragmentation scheme specified by 6LoWPAN for ICN LoW
PAN.</t>PAN.</t>
<t>ICN LoWPAN defines a morespace efficient representation of CCNx and <t>ICN LoWPAN defines a morespace-efficient representation of CCNx and
NDN packet formats. This syntactic change is described for CCNx and NDN NDN packet formats. This syntactic change is described for CCNx and NDN
separately, as the header formats and TLV encodings differ notably. For separately, as the header formats and TLV encodings differ notably. For
further reductions, default header values suitable for constrained IoT further reductions, default header values suitable for constrained IoT
networks are selected in order to elide corresponding TLVs. Experimental networks are selected in order to elide corresponding TLVs. Experimental
evaluations of the ICN LoWPAN header compression schemes in <xref format="default"/> illustrate a reduced message overhead, a shortened evaluations of the ICN LoWPAN header compression schemes in <xref 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 format="default"/> devices compared to uncompressed ICN messages.</t> Class 2devices <xref format="default"/> compared to uncompressed ICN messages.</t>
<t>In a typical IoT scenario (see <xref format="default"> <t>In a typical IoT scenario (see <xref format="default">
</xref>), embedded devices are interconnected via a quasi-stationary </xref>), embedded devices are interconnected via a quasi-stationary
infrastructure using a border router (BR) that connects the constrained infrastructure using a border router (BR) that connects the constrained
LoWPAN network by someGateway with the public Internet. InICN based LoWPAN network by somegateway with the public Internet. InICN-based
IoT networks,non-local Interest and Data messages transparently travel IoT networks,nonlocal Interest and Data messages transparently travel
through the BR up and down between aGateway and the embedded devices through the BR up and down between agateway and the embedded devices
situated in the constrained LoWPAN.</t> situated in the constrained LoWPAN.</t>
<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 200skipping to change at line 233
'--------' '--------'
LoWPAN LoWPAN
O O O O
O O
O O embeddedO O embedded
O O O devices O O O devices
O O O O
]]></artwork>]]></artwork>
</figure> </figure>
<t> <t>
The document has received fruitful reviews by members of the ICN community and the research group (seeAcknowledgments) for a period of twoyears. The document has received fruitful reviews by members of the ICN community and the research group (seethe Acknowledgments section) for a period of twoyears.
It is the consensus of ICNRG that this document should be published in the IRTF Stream of the RFC series. It is the consensus of ICNRG that this document should be published in the IRTF Stream of the RFC series.
This document does not constitute an IETF standard. This document does not constitute an IETF standard.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <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 thisxt describing it. Please let us know if you have any concerns.
document are to be interpreted as described in RFC 2119<xref format="default"/>. The use of the term, "silently ignore" is notOriginal:
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 similarlyconstrued.</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/> <xref/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>This document uses the terminology of <xref format="default"/>, <xref format="default"/>, and <xref format="default"/> for ICN entities.</t> <t>This document uses the terminology of <xref format="default"/>, <xref format="default"/>, and <xref format="default"/> for ICN entities.</t>
<t>The following terms are used in the document and defined as follows: <t>The following terms are used in the document and defined as follows:
</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 format="default"/>.</t> <xref format="default"/>.</t>
<figure anchor="fig.intro.hbh"> <figure anchor="fig.intro.hbh">
<name>ICN LoWPANconvergence layer for IEEE 802.15.4</name> <name>ICN LoWPANConvergence 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 | | | | LinkLayer |
'----------------|-' '-|--------------|-' '-|----------------''----------------|-' '-|--------------|-' '-|----------------'
'--------' '---------' '--------' '---------'
]]></artwork>]]></artwork>
</figure> </figure>
<t><xref format="default"/> of this document defines the <t><xref format="default"/> of this document 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 forlink-layers with small MTUs. The of particular importance forlink layers with small MTUs. The
stateless compression does not requirepre-configuration of global stateless compression does not requirepreconfiguration ofa global
state.</t> state.</t>
<!-- [rfced] Does adding the term "format" help with the readability of the fol
lowing sentences?
Current:
The advantage of TLVs is its native support of variably structured data.
The main disadvantage of TLVs is the verbosity that results from storing
the type and length of the encoded data.
Perhaps:
The advantage of the TLV format is its support of variably structured data.
The main disadvantage of the TLV format is the verbosity that results from
storing the type and length of the encoded data.
-->
<t>The CCNx and NDN header formats are composed of Type-Length-Value <t>The CCNx and NDN header formats are composed of Type-Length-Value
(TLV) fields to encode header data. The advantage of TLVs is its (TLV) fields to encode header data. The advantage of TLVs is its
native support of variably structured data. The main disadvantage of native support of variably structured data. The main disadvantage of
TLVs is the verbosity that results from storing the type and length of TLVs is the verbosity that results from storing the type and length of
the encoded data.</t> the encoded data.</t>
<t>The stateless header compression scheme makes use of compact bit <t>The stateless header compression scheme makes use of compact bit
fields to indicate the presence of optional TLVs in the uncompressed fields to indicate the presence of optional TLVs in the uncompressed
packet. The order of set bits in the bit fields corresponds to the packet. The order of set bits in the bit fields corresponds to the
order of each TLV in the packet. Further compression is achieved by order of each TLV in the packet. Further compression is achieved by
specifying default values and reducing the range of certain header specifying default values and reducing the range of certain header
fields.</t> fields.</t>
<t><xref format="default"/> demonstrates the stateless <t><xref 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 thetype and the length fields are removed. The third TLV so that theType and Length fields are removed. The third TLV
represents a boolean TLV (e.g., the MustBeFresh selector in NDN) for represents a boolean TLV (e.g., the MustBeFresh selector in NDN) for
which thetype, length and the value fields are elided.</t> which theType, Length, and Value fields are elided.</t>
<figure anchor="fig.TLV.compressed"> <figure anchor="fig.TLV.compressed">
<name>Compressionusing acompact bit field - bits encode theinclusio <name>CompressionUsing aCompact Bit Field -- Bits Encode theInclusi
n ofon 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 | Bitfield | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | BitField
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | | | |
,--' '----, '- Boolean Value ,--' '----, '- Boolean Value
| | | |
+-------+-------+-------++-------+-------+-------+
| LEN | VAL | VAL || LEN | VAL | VAL |
+-------+-------+-------++-------+-------+-------+
'---------------'-------''---------------'-------'
Var-len Value Fixed-len Value Var-len Value Fixed-len Value
]]></artwork>]]></artwork>
</figure> </figure>
<t>Stateless TLV compression for NDN is defined in <xref format="default"/>. <xref format="default"/> defines the stateless <t>Stateless TLV compression for NDN is defined in <xref format="default"/>. <xref format="default"/> defines the stateless
TLV compression for CCNx.</t> TLV compression for CCNx.</t>
<t>The extensibility of this compression is described in <xref format="default"/> and allows future documents to update the <t>The extensibility of this compression is described in <xref format="default"/> and allows future documents to update the
compression rules outlined in thismanuscript.</t> compression rules outlined in thisdocument.</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 twoorthogonal stateful compression <t>ICN LoWPAN further employs twoorthogonal, stateful compression
schemes for packet sizereductions which are defined in <xreftarget="st schemes for packet sizereductions, which are defined in <xreftarget="s
ateful.compression" format="default"/>. These mechanisms rely on sharedtateful.compression" format="default"/>. These mechanisms rely on shared
contexts that are either distributed and maintained in the entire contexts that are either distributed and maintained in the entire
LoWPAN, or are generatedon-demand hop-wise on a particularLoWPAN or are generatedon demand hop-wise on a particular
Interest-data path.</t>Interest-Data path.</t>
<t>The shared context identification is defined in <xref format="default"/>. The hop-wise name compression <t>The shared context identification is defined in <xref format="default"/>. The hop-wise name compression
"en-route" is specified in <xref format="default"/>.</t> "en-route" is specified in <xref 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 section="5" sectionFormat="of" format="default"/>). for IEEE 802.15.4 frames (see <xref section="5" sectionFormat="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 format="default"/> further specifies dispatch<!-- [rfced] In the following sentence, should "dispatch table" be instead "disp
pages to switchatch Page"?
between different contexts. When a LoWPAN parser encounters a<tt>Page s
witch</tt> LoWPAN encapsulation header,then allCurrent:
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 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 andpage 1 are reserved for 6LoWPAN. This document uses header.Pages 0 and 1 are reserved for 6LoWPAN. This document uses
page TBD1 (<tt>1111TBD1 (0xFTBD1)</tt>) for ICN LoWPAN.</t>Page 14 (<tt>11111110 (0xFE)</tt>) for ICN LoWPAN.</t>
<t>The base dispatch format (<xref format="defaul <t>The base dispatch format (<xref format="defaul
t"/>) is usedt"/>) is
and extended by CCNx and NDN in <xrefformat="default"/ used and extended by CCNx and NDN inSections <xrefform
> and <xrefformat="default"/>.</t>at="counter"/> and
<xrefformat="counter"/>.</t>
<figure anchor="fig.disp.base"> <figure anchor="fig.disp.base">
<name>Basedispatch format for ICN LoWPAN</name> <name>BaseDispatch Format for ICN LoWPAN</name>
<artwork align="center" name="" type="" alt=""><![CDATA[<artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 ... 0 1 23 ...
+---+---+-----------+---+---+---+---+---
|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 format="default"/>.</t> the extended dispatch format in <xref format="default"/>.</t>
<figure anchor="fig.disp.base.compr"> <figure anchor="fig.disp.base.compr">
<name>Extendeddispatch format for compressed ICN LoWPAN</name> <name>ExtendedDispatch Format for Compressed ICN LoWPAN</name>
<artwork align="center" name="" type="" alt=""><![CDATA[<artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 34 ... 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 format="default"/>).</dd> <dd>Context identifier(s) are present (see <xref 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 format="default"/>).</dd> <dd>Extension byte(s) are present (see <xref 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 ICNLoWPAN</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 section="5.1" sectionFormat="of" format="default"/></dd> defined in <xref section="5.1" sectionFormat="of" format="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 format="default"/> and <xref format="default"/>.</dd> <dd>Dispatches as defined inSections <xref format="counter"/> and <xref 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 format="default"/>.</t> depicted in <xref format="default"/>.</t>
<figure anchor="fig.ext.base"> <figure anchor="fig.ext.base">
<name>Baseformat for dispatch extensions.</name> <name>BaseFormat 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 structured data in a between devices <bcp14>SHOULD</bcp14> use manifests to encode structured data in a
well-defined format,as, e.g., outlined in <xref format="default"/>.</t> well-defined format,e.g., as outlined in <xref format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="sec.Fragmentation" numbered="true" toc="default"> <section anchor="sec.Fragmentation" numbered="true" toc="default">
<name>AdaptationLayer 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 section="5.3" sectionFormat="of" format="default"/> network layers. Therefore, <xref section="5.3" sectionFormat="of" format="default"/>
defines a protocol-independent fragmentation dispatch type, a defines a protocol-independent fragmentation dispatch type, a
fragmentation header for the first fragment, and a separate fragmentation header for the first fragment, and a separate
fragmentation header for subsequent fragments. ICN LoWPAN adopts this fragmentation header for subsequent fragments. ICN LoWPAN adopts this
fragmentation handling of <xref format="default"/>.</t> fragmentation handling of <xref format="default"/>.</t>
<t>TheFragmentation LoWPAN header can encapsulate other dispatch <t>Thefragmentation LoWPAN header can encapsulate other dispatch
headers. The order of dispatch types is defined in <xref section="5" sectionFormat="of" format="default"/>. <xref format="default"/> shows the headers. The order of dispatch types is defined in <xref section="5" sectionFormat="of" format="default"/>. <xref 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 format="default"/>.</t> contain any fragmentation headers and is depicted in <xref format="default"/>.</t>
<figure anchor="fig.fr_first"> <figure anchor="fig.fr_first">
<name>Fragmentationscheme</name> <name>FragmentationScheme</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 LoWPANframe</name> <name>Reassembled ICN LoWPANFrame</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 format="default"/> is an alternative <t>The 6LoWPAN Fragment Forwarding (6LFF) <xref 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
asseamless as the conventional hop-wise asseamlessly as the conventional hop-wise
fragmentation.Experimental evaluations <xreftarget="SFR-ICNLOWPAN" for fragmentation.However, experimental evaluations <xreftarget="SFR-ICNLO
mat="default"/>, however, suggest that amore refinedWPAN"
format="default"/> suggest that amore-refined
integration can increase the cache utilization of forwarders integration can increase the cache utilization of forwarders
on a request path.</t> on a request path.</t>
</section> </section>
</section> </section>
<section anchor="sec.ndn" numbered="true" toc="default"> <section anchor="sec.ndn" 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 format="default"/>. Type andlength that is described in <xref format="default"/>. Type andLength
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 actualtype or length field. If then that number is encoded into the actualType 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 thetype or length field is set to <tt>253</tt> and the number is encoded in the next fits into 2 bytes, then theType 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 thetype number is greater than 2 bytes and fits into 4 bytes, then theType
orlength field is set to <tt>254</tt> and the orLength field is set to <tt>254</tt> and the
number is encoded in the subsequent 4 bytes in network byte order. number is encoded in the subsequent 4 bytes in network byte order.
For larger numbers, thetype or length field is set to <tt>255</tt> and the number is encoded in the subsequent 8 For larger numbers, theType 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 encodetype and <t>In this specification, compressed NDN TLVs encodeType and
length fields using self-delimiting numeric values (SDNVs)Length fields using self-delimiting numeric values (SDNVs)
<xref format="default"/> commonly known fromDTN protoc <xref format="default"/> commonly known fromDelay-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 TLVencoding compared to SDNVs.</name> <name>NDN TLVEncoding Compared to SDNVs</name>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left">Value</th>
<th align="left">NDN TLVencoding</th> <th align="left">NDN TLVEncoding</th>
<th align="left">SDNVencoding</th> <th align="left">SDNVEncoding</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 587skipping 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 format="default"/> compares the required <xref format="default"/> compares the required
bytes for encoding a few selected values using the NDN TLV bytes for encoding a few selected values using the NDN TLV
encoding and SDNVs. For values up to 127, both methods encoding and SDNVs. For values up to 127, both methods
require a single byte. Values in the range [128;252] encode require a single byte. Values in the range [128;252] encode
as one byte for the NDN TLV scheme, while SDNVs require two as one byte for the NDN TLV scheme, while SDNVs require two
bytes. Starting at value 253, SDNVs require a less or equal bytes. Starting at value 253, SDNVs require a less or equal
amount of bytes compared to the NDN TLV encoding. amount of bytes compared to the NDN TLV encoding.
</t> </t>
</section> </section>
<section anchor="sec.ndn.namecompression" numbered="true" toc="default"> <section anchor="sec.ndn.namecompression" numbered="true" toc="default">
<name>Name TLV Compression</name> <name>Name TLV Compression</name>
<t>This Name TLV compression encodeslength fields of two consecutive <t>This Name TLV compression encodesLength fields of two consecutive
NameComponent TLVs into one byte, using a nibble for each. NameComponent TLVs into one byte, using a nibble for each.
The most significant nibble indicates the length of an immediately following NameComponent TLV. The most significant nibble indicates the length of an immediately following NameComponent TLV.
The least significant nibble denotes the length of a subsequent NameComponent TLV. The least significant nibble denotes the length of a subsequent NameComponent TLV.
A length of 0 marks the end of the compressed Name TLV. A length of 0 marks the end of the compressed Name TLV.
The lastlength field of an encoded NameComponent is either 0x00 for a name with an even number of components, The lastLength field of an encoded NameComponent is either 0x00 for a name 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 allows for an unlimited number of components. This process limits the length of a NameComponent TLV to 15 bytes but allows for an unlimited number of components.
An example for this encoding is presented in <xref format="default"/>.</t> An example for this encoding is presented in <xref format="default"/>.</t>
<figure anchor="fig.ndnshortnco"> <figure anchor="fig.ndnshortnco">
<name>Name TLVcompression for /HAW/Room/481/Humid/99</name> <name>Name TLVCompression 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 685skipping 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 format="default"/>) and sets theC f (see <xref format="default"/>) and sets theC,
lag toP, and M
<tt>0</tt> andthe P as well as the Mflags to <tt>0</tt> (<xrefformat="defaul
flag to <tt>0</tt> (<xrefformat="defaultt"/>).
"/>).<!--[rfced] As the last "N" in "NDN" stands for "Networking" may we remove "netw
ork" from instances of "NDN network stack" (e.g., it reads as Named Data Network
ing network stack)? Note that there are 2 instances.
-->
The Interest message is handed to the NDN network stack without modifications.</t> The Interest message is handed to the NDN network stack without modifications.</t>
<figure anchor="fig.ndn.int.uncompr"> <figure anchor="fig.ndn.int.uncompr">
<name>Dispatchformat for uncompressed NDN Interest messages</name> <name>DispatchFormat 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 format="default"/>) and sets the C (<xref format="default"/>) and sets the C
flag to<tt>1</tt>, flag to
the Pflag to <tt>0</tt> andthe Mflag to <tt>0</tt>.<tt>1</tt> and the P and Mflags 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 suchaHopLimit TLV is not present, it
will be inserted with a default value of DEFAULT_NDN_HOPLIMIT prior to will be inserted with a default value of DEFAULT_NDN_HOPLIMIT prior to
the compression.</t> the compression.</t>
<t>In the default use case, the Interest message is compressed with <t>In the default use case, the Interest message is compressed with
the following minimal rule set: </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 <xreftarget="sec.ndn.na <li>The Name TLV is compressed according to <xref
mecompression" format="default"/>. For this, all NameComponentstarget="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 thee greater than 0. An ImplicitSha256DigestComponent or
nd of the ParametersSha256DigestComponent <bcp14>MAY</bcp14> appear at theend
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 compressedInterest as illustrated in the end of the compressedInterest, as illustrated in
<xref format="default"/>. The <xref format="default"/>. The
InterestLifetime is encoded as described in <xreftarget="sec.comp InterestLifetime is encoded as described in <xref
ressedtime" format="default"/>. Ontarget="sec.compressedtime" format="default"/>. On
decompression, this encoding may yield an decompression, this encoding may yield an
Interestlifetime that is smaller than the originalInterestLifetime that is smaller than the original
value.</li> value.</li>
<li>The Type and Length fields of Nonce TLV, HopLimitTLV and <li>The Type and Length fields of Nonce TLV, HopLimitTLV, and
InterestLifetime TLV are elided. The Nonce value has a length of InterestLifetime TLV are elided. The Nonce value has a length of
4bytes and the HopLimit value has a length of 1 byte. The 4bytes, and the HopLimit value has a length of 1 byte. The
compressed InterestLifetime (<xreffor compressed InterestLifetime (<xref
mat="default"/>) has aformat="default"/>) has a
length of 1 byte. The presence of a Nonce and InterestLifetimeTLV length of 1 byte. The presence of a NonceTLV and InterestLifetimeT
isLV 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 anInerestLifetime, a length of <tt>4</tt> indicates presence of anInterestLifetime, 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 target="fig.ndn.int.newformat" format="default"/>.</t> <t>The compressed NDN LoWPAN Interest message is visualized in <xref target="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 = ValueT = Type, L = Length, V = Value
Lc = Compressed Length, Vc = Compressed ValueLc = Compressed Length, Vc = Compressed Value
: = optional field, | = mandatory field: = optional field, | = mandatory field
+---------+---------+ +---------++---------+---------+ +---------+
skipping to change at line 772skipping 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 format="default"/>.</t> in <xref format="default"/>.</t>
<figure anchor="fig.ndn.intcompr"> <figure anchor="fig.ndn.intcompr">
<name>Dispatchformat for compressed NDN Interest messages</name> <name>DispatchFormat 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 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
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 format="default"/>. If any name is not compressed according to <xref format="default"/>. If any name is not
compressible, the message <bcp14>MUST</bcp14> be sent uncompressed.</dd> compressible, the message <bcp14>MUST</bcp14> be sent uncompressed.</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 format="default"/>.</dd>
<dt>EXT: Extension</dt>
<dd>
<dl newline="false" spacing="normal" indent="4">
<dt>0:</dt>
<dd>No extension byte follows.</dd>
<dt>1:</dt>
<dd>Extension byte <tt>EXT_0</tt>
follows immediately. See <xref
format="default"/>.</dd>
</dl>
</dd>
</dl> </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 format="default"/> and is illustrated description in <xref format="default"/> and is illustrated
in <xref format="default"/>.</t> in <xref format="default"/>.</t>
<figure anchor="fig.ndn.interest.ext0"> <figure anchor="fig.ndn.interest.ext0">
<name>EXT_0format</name> <name>EXT_0Format</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 format="default"/>).</dd> compression strategy (see <xref 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 Cflag to <tt>0</tt>, format and sets the Cand Pflags to <tt>0</tt> and the M flag
the Pflag to <tt>0</tt> and the M flag
to <tt>1</tt> (<xref format="default"/>). The Data message is to <tt>1</tt> (<xref 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>Dispatchformat for uncompressed NDN Data messages</name> <name>DispatchFormat 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 format="default"/>) and sets the C format (<xref format="default"/>) and sets 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 format="default"/>. For this, all NameComponents <li>The Name TLV is compressed according to <xref 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 areelided and the value is encoded as described Length fields areelided, and the value is encoded as described
in <xref format="default"/> as a 1-byt in <xref format="default"/> as a 1-byt
e time-code. If the freshness period is note
time-code. If the freshness period is not
a valid time-value, then the message <bcp14>MUST</bcp14> be sent uncompressed a valid time-value, then the message <bcp14>MUST</bcp14> be sent uncompressed
in order to preserve the security envelope of the Data message. in order to preserve the security envelope of the Data message.
The presence of a FreshnessPeriod TLV is deduced from the The presence of a FreshnessPeriod TLV is deduced from the
remainingone byte length to parse.</li> remainingone-byte length to parse.</li>
<li>The Type fields of the SignatureInfo TLV, SignatureTypeTLV <li>The Type fields of the SignatureInfo TLV, SignatureTypeTLV,
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 target="fig.ndn.data.newformat" format="default"/>.</t> <t>The compressed NDN LoWPAN Data message is visualized in <xref target="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 = ValueT = Type, L = Length, V = Value
Lc = Compressed Length, Vc = Compressed ValueLc = Compressed Length, Vc = Compressed Value
: = optional field, | = mandatory field: = optional field, | = mandatory field
skipping to change at line 997skipping 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 format="default"/>.</t> in <xref format="default"/>.</t>
<figure anchor="fig.ndn.datacompr"> <figure anchor="fig.ndn.datacompr">
<name>Dispatchformat for compressed NDN Data messages</name> <name>DispatchFormat 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 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 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 <xreftarget="sec.FinalBlockId, and it is encoded according to <xref
ndn.namecompression" format="default"/>. If theFinalBlockId TLVtarget="sec.ndn.namecompression" format="default"/>. If theFin
is not compressible, then the message <bcp14>MUST</bcp14>be salBlockId
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 compressed according to <xref
format="default"/>. If the name is not 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 format="default"/>.</dd>
<dt>EXT: Extension</dt>
<dd>
<dl newline="false" spacing="normal" indent="4">
<dt>0:</dt>
<dd>No extension byte follows.</dd>
<dt>1:</dt>
<dd>Extension byte <tt>EXT_0</tt>
follows immediately. See <xref
format="default"/>.</dd>
</dl>
</dd>
</dl> </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 format="default"/> and is illustrated description in <xref format="default"/> and is illustrated
in <xref format="default"/>.</t> in <xref format="default"/>.</t>
<figure anchor="fig.ndn.data.ext0"> <figure anchor="fig.ndn.data.ext0">
<name>EXT_0format</name> <name>EXT_0Format</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 format="default"/>).</dd> compression strategy (see <xref 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 <t>The generic CCNx TLV encoding is described in <xref
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 morespace <t>The TLV encoding for CCNx LoWPAN is changed to the morespace-efficie
efficient encoding described in <xrefformat="dnt
efault"/>. encoding described in <xrefformat="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 target="sec.ndn.namecompression" format="default"/> for NDN. If a Name TLV contains <t>Name TLVs are compressed using the scheme already defined in <xref target="sec.ndn.namecompression" format="default"/> for NDN. If a Name TLV contains
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 format="default"/>) and sets the C as well as the M flag to <tt>0</tt>. (see <xref format="default"/>) and sets the C and M flags to <tt>0</tt>.
The P flag is set to <tt>1</tt> (<xref format="default"/>). The P flag is set to <tt>1</tt> (<xref format="default"/>).
The Interest message is handed to the CCNx network stack without modifications.</t> The Interest message is handed to the CCNx network stack without modifications.</t>
<figure anchor="fig.ccnx.int.uncompr"> <figure anchor="fig.ccnx.int.uncompr">
<name>Dispatchformat for uncompressed CCNx Interest messages</name> <name>DispatchFormat 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 format="default"/>) and sets the C and P flags to <tt>1</tt>. The M flag is set to <tt>0</tt>. (<xref 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 format="default"/>.</t> <xref 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 = ValueT = Type, L = Length, V = Value
Lc = Compressed Length, Vc = Compressed ValueLc = Compressed Length, Vc = Compressed Value
: = optional field, | = mandatory field: = optional field, | = mandatory field
skipping to change at line 1199skipping 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 format="default"/>.</t> in <xref format="default"/>.</t>
<figure anchor="fig.ccnx.intcompr"> <figure anchor="fig.ccnx.intcompr">
<name>Dispatchformat for compressed CCNx Interest messages</name> <name>DispatchFormat 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 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
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: OptionalHop-By-Hop InterestLifetime TLV</dt> <dt>ILT: Optionalhop-by-hop InterestLifetime TLV</dt>
<dd> <dd>
<t><br/></t>
<t>See <xref format="default"/> for further details <t>See <xref 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 format="default described in <xref format="default
"/>. Thetype"/>. The
andlength fields are elided.</dd>Type andLength fields are elided.</dd>
</dl> </dl>
</dd> </dd>
<dt>MGH: OptionalHop-By-Hop MessageHash TLV</dt> <dt>MGH: Optionalhop-by-hop MessageHash TLV</dt>
<dd> <dd>
<t><br/></t>
<t>See <xref format="default"/> for further <t>See <xref format="default"/> for further
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</bcp14> be sent another hash is contained, then the Interest <bcp14>MUST</bcp14> 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 ispresent and thetype as <dd>A T_SHA-256 TLV ispresent, and theType and
well as the length fields are removed. Thelength field is Length fields are removed. TheLength field is
assumed to represent 32 bytes. The outer Message Hash TLV assumed to represent 32 bytes. The outer Message Hash TLV
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</bcp14> be sent another hash is contained, then the Interest <bcp14>MUST</bcp14> 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 ispresent and thetype as <dd>A T_SHA-256 TLV ispresent, and theType and
well as the length fields are removed. Thelength field is Length fields are removed. TheLength 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</bcp14> be sent another hash is contained, then the Interest <bcp14>MUST</bcp14> 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 ispresent and thetype as <dd>A T_SHA-256 TLV ispresent, and theType and Length fieldsa
well as the length fieldsare removed. Thelength field isre
assumed to represent 32 bytes. Theouter removed. TheLength field is assumed to represent 32 bytes. Theo
ContentObjectHashRestriction TLV is omitted.</dd>uter
ContentObjectHashRestriction TLV is omitted.</dd>
</dl> </dl>
</dd> </dd>
<dt>VAL: Optional ValidationAlgorithm and ValidationPayloadTLVs</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 validationrelated 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 handlesvalidation related TLV compressions and is that handlesvalidation-related TLV compressions and is
described in <xrefformat="default"/> described in <xref
.</dd>format="default"/>.</dd>
</dl> </dl>
</dd> </dd>
<dt>CID: Context Identifier</dt>
<dd><t>See <xref
format="default"/>.</t></dd>
<dt>EXT: Extension</dt>
<dd>
<dl newline="false" spacing="normal" indent="4">
<dt>0:</dt>
<dd>No extension byte follows.</dd>
<dt>1:</dt>
<dd>Extension byte <tt>EXT_0</tt>
follows immediately. See <xref
format="default"/>.</dd>
</dl>
</dd>
</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 optionalHop-By-Hop Header TLVs are defined in <xreftarget="RFC two optionalhop-by-hop header TLVs are defined in <xref
8609" format="default"/>, but several more can be defined inhighertarget="RFC8609"
level specifications. For the compression specified in the format="default"/>, but several more can be defined inhigher-level
previous section, theHop-By-Hop TLVs are ordered as follows: specifications. For the compression specified in the
previous section, thehop-by-hop TLVs are ordered as follows:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>InterestLifetime TLV</li> <li>InterestLifetime TLV</li>
<li>Message Hash TLV</li> <li>Message Hash TLV</li>
</ol> </ol>
<t>Note: OtherHop-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 theShould the following TLVs be in 'camel case'? "Message Hash" and "Recommended Ca
same order as in the original message, but after theInterest Lifetiche Time"
me TLV and Message Hash TLV.</t>
Current (Sections 6.3.2.1 and 6.4.2.1):
Note: Otherhop-by-hop header TLVs than those two remain uncompressed
in the encodedmessage, and they appear in the same order as in the
original messagebut 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
originalmessage 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 theInterestLifetime
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 80 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 atype and Additionally, a Sigtime TLV is inlined without aType and
alength field.</dd> aLength 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 atype and Additionally, a Sigtime TLV is inlined without aType and
alength field.</dd> aLength 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 1448skipping 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 ispresent and thetype <dd>A T_SHA-256 TLV ispresent, and theType
field as well as the length fields are removed. Thelength and Length fields are removed. TheLength
field is assumed to represent 32 bytes. The outerKeyId field is assumed to represent 32 bytes. The outerKeyID
TLV is omitted.</dd> TLV is omitted.</dd>
<dt>11:</dt> <dt>11:</dt>
<dd>A T_SHA-512 TLV ispresent and thetype <dd>A T_SHA-512 TLV ispresent, and theType
field as well as the length fields are removed. Thelength and Length fields are removed. TheLength
field is assumed to represent 64 bytes. The outerKeyId field is assumed to represent 64 bytes. The outerKeyID
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. Thetype field is omitted.</t> TLV is present. TheType field is omitted.</t>
</section> </section>
</section> </section>
<section anchor="sec.ccnx.interest.ext0" numbered="true" toc="default"> <section anchor="sec.ccnx.interest.ext0" 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 format="default"/> and is illustrated description in <xref format="default"/> and is illustrated
in <xref format="default"/>.</t> in <xref format="default"/>.</t>
<figure anchor="fig.ccnx.interest.ext0"> <figure anchor="fig.ccnx.interest.ext0">
<name>EXT_0format</name> <name>EXT_0Format</name>
<artwork align="center" name="" type="" alt=""><![CDATA[<artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 4 5 6 70 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 format="default"/>).</dd> compression strategy (see <xref 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 Contentobject uses the base dispatch format (see <t>An uncompressed ContentObject uses the base dispatch format (see
<xref format="default"/>) and sets the C flag t <xref format="default"/>) and sets the C flag t
o<tt>0</tt>, the P and M flags too
<tt>0</tt> and the P and M flags to
<tt>1</tt> (<xref format="default"/>). <tt>1</tt> (<xref format="default"/>).
The Contentobject is handed to the CCNx network stack without modifications.</t> The ContentObject is handed to the CCNx network stack without modifications.</t>
<figure anchor="fig.ccnx.data.uncompr"> <figure anchor="fig.ccnx.data.uncompr">
<name>Dispatchformat for uncompressed CCNx Content objects</name> <name>DispatchFormat 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 Contentobject uses the extended dispatch format <t>The compressed ContentObject uses the extended dispatch format
(<xref format="default"/>) and sets the C (<xref format="default"/>) and sets the C
, P,as well as the Mflag to <tt>1</tt>., P,and M
If a Contentobject contains TLVs that are notmentioned in thefollowflags to <tt>1</tt>. If a ContentObject contains TLVs that are notmen
ing compressiontioned in
thefollowing 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 Contentobject is compressed with the following <t>By default, the ContentObject 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 theFixed Header.</li> <li>Theversion is elided from the fixed header and assumed to be
1.</li>
<li>The PacketType field is elided from thefixed 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 theFixed Header on decompression.</li> and are obtained from thefixed header on decompression.</li>
</ol> </ol>
<t>The compressed CCNx LoWPAN Data message is visualized in <xref target="fig.ccnx.data.newformat" format="default"/>.</t> <t>The compressed CCNx LoWPAN Data message is visualized in <xref target="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 = ValueT = Type, L = Length, V = Value
Lc = Compressed Length, Vc = Compressed ValueLc = Compressed Length, Vc = Compressed Value
: = optional field, | = mandatory field: = optional field, | = mandatory field
+-----------------------------+ +-------------------------++-----------------------------+ +-------------------------+
skipping to change at line 1587skipping 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 format="default"/>.</t> in <xref format="default"/>.</t>
<figure anchor="fig.ccnx.datacompr"> <figure anchor="fig.ccnx.datacompr">
<name>Dispatchformat for compressed CCNx Content objects</name> <name>DispatchFormat 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 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 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 <xrefformat="default"/>. <dd>See <xref
</dd>format="default"/>.</dd>
<dt>FRS: Reserved field in the fixed header</dt> <dt>FRS: Reserved field in the fixed header</dt>
<dd>See <xrefformat="default"/>. <dd>See <xref
</dd>format="default"/>.</dd>
<dt>PAY: Optional Payload TLV</dt> <dt>PAY: Optional Payload TLV</dt>
<dd>See <xrefformat="default"/>. <dd>See <xref
</dd>format="default"/>.</dd>
<dt>RCT: OptionalHop-By-Hop RecommendedCacheTime TLV</dt> <dt>RCT: Optionalhop-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 ispresent <dd>The Recommended Cache Time TLV ispresent,
and thetype as well as the length fields are elided.</dd> and theType and Length fields are elided.</dd>
</dl> </dl>
</dd> </dd>
<dt>MGH: OptionalHop-By-Hop MessageHash TLV</dt> <dt>MGH: Optionalhop-by-hop MessageHash TLV</dt>
<dd> <dd>
<t><br/></t> <t>See <xref format="default"/> for
<t>See <xref format="default"/> forfurthefurther 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 ispresent and thetype as <dd>A T_SHA-256 TLV ispresent, and theType and
well as the length fields are removed. Thelength field is Length fields are removed. TheLength field is
assumed to represent 32 bytes. The outer Message Hash TLV assumed to represent 32 bytes. The outer Message Hash TLV
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 ispresent and thetype <dd>The ExpiryTime TLV ispresent, and theType
as well as the length fields are elided.</dd> and Length fields are elided.</dd>
</dl> </dl>
</dd> </dd>
<dt>VAL: Optional ValidationAlgorithm and ValidationPayloadTLVs</dt <dt>VAL: Optional ValidationAlgorithm and ValidationPayload
>TLVs</dt>
<dd>See <dd>See
<xref format="default"/>.</dd> <xref 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 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 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 optionalHop-By-Hop Header TLVs are defined in <xrefta message, two optionalhop-by-hop header TLVs are defined in
rget="RFC8609" format="default"/>, but several more can bedefined inhigher <xreftarget="RFC8609" format="default"/>, but several more can bede
level specifications. For the compression specified in thefined in
previous section, theHop-By-Hop TLVs are ordered as follows:higher-level specifications. For the compression specified in the
previous section, thehop-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: OtherHop-By-Hop Header TLVs than those two remain <t>Note: Otherhop-by-hop header TLVs than those two remain
uncompressed in the encodedmessage and they appear in the uncompressed in the encodedmessage, and they appear in the
same order as in the originalmessage, but after the RecommendedCac same order as in the originalmessage but after the RecommendedCach
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 format="default"/> and is illustrated description in <xref format="default"/> and is illustrated
in <xref format="default"/>.</t> in <xref format="default"/>.</t>
<figure anchor="fig.ccnx.data.ext0"> <figure anchor="fig.ccnx.data.ext0">
<name>EXT_0format</name> <name>EXT_0Format</name>
<artwork align="center" name="" type="" alt=""><![CDATA[<artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 4 5 6 70 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 format="default"/>).</dd> compression strategy (see <xref 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 timevalues described in <xref section="5" sectionFormat="of" format="default"/> with the constant factor <tt>C</tt> set to <tt>C := relative time-values described in <xref section="5" sectionFormat="of" format="default"/> with the constant factor <tt>C</tt> set to <tt>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 format="default"/> for time-codes with exponent <xref format="default"/> for time-codes with exponent
0 to provide an increased precision and a gradual underflow 0 to provide an increased precision and a gradual underflow
for the smallest numbers. The formula is changed as for the smallest numbers. The formula is changed as
follows (a := mantissa; b := exponent): follows (a := mantissa, b := exponent):
</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 format="default"/>) <dd> (1 + a/8) * 2<sup>b</sup> * C (see <xref format="default"/>)
</dd> </dd>
</dl> </dl>
<t><t>This configuration allows for the followingranges:</t>
<ul spacing="compact">
This configuration allows for the followingranges:<li>Minimum subnormalnumber: 0 seconds</li>
<li>2nd minimum subnormalnumber: ~0.007812 seconds</li>
</t> <li>Maximum subnormalnumber: ~0.054688 seconds</li>
<dl newline="false" spacing="compact"> <li>Minimum normalizednumber: ~0.062500 seconds</li>
<dt>Minimum subnormalnumber:</dt> <li>2nd minimum normalizednumber: ~0.070312 seconds</li>
<dd>0 seconds</dd> <li>Maximum normalizednumber: ~3.99 years</li>
<dt>2nd minimum subnormalnumber:</dt> </ul>
<dd>~0.007812 seconds</dd>
<dt>Maximum subnormalnumber:</dt>
<dd>~0.054688 seconds</dd>
<dt>Minimum normalizednumber:</dt>
<dd>~0.062500 seconds</dd>
<dt>2nd minimum normalizednumber:</dt>
<dd>~0.070312 seconds</dd>
<dt>Maximum normalizednumber:</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 that is time-value <bcp14>MUST</bcp14> be set to the largest valid time-value that is
smaller than the invalid input value before compression. smaller than the invalid input value before compression.
</t> </t>
</section> </section>
<section anchor="stateful.compression" numbered="true" toc="default"> <section anchor="stateful.compression" 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 inthecontext state at all
nodes and omitted from communication. Second, redundancy in a single nodes and omitted from communication. Second, redundancy in a single
Interest-data exchange may be removed from ICN stateful forwarding on aInterest-Data exchange may be removed from ICN stateful forwarding on a
hop-by-hopbases and memorized in en-route state tables.</t> hop-by-hopbasis and memorized in en-route state tables.</t>
<section anchor="stateful.compression.local" numbered="true" toc="default"> <section anchor="stateful.compression.local" numbered="true" toc="default">
<name>LoWPAN-local State</name><name>LoWPAN-Local State</name>
<t>Acontext identifier (CID) is a byte that refers to a particular <t>AContext Identifier (CID) is a byte that refers to a particular
conceptual context between network devices and <bcp14>MAY</bcp14> be used to replace conceptual context between network devices and <bcp14>MAY</bcp14> be used 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 alocally-scoped unique identifier that <t>The 7-bit ContextID is alocally scoped unique identifier that
represents contextual state shared between sender and receiverof the representsthe contextual state shared betweenthe sender and receivero
f the
corresponding frame (see <xref format="default"/>). corresponding frame (see <xref format="default"/>).
If set the most significant bit indicates the presence of another, subsequent If set, the most significant bit indicates the presence of another, subsequent
ContextID byte (see <xref format="default"/>).</t> ContextID byte (see <xref format="default"/>).</t>
<t>Context state shared between senders and receivers is removedfrom th<t>The context state shared between senders and receivers is removedfro
em the
compressed packet prior tosending, and reinserted after reception compressed packet prior tosending and reinserted after reception
prior to passing to the upper stack.</t> prior to passing to the upper stack.</t>
<t>The actual information in a context and how it is encoded are out of scope of this document. <t>The actual information in a context and how it is encoded are out of scope of this document.
The initial distribution and maintenance of shared context is out The initial distribution and maintenance of shared context is out
of scope of this document. Frames containing unknown or invalid CIDs <bcp14>MUST</bcp14> be silently discarded.</t> of scope of this document. Frames containing unknown or invalid CIDs <bcp14>MUST</bcp14> be silently discarded.</t>
</section> </section>
<section anchor="stateful.compression.en-route" numbered="true" toc="default"> <section anchor="stateful.compression.en-route" numbered="true" toc="default">
<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 indata messages. Returning Name TLVs either equal the they return inData messages. Returning Name TLVs either equal the
original NameTLV, orthey contain the original Name TLV as a prefix. original NameTLV or contain the original Name TLV as a prefix.
ICN LoWPAN reduces this redundancy in responses by replacing Name TLVs ICN LoWPAN reduces this redundancy in responses by replacing Name TLVs
with single bytes that represent link-local HopIDs. HopIDs are with single bytes that represent link-local HopIDs. HopIDs are
carried as Context Identifiers (see <xref format="default"/>) of link-local scope as shown in <xref format="default"/>.</t> carried as Context Identifiers (see <xref format="default"/>) of link-local scope, as shown in <xref 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 state exhausted, the messages <bcp14>MUST</bcp14> be sent without en-route state
compression until new HopIDs are available. An ICN LoWPAN node that compression until new HopIDs are available. An ICN LoWPAN node that
forwards without replacing the name by a HopID (without en-route forwards without replacing the name by a HopID (without en-route
compression) <bcp14>MUST</bcp14> invalidate the HopID by setting all ID-bits to compression) <bcp14>MUST</bcp14> invalidate the HopID by setting all IDbits to
zero.</t> zero.</t>
<t>While an Interest is traversing, a forwarder generates an ephemeral <t>While an Interest is traversing, a forwarder generates an ephemeral
HopID that is tied to aPIT entry. Each HopID <bcp14>MUST</bcp14> beuni HopID that is tied to aPending Interest Table (PIT) entry. Each HopID
que within <bcp14>MUST</bcp14> beunique 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 target="fig.enroute-a" format="default"/>). </t> new HopID is stored in the HIDo column of the local PIT (see <xref target="fig.enroute-a" format="default"/>). </t>
<figure anchor="fig.enroute-a"> <figure anchor="fig.enroute-a">
<name>Settingcompression state en-route (Interest).</name> <name>SettingCompression 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 format="default"/>). </t> the response (<xref format="default"/>). </t>
<figure anchor="fig.enroute-b"> <figure anchor="fig.enroute-b">
<name>Eliding Name TLVsusing en-route state (data).</name> <name>Eliding Name TLVsUsing 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 1939skipping 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 format="default"/>). The CID is appended to the last ICN <t>A CID appears whenever the CID flag is set (see <xref format="default"/>). The CID is appended to the last ICN
LoWPAN dispatch byte as shown in <xref format="default"/>.</t> LoWPAN dispatch byte, as shown in <xref format="default"/>.</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 format="default"/>). This allows to use multiple shared contexts in compressed messages.</t> indicating the presence of a subsequent CID (<xref format="default"/>). This allows to use multiple shared contexts in compressed messages.</t>
<t>The HopID is always included as the very first CID.</t> <t>The HopID is always included as the very first CID.</t>
<figure anchor="fig.cid.chain"> <figure anchor="fig.cid.chain">
<name>Chaining ofcontext identifiers.</name> <name>Chaining ofContext 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 format="default"/> in an extension of the NDN/CCNx software stack <xref format="default"/> in
its IoT version on RIOT <xref format="default"/>. An experimental its IoT version on RIOT <xref format="default"/>. An experimental
evaluation for NDN over ICNLOWPAN with varying configurations has been evaluation for NDN over ICNLoWPAN with varying configurations has been
performed in <xref format="default"/>. Energyprofiling performed in <xref format="default"/>. Energyprofilin
s andg 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 offsetscompress as per <xreftarget="sec.compressedti <li>Signed time offsetscompress, per <xreftarget="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) isdistributed, such that<li>The contextual state (e.g., prefixes) isdistributed such that
long names can be elided from Interest anddata messages.</li> long names can be elided from Interest andData 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 ofGenericNameComponent type and are limited to a Name components are oftype 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 format="default"/>) is optimized for short <li>The name compression scheme (<xref format="default"/>) is optimized for short
name components ofGenericNameComponent type. An empirical name components oftype GenericNameComponent. An empirical
study on name lengths in different deployments of selected study on name lengths in different deployments of selected
use cases, such as smart home, smart city, and industrial use cases, such as smart home, smart city, and industrial
IoT can provide meaningful reports on necessary name IoT can provide meaningful reports on necessary name
component types and lengths. A conclusive outcome helps to component types and lengths. A conclusive outcome helps to
understand whether and how extension mechanisms are needed understand whether and how extension mechanisms are needed
(<xref format="default"/>). As a preliminary (<xref format="default"/>). As a preliminary
analysis, <xref format="default"/> investigates the analysis, <xref format="default"/> investigates the
effectiveness of the proposed compression scheme with URLs effectiveness of the proposed compression scheme with URLs
obtained from the WWW. Studies onCoAP <xref format="default"/> deployments can offer additional insights obtained from the WWW. Studies ondeployments of Constrained Application Protocol (CoAP) <xref format="default"/> can offer additional insights
on naming schemes in the IoT.</li> on naming schemes in the IoT.</li>
<li>The fragmentation scheme (<xref format="default"/>) inherited from 6LoWPAN allows <li>The fragmentation scheme (<xref 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 format="default"/> with selective packets. Fragment forwarding <xref format="default"/> with selective
fragment recovery <xref format="default"/> can improve the fragment recovery <xref format="default"/> can improve the
end-to-end latency andreliability, while it reduces buffer end-to-end latency andreliability while it reduces buffer
requirements on forwarders. Initial evaluations(<xrefSFR-ICNL
LOWPAN" format="default"/>) show that a naive integration ofOWPAN"
format="default"/> show that a naive integration of
these upcoming fragmentation features into ICN LoWPAN these upcoming fragmentation features into ICN LoWPAN
renders the hop-wise content replication inoperative, since renders the hop-wise content replication inoperative, since
Interest anddata messages are reassembled end-to-end. More Interest andData messages are reassembled end-to-end. More
deployment experiences are necessary to gauge the deployment experiences are necessary to gauge the
feasibility of different fragmentation schemes in ICN feasibility of different fragmentation schemes in ICN
LoWPAN. LoWPAN.
</li> </li>
<li>Context state (<xrefformat="d<li>The context state (<xref
efault"/>) holds informationformat="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 ofthe contextual state
can potentially be adopted from <xref section="7.2" s can potentially be adopted from <xref section="7.2" s
ectionFormat="of"format="default"/>, but requires further evaluations. WhileectionFormat="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 format="default"/>) supports a limited <li>The stateful en-route compression (<xref 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 thePending insight on the number of open requests stored in the
Interest Table of memory-constrained devices. This numberPIT of memory-constrained devices. This number
can serve as anupper-bound and determines whether the HopID can serve as anupper bound and determines whether the HopID
length needs to be resized to fit more HopIDsto the cost of length needs to be resized to fit more HopIDsat the cost of
additional 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 illuminateonthe complexity of implementing ICN help to illuminate the complexity of implementing ICN
LoWPAN for constrained devices, as well as on maintaining LoWPAN for constrained devices, as well as on maintaining
interoperability with 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 format="default"/> can potentially prevent fragment buffer saturation in forwarders.</t> <xref 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 devices.</t> link layer should be deployed. IEEE 802.15.4, e.g., provides capabilities to protect frames and restrict them to a point-to-point link or a group of devices.</t>
</section> </section>
<section anchor="iana" numbered="true" toc="default"> <section anchor="iana" 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 valuesof the<tt>6LoWPAN Dispatch Type Fi <t>IANA has assigned dispatch valuesfor ICN LoWPAN in the"Dispatch Typ
eld</tt>e Field"
registry <xrefformat="default"/><xref subregistry <xref format="default"/><xrefdefault"/>with Page025" format="default"/> of
TBD1 for ICN LoWPAN. <xrefformat="default" the "IPv6 Low Power Personal Area Network Parameters" registry.
/> representsupdates to the registry.</t> <xrefformat="default"/> representsthe upd
ates to the registry.</t>
<table anchor="tab.iana.dispatches" align="center"> <table anchor="tab.iana.dispatches" align="center">
<name>Dispatchtypes for NDN and CCNx with page TBD1.</name> <name>DispatchTypes for NDN and CCNx Dispatch Types with Page 14</name>
<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">00100000</td> <td align="center">0001xxxx</td>
<tdalign="center">TBD1</td> <tdalign="center">14</td>
<tdalign="left">Uncompressed NDNData messages</td> <tdalign="left">Compressed NDNInterest messages</td>
<td align="left">RFC 9139</td>
</tr> </tr>
<tr> <tr>
<tdalign="center">01 000000</td> <tdalign="center">00 100000</td>
<tdalign="center">TBD1</td> <tdalign="center">14</td>
<td align="left">UncompressedCCNx Interest messages</td> <td align="left">UncompressedNDN Data messages</td>
<td align="left">RFC 9139</td>
</tr> </tr>
<tr> <tr>
<tdalign="center">01 100000</td> <tdalign="center">00 11xxxx</td>
<tdalign="center">TBD1</td> <tdalign="center">14</td>
<tdalign="left">Uncompressed CCNx Content Object messages</td> <tdalign="left">Compressed NDN Data messages</td>
<td align="left">RFC 9139</td>
</tr> </tr>
<tr> <tr>
<tdalign="center">10 0xxxxx</td> <tdalign="center">01 000000</td>
<tdalign="center">TBD1</td> <tdalign="center">14</td>
<tdalign="left">Compressed NDN Interest messages</td> <tdalign="left">Uncompressed CCNx Interest messages</td>
<td align="left">RFC 9139</td>
</tr> </tr>
<tr> <tr>
<tdalign="center">10 1xxxxx</td> <tdalign="center">01 01xxxx</td>
<tdalign="center">TBD1</td> <tdalign="center">14</td>
<td align="left">CompressedNDN Data messages</td> <td align="left">CompressedCCNx Interest messages</td>
<td align="left">RFC 9139</td>
</tr> </tr>
<tr> <tr>
<tdalign="center">11 0xxxxx</td> <tdalign="center">01 100000</td>
<tdalign="center">TBD1</td> <tdalign="center">14</td>
<tdalign="left">Compressed CCNxInterest messages</td> <tdalign="left">Uncompressed CCNxContent Object messages</td>
<td align="left">RFC 9139</td>
</tr> </tr>
<tr> <tr>
<tdalign="center">11 1xxxxx</td> <tdalign="center">01 11xxxx</td>
<tdalign="center">TBD1</td> <tdalign="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 to="ICNRG-FLIC"/><displayreference 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.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4944.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4944.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5497.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5497.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6256.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6256.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml"/>
<!-- [rfced][ieee802.15.4] The URL below is correct. Thefull title is "IEEE80<!-- [rfced] Thefollowing 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]
"IEEEStd. 802.15.4-2015", April 2016,
<https://standards.ieee.org/findstds/
standard/802.15.4-2015.html>.
-->
-&gt;
<reference anchor="ieee802.15.4"> <reference anchor="ieee802.15.4">
<front> <front>
<title>IEEEStd. 802.15.4-2015</title> <title>IEEEStandard 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"> <reference anchor="IEEE.754.2019">
<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.RFC.7252.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7476.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7476.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7927.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7927.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7945.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7945.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml"/>
<!--<?rfc include="reference.RFC.7400"?>--> <!--<?rfc include="reference.RFC.7400"?>-->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8025.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8025.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8609.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8609.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8569.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8569.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8930.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8930.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8931.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.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 info -->
<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"/>
</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"> <reference anchor="CCN-LITE">
<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"> <reference anchor="RIOT">
<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 ThingsJournal" value="Vol. 5, No.<refcontent>IEEE Internet of ThingsJournal 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"> <reference anchor="NDN-EXP1">
<front> <front>
<title>InformationCentric Networking in the IoT:Experiments with <title>Informationcentric networking in the IoT:experiments with
NDN in theWild</title> NDN in thewild</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-CentricNetwor<refcontent>Proc. of 1st ACM Conf. on Information-CentricNetworking (
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"> <reference anchor="NDN-EXP2">
<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-CentricNetwor<refcontent>Proc. of 5th ACM Conf. on Information-CentricNetworking (
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"> <reference anchor="NDN-MAC">
<front> <front>
<title>TheNeed for aName to MACAddress Mapping in NDN:Towards <title>Theneed for aname to MACaddress mapping in NDN:towards
Quantifying theResource Gain</title> quantifying theresource 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-CentricNetwor<refcontent>Proc. of 4th ACM Conf. on Information-CentricNetworking (
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"> <reference anchor="SFR-ICNLOWPAN">
<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-CentricNetwor<refcontent>Proc. of 7th ACM Conf. on Information-CentricNetworking (
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"> <reference anchor="NDN">
<front> <front>
<title>NetworkingNamed Content</title> <title>Networkingnamed 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"/>
<datemonth="December" year="2009"/>
</front> </front>
<seriesInfo name="5th Int. Conf. on emerging Networking Experimentsan<refcontent>5th Int. Conf. on emerging Networking Experimentsand 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"> <reference anchor="NDN-PACKET-SPEC">
<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"> <reference anchor="TLV-ENC-802.15.4">
<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"> <reference anchor="WIRE-FORMAT-CONSID">
<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"> <reference anchor="ICNLOWPAN">
<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 componentsis <tt>clen</tt>. The lengths of TLV componentsare
specific to the CCNx or NDN encoding and outlined below.</t> specific to the CCNx or NDN encoding andare outlined below.</t>
<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,
the1 byte form of each TLV component is assumed. A typical TLV the1-byte form of each TLV component is assumed. A typical TLV
component therefore is of size 2(type field +length field) + the component therefore is of size 2(Type field +Length field) + the
actual value.</t> actual value.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Interest</name> <name>Interest</name>
<t><xref format="default"/> depicts the <t><xref format="default"/> depicts the
size requirements for a basic, uncompressed NDN Interest containing size requirements for a basic, uncompressed NDN Interest containing
a CanBePrefix TLV, a MustBeFresh TLV,a InterestLifetime TLV set to a CanBePrefix TLV, a MustBeFresh TLV,an InterestLifetime TLV set to
4seconds and a HopLimit TLV set to 6. Numbers below represent the 4seconds, and a HopLimit TLV set to 6. Numbers below represent the
amount of bytes.</t> amount of bytes.</t>
<figure anchor="fig.Size.NDN.interest.uncompressed"> <figure anchor="fig.Size.NDN.interest.uncompressed">
<name>Estimatedsize of an uncompressed NDN Interest</name> <name>EstimatedSize 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 format="default"/> depicts the <t><xref 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>Estimatedsize of a compressed NDN Interest</name> <name>EstimatedSize 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 format="default"/> depicts the size <t><xref format="default"/> depicts 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 isassumed, and the value is encoded using 1 byte. An HMACWithSha256 is
assumed as signature. The key locator is assumed to contain a Name assumed asa signature. The key locator is assumed to contain a Name
TLV of length klen.</t> TLV of length klen.</t>
<figure anchor="fig.Size.NDN.Data.uncompressed"> <figure anchor="fig.Size.NDN.Data.uncompressed">
<name>Estimatedsize of an uncompressed NDN Data</name> <name>EstimatedSize 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 2523skipping to change at line 2647
SignatureValue | | SignatureValue | |
DigestSha256 | | DigestSha256 | |
---------------------' | ---------------------' |
------------------------------------'------------------------------------'
]]></artwork>]]></artwork>
</figure> </figure>
<t><xref format="default"/> depicts the size <t><xref format="default"/> depicts 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>Estimatedsize of a compressed NDN Data</name> <name>EstimatedSize 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 fortype and <t>The CCNx TLV encoding defines a 2-byte encoding forType and
length fields, summing up to 4 bytes in total without a value.</t>Length fields, summing up to 4 bytes in total without a value.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Interest</name> <name>Interest</name>
<t><xref format="default" <t><xref 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 behop-by-hop TLVs are included, the protocol version is assumed to be
1 and thereserved field is assumed to be 0. A KeyIdRestriction TLV1, and theReserved field is assumed to be 0. A KeyIdRestriction TLV
with T_SHA-256 is included to limit the responses to Content Objects with T_SHA-256 is included to limit the responses to Content Objects
containing the specific key.</t> containing the specific key.</t>
<figure anchor="fig.Size.CCNx.interest.uncompressed"> <figure anchor="fig.Size.CCNx.interest.uncompressed">
<name>Estimatedsize of an uncompressed CCNx Interest</name> <name>EstimatedSize 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 format="default"/> <t><xref 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>Estimatedsize of a compressed CCNx Interest</name> <name>EstimatedSize 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_nName | = 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 format="default"/>d <t><xref format="default"/>
epicts the sizedepicts the size
requirements for a basic, uncompressed CCNx Content Object requirements for a basic, uncompressed CCNx Content Object
containing an ExpiryTime Message TLV, an HMAC_SHA-256 signature, the containing an ExpiryTime Message TLV, an HMAC_SHA-256 signature, the
signaturetime and a hash of the shared secret key. In the fixed signaturetime, and a hash of the shared secret key. In the fixed
header, the protocol version is assumed to be 1 and thereserved header, the protocol version is assumed to be 1 and theReserved
field is assumed to be 0</t> field is assumed to be 0</t>
<figure anchor="fig.Size.CCNx.Data.uncompressed"> <figure anchor="fig.Size.CCNx.Data.uncompressed">
<name>Estimatedsize of an uncompressed CCNx Content Object</name> <name>EstimatedSize 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 format="default"/>dep <t><xref format="default"/>
icts the sizedepicts 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>Estimatedsize of a compressed CCNx Data Object</name> <name>EstimatedSize 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 groupand the communities of RIOT and CCNlite. We would like to and the communities of RIOT and CCNlite. We would like to
thank all active members for constructive thoughts and feedback. In thank all active members for constructive thoughts and feedback. In
particular, the authors would like to thank (in alphabetical order) particular, the authors would like to thank (in alphabetical order)
Peter Kietzmann, Dirk Kutscher, Martine Lenders, Colin Perkins, Junxiao Sh<contact fullname="Peter Kietzmann"/>, <contact fullname="Dirk Kutscher"/>
i. The,
<contact fullname="Martine Lenders"/>, <contact fullname="Colin Perkins"/>
,
and <contact fullname="Junxiao Shi"/>. The
hop-wise stateful name compression was brought up in a discussion by hop-wise stateful name compression was brought up in a discussion by
Dave Oran, which is gratefully acknowledged. Larger parts of this work<contact fullname="Dave Oran"/>, which is gratefully acknowledged.
are inspired by <xref format="default"/> and <xreftarget Larger parts of this work
="RFC6282" format="default"/>. are inspired by <xref format="default"/> and
Specialmentioning goes toMark Mosko as well asG.Q. Wang andRavi <xreftarget="RFC6282" format="default"/>.
Ravindran as their previous work in <xrefformat Specialmention 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 <xrefformat="default"
/>
and <xref format="default"/> provided a good base for our and <xref format="default"/> provided a good base for our
discussions on stateless header compression mechanisms. discussions on stateless header compression mechanisms.
Many thanks also toCarsten Bormann andLars Eggert, who contributedin-de Many thanks also to<contact fullname="Carsten Bormann"/> and
pth commentsduring the IRSG review.<contact fullname="Lars Eggert"/>, who contributedin-depth commentsdurin
g
the IRSG review.
This work was supported in part by the German Federal Ministry of Research and This work was supported in part by the German Federal Ministry of Research and
Education within the projects I3 and RAPstore.</t> Education within the projects I3 and RAPstore.</t>
</section> </section>
<!--[rfced] Throughout the text, the following terminology appears to be used in
consistently. Please review these occurences and let us know if/how they may be
made consistent.
context state vs. contextual state
ContextID vs. CID
Sigtime vs. SignatureTime
Ranges are also formatted inconsistently:
"range (1...127)" vs "range [128;252]"
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online Style
Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let
us know if any changes are needed. For example, please consider whether "traditi
onal" or "native" should be updated for clarity.
While the NIST website <https://www.nist.gov/nist-research-library/nist-technica
l-series-publications-author-instructions#table1> indicates that "traditional" i
s potentially biased, it is also ambiguous. "Tradition" is a subjective term, a
s it is not the same for everyone.
-->
</back> </back>
</rfc></rfc>
 End of changes. 338 change blocks. 
691 lines changed or deleted831 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available fromhttp://tools.ietf.org/tools/rfcdiff/
[8]ページ先頭
©2009-2026 Movatter.jp