<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "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    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc category="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>
    <title abbrev="ICN Adaptation to LoWPANs">ICN LoWPANs">Information-Centric Networking (ICN) Adaptation to LoWPAN Low-Power Wireless Personal Area Networks (ICN LoWPAN)</title> (LoWPANs)</title>
    <seriesInfo name="RFC" value="9139"/>
    <author fullname="Cenk Gundogan" Gündoğan" initials="C." surname="Gundogan"> surname="Gündoğan">
      <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." initials="T." 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>
    <author fullname="Matthias Waehlisch" Wählisch" initials="M." surname="Waehlisch"> surname="Wählisch">
      <organization abbrev="link-lab &amp; FU Berlin">link-lab &amp; 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 abbrev="FHNW">University of Basel">University of
      Basel</organization>
      Applied Sciences and Arts Northwestern Switzerland</organization>
      <address>
        <postal>
          <street>Spiegelgasse 1</street>
          <street>Peter Merian-Str. 86</street>
          <city>Basel</city>

          <code>CH-4051</code>
          <code>4002</code>
          <country>Switzerland</country>
        </postal>

        <email>christopher.scherb@unibas.ch</email>
        <email>christopher.scherb@fhnw.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>

    <keyword>Content-Centric Networking (CCNx)</keyword>
    <keyword>Named Data Networking (NDN)</keyword>
    <keyword>header compression</keyword>
    <keyword>fragmentation</keyword>
    <keyword>6LoWPAN</keyword>
    <keyword>Internet of Things (IoT)</keyword>

    <abstract>
      <t>This document defines a convergence layer for CCNx Content-Centric Networking
      (CCNx) and NDN Named Data Networking (NDN) over IEEE
      802.15.4 LoWPAN 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 by
      6LoWPAN
      IPv6 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 to ICN Information-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 elide state states local to the LoWPAN and replace names in
      data
      Data 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 for Information Centric Networks Information-Centric Networking (ICN), as
      infrastructureless access to content, resilient forwarding, and
      in-network data replication demonstrated demonstrates notable advantages over the
      traditional
      Internet host-to-host approach on the Internet <xref
      target="NDN-EXP1"/>, target="NDN-EXP1"
      format="default"/> <xref target="NDN-EXP2"/>. target="NDN-EXP2" format="default"/>. Recent studies <xref
      target="NDN-MAC"/>
      target="NDN-MAC" format="default"/> have shown that an appropriate mapping to link layer
      link-layer technologies has a large impact on the practical performance of an ICN.
      This will be even more relevant in the context of IoT communication
      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 <xref target="NDN"/> target="NDN"
      format="default"/> and CCNx <xref target="RFC8569"/>, target="RFC8569" format="default"/> <xref target="RFC8609"/>.</t>
      target="RFC8609" format="default"/>.</t>
      <t>The IEEE 802.15.4 <xref target="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
      <xref target="RFC7228"/>), target="RFC7228" format="default"/>), in which devices are typically
      battery-operated
      battery operated and constrained in resources. Characteristics of LLNs
      include an unreliable environment, low bandwidth low-bandwidth transmissions, and
      increased latencies. IEEE 802.15.4 admits a maximum physical layer physical-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, signatures signatures, and content.</t>
      <t>6LoWPAN <xref target="RFC4944"/><xref target="RFC6282">, </xref> target="RFC4944" format="default"/> <xref target="RFC6282"
      format="default"/> is a
      convergence layer that provides frame formats, header compression compression, and
      adaptation layer
      adaptation-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>Prevalent Type-Length-Value (TLV) based packet formats based on Type-Length-Value (TLV), such as in
      CCNx and NDN NDN, are designed to be generic and extensible.  This leads to
      header verbosity verbosity, 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 of CCNx CCNx, as well as NDN NDN, 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 allows to reuse of
      the adaptation layer adaptation-layer fragmentation scheme specified by 6LoWPAN for ICN LoWPAN.</t>
      <t>ICN LoWPAN defines a more space efficient space-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 <xref
      target="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 <xref target="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 some Gateway gateway with the public Internet. In ICN based ICN-based
      IoT networks, non-local nonlocal Interest and Data messages transparently travel
      through the BR up and down between a Gateway gateway and the embedded devices
      situated in the constrained LoWPAN.</t>
      <figure anchor="fig-iot_network" title="IoT anchor="fig-iot_network">
        <name>IoT Stub Network"> Network</name>
<artwork align="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 (see Acknowledgments) 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>
    <section title="Terminology">
      <t>The numbered="true" toc="default">
      <name>Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in RFC 2119 BCP&nbsp;14 <xref
      target="RFC2119"/>. The use of the term, "silently ignore" is not
      defined in RFC 2119. However, the term is used in this document target="RFC2119"/> <xref target="RFC8174"/>
    when, and can
      be similarly construed.</t> only when, they appear in all capitals, as shown here.
        </t>
      <t>This document uses the terminology of <xref target="RFC7476"/>, target="RFC7476" format="default"/>, <xref
      target="RFC7927"/>, target="RFC7927" format="default"/>, and <xref target="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 over
          Low-power
          Low-Power Wireless Personal Area Network</t>

          <t hangText="LLN:">Low-Power Network</dd>
        <dt>LLN:</dt>
        <dd>Low-Power and Lossy Network</t>

          <t hangText="CCNx:">Content-Centric Networking Architecture</t>

          <t hangText="NDN:">Named Network</dd>
        <dt>CCNx:</dt>
        <dd>Content-Centric Networking</dd>
        <dt>NDN:</dt>
        <dd>Named Data Networking Architecture</t>

          <t hangText="byte:">synonym for octet</t>

          <t hangText="nibble:">synonym Networking</dd>
        <dt>byte:</dt>
        <dd>synonym for octet</dd>
        <dt>nibble:</dt>
        <dd>synonym for 4 bits</t>

          <t hangText="time-value:">a bits</dd>
        <dt>time-value:</dt>
        <dd>a time offset measured in seconds</t>

          <t hangText="time-code:">an seconds</dd>
        <dt>time-code:</dt>
        <dd>an 8-bit encoded time-value</t>
        </list></t> time-value</dd>
      </dl>
    </section>
    <section anchor="ICNLoWPAN" title="Overview numbered="true" toc="default">
      <name>Overview of ICN LoWPAN "> LoWPAN</name>
      <section title="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
        <xref target="fig.intro.hbh"/>.</t> target="fig.intro.hbh" format="default"/>.</t>
        <figure anchor="fig.intro.hbh"
                title="ICN anchor="fig.intro.hbh">
          <name>ICN LoWPAN convergence layer Convergence Layer for IEEE 802.15.4"> 802.15.4</name>
<artwork align="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-Layer  Link Layer    | |    | |  Link-Layer  Link Layer  | |     | |    Link-Layer    Link Layer  |
'----------------|-'    '-|--------------|-'     '-|----------------'
                 '--------'              '---------'
]]></artwork>
        </figure>
        <t><xref target="sec.lowpan_adaptation"/> target="sec.lowpan_adaptation" format="default"/> of this document defines the
        convergence layer for IEEE 802.15.4.</t>
      </section>
      <section title="Stateless numbered="true" toc="default">
        <name>Stateless Header Compression"> 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 for link-layers link layers with small MTUs. The
        stateless compression does not require pre-configuration preconfiguration of a global
        state.</t>
        <t>The CCNx and NDN header formats are composed of Type-Length-Value
        (TLV) fields to encode header data. The advantage of TLVs the TLV format is its
        native
        support of variably structured data. The main disadvantage of
        TLVs the
        TLV format 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><xref target="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 the type Type and the length Length fields are removed. The third TLV
        represents a boolean TLV (e.g., the MustBeFresh selector in NDN) for
        which the type, length Type, Length, and the value Value fields are elided.</t>
        <figure anchor="fig.TLV.compressed"
                title="Compression using anchor="fig.TLV.compressed">
          <name>Compression Using a compact bit field - bits encode Compact Bit Field -- Bits Encode the inclusion Inclusion of TLVs.">
	  TLVs</name>
<artwork align="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 |  Bit field Field
  +---+---+---+---+---+---+---+---+
    |       |                   |
 ,--'       '----,              '- Boolean Value
 |               |
