ICN LoWPAN:

Information-Centric Networking over Low-Power Wireless Personal Area Network

LLN:

Low-Power and Lossy Network

CCNx:

Content-Centric Networking

NDN:

Named Data Networking

byte:

synonym for octet

nibble:

synonym for 4 bits

time-value:

a time offset measured in seconds

time-code:

an 8-bit encoded time-value

  0   1   2   3   ...
+---+---+---+---+---
| 0 | P | M | C |
+---+---+---+---+---

P: Protocol

0:

The included protocol is NDN.

1:

The included protocol is CCNx.

M: Message Type

0:

The payload contains an Interest message.

1:

The payload contains a Data message.

C: Compression

0:

The message is uncompressed.

1:

The message is compressed.

  0   1   2   3      ... ...
+---+---+---+---+...+---+---+
| 0 | P | M | 1 |   |CID|EXT|
+---+---+---+---+...+---+---+

CID: Context Identifier

0:

No context identifiers are present.

1:

Context identifier(s) are present (see Section 8.1).

EXT: Extension

0:

No extension bytes are present.

1:

Extension byte(s) are present (see Section 4.1.1).

+------...------+------...-----+--------+-------...-------+-----...
| IEEE 802.15.4 | RFC4944 Disp.|  Page  | ICN LoWPAN Disp.| Payl. /
+------...------+------...-----+--------+-------...-------+-----...

IEEE 802.15.4:

The IEEE 802.15.4 header.

RFC4944 Disp.:

Optional additional dispatches defined in Section 5.1 of RFC 4944.

Page:

Page switch. 14 for ICN LoWPAN.

ICN LoWPAN:

Dispatches as defined in Sections [5] and [6].

Payload:

The actual (un-)compressed CCNx or NDN message.

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| - | - | - | - | - | - | - |EXT|
+---+---+---+---+---+---+---+---+

EXT: Extension

0:

No other extension byte follows.

1:

A further extension byte follows.

1. The Type field of the outermost MessageType TLV is removed.
2. The Name TLV is compressed according to Section 5.2. For this, all NameComponents are expected to be of type GenericNameComponent with a length greater than 0. An ImplicitSha256DigestComponent or ParametersSha256DigestComponent MAY appear at the end of the name. In any other case, the message MUST be sent uncompressed.
3. The Nonce TLV and InterestLifetime TLV are moved to the end of the compressed Interest, as illustrated in Figure 12. The InterestLifetime is encoded as described in Section 7. On decompression, this encoding may yield an InterestLifetime that is smaller than the original value.
4. The Type and Length fields of Nonce TLV, HopLimit TLV, and InterestLifetime TLV are elided. The Nonce value has a length of 4 bytes, and the HopLimit value has a length of 1 byte. The compressed InterestLifetime (Section 7) has a length of 1 byte. The presence of a Nonce TLV and InterestLifetime TLV is deduced from the remaining length to parse. A remaining length of 1 indicates the presence of an InterestLifetime, a length of 4 indicates the presence of a nonce, and a length of 5 indicates the presence of both TLVs.

T = Type, L = Length, V = Value
Lc = Compressed Length, Vc = Compressed Value
: = optional field, | = mandatory field

+---------+---------+                 +---------+
|  Msg T  |  Msg L  |                 |  Msg Lc |
+---------+---------+---------+       +---------+
| Name T  | Name L  | Name V  |       | Name Vc |
+---------+---------+---------+       +---------+---------+
: CBPfx T : CBPfx L :                 : FWDH Lc : FWDH Vc :
+---------+---------+                 +---------+---------+
: MBFr T  : MBFr L  :                 |  HPL V  |
+---------+---------+---------+  ==>  +---------+---------+
: FWDH T  : FWDH L  : FWDH V  :       :  APM Lc : APM Vc  :
+---------+---------+---------+       +---------+---------+
: NONCE T : NONCE L : NONCE V :       : NONCE V :
+---------+---------+---------+       +---------+
:  ILT T  :  ILT L  :  ILT V  :       :  ILT Vc :
+---------+---------+---------+       +---------+
:  HPL T  :  HPL L  :  HPL V  :
+---------+---------+---------+
:  APM T  :  APM L  :  APM V  :
+---------+---------+---------+

  0                                       1
  0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 1 |PFX|FRE|FWD|APM|DIG|        RSV        |CID|EXT|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

