Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs) HAW Hamburg
Berliner Tor 7 Hamburg D-20099 Germany +4940428758067 cenk.guendogan@haw-hamburg.de http://inet.haw-hamburg.de/members/cenk-gundogan
HAW Hamburg
Berliner Tor 7 Hamburg D-20099 Germany t.schmidt@haw-hamburg.de http://inet.haw-hamburg.de/members/schmidt
link-lab & FU Berlin
Hoenower Str. 35 Berlin D-10318 Germany mw@link-lab.net https://www.mi.fu-berlin.de/en/inf/groups/ilab/members/waehlisch.html
University of Applied Sciences and Arts Northwestern Switzerland
Peter Merian-Str. 86 Basel 4002 Switzerland christopher.scherb@fhnw.ch
University of Basel
Spiegelgasse 1 Basel 4051 Switzerland claudio.marxer@unibas.ch
University of Basel
Spiegelgasse 1 Basel 4051 Switzerland christian.tschudin@unibas.ch
Information-Centric Networking Content-Centric Networking (CCNx) Named Data Networking (NDN) header compression fragmentation 6LoWPAN Internet of Things (IoT) This document defines a convergence layer for Content-Centric Networking (CCNx) and Named Data Networking (NDN) over IEEE 802.15.4 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 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 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 states local to the LoWPAN and replace names in 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 document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of 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 not candidates for any level of 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 obtained at .
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 () 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
  • .  Introduction
  • .  Terminology
  • .  Overview of ICN LoWPAN
    • .  Link-Layer Convergence
    • .  Stateless Header Compression
    • .  Stateful Header Compression
  • .  IEEE 802.15.4 Adaptation
    • .  LoWPAN Encapsulation
      • .  Dispatch Extensions
    • .  Adaptation-Layer Fragmentation
  • .  Space-Efficient Message Encoding for NDN
    • .  TLV Encoding
    • .  Name TLV Compression
    • .  Interest Messages
      • .  Uncompressed Interest Messages
      • .  Compressed Interest Messages
      • .  Dispatch Extension
    • .  Data Messages
      • .  Uncompressed Data Messages
      • .  Compressed Data Messages
      • .  Dispatch Extension
  • .  Space-Efficient Message Encoding for CCNx
    • .  TLV Encoding
    • .  Name TLV Compression
    • .  Interest Messages
      • .  Uncompressed Interest Messages
      • .  Compressed Interest Messages
      • .  Dispatch Extension
    • .  Content Objects
      • .  Uncompressed Content Objects
      • .  Compressed Content Objects
      • .  Dispatch Extension
  • .  Compressed Time Encoding
  • .  Stateful Header Compression
    • .  LoWPAN-Local State
    • .  En Route State
    • .  Integrating Stateful Header Compression
  • .  ICN LoWPAN Constants and Variables
  • . Implementation Report and Guidance
    • .  Preferred Configuration
    • .  Further Experimental Deployments
  • . Security Considerations
  • . IANA Considerations
    • .  Updates to the 6LoWPAN Dispatch Type Field Registry
  • . References
    • .  Normative References
    • .  Informative References
  • .  Estimated Size Reduction
    • .  NDN
      • .  Interest
      • .  Data
    • .  CCNx
      • .  Interest
      • .  Content Object
  • Acknowledgments
  • Authors' Addresses
