ICN

Internet Research Group Task Force (IRTF)                          C. Gundogan
Internet-Draft
Request for Comments: 9139                                   TC. Schmidt
Intended status:
Category: Experimental                                       HAW Hamburg
Expires: August 14, 2021
ISSN: 2070-1721                                              M. Waehlisch Wählisch
                                                    link-lab & FU Berlin
                                                               C. Scherb
                                                               C. Marxer
                                                             C. Tschudin
                                                     University of Basel
                                                       February 10,
                                                           November 2021

             ICN Adaptation to LoWPAN Networks (ICN LoWPAN)
                     draft-irtf-icnrg-icnlowpan-10

Abstract

   This document defines a convergence layer for CCNx Content-Centric
   Networking (CCNx) and NDN Named Data Networking (NDN) over IEEE 802.15.4 LoWPAN networks.
   Low-Power Wireless Personal Area Networks (LoWPANs).  A new frame
   format is specified to adapt CCNx and NDN packets to the small MTU
   size of IEEE 802.15.4.  For that, syntactic and semantic changes to
   the TLV-based header formats are described.  To support compatibility
   with other LoWPAN technologies that may coexist on a wireless medium,
   the dispatching scheme provided by 6LoWPAN IPv6 over LoWPAN (6LoWPAN) is
   extended to include new dispatch types for CCNx and NDN.
   Additionally, the fragmentation component of the 6LoWPAN dispatching
   framework is applied to ICN Information-Centric Network (ICN) chunks.  In
   its second part, the document defines stateless and stateful
   compression schemes to improve efficiency on constrained links.
   Stateless compression reduces TLV expressions to static header fields
   for common use cases.  Stateful compression schemes elide state states
   local to the LoWPAN and replace names in data Data packets by short local
   identifiers.

   This document is a product of the IRTF Information-Centric Networking
   Research Group (ICNRG).

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and BCP 79.

   Internet-Drafts are working documents
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This document is a product of the Internet Engineering Research Task
   Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts. (IRTF).  The list IRTF publishes the results of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts Internet-related
   research and development activities.  These results might not be
   suitable for deployment.  This RFC represents the consensus of the
   Information-Centric Networking Research Group of the Internet
   Research Task Force (IRTF).  Documents approved for publication by
   the IRSG are draft documents valid not candidates for a maximum any level of six months Internet Standard; see
   Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 14, 2021.
   https://www.rfc-editor.org/info/rfc9139.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Overview of ICN LoWPAN  . . . . . . . . . . . . . . . . . . .   6
     3.1.  Link-Layer Convergence  . . . . . . . . . . . . . . . . .   6
     3.2.  Stateless Header Compression  . . . . . . . . . . . . . .   6
     3.3.  Stateful Header Compression . . . . . . . . . . . . . . .   8
   4.  IEEE 802.15.4 Adaptation  . . . . . . . . . . . . . . . . . .   8
     4.1.  LoWPAN Encapsulation  . . . . . . . . . . . . . . . . . .   8
       4.1.1.  Dispatch Extensions . . . . . . . . . . . . . . . . .  10
     4.2.  Adaptation Layer  Adaptation-Layer Fragmentation  . . . . . . . . . . . . .  10
   5.  Space-efficient  Space-Efficient Message Encoding for NDN  . . . . . . . . . .  11
     5.1.  TLV Encoding  . . . . . . . . . . . . . . . . . . . . . .  11
     5.2.  Name TLV Compression  . . . . . . . . . . . . . . . . . .  12
     5.3.  Interest Messages . . . . . . . . . . . . . . . . . . . .  13
       5.3.1.  Uncompressed Interest Messages  . . . . . . . . . . .  13
       5.3.2.  Compressed Interest Messages  . . . . . . . . . . . .  13
       5.3.3.  Dispatch Extension  . . . . . . . . . . . . . . . . .  17
     5.4.  Data Messages . . . . . . . . . . . . . . . . . . . . . .  17
       5.4.1.  Uncompressed Data Messages  . . . . . . . . . . . . .  17
       5.4.2.  Compressed Data Messages  . . . . . . . . . . . . . .  18
       5.4.3.  Dispatch Extension  . . . . . . . . . . . . . . . . .  20
   6.  Space-efficient  Space-Efficient Message Encoding for CCNx . . . . . . . . . .  21
     6.1.  TLV Encoding  . . . . . . . . . . . . . . . . . . . . . .  21
     6.2.  Name TLV Compression  . . . . . . . . . . . . . . . . . .  21
     6.3.  Interest Messages . . . . . . . . . . . . . . . . . . . .  21
       6.3.1.  Uncompressed Interest Messages  . . . . . . . . . . .  21
       6.3.2.  Compressed Interest Messages  . . . . . . . . . . . .  22
       6.3.3.  Dispatch Extension  . . . . . . . . . . . . . . . . .  28
     6.4.  Content Objects . . . . . . . . . . . . . . . . . . . . .  28
       6.4.1.  Uncompressed Content Objects  . . . . . . . . . . . .  28
       6.4.2.  Compressed Content Objects  . . . . . . . . . . . . .  29
       6.4.3.  Dispatch Extension  . . . . . . . . . . . . . . . . .  32
   7.  Compressed Time Encoding  . . . . . . . . . . . . . . . . . .  33
   8.  Stateful Header Compression . . . . . . . . . . . . . . . . .  34
     8.1.  LoWPAN-local  LoWPAN-Local State  . . . . . . . . . . . . . . . . . . .  34
     8.2.  En-route  En-Route State  . . . . . . . . . . . . . . . . . . . . .  35
     8.3.  Integrating Stateful Header Compression . . . . . . . . .  37
   9.  ICN LoWPAN Constants and Variables  . . . . . . . . . . . . .  37
   10. Implementation Report and Guidance  . . . . . . . . . . . . .  37
     10.1.  Preferred Configuration  . . . . . . . . . . . . . . . .  37
     10.2.  Further Experimental Deployments . . . . . . . . . . . .  38
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  39
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  40
     12.1.  Reserving Space in  Updates to the 6LoWPAN Dispatch Type Field Registry . . . . . . . . . . . . . . . . . . . . . . . .  40
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  40
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  40
     13.2.  Informative References . . . . . . . . . . . . . . . . .  41
   Appendix A.  Estimated Size Reduction . . . . . . . . . . . . . .  45
     A.1.  NDN . . . . . . . . . . . . . . . . . . . . . . . . . . .  45
       A.1.1.  Interest  . . . . . . . . . . . . . . . . . . . . . .  45
       A.1.2.  Data  . . . . . . . . . . . . . . . . . . . . . . . .  46
     A.2.  CCNx  . . . . . . . . . . . . . . . . . . . . . . . . . .  48
       A.2.1.  Interest  . . . . . . . . . . . . . . . . . . . . . .  48
       A.2.2.  Content Object  . . . . . . . . . . . . . . . . . . .  49
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  50
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  50

1.  Introduction

   The Internet of Things (IoT) has been identified as a promising
   deployment area for Information Centric Networks Information-Centric Networking (ICN), as
   infrastructureless access to content, resilient forwarding, and in-
   network data replication demonstrated demonstrates notable advantages over the
   traditional host-to-host approach on the Internet [NDN-EXP1], [NDN-EXP1]
   [NDN-EXP2].  Recent studies [NDN-MAC] have shown that an appropriate
   mapping to link layer link-layer technologies has a large impact on the
   practical performance of an ICN.  This will be even more relevant in
   the context of IoT communication where nodes often exchange messages
   via low-power wireless links under lossy conditions.  In this memo,
   we address the base adaptation of data chunks to such link layers for
   the ICN flavors NDN [NDN] and CCNx [RFC8569], [RFC8569] [RFC8609].

   The IEEE 802.15.4 [ieee802.15.4] link layer is used in low-power and
   lossy networks (see "LLN" LLN in [RFC7228]), in which devices are typically battery-operated
   battery operated and constrained in resources.  Characteristics of
   LLNs include an unreliable environment, low
   bandwidth low-bandwidth transmissions,
   and increased latencies.  IEEE 802.15.4 admits a maximum physical physical-
   layer packet size of 127 bytes.  The maximum frame header size is 25
   bytes, which leaves 102 bytes for the payload.  IEEE 802.15.4
   security features further reduce this payload length by up to 21
   bytes, yielding a net of 81 bytes for CCNx or NDN packet headers, signatures
   signatures, and content.

   6LoWPAN [RFC4944], [RFC4944] [RFC6282] is a convergence layer that provides
   frame formats, header compression compression, and adaptation layer adaptation-layer fragmentation
   for IPv6 packets in IEEE 802.15.4 networks.  The 6LoWPAN adaptation
   introduces a dispatching framework that prepends further information
   to 6LoWPAN packets, including a protocol identifier for payload and
   meta information about fragmentation.

   Prevalent Type-Length-Value (TLV) based packet formats based on Type-Length-Value (TLV), such as in
   CCNx and NDN NDN, are designed to be generic and extensible.  This leads
   to header verbosity verbosity, which is inappropriate in constrained
   environments of IEEE 802.15.4 links.  This document presents ICN
   LoWPAN, a convergence layer for IEEE 802.15.4 motivated by 6LoWPAN.
   ICN LoWPAN compresses packet headers of CCNx CCNx, as well as NDN NDN, and
   allows for an increased effective payload size per packet.
   Additionally, reusing the dispatching framework defined by 6LoWPAN
   enables compatibility between coexisting wireless deployments of
   competing network technologies.  This also allows to reuse of the
   adaptation layer
   adaptation-layer fragmentation scheme specified by 6LoWPAN for ICN
   LoWPAN.

   ICN LoWPAN defines a more space efficient space-efficient representation of CCNx and
   NDN packet formats.  This syntactic change is described for CCNx and
   NDN separately, as the header formats and TLV encodings differ
   notably.  For further reductions, default header values suitable for
   constrained IoT networks are selected in order to elide corresponding
   TLVs.  Experimental evaluations of the ICN LoWPAN header compression
   schemes in [ICNLOWPAN] illustrate a reduced message overhead, a
   shortened message airtime, and an overall decline in power
   consumption for typical Class 2 [RFC7228] devices [RFC7228] compared to
   uncompressed ICN messages.

   In a typical IoT scenario (see (Figure 1)), Figure 1), embedded devices are
   interconnected via a quasi-stationary infrastructure using a border
   router (BR) that connects the constrained LoWPAN network by some
   Gateway
   gateway with the public Internet.  In ICN based ICN-based IoT networks, non-
   local
   nonlocal Interest and Data messages transparently travel through the
   BR up and down between a Gateway gateway and the embedded devices situated in
   the constrained LoWPAN.

                         |Gateway Services|
                         -------------------------
                               |
                           ,--------,
                           |        |
                           |   BR   |
                           |        |
                           '--------'
                                        LoWPAN
                         O            O
                                O
                       O                O   embedded
                         O      O     O     devices
                          O         O

                         Figure 1: IoT Stub Network

   The document has received fruitful reviews by members of the ICN
   community and the research group (see Acknowledgments) the Acknowledgments section)
   for a period of two years.  It is the consensus of ICNRG that this
   document should be published in the IRTF Stream of the RFC series.
   This document does not constitute an IETF standard.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
   The use of the term, "silently ignore" is not defined in RFC 2119.
   However, the term is used in this document
   BCP 14 [RFC2119] [RFC8174] when, and can be similarly
   construed. only when, they appear in all
   capitals, as shown here.

   This document uses the terminology of [RFC7476], [RFC7927], and
   [RFC7945] for ICN entities.

   The following terms are used in the document and defined as follows:

   ICN LoWPAN:   Information-Centric Networking over Low-power Low-Power Wireless
                 Personal Area Network

   LLN:          Low-Power and Lossy Network

   CCNx:         Content-Centric Networking Architecture

   NDN:          Named Data Networking Architecture

   byte:         synonym for octet

   nibble:       synonym for 4 bits

   time-value:   a time offset measured in seconds

   time-code:    an 8-bit encoded time-value