PFX: CanBePrefix TLV

0:

The uncompressed message does not include a CanBePrefix TLV.

1:

The uncompressed message does include a CanBePrefix TLV and is removed from the compressed message.

FRE: MustBeFresh TLV

0:

The uncompressed message does not include a MustBeFresh TLV.

1:

The uncompressed message does include a MustBeFresh TLV and is removed from the compressed message.

FWD: ForwardingHint TLV

0:

The uncompressed message does not include a ForwardingHint TLV.

1:

The uncompressed message does include a ForwardingHint TLV. The Type field is removed from the compressed message. Further, all link delegation types and link preference types are removed. All included names are compressed according to Section 5.2. If any name is not compressible, the message MUST be sent uncompressed.

APM: ApplicationParameters TLV

0:

The uncompressed message does not include an ApplicationParameters TLV.

1:

The uncompressed message does include an ApplicationParameters TLV. The Type field is removed from the compressed message.

DIG: ImplicitSha256DigestComponent TLV

0:

The name does not include an ImplicitSha256DigestComponent as the last TLV.

1:

The name does include an ImplicitSha256DigestComponent as the last TLV. The Type and Length fields are omitted.

RSV: Reserved

Must be set to 0.

CID: Context Identifier

See Figure 5.

EXT: Extension

0:

No extension byte follows.

1:

Extension byte EXT_0 follows immediately. See Section 5.3.3.

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|  NCS  |        RSV        |EXT|
+---+---+---+---+---+---+---+---+

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

1:

A further extension byte follows immediately.

1. The Type field of the outermost MessageType TLV is removed.
2. The Name TLV is compressed according to Section 5.2. For this, all NameComponents are expected to be of type GenericNameComponent and to have a length greater than 0. In any other case, the message MUST be sent uncompressed.
3. The MetaInfo TLV Type and Length fields are elided from the compressed Data message.
4. The FreshnessPeriod TLV MUST be moved to the end of the compressed Data message. Type and Length fields are elided, and the value is encoded as described in Section 7 as a 1-byte time-code. If the freshness period is not a valid time-value, then the message MUST be sent uncompressed in order to preserve the security envelope of the Data message. The presence of a FreshnessPeriod TLV is deduced from the remaining one-byte length to parse.
5. The Type fields of the SignatureInfo TLV, SignatureType TLV, and SignatureValue TLV are removed.

T = Type, L = Length, V = Value
Lc = Compressed Length, Vc = Compressed Value
: = optional field, | = mandatory field

+---------+---------+                 +---------+
|  Msg T  |  Msg L  |                 |  Msg Lc |
+---------+---------+---------+       +---------+
| Name T  | Name L  | Name V  |       | Name Vc |
+---------+---------+---------+       +---------+---------+
: Meta T  : Meta L  :                 : CTyp Lc : CTyp V  :
+---------+---------+---------+       +---------+---------+
: CTyp T  : CTyp L  : CTyp V  :       : FBID V  :
+---------+---------+---------+  ==>  +---------+---------+
: FrPr T  : FrPr L  : FrPr V  :       : CONT Lc : CONT V  :
+---------+---------+---------+       +---------+---------+
: FBID T  : FBID L  : FBID V  :       |  Sig Lc |
+---------+---------+---------+       +---------+---------+
: CONT T  : CONT L  : CONT V  :       | SInf Lc | SInf Vc |
+---------+---------+---------+       +---------+---------+
|  Sig T  |  Sig L  |                 | SVal Lc | SVal Vc |
+---------+---------+---------+       +---------+---------+
| SInf T  | SInf L  | SInf V  |       : FrPr Vc :
+---------+---------+---------+       +---------+
| SVal T  | SVal L  | SVal V  |
+---------+---------+---------+

  0                                       1
  0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 0 | 1 | 1 |FBI|CON|KLO|            RSV            |CID|EXT|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