Introduction The Internet of Things (IoT) has been identified as a promising deployment area for Information-Centric Networking (ICN), as infrastructureless access to content, resilient forwarding, and in-network data replication demonstrates notable advantages over the Internet host-to-host approach . Recent studies have shown that an appropriate mapping to 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 and CCNx . The IEEE 802.15.4 link layer is used in low-power and lossy networks (see LLN in ), in which devices are typically battery operated and constrained in resources. Characteristics of LLNs include an unreliable environment, low-bandwidth transmissions, and increased latencies. IEEE 802.15.4 admits a maximum 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, and content. 6LoWPAN is a convergence layer that provides frame formats, header compression, and 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 packet formats based on Type-Length-Value (TLV), such as in CCNx and NDN, are designed to be generic and extensible. This leads to header 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, as well as 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 reuse of the adaptation-layer fragmentation scheme specified by 6LoWPAN for ICN LoWPAN. ICN LoWPAN defines a more 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 illustrate a reduced message overhead, a shortened message airtime, and an overall decline in power consumption for typical Class 2 devices compared to uncompressed ICN messages. In a typical IoT scenario (see ), embedded devices are interconnected via a quasi-stationary infrastructure using a border router (BR) that connects the constrained LoWPAN network by some gateway with the public Internet. In ICN-based IoT networks, nonlocal Interest and Data messages transparently travel through the BR up and down between a gateway and the embedded devices situated in the constrained LoWPAN.
IoT Stub Network |Gateway Services| ------------------------- | ,--------, | | | BR | | | '--------' LoWPAN O O O O O embedded O O O devices O O
The document has received fruitful reviews by members of the ICN community and the research group (see 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.
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 BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the terminology of , , and for ICN entities. The following terms are used in the document and defined as follows:
ICN LoWPAN:
Information-Centric Networking over Low-Power Wireless Personal Area Network
LLN:
Low-Power and Lossy Network
CCNx:
Content-Centric Networking
NDN:
Named Data Networking
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
Overview of ICN LoWPAN
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 .
ICN LoWPAN Convergence Layer for IEEE 802.15.4 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 | '----------------|-' '-|--------------|-' '-|----------------' '--------' '---------'
of this document defines the convergence layer for IEEE 802.15.4.
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 with small MTUs. The stateless compression does not require 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 the TLV format is its support of variably structured data. The main disadvantage of the TLV format is the verbosity that results from storing the type and length of the encoded data. 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. 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 and Length fields are removed. The third TLV represents a boolean TLV (e.g., the MustBeFresh selector in NDN) for which the Type, Length, and Value fields are elided.
Compression Using a Compact Bit Field -- Bits Encode the Inclusion of TLVs 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 +---+---+---+---+---+---+---+---+ | | | ,--' '----, '- Boolean Value | | +-------+-------+-------+ | LEN | VAL | VAL | +-------+-------+-------+ '---------------'-------' Var-len Value Fixed-len Value
Stateless TLV compression for NDN is defined in . defines the stateless TLV compression for CCNx. The extensibility of this compression is described in and allows future documents to update the compression rules outlined in this document.
Stateful Header Compression ICN LoWPAN further employs two orthogonal, stateful compression schemes for packet size reductions, which are defined in . These mechanisms rely on shared contexts that are either distributed and maintained in the entire LoWPAN or are generated on demand hop-wise on a particular Interest-Data path. The shared context identification is defined in . The hop-wise name compression "en route" is specified in .
IEEE 802.15.4 Adaptation
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 ). Multiple LoWPAN encapsulation headers can precede the actual payload, and each encapsulation header is identified by a dispatch type. further specifies dispatch Pages to switch between different contexts. When a LoWPAN parser encounters a Page switch LoWPAN encapsulation header, all following encapsulation headers are interpreted by using a dispatch Page, as specified by the Page switch header. Pages 0 and 1 are reserved for 6LoWPAN. This document uses Page 14 (1111 1110 (0xFE)) for ICN LoWPAN. The base dispatch format () is used and extended by CCNx and NDN in Sections and .
Base Dispatch Format for ICN LoWPAN 0 1 2 3 ... +---+---+---+---+--- | 0 | P | M | C | +---+---+---+---+---
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 .
Extended Dispatch Format for Compressed ICN LoWPAN 0 1 2 3 ... ... +---+---+---+---+...+---+---+ | 0 | P | M | 1 | |CID|EXT| +---+---+---+---+...+---+---+
CID: Context Identifier
0:
No context identifiers are present.
1:
Context identifier(s) are present (see ).
EXT: Extension
0:
No extension bytes are present.
1:
Extension byte(s) are present (see ).
The encapsulation format for ICN LoWPAN is displayed in .
LoWPAN Encapsulation with ICN LoWPAN +------...------+------...-----+--------+-------...-------+-----... | IEEE 802.15.4 | RFC4944 Disp.| Page | ICN LoWPAN Disp.| Payl. / +------...------+------...-----+--------+-------...-------+-----...
IEEE 802.15.4:
The IEEE 802.15.4 header.
RFC4944 Disp.:
Optional additional dispatches defined in .
Page:
Page switch. 14 for ICN LoWPAN.
ICN LoWPAN:
Dispatches as defined in Sections and .
Payload:
The actual (un-)compressed CCNx or NDN message.
Dispatch Extensions Extension bytes allow for the extensibility of the initial compression rule set. The base format for an extension byte is depicted in .
Base Format for Dispatch Extensions 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | - | - | - | - | - | - | - |EXT| +---+---+---+---+---+---+---+---+
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_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, e.g., as outlined in .
Adaptation-Layer Fragmentation Small payload sizes in the LoWPAN require fragmentation for various network layers. Therefore, 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 . The fragmentation LoWPAN header can encapsulate other dispatch headers. The order of dispatch types is defined in . shows the fragmentation scheme. The reassembled ICN LoWPAN frame does not contain any fragmentation headers and is depicted in .
Fragmentation Scheme +------...------+----...----+--------+------...-------+--------... | IEEE 802.15.4 | Frag. 1st | Page | ICN LoWPAN | Payload / +------...------+----...----+--------+------...-------+--------... +------...------+----...----+--------... | IEEE 802.15.4 | Frag. 2nd | Payload / +------...------+----...----+--------... . . . +------...------+----...----+--------... | IEEE 802.15.4 | Frag. Nth | Payload / +------...------+----...----+--------...
Reassembled ICN LoWPAN Frame +------...------+--------+------...-------+--------... | IEEE 802.15.4 | Page | ICN LoWPAN | Payload / +------...------+--------+------...-------+--------...
The 6LoWPAN Fragment Forwarding (6LFF) is an alternative approach that enables forwarding of fragments without reassembling packets on every intermediate hop. By reusing the 6LoWPAN dispatching framework, 6LFF integrates into ICN LoWPAN as seamlessly as the conventional hop-wise fragmentation. However, experimental evaluations suggest that a more-refined integration can increase the cache utilization of forwarders on a request path.
Space-Efficient Message Encoding for NDN
TLV Encoding The NDN packet format consists of TLV fields using the TLV encoding that is described in . Type and 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, then that number is encoded into the actual Type or Length field. If the number is greater or equals 253 and fits into 2 bytes, then the Type or Length field is set to 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 or Length field is set to 254 and the number is encoded in the subsequent 4 bytes in network byte order. For larger numbers, the Type or Length field is set to 255 and the number is encoded in the subsequent 8 bytes in network byte order. In this specification, compressed NDN TLVs encode Type and Length fields using self-delimiting numeric values (SDNVs) commonly known from 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. NDN TLV Encoding Compared to SDNVs
Value NDN TLV Encoding SDNV Encoding
0 0x00 0x00
127 0x7F 0x7F
128 0x80 0x81 0x00
253 0xFD 0x00 0xFD 0x81 0x7D
214 - 1 0xFD 0x3F 0xFF 0xFF 0x7F
214 0xFD 0x40 0x00 0x81 0x80 0x00
216 0xFE 0x00 0x01 0x00 0x00 0x84 0x80 0x00
221 - 1 0xFE 0x00 0x1F 0xFF 0xFF 0xFF 0xFF 0x7F
221 0xFE 0x00 0x20 0x00 0x00 0x81 0x80 0x80 0x00
228 - 1 0xFE 0x0F 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x7F
228 0xFE 0x1F 0x00 0x00 0x00 0x81 0x80 0x80 0x80 0x00
232 0xFF 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x90 0x80 0x80 0x80 0x00
235 - 1 0xFF 0x00 0x00 0x00 0x07 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x7F
235 0xFF 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00 0x81 0x80 0x80 0x80 0x80 0x00
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.
Name TLV Compression This Name TLV compression encodes 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 field of an encoded NameComponent is either 0x00 for a name with an even number of 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 but allows for an unlimited number of components. An example for this encoding is presented in .
Name TLV Compression for /HAW/Room/481/Humid/99 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interest Messages
Uncompressed Interest Messages An uncompressed Interest message uses the base dispatch format (see ) and sets the C, P, and M flags to 0 (). The Interest message is handed to the NDN stack without modifications.
Dispatch Format for Uncompressed NDN Interest Messages 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +---+---+---+---+---+---+---+---+
Compressed Interest Messages The compressed Interest message uses the extended dispatch format () and sets the C flag to 1 and the P and M flags to 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 field of the outermost MessageType TLV is removed.
  2. The Name TLV is compressed according to . 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, as illustrated in . The InterestLifetime is encoded as described in . On decompression, this encoding may yield an InterestLifetime that is smaller than the original value.
  4. The Type and Length fields of Nonce TLV, HopLimit TLV, and InterestLifetime TLV are elided. The Nonce value has a length of 4 bytes, and the HopLimit value has a length of 1 byte. The compressed InterestLifetime () 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 indicates the presence of an InterestLifetime, a length of 4 indicates the presence of a nonce, and a length of 5 indicates the presence of both TLVs.