3.  Overview of ICN LoWPAN

3.1.  Link-Layer Convergence

   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 Figure 2.

         Device 1                                         Device 2
   ,------------------,           Router            ,------------------,
   |  Application   . |     __________________      | ,-> Application  |
   |----------------|-|    |    NDN / CCNx    |     |-|----------------|
   |  NDN / CCNx    | |    | ,--------------, |     | |    NDN / CCNx  |
   |----------------|-|    |-|--------------|-|     |-|----------------|
   |  ICN LoWPAN    | |    | |  ICN LoWPAN  | |     | |    ICN LoWPAN  |
   |----------------|-|    |-|--------------|-|     |-|----------------|
   |  Link-Layer  Link Layer    | |    | |  Link-Layer  Link Layer  | |     | |    Link-Layer    Link Layer  |
   '----------------|-'    '-|--------------|-'     '-|----------------'
                    '--------'              '---------'

          Figure 2: ICN LoWPAN convergence layer Convergence Layer for IEEE 802.15.4

   Section 4 of this document defines the convergence layer for IEEE
   802.15.4.

3.2.  Stateless Header Compression

   ICN LoWPAN also defines a stateless header compression scheme with
   the main purpose of reducing header overhead of ICN packets.  This is
   of particular importance for link-layers link layers with small MTUs.  The
   stateless compression does not require pre-configuration preconfiguration of a global
   state.

   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.

   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.

   Figure 3 demonstrates the stateless header compression idea.  In this
   example, the first type of the first TLV is removed and the
   corresponding bit in the bit field is set.  The second TLV represents
   a fixed-length TLV (e.g., the Nonce TLV in NDN), so that the type Type and
   the length
   Length fields are removed.  The third TLV represents a boolean TLV
   (e.g., the MustBeFresh selector in NDN) for which the type,
   length Type, Length,
   and the value Value fields are elided.

      Uncompressed:

         Variable-length TLV      Fixed-length TLV      Boolean TLV
      ,-----------------------,-----------------------,-------------,
      +-------+-------+-------+-------+-------+-------+------+------+
      |  TYP  |  LEN  |  VAL  |  TYP  |  LEN  |  VAL  |  TYP | LEN  |
      +-------+-------+-------+-------+-------+-------+------+------+

      Compressed:

        +---+---+---+---+---+---+---+---+
        | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 |  Bit field Field
        +---+---+---+---+---+---+---+---+
          |       |                   |
       ,--'       '----,              '- Boolean Value
       |               |
      +-------+-------+-------+
      |  LEN  |  VAL  |  VAL  |
      +-------+-------+-------+
      '---------------'-------'
        Var-len Value  Fixed-len Value

       Figure 3: Compression using Using a compact bit field - bits encode Compact Bit Field -- Bits Encode
                           the
                            inclusion Inclusion of TLVs. TLVs

   Stateless TLV compression for NDN is defined in Section 5.  Section 6
   defines the stateless TLV compression for CCNx.

   The extensibility of this compression is described in Section 4.1.1
   and allows future documents to update the compression rules outlined
   in this manuscript. document.

3.3.  Stateful Header Compression

   ICN LoWPAN further employs two orthogonal orthogonal, stateful compression
   schemes for packet size reductions reductions, which are defined in Section 8.
   These mechanisms rely on shared contexts that are either distributed
   and maintained in the entire LoWPAN, LoWPAN or are generated on-demand on demand hop-
   wise on a particular Interest-data Interest-Data path.

   The shared context identification is defined in Section 8.1.  The
   hop-wise name compression "en-route" is specified in Section 8.2.

4.  IEEE 802.15.4 Adaptation

4.1.  LoWPAN Encapsulation

   The IEEE 802.15.4 frame header does not provide a protocol identifier
   for its payload.  This causes problems of misinterpreting frames when
   several network layers coexist on the same link.  To mitigate errors,
   6LoWPAN defines dispatches as encapsulation headers for IEEE 802.15.4
   frames (see Section 5 of [RFC4944]).  Multiple LoWPAN encapsulation
   headers can precede the actual payload payload, and each encapsulation header
   is identified by a dispatch type.

   [RFC8025] further specifies dispatch pages Pages to switch between
   different contexts.  When a LoWPAN parser encounters a "Page switch" Page switch
   LoWPAN encapsulation header, then all following encapsulation headers are
   interpreted by using a dispatch table table, as specified by the "Page
   switch" header. Page
   switch header.  Pages 0 and page 1 are reserved for 6LoWPAN.  This
   document uses page TBD1 ("1111 TBD1 (0xFTBD1)") Page 14 (1111 1110 (0xFE)) for ICN LoWPAN.

   The base dispatch format (Figure 4) is used and extended by CCNx and
   NDN in Section Sections 5 and Section 6.

                             0   1   2   3   ...
                           +---+---+-----------
                           +---+---+---+---+---
                           | C 0 | P | M |
                           +---+---+----------- C |
                           +---+---+---+---+---

               Figure 4: Base dispatch format Dispatch Format for ICN LoWPAN

   C: Compression

       0:          The message is uncompressed.

       1:          The message is compressed.

   P: Protocol
       0:  The included protocol is NDN.

       1:  The included protocol is CCNx.

   M: Message Type
       0:  The payload contains an Interest message.

       1:  The payload contains a Data message.

   C: Compression
       0:  The message is uncompressed.

       1:  The message is compressed.

   ICN LoWPAN frames with compressed CCNx and NDN messages (C=1) use the
   extended dispatch format in Figure 5.

                         0   1   2   3   4      ...
                         +---+---+---+---+---+--- ...
                       +---+---+---+---+...+---+---+
                       | 1 0 | P | M | 1 |   |CID|EXT|
                         +---+---+---+---+---+---
                       +---+---+---+---+...+---+---+

        Figure 5: Extended dispatch format Dispatch Format for compressed Compressed ICN LoWPAN

   CID: Context Identifier
       0:  No context identifiers are present.

       1:  Context identifier(s) are present (see Section 8.1).

   EXT: Extension
       0:  No extension bytes are present.

       1:  Extension byte(s) are present (see Section 4.1.1).

   The encapsulation format for ICN LoWPAN is displayed in Figure 6.

    +------...------+------...-----+--------+-------...-------+-----...
    | IEEE 802.15.4 | RFC4944 Disp.|  Page  | ICN LoWPAN Disp.| Payl. /
    +------...------+------...-----+--------+-------...-------+-----...

               Figure 6: LoWPAN Encapsulation with ICN-LoWPAN ICN LoWPAN

   IEEE 802.15.4:  The IEEE 802.15.4 header.

   RFC4944 Disp.:  Optional additional dispatches defined in Section 5.1
                   of [RFC4944] [RFC4944].

   Page:           Page Switch.  TBD1 switch. 14 for ICN LoWPAN.

   ICN LoWPAN:     Dispatches as defined in Section Sections 5 and Section 6.

   Payload:        The actual (un-)compressed CCNx or NDN message.

4.1.1.  Dispatch Extensions

   Extension bytes allow for the extensibility of the initial
   compression rule set.  The base format for an extension byte is
   depicted in Figure 7.

                       0   1   2   3   4   5   6   7
                     +---+---+---+---+---+---+---+---+
                     | - | - | - | - | - | - | - |EXT|
                     +---+---+---+---+---+---+---+---+

               Figure 7: Base format Format for dispatch extensions. Dispatch Extensions

   EXT: Extension
       0:  No other extension byte follows.

       1:  A further extension byte follows.

   Extension bytes are numbered according to their order.  Future
   documents MUST follow the naming scheme "EXT_0, EXT_0, EXT_1, ...", ...  when
   updating or referring to a specific dispatch extension byte.
   Amendments that require an exchange of configurational parameters
   between devices SHOULD use manifests to encode structured data in a
   well-defined format, as, e.g., as outlined in [I-D.irtf-icnrg-flic]. [ICNRG-FLIC].

4.2.  Adaptation Layer  Adaptation-Layer Fragmentation

   Small payload sizes in the LoWPAN require fragmentation for various
   network layers.  Therefore, Section 5.3 of [RFC4944] 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 [RFC4944].

   The Fragmentation fragmentation LoWPAN header can encapsulate other dispatch
   headers.  The order of dispatch types is defined in Section 5 of
   [RFC4944].  Figure 8 shows the fragmentation scheme.  The reassembled
   ICN LoWPAN frame does not contain any fragmentation headers and is
   depicted in Figure 9.

    +------...------+----...----+--------+------...-------+--------...
    | IEEE 802.15.4 | Frag. 1st |  Page  |   ICN LoWPAN   | Payload  /
    +------...------+----...----+--------+------...-------+--------...

    +------...------+----...----+--------...
    | IEEE 802.15.4 | Frag. 2nd | Payload  /
    +------...------+----...----+--------...

                    .
                    .
                    .

    +------...------+----...----+--------...
    | IEEE 802.15.4 | Frag. Nth | Payload  /
    +------...------+----...----+--------...

                       Figure 8: Fragmentation scheme Scheme

          +------...------+--------+------...-------+--------...
          | IEEE 802.15.4 |  Page  |   ICN LoWPAN   | Payload  /
          +------...------+--------+------...-------+--------...

                   Figure 9: Reassembled ICN LoWPAN frame Frame

   The 6LoWPAN Fragment Forwarding (6FF) (6LFF) [RFC8930] is an alternative
   approach that enables forwarding of fragments without reassembling
   packets on every intermediate hop.  By reusing the 6LoWPAN
   dispatching framework, 6FF 6LFF integrates into ICN LoWPAN as seamless seamlessly
   as the conventional hop-wise fragmentation.  Experimental  However, experimental
   evaluations
   [SFR-ICNLOWPAN], however, [SFR-ICNLOWPAN] suggest that a more refined more-refined integration
   can increase the cache utilization of forwarders on a request path.

5.  Space-efficient  Space-Efficient Message Encoding for NDN

