Movatterモバイル変換

<?xml version="1.0"<!DOCTYPE rfc<rfc ipr="trust200902"  <front>    <title abbrev="ICN Adaptation to LoWPANs">ICN    Adaptation to LoWPAN Networks (ICN LoWPAN)</title>    <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>          <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>          <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>          <country>Switzerland</country>        </postal>        <email>christian.tschudin@unibas.ch</email>      </address>    </author>    <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"      <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 Recent studies <xref 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 and CCNx <xref <xref      <t>The IEEE 802.15.4 <xref link layer is      used in low-power and lossy networks (see in      <xref 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 illustrate a reduced message overhead, a shortened      message airtime, and an overall decline in power consumption for typical      Class 2 devices compared to uncompressed ICN messages.</t>      <t>In a typical IoT scenario (see <xref        </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 Stub<artwork  |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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this   document are to be interpreted as described in RFC 2119   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 <xref and <xref for ICN entities.</t>      <t>The following terms are used in the document and defined as follows: Networking over Wireless Personal Area and Lossy Data for 4 time offset measured in 8-bit encoded    </section>    <section anchor="ICNLoWPAN" of ICN      <section        <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        <figure LoWPAN for IEEE<artwork      Device 1                                         Device 2,------------------,           Router            ,------------------,|  Application   . |     __________________      | ,-> Application  ||----------------|-|    |    NDN / CCNx    |     |-|----------------||  NDN / CCNx    | |    | ,--------------, |     | |    NDN / CCNx  ||----------------|-|    |-|--------------|-|     |-|----------------||  ICN LoWPAN    | |    | |  ICN LoWPAN  | |     | |    ICN LoWPAN  ||----------------|-|    |-|--------------|-|     |-|----------------||    | |    | |  | |     | |  |'----------------|-'    '-|--------------|-'     '-|----------------'                 '--------'              '---------']]></artwork>        </figure>        <t><xref of this document defines the        convergence layer for IEEE 802.15.4.</t>      </section>      <section Header        <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 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 a the of<artworkUncompressed:   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 <xref defines the stateless        TLV compression for CCNx.</t>        <t>The extensibility of this compression is described in <xref and allows future documents to update the        compression rules outlined in this      </section>      <section Header        <t>ICN LoWPAN further employs two stateful compression        schemes for packet size which are defined in <xref 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 The hop-wise name compression        "en-route" is specified in <xref      </section>    </section>    <section anchor="sec.lowpan_adaptation" 802.15.4      <section anchor="sec.lowpan_encap"        <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        Multiple LoWPAN encapsulation headers can precede the actual        and each encapsulation header is identified by a dispatch type.</t>        <t><xref further specifies dispatch toswitch between different contexts. When a LoWPAN parser encounters a LoWPAN encapsulation header, all        following encapsulation headers are interpreted by using a dispatch as specified by the        header. 0 and 1 are reserved for 6LoWPAN. This document uses for ICN LoWPAN.</t>        <t>The base dispatch format (<xref isused and extended by CCNx and NDN in <xref and<xref        <figure for ICN<artwork  0   1   2   ...| | P | M |]]></artwork>        </figure> included protocol is included protocol is Message payload contains an Interest payload contains a Data        <t>ICN LoWPAN frames with compressed CCNx and NDN messages (C=1) use        the extended dispatch format in <xref        <figure for ICN<artwork  0   1   2   3      ...| | P | M   |CID|EXT|]]></artwork>        </figure> Context context identifiers are identifier(s) are present (see <xref extension bytes are byte(s) are present (see <xref        <t>The encapsulation format for ICN LoWPAN is displayed in <xref        <figure Encapsulation with<artwork+------...------+------...-----+--------+-------...-------+-----...| IEEE 802.15.4 | RFC4944 Disp.|  Page  | ICN LoWPAN Disp.| Payl. /+------...------+------...-----+--------+-------...-------+-----...]]></artwork>        </figure> IEEE 802.15.4 additional dispatches            defined in <xref for ICN as defined in <xref and <xref actual (un-)compressed CCNx or NDN        <section anchor="sec.dispatch.ext"          <t>Extension bytes allow for the extensibility of the initial          compression rule set. The base format for an extension byte is          depicted in <xref          <figure for<artwork  0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+| - | - | - | - | - | - | - |EXT|+---+---+---+---+---+---+---+---+]]></artwork>          </figure> other extension byte further extension byte          <t>Extension bytes are numbered according to their order. Future          documents follow the naming scheme EXT_1,          when updating or referring to a specific dispatch extension byte.          Amendments that require an exchange of configurational parameters          between devices use manifests to encode structured data in a          well-defined format, e.g., outlined in <xref        </section>      </section>      <section anchor="sec.Fragmentation"        <t>Small payload sizes in the LoWPAN require fragmentation for various        network layers. Therefore, <xref        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        <t>The LoWPAN header can encapsulate other dispatch        headers. The order of dispatch types is defined in <xref <xref shows the        fragmentation scheme. The reassembled ICN LoWPAN frame does not        contain any fragmentation headers and is depicted in <xref        <figure+------...------+----...----+--------+------...-------+--------...| 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 ICN LoWPAN<artwork+------...------+--------+------...-------+--------...| IEEE 802.15.4 |  Page  |   ICN LoWPAN   | Payload  /+------...------+--------+------...-------+--------...]]></artwork>        </figure>        <t>The 6LoWPAN Fragment Forwarding <xref 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" Message Encoding for      <section anchor="sec.tlvencoding"        <t>The NDN packet format consists of TLV fields using the TLV encoding        that is described in <xref 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        then that number is encoded into the actual or field. If        the number is greater or equals and        fits into 2 bytes, then the or field is set to 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 and the        number is encoded in the subsequent 4 bytes in network byte order.        For larger numbers, the or field is set to 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 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> anchor="tab.sdnvperformance" TLV to 0x00 - 0x3F 0x40 0x80 0x00 0x01 0x00 0x80 - 0x00 0x1F 0xFF 0xFF 0x00 0x20 0x00 0x80 0x80 - 0x0F 0xFF 0xFF 0xFF 0xFF 0x1F 0x00 0x00 0x80 0x80 0x80 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x80 0x80 0x80 - 0x00 0x00 0x00 0x07 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x80 0x80 0x80 0x80        <t>          <xref 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" TLV        <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 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        <figure TLV for<artwork                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 Interest          <t>An uncompressed Interest message uses the base dispatch format          (see <xref and sets the and M to (<xref          The Interest message is handed to the NDN network stack without modifications.</t>          <figure for NDN Interest<artwork  0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |+---+---+---+---+---+---+---+---+]]></artwork>          </figure>        </section>        <section Interest          <t>The compressed Interest message uses the extended dispatch format          (<xref and sets the C flag to the P and M to          If an Interest message contains TLVs that are not mentioned in the          following compression rules, then this message 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: field of the outermost            MessageType TLV is Name TLV is compressed according to <xref For this, all    NameComponents are expected to be of type GenericNameComponent with a length            greater than 0. An ImplicitSha256DigestComponent or            ParametersSha256DigestComponent appear at the end of the            name. In any other case, the message be sent Nonce TLV and InterestLifetime TLV are moved to            the end of the compressed as illustrated in            <xref  The            InterestLifetime is encoded as described in <xref  On            decompression, this encoding may yield an that is smaller than the original 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 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 indicates the            presence of an a length of indicates            the presence of a nonce, and a length of indicates            the presence of both          <t>The compressed NDN LoWPAN Interest message is visualized in <xref          <figure of NDN LoWPAN Interest<artworkT = 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          <figure for NDN Interest<artwork  0                                       1  0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+| | 0 | 0 |+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+]]></artwork>          </figure> CanBePrefix uncompressed message does not include a                  CanBePrefix uncompressed message does include a                  CanBePrefix TLV and is removed from the compressed MustBeFresh uncompressed message does not include a                  MustBeFresh uncompressed message does include a                  MustBeFresh TLV and is removed from the compressed ForwardingHint uncompressed message does not include a                  ForwardingHint 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 If any name is not                  compressible, the message be sent ApplicationParameters uncompressed message does not include                  an ApplicationParameters uncompressed message does include an                  ApplicationParameters TLV. The Type field is removed from                  the compressed ImplicitSha256DigestComponent name does not include an                  ImplicitSha256DigestComponent as the last name does include an                  ImplicitSha256DigestComponent as the last TLV. The Type and                  Length fields are be set to        </section>        <section anchor="sec.ndn.interest.ext0"          <t>The byte follows the          description in <xref and is illustrated          in <xref          <figure  0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+|  NCS  |        RSV        |EXT|+---+---+---+---+---+---+---+---+]]></artwork>          </figure> Name Compression are compressed with the default name                  compression strategy (see <xref be set to extension byte further extension byte follows        </section>      </section>      <section        <section Data          <t>An uncompressed Data message uses the base dispatch          format and sets the C P to and the M flag          to (<xref  The Data message is          handed to the NDN network stack without modifications.</t>          <figure for NDN Data<artwork  0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+| 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 |+---+---+---+---+---+---+---+---+]]></artwork>          </figure>        </section>        <section Data          <t>The compressed Data message uses the extended dispatch          format (<xref and sets the C M flags to The          P flag is set to If a Data          message contains TLVs that are not mentioned in the          following compression rules, then this message be sent          uncompressed.</t>          <t>By default, the Data message is compressed with the following          base rule set: field of the outermost              MessageType TLV is Name TLV is compressed according to <xref 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 be              sent MetaInfo TLV Type and Length fields are elided from the              compressed Data FreshnessPeriod TLV be moved to the end of the              compressed Data message. Type and              Length fields are and the value is encoded as described              in <xref as a 1-byte      time-code. If the freshness period is not              a valid time-value, then the message 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 Type fields of the SignatureInfo TLV, SignatureType              and SignatureValue TLV are          <t>The compressed NDN LoWPAN Data message is visualized in <xref          <figure of NDN LoWPAN Data<artworkT = 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          <figure for NDN Data<artwork  0                                       1  0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+| | 0 | 1 |+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+]]></artwork>          </figure> FinalBlockId uncompressed message does not include a                  FinalBlockId uncompressed message does include a and it is encoded according to <xref If the FinalBlockId  TLV is not compressible, then the message be sent ContentType uncompressed message does not include a                  ContentType uncompressed message does include a                  ContentType TLV. The Type field is removed from the                  compressed KeyLocator the included SignatureType requires a                  KeyLocator TLV, then the KeyLocator represents a name and is                  compressed according to <xref If the  name is not compressible, then the message be sent the included SignatureType requires a                KeyLocator TLV, then the KeyLocator represents a KeyDigest.                The Type field of this KeyDigest is be set to        </section>        <section anchor="sec.ndn.data.ext0"          <t>The byte follows the          description in <xref and is illustrated          in <xref          <figure  0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+|  NCS  |        RSV        |EXT|+---+---+---+---+---+---+---+---+]]></artwork>          </figure> Name Compression are compressed with the default name                  compression strategy (see <xref be set to extension byte further extension byte follows        </section>      </section>    </section>    <section anchor="sec.ccnx" Message Encoding for      <section        <t>The generic CCNx TLV encoding is described in <xref 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 NDN and CCNx use the same compressed format for writing        TLVs.</t>      </section>      <section TLV        <t>Name TLVs are compressed using the scheme already defined in <xref for NDN. If a Name TLV contains        T_IPID, T_APP, or organizational TLVs, then the name remains        uncompressed.</t>      </section>      <section Interest          <t>An uncompressed Interest message uses the base dispatch format          (see <xref and sets the C M to          The P flag is set to (<xref          The Interest message is handed to the CCNx network stack without modifications.</t>          <figure for CCNx Interest<artwork  0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+| 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 |+---+---+---+---+---+---+---+---+]]></artwork>          </figure>        </section>        <section anchor="sec.ccnxintcompbaseheader" Interest          <t>The compressed Interest message uses the extended dispatch format          (<xref and sets the C and P flags to The M flag is set to          If an Interest message contains TLVs that are not mentioned in the          following compression rules, then this message be sent          uncompressed.</t>          <t>In the default use case, the Interest message is compressed with          the following minimal rule set: Type and Length fields of the CCNx Message TLV are elided            and are obtained from the on          <t>The compressed CCNx LoWPAN Interest message is visualized in          <xref          <figure of CCNx LoWPAN Interest<artworkT = 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          <figure for CCNx Interest<artwork  0                                       1  0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+| | 1 | 0+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+]]></artwork>          </figure> Flags field in the fixed Flags field equals 0 and is removed                  from the Interest Flags field appears in the fixed PacketType field in the fixed PacketType field is elided and assumed                  to be PacketType field is elided and assumed                  to be HopLimit field in the fixed HopLimit field appears in the fixed HopLimit field is elided and assumed to                  be Reserved field in the fixed Reserved field appears in the fixed Reserved field is elided and assumed to                  be Optional Payload Payload TLV is Payload TLV is and the                  field is Optional InterestLifetime      <t>See <xref for further details                  on the ordering of hop-by-hop TLVs.</t> InterestLifetime TLV is present in the                  Interest InterestLifetime TLV is present                  with a fixed length of 1 byte and is encoded as                  described in <xref The and fields are Optional MessageHash                <t>See <xref 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 be sent                  uncompressed.</t> MessageHash TLV is T_SHA-256 TLV is and the fields are removed. The field is                  assumed to represent 32 bytes. The outer Message Hash TLV                  is Optional KeyIdRestriction                <t>This TLV is expected to contain a T_SHA-256 TLV. If                  another hash is contained, then the Interest be sent                  uncompressed.</t> KeyIdRestriction TLV is T_SHA-256 TLV is and the fields are removed. The field is                  assumed to represent 32 bytes. The outer KeyIdRestriction                  TLV is Optional ContentObjectHashRestriction                <t>This TLV is expected to contain a T_SHA-256 TLV. If                  another hash is contained, then the Interest be sent                  uncompressed.</t> ContentObjectHashRestriction TLV is T_SHA-256 TLV is and the fields areremoved. The field is assumed to represent 32 bytes. The outer                ContentObjectHashRestriction TLV is Optional ValidationAlgorithm and ValidationPayload TLVs are present in                  the Interest TLVs are present in the                Interest message. An additional byte follows immediately                that handles TLV compressions and is                described in <xref          <section anchor="sec.ccnxhbhint" Header TLVs TLVs are unordered. For an Interest message,            two optional TLVs are defined in <xref but several more can be defined in    specifications. For the compression specified in the            previous section, the TLVs are ordered as follows: Hash 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"            <figure for<artwork0       1       2       3       4       5       6       7       8+-------+-------+-------+-------+-------+-------+-------+-------+|         ValidationAlg         |     KeyID     |      RSV      |+-------+-------+-------+-------+-------+-------+-------+-------+]]></artwork>            </figure> Optional ValidationAlgorithm uncompressed ValidationAlgorithm                    TLV is T_CRC32C ValidationAlgorithm TLV is                    assumed, but no ValidationAlgorithm TLV is T_CRC32C ValidationAlgorithm TLV is                    assumed, but no ValidationAlgorithm TLV is included.                    Additionally, a Sigtime TLV is inlined without a and                    a T_HMAC-SHA256 ValidationAlgorithm                    TLV is assumed, but no ValidationAlgorithm TLV is T_HMAC-SHA256 ValidationAlgorithm                    TLV is assumed, but no ValidationAlgorithm TLV is included.                    Additionally, a Sigtime TLV is inlined without a and                    a Optional KeyID TLV within the ValidationAlgorithm TLV is TLV is present and T_SHA-256 TLV is and the fields are removed. The                    field is assumed to represent 32 bytes. The outer                    TLV is T_SHA-512 TLV is and the fields are removed. The                    field is assumed to represent 64 bytes. The outer                    TLV is be set to            <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"          <t>The byte follows the          description in <xref and is illustrated          in <xref          <figure0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+|  NCS  |        RSV        |EXT|+---+---+---+---+---+---+---+---+]]></artwork>          </figure> Name Compression are compressed with the default name                  compression strategy (see <xref be set to extension byte further extension byte follows        </section>      </section>      <section        <section Content          <t>An uncompressed Content uses the base dispatch format (see          <xref and sets the C flag to the P and M flags to (<xref          The Content is handed to the CCNx network stack without modifications.</t>          <figure for CCNx Content<artwork  0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+| 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 |+---+---+---+---+---+---+---+---+]]></artwork>          </figure>        </section>        <section Content          <t>The compressed Content uses the extended dispatch format          (<xref and sets the C, P, M to If a Content contains TLVs that are not mentioned in  the following compression          rules, then this message be sent uncompressed.</t>          <t>By default, the Content is compressed with the following          base rule set: PacketType field is elided from the Type and Length fields of the CCNx Message TLV are elided              and are obtained from the on          <t>The compressed CCNx LoWPAN Data message is visualized in <xref          <figure of CCNx LoWPAN Data<artworkT = 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          <figure for CCNx Content<artwork  0                                       1  0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+| 1 | 1 | 1 PLTYP+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+]]></artwork>          </figure> Flags field in the fixed <xref Reserved field in the fixed <xref Optional Payload <xref Optional Recommended Cache Time TLV is Recommended Cache Time TLV is                  and the fields are Optional MessageHash      <t>See <xref 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 be sent uncompressed.</t> MessageHash TLV is T_SHA-256 TLV is and the fields are removed. The field is                  assumed to represent 32 bytes. The outer Message Hash TLV                  is Optional PayloadType PayloadType TLV is PayloadType TLV is and                      T_PAYLOADTYPE_DATA is PayloadType TLV is and                      T_PAYLOADTYPE_KEY is PayloadType TLV is present and Optional ExpiryTime ExpiryTime TLV is ExpiryTime TLV is and the fields are Optional ValidationAlgorithm and ValidationPayload              <xref be set to          <section anchor="sec.ccnxhbhdata" Header TLVs TLVs are unordered. For a Content Object            message, two optional TLVs are defined in    <xref but several more can be defined in specifications. For the compression specified in the            previous section, the TLVs are ordered as follows: Cache Time Hash            <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"          <t>The byte follows the          description in <xref and is illustrated          in <xref          <figure0   1   2   3   4   5   6   7+---+---+---+---+---+---+---+---+|  NCS  |        RSV        |EXT|+---+---+---+---+---+---+---+---+]]></artwork>          </figure> Name Compression are compressed with the default name                  compression strategy (see <xref be set to extension byte further extension byte follows        </section>      </section>    </section>    <section Time      <t>        This document adopts the 8-bit compact time representation for        relative described in <xref with the constant factor set to :=      </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 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): (b == (0 + a/8) * 2 * C (b &gt; (1 + a/8) * * C (see <xref configuration allows for the following subnormal number: 0 minimum subnormal number: ~0.007812 subnormal number: ~0.054688 normalized number: ~0.062500 minimum normalized number: ~0.070312 normalized number: ~3.99      <t>        The second modification only applies to uncompressible time        offsets that are outside any security envelope. An invalid        time-value be set to the largest valid time-value that is        smaller than the invalid input value before compression.      </t>    </section>    <section anchor="stateful.compression" Header      <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"        <t>A (CID) is a byte that refers to a particular        conceptual context between network devices and be used to replace        frequently appearing information, such as name prefixes, suffixes, or        meta information, such as Interest lifetime.</t>        <figure  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        If the most significant bit indicates the presence of another, subsequent        ContextID byte (see <xref 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 be silently discarded.</t>      </section>      <section anchor="stateful.compression.en-route"        <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 of link-local as shown in <xref        <figure Identifier as<artwork  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 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) 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 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        <figure    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>        <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        <figure Name TLVs    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>        <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 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 Stateful Header        <t>A CID appears whenever the CID flag is set (see <xref The CID is appended to the last ICN        LoWPAN dispatch as shown in <xref        <figure Encapsulation with ICN LoWPAN and<artwork...-------+--------+-------...-------+--...-+-------.../  ...    |  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 This allows to use multiple shared contexts in compressed messages.</t>        <t>The HopID is always included as the very first CID.</t>        <figure of<artwork+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+|1| CID / HopID | --> |1|     CID     | --> |0|     CID     |+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+]]></artwork>        </figure>      </section>    </section>    <section anchor="sec.ndn.constvars" LoWPAN Constants and      <t>This is a summary of all ICN LoWPAN constants and variables.    </section>    <section anchor="implementationnotice" Report and      <t>The ICN LoWPAN scheme defined in this document has been implemented as      an extension of the NDN/CCNx software stack <xref in      its IoT version on RIOT <xref An experimental      evaluation for NDN over ICN with varying configurations has been      performed in <xref  Energy and      processing time measurements indicate significant energy savings,      amortized costs for processing show no penalties.</t>      <section        <t>The header compression performance depends on certain aspects and        configurations. It works best for the following cases: time offsets per <xref without the need for state (e.g., prefixes) is such that            long names can be elided from Interest and used TLV type numbers for CCNx and NDN stay            in the lower range (&lt;          Name components are of type and are limited to a        length of 15 bytes to enable compression for all messages.</t>      </section>      <section Experimental        <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: name compression scheme (<xref 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 As a preliminary          analysis, <xref investigates the          effectiveness of the proposed compression scheme with URLs          obtained from the WWW. Studies on deployments can offer additional insights          on naming schemes in the fragmentation scheme (<xref inherited from 6LoWPAN allows          for a transparent, hop-wise reassembly of CCNx or NDN          packets. Fragment forwarding <xref with selective          fragment recovery <xref 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. state (<xref 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 distribution and synchronization of contextual state          can potentially be adopted from <xref 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 stateful en-route compression (<xref 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 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      </section>    </section>    <section anchor="security.considerations"      <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 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" the 6LoWPAN Dispatch Type Field        <t>IANA has assigned dispatch values the Type <xref <xref represents updates to the registry.</t> anchor="tab.iana.dispatches" for NDN and CCNx with align="center">Bit align="left">Header NDN NDN Data CCNx Content Object CCNx Content Object      </section>    </section>  </middle>  <back>        <reference anchor="ieee802.15.4">          <front>            <title>IEEE          </front>        </reference>        <reference anchor="IEEE.754.2019">          <front> for Floating-Point Arithmetic</title>          </front>        </reference>      </references>        <!--<?rfc include="reference.RFC.7400"?>-->        <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>        <reference anchor="NDN-MAC">          <front>            <title>The for a to MAC in NDN: the            <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>    <section anchor="sec.EstimatedSizeReduction" Size      <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 is the number of name 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 The lengths of TLV components      specific to the CCNx or NDN encoding and outlined below.</t>      <section        <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          <t><xref 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 of an NDN<artwork------------------------------------,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 depicts the          size requirements after compression.</t>          <figure of a NDN<artwork------------------------------------,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 the          total size gain is 17 bytes, which is 43% of the uncompressed          packet.</t>        </section>        <section          <t><xref 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 of an NDN<artwork------------------------------------,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 depicts the size          requirements for the compressed version of the above Data          packet.</t>          <figure of a NDN<artwork------------------------------------,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 the          total size gain is 21 bytes.</t>        </section>      </section>      <section        <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          <t><xref 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 of an CCNx<artwork------------------------------------,Fixed Header            = 8         |Message                 = 4         |  ---------------------,            |  Name                 |  4 +        = 56 + 4n + comps_n    NameSegments        = 4n +      |                       |  comps_n   |  ---------------------'            |  KeyIdRestriction      = 40        |------------------------------------']]></artwork>          </figure>          <t><xref  depicts the size requirements after compression.</t>          <figure of a CCNx<artwork------------------------------------,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 the size          is reduced by 53 bytes, which is 53% of the uncompressed          packet.</t>        </section>        <section          <t><xref  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 of an CCNx Content<artwork------------------------------------,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  depicts the size          requirements for a basic, compressed CCNx Data.</t>          <figure of a CCNx Data<artwork------------------------------------,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 the size          is reduced by 70 bytes, which is 40% of the uncompressed packet          containing a 4-byte payload.</t>        </section>      </section>    </section>    <section      <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 and      <xref      Special goes to as well as      as their previous work in <xref      and <xref 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>