The compressed NDN LoWPAN Interest message is visualized in .
Compression of NDN LoWPAN Interest Message 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 : +---------+---------+---------+
Further TLV compression is indicated by the ICN LoWPAN dispatch in .
Dispatch Format for Compressed NDN Interest Messages 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 1 |PFX|FRE|FWD|APM|DIG| RSV |CID|EXT| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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 . 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 .
EXT: Extension
0:
No extension byte follows.
1:
Extension byte EXT_0 follows immediately. See .
Dispatch Extension The EXT_0 byte follows the description in and is illustrated in .
EXT_0 Format 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | NCS | RSV |EXT| +---+---+---+---+---+---+---+---+
NCS: Name Compression Strategy
00:
Names are compressed with the default name compression strategy (see ).
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.
Data Messages
Uncompressed Data Messages An uncompressed Data message uses the base dispatch format and sets the C and P flags to 0 and the M flag to 1 (). The Data message is handed to the NDN stack without modifications.
Dispatch Format for Uncompressed NDN Data Messages 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | +---+---+---+---+---+---+---+---+
Compressed Data Messages The compressed Data message uses the extended dispatch format () and sets the C and M flags to 1. The P flag is set to 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 field of the outermost MessageType TLV is removed.
  2. The Name TLV is compressed according to . 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, and the value is encoded as described in 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 length to parse.
  5. The Type fields of the SignatureInfo TLV, SignatureType TLV, and SignatureValue TLV are removed.