+-------+-------+-------+
|  LEN  |  VAL  |  VAL  |
+-------+-------+-------+
'---------------'-------'
  Var-len Value  Fixed-len Value
]]></artwork>
        </figure>
        <t>Stateless TLV compression for NDN is defined in <xref
        target="sec.ndn"/>. target="sec.ndn" format="default"/>. <xref target="sec.ccnx"/> target="sec.ccnx" format="default"/> defines the stateless
        TLV compression for CCNx.</t>
        <t>The extensibility of this compression is described in <xref
        target="sec.dispatch.ext"/> target="sec.dispatch.ext" format="default"/> and allows future documents to update the
        compression rules outlined in this manuscript.</t> document.</t>
      </section>
      <section title="Stateful numbered="true" toc="default">
        <name>Stateful Header Compression"> Compression</name>
        <t>ICN LoWPAN further employs two orthogonal orthogonal, stateful compression
        schemes for packet size reductions reductions, which are defined in <xref
        target="stateful.compression"/>. target="stateful.compression" format="default"/>. These mechanisms rely on shared
        contexts that are either distributed and maintained in the entire
        LoWPAN,
        LoWPAN or are generated on-demand on demand hop-wise on a particular
        Interest-data
        Interest-Data path.</t>
        <t>The shared context identification is defined in <xref
        target="stateful.compression.local"/>. target="stateful.compression.local" format="default"/>. The hop-wise name compression
        "en-route"
        "en route" is specified in <xref
        target="stateful.compression.en-route"/>.</t> target="stateful.compression.en-route" format="default"/>.</t>
      </section>
    </section>
    <section anchor="sec.lowpan_adaptation" title="IEEE numbered="true" toc="default">
      <name>IEEE 802.15.4 Adaptation"> 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 (see Section 5 of <xref target="RFC4944"/>). target="RFC4944" section="5" sectionFormat="of" format="default"/>).
        Multiple LoWPAN encapsulation headers can precede the actual payload payload,
        and each encapsulation header is identified by a dispatch type.</t>
        <t><xref target="RFC8025"/> target="RFC8025" format="default"/> further specifies dispatch pages Pages to
	switch between different contexts. When a LoWPAN parser encounters a <spanx
        style="verb">Page switch</spanx> <tt>Page
	switch</tt> LoWPAN encapsulation header, then all
        following encapsulation headers are interpreted by using a dispatch
        table
        Page, as specified by the <spanx style="verb">Page switch</spanx> <tt>Page switch</tt>
        header. Page Pages 0 and page 1 are reserved for 6LoWPAN. This document uses
        page TBD1 (<spanx style="verb">1111 TBD1 (0xFTBD1)</spanx>)
        Page 14 (<tt>1111 1110 (0xFE)</tt>) for ICN LoWPAN.</t>
        <t>The base dispatch format (<xref target="fig.disp.base"/>) target="fig.disp.base" format="default"/>) is
	used and extended by CCNx and NDN in Sections <xref target="sec.ndn"/> target="sec.ndn" format="counter"/> and
	<xref
        target="sec.ccnx"/>.</t> target="sec.ccnx" format="counter"/>.</t>
        <figure anchor="fig.disp.base"
                title="Base dispatch format anchor="fig.disp.base">
          <name>Base Dispatch Format for ICN LoWPAN"> LoWPAN</name>
<artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
  0   1   2   3   ...
+---+---+-----------
+---+---+---+---+---
| C 0 | 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 is NDN.</t>

                <t hangText="1:">The NDN.</dd>
              <dt>1:</dt>
              <dd>The included protocol is CCNx.</t>
              </list></t>

            <t hangText="M: CCNx.</dd>
            </dl>
          </dd>
          <dt>M: Message Type"><list hangIndent="12"
                style="hanging">
                <t hangText="0:">The Type</dt>
          <dd>
            <dl newline="false" spacing="normal" indent="4">
              <dt>0:</dt>
              <dd>The payload contains an Interest message.</t>

                <t hangText="1:">The message.</dd>
              <dt>1:</dt>
              <dd>The payload contains a Data message.</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 <xref
        target="fig.disp.base.compr"/>.</t> target="fig.disp.base.compr" format="default"/>.</t>
        <figure anchor="fig.disp.base.compr"
                title="Extended dispatch format anchor="fig.disp.base.compr">
          <name>Extended Dispatch Format for compressed Compressed ICN LoWPAN"> LoWPAN</name>
<artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
  0   1   2   3   4      ...
+---+---+---+---+---+--- ...
+---+---+---+---+...+---+---+
| 1 0 | 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: Context Identifier"><list hangIndent="12"
                style="hanging">
                <t hangText="0:">No Identifier</dt>
          <dd>
            <dl newline="false" spacing="normal" indent="4">
              <dt>0:</dt>
              <dd>No context identifiers are present.</t>

                <t hangText="1:">Context present.</dd>
              <dt>1:</dt>
              <dd>Context identifier(s) are present (see <xref
                target="stateful.compression.local"/>).</t>
              </list></t>

            <t hangText="EXT: Extension"><list hangIndent="12" style="hanging">
                <t hangText="0:">No target="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 are present.</t>

                <t hangText="1:">Extension present.</dd>
              <dt>1:</dt>
              <dd>Extension byte(s) are present (see <xref
                target="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 <xref
        target="fig.ICN-LoWPAN.header"/>.</t> target="fig.ICN-LoWPAN.header" format="default"/>.</t>
        <figure anchor="fig.ICN-LoWPAN.header"
                title="LoWPAN anchor="fig.ICN-LoWPAN.header">
          <name>LoWPAN Encapsulation with ICN-LoWPAN"> ICN LoWPAN</name>
<artwork align="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.4 header.</t>

            <t hangText="RFC4944 Disp.:">Optional header.</dd>
          <dt>RFC4944 Disp.:</dt>
          <dd>Optional additional dispatches
            defined in Section 5.1 of <xref target="RFC4944"/></t>

            <t hangText="Page:">Page Switch. TBD1 target="RFC4944" section="5.1" sectionFormat="of" format="default"/>.</dd>
          <dt>Page:</dt>
          <dd><tt>Page switch</tt>. 14 for ICN LoWPAN.</t>

            <t hangText="ICN LoWPAN:">Dispatches LoWPAN.</dd>
          <dt>ICN LoWPAN:</dt>
          <dd>Dispatches as defined in Sections <xref
            target="sec.ndn"/> target="sec.ndn" format="counter"/> and <xref target="sec.ccnx"/>.</t>

            <t hangText="Payload:">The target="sec.ccnx" format="counter"/>.</dd>
          <dt>Payload:</dt>
          <dd>The actual (un-)compressed CCNx or NDN
            message.</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 <xref target="fig.ext.base"/>.</t> target="fig.ext.base" format="default"/>.</t>
          <figure anchor="fig.ext.base"
                  title="Base format anchor="fig.ext.base">
            <name>Base Format for dispatch extensions."> Dispatch Extensions</name>
<artwork align="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 byte follows.</t>

                  <t hangText="1:">A follows.</dd>
                <dt>1:</dt>
                <dd>A further extension byte follows.</t>
                </list></t>
            </list></t> follows.</dd>
              </dl>
            </dd>
          </dl>
          <t>Extension bytes are numbered according to their order. Future
          documents MUST <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 devices SHOULD <bcp14>SHOULD</bcp14> use manifests to encode structured data in a
          well-defined format, as, e.g., as outlined in <xref
          target="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 <xref target="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 <xref target="RFC4944"/>.</t> target="RFC4944" format="default"/>.</t>
        <t>The Fragmentation fragmentation LoWPAN header can encapsulate other dispatch
        headers. The order of dispatch types is defined in Section 5 of <xref
        target="RFC4944"/>. target="RFC4944" section="5" sectionFormat="of" format="default"/>. <xref target="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 <xref
        target="fig.fr_done"/>.</t> target="fig.fr_done" format="default"/>.</t>
        <figure anchor="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>
        <figure anchor="fig.fr_done" title="Reassembled anchor="fig.fr_done">
          <name>Reassembled ICN LoWPAN frame"> Frame</name>
<artwork align="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) <xref
        target="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, 6FF 6LFF integrates into ICN LoWPAN
        as seamless seamlessly as the conventional hop-wise
        fragmentation. Experimental However, experimental evaluations <xref
        target="SFR-ICNLOWPAN"/>, however, target="SFR-ICNLOWPAN"
	format="default"/> suggest that a more refined more-refined
        integration can increase the cache utilization of forwarders
        on a request path.</t>
      </section>
    </section>
    <section anchor="sec.ndn" title="Space-efficient numbered="true" toc="default">
      <name>Space-Efficient Message Encoding for NDN"> 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 <xref target="NDN-PACKET-SPEC"/>. target="NDN-PACKET-SPEC" format="default"/>. Type and length Length
        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 actual type Type or length Length field. If
        the number is greater or equals <spanx style="verb">253</spanx> <tt>253</tt> and
        fits into 2 bytes, then the type Type or length Length 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 the type Type
        or length Length 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, the type Type or length Length 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 encode type Type and
        length
        Length fields using self-delimiting numeric values (SDNVs)
        <xref target="RFC6256"/> target="RFC6256" format="default"/> commonly known from DTN Delay-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="NDN align="center">
          <name>NDN TLV encoding compared Encoding Compared to SDNVs.">
          <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>0xFD SDNVs</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 0x00 0xFD</c>
          <c>0x81 0x7D</c>

          <c>2^14 0xFD</td>
              <td align="left">0x81 0x7D</td>
            </tr>
            <tr>
              <td align="left">2<sup>14</sup> - 1</c>
          <c>0xFD 1</td>
              <td align="left">0xFD 0x3F 0xFF</c>
          <c>0xFF 0x7F</c>

          <c>2^14</c>
          <c>0xFD 0xFF</td>
              <td align="left">0xFF 0x7F</td>
            </tr>
            <tr>
              <td align="left">2<sup>14</sup></td>
              <td align="left">0xFD 0x40 0x00</c>
          <c>0x81 0x00</td>
              <td align="left">0x81 0x80 0x00</c>

          <c>2^16</c>
          <c>0xFE 0x00</td>
            </tr>
            <tr>
              <td align="left">2<sup>16</sup></td>
              <td align="left">0xFE 0x00 0x01 0x00 0x00</c>
          <c>0x84 0x00</td>
              <td align="left">0x84 0x80 0x00</c>

          <c>2^21 0x00</td>
            </tr>
            <tr>
              <td align="left">2<sup>21</sup> - 1</c>
          <c>0xFE 1</td>
              <td align="left">0xFE 0x00 0x1F 0xFF 0xFF</c>
          <c>0xFF 0xFF</td>
              <td align="left">0xFF 0xFF 0x7F</c>

          <c>2^21</c>
          <c>0xFE 0x7F</td>
            </tr>
            <tr>
              <td align="left">2<sup>21</sup></td>
              <td align="left">0xFE 0x00 0x20 0x00 0x00</c>
          <c>0x81 0x00</td>
              <td align="left">0x81 0x80 0x80 0x00</c>

          <c>2^28 0x00</td>
            </tr>
            <tr>
              <td align="left">2<sup>28</sup> - 1</c>
          <c>0xFE 1</td>
              <td align="left">0xFE 0x0F 0xFF 0xFF 0xFF</c>
          <c>0xFF 0xFF</td>
              <td align="left">0xFF 0xFF 0xFF 0x7F</c>

          <c>2^28</c>
          <c>0xFE 0x7F</td>
            </tr>
            <tr>
              <td align="left">2<sup>28</sup></td>
              <td align="left">0xFE 0x1F 0x00 0x00 0x00</c>
          <c>0x81 0x00</td>
              <td align="left">0x81 0x80 0x80 0x80 0x00</c>

          <c>2^32</c>
          <c>0xFF 0x00</td>
            </tr>
            <tr>
              <td align="left">2<sup>32</sup></td>
              <td align="left">0xFF 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00</c>
          <c>0x90 0x00</td>
              <td align="left">0x90 0x80 0x80 0x80 0x00</c>

          <c>2^35 0x00</td>
            </tr>
            <tr>
              <td align="left">2<sup>35</sup> - 1</c>
          <c>0xFF 1</td>
              <td align="left">0xFF 0x00 0x00 0x00 0x07 0xFF 0xFF 0xFF 0xFF</c>
          <c>0xFF 0xFF</td>
              <td align="left">0xFF 0xFF 0xFF 0xFF 0x7F</c>

          <c>2^35</c>
          <c>0xFF 0x7F</td>
            </tr>
            <tr>
              <td align="left">2<sup>35</sup></td>
              <td align="left">0xFF 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00</c>
          <c>0x81 0x00</td>
              <td align="left">0x81 0x80 0x80 0x80 0x80 0x00</c>
        </texttable> 0x00</td>
            </tr>
          </tbody>
        </table>
        <t>
          <xref target="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] (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="Name numbered="true" toc="default">
        <name>Name TLV Compression"> Compression</name>
        <t>This Name TLV compression encodes length Length 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 last length Length field of an encoded NameComponent is either 0x00 for a name with an even number of components, components
        and 0xYF (Y > &gt; 0) if an odd number of components are present.
        This process limits the length of a NameComponent TLV to 15 bytes, bytes but allows for an unlimited number of components.
        An example for this encoding is presented in <xref target="fig.ndnshortnco"/>.</t> target="fig.ndnshortnco" format="default"/>.</t>
        <figure anchor="fig.ndnshortnco"
                title="Name anchor="fig.ndnshortnco">
          <name>Name TLV compression Compression for /HAW/Room/481/Humid/99"> /HAW/Room/481/Humid/99</name>
<artwork align="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>
      <section title="Interest Messages">
        <section title="Uncompressed numbered="true" toc="default">
        <name>Interest Messages</name>
        <section numbered="true" toc="default">
          <name>Uncompressed Interest Messages"> Messages</name>
          <t>An uncompressed Interest message uses the base dispatch format
          (see <xref target="fig.disp.base"/>) target="fig.disp.base" format="default"/>) and sets the C flag to
          <spanx style="verb">0</spanx> C, P, and the P as well as the M
          flag
          flags to <spanx style="verb">0</spanx> <tt>0</tt> (<xref
          target="fig.ndn.int.uncompr"/>). target="fig.ndn.int.uncompr" format="default"/>).
          The Interest message is handed to the NDN network stack without modifications.</t>
          <figure anchor="fig.ndn.int.uncompr"
                  title="Dispatch format anchor="fig.ndn.int.uncompr">
            <name>Dispatch Format for uncompressed Uncompressed NDN Interest messages"> Messages</name>
