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 http://www.inf.fu-berlin.de/~waehl

University of Basel

Spiegelgasse 1 Basel CH-4051 Switzerland christopher.scherb@unibas.ch

University of Basel

Spiegelgasse 1 Basel CH-4051 Switzerland claudio.marxer@unibas.ch

University of Basel

Spiegelgasse 1 Basel CH-4051 Switzerland christian.tschudin@unibas.ch

ICN Research Group In this document, a convergence layer for CCNx and NDN over IEEE 802.15.4 LoWPAN networks is defined. 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 is extended to include new dispatch types for CCNx and NDN. Additionally, the link fragmentation component of the 6LoWPAN dispatching framework is applied to ICN chunks. Basic improvements in efficiency are advised by stateless and stateful compression schemes.

The Internet of Things (IoT) has been identified as a promising deployment area for Information Centric Networks (ICN), as infrastructureless access to content, resilient forwarding, and in-network data replication have shown noteable advantages over the traditional host-to-host approach on the Internet , . 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 octets. The maximum frame header size is 25 octets, which leaves 102 octets for the payload. IEEE 802.15.4 security features further reduce this payload length by up to 21 octets, yielding a net of 81 octets for CCNx or NDN packet headers, signatures and content. 6LoWPAN is a convergence layer that provides frame formats, header compression and link 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 IEEE 802.15.4 payload and meta information about link fragmentation. Prevalent Type-Length-Value (TLV) based packet formats 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 that compresses packet headers of CCNx as well as NDN and allows for an increased payload size per packet. Additionally by reusing the dispatching framwork defined by 6LoWPAN, compatibility between coexisting wireless networks of competing technologies is enabled. This also allows to reuse the link fragmentation scheme specified by 6LoWPAN for ICN LoWPAN. ICN LoWPAN utilizes 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 largely. For further reductions, default header values suitable for constrained IoT networks are selected in order to elide corresponding TLVs. In a typical IoT scenario (see ), embedded devices are interconnected via quasi-stationary infrastructure whith a border router (BR) interconnecting the constrained LoWPAN networks via some Gateway with the public Internet. In ICN based IoT networks, Interest and Data messages transparently travel through the BR up and down between a Gateway and the embedded devices within the constrained LoWPANs.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 . The use of the term, "silently ignore" is not defined in RFC 2119. However, the term is used in this document and can be similarly construed. This document uses the terminology of , , and for ICN entities. The following terms are used in the document and defined as follows: Information-Centric Networking over Low-power Wireless Personal Area Network Low-Power and Lossy Network Content-Centric Networking Architecture Named Data Networking

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 .

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.

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 pre-configuration of 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 variable-sized 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 mandatory and 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 codomain 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 the length fields are removed. The third TLV represents a boolean TLV (e.g. the MustBeFresh selector in NDN) and is missing the type, length and the value field.

ICN LoWPAN further employs 2 stateful compression schemes to enhance size reductions. These mechanisms rely on shared contexts that are either distributed and maintained in the whole LoWPAN, or are generated on-demand for a particular Interest-data path.

A context identifier (CID) is a 1-octet wide number that refers to a particular conceptual context between network devices and MAY be used to replace frequently appearing information, like name prefixes, suffixes, or meta information, such as Interest lifetime. The initial distribution and maintenance of shared context is out of scope. Frames containing unknown or invalid CIDs are silently discarded.

In CCNx and NDN, Name TLVs are included in Interest messages, and they return in data messages. Returning Name TLVs either equal to the original Name TLV, or they contain the original Name TLV as a prefix. ICN LoWPAN reduces this duplication in responses by replacing Name TLVs with 1-octet wide HopIDs. While an Interest is forwarded, each hop generates an ephemeral HopID that is tied to a PIT entry. Each HopID MUST be unique within the local PIT and only exist 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 ).

| B | ------------------------> | C | '---' '---' '---' ]]>

Responses include HopIDs that were obtained from Interests. If the returning Name TLV equals the original Name TLV, then the name is elided fully. Otherwise, the distinct 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 before forwarding the reponse ().

