ICN Adaptation to LowPAN Networks (ICN LoWPAN)
draft-gundogan-icnrg-ccnlowpan-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Cenk Gündoğan , Thomas C. Schmidt , Matthias Wählisch , Christopher Scherb , Claudio Marxer , Christian Tschudin | ||
| Last updated | 2018-03-05 | ||
| Replaced by | draft-irtf-icnrg-icnlowpan, draft-irtf-icnrg-icnlowpan, RFC 9139 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gundogan-icnrg-ccnlowpan-01
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
Abstract
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.
Status of This Memo
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.
Gundogan, et al. Expires September 6, 2018 [Page 1]
Internet-Draft ICN Adaptation to LowPANs March 2018
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of ICN LoWPAN . . . . . . . . . . . . . . . . . . . 5
3.1. Link-Layer Convergence . . . . . . . . . . . . . . . . . 5
3.2. Stateless Header Compression . . . . . . . . . . . . . . 5
4. IEEE 802.15.4 Adaptation . . . . . . . . . . . . . . . . . . 6
4.1. LoWPAN Encapsulation . . . . . . . . . . . . . . . . . . 6
4.2. ICN LoWPAN Fragmentation . . . . . . . . . . . . . . . . 7
5. ICN LoWPAN Header Compression for NDN . . . . . . . . . . . . 8
5.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Interest . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Data . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. ICN LoWPAN Header Compression for CCNx . . . . . . . . . . . 18
6.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Interest . . . . . . . . . . . . . . . . . . . . . . . . 18
6.3. Content Object . . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8.1. Page Switch Dispatch Type . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Normative References . . . . . . . . . . . . . . . . . . 27
9.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Estimated Size Reduction . . . . . . . . . . . . . . 30
A.1. NDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
A.1.1. Interest . . . . . . . . . . . . . . . . . . . . . . 30
A.1.2. Data . . . . . . . . . . . . . . . . . . . . . . . . 31
A.2. CCNx . . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.2.1. Interest . . . . . . . . . . . . . . . . . . . . . . 33
A.2.2. Data . . . . . . . . . . . . . . . . . . . . . . . . 34
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
Gundogan, et al. Expires September 6, 2018 [Page 2]
Internet-Draft ICN Adaptation to LowPANs March 2018
1. Introduction
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
Gundogan, et al. Expires September 6, 2018 [Page 3]
Internet-Draft ICN Adaptation to LowPANs March 2018
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
2. Terminology
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: Information-Centric Networking over Low-power Wireless
Personal Area Network
LLN Low-Power and Lossy Network
Gundogan, et al. Expires September 6, 2018 [Page 4]
Internet-Draft ICN Adaptation to LowPANs March 2018
CCNx: Content-Centric Networking Architecture
NDN: Named Data Networking
3. Overview of ICN LoWPAN
3.1. Link-Layer Convergence
ICN LoWPAN provides a convergence layer that maps ICN packets onto
constrained link-layer technologies. This includes features such as
link-layer fragmentation, protocol separation on the link-layer
level, and link-layer address mappings. The stack traversal is
visualized in 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.
3.2. Stateless Header Compression
ICN LoWPAN also defines a stateless header compression scheme with
the main purpose of reducing header overhead of ICN packets. This is
of particular importance for link-layers with small MTUs. The
stateless compression does not require 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
Gundogan, et al. Expires September 6, 2018 [Page 5]
Internet-Draft ICN Adaptation to LowPANs March 2018
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.
4. IEEE 802.15.4 Adaptation
4.1. LoWPAN Encapsulation
The IEEE 802.15.4 frame header does not provide a protocol identifier
for its payload. This causes problems of misinterpreting frames when
several 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.
Gundogan, et al. Expires September 6, 2018 [Page 6]
Internet-Draft ICN Adaptation to LowPANs March 2018
+-------------+------+---------------------+
| 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 | ... |
+-------------+------+---------------------+
Table 1: ICN Dispatch Types for (un-)compressed CCNx and NDN
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
IEEE 802.15.4: The IEEE 802.15.4 header.
Dispatches: Optional additional dispatch types.
Page Switch 2: This page identifier is set to 1111 0010.
LOWPAN_NDN_INT: This code point is set to 1000 0000.
Payload: The actual NDN Interest Message.
4.2. ICN LoWPAN Fragmentation
Section 5.3 of [RFC4944] defines a protocol independent fragmentation
dispatch type, a fragmentation header for the first fragment and a
Gundogan, et al. Expires September 6, 2018 [Page 7]
Internet-Draft ICN Adaptation to LowPANs March 2018
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
5. ICN LoWPAN Header Compression for NDN
5.1. TLV Encoding
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
Gundogan, et al. Expires September 6, 2018 [Page 8]
Internet-Draft ICN Adaptation to LowPANs March 2018
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.
Gundogan, et al. Expires September 6, 2018 [Page 9]
Internet-Draft ICN Adaptation to LowPANs March 2018
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
5.2. Interest
5.2.1. Uncompressed Interest
An uncompressed Interest message uses the LoWPAN dispatch
"LOWPAN_NDN_INT". The Interest message is handed to the NDN network
stack without modifications.
5.2.2. Compression Base Header Format
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:
1. The outermost Interest TLV is removed.
2. The "Type" field of the Name TLV is removed.
Gundogan, et al. Expires September 6, 2018 [Page 10]
Internet-Draft ICN Adaptation to LowPANs March 2018
3. The "Type" and "Length" fields of the NonceTLV are removed.
Further compression rules are given in the "LOWPAN_NDN_INT_HC"
dispatch (Figure 9).
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
NCO: NameComponent TLVs
0: The Name TLV is uncompressed and all NameComponent TLVs
contain a type field.
1: The first NameComponent TLV keeps the type field and all
type fields of subsequent NameComponent TLVs are elided.
When the Name TLV is decompressed, then the type field of
the first NameComponent TLV is replicated to all other
NameComponent TLVs.
SNC: Short NameComponent TLVs
0: The length fields of NameComponent TLVs are encoded as
described in Figure 8.
1: All NameComponent TLVs are limited in size to 15 octets
each and no 0 length NameComponent TLVs are present. The
compressed length encoding for short NameComponent TLVs
as described in Section 5.2.3 is used. Additionally,
using this encoding, the outermost length field of the
Name TLV is obsolete and removed.
SEL: Selector TLVs
0: No Selector TLVs are present in the Interest message.
1: Selector TLVs are present in the Interest message. An
additional octet follows immediately this dispatch octet
and handles Selector TLV compressions. See
Section 5.2.4.
GUI: Guider TLVs
0: No Guider TLVs are present in the Interest message.
Gundogan, et al. Expires September 6, 2018 [Page 11]
Internet-Draft ICN Adaptation to LowPANs March 2018
1: Guider TLVs are present in the Interest message. An
additional octet follows immediately this dispatch octet
and handles Guider TLV compressions. See Section 5.2.5.
EXT: Extension
0: No extension octet follows.
1: An extension octet follows immediately. Extension octets
are used to extend the compression scheme, but are out of
scope of this document.
5.2.3. Short NameComponent TLV Encoding
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
5.2.4. Selectors Compression
0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
| minSx | maxSx | ppk | excld | ChildSel | fresh | resvd |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 11: LOWPAN_NDN_INT_HC_SEL
Gundogan, et al. Expires September 6, 2018 [Page 12]
Internet-Draft ICN Adaptation to LowPANs March 2018
minSX: 1 bit flag. If set, then MinSuffixComponents are present in
the Interest message and the type field is removed.
maxSX: 1 bit flag. If set, then MaxSuffixComponents are present in
the Interest message and the type field is removed.
ppk: 1 bit flag. If set, then a PublisherPublicKeyLocator is
present in the Interest message and the type field is
removed.
excld: 1 bit flag. If set, then an exclude selector is present in
the Interest message and the type field is removed.
ChildSel: ChildSelector TLV
00: The ChildSelector is absent and a value of 0 is assumed.
01: The ChildSelector with value 0 was removed during the
compression.
10: The ChildSelector with value 1 was removed during the
compression.
fresh: 1 bit flag. If set, then a MustBeFresh selector is present
in the Interest message and the type and length fields are
removed.
resvd: 1 bit reserved and MUST be set to 0.
5.2.5. Guiders Compression
0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
| InterestLifetime |fwdhint| Reserved |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 12: LOWPAN_NDN_INT_HC_GUI
InterestLifetime TLV
000: The InterestLifetime TLV is absent in the original packet
and a default value of 4 seconds is assumed.
001: The InterestLifetime TLV is present and the type field is
removed. The length field is removed and assumed to be
"1".
Gundogan, et al. Expires September 6, 2018 [Page 13]
Internet-Draft ICN Adaptation to LowPANs March 2018
010: The InterestLifetime TLV is present and the type field is
removed. The length field is removed and assumed to be
"2".
011: The InterestLifetime TLV is present and the type field is
removed. The length field is removed and assumed to be
"4".
100: The InterestLifetime TLV is present and the type field is
removed. The length field is removed and assumed to be
"8".
101: The InterestLifetime TLV with value 4 seconds is present
in the Interest message. It is removed on compression
and inserted on decompression.
110: Reserved.
111: Reserved.
fwdhint: 1 bit flag. If set, then a ForwardingHint TLV is present
in the Interest message and the type field is removed.
5.3. Data
5.3.1. Uncompressed Data
An uncompressed Data message uses the LoWPAN dispatch
"LOWPAN_NDN_DATA". The Data message is handed to the NDN network
stack without modifications.
5.3.2. Compression Base Header Format
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:
1. The outermost Data TLV is removed.
2. The "Type" field of the Name TLV is removed.
3. The "Type" field of the MetaInfo TLV is removed.
4. The "Type" field of the Content TLV is removed.
5. The "Type" field of the SignatureInfo TLV is removed.
Gundogan, et al. Expires September 6, 2018 [Page 14]
Internet-Draft ICN Adaptation to LowPANs March 2018
6. The "Type" field of the SignatureValue TLV is removed.
Further compression rules are given in the "LOWPAN_NDN_DATA_HC"
dispatch (Figure 13).
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
NCO: NameComponent TLVs See Section 5.2.2.
SNC: Short NameComponent TLVs See Section 5.2.2.
MET: MetaInfo TLVs
0: No MetaInfo TLVs are present in the Data message.
1: MetaInfo TLVs are present in the Data message. An
additional octet follows immediately that handles
MetaInfo TLV compressions and is described in
Section 5.3.3.
EXT: Extension See Section 5.2.2.
SIG: Signature TLVs
0000: The type fields of the SignatureInfo TLV, SignatureType
TLV and SignatureValue TLV are removed.
0001: The Signature represents a DigestSha256. The
SignatureInfo and SignatureValue TLVs are absent. The 32
byte digest immediately follows the content.
0010: The Signature represents a SignatureSha256WithRsa. The
SignatureInfo TLV is absent and the SignatureValue TLV is
present without a type field. A KeyLocator TLV without a
type field follows immediately the content. The RSA
signature immediately follows the SignatureValue TLV.
0011: The Signature represents a SignatureSha256WithEcdsa. The
SignatureInfo TLV is absent and the SignatureValue TLV is
present without a type field. A KeyLocator TLV without a
type field follows immediately the content. The ECDSA
signature immediately follows the SignatureValue TLV.
Gundogan, et al. Expires September 6, 2018 [Page 15]
Internet-Draft ICN Adaptation to LowPANs March 2018
0100: The Signature represents a SignatureHmacWithSha256. The
SignatureInfo and SignatureValue TLVs are absent. A
KeyLocator TLV without a type field follows immediately
the content. The 32 byte HMAC signature follows
immediately the Keylocator TLV
0101: Reserved.
0110: Reserved.
0111: Reserved.
1000: Reserved.
1001: Reserved.
1010: Reserved.
1011: Reserved.
1100: Reserved.
1101: Reserved.
1110: Reserved.
1111: Reserved.
5.3.3. MetaInfo Compression
0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
| ctype | freshperiod | finalblid |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 14: LOWPAN_NDN_DATA_HC_B
ctype: ContentType TLV
000: The ContentType TLV is absent in the original Data
message and the default value "0" is assumed.
001: The ContentType TLV is present and the type field is
removed. The length field is removed and assumed to be
"1".
Gundogan, et al. Expires September 6, 2018 [Page 16]
Internet-Draft ICN Adaptation to LowPANs March 2018
010: The ContentType TLV is present and the type field is
removed. The length field is removed and assumed to be
"2".
011: The ContentType TLV is present and the type field is
removed. The length field is removed and assumed to be
"4".
100: The ContentType TLV is present and the type field is
removed. The length field is removed and assumed to be
"8".
101: The ContentType TLV with value 0 is present in the Data
message. It is removed on compression and inserted on
decompression.
110: Reserved.
111: Reserved.
freshperiod: FreshnessPeriod TLV
000: The FreshnessPeriod TLV is absent in the original Data
message.
001: The FreshnessPeriod TLV is present and the type field is
removed. The length field is removed and assumed to be
"1".
010: The FreshnessPeriod TLV is present and the type field is
removed. The length field is removed and assumed to be
"2".
011: The FreshnessPeriod TLV is present and the type field is
removed. The length field is removed and assumed to be
"4".
100: The FreshnessPeriod TLV is present and the type field is
removed. The length field is removed and assumed to be
"8".
101: Reserved.
110: Reserved.
111: Resedved.
finalblid: FinalBLockId TLV
Gundogan, et al. Expires September 6, 2018 [Page 17]
Internet-Draft ICN Adaptation to LowPANs March 2018
00: The FinalBlockId TLV is absent.
01: The FinalBlockId TLV is absent, but a FinalBlockId TLV
equal to the last NameComponent TLV of the Data message
name is assumed.
10: The FinalBlockId TLV is present and the type field is
removed.
11: Reserved.
6. ICN LoWPAN Header Compression for CCNx
6.1. TLV Encoding
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.
6.2. Interest
6.2.1. Uncompressed Interest
An uncompressed Interest message uses the LoWPAN dispatch
"LOWPAN_CCNX_INT". The Interest message is handed to the CCNx
network stack without modifications.
6.2.2. Compression Base Header Format
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:
1. The type and length fields of the CCNx Message TLV are elided and
are obtained from the Fixed Header on decompression.
Further compression rules are given in the "LOWPAN_CCNX_INT_HC"
dispatch (Figure 15).
Gundogan, et al. Expires September 6, 2018 [Page 18]
Internet-Draft ICN Adaptation to LowPANs March 2018
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
NSG: NameSegment TLVs See Section 5.2.2.
SNS: Short NameSegment TLVs See Section 5.2.2.
FLG: Flags field in the Fixed Header
0: The Flags field equals 0 and is removed from the Interest
message.
1: The Flags field is carried in-line.
HBH: Optional Hop-By-Hop Header TLVs
0: No Hop-By-Hop Header TLVs are present in the Interest
message. Also, the HeaderLength field in the fixed
header is elided from the Interest message and assumed to
be "8".
1: Hop-By-Hop Header TLVs are present in the Interest
message. An additional octet follows immediately that
handles Hop-By-Hop Header TLV compressions and is
described in Section 6.2.3.
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 is carried in-line
1: The HopLimit field is elided and assumed to be "1"
FRS: Reserved field in the fixed header
0: The Reserved field is carried in-line
Gundogan, et al. Expires September 6, 2018 [Page 19]
Internet-Draft ICN Adaptation to LowPANs March 2018
1: The Reserved field is elided and assumed to be "0"
MSG: Optional Interest Message TLVs
0: No Interest Message TLVs are present in the Interest
message.
1: Interest Message TLVs are present in the Interest
message. An additional octet follows immediately that
handles Interest Message TLV compressions and is
described in Section 6.2.4.
PAY: Optional Payload TLV
0: The Payload TLV is absent.
1: The Payload TLV is present and the type field is elided.
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 octet follows immediately that
handles validation related TLV compressions and is
described in Section 6.2.5.
EXT: Extension
0: No extension octet follows.
1: An extension octet follows immediately. Extension octets
are used to extend the compression scheme, but are out of
scope of this document.
6.2.3. Hop-By-Hop Header TLVs Compression
Hop-By-Hop Header TLVs are unordered. For an Interest message, two
optional Hop-By-Hop Header TLVs are defined in
[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:
1. Interest Lifetime TLV
2. Message Hash TLV
Gundogan, et al. Expires September 6, 2018 [Page 20]
Internet-Draft ICN Adaptation to LowPANs March 2018
This ordering is encoded into "LOWPAN_CCNX_INT_HC_HBH" so that type
fields are elided from the Interest Lifetime TLV and the Message Hash
TLV.
Note: If the original Interest message includes Hop-By-Hop Header
TLVs 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
IntLifetime: InterstLifetime Hop-By-Hop Header TLV
00: The Interest Lifetime TLV is absent.
01: The Interest Lifetime TLV is present and the type field
is removed.
10: The Interest Lifetime TLV is absent and a default value
of 0 seconds is assumed.
11: The Interest Lifetime TLV is absent and a default value
of 10 minutes is assumed.
MsgHash: Message Hash Hop-By-Hop Header TLV
00: The Message Hash TLV is absent.
01: The Message Hash TLV is present and uncompressed.
10: A T_SHA-256 TLV is present and the type field as well as
the length fields are removed. The length field is
assumed to represent 32 octets. The outer Message Hash
TLV is omitted.
11: A T_SHA-512 TLV is present and the type field as well as
the length fields are removed. The length field is
assumed to represent 64 octets. The outer Message Hash
TLV is omitted.
6.2.4. Interest Message TLVs Compression
Gundogan, et al. Expires September 6, 2018 [Page 21]
Internet-Draft ICN Adaptation to LowPANs March 2018
0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
| KeyIDRestr | CObHRestr | Reserved |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 17: LOWPAN_CCNX_INT_HC_MSG
KeyIDRestr: Optional KeyIdRestriction TLV within a CCNx Message TLV
00: The KeyIdRestriction TLV is absent.
01: The KeyIdRestriction TLV is present and uncompressed.
10: A T_SHA-256 TLV is present and the type field as well as
the length fields are removed. The length field is
assumed to represent 32 octets. The outer
KeyIdRestriction TLV is omitted.
11: A T_SHA-512 TLV is present and the type field as well as
the length fields are removed. The length field is
assumed to represent 64 octets. The outer
KeyIdRestriction TLV is omitted.
CObHRestr: Optional ContentObjectHashRestriction TLV within a CCNx
Message TLV
00: The ContentObjectHashRestriction TLV is absent.
01: The ContentObjectHashRestriction TLV is present and
uncompressed.
10: A T_SHA-256 TLV is present and the type field as well as
the length fields are removed. The length field is
assumed to represent 32 octets. The outer
ContentObjectHashRestriction TLV is omitted.
11: A T_SHA-512 TLV is present and the type field as well as
the length fields are removed. The length field is
assumed to represent 64 octets. The outer
ContentObjectHashRestriction TLV is omitted.
6.2.5. Validation
Gundogan, et al. Expires September 6, 2018 [Page 22]
Internet-Draft ICN Adaptation to LowPANs March 2018
0 1 2 3 4 5 6 7 8
+-------+-------+-------+-------+-------+-------+-------+-------+
| ValidationAlg | KeyID | Reserved |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 18: LOWPAN_CCNX_INT_HC_VAL
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
Sigtime 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 inclued. Additionally, a
Sigtime 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
Gundogan, et al. Expires September 6, 2018 [Page 23]
Internet-Draft ICN Adaptation to LowPANs March 2018
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 field as well as
the length fields are removed. The length field is
assumed to represent 32 octets. The outer KeyId TLV is
omitted.
11: A T_SHA-512 TLV is present and the type field as well as
the length fields are removed. The length field is
assumed to represent 64 octets. The outer KeyId TLV is
omitted.
The ValidationPayload TLV is present if the ValidationAlgorithm TLV
is present. The type field is omitted.
6.3. Content Object
6.3.1. Uncompressed Content Object
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.
6.3.2. Compression Base Header Format
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:
1. The PacketType field is elided from the Fixed Header.
2. The type and length fields of the CCNx Message TLV are elided and
are obtained from the Fixed Header on decompression.
Further compression rules are given in the "LOWPAN_CCNX_DATA_HC"
dispatch (Figure 19).
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
Gundogan, et al. Expires September 6, 2018 [Page 24]
Internet-Draft ICN Adaptation to LowPANs March 2018
NSG: NameSegment TLVs See Section 5.2.2.
SNS: Short NameSegment TLVs See Section 5.2.2.
FLG: Flags field in the fixed header See Section 6.2.2.
HBH: Optional Hop-By-Hop Header TLVs
0: No Hop-By-Hop Header TLVs are present in the Content
Object message. Also, the HeaderLength field in the
fixed header is elided from the Content Object message
and assumed to be "8".
1: Hop-By-Hop Header TLVs are present in the Content Object
message. An additional octet follows immediately that
handles Hop-By-Hop Header TLV compressions and is
described in Section 6.3.3.
FRS: Reserved field in the Fixed Header See Section 6.2.2.
MSG: Optional Content Object Message TLVs
0: No Content Object Message TLVs are present in the Content
Object message.
1: Content Object Message TLVs are present in the Content
Object message. An additional octet follows immediately
that handles Content Object Message TLV compressions and
is described in Section 6.3.4.
PAY: Optional Payload TLV See Section 6.2.2.
VAL: Optional ValidationAlgorithm and ValidationPayload TLVs See Sec
tion 6.2.2.
EXT: Extension See Section 6.2.2.
6.3.3. Hop-By-Hop Header TLVs Compression
Hop-By-Hop Header TLVs are unordered. For a Content Object message,
two optional Hop-By-Hop Header TLVs are defined in
[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:
1. Recommended Cache Time TLV
2. Message Hash TLV
Gundogan, et al. Expires September 6, 2018 [Page 25]
Internet-Draft ICN Adaptation to LowPANs March 2018
This ordering is encoded into "LOWPAN_CCNX_DATA_HC_HBH" so that type
fields are elided from the Recommended Cache Time TLV and the Message
Hash TLV.
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
RCT: Recommended Cache Time Hop-By-Hop Header TLV
0: The Recommended Cache Time TLV is absent.
1: The Recommended Cache Time TLV is present and the type as
well as the length fields are elided.
MsgHash: Message Hash Hop-By-Hop Header TLV See Section 6.2.3.
6.3.4. Content Object Message TLVs Compression
0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
| PayloadType |ExpTime| Reserved |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 21: LOWPAN_CCNX_DATA_HC_MSG
PayloadType: Optional PayloadType TLV within a CCNx Message TLV
00: The PayloadType TLV is absent and T_PAYLOADTYPE_DATA is
assumed.
01: The PayloadType TLV is absent and T_PAYLOADTYPE_KEY is
assumed.
10: The PayloadType TLV is absent and T_PAYLOADTYPE_LINK is
assumed.
11: The PayloadType TLV is present and uncompressed.
ExpTime: Optional ExpiryTime TLV within a CCNx Message TLV
0: The ExpiryTime TLV is absent.
Gundogan, et al. Expires September 6, 2018 [Page 26]
Internet-Draft ICN Adaptation to LowPANs March 2018
1: The ExpiryTime TLV is present and the type as well as the
length fields are elided.
7. Security Considerations
TODO
8. IANA Considerations
8.1. Page Switch Dispatch Type
This document makes use of "Page 2" from the existing paging
dispatches in [RFC8025].
9. References
9.1. Normative References
[ieee802.15.4]
IEEE Computer Society, "IEEE Std. 802.15.4-2015", April
2016, <https://standards.ieee.org/findstds/
standard/802.15.4-2015.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>.
[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>.
9.2. Informative References
[CCN-LITE]
"CCN-lite: A lightweight CCNx and NDN implementation",
<http://ccn-lite.net/>.
[I-D.irtf-icnrg-ccnxmessages]
Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV
Format", draft-irtf-icnrg-ccnxmessages-06 (work in
progress), October 2017.
Gundogan, et al. Expires September 6, 2018 [Page 27]
Internet-Draft ICN Adaptation to LowPANs March 2018
[I-D.irtf-icnrg-ccnxsemantics]
Mosko, M., Solis, I., and C. Wood, "CCNx Semantics",
draft-irtf-icnrg-ccnxsemantics-06 (work in progress),
October 2017.
[NDN] Jacobson, V., Smetters, D., Thornton, J., and M. Plass,
"Networking Named Content", 5th Int. Conf. on emerging
Networking Experiments and Technologies (ACM CoNEXT),
2009, <https://doi.org/10.1145/1658939.1658941>.
[NDN-EXP] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, TC., and M.
Waehlisch, "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-MAC] Kietzmann, P., Gundogan, C., Schmidt, TC., Hahm, O., and
M. Waehlisch, "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-TLV] "NDN Packet Format Specification",
<http://named-data.net/doc/NDN-packet-spec/0.2.1/>.
[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>.
[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>.
Gundogan, et al. Expires September 6, 2018 [Page 28]
Internet-Draft ICN Adaptation to LowPANs March 2018
[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>.
Gundogan, et al. Expires September 6, 2018 [Page 29]
Internet-Draft ICN Adaptation to LowPANs March 2018
Appendix A. Estimated Size Reduction
In the following a theoretical evaluation is given to estimate the
gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages.
We assume that "n" is the number of name components, "comps_n"
denotes the sum of n name component lengths. We also assume that the
length of each name component is lower than 16 bytes. The length of
the content is given by "clen". The lengths of TLV components is
specific to the CCNx or NDN encoding and outlined below.
A.1. NDN
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.
A.1.1. Interest
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.
Gundogan, et al. Expires September 6, 2018 [Page 30]
Internet-Draft ICN Adaptation to LowPANs March 2018
------------------------------------,
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.
A.1.2. Data
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.
Gundogan, et al. Expires September 6, 2018 [Page 31]
Internet-Draft ICN Adaptation to LowPANs March 2018
------------------------------------,
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.
Gundogan, et al. Expires September 6, 2018 [Page 32]
Internet-Draft ICN Adaptation to LowPANs March 2018
A.2. CCNx
The CCNx TLV encoding defines a 2-octet encoding for type and length
fields, summing up to 4 octets in total without a value.
A.2.1. Interest
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.
Gundogan, et al. Expires September 6, 2018 [Page 33]
Internet-Draft ICN Adaptation to LowPANs March 2018
A.2.2. Data
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.
Gundogan, et al. Expires September 6, 2018 [Page 34]
Internet-Draft ICN Adaptation to LowPANs March 2018
------------------------------------,
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.
Acknowledgments
Authors' Addresses
Cenk Gundogan
HAW Hamburg
Berliner Tor 7
Hamburg D-20099
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
Hamburg D-20099
Germany
EMail: t.schmidt@haw-hamburg.de
URI: http://inet.haw-hamburg.de/members/schmidt
Gundogan, et al. Expires September 6, 2018 [Page 35]
Internet-Draft ICN Adaptation to LowPANs March 2018
Matthias Waehlisch
link-lab & FU Berlin
Hoenower Str. 35
Berlin D-10318
Germany
EMail: mw@link-lab.net
URI: http://www.inf.fu-berlin.de/~waehl
Christopher Scherb
University of Basel
Spiegelgasse 1
Basel CH-4051
Switzerland
EMail: christopher.scherb@unibas.ch
Claudio Marxer
University of Basel
Spiegelgasse 1
Basel CH-4051
Switzerland
EMail: claudio.marxer@unibas.ch
Christian Tschudin
University of Basel
Spiegelgasse 1
Basel CH-4051
Switzerland
EMail: christian.tschudin@unibas.ch
Gundogan, et al. Expires September 6, 2018 [Page 36]