5.1.  TLV Encoding

   The NDN packet format consists of TLV fields using the TLV encoding
   that is described in [NDN-PACKET-SPEC].  Type and length Length fields are
   of variable size, where numbers greater than 252 are encoded using
   multiple bytes.

   If the type or length number is less than "253", 253, then that number is
   encoded into the actual type Type or length Length field.  If the number is
   greater or equals "253" 253 and fits into 2 bytes, then the type Type or
   length Length
   field is set to "253" 253 and the number is encoded in the next following 2
   bytes in network byte order, i.e., from the most significant byte
   (MSB) to the least significant byte (LSB).  If the number is greater
   than 2 bytes and fits into 4 bytes, then the type Type or length Length field is
   set to "254" 254 and the number is encoded in the subsequent 4 bytes in
   network byte order.  For larger numbers, the
   type Type or length Length field is
   set to "255" 255 and the number is encoded in the subsequent 8 bytes in
   network byte order.

   In this specification, compressed NDN TLVs encode type Type and length Length
   fields using self-delimiting numeric values (SDNVs) [RFC6256]
   commonly known from DTN Delay-Tolerant Networking (DTN) protocols.
   Instead of using the first byte as a marker for the number of
   following bytes, SDNVs use a single bit to indicate subsequent bytes.

   +----------+-----------------------------+--------------------------+

    +==========+==========================+==========================+
    | Value    | NDN TLV encoding Encoding         | SDNV encoding Encoding            |
   +----------+-----------------------------+--------------------------+
    +==========+==========================+==========================+
    | 0        | 0x00                     | 0x00                     |
    +----------+--------------------------+--------------------------+
    | 127      | 0x7F                     | 0x7F                     |
    +----------+--------------------------+--------------------------+
    | 128      | 0x80                     | 0x81 0x00                |
    +----------+--------------------------+--------------------------+
    | 253      | 0xFD 0x00 0xFD           | 0x81 0x7D                |
    +----------+--------------------------+--------------------------+
    | 2^14 - 1 | 0xFD 0x3F 0xFF           | 0xFF 0x7F                |
    +----------+--------------------------+--------------------------+
    | 2^14     | 0xFD 0x40 0x00           | 0x81 0x80 0x00           |
    +----------+--------------------------+--------------------------+
    | 2^16     | 0xFE 0x00 0x01 0x00 0x00 | 0x84 0x80 0x00           |
    +----------+--------------------------+--------------------------+
    | 2^21 - 1 | 0xFE 0x00 0x1F 0xFF 0xFF | 0xFF 0xFF 0x7F           |
    +----------+--------------------------+--------------------------+
    | 2^21     | 0xFE 0x00 0x20 0x00 0x00 | 0x81 0x80 0x80 0x00      |
    +----------+--------------------------+--------------------------+
    | 2^28 - 1 | 0xFE 0x0F 0xFF 0xFF 0xFF | 0xFF 0xFF 0xFF 0x7F      |
    +----------+--------------------------+--------------------------+
    | 2^28     | 0xFE 0x1F 0x00 0x00 0x00 | 0x81 0x80 0x80 0x80 0x00 |
    +----------+--------------------------+--------------------------+
    | 2^32     | 0xFF 0x00 0x00 0x00 0x01 | 0x90 0x80 0x80 0x80 0x00 |
    |          | 0x00 0x00 0x00 0x00      |                          |
    +----------+--------------------------+--------------------------+
    | 2^35 - 1 | 0xFF 0x00 0x00 0x00 0x07 | 0xFF 0xFF 0xFF 0xFF 0x7F |
    |          | 0xFF 0xFF 0xFF 0xFF      |                          |
    +----------+--------------------------+--------------------------+
    | 2^35     | 0xFF 0x00 0x00 0x00 0x08 | 0x81 0x80 0x80 0x80 0x80 |
    |          | 0x00 0x00 0x00 0x00      | 0x00                     |
   +----------+-----------------------------+--------------------------+
    +----------+--------------------------+--------------------------+

               Table 1: NDN TLV encoding compared Encoding Compared to SDNVs. SDNVs

   Table 1 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.

5.2.  Name TLV Compression

   This Name TLV compression encodes length Length fields of two consecutive
   NameComponent TLVs into one byte, using a nibble for each.  The most
   significant nibble indicates the length of an immediately following
   NameComponent TLV.  The least significant nibble denotes the length
   of a subsequent NameComponent TLV.  A length of 0 marks the end of
   the compressed Name TLV.  The last length Length field of an encoded
   NameComponent is either 0x00 for a name with an even number of
   components,
   components and 0xYF (Y > 0) if an odd number of components are
   present.  This process limits the length of a NameComponent TLV to 15
   bytes,
   bytes but allows for an unlimited number of components.  An example
   for this encoding is presented in Figure 10.

                     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       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 10: Name TLV compression Compression for /HAW/Room/481/Humid/99

5.3.  Interest Messages

5.3.1.  Uncompressed Interest Messages

   An uncompressed Interest message uses the base dispatch format (see
   Figure 4) and sets the C flag to "0" C, P, and the P as well as the M flag flags to "0" 0 (Figure 11).  The
   Interest message is handed to the NDN network stack without
   modifications.

                       0   1   2   3   4   5   6   7
                     +---+---+---+---+---+---+---+---+
                     | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
                     +---+---+---+---+---+---+---+---+

     Figure 11: Dispatch format Format for uncompressed Uncompressed NDN Interest messages Messages

5.3.2.  Compressed Interest Messages

   The compressed Interest message uses the extended dispatch format
   (Figure 5) and sets the C flag to "1", 1 and the P flag to "0" and the M
   flag flags to "0". 0.  If
   an Interest message contains TLVs that are not mentioned in the
   following compression rules, then this message MUST be sent
   uncompressed.

   This specification assumes that a HopLimit TLV is part of the
   original Interest message.  If such a HopLimit TLV is not present, it
   will be inserted with a default value of DEFAULT_NDN_HOPLIMIT prior
   to the compression.

   In the default use case, the Interest message is compressed with the
   following minimal rule set:

   1.  The "Type" Type field of the outermost MessageType TLV is removed.

   2.  The Name TLV is compressed according to Section 5.2.  For this,
       all NameComponents are expected to be of type
       GenericNameComponent with a length greater than 0.  An
       ImplicitSha256DigestComponent or ParametersSha256DigestComponent
       MAY appear at the end of the name.  In any other case, the
       message MUST be sent uncompressed.

   3.  The Nonce TLV and InterestLifetime TLV are moved to the end of
       the compressed Interest Interest, as illustrated in Figure 12.  The
       InterestLifetime is encoded as described in Section 7.  On
       decompression, this encoding may yield an Interestlifetime InterestLifetime that
       is smaller than the original value.

   4.  The Type and Length fields of Nonce TLV, HopLimit TLV TLV, and
       InterestLifetime TLV are elided.  The Nonce value has a length of
       4 bytes bytes, and the HopLimit value has a length of 1 byte.  The
       compressed InterestLifetime (Section 7) has a length of 1 byte.
       The presence of a Nonce TLV and InterestLifetime TLV is deduced
       from the remaining length to parse.  A remaining length of "1" 1
       indicates the presence of an InerestLifetime, InterestLifetime, a length of "4" 4
       indicates the presence of a nonce, and a length of "5" 5 indicates
       the presence of both TLVs.

   The compressed NDN LoWPAN Interest message is visualized in
   Figure 12.

        T = Type, L = Length, V = Value
        Lc = Compressed Length, Vc = Compressed Value
        : = optional field, | = mandatory field

        +---------+---------+                 +---------+
        |  Msg T  |  Msg L  |                 |  Msg Lc |
        +---------+---------+---------+       +---------+
        | Name T  | Name L  | Name V  |       | Name Vc |
        +---------+---------+---------+       +---------+---------+
        : CBPfx T : CBPfx L :                 : FWDH Lc : FWDH Vc :
        +---------+---------+                 +---------+---------+
        : MBFr T  : MBFr L  :                 |  HPL V  |
        +---------+---------+---------+  ==>  +---------+---------+
        : FWDH T  : FWDH L  : FWDH V  :       :  APM Lc : APM Vc  :
        +---------+---------+---------+       +---------+---------+
        : NONCE T : NONCE L : NONCE V :       : NONCE V :
        +---------+---------+---------+       +---------+
        :  ILT T  :  ILT L  :  ILT V  :       :  ILT Vc :
        +---------+---------+---------+       +---------+
        :  HPL T  :  HPL L  :  HPL V  :
        +---------+---------+---------+
        :  APM T  :  APM L  :  APM V  :
        +---------+---------+---------+

           Figure 12: Compression of NDN LoWPAN Interest Message

   Further TLV compression is indicated by the ICN LoWPAN dispatch in
   Figure 13.

       0                                       1
       0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     | 1 0 | 0 | 0 |CID|EXT|PFX|FRE|FWD|APM|DIG|          RSV | 1 |PFX|FRE|FWD|APM|DIG|        RSV        |CID|EXT|
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

      Figure 13: Dispatch format Format for compressed Compressed NDN Interest messages

   CID: Context Identifier  See Figure 5.

   EXT: Extension

       0:      No extension byte follows.

       1:      Extension byte "EXT_0" follows immediately.  See
               Section 5.3.3. Messages

   PFX: CanBePrefix TLV
       0:  The uncompressed message does not include a CanBePrefix TLV.

       1:  The uncompressed message does include a CanBePrefix TLV and
           is removed from the compressed message.

   FRE: MustBeFresh TLV
       0:  The uncompressed message does not include a MustBeFresh TLV.

       1:  The uncompressed message does include a MustBeFresh TLV and
           is removed from the compressed message.

   FWD: ForwardingHint TLV
       0:  The uncompressed message does not include a ForwardingHint
           TLV.

       1:  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
           Section 5.2.  If any name is not compressible, the message
           MUST be sent uncompressed.

   APM: ApplicationParameters TLV
       0:  The uncompressed message does not include an
           ApplicationParameters TLV.

       1:  The uncompressed message does include an
           ApplicationParameters TLV.  The Type field is removed from
           the compressed message.

   DIG: ImplicitSha256DigestComponent TLV
       0:  The name does not include an ImplicitSha256DigestComponent as
           the last TLV.

       1:  The name does include an ImplicitSha256DigestComponent as the
           last TLV.  The Type and Length fields are omitted.

   RSV: Reserved
       Must be set to 0.

   CID: Context Identifier
       See Figure 5.

   EXT: Extension
       0:  No extension byte follows.

       1:  Extension byte EXT_0 follows immediately.  See Section 5.3.3.

5.3.3.  Dispatch Extension

   The "EXT_0" EXT_0 byte follows the description in Section 4.1.1 and is
   illustrated in Figure 14.

                       0   1   2   3   4   5   6   7
                     +---+---+---+---+---+---+---+---+
                     |  NCS  |        RSV        |EXT|
                     +---+---+---+---+---+---+---+---+

                          Figure 14: EXT_0 format Format

   NCS: Name Compression Strategy
       00:  Names are compressed with the default name compression
           strategy (see Section 5.2).

       01:  Reserved.

       10:  Reserved.

       11:  Reserved.

   RSV: Reserved
       Must be set to 0.

   EXT: Extension
       0:  No extension byte follows.

       1:  A further extension byte follows immediately.