The IEEE 802.15.4 frame header does not provide a protocol identifier for its payload. This causes problems of misinterpreting frames when several networks coexist on the same link layer. To mitigate errors, 6LoWPAN defines dispatches as encapsulation headers for IEEE 802.15.4 frames (see Section 5 of ). Multiple LoWPAN encapsulation headers can prepend 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, then all following encapsulation headers are interpreted by using a dispatch table as specified by the Page switch header. Page 0 and page 1 are reserved for 6LoWPAN. This document uses page 2 (1111 0010 (0xF2)) for NDN and page 3 (1111 0011 (0xF3)) for CCNx. The base dispatch format () is used and extended by CCNx and NDN in and .

The message is uncompressed. The message is compressed. The payload contains a Interest message. The payload contains a Data message. The encapsulation format for ICN LoWPAN identifying an NDN Interest message is exemplarily displayed in .

The IEEE 802.15.4 header. Optional additional dispatch types. Page Switch 2 (0xF2) for NDN. NDN dispatches as defined in . The actual (un-)compressed NDN Interest.

Section 5.3 of 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 the fragmentation handling of . The Fragmentation LoWPAN header can encapsulate other dispatch headers. The order of dispatch types is adopted from . shows the fragmentation scheme. The reassembled ICN LoWPAN frame does not contain any fragmentation headers and is depicted in .

A CID is appended to the last ICN LoWPAN dispatch octet. Multiple CIDs are chained together, whereas the most significant bit indicates the presence of a subsequent CID ().

|1| CID | --> |0| CID | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ ]]>

The HopID is included as the very first CID. To distinguish the HopID from a typical LoWPAN-local CID, the 1st bit MUST be set (). This yields 64 distinct HopIDs. If this range (0..63) is exhausted, the messages MUST be sent without en-route state compression until new HopIDs are available.

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 octets. shows the NDN TLV encoding scheme. If the type or length number is less than 253, then that number is encoded into the actual type or length field ( a). If the number is greater or equals 253 and fits into 2 octets, then the type or lengh field is set to 253 and the number is encoded in the next following 2 octets in network byte order, i.e., from the most significant byte (MSB) to the least significant byte (LSB) ( b). If the number is greater than 2 octets and fits into 4 octets, then the type or length field is set to 254 and the number is encoded in the subsequent 4 octets in network byte order ( c). For greater numbers, the type or length field is set to 255 and the number is encoded in the subsequent 8 octets in network byte order ( d).

In this document, compressed NDN TLVs make use of a different TLV scheme that puts more emphasis on size reduction. Instead of using the first octet as a marker for the number of following octets, the compressed NDN TLV scheme uses a method to chain a variable number of octets together. If an octet equals 255 (0xFF), then the following octet will also be interpreted. The actual value of a chain equals the sum of all links. If the type or length number is less than 255, then that number is encoded into the actual type or length field ( a). If the type or length number (X) fits into 2 octets, then the first octet is set to 255 and the subsequent octet equals X mod 255 ( b). Following this scheme, a variable-sized number (X) is encoded using multiple octets of 255 with a trailing octet containing X mod 255 ( c).

This Name TLV compression encodes length fields of two consecutive NameComponent TLVs into one octet, using 4 bits each. This process limits the length of a NameComponent TLV to 15 octets. A length of 0 marks the end of the compressed Name TLV.

An uncompressed Interest message uses the base dispatch format (see ) and sets the C as well as the M flag to 0 (). resv MUST be set to 0. The Interest message is handed to the NDN network stack without modifications.