The compressed NDN LoWPAN Data message is visualized in .
Compression of NDN LoWPAN Data Message 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 : CTyp V : +---------+---------+---------+ +---------+---------+ : CTyp T : CTyp L : CTyp V : : FBID V : +---------+---------+---------+ ==> +---------+---------+ : FrPr T : FrPr L : FrPr V : : CONT Lc : CONT V : +---------+---------+---------+ +---------+---------+ : FBID T : FBID L : FBID V : | Sig Lc | +---------+---------+---------+ +---------+---------+ : CONT T : CONT L : CONT V : | SInf Lc | SInf Vc | +---------+---------+---------+ +---------+---------+ | Sig T | Sig L | | SVal Lc | SVal Vc | +---------+---------+---------+ +---------+---------+ | SInf T | SInf L | SInf V | : FrPr Vc : +---------+---------+---------+ +---------+ | SVal T | SVal L | SVal V | +---------+---------+---------+
Further TLV compression is indicated by the ICN LoWPAN dispatch in .
Dispatch Format for Compressed NDN Data Messages 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 0 | 1 | 1 |FBI|CON|KLO| RSV |CID|EXT| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
FBI: FinalBlockId TLV
0:
The uncompressed message does not include a FinalBlockId TLV.
1:
The uncompressed message does include a FinalBlockId, and it is encoded according to . 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 . 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 .
EXT: Extension
0:
No extension byte follows.
1:
Extension byte EXT_0 follows immediately. See .
Dispatch Extension The EXT_0 byte follows the description in and is illustrated in .
EXT_0 Format 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | NCS | RSV |EXT| +---+---+---+---+---+---+---+---+
NCS: Name Compression Strategy
00:
Names are compressed with the default name compression strategy (see ).
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.
Space-Efficient Message Encoding for CCNx
TLV Encoding The generic CCNx TLV encoding is described in . Type and Length fields attain the common fixed length of 2 bytes. The TLV encoding for CCNx LoWPAN is changed to the more space-efficient encoding described in . Hence, NDN and CCNx use the same compressed format for writing TLVs.
Name TLV Compression Name TLVs are compressed using the scheme already defined in for NDN. If a Name TLV contains T_IPID, T_APP, or organizational TLVs, then the name remains uncompressed.
Interest Messages
Uncompressed Interest Messages An uncompressed Interest message uses the base dispatch format (see ) and sets the C and M flags to 0. The P flag is set to 1 (). The Interest message is handed to the CCNx stack without modifications.
Dispatch Format for Uncompressed CCNx Interest Messages 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | +---+---+---+---+---+---+---+---+
Compressed Interest Messages The compressed Interest message uses the extended dispatch format () and sets the C and P flags to 1. The M flag is set to 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 on decompression.
The compressed CCNx LoWPAN Interest message is visualized in .
Compression of CCNx LoWPAN Interest Message 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 : +---------+---------+---------+
Further TLV compression is indicated by the ICN LoWPAN dispatch in .
Dispatch Format for Compressed CCNx Interest Messages 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 1 | 0 | 1 |FLG|PTY|HPL|FRS|PAY|ILT|MGH|KIR|CHR|VAL|CID|EXT| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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.
1:
The PacketType field is elided and assumed to be 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.
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.
PAY: Optional Payload TLV
0:
The Payload TLV is absent.
1:
The Payload TLV is present, and the Type field is elided.
ILT: Optional hop-by-hop InterestLifetime TLV
See for further details on the ordering of 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 . The Type and Length fields are elided.
MGH: Optional hop-by-hop MessageHash TLV
See for further details on the ordering of 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, and the Type and Length fields are removed. The 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, and the Type and Length fields are removed. The 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, and the Type and Length fields are removed. The Length field is assumed to represent 32 bytes. The outer ContentObjectHashRestriction TLV is omitted.
VAL: Optional ValidationAlgorithm and ValidationPayload TLVs
0:
No validation-related TLVs are present in the Interest message.
1:
Validation-related TLVs are present in the Interest message. An additional byte follows immediately that handles validation-related TLV compressions and is described in .
CID: Context Identifier
See .
EXT: Extension
0:
No extension byte follows.
1:
Extension byte EXT_0 follows immediately. See .
Hop-By-Hop Header TLVs Compression Hop-by-hop header TLVs are unordered. For an Interest message, two optional hop-by-hop header TLVs are defined in , but several more can be defined in higher-level specifications. For the compression specified in the previous section, the hop-by-hop TLVs are ordered as follows:
  1. InterestLifetime TLV
  2. Message Hash TLV
Note: All hop-by-hop header TLVs other than the InterestLifetime and MessageHash TLVs remain uncompressed in the encoded message, and they appear after the InterestLifetime and MessageHash TLVs in the same order as in the original message.
Validation
Dispatch for Interest Validations 0 1 2 3 4 5 6 7 8 +-------+-------+-------+-------+-------+-------+-------+-------+ | ValidationAlg | KeyID | RSV | +-------+-------+-------+-------+-------+-------+-------+-------+
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 SignatureTime TLV is inlined without a Type and a 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 SignatureTime TLV is inlined without a Type and a 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 TLV is absent.
01:
The KeyID TLV is present and uncompressed.
10:
A T_SHA-256 TLV is present, and the Type and Length fields are removed. The Length field is assumed to represent 32 bytes. The outer KeyID TLV is omitted.
11:
A T_SHA-512 TLV is present, and the Type and Length fields are removed. The Length field is assumed to represent 64 bytes. The outer KeyID TLV is omitted.
RSV: Reserved
Must be set to 0.
The ValidationPayload TLV is present if the ValidationAlgorithm TLV is present. The Type field is omitted.
Dispatch Extension The EXT_0 byte follows the description in and is illustrated in .
EXT_0 Format 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | NCS | RSV |EXT| +---+---+---+---+---+---+---+---+
NCS: Name Compression Strategy
00:
Names are compressed with the default name compression strategy (see ).
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.
Content Objects
Uncompressed Content Objects An uncompressed Content Object uses the base dispatch format (see ) and sets the C flag to 0 and the P and M flags to 1 (). The Content Object is handed to the CCNx stack without modifications.
Dispatch Format for Uncompressed CCNx Content Objects 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | +---+---+---+---+---+---+---+---+
Compressed Content Objects The compressed Content Object uses the extended dispatch format () and sets the C, P, and M flags to 1. If a Content Object contains TLVs that are not mentioned in the following compression rules, then this message MUST be sent uncompressed. By default, the Content 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.
  3. The Type and Length fields of the CCNx Message TLV are elided and are obtained from the fixed header on decompression.
