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 27, 2018.

Copyright Notice

Copyright (c) 2017 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
• 2. Terminology
• 3. CCN-LoWPAN
• 3.1. TLV Compression
• 3.2. Name Compression
• 3.3. Dispatch Page & Type
• 3.4. CCN-LoWPAN Fragmentation
• 3.5. CCN-LoWPAN NDN Format Specific Header
• 3.5.1. Interest
• 3.5.2. Data
• 3.6. CCN-LoWPAN CCNx Format Specific Header
• 3.6.1. Interest
• 3.6.2. Data
• 4. Security Considerations
• 5. References
• 5.1. Normative References
• 5.2. Informative References
• Acknowledgments
• Authors' Addresses

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.

                          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

      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 objective of this document is to define an adaptation layer that Figure 2).

1. registers CCNx and NDN packet format dispatch types for IEEE 802.15.4 frames,
2. handles packet header compression and
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 (

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.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|    ... Dispatch Types ...     |  CCN-LoWPAN   |    ... Payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
                

Figure 3: Dispatch Type + CCN-LoWPAN Header

Figure 3 shows the header structure for the proposed CCN-LoWPAN adaptation layer. Section 3.1. The compressed CCN packet follows immediately the CCN-LoWPAN header.

Dispatch Types:

Dispatch types for LoWPAN frames ([RFC4944]). Dispatch types specifically for CCN-LoWPAN are 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

3.1. TLV Compression

+-------+-------+-----------------+-------+-------+-----------+
|  TYP  |  LEN  |      VALUE      |  TYP  |  LEN  |   VALUE   |
+-------+-------+-----------------+-------+-------+-----------+
               

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.

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.

  +---+---+---+---+---+---+---+---+
  | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 |  Bitfield
  +---+---+---+---+---+---+---+---+
    |       |                   |
 ,--'       '-----------,       '- boolean
 |                      |
+-------+--------------+-------------+
|  LEN  |     VALUE    |    VALUE    |  Compressed TLV series
+-------+--------------+-------------+
               

Figure 5: A comressed series of TLVs

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 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).

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 TL | | Comp. TL | ... | ... | Comp. TL | ... | |
|         | '----------------'     '----------------' |
'-----------------------------------------------------'
                

Figure 6: Verbosity of Name TLVs in NDN

,-------------------------------------------,
|         |                                 |
| Name TL | Comp. CSEP Comp. CSEP ... Comp. |
|         |                                 |
'-------------------------------------------'
                

Figure 7: Compressed Name TLVs in NDN

Name components in CCNx and NDN are structured as shown in Figure 6. 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 transforms to CSEP within names. A compressed TLV for the name is given in Figure 7.

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.

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.

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].

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Fr. Type + Header | Disp. Page 2  | CCN-LoWPAN NDN Int. | Payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
                

Figure 8: Dispatch Types including Fragmentation

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.

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

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

0       1       2       3       4       5       6       7       8
+-------+-------+-------+-------+-------+-------+-------+-------+
| minSx | maxSx |  ppk  | excld | ChSel | fresh | IntLT | resv  |
+-------+-------+-------+-------+-------+-------+-------+-------+
                

Figure 10: NDN Interest Compression Header

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 "?". Figure 10.

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.

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.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Dispatch Types + Headers | Name | Nonce | [LV fields] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
                

Figure 11: CCN-LoWPAN Interest for NDN

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. 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.

Since MusBeFresh is a boolean, it does not appear in the payload.

3.5.2. Data

Data ::= DATA-TLV TLV-LENGTH
         Name
         MetaInfo
         Content
         Signature

MetaInfo ::= META-INFO-TYPE TLV-LENGTH
             ContentType?
             FreshnessPeriod?
             FinalBlockId?
                

Figure 12: NDN Data BNF

0       1       2       3       4       5       6       7       8
+-------+-------+-------+-------+-------+-------+-------+-------+
| ContT | FrPer | FB_ID |               reserved                |
+-------+-------+-------+-------+-------+-------+-------+-------+
                

Figure 13: NDN Data Compression Header

The dispatch type bit pattern is 0001 0011 (0xF3) (Table 1). An uncompressed NDN Data packet is structured as shown in Figure 12. Figure 13. The surrounding MetaInfo TLV around these values is omitted.

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.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dispatch Types + Headers  | Name | [LV fields] ... | Cont. | Sig  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                

Figure 14: NDN LoWPAN Content

The compressed NDN Data packet has the structure as shown in Figure 14. 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.

3.6. CCN-LoWPAN CCNx Format Specific Header

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

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.

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.

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

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

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

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 "?". Figure 17.

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 MessageType is removed. The MessageLength is also removed, as the Length of each nested TLV is known.

3.6.2. Data

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

0       1       2       3       4       5       6       7       8
+-------+-------+-------+-------+-------+-------+-------+-------+
|  rct  | ptype |  exp  |               reserved                |
+-------+-------+-------+-------+-------+-------+-------+-------+
                        

Figure 19: CCN-LoWPAN Data Object Header for CCNx

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 '?'. Figure 19.

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.

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

5.2. Informative References

Acknowledgments

Authors' Addresses