The compressed Interest message uses the base dispatch format and sets the C flag to 1 and the M flag to 0. By default, the Interest message is compressed with the following base rule set: The Type field of the outermost MessageType TLV is removed. The Name TLV is compressed according to . For this, all NameComponents are expected to be of type GenericNameComponent. Otherwise, the message MUST be sent uncompressed. The InterestLifetime TLV length is set to 2. Messages with lifetimes that require more than 2 octets MUST be sent uncompressed. The Nonce TLV, InterestLifetime TLV and HopLimit TLV MUST be moved to the end of the compressed Interest, keeping the order 1) Nonce TLV, 2) InterestLifetime TLV and 3) HopLimit TLV. The Type and Length fields of Nonce TLV, InterestLifetime TLV and HopLimit TLV are elided. The presence of each TLV is deduced from the remaining length to parse. The Nonce TLV has a fixed length of 4, the InterestLifetime TLV has a fixed length of 2 and the HopLimit TLV has a fixed length of 1. Any combination yields a distinct value that matches the remaining length to parse. Further TLV compression is indicated by the ICN LoWPAN dispatch in .

The name does not include an ImplicitSha256DigestComponent as the last TLV. The name does include an ImplicitSha256DigestComponent as the last TLV. The Type and Length fields are omitted. The uncompressed message does not include a CanBePrefix TLV. The uncompressed message does include a CanBePrefix TLV and is removed from the compressed message. The uncompressed message does not include a MustBeFresh TLV. The uncompressed message does include a MustBeFresh TLV and is removed from the compressed message. The uncompressed message does not include a ForwardingHint TLV. The uncompressed message does include a ForwardingHint TLV. The Type field is removed from the compressed message. The uncompressed message does not include a Parameters TLV. The uncompressed message does include a Parameters TLV. The Type field is removed from the compressed message. CID(s) are not appended to the dispatch octet. CID(s) are appended to the dispatch octet.

An uncompressed Data message uses the base dispatch format and sets the C flag to 0 and the M flag to 1 (). resv MUST be set to 0. The Data message is handed to the NDN network stack without modifications.

The compressed Data message uses the base dispatch format and sets the C flag as well as the M flag to 1. By default, the Data message is compressed with the following base rule set: The Type field of the outermost MessageType TLV is removed. The Name TLV is compressed according to . For this, all NameComponents are expected to be of type GenericNameComponent. Otherwise, the message MUST be sent uncompressed. The MetaInfo Type and Length fields are elided from the compressed Data message. If present, the FinalBlockId TLV is encoded according to . The ContentType TLV length is set to 1. Messages with ContentTypes that require more than 1 octet MUST be sent uncompressed. The FreshnessPeriod TLV length is set to 2. Messages with FreshnessPeriods that require more than 2 octets MUST be sent uncompressed. The FreshnessPeriod TLV and ContntType TLV MUST be moved to the end of the compressed Data, keeping the order 1) FreshnessPeriod TLV and 2) ContentType TLV. The Type and Length fields of ContentType TLV and FreshnessPeriod TLV are elided. The presence of each TLV is deduced from the remaining length to parse. The FreshnessPeriod TLV has a fixed length of 2 and the ContentType TLV has a fixed length of 1. Any combination yields a distinct value that matches the remaining length to parse. Further TLV compression is indicated by the ICN LoWPAN dispatch in .

The name does not include an ImplicitSha256DigestComponent as the last TLV. The name does include an ImplicitSha256DigestComponent as the last TLV. The Type and Length fields are omitted. The uncompressed message does not include a FinalBlockId TLV. The uncompressed message does include a FinalBlockId. The uncompressed message does not include a Content TLV. The uncompressed message does include a Content TLV. The Type field is removed from the compressed message. The Type fields of the SignatureInfo TLV, SignatureType TLV and SignatureValue TLV are removed. Reserved. Reserved. Reserved. CID(s) are not appended to the dispatch octet. CID(s) are appended to the dispatch octet.

The CCNx TLV encoding is described in . Type and Length fields attain the common fixed length of 2 octets. In this document, the TLV encoding is changed to the more space efficient encoding described in . Type and Length fields MUST be encoded as in .

Name TLVs are compressed using the same approach outlined in . If a Name TLV contains T_IPID, T_APP, or organizational TLVs, then the name remains uncompressed.

An uncompressed Interest message uses the base dispatch format (see ) and sets the C as well as the M flag to 0 (). resv MUST be set to 0. The Interest message is handed to the CCNx network stack without modifications.