<artwork align="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>
        <section title="Compressed numbered="true" toc="default">
          <name>Compressed Interest Messages"> Messages</name>
          <t>The compressed Interest message uses the extended dispatch format
          (<xref target="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 P flag to <spanx style="verb">0</spanx> and the M flag flags 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 message MUST <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 is removed.</t>

              <t>The removed.</li>
            <li>The Name TLV is compressed according to <xref
              target="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
            ParametersSha256DigestComponent MAY <bcp14>MAY</bcp14> appear at the end of the
            name. In any other case, the message MUST <bcp14>MUST</bcp14> be sent
              uncompressed.</t>

              <t>The
            uncompressed.</li>
            <li>The Nonce TLV and InterestLifetime TLV are moved to
            the end of the compressed Interest Interest, as illustrated in
            <xref target="fig.ndn.int.newformat"/>. target="fig.ndn.int.newformat" format="default"/>.  The
            InterestLifetime is encoded as described in <xref
              target="sec.compressedtime"/>.
	    target="sec.compressedtime" format="default"/>.  On
            decompression, this encoding may yield an
              Interestlifetime
            InterestLifetime that is smaller than the original
              value.</t>

              <t>The
            value.</li>
            <li>The Type and Length fields of Nonce TLV, HopLimit TLV TLV, and
            InterestLifetime TLV are elided. The Nonce value has a length of
            4 bytes bytes, and the HopLimit value has a length of 1 byte. The
            compressed InterestLifetime (<xref target="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 an InerestLifetime, 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 both TLVs.</t>
            </list></t> TLVs.</li>
          </ol>
          <t>The compressed NDN LoWPAN Interest message is visualized in <xref
          target="fig.ndn.int.newformat"/>.</t> target="fig.ndn.int.newformat" format="default"/>.</t>
          <figure anchor="fig.ndn.int.newformat"
                  title="Compression anchor="fig.ndn.int.newformat">
            <name>Compression of NDN LoWPAN Interest Message"> Message</name>
<artwork align="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 <xref target="fig.ndn.intcompr"/>.</t> target="fig.ndn.intcompr" format="default"/>.</t>
          <figure anchor="fig.ndn.intcompr"
                  title="Dispatch format anchor="fig.ndn.intcompr">
            <name>Dispatch Format for compressed Compressed NDN Interest messages"> Messages</name>
<artwork align="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
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 1 0 | 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: CanBePrefix TLV"><list hangIndent="12"
                  style="hanging">
                  <t hangText="0:">The TLV</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>0:</dt>
                <dd>The uncompressed message does not include a
                  CanBePrefix TLV.</t>

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

              <t hangText="FRE:
                  message.</dd>
              </dl>
            </dd>
            <dt>FRE: MustBeFresh TLV"><list hangIndent="12"
                  style="hanging">
                  <t hangText="0:">The TLV</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>0:</dt>
                <dd>The uncompressed message does not include a
                  MustBeFresh TLV.</t>

                  <t hangText="1:">The TLV.</dd>
                <dt>1:</dt>
                <dd>The uncompressed message does include a
                  MustBeFresh TLV and is removed from the compressed
                  message.</t>
                </list></t>

              <t hangText="FWD:
                  message.</dd>
              </dl>
            </dd>
            <dt>FWD: ForwardingHint TLV"><list hangIndent="12"
                  style="hanging">
                  <t hangText="0:">The TLV</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>0:</dt>
                <dd>The uncompressed message does not include a
                  ForwardingHint TLV.</t>

                  <t hangText="1:">The TLV.</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 <xref
                  target="sec.ndn.namecompression"/>. target="sec.ndn.namecompression" format="default"/>. If any name is not
                  compressible, the message MUST <bcp14>MUST</bcp14> be sent uncompressed.</t>
                </list></t>

              <t hangText="APM: uncompressed.</dd>
              </dl>
            </dd>
            <dt>APM: ApplicationParameters TLV"><list
                  hangIndent="12" style="hanging">
                  <t hangText="0:">The TLV</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>0:</dt>
                <dd>The uncompressed message does not include
                  an ApplicationParameters TLV.</t>

                  <t hangText="1:">The TLV.</dd>
                <dt>1:</dt>
                <dd>The uncompressed message does include an
                  ApplicationParameters TLV. The Type field is removed from
                  the compressed message.</t>
              </list></t>

              <t hangText="DIG: message.</dd>
              </dl>
            </dd>
            <dt>DIG: ImplicitSha256DigestComponent TLV"><list
                  hangIndent="12" style="hanging">
                  <t hangText="0:">The TLV</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>0:</dt>
                <dd>The name does not include an
                  ImplicitSha256DigestComponent as the last TLV.</t>

                  <t hangText="1:">The TLV.</dd>
                <dt>1:</dt>
                <dd>The name does include an
                  ImplicitSha256DigestComponent as the last TLV. The Type and
                  Length fields are omitted.</t>
                </list></t>

              <t hangText="RSV: Reserved">Must omitted.</dd>
              </dl>
            </dd>
            <dt>RSV: Reserved</dt>
            <dd>Must be set to 0.</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 <xref target="sec.dispatch.ext"/> target="sec.dispatch.ext" format="default"/> and is illustrated
          in <xref target="fig.ndn.interest.ext0"/>.</t> target="fig.ndn.interest.ext0" format="default"/>.</t>
          <figure anchor="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 Compression Strategy"><list
                  hangIndent="12" style="hanging">
                  <t hangText="00:">Names Strategy</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>00:</dt>
                <dd>Names are compressed with the default name
                  compression strategy (see <xref
                  target="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">Must target="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 to 0.</t>

              <t hangText="EXT: Extension"><list hangIndent="8"
                  style="hanging">
                  <t hangText="0:">No 0.</dd>
            <dt>EXT: Extension</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>0:</dt>
                <dd>No extension byte follows.</t>

                  <t hangText="1:">A follows.</dd>
                <dt>1:</dt>
                <dd>A further extension byte follows
                  immediately.</t>
                </list></t>
            </list></t>
                  immediately.</dd>
              </dl>
            </dd>
          </dl>
        </section>
      </section>
      <section title="Data Messages"> numbered="true" toc="default">
        <name>Data Messages</name>
        <section title="Uncompressed numbered="true" toc="default">
          <name>Uncompressed Data Messages"> Messages</name>
          <t>An uncompressed Data message uses the base dispatch
          format and sets the C flag to <spanx style="verb">0</spanx>,
          the and P flag flags to <spanx style="verb">0</spanx> <tt>0</tt> and the M flag
          to <spanx style="verb">1</spanx> <tt>1</tt> (<xref
          target="fig.ndn.data.uncompr"/>). target="fig.ndn.data.uncompr" format="default"/>).  The Data message is
          handed to the NDN network stack without modifications.</t>
          <figure anchor="fig.ndn.data.uncompr"
                  title="Dispatch format anchor="fig.ndn.data.uncompr">
            <name>Dispatch Format for uncompressed Uncompressed NDN Data messages"> Messages</name>
<artwork align="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>
        <section title="Compressed numbered="true" toc="default">
          <name>Compressed Data Messages"> Messages</name>
          <t>The compressed Data message uses the extended dispatch
          format (<xref target="fig.disp.base.compr"/>) target="fig.disp.base.compr" format="default"/>) and sets the C
          as well as the
          and 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 message MUST <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 is removed.</t>

              <t>The removed.</li>
            <li>The Name TLV is compressed according to <xref
              target="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 message MUST <bcp14>MUST</bcp14> be
              sent uncompressed.</t>

              <t>The uncompressed.</li>
            <li>The MetaInfo TLV Type and Length fields are elided from the
              compressed Data message.</t>

              <t>The message.</li>
            <li>The FreshnessPeriod TLV MUST <bcp14>MUST</bcp14> be moved to the end of the
              compressed Data message. Type and
              Length fields are elided elided, and the value is encoded as described
              in <xref target="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 message MUST <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
              remaining one byte one-byte length to parse.</t>

              <t>The parse.</li>
            <li>The Type fields of the SignatureInfo TLV, SignatureType TLV TLV,
              and SignatureValue TLV are removed.</t>
            </list></t> removed.</li>
          </ol>
          <t>The compressed NDN LoWPAN Data message is visualized in <xref
          target="fig.ndn.data.newformat"/>.</t> target="fig.ndn.data.newformat" format="default"/>.</t>
          <figure anchor="fig.ndn.data.newformat"
                  title="Compression anchor="fig.ndn.data.newformat">
            <name>Compression of NDN LoWPAN Data Message"> Message</name>
<artwork align="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 CTyp 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 <xref target="fig.ndn.datacompr"/>.</t> target="fig.ndn.datacompr" format="default"/>.</t>
          <figure anchor="fig.ndn.datacompr"
                  title="Dispatch format anchor="fig.ndn.datacompr">
            <name>Dispatch Format for compressed Compressed NDN Data messages"> Messages</name>
<artwork align="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
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 1 0 | 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: FinalBlockId TLV"><list hangIndent="12"
                  style="hanging">
                  <t hangText="0:">The TLV</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>0:</dt>
                <dd>The uncompressed message does not include a
                  FinalBlockId TLV.</t>

                  <t hangText="1:">The TLV.</dd>
                <dt>1:</dt>
                <dd>The uncompressed message does include a
                  FinalBlockId
                  FinalBlockId, and it is encoded according to <xref
                  target="sec.ndn.namecompression"/>.
		  target="sec.ndn.namecompression" format="default"/>. If the FinalBlockId
		  TLV is not compressible, then the message MUST <bcp14>MUST</bcp14> be sent
                  uncompressed.</t>
                </list></t>

              <t hangText="CON:
                  uncompressed.</dd>
              </dl>
            </dd>
            <dt>CON: ContentType TLV"><list hangIndent="12"
                  style="hanging">
                  <t hangText="0:">The TLV</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>0:</dt>
                <dd>The uncompressed message does not include a
                  ContentType TLV.</t>

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

              <t hangText="KLO: message.</dd>
              </dl>
            </dd>
            <dt>KLO: KeyLocator TLV"><list hangIndent="12"
                  style="hanging">
                  <t hangText="0:">If TLV</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 <xref
                  target="sec.ndn.namecompression"/>.
		  target="sec.ndn.namecompression" format="default"/>. If the
		  name is not compressible, then the message MUST
		  <bcp14>MUST</bcp14> be sent
                  uncompressed.</t>

                  <t hangText="1:">If uncompressed.</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 is removed.</t>
                </list></t>

              <t hangText="RSV: Reserved">Must removed.</dd>
              </dl>
            </dd>
            <dt>RSV: Reserved</dt>
            <dd>Must be set to 0.</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 <xref target="sec.dispatch.ext"/> target="sec.dispatch.ext" format="default"/> and is illustrated
          in <xref target="fig.ndn.data.ext0"/>.</t> target="fig.ndn.data.ext0" format="default"/>.</t>
          <figure anchor="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 Compression Strategy"><list
                  hangIndent="12" style="hanging">
                  <t hangText="00:">Names Strategy</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>00:</dt>
                <dd>Names are compressed with the default name
                  compression strategy (see <xref
                  target="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">Must target="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 to 0.</t>

              <t hangText="EXT: Extension"><list hangIndent="8"
                  style="hanging">
                  <t hangText="0:">No 0.</dd>
            <dt>EXT: Extension</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>0:</dt>
                <dd>No extension byte follows.</t>

                  <t hangText="1:">A follows.</dd>
                <dt>1:</dt>
                <dd>A further extension byte follows
                  immediately.</t>
                </list></t>
            </list></t>
                  immediately.</dd>
              </dl>
            </dd>
          </dl>
        </section>
      </section>
    </section>
    <section anchor="sec.ccnx"
             title="Space-efficient numbered="true" toc="default">
      <name>Space-Efficient Message Encoding for CCNx"> CCNx</name>
      <section title="TLV Encoding"> numbered="true" toc="default">
        <name>TLV Encoding</name>
        <t>The generic CCNx TLV encoding is described in <xref
        target="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 more space
        efficient space-efficient
	encoding described in <xref target="sec.tlvencoding"/>.
        Hence target="sec.tlvencoding" format="default"/>.
        Hence, NDN and CCNx use the same compressed format for writing
        TLVs.</t>
      </section>
      <section title="Name numbered="true" toc="default">
        <name>Name TLV Compression"> Compression</name>
        <t>Name TLVs are compressed using the scheme already defined in <xref
        target="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>
      <section title="Interest Messages">
        <section title="Uncompressed numbered="true" toc="default">
        <name>Interest Messages</name>
        <section numbered="true" toc="default">
          <name>Uncompressed Interest Messages"> Messages</name>
          <t>An uncompressed Interest message uses the base dispatch format
          (see <xref target="fig.disp.base"/>) target="fig.disp.base" format="default"/>) and sets the C as well as the and M flag flags to <spanx style="verb">0</spanx>. <tt>0</tt>.
          The P flag is set to <spanx style="verb">1</spanx> <tt>1</tt> (<xref target="fig.ccnx.int.uncompr"/>). target="fig.ccnx.int.uncompr" format="default"/>).
          The Interest message is handed to the CCNx network stack without modifications.</t>
          <figure anchor="fig.ccnx.int.uncompr"
                  title="Dispatch format anchor="fig.ccnx.int.uncompr">
            <name>Dispatch Format for uncompressed Uncompressed CCNx Interest messages"> Messages</name>