FBI: FinalBlockId TLV

0:

The uncompressed message does not include a FinalBlockId TLV.

1:

The uncompressed message does include a FinalBlockId, and it is encoded according to Section 5.2. If the FinalBlockId TLV is not compressible, then the message MUST be sent uncompressed.

CON: ContentType TLV

0:

The uncompressed message does not include a ContentType TLV.

1:

The uncompressed message does include a ContentType TLV. The Type field is removed from the compressed message.

KLO: KeyLocator TLV

0:

If the included SignatureType requires a KeyLocator TLV, then the KeyLocator represents a name and is compressed according to Section 5.2. If the name is not compressible, then the message MUST be sent uncompressed.

1:

If the included SignatureType requires a KeyLocator TLV, then the KeyLocator represents a KeyDigest. The Type field of this KeyDigest is removed.

RSV: Reserved

Must be set to 0.

CID: Context Identifier

See Figure 5.

EXT: Extension

0:

No extension byte follows.

1:

Extension byte EXT_0 follows immediately. See Section 5.4.3.

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|  NCS  |        RSV        |EXT|
+---+---+---+---+---+---+---+---+

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

1:

A further extension byte follows immediately.

1. The version is elided from the fixed header and assumed to be 1.
2. The Type and Length fields of the CCNx Message TLV are elided and are obtained from the fixed header on decompression.

T = Type, L = Length, V = Value
Lc = Compressed Length, Vc = Compressed Value
: = optional field, | = mandatory field

+-----------------------------+           +-------------------------+
|    Uncompr. Fixed Header    |           |   Compr. Fixed Header   |
+-----------------------------+           +-------------------------+
+---------+---------+---------+           +---------+
: ILT T   : ILT L   : ILT V   :           : ILT Vc  :
+---------+---------+---------+           +---------+
: MSGH T  : MSGH L  : MSGH V  :           : MSGH Vc :
+---------+---------+---------+           +---------+
+---------+---------+                     +---------+
| MSGT T  | MSGT L  |                     | Name Vc |
+---------+---------+---------+           +---------+
| Name T  | Name L  | Name V  |    ==>    : KIDR Vc :
+---------+---------+---------+           +---------+
: KIDR T  : KIDR L  : KIDR V  :           : OBHR Vc :
+---------+---------+---------+           +---------+---------+
: OBHR T  : OBHR L  : OBHR V  :           : PAYL Lc : PAYL V  :
+---------+---------+---------+           +---------+---------+
: PAYL T  : PAYL L  : PAYL V  :           : VALG Lc : VALG Vc :
+---------+---------+---------+           +---------+---------+
: VALG T  : VALG L  : VALG V  :           : VPAY Lc : VPAY V  :
+---------+---------+---------+           +---------+---------+
: VPAY T  : VPAY L  : VPAY V  :
+---------+---------+---------+

  0                                       1
  0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 1 | 0 | 1 |FLG|PTY|HPL|FRS|PAY|ILT|MGH|KIR|CHR|VAL|CID|EXT|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

FLG: Flags field in the fixed header

0:

The Flags field equals 0 and is removed from the Interest message.

1:

The Flags field appears in the fixed header.

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 appears in the fixed header.

1:

The HopLimit field is elided and assumed to be 1.

FRS: Reserved field in the fixed header

0:

The Reserved field appears in the fixed header.

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 byte and is encoded as described in Section 7. The Type and Length fields are elided.

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 and Length fields are removed. The Length field is assumed to represent 32 bytes. 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 and Length fields are removed. The Length field is assumed to represent 32 bytes. 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 and Length fields are removed. The Length field is assumed to represent 32 bytes. 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 byte follows immediately that handles validation-related TLV compressions and is described in Section 6.3.2.2.

CID: Context Identifier

See Figure 5.

EXT: Extension

0:

No extension byte follows.

1:

Extension byte EXT_0 follows immediately. See Section 6.3.3.

1. InterestLifetime TLV
2. Message Hash TLV

0       1       2       3       4       5       6       7       8
+-------+-------+-------+-------+-------+-------+-------+-------+
|         ValidationAlg         |     KeyID     |      RSV      |
+-------+-------+-------+-------+-------+-------+-------+-------+

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

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 and Length fields are removed. The Length field is assumed to represent 32 bytes. The outer KeyID TLV is omitted.

11:

A T_SHA-512 TLV is present, and the Type and Length fields are removed. The Length field is assumed to represent 64 bytes. The outer KeyID TLV is omitted.

RSV: Reserved

Must be set to 0.

0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|  NCS  |        RSV        |EXT|
+---+---+---+---+---+---+---+---+

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

1:

A further extension byte follows immediately.

1. The version is elided from the fixed header and assumed to be 1.
2. The PacketType field is elided from the fixed header.
3. The Type and Length fields of the CCNx Message TLV are elided and are obtained from the fixed header on decompression.

T = Type, L = Length, V = Value
Lc = Compressed Length, Vc = Compressed Value
: = optional field, | = mandatory field

+-----------------------------+           +-------------------------+
|    Uncompr. Fixed Header    |           |   Compr. Fixed Header   |
+-----------------------------+           +-------------------------+
+---------+---------+---------+           +---------+
: RCT T   : RCT L   : RCT V   :           : RCT Vc  :
+---------+---------+------.--+           +---------+
: MSGH T  : MSGH L  : MSGH V  :           : MSGH Vc :
+---------+---------+---------+           +---------+
+---------+---------+                     +---------+
| MSGT T  | MSGT L  |                     | Name Vc |
+---------+---------+---------+           +---------+
| Name T  | Name L  | Name V  |    ==>    : EXPT Vc :
+---------+---------+---------+           +---------+---------+
: PTYP T  : PTYP L  : PTYP V  :           : PAYL Lc : PAYL V  :
+---------+---------+---------+           +---------+---------+
: EXPT T  : EXPT L  : EXPT V  :           : VALG Lc : VALG Vc :
+---------+---------+---------+           +---------+---------+
: PAYL T  : PAYL L  : PAYL V  :           : VPAY Lc : VPAY V  :
+---------+---------+---------+           +---------+---------+
: VALG T  : VALG L  : VALG V  :
+---------+---------+---------+
: VPAY T  : VPAY L  : VPAY V  :
+---------+---------+---------+

  0                                       1
  0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 1 | 1 | 1 |FLG|FRS|PAY|RCT|MGH| PLTYP |EXP|VAL|RSV|CID|EXT|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

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 Recommended Cache Time TLV

0:

The Recommended Cache Time TLV is absent.

1:

The Recommended Cache Time TLV is present, and the Type and 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 and Length fields are removed. The Length field is assumed to represent 32 bytes. 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.

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 and Length fields are elided.

VAL: Optional ValidationAlgorithm and ValidationPayload TLVs

See Section 6.3.2.

RSV: Reserved

Must be set to 0.

CID: Context Identifier

See Figure 5.

EXT: Extension

0:

No extension byte follows.

1:

Extension byte EXT_0 follows immediately. See Section 6.4.3.

1. Recommended Cache Time TLV
2. Message Hash TLV

0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|  NCS  |        RSV        |EXT|
+---+---+---+---+---+---+---+---+

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

1:

A further extension byte follows immediately.

Subnormal (b == 0):

(0 + a/8) * 2 * C

Normalized (b > 0):

(1 + a/8) * 2^b * C (see [RFC 5497])

• Minimum subnormal number: 0 seconds
• 2nd minimum subnormal number: ~0.007812 seconds
• Maximum subnormal number: ~0.054688 seconds
• Minimum normalized number: ~0.062500 seconds
• 2nd minimum normalized number: ~0.070312 seconds
• Maximum normalized number: ~3.99 years

DEFAULT_NDN_HOPLIMIT:

255