5.4.  Data Messages

5.4.1.  Uncompressed Data Messages

   An uncompressed Data message uses the base dispatch format and sets
   the C flag to "0", the and P flag flags to "0" 0 and the M flag to "1" 1 (Figure 15).  The Data
   message is handed to the NDN network stack without modifications.

                       0   1   2   3   4   5   6   7
                     +---+---+---+---+---+---+---+---+
                     | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 |
                     +---+---+---+---+---+---+---+---+

       Figure 15: Dispatch format Format for uncompressed Uncompressed NDN Data messages Messages

5.4.2.  Compressed Data Messages

   The compressed Data message uses the extended dispatch format
   (Figure 5) and sets the C as well as the and M flags to "1". 1.  The P flag is set to "0". 0.
   If a Data message contains TLVs that are not mentioned in the
   following compression rules, then this message MUST be sent
   uncompressed.

   By default, the Data message is compressed with the following base
   rule set:

   1.  The "Type" Type field of the outermost MessageType TLV is removed.

   2.  The Name TLV is compressed according to Section 5.2.  For this,
       all NameComponents are expected to be of type
       GenericNameComponent and to have a length greater than 0.  In any
       other case, the message MUST be sent uncompressed.

   3.  The MetaInfo TLV Type and Length fields are elided from the
       compressed Data message.

   4.  The FreshnessPeriod TLV MUST be moved to the end of the
       compressed Data message.  Type and Length fields are elided elided, and
       the value is encoded as described in Section 7 as a 1-byte time-
       code.  If the freshness period is not a valid time-value, then
       the message MUST be sent uncompressed in order to preserve the
       security envelope of the Data message.  The presence of a
       FreshnessPeriod TLV is deduced from the remaining one byte one-byte length
       to parse.

   5.  The Type fields of the SignatureInfo TLV, SignatureType TLV TLV, and
       SignatureValue TLV are removed.

   The compressed NDN LoWPAN Data message is visualized in Figure 16.

        T = Type, L = Length, V = Value
        Lc = Compressed Length, Vc = Compressed Value
        : = optional field, | = mandatory field

        +---------+---------+                 +---------+
        |  Msg T  |  Msg L  |                 |  Msg Lc |
        +---------+---------+---------+       +---------+
        | Name T  | Name L  | Name V  |       | Name Vc |
        +---------+---------+---------+       +---------+---------+
        : Meta T  : Meta L  :                 : CTyp Lc : CType V :
        +---------+---------+---------+       +---------+---------+
        : CTyp T  : CTyp L  : CTyp V  :       : FBID V  :
        +---------+---------+---------+  ==>  +---------+---------+
        : FrPr T  : FrPr L  : FrPr V  :       : CONT Lc : CONT V  :
        +---------+---------+---------+       +---------+---------+
        : FBID T  : FBID L  : FBID V  :       |  Sig Lc |
        +---------+---------+---------+       +---------+---------+
        : CONT T  : CONT L  : CONT V  :       | SInf Lc | SInf Vc |
        +---------+---------+---------+       +---------+---------+
        |  Sig T  |  Sig L  |                 | SVal Lc | SVal Vc |
        +---------+---------+---------+       +---------+---------+
        | SInf T  | SInf L  | SInf V  |       : FrPr Vc :
        +---------+---------+---------+       +---------+
        | SVal T  | SVal L  | SVal V  |
        +---------+---------+---------+

             Figure 16: Compression of NDN LoWPAN Data Message

   Further TLV compression is indicated by the ICN LoWPAN dispatch in
   Figure 17.

       0                                       1
       0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     | 1 0 | 0 | 1 |CID|EXT|FBI|CON|KLO|              RSV | 1 |FBI|CON|KLO|            RSV            |CID|EXT|
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

        Figure 17: Dispatch format Format for compressed Compressed NDN Data messages

   CID: Context Identifier  See Figure 5.

   EXT: Extension

       0:      No extension byte follows.

       1:      Extension byte "EXT_0" follows immediately.  See
               Section 5.4.3. Messages

   FBI: FinalBlockId TLV
       0:  The uncompressed message does not include a FinalBlockId TLV.

       1:  The uncompressed message does include a FinalBlockId FinalBlockId, and it
           is encoded according to Section 5.2.  If the FinalBlockId TLV
           is not compressible, then the message MUST be sent
           uncompressed.

   CON: ContentType TLV
       0:  The uncompressed message does not include a ContentType TLV.

       1:  The uncompressed message does include a ContentType TLV.  The
           Type field is removed from the compressed message.

   KLO: KeyLocator TLV
       0:  If the included SignatureType requires a KeyLocator TLV, then
           the KeyLocator represents a name and is compressed according
           to Section 5.2.  If the name is not compressible, then the
           message MUST be sent uncompressed.

       1:  If the included SignatureType requires a KeyLocator TLV, then
           the KeyLocator represents a KeyDigest.  The Type field of
           this KeyDigest is removed.

   RSV: Reserved
       Must be set to 0.

   CID: Context Identifier
       See Figure 5.

   EXT: Extension
       0:  No extension byte follows.

       1:  Extension byte EXT_0 follows immediately.  See Section 5.4.3.

5.4.3.  Dispatch Extension

   The "EXT_0" EXT_0 byte follows the description in Section 4.1.1 and is
   illustrated in Figure 18.

                       0   1   2   3   4   5   6   7
                     +---+---+---+---+---+---+---+---+
                     |  NCS  |        RSV        |EXT|
                     +---+---+---+---+---+---+---+---+

                          Figure 18: EXT_0 format Format

   NCS: Name Compression Strategy
       00:  Names are compressed with the default name compression
           strategy (see Section 5.2).

       01:  Reserved.

       10:  Reserved.

       11:  Reserved.

   RSV: Reserved
       Must be set to 0.

   EXT: Extension
       0:  No extension byte follows.

       1:  A further extension byte follows immediately.

6.  Space-efficient  Space-Efficient Message Encoding for CCNx

6.1.  TLV Encoding

   The generic CCNx TLV encoding is described in [RFC8609].  Type and
   Length fields attain the common fixed length of 2 bytes.

   The TLV encoding for CCNx LoWPAN is changed to the more space space-
   efficient encoding described in Section 5.1.  Hence  Hence, NDN and CCNx use
   the same compressed format for writing TLVs.

6.2.  Name TLV Compression

   Name TLVs are compressed using the scheme already defined in
   Section 5.2 for NDN.  If a Name TLV contains T_IPID, T_APP, or
   organizational TLVs, then the name remains uncompressed.

6.3.  Interest Messages

6.3.1.  Uncompressed Interest Messages

   An uncompressed Interest message uses the base dispatch format (see
   Figure 4) and sets the C as well as the and M flag flags to "0". 0.  The P flag is set to "1" 1
   (Figure 19).  The Interest message is handed to the CCNx network
   stack without modifications.

                       0   1   2   3   4   5   6   7
                     +---+---+---+---+---+---+---+---+
                     | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 |
                     +---+---+---+---+---+---+---+---+

     Figure 19: Dispatch format Format for uncompressed Uncompressed CCNx Interest messages Messages

6.3.2.  Compressed Interest Messages

   The compressed Interest message uses the extended dispatch format
   (Figure 5) and sets the C and P flags to "1". 1.  The M flag is set to
   "0". 0.
   If an Interest message contains TLVs that are not mentioned in the
   following compression rules, then this message MUST be sent
   uncompressed.

   In the default use case, the Interest message is compressed with the
   following minimal rule set:

   1.  The version is elided from the fixed header and assumed to be 1.

   2.  The Type and Length fields of the CCNx Message TLV are elided and
       are obtained from the Fixed Header fixed header on decompression.

   The compressed CCNx LoWPAN Interest message is visualized in
   Figure 20.

   T = Type, L = Length, V = Value
   Lc = Compressed Length, Vc = Compressed Value
   : = optional field, | = mandatory field

   +-----------------------------+           +-------------------------+
   |    Uncompr. Fixed Header    |           |   Compr. Fixed Header   |
   +-----------------------------+           +-------------------------+
   +---------+---------+---------+           +---------+
   : ILT T   : ILT L   : ILT V   :           : ILT Vc  :
   +---------+---------+---------+           +---------+
   : MSGH T  : MSGH L  : MSGH V  :           : MSGH Vc :
   +---------+---------+---------+           +---------+
   +---------+---------+                     +---------+
   | MSGT T  | MSGT L  |                     | Name Vc |
   +---------+---------+---------+           +---------+
   | Name T  | Name L  | Name V  |    ==>    : KIDR Vc :
   +---------+---------+---------+           +---------+
   : KIDR T  : KIDR L  : KIDR V  :           : OBHR Vc :
   +---------+---------+---------+           +---------+---------+
   : OBHR T  : OBHR L  : OBHR V  :           : PAYL Lc : PAYL V  :
   +---------+---------+---------+           +---------+---------+
   : PAYL T  : PAYL L  : PAYL V  :           : VALG Lc : VALG Vc :
   +---------+---------+---------+           +---------+---------+
   : VALG T  : VALG L  : VALG V  :           : VPAY Lc : VPAY V  :
   +---------+---------+---------+           +---------+---------+
   : VPAY T  : VPAY L  : VPAY V  :
   +---------+---------+---------+

           Figure 20: Compression of CCNx LoWPAN Interest Message

   Further TLV compression is indicated by the ICN LoWPAN dispatch in
   Figure 21.

       0                                       1
       0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     | 1 0 | 1 | 0 |CID|EXT|VER|FLG|PTY|HPL|FRS|PAY|ILT|MGH|KIR|CHR|VAL| | 1 |FLG|PTY|HPL|FRS|PAY|ILT|MGH|KIR|CHR|VAL|CID|EXT|
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

      Figure 21: Dispatch format Format for compressed Compressed CCNx Interest messages

   CID: Context Identifier  See Figure 5.

   EXT: Extension

       0:      No extension byte follows.

       1:      Extension byte "EXT_0" follows immediately.  See
               Section 6.3.3.

   VER: CCNx protocol version in the fixed header

       0:      The Version field equals 1 and is removed from the fixed
               header.

       1:      The Version field appears in the fixed header. Messages

   FLG: Flags field in the fixed header
       0:  The Flags field equals 0 and is removed from the Interest
           message.

       1:  The Flags field appears in the fixed header.

   PTY: PacketType field in the fixed header
       0:  The PacketType field is elided and assumed to be
               "PT_INTEREST". PT_INTEREST.

       1:  The PacketType field is elided and assumed to be
               "PT_RETURN". PT_RETURN.

   HPL: HopLimit field in the fixed header
       0:  The HopLimit field appears in the fixed header.

       1:  The HopLimit field is elided and assumed to be "1". 1.

   FRS: Reserved field in the fixed header
       0:  The Reserved field appears in the fixed header.

       1:  The Reserved field is elided and assumed to be "0". 0.

   PAY: Optional Payload TLV
       0:  The Payload TLV is absent.

       1:  The Payload TLV is present present, and the type Type field is elided.

   ILT: Optional Hop-By-Hop hop-by-hop InterestLifetime TLV
       See Section 6.3.2.1 for further details on the ordering of hop-by-hop hop-
       by-hop TLVs.

       0:  No InterestLifetime TLV is present in the Interest message.

       1:  An InterestLifetime TLV is present with a fixed length of 1
           byte and is encoded as described in Section 7.  The
               type Type and length
           Length fields are elided.

   MGH: Optional Hop-By-Hop hop-by-hop MessageHash TLV
       See Section 6.3.2.1 for further details on the ordering of hop-by-hop hop-
       by-hop TLVs.

       This TLV is expected to contain a T_SHA-256 TLV.  If another hash
       is contained, then the Interest MUST be sent uncompressed.

       0:  The MessageHash TLV is absent.

       1:  A T_SHA-256 TLV is present present, and the type as well as the
               length Type and Length fields
           are removed.  The length Length field is assumed to represent 32
           bytes.  The outer Message Hash TLV is omitted.

   KIR: Optional KeyIdRestriction TLV
       This TLV is expected to contain a T_SHA-256 TLV.  If another hash
       is contained, then the Interest MUST be sent uncompressed.

       0:  The KeyIdRestriction TLV is absent.

       1:  A T_SHA-256 TLV is present present, and the type as well as the
               length Type and Length fields
           are removed.  The length Length field is assumed to represent 32
           bytes.  The outer KeyIdRestriction TLV is omitted.

   CHR: Optional ContentObjectHashRestriction TLV
       This TLV is expected to contain a T_SHA-256 TLV.  If another hash
       is contained, then the Interest MUST be sent uncompressed.

       0:  The ContentObjectHashRestriction TLV is absent.

       1:  A T_SHA-256 TLV is present present, and the type as well as the
               length Type and Length fields
           are removed.  The length Length field is assumed to represent 32
           bytes.  The outer ContentObjectHashRestriction TLV is
           omitted.

   VAL: Optional ValidationAlgorithm and ValidationPayload TLVs
       0:  No validation related validation-related TLVs are present in the Interest
           message.

       1:      Validation related  Validation-related TLVs are present in the Interest message.
           An additional byte follows immediately that handles validation related
           validation-related TLV compressions and is described in
           Section 6.3.2.2.

   CID: Context Identifier
       See Figure 5.

   EXT: Extension
       0:  No extension byte follows.

       1:  Extension byte EXT_0 follows immediately.  See Section 6.3.3.