The compressed Interest message uses the base dispatch format and sets the C flag to 1 and the M flag to 0. By default, the Interest message is compressed with the following base rule set: The Type and Length fields of the CCNx Message TLV are elided and are obtained from the Fixed Header on decompression. Further TLV compression is indicated by the ICN LoWPAN dispatch in .

The Flags field equals 0 and is removed from the Interest message. The Flags field is carried in-line. No Hop-By-Hop Header TLVs are present in the Interest message. Also, the HeaderLength field in the fixed header is elided from the Interest message and assumed to be 8. Uncompressed Hop-By-Hop Header TLVs are present in the Interest message. Hop-By-Hop Header TLVs are present in the Interest message. An additional octet follows immediately that handles Hop-By-Hop Header TLV compressions and is described in . Reserved. The PacketType field is elided and assumed to be PT_INTEREST The PacketType field is elided and assumed to be PT_RETURN The HopLimit field is carried in-line The HopLimit field is elided and assumed to be 1 The Reserved field is carried in-line The Reserved field is elided and assumed to be 0 No Interest Message TLVs are present in the Interest message. Interest Message TLVs are present in the Interest message. An additional octet follows immediately that handles Interest Message TLV compressions and is described in . The Payload TLV is absent. The Payload TLV is present and the type field is elided. No validation related TLVs are present in the Interest message. Validation related TLVs are present in the Interest message. An additional octet follows immediately that handles validation related TLV compressions and is described in . No extension octet follows. An extension octet follows immediately. Extension octets are used to extend the compression scheme, but are out of scope of this document. CID(s) are not appended to the last dispatch octet. CID(s) are appended to the last dispatch octet.

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 better compression, an ordering of Hop-By-Hop TLVs is required as follows: Interest Lifetime TLV Message Hash TLV With this ordering in place, Type fields are elided from the Interest Lifetime TLV and the Message Hash TLV. Note: If the original Interest message includes Hop-By-Hop Header TLVs that follow a different ordering, then they remain uncompressed.

The Interest Lifetime TLV is absent. The Interest Lifetime TLV is present and the type field is removed. The Interest Lifetime TLV is absent and a default value of 0 seconds is assumed. The Interest Lifetime TLV is absent and a default value of 10 minutes is assumed. The Message Hash TLV is absent. The Message Hash TLV is present and uncompressed. A T_SHA-256 TLV is present and the type field as well as the length fields are removed. The length field is assumed to represent 32 octets. The outer Message Hash TLV is omitted. A T_SHA-512 TLV is present and the type field as well as the length fields are removed. The length field is assumed to represent 64 octets. The outer Message Hash TLV is omitted.

The KeyIdRestriction TLV is absent. The KeyIdRestriction TLV is present and uncompressed. A T_SHA-256 TLV is present and the type field as well as the length fields are removed. The length field is assumed to represent 32 octets. The outer KeyIdRestriction TLV is omitted. A T_SHA-512 TLV is present and the type field as well as the length fields are removed. The length field is assumed to represent 64 octets. The outer KeyIdRestriction TLV is omitted. The ContentObjectHashRestriction TLV is absent. The ContentObjectHashRestriction TLV is present and uncompressed. A T_SHA-256 TLV is present and the type field as well as the length fields are removed. The length field is assumed to represent 32 octets. The outer ContentObjectHashRestriction TLV is omitted. A T_SHA-512 TLV is present and the type field as well as the length fields are removed. The length field is assumed to represent 64 octets. The outer ContentObjectHashRestriction TLV is omitted.

An uncompressed ValidationAlgorithm TLV is included. A T_CRC32C ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV is included. A T_CRC32C ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV is included. Additionally, a Sigtime TLV is inlined without a type and a length field. A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV is included. A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV is inclued. Additionally, a Sigtime TLV is inlined without a type and a length field. Reserved. Reserved. Reserved. Reserved. Reserved. Reserved. Reserved. Reserved. Reserved. Reserved. Reserved. The KeyId TLV is absent. The KeyId TLV is present and uncompressed. A T_SHA-256 TLV is present and the type field as well as the length fields are removed. The length field is assumed to represent 32 octets. The outer KeyId TLV is omitted. A T_SHA-512 TLV is present and the type field as well as the length fields are removed. The length field is assumed to represent 64 octets. The outer KeyId TLV is omitted. The ValidationPayload TLV is present if the ValidationAlgorithm TLV is present. The type field is omitted.