• Signed time offsets compress, per Section 7, without the need for rounding.
• The context state (e.g., prefixes) is distributed such that long names can be elided from Interest and Data messages.
• Frequently used TLV type numbers for CCNx and NDN stay in the lower range (< 255).

• The name compression scheme (Section 5.2) is optimized for short name components of type GenericNameComponent. An empirical study on name lengths in different deployments of selected use cases, such as smart home, smart city, and industrial IoT can provide meaningful reports on necessary name component types and lengths. A conclusive outcome helps to understand whether and how extension mechanisms are needed (Section 5.3.3). As a preliminary analysis, [ICNLOWPAN] investigates the effectiveness of the proposed compression scheme with URLs obtained from the WWW. Studies on deployments of Constrained Application Protocol (CoAP) [RFC 7252] can offer additional insights on naming schemes in the IoT.
• The fragmentation scheme (Section 4.2) inherited from 6LoWPAN allows for a transparent, hop-wise reassembly of CCNx or NDN packets. Fragment forwarding [RFC 8930] with selective fragment recovery [RFC 8931] can improve the end-to-end latency and reliability while it reduces buffer requirements on forwarders. Initial evaluations [SFR-ICNLOWPAN] show that a naive integration of these upcoming fragmentation features into ICN LoWPAN renders the hop-wise content replication inoperative, since Interest and Data messages are reassembled end-to-end. More deployment experiences are necessary to gauge the feasibility of different fragmentation schemes in ICN LoWPAN.
• The context state (Section 8.1) holds information that is shared between a set of devices in a LoWPAN. Fixed name prefixes and suffixes are good candidates to be distributed to all nodes in order to elide them from request and response messages. More experience and a deeper inspection of currently available and upcoming protocol features is necessary to identify other protocol fields.
• The distribution and synchronization of the context state can potentially be adopted from Section 7.2 of RFC 6775 but requires further evaluations. While 6LoWPAN uses the Neighbor Discovery protocol to disseminate state, CCNx and NDN deployments are missing out on a standard mechanism to bootstrap and manage configurations.
• The stateful en route compression (Section 8.2) supports a limited number of 127 distinct HopIDs that can be simultaneously in use on a single node. Complex deployment scenarios that make use of multiple, concurrent requests can provide a better insight on the number of open requests stored in the PIT of memory-constrained devices. This number can serve as an upper bound and determines whether the HopID length needs to be resized to fit more HopIDs at the cost of additional header overhead.
• 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. Different reports can help to illuminate the complexity of implementing ICN LoWPAN for constrained devices, as well as on maintaining interoperability with other implementations.

[IEEE.754.2019]

IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE Std 754-2019,
<https://standards.ieee.org/content/ieee-standards/en/standard/754-2019.html>.

[ieee802.15.4]

IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE Std 802.15.4-2020,
<https://standards.ieee.org/standard/802_15_4-2020.html>.

[RFC2119]

S. Bradner, "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]

G. Montenegro, N. Kushalnagar, J. Hui, 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>.

[RFC5497]

T. Clausen, and C. Dearlove, "Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, DOI 10.17487/RFC5497, March 2009,
<https://www.rfc-editor.org/info/rfc5497>.

[RFC6256]

W. Eddy, and E. Davies, "Using Self-Delimiting Numeric Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May 2011,
<https://www.rfc-editor.org/info/rfc6256>.

[RFC6282]

J. Hui, 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>.

[RFC6775]

Z. Shelby, S. Chakrabarti, E. Nordmark, and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[CCN-LITE]

"CCN-lite, a lightweight implementation of the CCNx protocol and its variations",
<https://github.com/cn-uofbasel/ccn-lite>.

[ICNLOWPAN]

FU Berlin, C. Gündoğan, P. Kietzmann, T. Schmidt, and M. Wählisch, "Designing a LoWPAN convergence layer for the Information Centric Internet of Things", December 2020,
<https://doi.org/10.1016/j.comcom.2020.10.002>.

[ICNRG-FLIC]