6.3.2.1.  Hop-By-Hop Header TLVs Compression

   Hop-By-Hop Header

   Hop-by-hop header TLVs are unordered.  For an Interest message, two
   optional Hop-By-Hop Header hop-by-hop header TLVs are defined in [RFC8609], but several
   more can be defined in higher level higher-level specifications.  For the
   compression specified in the previous section, the Hop-By-Hop hop-by-hop TLVs
   are ordered as follows:

   1.  Interest Lifetime  InterestLifetime TLV

   2.  Message Hash TLV

   Note: Other Hop-By-Hop Header hop-by-hop header TLVs than those two remain uncompressed
   in the encoded message message, and they appear in the same order as in the
   original message, message but after the Interest Lifetime InterestLifetime TLV and Message Hash
   TLV.

6.3.2.2.  Validation

     0       1       2       3       4       5       6       7       8
     +-------+-------+-------+-------+-------+-------+-------+-------+
     |         ValidationAlg         |     KeyID     |      RSV      |
     +-------+-------+-------+-------+-------+-------+-------+-------+

                Figure 22: Dispatch for Interset Interest Validations

   ValidationALg:

   ValidationAlg: Optional ValidationAlgorithm TLV
       0000:   An uncompressed ValidationAlgorithm TLV is included.

       0001:   A T_CRC32C ValidationAlgorithm TLV is assumed, but no
               ValidationAlgorithm TLV is included.

       0010:   A T_CRC32C ValidationAlgorithm TLV is assumed, but no
               ValidationAlgorithm TLV is included.  Additionally, a
               Sigtime TLV is inlined without a type Type and a length Length field.

       0011:   A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but
               no ValidationAlgorithm TLV is included.

       0100:   A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but
               no ValidationAlgorithm TLV is included.  Additionally, a
               Sigtime TLV is inlined without a type Type and a length Length field.

       0101:   Reserved.

       0110:   Reserved.

       0111:   Reserved.

       1000:   Reserved.

       1001:   Reserved.

       1010:   Reserved.

       1011:   Reserved.

       1100:   Reserved.

       1101:   Reserved.

       1110:   Reserved.

       1111:   Reserved.

   KeyID: Optional KeyID TLV within the ValidationAlgorithm TLV
       00:  The KeyId KeyID TLV is absent.

       01:  The KeyId KeyID TLV is present and uncompressed.

       10:  A T_SHA-256 TLV is present present, and the type field as well as
               the length Type and Length fields
           are removed.  The length Length field is assumed to represent 32
           bytes.  The outer KeyId KeyID TLV is omitted.

       11:  A T_SHA-512 TLV is present present, and the type field as well as
               the length Type and Length fields
           are removed.  The length Length field is assumed to represent 64
           bytes.  The outer KeyId KeyID TLV is omitted.

   RSV: Reserved
       Must be set to 0.

   The ValidationPayload TLV is present if the ValidationAlgorithm TLV
   is present.  The type Type field is omitted.

6.3.3.  Dispatch Extension

   The "EXT_0" EXT_0 byte follows the description in Section 4.1.1 and is
   illustrated in Figure 23.

                     0   1   2   3   4   5   6   7
                     +---+---+---+---+---+---+---+---+
                     |  NCS  |        RSV        |EXT|
                     +---+---+---+---+---+---+---+---+

                          Figure 23: EXT_0 format Format

   NCS: Name Compression Strategy
       00:  Names are compressed with the default name compression
           strategy (see Section 5.2).

       01:  Reserved.

       10:  Reserved.

       11:  Reserved.

   RSV: Reserved
       Must be set to 0.

   EXT: Extension
       0:  No extension byte follows.

       1:  A further extension byte follows immediately.

6.4.  Content Objects

6.4.1.  Uncompressed Content Objects

   An uncompressed Content object Object uses the base dispatch format (see
   Figure 4) and sets the C flag to "0", 0 and the P and M flags to "1" 1
   (Figure 24).  The Content object Object is handed to the CCNx network stack
   without modifications.

                       0   1   2   3   4   5   6   7
                     +---+---+---+---+---+---+---+---+
                     | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 |
                     +---+---+---+---+---+---+---+---+

      Figure 24: Dispatch format Format for uncompressed Uncompressed CCNx Content objects Objects

6.4.2.  Compressed Content Objects

   The compressed Content object Object uses the extended dispatch format
   (Figure 5) and sets the C, P, as well as the and M flag flags to "1". 1.  If a Content object Object
   contains TLVs that are not mentioned in the following compression
   rules, then this message MUST be sent uncompressed.

   By default, the Content object Object is compressed with the following base
   rule set:

   1.  The version is elided from the fixed header and assumed to be 1.

   2.  The PacketType field is elided from the Fixed Header.

   2. fixed header.

   3.  The Type and Length fields of the CCNx Message TLV are elided and
       are obtained from the Fixed Header fixed header on decompression.

   The compressed CCNx LoWPAN Data message is visualized in Figure 25.

   T = Type, L = Length, V = Value
   Lc = Compressed Length, Vc = Compressed Value
   : = optional field, | = mandatory field

   +-----------------------------+           +-------------------------+
   |    Uncompr. Fixed Header    |           |   Compr. Fixed Header   |
   +-----------------------------+           +-------------------------+
   +---------+---------+---------+           +---------+
   : RCT T   : RCT L   : RCT V   :           : RCT Vc  :
   +---------+---------+------.--+           +---------+
   : MSGH T  : MSGH L  : MSGH V  :           : MSGH Vc :
   +---------+---------+---------+           +---------+
   +---------+---------+                     +---------+
   | MSGT T  | MSGT L  |                     | Name Vc |
   +---------+---------+---------+           +---------+
   | Name T  | Name L  | Name V  |    ==>    : EXPT Vc :
   +---------+---------+---------+           +---------+---------+
   : PTYP T  : PTYP L  : PTYP V  :           : PAYL Lc : PAYL V  :
   +---------+---------+---------+           +---------+---------+
   : EXPT T  : EXPT L  : EXPT V  :           : VALG Lc : VALG Vc :
   +---------+---------+---------+           +---------+---------+
   : PAYL T  : PAYL L  : PAYL V  :           : VPAY Lc : VPAY V  :
   +---------+---------+---------+           +---------+---------+
   : VALG T  : VALG L  : VALG V  :
   +---------+---------+---------+
   : VPAY T  : VPAY L  : VPAY V  :
   +---------+---------+---------+

             Figure 25: Compression of CCNx LoWPAN Data Message

   Further TLV compression is indicated by the ICN LoWPAN dispatch in
   Figure 26.

       0                                       1
       0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     | 0 | 1 | 1 | 1 |CID|EXT|VER|FLG|FRS|PAY|RCT|MGH| |FLG|FRS|PAY|RCT|MGH| PLTYP |EXP|VAL|RSV| |EXP|VAL|RSV|CID|EXT|
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

       Figure 26: Dispatch format Format for compressed Compressed CCNx Content objects

   CID: Context Identifier  See Figure 5.

   EXT: Extension

       0:      No extension byte follows.

       1:      Extension byte "EXT_0" follows immediately.  See
               Section 6.4.3.

   VER: CCNx protocol version in the fixed header

       0:      The Version field equals 1 and is removed from the fixed
               header.

       1:      The Version field appears in the fixed header. Objects

   FLG: Flags field in the fixed header
       See Section 6.3.2.

   FRS: Reserved field in the fixed header
       See Section 6.3.2.

   PAY: Optional Payload TLV
       See Section 6.3.2.

   RCT: Optional Hop-By-Hop RecommendedCacheTime hop-by-hop Recommended Cache Time TLV
       0:  The Recommended Cache Time TLV is absent.

       1:  The Recommended Cache Time TLV is present present, and the type as
               well as the length Type and
           Length fields are elided.

   MGH: Optional Hop-By-Hop hop-by-hop MessageHash TLV
       See Section 6.4.2.1 for further details on the ordering of hop-by-hop hop-
       by-hop TLVs.

       This TLV is expected to contain a T_SHA-256 TLV.  If another hash
       is contained, then the Content Object MUST be sent uncompressed.

       0:  The MessageHash TLV is absent.

       1:  A T_SHA-256 TLV is present present, and the type as well as the
               length Type and Length fields
           are removed.  The length Length field is assumed to represent 32
           bytes.  The outer Message Hash TLV is omitted.

       PLTYP: Optional PayloadType TLV
           00:  The PayloadType TLV is absent.

           01:  The PayloadType TLV is absent absent, and T_PAYLOADTYPE_DATA is
               assumed.

           10:  The PayloadType TLV is absent absent, and T_PAYLOADTYPE_KEY is
               assumed.

           11:  The PayloadType TLV is present and uncompressed.

   EXP: Optional ExpiryTime TLV
       0:  The ExpiryTime TLV is absent.

       1:  The ExpiryTime TLV is present present, and the type as well as the
               length Type and Length fields
           are elided.

   VAL: Optional ValidationAlgorithm and ValidationPayload TLVs
       See Sec
       tion Section 6.3.2.

   RSV: Reserved
       Must be set to 0.

   CID: Context Identifier
       See Figure 5.

   EXT: Extension
       0:  No extension byte follows.

       1:  Extension byte EXT_0 follows immediately.  See Section 6.4.3.

