CCN Packet Adaptation to IEEE 802.15.4 Networks
draft-gundogan-icnrg-ccnlowpan-00
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 | 2017-09-23 | ||
| 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-00
ICN Research Group C. Gundogan
Internet-Draft T. Schmidt
Intended status: Experimental HAW Hamburg
Expires: March 26, 2018 M. Waehlisch
link-lab & FU Berlin
C. Scherb
C. Marxer
C. Tschudin
University of Basel
September 22, 2017
CCN Packet Adaptation to IEEE 802.15.4 Networks
draft-gundogan-icnrg-ccnlowpan-00
Abstract
Prevalent TLV-based CCN packet formats such as CCNx and NDN are
designed to be generic and extensible. This leads to header
verbosity which is not acceptable in constrained environments where
small-sized MTU link-layers like IEEE 802.15.4 are deployed. This
document presents an adaptation layer for IEEE 802.15.4 that reduces
CCNx and NDN packet header sizes for an increased payload size.
Further, a link fragmentation on this adaptation layer is described.
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 March 26, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
Gundogan, et al. Expires March 26, 2018 [Page 1]
Internet-Draft CCN on IEEE 802.15.4 Networks September 2017
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. CCN-LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. TLV Compression . . . . . . . . . . . . . . . . . . . . . 5
3.2. Name Compression . . . . . . . . . . . . . . . . . . . . 6
3.3. Dispatch Page & Type . . . . . . . . . . . . . . . . . . 7
3.4. CCN-LoWPAN Fragmentation . . . . . . . . . . . . . . . . 8
3.5. CCN-LoWPAN NDN Format Specific Header . . . . . . . . . . 8
3.5.1. Interest . . . . . . . . . . . . . . . . . . . . . . 8
3.5.2. Data . . . . . . . . . . . . . . . . . . . . . . . . 10
3.6. CCN-LoWPAN CCNx Format Specific Header . . . . . . . . . 12
3.6.1. Interest . . . . . . . . . . . . . . . . . . . . . . 13
3.6.2. Data . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Normative References . . . . . . . . . . . . . . . . . . 16
5.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
This document decribes a method to reduce the header size of Content-
centric Networking (CCN) packet formats like CCNx and the NDN (Named
Data Networking) TLV [NDN][NDN-TLV]. This includes reducing the size
of the TLV format as well as omitting optional TLVs by assuming sane
default values. The compression method is inspired by the 6LoWPAN
concept [RFC4944][RFC6282], where an adaptation layer for IPv6 on
IEEE 802.15.4 is provided.
In the typical IoT scenario (Figure 1), embedded devices are
interconnected via quasi-stationary infrastructure, where a border
gateway router (BGR) sits at the junction of separate constrained
LoWPAN networks and the Internet. For CCN, Interest and Data
messages are supposed to travel up to the embedded devices in the
contrained LoWPANs.
Gundogan, et al. Expires March 26, 2018 [Page 2]
Internet-Draft CCN on IEEE 802.15.4 Networks September 2017
NDN / CCNx
-------------------------
|
|
,-------,
| |
| BGR |
O | |
O '-------'
O LoWPAN
O O
O
O O O O O O
O
O O O embedded
O O O devices
O O O
Figure 1: IoT 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:
CCN-LoWPAN: Content-centric Networking over Low-power Wireless
Personal Area Network
TLV: Type Length Value
3. CCN-LoWPAN
The objective of this document is to define an adaptation layer that
1. registers CCNx and NDN packet format dispatch types for IEEE
802.15.4 frames,
2. handles packet header compression and
Gundogan, et al. Expires March 26, 2018 [Page 3]
Internet-Draft CCN on IEEE 802.15.4 Networks September 2017
3. adopts the 6LoWPAN link fragmentation ([RFC4944]) to enable
transmissions over IEEE 802.15.4 for packets larger than the
Maximum Transmission Unit (MTU) of 127 bytes.
The adaptation is handled on a convergence layer between the actual
CCN layer (L3) and the IEEE 802.15.4 link-layer (L2). The adaptation
is transparent to any application inside the low-power network.
Therefore, after the packet was received on any IoT node, it is
transformed and parsed as a standard CCN message by the CCN layer.
As such, the message is passed to the common CCN forwarding pipeline
(Router) or an application (Figure 2).
Device 1 Device 2
,------------------, Router ,------------------,
| Application . | __________________ | ,-> Application |
|----------------|-| | NDN / CCN | |-|----------------|
| NDN / CCN | | | ,--------------, | | | NDN / CCN |
|----------------|-| |-|--------------|-| |-|----------------|
| CCN-LoWPAN | | | | CCN-LoWPAN | | | | CCN-LoWPAN |
|----------------|-| |-|--------------|-| |-|----------------|
| 802.15.4 | | | | 802.15.4 | | | | 802.15.4 |
'----------------|-' '-|--------------|-' '-|----------------'
'--------' '---------'
Figure 2: Hop-By-Hop Adaptation
The parsing of position independent TLVs relies on the Type field to
identify a specific TLV. The CCNx and NDN packet formats however
mostly consist of TLVs with fixed position. The proposed packet
compression 1) reduces TLV sizes by removing the Type field of TLVs
and 2) reduces the header length by omitting TLVs and assuming sane
default values as specified in this document.
In a compressed packet, a CCN-LoWPAN header is prepended and
describes the compression scheme. CCN-LoWPAN defines packet format
specific headers for Interest and Data packets separately.
Figure 3 shows the header structure for the proposed CCN-LoWPAN
adaptation layer.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| ... Dispatch Types ... | CCN-LoWPAN | ... Payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 3: Dispatch Type + CCN-LoWPAN Header
Dispatch Types: Dispatch types for LoWPAN frames ([RFC4944]).
Dispatch types specifically for CCN-LoWPAN are
Gundogan, et al. Expires March 26, 2018 [Page 4]
Internet-Draft CCN on IEEE 802.15.4 Networks September 2017
defined in Section 3.3 of this document. CCN-LoWPAN
makes use of the Dispatch Page "2" ([RFC8025]).
CCN-LoWPAN: A packet format specific CCN-LoWPAN header.
Payload: A compressed CCNx or NDN packet.
The bits in the CCN-LoWPAN header define which header field TLVs are
present. The order of the TLVs in the compressed header corresponds
to the order of the bits from MSB to LSB, as described in
Section 3.1. The compressed CCN packet follows immediately the CCN-
LoWPAN header.
3.1. TLV Compression
TLV (Type, Length, Value) is an extendible method to encode data.
The actual Value field of a TLV is thereby marked with a Type field
and a Length field. Providing the length of the value is beneficial
for parsing, since it allows variable-sized data and enables non-
linear skipping of TLVs using the Length field as offset. TLVs are
position independent, because of the Type field denoting the data to
parse. A typical series of TLVs is shown in Figure 4.
+-------+-------+-----------------+-------+-------+-----------+
| TYP | LEN | VALUE | TYP | LEN | VALUE |
+-------+-------+-----------------+-------+-------+-----------+
The Type and Length fields may also be of variable lengths depending
on the TLV encoding.
Figure 4: An uncompressed series of TLVs
In contrast to fixed-sized and ordered fields, TLVs have the
disadvantage of being much more verbose by providing the Type and the
Length in addition to the Value. For computer networks running IEEE
802.11 or Ethernet this may not pose a problem, but for networks
using small-sized MTU networks like IEEE 802.15.4 this overhead is
crucial.
This compression scheme reduces the overhead in a series of TLVs.
For a series of TLVs with each TLV having a fixed position in the
series, the Type field of each TLV is omitted, leaving only a series
of LVs. The order of TLVs thus MUST be known by the packet format
parser. In addition to this extended parser logic, a bitfield
representing the presence of a TLV is necessary to support optional
TLVs in the series. Figure 5 demonstrates how the overhead of a
series of TLVs is reduced by excluding the Type fields. Instead of
encoding the Type inside a TLV, the Type is defined by one
Gundogan, et al. Expires March 26, 2018 [Page 5]
Internet-Draft CCN on IEEE 802.15.4 Networks September 2017
corresponding bit in the bitfield. If the bit is set, the Length and
the Value are assumed by the parser to be present in the order of the
set bits in the bitfield (see first set bit in the Figure).
Additionally, if the field has a fixed length (e.g. a 32-bit number),
the Length field MUST be omitted, too (see second set bit in the
Figure). If a TLV contains just a boolean value, then setting the
correct bit in the bitfield encodes the Type and the boolean value.
No further fields are enocded in the series (see third set bit in the
Figure).
+---+---+---+---+---+---+---+---+
| 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | Bitfield
+---+---+---+---+---+---+---+---+
| | |
,--' '-----------, '- boolean
| |
+-------+--------------+-------------+
| LEN | VALUE | VALUE | Compressed TLV series
+-------+--------------+-------------+
Figure 5: A comressed series of TLVs
Note: This compresssion scheme extends the packet parser complexity
in order to reduce the TLV series. It reduces the overhead of the
TLV encoding and does not modify the contained data in the Value
field.
3.2. Name Compression
Name components in CCNx and NDN are structured as shown in Figure 6.
,-----------------------------------------------------,
| | ,----------------, ,----------------, |
| Name TL | | Comp. TL | ... | ... | Comp. TL | ... | |
| | '----------------' '----------------' |
'-----------------------------------------------------'
Figure 6: Verbosity of Name TLVs in NDN
Each name component is marked by a TLV, which contains a series of
name component TLVs. In this compression scheme, the Type field of
name components is removed, leaving a series of LVs. Given the total
length in the Name TLV, the name component TLV series is further
reduced by removing the Length field and reserving a character for
separating name components ("CSEP"). In this document, "CSEP" is set
to ascii 0x00. All occurences of the "CSEP" character within a name
component MUST be escaped wit another "CSEP". "CSEP CSEP" therefore
Gundogan, et al. Expires March 26, 2018 [Page 6]
Internet-Draft CCN on IEEE 802.15.4 Networks September 2017
transforms to "CSEP" within names. A compressed TLV for the name is
given in Figure 7.
,-------------------------------------------,
| | |
| Name TL | Comp. CSEP Comp. CSEP ... Comp. |
| | |
'-------------------------------------------'
Figure 7: Compressed Name TLVs in NDN
Names can opionally further be compressed by limiting the alphabet to
a reduced set for a specific use case, or by using a LZ77-style
compression like in [RFC7400]. Both additions are out of scope of
this document.
3.3. Dispatch Page & Type
Similar to 6LoWPAaN (Section 5.1 of [RFC4944]), this document defines
dispatch types to identify the payload as (un-)compressed CCNx or NDN
headers (Table 1). [RFC8025] further specifies dispatch pages to
switch between different dispatch contexts. For an orthogonal code
space, this document specifies the use of page 2 ("1111 0010
(0xF2)"). Section 6.2 of [RFC8025] gives an overview of unassigned
dispatch pages and types.
+------------------+------+-------------------------------------+
| Bit Pattern | Page | Header Type |
+------------------+------+-------------------------------------+
| 0000 0000 (0x00) | 2 | Uncompressed CCNx Header (Interest) |
| 0000 0001 (0x01) | 2 | Uncompressed CCNx Header (Data) |
| 0000 0010 (0x02) | 2 | Uncompressed NDN Header (Interest) |
| 0000 0011 (0x03) | 2 | Uncompressed NDN Header (Data) |
| 0001 0000 (0xF0) | 2 | CCN-LoWPAN CCNx Header (Interest) |
| 0001 0001 (0xF1) | 2 | CCN-LoWPAN CCNx Header (Data) |
| 0001 0010 (0xF2) | 2 | CCN-LoWPAN NDN Header (Interest) |
| 0001 0011 (0xF3) | 2 | CCN-LoWPAN NDN Header (Data) |
+------------------+------+-------------------------------------+
Table 1: 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 MUST be
specified 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 header for Interests, the bit pattern is as follows:
"1111 0010 0000 0001".
Gundogan, et al. Expires March 26, 2018 [Page 7]
Internet-Draft CCN on IEEE 802.15.4 Networks September 2017
3.4. CCN-LoWPAN Fragmentation
IEEE 802.15.4 provides a maximum physical layer packet size of 127
octets. The maximum frame size can be 25 octets, which leaves 102
octets for payload. IEEE 802.15.4 security features can even reduce
this payload length by a maximum of 21 octets, yielding a minimum
total net of 81 octets for CCNx or NDN packet headers, signatures and
content. To support packet sizes greater than this restriction, a
link fragmentation and reassembly scheme is necessary.
Section 5.3 of [RFC4944] defines a protocol independent fragmentation
dispatch type and a fragmentation header for the first fragment and a
separate fragmentation header for subsequent fragments. CCN-LoWPAN
adopts the fragmentation handling of [RFC4944].
The Fragmentation dispatch type is prepended to other dispatch types
and the payload. The order of dispatch types is adopted from
[RFC4944]. To use the CCN-LoWPAN dispatch types (defined in
Table 1), a page switch to page 2 MUST occure.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Fr. Type + Header | Disp. Page 2 | CCN-LoWPAN NDN Int. | Payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 8: Dispatch Types including Fragmentation
3.5. CCN-LoWPAN NDN Format Specific Header
In this section the compression scheme for NDN Interest and Data
object packets is defined. The packet format specification is
obtained from [NDN-TLV].
3.5.1. Interest
The dispatch type bit pattern is "0001 0010 (0xF2)" (Table 1). An
uncompressed NDN Interest message is structured as shown in Figure 9.
where optional components are marked by a "?".
Gundogan, et al. Expires March 26, 2018 [Page 8]
Internet-Draft CCN on IEEE 802.15.4 Networks September 2017
Interest ::= INTEREST-TYPE TLV-LENGTH
Name
Selectors?
Nonce
InterestLifetime?
ForwardingHint?
Selectors ::= SELECTORS-TYPE TLV-LENGTH
MinSuffixComponents?
MaxSuffixComponents?
PublisherPublicKeyLocator?
Exclude?
ChildSelector?
MustBeFresh?
Figure 9: NDN Interest BNF
The packet specific compression header for the NDN Interest message
is defined as shown in Figure 10.
0 1 2 3 4 5 6 7 8
+-------+-------+-------+-------+-------+-------+-------+-------+
| minSx | maxSx | ppk | excld | ChSel | fresh | IntLT | resv |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 10: NDN Interest Compression Header
minSX: 1 bit flag. If set, then MinSuffixComponents are available
in the compressed NDN Interest packet.
maxSX: 1 bit flag. If set, then MaxSuffixComponents are available
in the compressed NDN Interest packet.
ppk: 1 bit flag. If set, then a PublisherPublicKeyLocator is
available in the compressed NDN Interest packet.
excld: 1 bit flag. If set, then an exclude selector is available in
the compressed NDN Interest packet.
ChSel: 1 bit flag. If set, then a ChildSelector is available in the
compressed NDN Interest packet.
fresh: 1 bit flag. If set, then the compressed NDN Interest is
handled as if the MustBeFresh selector is available. The
MustBeFresh selector is of boolean type and therefore is
omitted from the compressed NDN Interest entirely.
Gundogan, et al. Expires March 26, 2018 [Page 9]
Internet-Draft CCN on IEEE 802.15.4 Networks September 2017
IntLT: 1 bit flag. If set, then the Interest Lifetime selector is
available in the compressed NDN Interest packet.
resv: 1 bit flag. This flag is reserved and MUST be set to 0.
If one of the bits in this CCN-LoWPAN header is set, the Length and
the Value of the corresponding field is written in the packet in the
same order as they appear in this header. For NDN, only the name and
nonce is mandatory. A compressed NDN Interest has the structure as
in Figure 11.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Dispatch Types + Headers | Name | Nonce | [LV fields] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 11: CCN-LoWPAN Interest for NDN
If only the exclude and the MustBeFresh bits are set, the Interest
message will be structured as shown in Table 2. D denotes all
dispatch types and headers, CCNL denotes the dispatch header for the
CCN-LoWPAN compression, N is the name, L is length.
+-----+----------+---+--------+-------+----+---------+
| D | CCNL | L | N | Nonce | L | Exclude |
+-----+----------+---+--------+-------+----+---------+
| ... | 00010100 | 6 | name/d | 34323 | 12 | <excl.> |
+-----+----------+---+--------+-------+----+---------+
Table 2: CCN-LoWPAN Interest with exclude and MustBeFresh
Since MusBeFresh is a boolean, it does not appear in the payload.
3.5.2. Data
The dispatch type bit pattern is "0001 0011 (0xF3)" (Table 1). An
uncompressed NDN Data packet is structured as shown in Figure 12.
Gundogan, et al. Expires March 26, 2018 [Page 10]
Internet-Draft CCN on IEEE 802.15.4 Networks September 2017
Data ::= DATA-TLV TLV-LENGTH
Name
MetaInfo
Content
Signature
MetaInfo ::= META-INFO-TYPE TLV-LENGTH
ContentType?
FreshnessPeriod?
FinalBlockId?
Figure 12: NDN Data BNF
The CCN-LoWPAN dispatch header of the NDN Data packet marks if
Content Type, Freshness Period and Final Block ID are available as
shown in Figure 13. The surrounding MetaInfo TLV around these values
is omitted.
0 1 2 3 4 5 6 7 8
+-------+-------+-------+-------+-------+-------+-------+-------+
| ContT | FrPer | FB_ID | reserved |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 13: NDN Data Compression Header
ContT: 1 bit flag. If set, then a ContentType is present in the
compressed NDN Data packet. If the ContT is cleared,
then a content type of BLOB (0) is assumed and no
ContenType is present in the compressed NDN Data packet.
FrPer: 1 bit flag. If set, then a FreshnessPeriod is present in
the compressed NDN Data Packet. If the FrPer is cleared,
then a default value of 0 is assumed and no
FreshnessPeriod is present in the compressed NDN Data
packet.
FB_ID: 1 bit flag. If set, then a FinalBlockId is present in
the compressed NDN Data packet. If the FB_ID is cleared,
then no FinalBlockId is present in the compressed NDN
Data packet.
reserved: 5 bits. These bits are reserved and MUST be set to 0.
The compressed NDN Data packet has the structure as shown in
Figure 14.
Gundogan, et al. Expires March 26, 2018 [Page 11]
Internet-Draft CCN on IEEE 802.15.4 Networks September 2017
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dispatch Types + Headers | Name | [LV fields] ... | Cont. | Sig |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: NDN LoWPAN Content
Assuming the FinalBlock ID is the only MetaInfo which is enabled, the
compressed NDN Data packet will look as demonstrated in Table 3. D
denotes all dispatch types, CCNL denotes the dispatch header for the
CCN-LoWPAN compression, N is the name, C is the content, L is length
and S is signature.
+-----+----------+---+--------+------+----+---+-----+---+
| D | CCNL | L | N | FBID | L | C | L | S |
+-----+----------+---+--------+------+----+---+-----+---+
| ... | 01000010 | 6 | name/d | 34 | 64 | c | 256 | s |
+-----+----------+---+--------+------+----+---+-----+---+
Table 3: CCN-LoWPAN Data packet with FinalBlock ID
3.6. CCN-LoWPAN CCNx Format Specific Header
In this section the compression scheme for CCNx Interest and Data
object packets is defined. The packet format specification is
obtained from [I-D.irtf-icnrg-ccnxmessages]. The CCN-LoWPAN dispatch
header for the CCNx packet format consists of 2 octets. Thereby, the
first octet marks the presence of fields in the fixed header which is
defined for both CCNx Interest and Data object packets. The fixed
header consists of the Version, the PacketType, the PacketLength and
packet specific fields. Since the packet type is defined by the
dispatch type and the packet length is given by the L2 frame header
excluding the dispatch types and headers, both fields can be removed.
In this document, the Version is marked as optional and a default
version is assumed. In CCNx every packet can carry a payload and
validation info, but both are optional. The first octect for the
fixed header of CCNx packets is structured as shown in Figure 15.
0 1 2 3 4 5 6 7 8
+-------+-------+-------+-------+-------+-------+-------+-------+
| ver | reserved | hash | payld | val | HbH |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 15: CCN-LoWPAN for the fixed header of CCNx
ver: 1 bit flag. If set, then a Version field is present in
the compressed fixed header of the CCNx packet. If ver
is cleared, then a default version of '1' (=CCNx v1.0) is
assumed.
Gundogan, et al. Expires March 26, 2018 [Page 12]
Internet-Draft CCN on IEEE 802.15.4 Networks September 2017
reserved: 3 bits. These bits are reserved and MUST be set to 0.
hash: 1 bit flag. If set, a hash field is available. There is
no default value.
payld: 1 bit flag. If set, then a PacketPayloadTLV is present
in the compressed CCNx packet. If cleared, there is no
PacketPayloadTLV in the packet.
val: 1 bit flag. If set, then a ValidationTLV is present in
the compressed CCNx packet. If cleared, there is no
ValidationTLV in the packet
HbH: 1 bit flag. If set, then a HoyByHopTLV is present in the
compressed CCNx Packet.
3.6.1. Interest
The dispatch type bit pattern is "0001 0000 (0xF0)" (Table 1). An
uncompressed CCNx Interest message is structured as shown in
Figure 16. where optional components are marked by a "?".
Interest ::= Version
PacketType
PacketLength
HopLimit
Reserved / ReturnCode
Flags
HeaderLength
InterestLifetimeTLV?
MsgHashTLV?
PacketPayloadTLV
ValidationAlgorithmTLV?
ValidationPayloadTLV?
PacketPayloadTLV ::= T_INTEREST MsgLen
NameTLV
KeyIDRestrictionTLV?
ContentObjectHashRestrictionTLV?
PayloadTLV?
Figure 16: CCNx Interest BNF
The second octet for the CCNx Interest message is defined as in
Figure 17.
Gundogan, et al. Expires March 26, 2018 [Page 13]
Internet-Draft CCN on IEEE 802.15.4 Networks September 2017
0 1 2 3 4 5 6 7 8
+-------+-------+-------+-------+-------+-------+-------+-------+
| ilt | keyid | ohstr | hlim | hlim | flags | ret | resv |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 17: CCN-LoWPAN dispatch header for compressed Interest in CCNx
ilt: 1 bit flag. If set, then a InterestLiveTime field is
present in the compressed Interest header of the CCNx
packet. If ilt is cleared, the InterestLiveTime is
assumed to be zero, which indicates, the Interest does
not expect a response.
keyid: 1 bit flag. If set, a KeyIDRestrictionTLV field is
present in the compressed Interest header of the CCNx
packet. There is no default value, since the field is
optional in CCNx.
ohsr: 1 bit flag. If set, ContentObjectHashRestriction field
is present in the compressed Interest header of the CCNx
packet. There is no default value, since the field is
optional in CCNx.
hlim: 2 bit flag. If set to 0x00, the hop limit is carried in
the payload. If set to 0x01, the hop limit is omitted
from the payload and a hop limit of 1 is assumed. If set
to 0x02, the hop limit is omitted from the payload and a
hop limit of 64 is assumed. If set to 0x03, the hop
limit is omitted from the payload and a hop limit of 255
is assumed.
flags: 1 bit flag. If set, a flag field is present in the
compressed Interest header of the CCNx packet. Currently
there are no flags defined, thus the bit must be cleared.
ret: 1 bit flag. If set, a return field is present in the
compressed Interest header of the CCNx packet. This
field is optional in CCNx, so there is no default value.
resv: 1 bit flag. This flag is reserved and MUST be set to 0.
Similar to the NDN packet format, if a field is available, the
corresponding bit is enabeld.
For an Interest message, the PacketPayloadTLV contains a surrounding
MessageType of T_INTEREST and an overall MessageLength. This
information is already contained in the dispatch type. Thus, the
Gundogan, et al. Expires March 26, 2018 [Page 14]
Internet-Draft CCN on IEEE 802.15.4 Networks September 2017
MessageType is removed. The MessageLength is also removed, as the
Length of each nested TLV is known.
3.6.2. Data
The dispatch type bit pattern is "0001 0001 (0xF1)" (Table 1). An
uncompressed CCNx Data message is designed as shown in Figure 18.
Optional fields are marked by '?'.
Data ::= Version
PacketType
PacketLength
Reserved
Flags
HeaderLength
CacheTimeTLV?
MsgHashTLV?
PacketPayloadTLV
ValidationAlgorithmTLV?
ValidationPayloadTLV?
PacketPayloadTLV ::= T_OBJECT MsgLen
NameTLV
PayloadTypeTLV?
PayloadTLV?
ExpiryTimeTLV?
Figure 18: CCNx Data BNF
The second octet of the CCN-LoWPAN dispatch header for a Data object
is structured as shown in Figure 19.
0 1 2 3 4 5 6 7 8
+-------+-------+-------+-------+-------+-------+-------+-------+
| rct | ptype | exp | reserved |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 19: CCN-LoWPAN Data Object Header for CCNx
rct: 1 bit flag. If set, then a CacheTimeTLV is present in
the compressed Data header of the CCNx packet. Since the
CacheTimeTLV is of fixed length (8 octets), not only th
Type field, but also the Length field of this TLV is
omitted in the compressed CCNx packet.
ptype: 1 bit flag. If set, a PayloadTypeTLV is present in the
compressed Data header of the CCNx packet. If cleared,
then the "Data" PayloadTypeTLV is assumed.
Gundogan, et al. Expires March 26, 2018 [Page 15]
Internet-Draft CCN on IEEE 802.15.4 Networks September 2017
exp: 1 bit flag. If set, then a ExpiryTimeTLV is present in
the compressed Data header of the CCNx packet. Since the
ExpiryTimeTLV is of fixed length (8 octets), not only th
Type field, but also the Length field of this TLV is
omitted in the compressed CCNx packet.
resv: 5 bits flag. This flag is reserved and MUST be set to 0.
For a Data message, the PacketPayloadTLV contains a surrounding
MessageType of T_OBJECT and an overall MessageLength. This
information is already contained in the dispatch type. Thus, the
MessageType is removed. The MessageLength is also removed, as the
Length of each nested TLV is known.
4. Security Considerations
TODO
5. References
5.1. Normative References
[I-D.irtf-icnrg-ccnxmessages]
Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV
Format", draft-irtf-icnrg-ccnxmessages-05 (work in
progress), September 2017.
[NDN-TLV] "NDN Packet Format Specification",
<https://named-data.net/doc/ndn-tlv/>.
[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>.
Gundogan, et al. Expires March 26, 2018 [Page 16]
Internet-Draft CCN on IEEE 802.15.4 Networks September 2017
[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November
2014, <https://www.rfc-editor.org/info/rfc7400>.
[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>.
5.2. Informative References
[CCN-LITE]
"CCN-lite: A lightweight CCNx and NDN implementation",
<http://ccn-lite.net/>.
[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.
[RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G.,
Tyson, G., Davies, E., Molinaro, A., and S. Eum,
"Information-Centric Networking: Baseline Scenarios",
RFC 7476, DOI 10.17487/RFC7476, March 2015,
<https://www.rfc-editor.org/info/rfc7476>.
[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
"Information-Centric Networking (ICN) Research
Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
<https://www.rfc-editor.org/info/rfc7927>.
[RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S.,
and G. Boggia, "Information-Centric Networking: Evaluation
and Security Considerations", RFC 7945,
DOI 10.17487/RFC7945, September 2016,
<https://www.rfc-editor.org/info/rfc7945>.
Gundogan, et al. Expires March 26, 2018 [Page 17]
Internet-Draft CCN on IEEE 802.15.4 Networks September 2017
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
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
Gundogan, et al. Expires March 26, 2018 [Page 18]
Internet-Draft CCN on IEEE 802.15.4 Networks September 2017
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 March 26, 2018 [Page 19]