< draft-irtf-icnrg-icnlowpan-02.txt   draft-irtf-icnrg-icnlowpan-03.txt >
ICN Research Group C. Gundogan ICN Research Group C. Gundogan
Internet-Draft TC. Schmidt Internet-Draft TC. Schmidt
Intended status: Experimental HAW Hamburg Intended status: Experimental HAW Hamburg
Expires: September 9, 2019 M. Waehlisch Expires: January 9, 2020 M. Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
C. Scherb C. Scherb
C. Marxer C. Marxer
C. Tschudin C. Tschudin
University of Basel University of Basel
March 8, 2019 July 8, 2019
ICN Adaptation to LowPAN Networks (ICN LoWPAN) ICN Adaptation to LowPAN Networks (ICN LoWPAN)
draft-irtf-icnrg-icnlowpan-02 draft-irtf-icnrg-icnlowpan-03
Abstract Abstract
In this document, a convergence layer for CCNx and NDN over IEEE In this document, a convergence layer for CCNx and NDN over IEEE
802.15.4 LoWPAN networks is defined. A new frame format is specified 802.15.4 LoWPAN networks is defined. A new frame format is specified
to adapt CCNx and NDN packets to the small MTU size of IEEE 802.15.4. to adapt CCNx and NDN packets to the small MTU size of IEEE 802.15.4.
For that, syntactic and semantic changes to the TLV-based header For that, syntactic and semantic changes to the TLV-based header
formats are described. To support compatibility with other LoWPAN formats are described. To support compatibility with other LoWPAN
technologies that may coexist on a wireless medium, the dispatching technologies that may coexist on a wireless medium, the dispatching
scheme provided by 6LoWPAN is extended to include new dispatch types scheme provided by 6LoWPAN is extended to include new dispatch types
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
3.2. Stateless Header Compression . . . . . . . . . . . . . . 6 3.2. Stateless Header Compression . . . . . . . . . . . . . . 6
3.3. Stateful Header Compression . . . . . . . . . . . . . . . 7 3.3. Stateful Header Compression . . . . . . . . . . . . . . . 7
4. IEEE 802.15.4 Adaptation . . . . . . . . . . . . . . . . . . 7 4. IEEE 802.15.4 Adaptation . . . . . . . . . . . . . . . . . . 7
4.1. LoWPAN Encapsulation . . . . . . . . . . . . . . . . . . 7 4.1. LoWPAN Encapsulation . . . . . . . . . . . . . . . . . . 7
4.2. Link Fragmentation . . . . . . . . . . . . . . . . . . . 8 4.2. Link Fragmentation . . . . . . . . . . . . . . . . . . . 8
5. Space-efficient Message Encoding for NDN . . . . . . . . . . 9 5. Space-efficient Message Encoding for NDN . . . . . . . . . . 9
5.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 9 5.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Name TLV Compression . . . . . . . . . . . . . . . . . . 10 5.2. Name TLV Compression . . . . . . . . . . . . . . . . . . 10
5.3. Interest Messages . . . . . . . . . . . . . . . . . . . . 11 5.3. Interest Messages . . . . . . . . . . . . . . . . . . . . 11
5.4. Data Messages . . . . . . . . . . . . . . . . . . . . . . 14 5.4. Data Messages . . . . . . . . . . . . . . . . . . . . . . 14
6. Space-efficient Message Encoding for CCNx . . . . . . . . . . 17 6. Space-efficient Message Encoding for CCNx . . . . . . . . . . 16
6.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 17 6.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Name TLV Compression . . . . . . . . . . . . . . . . . . 17 6.2. Name TLV Compression . . . . . . . . . . . . . . . . . . 16
6.3. Interest Messages . . . . . . . . . . . . . . . . . . . . 17 6.3. Interest Messages . . . . . . . . . . . . . . . . . . . . 17
6.4. Content Objects . . . . . . . . . . . . . . . . . . . . . 23 6.4. Content Objects . . . . . . . . . . . . . . . . . . . . . 23
7. Compressed Time Encoding . . . . . . . . . . . . . . . . . . 26 7. Compressed Time Encoding . . . . . . . . . . . . . . . . . . 26
8. Stateful Header Compression . . . . . . . . . . . . . . . . . 27 8. Stateful Header Compression . . . . . . . . . . . . . . . . . 27
8.1. LoWPAN-local State . . . . . . . . . . . . . . . . . . . 27 8.1. LoWPAN-local State . . . . . . . . . . . . . . . . . . . 27
8.2. En-route State . . . . . . . . . . . . . . . . . . . . . 28 8.2. En-route State . . . . . . . . . . . . . . . . . . . . . 28
8.3. Integrating Stateful Header Compression . . . . . . . . . 30 8.3. Integrating Stateful Header Compression . . . . . . . . . 30
9. Implementation Report and Guidance . . . . . . . . . . . . . 30 9. ICNLoWPAN Constants and Variables . . . . . . . . . . . . . . 30
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 10. Implementation Report and Guidance . . . . . . . . . . . . . 30
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 11. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11.1. Page Switch Dispatch Type . . . . . . . . . . . . . . . 31 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 12.1. Page Switch Dispatch Type . . . . . . . . . . . . . . . 31
12.1. Normative References . . . . . . . . . . . . . . . . . . 31 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
12.2. Informative References . . . . . . . . . . . . . . . . . 32 13.1. Normative References . . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Estimated Size Reduction . . . . . . . . . . . . . . 35 Appendix A. Estimated Size Reduction . . . . . . . . . . . . . . 35
A.1. NDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 A.1. NDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.1.1. Interest . . . . . . . . . . . . . . . . . . . . . . 35 A.1.1. Interest . . . . . . . . . . . . . . . . . . . . . . 35
A.1.2. Data . . . . . . . . . . . . . . . . . . . . . . . . 36 A.1.2. Data . . . . . . . . . . . . . . . . . . . . . . . . 36
A.2. CCNx . . . . . . . . . . . . . . . . . . . . . . . . . . 38 A.2. CCNx . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.2.1. Interest . . . . . . . . . . . . . . . . . . . . . . 38 A.2.1. Interest . . . . . . . . . . . . . . . . . . . . . . 38
A.2.2. Content Object . . . . . . . . . . . . . . . . . . . 39 A.2.2. Content Object . . . . . . . . . . . . . . . . . . . 39
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
skipping to change at page 4, line 51 skipping to change at page 5, line 4
O O O devices O O O devices
O O O O
Figure 1: IoT Stub Network Figure 1: IoT Stub Network
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The use of the term, "silently ignore" is not defined in RFC 2119.
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 However, the term is used in this document and can be similarly
construed. construed.
This document uses the terminology of [RFC7476], [RFC7927], and This document uses the terminology of [RFC7476], [RFC7927], and
[RFC7945] for ICN entities. [RFC7945] for ICN entities.
The following terms are used in the document and defined as follows: The following terms are used in the document and defined as follows:
ICN LoWPAN: Information-Centric Networking over Low-power Wireless ICN LoWPAN: Information-Centric Networking over Low-power Wireless
Personal Area Network Personal Area Network
LLN Low-Power and Lossy Network LLN Low-Power and Lossy Network
CCNx: Content-Centric Networking Architecture CCNx: Content-Centric Networking Architecture
NDN: Named Data Networking Architecture NDN: Named Data Networking Architecture
time-value: a time value measured in seconds
time-code: an 8-bit encoded time-value
3. Overview of ICN LoWPAN 3. Overview of ICN LoWPAN
3.1. Link-Layer Convergence 3.1. Link-Layer Convergence
ICN LoWPAN provides a convergence layer that maps ICN packets onto ICN LoWPAN provides a convergence layer that maps ICN packets onto
constrained link-layer technologies. This includes features such as constrained link-layer technologies. This includes features such as
link-layer fragmentation, protocol separation on the link-layer link-layer fragmentation, protocol separation on the link-layer
level, and link-layer address mappings. The stack traversal is level, and link-layer address mappings. The stack traversal is
visualized in Figure 2. visualized in Figure 2.
skipping to change at page 11, line 42 skipping to change at page 11, line 42
0 1 ... 7 0 1 ... 7
+---+---+-----------------------+ +---+---+-----------------------+
| 0 | 0 | resv | | 0 | 0 | resv |
+---+---+-----------------------+ +---+---+-----------------------+
Figure 11: Dispatch format for uncompressed NDN Interest messages Figure 11: Dispatch format for uncompressed NDN Interest messages
5.3.2. Compressed Interest Messages 5.3.2. Compressed Interest Messages
The compressed Interest message uses the extended dispatch format The compressed Interest message uses the extended dispatch format
(Figure 5) and sets the C flag to "1" and the M flag to "0". In the (Figure 5) and sets the C flag to "1" and the M flag to "0". This
default use case, the Interest message is compressed with the specification assumes the presence of a HopLimit TLV, which will be
following minimal rule set: set to a default value of DEFAULT_NDN_HOPLIMIT prior to the
compression if absent in the original message. In the default use
case, the Interest message is compressed with the following minimal
rule set:
1. The "Type" field of the outermost MessageType TLV is removed. 1. The "Type" field of the outermost MessageType TLV is removed.
2. The Name TLV is compressed according to Section 5.2. For this, 2. The Name TLV is compressed according to Section 5.2. For this,
all NameComponents are expected to be of type all NameComponents are expected to be of type
GenericNameComponent. Otherwise, the message MUST be sent GenericNameComponent. Otherwise, the message MUST be sent
uncompressed. uncompressed.
3. The InterestLifetime TLV length is set to 2 and the time is 3. InterestLifetime TLV is encoded as described in Section 7. If a
encoded as described in Section 7. The type and length fields lifetime is not a valid time-value, then the lifetime is rounded
are elided. If a lifetime is not a valid time-value, then the up to the nearest valid time-value (see Section 7).
lifetime is rounded up to the nearest valid time-value (see
Section 7).
4. The Nonce TLV, InterestLifetime TLV and HopLimit TLV MUST be 4. The Nonce TLV, HopLimit TLV and InterestLifetime TLV MUST be
moved to the end of the compressed Interest, keeping the order 1) moved to the end of the compressed Interest, keeping the order 1)
Nonce TLV, 2) InterestLifetime TLV and 3) HopLimit TLV. Nonce TLV, 2) HopLimit TLV and 3) InterestLifetime TLV.
5. The Type and Length fields of Nonce TLV, InterestLifetime TLV and 5. The Type and Length fields of Nonce TLV, HopLimit TLV and
HopLimit TLV are elided. The presence of each TLV is deduced InterestLifetime TLV are elided. The Nonce value has a length of
from the remaining length to parse. The Nonce TLV has a fixed 4 octets and the HopLimit value has a length of 1 octet. The
length of 4, the InterestLifetime TLV has a fixed length of 2 and compressed InterestLifetime (Section 7) has a length of 1 octet.
the HopLimit TLV has a fixed length of 1. Any combination yields The presence of an InterestLifetime TLV is deduced from the
a distinct value that matches the remaining length to parse. remaining length to parse.
The compressed NDN LoWPAN Interest message is visualized in The compressed NDN LoWPAN Interest message is visualized in
Figure 12. Figure 12.
T = Type, L = Length, V = Value T = Type, L = Length, V = Value
+--------+--------+ +--------+ +--------+--------+ +--------+
| Msg T | Msg L | | Msg L | | Msg T | Msg L | | Msg L |
+--------+--------+--------+ +--------+ +--------+--------+--------+ +--------+
| Name T | Name L | Name V | | Name V | | Name T | Name L | Name V | | Name V |
+--------+--------+--------+ +--------+--------+ +--------+--------+--------+ +--------+--------+
| CBPfx T| CBPfx L| | FWDH L | FWDH V | | CBPfx T| CBPfx L| | FWDH L | FWDH V |
+--------+--------+ +--------+--------+ +--------+--------+ +--------+--------+
| MBFr T | MBFr L | | PRM L | PRM V | | MBFr T | MBFr L | | PRM L | PRM V |
+--------+--------+--------+ ==> +--------+--------+ +--------+--------+--------+ ==> +--------+--------+
| FWDH T | FWDH L | FWDH V | | NONC V | | FWDH T | FWDH L | FWDH V | | NONC V |
+--------+--------+--------+ +--------+ +--------+--------+--------+ +--------+
| NONC T | NONC L | NONC V | | ILT V | | NONC T | NONC L | NONC V | | HPL V |
+--------+--------+--------+ +--------+ +--------+--------+--------+ +--------+
| ILT T | ILT L | ILT V | | HPL V | | ILT T | ILT L | ILT V | | ILT V |
+--------+--------+--------+ +--------+ +--------+--------+--------+ +--------+
| HPL T | HPL L | HPL V | | HPL T | HPL L | HPL V |
+--------+--------+--------+ +--------+--------+--------+
| PRM T | PRM L | PRM V | | PRM T | PRM L | PRM V |
+--------+--------+--------+ +--------+--------+--------+
Figure 12: Compressed NDN LoWPAN Interest Message Figure 12: Compression of NDN LoWPAN Interest Message
Further TLV compression is indicated by the ICN LoWPAN dispatch in Further TLV compression is indicated by the ICN LoWPAN dispatch in
Figure 13. Figure 13.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 | 0 |CID|DIG|PFX|FRE|FWD|PRM| | 1 | 0 |CID|DIG|PFX|FRE|FWD|PRM|
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 13: Dispatch format for compressed NDN Interest messages Figure 13: Dispatch format for compressed NDN Interest messages
skipping to change at page 14, line 39 skipping to change at page 14, line 39
default, the Data message is compressed with the following base rule default, the Data message is compressed with the following base rule
set: set:
1. The "Type" field of the outermost MessageType TLV is removed. 1. The "Type" field of the outermost MessageType TLV is removed.
2. The Name TLV is compressed according to Section 5.2. For this, 2. The Name TLV is compressed according to Section 5.2. For this,
all NameComponents are expected to be of type all NameComponents are expected to be of type
GenericNameComponent. Otherwise, the message MUST be sent GenericNameComponent. Otherwise, the message MUST be sent
uncompressed. uncompressed.
3. The MetaInfo Type and Length fields are elided from the 3. The MetaInfo TLV as well as Content TLV Type and Length fields
compressed Data message. are elided from the compressed Data message.
4. If present, the FinalBlockId TLV is encoded according to 4. If present, the FinalBlockId TLV is encoded according to
Section 5.2. Section 5.2.
5. The ContentType TLV length is set to 1. Messages with 5. The FreshnessPeriod TLV MUST be moved to the end of the
ContentTypes that require more than 1 octet MUST be sent compressed Data message and the length is set to 1. Type and
uncompressed. Length fields are elided and the value is encoded as described in
Section 7. If the freshness period is not a valid time-value,
6. The FreshnessPeriod TLV length is set to 2 and the time is then the message MUST be sent uncompressed in order to preserve
encoded as described in Section 7. If the freshness period is the security envelope of the Data message. The presence of a
not a valid time-value, then the message MUST be sent FreshnessPeriod TLV is deduced from the remaining length to
uncompressed in order to preserve the security envelope of the parse.
data message.
7. The FreshnessPeriod TLV and ContntType TLV MUST be moved to the
end of the compressed Data, keeping the order 1) FreshnessPeriod
TLV and 2) ContentType TLV.
8. The Type and Length fields of ContentType TLV and FreshnessPeriod
TLV are elided. The presence of each TLV is deduced from the
remaining length to parse. The FreshnessPeriod TLV has a fixed
length of 2 and the ContentType TLV has a fixed length of 1. Any
combination yields a distinct value that matches the remaining
length to parse.
The compressed NDN LoWPAN Data message is visualized in Figure 15. The compressed NDN LoWPAN Data message is visualized in Figure 15.
T = Type, L = Length, V = Value T = Type, L = Length, V = Value
+--------+--------+ +--------+ +--------+--------+ +--------+
| Msg T | Msg L | | Msg L | | Msg T | Msg L | | Msg L |
+--------+--------+--------+ +--------+ +--------+--------+--------+ +--------+
| Name T | Name L | Name V | | Name V | | Name T | Name L | Name V | | Name V |
+--------+--------+--------+ +--------+--------+ +--------+--------+--------+ +--------+
| Meta T | Meta L | | FWDH L | FWDH V | | Meta T | Meta L | | CTyp V |
+--------+--------+--------+ +--------+--------+ +--------+--------+--------+ +--------+
| CTyp T | CTyp L | CTyp V | | FBID V | | CTyp T | CTyp L | CTyp V | | FBID V |
+--------+--------+--------+ ==> +--------+ +--------+--------+--------+ ==> +--------+--------+
| FrPr T | FrPr L | FrPr V | | Sig L | | FrPr T | FrPr L | FrPr V | | CONT L | CONT V |
+--------+--------+--------+ +--------+--------+ +--------+--------+--------+ +--------+--------+
| FBID T | FBID L | FBID V | | SInf L | SInf V | | FBID T | FBID L | FBID V | | Sig L |
+--------+--------+--------+ +--------+--------+
| CONT T | CONT L | CONT V | | SInf L | SInf V |
+--------+--------+--------+ +--------+--------+ +--------+--------+--------+ +--------+--------+
| Sig T | Sig L | | SVal L | SVal V | | Sig T | Sig L | | SVal L | SVal V |
+--------+--------+--------+ +--------+--------+ +--------+--------+--------+ +--------+--------+
| SInf T | SInf L | SInf V | | FrPr V | | SInf T | SInf L | SInf V | | FrPr V |
+--------+--------+--------+ +--------+ +--------+--------+--------+ +--------+
| SVal T | SVal L | SVal V | | CTyp V | | SVal T | SVal L | SVal V |
+--------+--------+--------+ +--------+ +--------+--------+--------+
Figure 15: Compressed NDN LoWPAN Data Message Figure 15: Compression of NDN LoWPAN Data Message
Further TLV compression is indicated by the ICN LoWPAN dispatch in Further TLV compression is indicated by the ICN LoWPAN dispatch in
Figure 16. Figure 16.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 | 1 |CID|DIG|FBI|CON| SIG | | 1 | 1 |CID|DIG|FBI|CON| SIG |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 16: Dispatch format for compressed NDN Data messages Figure 16: Dispatch format for compressed NDN Data messages
skipping to change at page 16, line 30 skipping to change at page 16, line 12
ImplicitSha256DigestComponent as the last TLV. The ImplicitSha256DigestComponent as the last TLV. The
Type and Length fields are omitted. Type and Length fields are omitted.
FBI: FinalBlockId TLV FBI: FinalBlockId TLV
0: The uncompressed message does not include a 0: The uncompressed message does not include a
FinalBlockId TLV. FinalBlockId TLV.
1: The uncompressed message does include a FinalBlockId. 1: The uncompressed message does include a FinalBlockId.
CON: Content TLV CON: ContentType TLV
0: The uncompressed message does not include a Content 0: The uncompressed message does not include a
TLV. ContentType TLV.
1: The uncompressed message does include a Content TLV. 1: The uncompressed message does include a ContentType
The Type field is removed from the compressed TLV. The Type field is removed from the compressed
message. message.
SIG: Signature TLV SIG: Signature TLV
00: The Type fields of the SignatureInfo TLV, 00: The Type fields of the SignatureInfo TLV,
SignatureType TLV and SignatureValue TLV are removed. SignatureType TLV and SignatureValue TLV are removed.
01: Reserved. 01: Reserved.
10: Reserved. 10: Reserved.
skipping to change at page 18, line 31 skipping to change at page 18, line 31
+--------+--------+--------+ +--------+--------+ +--------+--------+--------+ +--------+--------+
| OBHR T | OBHR L | OBHR V | | PAYL L | PAYL V | | OBHR T | OBHR L | OBHR V | | PAYL L | PAYL V |
+--------+--------+--------+ +--------+--------+ +--------+--------+--------+ +--------+--------+
| PAYL T | PAYL L | PAYL V | | VALG L | VALG V | | PAYL T | PAYL L | PAYL V | | VALG L | VALG V |
+--------+--------+--------+ +--------+--------+ +--------+--------+--------+ +--------+--------+
| VALG T | VALG L | VALG V | | VPAY L | VPAY V | | VALG T | VALG L | VALG V | | VPAY L | VPAY V |
+--------+--------+--------+ +--------+--------+ +--------+--------+--------+ +--------+--------+
| VPAY T | VPAY L | VPAY V | | VPAY T | VPAY L | VPAY V |
+--------+--------+--------+ +--------+--------+--------+
Figure 18: Compressed CCNx LoWPAN Interest Message Figure 18: Compression of CCNx LoWPAN Interest Message
Further TLV compression is indicated by the ICN LoWPAN dispatch in Further TLV compression is indicated by the ICN LoWPAN dispatch in
Figure 19. Figure 19.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 1 | 0 |CID|VER|FLG|PTY|HPL|FRS|PAY|ILT|MGH|KIR|CHR|VAL|EXT|RSV| | 1 | 0 |CID|VER|FLG|PTY|HPL|FRS|PAY|ILT|MGH|KIR|CHR|VAL|EXT|RSV|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
skipping to change at page 19, line 47 skipping to change at page 19, line 47
ILT: Optional Hop-By-Hop InterestLifetime TLV ILT: Optional Hop-By-Hop InterestLifetime TLV
See Section 6.3.2.1 for further details on the ordering See Section 6.3.2.1 for further details on the ordering
of hop-by-hop TLVs. of hop-by-hop TLVs.
0: No InterestLifetime TLV is present in the Interest 0: No InterestLifetime TLV is present in the Interest
message. message.
1: An InterestLifetime TLV is present with a fixed length of 1: An InterestLifetime TLV is present with a fixed length of
2 octets and is encoded as described in Section 7. The 1 octet and is encoded as described in Section 7. The
type and length fields are elided. If a lifetime is not type and length fields are elided. If a lifetime is not
a valid time-value, then the lifetime is rounded up to a valid time-value, then the lifetime is rounded up to
the nearest valid time-value (see Section 7). the nearest valid time-value (see Section 7).
MGH: Optional Hop-By-Hop MessageHash TLV MGH: Optional Hop-By-Hop MessageHash TLV
See Section 6.3.2.1 for further details on the ordering See Section 6.3.2.1 for further details on the ordering
of hop-by-hop TLVs. of hop-by-hop TLVs.
This TLV is expected to contain a T_SHA-256 TLV. If This TLV is expected to contain a T_SHA-256 TLV. If
another hash is contained, then the Interest MUST be sent another hash is contained, then the Interest MUST be sent
skipping to change at page 24, line 31 skipping to change at page 24, line 31
+--------+--------+--------+ +--------+--------+ +--------+--------+--------+ +--------+--------+
| EXPT T | EXPT L | EXPT V | | VALG L | VALG V | | EXPT T | EXPT L | EXPT V | | VALG L | VALG V |
+--------+--------+--------+ +--------+--------+ +--------+--------+--------+ +--------+--------+
| PAYL T | PAYL L | PAYL V | | VPAY L | VPAY V | | PAYL T | PAYL L | PAYL V | | VPAY L | VPAY V |
+--------+--------+--------+ +--------+--------+ +--------+--------+--------+ +--------+--------+
| VALG T | VALG L | VALG V | | VALG T | VALG L | VALG V |
+--------+--------+--------+ +--------+--------+--------+
| VPAY T | VPAY L | VPAY V | | VPAY T | VPAY L | VPAY V |
+--------+--------+--------+ +--------+--------+--------+
Figure 22: Compressed CCNx LoWPAN Data Message Figure 22: Compression of CCNx LoWPAN Data Message
Further TLV compression is indicated by the ICN LoWPAN dispatch in Further TLV compression is indicated by the ICN LoWPAN dispatch in
Figure 23. Figure 23.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 1 | 1 |CID|VER|FLG|FRS|PAY|RCT|MGH| PLTYP |EXP|VAL|EXT| RSV | | 1 | 1 |CID|VER|FLG|FRS|PAY|RCT|MGH| PLTYP |EXP|VAL|EXT| RSV |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
skipping to change at page 26, line 36 skipping to change at page 26, line 36
With this ordering in place, Type fields are elided from the With this ordering in place, Type fields are elided from the
Recommended Cache Time TLV and Message Hash TLV. Recommended Cache Time TLV and Message Hash TLV.
Note: If the original Content Object message includes Hop-By-Hop Note: If the original Content Object message includes Hop-By-Hop
Header TLVs with a different ordering, then they remain uncompressed. Header TLVs with a different ordering, then they remain uncompressed.
7. Compressed Time Encoding 7. Compressed Time Encoding
This document defines a compressed TLV encoding format for time- This document defines a compressed TLV encoding format for time-
values that is inspired from [RFC5497]. 16-bit time-codes are used to values that is inspired from [RFC5497]. 8-bit time-codes are used to
represent time-values ranging from milliseconds to days. represent time-values ranging from milliseconds to days.
Time-codes are constructed using the formula: Time-codes are constructed using the formula:
time-code := 2048 * b + a time-code := 8 * b + a
where a is the mantissa and b the exponent of a time-value that where a is the mantissa and b the exponent of a time-value that
follows the form: follows the form:
time-value := (1 + a/2048) * 2^b * C time-value := (1 + a/8) * 2^b * C
The least significant 11 bits of a time-code represents the mantissa The least significant 3 bits of a time-code represents the mantissa
(a) and the most significant 5 bits represent the exponent (b). C is (a) and the most significant 5 bits represent the exponent (b). C is
set to 1/1024 seconds in order to achieve a millisecond resolution. set to 1/1024 seconds in order to achieve a millisecond resolution.
A time-code of all-bits zero MUST be decoded as a time-value of all- A time-code of all-bits zero MUST be decoded as a time-value of all-
bits zero. The smallest representable time-value is thus 0 (a=0, bits zero. The smallest representable time-value is thus 0 (a=0,
b=0), the second smallest is ~0.9 ms (a=1, b=0), and the largest b=0), the second smallest is ~1 ms (a=1, b=0), and the largest time-
time-value is ~48 days (a=2047, b=31). value is ~45 days (a=7, b=31).
An invalid time-value (t, in seconds) MAY be rounded up to the An invalid time-value (t, in seconds) MUST be rounded up to the
nearest valid time-value using this algorithm: nearest valid time-value using this algorithm:
o set b := floor(log2(t/C)) o set b := floor(log2(t/C))
o set a := 2048 * (t / (C * 2^b) - 1) o set a := 8 * (t / (C * 2^b) - 1)
8. Stateful Header Compression 8. Stateful Header Compression
Stateful header compression in ICN LoWPAN enables packet size Stateful header compression in ICN LoWPAN enables packet size
reductions in two ways. First, common information that is shared reductions in two ways. First, common information that is shared
throughout the local LoWPAN may be memorized in context state at all throughout the local LoWPAN may be memorized in context state at all
nodes and ommitted from communication. Second, redundancy in a nodes and ommitted from communication. Second, redundancy in a
single Interest-data exchange may be removed from ICN stateful single Interest-data exchange may be removed from ICN stateful
forwarding on a hop-by-hop bases and memorized in en-route state forwarding on a hop-by-hop bases and memorized in en-route state
tables. tables.
skipping to change at page 30, line 28 skipping to change at page 30, line 28
indicating the presence of a subsequent CID (Figure 29). indicating the presence of a subsequent CID (Figure 29).
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1| CID | --> |1| CID | --> |0| CID | |1| CID | --> |1| CID | --> |0| CID |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 29: Chaining of context identifiers. Figure 29: Chaining of context identifiers.
The HopID is always included as the very first CID. The HopID is always included as the very first CID.
9. Implementation Report and Guidance 9. ICNLoWPAN Constants and Variables
This is a summary of all ICNLoWPAN constants and variables.
DEFAULT_NDN_HOPLIMIT: 255
10. Implementation Report and Guidance
The ICN LoWPAN scheme defined in this document has been implemented 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 as an extension of the NDN/CCNx software stack [CCN-LITE] in its IoT
version on RIOT [RIOT]. An experimental evaluation with varying version on RIOT [RIOT]. An experimental evaluation with varying
configurations is performed in [ICNLOWPAN]. configurations is performed in [ICNLOWPAN].
The header compression performance depends on certain aspects and The header compression performance depends on certain aspects and
configurations. It works best for the following cases: configurations. It works best for the following cases:
o Each name component is of GenericNameComponent type and is limited o Each name component is of GenericNameComponent type and is limited
to a length of 15 bytes. to a length of 15 bytes.
o Time-values for content freshness TLVs represent valid time-values o Time-values for content freshness TLVs represent valid time-values
as per Section 7. Interest lifetimes will round up to the nearest as per Section 7. Interest lifetimes will round up to the nearest
valid encoded time-value. valid encoded time-value.
o Contextual state is distributed, such that long names are elided o Contextual state is distributed, such that long names are elided
from Interest and data messages. from Interest and data messages.
10. Security Considerations 11. Security Considerations
Main memory is typically a scarce resource of constrained networked Main memory is typically a scarce resource of constrained networked
devices. Fragmentation as described in this memo preserves fragments devices. Fragmentation as described in this memo preserves fragments
and purges them only after a packet is reassembled, which requires a and purges them only after a packet is reassembled, which requires a
buffering of all fragments. This scheme is able to handle fragments buffering of all fragments. This scheme is able to handle fragments
for distinctive packets simultaneously, which can lead to overflowing for distinctive packets simultaneously, which can lead to overflowing
packet buffers which cannot hold all necessary fragments for packet packet buffers which cannot hold all necessary fragments for packet
reassembly. Implementers are thus urged to make use of appropriate reassembly. Implementers are thus urged to make use of appropriate
buffer replacement strategies for fragments. buffer replacement strategies for fragments.
The stateful header compression generates ephemeral HopIDs for The stateful header compression generates ephemeral HopIDs for
incoming and outgoing Interests and consumes them on returning Data incoming and outgoing Interests and consumes them on returning Data
packets. Forged Interests can deplete the number of available packets. Forged Interests can deplete the number of available
HopIDs, thus leading to a denial of compression service for HopIDs, thus leading to a denial of compression service for
subsequent content requests. subsequent content requests.
To further alleviate the problems caused by forged fragments or To further alleviate the problems caused by forged fragments or
Interest initiations, proper protective mechanisms for accessing the Interest initiations, proper protective mechanisms for accessing the
link-layer should be deployed. link-layer should be deployed.
11. IANA Considerations 12. IANA Considerations
11.1. Page Switch Dispatch Type 12.1. Page Switch Dispatch Type
This document makes use of "Page 2" from the existing paging This document makes use of "Page 2" from the existing paging
dispatches in [RFC8025]. dispatches in [RFC8025].
12. References 13. References
12.1. Normative References 13.1. Normative References
[ieee802.15.4] [ieee802.15.4]
"IEEE Std. 802.15.4-2015", April 2016, "IEEE Std. 802.15.4-2015", April 2016,
<https://standards.ieee.org/findstds/ <https://standards.ieee.org/findstds/
standard/802.15.4-2015.html>. standard/802.15.4-2015.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 32, line 5 skipping to change at page 32, line 10
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>. <https://www.rfc-editor.org/info/rfc4944>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>. <https://www.rfc-editor.org/info/rfc6282>.
12.2. Informative References 13.2. Informative References
[CCN-LITE] [CCN-LITE]
"CCN-lite: A lightweight CCNx and NDN implementation", "CCN-lite: A lightweight CCNx and NDN implementation",
<http://ccn-lite.net/>. <http://ccn-lite.net/>.
[I-D.irtf-icnrg-ccnxmessages] [I-D.irtf-icnrg-ccnxmessages]
Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV
Format", draft-irtf-icnrg-ccnxmessages-09 (work in Format", draft-irtf-icnrg-ccnxmessages-09 (work in
progress), January 2019. progress), January 2019.
skipping to change at page 32, line 45 skipping to change at page 32, line 50
Experiments with NDN in the Wild", Proc. of 1st ACM Conf. Experiments with NDN in the Wild", Proc. of 1st ACM Conf.
on Information-Centric Networking (ICN-2014) ACM DL, pp. on Information-Centric Networking (ICN-2014) ACM DL, pp.
77-86, September 2014, 77-86, September 2014,
<http://dx.doi.org/10.1145/2660129.2660144>. <http://dx.doi.org/10.1145/2660129.2660144>.
[NDN-EXP2] [NDN-EXP2]
Gundogan, C., Kietzmann, P., Lenders, M., Petersen, H., Gundogan, C., Kietzmann, P., Lenders, M., Petersen, H.,
Schmidt, TC., and M. Waehlisch, "NDN, CoAP, and MQTT: A Schmidt, TC., and M. Waehlisch, "NDN, CoAP, and MQTT: A
Comparative Measurement Study in the IoT", Proc. of 5th Comparative Measurement Study in the IoT", Proc. of 5th
ACM Conf. on Information-Centric Networking (ICN-2018) ACM ACM Conf. on Information-Centric Networking (ICN-2018) ACM
DL, pp. , September 2018, <http://dx.doi.org/>. DL, pp. 159-171, September 2018,
<https://doi.org/10.1145/3267955.3267967>.
[NDN-MAC] Kietzmann, P., Gundogan, C., Schmidt, TC., Hahm, O., and [NDN-MAC] Kietzmann, P., Gundogan, C., Schmidt, TC., Hahm, O., and
M. Waehlisch, "The Need for a Name to MAC Address Mapping M. Waehlisch, "The Need for a Name to MAC Address Mapping
in NDN: Towards Quantifying the Resource Gain", Proc. of in NDN: Towards Quantifying the Resource Gain", Proc. of
4th ACM Conf. on Information-Centric Networking (ICN- 4th ACM Conf. on Information-Centric Networking (ICN-
2017) ACM DL, pp. 36-42, September 2017, 2017) ACM DL, pp. 36-42, September 2017,
<https://doi.org/10.1145/3125719.3125737>. <https://doi.org/10.1145/3125719.3125737>.
[NDN-PACKET-SPEC] [NDN-PACKET-SPEC]
"NDN Packet Format Specification", "NDN Packet Format Specification",
skipping to change at page 36, line 15 skipping to change at page 36, line 15
------------------------------------, ------------------------------------,
Dispatch Page Switch = 1 | Dispatch Page Switch = 1 |
NDN Interset Dispatch = 1 | NDN Interset Dispatch = 1 |
Interest TLV = 1 | Interest TLV = 1 |
-----------------------, | -----------------------, |
Name | = 9 + n/2 + comps_n Name | = 9 + n/2 + comps_n
NameComponents = n/2 + | NameComponents = n/2 + |
| comps_n | | comps_n |
-----------------------' | -----------------------' |
Nonce = 4 | Nonce = 4 |
InterestLifetime = 2 | HopLimit = 1 |
InterestLifetime = 1 |
------------------------------------' ------------------------------------'
Figure 31: Estimated size of a compressed NDN Interest Figure 31: Estimated size of a compressed NDN Interest
The size difference is: The size difference is:
12 + 1.5n octets. 12 + 1.5n octets.
For the name "/DE/HH/HAW/BT7", the total size gain is 18 octets, For the name "/DE/HH/HAW/BT7", the total size gain is 18 octets,
which is 46% of the uncompressed packet. which is 46% of the uncompressed packet.
A.1.2. Data A.1.2. Data
Figure 32 depicts the size requirements for a basic, uncompressed NDN Figure 32 depicts the size requirements for a basic, uncompressed NDN
Data containing a FreshnessPeriod as MetaInfo. A FreshnessPeriod of Data containing a FreshnessPeriod as MetaInfo. A FreshnessPeriod of
1 minute is assumed. The value is thereby encoded using 2 octets. 1 minute is assumed and the value is encoded using 1 octet. An
An HMACWithSha256 is assumed as signature. The key locator is HMACWithSha256 is assumed as signature. The key locator is assumed
assumed to contain a Name TLV of length klen. to contain a Name TLV of length klen.
------------------------------------, ------------------------------------,
Data TLV = 2 | Data TLV = 2 |
---------------------, | ---------------------, |
Name | 2 + | Name | 2 + |
NameComponents = 2n + | NameComponents = 2n + |
| comps_n | | comps_n |
---------------------' | ---------------------' |
---------------------, | ---------------------, |
MetaInfo | | MetaInfo | |
skipping to change at page 37, line 36 skipping to change at page 37, line 36
Figure 32: Estimated size of an uncompressed NDN Data Figure 32: Estimated size of an uncompressed NDN Data
Figure 33 depicts the size requirements for the compressed version of Figure 33 depicts the size requirements for the compressed version of
the above Data packet. the above Data packet.
------------------------------------, ------------------------------------,
Dispatch Page Switch = 1 | Dispatch Page Switch = 1 |
NDN Data Dispatch = 1 | NDN Data Dispatch = 1 |
-----------------------, | -----------------------, |
Name | = 38 + n/2 + comps_n + Name | = 37 + n/2 + comps_n +
NameComponents = n/2 + | clen + klen NameComponents = n/2 + | clen + klen
| comps_n | | comps_n |
-----------------------' | -----------------------' |
Content = 1 + clen | Content = 1 + clen |
KeyLocator = 1 + klen | KeyLocator = 1 + klen |
DigestSha256 = 32 | DigestSha256 = 32 |
FreshnessPeriod = 2 | FreshnessPeriod = 1 |
------------------------------------' ------------------------------------'
Figure 33: Estimated size of a compressed NDN Data Figure 33: Estimated size of a compressed NDN Data
The size difference is: The size difference is:
15 + 1.5n octets. 16 + 1.5n octets.
For the name "/DE/HH/HAW/BT7", the total size gain is 21 octets. For the name "/DE/HH/HAW/BT7", the total size gain is 22 octets.
A.2. CCNx A.2. CCNx
The CCNx TLV encoding defines a 2-octet encoding for type and length The CCNx TLV encoding defines a 2-octet encoding for type and length
fields, summing up to 4 octets in total without a value. fields, summing up to 4 octets in total without a value.
A.2.1. Interest A.2.1. Interest
Figure 34 depicts the size requirements for a basic, uncompressed Figure 34 depicts the size requirements for a basic, uncompressed
CCNx Interest. No Hop-By-Hop TLVs are included, the protocol version CCNx Interest. No Hop-By-Hop TLVs are included, the protocol version
 End of changes. 51 change blocks. 
97 lines changed or deleted 102 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/