6.4.2.1.  Hop-By-Hop Header TLVs Compression

   Hop-By-Hop Header

   Hop-by-hop header TLVs are unordered.  For a Content Object message,
   two optional Hop-By-Hop Header hop-by-hop header TLVs are defined in [RFC8609], but
   several more can be defined in higher level higher-level specifications.  For the
   compression specified in the previous section, the Hop-By-Hop hop-by-hop TLVs
   are ordered as follows:

   1.  Recommended Cache Time TLV

   2.  Message Hash TLV

   Note: Other Hop-By-Hop Header hop-by-hop header TLVs than those two remain uncompressed
   in the encoded message message, and they appear in the same order as in the
   original message, message but after the Recommended Cache Time TLV and Message
   Hash TLV.

6.4.3.  Dispatch Extension

   The "EXT_0" EXT_0 byte follows the description in Section 4.1.1 and is
   illustrated in Figure 27.

                     0   1   2   3   4   5   6   7
                     +---+---+---+---+---+---+---+---+
                     |  NCS  |        RSV        |EXT|
                     +---+---+---+---+---+---+---+---+

                          Figure 27: EXT_0 format Format

   NCS: Name Compression Strategy
       00:  Names are compressed with the default name compression
           strategy (see Section 5.2).

       01:  Reserved.

       10:  Reserved.

       11:  Reserved.

   RSV: Reserved
       Must be set to 0.

   EXT: Extension
       0:  No extension byte follows.

       1:  A further extension byte follows immediately.

7.  Compressed Time Encoding

   This document adopts the 8-bit compact time representation for
   relative time values time-values described in Section 5 of [RFC5497] with the
   constant factor "C" C set to "C C := 1/32". 1/32.

   Valid time offsets in CCNx and NDN reach range from a few milliseconds
   (e.g., lifetime of low-latency Interests) to several years (e.g.,
   content freshness periods in caches).  Therefore, this document adds
   two modifications to the compression algorithm.

   The first modification is the inclusion of a subnormal form
   [IEEE.754.2019] for time-codes with exponent 0 to provide an
   increased precision and a gradual underflow for the smallest numbers.
   The formula is changed as follows (a := mantissa; mantissa, b := exponent):

   Subnormal (b == 0):  (0 + a/8) * 2 * C

   Normalized (b > 0):  (1 + a/8) * 2^b * C (see [RFC5497])

   This configuration allows for the following ranges:

   o

   *  Minimum subnormal number: 0 seconds

   o
   *  2nd minimum subnormal number: ~0.007812 seconds

   o
   *  Maximum subnormal number: ~0.054688 seconds

   o
   *  Minimum normalized number: ~0.062500 seconds

   o
   *  2nd minimum normalized number: ~0.070312 seconds
   o
   *  Maximum normalized number: ~3.99 years

   The second modification only applies to uncompressible time offsets
   that are outside any security envelope.  An invalid time-value MUST
   be set to the largest valid time-value that is smaller than the
   invalid input value before compression.

8.  Stateful Header Compression

   Stateful header compression in ICN LoWPAN enables packet size
   reductions in two ways.  First, common information that is shared
   throughout the local LoWPAN may be memorized in the context state at
   all nodes and omitted from communication.  Second, redundancy in a
   single
   Interest-data Interest-Data exchange may be removed from ICN stateful
   forwarding on a hop-by-hop bases basis and memorized in en-route state
   tables.

8.1.  LoWPAN-local  LoWPAN-Local State

   A context identifier Context Identifier (CID) is a byte that refers to a particular
   conceptual context between network devices and MAY be used to replace
   frequently appearing information, such as name prefixes, suffixes, or
   meta information, such as Interest lifetime.

                       0   1   2   3   4   5   6   7
                     +---+---+---+---+---+---+---+---+
                     | X |         ContextID         |
                     +---+---+---+---+---+---+---+---+

                       Figure 28: Context Identifier. Identifier

   The 7-bit ContextID is a locally-scoped locally scoped unique identifier that
   represents the contextual state shared between the sender and
   receiver of the corresponding frame (see Figure 28).  If set set, the
   most significant bit indicates the presence of another, subsequent
   ContextID byte (see Figure 33).

   Context

   The context state shared between senders and receivers is removed
   from the compressed packet prior to sending, sending and reinserted after
   reception prior to passing to the upper stack.

   The actual information in a context and how it is encoded are out of
   scope of this document.  The initial distribution and maintenance of
   shared context is out of scope of this document.  Frames containing
   unknown or invalid CIDs MUST be silently discarded.

8.2.  En-route  En-Route State

   In CCNx and NDN, Name TLVs are included in Interest messages, and
   they return in data Data messages.  Returning Name TLVs either equal the
   original Name TLV, TLV or they contain the original Name TLV as a prefix.  ICN
   LoWPAN reduces this redundancy in responses by replacing Name TLVs
   with single bytes that represent link-local HopIDs.  HopIDs are
   carried as Context Identifiers (see Section 8.1) of link-local scope scope,
   as shown in Figure 29.

                       0   1   2   3   4   5   6   7
                     +---+---+---+---+---+---+---+---+
                     | X |          HopID            |
                     +---+---+---+---+---+---+---+---+

                   Figure 29: Context Identifier as HopID. HopID

   A HopID is valid if not all ID bits are set to zero and invalid
   otherwise.  This yields 127 distinct HopIDs.  If this range (1...127)
   is exhausted, the messages MUST be sent without en-route state
   compression until new HopIDs are available.  An ICN LoWPAN node that
   forwards without replacing the name by a HopID (without en-route
   compression) MUST invalidate the HopID by setting all ID-bits ID bits to
   zero.

   While an Interest is traversing, a forwarder generates an ephemeral
   HopID that is tied to a PIT Pending Interest Table (PIT) entry.  Each
   HopID MUST 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).

   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
   Figure 30).

       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 |
   '---'                           '---'                           '---'

          Figure 30: Setting compression state en-route (Interest). Compression State En-Route (Interest)

   Responses include HopIDs that were obtained from Interests.  If the
   returning Name TLV equals the original Name TLV, then the name is
   entirely elided.  Otherwise, only the matching name prefix is elided elided,
   and the distinct name suffix is included along with the HopID.  When
   a response is forwarded, the contained HopID is extracted and used to
   match against the correct PIT entry by performing a lookup on the
   HIDo column.  The HopID is then replaced with the corresponding HopID
   from the HIDi column prior to forwarding the response (Figure 31).

       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 |
   '---'                           '---'                           '---'

          Figure 31: Eliding Name TLVs using en-route state (data). Using En-Route State (Data)

   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 SHOULD use en-
   route compression whenever the stateful compression mechanism is
   activated.

   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.

8.3.  Integrating Stateful Header Compression

   A CID appears whenever the CID flag is set (see Figure 5).  The CID
   is appended to the last ICN LoWPAN dispatch byte byte, as shown in
   Figure 32.

          ...-------+--------+-------...-------+--...-+-------...
          /  ...    |  Page  | ICN LoWPAN Disp.| CIDs | Payload /
          ...-------+--------+-------...-------+--...-+-------...

          Figure 32: LoWPAN Encapsulation with ICN LoWPAN and CIDs

   Multiple CIDs are chained together, with the most significant bit
   indicating the presence of a subsequent CID (Figure 33).  This allows
   to use multiple shared contexts in compressed messages.

   The HopID is always included as the very first CID.

       +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
       |1| CID / HopID | --> |1|     CID     | --> |0|     CID     |
       +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+

                 Figure 33: Chaining of context identifiers. Context Identifiers

9.  ICN LoWPAN Constants and Variables

   This is a summary of all ICN LoWPAN constants and variables.

   DEFAULT_NDN_HOPLIMIT:  255

10.  Implementation Report and Guidance

   The ICN LoWPAN scheme defined in this document has been implemented
   as an extension of the NDN/CCNx software stack [CCN-LITE] in its IoT
   version on RIOT [RIOT].  An experimental evaluation for NDN over ICN
   LOWPAN
   LoWPAN with varying configurations has been performed in [ICNLOWPAN].
   Energy profilings profiling and processing time measurements indicate
   significant energy savings, while and the amortized costs for processing
   show no penalties.

10.1.  Preferred Configuration

   The header compression performance depends on certain aspects and
   configurations.  It works best for the following cases:

   o

   *  Signed time offsets compress as compress, per Section 7 7, without the need for
      rounding.

   o  Contextual

   *  The contextual state (e.g., prefixes) is distributed, distributed such that
      long names can be elided from Interest and data Data messages.

   o

   *  Frequently used TLV type numbers for CCNx and NDN stay in the
      lower range (< 255).

   Name components are of GenericNameComponent type GenericNameComponent and are limited to a
   length of 15 bytes to enable compression for all messages.

