ICN Adaptation to LoWPAN Networks (ICN LoWPAN)
draft-irtf-icnrg-icnlowpan-08
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9139.
|
|
|---|---|---|---|
| Authors | Cenk Gündoğan , Thomas C. Schmidt , Matthias Wählisch , Christopher Scherb , Claudio Marxer , Christian Tschudin | ||
| Last updated | 2020-08-25 (Latest revision 2020-05-01) | ||
| Replaces | draft-gundogan-icnrg-ccnlowpan | ||
| RFC stream | Internet Research Task Force (IRTF) | ||
| Formats | |||
| IETF conflict review | conflict-review-irtf-icnrg-icnlowpan, conflict-review-irtf-icnrg-icnlowpan, conflict-review-irtf-icnrg-icnlowpan, conflict-review-irtf-icnrg-icnlowpan, conflict-review-irtf-icnrg-icnlowpan, conflict-review-irtf-icnrg-icnlowpan | ||
| Additional resources | Mailing list discussion | ||
| Stream | IRTF state | IRSG Review | |
| Consensus boilerplate | Yes | ||
| Document shepherd | Dirk Kutscher | ||
| Shepherd write-up | Show Last changed 2020-04-08 | ||
| IESG | IESG state | Became RFC 9139 (Experimental) | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | Dirk Kutscher <ietf@dkutscher.net> |
draft-irtf-icnrg-icnlowpan-08
Internet-Draft ICN Adaptation to LoWPANs May 2020 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 1 | 1 | 0 |CID|EXT|VER|FLG|PTY|HPL|FRS|PAY|ILT|MGH|KIR|CHR|VAL| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Figure 22: Dispatch format for compressed CCNx Interest messages CID: Context Identifier See Figure 5. EXT: Extension 0: No extension octet follows. 1: Extension octet "EXT_0" follows immediately. See Section 6.3.3. VER: CCNx protocol version in the fixed header 0: The Version field equals 1 and is removed from the fixed header. 1: The Version field is carried in-line. FLG: Flags field in the fixed header 0: The Flags field equals 0 and is removed from the Interest message. 1: The Flags field is carried in-line. PTY: PacketType field in the fixed header 0: The PacketType field is elided and assumed to be "PT_INTEREST" 1: The PacketType field is elided and assumed to be "PT_RETURN" HPL: HopLimit field in the fixed header 0: The HopLimit field is carried in-line 1: The HopLimit field is elided and assumed to be "1" FRS: Reserved field in the fixed header 0: The Reserved field is carried in-line Gundogan, et al. Expires November 2, 2020 [Page 23] Internet-Draft ICN Adaptation to LoWPANs May 2020 1: The Reserved field is elided and assumed to be "0" PAY: Optional Payload TLV 0: The Payload TLV is absent. 1: The Payload TLV is present and the type field is elided. ILT: Optional Hop-By-Hop InterestLifetime TLV See Section 6.3.2.1 for further details on the ordering of hop-by-hop TLVs. 0: No InterestLifetime TLV is present in the Interest message. 1: An InterestLifetime TLV is present with a fixed length of 1 octet and is encoded as described in Section 7. The type and length fields are elided. If a lifetime is not a valid time-value, then the lifetime is rounded up to the nearest valid time-value (see Section 7). MGH: Optional Hop-By-Hop MessageHash TLV See Section 6.3.2.1 for further details on the ordering of hop-by-hop TLVs. This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the Interest MUST be sent uncompressed. 0: The MessageHash TLV is absent. 1: A T_SHA-256 TLV is present and the type as well as the length fields are removed. The length field is assumed to represent 32 octets. The outer Message Hash TLV is omitted. KIR: Optional KeyIdRestriction TLV This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the Interest MUST be sent uncompressed. 0: The KeyIdRestriction TLV is absent. 1: A T_SHA-256 TLV is present and the type as well as the length fields are removed. The length field is assumed Gundogan, et al. Expires November 2, 2020 [Page 24] Internet-Draft ICN Adaptation to LoWPANs May 2020 to represent 32 octets. The outer KeyIdRestriction TLV is omitted. CHR: Optional ContentObjectHashRestriction TLV This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the Interest MUST be sent uncompressed. 0: The ContentObjectHashRestriction TLV is absent. 1: A T_SHA-256 TLV is present and the type as well as the length fields are removed. The length field is assumed to represent 32 octets. The outer ContentObjectHashRestriction TLV is omitted. VAL: Optional ValidationAlgorithm and ValidationPayload TLVs 0: No validation related TLVs are present in the Interest message. 1: Validation related TLVs are present in the Interest message. An additional octet follows immediately that handles validation related TLV compressions and is described in Section 6.3.2.2. 6.3.2.1. Hop-By-Hop Header TLVs Compression Hop-By-Hop Header TLVs are unordered. For an Interest message, two optional Hop-By-Hop Header TLVs are defined in [RFC8609], but several more can be defined in higher level specifications. For the compression specified in the previous section, the Hop-By-Hop TLVs are ordered as follows: 1. Interest Lifetime TLV 2. Message Hash TLV Note: Other Hop-By-Hop Header TLVs than those two remain uncompressed. 6.3.2.2. Validation Gundogan, et al. Expires November 2, 2020 [Page 25] Internet-Draft ICN Adaptation to LoWPANs May 2020 0 1 2 3 4 5 6 7 8 +-------+-------+-------+-------+-------+-------+-------+-------+ | ValidationAlg | KeyID | RSV | +-------+-------+-------+-------+-------+-------+-------+-------+ Figure 23: Dispatch for Interset Validations ValidationALg: Optional ValidationAlgorithm TLV 0000: An uncompressed ValidationAlgorithm TLV is included. 0001: A T_CRC32C ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV is included. 0010: A T_CRC32C ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV is included. Additionally, a Sigtime TLV is inlined without a type and a length field. 0011: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV is included. 0100: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but no ValidationAlgorithm TLV is included. Additionally, a Sigtime TLV is inlined without a type and a length field. 0101: Reserved. 0110: Reserved. 0111: Reserved. 1000: Reserved. 1001: Reserved. 1010: Reserved. 1011: Reserved. 1100: Reserved. 1101: Reserved. 1110: Reserved. 1111: Reserved. KeyID: Optional KeyID TLV within the ValidationAlgorithm TLV Gundogan, et al. Expires November 2, 2020 [Page 26] Internet-Draft ICN Adaptation to LoWPANs May 2020 00: The KeyId TLV is absent. 01: The KeyId TLV is present and uncompressed. 10: A T_SHA-256 TLV is present and the type field as well as the length fields are removed. The length field is assumed to represent 32 octets. The outer KeyId TLV is omitted. 11: A T_SHA-512 TLV is present and the type field as well as the length fields are removed. The length field is assumed to represent 64 octets. The outer KeyId TLV is omitted. RSV: Reserved Must be set to 0. The ValidationPayload TLV is present if the ValidationAlgorithm TLV is present. The type field is omitted. 6.3.3. Dispatch Extension The "EXT_0" octet follows the description in Section 4.1.1 and is illustrated in Figure 24. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | NCS | RSV |EXT| +---+---+---+---+---+---+---+---+ Figure 24: EXT_0 format NCS: Name Compression Strategy 00: Names are compressed with the default name compression strategy (see Section 5.2). 01: Reserved. 10: Reserved. 11: Reserved. RSV: Reserved Must be set to 0. EXT: Extension 0: No extension octet follows. Gundogan, et al. Expires November 2, 2020 [Page 27] Internet-Draft ICN Adaptation to LoWPANs May 2020 1: A further extension octet follows immediately. 6.4. Content Objects 6.4.1. Uncompressed Content Objects An uncompressed Content object uses the base dispatch format (see Figure 4) and sets the P and M flags to "1". The C flag is to "0" (Figure 25). "RSV" MUST be set to 0. The Content object is handed to the CCNx network stack without modifications. 0 1 2 ... 7 +---+---+-----------------------+ | 1 | 0 | 1 | RSV | +---+---+-----------------------+ Figure 25: Dispatch format for uncompressed CCNx Content objects 6.4.2. Compressed Content Objects The compressed Content object uses the extended dispatch format (Figure 5) and sets the P, C as well as the M flag to "1". If a Content object contains TLVs that are not mentioned in the following compression rules, then this message MUST be sent uncompressed. By default, the Content object is compressed with the following base rule set: 1. The PacketType field is elided from the Fixed Header. 2. The Type and Length fields of the CCNx Message TLV are elided and are obtained from the Fixed Header on decompression. The compressed CCNx LoWPAN Data message is visualized in Figure 26. Gundogan, et al. Expires November 2, 2020 [Page 28] Internet-Draft ICN Adaptation to LoWPANs May 2020 T = Type, L = Length, V = Value +--------------------------+ +--------------------------+ | Uncompr. Fixed Header | | Compr. Fixed Header | +--------------------------+ +--------------------------+ +--------+--------+--------+ +--------+ | RCT T | RCT L | RCT V | | RCT V | +--------+--------+--------+ +--------+--------+ | MSGH T | MSGH L | MSGH V | | MSGH L | MSGH V | +--------+--------+--------+ +--------+--------+ +--------+--------+ +--------+ | MSGT T | MSGT L | | Name V | +--------+--------+--------+ +--------+ | Name T | Name L | Name V | ==> | EXPT V | +--------+--------+--------+ +--------+--------+ | PTYP T | PTYP L | PTYP V | | PAYL L | PAYL V | +--------+--------+--------+ +--------+--------+ | EXPT T | EXPT L | EXPT V | | VALG L | VALG V | +--------+--------+--------+ +--------+--------+ | PAYL T | PAYL L | PAYL V | | VPAY L | VPAY V | +--------+--------+--------+ +--------+--------+ | VALG T | VALG L | VALG V | +--------+--------+--------+ | VPAY T | VPAY L | VPAY V | +--------+--------+--------+ Figure 26: Compression of CCNx LoWPAN Data Message Further TLV compression is indicated by the ICN LoWPAN dispatch in Figure 27. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 1 | 1 | 1 |CID|EXT|VER|FLG|FRS|PAY|RCT|MGH| PLTYP |EXP|VAL|RSV| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Figure 27: Dispatch format for compressed CCNx Content objects CID: Context Identifier See Figure 5. EXT: Extension 0: No extension octet follows. 1: Extension octet "EXT_0" follows immediately. See Section 6.4.3. Gundogan, et al. Expires November 2, 2020 [Page 29] Internet-Draft ICN Adaptation to LoWPANs May 2020 VER: CCNx protocol version in the fixed header 0: The Version field equals 1 and is removed from the fixed header. 1: The Version field is carried in-line. FLG: Flags field in the fixed header See Section 6.3.2. FRS: Reserved field in the fixed header See Section 6.3.2. PAY: Optional Payload TLV See Section 6.3.2. RCT: Optional Hop-By-Hop RecommendedCacheTime TLV 0: The Recommended Cache Time TLV is absent. 1: The Recommended Cache Time TLV is present and the type as well as the length fields are elided. MGH: Optional Hop-By-Hop MessageHash TLV See Section 6.4.2.1 for further details on the ordering of hop-by-hop TLVs. This TLV is expected to contain a T_SHA-256 TLV. If another hash is contained, then the Content Object MUST be sent uncompressed. 0: The MessageHash TLV is absent. 1: A T_SHA-256 TLV is present and the type as well as the length fields are removed. The length field is assumed to represent 32 octets. The outer Message Hash TLV is omitted. PLTYP: Optional PayloadType TLV 00: The PayloadType TLV is absent. 01: The PayloadType TLV is absent and T_PAYLOADTYPE_DATA is assumed. 10: The PayloadType TLV is absent and T_PAYLOADTYPE_KEY is assumed. Gundogan, et al. Expires November 2, 2020 [Page 30] Internet-Draft ICN Adaptation to LoWPANs May 2020 11: The PayloadType TLV is present and uncompressed. EXP: Optional ExpiryTime TLV 0: The ExpiryTime TLV is absent. 1: The ExpiryTime TLV is present and the type as well as the length fields are elided. VAL: Optional ValidationAlgorithm and ValidationPayload TLVs See Sec tion 6.3.2. RSV: Reserved Must be set to 0. 6.4.2.1. Hop-By-Hop Header TLVs Compression Hop-By-Hop Header TLVs are unordered. For a Content Object message, two optional Hop-By-Hop Header TLVs are defined in [RFC8609], but several more can be defined in higher level specifications. For the compression specified in the previous section, the Hop-By-Hop TLVs are ordered as follows: 1. Recommended Cache Time TLV 2. Message Hash TLV Note: Other Hop-By-Hop Header TLVs than those two remain uncompressed. 6.4.3. Dispatch Extension The "EXT_0" octet follows the description in Section 4.1.1 and is illustrated in Figure 28. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | NCS | RSV |EXT| +---+---+---+---+---+---+---+---+ Figure 28: EXT_0 format NCS: Name Compression Strategy 00: Names are compressed with the default name compression strategy (see Section 5.2). 01: Reserved. Gundogan, et al. Expires November 2, 2020 [Page 31] Internet-Draft ICN Adaptation to LoWPANs May 2020 10: Reserved. 11: Reserved. RSV: Reserved Must be set to 0. EXT: Extension 0: No extension octet follows. 1: A further extension octet follows immediately. 7. Compressed Time Encoding This document adopts the compact time representation [I-D.gundogan-icnrg-ccnx-timetlv] for relative time values. Exponent (e) and mantissa (m) values are encoded in a 1-octet wide representation as depicted in Figure 29. <-- one octet --> +---+---+---+---+---+---+---+---+ | exponent (e) | mantissa (m) | +---+---+---+---+---+---+---+---+ Figure 29: A time-code with exponent and mantissa to encode a logarithmic range time representation. The mantissa size is set to 3 bits, the exponent size to 5 bits, and a bias of -5 is applied. This allows for a time representation that ranges from milliseconds with high precision to days with low precision. The base unit for time values are seconds. A time-value is calculated using the following formula, where (e) represents the exponent, (m) the mantissa, (m_max = 8) the maximum mantissa value, and (b) the bias. Subnormal (e == 0): (0 + m/m_max) * 2^(1+b) Normalized (e > 0): (1 + m/m_max) * 2^(e+b) The subnormal form provides a gradual underflow from the smallest normalized number towards zero. This configuration allows for the following ranges: o Minimum subnormal number: 0 seconds o Maximum subnormal number: ~0.054688 seconds Gundogan, et al. Expires November 2, 2020 [Page 32] Internet-Draft ICN Adaptation to LoWPANs May 2020 o Minimum normalized number: ~0.062500 seconds o Maximum normalized number: ~3.987284 years Valid time-values are always positive numbers. An invalid time-value (t, in seconds) MUST be rounded down to the nearest valid time-value using this algorithm, where (e) represents the number of bits for the exponent, (m) the number of bits for the mantissa, and (m_max = 8) the maximum mantissa value. The bias (b) is set to -5 as before. o e := floor( log2( t/(2^-b) )) o m := floor( 8 * (t / 2^(e+b) - 1 )) 8. Stateful Header Compression Stateful header compression in ICN LoWPAN enables packet size reductions in two ways. First, common information that is shared throughout the local LoWPAN may be memorized in context state at all nodes and omitted from communication. Second, redundancy in a single Interest-data exchange may be removed from ICN stateful forwarding on a hop-by-hop bases and memorized in en-route state tables. 8.1. LoWPAN-local State A context identifier (CID) is an octet that refers to a particular conceptual context between network devices and MAY be used to replace frequently appearing information, such as name prefixes, suffixes, or meta information, such as Interest lifetime. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | X | ContextID | +---+---+---+---+---+---+---+---+ Figure 30: Context Identifier. The ContextID refers to a locally-scoped unique identifier that represents contextual state shared between sender and receiver of the corresponding frame (see Figure 30). Such state shared between senders and receivers is removed from the compressed packet prior to sending, and reinserted after reception prior to passing to the upper stack. The initial distribution and maintenance of shared context is out of scope of this document. Frames containing unknown or invalid CIDs MUST be silently discarded. Gundogan, et al. Expires November 2, 2020 [Page 33] Internet-Draft ICN Adaptation to LoWPANs May 2020 8.2. En-route State In CCNx and NDN, Name TLVs are included in Interest messages, and they return in data messages. Returning Name TLVs either equal the original Name TLV, or they contain the original Name TLV as a prefix. ICN LoWPAN reduces this redundancy in responses by replacing Name TLVs with single octets that represent link-local HopIDs. HopIDs are carried as Context Identifiers of link-local scope as shown in Figure 31. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | X | HopID | +---+---+---+---+---+---+---+---+ Figure 31: Context Identifier as HopID. A HopID is valid, if not all ID bits are set to zero and invalid otherwise. This yields 127 distinct HopIDs. If this range (1...127) is exhausted, the messages MUST be sent without en-route state compression until new HopIDs are available. An ICN LoWPAN node that forwards without replacing the name by a HopID (without en-route compression) MUST invalidate the HopID by setting all ID-bits to zero. While an Interest is traversing, a forwarder generates an ephemeral HopID that is tied to a PIT entry. Each HopID MUST be unique within the local PIT and only exists during the lifetime of a PIT entry. To maintain HopIDs, the local PIT is extended by two new columns: HIDi (inbound HopIDs) and HIDo (outbound HopIDs). HopIDs are included in Interests and stored on the next hop with the resulting PIT entry in the HIDi column. The HopID is replaced with a newly generated local HopID before the Interest is forwarded. This new HopID is stored in the HIDo column of the local PIT (see Figure 32). Gundogan, et al. Expires November 2, 2020 [Page 34] Internet-Draft ICN Adaptation to LoWPANs May 2020 PIT of B PIT Extension PIT of C PIT Extension +--------+------++------+------+ +--------+------++------+------+ | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | +========+======++======+======+ +========+======++======+======+ | /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | | +--------+------++------+------+ +--------+------++------+------+ ^ | ^ store | '----------------------, ,---' store | send v | ,---, /p0, h_A ,---, /p0, h_B ,---, | A | ------------------------> | B | ------------------------> | C | '---' '---' '---' Figure 32: Setting compression state en-route (Interest). Responses include HopIDs that were obtained from Interests. If the returning Name TLV equals the original Name TLV, then the name is entirely elided. Otherwise, the distinct suffix is included along with the HopID. When a response is forwarded, the contained HopID is extracted and used to match against the correct PIT entry by performing a lookup on the HIDo column. The HopID is then replaced with the corresponding HopID from the HIDi column prior to forwarding the response (Figure 33). PIT of B PIT Extension PIT of C PIT Extension +--------+------++------+------+ +--------+------++------+------+ | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | +========+======++======+======+ +========+======++======+======+ | /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | | +--------+------++------+------+ +--------+------++------+------+ | ^ | send | '----------------------, ,---' send v match | v ,---, h_A ,---, h_B ,---, | A | <------------------------ | B | <------------------------ | C | '---' '---' '---' Figure 33: Eliding Name TLVs using en-route state (data). It should be noted that each forwarder of an Interest in an ICN LoWPAN network can individually decide whether to participate in en- route compression or not. However, an ICN LoWPAN node SHOULD use en- route compression whenever the stateful compression mechanism is activated. Note also that the extensions of the PIT data structure are required only at ICN LoWPAN nodes, while regular NDN/CCNx forwarders outside of an ICN LoWPAN domain do not need to implement these extensions. Gundogan, et al. Expires November 2, 2020 [Page 35] Internet-Draft ICN Adaptation to LoWPANs May 2020 8.3. Integrating Stateful Header Compression A CID appears whenever the CID flag is set (see Figure 5). The CID is appended to the last ICN LoWPAN dispatch octet as shown in Figure 34. ...-------+--------+-------...-------+--...-+-------... / ... | Page | ICN LoWPAN Disp.| CIDs | Payload / ...-------+--------+-------...-------+--...-+-------... Figure 34: LoWPAN Encapsulation with ICN LoWPAN and CIDs Multiple CIDs are chained together, with the most significant bit indicating the presence of a subsequent CID (Figure 35). +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |1| CID | --> |1| CID | --> |0| CID | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ Figure 35: Chaining of context identifiers. The HopID is always included as the very first CID. 9. ICN LoWPAN Constants and Variables This is a summary of all ICN LoWPAN constants and variables. DEFAULT_NDN_HOPLIMIT: 255 10. Implementation Report and Guidance The ICN LoWPAN scheme defined in this document has been implemented as an extension of the NDN/CCNx software stack [CCN-LITE] in its IoT version on RIOT [RIOT]. An experimental evaluation for NDN over ICN LOWPAN with varying configurations has been performed in [ICNLOWPAN]. Energy profilings and processing time measurements indicate significant energy savings, while amortized costs for processing show no penalties. 10.1. Preferred Configuration The header compression performance depends on certain aspects and configurations. It works best for the following cases: o Each name component is of GenericNameComponent type and is limited to a length of 15 bytes. o Relative time values use a compressed encoding as per Section 7. Gundogan, et al. Expires November 2, 2020 [Page 36] Internet-Draft ICN Adaptation to LoWPANs May 2020 o Contextual state (e.g., prefixes) is distributed, such that long names can be elided from Interest and data messages. 10.2. Further Experimental Deployments An investigation of ICN LoWPAN in large-scale deployments with varying traffic patterns using larger samples of the different board types available remains as future work. Especially for the stateful en-route compression and link fragmentation, complex deployment scenarios may provide a better insight regarding compression parameters. Multiple implementations that generate and deploy the compression options of this memo in different ways will also add to the experience and understanding of the benefits and limitations of the proposed schemes. 11. Security Considerations Main memory is typically a scarce resource of constrained networked devices. Fragmentation as described in this memo preserves fragments and purges them only after a packet is reassembled, which requires a buffering of all fragments. This scheme is able to handle fragments for distinctive packets simultaneously, which can lead to overflowing packet buffers that cannot hold all necessary fragments for packet reassembly. Implementers are thus urged to make use of appropriate buffer replacement strategies for fragments. The stateful header compression generates ephemeral HopIDs for incoming and outgoing Interests and consumes them on returning Data packets. Forged Interests can deplete the number of available HopIDs, thus leading to a denial of compression service for subsequent content requests. To further alleviate the problems caused by forged fragments or Interest initiations, proper protective mechanisms for accessing the link-layer should be deployed. 12. IANA Considerations 12.1. Reserving Space in the 6LoWPAN Dispatch Type Field Registry IANA has assigned dispatch values of the "6LoWPAN Dispatch Type Field" registry [RFC4944][RFC8025] with Page TBD1 for ICN LoWPAN. Table 1 represents updates to the registry. Gundogan, et al. Expires November 2, 2020 [Page 37] Internet-Draft ICN Adaptation to LoWPANs May 2020 +-------------+------+-------------------------------------------+ | Bit Pattern | Page | Header Type | +-------------+------+-------------------------------------------+ | 00 0xxxxx | TBD1 | Uncompressed NDN Interest messages | | 00 1xxxxx | TBD1 | Uncompressed NDN Data messages | | 01 0xxxxx | TBD1 | Compressed NDN Interest messages | | 01 1xxxxx | TBD1 | Compressed NDN Data messages | | 10 0xxxxx | TBD1 | Uncompressed CCNx Interest messages | | 10 1xxxxx | TBD1 | Uncompressed CCNx Content Object messages | | 11 0xxxxx | TBD1 | Compressed CCNx Interest messages | | 11 1xxxxx | TBD1 | Compressed CCNx Content Object messages | +-------------+------+-------------------------------------------+ Table 1: Dispatch types for NDN and CCNx with page TBD1. 13. References 13.1. Normative References [ieee802.15.4] "IEEE Std. 802.15.4-2015", April 2016, <https://standards.ieee.org/findstds/ standard/802.15.4-2015.html>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <https://www.rfc-editor.org/info/rfc4944>. [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <https://www.rfc-editor.org/info/rfc6282>. 13.2. Informative References [CCN-LITE] "CCN-lite: A lightweight CCNx and NDN implementation", <http://ccn-lite.net/>. Gundogan, et al. Expires November 2, 2020 [Page 38] Internet-Draft ICN Adaptation to LoWPANs May 2020 [I-D.gundogan-icnrg-ccnx-timetlv] Gundogan, C., Schmidt, TC., Oran, D., and M. Waehlisch, "An Alternative Delta Time encoding for CCNx using Interval Time from RFC5497", draft-gundogan-icnrg-ccnx- timetlv-00 (work in progress), November 2019. [I-D.irtf-icnrg-flic] Tschudin, C., Wood, C., Mosko, M., and D. Oran, "File-Like ICN Collections (FLIC)", draft-irtf-icnrg-flic-02 (work in progress), November 2019. [ICNLOWPAN] Gundogan, C., Kietzmann, P., Schmidt, TC., and M. Waehlisch, "ICNLoWPAN -- Named-Data Networking in Low Power IoT Networks", Proc. of 18th IFIP Networking Conference , May 2019. [NDN] Jacobson, V., Smetters, D., Thornton, J., and M. Plass, "Networking Named Content", 5th Int. Conf. on emerging Networking Experiments and Technologies (ACM CoNEXT), 2009, <https://doi.org/10.1145/1658939.1658941>. [NDN-EXP1] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, TC., and M. Waehlisch, "Information Centric Networking in the IoT: Experiments with NDN in the Wild", Proc. of 1st ACM Conf. on Information-Centric Networking (ICN-2014) ACM DL, pp. 77-86, September 2014, <http://dx.doi.org/10.1145/2660129.2660144>. [NDN-EXP2] Gundogan, C., Kietzmann, P., Lenders, M., Petersen, H., Schmidt, TC., and M. Waehlisch, "NDN, CoAP, and MQTT: A Comparative Measurement Study in the IoT", Proc. of 5th ACM Conf. on Information-Centric Networking (ICN-2018) ACM DL, pp. 159-171, September 2018, <https://doi.org/10.1145/3267955.3267967>. [NDN-MAC] Kietzmann, P., Gundogan, C., Schmidt, TC., Hahm, O., and M. Waehlisch, "The Need for a Name to MAC Address Mapping in NDN: Towards Quantifying the Resource Gain", Proc. of 4th ACM Conf. on Information-Centric Networking (ICN- 2017) ACM DL, pp. 36-42, September 2017, <https://doi.org/10.1145/3125719.3125737>. [NDN-PACKET-SPEC] "NDN Packet Format Specification", <https://named-data.net/doc/NDN-packet-spec/0.3/>. Gundogan, et al. Expires November 2, 2020 [Page 39] Internet-Draft ICN Adaptation to LoWPANs May 2020 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>. [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., Tyson, G., Davies, E., Molinaro, A., and S. Eum, "Information-Centric Networking: Baseline Scenarios", RFC 7476, DOI 10.17487/RFC7476, March 2015, <https://www.rfc-editor.org/info/rfc7476>. [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, <https://www.rfc-editor.org/info/rfc7927>. [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., and G. Boggia, "Information-Centric Networking: Evaluation and Security Considerations", RFC 7945, DOI 10.17487/RFC7945, September 2016, <https://www.rfc-editor.org/info/rfc7945>. [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch", RFC 8025, DOI 10.17487/RFC8025, November 2016, <https://www.rfc-editor.org/info/rfc8025>. [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019, <https://www.rfc-editor.org/info/rfc8569>. [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019, <https://www.rfc-editor.org/info/rfc8609>. [RIOT] Baccelli, E., Gundogan, C., Hahm, O., Kietzmann, P., Lenders, MS., Petersen, H., Schleiser, K., Schmidt, TC., and M. Waehlisch, "RIOT: an Open Source Operating System for Low-end Embedded Devices in the IoT", IEEE Internet of Things Journal Vol. 5, No. 6, p. 4428-4440, December 2018, <https://doi.org/10.1109/JIOT.2018.2815038>. Gundogan, et al. Expires November 2, 2020 [Page 40] Internet-Draft ICN Adaptation to LoWPANs May 2020 [TLV-ENC-802.15.4] "CCN and NDN TLV encodings in 802.15.4 packets", <https://datatracker.ietf.org/meeting/interim-2015-icnrg- 01/materials/slides-interim-2015-icnrg-1-2>. [WIRE-FORMAT-CONSID] "CCN/NDN Protocol Wire Format and Functionality Considerations", <https://datatracker.ietf.org/meeting/ interim-2015-icnrg-01/materials/slides-interim-2015-icnrg- 1-8>. Gundogan, et al. Expires November 2, 2020 [Page 41] Internet-Draft ICN Adaptation to LoWPANs May 2020 Appendix A. Estimated Size Reduction In the following a theoretical evaluation is given to estimate the gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages. We assume that "n" is the number of name components, "comps_n" denotes the sum of n name component lengths. We also assume that the length of each name component is lower than 16 bytes. The length of the content is given by "clen". The lengths of TLV components is specific to the CCNx or NDN encoding and outlined below. A.1. NDN The NDN TLV encoding has variable-sized TLV fields. For simplicity, the 1 octet form of each TLV component is assumed. A typical TLV component therefore is of size 2 (type field + length field) + the actual value. A.1.1. Interest Figure 36 depicts the size requirements for a basic, uncompressed NDN Interest containing a CanBePrefix TLV, a MustBeFresh TLV, a InterestLifetime TLV set to 4 seconds and a HopLimit TLV set to 6. Numbers below represent the amount of octets. ------------------------------------, Interest TLV = 2 | ---------------------, | Name | 2 + | NameComponents = 2n + | | comps_n | ---------------------' = 21 + 2n + comps_n CanBePrefix = 2 | MustBeFresh = 2 | Nonce = 6 | InterestLifetime = 4 | HopLimit = 3 | ------------------------------------' Figure 36: Estimated size of an uncompressed NDN Interest Figure 37 depicts the size requirements after compression. Gundogan, et al. Expires November 2, 2020 [Page 42] Internet-Draft ICN Adaptation to LoWPANs May 2020 ------------------------------------, Dispatch Page Switch = 1 | NDN Interset Dispatch = 2 | Interest TLV = 1 | -----------------------, | Name | = 10 + n/2 + comps_n NameComponents = n/2 + | | comps_n | -----------------------' | Nonce = 4 | HopLimit = 1 | InterestLifetime = 1 | ------------------------------------' Figure 37: Estimated size of a compressed NDN Interest The size difference is: 11 + 1.5n octets. For the name "/DE/HH/HAW/BT7", the total size gain is 17 octets, which is 43% of the uncompressed packet. A.1.2. Data Figure 38 depicts the size requirements for a basic, uncompressed NDN Data containing a FreshnessPeriod as MetaInfo. A FreshnessPeriod of 1 minute is assumed and the value is encoded using 1 octet. An HMACWithSha256 is assumed as signature. The key locator is assumed to contain a Name TLV of length klen. Gundogan, et al. Expires November 2, 2020 [Page 43] Internet-Draft ICN Adaptation to LoWPANs May 2020 ------------------------------------, Data TLV = 2 | ---------------------, | Name | 2 + | NameComponents = 2n + | | comps_n | ---------------------' | ---------------------, | MetaInfo | | FreshnessPeriod = 6 = 53 + 2n + comps_n + | | clen + klen ---------------------' | Content = 2 + clen | ---------------------, | SignatureInfo | | SignatureType | | KeyLocator = 41 + klen | SignatureValue | | DigestSha256 | | ---------------------' | ------------------------------------' Figure 38: Estimated size of an uncompressed NDN Data Figure 39 depicts the size requirements for the compressed version of the above Data packet. ------------------------------------, Dispatch Page Switch = 1 | NDN Data Dispatch = 2 | -----------------------, | Name | = 38 + n/2 + comps_n + NameComponents = n/2 + | clen + klen | comps_n | -----------------------' | Content = 1 + clen | KeyLocator = 1 + klen | DigestSha256 = 32 | FreshnessPeriod = 1 | ------------------------------------' Figure 39: Estimated size of a compressed NDN Data The size difference is: 15 + 1.5n octets. For the name "/DE/HH/HAW/BT7", the total size gain is 21 octets. Gundogan, et al. Expires November 2, 2020 [Page 44] Internet-Draft ICN Adaptation to LoWPANs May 2020 A.2. CCNx The CCNx TLV encoding defines a 2-octet encoding for type and length fields, summing up to 4 octets in total without a value. A.2.1. Interest Figure 40 depicts the size requirements for a basic, uncompressed CCNx Interest. No Hop-By-Hop TLVs are included, the protocol version is assumed to be 1 and the reserved field is assumed to be 0. A KeyIdRestriction TLV with T_SHA-256 is included to limit the responses to Content Objects containing the specific key. ------------------------------------, Fixed Header = 8 | Message = 4 | ---------------------, | Name | 4 + = 56 + 4n + comps_n NameSegments = 4n + | | comps_n | ---------------------' | KeyIdRestriction = 40 | ------------------------------------' Figure 40: Estimated size of an uncompressed CCNx Interest Figure 41 depicts the size requirements after compression. ------------------------------------, Dispatch Page Switch = 1 | CCNx Interest Dispatch = 2 | Fixed Header = 3 | -----------------------, | Name | = 38 + n/2 + comps_n NameSegments = n/2 + | | comps_n | -----------------------' | T_SHA-256 = 32 | ------------------------------------' Figure 41: Estimated size of a compressed CCNx Interest The size difference is: 18 + 3.5n octets. For the name "/DE/HH/HAW/BT7", the size is reduced by 53 octets, which is 53% of the uncompressed packet. Gundogan, et al. Expires November 2, 2020 [Page 45] Internet-Draft ICN Adaptation to LoWPANs May 2020 A.2.2. Content Object Figure 42 depicts the size requirements for a basic, uncompressed CCNx Content Object containing an ExpiryTime Message TLV, an HMAC_SHA-256 signature, the signature time and a hash of the shared secret key. In the fixed header, the protocol version is assumed to be 1 and the reserved field is assumed to be 0 ------------------------------------, Fixed Header = 8 | Message = 4 | ---------------------, | Name | 4 + | NameSegments = 4n + | | comps_n | ---------------------' | ExpiryTime = 12 = 124 + 4n + comps_n + clen Payload = 4 + clen | ---------------------, | ValidationAlgorithm | | T_HMAC-256 = 56 | KeyId | | SignatureTime | | ---------------------' | ValidationPayload = 36 | ------------------------------------' Figure 42: Estimated size of an uncompressed CCNx Content Object Figure 43 depicts the size requirements for a basic, compressed CCNx Data. Gundogan, et al. Expires November 2, 2020 [Page 46] Internet-Draft ICN Adaptation to LoWPANs May 2020 ------------------------------------, Dispatch Page Switch = 1 | CCNx Content Dispatch = 3 | Fixed Header = 2 | -----------------------, | Name | | NameSegments = n/2 + | | comps_n = 89 + n/2 + comps_n + clen -----------------------' | ExpiryTime = 8 | Payload = 1 + clen | T_HMAC-SHA256 = 32 | SignatureTime = 8 | ValidationPayload = 34 | ------------------------------------' Figure 43: Estimated size of a compressed CCNx Data Object The size difference is: 35 + 3.5n octets. For the name "/DE/HH/HAW/BT7", the size is reduced by 70 octets, which is 40% of the uncompressed packet containing a 4-octet payload. Acknowledgments This work was stimulated by fruitful discussions in the ICNRG research group and the communities of RIOT and CCNlite. We would like to thank all active members for constructive thoughts and feedback. In particular, the authors would like to thank (in alphabetical order) Peter Kietzmann, Dirk Kutscher, Martine Lenders, Colin Perkins, Junxiao Shi. The hop-wise stateful name compression was brought up in a discussion by Dave Oran, which is gratefully acknowledged. Larger parts of this work are inspired by [RFC4944] and [RFC6282]. Special mentioning goes to Mark Mosko as well as G.Q. Wang and Ravi Ravindran as their previous work in [TLV-ENC-802.15.4] and [WIRE-FORMAT-CONSID] provided a good base for our discussions on stateless header compression mechanisms. This work was supported in part by the German Federal Ministry of Research and Education within the projects I3 and RAPstore. Authors' Addresses Gundogan, et al. Expires November 2, 2020 [Page 47] Internet-Draft ICN Adaptation to LoWPANs May 2020 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 November 2, 2020 [Page 48] Internet-Draft ICN Adaptation to LoWPANs May 2020 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 November 2, 2020 [Page 49]