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 | | +-----+----------+---+--------+-------+----+---------+ 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", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, . [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, . 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, . [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, . 5.2. Informative References [CCN-LITE] "CCN-lite: A lightweight CCNx and NDN implementation", . [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, . [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, . [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, . 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]