10.2.  Further Experimental Deployments

   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:

   o

   *  The name compression scheme (Section 5.2) is optimized for short
      name components of GenericNameComponent type. type GenericNameComponent.  An empirical study
      on name lengths in different deployments of selected use cases,
      such as smart home, smart city, and industrial IoT can provide
      meaningful reports on necessary name component types and lengths.
      A conclusive outcome helps to understand whether and how extension
      mechanisms are needed (Section 5.3.3).  As a preliminary analysis,
      [ICNLOWPAN] investigates the effectiveness of the proposed
      compression scheme with URLs obtained from the WWW.  Studies on
      CoAP [RFC7252]
      deployments of Constrained Application Protocol (CoAP) [RFC7252]
      can offer additional insights on naming schemes in the IoT.

   o

   *  The fragmentation scheme (Section 4.2) inherited from 6LoWPAN
      allows for a transparent, hop-wise reassembly of CCNx or NDN
      packets.  Fragment forwarding [RFC8930] with selective fragment
      recovery [RFC8931] can improve the end-to-end latency and
      reliability,
      reliability while it reduces buffer requirements on forwarders.
      Initial evaluations ([SFR-ICNLOWPAN]) [SFR-ICNLOWPAN] show that a naive integration
      of these upcoming fragmentation features into ICN LoWPAN renders
      the hop-wise content replication inoperative, since Interest and data
      Data messages are reassembled end-to-end.  More deployment
      experiences are necessary to gauge the feasibility of different
      fragmentation schemes in ICN LoWPAN.

   o  Context

   *  The context state (Section 8.1) 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.

   o

   *  The distribution and synchronization of the contextual state can
      potentially be adopted from Section 7.2 of [RFC6775], [RFC6775] 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.

   o

   *  The stateful en-route compression (Section 8.2) supports a limited
      number of 127 distinct HopIDs that can be simultaneously in use on
      a single node.  Complex deployment scenarios that make use of
      multiple, concurrent requests can provide a better insight on the
      number of open requests stored in the Pending Interest Table PIT of memory-constrained
      devices.  This number can serve as an upper- upper bound and determines
      whether the HopID length needs to be resized to fit more HopIDs to at
      the cost of additional header overhead.

   o

   *  Multiple implementations that generate and deploy the compression
      options of this memo in different ways will also add to the
      experience and understanding of the benefits and limitations of
      the proposed schemes.  Different reports can help to illuminate on
      the complexity of implementing ICN LoWPAN for constrained devices,
      as well as on maintaining interoperability with other
      implementations.

11.  Security Considerations

   Main memory is typically a scarce resource of constrained networked
   devices.  Fragmentation  Fragmentation, as described in this memo memo, preserves
   fragments and purges them only after a packet is reassembled, which
   requires a buffering of all fragments.  This scheme is able to handle
   fragments for distinctive packets simultaneously, which can lead to
   overflowing packet buffers that cannot hold all necessary fragments
   for packet reassembly.  Implementers are thus urged to make use of
   appropriate buffer replacement strategies for fragments.  Minimal
   fragment forwarding [RFC8930] can potentially prevent fragment buffer
   saturation in forwarders.

   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.

   To further alleviate the problems caused by forged fragments or
   Interest initiations, proper protective mechanisms for accessing the
   link-layer
   link layer should be deployed.  IEEE 802.15.4, e.g., provides
   capabilities to protect frames and restrict them to a point-to-point
   link,
   link or a group of devices.

12.  IANA Considerations

12.1.  Reserving Space in  Updates to the 6LoWPAN Dispatch Type Field Registry

   IANA has assigned dispatch values of for ICN LoWPAN in the "6LoWPAN Dispatch "Dispatch
   Type Field" registry [RFC4944][RFC8025] with Page TBD1 for ICN LoWPAN. subregistry [RFC4944] [RFC8025] of the "IPv6 Low Power
   Personal Area Network Parameters" registry.  Table 2 represents the
   updates to the registry.

    +-------------+------+-------------------------------------------+

       +=============+======+=========================+===========+
       | Bit Pattern | Page | Header Type             |
    +-------------+------+-------------------------------------------+ Reference |
       +=============+======+=========================+===========+
       |  00 000000  | TBD1  14  | Uncompressed NDN        | RFC 9139  |
       |             |      | Interest messages       |           |
       +-------------+------+-------------------------+-----------+
       |  00 01xxxx  |  14  | Compressed NDN Interest | RFC 9139  |
       |             |      | messages                |           |
       +-------------+------+-------------------------+-----------+
       |  00 100000  | TBD1  14  | Uncompressed NDN Data   | RFC 9139  |
       |             |      | messages                |           |
       +-------------+------+-------------------------+-----------+
       |  00 11xxxx  |  14  | Compressed NDN Data     | RFC 9139  |
       |             |      | messages                |           |
       +-------------+------+-------------------------+-----------+
       |  01 000000  | TBD1  14  | Uncompressed CCNx       | RFC 9139  |
       |             |      | Interest messages       |           |
       +-------------+------+-------------------------+-----------+
       |  01 100000 01xxxx  | TBD1  14  | Uncompressed Compressed CCNx Content Object messages         | RFC 9139  |
       |  10 0xxxxx             | TBD1      | Compressed NDN Interest messages       |           |  10 1xxxxx
       +-------------+------+-------------------------+-----------+
       | TBD1  01 100000  | Compressed NDN Data messages  14  | Uncompressed CCNx       |  11 0xxxxx RFC 9139  | TBD1
       | Compressed CCNx Interest             |      | Content Object messages |           |  11 1xxxxx
       +-------------+------+-------------------------+-----------+
       |  01 11xxxx  | TBD1  14  | Compressed CCNx Content | RFC 9139  |
       |             |      | Object messages         |
    +-------------+------+-------------------------------------------+

         Table 2: Dispatch types for NDN and CCNx with page TBD1.           |
       +-------------+------+-------------------------+-----------+

13.  References

13.1.  Normative References

   [IEEE.754.2019]
              Institute of Electrical and Electronics Engineers, C/MSC -
              Microprocessor Standards Committee, "Standard
              IEEE, "IEEE Standard for Floating-Point Arithmetic", June 2019,
              <https://standards.ieee.org/content/ieee-standards/en/
              standard/754-2019.html>. IEEE
              Std 754-2019, <https://standards.ieee.org/content/ieee-
              standards/en/standard/754-2019.html>.

   [ieee802.15.4]
              IEEE, "IEEE Std. 802.15.4-2015", April 2016, Standard for Low-Rate Wireless Networks", IEEE
              Std 802.15.4-2015, <https://standards.ieee.org/findstds/
              standard/802.15.4-2015.html>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
              <https://www.rfc-editor.org/info/rfc4944>.

   [RFC5497]  Clausen, T. and C. Dearlove, "Representing Multi-Value
              Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
              DOI 10.17487/RFC5497, March 2009,
              <https://www.rfc-editor.org/info/rfc5497>.

   [RFC6256]  Eddy, W. and E. Davies, "Using Self-Delimiting Numeric
              Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May
              2011, <https://www.rfc-editor.org/info/rfc6256>.

   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              DOI 10.17487/RFC6282, September 2011,
              <https://www.rfc-editor.org/info/rfc6282>.

   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
              Bormann, "Neighbor Discovery Optimization for IPv6 over
              Low-Power Wireless Personal Area Networks (6LoWPANs)",
              RFC 6775, DOI 10.17487/RFC6775, November 2012,
              <https://www.rfc-editor.org/info/rfc6775>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

13.2.  Informative References

   [CCN-LITE] "CCN-lite: A lightweight CCNx and NDN implementation",
              <http://ccn-lite.net/>.

   [I-D.irtf-icnrg-flic]
              Tschudin, C., Wood, C., Mosko, M., and D. Oran, "File-Like
              ICN Collections (FLIC)", draft-irtf-icnrg-flic-02 (work in
              progress), November 2019.

   [ICNLOWPAN]
              Gundogan,
              Gündogan, C., Kietzmann, P., Schmidt, TC., and M.
              Waehlisch,
              Wählisch, "ICNLoWPAN -- - Named-Data Networking in Low Power
              IoT Networks", Proc. of 18th IFIP Networking Conference,
              May 2019,
              <https://doi.org/10.23919/IFIPNetworking.2019.8816850>.

   [ICNRG-FLIC]
              Tschudin, C., Wood, C., Mosko, M., and D. Oran, Ed.,
              "File-Like ICN Collections (FLIC)", Work in Progress,
              Internet-Draft, draft-irtf-icnrg-flic-02, 4 November 2019,
              <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-
              flic-02>.

   [NDN]      Jacobson, V., Smetters, D., Thornton, J., and M. Plass, M.,
              Briggs, N., and R. Braynard, "Networking Named Content", named content",
              5th Int. Conf. on emerging Networking Experiments and
              Technologies (ACM CoNEXT), December 2009,
              <https://doi.org/10.1145/1658939.1658941>.

   [NDN-EXP1] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, TC., and M.
              Waehlisch,
              Wählisch, "Information Centric Networking centric networking in the IoT:
              Experiments
              experiments with NDN in the Wild", wild", Proc. of 1st ACM Conf.
              on Information-Centric Networking (ICN-2014) ACM DL, pp.
              77-86, September 2014,
              <http://dx.doi.org/10.1145/2660129.2660144>.

   [NDN-EXP2]
              Gundogan, Gündoğan, C., Kietzmann, P., Lenders, M., Petersen, H.,
              Schmidt, TC., and M. Waehlisch, Wählisch, "NDN, CoAP, and MQTT: A
              Comparative Measurement Study a
              comparative measurement study in the IoT", Proc. of 5th
              ACM Conf. on Information-Centric Networking (ICN-2018) ACM
              DL, pp. 159-171, September 2018,
              <https://doi.org/10.1145/3267955.3267967>.

   [NDN-MAC]  Kietzmann, P., Gundogan, Gündoğan, C., Schmidt, TC., Hahm, O., and
              M. Waehlisch, Wählisch, "The Need need for a Name name to MAC Address Mapping address mapping
              in NDN: Towards Quantifying towards quantifying the Resource Gain", resource gain", Proc. of
              4th ACM Conf. on Information-Centric Networking (ICN-
              2017) (ICN-2017)
              ACM DL, pp. 36-42, September 2017,
              <https://doi.org/10.1145/3125719.3125737>.

   [NDN-PACKET-SPEC]
              "NDN Packet Format Specification",
              <https://named-data.net/doc/NDN-packet-spec/0.3/>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/info/rfc7228>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/info/rfc7252>.

   [RFC7476]  Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G.,
              Tyson, G., Davies, E., Molinaro, A., and S. Eum,
              "Information-Centric Networking: Baseline Scenarios",
              RFC 7476, DOI 10.17487/RFC7476, March 2015,
              <https://www.rfc-editor.org/info/rfc7476>.

   [RFC7927]  Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
              Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
              "Information-Centric Networking (ICN) Research
              Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
              <https://www.rfc-editor.org/info/rfc7927>.

   [RFC7945]  Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S.,
              and G. Boggia, "Information-Centric Networking: Evaluation
              and Security Considerations", RFC 7945,
              DOI 10.17487/RFC7945, September 2016,
              <https://www.rfc-editor.org/info/rfc7945>.

   [RFC8025]  Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
              Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
              RFC 8025, DOI 10.17487/RFC8025, November 2016,
              <https://www.rfc-editor.org/info/rfc8025>.

   [RFC8569]  Mosko, M., Solis, I., and C. Wood, "Content-Centric
              Networking (CCNx) Semantics", RFC 8569,
              DOI 10.17487/RFC8569, July 2019,
              <https://www.rfc-editor.org/info/rfc8569>.

   [RFC8609]  Mosko, M., Solis, I., and C. Wood, "Content-Centric
              Networking (CCNx) Messages in TLV Format", RFC 8609,
              DOI 10.17487/RFC8609, July 2019,
              <https://www.rfc-editor.org/info/rfc8609>.

   [RFC8930]  Watteyne, T., Ed., Thubert, P., Ed., and C. Bormann, "On
              Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6
              Network", RFC 8930, DOI 10.17487/RFC8930, November 2020,
              <https://www.rfc-editor.org/info/rfc8930>.

   [RFC8931]  Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal
              Area Network (6LoWPAN) Selective Fragment Recovery",
              RFC 8931, DOI 10.17487/RFC8931, November 2020,
              <https://www.rfc-editor.org/info/rfc8931>.

   [RIOT]     Baccelli, E., Gundogan, Gündoğan, C., Hahm, O., Kietzmann, P.,
              Lenders, MS., Petersen, H., Schleiser, K., Schmidt, TC.,
              and M. Waehlisch, Wählisch, "RIOT: an An Open Source Operating System
              for Low-end Low-End Embedded Devices in the IoT", IEEE Internet of
              Things Journal Vol. 5, No. 6, p.  4428-4440, December
              2018, <https://doi.org/10.1109/JIOT.2018.2815038>.

   [SFR-ICNLOWPAN]
              Lenders, M., Gundogan, Gündoğan, C., Schmidt, TC., and M. Waehlisch, Wählisch,
              "Connecting the Dots: Selective Fragment Recovery in
              ICNLoWPAN", Proc. of 7th ACM Conf. on Information-Centric
              Networking (ICN-2020) ACM DL, pp. 70-76, September 2020,
              <https://doi.org/10.1145/3405656.3418719>.

   [TLV-ENC-802.15.4]
              Mosko, M. and C. Tschudin, "CCN and NDN TLV encodings in
              802.15.4 packets", January 2015,
              <https://datatracker.ietf.org/meeting/interim-2015-icnrg-
              01/materials/slides-interim-2015-icnrg-1-2>.

   [WIRE-FORMAT-CONSID]
              Wang, G., Tschudin, C., and R. Ravindran, "CCN/NDN
              Protocol Wire Format and Functionality Considerations",
              January 2015, <https://datatracker.ietf.org/meeting/
              interim-2015-icnrg-01/materials/slides-interim-2015-icnrg-
              1-8>.

