RFC 9139 | ICN Adaptation to LoWPANs | November 2021 |
Gündoğan, et al. | Experimental | [Page] |
This document defines a convergence layer for Content-Centric Networking (CCNx) and Named Data Networking (NDN) over IEEE 802.15.4 Low-Power Wireless Personal Area Networks (LoWPANs). A new frame format is specified to adapt CCNx and NDN packets to the small MTU size of IEEE 802.15.4. For that, syntactic and semantic changes to the TLV-based header formats are described. To support compatibility with other LoWPAN technologies that may coexist on a wireless medium, the dispatching scheme provided by IPv6 over LoWPAN (6LoWPAN) is extended to include new dispatch types for CCNx and NDN. Additionally, the fragmentation component of the 6LoWPAN dispatching framework is applied to Information-Centric Network (ICN) chunks. In its second part, the document defines stateless and stateful compression schemes to improve efficiency on constrained links. Stateless compression reduces TLV expressions to static header fields for common use cases. Stateful compression schemes elide states local to the LoWPAN and replace names in Data packets by short local identifiers.¶
This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).¶
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.¶
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Information-Centric Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9139.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
The Internet of Things (IoT) has been identified as a promising deployment area for Information-Centric Networking (ICN), as infrastructureless access to content, resilient forwarding, and in-network data replication demonstrates notable advantages over the Internet host-to-host approach [NDN-EXP1] [NDN-EXP2]. Recent studies [NDN-MAC] 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 [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]), in which devices are typically
battery operated and constrained in resources. Characteristics of LLNs
include an unreliable environment, low-bandwidth transmissions, and
increased latencies. IEEE 802.15.4 admits a maximum physical-layer
packet size of 127 bytes. The maximum frame header size is 25 bytes,
which leaves 102 bytes for the payload. IEEE 802.15.4 security features
further reduce this payload length by up to 21 bytes, yielding a net of
81 bytes for CCNx or NDN packet headers, signatures, and content.¶
6LoWPAN [RFC4944] [RFC6282] is a convergence layer that provides frame formats, header compression, and adaptation-layer fragmentation for IPv6 packets in IEEE 802.15.4 networks. The 6LoWPAN adaptation introduces a dispatching framework that prepends further information to 6LoWPAN packets, including a protocol identifier for payload and meta information about fragmentation.¶
Prevalent packet formats based on Type-Length-Value (TLV), such as in CCNx and NDN, are designed to be generic and extensible. This leads to header verbosity, which is inappropriate in constrained environments of IEEE 802.15.4 links. This document presents ICN LoWPAN, a convergence layer for IEEE 802.15.4 motivated by 6LoWPAN. ICN LoWPAN compresses packet headers of CCNx, as well as NDN, and allows for an increased effective payload size per packet. Additionally, reusing the dispatching framework defined by 6LoWPAN enables compatibility between coexisting wireless deployments of competing network technologies. This also allows reuse of the adaptation-layer fragmentation scheme specified by 6LoWPAN for ICN LoWPAN.¶
ICN LoWPAN defines a more space-efficient representation of CCNx and NDN packet formats. This syntactic change is described for CCNx and NDN separately, as the header formats and TLV encodings differ notably. For further reductions, default header values suitable for constrained IoT networks are selected in order to elide corresponding TLVs. Experimental evaluations of the ICN LoWPAN header compression schemes in [ICNLOWPAN] illustrate a reduced message overhead, a shortened message airtime, and an overall decline 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 interconnected via a quasi-stationary infrastructure using a border router (BR) that connects the constrained LoWPAN network by some gateway with the public Internet. In ICN-based IoT networks, nonlocal Interest and Data messages transparently travel through the BR up and down between a gateway and the embedded devices situated in the constrained LoWPAN.¶
The document has received fruitful reviews by members of the ICN community and the research group (see the Acknowledgments section) for a period of two years. It is the consensus of ICNRG that this document should be published in the IRTF Stream of the RFC series. This document does not constitute an IETF standard.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the terminology of [RFC7476], [RFC7927], and [RFC7945] for ICN entities.¶
The following terms are used in the document and defined as follows:¶
ICN LoWPAN provides a convergence layer that maps ICN packets onto constrained link-layer technologies. This includes features such as link-layer fragmentation, protocol separation on the link-layer level, and link-layer address mappings. The stack traversal is visualized in Figure 2.¶
Section 4 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 preconfiguration of a global state.¶
The CCNx and NDN header formats are composed of Type-Length-Value (TLV) fields to encode header data. The advantage of the TLV format is its support of variably structured data. The main disadvantage of the TLV format is the verbosity that results from storing the type and length of the encoded data.¶
The stateless header compression scheme makes use of compact bit fields to indicate the presence of optional TLVs in the uncompressed packet. The order of set bits in the bit fields corresponds to the order of each TLV in the packet. Further compression is achieved by specifying default values and reducing the range of certain header fields.¶
Figure 3 demonstrates the stateless header compression idea. In this example, the first type of the first TLV is removed and the corresponding bit in the bit field is set. The second TLV represents a fixed-length TLV (e.g., the Nonce TLV in NDN), so that the Type and Length fields are removed. The third TLV represents a boolean TLV (e.g., the MustBeFresh selector in NDN) for which the Type, Length, and Value fields are elided.¶
Stateless TLV compression for NDN is defined in Section 5. Section 6 defines the stateless TLV compression for CCNx.¶
The extensibility of this compression is described in Section 4.1.1 and allows future documents to update the compression rules outlined in this document.¶
ICN LoWPAN further employs two orthogonal, stateful compression schemes for packet size reductions, which are defined in Section 8. These mechanisms rely on shared contexts that are either distributed and maintained in the entire LoWPAN or are generated on demand hop-wise on a particular Interest-Data path.¶
The shared context identification is defined in Section 8.1. The hop-wise name compression "en route" is specified in Section 8.2.¶
The IEEE 802.15.4 frame header does not provide a protocol identifier for its payload. This causes problems of misinterpreting frames when several network layers coexist on the same link. To mitigate errors, 6LoWPAN defines dispatches as encapsulation headers for IEEE 802.15.4 frames (see Section 5 of [RFC4944]). Multiple LoWPAN encapsulation headers can precede the actual payload, and each encapsulation header is identified by a dispatch type.¶
[RFC8025] further specifies dispatch Pages to
switch between different contexts. When a LoWPAN parser encounters a Page
switch
LoWPAN encapsulation header, all
following encapsulation headers are interpreted by using a dispatch
Page, as specified by the Page switch
header. Pages 0 and 1 are reserved for 6LoWPAN. This document uses
Page 14 (1111 1110 (0xFE)
) for ICN LoWPAN.¶
The base dispatch format (Figure 4) is used and extended by CCNx and NDN in Sections 5 and 6.¶
ICN LoWPAN frames with compressed CCNx and NDN messages (C=1) use the extended dispatch format in Figure 5.¶
The encapsulation format for ICN LoWPAN is displayed in Figure 6.¶
Page switch
. 14 for ICN LoWPAN.¶
Extension bytes allow for the extensibility of the initial compression rule set. The base format for an extension byte is depicted in Figure 7.¶
Extension bytes are numbered according to their order. Future
documents MUST follow the naming scheme EXT_0, EXT_1, ...
when updating or referring to a specific dispatch extension byte.
Amendments that require an exchange of configurational parameters
between devices SHOULD use manifests to encode structured data in a
well-defined format, e.g., as outlined in [ICNRG-FLIC].¶
Small payload sizes in the LoWPAN require fragmentation for various network layers. Therefore, Section 5.3 of [RFC4944] defines a protocol-independent fragmentation dispatch type, a fragmentation header for the first fragment, and a separate fragmentation header for subsequent fragments. ICN LoWPAN adopts this fragmentation handling of [RFC4944].¶
The fragmentation LoWPAN header can encapsulate other dispatch headers. The order of dispatch types is defined in Section 5 of [RFC4944]. Figure 8 shows the fragmentation scheme. The reassembled ICN LoWPAN frame does not contain any fragmentation headers and is depicted in Figure 9.¶
The 6LoWPAN Fragment Forwarding (6LFF) [RFC8930] is an alternative approach that enables forwarding of fragments without reassembling packets on every intermediate hop. By reusing the 6LoWPAN dispatching framework, 6LFF integrates into ICN LoWPAN as seamlessly as the conventional hop-wise fragmentation. However, experimental evaluations [SFR-ICNLOWPAN] suggest that a more-refined integration can increase the cache utilization of forwarders on a request path.¶
The NDN packet format consists of TLV fields using the TLV encoding that is described in [NDN-PACKET-SPEC]. Type and Length fields are of variable size, where numbers greater than 252 are encoded using multiple bytes.¶
If the type or length number is less than 253
,
then that number is encoded into the actual Type or Length field. If
the number is greater or equals 253
and
fits into 2 bytes, then the Type or Length field is set to 253
and the number is encoded in the next
following 2 bytes in network byte order, i.e., from the most
significant byte (MSB) to the least significant byte (LSB). If the
number is greater than 2 bytes and fits into 4 bytes, then the Type
or Length field is set to 254
and the
number is encoded in the subsequent 4 bytes in network byte order.
For larger numbers, the Type or Length field is set to 255
and the number is encoded in the subsequent 8
bytes in network byte order.¶
In this specification, compressed NDN TLVs encode Type and Length fields using self-delimiting numeric values (SDNVs) [RFC6256] commonly known from Delay-Tolerant Networking (DTN) protocols. Instead of using the first byte as a marker for the number of following bytes, SDNVs use a single bit to indicate subsequent bytes.¶
Value | NDN TLV Encoding | SDNV Encoding |
---|---|---|
0 | 0x00 | 0x00 |
127 | 0x7F | 0x7F |
128 | 0x80 | 0x81 0x00 |
253 | 0xFD 0x00 0xFD | 0x81 0x7D |
214 - 1 | 0xFD 0x3F 0xFF | 0xFF 0x7F |
214 | 0xFD 0x40 0x00 | 0x81 0x80 0x00 |
216 | 0xFE 0x00 0x01 0x00 0x00 | 0x84 0x80 0x00 |
221 - 1 | 0xFE 0x00 0x1F 0xFF 0xFF | 0xFF 0xFF 0x7F |
221 | 0xFE 0x00 0x20 0x00 0x00 | 0x81 0x80 0x80 0x00 |
228 - 1 | 0xFE 0x0F 0xFF 0xFF 0xFF | 0xFF 0xFF 0xFF 0x7F |
228 | 0xFE 0x1F 0x00 0x00 0x00 | 0x81 0x80 0x80 0x80 0x00 |
232 | 0xFF 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 | 0x90 0x80 0x80 0x80 0x00 |
235 - 1 | 0xFF 0x00 0x00 0x00 0x07 0xFF 0xFF 0xFF 0xFF | 0xFF 0xFF 0xFF 0xFF 0x7F |
235 | 0xFF 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00 | 0x81 0x80 0x80 0x80 0x80 0x00 |
Table 1 compares the required bytes for encoding a few selected values using the NDN TLV encoding and SDNVs. For values up to 127, both methods require a single byte. Values in the range (128...252) encode as one byte for the NDN TLV scheme, while SDNVs require two bytes. Starting at value 253, SDNVs require a less or equal amount of bytes compared to the NDN TLV encoding.¶
This Name TLV compression encodes Length fields of two consecutive NameComponent TLVs into one byte, using a nibble for each. The most significant nibble indicates the length of an immediately following NameComponent TLV. The least significant nibble denotes the length of a subsequent NameComponent TLV. A length of 0 marks the end of the compressed Name TLV. The last Length field of an encoded NameComponent is either 0x00 for a name with an even number of components and 0xYF (Y > 0) if an odd number of components are present. This process limits the length of a NameComponent TLV to 15 bytes but allows for an unlimited number of components. An example for this encoding is presented in Figure 10.¶
An uncompressed Interest message uses the base dispatch format
(see Figure 4) and sets the C, P, and M
flags to 0
(Figure 11).
The Interest message is handed to the NDN stack without modifications.¶
The compressed Interest message uses the extended dispatch format
(Figure 5) and sets the C flag to
1
and the P and M flags to 0
.
If an Interest message contains TLVs that are not mentioned in the
following compression rules, then this message MUST be sent
uncompressed.¶
This specification assumes that a HopLimit TLV is part of the original Interest message. If such a HopLimit TLV is not present, it will be inserted with a default value of DEFAULT_NDN_HOPLIMIT prior to the compression.¶
In the default use case, the Interest message is compressed with the following minimal rule set:¶
Type
field of the outermost
MessageType TLV is removed.¶
1
indicates the
presence of an InterestLifetime, a length of 4
indicates
the presence of a nonce, and a length of 5
indicates
the presence of both TLVs.¶
The compressed NDN LoWPAN Interest message is visualized in Figure 12.¶
Further TLV compression is indicated by the ICN LoWPAN dispatch in Figure 13.¶
EXT_0
follows immediately. See Section 5.3.3.¶
The EXT_0
byte follows the
description in Section 4.1.1 and is illustrated
in Figure 14.¶
An uncompressed Data message uses the base dispatch
format and sets the C and P flags to 0
and the M flag
to 1
(Figure 15). The Data message is
handed to the NDN stack without modifications.¶
The compressed Data message uses the extended dispatch
format (Figure 5) and sets the C
and M flags to 1
. The
P flag is set to 0
. If a Data
message contains TLVs that are not mentioned in the
following compression rules, then this message MUST be sent
uncompressed.¶
By default, the Data message is compressed with the following base rule set:¶
Type
field of the outermost
MessageType TLV is removed.¶
The compressed NDN LoWPAN Data message is visualized in Figure 16.¶
Further TLV compression is indicated by the ICN LoWPAN dispatch in Figure 17.¶
EXT_0
follows immediately. See Section 5.4.3.¶
The EXT_0
byte follows the
description in Section 4.1.1 and is illustrated
in Figure 18.¶
The generic CCNx TLV encoding is described in [RFC8609]. Type and Length fields attain the common fixed length of 2 bytes.¶
The TLV encoding for CCNx LoWPAN is changed to the more space-efficient encoding described in Section 5.1. Hence, NDN and CCNx use the same compressed format for writing TLVs.¶
Name TLVs are compressed using the scheme already defined in Section 5.2 for NDN. If a Name TLV contains T_IPID, T_APP, or organizational TLVs, then the name remains uncompressed.¶
An uncompressed Interest message uses the base dispatch format
(see Figure 4) and sets the C and M flags to 0
.
The P flag is set to 1
(Figure 19).
The Interest message is handed to the CCNx stack without modifications.¶
The compressed Interest message uses the extended dispatch format
(Figure 5) and sets the C and P flags to 1
. The M flag is set to 0
.
If an Interest message contains TLVs that are not mentioned in the
following compression rules, then this message MUST be sent
uncompressed.¶
In the default use case, the Interest message is compressed with the following minimal rule set:¶
The compressed CCNx LoWPAN Interest message is visualized in Figure 20.¶
Further TLV compression is indicated by the ICN LoWPAN dispatch in Figure 21.¶
See Section 6.3.2.1 for further details on the ordering of hop-by-hop TLVs.¶
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.¶
This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the Interest MUST be sent uncompressed.¶
This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the Interest MUST be sent uncompressed.¶
EXT_0
follows immediately. See Section 6.3.3.¶
Hop-by-hop header TLVs are unordered. For an Interest 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 specified in the previous section, the hop-by-hop TLVs are ordered as follows:¶
Note: All hop-by-hop header TLVs other than the InterestLifetime and MessageHash TLVs remain uncompressed in the encoded message, and they appear after the InterestLifetime and MessageHash TLVs in the same order as in the original message.¶
The ValidationPayload TLV is present if the ValidationAlgorithm TLV is present. The Type field is omitted.¶
The EXT_0
byte follows the
description in Section 4.1.1 and is illustrated
in Figure 23.¶
An uncompressed Content Object uses the base dispatch format (see
Figure 4) and sets the C flag to
0
and the P and M flags to
1
(Figure 24).
The Content Object is handed to the CCNx stack without modifications.¶
The compressed Content Object uses the extended dispatch format
(Figure 5) and sets the C, P, and M
flags to 1
. If a Content Object contains TLVs that are not mentioned in
the following compression
rules, then this message MUST be sent uncompressed.¶
By default, the Content Object is compressed with the following base rule set:¶
The compressed CCNx LoWPAN Data message is visualized in Figure 25.¶
Further TLV compression is indicated by the ICN LoWPAN dispatch in Figure 26.¶
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-256 TLV. If another hash is contained, then the Content Object MUST be sent uncompressed.¶
EXT_0
follows immediately. See Section 6.4.3.¶
Hop-by-hop header TLVs are unordered. 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 specified in the previous section, the hop-by-hop TLVs are ordered as follows:¶
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.¶
The EXT_0
byte follows the
description in Section 4.1.1 and is illustrated
in Figure 27.¶
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 range from a few milliseconds (e.g., lifetime of low-latency Interests) to several years (e.g., content freshness periods in caches). Therefore, this document adds two modifications to the compression algorithm.¶
The first modification is the inclusion of a subnormal form [IEEE.754.2019] for time-codes with exponent 0 to provide an increased precision and a gradual underflow for the smallest numbers. The formula is changed as follows (a := mantissa, b := exponent):¶
This configuration allows for the following ranges:¶
The second modification only applies to uncompressible time offsets that are outside any security envelope. An invalid time-value MUST be set to the largest valid time-value that is smaller than the invalid input value before compression.¶
Stateful header compression in ICN LoWPAN enables packet size reductions in two ways. First, common information that is shared throughout the local LoWPAN may be memorized in the context state at all nodes and omitted from communication. Second, redundancy in a single Interest-Data exchange may be removed from ICN stateful forwarding on a hop-by-hop basis and memorized in en route state tables.¶
A Context Identifier (CID) is a byte that refers to a particular conceptual context between network devices and MAY be used to replace frequently appearing information, such as name prefixes, suffixes, or meta information, such as Interest lifetime.¶
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 set, the most significant bit indicates the presence of another, subsequent CID byte (see Figure 33).¶
The context state shared between senders and receivers is removed from the compressed packet prior to sending and reinserted after reception prior to passing to the upper stack.¶
The actual information in a context and how it is encoded are out of scope of this document. The initial distribution and maintenance of shared context is out of scope of this document. Frames containing unknown or invalid CIDs MUST be silently discarded.¶
In CCNx and NDN, Name TLVs are included in Interest messages, and they return in Data messages. Returning Name TLVs either equal the original Name TLV or contain the original Name TLV as a prefix. ICN LoWPAN reduces this redundancy in responses by replacing Name TLVs with single bytes that represent link-local HopIDs. HopIDs are carried as Context Identifiers (see Section 8.1) of link-local scope, as shown in Figure 29.¶
A HopID is valid if not all ID bits are set to zero and invalid otherwise. This yields 127 distinct HopIDs. If this range (1...127) is exhausted, the messages MUST be sent without en route state compression until new HopIDs are available. An ICN LoWPAN node that forwards without replacing the Name TLV with a HopID (without en route compression) MUST invalidate the HopID by setting all ID bits to zero.¶
While an Interest is traversing, a forwarder generates an ephemeral HopID that is tied to a Pending Interest Table (PIT) entry. Each HopID MUST be unique within the local PIT and only exists during the lifetime of a PIT entry. To maintain HopIDs, the local PIT is extended by two new columns: HIDi (inbound HopIDs) and HIDo (outbound HopIDs).¶
HopIDs are included in Interests and stored on the next hop with the resulting PIT entry in the HIDi column. The HopID is replaced with a newly generated local HopID before the Interest is forwarded. This new HopID is stored in the HIDo column of the local PIT (see Figure 30).¶
Responses include HopIDs that were obtained from Interests. If the returning Name TLV equals the original Name TLV, then the name is entirely elided. Otherwise, only the matching name prefix is elided, and the distinct name suffix is included along with the HopID. When a response is forwarded, the contained HopID is extracted and used to match against the correct PIT entry by performing a lookup on the HIDo column. The HopID is then replaced with the corresponding HopID from the HIDi column prior to forwarding the response (Figure 31).¶
It should be noted that each forwarder of an Interest in an ICN LoWPAN network can individually decide whether to participate in en route compression or not. However, an ICN LoWPAN node SHOULD use en route compression whenever the stateful compression mechanism is activated.¶
Note also that the extensions of the PIT data structure are required only at ICN LoWPAN nodes, while regular NDN/CCNx forwarders outside of an ICN LoWPAN domain do not need to implement these extensions.¶
A CID appears whenever the CID flag is set (see Figure 5). The CID is appended to the last ICN LoWPAN dispatch byte, as shown in Figure 32.¶
Multiple CIDs are chained together, with the most significant bit indicating the presence of a subsequent CID (Figure 33). This allows the use of multiple shared contexts in compressed messages.¶
The HopID is always included as the very first CID.¶
This is a summary of all ICN LoWPAN constants and variables.¶
The ICN LoWPAN scheme defined in this document has been implemented as an extension of the NDN/CCNx software stack [CCN-LITE] in its IoT version on RIOT [RIOT]. An experimental evaluation for NDN over ICN LoWPAN with varying configurations has been performed in [ICNLOWPAN]. Energy profiling and processing time measurements indicate significant energy savings, and the amortized costs for processing show no penalties.¶
The header compression performance depends on certain aspects and configurations. It works best for the following cases:¶
Name components are of type GenericNameComponent and are limited to a length of 15 bytes to enable compression for all messages.¶
An investigation of ICN LoWPAN in large-scale deployments with varying traffic patterns using larger samples of the different board types available remains as future work. This document will be revised to progress it to the Standards Track, once sufficient operational experience has been acquired. Experience reports are encouraged, particularly in the following areas:¶
Main memory is typically a scarce resource of constrained networked devices. Fragmentation, as described in this memo, preserves fragments and purges them only after a packet is reassembled, which requires a buffering of all fragments. This scheme is able to handle fragments for distinctive packets simultaneously, which can lead to overflowing packet buffers that cannot hold all necessary fragments for packet reassembly. Implementers are thus urged to make use of appropriate buffer replacement strategies for fragments. Minimal fragment forwarding [RFC8930] can potentially prevent fragment buffer saturation in forwarders.¶
The stateful header compression generates ephemeral HopIDs for incoming and outgoing Interests and consumes them on returning Data packets. Forged Interests can deplete the number of available HopIDs, thus leading to a denial of compression service for subsequent content requests.¶
To further alleviate the problems caused by forged fragments or Interest initiations, proper protective mechanisms for accessing the link layer should be deployed. IEEE 802.15.4, e.g., provides capabilities to protect frames and restrict them to a point-to-point link or a group of devices.¶
IANA has assigned 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 represents the updates to the registry.¶
Bit Pattern | Page | Header Type | Reference |
---|---|---|---|
00 000000 | 14 | Uncompressed NDN Interest messages | RFC 9139 |
00 01xxxx | 14 | Compressed NDN Interest messages | RFC 9139 |
00 100000 | 14 | Uncompressed NDN Data messages | RFC 9139 |
00 11xxxx | 14 | Compressed NDN Data messages | RFC 9139 |
01 000000 | 14 | Uncompressed CCNx Interest messages | RFC 9139 |
01 01xxxx | 14 | Compressed CCNx Interest messages | RFC 9139 |
01 100000 | 14 | Uncompressed CCNx Content Object messages | RFC 9139 |
01 11xxxx | 14 | Compressed CCNx Content Object messages | RFC 9139 |
In the following, a theoretical evaluation is given to estimate the gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages.¶
We assume that n
is the number of name
components; comps_n
denotes the sum of n
name component lengths. We also assume that the length of each name
component is lower than 16 bytes. The length of the content is given by
clen
. The lengths of TLV components are
specific to the CCNx or NDN encoding and are outlined below.¶
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.¶
Figure 34 depicts the size requirements for a basic, uncompressed NDN Interest containing a CanBePrefix TLV, a MustBeFresh TLV, an InterestLifetime TLV set to 4 seconds, and a HopLimit TLV set to 6. Numbers below represent the amount of bytes.¶
Figure 35 depicts the size requirements after compression.¶
The size difference is 11 + 1.5n bytes.¶
For the name /DE/HH/HAW/BT7
, the
total size gain is 17 bytes, which is 43% of the uncompressed
packet.¶
Figure 36 depicts the size requirements for a basic, uncompressed NDN Data containing a FreshnessPeriod as MetaInfo. A FreshnessPeriod of 1 minute is assumed, and the value is encoded using 1 byte. An HMACWithSha256 is assumed as a signature. The key locator is assumed to contain a Name TLV of length klen.¶
Figure 37 depicts the size requirements for the compressed version of the above Data packet.¶
The size difference is 15 + 1.5n bytes.¶
For the name /DE/HH/HAW/BT7
, the
total size gain is 21 bytes.¶
The CCNx TLV encoding defines a 2-byte encoding for Type and Length fields, summing up to 4 bytes in total without a value.¶
Figure 38 depicts the size requirements for a basic, uncompressed CCNx Interest. No hop-by-hop TLVs are included, the protocol version is assumed to be 1, and the Reserved field is assumed to be 0. A KeyIdRestriction TLV with T_SHA-256 is included to limit the responses to Content Objects containing the specific key.¶
Figure 39 depicts the size requirements after compression.¶
The size difference is 18 + 3.5n bytes.¶
For the name /DE/HH/HAW/BT7
, the size
is reduced by 53 bytes, which is 53% of the uncompressed
packet.¶
Figure 40 depicts the size requirements for a basic, uncompressed CCNx Content Object containing an ExpiryTime Message TLV, an HMAC_SHA-256 signature, the signature time, 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¶
Figure 41 depicts the size requirements for a basic, compressed CCNx Data.¶
The size difference is 35 + 3.5n bytes.¶
For the name /DE/HH/HAW/BT7
, the size
is reduced by 70 bytes, which is 40% of the uncompressed packet
containing a 4-byte payload.¶
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.¶