The compressed CCNx LoWPAN Data message is visualized in .
Compression of CCNx LoWPAN Data Message 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 : +---------+---------+---------+
Further TLV compression is indicated by the ICN LoWPAN dispatch in .
Dispatch Format for Compressed CCNx Content Objects 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 1 | 1 | 1 |FLG|FRS|PAY|RCT|MGH| PLTYP |EXP|VAL|RSV|CID|EXT| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
FLG: Flags field in the fixed header
See .
FRS: Reserved field in the fixed header
See .
PAY: Optional Payload TLV
See .
RCT: Optional hop-by-hop Recommended Cache Time TLV
0:
The Recommended Cache Time TLV is absent.
1:
The Recommended Cache Time TLV is present, and the Type and Length fields are elided.
MGH: Optional hop-by-hop MessageHash TLV
See for further details on the ordering of 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, and the Type and Length fields are removed. The 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, and T_PAYLOADTYPE_DATA is assumed.
10:
The PayloadType TLV is 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, and the Type and Length fields are elided.
VAL: Optional ValidationAlgorithm and ValidationPayload TLVs
See .
RSV: Reserved
Must be set to 0.
CID: Context Identifier
See .
EXT: Extension
0:
No extension byte follows.
1:
Extension byte EXT_0 follows immediately. See .
Hop-By-Hop Header TLVs Compression Hop-by-hop header TLVs are unordered. For a Content Object message, two optional hop-by-hop header TLVs are defined in , but several more can be defined in higher-level specifications. For the compression specified in the previous section, the hop-by-hop TLVs are ordered as follows:
  1. Recommended Cache Time TLV
  2. Message Hash TLV
Note: All hop-by-hop header TLVs other than the RecommendedCacheTime and MessageHash TLVs remain uncompressed in the encoded message, and they appear after the RecommendedCacheTime and MessageHash TLVs in the same order as in the original message.
Dispatch Extension The EXT_0 byte follows the description in and is illustrated in .
EXT_0 Format 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | NCS | RSV |EXT| +---+---+---+---+---+---+---+---+
NCS: Name Compression Strategy
00:
Names are compressed with the default name compression strategy (see ).
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.
Compressed Time Encoding This document adopts the 8-bit compact time representation for relative time-values described in with the constant factor C set to C := 1/32. Valid time offsets in CCNx and NDN 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 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, b := exponent):
Subnormal (b == 0):
(0 + a/8) * 2 * C
Normalized (b > 0):
(1 + a/8) * 2b * C (see )
This configuration allows for the following ranges:
  • Minimum subnormal number: 0 seconds
  • 2nd minimum subnormal number: ~0.007812 seconds
  • Maximum subnormal number: ~0.054688 seconds
  • Minimum normalized number: ~0.062500 seconds
  • 2nd minimum normalized number: ~0.070312 seconds
  • 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.
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 exchange may be removed from ICN stateful forwarding on a hop-by-hop basis and memorized in en route state tables.
LoWPAN-Local State A 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.
Context Identifier 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | X | CID | +---+---+---+---+---+---+---+---+
The 7-bit CID is a locally scoped unique identifier that represents the context state shared between the sender and receiver of the corresponding frame (see ). If set, the most significant bit indicates the presence of another, subsequent CID byte (see ). The context state shared between senders and receivers is removed from the compressed packet prior to 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.
En Route State In CCNx and NDN, Name TLVs are included in Interest messages, and they return in Data messages. Returning Name TLVs either equal the original Name TLV or contain the original Name TLV as a prefix. ICN LoWPAN reduces this redundancy in responses by replacing Name TLVs with single bytes that represent link-local HopIDs. HopIDs are carried as Context Identifiers (see ) of link-local scope, as shown in .
Context Identifier as HopID 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | X | 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 TLV with a HopID (without en route compression) MUST invalidate the HopID by setting all ID bits to zero. While an Interest is traversing, a forwarder generates an ephemeral HopID that is tied to a 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 ).
Setting Compression State En Route (Interest) 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 | '---' '---' '---'
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, 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 ().
Eliding Name TLVs Using En Route State (Data) 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 | '---' '---' '---'
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.
Integrating Stateful Header Compression A CID appears whenever the CID flag is set (see ). The CID is appended to the last ICN LoWPAN dispatch byte, as shown in .
LoWPAN Encapsulation with ICN LoWPAN and CIDs ...-------+--------+-------...-------+--...-+-------... / ... | Page | ICN LoWPAN Disp.| CIDs | Payload / ...-------+--------+-------...-------+--...-+-------...
Multiple CIDs are chained together, with the most significant bit indicating the presence of a subsequent CID (). This allows the use of multiple shared contexts in compressed messages. The HopID is always included as the very first CID.
Chaining of Context Identifiers +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |1| CID / HopID | --> |1| CID | --> |0| CID | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
ICN LoWPAN Constants and Variables This is a summary of all ICN LoWPAN constants and variables.
DEFAULT_NDN_HOPLIMIT:
255
Implementation Report and Guidance The ICN LoWPAN scheme defined in this document has been implemented as an extension of the NDN/CCNx software stack in its IoT version on RIOT . An experimental evaluation for NDN over ICN LoWPAN with varying configurations has been performed in . Energy profiling and processing time measurements indicate significant energy savings, and the amortized costs for processing show no penalties.
Preferred Configuration The header compression performance depends on certain aspects and configurations. It works best for the following cases:
  • Signed time offsets compress, per , without the need for rounding.
  • The context state (e.g., prefixes) is distributed such that long names can be elided from Interest and Data messages.
  • Frequently used TLV type numbers for CCNx and NDN stay in the lower range (< 255).