Appendix A.  Estimated Size Reduction

   In the following following, a theoretical evaluation is given to estimate the
   gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages.

   We assume that "n" n is the number of name components, "comps_n" components; comps_n 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 "clen". clen.  The lengths of TLV components is are specific
   to the CCNx or NDN encoding and are outlined below.

A.1.  NDN

   The NDN TLV encoding has variable-sized TLV fields.  For simplicity,
   the 1 byte 1-byte form of each TLV component is assumed.  A typical TLV
   component therefore is of size 2 (type (Type field + length Length field) + the
   actual value.

A.1.1.  Interest

   Figure 34 depicts the size requirements for a basic, uncompressed NDN
   Interest containing a CanBePrefix TLV, a MustBeFresh TLV, a an
   InterestLifetime TLV set to 4 seconds seconds, and a HopLimit TLV set to 6.
   Numbers below represent the amount of bytes.

         ------------------------------------,
         Interest TLV            = 2         |
           ---------------------,            |
           Name                 |  2 +       |
             NameComponents      = 2n +      |
                                |  comps_n   |
           ---------------------'             = 21 + 2n + comps_n
           CanBePrefix           = 2         |
           MustBeFresh           = 2         |
           Nonce                 = 6         |
           InterestLifetime      = 4         |
           HopLimit              = 3         |
         ------------------------------------'

         Figure 34: Estimated size Size of an uncompressed Uncompressed NDN Interest

   Figure 35 depicts the size requirements after compression.

         ------------------------------------,
         Dispatch Page Switch    = 1         |
         NDN Interset Interest Dispatch   = 2         |
         Interest TLV            = 1         |
         -----------------------,            |
         Name                   |            |
           NameComponents        = n/2 +      = 10 + n/2 + comps_n
                                |  comps_n   |
         -----------------------'            |
         Nonce                   = 4         |
         HopLimit                = 1         |
         InterestLifetime        = 1         |
         ------------------------------------'

           Figure 35: Estimated size Size of a compressed Compressed NDN Interest

   The size difference is: is 11 + 1.5n bytes.

   For the name "/DE/HH/HAW/BT7", /DE/HH/HAW/BT7, the total size gain is 17 bytes, which
   is 43% of the uncompressed packet.

A.1.2.  Data

   Figure 36 depicts the size requirements for a basic, uncompressed NDN
   Data containing a FreshnessPeriod as MetaInfo.  A FreshnessPeriod of
   1 minute is assumed assumed, and the value is encoded using 1 byte.  An
   HMACWithSha256 is assumed as a signature.  The key locator is assumed
   to contain a Name TLV of length klen.

        ------------------------------------,
        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       |            |
          ---------------------'            |
        ------------------------------------'

           Figure 36: Estimated size Size of an uncompressed Uncompressed NDN Data

   Figure 37 depicts the size requirements for the compressed version of
   the above Data packet.

        ------------------------------------,
        Dispatch Page Switch    = 1         |
        NDN Data Dispatch       = 2         |
        -----------------------,            |
        Name                   |            |
          NameComponents        = n/2 +     |
                               |  comps_n    = 38 + n/2 + comps_n +
        -----------------------'            |  clen + klen
        Content                 = 1 + clen  |
        KeyLocator              = 1 + klen  |
        DigestSha256            = 32        |
        FreshnessPeriod         = 1         |
        ------------------------------------'

             Figure 37: Estimated size Size of a compressed Compressed NDN Data

   The size difference is: is 15 + 1.5n bytes.

   For the name "/DE/HH/HAW/BT7", /DE/HH/HAW/BT7, the total size gain is 21 bytes.

A.2.  CCNx

   The CCNx TLV encoding defines a 2-byte encoding for type Type and length Length
   fields, summing up to 4 bytes in total without a value.

A.2.1.  Interest

   Figure 38 depicts the size requirements for a basic, uncompressed
   CCNx Interest.  No Hop-By-Hop hop-by-hop TLVs are included, the protocol version
   is assumed to be 1 1, and the reserved Reserved field is assumed to be 0.  A
   KeyIdRestriction TLV with T_SHA-256 is included to limit the
   responses to Content Objects containing the specific key.

         ------------------------------------,
         Fixed Header            = 8         |
         Message                 = 4         |
           ---------------------,            |
           Name                 |  4 +        = 56 + 4n + comps_n
             NameSegments        = 4n +      |
                                |  comps_n   |
           ---------------------'            |
           KeyIdRestriction      = 40        |
         ------------------------------------'

         Figure 38: Estimated size Size of an uncompressed Uncompressed CCNx Interest

   Figure 39 depicts the size requirements after compression.

         ------------------------------------,
         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        |
         ------------------------------------'

          Figure 39: Estimated size Size of a compressed Compressed CCNx Interest

   The size difference is: is 18 + 3.5n bytes.

   For the name "/DE/HH/HAW/BT7", /DE/HH/HAW/BT7, the size is reduced by 53 bytes, which
   is 53% of the uncompressed packet.

A.2.2.  Content Object

   Figure 40 depicts the size requirements for a basic, uncompressed
   CCNx Content Object containing an ExpiryTime Message TLV, an
   HMAC_SHA-256 signature, the signature time time, and a hash of the shared
   secret key.  In the fixed header, the protocol version is assumed to
   be 1 and the reserved Reserved field is assumed to be 0

     ------------------------------------,
     Fixed Header            = 8         |
     Message                 = 4         |
       ---------------------,            |
       Name                 |  4 +       |
         NameSegments        = 4n +      |
                            |  comps_n   |
       ---------------------'            |
       ExpiryTime            = 12         = 124 + 4n + comps_n + clen
       Payload               = 4 + clen  |
       ---------------------,            |
       ValidationAlgorithm  |            |
         T_HMAC-256          = 56        |
           KeyId
           KeyID            |            |
         SignatureTime      |            |
       ---------------------'            |
       ValidationPayload     = 36        |
     ------------------------------------'

      Figure 40: Estimated size Size of an uncompressed Uncompressed CCNx Content Object

   Figure 41 depicts the size requirements for a basic, compressed CCNx
   Data.

     ------------------------------------,
     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        |
     ------------------------------------'

         Figure 41: Estimated size Size of a compressed Compressed CCNx Data Object

   The size difference is: is 35 + 3.5n bytes.

   For the name "/DE/HH/HAW/BT7", /DE/HH/HAW/BT7, the size is reduced by 70 bytes, which
   is 40% of the uncompressed packet containing a 4-byte payload.

Acknowledgments

   This work was stimulated by fruitful discussions in the ICNRG
   research group and the
   communities of RIOT and CCNlite.  We would like to thank all active
   members for constructive thoughts and feedback.  In particular, the
   authors would like to thank (in alphabetical order) Peter Kietzmann,
   Dirk Kutscher, Martine Lenders, Colin Perkins, and Junxiao Shi. The
   hop-wise stateful name compression was brought up in a discussion by
   Dave Oran, which is gratefully acknowledged.  Larger parts of this
   work are inspired by [RFC4944] and [RFC6282].  Special mentioning mention goes
   to Mark Mosko Mosko, as well as G.Q. Wang and Ravi Ravindran Ravindran, as their
   previous work in [TLV-ENC-802.15.4] and [WIRE-FORMAT-CONSID] provided
   a good base for our discussions on stateless header compression
   mechanisms.  Many thanks also to Carsten Bormann and Lars Eggert, who
   contributed in-depth comments during the IRSG review.  This work was
   supported in part by the German Federal Ministry of Research and
   Education within the projects I3 and RAPstore.

Authors' Addresses

   Cenk Gundogan
   HAW Hamburg
   Berliner Tor 7
   Hamburg
   D-20099 Hamburg
   Germany

   Phone: +4940428758067
   EMail:
   Email: cenk.guendogan@haw-hamburg.de
   URI:   http://inet.haw-hamburg.de/members/cenk-gundogan

   Thomas C. Schmidt
   HAW Hamburg
   Berliner Tor 7
   Hamburg
   D-20099 Hamburg
   Germany

   EMail:

   Email: t.schmidt@haw-hamburg.de
   URI:   http://inet.haw-hamburg.de/members/schmidt

   Matthias Waehlisch Wählisch
   link-lab & FU Berlin
   Hoenower Str. 35
   Berlin
   D-10318 Berlin
   Germany

   EMail:

   Email: mw@link-lab.net
   URI:   http://www.inf.fu-berlin.de/~waehl   https://www.mi.fu-berlin.de/en/inf/groups/ilab/members/
   waehlisch.html

   Christopher Scherb
   University of Basel
   Spiegelgasse 1
   Basel
   CH-4051 Basel
   Switzerland

   EMail:

   Email: christopher.scherb@unibas.ch

   Claudio Marxer
   University of Basel
   Spiegelgasse 1
   Basel
   CH-4051 Basel
   Switzerland

   EMail:

   Email: claudio.marxer@unibas.ch

   Christian Tschudin
   University of Basel
   Spiegelgasse 1
   Basel
   CH-4051 Basel
   Switzerland

   EMail:

   Email: christian.tschudin@unibas.ch