Movatterモバイル変換

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE rfc [  <!ENTITY nbsp    "&#160;">  <!ENTITY zwsp   "&#8203;">  <!ENTITY nbhy   "&#8209;">  <!ENTITY wj     "&#8288;">]><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" submissionType="IRTF" category="exp" consensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">  <!-- xml2rfc v2v3 conversion 3.9.1 -->  <front>    <title abbrev="ICN Adaptation to LoWPANs">ICN    Adaptation to LoWPAN Networks (ICN LoWPAN)</title>    <seriesInfo name="RFC"    <author fullname="Cenk Gundogan" initials="C." surname="Gundogan">      <organization abbrev="HAW Hamburg">HAW Hamburg</organization>      <address>        <postal>          <street>Berliner Tor 7</street>          <city>Hamburg</city>          <code>D-20099</code>          <country>Germany</country>        </postal>        <phone>+4940428758067</phone>        <email>cenk.guendogan@haw-hamburg.de</email>        <uri>http://inet.haw-hamburg.de/members/cenk-gundogan</uri>      </address>    </author>    <author fullname="Thomas C. Schmidt" initials="TC." surname="Schmidt">      <organization abbrev="HAW Hamburg">HAW Hamburg</organization>      <address>        <postal>          <street>Berliner Tor 7</street>          <city>Hamburg</city>          <code>D-20099</code>          <country>Germany</country>        </postal>        <email>t.schmidt@haw-hamburg.de</email>        <uri>http://inet.haw-hamburg.de/members/schmidt</uri>      </address>    </author>    <author fullname="Matthias initials="M."      <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>      </address>    </author>    <author fullname="Christopher Scherb" initials="C." surname="Scherb">      <organization abbrev="University of Basel">University of      Basel</organization>      <address>        <postal>          <street>Spiegelgasse 1</street>          <city>Basel</city>          <code>4051</code>          <country>Switzerland</country>        </postal>        <email>christopher.scherb@unibas.ch</email>      </address>    </author>    <author fullname="Claudio Marxer" initials="C." surname="Marxer">      <organization abbrev="University of Basel">University of      Basel</organization>      <address>        <postal>          <street>Spiegelgasse 1</street>          <city>Basel</city>          <code>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>4051</code>          <country>Switzerland</country>        </postal>        <email>christian.tschudin@unibas.ch</email>      </address>    </author>    <date year="2021" /><!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search.--><keyword>example</keyword>    <abstract>      <t>This document defines a convergence layer for and over IEEE      802.15.4 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 is extended      to include new dispatch types for CCNx and NDN.      Additionally, the fragmentation component of the 6LoWPAN      dispatching framework is applied to      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 local to the LoWPAN and replace names in 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" numbered="true" toc="default">      <name>Introduction</name>      <t>The Internet of Things (IoT) has been identified as a promising      deployment area for (ICN), as      infrastructureless access to content, resilient forwarding, and      in-network data replication notable advantages over the      traditional host-to-host approach on the Internet <xref <xref format="default"/>. Recent studies <xref      format="default"/> have shown that an appropriate mapping to 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      format="default"/> and CCNx <xref <xref      format="default"/>.</t>      <t>The IEEE 802.15.4 <xref format="default"/> link layer is      used in low-power and lossy networks (see <tt>LLN</tt> in      <xref format="default"/>), in which devices are typically and constrained in resources. Characteristics of LLNs      include an unreliable environment, transmissions, and      increased latencies. IEEE 802.15.4 admits a maximum      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, and content.</t>      <t>6LoWPAN <xref is a      convergence layer that provides frame formats, header and 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 packet formats such as in      CCNx and are designed to be generic and extensible.  This leads to      header 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 as well as 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 reuse      the fragmentation scheme specified by 6LoWPAN for ICN LoWPAN.</t>      <t>ICN LoWPAN defines a more 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 format="default"/> illustrate a reduced message overhead, a shortened      message airtime, and an overall decline in power consumption for typical      Class 2 <xref format="default"/> compared to uncompressed ICN messages.</t>      <t>In a typical IoT scenario (see <xref 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 with the public Internet. In      IoT networks, Interest and Data messages transparently travel      through the BR up and down between a and the embedded devices      situated in the constrained LoWPAN.</t>      <figure anchor="fig-iot_network">        <name>IoT Stub Network</name><artwork align="center" name="" type="" alt=""><![CDATA[  |Gateway Services|  -------------------------        |    ,--------,    |        |    |   BR   |    |        |    '--------'                 LoWPAN  O            O         OO                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 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 numbered="true" toc="default">      <name>Terminology</name> key words and in this   document are to be interpreted as described in RFC 2119   The use of the term, "silently ignore" is not defined in RFC 2119.   However, the term is used in this document and can be similarly      <t>This document uses the terminology of <xref format="default"/>, <xref format="default"/>, and <xref format="default"/> for ICN entities.</t>      <t>The following terms are used in the document and defined as follows:      </t>      <dl newline="false" spacing="normal" indent="14">        <dt>ICN LoWPAN:</dt>        <dd>Information-Centric Networking over Wireless Personal Area Network</dd>        <dt>LLN:</dt>        <dd>Low-Power and Lossy Network</dd>        <dt>CCNx:</dt>        <dd>Content-Centric        <dt>NDN:</dt>        <dd>Named Data        <dt>byte:</dt>        <dd>synonym for octet</dd>        <dt>nibble:</dt>        <dd>synonym for 4 bits</dd>        <dt>time-value:</dt>        <dd>a time offset measured in seconds</dd>        <dt>time-code:</dt>        <dd>an 8-bit encoded time-value</dd>      </dl>    </section>    <section anchor="ICNLoWPAN" numbered="true" toc="default">      <name>Overview of ICN LoWPAN</name>      <section 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 format="default"/>.</t>        <figure anchor="fig.intro.hbh">          <name>ICN LoWPAN for IEEE 802.15.4</name><artwork 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  ||----------------|-|    |-|--------------|-|     |-|----------------||    | |    | |  | |     | |  |'----------------|-'    '-|--------------|-'     '-|----------------'                 '--------'              '---------']]></artwork>        </figure>        <t><xref format="default"/> of this document defines the        convergence layer for IEEE 802.15.4.</t>      </section>      <section numbered="true" toc="default">        <name>Stateless Header 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 with small MTUs. The        stateless compression does not require of 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 is its        native support of variably structured data. The main disadvantage of        TLVs is the verbosity that results from storing the type and length of        the encoded data.</t>        <t>The stateless header compression scheme makes use of compact bit        fields to indicate the presence of optional TLVs in the uncompressed        packet. The order of set bits in the bit fields corresponds to the        order of each TLV in the packet. Further compression is achieved by        specifying default values and reducing the range of certain header        fields.</t>        <t><xref 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 and fields are removed. The third TLV        represents a boolean TLV (e.g., the MustBeFresh selector in NDN) for        which the and fields are elided.</t>        <figure anchor="fig.TLV.compressed">          <name>Compression a the of<artwork 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  +---+---+---+---+---+---+---+---+    |       |                   | ,--'       '----,              '- Boolean Value |               |+-------+-------+-------+|  LEN  |  VAL  |  VAL  |+-------+-------+-------+'---------------'-------'  Var-len Value  Fixed-len Value]]></artwork>        </figure>        <t>Stateless TLV compression for NDN is defined in <xref format="default"/>. <xref format="default"/> defines the stateless        TLV compression for CCNx.</t>        <t>The extensibility of this compression is described in <xref format="default"/> and allows future documents to update the        compression rules outlined in this      </section>      <section numbered="true" toc="default">        <name>Stateful Header Compression</name>        <t>ICN LoWPAN further employs two stateful compression        schemes for packet size which are defined in <xref format="default"/>. These mechanisms rely on shared        contexts that are either distributed and maintained in the entire or are generated hop-wise on a particular path.</t>        <t>The shared context identification is defined in <xref format="default"/>. The hop-wise name compression        "en-route" is specified in <xref format="default"/>.</t>      </section>    </section>    <section anchor="sec.lowpan_adaptation" numbered="true" toc="default">      <name>IEEE 802.15.4 Adaptation</name>      <section anchor="sec.lowpan_encap" numbered="true" toc="default">        <name>LoWPAN Encapsulation</name>        <t>The IEEE 802.15.4 frame header does not provide a protocol        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 <xref section="5" sectionFormat="of" format="default"/>).        Multiple LoWPAN encapsulation headers can precede the actual        and each encapsulation header is identified by a dispatch type.</t>        <t><xref format="default"/> further specifies dispatch toswitch between different contexts. When a LoWPAN parser encounters a <tt>Pageswitch</tt> LoWPAN encapsulation header, all        following encapsulation headers are interpreted by using a dispatch as specified by the <tt>Page switch</tt>        header. 0 and 1 are reserved for 6LoWPAN. This document uses (<tt>1111 for ICN LoWPAN.</t>        <t>The base dispatch format (<xref format="default"/>) isused and extended by CCNx and NDN in <xref and<xref        <figure anchor="fig.disp.base">          <name>Base for ICN LoWPAN</name><artwork align="center" name="" type="" alt=""><![CDATA[  0   1   2   ...| | P | M |]]></artwork>        </figure>        <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.</dd>              <dt>1:</dt>              <dd>The included protocol is CCNx.</dd>            </dl>          </dd>          <dt>M: Message Type</dt>          <dd>            <dl newline="false" spacing="normal" indent="4">              <dt>0:</dt>              <dd>The payload contains an Interest message.</dd>              <dt>1:</dt>              <dd>The payload contains a Data message.</dd>            </dl>          </dd>        </dl>        <t>ICN LoWPAN frames with compressed CCNx and NDN messages (C=1) use        the extended dispatch format in <xref format="default"/>.</t>        <figure anchor="fig.disp.base.compr">          <name>Extended for ICN LoWPAN</name><artwork align="center" name="" type="" alt=""><![CDATA[  0   1   2   3      ...| | P | M   |CID|EXT|]]></artwork>        </figure>        <dl newline="true" spacing="normal" indent="4">          <dt>CID: Context Identifier</dt>          <dd>            <dl newline="false" spacing="normal" indent="4">              <dt>0:</dt>              <dd>No context identifiers are present.</dd>              <dt>1:</dt>              <dd>Context identifier(s) are present (see <xref 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.</dd>              <dt>1:</dt>              <dd>Extension byte(s) are present (see <xref format="default"/>).</dd>            </dl>          </dd>        </dl>        <t>The encapsulation format for ICN LoWPAN is displayed in <xref format="default"/>.</t>        <figure anchor="fig.ICN-LoWPAN.header">          <name>LoWPAN Encapsulation with<artwork align="center" name="" type="" alt=""><![CDATA[+------...------+------...-----+--------+-------...-------+-----...| IEEE 802.15.4 | RFC4944 Disp.|  Page  | ICN LoWPAN Disp.| Payl. /+------...------+------...-----+--------+-------...-------+-----...]]></artwork>        </figure>        <dl newline="false" spacing="normal" indent="16">          <dt>IEEE 802.15.4:</dt>          <dd>The IEEE 802.15.4 header.</dd>          <dt>RFC4944 Disp.:</dt>          <dd>Optional additional dispatches            defined in <xref section="5.1" sectionFormat="of"          <dt>Page:</dt> for ICN LoWPAN.</dd>          <dt>ICN LoWPAN:</dt>          <dd>Dispatches as defined in <xref and <xref          <dt>Payload:</dt>          <dd>The actual (un-)compressed CCNx or NDN            message.</dd>        </dl>        <section anchor="sec.dispatch.ext" 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 format="default"/>.</t>          <figure anchor="fig.ext.base">            <name>Base for<artwork align="center" name="" type="" alt=""><![CDATA[  0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+| - | - | - | - | - | - | - |EXT|+---+---+---+---+---+---+---+---+]]></artwork>          </figure>          <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.</dd>                <dt>1:</dt>                <dd>A further extension byte follows.</dd>              </dl>            </dd>          </dl>          <t>Extension bytes are numbered according to their order. Future          documents <bcp14>MUST</bcp14> follow the naming scheme <tt>EXT_0, EXT_1,          when updating or referring to a specific dispatch extension byte.          Amendments that require an exchange of configurational parameters          between devices <bcp14>SHOULD</bcp14> use manifests to encode structured data in a          well-defined format, e.g., outlined in <xref format="default"/>.</t>        </section>      </section>      <section anchor="sec.Fragmentation" numbered="true" toc="default"> Fragmentation</name>        <t>Small payload sizes in the LoWPAN require fragmentation for various        network layers. Therefore, <xref 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 format="default"/>.</t>        <t>The LoWPAN header can encapsulate other dispatch        headers. The order of dispatch types is defined in <xref section="5" sectionFormat="of" format="default"/>. <xref format="default"/> shows the        fragmentation scheme. The reassembled ICN LoWPAN frame does not        contain any fragmentation headers and is depicted in <xref format="default"/>.</t>        <figure anchor="fig.fr_first">          <name>Fragmentation<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">          <name>Reassembled ICN LoWPAN<artwork align="center" name="" type="" alt=""><![CDATA[+------...------+--------+------...-------+--------...| IEEE 802.15.4 |  Page  |   ICN LoWPAN   | Payload  /+------...------+--------+------...-------+--------...]]></artwork>        </figure>        <t>The 6LoWPAN Fragment Forwarding <xref format="default"/> is an alternative        approach that enables forwarding of fragments without        reassembling packets on every intermediate hop. By reusing the        6LoWPAN dispatching framework, integrates into ICN LoWPAN        as as the conventional hop-wise        fragmentation. evaluations <xref suggest that a        integration can increase the cache utilization of forwarders        on a request path.</t>      </section>    </section>    <section anchor="sec.ndn" numbered="true" toc="default"> Message Encoding for NDN</name>      <section anchor="sec.tlvencoding" numbered="true" toc="default">        <name>TLV Encoding</name>        <t>The NDN packet format consists of TLV fields using the TLV encoding        that is described in <xref format="default"/>. Type and        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 <tt>253</tt>,        then that number is encoded into the actual or field. If        the number is greater or equals <tt>253</tt> and        fits into 2 bytes, then the or field is set to <tt>253</tt> and the number is encoded in the next        following 2 bytes in network byte order, i.e., from the most        significant byte (MSB) to the least significant byte (LSB). If the        number is greater than 2 bytes and fits into 4 bytes, then the        or field is set to <tt>254</tt> and the        number is encoded in the subsequent 4 bytes in network byte order.        For larger numbers, the or field is set to <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 and fields using self-delimiting numeric values (SDNVs)        <xref format="default"/> commonly known from 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>        <table anchor="tab.sdnvperformance" align="center">          <name>NDN TLV to          <thead>            <tr>              <th align="left">Value</th>              <th align="left">NDN TLV              <th align="left">SDNV            </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</td>              <td align="left">0x81 0x7D</td>            </tr>            <tr>              <td - 1</td>              <td align="left">0xFD 0x3F 0xFF</td>              <td align="left">0xFF 0x7F</td>            </tr>            <tr>              <td              <td align="left">0xFD 0x40 0x00</td>              <td align="left">0x81 0x80 0x00</td>            </tr>            <tr>              <td              <td align="left">0xFE 0x00 0x01 0x00 0x00</td>              <td align="left">0x84 0x80 0x00</td>            </tr>            <tr>              <td - 1</td>              <td align="left">0xFE 0x00 0x1F 0xFF 0xFF</td>              <td align="left">0xFF 0xFF 0x7F</td>            </tr>            <tr>              <td              <td align="left">0xFE 0x00 0x20 0x00 0x00</td>              <td align="left">0x81 0x80 0x80 0x00</td>            </tr>            <tr>              <td - 1</td>              <td align="left">0xFE 0x0F 0xFF 0xFF 0xFF</td>              <td align="left">0xFF 0xFF 0xFF 0x7F</td>            </tr>            <tr>              <td              <td align="left">0xFE 0x1F 0x00 0x00 0x00</td>              <td align="left">0x81 0x80 0x80 0x80 0x00</td>            </tr>            <tr>              <td              <td align="left">0xFF 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00</td>              <td align="left">0x90 0x80 0x80 0x80 0x00</td>            </tr>            <tr>              <td - 1</td>              <td align="left">0xFF 0x00 0x00 0x00 0x07 0xFF 0xFF 0xFF 0xFF</td>              <td align="left">0xFF 0xFF 0xFF 0xFF 0x7F</td>            </tr>            <tr>              <td              <td align="left">0xFF 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00</td>              <td align="left">0x81 0x80 0x80 0x80 0x80 0x00</td>            </tr>          </tbody>        </table>        <t>          <xref format="default"/> compares the required          bytes for encoding a few selected values using the NDN TLV          encoding and SDNVs. For values up to 127, both methods          require a single byte. Values in the range [128;252] encode          as one byte for the NDN TLV scheme, while SDNVs require two          bytes.  Starting at value 253, SDNVs require a less or equal          amount of bytes compared to the NDN TLV encoding.        </t>      </section>      <section anchor="sec.ndn.namecompression" numbered="true" toc="default">        <name>Name TLV Compression</name>        <t>This Name TLV compression encodes 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 field of an encoded NameComponent is either 0x00 for a name with an even number of        and 0xYF (Y &gt; 0) if an odd number of components are present.        This process limits the length of a NameComponent TLV to 15 but allows for an unlimited number of components.        An example for this encoding is presented in <xref format="default"/>.</t>        <figure anchor="fig.ndnshortnco">          <name>Name TLV for /HAW/Room/481/Humid/99</name><artwork 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 numbered="true" toc="default">        <name>Interest Messages</name>        <section numbered="true" toc="default">          <name>Uncompressed Interest Messages</name>          <t>An uncompressed Interest message uses the base dispatch format          (see <xref format="default"/>) and sets the and M to <tt>0</tt> (<xref format="default"/>).          The Interest message is handed to the NDN network stack without modifications.</t>          <figure anchor="fig.ndn.int.uncompr">            <name>Dispatch for NDN Interest<artwork 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 numbered="true" toc="default">          <name>Compressed Interest Messages</name>          <t>The compressed Interest message uses the extended dispatch format          (<xref format="default"/>) and sets the C flag to the P and M to <tt>0</tt>.          If an Interest message contains TLVs that are not mentioned in the          following compression rules, then this message <bcp14>MUST</bcp14> be sent          uncompressed.</t>          <t>This specification assumes that a HopLimit TLV is part of the          original Interest message. If such 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: </t>          <ol spacing="normal" type="1">    <li>The <tt>Type</tt> field of the outermost            MessageType TLV is removed.</li>            <li>The Name TLV is compressed according to <xref    format="default"/>. For this, all    NameComponents are expected to be of type GenericNameComponent with a length            greater than 0. An ImplicitSha256DigestComponent or            ParametersSha256DigestComponent <bcp14>MAY</bcp14> appear at the end of the            name. In any other case, the message <bcp14>MUST</bcp14> be sent            uncompressed.</li>            <li>The Nonce TLV and InterestLifetime TLV are moved to            the end of the compressed as illustrated in            <xref format="default"/>.  The            InterestLifetime is encoded as described in <xref    format="default"/>.  On            decompression, this encoding may yield an that is smaller than the original            value.</li>            <li>The Type and Length fields of Nonce TLV, HopLimit and            InterestLifetime TLV are elided. The Nonce value has a length of            4 and the HopLimit value has a length of 1 byte. The            compressed InterestLifetime (<xref    format="default"/>) has a            length of 1 byte. The presence of a Nonce and InterestLifetime TLV is            deduced from the remaining length to parse.            A remaining length of <tt>1</tt> indicates the            presence of an a length of <tt>4</tt> indicates            the presence of a nonce, and a length of <tt>5</tt> indicates            the presence of both TLVs.</li>          </ol>          <t>The compressed NDN LoWPAN Interest message is visualized in <xref format="default"/>.</t>          <figure anchor="fig.ndn.int.newformat">            <name>Compression of NDN LoWPAN Interest Message</name><artwork align="center" name="" type="" alt=""><![CDATA[T = Type, L = Length, V = ValueLc = 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 format="default"/>.</t>          <figure anchor="fig.ndn.intcompr">            <name>Dispatch for NDN Interest<artwork 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 | 0 |+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+]]></artwork>          </figure>          <dl newline="true" spacing="normal" indent="4">            <dt>PFX: CanBePrefix TLV</dt>            <dd>              <dl newline="false" spacing="normal" indent="4">                <dt>0:</dt>                <dd>The uncompressed message does not include a                  CanBePrefix TLV.</dd>                <dt>1:</dt>                <dd>The uncompressed message does include a                  CanBePrefix TLV and is removed from the compressed                  message.</dd>              </dl>            </dd>            <dt>FRE: MustBeFresh TLV</dt>            <dd>              <dl newline="false" spacing="normal" indent="4">                <dt>0:</dt>                <dd>The uncompressed message does not include a                  MustBeFresh TLV.</dd>                <dt>1:</dt>                <dd>The uncompressed message does include a                  MustBeFresh TLV and is removed from the compressed                  message.</dd>              </dl>            </dd>            <dt>FWD: ForwardingHint TLV</dt>            <dd>              <dl newline="false" spacing="normal" indent="4">                <dt>0:</dt>                <dd>The uncompressed message does not include a                  ForwardingHint 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 format="default"/>. If any name is not                  compressible, the message <bcp14>MUST</bcp14> be sent uncompressed.</dd>              </dl>            </dd>            <dt>APM: ApplicationParameters TLV</dt>            <dd>              <dl newline="false" spacing="normal" indent="4">                <dt>0:</dt>                <dd>The uncompressed message does not include                  an ApplicationParameters TLV.</dd>                <dt>1:</dt>                <dd>The uncompressed message does include an                  ApplicationParameters TLV. The Type field is removed from                  the compressed message.</dd>              </dl>            </dd>            <dt>DIG: ImplicitSha256DigestComponent 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.</dd>                <dt>1:</dt>                <dd>The name does include an                  ImplicitSha256DigestComponent as the last TLV. The Type and                  Length fields are omitted.</dd>              </dl>            </dd>            <dt>RSV: Reserved</dt>            <dd>Must be set to 0.</dd>          </dl>        </section>        <section anchor="sec.ndn.interest.ext0" numbered="true" toc="default">          <name>Dispatch Extension</name>          <t>The <tt>EXT_0</tt> byte follows the          description in <xref format="default"/> and is illustrated          in <xref format="default"/>.</t>          <figure anchor="fig.ndn.interest.ext0">            <name>EXT_0<artwork align="center" name="" type="" alt=""><![CDATA[  0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+|  NCS  |        RSV        |EXT|+---+---+---+---+---+---+---+---+]]></artwork>          </figure>          <dl newline="true" spacing="normal" indent="4">            <dt>NCS: Name Compression 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 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.</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>A further extension byte follows                  immediately.</dd>              </dl>            </dd>          </dl>        </section>      </section>      <section numbered="true" toc="default">        <name>Data Messages</name>        <section numbered="true" toc="default">          <name>Uncompressed Data Messages</name>          <t>An uncompressed Data message uses the base dispatch          format and sets the C P to <tt>0</tt> and the M flag          to <tt>1</tt> (<xref format="default"/>).  The Data message is          handed to the NDN network stack without modifications.</t>          <figure anchor="fig.ndn.data.uncompr">            <name>Dispatch for NDN Data<artwork 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 numbered="true" toc="default">          <name>Compressed Data Messages</name>          <t>The compressed Data message uses the extended dispatch          format (<xref format="default"/>) and sets the C M flags to <tt>1</tt>. The          P flag is set to <tt>0</tt>. If a Data          message contains TLVs that are not mentioned in the          following compression rules, then this message <bcp14>MUST</bcp14> be sent          uncompressed.</t>          <t>By default, the Data message is compressed with the following          base rule set: </t>          <ol spacing="normal" type="1">    <li>The <tt>Type</tt> field of the outermost              MessageType TLV is removed.</li>            <li>The Name TLV is compressed according to <xref format="default"/>. For this, all NameComponents              are expected to be of type GenericNameComponent and to have a              length greater than 0. In any other case, the message <bcp14>MUST</bcp14> be              sent uncompressed.</li>            <li>The MetaInfo TLV Type and Length fields are elided from the              compressed Data message.</li>            <li>The FreshnessPeriod TLV <bcp14>MUST</bcp14> be moved to the end of the              compressed Data message. Type and              Length fields are and the value is encoded as described              in <xref format="default"/> as a 1-byte      time-code. If the freshness period is not              a valid time-value, then the message <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 length to parse.</li>            <li>The Type fields of the SignatureInfo TLV, SignatureType              and SignatureValue TLV are removed.</li>          </ol>          <t>The compressed NDN LoWPAN Data message is visualized in <xref format="default"/>.</t>          <figure anchor="fig.ndn.data.newformat">            <name>Compression of NDN LoWPAN Data Message</name><artwork align="center" name="" type="" alt=""><![CDATA[T = Type, L = Length, V = ValueLc = Compressed Length, Vc = Compressed Value: = optional field, | = mandatory field+---------+---------+                 +---------+|  Msg T  |  Msg L  |                 |  Msg Lc |+---------+---------+---------+       +---------+| Name T  | Name L  | Name V  |       | Name Vc |+---------+---------+---------+       +---------+---------+: Meta T  : Meta L  :                 : CTyp Lc : CType V :+---------+---------+---------+       +---------+---------+: CTyp T  : CTyp L  : CTyp V  :       : FBID V  :+---------+---------+---------+  ==>  +---------+---------+: FrPr T  : FrPr L  : FrPr V  :       : CONT Lc : CONT V  :+---------+---------+---------+       +---------+---------+: FBID T  : FBID L  : FBID V  :       |  Sig Lc |+---------+---------+---------+       +---------+---------+: CONT T  : CONT L  : CONT V  :       | SInf Lc | SInf Vc |+---------+---------+---------+       +---------+---------+|  Sig T  |  Sig L  |                 | SVal Lc | SVal Vc |+---------+---------+---------+       +---------+---------+| SInf T  | SInf L  | SInf V  |       : FrPr Vc :+---------+---------+---------+       +---------+| SVal T  | SVal L  | SVal V  |+---------+---------+---------+]]></artwork>          </figure>          <t>Further TLV compression is indicated by the ICN LoWPAN dispatch          in <xref format="default"/>.</t>          <figure anchor="fig.ndn.datacompr">            <name>Dispatch for NDN Data<artwork 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 |+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+]]></artwork>          </figure>          <dl newline="true" spacing="normal" indent="4">            <dt>FBI: FinalBlockId TLV</dt>            <dd>              <dl newline="false" spacing="normal" indent="4">                <dt>0:</dt>                <dd>The uncompressed message does not include a                  FinalBlockId TLV.</dd>                <dt>1:</dt>                <dd>The uncompressed message does include a and it is encoded according to <xref  format="default"/>. If the FinalBlockId  TLV is not compressible, then the message <bcp14>MUST</bcp14> be sent                  uncompressed.</dd>              </dl>            </dd>            <dt>CON: ContentType TLV</dt>            <dd>              <dl newline="false" spacing="normal" indent="4">                <dt>0:</dt>                <dd>The uncompressed message does not include a                  ContentType TLV.</dd>                <dt>1:</dt>                <dd>The uncompressed message does include a                  ContentType TLV. The Type field is removed from the                  compressed message.</dd>              </dl>            </dd>            <dt>KLO: KeyLocator 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  format="default"/>. If the  name is not compressible, then the message  <bcp14>MUST</bcp14> be sent 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.</dd>              </dl>            </dd>            <dt>RSV: Reserved</dt>            <dd>Must be set to 0.</dd>          </dl>        </section>        <section anchor="sec.ndn.data.ext0" numbered="true" toc="default">          <name>Dispatch Extension</name>          <t>The <tt>EXT_0</tt> byte follows the          description in <xref format="default"/> and is illustrated          in <xref format="default"/>.</t>          <figure anchor="fig.ndn.data.ext0">            <name>EXT_0<artwork align="center" name="" type="" alt=""><![CDATA[  0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+|  NCS  |        RSV        |EXT|+---+---+---+---+---+---+---+---+]]></artwork>          </figure>          <dl newline="true" spacing="normal" indent="4">            <dt>NCS: Name Compression 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 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.</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>A further extension byte follows                  immediately.</dd>              </dl>            </dd>          </dl>        </section>      </section>    </section>    <section anchor="sec.ccnx" numbered="true" toc="default"> Message Encoding for CCNx</name>      <section numbered="true" toc="default">        <name>TLV Encoding</name>        <t>The generic CCNx TLV encoding is described in <xrefformat="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 moreencoding described in <xref format="default"/>. NDN and CCNx use the same compressed format for writing        TLVs.</t>      </section>      <section numbered="true" toc="default">        <name>Name TLV Compression</name>        <t>Name TLVs are compressed using the scheme already defined in <xref format="default"/> for NDN. If a Name TLV contains        T_IPID, T_APP, or organizational TLVs, then the name remains        uncompressed.</t>      </section>      <section numbered="true" toc="default">        <name>Interest Messages</name>        <section numbered="true" toc="default">          <name>Uncompressed Interest Messages</name>          <t>An uncompressed Interest message uses the base dispatch format          (see <xref format="default"/>) and sets the C M to <tt>0</tt>.          The P flag is set to <tt>1</tt> (<xref format="default"/>).          The Interest message is handed to the CCNx network stack without modifications.</t>          <figure anchor="fig.ccnx.int.uncompr">            <name>Dispatch for CCNx Interest<artwork 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" numbered="true" toc="default">          <name>Compressed Interest Messages</name>          <t>The compressed Interest message uses the extended dispatch format          (<xref format="default"/>) and sets the C and P flags to <tt>1</tt>. The M flag is set to <tt>0</tt>.          If an Interest message contains TLVs that are not mentioned in the          following compression rules, then this message <bcp14>MUST</bcp14> be sent          uncompressed.</t>          <t>In the default use case, the Interest message is compressed with          the following minimal rule set: </t>          <ol spacing="normal" type="1">    <li>The Type and Length fields of the CCNx Message TLV are elided            and are obtained from the on decompression.</li>          </ol>          <t>The compressed CCNx LoWPAN Interest message is visualized in          <xref format="default"/>.</t>          <figure anchor="fig.ccnx.int.newformat">            <name>Compression of CCNx LoWPAN Interest Message</name><artwork align="center" name="" type="" alt=""><![CDATA[T = Type, L = Length, V = ValueLc = 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 format="default"/>.</t>          <figure anchor="fig.ccnx.intcompr">            <name>Dispatch for CCNx Interest<artwork 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+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+]]></artwork>          </figure>          <dl newline="true" spacing="normal" indent="4">            <dt>FLG: Flags field in the fixed 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.</dd>                <dt>1:</dt>                <dd>The Flags field appears in the fixed header.</dd>              </dl>            </dd>            <dt>PTY: PacketType field in the fixed header</dt>            <dd>              <dl newline="false" spacing="normal" indent="4">                <dt>0:</dt>                <dd>The PacketType field is elided and assumed                  to be <tt>PT_INTEREST</tt>.</dd>                <dt>1:</dt>                <dd>The PacketType field is elided and assumed                  to be <tt>PT_RETURN</tt>.</dd>              </dl>            </dd>            <dt>HPL: HopLimit field in the fixed header</dt>            <dd>              <dl newline="false" spacing="normal" indent="4">                <dt>0:</dt>                <dd>The HopLimit field appears in the fixed header.</dd>                <dt>1:</dt>                <dd>The HopLimit field is elided and assumed to                  be <tt>1</tt>.</dd>              </dl>            </dd>            <dt>FRS: Reserved field in the fixed header</dt>            <dd>              <dl newline="false" spacing="normal" indent="4">                <dt>0:</dt>                <dd>The Reserved field appears in the fixed header.</dd>                <dt>1:</dt>                <dd>The Reserved field is elided and assumed to                  be <tt>0</tt>.</dd>              </dl>            </dd>            <dt>PAY: Optional Payload TLV</dt>            <dd>              <dl newline="false" spacing="normal" indent="4">                <dt>0:</dt>                <dd>The Payload TLV is absent.</dd>                <dt>1:</dt>                <dd>The Payload TLV is and the                  field is elided.</dd>              </dl>            </dd>            <dt>ILT: Optional InterestLifetime TLV</dt>            <dd>      <t>See <xref format="default"/> for further details                  on the ordering of hop-by-hop TLVs.</t>              <dl newline="false" spacing="normal" indent="4">                <dt>0:</dt>                <dd>No InterestLifetime TLV is present in the                  Interest 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 format="default"/>. The and fields are elided.</dd>              </dl>            </dd>            <dt>MGH: Optional MessageHash TLV</dt>            <dd>                <t>See <xref format="default"/> for furtherdetails 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 <bcp14>MUST</bcp14> be sent                  uncompressed.</t>              <dl newline="false" spacing="normal" indent="4">                <dt>0:</dt>                <dd>The MessageHash TLV is absent.</dd>                <dt>1:</dt>                <dd>A T_SHA-256 TLV is and the fields are removed. The field is                  assumed to represent 32 bytes. The outer Message Hash TLV                  is omitted.</dd>              </dl>            </dd>            <dt>KIR: Optional KeyIdRestriction TLV</dt>            <dd>                <t>This TLV is expected to contain a T_SHA-256 TLV. If                  another hash is contained, then the Interest <bcp14>MUST</bcp14> be sent                  uncompressed.</t>              <dl newline="false" spacing="normal" indent="4">                <dt>0:</dt>                <dd>The KeyIdRestriction TLV is absent.</dd>                <dt>1:</dt>                <dd>A T_SHA-256 TLV is and the fields are removed. The field is                  assumed to represent 32 bytes. The outer KeyIdRestriction                  TLV is omitted.</dd>              </dl>            </dd>            <dt>CHR: Optional ContentObjectHashRestriction TLV</dt>            <dd>                <t>This TLV is expected to contain a T_SHA-256 TLV. If                  another hash is contained, then the Interest <bcp14>MUST</bcp14> be sent                  uncompressed.</t>              <dl newline="false" spacing="normal" indent="4">                <dt>0:</dt>                <dd>The ContentObjectHashRestriction TLV is                  absent.</dd>                <dt>1:</dt>                <dd>A T_SHA-256 TLV is and the fields areremoved. The field is assumed to represent 32 bytes. The outer                ContentObjectHashRestriction TLV is omitted.</dd>              </dl>            </dd>            <dt>VAL: Optional ValidationAlgorithm and ValidationPayload    TLVs</dt>            <dd>              <dl newline="false" spacing="normal" indent="4">                <dt>0:</dt>                <dd>No TLVs are present in                  the Interest message.</dd>                <dt>1:</dt> TLVs are present in the                Interest message. An additional byte follows immediately                that handles TLV compressions and is                described in <xrefformat="default"/>.</dd>              </dl>            </dd>          </dl>          <section anchor="sec.ccnxhbhint" toc="exclude" numbered="true">            <name>Hop-By-Hop Header TLVs Compression</name> TLVs are unordered. For an Interest message,            two optional TLVs are defined in <xref       format="default"/>, but several more can be defined in    specifications. For the compression specified in the            previous section, the TLVs are ordered as follows:            </t>            <ol spacing="normal" type="1"> TLV</li>              <li>Message Hash TLV</li>            </ol> Other TLVs than those two remain uncompressed   in the encoded message and they appear in the same order as in the   original message, but after the TLV and Message Hash TLV.</t>          </section>          <section anchor="sec.ccnx.intval" toc="exclude" numbered="true">            <name>Validation</name>            <figure anchor="fig.ccnx.dispatchintval">              <name>Dispatch for Validations</name><artwork align="center" name="" type="" alt=""><![CDATA[0       1       2       3       4       5       6       7       8+-------+-------+-------+-------+-------+-------+-------+-------+|         ValidationAlg         |     KeyID     |      RSV      |+-------+-------+-------+-------+-------+-------+-------+-------+]]></artwork>            </figure>            <dl newline="true" spacing="normal" indent="4"> Optional ValidationAlgorithm TLV</dt>              <dd>                <dl newline="false" spacing="normal" indent="8">                  <dt>0000:</dt>                  <dd>An uncompressed ValidationAlgorithm                    TLV is included.</dd>                  <dt>0001:</dt>                  <dd>A T_CRC32C ValidationAlgorithm TLV is                    assumed, but no ValidationAlgorithm TLV is included.</dd>                  <dt>0010:</dt>                  <dd>A T_CRC32C ValidationAlgorithm TLV is                    assumed, but no ValidationAlgorithm TLV is included.                    Additionally, a Sigtime TLV is inlined without a and                    a field.</dd>                  <dt>0011:</dt>                  <dd>A T_HMAC-SHA256 ValidationAlgorithm                    TLV is assumed, but no ValidationAlgorithm TLV is                    included.</dd>                  <dt>0100:</dt>                  <dd>A T_HMAC-SHA256 ValidationAlgorithm                    TLV is assumed, but no ValidationAlgorithm TLV is included.                    Additionally, a Sigtime TLV is inlined without a and                    a 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</dt>              <dd>                <dl newline="false" spacing="normal" indent="4">                  <dt>00:</dt>                  <dd>The TLV is absent.</dd>                  <dt>01:</dt>                  <dd>The TLV is present and                    uncompressed.</dd>                  <dt>10:</dt>                  <dd>A T_SHA-256 TLV is and the fields are removed. The                    field is assumed to represent 32 bytes. The outer                    TLV is omitted.</dd>                  <dt>11:</dt>                  <dd>A T_SHA-512 TLV is and the fields are removed. The                    field is assumed to represent 64 bytes. The outer                    TLV is omitted.</dd>                </dl>              </dd>              <dt>RSV: Reserved</dt>              <dd>Must be set to 0.</dd>            </dl>            <t>The ValidationPayload TLV is present if the ValidationAlgorithm            TLV is present. The field is omitted.</t>          </section>        </section>        <section anchor="sec.ccnx.interest.ext0" numbered="true" toc="default">          <name>Dispatch Extension</name>          <t>The <tt>EXT_0</tt> byte follows the          description in <xref format="default"/> and is illustrated          in <xref format="default"/>.</t>          <figure anchor="fig.ccnx.interest.ext0">            <name>EXT_0<artwork align="center" name="" type="" alt=""><![CDATA[0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+|  NCS  |        RSV        |EXT|+---+---+---+---+---+---+---+---+]]></artwork>          </figure>          <dl newline="true" spacing="normal" indent="4">            <dt>NCS: Name Compression 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 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.</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>A further extension byte follows                  immediately.</dd>              </dl>            </dd>          </dl>        </section>      </section>      <section numbered="true" toc="default">        <name>Content Objects</name>        <section numbered="true" toc="default">          <name>Uncompressed Content Objects</name>          <t>An uncompressed Content uses the base dispatch format (see          <xref format="default"/>) and sets the C flag to the P and M flags to          <tt>1</tt> (<xref format="default"/>).          The Content is handed to the CCNx network stack without modifications.</t>          <figure anchor="fig.ccnx.data.uncompr">            <name>Dispatch for CCNx Content<artwork 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 numbered="true" toc="default">          <name>Compressed Content Objects</name>          <t>The compressed Content uses the extended dispatch format          (<xref format="default"/>) and sets the C, P, M to <tt>1</tt>. If a Content contains TLVs that are not mentioned in  the following compression          rules, then this message <bcp14>MUST</bcp14> be sent uncompressed.</t>          <t>By default, the Content is compressed with the following          base rule set: </t>          <ol spacing="normal" type="1">    <li>The PacketType field is elided from the            <li>The Type and Length fields of the CCNx Message TLV are elided              and are obtained from the on decompression.</li>          </ol>          <t>The compressed CCNx LoWPAN Data message is visualized in <xref format="default"/>.</t>          <figure anchor="fig.ccnx.data.newformat">            <name>Compression of CCNx LoWPAN Data Message</name><artwork align="center" name="" type="" alt=""><![CDATA[T = Type, L = Length, V = ValueLc = 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 format="default"/>.</t>          <figure anchor="fig.ccnx.datacompr">            <name>Dispatch for CCNx Content<artwork 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 | 1 | 1 PLTYP+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+]]></artwork>          </figure>          <dl newline="true" spacing="normal" indent="4">            <dt>FLG: Flags field in the fixed header</dt>            <dd>See <xref    format="default"/>.</dd>            <dt>FRS: Reserved field in the fixed header</dt>            <dd>See <xref    format="default"/>.</dd>            <dt>PAY: Optional Payload TLV</dt>            <dd>See <xref    format="default"/>.</dd>            <dt>RCT: Optional TLV</dt>            <dd>              <dl newline="false" spacing="normal" indent="4">                <dt>0:</dt>                <dd>The Recommended Cache Time TLV is                  absent.</dd>                <dt>1:</dt>                <dd>The Recommended Cache Time TLV is                  and the fields are elided.</dd>              </dl>            </dd>            <dt>MGH: Optional MessageHash TLV</dt>            <dd>      <t>See <xref 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      <bcp14>MUST</bcp14> be sent uncompressed.</t>  <dl newline="false" spacing="normal" indent="4">                <dt>0:</dt>                <dd>The MessageHash TLV is absent.</dd>                <dt>1:</dt>                <dd>A T_SHA-256 TLV is and the fields are removed. The field is                  assumed to represent 32 bytes. The outer Message Hash TLV                  is omitted.</dd>              </dl>            </dd>            <dt/>            <dd>              <dl newline="true" spacing="normal" indent="4">                <dt>PLTYP: Optional PayloadType TLV</dt>                <dd>                  <dl newline="false" spacing="normal" indent="4">                    <dt>00:</dt>                    <dd>The PayloadType TLV is absent.</dd>                    <dt>01:</dt>                    <dd>The PayloadType TLV is and                      T_PAYLOADTYPE_DATA is assumed.</dd>                    <dt>10:</dt>                    <dd>The PayloadType TLV is and                      T_PAYLOADTYPE_KEY is assumed.</dd>                    <dt>11:</dt>                    <dd>The PayloadType TLV is present and                      uncompressed.</dd>                  </dl>                </dd>              </dl>            </dd>            <dt>EXP: Optional ExpiryTime TLV</dt>            <dd>              <dl newline="false" spacing="normal" indent="4">                <dt>0:</dt>                <dd>The ExpiryTime TLV is absent.</dd>                <dt>1:</dt>                <dd>The ExpiryTime TLV is and the fields are elided.</dd>              </dl>            </dd>            <dt>VAL: Optional ValidationAlgorithm and ValidationPayload    TLVs</dt>            <dd>See              <xref format="default"/>.</dd>            <dt>RSV: Reserved</dt>            <dd>Must be set to 0.</dd>          </dl>          <section anchor="sec.ccnxhbhdata" toc="exclude" numbered="true">            <name>Hop-By-Hop Header TLVs Compression</name> TLVs are unordered. For a Content Object            message, two optional TLVs are defined in    <xref format="default"/>, but several more can be defined in specifications. For the compression specified in the            previous section, the TLVs are ordered as follows:            </t>            <ol spacing="normal" type="1">      <li>Recommended Cache Time TLV</li>              <li>Message Hash TLV</li>            </ol>            <t>Note: Other TLVs than those two remain            uncompressed in the encoded and they appear in the            same order as in the original but after the Recommended Cache Time TLV and Message Hash TLV.</t>          </section>        </section>        <section anchor="sec.ccnx.data.ext0" numbered="true" toc="default">          <name>Dispatch Extension</name>          <t>The <tt>EXT_0</tt> byte follows the          description in <xref format="default"/> and is illustrated          in <xref format="default"/>.</t>          <figure anchor="fig.ccnx.data.ext0">            <name>EXT_0<artwork align="center" name="" type="" alt=""><![CDATA[0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+|  NCS  |        RSV        |EXT|+---+---+---+---+---+---+---+---+]]></artwork>          </figure>          <dl newline="true" spacing="normal" indent="4">            <dt>NCS: Name Compression 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 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.</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>A further extension byte follows                  immediately.</dd>              </dl>            </dd>          </dl>        </section>      </section>    </section>    <section anchor="sec.compressedtime" numbered="true" toc="default">      <name>Compressed Time Encoding</name>      <t>        This document adopts the 8-bit compact time representation for        relative described in <xref section="5" sectionFormat="of" format="default"/> with the constant factor <tt>C</tt> set to <tt>C :=        1/32</tt>.      </t>      <t>        Valid time offsets in CCNx and NDN 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 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 := b := exponent):      </t>      <dl newline="false" spacing="normal">        <dt>Subnormal (b == 0):</dt>        <dd> (0 + a/8) * 2 * C          </dd>        <dt>Normalized (b &gt; 0):</dt>        <dd> (1 + a/8) * * C (see <xref format="default"/>)          </dd>      </dl> configuration allows for the following spacing="compact"> subnormal minimum subnormal subnormal normalized minimum normalized normalized      <t>        The second modification only applies to uncompressible time        offsets that are outside any security envelope. An invalid        time-value <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" numbered="true" toc="default">      <name>Stateful Header 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 context state at all      nodes and omitted from communication. Second, redundancy in a single exchange may be removed from ICN stateful forwarding on a      hop-by-hop and memorized in en-route state tables.</t>      <section anchor="stateful.compression.local" numbered="true" toc="default"> State</name>        <t>A (CID) is a byte that refers to a particular        conceptual context between network devices and <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">          <name>Context<artwork align="center" name="" type="" alt=""><![CDATA[  0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+| X |         ContextID         |+---+---+---+---+---+---+---+---+]]></artwork>        </figure>        <t>The 7-bit ContextID is a unique identifier that        represents contextual state shared between sender and receiver of the        corresponding frame (see <xref format="default"/>).        If the most significant bit indicates the presence of another, subsequent        ContextID byte (see <xref format="default"/>).</t> state shared between senders and receivers is removed from the        compressed packet prior to 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 <bcp14>MUST</bcp14> be silently discarded.</t>      </section>      <section anchor="stateful.compression.en-route" numbered="true" toc="default"> State</name>        <t>In CCNx and NDN, Name TLVs are included in Interest messages, and        they return in messages. Returning Name TLVs either equal the        original Name or 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 format="default"/>) of link-local as shown in <xref format="default"/>.</t>        <figure anchor="fig.hopid">          <name>Context Identifier as<artwork 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 <bcp14>MUST</bcp14> be sent without en-route state        compression until new HopIDs are available. An ICN LoWPAN node that        forwards without replacing the name by a HopID (without en-route        compression) <bcp14>MUST</bcp14> invalidate the HopID by setting all to        zero.</t>        <t>While an Interest is traversing, a forwarder generates an ephemeral        HopID that is tied to a entry. Each HopID<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 format="default"/>). </t>        <figure anchor="fig.enroute-a">          <name>Setting<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>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 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 format="default"/>). </t>        <figure anchor="fig.enroute-b">          <name>Eliding Name TLVs<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>It should be noted that each forwarder of an Interest in an ICN        LoWPAN network can individually decide whether to participate in        en-route compression or not. However, an ICN LoWPAN node <bcp14>SHOULD</bcp14> use        en-route compression whenever the stateful compression mechanism is        activated.</t>        <t>Note also that the extensions of the PIT data structure are        required only at ICN LoWPAN nodes, while regular NDN/CCNx forwarders        outside of an ICN LoWPAN domain do not need to implement these        extensions.</t>      </section>      <section numbered="true" toc="default">        <name>Integrating Stateful Header Compression</name>        <t>A CID appears whenever the CID flag is set (see <xref format="default"/>). The CID is appended to the last ICN        LoWPAN dispatch as shown in <xref format="default"/>.</t>        <figure anchor="fig.cid.loc">          <name>LoWPAN Encapsulation with ICN LoWPAN and CIDs</name><artwork 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 format="default"/>). This allows to use multiple shared contexts in compressed messages.</t>        <t>The HopID is always included as the very first CID.</t>        <figure anchor="fig.cid.chain">          <name>Chaining of<artwork align="center" name="" type="" alt=""><![CDATA[+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+|1| CID / HopID | --> |1|     CID     | --> |0|     CID     |+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+]]></artwork>        </figure>      </section>    </section>    <section anchor="sec.ndn.constvars" numbered="true" toc="default">      <name>ICN LoWPAN Constants and Variables</name>      <t>This is a summary of all ICN LoWPAN constants and variables. </t>      <dl newline="false" spacing="normal" indent="8">        <dt>DEFAULT_NDN_HOPLIMIT:</dt>        <dd>255</dd>      </dl>    </section>    <section anchor="implementationnotice" numbered="true" toc="default">      <name>Implementation Report and Guidance</name>      <t>The ICN LoWPAN scheme defined in this document has been implemented as      an extension of the NDN/CCNx software stack <xref format="default"/> in      its IoT version on RIOT <xref format="default"/>. An experimental      evaluation for NDN over ICN with varying configurations has been      performed in <xref format="default"/>.  Energy and      processing time measurements indicate significant energy savings,      amortized costs for processing show no penalties.</t>      <section 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: </t>        <ul spacing="normal">          <li>Signed time offsets per <xref without the need for rounding.</li> state (e.g., prefixes) is such that            long names can be elided from Interest and messages.</li>          <li>Frequently used TLV type numbers for CCNx and NDN stay            in the lower range (&lt; 255).</li>        </ul>        <t>          Name components are of type and are limited to a        length of 15 bytes to enable compression for all messages.</t>      </section>      <section numbered="true" toc="default">        <name>Further Experimental 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:        </t>        <ul spacing="normal">          <li>The name compression scheme (<xref format="default"/>) is optimized for short          name components of 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 format="default"/>). As a preliminary          analysis, <xref format="default"/> investigates the          effectiveness of the proposed compression scheme with URLs          obtained from the WWW. Studies on <xref format="default"/> can offer additional insights          on naming schemes in the IoT.</li>          <li>The fragmentation scheme (<xref format="default"/>) inherited from 6LoWPAN allows          for a transparent, hop-wise reassembly of CCNx or NDN          packets. Fragment forwarding <xref format="default"/> with selective          fragment recovery <xref format="default"/> can improve the          end-to-end latency and while it reduces buffer          requirements on forwarders. Initial evaluations show that a naive integration of          these upcoming fragmentation features into ICN LoWPAN          renders the hop-wise content replication inoperative, since          Interest and messages are reassembled end-to-end. More          deployment experiences are necessary to gauge the          feasibility of different fragmentation schemes in ICN          LoWPAN.          </li> state (<xref 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.</li>          <li>The distribution and synchronization of contextual state          can potentially be adopted from <xref section="7.2" sectionFormat="of" 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.</li>          <li>The stateful en-route compression (<xref 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 of memory-constrained devices. This number          can serve as an and determines whether the HopID          length needs to be resized to fit more HopIDs the cost of          additional header 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 the complexity of implementing ICN          LoWPAN for constrained devices, as well as on maintaining          interoperability with other implementations.</li>        </ul>      </section>    </section>    <section anchor="security.considerations" numbered="true" toc="default">      <name>Security Considerations</name>      <t>Main memory is typically a scarce resource of constrained networked      devices. as described in this 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 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 should be deployed. IEEE 802.15.4, e.g., provides capabilities to protect frames and restrict them to a point-to-point or a group of devices.</t>    </section>    <section anchor="iana" numbered="true" toc="default">      <name>IANA Considerations</name>      <section numbered="true" toc="default"> the 6LoWPAN Dispatch Type Field Registry</name>        <t>IANA has assigned dispatch values the Type <xref format="default"/>        <xref format="default"/> represents updates to the registry.</t>        <table anchor="tab.iana.dispatches" align="center">          <name>Dispatch for NDN and CCNx with          <thead>            <tr>              <th align="center">Bit Pattern</th>              <th align="center">Page</th>              <th align="left">Header Type</th>            </tr>          </thead>          <tbody>            <tr>              <td align="center">00 000000</td>              <td              <td align="left">Uncompressed NDN Interest messages</td>            </tr>            <tr>              <td align="center">00              <td              <td NDN messages</td>            </tr>            <tr>              <td              <td              <td align="left">Uncompressed messages</td>            </tr>            <tr>              <td              <td              <td messages</td>            </tr>            <tr>              <td              <td              <td Interest messages</td>            </tr>            <tr>              <td              <td              <td align="left">Compressed messages</td>            </tr>            <tr>              <td              <td              <td CCNx messages</td>            </tr>            <tr>              <td              <td              <td align="left">Compressed CCNx Content Object messages</td>            </tr>          </tbody>        </table>      </section>    </section>  </middle>  <back><displayreference 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.4944.xml"/>        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5497.xml"/>        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6256.xml"/>        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml"/>        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml"/><!-- [rfced] The              "IEEE-->        <reference anchor="ieee802.15.4">          <front>            <title>IEEE Standard for        <reference anchor="IEEE.754.2019">          <front> for Floating-Point Arithmetic</title>          </front>        </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"/>        <!--<?rfc include="reference.RFC.7400"?>-->        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8025.xml"/>        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8609.xml"/>        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8569.xml"/>        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8930.xml"/>        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8931.xml"/><!-- [I-D.irtf-icnrg-flic] IESG state  --><!-- [rfced]  Please review.-->        <reference anchor="CCN-LITE">          <front>            <title>CCN-lite: A lightweight CCNx and NDN implementation</title>            <author/>          </front>        </reference>        <reference anchor="RIOT">          <front>            <title>RIOT: Open Source Operating System for Embedded          Devices in the IoT</title>            <author initials="E." surname="Baccelli">              <organization>INRIA</organization>            </author>            <author initials="C."              <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."              <organization>FU Berlin</organization>            </author>            <date month="December" year="2018"/>          </front> Internet of Things 5, No. 6, p.        </reference>        <reference anchor="NDN-EXP1">          <front>            <title>Information in the IoT: with          NDN in the            <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."              <organization>FU Berlin</organization>            </author>            <date month="September" year="2014"/>          </front> of 1st ACM Conf. on Information-Centric Networking DL, pp.        </reference>        <reference anchor="NDN-EXP2">          <front>            <title>NDN, CoAP, and MQTT: in the          IoT</title>            <author initials="C."              <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."              <organization>FU Berlin</organization>            </author>            <date month="September" year="2018"/>          </front> of 5th ACM Conf. on Information-Centric Networking DL, pp.        </reference> need for a name to MAC address mapping in NDN: towards            quantifying the resource            <author initials="P." surname="Kietzmann">              <organization>HAW Hamburg</organization>            </author>            <author initials="C."              <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."              <organization>FU Berlin</organization>            </author>            <date month="September" year="2017"/>          </front> of 4th ACM Conf. on Information-Centric Networking DL, pp.        </reference>        <reference anchor="SFR-ICNLOWPAN">          <front>            <title>Connecting the Dots: Selective Fragment Recovery in          ICNLoWPAN</title>            <author initials="M." surname="Lenders">              <organization>FU Berlin</organization>            </author>            <author initials="C."              <organization>HAW Hamburg</organization>            </author>            <author initials="TC." surname="Schmidt">              <organization>HAW Hamburg</organization>            </author>            <author initials="M."              <organization>FU Berlin</organization>            </author>            <date month="September" year="2020"/>          </front> of 7th ACM Conf. on Information-Centric Networking DL, pp.        </reference>        <reference anchor="NDN">          <front>            <title>Networking            <author initials="V." surname="Jacobson"/>            <author initials="D." surname="Smetters"/>            <author initials="J." surname="Thornton"/>            <author initials="M." surname="Plass"/>            <date year="2009"/>          </front> Int. Conf. on emerging Networking Experiments and        </reference>        <reference anchor="NDN-PACKET-SPEC">          <front>            <title>NDN Packet Format Specification</title>            <author/>          </front>        </reference>        <reference anchor="TLV-ENC-802.15.4">          <front>            <title>CCN and NDN TLV encodings in 802.15.4 packets</title>          </front>        </reference>        <reference anchor="WIRE-FORMAT-CONSID">          <front>            <title>CCN/NDN Protocol Wire Format and Functionality          Considerations</title>          </front>        </reference>        <reference anchor="ICNLOWPAN">          <front>            <title>ICNLoWPAN Named-Data Networking in Low Power IoT          Networks</title>            <author initials="C."              <organization>HAW Hamburg</organization>            </author>            <author initials="P." surname="Kietzmann">              <organization>HAW Hamburg</organization>            </author>            <author initials="TC." surname="Schmidt">              <organization>HAW Hamburg</organization>            </author>            <author initials="M."              <organization>FU Berlin</organization>            </author>            <date month="May" year="2019"/>          </front> of Networking        </reference>      </references>    </references>    <section anchor="sec.EstimatedSizeReduction" numbered="true" toc="default">      <name>Estimated Size Reduction</name>      <t>In the a theoretical evaluation is given to estimate the      gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages.</t>      <t>We assume that <tt>n</tt> is the number of name <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      <tt>clen</tt>. The lengths of TLV components      specific to the CCNx or NDN encoding and outlined below.</t>      <section numbered="true" toc="default">        <name>NDN</name>        <t>The NDN TLV encoding has variable-sized TLV fields. For simplicity,        the form of each TLV component is assumed. A typical TLV        component therefore is of size 2 field + field) + the        actual value.</t>        <section numbered="true" toc="default">          <name>Interest</name>          <t><xref format="default"/> depicts the          size requirements for a basic, uncompressed NDN Interest containing          a CanBePrefix TLV, a MustBeFresh TLV, InterestLifetime TLV set to          4 and a HopLimit TLV set to 6. Numbers below represent the          amount of bytes.</t>          <figure anchor="fig.Size.NDN.interest.uncompressed">            <name>Estimated of an NDN Interest</name><artwork 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 format="default"/> depicts the          size requirements after compression.</t>          <figure anchor="fig.Size.NDN.interest.compressed">            <name>Estimated of a NDN Interest</name><artwork align="center" name="" type="" alt=""><![CDATA[------------------------------------,Dispatch Page Switch    = 1         |NDN 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 11 + 1.5n bytes.</t>          <t>For the name <tt>/DE/HH/HAW/BT7</tt>, the          total size gain is 17 bytes, which is 43% of the uncompressed          packet.</t>        </section>        <section numbered="true" toc="default">          <name>Data</name>          <t><xref format="default"/> depicts the size          requirements for a basic, uncompressed NDN Data containing a          FreshnessPeriod as MetaInfo. A FreshnessPeriod of 1 minute is and the value is encoded using 1 byte. An HMACWithSha256 is          assumed as signature. The key locator is assumed to contain a Name          TLV of length klen.</t>          <figure anchor="fig.Size.NDN.Data.uncompressed">            <name>Estimated of an NDN Data</name><artwork 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 format="default"/> depicts the size          requirements for the compressed version of the above Data          packet.</t>          <figure anchor="fig.Size.NDN.Data.compressed">            <name>Estimated of a NDN Data</name><artwork 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 + klenContent                 = 1 + clen  |KeyLocator              = 1 + klen  |DigestSha256            = 32        |FreshnessPeriod         = 1         |------------------------------------']]></artwork>          </figure>          <t>The size difference 15 + 1.5n bytes.</t>          <t>For the name <tt>/DE/HH/HAW/BT7</tt>, the          total size gain is 21 bytes.</t>        </section>      </section>      <section numbered="true" toc="default">        <name>CCNx</name>        <t>The CCNx TLV encoding defines a 2-byte encoding for and fields, summing up to 4 bytes in total without a value.</t>        <section numbered="true" toc="default">          <name>Interest</name>          <t><xref format="default"/> depicts  the size requirements for a basic, uncompressed CCNx Interest. No TLVs are included, the protocol version is assumed to be and the 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">            <name>Estimated of an CCNx Interest</name><artwork 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 format="default"/>  depicts the size requirements after compression.</t>          <figure anchor="fig.Size.CCNx.interest.compressed">            <name>Estimated of a CCNx Interest</name><artwork 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 18 + 3.5n bytes.</t>          <t>For the name <tt>/DE/HH/HAW/BT7</tt>, the size          is reduced by 53 bytes, which is 53% of the uncompressed          packet.</t>        </section>        <section numbered="true" toc="default">          <name>Content Object</name>          <t><xref 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 and a hash of the shared secret key. In the fixed          header, the protocol version is assumed to be 1 and the          field is assumed to be 0</t>          <figure anchor="fig.Size.CCNx.Data.uncompressed">            <name>Estimated of an CCNx Content Object</name><artwork 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        |            |            |    SignatureTime      |            |  ---------------------'            |  ValidationPayload     = 36        |------------------------------------']]></artwork>          </figure>          <t><xref format="default"/>  depicts the size          requirements for a basic, compressed CCNx Data.</t>          <figure anchor="fig.Size.CCNx.Data.compressed">            <name>Estimated of a CCNx Data Object</name><artwork 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  35 + 3.5n bytes.</t>          <t>For the name <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="false" toc="default">      <name>Acknowledgments</name>      <t>This work was stimulated by fruitful discussions in the ICNRG      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) The      hop-wise stateful name compression was brought up in a discussion by which is gratefully acknowledged.      Larger parts of this work      are inspired by <xref format="default"/> and      <xref format="default"/>.      Special goes to as well as      as their previous work in <xref format="default"/>      and <xref format="default"/> provided a good base for our      discussions on stateless header compression mechanisms.      Many thanks also to 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>