Name components are of type GenericNameComponent and are limited to a length of 15 bytes to enable compression for all messages.
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:
  • The name compression scheme () is optimized for short name components of 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 (). As a preliminary analysis, investigates the effectiveness of the proposed compression scheme with URLs obtained from the WWW. Studies on deployments of Constrained Application Protocol (CoAP) can offer additional insights on naming schemes in the IoT.
  • The fragmentation scheme () inherited from 6LoWPAN allows for a transparent, hop-wise reassembly of CCNx or NDN packets. Fragment forwarding with selective fragment recovery can improve the end-to-end latency and reliability while it reduces buffer requirements on forwarders. Initial evaluations show that a naive integration of these upcoming fragmentation features into ICN LoWPAN renders the hop-wise content replication inoperative, since Interest and Data messages are reassembled end-to-end. More deployment experiences are necessary to gauge the feasibility of different fragmentation schemes in ICN LoWPAN.
  • The context state () 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.
  • The distribution and synchronization of the context state can potentially be adopted from 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.
  • The stateful en route compression () 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 PIT of memory-constrained devices. This number can serve as an upper bound and determines whether the HopID length needs to be resized to fit more HopIDs at the cost of additional header overhead.
  • Multiple implementations that generate and deploy the compression options of this memo in different ways will also add to the experience and understanding of the benefits and limitations of the proposed schemes. Different reports can help to illuminate the complexity of implementing ICN LoWPAN for constrained devices, as well as on maintaining interoperability with other implementations.