An uncompressed Content object uses the base dispatch format (see ) and sets the C flag to 0 and the M flag to 1 (). resv MUST be set to 0. The Content object is handed to the CCNx network stack without modifications.

The compressed Content object uses the base dispatch format and sets the C flag as well as the M flag to 1. By default, the Content object is compressed with the following base rule set: The PacketType field is elided from the Fixed Header. The Type and Length fields of the CCNx Message TLV are elided and are obtained from the Fixed Header on decompression. Further TLV compression is indicated by the ICN LoWPAN dispatch in .

See . See HBH handling in . An additional octet that handles the Hop-By-Hop Header TLV compression is described in . See . No Content Object Message TLVs are present in the Content Object message. Content Object Message TLVs are present in the Content Object message. An additional octet follows immediately that handles Content Object Message TLV compressions and is described in . See . See . See . CID(s) are not appended to the last dispatch octet. CID(s) are appended to the last dispatch octet.

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 better compression, an ordering of Hop-By-Hop TLVs is required as follows: Recommended Cache Time TLV Message Hash TLV With this ordering in place, Type fields are elided from the Recommended Cache Time TLV and Message Hash TLV. Note: If the original Content Object message includes Hop-By-Hop Header TLVs with a different ordering, then they remain uncompressed.

The Recommended Cache Time TLV is absent. The Recommended Cache Time TLV is present and the type as well as the length fields are elided. See .

The PayloadType TLV is absent and T_PAYLOADTYPE_DATA is assumed. The PayloadType TLV is absent and T_PAYLOADTYPE_KEY is assumed. The PayloadType TLV is absent and T_PAYLOADTYPE_LINK is assumed. The PayloadType TLV is present and uncompressed. The ExpiryTime TLV is absent. The ExpiryTime TLV is present and the type as well as the length fields are elided.

Main memory is typically a constrained resource of constrained networked devices. Fragmentation as described in this memo preserves fragments and purges them only after a packet is reassembled. 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. Users are thus urged to make use of appropriate buffer replacement strategies for fragments. 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 security mechanisms for accessing the link-layer may strengthen robustness in real deployments.

This document makes use of Page 2 from the existing paging dispatches in .

INRIA FU Berlin INRIA HAW Hamburg FU Berlin HAW Hamburg HAW Hamburg FU Berlin FU Berlin HAW Hamburg FU Berlin HAW Hamburg HAW Hamburg HAW Hamburg riot-os.org FU Berlin

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 is specific to the CCNx or NDN encoding and outlined below.

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

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

depicts the size requirements after compression.

The size difference is: 12 + 1.5n octets. For the name /DE/HH/HAW/BT7, the total size gain is 18 octets, which is 46% of the uncompressed packet.

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

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

The size difference is: 15 + 1.5n octets. For the name /DE/HH/HAW/BT7, the total size gain is 21 octets.

The CCNx TLV encoding defines a 2-octet encoding for type and length fields, summing up to 4 octets in total without a value.

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

depicts the size requirements after compression.

The size difference is: 17 + 3.5n octets. For the name /DE/HH/HAW/BT7, the total size gain is 31 octets, which is 38% of the uncompressed packet.

depicts the size requirements for a basic, uncompressed CCNx Data containing an ExpiryTime Message TLV, an HMAC_SHA-256 signature, the signature time and a hash of the shared secret key.

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

The size difference is: 33 + 3.5n octets. For the name /DE/HH/HAW/BT7, the total size gain is 47 octets.

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, +++. 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 and . Special mentioning goes to Mark Mosko as well as G.Q. Wang and Ravi Ravindran as their previous work in and provided a good base for our discussions on stateless header compression mechanisms. This work was supported in part by the German Federal Ministry of Research and Education within the projects I3 and RAPstore.