CCN Packet Adaptation to IEEE 802.15.4 Networks
draft-gundogan-icnrg-ccnlowpan-00

Versions: 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]