Network Systems Research & Design, C. Tschudin, C. Wood, M. Mosko, and D. Oran, "File-Like ICN Collections (FLIC)", Internet-Draft draft-irtf-icnrg-flic-02, November 2019,
<https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-flic-02>.

[NDN]

V. Jacobson, D. Smetters, J. Thornton, M. Plass, N. Briggs, and R. Braynard, "Networking named content", December 2009,
<https://doi.org/10.1145/1658939.1658941>.

[NDN-EXP1]

FU Berlin, E. Baccelli, C. Mehlis, O. Hahm, TC. Schmidt, and M. Wählisch, "Information centric networking in the IoT: experiments with NDN in the wild", September 2014,
<http://dx.doi.org/10.1145/2660129.2660144>.

[NDN-EXP2]

FU Berlin, C. Gündoğan, P. Kietzmann, M. Lenders, H. Petersen, TC. Schmidt, and M. Wählisch, "NDN, CoAP, and MQTT: a comparative measurement study in the IoT", September 2018,
<https://doi.org/10.1145/3267955.3267967>.

[NDN-MAC]

FU Berlin, P. Kietzmann, C. Gündoğan, TC. Schmidt, O. Hahm, and M. Wählisch, "The need for a name to MAC address mapping in NDN: towards quantifying the resource gain", 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/>.

[RFC7228]

C. Bormann, M. Ersue, and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.

[RFC7252]

Z. Shelby, K. Hartke, and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.

[RFC7476]

K. Pentikousis, B. Ohlman, D. Corujo, G. Boggia, G. Tyson, E. Davies, A. Molinaro, and S. Eum, "Information-Centric Networking: Baseline Scenarios", RFC 7476, DOI 10.17487/RFC7476, March 2015,
<https://www.rfc-editor.org/info/rfc7476>.

[RFC7927]

D. Kutscher, S. Eum, K. Pentikousis, I. Psaras, D. Corujo, D. Saucez, T. Schmidt, 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]

K. Pentikousis, B. Ohlman, E. Davies, S. Spirou, 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]

P. Thubert, 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]

M. Mosko, I. Solis, and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019,
<https://www.rfc-editor.org/info/rfc8569>.

[RFC8609]

M. Mosko, I. Solis, 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>.

[RFC8930]

T. Watteyne, P. Thubert, and C. Bormann, "On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network", RFC 8930, DOI 10.17487/RFC8930, November 2020,
<https://www.rfc-editor.org/info/rfc8930>.

[RFC8931]

P. Thubert, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery", RFC 8931, DOI 10.17487/RFC8931, November 2020,
<https://www.rfc-editor.org/info/rfc8931>.

[RIOT]

FU Berlin, E. Baccelli, C. Gündoğan, O. Hahm, P. Kietzmann, MS. Lenders, H. Petersen, K. Schleiser, TC. Schmidt, and M. Wählisch, "RIOT: An Open Source Operating System for Low-End Embedded Devices in the IoT", December 2018,
<https://doi.org/10.1109/JIOT.2018.2815038>.

[SFR-ICNLOWPAN]

FU Berlin, M. Lenders, C. Gündoğan, TC. Schmidt, and M. Wählisch, "Connecting the Dots: Selective Fragment Recovery in ICNLoWPAN", September 2020,
<https://doi.org/10.1145/3405656.3418719>.

[TLV-ENC-802.15.4]

M. Mosko, and C. Tschudin, "CCN and NDN TLV encodings in 802.15.4 packets", January 2015,
<https://datatracker.ietf.org/meeting/interim-2015-icnrg-01/materials/slides-interim-2015-icnrg-1-2>.

[WIRE-FORMAT-CONSID]

G. Wang, C. Tschudin, and R. Ravindran, "CCN/NDN Protocol Wire Format and Functionality Considerations", January 2015,
<https://datatracker.ietf.org/meeting/interim-2015-icnrg-01/materials/slides-interim-2015-icnrg-1-8>.

Cenk Gündoğan

Thomas C. Schmidt

Matthias Wählisch

Christopher Scherb

Claudio Marxer

Christian Tschudin