RFC 9139
Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs)
RFC 9139: Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs) ๐ฆ
Okay bestie, here's the basic info first. ๐
- RFC number: 9139
- Stream: Internet Research Task Force (IRTF) ๐
- Category: Experimental ๐งช
- Date: November 2021 ๐
- ISSN: 2070-1721
- Authors: C. Gรผndoฤan, T. Schmidt, and M. Wรคhlisch (HAW Hamburg, plus link-lab & FU Berlin for Wรคhlisch), C. Scherb (FHNW), C. Marxer (no affiliation listed in the header), and C. Tschudin (University of Basel) ๐ฉโ๐ป
- Obsoletes / Updates: The header doesn't list anything it obsoletes or updates. ๐ โโ๏ธ
Abstract ๐ธ
Okay, so this document is a convergence layer for CCNx and NDN over IEEE 802.15.4 Low-Power Wireless Personal Area Networks (LoWPANs). ๐ฆ The big idea is a new frame format that squeezes CCNx and NDN packets down to fit the tiny MTU of IEEE 802.15.4. To make that happen, the TLV-based header formats get some syntactic and semantic changes. โจ
To keep things compatible with other LoWPAN tech sharing the same wireless medium, the dispatching scheme from IPv6 over LoWPAN (6LoWPAN) gets extended with new dispatch types for CCNx and NDN. ๐ On top of that, the fragmentation part of the 6LoWPAN dispatching framework is applied to ICN chunks. ๐งฉ
The second part of the document is where it gets really good: it defines stateless and stateful compression to boost efficiency on constrained links. ๐ฅ Stateless compression turns TLV expressions into static header fields for common use cases. Stateful compression elides states that are local to the LoWPAN, and it replaces names in Data packets with 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's published for examination, experimental implementation, and evaluation. ๐งช
It defines an Experimental Protocol for the Internet community. It's a product of the Internet Research Task Force (IRTF), which publishes the results of Internet-related research and development. Those results might not be suitable for deployment, fr fr. โ ๏ธ This RFC represents the consensus of the Information-Centric Networking Research Group of the IRTF. Documents approved for publication by the IRSG are not candidates for any level of Internet Standard. See Section 2 of RFC 7841 for that. ๐
You can find info about the current status of this document, any errata, and how to give feedback at https://www.rfc-editor.org/info/rfc9139. ๐
Copyright Notice ๐
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. ๐
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for this document. ๐
Table of Contents ๐
1. Introduction
2. Terminology
3. Overview of ICN LoWPAN
3.1. Link-Layer Convergence
3.2. Stateless Header Compression
3.3. Stateful Header Compression
4. IEEE 802.15.4 Adaptation
4.1. LoWPAN Encapsulation
4.1.1. Dispatch Extensions
4.2. Adaptation-Layer Fragmentation
5. Space-Efficient Message Encoding for NDN
5.1. TLV Encoding
5.2. Name TLV Compression
5.3. Interest Messages
5.3.1. Uncompressed Interest Messages
5.3.2. Compressed Interest Messages
5.3.3. Dispatch Extension
5.4. Data Messages
5.4.1. Uncompressed Data Messages
5.4.2. Compressed Data Messages
5.4.3. Dispatch Extension
6. Space-Efficient Message Encoding for CCNx
6.1. TLV Encoding
6.2. Name TLV Compression
6.3. Interest Messages
6.3.1. Uncompressed Interest Messages
6.3.2. Compressed Interest Messages
6.3.3. Dispatch Extension
6.4. Content Objects
6.4.1. Uncompressed Content Objects
6.4.2. Compressed Content Objects
6.4.3. Dispatch Extension
7. Compressed Time Encoding
8. Stateful Header Compression
8.1. LoWPAN-Local State
8.2. En Route State
8.3. Integrating Stateful Header Compression
9. ICN LoWPAN Constants and Variables
10. Implementation Report and Guidance
10.1. Preferred Configuration
10.2. Further Experimental Deployments
11. Security Considerations
12. IANA Considerations
12.1. Updates to the 6LoWPAN Dispatch Type Field Registry
13. References
13.1. Normative References
13.2. Informative References
Appendix A. Estimated Size Reduction
A.1. NDN
A.1.1. Interest
A.1.2. Data
A.2. CCNx
A.2.1. Interest
A.2.2. Content Object
Acknowledgments
Authors' Addresses1. Introduction โจ
The Internet of Things (IoT) is a promising place for Information-Centric Networking (ICN) to live. ๐ฑ Infrastructureless access to content, resilient forwarding, and in-network data replication show real perks compared to the usual Internet host-to-host approach [NDN-EXP1] [NDN-EXP2]. Recent studies [NDN-MAC] found that mapping ICN onto the right link-layer technology makes a huge difference to how it actually performs. ๐ That matters even more for IoT, where nodes often swap messages over low-power wireless links under lossy conditions. ๐ถ This memo covers the base adaptation of data chunks to those link layers for the ICN flavors NDN [NDN] and CCNx [RFC8569] [RFC8609]. ๐ง
The IEEE 802.15.4 [ieee802.15.4] link layer is used in low-power and lossy networks (see LLN in [RFC7228]). Devices there are usually battery operated and short on resources. ๐ LLNs are an unreliable environment with low-bandwidth transmissions and higher latencies. ๐ฅฒ IEEE 802.15.4 allows 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 can shave up to another 21 bytes off the payload, so you're left with a net of 81 bytes for CCNx or NDN packet headers, signatures, and content. ๐ญ
6LoWPAN [RFC4944] [RFC6282] is a convergence layer. It provides frame formats, header compression, and adaptation-layer fragmentation for IPv6 packets in IEEE 802.15.4 networks. ๐ Its adaptation adds a dispatching framework that prepends extra information to 6LoWPAN packets. That includes a protocol identifier for the payload and meta information about fragmentation. ๐
Prevalent packet formats built on Type-Length-Value (TLV), like the ones in CCNx and NDN, are generic and extensible, which is great, but it also makes headers verbose. ๐ That's a bad fit for the constrained environment of IEEE 802.15.4 links. This document presents ICN LoWPAN, a convergence layer for IEEE 802.15.4 that's motivated by 6LoWPAN. ICN LoWPAN compresses packet headers for both CCNx and NDN, and it lets each packet carry a bigger effective payload. ๐ฆ Reusing the 6LoWPAN dispatching framework also keeps coexisting wireless deployments of competing network technologies compatible. ๐ค And it lets ICN LoWPAN reuse the adaptation-layer fragmentation scheme that 6LoWPAN specifies. ๐งฉ
ICN LoWPAN defines a more space-efficient representation of CCNx and NDN packet formats. The syntactic change is described for CCNx and NDN separately, because their header formats and TLV encodings differ a lot. ๐ซ For further reductions, default header values that suit constrained IoT networks are selected so the matching TLVs can be elided. โ๏ธ Experimental evaluations of the ICN LoWPAN header compression schemes in [ICNLOWPAN] show less message overhead, shorter message airtime, and an overall drop in power consumption for typical Class 2 devices [RFC7228] compared to uncompressed ICN messages. โก
In a typical IoT scenario (see Figure 1), embedded devices are connected through a quasi-stationary infrastructure. A border router (BR) links the constrained LoWPAN network to the public Internet through some gateway. ๐ In ICN-based IoT networks, nonlocal Interest and Data messages travel transparently through the BR, going up and down between a gateway and the embedded devices inside the constrained LoWPAN. ๐ฆ
|Gateway Services|
-------------------------
|
,--------,
| |
| BR |
| |
'--------'
LoWPAN
O O
O
O O embedded
O O O devices
O O
Figure 1: IoT Stub NetworkThe document got fruitful reviews from members of the ICN community and the research group (see the Acknowledgments section) over a period of two years. ๐ฅฐ It's the consensus of ICNRG that this document should be published in the IRTF Stream of the RFC series. Just so we're clear, this document does not constitute an IETF standard. ๐โโ๏ธ
2. Terminology ๐ง
Here's the key words situation. 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 read as described in BCP 14 [RFC2119] [RFC8174]. They only count when they show up in all capitals, exactly like that. ๐ฏ Lowercase versions are just regular words, no cap. ๐ โโ๏ธ
This document uses the terminology of [RFC7476], [RFC7927], and [RFC7945] for ICN entities. ๐
Here are the terms used in the document and what they mean: ๐
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 ๐
3. Overview of ICN LoWPAN ๐ง
3.1. Link-Layer Convergence ๐ฆ
okay so ICN LoWPAN has this convergence layer ๐ which basically takes ICN packets and squishes them onto those tiny constrained link-layer techs. it also handles things like link-layer fragmentation, keeping protocols separated at the link layer, and mapping link-layer addresses. ๐ง the whole stack traversal is shown in Figure 2 below, and it's giving layers stacked on layers. obsessed ๐ญ
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 |
'----------------|-' '-|--------------|-' '-|----------------'
'--------' '---------'
Figure 2: ICN LoWPAN Convergence Layer for IEEE 802.15.4Section 4 of this document is where the convergence layer for IEEE 802.15.4 gets defined. ๐
3.2. Stateless Header Compression ๐
ICN LoWPAN also comes with a stateless header compression scheme, and its whole thing is shrinking ICN packet headers so they don't eat everything. this matters a LOT for link layers with small MTUs ๐ฅบ and the stateless compression doesn't need any global state to be preconfigured. no setup drama, just vibes โจ
ok so the CCNx and NDN header formats are built out of Type-Length-Value (TLV) fields to encode header data. the big win of TLV is that it handles variably structured data really nicely. the downside is that it's kinda verbose, because you're storing the type and length of every encoded piece of data. ๐
the stateless header compression scheme uses compact bit fields to say which optional TLVs are present in the uncompressed packet. the order of the set bits lines up with the order of the TLVs in the packet, which is so clever ๐ง and then it squeezes things even more by using default values and shrinking the range of certain header fields. iconic ๐
Figure 3 shows the idea in action. in this example, the first type of the first TLV gets removed and its bit in the bit field gets set. the second TLV is a fixed-length TLV (like the Nonce TLV in NDN), so its Type and Length fields get dropped. the third TLV is a boolean TLV (like the MustBeFresh selector in NDN), so its Type, Length, and Value fields all get elided. no cap, it's so efficient ๐ฆ
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
Figure 3: Compression Using a Compact Bit Field -- Bits Encode
the Inclusion of TLVsStateless TLV compression for NDN is defined in Section 5, and Section 6 covers the stateless TLV compression for CCNx. ๐ธ The extensibility of this compression is described in Section 4.1.1, and it lets future documents update the compression rules laid out here. future-proof king ๐
3.3. Stateful Header Compression ๐ง
ICN LoWPAN also uses two orthogonal, stateful compression schemes for shrinking packet sizes, and those are defined in Section 8. these mechanisms rely on shared contexts. the contexts are either distributed and kept around across the whole LoWPAN, or they get generated on demand hop-wise along a particular Interest-Data path. ๐
the shared context identification is defined in Section 8.1, and the hop-wise name compression "en route" is specified in Section 8.2. ๐
4. IEEE 802.15.4 Adaptation ๐
4.1. LoWPAN Encapsulation ๐ซถ
ok the IEEE 802.15.4 frame header doesn't have a protocol identifier for its payload ๐ฌ which causes chaos when multiple network layers share the same link, because frames can get misinterpreted. to fix that, 6LoWPAN defines dispatches as encapsulation headers for IEEE 802.15.4 frames (see Section 5 of [RFC4944]). multiple LoWPAN encapsulation headers can sit in front of the actual payload, and each one is identified by a dispatch type. โจ
[RFC8025] goes further and specifies dispatch Pages so you can switch between different contexts. when a LoWPAN parser hits a Page switch LoWPAN encapsulation header, all the encapsulation headers that follow get interpreted using a dispatch Page, as the Page switch header specifies. Pages 0 and 1 are reserved for 6LoWPAN. this document uses Page 14 (1111 1110 (0xFE)) for ICN LoWPAN. ๐
the base dispatch format in Figure 4 is used and then extended by CCNx and NDN in Sections 5 and 6. ๐
0 1 2 3 ...
+---+---+---+---+---
| 0 | P | M | C |
+---+---+---+---+---
Figure 4: Base Dispatch Format for ICN LoWPAN- P: Protocol
0: The included protocol is NDN.1: The included protocol is CCNx.
- M: Message Type
0: The payload contains an Interest message.1: The payload contains a Data message.
- C: Compression
0: The message is uncompressed.1: The message is compressed.
ICN LoWPAN frames with compressed CCNx and NDN messages (C=1) use the extended dispatch format in Figure 5. ๐ฆ
0 1 2 3 ... ...
+---+---+---+---+...+---+---+
| 0 | P | M | 1 | |CID|EXT|
+---+---+---+---+...+---+---+
Figure 5: Extended Dispatch Format for Compressed ICN LoWPAN- CID: Context Identifier
0: No context identifiers are present.1: Context identifier(s) are present (see Section 8.1).
- EXT: Extension
0: No extension bytes are present.1: Extension byte(s) are present (see Section 4.1.1).
the encapsulation format for ICN LoWPAN is shown in Figure 6. ๐ง
+------...------+------...-----+--------+-------...-------+-----...
| IEEE 802.15.4 | RFC4944 Disp.| Page | ICN LoWPAN Disp.| Payl. /
+------...------+------...-----+--------+-------...-------+-----...
Figure 6: LoWPAN Encapsulation with ICN LoWPAN- IEEE 802.15.4: The IEEE 802.15.4 header.
- RFC4944 Disp.: Optional additional dispatches defined in Section 5.1 of [RFC4944].
- Page: Page switch. 14 for ICN LoWPAN.
- ICN LoWPAN: Dispatches as defined in Sections 5 and 6.
- Payload: The actual (un-)compressed CCNx or NDN message.
4.1.1. Dispatch Extensions ๐ธ
extension bytes are what let the initial compression rule set grow over time ๐ฑ the base format for an extension byte is shown in Figure 7.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| - | - | - | - | - | - | - |EXT|
+---+---+---+---+---+---+---+---+
Figure 7: Base Format for Dispatch Extensions- EXT: Extension
0: No other extension byte follows.1: A further extension byte follows.
extension bytes get numbered by their order. future documents MUST follow the naming scheme EXT_0, EXT_1, ... when they update or refer to a specific dispatch extension byte. โ ๏ธ and if an amendment needs devices to swap configuration parameters, it SHOULD use manifests to encode structured data in a well-defined format, like the one outlined in [ICNRG-FLIC]. ๐ซถ
4.2. Adaptation-Layer Fragmentation ๐
small payload sizes in the LoWPAN mean fragmentation is needed for a bunch of network layers ๐ค so Section 5.3 of [RFC4944] defines a protocol-independent fragmentation dispatch type, a fragmentation header for the first fragment, and a separate fragmentation header for the subsequent fragments. ICN LoWPAN just adopts that fragmentation handling from [RFC4944]. slay, no need to reinvent the wheel ๐
the fragmentation LoWPAN header can encapsulate other dispatch headers. the order of dispatch types is defined in Section 5 of [RFC4944]. Figure 8 shows the fragmentation scheme, and the reassembled ICN LoWPAN frame has no fragmentation headers at all, as Figure 9 shows. ๐ฆ
+------...------+----...----+--------+------...-------+--------...
| IEEE 802.15.4 | Frag. 1st | Page | ICN LoWPAN | Payload /
+------...------+----...----+--------+------...-------+--------...
+------...------+----...----+--------...
| IEEE 802.15.4 | Frag. 2nd | Payload /
+------...------+----...----+--------...
.
.
.
+------...------+----...----+--------...
| IEEE 802.15.4 | Frag. Nth | Payload /
+------...------+----...----+--------...
Figure 8: Fragmentation Scheme
+------...------+--------+------...-------+--------...
| IEEE 802.15.4 | Page | ICN LoWPAN | Payload /
+------...------+--------+------...-------+--------...
Figure 9: Reassembled ICN LoWPAN Framethe 6LoWPAN Fragment Forwarding (6LFF) [RFC8930] is an alternative approach ๐ it lets fragments get forwarded without reassembling the packet on every intermediate hop. since it reuses the 6LoWPAN dispatching framework, 6LFF slots into ICN LoWPAN just as seamlessly as the conventional hop-wise fragmentation. BUT ๐ experimental evaluations [SFR-ICNLOWPAN] suggest that a more-refined integration can boost cache utilization of forwarders on a request path. the plot thickens ๐ฟ
5. Space-Efficient Message Encoding for NDN ๐งโจ
5.1. TLV Encoding โจ
okay so the NDN packet format is built out of TLV fields, using the TLV encoding described in [NDN-PACKET-SPEC]. ๐ The Type and Length fields are variable size, and numbers bigger than 252 get spread across multiple bytes. ๐
here's the deal: if the type or length number is less than 253, it just goes straight into the Type or Length field. ๐ฆ If the number is 253 or more and fits into 2 bytes, the field gets set to 253 and the number lives in the next 2 bytes, in network byte order (that's MSB first, then LSB). ๐ธ If it's bigger than 2 bytes but fits into 4, the field gets set to 254 and the number goes in the next 4 bytes in network byte order. ๐ And for really big numbers, the field is set to 255 and the number goes in the next 8 bytes in network byte order. ๐
now, in this specification, compressed NDN TLVs encode their Type and Length fields using self-delimiting numeric values (SDNVs) [RFC6256]. ๐ง These are the ones you might already know from Delay-Tolerant Networking (DTN) protocols. โจ The big difference is that instead of using the first byte as a marker for how many bytes follow, SDNVs use a single bit to say whether more bytes are coming. ๐
+==========+==========================+==========================+
| Value | NDN TLV Encoding | SDNV Encoding |
+==========+==========================+==========================+
| 0 | 0x00 | 0x00 |
+----------+--------------------------+--------------------------+
| 127 | 0x7F | 0x7F |
+----------+--------------------------+--------------------------+
| 128 | 0x80 | 0x81 0x00 |
+----------+--------------------------+--------------------------+
| 253 | 0xFD 0x00 0xFD | 0x81 0x7D |
+----------+--------------------------+--------------------------+
| 2^14 - 1 | 0xFD 0x3F 0xFF | 0xFF 0x7F |
+----------+--------------------------+--------------------------+
| 2^14 | 0xFD 0x40 0x00 | 0x81 0x80 0x00 |
+----------+--------------------------+--------------------------+
| 2^16 | 0xFE 0x00 0x01 0x00 0x00 | 0x84 0x80 0x00 |
+----------+--------------------------+--------------------------+
| 2^21 - 1 | 0xFE 0x00 0x1F 0xFF 0xFF | 0xFF 0xFF 0x7F |
+----------+--------------------------+--------------------------+
| 2^21 | 0xFE 0x00 0x20 0x00 0x00 | 0x81 0x80 0x80 0x00 |
+----------+--------------------------+--------------------------+
| 2^28 - 1 | 0xFE 0x0F 0xFF 0xFF 0xFF | 0xFF 0xFF 0xFF 0x7F |
+----------+--------------------------+--------------------------+
| 2^28 | 0xFE 0x1F 0x00 0x00 0x00 | 0x81 0x80 0x80 0x80 0x00 |
+----------+--------------------------+--------------------------+
| 2^32 | 0xFF 0x00 0x00 0x00 0x01 | 0x90 0x80 0x80 0x80 0x00 |
| | 0x00 0x00 0x00 0x00 | |
+----------+--------------------------+--------------------------+
| 2^35 - 1 | 0xFF 0x00 0x00 0x00 0x07 | 0xFF 0xFF 0xFF 0xFF 0x7F |
| | 0xFF 0xFF 0xFF 0xFF | |
+----------+--------------------------+--------------------------+
| 2^35 | 0xFF 0x00 0x00 0x00 0x08 | 0x81 0x80 0x80 0x80 0x80 |
| | 0x00 0x00 0x00 0x00 | 0x00 |
+----------+--------------------------+--------------------------+
Table 1: NDN TLV Encoding Compared to SDNVsTable 1 compares the bytes needed for a few picked values using NDN TLV encoding and SDNVs. ๐ For values up to 127, both methods need just one byte, honestly so cute. ๐ Values from 128 to 252 take one byte with NDN TLV, but SDNVs need two bytes. ๐ซถ Starting at 253, SDNVs need the same number of bytes or fewer than NDN TLV. ๐ฅ
5.2. Name TLV Compression โจ
this one is giving clever packing. ๐ Name TLV compression squishes the Length fields of two consecutive NameComponent TLVs into one byte, using one nibble for each. ๐ The most significant nibble tells you the length of the NameComponent TLV that comes right after, and the least significant nibble gives the length of the one after that. ๐ฆ 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) or 0xYF with Y > 0 (for an odd number of components). ๐ง This process caps a NameComponent TLV at 15 bytes, but there's no limit on how many components you can have. ๐ Figure 10 has an example. ๐
Name: /HAW/Room/481/Humid/99
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 1|0 1 0 0| H | A | W |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R | o | o | m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 1|0 1 0 1| 4 | 8 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H | u | m | i |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d |0 0 1 0|0 0 0 0| 9 | 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Name TLV Compression for /HAW/Room/481/Humid/995.3. Interest Messages โจ
5.3.1. Uncompressed Interest Messages ๐
okay so an uncompressed Interest message uses the base dispatch format (check out Figure 4) and sets the C, P, and M flags to 0 (Figure 11). ๐ฆ The Interest message gets handed to the NDN stack with no modifications at all. ๐ธ
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+---+---+---+---+---+---+---+---+
Figure 11: Dispatch Format for Uncompressed NDN Interest Messages5.3.2. Compressed Interest Messages ๐
okay so the compressed Interest message uses the extended dispatch format (Figure 5), sets the C flag to 1, and keeps the P and M flags at 0 ๐ง. If an Interest message has any TLVs that the compression rules below don't mention, this message MUST be sent uncompressed. no exceptions, bestie ๐
we're assuming every Interest already has a HopLimit TLV ๐ซ. if it's missing, one gets slipped in with a default value of DEFAULT_NDN_HOPLIMIT before compression happens โจ
in the default use case, the Interest gets squished with this minimal rule set ๐ธ
- The Type field of the outermost
MessageTypeTLV gets removed. - The Name TLV gets compressed according to Section 5.2 ๐งฉ. all the NameComponents are supposed to be
GenericNameComponenttype with a length greater than 0. anImplicitSha256DigestComponentorParametersSha256DigestComponentMAY show up at the end of the name. in any other case, the message MUST be sent uncompressed ๐ - The Nonce TLV and InterestLifetime TLV get moved to the end of the compressed Interest, as shown in Figure 12 ๐. The InterestLifetime is encoded as described in Section 7. on decompression, this encoding may yield an InterestLifetime that is smaller than the original value ๐ฅบ
- The Type and Length fields of the Nonce TLV, HopLimit TLV, and InterestLifetime TLV get elided ๐ซถ. the Nonce value has a length of 4 bytes, and the HopLimit value has a length of 1 byte. the compressed InterestLifetime (Section 7) has a length of 1 byte. the presence of a Nonce TLV and InterestLifetime TLV gets deduced from the remaining length to parse. a remaining length of 1 means there's an InterestLifetime, a length of 4 means there's a nonce, and a length of 5 means both TLVs are there ๐ฅ
The compressed NDN LoWPAN Interest message is visualized in Figure 12 ๐ฆ
T = Type, L = Length, V = Value
Lc = Compressed Length, Vc = Compressed Value
: = optional field, | = mandatory field
+---------+---------+ +---------+
| Msg T | Msg L | | Msg Lc |
+---------+---------+---------+ +---------+
| Name T | Name L | Name V | | Name Vc |
+---------+---------+---------+ +---------+---------+
: CBPfx T : CBPfx L : : FWDH Lc : FWDH Vc :
+---------+---------+ +---------+---------+
: MBFr T : MBFr L : | HPL V |
+---------+---------+---------+ ==> +---------+---------+
: FWDH T : FWDH L : FWDH V : : APM Lc : APM Vc :
+---------+---------+---------+ +---------+---------+
: NONCE T : NONCE L : NONCE V : : NONCE V :
+---------+---------+---------+ +---------+
: ILT T : ILT L : ILT V : : ILT Vc :
+---------+---------+---------+ +---------+
: HPL T : HPL L : HPL V :
+---------+---------+---------+
: APM T : APM L : APM V :
+---------+---------+---------+
Figure 12: Compression of NDN LoWPAN Interest Messagefurther TLV compression is signalled by the ICN LoWPAN dispatch in Figure 13 ๐
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 1 |PFX|FRE|FWD|APM|DIG| RSV |CID|EXT|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 13: Dispatch Format for Compressed NDN Interest Messageshere's the breakdown of each flag ๐
PFX: CanBePrefix TLV- 0: The uncompressed message does not include a CanBePrefix TLV.
- 1: The uncompressed message does include a CanBePrefix TLV, and it 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 it 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. Also, all link delegation types and link preference types are removed. All included names are compressed according to Section 5.2. If any name is not compressible, the message MUST be sent uncompressed.
APM: ApplicationParameters TLV- 0: The uncompressed message does not include an ApplicationParameters TLV.
- 1: The uncompressed message does include an ApplicationParameters TLV. The Type field is removed from the compressed message.
DIG: ImplicitSha256DigestComponent TLV- 0: The name does not include an ImplicitSha256DigestComponent as the last TLV.
- 1: The name does include an ImplicitSha256DigestComponent as the last TLV. The Type and Length fields are omitted.
RSV: Reserved- Must be set to 0.
CID: Context Identifier- See Figure 5.
EXT: Extension- 0: No extension byte follows.
- 1: Extension byte EXT_0 follows immediately. See Section 5.3.3.
5.3.3. Dispatch Extension ๐ง
the EXT_0 byte follows the description in Section 4.1.1 and is illustrated in Figure 14 ๐
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| NCS | RSV |EXT|
+---+---+---+---+---+---+---+---+
Figure 14: EXT_0 FormatNCS: Name Compression Strategy- 00: Names are compressed with the default name compression strategy (see Section 5.2).
- 01: Reserved.
- 10: Reserved.
- 11: Reserved.
RSV: Reserved- Must be set to 0.
EXT: Extension- 0: No extension byte follows.
- 1: A further extension byte follows immediately.
5.4. Data Messages ๐
5.4.1. Uncompressed Data Messages ๐ท
an uncompressed Data message uses the base dispatch format, sets the C and P flags to 0, and sets the M flag to 1 (Figure 15) ๐ซง. the Data message gets handed to the NDN stack without any modifications โจ
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 |
+---+---+---+---+---+---+---+---+
Figure 15: Dispatch Format for Uncompressed NDN Data Messages5.4.2. Compressed Data Messages ๐
the compressed Data message uses the extended dispatch format (Figure 5), sets the C and M flags to 1, and sets the P flag to 0 ๐. if a Data message has any TLVs that the compression rules below don't mention, this message MUST be sent uncompressed.
by default, the Data message gets compressed with this base rule set ๐
- The Type field of the outermost
MessageTypeTLV gets removed. - The Name TLV gets compressed according to Section 5.2 ๐งฉ. all the NameComponents are supposed to be
GenericNameComponenttype and have a length greater than 0. in any other case, the message MUST be sent uncompressed ๐ญ - The
MetaInfoTLV Type and Length fields get elided from the compressed Data message ๐ซถ. - The FreshnessPeriod TLV MUST be moved to the end of the compressed Data message ๐. Its Type and Length fields are elided, and the value is encoded as described in Section 7 as a 1-byte time-code. if the freshness period is not a valid time-value, then the message MUST be sent uncompressed to keep the security envelope of the Data message safe ๐ก๏ธ. the presence of a FreshnessPeriod TLV gets deduced from the remaining one-byte length to parse.
- The Type fields of the SignatureInfo TLV, SignatureType TLV, and SignatureValue TLV get removed ๐ธ.
The compressed NDN LoWPAN Data message is visualized in Figure 16 ๐ฆ
T = Type, L = Length, V = Value
Lc = Compressed Length, Vc = Compressed Value
: = optional field, | = mandatory field
+---------+---------+ +---------+
| Msg T | Msg L | | Msg Lc |
+---------+---------+---------+ +---------+
| Name T | Name L | Name V | | Name Vc |
+---------+---------+---------+ +---------+---------+
: Meta T : Meta L : : CTyp Lc : 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 |
+---------+---------+---------+
Figure 16: Compression of NDN LoWPAN Data Messagefurther TLV compression is signalled by the ICN LoWPAN dispatch in Figure 17 โญ
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 0 | 1 | 1 |FBI|CON|KLO| RSV |CID|EXT|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 17: Dispatch Format for Compressed NDN Data Messagesand here's what each of those flags means ๐
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 Section 5.2. If the FinalBlockId TLV is not compressible, then the message MUST be sent uncompressed.
CON: ContentType TLV- 0: The uncompressed message does not include a ContentType TLV.
- 1: The uncompressed message does include a ContentType TLV. The Type field is removed from the compressed message.
KLO: KeyLocator TLV- 0: If the included SignatureType requires a KeyLocator TLV, then the KeyLocator represents a name and is compressed according to Section 5.2. If the name is not compressible, then the message MUST be sent uncompressed.
- 1: If the included SignatureType requires a KeyLocator TLV, then the KeyLocator represents a KeyDigest. The Type field of this KeyDigest is removed.
RSV: Reserved- Must be set to 0.
CID: Context Identifier- See Figure 5.
EXT: Extension- 0: No extension byte follows.
- 1: Extension byte EXT_0 follows immediately. See Section 5.4.3.
5.4.3. Dispatch Extension โจ
okay so the EXT_0 byte works exactly like we already covered back in Section 4.1.1 ๐ซถ and it's drawn out in Figure 18 ๐
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| NCS | RSV |EXT|
+---+---+---+---+---+---+---+---+Figure 18: EXT_0 Format ๐
- NCS: Name Compression Strategy ๐ธ
00: Names are compressed with the default name compression strategy (see Section 5.2). ๐01: Reserved.10: Reserved.11: Reserved.
- RSV: Reserved ๐
- Must be set to 0.
- EXT: Extension ๐ฆ
0: No extension byte follows.1: A further extension byte follows immediately.
6. Space-Efficient Message Encoding for CCNx ๐
6.1. TLV Encoding ๐ง
the generic CCNx TLV encoding is described in [RFC8609]. Type and Length fields attain the common fixed length of 2 bytes, which is very cute and very neat ๐ฅฐ
the TLV encoding for CCNx LoWPAN gets switched over to the more space-efficient encoding from Section 5.1. so yep, NDN and CCNx end up using the same compressed format for writing TLVs. iconic behavior, honestly โจ
6.2. Name TLV Compression ๐
Name TLVs get compressed using the scheme we already defined in Section 5.2 for NDN. the one exception is if a Name TLV contains T_IPID, T_APP, or organizational TLVs. in that case the name just stays uncompressed ๐ซ
6.3. Interest Messages ๐
6.3.1. Uncompressed Interest Messages ๐ฆ
an uncompressed Interest message uses the base dispatch format (see Figure 4) and sets the C and M flags to 0. the P flag gets set to 1 (Figure 19). then the Interest message is handed to the CCNx stack without any modifications, no cap ๐
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 |
+---+---+---+---+---+---+---+---+Figure 19: Dispatch Format for Uncompressed CCNx Interest Messages โจ
6.3.2. Compressed Interest Messages ๐ซง
okay the compressed Interest message uses the extended dispatch format (Figure 5), and it sets the C and P flags to 1. the M flag is set to 0. now here's the tea: if an Interest message has TLVs that aren't mentioned in the compression rules below, then this message MUST be sent uncompressed. no exceptions, bestie ๐ซ
in the default use case, the Interest message gets compressed with this minimal rule set:
- The version is elided from the fixed header and assumed to be 1.
- 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 Figure 20. here's the legend first so you can read the art ๐
T = Type, L = Length, V = Value
Lc = Compressed Length, Vc = Compressed Value
: = optional field, | = mandatory field +-----------------------------+ +-------------------------+
| Uncompr. Fixed Header | | Compr. Fixed Header |
+-----------------------------+ +-------------------------+
+---------+---------+---------+ +---------+
: ILT T : ILT L : ILT V : : ILT Vc :
+---------+---------+---------+ +---------+
: MSGH T : MSGH L : MSGH V : : MSGH Vc :
+---------+---------+---------+ +---------+
+---------+---------+ +---------+
| MSGT T | MSGT L | | Name Vc |
+---------+---------+---------+ +---------+
| Name T | Name L | Name V | ==> : KIDR Vc :
+---------+---------+---------+ +---------+
: KIDR T : KIDR L : KIDR V : : OBHR Vc :
+---------+---------+---------+ +---------+---------+
: OBHR T : OBHR L : OBHR V : : PAYL Lc : PAYL V :
+---------+---------+---------+ +---------+---------+
: PAYL T : PAYL L : PAYL V : : VALG Lc : VALG Vc :
+---------+---------+---------+ +---------+---------+
: VALG T : VALG L : VALG V : : VPAY Lc : VPAY V :
+---------+---------+---------+ +---------+---------+
: VPAY T : VPAY L : VPAY V :
+---------+---------+---------+Figure 20: Compression of CCNx LoWPAN Interest Message ๐ท
further TLV compression is signalled by the ICN LoWPAN dispatch in Figure 21. this one is giving bit-level drama ๐ฅ
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|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+Figure 21: Dispatch Format for Compressed CCNx Interest Messages ๐ง
now let's go through each field:
- 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 Section 6.3.2.1 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 Section 7. The Type and Length fields are elided.
- MGH: Optional hop-by-hop MessageHash TLV ๐
- See Section 6.3.2.1 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 Section 6.3.2.2.
- CID: Context Identifier ๐ชช
- See Figure 5.
- EXT: Extension ๐งฉ
0: No extension byte follows.1: Extension byte EXT_0 follows immediately. See Section 6.3.3.
6.3.2.1. Hop-By-Hop Header TLVs Compression ๐ญ
hop-by-hop header TLVs are unordered, bestie ๐คทโโ๏ธ for an Interest message, [RFC8609] defines two optional hop-by-hop header TLVs, but higher-level specifications can define several more. for the compression in the previous section, the hop-by-hop TLVs get ordered like this:
- InterestLifetime TLV
- Message Hash TLV
Note: All hop-by-hop header TLVs other than the InterestLifetime and MessageHash TLVs remain uncompressed in the encoded message. they show up after the InterestLifetime and MessageHash TLVs, in the same order as they were in the original message. โจ
6.3.2.2. Validation ๐
0 1 2 3 4 5 6 7 8
+-------+-------+-------+-------+-------+-------+-------+-------+
| ValidationAlg | KeyID | RSV |
+-------+-------+-------+-------+-------+-------+-------+-------+Figure 22: Dispatch for Interest Validations ๐ธ
- 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. its Type field is omitted, so it's a little bit of a stealth move ๐ฅท
6.3.3. Dispatch Extension ๐
the EXT_0 byte follows the description in Section 4.1.1 and is illustrated in Figure 23. same energy as before, just a new spot ๐
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| NCS | RSV |EXT|
+---+---+---+---+---+---+---+---+Figure 23: EXT_0 Format ๐
- NCS: Name Compression Strategy ๐ธ
00: Names are compressed with the default name compression strategy (see Section 5.2). ๐01: Reserved.10: Reserved.11: Reserved.
- RSV: Reserved ๐
- Must be set to 0.
- EXT: Extension ๐ฆ
0: No extension byte follows.1: A further extension byte follows immediately.
6.4. Content Objects ๐
6.4.1. Uncompressed Content Objects โจ
okay so an uncompressed Content Object is the no-filter version ๐
it uses the base dispatch format (see Figure 4), sets the C flag to 0, and sets both the P and M flags to 1 (Figure 24). it gets handed to the CCNx stack totally as-is, no edits, no cap ๐ซถ
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 |
+---+---+---+---+---+---+---+---+Figure 24: Dispatch Format for Uncompressed CCNx Content Objects
6.4.2. Compressed Content Objects
the compressed version is giving full glow-up ๐ฆ it uses the extended dispatch format (Figure 5) and sets the C, P, and M flags to 1. heads up though: if a Content Object has TLVs that aren't covered by the compression rules below, this message MUST be sent uncompressed. no exceptions bestie ๐ซ
by default, the Content Object gets compressed with this base rule set:
- The version is elided from the fixed header and assumed to be 1.
- 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.
the compressed CCNx LoWPAN Data message is visualized in Figure 25 ๐ธ
T = Type, L = Length, V = Value
Lc = Compressed Length, Vc = Compressed Value
: = optional field, | = mandatory field
+-----------------------------+ +-------------------------+
| Uncompr. Fixed Header | | Compr. Fixed Header |
+-----------------------------+ +-------------------------+
+---------+---------+---------+ +---------+
: RCT T : RCT L : RCT V : : RCT Vc :
+---------+---------+------.--+ +---------+
: MSGH T : MSGH L : MSGH V : : MSGH Vc :
+---------+---------+---------+ +---------+
+---------+---------+ +---------+
| MSGT T | MSGT L | | Name Vc |
+---------+---------+---------+ +---------+
| Name T | Name L | Name V | ==> : EXPT Vc :
+---------+---------+---------+ +---------+---------+
: PTYP T : PTYP L : PTYP V : : PAYL Lc : PAYL V :
+---------+---------+---------+ +---------+---------+
: EXPT T : EXPT L : EXPT V : : VALG Lc : VALG Vc :
+---------+---------+---------+ +---------+---------+
: PAYL T : PAYL L : PAYL V : : VPAY Lc : VPAY V :
+---------+---------+---------+ +---------+---------+
: VALG T : VALG L : VALG V :
+---------+---------+---------+
: VPAY T : VPAY L : VPAY V :
+---------+---------+---------+Figure 25: Compression of CCNx LoWPAN Data Message
further TLV compression gets signalled by the ICN LoWPAN dispatch in Figure 26 ๐
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 1 | 1 | 1 |FLG|FRS|PAY|RCT|MGH| PLTYP |EXP|VAL|RSV|CID|EXT|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+Figure 26: Dispatch Format for Compressed CCNx Content Objects
here's what each bit in that dispatch means ๐ง
FLG: Flags field in the fixed header- See Section 6.3.2.
FRS: Reserved field in the fixed header- See Section 6.3.2.
PAY: Optional Payload TLV- See Section 6.3.2.
RCT: Optional hop-by-hop Recommended Cache Time TLV0: 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 Section 6.4.2.1 for further details on the ordering of hop-by-hop TLVs.
- This TLV is expected to contain a
T_SHA-256TLV. If another hash is contained, then the Content Object MUST be sent uncompressed. ๐ 0: The MessageHash TLV is absent.1: AT_SHA-256TLV 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 TLV00: The PayloadType TLV is absent.01: The PayloadType TLV is absent, andT_PAYLOADTYPE_DATAis assumed.10: The PayloadType TLV is absent, andT_PAYLOADTYPE_KEYis assumed.11: The PayloadType TLV is present and uncompressed.
EXP: Optional ExpiryTime TLV0: 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 Section 6.3.2.
RSV: Reserved- Must be set to 0.
CID: Context Identifier- See Figure 5.
EXT: Extension0: No extension byte follows.1: Extension byteEXT_0follows immediately. See Section 6.4.3.
6.4.2.1. Hop-By-Hop Header TLVs Compression
hop-by-hop header TLVs are unordered, so no vibes-based ordering here ๐ for a Content Object message, two optional hop-by-hop header TLVs are defined in [RFC8609], but several more can be defined in higher-level specifications. for the compression in the previous section, the hop-by-hop TLVs are ordered like this:
- Recommended Cache Time TLV
- 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. ๐
6.4.3. Dispatch Extension
the EXT_0 byte follows the description in Section 4.1.1 and is illustrated in Figure 27 โจ
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| NCS | RSV |EXT|
+---+---+---+---+---+---+---+---+Figure 27: EXT_0 Format
the fields inside EXT_0 ๐
NCS: Name Compression Strategy00: Names are compressed with the default name compression strategy (see Section 5.2).01: Reserved.10: Reserved.11: Reserved.
RSV: Reserved- Must be set to 0.
EXT: Extension0: No extension byte follows.1: A further extension byte follows immediately.
7. Compressed Time Encoding โณ
this document adopts the 8-bit compact time representation for relative time-values described in Section 5 of [RFC5497], with the constant factor C set to C := 1/32. ๐ฆ
valid time offsets in CCNx and NDN run from a few milliseconds (like the lifetime of low-latency Interests) all the way up to several years (like content freshness periods in caches). so this document adds two modifications to the compression algorithm ๐
the first modification is a subnormal form [IEEE.754.2019] for time-codes with exponent 0. this gives extra precision and a gradual underflow for the smallest numbers. the formula gets changed like this (a := mantissa, b := exponent):
- Subnormal (b == 0):
(0 + a/8) * 2 * C - Normalized (b > 0):
(1 + a/8) * 2^b * C(see [RFC5497])
this configuration gives you these 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. ๐
8. Stateful Header Compression ๐ธ
stateful header compression in ICN LoWPAN gives you packet size reductions in two ways. first, common information shared throughout the local LoWPAN can be memorized in the context state at all nodes and left out of communication. second, redundancy in a single Interest-Data exchange can be removed from ICN stateful forwarding on a hop-by-hop basis and memorized in en route state tables. the glow-up is real ๐ฅ
8.1. LoWPAN-Local State
a Context Identifier (CID) is a byte that refers to a particular conceptual context between network devices, and it MAY be used to replace frequently appearing information, such as name prefixes, suffixes, or meta information, such as Interest lifetime. ๐
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| X | CID |
+---+---+---+---+---+---+---+---+Figure 28: Context Identifier
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 Figure 28). if the most significant bit is set, it indicates the presence of another, subsequent CID byte (see Figure 33). โจ
the context state shared between senders and receivers gets removed from the compressed packet before sending, and reinserted after reception before passing to the upper stack. ๐ง
the actual information in a context and how it's encoded is out of scope for this document. so is the initial distribution and maintenance of shared context. and frames containing unknown or invalid CIDs MUST be silently discarded. ๐ซ๐
8.2. En Route State ๐ฆ
okay so in CCNx and NDN, Name TLVs ride along in Interest messages and then come right back in Data messages ๐. the returning Name TLVs either match the original Name TLV exactly or contain it as a prefix. ICN LoWPAN is like "why repeat yourself bestie" ๐ so it swaps those Name TLVs in responses for single bytes that stand in for link-local HopIDs. the HopIDs travel as Context Identifiers (see Section 8.1) with link-local scope, see Figure 29 โจ
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| X | HopID |
+---+---+---+---+---+---+---+---+Figure 29: Context Identifier as HopID
a HopID is valid if not all of its ID bits are set to zero, and invalid otherwise ๐ that gives us 127 distinct HopIDs (1...127). if that range runs out, the messages MUST be sent without en route state compression until new HopIDs are free again ๐ญ and any ICN LoWPAN node that forwards without swapping the Name TLV for a HopID (no en route compression) MUST invalidate the HopID by setting all ID bits to zero. no ghost IDs allowed ๐ป
while an Interest is traveling, a forwarder makes up an ephemeral HopID that's tied to a Pending Interest Table (PIT) entry ๐ง each HopID MUST be unique within the local PIT, and it only lives as long as that PIT entry does. to keep track of them, the local PIT gets two new columns: HIDi (inbound HopIDs) and HIDo (outbound HopIDs) ๐
HopIDs show up in Interests and get stored on the next hop, in the HIDi column of the resulting PIT entry. right before the Interest gets forwarded, the HopID is swapped for a newly generated local HopID, and that new one is stored in the HIDo column of the local PIT (see Figure 30) ๐
PIT of B PIT Extension PIT of C PIT Extension
+--------+------++------+------+ +--------+------++------+------+
| Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo |
+========+======++======+======+ +========+======++======+======+
| /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | |
+--------+------++------+------+ +--------+------++------+------+
^ | ^
store | '----------------------, ,---' store
| send v |
,---, /p0, h_A ,---, /p0, h_B ,---,
| A | ------------------------> | B | ------------------------> | C |
'---' '---' '---'Figure 30: Setting Compression State En Route (Interest)
responses carry HopIDs that came from Interests ๐ฆ if the returning Name TLV matches the original Name TLV, the whole name gets elided (gone, bye ๐). otherwise, only the matching name prefix gets elided, and the leftover name suffix is sent along with the HopID. when a response gets forwarded, the HopID inside it is pulled out and used to find the right PIT entry by looking up the HIDo column โจ then the HopID gets swapped for the matching HopID from the HIDi column before the response goes out (see Figure 31) ๐
PIT of B PIT Extension PIT of C PIT Extension
+--------+------++------+------+ +--------+------++------+------+
| Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo |
+========+======++======+======+ +========+======++======+======+
| /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | |
+--------+------++------+------+ +--------+------++------+------+
| ^ |
send | '----------------------, ,---' send
v match | v
,---, h_A ,---, h_B ,---,
| A | <------------------------ | B | <------------------------ | C |
'---' '---' '---'Figure 31: Eliding Name TLVs Using En Route State (Data)
ngl, each forwarder in an ICN LoWPAN network gets to decide for itself whether it joins en route compression ๐ that said, an ICN LoWPAN node SHOULD use en route compression whenever the stateful compression mechanism is activated ๐ซถ
also, the PIT extensions are only required at ICN LoWPAN nodes. regular NDN/CCNx forwarders outside of an ICN LoWPAN domain don't need to implement any of this ๐
8.3. Integrating Stateful Header Compression ๐งฉ
a CID shows up whenever the CID flag is set (see Figure 5) ๐ธ it gets tacked onto the end of the last ICN LoWPAN dispatch byte, as in Figure 32 โจ
...-------+--------+-------...-------+--...-+-------...
/ ... | Page | ICN LoWPAN Disp.| CIDs | Payload /
...-------+--------+-------...-------+--...-+-------...Figure 32: LoWPAN Encapsulation with ICN LoWPAN and CIDs
multiple CIDs get chained together, and the most significant bit tells you whether another CID comes after it (Figure 33) ๐ this is how you get multiple shared contexts in compressed messages, iconic behavior ๐
the HopID is always the very first CID ๐ฆ
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1| CID / HopID | --> |1| CID | --> |0| CID |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+Figure 33: Chaining of Context Identifiers
9. ICN LoWPAN Constants and Variables ๐
this is the summary of every ICN LoWPAN constant and variable, all in one place ๐ง
DEFAULT_NDN_HOPLIMIT: 25510. Implementation Report and Guidance ๐
the ICN LoWPAN scheme in this document has been implemented as an extension of the NDN/CCNx software stack [CCN-LITE], in its IoT version on RIOT [RIOT] ๐ค an experimental evaluation of NDN over ICN LoWPAN with different configurations was done in [ICNLOWPAN] ๐ energy profiling and processing time measurements show significant energy savings, and the amortized processing costs show no penalties. no cap, that's a W ๐
10.1. Preferred Configuration ๐
header compression performance depends on certain aspects and configurations ๐ฅฐ it works best for these cases:
- signed time offsets compress (per Section 7) without needing rounding โจ
- the context state (e.g., prefixes) is distributed so 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, so compression works for all messages ๐ซถ
10.2. Further Experimental Deployments ๐ฌ
an investigation of ICN LoWPAN in large-scale deployments, with different traffic patterns and bigger samples of the board types available, is still future work ๐ฎ this document will be revised to move it to the Standards Track once enough operational experience has been gathered. experience reports are encouraged, especially in these areas:
- the name compression scheme (Section 5.2) is optimized for short name components of type
GenericNameComponent๐ an empirical study of name lengths in different deployments of selected use cases, like smart home, smart city, and industrial IoT, can give meaningful reports on which name component types and lengths are needed. a conclusive outcome helps us understand whether and how extension mechanisms are needed (Section 5.3.3) ๐ง as a preliminary analysis, [ICNLOWPAN] looks at how well the proposed compression works with URLs from the WWW ๐ studies on deployments of Constrained Application Protocol (CoAP) [RFC7252] can offer more insight into naming schemes in the IoT ๐ - the fragmentation scheme (Section 4.2), inherited from 6LoWPAN, allows a transparent, hop-wise reassembly of CCNx or NDN packets ๐งฉ fragment forwarding [RFC8930] with selective fragment recovery [RFC8931] can improve end-to-end latency and reliability while reducing buffer requirements on forwarders โจ early evaluations [SFR-ICNLOWPAN] show that a naive integration of these upcoming fragmentation features into ICN LoWPAN makes the hop-wise content replication inoperative, since Interest and Data messages get reassembled end-to-end ๐ญ more deployment experience is needed to gauge how feasible the different fragmentation schemes are in ICN LoWPAN ๐
- the context state (Section 8.1) holds information shared between a set of devices in a LoWPAN ๐ค fixed name prefixes and suffixes are good candidates to distribute to all nodes so they can be elided from request and response messages ๐ more experience and a deeper look at currently available and upcoming protocol features is needed to identify other protocol fields ๐
- the distribution and synchronization of the context state can potentially be adopted from Section 7.2 of [RFC6775], but it needs further evaluation ๐งช while 6LoWPAN uses the Neighbor Discovery protocol to disseminate state, CCNx and NDN deployments are missing a standard mechanism to bootstrap and manage configurations ๐ฅบ
- the stateful en route compression (Section 8.2) supports a limited number of 127 distinct HopIDs that can be in use at the same time on a single node ๐ข complex deployments with multiple concurrent requests can give better insight into how many open requests the PIT of memory-constrained devices can store ๐ญ that number can serve as an upper bound and decide whether the HopID length needs resizing to fit more HopIDs, at the cost of extra header overhead โ๏ธ
- multiple implementations that generate and deploy the compression options of this memo in different ways will add to our understanding of the benefits and limitations of the proposed schemes ๐ซ different reports can show how complex it is to implement ICN LoWPAN on constrained devices, and how to stay interoperable with other implementations ๐ฆ
11. Security Considerations ๐จ
main memory is typically a scarce resource on constrained networked devices, bestie ๐ญ fragmentation, as described in this memo, keeps fragments and only purges them after a packet is reassembled, which means buffering all the fragments. this scheme can handle fragments for distinct packets at the same time, and that can overflow packet buffers that can't hold all the fragments needed for reassembly ๐ implementers are therefore strongly urged to use appropriate buffer replacement strategies for fragments. minimal fragment forwarding [RFC8930] can potentially prevent fragment buffer saturation in forwarders ๐ก๏ธ
the stateful header compression generates ephemeral HopIDs for incoming and outgoing Interests and uses them up on returning Data packets ๐ฅ forged Interests can deplete the number of available HopIDs, which leads to a denial of compression service for later content requests ๐ฑ
to further ease the problems caused by forged fragments or Interest initiations, proper protective mechanisms for accessing the link layer should be deployed ๐ IEEE 802.15.4, for example, provides capabilities to protect frames and restrict them to a point-to-point link or a group of devices ๐
12. IANA Considerations โจ
12.1. Updates to the 6LoWPAN Dispatch Type Field Registry
okay so IANA has handed out dispatch values for ICN LoWPAN in the "Dispatch Type Field" subregistry [RFC4944] [RFC8025] of the "IPv6 Low Power Personal Area Network Parameters" registry ๐๏ธ๐ Table 2 shows all the updates to the registry, and it's giving very organized energy.
+=============+======+=========================+===========+
| Bit Pattern | Page | Header Type | Reference |
+=============+======+=========================+===========+
| 00 000000 | 14 | Uncompressed NDN | RFC 9139 |
| | | Interest messages | |
+-------------+------+-------------------------+-----------+
| 00 01xxxx | 14 | Compressed NDN Interest | RFC 9139 |
| | | messages | |
+-------------+------+-------------------------+-----------+
| 00 100000 | 14 | Uncompressed NDN Data | RFC 9139 |
| | | messages | |
+-------------+------+-------------------------+-----------+
| 00 11xxxx | 14 | Compressed NDN Data | RFC 9139 |
| | | messages | |
+-------------+------+-------------------------+-----------+
| 01 000000 | 14 | Uncompressed CCNx | RFC 9139 |
| | | Interest messages | |
+-------------+------+-------------------------+-----------+
| 01 01xxxx | 14 | Compressed CCNx | RFC 9139 |
| | | Interest messages | |
+-------------+------+-------------------------+-----------+
| 01 100000 | 14 | Uncompressed CCNx | RFC 9139 |
| | | Content Object messages | |
+-------------+------+-------------------------+-----------+
| 01 11xxxx | 14 | Compressed CCNx Content | RFC 9139 |
| | | Object messages | |
+-------------+------+-------------------------+-----------+Table 2: Dispatch Types for NDN and CCNx ๐ธ
13. References ๐
13.1. Normative References
[IEEE.754.2019]IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE Std 754-2019,<https://standards.ieee.org/content/ieee-standards/en/standard/754-2019.html>.[ieee802.15.4]IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE Std 802.15.4-2020,<https://standards.ieee.org/standard/802_15_4-2020.html>.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,<https://www.rfc-editor.org/info/rfc2119>.[RFC4944]Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,<https://www.rfc-editor.org/info/rfc4944>.[RFC5497]Clausen, T. and C. Dearlove, "Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, DOI 10.17487/RFC5497, March 2009,<https://www.rfc-editor.org/info/rfc5497>.[RFC6256]Eddy, W. and E. Davies, "Using Self-Delimiting Numeric Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May 2011,<https://www.rfc-editor.org/info/rfc6256>.[RFC6282]Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011,<https://www.rfc-editor.org/info/rfc6282>.[RFC6775]Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012,<https://www.rfc-editor.org/info/rfc6775>.[RFC8174]Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,<https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References
[CCN-LITE]"CCN-lite, a lightweight implementation of the CCNx protocol and its variations",<https://github.com/cn-uofbasel/ccn-lite>.[ICNLOWPAN]Gรผndoฤan, C., Kietzmann, P., Schmidt, T., and M. Wรคhlisch, "Designing a LoWPAN convergence layer for the Information Centric Internet of Things", Computer Communications, Vol. 164, No. 1, p. 114โ123, Elsevier, December 2020,<https://doi.org/10.1016/j.comcom.2020.10.002>.[ICNRG-FLIC]Tschudin, C., Wood, C., Mosko, M., and D. Oran, Ed., "File-Like ICN Collections (FLIC)", Work in Progress, Internet-Draft, draft-irtf-icnrg-flic-02, 4 November 2019,<https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-flic-02>.[NDN]Jacobson, V., Smetters, D., Thornton, J., Plass, M., Briggs, N., and R. Braynard, "Networking named content", 5th Int. Conf. on emerging Networking Experiments and Technologies (ACM CoNEXT), December 2009,<https://doi.org/10.1145/1658939.1658941>.[NDN-EXP1]Baccelli, E., Mehlis, C., Hahm, O., Schmidt, TC., and M. Wรคhlisch, "Information centric networking in the IoT: experiments with NDN in the wild", Proc. of 1st ACM Conf. on Information-Centric Networking (ICN-2014) ACM DL, pp. 77-86, September 2014,<http://dx.doi.org/10.1145/2660129.2660144>.[NDN-EXP2]Gรผndoฤan, C., Kietzmann, P., Lenders, M., Petersen, H., Schmidt, TC., and M. Wรคhlisch, "NDN, CoAP, and MQTT: a comparative measurement study in the IoT", Proc. of 5th ACM Conf. on Information-Centric Networking (ICN-2018) ACM DL, pp. 159-171, September 2018,<https://doi.org/10.1145/3267955.3267967>.[NDN-MAC]Kietzmann, P., Gรผndoฤan, C., Schmidt, TC., Hahm, O., and M. Wรคhlisch, "The need for a name to MAC address mapping in NDN: towards quantifying the resource gain", Proc. of 4th ACM Conf. on Information-Centric Networking (ICN-2017) ACM DL, pp. 36-42, September 2017,<https://doi.org/10.1145/3125719.3125737>.[NDN-PACKET-SPEC]"NDN Packet Format Specification",<https://named-data.net/doc/NDN-packet-spec/0.3/>.[RFC7228]Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014,<https://www.rfc-editor.org/info/rfc7228>.[RFC7252]Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014,<https://www.rfc-editor.org/info/rfc7252>.[RFC7476]Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., Tyson, G., Davies, E., Molinaro, A., and S. Eum, "Information-Centric Networking: Baseline Scenarios", RFC 7476, DOI 10.17487/RFC7476, March 2015,<https://www.rfc-editor.org/info/rfc7476>.[RFC7927]Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,<https://www.rfc-editor.org/info/rfc7927>.[RFC7945]Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., and G. Boggia, "Information-Centric Networking: Evaluation and Security Considerations", RFC 7945, DOI 10.17487/RFC7945, September 2016,<https://www.rfc-editor.org/info/rfc7945>.[RFC8025]Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch", RFC 8025, DOI 10.17487/RFC8025, November 2016,<https://www.rfc-editor.org/info/rfc8025>.[RFC8569]Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019,<https://www.rfc-editor.org/info/rfc8569>.[RFC8609]Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019,<https://www.rfc-editor.org/info/rfc8609>.[RFC8930]Watteyne, T., Ed., Thubert, P., Ed., and C. Bormann, "On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network", RFC 8930, DOI 10.17487/RFC8930, November 2020,<https://www.rfc-editor.org/info/rfc8930>.[RFC8931]Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery", RFC 8931, DOI 10.17487/RFC8931, November 2020,<https://www.rfc-editor.org/info/rfc8931>.[RIOT]Baccelli, E., Gรผndoฤan, C., Hahm, O., Kietzmann, P., Lenders, MS., Petersen, H., Schleiser, K., Schmidt, TC., and M. Wรคhlisch, "RIOT: An Open Source Operating System for Low-End Embedded Devices in the IoT", IEEE Internet of Things Journal Vol. 5, No. 6, p. 4428-4440, December 2018,<https://doi.org/10.1109/JIOT.2018.2815038>.[SFR-ICNLOWPAN]Lenders, M., Gรผndoฤan, C., Schmidt, TC., and M. Wรคhlisch, "Connecting the Dots: Selective Fragment Recovery in ICNLoWPAN", Proc. of 7th ACM Conf. on Information-Centric Networking (ICN-2020) ACM DL, pp. 70-76, September 2020,<https://doi.org/10.1145/3405656.3418719>.[TLV-ENC-802.15.4]Mosko, M. and C. Tschudin, "CCN and NDN TLV encodings in 802.15.4 packets", January 2015,<https://datatracker.ietf.org/meeting/interim-2015-icnrg-01/materials/slides-interim-2015-icnrg-1-2>.[WIRE-FORMAT-CONSID]Wang, G., Tschudin, C., and R. Ravindran, "CCN/NDN Protocol Wire Format and Functionality Considerations", January 2015,<https://datatracker.ietf.org/meeting/interim-2015-icnrg-01/materials/slides-interim-2015-icnrg-1-8>.
Appendix A. Estimated Size Reduction ๐ฆ
okay this part is a theoretical evaluation (my fave kind of math ๐งฎ๐ ) that estimates the gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages.
We assume that n is the number of name components, and 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. ๐
A.1. 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. ๐
A.1.1. Interest โจ
Okay so bestie, this part is where we actually do the math on how much smaller NDN packets get after compression ๐งฎ๐ Figure 34 shows the size of a basic, uncompressed NDN Interest. This one has a CanBePrefix TLV, a MustBeFresh TLV, an InterestLifetime TLV set to 4 seconds, and a HopLimit TLV set to 6. All the numbers are in bytes, so no cap, we're counting every single one ๐ซถ
------------------------------------,
Interest TLV = 2 |
---------------------, |
Name | 2 + |
NameComponents = 2n + |
| comps_n |
---------------------' = 21 + 2n + comps_n
CanBePrefix = 2 |
MustBeFresh = 2 |
Nonce = 6 |
InterestLifetime = 4 |
HopLimit = 3 |
------------------------------------'
Figure 34: Estimated Size of an Uncompressed NDN InterestFigure 35 is the glow-up version ๐ฆโจ This is the size after compression:
------------------------------------,
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 |
------------------------------------'
Figure 35: Estimated Size of a Compressed NDN InterestThe 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. ๐ธ That's a whole lot of savings, periodt ๐
A.1.2. Data ๐
Now we're doing the Data packet, and it's giving very detailed ๐ง Figure 36 is the uncompressed version. It has 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. Iykyk ๐
------------------------------------,
Data TLV = 2 |
---------------------, |
Name | 2 + |
NameComponents = 2n + |
| comps_n |
---------------------' |
---------------------, |
MetaInfo | |
FreshnessPeriod = 6 |
| = 53 + 2n + comps_n +
---------------------' | clen + klen
Content = 2 + clen |
---------------------, |
SignatureInfo | |
SignatureType | |
KeyLocator = 41 + klen |
SignatureValue | |
DigestSha256 | |
---------------------' |
------------------------------------'
Figure 36: Estimated Size of an Uncompressed NDN DataFigure 37 is the compressed version of that same Data packet ๐
------------------------------------,
Dispatch Page Switch = 1 |
NDN Data Dispatch = 2 |
-----------------------, |
Name | |
NameComponents = n/2 + |
| comps_n = 38 + n/2 + comps_n +
-----------------------' | clen + klen
Content = 1 + clen |
KeyLocator = 1 + klen |
DigestSha256 = 32 |
FreshnessPeriod = 1 |
------------------------------------'
Figure 37: Estimated Size of a Compressed NDN DataThe size difference is 15 + 1.5n bytes. ๐
For the name /DE/HH/HAW/BT7, the total size gain is 21 bytes. โจ Bestie, the savings keep stacking ๐ญ๐ฅ
A.2. CCNx ๐
So the CCNx TLV encoding has a 2-byte encoding for Type and Length fields, which adds up to 4 bytes in total without a value ๐งธ
A.2.1. Interest ๐ฆ
Figure 38 is the 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 ๐
------------------------------------,
Fixed Header = 8 |
Message = 4 |
---------------------, |
Name | 4 + = 56 + 4n + comps_n
NameSegments = 4n + |
| comps_n |
---------------------' |
KeyIdRestriction = 40 |
------------------------------------'
Figure 38: Estimated Size of an Uncompressed CCNx InterestFigure 39 shows the size after compression ๐
------------------------------------,
Dispatch Page Switch = 1 |
CCNx Interest Dispatch = 2 |
Fixed Header = 3 |
-----------------------, |
Name | = 38 + n/2 + comps_n
NameSegments = n/2 + |
| comps_n |
-----------------------' |
T_SHA-256 = 32 |
------------------------------------'
Figure 39: Estimated Size of a Compressed CCNx InterestThe 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. ๐ Slay ๐
A.2.2. Content Object ๐ง
Figure 40 is the basic, uncompressed CCNx Content Object. It has 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 ๐ซถ
------------------------------------,
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 |
------------------------------------'
Figure 40: Estimated Size of an Uncompressed CCNx Content ObjectFigure 41 is the basic, compressed CCNx Data ๐
------------------------------------,
Dispatch Page Switch = 1 |
CCNx Content Dispatch = 3 |
Fixed Header = 2 |
-----------------------, |
Name | |
NameSegments = n/2 + |
| comps_n = 89 + n/2 + comps_n + clen
-----------------------' |
ExpiryTime = 8 |
Payload = 1 + clen |
T_HMAC-SHA256 = 32 |
SignatureTime = 8 |
ValidationPayload = 34 |
------------------------------------'
Figure 41: Estimated Size of a Compressed CCNx Data ObjectThe 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. ๐ฆ Okay that's the whole CCNx comparison, and it's iconic ๐
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) Peter Kietzmann, Dirk Kutscher, Martine Lenders, Colin Perkins, and Junxiao Shi. The hop-wise stateful name compression was brought up in a discussion by Dave Oran, which is gratefully acknowledged. Larger parts of this work are inspired by [RFC4944] and [RFC6282]. Special mention goes to Mark Mosko, as well as G.Q. Wang and Ravi Ravindran, as their previous work in [TLV-ENC-802.15.4] and [WIRE-FORMAT-CONSID] provided a good base for our discussions on stateless header compression mechanisms. Many thanks also to Carsten Bormann and Lars Eggert, who contributed in-depth comments during the IRSG review. This work was supported in part by the German Federal Ministry of Research and Education within the projects I3 and RAPstore. ๐งโจ
Authors' Addresses ๐
Cenk Gรผndoฤan HAW Hamburg Berliner Tor 7 D-20099 Hamburg Germany
Phone: +4940428758067 Email: cenk.guendogan@haw-hamburg.de URI: http://inet.haw-hamburg.de/members/cenk-gundogan
Thomas C. Schmidt HAW Hamburg Berliner Tor 7 D-20099 Hamburg Germany
Email: t.schmidt@haw-hamburg.de URI: http://inet.haw-hamburg.de/members/schmidt
Matthias Wรคhlisch link-lab & FU Berlin Hoenower Str. 35 D-10318 Berlin Germany
Email: mw@link-lab.net URI: https://www.mi.fu-berlin.de/en/inf/groups/ilab/members/ waehlisch.html
Christopher Scherb University of Applied Sciences and Arts Northwestern Switzerland Peter Merian-Str. 86 CH-4002 Basel Switzerland
Email: christopher.scherb@fhnw.ch
Claudio Marxer University of Basel Spiegelgasse 1 CH-4051 Basel Switzerland
Email: claudio.marxer@unibas.ch
Christian Tschudin University of Basel Spiegelgasse 1 CH-4051 Basel Switzerland
Email: christian.tschudin@unibas.ch
๐ฆ where this page comes from
- ietf: rfc9139 2021-11
- ๐ girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms