| ICN Research Group | C. Gundogan |
| Internet-Draft | T. Schmidt |
| Intended status: Experimental | HAW Hamburg |
| Expires: September 6, 2018 | M. Waehlisch |
| link-lab & FU Berlin | |
| C. Scherb | |
| C. Marxer | |
| C. Tschudin | |
| University of Basel | |
| March 5, 2018 |
ICN Adaptation to LowPAN Networks (ICN LoWPAN)
draft-gundogan-icnrg-ccnlowpan-01
In this document, a convergence layer for CCNx and NDN over IEEE 802.15.4 LowPan networks is defined. A new frame format is specified to adapt CCNx and NDN packets to the small MTU size of IEEE 802.15.4. For that, syntactic and semantic changes to the TLV-based header formats are described. To support compatibility with other LoWPAN technologies that may coexist on a wireless medium, the dispatching scheme provided by 6LoWPAN is extended to include new dispatch types for CCNx and NDN. Additionally, the link fragmentation component of the 6LoWPAN dispatching framework is applied to ICN chunks. Basic improvements in efficiency are advised by stateless compression schemes.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018.
Copyright (c) 2018 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 Networks (ICN), as infrastructureless access to content, resilient forwarding, and in-network data replication have shown noteable advantages over the traditional host-to-host approach on the Internet [NDN-EXP]. 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.
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 octets. The maximum frame header size is 25 octets, which leaves 102 octets for the payload. IEEE 802.15.4 security features further reduce this payload length by up to 21 octets, yielding a net of 81 octets for CCNx or NDN packet headers, signatures and content.
6LoWPAN [RFC4944][RFC6282] is a convergence layer that provides frame formats, header compression and link fragmentation for IPv6 packets in IEEE 802.15.4 networks. The 6LoWPAN adaptation introduces a dispatching framework that prepends further information to 6LoWPAN packets, including a protocol identifier for IEEE 802.15.4 payload and meta information about link fragmentation.
Prevalent Type-Length-Value (TLV) based packet formats such as in CCNx and NDN are designed to be generic and extensible. This leads to header verbosity which is inappropriate in constrained environments of IEEE 802.15.4 links. This document presents ICN LoWPAN, a convergence layer for IEEE 802.15.4 motivated by 6LoWPAN that compresses packet headers of CCNx as well as NDN and allows for an increased payload size per packet. Additionally by reusing the dispatching framwork defined by 6LoWPAN, compatibility between coexisting wireless networks of competing technologies is enabled. This also allows to reuse the link fragmentation scheme specified by 6LoWPAN for ICN LoWPAN.
ICN LoWPAN utilizes a more space efficient representation of CCNx and NDN packet formats. This syntactic change is described for CCNx and NDN separately, as the header formats and TLV encodings differ largely. For further reductions, default header values suitable for constrained IoT networks are selected in order to elide corresponding TLVs.
In a typical IoT scenario (see Figure 1), embedded devices are interconnected via quasi-stationary infrastructure whith a border router (BR) interconnecting the constrained LoWPAN networks via some Gateway with the public Internet. In ICN based IoT networks, Interest and Data messages transparently travel through the BR up and down between a Gateway and the embedded devices within the constrained LoWPANs.
|Gateway Services|
-------------------------
|
,--------,
| |
| BR |
| |
'--------'
LoWPAN
O O
O
O O embedded
O O O devices
O O
Figure 1: IoT Stub Network
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The use of the term, "silently ignore" is not defined in RFC 2119. However, the term is used in this document and can be similarly construed.
This document uses the terminology of [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.
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.4
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 pre-configuration of global state.
The CCNx and NDN header formats are composed of Type-Length-Value (TLV) fields to encode header data. The advantage of TLVs is its native support of variable-sized data. The main disadvantage of TLVs is the verbosity that results from storing the type and length of the encoded data.
The stateless header compression scheme makes use of compact bit fields to indicate the presence of mandatory and optional TLVs in the uncompressed packet. The order of set bits in the bit fields corresponds to the order of each TLV in the packet. Further compression is achieved by specifying default values and reducing the codomain of certain header fields.
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 the length fields are removed. The third TLV represents a boolean TLV (e.g. the MustBeFresh selector in NDN) and is missing the type, length and the value field.
+---+---+---+---+---+---+---+---+
| 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | Bit field
+---+---+---+---+---+---+---+---+
| | |
,--' '-----------, '- boolean
| |
+-------+--------------+-------------+
| LEN | VALUE | VALUE |
+-------+--------------+-------------+
Figure 3: Compression using a compact bit field to encode context information.
The IEEE 802.15.4 frame header does not provide a protocol identifier for its payload. This causes problems of misinterpreting frames when several networks coexist on the same link layer. To mitigate errors, 6LoWPAN defines dispatches as encapsulation headers for IEEE 802.15.4 frames (see Section 5 of [RFC4944]). Multiple LoWPAN encapsulation headers can prepend 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, then all following encapsulation headers are interpreted by using a dispatch table as specified by the Page switch header. Page 0 and page 1 are reserved for 6LoWPAN. This document defines dispatch types to identify the payload of CCNx or NDN messages under different compression schemes in Table 1 using page 2 (1111 0010 (0xF2)) to assure isolated code spaces.
| Bit Pattern | Page | Header Type |
|---|---|---|
| 0000 0000 | 2 | LOWPAN_CCNX_INT |
| 001x xxxx | 2 | LOWPAN_CCNX_INT_HC |
| 0100 0000 | 2 | LOWPAN_CCNX_DATA |
| 011x xxxx | 2 | LOWPAN_CCNX_DATA_HC |
| ... | 2 | ... |
| 1000 0000 | 2 | LOWPAN_NDN_INT |
| 101x xxxx | 2 | LOWPAN_NDN_INT_HC |
| 1100 0000 | 2 | LOWPAN_NDN_DATA |
| 111x xxxx | 2 | LOWPAN_NDN_DATA_HC |
| ... | 2 | ... |
For backwards compatibility, [RFC8025] does not require a Page switch dispatch type for page 0. For page 2, a Page switch header is needed to indicate a context switch before parsing the dispatch type. As an example, to select page 2 and mark the payload as an uncompressed NDN Interest, the bit pattern reads: 1111 0010 1000 0000.
The encapsulation format for ICN LoWPAN identifying an NDN Interest message is exemplarily displayed in Figure 4.
+---------------+-------------+--------+----------------+-------+
| IEEE 802.15.4 | Dispatches | Page 2 | LOWPAN_NDN_INT | Payl. /
+---------------+-------------+--------+----------------+-------+
Figure 4: LoWPAN Encapsulation of NDN Interest with ICN LoWPAN
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 the fragmentation handling of [RFC4944].
The Fragmentation LoWPAN header can encapsulate other dispatch headers. The order of dispatch types is adopted from [RFC4944]. To use the ICN LoWPAN dispatch types (defined in Table 1), a page switch to page 2 MUST occure. Figure 5 shows the fragmentation scheme. The reassembled ICN LoWPAN frame does not contain any fragmentation headers and is depicted in Figure 6.
+---------------+-----------+--------+----------------+-------------+
| IEEE 802.15.4 | Frag. 1st | Page 2 | LOWPAN_NDN_INT | Payload ... /
+---------------+-----------+--------+----------------+-------------+
+---------------+-----------+-------------+
| IEEE 802.15.4 | Frag. 2nd | ... Payload /
+---------------+-----------+-------------+
.
.
.
+---------------+-----------+-------------+
| IEEE 802.15.4 | Frag. Nth | ... Payload /
+---------------+-----------+-------------+
Figure 5: Fragmentation scheme
+---------------+---------+-----------------+---------+
| IEEE 802.15.4 | Page 2 | LOWPAN_NDN_INT | Payload /
+---------------+---------+-----------------+---------+
Figure 6: Reassembled ICN LoWPAN frame
The NDN packet format consists of TLV fields using the TLV encoding that is described in [NDN-TLV]. Type and length fields are of variable size, where numbers greater than 252 are encoded using multiple octets. Figure 7 shows the NDN TLV encoding scheme.
If the type or length number is less than 253, then that number is encoded into the actual type or length field (Figure 7 a). If the number is greater or equals 253 and fits into 2 octets, then the type or lengh field is set to 253 and the number is encoded in the next following 2 octets in network byte order, i.e., from the most significant byte (MSB) to the least significant byte (LSB) (Figure 7 b). If the number is greater than 2 octets and fits into 4 octets, then the type or length field is set to 254 and the number is encoded in the subsequent 4 octets in network byte order (Figure 7 c). For greater numbers, the type or length field is set to 255 and the number is encoded in the subsequent 8 octets in network byte order (Figure 7 d).
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
a) | < 253 |
+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
b) | 253 | MSB LSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 254 | MSB /
c) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSB |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | MSB /
+-+-+-+-+-+-+-+-+ +
d) | /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSB |
+-+-+-+-+-+-+-+-+
Figure 7: NDN TLV encoding scheme
In this document, compressed NDN TLVs make use of a different TLV scheme that puts more emphasis on size reduction. Instead of using the first octet as a marker for the number of following octets, the compressed NDN TLV scheme uses a method to chain a variable number of octets together. If an octet equals 255 (0xFF), then the following octet will also be interpreted. The actual value of a chain equals the sum of all links.
If the type or length number is less than 255, then that number is encoded into the actual type or length field (Figure 8 a). If the type or length number (X) fits into 2 octets, then the first octet is set to 255 and the subsequent octet equals X mod 255 (Figure 8 b). Following this scheme, a variable-sized number (X) is encoded using multiple octets of 255 with a trailing octet containing X mod 255 (Figure 8 c).
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
a) | < 255 (X) | = X
+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
b) | 255 | < 255 (X) | = 255 + X
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+
c) | 255 | 255 | < 255 (X) | = (N * 255) + X
+-+-+-+-+-+-+-+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+
(N - 1)
Figure 8: Compressed NDN TLV encoding scheme
An uncompressed Interest message uses the LoWPAN dispatch LOWPAN_NDN_INT. The Interest message is handed to the NDN network stack without modifications.
The compression base header makes use of the dispatch type LOWPAN_NDN_INT_HC (Table 1).
By default, the Interest message is compressed with the following rule set: LOWPAN_NDN_INT_HC dispatch (Figure 9).
Further compression rules are given in the
0
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 0 | 1 |NCO|SNC|SEL|GUI|EXT|
+---+---+---+---+---+---+---+---+
Figure 9: Compression base header format for Interest
The short NameComponent TLV encoding encodes the length fields of two consecutive NameComponent TLVs into one octet, using 4 bits each. This process limits the length of a NameComponent TLV to 15 octets and is repeated until a length of 0 is encountered, which marks the end of the Name TLV. This encoding forbids 0 length NameComponent TLVs.
Name: /HAW/Room/481/Humid/12
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| 1 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Length field encoding for short NameComponent TLVs
0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
| minSx | maxSx | ppk | excld | ChildSel | fresh | resvd |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 11: LOWPAN_NDN_INT_HC_SEL
0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
| InterestLifetime |fwdhint| Reserved |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 12: LOWPAN_NDN_INT_HC_GUI
An uncompressed Data message uses the LoWPAN dispatch LOWPAN_NDN_DATA. The Data message is handed to the NDN network stack without modifications.
The compression base header makes use of the dispatch type LOWPAN_NDN_DATA_HC (Table 1).
By default, the Data message is compressed with the following rule set: LOWPAN_NDN_DATA_HC dispatch (Figure 13).
Further compression rules are given in the
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 1 | 0 | 1 |NCO|SNC|MET|EXT| Reserved | SIG |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 13: Compression base header format for Data
0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
| ctype | freshperiod | finalblid |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 14: LOWPAN_NDN_DATA_HC_B
The CCNx TLV encoding is described in [I-D.irtf-icnrg-ccnxmessages]. Type and length fields are of fixed length of 2 octets each.
In this document, the TLV encoding is changed to the more space efficient encoding described in Section 5.1. Type and length fields MUST be encoded as in Figure 8.
An uncompressed Interest message uses the LoWPAN dispatch LOWPAN_CCNX_INT. The Interest message is handed to the CCNx network stack without modifications.
The compression base header makes use of the dispatch type LOWPAN_CCNX_INT_HC (Table 1).
By default, the Interest message is compressed with the following rule set: LOWPAN_CCNX_INT_HC dispatch (Figure 15).
Further compression rules are given in the
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 0 | 1 |NSG|SNS|FLG|HBH|PTY|HPL|FRS|MSG|PAY|VAL|EXT| RESVD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 15: Compression base header format for Interest
Hop-By-Hop Header TLVs are unordered. For an Interest message, two optional Hop-By-Hop Header TLVs are defined in [I-D.irtf-icnrg-ccnxmessages], but several more can be defined in higher level specifications. For better compression, an ordering of Hop-By-Hop TLVs is enforced as follows: LOWPAN_CCNX_INT_HC_HBH so that type fields are elided from the Interest Lifetime TLV and the Message Hash TLV.
This ordering is encoded into
Note: If the original Interest message includes Hop-By-Hop Header TLVs with a different ordering, then they remain uncompressed.
0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
| IntLifetime | MsgHash | Reserved |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 16: LOWPAN_CCNX_INT_HC_HBH
0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
| KeyIDRestr | CObHRestr | Reserved |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 17: LOWPAN_CCNX_INT_HC_MSG
0 1 2 3 4 5 6 7 8
+-------+-------+-------+-------+-------+-------+-------+-------+
| ValidationAlg | KeyID | Reserved |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 18: LOWPAN_CCNX_INT_HC_VAL
The ValidationPayload TLV is present if the ValidationAlgorithm TLV is present. The type field is omitted.
An uncompressed Content Object message uses the LoWPAN dispatch LOWPAN_CCNX_DATA. The Content Object message is handed to the CCNx network stack without modifications.
The compression base header makes use of the dispatch type LOWPAN_CCNX_DATA_HC (Table 1).
By default, the Content Object message is compressed with the following rule set: LOWPAN_CCNX_DATA_HC dispatch (Figure 19).
Further compression rules are given in the
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 0 | 1 |NSG|SNS|FLG|HBH|FRS|MSG|PAY|VAL|EXT| RESVD |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 19: Compression base header format for Content Object
Hop-By-Hop Header TLVs are unordered. For a Content Object message, two optional Hop-By-Hop Header TLVs are defined in [I-D.irtf-icnrg-ccnxmessages], but several more can be defined in higher level specifications. For better compression, an ordering of Hop-By-Hop TLVs is enforced as follows: LOWPAN_CCNX_DATA_HC_HBH so that type fields are elided from the Recommended Cache Time TLV and the Message Hash TLV.
This ordering is encoded into
Note: If the original Content Object message includes Hop-By-Hop Header TLVs with a different ordering, then they remain uncompressed.
0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
| RCT | MsgHash | Reserved |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 20: LOWPAN_CCNX_DATA_HC_HBH
0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
| PayloadType |ExpTime| Reserved |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 21: LOWPAN_CCNX_DATA_HC_MSG
TODO
This document makes use of Page 2 from the existing paging dispatches in [RFC8025].
| [ieee802.15.4] | IEEE Computer Society, "IEEE Std. 802.15.4-2015", April 2016. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [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. |
| [RFC6282] | Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011. |
In the following a theoretical evaluation is given to estimate the gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages.
We assume that n is the number of name components, comps_n denotes the sum of n name component lengths. We also assume that the length of each name component is lower than 16 bytes. The length of the content is given by clen. The lengths of TLV components is specific to the CCNx or NDN encoding and outlined below.
The NDN TLV encoding has variable-sized TLV fields. For simplicity, the 1 octet form of each TLV component is assumed. A typical TLV component therefore is of size 2 (type field + length field) + the actual value.
Figure 22 depicts the size requirements for a basic, uncompressed NDN Interest containing a MustBeFresh selector, a ChildSelector with value 1 (rightmost child) and an InterestLifetime guider set to 4 seconds. Numbers below represent the amount of octets.
------------------------------------,
Interest = 2 |
---------------------, |
Name | 2 + |
NameComponents = 2n + |
| comps_n |
---------------------' |
---------------------, = 21 + 2n + comps_n
Selectors | |
MustBeFresh = 7 |
ChildSelector | |
---------------------' |
Nonce = 6 |
InterestLifetime = 4 |
------------------------------------'
Figure 22: Estimated size of an uncompressed NDN Interest
Figure 23 depicts the size requirements after compression.
------------------------------------,
Dispatch Page Switch = 1 |
LOWPAN_NDN_INT_HC = 1 |
LOWPAN_NDN_INT_HC_SEL = 1 |
LOWPAN_NDN_INT_HC_GUI = 1 |
-----------------------, = 9 + n/2 + comps_n
Name | 1 + |
NameComponents = n/2 + |
| comps_n |
-----------------------' |
Nonce = 4 |
------------------------------------'
Figure 23: Estimated size of a compressed NDN Interest
The NDN Interest message is compressed with the LOWPAN_NDN_INT_HC strategy using the two additional octets LOWPAN_NDN_INT_HC_SEL and LOWPAN_NDN_INT_HC_GUI. The MustBeFresh and Child selectors are omitted. The type and length fields of the Nonce TLV are elided.
The size difference is:
12 + 1.5n octets.
For the name /DE/HH/HAW/BT7, the total size gain is 18 octets, which is 46% of the uncompressed packet.
Figure 24 depicts the size requirements for a basic, uncompressed NDN Data containing a FreshnessPeriod as MetaInfo. A FreshnessPeriod of 10 minutes is assumed and the value is given as 600,000 milliseconds. The value is thereby encoded using 4 octets. An HMACWithSha256 is assumed as signature. The key locator is assumed to contain a Name TLV of length klen.
------------------------------------,
Data = 2 |
---------------------, |
Name | 2 + |
NameComponents = 2n + |
| comps_n |
---------------------' |
---------------------, |
MetaInfo | |
FreshnessPeriod = 8 = 55 + 2n + comps_n +
| | clen + klen
---------------------' |
Content = 2 + clen |
---------------------, |
SignatureInfo | |
SignatureType | |
KeyLocator = 41 + klen |
SignatureValue | |
DigestSha256 | |
---------------------' |
------------------------------------'
Figure 24: Estimated size of an uncompressed NDN Data
Figure 25 depicts the size requirements for the compressed version of the above Data packet.
------------------------------------,
Dispatch Page Switch = 1 |
LOWPAN_NDN_DATA_HC = 2 |
LOWPAN_NDN_DATA_HC_MET = 1 |
-----------------------, |
Name | 1 + = 43 + n/2 + comps_n +
NameComponents = n/2 + | clen + klen
| comps_n |
-----------------------' |
FreshnessPeriod = 4 |
Content = 1 + clen |
KeyLocator = 1 + klen |
DigestSha256 = 32 |
------------------------------------'
Figure 25: Estimated size of a compressed NDN Data
The size difference is:
12 + 1.5n octets.
For the name /DE/HH/HAW/BT7, the total size gain is 18 octets.
The CCNx TLV encoding defines a 2-octet encoding for type and length fields, summing up to 4 octets in total without a value.
Figure 26 depicts the size requirements for a basic, uncompressed CCNx Interest. No Hop-By-Hop TLVs are included and the protocol version as well as the reserved field are assumed to be 0. A KeyIdRestriction TLV with T_SHA-256 is included to limit the responses to Content Objects containing the specific key.
------------------------------------,
Fixed Header = 8 |
Message = 4 |
---------------------, |
Name | 4 + = 56 + 4n + comps_n
NameSegments = 4n + |
| comps_n |
---------------------' |
KeyIdRestriction = 40 |
------------------------------------'
Figure 26: Estimated size of an uncompressed CCNx Interest
Figure 27 depicts the size requirements after compression.
------------------------------------,
Dispatch Page Switch = 1 |
LOWPAN_CCNX_INT_HC = 2 |
LOWPAN_CCNX_INT_HC_MSG = 1 |
Fixed Header = 3 |
-----------------------, = 40 + n/2 + comps_n
Name | 1 + |
NameSegments = n/2 + |
| comps_n |
-----------------------' |
T_SHA-256 = 32 |
------------------------------------'
Figure 27: Estimated size of a compressed CCNx Interest
The size difference is:
16 + 3.5n octets.
For the name /DE/HH/HAW/BT7, the total size gain is 30 octets, which is 36% of the uncompressed packet.
Figure 28 depicts the size requirements for a basic, uncompressed CCNx Data containing an ExpiryTime Message TLV, an HMAC_SHA-256 signature, the signature time and a hash of the shared secret key.
------------------------------------,
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 28: Estimated size of an uncompressed CCNx Data Object
Figure 29 depicts the size requirements for a basic, compressed CCNx Data.
------------------------------------,
Dispatch Page Switch = 1 |
LOWPAN_CCNX_DATA_HC = 2 |
LOWPAN_CCNX_DATA_HC_MSG = 1 |
LOWPAN_CCNX_DATA_HC_VAL = 1 |
Fixed Header = 2 |
-----------------------, |
Name | 1 + = 92 + n/2 + comps_n + clen
NameSegments = n/2 + |
| comps_n |
-----------------------' |
ExpiryTime = 8 |
Payload = 1 + clen |
T_HMAC-SHA256 = 32 |
SignatureTime = 8 |
ValidationPayload = 34 |
------------------------------------'
Figure 29: Estimated size of a compressed CCNx Data Object
The size difference is:
32 + 3.5n octets.
For the name /DE/HH/HAW/BT7, the total size gain is 46 octets.