<artwork align="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="Compressed numbered="true" toc="default">
          <name>Compressed Interest Messages"> Messages</name>
          <t>The compressed Interest message uses the extended dispatch format
          (<xref target="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 message MUST <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 the Fixed Header fixed header on decompression.</t>
            </list></t> decompression.</li>
          </ol>
          <t>The compressed CCNx LoWPAN Interest message is visualized in
          <xref target="fig.ccnx.int.newformat"/>.</t> target="fig.ccnx.int.newformat" format="default"/>.</t>
          <figure anchor="fig.ccnx.int.newformat"
                  title="Compression anchor="fig.ccnx.int.newformat">
            <name>Compression of CCNx LoWPAN Interest Message"> Message</name>
<artwork align="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 <xref target="fig.ccnx.intcompr"/>.</t> target="fig.ccnx.intcompr" format="default"/>.</t>
          <figure anchor="fig.ccnx.intcompr"
                  title="Dispatch format anchor="fig.ccnx.intcompr">
            <name>Dispatch Format for compressed Compressed CCNx Interest messages"> Messages</name>
<artwork align="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
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 1 0 | 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 fixed header"><list
                  hangIndent="8" style="hanging">
                  <t hangText="0:">The header</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>0:</dt>
                <dd>The Flags field equals 0 and is removed
                  from the Interest message.</t>

                  <t hangText="1:">The message.</dd>
                <dt>1:</dt>
                <dd>The Flags field appears in the fixed header.</t>
                </list></t>

              <t hangText="PTY: header.</dd>
              </dl>
            </dd>
            <dt>PTY: PacketType field in the fixed header"><list
                  hangIndent="8" style="hanging">
                  <t hangText="0:">The header</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 fixed header"><list
                  hangIndent="8" style="hanging">
                  <t hangText="0:">The header</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>0:</dt>
                <dd>The HopLimit field appears in the fixed header.</t>

                  <t hangText="1:">The header.</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 fixed header"><list
                  hangIndent="8" style="hanging">
                  <t hangText="0:">The header</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>0:</dt>
                <dd>The Reserved field appears in the fixed header.</t>

                  <t hangText="1:">The header.</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 Payload TLV"><list hangIndent="8"
                  style="hanging">
                  <t hangText="0:">The TLV</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>0:</dt>
                <dd>The Payload TLV is absent.</t>

                  <t hangText="1:">The absent.</dd>
                <dt>1:</dt>
                <dd>The Payload TLV is present present, and the type Type
                  field is elided.</t>
                </list></t>

              <t
              hangText="ILT: elided.</dd>
              </dl>
            </dd>
            <dt>ILT: Optional Hop-By-Hop hop-by-hop InterestLifetime TLV"><list
                  hangIndent="8" style="hanging"> TLV</dt>
            <dd>
	      <t>See <xref target="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
                  Interest message.</t>

                  <t hangText="1:">An message.</dd>
                <dt>1:</dt>
                <dd>An InterestLifetime TLV is present
                  with a fixed length of 1 byte and is encoded as
                  described in <xref
                  target="sec.compressedtime"/>. target="sec.compressedtime" format="default"/>. The type
		  Type and length Length fields are elided.</t>
                </list></t>

              <t hangText="MGH: elided.</dd>
              </dl>
            </dd>
            <dt>MGH: Optional Hop-By-Hop hop-by-hop MessageHash TLV"><list
                  hangIndent="8" style="hanging"> TLV</dt>
            <dd>
                <t>See <xref target="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 Interest MUST <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 is absent.</t>

                  <t hangText="1:">A absent.</dd>
                <dt>1:</dt>
                <dd>A T_SHA-256 TLV is present present, and the type as
                  well as the length Type and
                  Length fields are removed. The length Length field is
                  assumed to represent 32 bytes. The outer Message Hash TLV
                  is omitted.</t>
                </list></t>

              <t hangText="KIR: omitted.</dd>
              </dl>
            </dd>
            <dt>KIR: Optional KeyIdRestriction TLV"><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 Interest MUST <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 is absent.</t>

                  <t hangText="1:">A absent.</dd>
                <dt>1:</dt>
                <dd>A T_SHA-256 TLV is present present, and the type as
                  well as the length Type and
                  Length fields are removed. The length Length field is
                  assumed to represent 32 bytes. The outer KeyIdRestriction
                  TLV is omitted.</t>
                </list></t>

              <t
              hangText="CHR: omitted.</dd>
              </dl>
            </dd>
            <dt>CHR: Optional ContentObjectHashRestriction TLV"><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 Interest MUST <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 is
                  absent.</t>

                  <t hangText="1:">A
                  absent.</dd>
                <dt>1:</dt>
                <dd>A T_SHA-256 TLV is present present, and the type as
                  well as the length Type and Length fields are
		removed. The length Length field is assumed to represent 32 bytes. The outer
                ContentObjectHashRestriction TLV is omitted.</t>
                </list></t>

              <t
              hangText="VAL: omitted.</dd>
              </dl>
            </dd>
            <dt>VAL: Optional ValidationAlgorithm and ValidationPayload TLVs"><list
                  hangIndent="8" style="hanging">
                  <t hangText="0:">No validation related
	    TLVs</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>0:</dt>
                <dd>No validation-related TLVs are present in
                  the Interest message.</t>

                  <t hangText="1:">Validation related message.</dd>
                <dt>1:</dt>
                <dd>Validation-related TLVs are present in the
                Interest message. An additional byte follows immediately
                that handles validation related validation-related TLV compressions and is
                described in <xref target="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-Hop toc="exclude" numbered="true">
            <name>Hop-By-Hop Header TLVs Compression" toc="exclude">
            <t>Hop-By-Hop Header Compression</name>
            <t>Hop-by-hop header TLVs are unordered. For an Interest message,
            two optional Hop-By-Hop Header hop-by-hop header TLVs are defined in <xref
            target="RFC8609"/>,
	    target="RFC8609"
	    format="default"/>, but several more can be defined in higher
            level higher-level
	    specifications. For the compression specified in the
            previous section, the Hop-By-Hop hop-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 Hash TLV</t>
              </list></t> TLV</li>
            </ol>
            <t>Note: Other Hop-By-Hop Header All hop-by-hop header TLVs other than those two the InterestLifetime and
            MessageHash TLVs remain uncompressed in the encoded message message, and they
            appear after the InterestLifetime and MessageHash TLVs in the same
            order as in the original message, but after the Interest Lifetime TLV and Message Hash TLV.</t> message.</t>
          </section>
          <section anchor="sec.ccnx.intval" title="Validation" toc="exclude"> toc="exclude" numbered="true">
            <name>Validation</name>
            <figure anchor="fig.ccnx.dispatchintval"
                    title="Dispatch anchor="fig.ccnx.dispatchintval">
              <name>Dispatch for Interset Validations"> Interest Validations</name>
<artwork align="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 ValidationAlgorithm TLV"><list
                    hangIndent="8" style="hanging">
                    <t hangText="0000:">An TLV</dt>
              <dd>
                <dl newline="false" spacing="normal" indent="8">
                  <dt>0000:</dt>
                  <dd>An uncompressed ValidationAlgorithm
                    TLV is included.</t>

                    <t hangText="0001:">A included.</dd>
                  <dt>0001:</dt>
                  <dd>A T_CRC32C ValidationAlgorithm TLV is
                    assumed, but no ValidationAlgorithm TLV is included.</t>

                    <t hangText="0010:">A included.</dd>
                  <dt>0010:</dt>
                  <dd>A T_CRC32C ValidationAlgorithm TLV is
                    assumed, but no ValidationAlgorithm TLV is included.
                    Additionally, a Sigtime SignatureTime TLV is inlined without a type Type and
                    a length field.</t>

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

                    <t hangText="0100:">A
                    included.</dd>
                  <dt>0100:</dt>
                  <dd>A T_HMAC-SHA256 ValidationAlgorithm
                    TLV is assumed, but no ValidationAlgorithm TLV is included.
                    Additionally, a Sigtime SignatureTime TLV is inlined without a type Type and
                    a length 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 ValidationAlgorithm TLV"><list
                    hangIndent="8" style="hanging">
                    <t hangText="00:">The KeyId TLV</dt>
              <dd>
                <dl newline="false" spacing="normal" indent="4">
                  <dt>00:</dt>
                  <dd>The KeyID TLV is absent.</t>

                    <t hangText="01:">The KeyId absent.</dd>
                  <dt>01:</dt>
                  <dd>The KeyID TLV is present and
                    uncompressed.</t>

                    <t hangText="10:">A
                    uncompressed.</dd>
                  <dt>10:</dt>
                  <dd>A T_SHA-256 TLV is present present, and the type
                    field as well as the length Type
                    and Length fields are removed. The length Length
                    field is assumed to represent 32 bytes. The outer KeyId KeyID
                    TLV is omitted.</t>

                    <t hangText="11:">A omitted.</dd>
                  <dt>11:</dt>
                  <dd>A T_SHA-512 TLV is present present, and the type
                    field as well as the length Type
                    and Length fields are removed. The length Length
                    field is assumed to represent 64 bytes. The outer KeyId KeyID
                    TLV is omitted.</t>
                </list></t>

                <t hangText="RSV: Reserved">Must omitted.</dd>
                </dl>
              </dd>
              <dt>RSV: Reserved</dt>
              <dd>Must be set to 0.</t>

              </list></t> 0.</dd>
            </dl>
            <t>The ValidationPayload TLV is present if the ValidationAlgorithm
            TLV is present. The type Type 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 <xref target="sec.dispatch.ext"/> target="sec.dispatch.ext" format="default"/> and is illustrated
          in <xref target="fig.ccnx.interest.ext0"/>.</t> target="fig.ccnx.interest.ext0" format="default"/>.</t>
          <figure anchor="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 Compression Strategy"><list
                  hangIndent="12" style="hanging">
                  <t hangText="00:">Names Strategy</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>00:</dt>
                <dd>Names are compressed with the default name
                  compression strategy (see <xref
                  target="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">Must target="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 to 0.</t>

              <t hangText="EXT: Extension"><list hangIndent="8"
                  style="hanging">
                  <t hangText="0:">No 0.</dd>
            <dt>EXT: Extension</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>0:</dt>
                <dd>No extension byte follows.</t>

                  <t hangText="1:">A follows.</dd>
                <dt>1:</dt>
                <dd>A further extension byte follows
                  immediately.</t>
                </list></t>
            </list></t>
                  immediately.</dd>
              </dl>
            </dd>
          </dl>
        </section>
      </section>
      <section title="Content Objects"> numbered="true" toc="default">
        <name>Content Objects</name>
        <section title="Uncompressed numbered="true" toc="default">
          <name>Uncompressed Content Objects"> Objects</name>
          <t>An uncompressed Content object Object uses the base dispatch format (see
          <xref target="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> (<xref target="fig.ccnx.data.uncompr"/>). target="fig.ccnx.data.uncompr" format="default"/>).
          The Content object Object is handed to the CCNx network stack without modifications.</t>
          <figure anchor="fig.ccnx.data.uncompr"
                  title="Dispatch format anchor="fig.ccnx.data.uncompr">
            <name>Dispatch Format for uncompressed Uncompressed CCNx Content objects"> Objects</name>
<artwork align="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>
        <section title="Compressed numbered="true" toc="default">
          <name>Compressed Content Objects"> Objects</name>
          <t>The compressed Content object Object uses the extended dispatch format
          (<xref target="fig.disp.base.compr"/>) target="fig.disp.base.compr" format="default"/>) and sets the C, P, as well as the and M flag
	  flags to <spanx style="verb">1</spanx>. <tt>1</tt>. If a Content object Object contains TLVs that are not mentioned in
	  the following compression
          rules, then this message MUST <bcp14>MUST</bcp14> be sent uncompressed.</t>
          <t>By default, the Content object Object 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 the Fixed Header.</t>

              <t>The fixed header.</li>
            <li>The Type and Length fields of the CCNx Message TLV are elided
              and are obtained from the Fixed Header fixed header on decompression.</t>
            </list></t> decompression.</li>
          </ol>
          <t>The compressed CCNx LoWPAN Data message is visualized in <xref
          target="fig.ccnx.data.newformat"/>.</t> target="fig.ccnx.data.newformat" format="default"/>.</t>
          <figure anchor="fig.ccnx.data.newformat"
                  title="Compression anchor="fig.ccnx.data.newformat">
            <name>Compression of CCNx LoWPAN Data Message"> Message</name>
<artwork align="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 <xref target="fig.ccnx.datacompr"/>.</t> target="fig.ccnx.datacompr" format="default"/>.</t>
          <figure anchor="fig.ccnx.datacompr"
                  title="Dispatch format anchor="fig.ccnx.datacompr">
            <name>Dispatch Format for compressed Compressed CCNx Content objects"> Objects</name>
<artwork align="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 fixed header">See header</dt>
            <dd>See <xref
              target="sec.ccnxintcompbaseheader"/>.</t>

              <t hangText="FRS: target="sec.ccnxintcompbaseheader"
	    format="default"/>.</dd>
            <dt>FRS: Reserved field in the fixed header">See header</dt>
            <dd>See <xref
              target="sec.ccnxintcompbaseheader"/>.</t>

              <t hangText="PAY: target="sec.ccnxintcompbaseheader"
	    format="default"/>.</dd>
            <dt>PAY: Optional Payload TLV">See TLV</dt>
            <dd>See <xref
              target="sec.ccnxintcompbaseheader"/>.</t>

              <t
              hangText="RCT: target="sec.ccnxintcompbaseheader"
	    format="default"/>.</dd>
            <dt>RCT: Optional Hop-By-Hop RecommendedCacheTime TLV"><list
                  hangIndent="8" style="hanging">
                  <t hangText="0:">The hop-by-hop Recommended Cache Time TLV</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>0:</dt>
                <dd>The Recommended Cache Time TLV is
                  absent.</t>

                  <t hangText="1:">The
                  absent.</dd>
                <dt>1:</dt>
                <dd>The Recommended Cache Time TLV is present present,
                  and the type as well as the length Type and Length fields are elided.</t>
                </list></t>

              <t hangText="MGH: elided.</dd>
              </dl>
            </dd>
            <dt>MGH: Optional Hop-By-Hop hop-by-hop MessageHash TLV"><list
                  hangIndent="8" style="hanging"> TLV</dt>
            <dd>
	      <t>See <xref target="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 Object MUST
	      <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 is absent.</t>

                  <t hangText="1:">A absent.</dd>
                <dt>1:</dt>
                <dd>A T_SHA-256 TLV is present present, and the type as
                  well as the length Type and
                  Length fields are removed. The length Length field is
                  assumed to represent 32 bytes. The outer Message Hash TLV
                  is omitted.</t>
                </list></t>

              <t><list hangIndent="4" style="hanging">
                  <t hangText="PLTYP: omitted.</dd>
              </dl>
            </dd>
            <dt>PLTYP: Optional PayloadType TLV"><list
                      hangIndent="8" style="hanging">
                      <t hangText="00:">The TLV</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>00:</dt>
                <dd>The PayloadType TLV is absent.</t>

                      <t hangText="01:">The absent.</dd>
                <dt>01:</dt>
                <dd>The PayloadType TLV is absent absent, and
                  T_PAYLOADTYPE_DATA is assumed.</t>

                      <t hangText="10:">The assumed.</dd>
                <dt>10:</dt>
                <dd>The PayloadType TLV is absent absent, and
                  T_PAYLOADTYPE_KEY is assumed.</t>

                      <t hangText="11:">The assumed.</dd>
                <dt>11:</dt>
                <dd>The PayloadType TLV is present and
                      uncompressed.</t>
                    </list></t>
                </list></t>

              <t hangText="EXP:
                  uncompressed.</dd>
              </dl>
            </dd>
            <dt>EXP: Optional ExpiryTime TLV"><list hangIndent="8"
                  style="hanging">
                  <t hangText="0:">The TLV</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>0:</dt>
                <dd>The ExpiryTime TLV is absent.</t>

                  <t hangText="1:">The absent.</dd>
                <dt>1:</dt>
                <dd>The ExpiryTime TLV is present present, and the type
                  as well as the length Type
                  and Length fields are elided.</t>
                </list></t>

              <t
              hangText="VAL: elided.</dd>
              </dl>
            </dd>
            <dt>VAL: Optional ValidationAlgorithm and ValidationPayload TLVs">See
	    TLVs</dt>
            <dd>See
              <xref target="sec.ccnxintcompbaseheader"/>.</t>

              <t hangText="RSV: Reserved">Must target="sec.ccnxintcompbaseheader" format="default"/>.</dd>
            <dt>RSV: Reserved</dt>
            <dd>Must be set to 0.</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-Hop toc="exclude" numbered="true">
            <name>Hop-By-Hop Header TLVs Compression" toc="exclude">
            <t>Hop-By-Hop Header Compression</name>
            <t>Hop-by-hop header TLVs are unordered. For a Content Object
            message, two optional Hop-By-Hop Header hop-by-hop header TLVs are defined in
	    <xref
            target="RFC8609"/>, target="RFC8609" format="default"/>, but several more can be defined in higher
            level
	    higher-level specifications. For the compression specified in the
            previous section, the Hop-By-Hop hop-by-hop TLVs are ordered as follows:
            <list style="numbers">
                <t>Recommended
            </t>
            <ol spacing="normal" type="1">
	      <li>Recommended Cache Time TLV</t>

                <t>Message TLV</li>
              <li>Message Hash TLV</t>
              </list></t> TLV</li>
            </ol>
            <t>Note: Other Hop-By-Hop Header All hop-by-hop header TLVs other than those two the RecommendedCacheTime
            and MessageHash TLVs remain uncompressed in the encoded message message, and
            they appear after the RecommendedCacheTime and MessageHash TLVs in
            the same order as in the original message, but after the Recommended Cache Time TLV and Message Hash TLV.</t> message.</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 <xref target="sec.dispatch.ext"/> target="sec.dispatch.ext" format="default"/> and is illustrated
          in <xref target="fig.ccnx.data.ext0"/>.</t> target="fig.ccnx.data.ext0" format="default"/>.</t>
          <figure anchor="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 Compression Strategy"><list
                  hangIndent="12" style="hanging">
                  <t hangText="00:">Names Strategy</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>00:</dt>
                <dd>Names are compressed with the default name
                  compression strategy (see <xref
                  target="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">Must target="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 to 0.</t>

              <t hangText="EXT: Extension"><list hangIndent="8"
                  style="hanging">
                  <t hangText="0:">No 0.</dd>
            <dt>EXT: Extension</dt>
            <dd>
              <dl newline="false" spacing="normal" indent="4">
                <dt>0:</dt>
                <dd>No extension byte follows.</t>

                  <t hangText="1:">A follows.</dd>
                <dt>1:</dt>
                <dd>A further extension byte follows
                  immediately.</t>
                </list></t>
            </list></t>
                  immediately.</dd>
              </dl>
            </dd>
          </dl>
        </section>
      </section>
    </section>
    <section title="Compressed anchor="sec.compressedtime" numbered="true" toc="default">
      <name>Compressed Time Encoding" anchor="sec.compressedtime"> Encoding</name>
      <t>
        This document adopts the 8-bit compact time representation for
        relative time values time-values described in Section 5 of <xref
        target="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 NDN reach range 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
        <xref target="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 &gt; 0):"> 0):</dt>
        <dd> (1 + a/8) * 2^b 2<sup>b</sup> * C (see <xref target="RFC5497"/>)
          </t>
        </list>

        This target="RFC5497" format="default"/>)
          </dd>
      </dl>
      <t>This configuration allows for the following ranges:

        <list style="symbols">
          <t>Minimum ranges:</t>
      <ul spacing="compact">
        <li>Minimum subnormal number: 0 seconds</t>
          <t>2nd seconds</li>
        <li>2nd minimum subnormal number: ~0.007812 seconds</t>
          <t>Maximum seconds</li>
        <li>Maximum subnormal number: ~0.054688 seconds</t>
          <t>Minimum seconds</li>
        <li>Minimum normalized number: ~0.062500 seconds</t>
          <t>2nd seconds</li>
        <li>2nd minimum normalized number: ~0.070312 seconds</t>
          <t>Maximum seconds</li>
        <li>Maximum normalized number: ~3.99 years</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-value MUST <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="Stateful numbered="true" toc="default">
      <name>Stateful Header Compression"> 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 single
      Interest-data
      Interest-Data exchange may be removed from ICN stateful forwarding on a
      hop-by-hop bases basis and memorized in en-route en route state tables.</t>
      <section anchor="stateful.compression.local" title="LoWPAN-local State"> numbered="true" toc="default">
        <name>LoWPAN-Local State</name>
        <t>A context identifier Context Identifier (CID) is a byte that refers to a particular
        conceptual context between network devices and MAY <bcp14>MAY</bcp14> be used to replace
        frequently appearing information, such as name prefixes, suffixes, or
        meta information, such as Interest lifetime.</t>
        <figure anchor="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            CID            |
+---+---+---+---+---+---+---+---+
]]></artwork>
        </figure>
        <t>The 7-bit ContextID CID is a locally-scoped locally scoped unique identifier that
        represents contextual the context state shared between the sender and receiver of the
        corresponding frame (see <xref target="fig.cid"/>). target="fig.cid" format="default"/>).
        If set set, the most significant bit indicates the presence of another, subsequent
        ContextID
        CID byte (see <xref target="fig.cid.chain"/>).</t>

        <t>Context target="fig.cid.chain" format="default"/>).</t>
        <t>The context state shared between senders and receivers is removed from the
        compressed packet prior to sending, 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 CIDs MUST <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 in data Data messages. Returning Name TLVs either equal the
        original Name TLV, TLV or they contain 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 <xref target="stateful.compression.local"/>) target="stateful.compression.local" format="default"/>) of link-local scope scope, as shown in <xref
        target="fig.hopid"/>.</t> target="fig.hopid" format="default"/>.</t>
        <figure anchor="fig.hopid" title="Context anchor="fig.hopid">
          <name>Context Identifier as HopID."> HopID</name>
<artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| X |          HopID            |
+---+---+---+---+---+---+---+---+
]]></artwork>
        </figure>
        <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 messages MUST <bcp14>MUST</bcp14> be sent without en-route en route state
        compression until new HopIDs are available. An ICN LoWPAN node that
        forwards without replacing the name by Name TLV with a HopID (without en-route en route
        compression) MUST <bcp14>MUST</bcp14> invalidate the HopID by setting all ID-bits ID bits to
        zero.</t>
        <t>While an Interest is traversing, a forwarder generates an ephemeral
        HopID that is tied to a PIT Pending Interest Table (PIT) entry. Each HopID MUST
	<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 <xref
        target="fig.enroute-a"/>). target="fig.enroute-a" format="default"/>). </t>
        <figure anchor="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 is elided elided, 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 (<xref target="fig.enroute-b"/>). target="fig.enroute-b" format="default"/>). </t>
        <figure
            anchor="fig.enroute-b"
            title="Eliding anchor="fig.enroute-b">
          <name>Eliding Name TLVs using 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
        en route compression or not. However, an ICN LoWPAN node SHOULD <bcp14>SHOULD</bcp14> use
        en-route
        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>
      <section title="Integrating numbered="true" toc="default">
        <name>Integrating Stateful Header Compression"> Compression</name>
        <t>A CID appears whenever the CID flag is set (see <xref
        target="fig.disp.base.compr"/>). target="fig.disp.base.compr" format="default"/>). The CID is appended to the last ICN
        LoWPAN dispatch byte byte, as shown in <xref target="fig.cid.loc"/>.</t> target="fig.cid.loc" format="default"/>.</t>
        <figure anchor="fig.cid.loc"
                title="LoWPAN anchor="fig.cid.loc">
          <name>LoWPAN Encapsulation with ICN LoWPAN and CIDs"> CIDs</name>
<artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
...-------+--------+-------...-------+--...-+-------...
/  ...    |  Page  | ICN LoWPAN Disp.| CIDs | Payload /
...-------+--------+-------...-------+--...-+-------...
]]></artwork>
        </figure>
        <t>Multiple CIDs are chained together, with the most significant bit
        indicating the presence of a subsequent CID (<xref
        target="fig.cid.chain"/>). target="fig.cid.chain" format="default"/>). This allows to the use of multiple shared contexts in compressed messages.</t>
        <t>The HopID is always included as the very first CID.</t>
        <figure anchor="fig.cid.chain"
                title="Chaining anchor="fig.cid.chain">
          <name>Chaining of context identifiers."> Context Identifiers</name>
<artwork align="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="ICN numbered="true" toc="default">
      <name>ICN LoWPAN Constants and Variables"> 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="Implementation numbered="true" toc="default">
      <name>Implementation Report and Guidance"> Guidance</name>
      <t>The ICN LoWPAN scheme defined in this document has been implemented as
      an extension of the NDN/CCNx software stack <xref target="CCN-LITE"/> target="CCN-LITE" format="default"/> in
      its IoT version on RIOT <xref target="RIOT"/>. target="RIOT" format="default"/>. An experimental
      evaluation for NDN over ICN LOWPAN LoWPAN with varying configurations has been
      performed in <xref target="ICNLOWPAN"/>. target="ICNLOWPAN" format="default"/>.  Energy profilings profiling and
      processing time measurements indicate significant energy savings, while and the
      amortized costs for processing show no penalties.</t>
      <section title="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 offsets compress as compress, per <xref
            target="sec.compressedtime"/> target="sec.compressedtime"
	  format="default"/>, without the need for
            rounding.</t>

            <t>Contextual rounding.</li>
          <li>The context state (e.g., prefixes) is distributed, distributed such that
            long names can be elided from Interest and data messages.</t>

            <t>Frequently Data messages.</li>
          <li>Frequently used TLV type numbers for CCNx and NDN stay
            in the lower range (&lt; 255).</t>
          </list> 255).</li>
        </ul>
        <t>
          Name components are of GenericNameComponent type GenericNameComponent and are limited to a
        length of 15 bytes to enable compression for all messages.</t>
      </section>
      <section title="Further numbered="true" toc="default">
        <name>Further Experimental Deployments"> 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 (<xref
          target="sec.ndn.namecompression"/>) target="sec.ndn.namecompression" format="default"/>) is optimized for short
          name components of GenericNameComponent 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
          (<xref target="sec.ndn.interest.ext0"/>). target="sec.ndn.interest.ext0" format="default"/>). As a preliminary
          analysis, <xref target="ICNLOWPAN"/> target="ICNLOWPAN" format="default"/> investigates the
          effectiveness of the proposed compression scheme with URLs
          obtained from the WWW. Studies on CoAP <xref
          target="RFC7252"/> deployments of Constrained Application Protocol (CoAP) <xref target="RFC7252" format="default"/> can offer additional insights
          on naming schemes in the IoT.</t>

          <t>The IoT.</li>
          <li>The fragmentation scheme (<xref
          target="sec.Fragmentation"/>) target="sec.Fragmentation" format="default"/>) inherited from 6LoWPAN allows
          for a transparent, hop-wise reassembly of CCNx or NDN
          packets. Fragment forwarding <xref
          target="RFC8930"/> target="RFC8930" format="default"/> with selective
          fragment recovery <xref
          target="RFC8931"/> target="RFC8931" format="default"/> can improve the
          end-to-end latency and reliability, 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 and data Data 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 (<xref
          target="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 protocol fields.</t>

          <t>The fields.</li>
          <li>The distribution and synchronization of contextual the context state
          can potentially be adopted from Section 7.2 of <xref
          target="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 manage
          configurations.</t>

          <t>The
          configurations.</li>
          <li>The stateful en-route en route compression (<xref
          target="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 the Pending
          Interest Table
          PIT of memory-constrained devices. This number
          can serve as an upper-bound upper bound and determines whether the HopID
          length needs to be resized to fit more HopIDs to at the cost of
          additional header overhead.</t>

          <t>Multiple overhead.</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 illuminate on the complexity of implementing ICN
          LoWPAN for constrained devices, as well as on maintaining
          interoperability with other implementations.</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. Fragmentation Fragmentation, as described in this memo memo, 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
      <xref target="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 the
      link-layer
      link layer should be deployed. IEEE 802.15.4, e.g., provides capabilities to protect frames and restrict them to a point-to-point link, link or a group of devices.</t>
    </section>
    <section anchor="iana" title="IANA Considerations">
      <section title="Reserving Space in numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section numbered="true" toc="default">
        <name>Updates to the 6LoWPAN Dispatch Type Field Registry"> Registry</name>
        <t>IANA has assigned dispatch values of for ICN LoWPAN in the <spanx style="verb">6LoWPAN Dispatch "Dispatch Type Field</spanx>
        registry Field"
        subregistry <xref target="RFC4944"/><xref target="RFC8025"/> with Page
        TBD1 for ICN LoWPAN. target="RFC4944" format="default"/> <xref
        target="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 types align="center">
          <name>Dispatch Types for NDN and CCNx with page TBD1.">
          <ttcol CCNx</name>
          <thead>
            <tr>
              <th align="center">Bit Pattern</ttcol>

          <ttcol align="center">Page</ttcol>

          <ttcol Pattern</th>
              <th align="center">Page</th>
              <th align="left">Header Type</ttcol>

          <c>00 000000</c>

          <c>TBD1</c>

          <c>Uncompressed Type</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 NDN Interest messages</c>

          <c>00 100000</c>

          <c>TBD1</c>

          <c>Uncompressed Data 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 Data messages</c>

          <c>01 000000</c>

          <c>TBD1</c>

          <c>Uncompressed CCNx Interest messages</c>

          <c>01 100000</c>

          <c>TBD1</c>

          <c>Uncompressed messages</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 Object messages</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>Compressed messages</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 Object messages</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"/>

        <reference anchor="ieee802.15.4"
                 target="https://standards.ieee.org/findstds/standard/802.15.4-2015.html"> target="https://standards.ieee.org/standard/802_15_4-2020.html">
          <front>
            <title>IEEE Std. 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-2020"/>
        </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><organization>IEEE</organization></author>
          </front>
	  <seriesInfo name="IEEE Std" value="754-2019"/>
        </reference>
      </references>

      <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"/>

        <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"/>

<reference anchor="I-D.irtf-icnrg-flic">
<front>
<title>File-Like ICN Collections (FLIC)</title>
<author initials="" fullname=""
                  surname="Institute of Electrical and Electronics Engineers, C/MSC - Microprocessor Standards Committee"/> initials="C." surname="Tschudin" fullname="Christian Tschudin">
<organization>University of Basel</organization>
</author>
<author initials="C." surname="Wood" fullname="Christopher A. Wood">
<organization>University of California Irvine</organization>
</author>
<author initials="M." surname="Mosko" fullname="Marc Mosko">
<organization>PARC, Inc.</organization>
</author>
<author initials="D." surname="Oran" fullname="David R. Oran" role="editor">
<organization>Network Systems Research &amp; Design</organization>
</author>
<date month="June" 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>

    </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"?>

      <!--<?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"?>

        <reference anchor="CCN-LITE" target="http://ccn-lite.net/"> target="https://github.com/cn-uofbasel/ccn-lite">
          <front>
          <title>CCN-lite: A
            <title>CCN-lite, a lightweight implementation of the CCNx protocol and NDN implementation</title> its variations</title>
            <author/>

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

        <reference anchor="RIOT" target="https://doi.org/10.1109/JIOT.2018.2815038">
          <front>
            <title>RIOT: an An Open Source Operating System for Low-end Low-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 Things Journal"
                    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>Information Centric Networking centric networking in the IoT: Experiments experiments with
          NDN in the Wild</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 Study a 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>The Need need for a Name name to MAC Address Mapping address mapping in NDN: Towards
          Quantifying towards
            quantifying the Resource 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>Networking Named 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 and Technologies"
                    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"> target="https://doi.org/10.1016/j.comcom.2020.10.002">
          <front>
          <title>ICNLoWPAN -- Named-Data Networking in Low Power IoT
          Networks</title>
            <title>Designing a LoWPAN convergence layer for the Information Centric Internet of Things</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="TC." initials="T." 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"/> month="December" year="2020"/>
          </front>

        <seriesInfo name="Proc. of 18th" value="IFIP Networking Conference"/>
          <refcontent>Computer Communications, Vol. 164, No. 1, p. 114–123, Elsevier</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="sec.EstimatedSizeReduction"
             title="Estimated numbered="true" toc="default">
      <name>Estimated Size Reduction"> Reduction</name>
      <t>In the following following, 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 name
      components, <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 components is are
      specific to the CCNx or NDN encoding and are outlined below.</t>
      <section title="NDN"> numbered="true" toc="default">
        <name>NDN</name>
        <t>The NDN TLV encoding has variable-sized TLV fields. For simplicity,
        the 1 byte 1-byte form of each TLV component is assumed. A typical TLV
        component therefore is of size 2 (type (Type field + length Length field) + the
        actual value.</t>
        <section title="Interest"> numbered="true" toc="default">
          <name>Interest</name>
          <t><xref target="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, a an InterestLifetime TLV set to
          4 seconds seconds, and a HopLimit TLV set to 6. Numbers below represent the
          amount of bytes.</t>
          <figure anchor="fig.Size.NDN.interest.uncompressed"
                  title="Estimated size anchor="fig.Size.NDN.interest.uncompressed">
            <name>Estimated Size of an uncompressed Uncompressed NDN Interest"> Interest</name>
<artwork align="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><xref target="fig.Size.NDN.interest.compressed"/> target="fig.Size.NDN.interest.compressed" format="default"/> depicts the
          size requirements after compression.</t>
          <figure anchor="fig.Size.NDN.interest.compressed"
                  title="Estimated size anchor="fig.Size.NDN.interest.compressed">
            <name>Estimated Size of a compressed Compressed NDN Interest"> Interest</name>
<artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
------------------------------------,
Dispatch Page Switch    = 1         |
NDN Interset Interest 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 difference is: <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>
        <section title="Data"> numbered="true" toc="default">
          <name>Data</name>
          <t><xref target="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 is
          assumed
          assumed, 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>
          <figure anchor="fig.Size.NDN.Data.uncompressed"
                  title="Estimated size anchor="fig.Size.NDN.Data.uncompressed">
            <name>Estimated Size of an uncompressed Uncompressed NDN Data"> Data</name>
<artwork align="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><xref target="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>
          <figure anchor="fig.Size.NDN.Data.compressed"
                  title="Estimated size anchor="fig.Size.NDN.Data.compressed">
            <name>Estimated Size of a compressed Compressed NDN Data"> Data</name>
<artwork align="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 difference is: <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>
      <section title="CCNx"> numbered="true" toc="default">
        <name>CCNx</name>
        <t>The CCNx TLV encoding defines a 2-byte encoding for type Type and
        length
        Length fields, summing up to 4 bytes in total without a value.</t>
        <section title="Interest"> numbered="true" toc="default">
          <name>Interest</name>
          <t><xref target="fig.Size.CCNx.interest.uncompressed"/> target="fig.Size.CCNx.interest.uncompressed" format="default"/> depicts
	  the size requirements for a basic, uncompressed CCNx Interest. No
          Hop-By-Hop
          hop-by-hop TLVs are included, the protocol version is assumed to be
          1
          1, and the reserved Reserved 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>
          <figure anchor="fig.Size.CCNx.interest.uncompressed"
                  title="Estimated size anchor="fig.Size.CCNx.interest.uncompressed">
            <name>Estimated Size of an uncompressed Uncompressed CCNx Interest"> Interest</name>
<artwork align="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><xref target="fig.Size.CCNx.interest.compressed"/> target="fig.Size.CCNx.interest.compressed" format="default"/>
	  depicts the size requirements after compression.</t>
          <figure anchor="fig.Size.CCNx.interest.compressed"
                  title="Estimated size anchor="fig.Size.CCNx.interest.compressed">
            <name>Estimated Size of a compressed Compressed CCNx Interest"> Interest</name>
<artwork align="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 difference is: <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>
        <section title="Content Object"> numbered="true" toc="default">
          <name>Content Object</name>
          <t><xref target="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
          signature time time, and a hash of the shared secret key. In the fixed
          header, the protocol version is assumed to be 1 and the reserved Reserved
          field is assumed to be 0</t>
          <figure anchor="fig.Size.CCNx.Data.uncompressed"
                  title="Estimated size anchor="fig.Size.CCNx.Data.uncompressed">
            <name>Estimated Size of an uncompressed Uncompressed CCNx Content Object"> Object</name>
<artwork align="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        |
      KeyId
      KeyID            |            |
    SignatureTime      |            |
  ---------------------'            |
  ValidationPayload     = 36        |
------------------------------------'
]]></artwork>
          </figure>
          <t><xref target="fig.Size.CCNx.Data.compressed"/> target="fig.Size.CCNx.Data.compressed" format="default"/>
	  depicts the size
          requirements for a basic, compressed CCNx Data.</t>
          <figure anchor="fig.Size.CCNx.Data.compressed"
                  title="Estimated size anchor="fig.Size.CCNx.Data.compressed">
            <name>Estimated Size of a compressed Compressed CCNx Data Object"> Object</name>
<artwork align="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 difference is: <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>
    <section numbered="no" title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>This work was stimulated by fruitful discussions in the ICNRG
      research group
      and 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 by
      Dave Oran,
      <contact fullname="Dave Oran"/>, which is gratefully acknowledged.
      Larger parts of this work
      are inspired by <xref target="RFC4944"/> target="RFC4944" format="default"/> and
      <xref target="RFC6282"/>. target="RFC6282" format="default"/>.
      Special mentioning mention goes to Mark Mosko <contact fullname="Mark Mosko"/>, as well as G.Q. Wang and Ravi
      Ravindran
      <contact fullname="G.Q. Wang"/> and <contact fullname="Ravi Ravindran"/>,
      as their previous work in <xref target="TLV-ENC-802.15.4"/> target="TLV-ENC-802.15.4" format="default"/>
      and <xref target="WIRE-FORMAT-CONSID"/> target="WIRE-FORMAT-CONSID" format="default"/> provided a good base for our
      discussions on stateless header compression mechanisms.
      Many thanks also to Carsten 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>
  </back>
</rfc>