Security Considerations Main memory is typically a scarce resource of constrained networked devices. Fragmentation, as described in this 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 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 should be deployed. IEEE 802.15.4, e.g., provides capabilities to protect frames and restrict them to a point-to-point link or a group of devices.
IANA Considerations
Updates to the 6LoWPAN Dispatch Type Field Registry IANA has assigned dispatch values for ICN LoWPAN in the "Dispatch Type Field" subregistry of the "IPv6 Low Power Personal Area Network Parameters" registry. represents the updates to the registry. Dispatch Types for NDN and CCNx
Bit Pattern Page Header Type Reference
00 000000 14 Uncompressed NDN Interest messages RFC 9139
00 01xxxx 14 Compressed NDN Interest messages RFC 9139
00 100000 14 Uncompressed NDN Data messages RFC 9139
00 11xxxx 14 Compressed NDN Data messages RFC 9139
01 000000 14 Uncompressed CCNx Interest messages RFC 9139
01 01xxxx 14 Compressed CCNx Interest messages RFC 9139
01 100000 14 Uncompressed CCNx Content Object messages RFC 9139
01 11xxxx 14 Compressed CCNx Content Object messages RFC 9139
References Normative References IEEE Standard for Floating-Point Arithmetic IEEE IEEE Standard for Low-Rate Wireless Networks IEEE Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Transmission of IPv6 Packets over IEEE 802.15.4 Networks This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK] Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs) This document describes a general and flexible TLV (type-length-value structure) for representing time-values, such as an interval or a duration, using the generalized Mobile Ad hoc NETwork (MANET) packet/ message format. It defines two Message TLVs and two Address Block TLVs for representing validity and interval times for MANET routing protocols. [STANDARDS-TRACK] Using Self-Delimiting Numeric Values in Protocols Self-Delimiting Numeric Values (SDNVs) have recently been introduced as a field type in proposed Delay-Tolerant Networking protocols. SDNVs encode an arbitrary-length non-negative integer or arbitrary- length bitstring with minimum overhead. They are intended to provide protocol flexibility without sacrificing economy and to assist in future-proofing protocols under development. This document describes formats and algorithms for SDNV encoding and decoding, along with notes on implementation and usage. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document is not an Internet Standards Track specification; it is published for informational purposes. Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. [STANDARDS-TRACK] Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References CCN-lite, a lightweight implementation of the CCNx protocol and its variations Designing a LoWPAN convergence layer for the Information Centric Internet of Things HAW Hamburg HAW Hamburg HAW Hamburg FU Berlin Computer Communications, Vol. 164, No. 1, p. 114–123, Elsevier File-Like ICN Collections (FLIC) University of Basel University of California Irvine PARC, Inc. Network Systems Research & Design Work in Progress Networking named content 5th Int. Conf. on emerging Networking Experiments and Technologies (ACM CoNEXT) Information centric networking in the IoT: experiments with NDN in the wild INRIA FU Berlin INRIA HAW Hamburg FU Berlin Proc. of 1st ACM Conf. on Information-Centric Networking (ICN-2014) ACM DL, pp. 77-86 NDN, CoAP, and MQTT: a comparative measurement study in the IoT HAW Hamburg HAW Hamburg FU Berlin FU Berlin HAW Hamburg FU Berlin Proc. of 5th ACM Conf. on Information-Centric Networking (ICN-2018) ACM DL, pp. 159-171 The need for a name to MAC address mapping in NDN: towards quantifying the resource gain HAW Hamburg HAW Hamburg HAW Hamburg riot-os.org FU Berlin Proc. of 4th ACM Conf. on Information-Centric Networking (ICN-2017) ACM DL, pp. 36-42 NDN Packet Format Specification Terminology for Constrained-Node Networks The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. The Constrained Application Protocol (CoAP) The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. Information-Centric Networking: Baseline Scenarios This document aims at establishing a common understanding about a set of scenarios that can be used as a base for the evaluation of different information-centric networking (ICN) approaches so that they can be tested and compared against each other while showcasing their own advantages. Towards this end, we review the ICN literature and document scenarios which have been considered in previous performance evaluation studies. We discuss a variety of aspects that an ICN solution can address. This includes general aspects, such as, network efficiency, reduced complexity, increased scalability and reliability, mobility support, multicast and caching performance, real-time communication efficiency, energy consumption frugality, and disruption and delay tolerance. We detail ICN-specific aspects as well, such as information security and trust, persistence, availability, provenance, and location independence. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG). Information-Centric Networking (ICN) Research Challenges This memo describes research challenges for Information-Centric Networking (ICN), an approach to evolve the Internet infrastructure to directly support information distribution by introducing uniquely named data as a core Internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling or enhancing a number of desirable features, such as security, user mobility, multicast, and in-network caching. Mechanisms for realizing these benefits is the subject of ongoing research in the IRTF and elsewhere. This document describes current research challenges in ICN, including naming, security, routing, system scalability, mobility management, wireless networking, transport services, in-network caching, and network management. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG). Information-Centric Networking: Evaluation and Security Considerations This document presents a number of considerations regarding evaluating Information-Centric Networking (ICN) and sheds some light on the impact of ICN on network security. It also surveys the evaluation tools currently available to researchers in the ICN area and provides suggestions regarding methodology and metrics. IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch This specification updates RFC 4944 to introduce a new context switch mechanism for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) compression, expressed in terms of Pages and signaled by a new Paging Dispatch. Content-Centric Networking (CCNx) Semantics This document describes the core concepts of the Content-Centric Networking (CCNx) architecture and presents a network protocol based on two messages: Interests and Content Objects. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding. The protocol also uses a control message called an Interest Return, whereby one system can return an Interest message to the previous hop due to an error condition. This indicates to the previous hop that the current system will not respond to the Interest. This document is a product of the Information-Centric Networking Research Group (ICNRG). The document received wide review among ICNRG participants. Two full implementations are in active use and have informed the technical maturity of the protocol specification. Content-Centric Networking (CCNx) Messages in TLV Format Content-Centric Networking (CCNx) is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. This document specifies the encoding of CCNx messages in a TLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification. This document is a product of the Information Centric Networking research group (ICNRG). The document received wide review among ICNRG participants and has two full implementations currently in active use, which have informed the technical maturity of the protocol specification. On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network This document provides generic rules to enable the forwarding of an IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) fragment over a route-over network. Forwarding fragments can improve both end-to-end latency and reliability as well as reduce the buffer requirements in intermediate nodes; it may be implemented using RFC 4944 and Virtual Reassembly Buffers (VRBs). IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery This document updates RFC 4944 with a protocol that forwards individual fragments across a route-over mesh and recovers them end to end, with congestion control capabilities to protect the network. RIOT: An Open Source Operating System for Low-End Embedded Devices in the IoT INRIA HAW Hamburg INRIA and FU Berlin HAW Hamburg FU Berlin FU Berlin INRIA and FU Berlin HAW Hamburg FU Berlin IEEE Internet of Things Journal Vol. 5, No. 6, p. 4428-4440 Connecting the Dots: Selective Fragment Recovery in ICNLoWPAN FU Berlin HAW Hamburg HAW Hamburg FU Berlin Proc. of 7th ACM Conf. on Information-Centric Networking (ICN-2020) ACM DL, pp. 70-76 CCN and NDN TLV encodings in 802.15.4 packets CCN/NDN Protocol Wire Format and Functionality Considerations
Estimated Size Reduction In the following, a theoretical evaluation is given to estimate the gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages. We assume that n is the number of name 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. The lengths of TLV components are specific to the CCNx or NDN encoding and are outlined below.
NDN The NDN TLV encoding has variable-sized TLV fields. For simplicity, the 1-byte form of each TLV component is assumed. A typical TLV component therefore is of size 2 (Type field + Length field) + the actual value.
Interest depicts the size requirements for a basic, uncompressed NDN Interest containing a CanBePrefix TLV, a MustBeFresh TLV, an InterestLifetime TLV set to 4 seconds, and a HopLimit TLV set to 6. Numbers below represent the amount of bytes.
Estimated Size of an Uncompressed NDN Interest ------------------------------------, Interest TLV = 2 | ---------------------, | Name | 2 + | NameComponents = 2n + | | comps_n | ---------------------' = 21 + 2n + comps_n CanBePrefix = 2 | MustBeFresh = 2 | Nonce = 6 | InterestLifetime = 4 | HopLimit = 3 | ------------------------------------'
depicts the size requirements after compression.
Estimated Size of a Compressed NDN Interest ------------------------------------, Dispatch Page Switch = 1 | NDN Interest Dispatch = 2 | Interest TLV = 1 | -----------------------, | Name | | NameComponents = n/2 + = 10 + n/2 + comps_n | comps_n | -----------------------' | Nonce = 4 | HopLimit = 1 | InterestLifetime = 1 | ------------------------------------'
The size difference is 11 + 1.5n bytes. For the name /DE/HH/HAW/BT7, the total size gain is 17 bytes, which is 43% of the uncompressed packet.
Data depicts the size requirements for a basic, uncompressed NDN Data containing a FreshnessPeriod as MetaInfo. A FreshnessPeriod of 1 minute is 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.
Estimated Size of an Uncompressed NDN Data ------------------------------------, 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 | | ---------------------' | ------------------------------------'
depicts the size requirements for the compressed version of the above Data packet.
Estimated Size of a Compressed NDN Data ------------------------------------, 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 | ------------------------------------'
The size difference is 15 + 1.5n bytes. For the name /DE/HH/HAW/BT7, the total size gain is 21 bytes.
CCNx The CCNx TLV encoding defines a 2-byte encoding for Type and Length fields, summing up to 4 bytes in total without a value.
Interest depicts the size requirements for a basic, uncompressed CCNx Interest. No hop-by-hop TLVs are included, the protocol version is assumed to be 1, and the 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.
Estimated Size of an Uncompressed CCNx Interest ------------------------------------, Fixed Header = 8 | Message = 4 | ---------------------, | Name | 4 + = 56 + 4n + comps_n NameSegments = 4n + | | comps_n | ---------------------' | KeyIdRestriction = 40 | ------------------------------------'
depicts the size requirements after compression.
Estimated Size of a Compressed CCNx Interest ------------------------------------, 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 | ------------------------------------'
The size difference is 18 + 3.5n bytes. For the name /DE/HH/HAW/BT7, the size is reduced by 53 bytes, which is 53% of the uncompressed packet.
Content Object depicts the size requirements for a basic, uncompressed CCNx Content Object containing an ExpiryTime Message TLV, an HMAC_SHA-256 signature, the signature time, and a hash of the shared secret key. In the fixed header, the protocol version is assumed to be 1 and the Reserved field is assumed to be 0
Estimated Size of an Uncompressed CCNx Content Object ------------------------------------, 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 | | SignatureTime | | ---------------------' | ValidationPayload = 36 | ------------------------------------'
depicts the size requirements for a basic, compressed CCNx Data.
Estimated Size of a Compressed CCNx Data Object ------------------------------------, 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 | ------------------------------------'
The size difference is 35 + 3.5n bytes. For the name /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 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) , , , , and . The hop-wise stateful name compression was brought up in a discussion by , which is gratefully acknowledged. Larger parts of this work are inspired by and . Special mention goes to , as well as and , as their previous work in and provided a good base for our discussions on stateless header compression mechanisms. Many thanks also to and , 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 HAW Hamburg
Berliner Tor 7 Hamburg D-20099 Germany +4940428758067 cenk.guendogan@haw-hamburg.de http://inet.haw-hamburg.de/members/cenk-gundogan
HAW Hamburg
Berliner Tor 7 Hamburg D-20099 Germany t.schmidt@haw-hamburg.de http://inet.haw-hamburg.de/members/schmidt
link-lab & FU Berlin
Hoenower Str. 35 Berlin D-10318 Germany mw@link-lab.net https://www.mi.fu-berlin.de/en/inf/groups/ilab/members/waehlisch.html
University of Applied Sciences and Arts Northwestern Switzerland
Peter Merian-Str. 86 Basel 4002 Switzerland christopher.scherb@fhnw.ch
University of Basel
Spiegelgasse 1 Basel 4051 Switzerland claudio.marxer@unibas.ch
University of Basel
Spiegelgasse 1 Basel 4051 Switzerland christian.tschudin@unibas.ch