<?xml version="1.0"encoding="US-ASCII"?>encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <?rfc toc="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc compact="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc linkmailto="no" ?> <?rfc rfcedstyle="yes"?> <?rfc-ext allow-markup-in-artwork="yes" ?> <?rfc-ext include-references-in-index="yes" ?>[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfccategory="exp" docName="draft-irtf-icnrg-icnlowpan-10"xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-irtf-icnrg-icnlowpan-11" number="9139" ipr="trust200902"submissionType="IRTF">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 --> <front> <!--[rfced] Please ensure that the guidelines listed in Section 2.1 of RFC 5743 have been adhered to in this document. --> <!--[rfced] The expansions of "ICN LoWPAN in the document title and Terminology section differs. May we update the title as follows? Original: ICN Adaptation to LoWPAN Networks (ICN LoWPAN) Perhaps: Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs) --> <title abbrev="ICN Adaptation to LoWPANs">ICN Adaptation to LoWPAN Networks (ICN LoWPAN)</title> <seriesInfo name="RFC" value="9139"/> <!-- [rfced] Cenk, we have updated the spelling of your surname from "Gundogan" to "Gündogan" based on the information found at <https://inet.haw-hamburg.de/members/cenk-gundogan>. Please let us know if any changes are necessary. --> <author fullname="Cenk Gundogan" initials="C." surname="Gundogan"> <organization abbrev="HAW Hamburg">HAW Hamburg</organization> <address> <postal> <street>Berliner Tor 7</street> <city>Hamburg</city> <code>D-20099</code> <country>Germany</country> </postal> <phone>+4940428758067</phone> <email>cenk.guendogan@haw-hamburg.de</email> <uri>http://inet.haw-hamburg.de/members/cenk-gundogan</uri> </address> </author> <author fullname="Thomas C. Schmidt" initials="TC." surname="Schmidt"> <organization abbrev="HAW Hamburg">HAW Hamburg</organization> <address> <postal> <street>Berliner Tor 7</street> <city>Hamburg</city> <code>D-20099</code> <country>Germany</country> </postal> <email>t.schmidt@haw-hamburg.de</email> <uri>http://inet.haw-hamburg.de/members/schmidt</uri> </address> </author> <!-- [rfced] Matthias, we have updated the spelling of your surname from "Waehlisch" 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="MatthiasWaehlisch"Wählisch" initials="M."surname="Waehlisch">surname="Wählisch"> <organization abbrev="link-lab & FU Berlin">link-lab & FU Berlin</organization> <address> <postal> <street>Hoenower Str. 35</street> <city>Berlin</city> <code>D-10318</code> <country>Germany</country> </postal> <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> </author> <author fullname="Christopher Scherb" initials="C." surname="Scherb"> <organization abbrev="University of Basel">University of Basel</organization> <address> <postal> <street>Spiegelgasse 1</street> <city>Basel</city><code>CH-4051</code><code>4051</code> <country>Switzerland</country> </postal> <email>christopher.scherb@unibas.ch</email> </address> </author> <author fullname="Claudio Marxer" initials="C." surname="Marxer"> <organization abbrev="University of Basel">University of Basel</organization> <address> <postal> <street>Spiegelgasse 1</street> <city>Basel</city><code>CH-4051</code><code>4051</code> <country>Switzerland</country> </postal> <email>claudio.marxer@unibas.ch</email> </address> </author> <author fullname="Christian Tschudin" initials="C." surname="Tschudin"> <organization abbrev="University of Basel">University of Basel</organization> <address> <postal> <street>Spiegelgasse 1</street> <city>Basel</city><code>CH-4051</code><code>4051</code> <country>Switzerland</country> </postal> <email>christian.tschudin@unibas.ch</email> </address> </author><date/> <workgroup>ICN Research Group</workgroup><date year="2021" month="November" /> <workgroup>Information-Centric Networking</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract> <t>This document defines a convergence layer forCCNxContent-Centric Networking (CCNx) andNDNNamed Data Networking (NDN) over IEEE 802.15.4LoWPAN networks.Low-Power Wireless Personal Area Networks (LoWPANs). A new frame format is specified to adapt CCNx and NDN packets to the small MTU size of IEEE 802.15.4. For that, syntactic and semantic changes to the TLV-based header formats are described. To support compatibility with other LoWPAN technologies that may coexist on a wireless medium, the dispatching scheme provided by6LoWPANIPv6 over LoWPAN (6LoWPAN) is extended to include new dispatch types for CCNx and NDN. Additionally, the fragmentation component of the 6LoWPAN dispatching framework is applied toICNInformation-Centric Network (ICN) chunks. In its second part, the document defines stateless and stateful compression schemes to improve efficiency on constrained links. Stateless compression reduces TLV expressions to static header fields for common use cases. Stateful compression schemes elidestatestates local to the LoWPAN and replace names indataData packets by short local identifiers.</t> <t>This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).</t> </abstract> </front> <middle> <section anchor="intro"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>The Internet of Things (IoT) has been identified as a promising deployment area forInformation Centric NetworksInformation-Centric Networking (ICN), as infrastructureless access to content, resilient forwarding, and in-network data replicationdemonstrateddemonstrates notable advantages over the traditional host-to-host approach on the Internet <xreftarget="NDN-EXP1"/>,target="NDN-EXP1" format="default"/> <xreftarget="NDN-EXP2"/>.target="NDN-EXP2" format="default"/>. Recent studies <xreftarget="NDN-MAC"/>target="NDN-MAC" format="default"/> have shown that an appropriate mapping tolink layerlink-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 where nodes often exchange messages via low-power wireless links under lossy conditions. In this memo, we address the base adaptation of data chunks to such link layers for the ICN flavors NDN <xreftarget="NDN"/>target="NDN" format="default"/> and CCNx <xreftarget="RFC8569"/>,target="RFC8569" format="default"/> <xreftarget="RFC8609"/>.</t>target="RFC8609" format="default"/>.</t> <t>The IEEE 802.15.4 <xreftarget="ieee802.15.4"/>target="ieee802.15.4" format="default"/> link layer is used in low-power and lossy networks (see<spanx style="verb">LLN</spanx><tt>LLN</tt> in <xreftarget="RFC7228"/>),target="RFC7228" format="default"/>), in which devices are typicallybattery-operatedbattery operated and constrained in resources. Characteristics of LLNs include an unreliable environment,low bandwidthlow-bandwidth transmissions, and increased latencies. IEEE 802.15.4 admits a maximumphysical layerphysical-layer 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 further reduce this payload length by up to 21 bytes, yielding a net of 81 bytes for CCNx or NDN packet headers,signaturessignatures, and content.</t> <t>6LoWPAN <xreftarget="RFC4944"/><xref target="RFC6282">, </xref>target="RFC4944" format="default"/> <xref target="RFC6282" format="default"/> is a convergence layer that provides frame formats, headercompressioncompression, andadaptation layeradaptation-layer fragmentation for IPv6 packets in IEEE 802.15.4 networks. The 6LoWPAN adaptation introduces a dispatching framework that prepends further information to 6LoWPAN packets, including a protocol identifier for payload and meta information about fragmentation.</t> <t>PrevalentType-Length-Value (TLV) basedpacket formats based on Type-Length-Value (TLV), such as in CCNx andNDNNDN, are designed to be generic and extensible. This leads to headerverbosityverbosity, which is inappropriate in constrained environments of IEEE 802.15.4 links. This document presents ICN LoWPAN, a convergence layer for IEEE 802.15.4 motivated by 6LoWPAN. ICN LoWPAN compresses packet headers ofCCNxCCNx, as well asNDNNDN, and allows for an increased effective payload size per packet. Additionally, reusing the dispatching framework defined by 6LoWPAN enables compatibility between coexisting wireless deployments of competing network technologies. This also allowstoreuse of theadaptation layeradaptation-layer fragmentation scheme specified by 6LoWPAN for ICN LoWPAN.</t> <t>ICN LoWPAN defines a morespace efficientspace-efficient representation of CCNx and NDN packet formats. This syntactic change is described for CCNx and NDN separately, as the header formats and TLV encodings differ notably. For further reductions, default header values suitable for constrained IoT networks are selected in order to elide corresponding TLVs. Experimental evaluations of the ICN LoWPAN header compression schemes in <xreftarget="ICNLOWPAN"/>target="ICNLOWPAN" format="default"/> illustrate a reduced message overhead, a shortened message airtime, and an overall decline in power consumption for typical Class 2<xref target="RFC7228"/>devices <xref target="RFC7228" format="default"/> compared to uncompressed ICN messages.</t> <t>In a typical IoT scenario (see <xreftarget="fig-iot_network">target="fig-iot_network" format="default"> </xref>), embedded devices are interconnected via a quasi-stationary infrastructure using a border router (BR) that connects the constrained LoWPAN network by someGatewaygateway with the public Internet. InICN basedICN-based IoT networks,non-localnonlocal Interest and Data messages transparently travel through the BR up and down between aGatewaygateway and the embedded devices situated in the constrained LoWPAN.</t> <figureanchor="fig-iot_network" title="IoTanchor="fig-iot_network"> <name>IoT StubNetwork">Network</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ |Gateway Services| ------------------------- | ,--------, | | | BR | | | '--------' LoWPAN O O O O O embedded O O O devices O O ]]></artwork> </figure> <t> The document has received fruitful reviews by members of the ICN community and the research group (seeAcknowledgments)the Acknowledgments section) for a period of two years. 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. </t> </section> <sectiontitle="Terminology"> <t>Thenumbered="true" toc="default"> <name>Terminology</name> <!--[rfced] Please note that we have added RFC 8174 to the Normative References section and updated the text in the Terminology section below. Additionally, the term "silently ignored" is not used in this document, so we have removed the text describing it. Please let us know if you have any concerns. Original: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119<xref target="RFC2119"/>.[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 similarlyconstrued.</t>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>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> <t>This document uses the terminology of <xreftarget="RFC7476"/>,target="RFC7476" format="default"/>, <xreftarget="RFC7927"/>,target="RFC7927" format="default"/>, and <xreftarget="RFC7945"/>target="RFC7945" format="default"/> for ICN entities.</t> <t>The following terms are used in the document and defined as follows:<list hangIndent="14" style="hanging"> <t hangText="ICN LoWPAN:">Information-Centric</t> <dl newline="false" spacing="normal" indent="14"> <dt>ICN LoWPAN:</dt> <dd>Information-Centric Networking overLow-powerLow-Power Wireless Personal AreaNetwork</t> <t hangText="LLN:">Low-PowerNetwork</dd> <dt>LLN:</dt> <dd>Low-Power and LossyNetwork</t> <t hangText="CCNx:">Content-Centric Networking Architecture</t> <t hangText="NDN:">NamedNetwork</dd> <dt>CCNx:</dt> <dd>Content-Centric Networking</dd> <dt>NDN:</dt> <dd>Named DataNetworking Architecture</t> <t hangText="byte:">synonym for octet</t> <t hangText="nibble:">synonymNetworking</dd> <dt>byte:</dt> <dd>synonym for octet</dd> <dt>nibble:</dt> <dd>synonym for 4bits</t> <t hangText="time-value:">abits</dd> <dt>time-value:</dt> <dd>a time offset measured inseconds</t> <t hangText="time-code:">anseconds</dd> <dt>time-code:</dt> <dd>an 8-bit encodedtime-value</t> </list></t>time-value</dd> </dl> </section> <section anchor="ICNLoWPAN"title="Overviewnumbered="true" toc="default"> <name>Overview of ICNLoWPAN ">LoWPAN</name> <sectiontitle="Link-Layer Convergence">numbered="true" toc="default"> <name>Link-Layer Convergence</name> <t>ICN LoWPAN provides a convergence layer that maps ICN packets onto constrained link-layer technologies. This includes features such as link-layer fragmentation, protocol separation on the link-layer level, and link-layer address mappings. The stack traversal is visualized in <xreftarget="fig.intro.hbh"/>.</t>target="fig.intro.hbh" format="default"/>.</t> <figureanchor="fig.intro.hbh" title="ICNanchor="fig.intro.hbh"> <name>ICN LoWPANconvergence layerConvergence Layer for IEEE802.15.4">802.15.4</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ Device 1 Device 2 ,------------------, Router ,------------------, | Application . | __________________ | ,-> Application | |----------------|-| | NDN / CCNx | |-|----------------| | NDN / CCNx | | | ,--------------, | | | NDN / CCNx | |----------------|-| |-|--------------|-| |-|----------------| | ICN LoWPAN | | | | ICN LoWPAN | | | | ICN LoWPAN | |----------------|-| |-|--------------|-| |-|----------------| |Link-LayerLink Layer | | | |Link-LayerLink Layer | | | |Link-LayerLink Layer | '----------------|-' '-|--------------|-' '-|----------------' '--------' '---------' ]]></artwork> </figure> <t><xreftarget="sec.lowpan_adaptation"/>target="sec.lowpan_adaptation" format="default"/> of this document defines the convergence layer for IEEE 802.15.4.</t> </section> <sectiontitle="Statelessnumbered="true" toc="default"> <name>Stateless HeaderCompression">Compression</name> <t>ICN LoWPAN also defines a stateless header compression scheme with the main purpose of reducing header overhead of ICN packets. This is of particular importance forlink-layerslink layers with small MTUs. The stateless compression does not requirepre-configurationpreconfiguration of a global state.</t> <!-- [rfced] Does adding the term "format" help with the readability of the following 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 (TLV) fields to encode header data. 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.</t> <t>The stateless header compression scheme makes use of compact bit fields to indicate the presence of optional TLVs in the uncompressed 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 specifying default values and reducing the range of certain header fields.</t> <t><xreftarget="fig.TLV.compressed"/>target="fig.TLV.compressed" format="default"/> demonstrates the stateless 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 second TLV represents a fixed-length TLV (e.g., the Nonce TLV in NDN), so that thetypeType andthe lengthLength fields are removed. The third TLV represents a boolean TLV (e.g., the MustBeFresh selector in NDN) for which thetype, lengthType, Length, andthe valueValue fields are elided.</t> <figureanchor="fig.TLV.compressed" title="Compression usinganchor="fig.TLV.compressed"> <name>Compression Using acompact bit field - bits encodeCompact Bit Field -- Bits Encode theinclusionInclusion ofTLVs.">TLVs</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ Uncompressed: Variable-length TLV Fixed-length TLV Boolean TLV ,-----------------------,-----------------------,-------------, +-------+-------+-------+-------+-------+-------+------+------+ | TYP | LEN | VAL | TYP | LEN | VAL | TYP | LEN | +-------+-------+-------+-------+-------+-------+------+------+ Compressed: +---+---+---+---+---+---+---+---+ | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | BitfieldField +---+---+---+---+---+---+---+---+ | | | ,--' '----, '- Boolean Value | | +-------+-------+-------+ | LEN | VAL | VAL | +-------+-------+-------+ '---------------'-------' Var-len Value Fixed-len Value ]]></artwork> </figure> <t>Stateless TLV compression for NDN is defined in <xreftarget="sec.ndn"/>.target="sec.ndn" format="default"/>. <xreftarget="sec.ccnx"/>target="sec.ccnx" format="default"/> defines the stateless TLV compression for CCNx.</t> <t>The extensibility of this compression is described in <xreftarget="sec.dispatch.ext"/>target="sec.dispatch.ext" format="default"/> and allows future documents to update the compression rules outlined in thismanuscript.</t>document.</t> </section> <sectiontitle="Statefulnumbered="true" toc="default"> <name>Stateful HeaderCompression">Compression</name> <t>ICN LoWPAN further employs twoorthogonalorthogonal, stateful compression schemes for packet sizereductionsreductions, which are defined in <xreftarget="stateful.compression"/>.target="stateful.compression" format="default"/>. These mechanisms rely on shared contexts that are either distributed and maintained in the entireLoWPAN,LoWPAN or are generatedon-demandon demand hop-wise on a particularInterest-dataInterest-Data path.</t> <t>The shared context identification is defined in <xreftarget="stateful.compression.local"/>.target="stateful.compression.local" format="default"/>. The hop-wise name compression "en-route" is specified in <xreftarget="stateful.compression.en-route"/>.</t>target="stateful.compression.en-route" format="default"/>.</t> </section> </section> <section anchor="sec.lowpan_adaptation"title="IEEEnumbered="true" toc="default"> <name>IEEE 802.15.4Adaptation">Adaptation</name> <section anchor="sec.lowpan_encap"title="LoWPAN Encapsulation">numbered="true" toc="default"> <name>LoWPAN Encapsulation</name> <t>The IEEE 802.15.4 frame header does not provide a protocol identifier for its payload. This causes problems of misinterpreting frames when several network layers coexist on the same link. To mitigate errors, 6LoWPAN defines dispatches as encapsulation headers for IEEE 802.15.4 frames (seeSection 5 of<xreftarget="RFC4944"/>).target="RFC4944" section="5" sectionFormat="of" format="default"/>). Multiple LoWPAN encapsulation headers can precede the actualpayloadpayload, and each encapsulation header is identified by a dispatch type.</t> <!-- [rfced] In the following sentence, should "dispatch table" be instead "dispatch Page"? Current: When a LoWPAN parser encounters a Page switch LoWPAN encapsulation header, all following encapsulation headers are interpreted by using a dispatch table, as specified by the Page switch header. Perhaps: When a LoWPAN parser encounters a Page switch LoWPAN encapsulation header, all following encapsulation headers are interpreted by using a dispatch Page, as specified by the Page switch header. --> <t><xreftarget="RFC8025"/>target="RFC8025" format="default"/> further specifies dispatchpagesPages to switch between different contexts. When a LoWPAN parser encounters a<spanx style="verb">Page switch</spanx><tt>Page switch</tt> LoWPAN encapsulation header,thenall following encapsulation headers are interpreted by using a dispatchtabletable, as specified by the<spanx style="verb">Page switch</spanx><tt>Page switch</tt> header.PagePages 0 andpage1 are reserved for 6LoWPAN. This document usespage TBD1 (<spanx style="verb">1111 TBD1 (0xFTBD1)</spanx>)Page 14 (<tt>1111 1110 (0xFE)</tt>) for ICN LoWPAN.</t> <t>The base dispatch format (<xreftarget="fig.disp.base"/>)target="fig.disp.base" format="default"/>) is used and extended by CCNx and NDN in Sections <xreftarget="sec.ndn"/>target="sec.ndn" format="counter"/> and <xreftarget="sec.ccnx"/>.</t>target="sec.ccnx" format="counter"/>.</t> <figureanchor="fig.disp.base" title="Base dispatch formatanchor="fig.disp.base"> <name>Base Dispatch Format for ICNLoWPAN">LoWPAN</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 ...+---+---+-----------+---+---+---+---+--- |C0 | P | M |+---+---+-----------C | +---+---+---+---+--- ]]></artwork> </figure><t><list hangIndent="4" style="hanging"> <t hangText="C: Compression"><list hangIndent="12" style="hanging"> <t hangText="0:">The message is uncompressed.</t> <t hangText="1:">The message is compressed.</t> </list></t> <t hangText="P: Protocol"><list hangIndent="12" style="hanging"> <t hangText="0:">The<dl newline="true" spacing="normal" indent="4"> <dt>P: Protocol</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>The included protocol isNDN.</t> <t hangText="1:">TheNDN.</dd> <dt>1:</dt> <dd>The included protocol isCCNx.</t> </list></t> <t hangText="M:CCNx.</dd> </dl> </dd> <dt>M: MessageType"><list hangIndent="12" style="hanging"> <t hangText="0:">TheType</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>The payload contains an Interestmessage.</t> <t hangText="1:">Themessage.</dd> <dt>1:</dt> <dd>The payload contains a Datamessage.</t> </list></t> </list></t>message.</dd> </dl> </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> <t>ICN LoWPAN frames with compressed CCNx and NDN messages (C=1) use the extended dispatch format in <xreftarget="fig.disp.base.compr"/>.</t>target="fig.disp.base.compr" format="default"/>.</t> <figureanchor="fig.disp.base.compr" title="Extended dispatch formatanchor="fig.disp.base.compr"> <name>Extended Dispatch Format forcompressedCompressed ICNLoWPAN">LoWPAN</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 34...+---+---+---+---+---+---... +---+---+---+---+...+---+---+ |10 | P | M | 1 | |CID|EXT|+---+---+---+---+---+---+---+---+---+---+...+---+---+ ]]></artwork> </figure><t><list hangIndent="4" style="hanging"> <t hangText="CID:<dl newline="true" spacing="normal" indent="4"> <dt>CID: ContextIdentifier"><list hangIndent="12" style="hanging"> <t hangText="0:">NoIdentifier</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>No context identifiers arepresent.</t> <t hangText="1:">Contextpresent.</dd> <dt>1:</dt> <dd>Context identifier(s) are present (see <xreftarget="stateful.compression.local"/>).</t> </list></t> <t hangText="EXT: Extension"><list hangIndent="12" style="hanging"> <t hangText="0:">Notarget="stateful.compression.local" format="default"/>).</dd> </dl> </dd> <dt>EXT: Extension</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>No extension bytes arepresent.</t> <t hangText="1:">Extensionpresent.</dd> <dt>1:</dt> <dd>Extension byte(s) are present (see <xreftarget="sec.dispatch.ext"/>).</t> </list></t> </list></t>target="sec.dispatch.ext" format="default"/>).</dd> </dl> </dd> </dl> <t>The encapsulation format for ICN LoWPAN is displayed in <xreftarget="fig.ICN-LoWPAN.header"/>.</t>target="fig.ICN-LoWPAN.header" format="default"/>.</t> <figureanchor="fig.ICN-LoWPAN.header" title="LoWPANanchor="fig.ICN-LoWPAN.header"> <name>LoWPAN Encapsulation withICN-LoWPAN">ICN LoWPAN</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ +------...------+------...-----+--------+-------...-------+-----... | IEEE 802.15.4 | RFC4944 Disp.| Page | ICN LoWPAN Disp.| Payl. / +------...------+------...-----+--------+-------...-------+-----... ]]></artwork> </figure><t><list hangIndent="16" style="hanging"> <t hangText="IEEE 802.15.4:">The<dl newline="false" spacing="normal" indent="16"> <dt>IEEE 802.15.4:</dt> <dd>The IEEE 802.15.4header.</t> <t hangText="RFC4944 Disp.:">Optionalheader.</dd> <dt>RFC4944 Disp.:</dt> <dd>Optional additional dispatches defined inSection 5.1 of<xreftarget="RFC4944"/></t> <t hangText="Page:">Page Switch. TBD1target="RFC4944" section="5.1" sectionFormat="of" format="default"/>.</dd> <dt>Page:</dt> <dd><tt>Page switch</tt>. 14 for ICNLoWPAN.</t> <t hangText="ICN LoWPAN:">DispatchesLoWPAN.</dd> <dt>ICN LoWPAN:</dt> <dd>Dispatches as defined in Sections <xreftarget="sec.ndn"/>target="sec.ndn" format="counter"/> and <xreftarget="sec.ccnx"/>.</t> <t hangText="Payload:">Thetarget="sec.ccnx" format="counter"/>.</dd> <dt>Payload:</dt> <dd>The actual (un-)compressed CCNx or NDNmessage.</t> </list></t>message.</dd> </dl> <section anchor="sec.dispatch.ext"title="Dispatch Extensions">numbered="true" toc="default"> <name>Dispatch Extensions</name> <t>Extension bytes allow for the extensibility of the initial compression rule set. The base format for an extension byte is depicted in <xreftarget="fig.ext.base"/>.</t>target="fig.ext.base" format="default"/>.</t> <figureanchor="fig.ext.base" title="Base formatanchor="fig.ext.base"> <name>Base Format fordispatch extensions.">Dispatch Extensions</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | - | - | - | - | - | - | - |EXT| +---+---+---+---+---+---+---+---+ ]]></artwork> </figure><t><list hangIndent="4" style="hanging"> <t hangText="EXT: Extension"><list hangIndent="12" style="hanging"> <t hangText="0:">No<dl newline="true" spacing="normal" indent="4"> <dt>EXT: Extension</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>No other extension bytefollows.</t> <t hangText="1:">Afollows.</dd> <dt>1:</dt> <dd>A further extension bytefollows.</t> </list></t> </list></t>follows.</dd> </dl> </dd> </dl> <t>Extension bytes are numbered according to their order. Future documentsMUST<bcp14>MUST</bcp14> follow the naming scheme<spanx style="verb">EXT_0,<tt>EXT_0, EXT_1,...</spanx>,...</tt> when updating or referring to a specific dispatch extension byte. Amendments that require an exchange of configurational parameters between devicesSHOULD<bcp14>SHOULD</bcp14> use manifests to encode structured data in a well-defined format,as,e.g., as outlined in <xreftarget="I-D.irtf-icnrg-flic"/>.</t>target="I-D.irtf-icnrg-flic" format="default"/>.</t> </section> </section> <section anchor="sec.Fragmentation"title="Adaptation Layer Fragmentation">numbered="true" toc="default"> <name>Adaptation-Layer Fragmentation</name> <t>Small payload sizes in the LoWPAN require fragmentation for various network layers. Therefore,Section 5.3 of<xreftarget="RFC4944"/>target="RFC4944" section="5.3" sectionFormat="of" format="default"/> defines a protocol-independent fragmentation dispatch type, a fragmentation header for the first fragment, and a separate fragmentation header for subsequent fragments. ICN LoWPAN adopts this fragmentation handling of <xreftarget="RFC4944"/>.</t>target="RFC4944" format="default"/>.</t> <t>TheFragmentationfragmentation LoWPAN header can encapsulate other dispatch headers. The order of dispatch types is defined inSection 5 of<xreftarget="RFC4944"/>.target="RFC4944" section="5" sectionFormat="of" format="default"/>. <xreftarget="fig.fr_first"/>target="fig.fr_first" format="default"/> shows the fragmentation scheme. The reassembled ICN LoWPAN frame does not contain any fragmentation headers and is depicted in <xreftarget="fig.fr_done"/>.</t>target="fig.fr_done" format="default"/>.</t> <figureanchor="fig.fr_first" title="Fragmentation scheme"> <artwork align="center"><![CDATA[anchor="fig.fr_first"> <name>Fragmentation Scheme</name> <artwork align="center" name="" type="" alt=""><![CDATA[ +------...------+----...----+--------+------...-------+--------... | IEEE 802.15.4 | Frag. 1st | Page | ICN LoWPAN | Payload / +------...------+----...----+--------+------...-------+--------... +------...------+----...----+--------... | IEEE 802.15.4 | Frag. 2nd | Payload / +------...------+----...----+--------... . . . +------...------+----...----+--------... | IEEE 802.15.4 | Frag. Nth | Payload / +------...------+----...----+--------... ]]></artwork> </figure> <figureanchor="fig.fr_done" title="Reassembledanchor="fig.fr_done"> <name>Reassembled ICN LoWPANframe">Frame</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ +------...------+--------+------...-------+--------... | IEEE 802.15.4 | Page | ICN LoWPAN | Payload / +------...------+--------+------...-------+--------... ]]></artwork> </figure> <t>The 6LoWPAN Fragment Forwarding(6FF)(6LFF) <xreftarget="RFC8930"/>target="RFC8930" format="default"/> is an alternative approach that enables forwarding of fragments without reassembling packets on every intermediate hop. By reusing the 6LoWPAN dispatching framework,6FF6LFF integrates into ICN LoWPAN asseamlessseamlessly as the conventional hop-wise fragmentation.ExperimentalHowever, experimental evaluations <xreftarget="SFR-ICNLOWPAN"/>, however,target="SFR-ICNLOWPAN" format="default"/> suggest that amore refinedmore-refined integration can increase the cache utilization of forwarders on a request path.</t> </section> </section> <section anchor="sec.ndn"title="Space-efficientnumbered="true" toc="default"> <name>Space-Efficient Message Encoding forNDN">NDN</name> <section anchor="sec.tlvencoding"title="TLV Encoding">numbered="true" toc="default"> <name>TLV Encoding</name> <t>The NDN packet format consists of TLV fields using the TLV encoding that is described in <xreftarget="NDN-PACKET-SPEC"/>.target="NDN-PACKET-SPEC" format="default"/>. Type andlengthLength fields are of variable size, where numbers greater than 252 are encoded using multiple bytes.</t> <t>If the type or length number is less than<spanx style="verb">253</spanx>,<tt>253</tt>, then that number is encoded into the actualtypeType orlengthLength field. If the number is greater or equals<spanx style="verb">253</spanx><tt>253</tt> and fits into 2 bytes, then thetypeType orlengthLength field is set to<spanx style="verb">253</spanx><tt>253</tt> and the number is encoded in the next following 2 bytes in network byte order, i.e., from the most significant byte (MSB) to the least significant byte (LSB). If the number is greater than 2 bytes and fits into 4 bytes, then thetypeType orlengthLength field is set to<spanx style="verb">254</spanx><tt>254</tt> and the number is encoded in the subsequent 4 bytes in network byte order. For larger numbers, thetypeType orlengthLength field is set to<spanx style="verb">255</spanx><tt>255</tt> and the number is encoded in the subsequent 8 bytes in network byte order.</t> <t>In this specification, compressed NDN TLVs encodetypeType andlengthLength fields using self-delimiting numeric values (SDNVs) <xreftarget="RFC6256"/>target="RFC6256" format="default"/> commonly known fromDTNDelay-Tolerant Networking (DTN) protocols. Instead of using the first byte as a marker for the number of following bytes, SDNVs use a single bit to indicate subsequent bytes.</t><texttable<table anchor="tab.sdnvperformance"title="NDNalign="center"> <name>NDN TLVencoding comparedEncoding Compared toSDNVs."> <ttcol align="left">Value</ttcol> <ttcol align="left" width="35%">NDN TLV encoding</ttcol> <ttcol align="left" width="40%">SDNV encoding</ttcol> <c>0</c> <c>0x00</c> <c>0x00</c> <c>127</c> <c>0x7F</c> <c>0x7F</c> <c>128</c> <c>0x80</c> <c>0x81 0x00</c> <c>253</c> <c>0xFDSDNVs</name> <thead> <tr> <th align="left">Value</th> <th align="left">NDN TLV Encoding</th> <th align="left">SDNV Encoding</th> </tr> </thead> <tbody> <tr> <td align="left">0</td> <td align="left">0x00</td> <td align="left">0x00</td> </tr> <tr> <td align="left">127</td> <td align="left">0x7F</td> <td align="left">0x7F</td> </tr> <tr> <td align="left">128</td> <td align="left">0x80</td> <td align="left">0x81 0x00</td> </tr> <tr> <td align="left">253</td> <td align="left">0xFD 0x000xFD</c> <c>0x81 0x7D</c> <c>2^140xFD</td> <td align="left">0x81 0x7D</td> </tr> <tr> <td align="left">2<sup>14</sup> -1</c> <c>0xFD1</td> <td align="left">0xFD 0x3F0xFF</c> <c>0xFF 0x7F</c> <c>2^14</c> <c>0xFD0xFF</td> <td align="left">0xFF 0x7F</td> </tr> <tr> <td align="left">2<sup>14</sup></td> <td align="left">0xFD 0x400x00</c> <c>0x810x00</td> <td align="left">0x81 0x800x00</c> <c>2^16</c> <c>0xFE0x00</td> </tr> <tr> <td align="left">2<sup>16</sup></td> <td align="left">0xFE 0x00 0x01 0x000x00</c> <c>0x840x00</td> <td align="left">0x84 0x800x00</c> <c>2^210x00</td> </tr> <tr> <td align="left">2<sup>21</sup> -1</c> <c>0xFE1</td> <td align="left">0xFE 0x00 0x1F 0xFF0xFF</c> <c>0xFF0xFF</td> <td align="left">0xFF 0xFF0x7F</c> <c>2^21</c> <c>0xFE0x7F</td> </tr> <tr> <td align="left">2<sup>21</sup></td> <td align="left">0xFE 0x00 0x20 0x000x00</c> <c>0x810x00</td> <td align="left">0x81 0x80 0x800x00</c> <c>2^280x00</td> </tr> <tr> <td align="left">2<sup>28</sup> -1</c> <c>0xFE1</td> <td align="left">0xFE 0x0F 0xFF 0xFF0xFF</c> <c>0xFF0xFF</td> <td align="left">0xFF 0xFF 0xFF0x7F</c> <c>2^28</c> <c>0xFE0x7F</td> </tr> <tr> <td align="left">2<sup>28</sup></td> <td align="left">0xFE 0x1F 0x00 0x000x00</c> <c>0x810x00</td> <td align="left">0x81 0x80 0x80 0x800x00</c> <c>2^32</c> <c>0xFF0x00</td> </tr> <tr> <td align="left">2<sup>32</sup></td> <td align="left">0xFF 0x00 0x00 0x00 0x01 0x00 0x00 0x000x00</c> <c>0x900x00</td> <td align="left">0x90 0x80 0x80 0x800x00</c> <c>2^350x00</td> </tr> <tr> <td align="left">2<sup>35</sup> -1</c> <c>0xFF1</td> <td align="left">0xFF 0x00 0x00 0x00 0x07 0xFF 0xFF 0xFF0xFF</c> <c>0xFF0xFF</td> <td align="left">0xFF 0xFF 0xFF 0xFF0x7F</c> <c>2^35</c> <c>0xFF0x7F</td> </tr> <tr> <td align="left">2<sup>35</sup></td> <td align="left">0xFF 0x00 0x00 0x00 0x08 0x00 0x00 0x000x00</c> <c>0x810x00</td> <td align="left">0x81 0x80 0x80 0x80 0x800x00</c> </texttable>0x00</td> </tr> </tbody> </table> <t> <xreftarget="tab.sdnvperformance"/>target="tab.sdnvperformance" format="default"/> compares the required bytes for encoding a few selected values using the NDN TLV encoding and SDNVs. For values up to 127, both methods require a single byte. Values in the range [128;252] encode as one byte for the NDN TLV scheme, while SDNVs require two bytes. Starting at value 253, SDNVs require a less or equal amount of bytes compared to the NDN TLV encoding. </t> </section> <section anchor="sec.ndn.namecompression"title="Namenumbered="true" toc="default"> <name>Name TLVCompression">Compression</name> <t>This Name TLV compression encodeslengthLength fields of two consecutive NameComponent TLVs into one byte, using a nibble for each. 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. A length of 0 marks the end of the compressed Name TLV. The lastlengthLength field of an encoded NameComponent is either 0x00 for a name with an even number ofcomponents,components and 0xYF (Y>> 0) if an odd number of components are present. This process limits the length of a NameComponent TLV to 15bytes,bytes but allows for an unlimited number of components. An example for this encoding is presented in <xreftarget="fig.ndnshortnco"/>.</t>target="fig.ndnshortnco" format="default"/>.</t> <figureanchor="fig.ndnshortnco" title="Nameanchor="fig.ndnshortnco"> <name>Name TLVcompressionCompression for/HAW/Room/481/Humid/99">/HAW/Room/481/Humid/99</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ Name: /HAW/Room/481/Humid/99 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 0 1 1|0 1 0 0| H | A | W | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R | o | o | m | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 1|0 1 0 1| 4 | 8 | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H | u | m | i | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d |0 0 1 0|0 0 0 0| 9 | 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> </section> <sectiontitle="Interest Messages"> <section title="Uncompressednumbered="true" toc="default"> <name>Interest Messages</name> <section numbered="true" toc="default"> <name>Uncompressed InterestMessages">Messages</name> <t>An uncompressed Interest message uses the base dispatch format (see <xreftarget="fig.disp.base"/>)target="fig.disp.base" format="default"/>) and sets theC flag to <spanx style="verb">0</spanx>C, P, andthe P as well as theMflagflags to<spanx style="verb">0</spanx><tt>0</tt> (<xreftarget="fig.ndn.int.uncompr"/>).target="fig.ndn.int.uncompr" format="default"/>). <!--[rfced] As the last "N" in "NDN" stands for "Networking" may we remove "network" from instances of "NDN network stack" (e.g., it reads as Named Data Networking network stack)? Note that there are 2 instances. --> The Interest message is handed to the NDN network stack without modifications.</t> <figureanchor="fig.ndn.int.uncompr" title="Dispatch formatanchor="fig.ndn.int.uncompr"> <name>Dispatch Format foruncompressedUncompressed NDN Interestmessages">Messages</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +---+---+---+---+---+---+---+---+ ]]></artwork> </figure> </section> <sectiontitle="Compressednumbered="true" toc="default"> <name>Compressed InterestMessages">Messages</name> <t>The compressed Interest message uses the extended dispatch format (<xreftarget="fig.disp.base.compr"/>)target="fig.disp.base.compr" format="default"/>) and sets the C flag to<spanx style="verb">1</spanx>,<tt>1</tt> and the Pflag to <spanx style="verb">0</spanx>andtheMflagflags to<spanx style="verb">0</spanx>.<tt>0</tt>. If an Interest message contains TLVs that are not mentioned in the following compression rules, then this messageMUST<bcp14>MUST</bcp14> be sent uncompressed.</t> <t>This specification assumes that a HopLimit TLV is part of the original Interest message. If such a HopLimit TLV is not present, it will be inserted with a default value of DEFAULT_NDN_HOPLIMIT prior to the compression.</t> <t>In the default use case, the Interest message is compressed with the following minimal rule set:<list style="numbers"> <t>The <spanx style="verb">Type</spanx></t> <ol spacing="normal" type="1"> <li>The <tt>Type</tt> field of the outermost MessageType TLV isremoved.</t> <t>Theremoved.</li> <li>The Name TLV is compressed according to <xreftarget="sec.ndn.namecompression"/>.target="sec.ndn.namecompression" format="default"/>. For this, all NameComponents are expected to be of type GenericNameComponent with a length greater than 0. An ImplicitSha256DigestComponent or ParametersSha256DigestComponentMAY<bcp14>MAY</bcp14> appear at the end of the name. In any other case, the messageMUST<bcp14>MUST</bcp14> be sentuncompressed.</t> <t>Theuncompressed.</li> <li>The Nonce TLV and InterestLifetime TLV are moved to the end of the compressedInterestInterest, as illustrated in <xreftarget="fig.ndn.int.newformat"/>.target="fig.ndn.int.newformat" format="default"/>. The InterestLifetime is encoded as described in <xreftarget="sec.compressedtime"/>.target="sec.compressedtime" format="default"/>. On decompression, this encoding may yield anInterestlifetimeInterestLifetime that is smaller than the originalvalue.</t> <t>Thevalue.</li> <li>The Type and Length fields of Nonce TLV, HopLimitTLVTLV, and InterestLifetime TLV are elided. The Nonce value has a length of 4bytesbytes, and the HopLimit value has a length of 1 byte. The compressed InterestLifetime (<xreftarget="sec.compressedtime"/>)target="sec.compressedtime" format="default"/>) has a length of 1 byte. The presence of a Nonce TLV and InterestLifetime TLV is deduced from the remaining length to parse. A remaining length of<spanx style="verb">1</spanx><tt>1</tt> indicates the presence of anInerestLifetime,InterestLifetime, a length of<spanx style="verb">4</spanx><tt>4</tt> indicates the presence of a nonce, and a length of<spanx style="verb">5</spanx><tt>5</tt> indicates the presence of bothTLVs.</t> </list></t>TLVs.</li> </ol> <t>The compressed NDN LoWPAN Interest message is visualized in <xreftarget="fig.ndn.int.newformat"/>.</t>target="fig.ndn.int.newformat" format="default"/>.</t> <figureanchor="fig.ndn.int.newformat" title="Compressionanchor="fig.ndn.int.newformat"> <name>Compression of NDN LoWPAN InterestMessage">Message</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ T = Type, L = Length, V = Value Lc = Compressed Length, Vc = Compressed Value : = optional field, | = mandatory field +---------+---------+ +---------+ | Msg T | Msg L | | Msg Lc | +---------+---------+---------+ +---------+ | Name T | Name L | Name V | | Name Vc | +---------+---------+---------+ +---------+---------+ : CBPfx T : CBPfx L : : FWDH Lc : FWDH Vc : +---------+---------+ +---------+---------+ : MBFr T : MBFr L : | HPL V | +---------+---------+---------+ ==> +---------+---------+ : FWDH T : FWDH L : FWDH V : : APM Lc : APM Vc : +---------+---------+---------+ +---------+---------+ : NONCE T : NONCE L : NONCE V : : NONCE V : +---------+---------+---------+ +---------+ : ILT T : ILT L : ILT V : : ILT Vc : +---------+---------+---------+ +---------+ : HPL T : HPL L : HPL V : +---------+---------+---------+ : APM T : APM L : APM V : +---------+---------+---------+ ]]></artwork> </figure> <t>Further TLV compression is indicated by the ICN LoWPAN dispatch in <xreftarget="fig.ndn.intcompr"/>.</t>target="fig.ndn.intcompr" format="default"/>.</t> <figureanchor="fig.ndn.intcompr" title="Dispatch formatanchor="fig.ndn.intcompr"> <name>Dispatch Format forcompressedCompressed NDN Interestmessages">Messages</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |10 | 0 | 0|CID|EXT|PFX|FRE|FWD|APM|DIG| RSV| 1 |PFX|FRE|FWD|APM|DIG| RSV |CID|EXT| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ ]]></artwork> </figure><t><list hangIndent="4" style="hanging"> <t hangText="CID: Context Identifier">See <xref target="fig.disp.base.compr"/>.</t> <t hangText="EXT: Extension"><list hangIndent="8" style="hanging"> <t hangText="0:">No extension byte follows.</t> <t hangText="1:">Extension byte <spanx style="verb">EXT_0</spanx> follows immediately. See <xref target="sec.ndn.interest.ext0"/>.</t> </list></t> <t hangText="PFX:<dl newline="true" spacing="normal" indent="4"> <dt>PFX: CanBePrefixTLV"><list hangIndent="12" style="hanging"> <t hangText="0:">TheTLV</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>The uncompressed message does not include a CanBePrefixTLV.</t> <t hangText="1:">TheTLV.</dd> <dt>1:</dt> <dd>The uncompressed message does include a CanBePrefix TLV and is removed from the compressedmessage.</t> </list></t> <t hangText="FRE:message.</dd> </dl> </dd> <dt>FRE: MustBeFreshTLV"><list hangIndent="12" style="hanging"> <t hangText="0:">TheTLV</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>The uncompressed message does not include a MustBeFreshTLV.</t> <t hangText="1:">TheTLV.</dd> <dt>1:</dt> <dd>The uncompressed message does include a MustBeFresh TLV and is removed from the compressedmessage.</t> </list></t> <t hangText="FWD:message.</dd> </dl> </dd> <dt>FWD: ForwardingHintTLV"><list hangIndent="12" style="hanging"> <t hangText="0:">TheTLV</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>The uncompressed message does not include a ForwardingHintTLV.</t> <t hangText="1:">TheTLV.</dd> <dt>1:</dt> <dd>The uncompressed message does include a ForwardingHint TLV. The Type field is removed from the compressed message. Further, all link delegation types and link preference types are removed. All included names are compressed according to <xreftarget="sec.ndn.namecompression"/>.target="sec.ndn.namecompression" format="default"/>. If any name is not compressible, the messageMUST<bcp14>MUST</bcp14> be sentuncompressed.</t> </list></t> <t hangText="APM:uncompressed.</dd> </dl> </dd> <dt>APM: ApplicationParametersTLV"><list hangIndent="12" style="hanging"> <t hangText="0:">TheTLV</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>The uncompressed message does not include an ApplicationParametersTLV.</t> <t hangText="1:">TheTLV.</dd> <dt>1:</dt> <dd>The uncompressed message does include an ApplicationParameters TLV. The Type field is removed from the compressedmessage.</t> </list></t> <t hangText="DIG:message.</dd> </dl> </dd> <dt>DIG: ImplicitSha256DigestComponentTLV"><list hangIndent="12" style="hanging"> <t hangText="0:">TheTLV</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>The name does not include an ImplicitSha256DigestComponent as the lastTLV.</t> <t hangText="1:">TheTLV.</dd> <dt>1:</dt> <dd>The name does include an ImplicitSha256DigestComponent as the last TLV. The Type and Length fields areomitted.</t> </list></t> <t hangText="RSV: Reserved">Mustomitted.</dd> </dl> </dd> <dt>RSV: Reserved</dt> <dd>Must be set to0.</t> </list></t>0.</dd> <dt>CID: Context Identifier</dt> <dd>See <xref target="fig.disp.base.compr" format="default"/>.</dd> <dt>EXT: Extension</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>No extension byte follows.</dd> <dt>1:</dt> <dd>Extension byte <tt>EXT_0</tt> follows immediately. See <xref target="sec.ndn.interest.ext0" format="default"/>.</dd> </dl> </dd> </dl> </section> <section anchor="sec.ndn.interest.ext0"title="Dispatch Extension">numbered="true" toc="default"> <name>Dispatch Extension</name> <t>The<spanx style="verb">EXT_0</spanx><tt>EXT_0</tt> byte follows the description in <xreftarget="sec.dispatch.ext"/>target="sec.dispatch.ext" format="default"/> and is illustrated in <xreftarget="fig.ndn.interest.ext0"/>.</t>target="fig.ndn.interest.ext0" format="default"/>.</t> <figureanchor="fig.ndn.interest.ext0" title="EXT_0 format"> <artwork align="center"><![CDATA[anchor="fig.ndn.interest.ext0"> <name>EXT_0 Format</name> <artwork align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | NCS | RSV |EXT| +---+---+---+---+---+---+---+---+ ]]></artwork> </figure><t><list hangIndent="4" style="hanging"> <t hangText="NCS:<dl newline="true" spacing="normal" indent="4"> <dt>NCS: Name CompressionStrategy"><list hangIndent="12" style="hanging"> <t hangText="00:">NamesStrategy</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>00:</dt> <dd>Names are compressed with the default name compression strategy (see <xreftarget="sec.ndn.namecompression"/>).</t> <t hangText="01:">Reserved.</t> <t hangText="10:">Reserved.</t> <t hangText="11:">Reserved.</t> </list></t> <t hangText="RSV: Reserved">Musttarget="sec.ndn.namecompression" format="default"/>).</dd> <dt>01:</dt> <dd>Reserved.</dd> <dt>10:</dt> <dd>Reserved.</dd> <dt>11:</dt> <dd>Reserved.</dd> </dl> </dd> <dt>RSV: Reserved</dt> <dd>Must be set to0.</t> <t hangText="EXT: Extension"><list hangIndent="8" style="hanging"> <t hangText="0:">No0.</dd> <dt>EXT: Extension</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>No extension bytefollows.</t> <t hangText="1:">Afollows.</dd> <dt>1:</dt> <dd>A further extension byte followsimmediately.</t> </list></t> </list></t>immediately.</dd> </dl> </dd> </dl> </section> </section> <sectiontitle="Data Messages">numbered="true" toc="default"> <name>Data Messages</name> <sectiontitle="Uncompressednumbered="true" toc="default"> <name>Uncompressed DataMessages">Messages</name> <t>An uncompressed Data message uses the base dispatch format and sets the Cflag to <spanx style="verb">0</spanx>, theand Pflagflags to<spanx style="verb">0</spanx><tt>0</tt> and the M flag to<spanx style="verb">1</spanx><tt>1</tt> (<xreftarget="fig.ndn.data.uncompr"/>).target="fig.ndn.data.uncompr" format="default"/>). The Data message is handed to the NDN network stack without modifications.</t> <figureanchor="fig.ndn.data.uncompr" title="Dispatch formatanchor="fig.ndn.data.uncompr"> <name>Dispatch Format foruncompressedUncompressed NDN Datamessages">Messages</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | +---+---+---+---+---+---+---+---+ ]]></artwork> </figure> </section> <sectiontitle="Compressednumbered="true" toc="default"> <name>Compressed DataMessages">Messages</name> <t>The compressed Data message uses the extended dispatch format (<xreftarget="fig.disp.base.compr"/>)target="fig.disp.base.compr" format="default"/>) and sets the Cas well as theand M flags to<spanx style="verb">1</spanx>.<tt>1</tt>. The P flag is set to<spanx style="verb">0</spanx>.<tt>0</tt>. If a Data message contains TLVs that are not mentioned in the following compression rules, then this messageMUST<bcp14>MUST</bcp14> be sent uncompressed.</t> <t>By default, the Data message is compressed with the following base rule set:<list style="numbers"> <t>The <spanx style="verb">Type</spanx></t> <ol spacing="normal" type="1"> <li>The <tt>Type</tt> field of the outermost MessageType TLV isremoved.</t> <t>Theremoved.</li> <li>The Name TLV is compressed according to <xreftarget="sec.ndn.namecompression"/>.target="sec.ndn.namecompression" format="default"/>. For this, all NameComponents are expected to be of type GenericNameComponent and to have a length greater than 0. In any other case, the messageMUST<bcp14>MUST</bcp14> be sentuncompressed.</t> <t>Theuncompressed.</li> <li>The MetaInfo TLV Type and Length fields are elided from the compressed Datamessage.</t> <t>Themessage.</li> <li>The FreshnessPeriod TLVMUST<bcp14>MUST</bcp14> be moved to the end of the compressed Data message. Type and Length fields areelidedelided, and the value is encoded as described in <xreftarget="sec.compressedtime"/>target="sec.compressedtime" format="default"/> as a 1-byte time-code. If the freshness period is not a valid time-value, then the messageMUST<bcp14>MUST</bcp14> be sent uncompressed in order to preserve the security envelope of the Data message. The presence of a FreshnessPeriod TLV is deduced from the remainingone byteone-byte length toparse.</t> <t>Theparse.</li> <li>The Type fields of the SignatureInfo TLV, SignatureTypeTLVTLV, and SignatureValue TLV areremoved.</t> </list></t>removed.</li> </ol> <t>The compressed NDN LoWPAN Data message is visualized in <xreftarget="fig.ndn.data.newformat"/>.</t>target="fig.ndn.data.newformat" format="default"/>.</t> <figureanchor="fig.ndn.data.newformat" title="Compressionanchor="fig.ndn.data.newformat"> <name>Compression of NDN LoWPAN DataMessage">Message</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ T = Type, L = Length, V = Value Lc = Compressed Length, Vc = Compressed Value : = optional field, | = mandatory field +---------+---------+ +---------+ | Msg T | Msg L | | Msg Lc | +---------+---------+---------+ +---------+ | Name T | Name L | Name V | | Name Vc | +---------+---------+---------+ +---------+---------+ : Meta T : Meta L : : CTyp Lc : CType V : +---------+---------+---------+ +---------+---------+ : CTyp T : CTyp L : CTyp V : : FBID V : +---------+---------+---------+ ==> +---------+---------+ : FrPr T : FrPr L : FrPr V : : CONT Lc : CONT V : +---------+---------+---------+ +---------+---------+ : FBID T : FBID L : FBID V : | Sig Lc | +---------+---------+---------+ +---------+---------+ : CONT T : CONT L : CONT V : | SInf Lc | SInf Vc | +---------+---------+---------+ +---------+---------+ | Sig T | Sig L | | SVal Lc | SVal Vc | +---------+---------+---------+ +---------+---------+ | SInf T | SInf L | SInf V | : FrPr Vc : +---------+---------+---------+ +---------+ | SVal T | SVal L | SVal V | +---------+---------+---------+ ]]></artwork> </figure> <t>Further TLV compression is indicated by the ICN LoWPAN dispatch in <xreftarget="fig.ndn.datacompr"/>.</t>target="fig.ndn.datacompr" format="default"/>.</t> <figureanchor="fig.ndn.datacompr" title="Dispatch formatanchor="fig.ndn.datacompr"> <name>Dispatch Format forcompressedCompressed NDN Datamessages">Messages</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |10 | 0 | 1|CID|EXT|FBI|CON|KLO| RSV| 1 |FBI|CON|KLO| RSV |CID|EXT| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ ]]></artwork> </figure><t><list hangIndent="4" style="hanging"> <t hangText="CID: Context Identifier">See <xref target="fig.disp.base.compr"/>.</t> <t hangText="EXT: Extension"><list hangIndent="8" style="hanging"> <t hangText="0:">No extension byte follows.</t> <t hangText="1:">Extension byte <spanx style="verb">EXT_0</spanx> follows immediately. See <xref target="sec.ndn.data.ext0"/>.</t> </list></t> <t hangText="FBI:<dl newline="true" spacing="normal" indent="4"> <dt>FBI: FinalBlockIdTLV"><list hangIndent="12" style="hanging"> <t hangText="0:">TheTLV</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>The uncompressed message does not include a FinalBlockIdTLV.</t> <t hangText="1:">TheTLV.</dd> <dt>1:</dt> <dd>The uncompressed message does include aFinalBlockIdFinalBlockId, and it is encoded according to <xreftarget="sec.ndn.namecompression"/>.target="sec.ndn.namecompression" format="default"/>. If the FinalBlockId TLV is not compressible, then the messageMUST<bcp14>MUST</bcp14> be sentuncompressed.</t> </list></t> <t hangText="CON:uncompressed.</dd> </dl> </dd> <dt>CON: ContentTypeTLV"><list hangIndent="12" style="hanging"> <t hangText="0:">TheTLV</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>The uncompressed message does not include a ContentTypeTLV.</t> <t hangText="1:">TheTLV.</dd> <dt>1:</dt> <dd>The uncompressed message does include a ContentType TLV. The Type field is removed from the compressedmessage.</t> </list></t> <t hangText="KLO:message.</dd> </dl> </dd> <dt>KLO: KeyLocatorTLV"><list hangIndent="12" style="hanging"> <t hangText="0:">IfTLV</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>If the included SignatureType requires a KeyLocator TLV, then the KeyLocator represents a name and is compressed according to <xreftarget="sec.ndn.namecompression"/>.target="sec.ndn.namecompression" format="default"/>. If the name is not compressible, then the messageMUST<bcp14>MUST</bcp14> be sentuncompressed.</t> <t hangText="1:">Ifuncompressed.</dd> <dt>1:</dt> <dd>If the included SignatureType requires a KeyLocator TLV, then the KeyLocator represents a KeyDigest. The Type field of this KeyDigest isremoved.</t> </list></t> <t hangText="RSV: Reserved">Mustremoved.</dd> </dl> </dd> <dt>RSV: Reserved</dt> <dd>Must be set to0.</t> </list></t>0.</dd> <dt>CID: Context Identifier</dt> <dd>See <xref target="fig.disp.base.compr" format="default"/>.</dd> <dt>EXT: Extension</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>No extension byte follows.</dd> <dt>1:</dt> <dd>Extension byte <tt>EXT_0</tt> follows immediately. See <xref target="sec.ndn.data.ext0" format="default"/>.</dd> </dl> </dd> </dl> </section> <section anchor="sec.ndn.data.ext0"title="Dispatch Extension">numbered="true" toc="default"> <name>Dispatch Extension</name> <t>The<spanx style="verb">EXT_0</spanx><tt>EXT_0</tt> byte follows the description in <xreftarget="sec.dispatch.ext"/>target="sec.dispatch.ext" format="default"/> and is illustrated in <xreftarget="fig.ndn.data.ext0"/>.</t>target="fig.ndn.data.ext0" format="default"/>.</t> <figureanchor="fig.ndn.data.ext0" title="EXT_0 format"> <artwork align="center"><![CDATA[anchor="fig.ndn.data.ext0"> <name>EXT_0 Format</name> <artwork align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | NCS | RSV |EXT| +---+---+---+---+---+---+---+---+ ]]></artwork> </figure><t><list hangIndent="4" style="hanging"> <t hangText="NCS:<dl newline="true" spacing="normal" indent="4"> <dt>NCS: Name CompressionStrategy"><list hangIndent="12" style="hanging"> <t hangText="00:">NamesStrategy</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>00:</dt> <dd>Names are compressed with the default name compression strategy (see <xreftarget="sec.ndn.namecompression"/>).</t> <t hangText="01:">Reserved.</t> <t hangText="10:">Reserved.</t> <t hangText="11:">Reserved.</t> </list></t> <t hangText="RSV: Reserved">Musttarget="sec.ndn.namecompression" format="default"/>).</dd> <dt>01:</dt> <dd>Reserved.</dd> <dt>10:</dt> <dd>Reserved.</dd> <dt>11:</dt> <dd>Reserved.</dd> </dl> </dd> <dt>RSV: Reserved</dt> <dd>Must be set to0.</t> <t hangText="EXT: Extension"><list hangIndent="8" style="hanging"> <t hangText="0:">No0.</dd> <dt>EXT: Extension</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>No extension bytefollows.</t> <t hangText="1:">Afollows.</dd> <dt>1:</dt> <dd>A further extension byte followsimmediately.</t> </list></t> </list></t>immediately.</dd> </dl> </dd> </dl> </section> </section> </section> <section anchor="sec.ccnx"title="Space-efficientnumbered="true" toc="default"> <name>Space-Efficient Message Encoding forCCNx">CCNx</name> <sectiontitle="TLV Encoding">numbered="true" toc="default"> <name>TLV Encoding</name> <t>The generic CCNx TLV encoding is described in <xreftarget="RFC8609"/>.target="RFC8609" format="default"/>. Type and Length fields attain the common fixed length of 2 bytes.</t> <t>The TLV encoding for CCNx LoWPAN is changed to the morespace efficientspace-efficient encoding described in <xreftarget="sec.tlvencoding"/>. Hencetarget="sec.tlvencoding" format="default"/>. Hence, NDN and CCNx use the same compressed format for writing TLVs.</t> </section> <sectiontitle="Namenumbered="true" toc="default"> <name>Name TLVCompression">Compression</name> <t>Name TLVs are compressed using the scheme already defined in <xreftarget="sec.ndn.namecompression"/>target="sec.ndn.namecompression" format="default"/> for NDN. If a Name TLV contains T_IPID, T_APP, or organizational TLVs, then the name remains uncompressed.</t> </section> <sectiontitle="Interest Messages"> <section title="Uncompressednumbered="true" toc="default"> <name>Interest Messages</name> <section numbered="true" toc="default"> <name>Uncompressed InterestMessages">Messages</name> <t>An uncompressed Interest message uses the base dispatch format (see <xreftarget="fig.disp.base"/>)target="fig.disp.base" format="default"/>) and sets the Cas well as theand Mflagflags to<spanx style="verb">0</spanx>.<tt>0</tt>. The P flag is set to<spanx style="verb">1</spanx><tt>1</tt> (<xreftarget="fig.ccnx.int.uncompr"/>).target="fig.ccnx.int.uncompr" format="default"/>). The Interest message is handed to the CCNx network stack without modifications.</t> <figureanchor="fig.ccnx.int.uncompr" title="Dispatch formatanchor="fig.ccnx.int.uncompr"> <name>Dispatch Format foruncompressedUncompressed CCNx Interestmessages">Messages</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | +---+---+---+---+---+---+---+---+ ]]></artwork> </figure> </section> <section anchor="sec.ccnxintcompbaseheader"title="Compressednumbered="true" toc="default"> <name>Compressed InterestMessages">Messages</name> <t>The compressed Interest message uses the extended dispatch format (<xreftarget="fig.disp.base.compr"/>)target="fig.disp.base.compr" format="default"/>) and sets the C and P flags to<spanx style="verb">1</spanx>.<tt>1</tt>. The M flag is set to<spanx style="verb">0</spanx>.<tt>0</tt>. If an Interest message contains TLVs that are not mentioned in the following compression rules, then this messageMUST<bcp14>MUST</bcp14> be sent uncompressed.</t> <t>In the default use case, the Interest message is compressed with the following minimal rule set:<list style="numbers"> <t>The</t> <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 and are obtained from theFixed Headerfixed header ondecompression.</t> </list></t>decompression.</li> </ol> <t>The compressed CCNx LoWPAN Interest message is visualized in <xreftarget="fig.ccnx.int.newformat"/>.</t>target="fig.ccnx.int.newformat" format="default"/>.</t> <figureanchor="fig.ccnx.int.newformat" title="Compressionanchor="fig.ccnx.int.newformat"> <name>Compression of CCNx LoWPAN InterestMessage">Message</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ T = Type, L = Length, V = Value Lc = Compressed Length, Vc = Compressed Value : = optional field, | = mandatory field +-----------------------------+ +-------------------------+ | Uncompr. Fixed Header | | Compr. Fixed Header | +-----------------------------+ +-------------------------+ +---------+---------+---------+ +---------+ : ILT T : ILT L : ILT V : : ILT Vc : +---------+---------+---------+ +---------+ : MSGH T : MSGH L : MSGH V : : MSGH Vc : +---------+---------+---------+ +---------+ +---------+---------+ +---------+ | MSGT T | MSGT L | | Name Vc | +---------+---------+---------+ +---------+ | Name T | Name L | Name V | ==> : KIDR Vc : +---------+---------+---------+ +---------+ : KIDR T : KIDR L : KIDR V : : OBHR Vc : +---------+---------+---------+ +---------+---------+ : OBHR T : OBHR L : OBHR V : : PAYL Lc : PAYL V : +---------+---------+---------+ +---------+---------+ : PAYL T : PAYL L : PAYL V : : VALG Lc : VALG Vc : +---------+---------+---------+ +---------+---------+ : VALG T : VALG L : VALG V : : VPAY Lc : VPAY V : +---------+---------+---------+ +---------+---------+ : VPAY T : VPAY L : VPAY V : +---------+---------+---------+ ]]></artwork> </figure> <t>Further TLV compression is indicated by the ICN LoWPAN dispatch in <xreftarget="fig.ccnx.intcompr"/>.</t>target="fig.ccnx.intcompr" format="default"/>.</t> <figureanchor="fig.ccnx.intcompr" title="Dispatch formatanchor="fig.ccnx.intcompr"> <name>Dispatch Format forcompressedCompressed CCNx Interestmessages">Messages</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |10 | 1 | 0|CID|EXT|VER|FLG|PTY|HPL|FRS|PAY|ILT|MGH|KIR|CHR|VAL|| 1 |FLG|PTY|HPL|FRS|PAY|ILT|MGH|KIR|CHR|VAL|CID|EXT| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ ]]></artwork> </figure><t><list hangIndent="4" style="hanging"> <t hangText="CID: Context Identifier">See <xref target="fig.disp.base.compr"/>.</t> <t hangText="EXT: Extension"><list hangIndent="8" style="hanging"> <t hangText="0:">No extension byte follows.</t> <t hangText="1:">Extension byte <spanx style="verb">EXT_0</spanx> follows immediately. See <xref target="sec.ccnx.interest.ext0"/>.</t> </list></t> <t hangText="VER: CCNx protocol version in the fixed header"><list hangIndent="8" style="hanging"> <t hangText="0:">The Version field equals 1 and is removed from the fixed header.</t> <t hangText="1:">The Version field appears in the fixed header.</t> </list></t> <t hangText="FLG:<dl newline="true" spacing="normal" indent="4"> <dt>FLG: Flags field in the fixedheader"><list hangIndent="8" style="hanging"> <t hangText="0:">Theheader</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>The Flags field equals 0 and is removed from the Interestmessage.</t> <t hangText="1:">Themessage.</dd> <dt>1:</dt> <dd>The Flags field appears in the fixedheader.</t> </list></t> <t hangText="PTY:header.</dd> </dl> </dd> <dt>PTY: PacketType field in the fixedheader"><list hangIndent="8" style="hanging"> <t hangText="0:">Theheader</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>The PacketType field is elided and assumed to be<spanx style="verb">PT_INTEREST</spanx>.</t> <t hangText="1:">The<tt>PT_INTEREST</tt>.</dd> <dt>1:</dt> <dd>The PacketType field is elided and assumed to be<spanx style="verb">PT_RETURN</spanx>.</t> </list></t> <t hangText="HPL:<tt>PT_RETURN</tt>.</dd> </dl> </dd> <dt>HPL: HopLimit field in the fixedheader"><list hangIndent="8" style="hanging"> <t hangText="0:">Theheader</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>The HopLimit field appears in the fixedheader.</t> <t hangText="1:">Theheader.</dd> <dt>1:</dt> <dd>The HopLimit field is elided and assumed to be<spanx style="verb">1</spanx>.</t> </list></t> <t hangText="FRS:<tt>1</tt>.</dd> </dl> </dd> <dt>FRS: Reserved field in the fixedheader"><list hangIndent="8" style="hanging"> <t hangText="0:">Theheader</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>The Reserved field appears in the fixedheader.</t> <t hangText="1:">Theheader.</dd> <dt>1:</dt> <dd>The Reserved field is elided and assumed to be<spanx style="verb">0</spanx>.</t> </list></t> <t hangText="PAY:<tt>0</tt>.</dd> </dl> </dd> <dt>PAY: Optional PayloadTLV"><list hangIndent="8" style="hanging"> <t hangText="0:">TheTLV</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>The Payload TLV isabsent.</t> <t hangText="1:">Theabsent.</dd> <dt>1:</dt> <dd>The Payload TLV ispresentpresent, and thetypeType field iselided.</t> </list></t> <t hangText="ILT:elided.</dd> </dl> </dd> <dt>ILT: OptionalHop-By-Hophop-by-hop InterestLifetimeTLV"><list hangIndent="8" style="hanging">TLV</dt> <dd> <t>See <xreftarget="sec.ccnxhbhint"/>target="sec.ccnxhbhint" format="default"/> for further details on the ordering of hop-by-hop TLVs.</t><t hangText="0:">No<dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>No InterestLifetime TLV is present in the Interestmessage.</t> <t hangText="1:">Anmessage.</dd> <dt>1:</dt> <dd>An InterestLifetime TLV is present with a fixed length of 1 byte and is encoded as described in <xreftarget="sec.compressedtime"/>.target="sec.compressedtime" format="default"/>. ThetypeType andlengthLength fields areelided.</t> </list></t> <t hangText="MGH:elided.</dd> </dl> </dd> <dt>MGH: OptionalHop-By-Hophop-by-hop MessageHashTLV"><list hangIndent="8" style="hanging">TLV</dt> <dd> <t>See <xreftarget="sec.ccnxhbhint"/>target="sec.ccnxhbhint" format="default"/> for further details on the ordering of hop-by-hop TLVs.</t> <t>This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the InterestMUST<bcp14>MUST</bcp14> be sent uncompressed.</t><t hangText="0:">The<dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>The MessageHash TLV isabsent.</t> <t hangText="1:">Aabsent.</dd> <dt>1:</dt> <dd>A T_SHA-256 TLV ispresentpresent, and thetype as well as the lengthType and Length fields are removed. ThelengthLength field is assumed to represent 32 bytes. The outer Message Hash TLV isomitted.</t> </list></t> <t hangText="KIR:omitted.</dd> </dl> </dd> <dt>KIR: Optional KeyIdRestrictionTLV"><list hangIndent="8" style="hanging">TLV</dt> <dd> <t>This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the InterestMUST<bcp14>MUST</bcp14> be sent uncompressed.</t><t hangText="0:">The<dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>The KeyIdRestriction TLV isabsent.</t> <t hangText="1:">Aabsent.</dd> <dt>1:</dt> <dd>A T_SHA-256 TLV ispresentpresent, and thetype as well as the lengthType and Length fields are removed. ThelengthLength field is assumed to represent 32 bytes. The outer KeyIdRestriction TLV isomitted.</t> </list></t> <t hangText="CHR:omitted.</dd> </dl> </dd> <dt>CHR: Optional ContentObjectHashRestrictionTLV"><list hangIndent="8" style="hanging">TLV</dt> <dd> <t>This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the InterestMUST<bcp14>MUST</bcp14> be sent uncompressed.</t><t hangText="0:">The<dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>The ContentObjectHashRestriction TLV isabsent.</t> <t hangText="1:">Aabsent.</dd> <dt>1:</dt> <dd>A T_SHA-256 TLV ispresentpresent, and thetype as well as the lengthType and Length fields are removed. ThelengthLength field is assumed to represent 32 bytes. The outer ContentObjectHashRestriction TLV isomitted.</t> </list></t> <t hangText="VAL:omitted.</dd> </dl> </dd> <dt>VAL: Optional ValidationAlgorithm and ValidationPayloadTLVs"><list hangIndent="8" style="hanging"> <t hangText="0:">No validation relatedTLVs</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>No validation-related TLVs are present in the Interestmessage.</t> <t hangText="1:">Validation relatedmessage.</dd> <dt>1:</dt> <dd>Validation-related TLVs are present in the Interest message. An additional byte follows immediately that handlesvalidation relatedvalidation-related TLV compressions and is described in <xreftarget="sec.ccnx.intval"/>.</t> </list></t> </list></t>target="sec.ccnx.intval" format="default"/>.</dd> </dl> </dd> <dt>CID: Context Identifier</dt> <dd><t>See <xref target="fig.disp.base.compr" format="default"/>.</t></dd> <dt>EXT: Extension</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>No extension byte follows.</dd> <dt>1:</dt> <dd>Extension byte <tt>EXT_0</tt> follows immediately. See <xref target="sec.ccnx.interest.ext0" format="default"/>.</dd> </dl> </dd> </dl> <section anchor="sec.ccnxhbhint"title="Hop-By-Hoptoc="exclude" numbered="true"> <name>Hop-By-Hop Header TLVsCompression" toc="exclude"> <t>Hop-By-Hop HeaderCompression</name> <t>Hop-by-hop header TLVs are unordered. For an Interest message, two optionalHop-By-Hop Headerhop-by-hop header TLVs are defined in <xreftarget="RFC8609"/>,target="RFC8609" format="default"/>, but several more can be defined inhigher levelhigher-level specifications. For the compression specified in the previous section, theHop-By-Hophop-by-hop TLVs are ordered as follows:<list style="numbers"> <t>Interest Lifetime TLV</t> <t>Message</t> <ol spacing="normal" type="1"> <li>InterestLifetime TLV</li> <li>Message HashTLV</t> </list></t> <t>Note:TLV</li> </ol> <!-- [rfced] Does listing the TLVs improve the readability of the sentence? Should the following TLVs be in 'camel case'? "Message Hash" and "Recommended Cache Time" Current (Sections 6.3.2.1 and 6.4.2.1): Note: OtherHop-By-Hop Headerhop-by-hop header TLVs than those two remain uncompressed in the encoded message, and they appear in the same order as in the original message but after the InterestLifetime TLV and Message Hash TLV. ... Note: Other hop-by-hop header TLVs than those two remain uncompressed in the encoded message, and they appear in the same order as in the original message but after the Recommended Cache Time TLV and Message Hash TLV. Perhaps: Note: All hop-by-hop header TLVs other than the InterestLifetime and MessageHash TLVs remain uncompressed in the encoded message, and they appear after the InterestLifetime and MessageHash TLVs in the same order as in the original message. ... Note: All hop-by-hop header TLVs other than the RecommendedCacheTime and MessageHash TLVs remain uncompressed in the encoded message, and they appear after the RecommendedCacheTime and MessageHash TLVs in the same order as in the original message. --> <t>Note: Other hop-by-hop header TLVs than those two remain uncompressed in the encoded message, and they appear in the same order as in the original message but after theInterest LifetimeInterestLifetime TLV and Message Hash TLV.</t> </section> <section anchor="sec.ccnx.intval"title="Validation" toc="exclude">toc="exclude" numbered="true"> <name>Validation</name> <figureanchor="fig.ccnx.dispatchintval" title="Dispatchanchor="fig.ccnx.dispatchintval"> <name>Dispatch forInterset Validations">Interest Validations</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 8 +-------+-------+-------+-------+-------+-------+-------+-------+ | ValidationAlg | KeyID | RSV | +-------+-------+-------+-------+-------+-------+-------+-------+ ]]></artwork> </figure><t><list hangIndent="4" style="hanging"> <t hangText="ValidationALg:<dl newline="true" spacing="normal" indent="4"> <dt>ValidationAlg: Optional ValidationAlgorithmTLV"><list hangIndent="8" style="hanging"> <t hangText="0000:">AnTLV</dt> <dd> <dl newline="false" spacing="normal" indent="8"> <dt>0000:</dt> <dd>An uncompressed ValidationAlgorithm TLV isincluded.</t> <t hangText="0001:">Aincluded.</dd> <dt>0001:</dt> <dd>A T_CRC32C ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV isincluded.</t> <t hangText="0010:">Aincluded.</dd> <dt>0010:</dt> <dd>A T_CRC32C ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV is included. Additionally, a Sigtime TLV is inlined without atypeType and alength field.</t> <t hangText="0011:">ALength field.</dd> <dt>0011:</dt> <dd>A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV isincluded.</t> <t hangText="0100:">Aincluded.</dd> <dt>0100:</dt> <dd>A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV is included. Additionally, a Sigtime TLV is inlined without atypeType and alength field.</t> <t hangText="0101:">Reserved.</t> <t hangText="0110:">Reserved.</t> <t hangText="0111:">Reserved.</t> <t hangText="1000:">Reserved.</t> <t hangText="1001:">Reserved.</t> <t hangText="1010:">Reserved.</t> <t hangText="1011:">Reserved.</t> <t hangText="1100:">Reserved.</t> <t hangText="1101:">Reserved.</t> <t hangText="1110:">Reserved.</t> <t hangText="1111:">Reserved.</t> </list></t> <t hangText="KeyID:Length field.</dd> <dt>0101:</dt> <dd>Reserved.</dd> <dt>0110:</dt> <dd>Reserved.</dd> <dt>0111:</dt> <dd>Reserved.</dd> <dt>1000:</dt> <dd>Reserved.</dd> <dt>1001:</dt> <dd>Reserved.</dd> <dt>1010:</dt> <dd>Reserved.</dd> <dt>1011:</dt> <dd>Reserved.</dd> <dt>1100:</dt> <dd>Reserved.</dd> <dt>1101:</dt> <dd>Reserved.</dd> <dt>1110:</dt> <dd>Reserved.</dd> <dt>1111:</dt> <dd>Reserved.</dd> </dl> </dd> <dt>KeyID: Optional KeyID TLV within the ValidationAlgorithmTLV"><list hangIndent="8" style="hanging"> <t hangText="00:">The KeyIdTLV</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>00:</dt> <dd>The KeyID TLV isabsent.</t> <t hangText="01:">The KeyIdabsent.</dd> <dt>01:</dt> <dd>The KeyID TLV is present anduncompressed.</t> <t hangText="10:">Auncompressed.</dd> <dt>10:</dt> <dd>A T_SHA-256 TLV ispresentpresent, and thetype field as well as the lengthType and Length fields are removed. ThelengthLength field is assumed to represent 32 bytes. The outerKeyIdKeyID TLV isomitted.</t> <t hangText="11:">Aomitted.</dd> <dt>11:</dt> <dd>A T_SHA-512 TLV ispresentpresent, and thetype field as well as the lengthType and Length fields are removed. ThelengthLength field is assumed to represent 64 bytes. The outerKeyIdKeyID TLV isomitted.</t> </list></t> <t hangText="RSV: Reserved">Mustomitted.</dd> </dl> </dd> <dt>RSV: Reserved</dt> <dd>Must be set to0.</t> </list></t>0.</dd> </dl> <t>The ValidationPayload TLV is present if the ValidationAlgorithm TLV is present. ThetypeType field is omitted.</t> </section> </section> <section anchor="sec.ccnx.interest.ext0"title="Dispatch Extension">numbered="true" toc="default"> <name>Dispatch Extension</name> <t>The<spanx style="verb">EXT_0</spanx><tt>EXT_0</tt> byte follows the description in <xreftarget="sec.dispatch.ext"/>target="sec.dispatch.ext" format="default"/> and is illustrated in <xreftarget="fig.ccnx.interest.ext0"/>.</t>target="fig.ccnx.interest.ext0" format="default"/>.</t> <figureanchor="fig.ccnx.interest.ext0" title="EXT_0 format"> <artwork align="center"><![CDATA[anchor="fig.ccnx.interest.ext0"> <name>EXT_0 Format</name> <artwork align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | NCS | RSV |EXT| +---+---+---+---+---+---+---+---+ ]]></artwork> </figure><t><list hangIndent="4" style="hanging"> <t hangText="NCS:<dl newline="true" spacing="normal" indent="4"> <dt>NCS: Name CompressionStrategy"><list hangIndent="12" style="hanging"> <t hangText="00:">NamesStrategy</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>00:</dt> <dd>Names are compressed with the default name compression strategy (see <xreftarget="sec.ndn.namecompression"/>).</t> <t hangText="01:">Reserved.</t> <t hangText="10:">Reserved.</t> <t hangText="11:">Reserved.</t> </list></t> <t hangText="RSV: Reserved">Musttarget="sec.ndn.namecompression" format="default"/>).</dd> <dt>01:</dt> <dd>Reserved.</dd> <dt>10:</dt> <dd>Reserved.</dd> <dt>11:</dt> <dd>Reserved.</dd> </dl> </dd> <dt>RSV: Reserved</dt> <dd>Must be set to0.</t> <t hangText="EXT: Extension"><list hangIndent="8" style="hanging"> <t hangText="0:">No0.</dd> <dt>EXT: Extension</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>No extension bytefollows.</t> <t hangText="1:">Afollows.</dd> <dt>1:</dt> <dd>A further extension byte followsimmediately.</t> </list></t> </list></t>immediately.</dd> </dl> </dd> </dl> </section> </section> <sectiontitle="Content Objects">numbered="true" toc="default"> <name>Content Objects</name> <sectiontitle="Uncompressednumbered="true" toc="default"> <name>Uncompressed ContentObjects">Objects</name> <t>An uncompressed ContentobjectObject uses the base dispatch format (see <xreftarget="fig.disp.base"/>)target="fig.disp.base" format="default"/>) and sets the C flag to<spanx style="verb">0</spanx>,<tt>0</tt> and the P and M flags to<spanx style="verb">1</spanx><tt>1</tt> (<xreftarget="fig.ccnx.data.uncompr"/>).target="fig.ccnx.data.uncompr" format="default"/>). The ContentobjectObject is handed to the CCNx network stack without modifications.</t> <figureanchor="fig.ccnx.data.uncompr" title="Dispatch formatanchor="fig.ccnx.data.uncompr"> <name>Dispatch Format foruncompressedUncompressed CCNx Contentobjects">Objects</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | +---+---+---+---+---+---+---+---+ ]]></artwork> </figure> </section> <sectiontitle="Compressednumbered="true" toc="default"> <name>Compressed ContentObjects">Objects</name> <t>The compressed ContentobjectObject uses the extended dispatch format (<xreftarget="fig.disp.base.compr"/>)target="fig.disp.base.compr" format="default"/>) and sets the C, P,as well as theand Mflagflags to<spanx style="verb">1</spanx>.<tt>1</tt>. If a ContentobjectObject contains TLVs that are not mentioned in the following compression rules, then this messageMUST<bcp14>MUST</bcp14> be sent uncompressed.</t> <t>By default, the ContentobjectObject is compressed with the following base rule set:<list style="numbers"> <t>The</t> <ol spacing="normal" type="1"> <li>The version is elided from the fixed header and assumed to be 1.</li> <li>The PacketType field is elided from theFixed Header.</t> <t>Thefixed header.</li> <li>The Type and Length fields of the CCNx Message TLV are elided and are obtained from theFixed Headerfixed header ondecompression.</t> </list></t>decompression.</li> </ol> <t>The compressed CCNx LoWPAN Data message is visualized in <xreftarget="fig.ccnx.data.newformat"/>.</t>target="fig.ccnx.data.newformat" format="default"/>.</t> <figureanchor="fig.ccnx.data.newformat" title="Compressionanchor="fig.ccnx.data.newformat"> <name>Compression of CCNx LoWPAN DataMessage">Message</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ T = Type, L = Length, V = Value Lc = Compressed Length, Vc = Compressed Value : = optional field, | = mandatory field +-----------------------------+ +-------------------------+ | Uncompr. Fixed Header | | Compr. Fixed Header | +-----------------------------+ +-------------------------+ +---------+---------+---------+ +---------+ : RCT T : RCT L : RCT V : : RCT Vc : +---------+---------+------.--+ +---------+ : MSGH T : MSGH L : MSGH V : : MSGH Vc : +---------+---------+---------+ +---------+ +---------+---------+ +---------+ | MSGT T | MSGT L | | Name Vc | +---------+---------+---------+ +---------+ | Name T | Name L | Name V | ==> : EXPT Vc : +---------+---------+---------+ +---------+---------+ : PTYP T : PTYP L : PTYP V : : PAYL Lc : PAYL V : +---------+---------+---------+ +---------+---------+ : EXPT T : EXPT L : EXPT V : : VALG Lc : VALG Vc : +---------+---------+---------+ +---------+---------+ : PAYL T : PAYL L : PAYL V : : VPAY Lc : VPAY V : +---------+---------+---------+ +---------+---------+ : VALG T : VALG L : VALG V : +---------+---------+---------+ : VPAY T : VPAY L : VPAY V : +---------+---------+---------+ ]]></artwork> </figure> <t>Further TLV compression is indicated by the ICN LoWPAN dispatch in <xreftarget="fig.ccnx.datacompr"/>.</t>target="fig.ccnx.datacompr" format="default"/>.</t> <figureanchor="fig.ccnx.datacompr" title="Dispatch formatanchor="fig.ccnx.datacompr"> <name>Dispatch Format forcompressedCompressed CCNx Contentobjects">Objects</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 1 | 1 | 1|CID|EXT|VER|FLG|FRS|PAY|RCT|MGH||FLG|FRS|PAY|RCT|MGH| PLTYP|EXP|VAL|RSV||EXP|VAL|RSV|CID|EXT| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ ]]></artwork> </figure><t><list hangIndent="4" style="hanging"> <t hangText="CID: Context Identifier">See <xref target="fig.disp.base.compr"/>.</t> <t hangText="EXT: Extension"><list hangIndent="8" style="hanging"> <t hangText="0:">No extension byte follows.</t> <t hangText="1:">Extension byte <spanx style="verb">EXT_0</spanx> follows immediately. See <xref target="sec.ccnx.data.ext0"/>.</t> </list></t> <t hangText="VER: CCNx protocol version in the fixed header"><list hangIndent="8" style="hanging"> <t hangText="0:">The Version field equals 1 and is removed from the fixed header.</t> <t hangText="1:">The Version field appears in the fixed header.</t> </list></t> <t hangText="FLG:<dl newline="true" spacing="normal" indent="4"> <dt>FLG: Flags field in the fixedheader">Seeheader</dt> <dd>See <xreftarget="sec.ccnxintcompbaseheader"/>.</t> <t hangText="FRS:target="sec.ccnxintcompbaseheader" format="default"/>.</dd> <dt>FRS: Reserved field in the fixedheader">Seeheader</dt> <dd>See <xreftarget="sec.ccnxintcompbaseheader"/>.</t> <t hangText="PAY:target="sec.ccnxintcompbaseheader" format="default"/>.</dd> <dt>PAY: Optional PayloadTLV">SeeTLV</dt> <dd>See <xreftarget="sec.ccnxintcompbaseheader"/>.</t> <t hangText="RCT:target="sec.ccnxintcompbaseheader" format="default"/>.</dd> <dt>RCT: OptionalHop-By-Hop RecommendedCacheTime TLV"><list hangIndent="8" style="hanging"> <t hangText="0:">Thehop-by-hop Recommended Cache Time TLV</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>The Recommended Cache Time TLV isabsent.</t> <t hangText="1:">Theabsent.</dd> <dt>1:</dt> <dd>The Recommended Cache Time TLV ispresentpresent, and thetype as well as the lengthType and Length fields areelided.</t> </list></t> <t hangText="MGH:elided.</dd> </dl> </dd> <dt>MGH: OptionalHop-By-Hophop-by-hop MessageHashTLV"><list hangIndent="8" style="hanging">TLV</dt> <dd> <t>See <xreftarget="sec.ccnxhbhdata"/>target="sec.ccnxhbhdata" format="default"/> for further details on the ordering of hop-by-hop TLVs.</t> <t>This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the Content ObjectMUST<bcp14>MUST</bcp14> be sent uncompressed.</t><t hangText="0:">The<dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>The MessageHash TLV isabsent.</t> <t hangText="1:">Aabsent.</dd> <dt>1:</dt> <dd>A T_SHA-256 TLV ispresentpresent, and thetype as well as the lengthType and Length fields are removed. ThelengthLength field is assumed to represent 32 bytes. The outer Message Hash TLV isomitted.</t> </list></t> <t><list hangIndent="4" style="hanging"> <t hangText="PLTYP:omitted.</dd> </dl> </dd> <dt/> <dd> <dl newline="true" spacing="normal" indent="4"> <dt>PLTYP: Optional PayloadTypeTLV"><list hangIndent="8" style="hanging"> <t hangText="00:">TheTLV</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>00:</dt> <dd>The PayloadType TLV isabsent.</t> <t hangText="01:">Theabsent.</dd> <dt>01:</dt> <dd>The PayloadType TLV isabsentabsent, and T_PAYLOADTYPE_DATA isassumed.</t> <t hangText="10:">Theassumed.</dd> <dt>10:</dt> <dd>The PayloadType TLV isabsentabsent, and T_PAYLOADTYPE_KEY isassumed.</t> <t hangText="11:">Theassumed.</dd> <dt>11:</dt> <dd>The PayloadType TLV is present anduncompressed.</t> </list></t> </list></t> <t hangText="EXP:uncompressed.</dd> </dl> </dd> </dl> </dd> <dt>EXP: Optional ExpiryTimeTLV"><list hangIndent="8" style="hanging"> <t hangText="0:">TheTLV</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>The ExpiryTime TLV isabsent.</t> <t hangText="1:">Theabsent.</dd> <dt>1:</dt> <dd>The ExpiryTime TLV ispresentpresent, and thetype as well as the lengthType and Length fields areelided.</t> </list></t> <t hangText="VAL:elided.</dd> </dl> </dd> <dt>VAL: Optional ValidationAlgorithm and ValidationPayloadTLVs">SeeTLVs</dt> <dd>See <xreftarget="sec.ccnxintcompbaseheader"/>.</t> <t hangText="RSV: Reserved">Musttarget="sec.ccnxintcompbaseheader" format="default"/>.</dd> <dt>RSV: Reserved</dt> <dd>Must be set to0.</t> </list></t>0.</dd> <dt>CID: Context Identifier</dt> <dd>See <xref target="fig.disp.base.compr" format="default"/>.</dd> <dt>EXT: Extension</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>No extension byte follows.</dd> <dt>1:</dt> <dd>Extension byte <tt>EXT_0</tt> follows immediately. See <xref target="sec.ccnx.data.ext0" format="default"/>.</dd> </dl> </dd> </dl> <section anchor="sec.ccnxhbhdata"title="Hop-By-Hoptoc="exclude" numbered="true"> <name>Hop-By-Hop Header TLVsCompression" toc="exclude"> <t>Hop-By-Hop HeaderCompression</name> <t>Hop-by-hop header TLVs are unordered. For a Content Object message, two optionalHop-By-Hop Headerhop-by-hop header TLVs are defined in <xreftarget="RFC8609"/>,target="RFC8609" format="default"/>, but several more can be defined inhigher levelhigher-level specifications. For the compression specified in the previous section, theHop-By-Hophop-by-hop TLVs are ordered as follows:<list style="numbers"> <t>Recommended</t> <ol spacing="normal" type="1"> <li>Recommended Cache TimeTLV</t> <t>MessageTLV</li> <li>Message HashTLV</t> </list></t>TLV</li> </ol> <t>Note: OtherHop-By-Hop Headerhop-by-hop header TLVs than those two remain uncompressed in the encodedmessagemessage, and they appear in the same order as in the originalmessage,message but after the Recommended Cache Time TLV and Message Hash TLV.</t> </section> </section> <section anchor="sec.ccnx.data.ext0"title="Dispatch Extension">numbered="true" toc="default"> <name>Dispatch Extension</name> <t>The<spanx style="verb">EXT_0</spanx><tt>EXT_0</tt> byte follows the description in <xreftarget="sec.dispatch.ext"/>target="sec.dispatch.ext" format="default"/> and is illustrated in <xreftarget="fig.ccnx.data.ext0"/>.</t>target="fig.ccnx.data.ext0" format="default"/>.</t> <figureanchor="fig.ccnx.data.ext0" title="EXT_0 format"> <artwork align="center"><![CDATA[anchor="fig.ccnx.data.ext0"> <name>EXT_0 Format</name> <artwork align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | NCS | RSV |EXT| +---+---+---+---+---+---+---+---+ ]]></artwork> </figure><t><list hangIndent="4" style="hanging"> <t hangText="NCS:<dl newline="true" spacing="normal" indent="4"> <dt>NCS: Name CompressionStrategy"><list hangIndent="12" style="hanging"> <t hangText="00:">NamesStrategy</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>00:</dt> <dd>Names are compressed with the default name compression strategy (see <xreftarget="sec.ndn.namecompression"/>).</t> <t hangText="01:">Reserved.</t> <t hangText="10:">Reserved.</t> <t hangText="11:">Reserved.</t> </list></t> <t hangText="RSV: Reserved">Musttarget="sec.ndn.namecompression" format="default"/>).</dd> <dt>01:</dt> <dd>Reserved.</dd> <dt>10:</dt> <dd>Reserved.</dd> <dt>11:</dt> <dd>Reserved.</dd> </dl> </dd> <dt>RSV: Reserved</dt> <dd>Must be set to0.</t> <t hangText="EXT: Extension"><list hangIndent="8" style="hanging"> <t hangText="0:">No0.</dd> <dt>EXT: Extension</dt> <dd> <dl newline="false" spacing="normal" indent="4"> <dt>0:</dt> <dd>No extension bytefollows.</t> <t hangText="1:">Afollows.</dd> <dt>1:</dt> <dd>A further extension byte followsimmediately.</t> </list></t> </list></t>immediately.</dd> </dl> </dd> </dl> </section> </section> </section> <sectiontitle="Compressedanchor="sec.compressedtime" numbered="true" toc="default"> <name>Compressed TimeEncoding" anchor="sec.compressedtime">Encoding</name> <t> This document adopts the 8-bit compact time representation for relativetime valuestime-values described inSection 5 of<xreftarget="RFC5497"/>target="RFC5497" section="5" sectionFormat="of" format="default"/> with the constant factor<spanx style="verb">C</spanx><tt>C</tt> set to<spanx style="verb">C<tt>C :=1/32</spanx>.1/32</tt>. </t> <t> Valid time offsets in CCNx and NDNreachrange from a few milliseconds (e.g., lifetime of low-latency Interests) to several years (e.g., content freshness periods in caches). Therefore, this document adds two modifications to the compression algorithm. </t> <t> The first modification is the inclusion of a subnormal form <xreftarget="IEEE.754.2019"/>target="IEEE.754.2019" format="default"/> for time-codes with exponent 0 to provide an increased precision and a gradual underflow for the smallest numbers. The formula is changed as follows (a :=mantissa;mantissa, b := exponent):<list style="hanging"> <t hangText="Subnormal</t> <dl newline="false" spacing="normal"> <dt>Subnormal (b ==0):">0):</dt> <dd> (0 + a/8) * 2 * C</t> <t hangText="Normalized</dd> <dt>Normalized (b >0):">0):</dt> <dd> (1 + a/8) *2^b2<sup>b</sup> * C (see <xreftarget="RFC5497"/>) </t> </list> Thistarget="RFC5497" format="default"/>) </dd> </dl> <t>This configuration allows for the followingranges: <list style="symbols"> <t>Minimumranges:</t> <ul spacing="compact"> <li>Minimum subnormal number: 0seconds</t> <t>2ndseconds</li> <li>2nd minimum subnormal number: ~0.007812seconds</t> <t>Maximumseconds</li> <li>Maximum subnormal number: ~0.054688seconds</t> <t>Minimumseconds</li> <li>Minimum normalized number: ~0.062500seconds</t> <t>2ndseconds</li> <li>2nd minimum normalized number: ~0.070312seconds</t> <t>Maximumseconds</li> <li>Maximum normalized number: ~3.99years</t> </list> </t>years</li> </ul> <t> The second modification only applies to uncompressible time offsets that are outside any security envelope. An invalid time-valueMUST<bcp14>MUST</bcp14> be set to the largest valid time-value that is smaller than the invalid input value before compression. </t> </section> <section anchor="stateful.compression"title="Statefulnumbered="true" toc="default"> <name>Stateful HeaderCompression">Compression</name> <t>Stateful header compression in ICN LoWPAN enables packet size reductions in two ways. First, common information that is shared throughout the local LoWPAN may be memorized in the context state at all nodes and omitted from communication. Second, redundancy in a singleInterest-dataInterest-Data exchange may be removed from ICN stateful forwarding on a hop-by-hopbasesbasis and memorized in en-route state tables.</t> <section anchor="stateful.compression.local"title="LoWPAN-local State">numbered="true" toc="default"> <name>LoWPAN-Local State</name> <t>Acontext identifierContext Identifier (CID) is a byte that refers to a particular conceptual context between network devices andMAY<bcp14>MAY</bcp14> be used to replace frequently appearing information, such as name prefixes, suffixes, or meta information, such as Interest lifetime.</t> <figureanchor="fig.cid" title="Context Identifier."> <artwork align="center"><![CDATA[anchor="fig.cid"> <name>Context Identifier</name> <artwork align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | X | ContextID | +---+---+---+---+---+---+---+---+ ]]></artwork> </figure> <t>The 7-bit ContextID is alocally-scopedlocally scoped unique identifier that represents the contextual state shared between the sender and receiver of the corresponding frame (see <xreftarget="fig.cid"/>).target="fig.cid" format="default"/>). Ifsetset, the most significant bit indicates the presence of another, subsequent ContextID byte (see <xreftarget="fig.cid.chain"/>).</t> <t>Contexttarget="fig.cid.chain" format="default"/>).</t> <t>The context state shared between senders and receivers is removed from the compressed packet prior tosending,sending and reinserted after reception 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. The initial distribution and maintenance of shared context is out of scope of this document. Frames containing unknown or invalid CIDsMUST<bcp14>MUST</bcp14> be silently discarded.</t> </section> <section anchor="stateful.compression.en-route"title="En-route State">numbered="true" toc="default"> <name>En-Route State</name> <t>In CCNx and NDN, Name TLVs are included in Interest messages, and they return indataData messages. Returning Name TLVs either equal the original NameTLV,TLV ortheycontain the original Name TLV as a prefix. ICN LoWPAN reduces this redundancy in responses by replacing Name TLVs with single bytes that represent link-local HopIDs. HopIDs are carried as Context Identifiers (see <xreftarget="stateful.compression.local"/>)target="stateful.compression.local" format="default"/>) of link-localscopescope, as shown in <xreftarget="fig.hopid"/>.</t>target="fig.hopid" format="default"/>.</t> <figureanchor="fig.hopid" title="Contextanchor="fig.hopid"> <name>Context Identifier asHopID.">HopID</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | X | HopID | +---+---+---+---+---+---+---+---+ ]]></artwork> </figure> <!-- [rfced] In the following sentence, should "replacing the name by" be "replacing the Name TLV with"? Current: An ICN LoWPAN node that forwards without replacing the name by a HopID (without en-route compression) MUST invalidate the HopID by setting all ID bits to zero. Perhaps: An ICN LoWPAN node that forwards without replacing the Name TLV with a HopID (without en-route compression) MUST invalidate the HopID by setting all ID bits to zero. --> <t>A HopID is valid if not all ID bits are set to zero and invalid otherwise. This yields 127 distinct HopIDs. If this range (1...127) is exhausted, the messagesMUST<bcp14>MUST</bcp14> be sent without en-route state compression until new HopIDs are available. An ICN LoWPAN node that forwards without replacing the name by a HopID (without en-route compression)MUST<bcp14>MUST</bcp14> invalidate the HopID by setting allID-bitsID bits to zero.</t> <t>While an Interest is traversing, a forwarder generates an ephemeral HopID that is tied to aPITPending Interest Table (PIT) entry. Each HopIDMUST<bcp14>MUST</bcp14> be unique within 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 (inbound HopIDs) and HIDo (outbound HopIDs).</t> <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 a newly generated local HopID before the Interest is forwarded. This new HopID is stored in the HIDo column of the local PIT (see <xreftarget="fig.enroute-a"/>).target="fig.enroute-a" format="default"/>). </t> <figureanchor="fig.enroute-a" title="Setting compression state en-route (Interest)."> <artwork align="center"><![CDATA[anchor="fig.enroute-a"> <name>Setting Compression State En-Route (Interest)</name> <artwork align="center" name="" type="" alt=""><![CDATA[ PIT of B PIT Extension PIT of C PIT Extension +--------+------++------+------+ +--------+------++------+------+ | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | +========+======++======+======+ +========+======++======+======+ | /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | | +--------+------++------+------+ +--------+------++------+------+ ^ | ^ store | '----------------------, ,---' store | send v | ,---, /p0, h_A ,---, /p0, h_B ,---, | A | ------------------------> | B | ------------------------> | C | '---' '---' '---' ]]></artwork></figure></t></figure> <t>Responses include HopIDs that were obtained from Interests. If the returning Name TLV equals the original Name TLV, then the name is entirely elided. Otherwise, only the matching name prefix iselidedelided, and the distinct name suffix is included along with the HopID. When a response is forwarded, the contained HopID is extracted and used to match against the correct PIT entry by performing a lookup on the HIDo column. The HopID is then replaced with the corresponding HopID from the HIDi column prior to forwarding the response (<xreftarget="fig.enroute-b"/>).target="fig.enroute-b" format="default"/>). </t> <figureanchor="fig.enroute-b" title="Elidinganchor="fig.enroute-b"> <name>Eliding Name TLVsusing en-route state (data)."> <artwork align="center"><![CDATA[Using En-Route State (Data)</name> <artwork align="center" name="" type="" alt=""><![CDATA[ PIT of B PIT Extension PIT of C PIT Extension +--------+------++------+------+ +--------+------++------+------+ | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | +========+======++======+======+ +========+======++======+======+ | /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | | +--------+------++------+------+ +--------+------++------+------+ | ^ | send | '----------------------, ,---' send v match | v ,---, h_A ,---, h_B ,---, | A | <------------------------ | B | <------------------------ | C | '---' '---' '---' ]]></artwork></figure></t></figure> <t>It should be noted that each forwarder of an Interest in an ICN LoWPAN network can individually decide whether to participate in en-route compression or not. However, an ICN LoWPAN nodeSHOULD<bcp14>SHOULD</bcp14> use en-route compression whenever the stateful compression mechanism is activated.</t> <t>Note also that the extensions of the PIT data structure are required only at ICN LoWPAN nodes, while regular NDN/CCNx forwarders outside of an ICN LoWPAN domain do not need to implement these extensions.</t> </section> <sectiontitle="Integratingnumbered="true" toc="default"> <name>Integrating Stateful HeaderCompression">Compression</name> <t>A CID appears whenever the CID flag is set (see <xreftarget="fig.disp.base.compr"/>).target="fig.disp.base.compr" format="default"/>). The CID is appended to the last ICN LoWPAN dispatchbytebyte, as shown in <xreftarget="fig.cid.loc"/>.</t>target="fig.cid.loc" format="default"/>.</t> <figureanchor="fig.cid.loc" title="LoWPANanchor="fig.cid.loc"> <name>LoWPAN Encapsulation with ICN LoWPAN andCIDs">CIDs</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ ...-------+--------+-------...-------+--...-+-------... / ... | Page | ICN LoWPAN Disp.| CIDs | Payload / ...-------+--------+-------...-------+--...-+-------... ]]></artwork> </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 indicating the presence of a subsequent CID (<xreftarget="fig.cid.chain"/>).target="fig.cid.chain" format="default"/>). This allows to use multiple shared contexts in compressed messages.</t> <t>The HopID is always included as the very first CID.</t> <figureanchor="fig.cid.chain" title="Chaininganchor="fig.cid.chain"> <name>Chaining ofcontext identifiers.">Context Identifiers</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |1| CID / HopID | --> |1| CID | --> |0| CID | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ ]]></artwork> </figure><t/></section> </section> <section anchor="sec.ndn.constvars"title="ICNnumbered="true" toc="default"> <name>ICN LoWPAN Constants andVariables">Variables</name> <t>This is a summary of all ICN LoWPAN constants and variables.<list hangIndent="8" style="hanging"> <t hangText="DEFAULT_NDN_HOPLIMIT:">255</t> </list></t></t> <dl newline="false" spacing="normal" indent="8"> <dt>DEFAULT_NDN_HOPLIMIT:</dt> <dd>255</dd> </dl> </section> <section anchor="implementationnotice"title="Implementationnumbered="true" toc="default"> <name>Implementation Report andGuidance">Guidance</name> <!-- [rfced] RFC 7942 recommends deleting the implementation status section before publishing as an RFC. Please let us know if any changes to Section 10 "Implementation Report and Guidance" are necessary. --> <t>The ICN LoWPAN scheme defined in this document has been implemented as an extension of the NDN/CCNx software stack <xreftarget="CCN-LITE"/>target="CCN-LITE" format="default"/> in its IoT version on RIOT <xreftarget="RIOT"/>.target="RIOT" format="default"/>. An experimental evaluation for NDN over ICNLOWPANLoWPAN with varying configurations has been performed in <xreftarget="ICNLOWPAN"/>.target="ICNLOWPAN" format="default"/>. Energyprofilingsprofiling and processing time measurements indicate significant energy savings,whileand the amortized costs for processing show no penalties.</t> <sectiontitle="Preferred Configuration">numbered="true" toc="default"> <name>Preferred Configuration</name> <t>The header compression performance depends on certain aspects and configurations. It works best for the following cases:<list style="symbols"> <t>Signed</t> <ul spacing="normal"> <li>Signed time offsetscompress ascompress, per <xreftarget="sec.compressedtime"/>target="sec.compressedtime" format="default"/>, without the need forrounding.</t> <t>Contextualrounding.</li> <li>The contextual state (e.g., prefixes) isdistributed,distributed such that long names can be elided from Interest anddata messages.</t> <t>FrequentlyData messages.</li> <li>Frequently used TLV type numbers for CCNx and NDN stay in the lower range (<255).</t> </list>255).</li> </ul> <t> Name components are ofGenericNameComponenttype GenericNameComponent and are limited to a length of 15 bytes to enable compression for all messages.</t> </section> <sectiontitle="Furthernumbered="true" toc="default"> <name>Further ExperimentalDeployments">Deployments</name> <t>An investigation of ICN LoWPAN in large-scale deployments with varying traffic patterns using larger samples of the different board types available remains as future work. This document will be revised to progress it to the Standards Track, once sufficient operational experience has been acquired. Experience reports are encouraged, particularly in the following areas:<list style="symbols"> <t>The</t> <ul spacing="normal"> <li>The name compression scheme (<xreftarget="sec.ndn.namecompression"/>)target="sec.ndn.namecompression" format="default"/>) is optimized for short name components ofGenericNameComponent type.type GenericNameComponent. An empirical study on name lengths in different deployments of selected use cases, such as smart home, smart city, and industrial IoT can provide meaningful reports on necessary name component types and lengths. A conclusive outcome helps to understand whether and how extension mechanisms are needed (<xreftarget="sec.ndn.interest.ext0"/>).target="sec.ndn.interest.ext0" format="default"/>). As a preliminary analysis, <xreftarget="ICNLOWPAN"/>target="ICNLOWPAN" format="default"/> investigates the effectiveness of the proposed compression scheme with URLs obtained from the WWW. Studies onCoAP <xref target="RFC7252"/>deployments of Constrained Application Protocol (CoAP) <xref target="RFC7252" format="default"/> can offer additional insights on naming schemes in theIoT.</t> <t>TheIoT.</li> <li>The fragmentation scheme (<xreftarget="sec.Fragmentation"/>)target="sec.Fragmentation" format="default"/>) inherited from 6LoWPAN allows for a transparent, hop-wise reassembly of CCNx or NDN packets. Fragment forwarding <xreftarget="RFC8930"/>target="RFC8930" format="default"/> with selective fragment recovery <xreftarget="RFC8931"/>target="RFC8931" format="default"/> can improve the end-to-end latency andreliability,reliability while it reduces buffer requirements on forwarders. Initial evaluations(<xref target="SFR-ICNLOWPAN"/>)<xref target="SFR-ICNLOWPAN" format="default"/> show that a naive integration of these upcoming fragmentation features into ICN LoWPAN renders the hop-wise content replication inoperative, since Interest anddataData messages are reassembled end-to-end. More deployment experiences are necessary to gauge the feasibility of different fragmentation schemes in ICN LoWPAN.</t> <t>Context</li> <li>The context state (<xreftarget="stateful.compression.local"/>)target="stateful.compression.local" format="default"/>) holds information that is shared between a set of devices in a LoWPAN. Fixed name prefixes and suffixes are good candidates to be distributed to all nodes in order to elide them from request and response messages. More experience and a deeper inspection of currently available and upcoming protocol features is necessary to identify other protocolfields.</t> <t>Thefields.</li> <li>The distribution and synchronization of the contextual state can potentially be adopted fromSection 7.2 of<xreftarget="RFC6775"/>,target="RFC6775" section="7.2" sectionFormat="of" format="default"/> but requires further evaluations. While 6LoWPAN uses the Neighbor Discovery protocol to disseminate state, CCNx and NDN deployments are missing out on a standard mechanism to bootstrap and manageconfigurations.</t> <t>Theconfigurations.</li> <li>The stateful en-route compression (<xreftarget="stateful.compression.en-route"/>)target="stateful.compression.en-route" format="default"/>) supports a limited number of 127 distinct HopIDs that can be simultaneously in use on a single node. Complex deployment scenarios that make use of multiple, concurrent requests can provide a better insight on the number of open requests stored in thePending Interest TablePIT of memory-constrained devices. This number can serve as anupper-boundupper bound and determines whether the HopID length needs to be resized to fit more HopIDstoat the cost of additional headeroverhead.</t> <t>Multipleoverhead.</li> <li>Multiple implementations that generate and deploy the compression options of this memo in different ways will also add to the experience and understanding of the benefits and limitations of the proposed schemes. Different reports can help to illuminateonthe complexity of implementing ICN LoWPAN for constrained devices, as well as on maintaining interoperability with otherimplementations.</t> </list> </t>implementations.</li> </ul> </section> </section> <section anchor="security.considerations"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>Main memory is typically a scarce resource of constrained networked devices.FragmentationFragmentation, as described in thismemomemo, preserves fragments and purges them only after a packet is reassembled, which requires a buffering of all fragments. This scheme is able to handle fragments for distinctive packets simultaneously, which can lead to overflowing packet buffers that cannot hold all necessary fragments for packet reassembly. Implementers are thus urged to make use of appropriate buffer replacement strategies for fragments. Minimal fragment forwarding <xreftarget="RFC8930"/>target="RFC8930" format="default"/> can potentially prevent fragment buffer saturation in forwarders.</t> <t>The stateful header compression generates ephemeral HopIDs for incoming and outgoing Interests and consumes them on returning Data packets. Forged Interests can deplete the number of available HopIDs, thus leading to a denial of compression service for subsequent content requests.</t> <t>To further alleviate the problems caused by forged fragments or Interest initiations, proper protective mechanisms for accessing thelink-layerlink layer should be deployed. IEEE 802.15.4, e.g., provides capabilities to protect frames and restrict them to a point-to-pointlink,link or a group of devices.</t> </section> <section anchor="iana"title="IANA Considerations"> <section title="Reserving Space innumbered="true" toc="default"> <name>IANA Considerations</name> <section numbered="true" toc="default"> <name>Updates to the 6LoWPAN Dispatch Type FieldRegistry">Registry</name> <t>IANA has assigned dispatch valuesoffor ICN LoWPAN in the<spanx style="verb">6LoWPAN Dispatch"Dispatch TypeField</spanx> registryField" subregistry <xreftarget="RFC4944"/><xref target="RFC8025"/> with Page TBD1 for ICN LoWPAN.target="RFC4944" format="default"/> <xreftarget="tab.iana.dispatches"/>target="RFC8025" format="default"/> of the "IPv6 Low Power Personal Area Network Parameters" registry. <xref target="tab.iana.dispatches" format="default"/> represents the updates to the registry.</t><texttable<table anchor="tab.iana.dispatches"title="Dispatch typesalign="center"> <name>Dispatch Types for NDN and CCNx Dispatch Types withpage TBD1."> <ttcolPage 14</name> <thead> <tr> <th align="center">BitPattern</ttcol> <ttcol align="center">Page</ttcol> <ttcolPattern</th> <th align="center">Page</th> <th align="left">HeaderType</ttcol> <c>00 000000</c> <c>TBD1</c> <c>UncompressedType</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="center">00 000000</td> <td align="center">14</td> <td align="left">Uncompressed NDN Interest messages</td> <td align="left">RFC 9139</td> </tr> <tr> <td align="center">00 01xxxx</td> <td align="center">14</td> <td align="left">Compressed NDN Interest messages</td> <td align="left">RFC 9139</td> </tr> <tr> <td align="center">00 100000</td> <td align="center">14</td> <td align="left">Uncompressed NDNInterest messages</c> <c>00 100000</c> <c>TBD1</c> <c>UncompressedData messages</td> <td align="left">RFC 9139</td> </tr> <tr> <td align="center">00 11xxxx</td> <td align="center">14</td> <td align="left">Compressed NDN Datamessages</c> <c>01 000000</c> <c>TBD1</c> <c>Uncompressed CCNx Interest messages</c> <c>01 100000</c> <c>TBD1</c> <c>Uncompressedmessages</td> <td align="left">RFC 9139</td> </tr> <tr> <td align="center">01 000000</td> <td align="center">14</td> <td align="left">Uncompressed CCNx Interest messages</td> <td align="left">RFC 9139</td> </tr> <tr> <td align="center">01 01xxxx</td> <td align="center">14</td> <td align="left">Compressed CCNx Interest messages</td> <td align="left">RFC 9139</td> </tr> <tr> <td align="center">01 100000</td> <td align="center">14</td> <td align="left">Uncompressed CCNx Content Objectmessages</c> <c>10 0xxxxx</c> <c>TBD1</c> <c>Compressed NDN Interest messages</c> <c>10 1xxxxx</c> <c>TBD1</c> <c>Compressed NDN Data messages</c> <c>11 0xxxxx</c> <c>TBD1</c> <c>Compressed CCNx Interest messages</c> <c>11 1xxxxx</c> <c>TBD1</c> <c>Compressedmessages</td> <td align="left">RFC 9139</td> </tr> <tr> <td align="center">01 11xxxx</td> <td align="center">14</td> <td align="left">Compressed CCNx Content Objectmessages</c> </texttable>messages</td> <td align="left">RFC 9139</td> </tr> </tbody> </table> </section> </section> </middle> <back><references title="Normative References"> <?rfc include="reference.RFC.2119"?> <?rfc include="reference.RFC.4944"?> <?rfc include="reference.RFC.5497"?> <?rfc include="reference.RFC.6256"?> <?rfc include="reference.RFC.6282"?> <?rfc include="reference.RFC.6775"?><displayreference target="I-D.irtf-icnrg-flic" to="ICNRG-FLIC"/> <references> <name>References</name> <references> <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.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.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.6282.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml"/> <!-- [rfced] The following reference has be superceded by a 2020 version. Should it be updated to reflect this? Original: [ieee802.15.4] "IEEE Std. 802.15.4-2015", April 2016, <https://standards.ieee.org/findstds/ standard/802.15.4-2015.html>. --> <reference anchor="ieee802.15.4" target="https://standards.ieee.org/findstds/standard/802.15.4-2015.html"> <front> <title>IEEEStd. 802.15.4-2015</title> <author surname="IEEE Computer Society"/> <date month="April" year="2016"/>Standard for Low-Rate Wireless Networks</title> <author><organization>IEEE</organization></author> </front> <seriesInfo name="IEEE Std" value="802.15.4-2015"/> </reference> <reference anchor="IEEE.754.2019" target="https://standards.ieee.org/content/ieee-standards/en/standard/754-2019.html"> <front><title>Standard<title>IEEE Standard for Floating-Point Arithmetic</title><author initials="" fullname="" surname="Institute of Electrical and Electronics Engineers, C/MSC - Microprocessor Standards Committee"/> <date month="June" year="2019"/><author><organization>IEEE</organization></author> </front> <seriesInfo name="IEEE Std" value="754-2019"/> </reference> </references><references title="Informative References"> <?rfc include="reference.RFC.7252"?> <?rfc include="reference.RFC.7476"?> <?rfc include="reference.RFC.7927"?> <?rfc include="reference.RFC.7945"?> <?rfc include="reference.RFC.7228"?><references> <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.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.7945.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml"/> <!--<?rfc include="reference.RFC.7400"?>--><?rfc include="reference.RFC.8025"?> <?rfc include="reference.RFC.8609"?> <?rfc include="reference.RFC.8569"?> <?rfc include="reference.RFC.8930"?> <?rfc include="reference.RFC.8931"?> <?rfc include="reference.I-D.draft-irtf-icnrg-flic-02"?><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.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.8931.xml"/> <!-- [I-D.irtf-icnrg-flic] IESG state Expired, long way used to capture editor info --> <reference anchor="I-D.irtf-icnrg-flic"> <front> <title>File-Like ICN Collections (FLIC)</title> <author initials="C." surname="Tschudin" fullname="Christian Tschudin"> <organization>University of Basel</organization> </author> <author initials="C." surname="Wood" fullname="Christopher A. Wood"> <organization>University of California Irvine</organization> </author> <author initials="M." surname="Mosko" fullname="Marc Mosko"> <organization>PARC, Inc.</organization> </author> <author initials="D." surname="Oran" fullname="David R. Oran" role="editor"> <organization>Network Systems Research & Design</organization> </author> <date month="November" day="4" year="2019"/> </front> <seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-flic-02"/> <format type="TXT" target="https://www.ietf.org/archive/id/draft-irtf-icnrg-flic-02.txt"/> </reference> <!-- [rfced] We are having trouble accessing the URL from the reference below. Please review. [CCN-LITE] "CCN-lite: A lightweight CCNx and NDN implementation", <http://ccn-lite.net/>. --> <reference anchor="CCN-LITE" target="http://ccn-lite.net/"> <front> <title>CCN-lite: A lightweight CCNx and NDN implementation</title> <author/><date/></front> </reference> <reference anchor="RIOT" target="https://doi.org/10.1109/JIOT.2018.2815038"> <front> <title>RIOT:anAn Open Source Operating System forLow-endLow-End Embedded Devices in the IoT</title> <author initials="E." surname="Baccelli"> <organization>INRIA</organization> </author> <author initials="C."surname="Gundogan">surname="Gündoğan"> <organization>HAW Hamburg</organization> </author> <author initials="O." surname="Hahm"> <organization>INRIA and FU Berlin</organization> </author> <author initials="P." surname="Kietzmann"> <organization>HAW Hamburg</organization> </author> <author initials="MS." surname="Lenders"> <organization>FU Berlin</organization> </author> <author initials="H." surname="Petersen"> <organization>FU Berlin</organization> </author> <author initials="K." surname="Schleiser"> <organization>INRIA and FU Berlin</organization> </author> <author initials="TC." surname="Schmidt"> <organization>HAW Hamburg</organization> </author> <author initials="M."surname="Waehlisch">surname="Wählisch"> <organization>FU Berlin</organization> </author> <date month="December" year="2018"/> </front><seriesInfo name="IEEE<refcontent>IEEE Internet of ThingsJournal" value="Vol.Journal Vol. 5, No. 6, p.4428-4440"/>4428-4440</refcontent> </reference> <reference anchor="NDN-EXP1" target="http://dx.doi.org/10.1145/2660129.2660144"> <front> <title>InformationCentric Networkingcentric networking in the IoT:Experimentsexperiments with NDN in theWild</title>wild</title> <author initials="E." surname="Baccelli"> <organization>INRIA</organization> </author> <author initials="C." surname="Mehlis"> <organization>FU Berlin</organization> </author> <author initials="O." surname="Hahm"> <organization>INRIA</organization> </author> <author initials="TC." surname="Schmidt"> <organization>HAW Hamburg</organization> </author> <author initials="M."surname="Waehlisch">surname="Wählisch"> <organization>FU Berlin</organization> </author> <date month="September" year="2014"/> </front><seriesInfo name="Proc.<refcontent>Proc. of 1st ACM Conf. on Information-Centric Networking(ICN-2014)" value="ACM(ICN-2014) ACM DL, pp.77-86"/>77-86</refcontent> </reference> <reference anchor="NDN-EXP2" target="https://doi.org/10.1145/3267955.3267967"> <front> <title>NDN, CoAP, and MQTT:A Comparative Measurement Studya comparative measurement study in the IoT</title> <author initials="C."surname="Gundogan">surname="Gündoğan"> <organization>HAW Hamburg</organization> </author> <author initials="P." surname="Kietzmann"> <organization>HAW Hamburg</organization> </author> <author initials="M." surname="Lenders"> <organization>FU Berlin</organization> </author> <author initials="H." surname="Petersen"> <organization>FU Berlin</organization> </author> <author initials="TC." surname="Schmidt"> <organization>HAW Hamburg</organization> </author> <author initials="M."surname="Waehlisch">surname="Wählisch"> <organization>FU Berlin</organization> </author> <date month="September" year="2018"/> </front><seriesInfo name="Proc.<refcontent>Proc. of 5th ACM Conf. on Information-Centric Networking(ICN-2018)" value="ACM(ICN-2018) ACM DL, pp.159-171"/>159-171</refcontent> </reference> <reference anchor="NDN-MAC" target="https://doi.org/10.1145/3125719.3125737"> <front> <title>TheNeedneed for aNamename to MACAddress Mappingaddress mapping in NDN:Towards Quantifyingtowards quantifying theResource Gain</title>resource gain</title> <author initials="P." surname="Kietzmann"> <organization>HAW Hamburg</organization> </author> <author initials="C."surname="Gundogan">surname="Gündoğan"> <organization>HAW Hamburg</organization> </author> <author initials="TC." surname="Schmidt"> <organization>HAW Hamburg</organization> </author> <author initials="O." surname="Hahm"> <organization>riot-os.org</organization> </author> <author initials="M."surname="Waehlisch">surname="Wählisch"> <organization>FU Berlin</organization> </author> <date month="September" year="2017"/> </front><seriesInfo name="Proc.<refcontent>Proc. of 4th ACM Conf. on Information-Centric Networking(ICN-2017)" value="ACM(ICN-2017) ACM DL, pp.36-42"/>36-42</refcontent> </reference> <reference anchor="SFR-ICNLOWPAN" target="https://doi.org/10.1145/3405656.3418719"> <front> <title>Connecting the Dots: Selective Fragment Recovery in ICNLoWPAN</title> <author initials="M." surname="Lenders"> <organization>FU Berlin</organization> </author> <author initials="C."surname="Gundogan">surname="Gündoğan"> <organization>HAW Hamburg</organization> </author> <author initials="TC." surname="Schmidt"> <organization>HAW Hamburg</organization> </author> <author initials="M."surname="Waehlisch">surname="Wählisch"> <organization>FU Berlin</organization> </author> <date month="September" year="2020"/> </front><seriesInfo name="Proc.<refcontent>Proc. of 7th ACM Conf. on Information-Centric Networking(ICN-2020)" value="ACM(ICN-2020) ACM DL, pp.70-76"/>70-76</refcontent> </reference> <reference anchor="NDN" target="https://doi.org/10.1145/1658939.1658941"> <front> <title>NetworkingNamed Content</title>named content</title> <author initials="V." surname="Jacobson"/> <author initials="D." surname="Smetters"/> <author initials="J." surname="Thornton"/> <author initials="M." surname="Plass"/> <author initials="N." surname="Briggs"/> <author initials="R." surname="Braynard"/> <date month="December" year="2009"/> </front><seriesInfo name="5th<refcontent>5th Int. Conf. on emerging Networking Experiments andTechnologies" value="(ACM CoNEXT)"/>Technologies (ACM CoNEXT)</refcontent> </reference> <reference anchor="NDN-PACKET-SPEC" target="https://named-data.net/doc/NDN-packet-spec/0.3/"> <front> <title>NDN Packet Format Specification</title> <author/><date/></front> </reference> <reference anchor="TLV-ENC-802.15.4" target="https://datatracker.ietf.org/meeting/interim-2015-icnrg-01/materials/slides-interim-2015-icnrg-1-2"> <front> <title>CCN and NDN TLV encodings in 802.15.4 packets</title><author/> <date/><author initials="M." surname="Mosko"/> <author initials="C." surname="Tschudin"/> <date month="January" year="2015"/> </front> </reference> <reference anchor="WIRE-FORMAT-CONSID" target="https://datatracker.ietf.org/meeting/interim-2015-icnrg-01/materials/slides-interim-2015-icnrg-1-8"> <front> <title>CCN/NDN Protocol Wire Format and Functionality Considerations</title><author/> <date/><author initials="G." surname="Wang"/> <author initials="C." surname="Tschudin"/> <author initials="R." surname="Ravindran"/> <date month="January" year="2015"/> </front> </reference> <reference anchor="ICNLOWPAN" target="https://doi.org/10.23919/IFIPNetworking.2019.8816850"> <front> <title>ICNLoWPAN--- Named-Data Networking in Low Power IoT Networks</title> <author initials="C."surname="Gundogan">surname="Gündogan"> <organization>HAW Hamburg</organization> </author> <author initials="P." surname="Kietzmann"> <organization>HAW Hamburg</organization> </author> <author initials="TC." surname="Schmidt"> <organization>HAW Hamburg</organization> </author> <author initials="M."surname="Waehlisch">surname="Wählisch"> <organization>FU Berlin</organization> </author> <date month="May" year="2019"/> </front><seriesInfo name="Proc.<refcontent>Proc. of18th" value="IFIP18th IFIP NetworkingConference"/>Conference</refcontent> </reference> </references> </references> <section anchor="sec.EstimatedSizeReduction"title="Estimatednumbered="true" toc="default"> <name>Estimated SizeReduction">Reduction</name> <t>In thefollowingfollowing, a theoretical evaluation is given to estimate the gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages.</t> <t>We assume that<spanx style="verb">n</spanx><tt>n</tt> is the number of namecomponents, <spanx style="verb">comps_n</spanx>components; <tt>comps_n</tt> denotes the sum of n 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<spanx style="verb">clen</spanx>.<tt>clen</tt>. The lengths of TLV componentsisare specific to the CCNx or NDN encoding and are outlined below.</t> <sectiontitle="NDN">numbered="true" toc="default"> <name>NDN</name> <t>The NDN TLV encoding has variable-sized TLV fields. For simplicity, the1 byte1-byte form of each TLV component is assumed. A typical TLV component therefore is of size 2(type(Type field +lengthLength field) + the actual value.</t> <sectiontitle="Interest">numbered="true" toc="default"> <name>Interest</name> <t><xreftarget="fig.Size.NDN.interest.uncompressed"/>target="fig.Size.NDN.interest.uncompressed" format="default"/> depicts the size requirements for a basic, uncompressed NDN Interest containing a CanBePrefix TLV, a MustBeFresh TLV,aan InterestLifetime TLV set to 4secondsseconds, and a HopLimit TLV set to 6. Numbers below represent the amount of bytes.</t> <figureanchor="fig.Size.NDN.interest.uncompressed" title="Estimated sizeanchor="fig.Size.NDN.interest.uncompressed"> <name>Estimated Size of anuncompressedUncompressed NDNInterest">Interest</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ ------------------------------------, Interest TLV = 2 | ---------------------, | Name | 2 + | NameComponents = 2n + | | comps_n | ---------------------' = 21 + 2n + comps_n CanBePrefix = 2 | MustBeFresh = 2 | Nonce = 6 | InterestLifetime = 4 | HopLimit = 3 | ------------------------------------' ]]></artwork> </figure> <t><xreftarget="fig.Size.NDN.interest.compressed"/>target="fig.Size.NDN.interest.compressed" format="default"/> depicts the size requirements after compression.</t> <figureanchor="fig.Size.NDN.interest.compressed" title="Estimated sizeanchor="fig.Size.NDN.interest.compressed"> <name>Estimated Size of acompressedCompressed NDNInterest">Interest</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ ------------------------------------, Dispatch Page Switch = 1 | NDNIntersetInterest Dispatch = 2 | Interest TLV = 1 | -----------------------, | Name | | NameComponents = n/2 + = 10 + n/2 + comps_n | comps_n | -----------------------' | Nonce = 4 | HopLimit = 1 | InterestLifetime = 1 | ------------------------------------' ]]></artwork> </figure> <t>The size differenceis: <vspace/>is 11 + 1.5n bytes.</t> <t>For the name<spanx style="verb">/DE/HH/HAW/BT7</spanx>,<tt>/DE/HH/HAW/BT7</tt>, the total size gain is 17 bytes, which is 43% of the uncompressed packet.</t> </section> <sectiontitle="Data">numbered="true" toc="default"> <name>Data</name> <t><xreftarget="fig.Size.NDN.Data.uncompressed"/>target="fig.Size.NDN.Data.uncompressed" format="default"/> depicts the size requirements for a basic, uncompressed NDN Data containing a FreshnessPeriod as MetaInfo. A FreshnessPeriod of 1 minute isassumedassumed, and the value is encoded using 1 byte. An HMACWithSha256 is assumed as a signature. The key locator is assumed to contain a Name TLV of length klen.</t> <figureanchor="fig.Size.NDN.Data.uncompressed" title="Estimated sizeanchor="fig.Size.NDN.Data.uncompressed"> <name>Estimated Size of anuncompressedUncompressed NDNData">Data</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ ------------------------------------, Data TLV = 2 | ---------------------, | Name | 2 + | NameComponents = 2n + | | comps_n | ---------------------' | ---------------------, | MetaInfo | | FreshnessPeriod = 6 | | = 53 + 2n + comps_n + ---------------------' | clen + klen Content = 2 + clen | ---------------------, | SignatureInfo | | SignatureType | | KeyLocator = 41 + klen | SignatureValue | | DigestSha256 | | ---------------------' | ------------------------------------' ]]></artwork> </figure> <t><xreftarget="fig.Size.NDN.Data.compressed"/>target="fig.Size.NDN.Data.compressed" format="default"/> depicts the size requirements for the compressed version of the above Data packet.</t> <figureanchor="fig.Size.NDN.Data.compressed" title="Estimated sizeanchor="fig.Size.NDN.Data.compressed"> <name>Estimated Size of acompressedCompressed NDNData">Data</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ ------------------------------------, Dispatch Page Switch = 1 | NDN Data Dispatch = 2 | -----------------------, | Name | | NameComponents = n/2 + | | comps_n = 38 + n/2 + comps_n + -----------------------' | clen + klen Content = 1 + clen | KeyLocator = 1 + klen | DigestSha256 = 32 | FreshnessPeriod = 1 | ------------------------------------' ]]></artwork> </figure> <t>The size differenceis: <vspace/>is 15 + 1.5n bytes.</t> <t>For the name<spanx style="verb">/DE/HH/HAW/BT7</spanx>,<tt>/DE/HH/HAW/BT7</tt>, the total size gain is 21 bytes.</t> </section> </section> <sectiontitle="CCNx">numbered="true" toc="default"> <name>CCNx</name> <t>The CCNx TLV encoding defines a 2-byte encoding fortypeType andlengthLength fields, summing up to 4 bytes in total without a value.</t> <sectiontitle="Interest">numbered="true" toc="default"> <name>Interest</name> <t><xreftarget="fig.Size.CCNx.interest.uncompressed"/>target="fig.Size.CCNx.interest.uncompressed" format="default"/> depicts the size requirements for a basic, uncompressed CCNx Interest. NoHop-By-Hophop-by-hop TLVs are included, the protocol version is assumed to be11, and thereservedReserved field is assumed to be 0. A KeyIdRestriction TLV with T_SHA-256 is included to limit the responses to Content Objects containing the specific key.</t> <figureanchor="fig.Size.CCNx.interest.uncompressed" title="Estimated sizeanchor="fig.Size.CCNx.interest.uncompressed"> <name>Estimated Size of anuncompressedUncompressed CCNxInterest">Interest</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ ------------------------------------, Fixed Header = 8 | Message = 4 | ---------------------, | Name | 4 + = 56 + 4n + comps_n NameSegments = 4n + | | comps_n | ---------------------' | KeyIdRestriction = 40 | ------------------------------------' ]]></artwork> </figure> <t><xreftarget="fig.Size.CCNx.interest.compressed"/>target="fig.Size.CCNx.interest.compressed" format="default"/> depicts the size requirements after compression.</t> <figureanchor="fig.Size.CCNx.interest.compressed" title="Estimated sizeanchor="fig.Size.CCNx.interest.compressed"> <name>Estimated Size of acompressedCompressed CCNxInterest">Interest</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ ------------------------------------, Dispatch Page Switch = 1 | CCNx Interest Dispatch = 2 | Fixed Header = 3 | -----------------------, | Name | = 38 + n/2 + comps_n NameSegments = n/2 + | | comps_n | -----------------------' | T_SHA-256 = 32 | ------------------------------------' ]]></artwork> </figure> <t>The size differenceis: <vspace/>is 18 + 3.5n bytes.</t> <t>For the name<spanx style="verb">/DE/HH/HAW/BT7</spanx>,<tt>/DE/HH/HAW/BT7</tt>, the size is reduced by 53 bytes, which is 53% of the uncompressed packet.</t> </section> <sectiontitle="Content Object">numbered="true" toc="default"> <name>Content Object</name> <t><xreftarget="fig.Size.CCNx.Data.uncompressed"/>target="fig.Size.CCNx.Data.uncompressed" format="default"/> depicts the size requirements for a basic, uncompressed CCNx Content Object containing an ExpiryTime Message TLV, an HMAC_SHA-256 signature, the signaturetimetime, and a hash of the shared secret key. In the fixed header, the protocol version is assumed to be 1 and thereservedReserved field is assumed to be 0</t> <figureanchor="fig.Size.CCNx.Data.uncompressed" title="Estimated sizeanchor="fig.Size.CCNx.Data.uncompressed"> <name>Estimated Size of anuncompressedUncompressed CCNx ContentObject">Object</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ ------------------------------------, Fixed Header = 8 | Message = 4 | ---------------------, | Name | 4 + | NameSegments = 4n + | | comps_n | ---------------------' | ExpiryTime = 12 = 124 + 4n + comps_n + clen Payload = 4 + clen | ---------------------, | ValidationAlgorithm | | T_HMAC-256 = 56 |KeyIdKeyID | | SignatureTime | | ---------------------' | ValidationPayload = 36 | ------------------------------------' ]]></artwork> </figure> <t><xreftarget="fig.Size.CCNx.Data.compressed"/>target="fig.Size.CCNx.Data.compressed" format="default"/> depicts the size requirements for a basic, compressed CCNx Data.</t> <figureanchor="fig.Size.CCNx.Data.compressed" title="Estimated sizeanchor="fig.Size.CCNx.Data.compressed"> <name>Estimated Size of acompressedCompressed CCNx DataObject">Object</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ ------------------------------------, Dispatch Page Switch = 1 | CCNx Content Dispatch = 3 | Fixed Header = 2 | -----------------------, | Name | | NameSegments = n/2 + | | comps_n = 89 + n/2 + comps_n + clen -----------------------' | ExpiryTime = 8 | Payload = 1 + clen | T_HMAC-SHA256 = 32 | SignatureTime = 8 | ValidationPayload = 34 | ------------------------------------' ]]></artwork> </figure> <t>The size differenceis: <vspace/>is 35 + 3.5n bytes.</t> <t>For the name<spanx style="verb">/DE/HH/HAW/BT7</spanx>,<tt>/DE/HH/HAW/BT7</tt>, the size is reduced by 70 bytes, which is 40% of the uncompressed packet containing a 4-byte payload.</t> </section> </section> </section> <sectionnumbered="no" title="Acknowledgments">numbered="false" toc="default"> <name>Acknowledgments</name> <t>This work was stimulated by fruitful discussions in the ICNRGresearch groupand the communities of RIOT and CCNlite. We would like to thank all active members for constructive thoughts and feedback. In particular, the authors would like to thank (in alphabetical order)Peter Kietzmann, Dirk Kutscher, Martine Lenders, Colin Perkins, Junxiao Shi.<contact fullname="Peter Kietzmann"/>, <contact fullname="Dirk Kutscher"/>, <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 byDave Oran,<contact fullname="Dave Oran"/>, which is gratefully acknowledged. Larger parts of this work are inspired by <xreftarget="RFC4944"/>target="RFC4944" format="default"/> and <xreftarget="RFC6282"/>.target="RFC6282" format="default"/>. Specialmentioningmention goes toMark Mosko<contact fullname="Mark Mosko"/>, as well asG.Q. Wang and Ravi Ravindran<contact fullname="G.Q. Wang"/> and <contact fullname="Ravi Ravindran"/>, as their previous work in <xreftarget="TLV-ENC-802.15.4"/>target="TLV-ENC-802.15.4" format="default"/> and <xreftarget="WIRE-FORMAT-CONSID"/>target="WIRE-FORMAT-CONSID" format="default"/> provided a good base for our discussions on stateless header compression mechanisms. Many thanks also toCarsten Bormann and Lars Eggert,<contact fullname="Carsten Bormann"/> and <contact fullname="Lars Eggert"/>, who contributed in-depth comments during the IRSG review. This work was supported in part by the German Federal Ministry of Research and Education within the projects I3 and RAPstore.</t> </section> <!--[rfced] Throughout the text, the following terminology appears to be used inconsistently. 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 "traditional" or "native" should be updated for clarity. While the NIST website <https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> indicates that "traditional" is potentially biased, it is also ambiguous. "Tradition" is a subjective term, as it is not the same for everyone. --> </back> </rfc>