rfc9139.original   rfc9139.txt 
ICN Research Group C. Gundogan Internet Research Task Force (IRTF) C. Gundogan
Internet-Draft TC. Schmidt Request for Comments: 9139 TC. Schmidt
Intended status: Experimental HAW Hamburg Category: Experimental HAW Hamburg
Expires: August 14, 2021 M. Waehlisch ISSN: 2070-1721 M. Wählisch
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
February 10, 2021 November 2021
ICN Adaptation to LoWPAN Networks (ICN LoWPAN) ICN Adaptation to LoWPAN Networks (ICN LoWPAN)
draft-irtf-icnrg-icnlowpan-10
Abstract Abstract
This document defines a convergence layer for CCNx and NDN over IEEE This document defines a convergence layer for Content-Centric
802.15.4 LoWPAN networks. A new frame format is specified to adapt Networking (CCNx) and Named Data Networking (NDN) over IEEE 802.15.4
CCNx and NDN packets to the small MTU size of IEEE 802.15.4. For Low-Power Wireless Personal Area Networks (LoWPANs). A new frame
that, syntactic and semantic changes to the TLV-based header formats format is specified to adapt CCNx and NDN packets to the small MTU
are described. To support compatibility with other LoWPAN size of IEEE 802.15.4. For that, syntactic and semantic changes to
technologies that may coexist on a wireless medium, the dispatching the TLV-based header formats are described. To support compatibility
scheme provided by 6LoWPAN is extended to include new dispatch types with other LoWPAN technologies that may coexist on a wireless medium,
for CCNx and NDN. Additionally, the fragmentation component of the the dispatching scheme provided by IPv6 over LoWPAN (6LoWPAN) is
6LoWPAN dispatching framework is applied to ICN chunks. In its extended to include new dispatch types for CCNx and NDN.
second part, the document defines stateless and stateful compression Additionally, the fragmentation component of the 6LoWPAN dispatching
schemes to improve efficiency on constrained links. Stateless framework is applied to Information-Centric Network (ICN) chunks. In
compression reduces TLV expressions to static header fields for its second part, the document defines stateless and stateful
common use cases. Stateful compression schemes elide state local to compression schemes to improve efficiency on constrained links.
the LoWPAN and replace names in data packets by short local Stateless compression reduces TLV expressions to static header fields
for common use cases. Stateful compression schemes elide states
local to the LoWPAN and replace names in Data packets by short local
identifiers. identifiers.
This document is a product of the IRTF Information-Centric Networking This document is a product of the IRTF Information-Centric Networking
Research Group (ICNRG). Research Group (ICNRG).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Research Task
time. It is inappropriate to use Internet-Drafts as reference Force (IRTF). The IRTF publishes the results of Internet-related
material or to cite them other than as "work in progress." research and development activities. These results might not be
suitable for deployment. This RFC represents the consensus of the
Information-Centric Networking Research Group of the Internet
Research Task Force (IRTF). Documents approved for publication by
the IRSG are not candidates for any level of Internet Standard; see
Section 2 of RFC 7841.
This Internet-Draft will expire on August 14, 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9139.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology
3. Overview of ICN LoWPAN . . . . . . . . . . . . . . . . . . . 6 3. Overview of ICN LoWPAN
3.1. Link-Layer Convergence . . . . . . . . . . . . . . . . . 6 3.1. Link-Layer Convergence
3.2. Stateless Header Compression . . . . . . . . . . . . . . 6 3.2. Stateless Header Compression
3.3. Stateful Header Compression . . . . . . . . . . . . . . . 8 3.3. Stateful Header Compression
4. IEEE 802.15.4 Adaptation . . . . . . . . . . . . . . . . . . 8 4. IEEE 802.15.4 Adaptation
4.1. LoWPAN Encapsulation . . . . . . . . . . . . . . . . . . 8 4.1. LoWPAN Encapsulation
4.1.1. Dispatch Extensions . . . . . . . . . . . . . . . . . 10 4.1.1. Dispatch Extensions
4.2. Adaptation Layer Fragmentation . . . . . . . . . . . . . 10 4.2. Adaptation-Layer Fragmentation
5. Space-efficient Message Encoding for NDN . . . . . . . . . . 11 5. Space-Efficient Message Encoding for NDN
5.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 11 5.1. TLV Encoding
5.2. Name TLV Compression . . . . . . . . . . . . . . . . . . 12 5.2. Name TLV Compression
5.3. Interest Messages . . . . . . . . . . . . . . . . . . . . 13 5.3. Interest Messages
5.3.1. Uncompressed Interest Messages . . . . . . . . . . . 13 5.3.1. Uncompressed Interest Messages
5.3.2. Compressed Interest Messages . . . . . . . . . . . . 13 5.3.2. Compressed Interest Messages
5.3.3. Dispatch Extension . . . . . . . . . . . . . . . . . 17 5.3.3. Dispatch Extension
5.4. Data Messages . . . . . . . . . . . . . . . . . . . . . . 17 5.4. Data Messages
5.4.1. Uncompressed Data Messages . . . . . . . . . . . . . 17 5.4.1. Uncompressed Data Messages
5.4.2. Compressed Data Messages . . . . . . . . . . . . . . 18 5.4.2. Compressed Data Messages
5.4.3. Dispatch Extension . . . . . . . . . . . . . . . . . 20 5.4.3. Dispatch Extension
6. Space-efficient Message Encoding for CCNx . . . . . . . . . . 21 6. Space-Efficient Message Encoding for CCNx
6.1. TLV Encoding . . . . . . . . . . . . . . . . . . . . . . 21 6.1. TLV Encoding
6.2. Name TLV Compression . . . . . . . . . . . . . . . . . . 21 6.2. Name TLV Compression
6.3. Interest Messages . . . . . . . . . . . . . . . . . . . . 21 6.3. Interest Messages
6.3.1. Uncompressed Interest Messages . . . . . . . . . . . 21 6.3.1. Uncompressed Interest Messages
6.3.2. Compressed Interest Messages . . . . . . . . . . . . 22 6.3.2. Compressed Interest Messages
6.3.3. Dispatch Extension . . . . . . . . . . . . . . . . . 28 6.3.3. Dispatch Extension
6.4. Content Objects . . . . . . . . . . . . . . . . . . . . . 28 6.4. Content Objects
6.4.1. Uncompressed Content Objects . . . . . . . . . . . . 28 6.4.1. Uncompressed Content Objects
6.4.2. Compressed Content Objects . . . . . . . . . . . . . 29 6.4.2. Compressed Content Objects
6.4.3. Dispatch Extension . . . . . . . . . . . . . . . . . 32 6.4.3. Dispatch Extension
7. Compressed Time Encoding . . . . . . . . . . . . . . . . . . 33 7. Compressed Time Encoding
8. Stateful Header Compression . . . . . . . . . . . . . . . . . 34 8. Stateful Header Compression
8.1. LoWPAN-local State . . . . . . . . . . . . . . . . . . . 34 8.1. LoWPAN-Local State
8.2. En-route State . . . . . . . . . . . . . . . . . . . . . 35 8.2. En-Route State
8.3. Integrating Stateful Header Compression . . . . . . . . . 37 8.3. Integrating Stateful Header Compression
9. ICN LoWPAN Constants and Variables . . . . . . . . . . . . . 37 9. ICN LoWPAN Constants and Variables
10. Implementation Report and Guidance . . . . . . . . . . . . . 37 10. Implementation Report and Guidance
10.1. Preferred Configuration . . . . . . . . . . . . . . . . 37 10.1. Preferred Configuration
10.2. Further Experimental Deployments . . . . . . . . . . . . 38 10.2. Further Experimental Deployments
11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 11. Security Considerations
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 12. IANA Considerations
12.1. Reserving Space in the 6LoWPAN Dispatch Type Field 12.1. Updates to the 6LoWPAN Dispatch Type Field Registry
Registry . . . . . . . . . . . . . . . . . . . . . . . . 40 13. References
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 13.1. Normative References
13.1. Normative References . . . . . . . . . . . . . . . . . . 40 13.2. Informative References
13.2. Informative References . . . . . . . . . . . . . . . . . 41 Appendix A. Estimated Size Reduction
Appendix A. Estimated Size Reduction . . . . . . . . . . . . . . 45 A.1. NDN
A.1. NDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 A.1.1. Interest
A.1.1. Interest . . . . . . . . . . . . . . . . . . . . . . 45 A.1.2. Data
A.1.2. Data . . . . . . . . . . . . . . . . . . . . . . . . 46 A.2. CCNx
A.2. CCNx . . . . . . . . . . . . . . . . . . . . . . . . . . 48 A.2.1. Interest
A.2.1. Interest . . . . . . . . . . . . . . . . . . . . . . 48 A.2.2. Content Object
A.2.2. Content Object . . . . . . . . . . . . . . . . . . . 49 Acknowledgments
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
The Internet of Things (IoT) has been identified as a promising The Internet of Things (IoT) has been identified as a promising
deployment area for Information Centric Networks (ICN), as deployment area for Information-Centric Networking (ICN), as
infrastructureless access to content, resilient forwarding, and in- infrastructureless access to content, resilient forwarding, and in-
network data replication demonstrated notable advantages over the network data replication demonstrates notable advantages over the
traditional host-to-host approach on the Internet [NDN-EXP1], traditional host-to-host approach on the Internet [NDN-EXP1]
[NDN-EXP2]. Recent studies [NDN-MAC] have shown that an appropriate [NDN-EXP2]. Recent studies [NDN-MAC] have shown that an appropriate
mapping to link layer technologies has a large impact on the mapping to link-layer technologies has a large impact on the
practical performance of an ICN. This will be even more relevant in practical performance of an ICN. This will be even more relevant in
the context of IoT communication where nodes often exchange messages the context of IoT communication where nodes often exchange messages
via low-power wireless links under lossy conditions. In this memo, via low-power wireless links under lossy conditions. In this memo,
we address the base adaptation of data chunks to such link layers for we address the base adaptation of data chunks to such link layers for
the ICN flavors NDN [NDN] and CCNx [RFC8569], [RFC8609]. the ICN flavors NDN [NDN] and CCNx [RFC8569] [RFC8609].
The IEEE 802.15.4 [ieee802.15.4] link layer is used in low-power and The IEEE 802.15.4 [ieee802.15.4] link layer is used in low-power and
lossy networks (see "LLN" in [RFC7228]), in which devices are lossy networks (see LLN in [RFC7228]), in which devices are typically
typically battery-operated and constrained in resources. battery operated and constrained in resources. Characteristics of
Characteristics of LLNs include an unreliable environment, low LLNs include an unreliable environment, low-bandwidth transmissions,
bandwidth transmissions, and increased latencies. IEEE 802.15.4 and increased latencies. IEEE 802.15.4 admits a maximum physical-
admits a maximum physical layer packet size of 127 bytes. The layer packet size of 127 bytes. The maximum frame header size is 25
maximum frame header size is 25 bytes, which leaves 102 bytes for the bytes, which leaves 102 bytes for the payload. IEEE 802.15.4
payload. IEEE 802.15.4 security features further reduce this payload security features further reduce this payload length by up to 21
length by up to 21 bytes, yielding a net of 81 bytes for CCNx or NDN bytes, yielding a net of 81 bytes for CCNx or NDN packet headers,
packet headers, signatures and content. signatures, and content.
6LoWPAN [RFC4944], [RFC6282] is a convergence layer that provides 6LoWPAN [RFC4944] [RFC6282] is a convergence layer that provides
frame formats, header compression and adaptation layer fragmentation frame formats, header compression, and adaptation-layer fragmentation
for IPv6 packets in IEEE 802.15.4 networks. The 6LoWPAN adaptation for IPv6 packets in IEEE 802.15.4 networks. The 6LoWPAN adaptation
introduces a dispatching framework that prepends further information introduces a dispatching framework that prepends further information
to 6LoWPAN packets, including a protocol identifier for payload and to 6LoWPAN packets, including a protocol identifier for payload and
meta information about fragmentation. meta information about fragmentation.
Prevalent Type-Length-Value (TLV) based packet formats such as in Prevalent packet formats based on Type-Length-Value (TLV), such as in
CCNx and NDN are designed to be generic and extensible. This leads CCNx and NDN, are designed to be generic and extensible. This leads
to header verbosity which is inappropriate in constrained to header verbosity, which is inappropriate in constrained
environments of IEEE 802.15.4 links. This document presents ICN environments of IEEE 802.15.4 links. This document presents ICN
LoWPAN, a convergence layer for IEEE 802.15.4 motivated by 6LoWPAN. LoWPAN, a convergence layer for IEEE 802.15.4 motivated by 6LoWPAN.
ICN LoWPAN compresses packet headers of CCNx as well as NDN and ICN LoWPAN compresses packet headers of CCNx, as well as NDN, and
allows for an increased effective payload size per packet. allows for an increased effective payload size per packet.
Additionally, reusing the dispatching framework defined by 6LoWPAN Additionally, reusing the dispatching framework defined by 6LoWPAN
enables compatibility between coexisting wireless deployments of enables compatibility between coexisting wireless deployments of
competing network technologies. This also allows to reuse the competing network technologies. This also allows reuse of the
adaptation layer fragmentation scheme specified by 6LoWPAN for ICN adaptation-layer fragmentation scheme specified by 6LoWPAN for ICN
LoWPAN. LoWPAN.
ICN LoWPAN defines a more space efficient representation of CCNx and ICN LoWPAN defines a more space-efficient representation of CCNx and
NDN packet formats. This syntactic change is described for CCNx and NDN packet formats. This syntactic change is described for CCNx and
NDN separately, as the header formats and TLV encodings differ NDN separately, as the header formats and TLV encodings differ
notably. For further reductions, default header values suitable for notably. For further reductions, default header values suitable for
constrained IoT networks are selected in order to elide corresponding constrained IoT networks are selected in order to elide corresponding
TLVs. Experimental evaluations of the ICN LoWPAN header compression TLVs. Experimental evaluations of the ICN LoWPAN header compression
schemes in [ICNLOWPAN] illustrate a reduced message overhead, a schemes in [ICNLOWPAN] illustrate a reduced message overhead, a
shortened message airtime, and an overall decline in power shortened message airtime, and an overall decline in power
consumption for typical Class 2 [RFC7228] devices compared to consumption for typical Class 2 devices [RFC7228] compared to
uncompressed ICN messages. uncompressed ICN messages.
In a typical IoT scenario (see (Figure 1)), embedded devices are In a typical IoT scenario (see Figure 1), embedded devices are
interconnected via a quasi-stationary infrastructure using a border interconnected via a quasi-stationary infrastructure using a border
router (BR) that connects the constrained LoWPAN network by some router (BR) that connects the constrained LoWPAN network by some
Gateway with the public Internet. In ICN based IoT networks, non- gateway with the public Internet. In ICN-based IoT networks,
local Interest and Data messages transparently travel through the BR nonlocal Interest and Data messages transparently travel through the
up and down between a Gateway and the embedded devices situated in BR up and down between a gateway and the embedded devices situated in
the constrained LoWPAN. the constrained LoWPAN.
|Gateway Services| |Gateway Services|
------------------------- -------------------------
| |
,--------, ,--------,
| | | |
| BR | | BR |
| | | |
'--------' '--------'
LoWPAN LoWPAN
O O O O
O O
O O embedded O O embedded
O O O devices O O O devices
O O O O
Figure 1: IoT Stub Network Figure 1: IoT Stub Network
The document has received fruitful reviews by members of the ICN The document has received fruitful reviews by members of the ICN
community and the research group (see Acknowledgments) for a period community and the research group (see the Acknowledgments section)
of two years. It is the consensus of ICNRG that this document should for a period of two years. It is the consensus of ICNRG that this
be published in the IRTF Stream of the RFC series. This document document should be published in the IRTF Stream of the RFC series.
does not constitute an IETF standard. This document does not constitute an IETF standard.
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
The use of the term, "silently ignore" is not defined in RFC 2119. BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
However, the term is used in this document and can be similarly capitals, as shown here.
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
NDN: Named Data Networking Architecture NDN: Named Data Networking
byte: synonym for octet byte: synonym for octet
nibble: synonym for 4 bits nibble: synonym for 4 bits
time-value: a time offset measured in seconds time-value: a time offset measured in seconds
time-code: an 8-bit encoded time-value 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
skipping to change at page 6, line 28 skipping to change at page 14, line ?
visualized in Figure 2. visualized in Figure 2.
Device 1 Device 2 Device 1 Device 2
,------------------, Router ,------------------, ,------------------, Router ,------------------,
| Application . | __________________ | ,-> Application | | Application . | __________________ | ,-> Application |
|----------------|-| | NDN / CCNx | |-|----------------| |----------------|-| | NDN / CCNx | |-|----------------|
| NDN / CCNx | | | ,--------------, | | | NDN / CCNx | | NDN / CCNx | | | ,--------------, | | | NDN / CCNx |
|----------------|-| |-|--------------|-| |-|----------------| |----------------|-| |-|--------------|-| |-|----------------|
| ICN LoWPAN | | | | ICN LoWPAN | | | | ICN LoWPAN | | ICN LoWPAN | | | | ICN LoWPAN | | | | ICN LoWPAN |
|----------------|-| |-|--------------|-| |-|----------------| |----------------|-| |-|--------------|-| |-|----------------|
| Link-Layer | | | | Link-Layer | | | | Link-Layer | | Link Layer | | | | Link Layer | | | | Link Layer |
'----------------|-' '-|--------------|-' '-|----------------' '----------------|-' '-|--------------|-' '-|----------------'
'--------' '---------' '--------' '---------'
Figure 2: ICN LoWPAN convergence layer for IEEE 802.15.4 Figure 2: ICN LoWPAN Convergence Layer for IEEE 802.15.4
Section 4 of this document defines the convergence layer for IEEE Section 4 of this document defines the convergence layer for IEEE
802.15.4. 802.15.4.
3.2. Stateless Header Compression 3.2. Stateless Header Compression
ICN LoWPAN also defines a stateless header compression scheme with ICN LoWPAN also defines a stateless header compression scheme with
the main purpose of reducing header overhead of ICN packets. This is the main purpose of reducing header overhead of ICN packets. This is
of particular importance for link-layers with small MTUs. The of particular importance for link layers with small MTUs. The
stateless compression does not require pre-configuration of global stateless compression does not require preconfiguration of a global
state. state.
The CCNx and NDN header formats are composed of Type-Length-Value The CCNx and NDN header formats are composed of Type-Length-Value
(TLV) fields to encode header data. The advantage of TLVs is its (TLV) fields to encode header data. The advantage of TLVs is its
native support of variably structured data. The main disadvantage of native support of variably structured data. The main disadvantage of
TLVs is the verbosity that results from storing the type and length TLVs is the verbosity that results from storing the type and length
of the encoded data. of the encoded data.
The stateless header compression scheme makes use of compact bit The stateless header compression scheme makes use of compact bit
fields to indicate the presence of optional TLVs in the uncompressed fields to indicate the presence of optional TLVs in the uncompressed
packet. The order of set bits in the bit fields corresponds to the packet. The order of set bits in the bit fields corresponds to the
order of each TLV in the packet. Further compression is achieved by order of each TLV in the packet. Further compression is achieved by
specifying default values and reducing the range of certain header specifying default values and reducing the range of certain header
fields. fields.
Figure 3 demonstrates the stateless header compression idea. In this Figure 3 demonstrates the stateless header compression idea. In this
example, the first type of the first TLV is removed and the example, the first type of the first TLV is removed and the
corresponding bit in the bit field is set. The second TLV represents corresponding bit in the bit field is set. The second TLV represents
a fixed-length TLV (e.g., the Nonce TLV in NDN), so that the type and a fixed-length TLV (e.g., the Nonce TLV in NDN), so that the Type and
the length fields are removed. The third TLV represents a boolean Length fields are removed. The third TLV represents a boolean TLV
TLV (e.g., the MustBeFresh selector in NDN) for which the type, (e.g., the MustBeFresh selector in NDN) for which the Type, Length,
length and the value fields are elided. and Value fields are elided.
Uncompressed: Uncompressed:
Variable-length TLV Fixed-length TLV Boolean TLV Variable-length TLV Fixed-length TLV Boolean TLV
,-----------------------,-----------------------,-------------, ,-----------------------,-----------------------,-------------,
+-------+-------+-------+-------+-------+-------+------+------+ +-------+-------+-------+-------+-------+-------+------+------+
| TYP | LEN | VAL | TYP | LEN | VAL | TYP | LEN | | TYP | LEN | VAL | TYP | LEN | VAL | TYP | LEN |
+-------+-------+-------+-------+-------+-------+------+------+ +-------+-------+-------+-------+-------+-------+------+------+
Compressed: Compressed:
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | Bit field | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | Bit Field
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | | | |
,--' '----, '- Boolean Value ,--' '----, '- Boolean Value
| | | |
+-------+-------+-------+ +-------+-------+-------+
| LEN | VAL | VAL | | LEN | VAL | VAL |
+-------+-------+-------+ +-------+-------+-------+
'---------------'-------' '---------------'-------'
Var-len Value Fixed-len Value Var-len Value Fixed-len Value
Figure 3: Compression using a compact bit field - bits encode the Figure 3: Compression Using a Compact Bit Field -- Bits Encode
inclusion of TLVs. the Inclusion of TLVs
Stateless TLV compression for NDN is defined in Section 5. Section 6 Stateless TLV compression for NDN is defined in Section 5. Section 6
defines the stateless TLV compression for CCNx. defines the stateless TLV compression for CCNx.
The extensibility of this compression is described in Section 4.1.1 The extensibility of this compression is described in Section 4.1.1
and allows future documents to update the compression rules outlined and allows future documents to update the compression rules outlined
in this manuscript. in this document.
3.3. Stateful Header Compression 3.3. Stateful Header Compression
ICN LoWPAN further employs two orthogonal stateful compression ICN LoWPAN further employs two orthogonal, stateful compression
schemes for packet size reductions which are defined in Section 8. schemes for packet size reductions, which are defined in Section 8.
These mechanisms rely on shared contexts that are either distributed These mechanisms rely on shared contexts that are either distributed
and maintained in the entire LoWPAN, or are generated on-demand hop- and maintained in the entire LoWPAN or are generated on demand hop-
wise on a particular Interest-data path. wise on a particular Interest-Data path.
The shared context identification is defined in Section 8.1. The The shared context identification is defined in Section 8.1. The
hop-wise name compression "en-route" is specified in Section 8.2. hop-wise name compression "en-route" is specified in Section 8.2.
4. IEEE 802.15.4 Adaptation 4. IEEE 802.15.4 Adaptation
4.1. LoWPAN Encapsulation 4.1. LoWPAN Encapsulation
The IEEE 802.15.4 frame header does not provide a protocol identifier The IEEE 802.15.4 frame header does not provide a protocol identifier
for its payload. This causes problems of misinterpreting frames when for its payload. This causes problems of misinterpreting frames when
several network layers coexist on the same link. To mitigate errors, several network layers coexist on the same link. To mitigate errors,
6LoWPAN defines dispatches as encapsulation headers for IEEE 802.15.4 6LoWPAN defines dispatches as encapsulation headers for IEEE 802.15.4
frames (see Section 5 of [RFC4944]). Multiple LoWPAN encapsulation frames (see Section 5 of [RFC4944]). Multiple LoWPAN encapsulation
headers can precede the actual payload and each encapsulation header headers can precede the actual payload, and each encapsulation header
is identified by a dispatch type. is identified by a dispatch type.
[RFC8025] further specifies dispatch pages to switch between [RFC8025] further specifies dispatch Pages to switch between
different contexts. When a LoWPAN parser encounters a "Page switch" different contexts. When a LoWPAN parser encounters a Page switch
LoWPAN encapsulation header, then all following encapsulation headers LoWPAN encapsulation header, all following encapsulation headers are
are interpreted by using a dispatch table as specified by the "Page interpreted by using a dispatch table, as specified by the Page
switch" header. Page 0 and page 1 are reserved for 6LoWPAN. This switch header. Pages 0 and 1 are reserved for 6LoWPAN. This
document uses page TBD1 ("1111 TBD1 (0xFTBD1)") for ICN LoWPAN. document uses Page 14 (1111 1110 (0xFE)) for ICN LoWPAN.
The base dispatch format (Figure 4) is used and extended by CCNx and The base dispatch format (Figure 4) is used and extended by CCNx and
NDN in Section 5 and Section 6. NDN in Sections 5 and 6.
0 1 2 ...
+---+---+-----------
| C | P | M |
+---+---+-----------
Figure 4: Base dispatch format for ICN LoWPAN
C: Compression
0: The message is uncompressed. 0 1 2 3 ...
+---+---+---+---+---
| 0 | P | M | C |
+---+---+---+---+---
1: The message is compressed. Figure 4: Base Dispatch Format for ICN LoWPAN
P: Protocol P: Protocol
0: The included protocol is NDN. 0: The included protocol is NDN.
1: The included protocol is CCNx. 1: The included protocol is CCNx.
M: Message Type M: Message Type
0: The payload contains an Interest message.
0: The payload contains an Interest message. 1: The payload contains a Data message.
1: The payload contains a Data message. C: Compression
0: The message is uncompressed.
1: The message is compressed.
ICN LoWPAN frames with compressed CCNx and NDN messages (C=1) use the ICN LoWPAN frames with compressed CCNx and NDN messages (C=1) use the
extended dispatch format in Figure 5. extended dispatch format in Figure 5.
0 1 2 3 4 ... 0 1 2 3 ... ...
+---+---+---+---+---+--- +---+---+---+---+...+---+---+
| 1 | P | M |CID|EXT| | 0 | P | M | 1 | |CID|EXT|
+---+---+---+---+---+--- +---+---+---+---+...+---+---+
Figure 5: Extended dispatch format for compressed ICN LoWPAN Figure 5: Extended Dispatch Format for Compressed ICN LoWPAN
CID: Context Identifier CID: Context Identifier
0: No context identifiers are present.
0: No context identifiers are present. 1: Context identifier(s) are present (see Section 8.1).
1: Context identifier(s) are present (see Section 8.1).
EXT: Extension EXT: Extension
0: No extension bytes are present.
0: No extension bytes are present. 1: Extension byte(s) are present (see Section 4.1.1).
1: Extension byte(s) are present (see Section 4.1.1).
The encapsulation format for ICN LoWPAN is displayed in Figure 6. The encapsulation format for ICN LoWPAN is displayed in Figure 6.
+------...------+------...-----+--------+-------...-------+-----... +------...------+------...-----+--------+-------...-------+-----...
| IEEE 802.15.4 | RFC4944 Disp.| Page | ICN LoWPAN Disp.| Payl. / | IEEE 802.15.4 | RFC4944 Disp.| Page | ICN LoWPAN Disp.| Payl. /
+------...------+------...-----+--------+-------...-------+-----... +------...------+------...-----+--------+-------...-------+-----...
Figure 6: LoWPAN Encapsulation with ICN-LoWPAN Figure 6: LoWPAN Encapsulation with ICN LoWPAN
IEEE 802.15.4: The IEEE 802.15.4 header. IEEE 802.15.4: The IEEE 802.15.4 header.
RFC4944 Disp.: Optional additional dispatches defined in Section 5.1 RFC4944 Disp.: Optional additional dispatches defined in Section 5.1
of [RFC4944] of [RFC4944].
Page: Page Switch. TBD1 for ICN LoWPAN. Page: Page switch. 14 for ICN LoWPAN.
ICN LoWPAN: Dispatches as defined in Section 5 and Section 6. ICN LoWPAN: Dispatches as defined in Sections 5 and 6.
Payload: The actual (un-)compressed CCNx or NDN message. Payload: The actual (un-)compressed CCNx or NDN message.
4.1.1. Dispatch Extensions 4.1.1. Dispatch Extensions
Extension bytes allow for the extensibility of the initial Extension bytes allow for the extensibility of the initial
compression rule set. The base format for an extension byte is compression rule set. The base format for an extension byte is
depicted in Figure 7. depicted in Figure 7.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| - | - | - | - | - | - | - |EXT| | - | - | - | - | - | - | - |EXT|
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 7: Base format for dispatch extensions. Figure 7: Base Format for Dispatch Extensions
EXT: Extension EXT: Extension
0: No other extension byte follows.
0: No other extension byte follows. 1: A further extension byte follows.
1: A further extension byte follows.
Extension bytes are numbered according to their order. Future Extension bytes are numbered according to their order. Future
documents MUST follow the naming scheme "EXT_0, EXT_1, ...", when documents MUST follow the naming scheme EXT_0, EXT_1, ... when
updating or referring to a specific dispatch extension byte. updating or referring to a specific dispatch extension byte.
Amendments that require an exchange of configurational parameters Amendments that require an exchange of configurational parameters
between devices SHOULD use manifests to encode structured data in a between devices SHOULD use manifests to encode structured data in a
well-defined format, as, e.g., outlined in [I-D.irtf-icnrg-flic]. well-defined format, e.g., as outlined in [ICNRG-FLIC].
4.2. Adaptation Layer Fragmentation 4.2. Adaptation-Layer Fragmentation
Small payload sizes in the LoWPAN require fragmentation for various Small payload sizes in the LoWPAN require fragmentation for various
network layers. Therefore, Section 5.3 of [RFC4944] defines a network layers. Therefore, Section 5.3 of [RFC4944] defines a
protocol-independent fragmentation dispatch type, a fragmentation protocol-independent fragmentation dispatch type, a fragmentation
header for the first fragment, and a separate fragmentation header header for the first fragment, and a separate fragmentation header
for subsequent fragments. ICN LoWPAN adopts this fragmentation for subsequent fragments. ICN LoWPAN adopts this fragmentation
handling of [RFC4944]. handling of [RFC4944].
The Fragmentation LoWPAN header can encapsulate other dispatch The fragmentation LoWPAN header can encapsulate other dispatch
headers. The order of dispatch types is defined in Section 5 of headers. The order of dispatch types is defined in Section 5 of
[RFC4944]. Figure 8 shows the fragmentation scheme. The reassembled [RFC4944]. Figure 8 shows the fragmentation scheme. The reassembled
ICN LoWPAN frame does not contain any fragmentation headers and is ICN LoWPAN frame does not contain any fragmentation headers and is
depicted in Figure 9. depicted in Figure 9.
+------...------+----...----+--------+------...-------+--------... +------...------+----...----+--------+------...-------+--------...
| IEEE 802.15.4 | Frag. 1st | Page | ICN LoWPAN | Payload / | IEEE 802.15.4 | Frag. 1st | Page | ICN LoWPAN | Payload /
+------...------+----...----+--------+------...-------+--------... +------...------+----...----+--------+------...-------+--------...
+------...------+----...----+--------... +------...------+----...----+--------...
skipping to change at page 11, line 21 skipping to change at page 14, line ?
+------...------+----...----+--------... +------...------+----...----+--------...
. .
. .
. .
+------...------+----...----+--------... +------...------+----...----+--------...
| IEEE 802.15.4 | Frag. Nth | Payload / | IEEE 802.15.4 | Frag. Nth | Payload /
+------...------+----...----+--------... +------...------+----...----+--------...
Figure 8: Fragmentation scheme Figure 8: Fragmentation Scheme
+------...------+--------+------...-------+--------... +------...------+--------+------...-------+--------...
| IEEE 802.15.4 | Page | ICN LoWPAN | Payload / | IEEE 802.15.4 | Page | ICN LoWPAN | Payload /
+------...------+--------+------...-------+--------... +------...------+--------+------...-------+--------...
Figure 9: Reassembled ICN LoWPAN frame Figure 9: Reassembled ICN LoWPAN Frame
The 6LoWPAN Fragment Forwarding (6FF) [RFC8930] is an alternative The 6LoWPAN Fragment Forwarding (6LFF) [RFC8930] is an alternative
approach that enables forwarding of fragments without reassembling approach that enables forwarding of fragments without reassembling
packets on every intermediate hop. By reusing the 6LoWPAN packets on every intermediate hop. By reusing the 6LoWPAN
dispatching framework, 6FF integrates into ICN LoWPAN as seamless as dispatching framework, 6LFF integrates into ICN LoWPAN as seamlessly
the conventional hop-wise fragmentation. Experimental evaluations as the conventional hop-wise fragmentation. However, experimental
[SFR-ICNLOWPAN], however, suggest that a more refined integration can evaluations [SFR-ICNLOWPAN] suggest that a more-refined integration
increase the cache utilization of forwarders on a request path. can increase the cache utilization of forwarders on a request path.
5. Space-efficient Message Encoding for NDN 5. Space-Efficient Message Encoding for NDN
5.1. TLV Encoding 5.1. TLV Encoding
The NDN packet format consists of TLV fields using the TLV encoding The NDN packet format consists of TLV fields using the TLV encoding
that is described in [NDN-PACKET-SPEC]. Type and length fields are that is described in [NDN-PACKET-SPEC]. Type and Length fields are
of variable size, where numbers greater than 252 are encoded using of variable size, where numbers greater than 252 are encoded using
multiple bytes. multiple bytes.
If the type or length number is less than "253", then that number is If the type or length number is less than 253, then that number is
encoded into the actual type or length field. If the number is encoded into the actual Type or Length field. If the number is
greater or equals "253" and fits into 2 bytes, then the type or greater or equals 253 and fits into 2 bytes, then the Type or Length
length field is set to "253" and the number is encoded in the next field is set to 253 and the number is encoded in the next following 2
following 2 bytes in network byte order, i.e., from the most bytes in network byte order, i.e., from the most significant byte
significant byte (MSB) to the least significant byte (LSB). If the (MSB) to the least significant byte (LSB). If the number is greater
number is greater than 2 bytes and fits into 4 bytes, then the type than 2 bytes and fits into 4 bytes, then the Type or Length field is
or length field is set to "254" and the number is encoded in the set to 254 and the number is encoded in the subsequent 4 bytes in
subsequent 4 bytes in network byte order. For larger numbers, the network byte order. For larger numbers, the Type or Length field is
type or length field is set to "255" and the number is encoded in the set to 255 and the number is encoded in the subsequent 8 bytes in
subsequent 8 bytes in network byte order. network byte order.
In this specification, compressed NDN TLVs encode type and length In this specification, compressed NDN TLVs encode Type and Length
fields using self-delimiting numeric values (SDNVs) [RFC6256] fields using self-delimiting numeric values (SDNVs) [RFC6256]
commonly known from DTN protocols. Instead of using the first byte commonly known from Delay-Tolerant Networking (DTN) protocols.
as a marker for the number of following bytes, SDNVs use a single bit Instead of using the first byte as a marker for the number of
to indicate subsequent bytes. following bytes, SDNVs use a single bit to indicate subsequent bytes.
+----------+-----------------------------+--------------------------+ +==========+==========================+==========================+
| Value | NDN TLV encoding | SDNV encoding | | Value | NDN TLV Encoding | SDNV Encoding |
+----------+-----------------------------+--------------------------+ +==========+==========================+==========================+
| 0 | 0x00 | 0x00 | | 0 | 0x00 | 0x00 |
| 127 | 0x7F | 0x7F | +----------+--------------------------+--------------------------+
| 128 | 0x80 | 0x81 0x00 | | 127 | 0x7F | 0x7F |
| 253 | 0xFD 0x00 0xFD | 0x81 0x7D | +----------+--------------------------+--------------------------+
| 2^14 - 1 | 0xFD 0x3F 0xFF | 0xFF 0x7F | | 128 | 0x80 | 0x81 0x00 |
| 2^14 | 0xFD 0x40 0x00 | 0x81 0x80 0x00 | +----------+--------------------------+--------------------------+
| 2^16 | 0xFE 0x00 0x01 0x00 0x00 | 0x84 0x80 0x00 | | 253 | 0xFD 0x00 0xFD | 0x81 0x7D |
| 2^21 - 1 | 0xFE 0x00 0x1F 0xFF 0xFF | 0xFF 0xFF 0x7F | +----------+--------------------------+--------------------------+
| 2^21 | 0xFE 0x00 0x20 0x00 0x00 | 0x81 0x80 0x80 0x00 | | 2^14 - 1 | 0xFD 0x3F 0xFF | 0xFF 0x7F |
| 2^28 - 1 | 0xFE 0x0F 0xFF 0xFF 0xFF | 0xFF 0xFF 0xFF 0x7F | +----------+--------------------------+--------------------------+
| 2^28 | 0xFE 0x1F 0x00 0x00 0x00 | 0x81 0x80 0x80 0x80 0x00 | | 2^14 | 0xFD 0x40 0x00 | 0x81 0x80 0x00 |
| 2^32 | 0xFF 0x00 0x00 0x00 0x01 | 0x90 0x80 0x80 0x80 0x00 | +----------+--------------------------+--------------------------+
| | 0x00 0x00 0x00 0x00 | | | 2^16 | 0xFE 0x00 0x01 0x00 0x00 | 0x84 0x80 0x00 |
| 2^35 - 1 | 0xFF 0x00 0x00 0x00 0x07 | 0xFF 0xFF 0xFF 0xFF 0x7F | +----------+--------------------------+--------------------------+
| | 0xFF 0xFF 0xFF 0xFF | | | 2^21 - 1 | 0xFE 0x00 0x1F 0xFF 0xFF | 0xFF 0xFF 0x7F |
| 2^35 | 0xFF 0x00 0x00 0x00 0x08 | 0x81 0x80 0x80 0x80 0x80 | +----------+--------------------------+--------------------------+
| | 0x00 0x00 0x00 0x00 | 0x00 | | 2^21 | 0xFE 0x00 0x20 0x00 0x00 | 0x81 0x80 0x80 0x00 |
+----------+-----------------------------+--------------------------+ +----------+--------------------------+--------------------------+
| 2^28 - 1 | 0xFE 0x0F 0xFF 0xFF 0xFF | 0xFF 0xFF 0xFF 0x7F |
+----------+--------------------------+--------------------------+
| 2^28 | 0xFE 0x1F 0x00 0x00 0x00 | 0x81 0x80 0x80 0x80 0x00 |
+----------+--------------------------+--------------------------+
| 2^32 | 0xFF 0x00 0x00 0x00 0x01 | 0x90 0x80 0x80 0x80 0x00 |
| | 0x00 0x00 0x00 0x00 | |
+----------+--------------------------+--------------------------+
| 2^35 - 1 | 0xFF 0x00 0x00 0x00 0x07 | 0xFF 0xFF 0xFF 0xFF 0x7F |
| | 0xFF 0xFF 0xFF 0xFF | |
+----------+--------------------------+--------------------------+
| 2^35 | 0xFF 0x00 0x00 0x00 0x08 | 0x81 0x80 0x80 0x80 0x80 |
| | 0x00 0x00 0x00 0x00 | 0x00 |
+----------+--------------------------+--------------------------+
Table 1: NDN TLV encoding compared to SDNVs. Table 1: NDN TLV Encoding Compared to SDNVs
Table 1 compares the required bytes for encoding a few selected Table 1 compares the required bytes for encoding a few selected
values using the NDN TLV encoding and SDNVs. For values up to 127, values using the NDN TLV encoding and SDNVs. For values up to 127,
both methods require a single byte. Values in the range [128;252] both methods require a single byte. Values in the range [128;252]
encode as one byte for the NDN TLV scheme, while SDNVs require two encode as one byte for the NDN TLV scheme, while SDNVs require two
bytes. Starting at value 253, SDNVs require a less or equal amount bytes. Starting at value 253, SDNVs require a less or equal amount
of bytes compared to the NDN TLV encoding. of bytes compared to the NDN TLV encoding.
5.2. Name TLV Compression 5.2. Name TLV Compression
This Name TLV compression encodes length fields of two consecutive This Name TLV compression encodes Length fields of two consecutive
NameComponent TLVs into one byte, using a nibble for each. The most NameComponent TLVs into one byte, using a nibble for each. The most
significant nibble indicates the length of an immediately following significant nibble indicates the length of an immediately following
NameComponent TLV. The least significant nibble denotes the length NameComponent TLV. The least significant nibble denotes the length
of a subsequent NameComponent TLV. A length of 0 marks the end of of a subsequent NameComponent TLV. A length of 0 marks the end of
the compressed Name TLV. The last length field of an encoded the compressed Name TLV. The last Length field of an encoded
NameComponent is either 0x00 for a name with an even number of NameComponent is either 0x00 for a name with an even number of
components, and 0xYF (Y > 0) if an odd number of components are components and 0xYF (Y > 0) if an odd number of components are
present. This process limits the length of a NameComponent TLV to 15 present. This process limits the length of a NameComponent TLV to 15
bytes, but allows for an unlimited number of components. An example bytes but allows for an unlimited number of components. An example
for this encoding is presented in Figure 10. for this encoding is presented in Figure 10.
Name: /HAW/Room/481/Humid/99 Name: /HAW/Room/481/Humid/99
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 1|0 1 0 0| H | A | W | |0 0 1 1|0 1 0 0| H | A | W |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R | o | o | m | | R | o | o | m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 1|0 1 0 1| 4 | 8 | 1 | |0 0 1 1|0 1 0 1| 4 | 8 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H | u | m | i | | H | u | m | i |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d |0 0 1 0|0 0 0 0| 9 | 9 | | d |0 0 1 0|0 0 0 0| 9 | 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Name TLV compression for /HAW/Room/481/Humid/99 Figure 10: Name TLV Compression for /HAW/Room/481/Humid/99
5.3. Interest Messages 5.3. Interest Messages
5.3.1. Uncompressed Interest Messages 5.3.1. Uncompressed Interest Messages
An uncompressed Interest message uses the base dispatch format (see An uncompressed Interest message uses the base dispatch format (see
Figure 4) and sets the C flag to "0" and the P as well as the M flag Figure 4) and sets the C, P, and M flags to 0 (Figure 11). The
to "0" (Figure 11). The Interest message is handed to the NDN Interest message is handed to the NDN network stack without
network stack without modifications. modifications.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
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", the P flag to "0" and the M (Figure 5) and sets the C flag to 1 and the P and M flags to 0. If
flag to "0". If an Interest message contains TLVs that are not an Interest message contains TLVs that are not mentioned in the
mentioned in the following compression rules, then this message MUST following compression rules, then this message MUST be sent
be sent uncompressed. uncompressed.
This specification assumes that a HopLimit TLV is part of the This specification assumes that a HopLimit TLV is part of the
original Interest message. If such HopLimit TLV is not present, it original Interest message. If such a HopLimit TLV is not present, it
will be inserted with a default value of DEFAULT_NDN_HOPLIMIT prior will be inserted with a default value of DEFAULT_NDN_HOPLIMIT prior
to the compression. to the compression.
In the default use case, the Interest message is compressed with the In the default use case, the Interest message is compressed with the
following minimal rule set: 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 with a length greater than 0. An GenericNameComponent with a length greater than 0. An
ImplicitSha256DigestComponent or ParametersSha256DigestComponent ImplicitSha256DigestComponent or ParametersSha256DigestComponent
MAY appear at the end of the name. In any other case, the MAY appear at the end of the name. In any other case, the
message MUST be sent uncompressed. message MUST be sent uncompressed.
3. The Nonce TLV and InterestLifetime TLV are moved to the end of 3. The Nonce TLV and InterestLifetime TLV are moved to the end of
the compressed Interest as illustrated in Figure 12. The the compressed Interest, as illustrated in Figure 12. The
InterestLifetime is encoded as described in Section 7. On InterestLifetime is encoded as described in Section 7. On
decompression, this encoding may yield an Interestlifetime that decompression, this encoding may yield an InterestLifetime that
is smaller than the original value. is smaller than the original value.
4. The Type and Length fields of Nonce TLV, HopLimit TLV and 4. The Type and Length fields of Nonce TLV, HopLimit TLV, and
InterestLifetime TLV are elided. The Nonce value has a length of InterestLifetime TLV are elided. The Nonce value has a length of
4 bytes and the HopLimit value has a length of 1 byte. The 4 bytes, and the HopLimit value has a length of 1 byte. The
compressed InterestLifetime (Section 7) has a length of 1 byte. compressed InterestLifetime (Section 7) has a length of 1 byte.
The presence of a Nonce and InterestLifetime TLV is deduced from The presence of a Nonce TLV and InterestLifetime TLV is deduced
the remaining length to parse. A remaining length of "1" from the remaining length to parse. A remaining length of 1
indicates the presence of an InerestLifetime, a length of "4" indicates the presence of an InterestLifetime, a length of 4
indicates the presence of a nonce, and a length of "5" indicates indicates the presence of a nonce, and a length of 5 indicates
the presence of both TLVs. the presence of both TLVs.
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
Lc = Compressed Length, Vc = Compressed Value Lc = Compressed Length, Vc = Compressed Value
: = optional field, | = mandatory field : = optional field, | = mandatory field
+---------+---------+ +---------+ +---------+---------+ +---------+
skipping to change at page 15, line 37 skipping to change at page 14, line ?
+---------+---------+---------+ +---------+---------+---------+
Figure 12: Compression of 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 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 | 0 |CID|EXT|PFX|FRE|FWD|APM|DIG| RSV | | 0 | 0 | 0 | 1 |PFX|FRE|FWD|APM|DIG| RSV |CID|EXT|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 13: Dispatch format for compressed NDN Interest messages Figure 13: Dispatch Format for Compressed NDN Interest Messages
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.
PFX: CanBePrefix TLV PFX: CanBePrefix TLV
0: The uncompressed message does not include a 0: The uncompressed message does not include a CanBePrefix TLV.
CanBePrefix TLV.
1: The uncompressed message does include a CanBePrefix 1: The uncompressed message does include a CanBePrefix TLV and
TLV and is removed from the compressed message. is removed from the compressed message.
FRE: MustBeFresh TLV FRE: MustBeFresh TLV
0: The uncompressed message does not include a MustBeFresh TLV.
0: The uncompressed message does not include a 1: The uncompressed message does include a MustBeFresh TLV and
MustBeFresh TLV. is removed from the compressed message.
1: The uncompressed message does include a MustBeFresh
TLV and is removed from the compressed message.
FWD: ForwardingHint TLV FWD: ForwardingHint TLV
0: The uncompressed message does not include a ForwardingHint
TLV.
0: The uncompressed message does not include a 1: The uncompressed message does include a ForwardingHint TLV.
ForwardingHint TLV. The Type field is removed from the compressed message.
Further, all link delegation types and link preference types
1: The uncompressed message does include a are removed. All included names are compressed according to
ForwardingHint TLV. The Type field is removed from Section 5.2. If any name is not compressible, the message
the compressed message. Further, all link delegation MUST be sent uncompressed.
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 APM: ApplicationParameters TLV
0: The uncompressed message does not include an
ApplicationParameters TLV.
0: The uncompressed message does not include an 1: The uncompressed message does include an
ApplicationParameters TLV. ApplicationParameters TLV. The Type field is removed from
the compressed message.
1: The uncompressed message does include an
ApplicationParameters TLV. The Type field is removed
from the compressed message.
DIG: ImplicitSha256DigestComponent TLV DIG: ImplicitSha256DigestComponent TLV
0: The name does not include an ImplicitSha256DigestComponent as
the last TLV.
0: The name does not include an 1: The name does include an ImplicitSha256DigestComponent as the
ImplicitSha256DigestComponent as the last TLV. last TLV. The Type and Length fields are omitted.
1: The name does include an RSV: Reserved
ImplicitSha256DigestComponent as the last TLV. The Must be set to 0.
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.
5.3.3. Dispatch Extension 5.3.3. Dispatch Extension
The "EXT_0" byte follows the description in Section 4.1.1 and is The EXT_0 byte follows the description in Section 4.1.1 and is
illustrated in Figure 14. illustrated in Figure 14.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| NCS | RSV |EXT| | NCS | RSV |EXT|
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 14: EXT_0 format Figure 14: EXT_0 Format
NCS: Name Compression Strategy NCS: Name Compression Strategy
00: Names are compressed with the default name compression
strategy (see Section 5.2).
00: Names are compressed with the default name 01: Reserved.
compression strategy (see Section 5.2).
01: Reserved.
10: Reserved. 10: Reserved.
11: Reserved. 11: Reserved.
RSV: Reserved Must be set to 0. RSV: Reserved
Must be set to 0.
EXT: Extension EXT: Extension
0: No extension byte follows.
0: No extension byte follows. 1: A further extension byte follows immediately.
1: A further extension byte follows immediately.
5.4. Data Messages 5.4. Data Messages
5.4.1. Uncompressed Data Messages 5.4.1. Uncompressed Data Messages
An uncompressed Data message uses the base dispatch format and sets An uncompressed Data message uses the base dispatch format and sets
the C flag to "0", the P flag to "0" and the M flag to "1" the C and P flags to 0 and the M flag to 1 (Figure 15). The Data
(Figure 15). The Data message is handed to the NDN network stack message is handed to the NDN network stack without modifications.
without modifications.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 15: Dispatch format for uncompressed NDN Data messages Figure 15: Dispatch Format for Uncompressed NDN Data Messages
5.4.2. Compressed Data Messages 5.4.2. Compressed Data Messages
The compressed Data message uses the extended dispatch format The compressed Data message uses the extended dispatch format
(Figure 5) and sets the C as well as the M flags to "1". The P flag (Figure 5) and sets the C and M flags to 1. The P flag is set to 0.
is set to "0". If a Data message contains TLVs that are not If a Data message contains TLVs that are not mentioned in the
mentioned in the following compression rules, then this message MUST following compression rules, then this message MUST be sent
be sent uncompressed. uncompressed.
By default, the Data message is compressed with the following base By default, the Data message is compressed with the following base
rule set: 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 and to have a length greater than 0. In any GenericNameComponent and to have a length greater than 0. In any
other case, the message MUST be sent uncompressed. other case, the message MUST be sent uncompressed.
3. The MetaInfo TLV Type and Length fields are elided from the 3. The MetaInfo TLV Type and Length fields are elided from the
compressed Data message. compressed Data message.
4. The FreshnessPeriod TLV MUST be moved to the end of the 4. The FreshnessPeriod TLV MUST be moved to the end of the
compressed Data message. Type and Length fields are elided and compressed Data message. Type and Length fields are elided, and
the value is encoded as described in Section 7 as a 1-byte time- 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 code. If the freshness period is not a valid time-value, then
the message MUST be sent uncompressed in order to preserve the the message MUST be sent uncompressed in order to preserve the
security envelope of the Data message. The presence of a security envelope of the Data message. The presence of a
FreshnessPeriod TLV is deduced from the remaining one byte length FreshnessPeriod TLV is deduced from the remaining one-byte length
to parse. to parse.
5. The Type fields of the SignatureInfo TLV, SignatureType TLV and 5. The Type fields of the SignatureInfo TLV, SignatureType TLV, and
SignatureValue TLV are removed. SignatureValue TLV are removed.
The compressed NDN LoWPAN Data message is visualized in Figure 16. The compressed NDN LoWPAN Data message is visualized in Figure 16.
T = Type, L = Length, V = Value T = Type, L = Length, V = Value
Lc = Compressed Length, Vc = Compressed Value Lc = Compressed Length, Vc = Compressed Value
: = optional field, | = mandatory field : = optional field, | = mandatory field
+---------+---------+ +---------+ +---------+---------+ +---------+
| Msg T | Msg L | | Msg Lc | | Msg T | Msg L | | Msg Lc |
skipping to change at page 19, line 39 skipping to change at page 14, line ?
+---------+---------+---------+ +---------+---------+---------+
Figure 16: Compression of NDN LoWPAN Data Message Figure 16: 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 17. Figure 17.
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 | 1 |CID|EXT|FBI|CON|KLO| RSV | | 0 | 0 | 1 | 1 |FBI|CON|KLO| RSV |CID|EXT|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 17: Dispatch format for compressed NDN Data messages Figure 17: Dispatch Format for Compressed NDN Data Messages
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.
FBI: FinalBlockId TLV FBI: FinalBlockId TLV
0: The uncompressed message does not include a FinalBlockId TLV.
0: The uncompressed message does not include a 1: The uncompressed message does include a FinalBlockId, and it
FinalBlockId TLV. is encoded according to Section 5.2. If the FinalBlockId TLV
is not compressible, then the message MUST be sent
1: The uncompressed message does include a FinalBlockId uncompressed.
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 CON: ContentType TLV
0: The uncompressed message does not include a ContentType TLV.
0: The uncompressed message does not include a 1: The uncompressed message does include a ContentType TLV. The
ContentType TLV. Type field is removed from the compressed message.
1: The uncompressed message does include a ContentType
TLV. The Type field is removed from the compressed
message.
KLO: KeyLocator TLV 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.
0: If the included SignatureType requires a KeyLocator 1: If the included SignatureType requires a KeyLocator TLV, then
TLV, then the KeyLocator represents a name and is the KeyLocator represents a KeyDigest. The Type field of
compressed according to Section 5.2. If the name is this KeyDigest is removed.
not compressible, then the message MUST be sent
uncompressed.
1: If the included SignatureType requires a KeyLocator RSV: Reserved
TLV, then the KeyLocator represents a KeyDigest. The Must be set to 0.
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.
5.4.3. Dispatch Extension 5.4.3. Dispatch Extension
The "EXT_0" byte follows the description in Section 4.1.1 and is The EXT_0 byte follows the description in Section 4.1.1 and is
illustrated in Figure 18. illustrated in Figure 18.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| NCS | RSV |EXT| | NCS | RSV |EXT|
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 18: EXT_0 format Figure 18: EXT_0 Format
NCS: Name Compression Strategy NCS: Name Compression Strategy
00: Names are compressed with the default name 00: Names are compressed with the default name compression
compression strategy (see Section 5.2). strategy (see Section 5.2).
01: Reserved. 01: Reserved.
10: Reserved. 10: Reserved.
11: Reserved. 11: Reserved.
RSV: Reserved Must be set to 0. RSV: Reserved
Must be set to 0.
EXT: Extension EXT: Extension
0: No extension byte follows.
0: No extension byte follows. 1: A further extension byte follows immediately.
1: A further extension byte follows immediately.
6. Space-efficient Message Encoding for CCNx 6. Space-Efficient Message Encoding for CCNx
6.1. TLV Encoding 6.1. TLV Encoding
The generic CCNx TLV encoding is described in [RFC8609]. Type and The generic CCNx TLV encoding is described in [RFC8609]. Type and
Length fields attain the common fixed length of 2 bytes. Length fields attain the common fixed length of 2 bytes.
The TLV encoding for CCNx LoWPAN is changed to the more space The TLV encoding for CCNx LoWPAN is changed to the more space-
efficient encoding described in Section 5.1. Hence NDN and CCNx use efficient encoding described in Section 5.1. Hence, NDN and CCNx use
the same compressed format for writing TLVs. the same compressed format for writing TLVs.
6.2. Name TLV Compression 6.2. Name TLV Compression
Name TLVs are compressed using the scheme already defined in Name TLVs are compressed using the scheme already defined in
Section 5.2 for NDN. If a Name TLV contains T_IPID, T_APP, or Section 5.2 for NDN. If a Name TLV contains T_IPID, T_APP, or
organizational TLVs, then the name remains uncompressed. organizational TLVs, then the name remains uncompressed.
6.3. Interest Messages 6.3. Interest Messages
6.3.1. Uncompressed Interest Messages 6.3.1. Uncompressed Interest Messages
An uncompressed Interest message uses the base dispatch format (see An uncompressed Interest message uses the base dispatch format (see
Figure 4) and sets the C as well as the M flag to "0". The P flag is Figure 4) and sets the C and M flags to 0. The P flag is set to 1
set to "1" (Figure 19). The Interest message is handed to the CCNx (Figure 19). The Interest message is handed to the CCNx network
network stack without modifications. stack without modifications.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 19: Dispatch format for uncompressed CCNx Interest messages Figure 19: Dispatch Format for Uncompressed CCNx Interest Messages
6.3.2. Compressed Interest Messages 6.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 and P flags to "1". The M flag is set to (Figure 5) and sets the C and P flags to 1. The M flag is set to 0.
"0". If an Interest message contains TLVs that are not mentioned in If an Interest message contains TLVs that are not mentioned in the
the following compression rules, then this message MUST be sent following compression rules, then this message MUST be sent
uncompressed. uncompressed.
In the default use case, the Interest message is compressed with the In the default use case, the Interest message is compressed with the
following minimal rule set: following minimal rule set:
1. The Type and Length fields of the CCNx Message TLV are elided and 1. The version is elided from the fixed header and assumed to be 1.
are obtained from the Fixed Header on decompression.
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 Interest message is visualized in The compressed CCNx LoWPAN Interest message is visualized in
Figure 20. Figure 20.
T = Type, L = Length, V = Value T = Type, L = Length, V = Value
Lc = Compressed Length, Vc = Compressed Value Lc = Compressed Length, Vc = Compressed Value
: = optional field, | = mandatory field : = optional field, | = mandatory field
+-----------------------------+ +-------------------------+ +-----------------------------+ +-------------------------+
| Uncompr. Fixed Header | | Compr. Fixed Header | | Uncompr. Fixed Header | | Compr. Fixed Header |
skipping to change at page 23, line 33 skipping to change at page 14, line ?
+---------+---------+---------+ +---------+---------+ +---------+---------+---------+ +---------+---------+
: OBHR T : OBHR L : OBHR V : : PAYL Lc : PAYL V : : OBHR T : OBHR L : OBHR V : : PAYL Lc : PAYL V :
+---------+---------+---------+ +---------+---------+ +---------+---------+---------+ +---------+---------+
: PAYL T : PAYL L : PAYL V : : VALG Lc : VALG Vc : : PAYL T : PAYL L : PAYL V : : VALG Lc : VALG Vc :
+---------+---------+---------+ +---------+---------+ +---------+---------+---------+ +---------+---------+
: VALG T : VALG L : VALG V : : VPAY Lc : VPAY V : : VALG T : VALG L : VALG V : : VPAY Lc : VPAY V :
+---------+---------+---------+ +---------+---------+ +---------+---------+---------+ +---------+---------+
: VPAY T : VPAY L : VPAY V : : VPAY T : VPAY L : VPAY V :
+---------+---------+---------+ +---------+---------+---------+
Figure 20: Compression of CCNx LoWPAN Interest Message Figure 20: 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 21. Figure 21.
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 | 0 |CID|EXT|VER|FLG|PTY|HPL|FRS|PAY|ILT|MGH|KIR|CHR|VAL| | 0 | 1 | 0 | 1 |FLG|PTY|HPL|FRS|PAY|ILT|MGH|KIR|CHR|VAL|CID|EXT|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 21: Dispatch format for compressed CCNx Interest messages Figure 21: Dispatch Format for Compressed CCNx Interest Messages
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.
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 appears in the fixed header.
FLG: Flags field in the fixed header FLG: Flags field in the fixed header
0: The Flags field equals 0 and is removed from the Interest
message.
0: The Flags field equals 0 and is removed from the Interest 1: The Flags field appears in the fixed header.
message.
1: The Flags field appears in the fixed header.
PTY: PacketType field in the fixed header PTY: PacketType field in the fixed header
0: The PacketType field is elided and assumed to be PT_INTEREST.
0: The PacketType field is elided and assumed to be 1: The PacketType field is elided and assumed to be PT_RETURN.
"PT_INTEREST".
1: The PacketType field is elided and assumed to be
"PT_RETURN".
HPL: HopLimit field in the fixed header HPL: HopLimit field in the fixed header
0: The HopLimit field appears in the fixed header.
0: The HopLimit field appears in the fixed header. 1: The HopLimit field is elided and assumed to be 1.
1: The HopLimit field is elided and assumed to be "1".
FRS: Reserved field in the fixed header FRS: Reserved field in the fixed header
0: The Reserved field appears in the fixed header.
0: The Reserved field appears in the fixed header. 1: The Reserved field is elided and assumed to be 0.
1: The Reserved field is elided and assumed to be "0".
PAY: Optional Payload TLV PAY: Optional Payload TLV
0: The Payload TLV is absent.
0: The Payload TLV is absent. 1: The Payload TLV is present, and the Type field is elided.
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 ILT: Optional hop-by-hop InterestLifetime TLV
message. See Section 6.3.2.1 for further details on the ordering of hop-
by-hop TLVs.
1: An InterestLifetime TLV is present with a fixed length of 0: No InterestLifetime TLV is present in the Interest message.
1 byte and is encoded as described in Section 7. The
type and length fields are elided.
MGH: Optional Hop-By-Hop MessageHash TLV 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.
See Section 6.3.2.1 for further details on the ordering MGH: Optional hop-by-hop MessageHash TLV
of hop-by-hop TLVs. 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 This TLV is expected to contain a T_SHA-256 TLV. If another hash
another hash is contained, then the Interest MUST be sent is contained, then the Interest MUST be sent uncompressed.
uncompressed.
0: The MessageHash TLV is absent. 0: The MessageHash TLV is absent.
1: A T_SHA-256 TLV is present and the type as well as the 1: A T_SHA-256 TLV is present, and the Type and Length fields
length fields are removed. The length field is assumed are removed. The Length field is assumed to represent 32
to represent 32 bytes. The outer Message Hash TLV is bytes. The outer Message Hash TLV is omitted.
omitted.
KIR: Optional KeyIdRestriction TLV 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.
This TLV is expected to contain a T_SHA-256 TLV. If 0: The KeyIdRestriction TLV is absent.
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 1: A T_SHA-256 TLV is present, and the Type and Length fields
length fields are removed. The length field is assumed are removed. The Length field is assumed to represent 32
to represent 32 bytes. The outer KeyIdRestriction TLV is bytes. The outer KeyIdRestriction TLV is omitted.
omitted.
CHR: Optional ContentObjectHashRestriction TLV 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.
This TLV is expected to contain a T_SHA-256 TLV. If 0: The ContentObjectHashRestriction TLV is absent.
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 1: A T_SHA-256 TLV is present, and the Type and Length fields
length fields are removed. The length field is assumed are removed. The Length field is assumed to represent 32
to represent 32 bytes. The outer bytes. The outer ContentObjectHashRestriction TLV is
ContentObjectHashRestriction TLV is omitted. omitted.
VAL: Optional ValidationAlgorithm and ValidationPayload TLVs VAL: Optional ValidationAlgorithm and ValidationPayload TLVs
0: No validation-related TLVs are present in the Interest
message.
0: No validation related TLVs are present in the Interest 1: Validation-related TLVs are present in the Interest message.
message. An additional byte follows immediately that handles
validation-related TLV compressions and is described in
Section 6.3.2.2.
1: Validation related TLVs are present in the Interest CID: Context Identifier
message. An additional byte follows immediately that See Figure 5.
handles validation related TLV compressions and is
described in Section 6.3.2.2. EXT: Extension
0: No extension byte follows.
1: Extension byte EXT_0 follows immediately. See Section 6.3.3.
6.3.2.1. Hop-By-Hop Header TLVs Compression 6.3.2.1. Hop-By-Hop Header TLVs Compression
Hop-By-Hop Header TLVs are unordered. For an Interest message, two Hop-by-hop header TLVs are unordered. For an Interest message, two
optional Hop-By-Hop Header TLVs are defined in [RFC8609], but several optional hop-by-hop header TLVs are defined in [RFC8609], but several
more can be defined in higher level specifications. For the more can be defined in higher-level specifications. For the
compression specified in the previous section, the Hop-By-Hop TLVs compression specified in the previous section, the hop-by-hop TLVs
are ordered as follows: are ordered as follows:
1. Interest Lifetime TLV 1. InterestLifetime TLV
2. Message Hash TLV 2. Message Hash TLV
Note: Other Hop-By-Hop Header TLVs than those two remain uncompressed Note: Other hop-by-hop header TLVs than those two remain uncompressed
in the encoded message and they appear in the same order as in the in the encoded message, and they appear in the same order as in the
original message, but after the Interest Lifetime TLV and Message original message but after the InterestLifetime TLV and Message Hash
Hash TLV. TLV.
6.3.2.2. Validation 6.3.2.2. Validation
0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
| ValidationAlg | KeyID | RSV | | ValidationAlg | KeyID | RSV |
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
Figure 22: Dispatch for Interset Validations Figure 22: Dispatch for Interest Validations
ValidationALg: Optional ValidationAlgorithm TLV
ValidationAlg: Optional ValidationAlgorithm TLV
0000: An uncompressed ValidationAlgorithm TLV is included. 0000: An uncompressed ValidationAlgorithm TLV is included.
0001: A T_CRC32C ValidationAlgorithm TLV is assumed, but no 0001: A T_CRC32C ValidationAlgorithm TLV is assumed, but no
ValidationAlgorithm TLV is included. ValidationAlgorithm TLV is included.
0010: A T_CRC32C ValidationAlgorithm TLV is assumed, but no 0010: A T_CRC32C ValidationAlgorithm TLV is assumed, but no
ValidationAlgorithm TLV is included. Additionally, a ValidationAlgorithm TLV is included. Additionally, a
Sigtime TLV is inlined without a type and a length field. Sigtime TLV is inlined without a Type and a Length field.
0011: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but 0011: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but
no ValidationAlgorithm TLV is included. no ValidationAlgorithm TLV is included.
0100: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but 0100: A T_HMAC-SHA256 ValidationAlgorithm TLV is assumed, but
no ValidationAlgorithm TLV is included. Additionally, a no ValidationAlgorithm TLV is included. Additionally, a
Sigtime TLV is inlined without a type and a length field. Sigtime TLV is inlined without a Type and a Length field.
0101: Reserved. 0101: Reserved.
0110: Reserved. 0110: Reserved.
0111: Reserved. 0111: Reserved.
1000: Reserved. 1000: Reserved.
1001: Reserved. 1001: Reserved.
skipping to change at page 27, line 35 skipping to change at page 14, line ?
1100: Reserved. 1100: Reserved.
1101: Reserved. 1101: Reserved.
1110: Reserved. 1110: Reserved.
1111: Reserved. 1111: Reserved.
KeyID: Optional KeyID TLV within the ValidationAlgorithm TLV KeyID: Optional KeyID TLV within the ValidationAlgorithm TLV
00: The KeyID TLV is absent.
00: The KeyId TLV is absent. 01: The KeyID TLV is present and uncompressed.
01: The KeyId TLV is present and uncompressed.
10: A T_SHA-256 TLV is present and the type field as well as 10: A T_SHA-256 TLV is present, and the Type and Length fields
the length fields are removed. The length field is are removed. The Length field is assumed to represent 32
assumed to represent 32 bytes. The outer KeyId TLV is bytes. The outer KeyID TLV is omitted.
omitted.
11: A T_SHA-512 TLV is present and the type field as well as 11: A T_SHA-512 TLV is present, and the Type and Length fields
the length fields are removed. The length field is are removed. The Length field is assumed to represent 64
assumed to represent 64 bytes. The outer KeyId TLV is bytes. The outer KeyID TLV is omitted.
omitted.
RSV: Reserved Must be set to 0. RSV: Reserved
Must be set to 0.
The ValidationPayload TLV is present if the ValidationAlgorithm TLV The ValidationPayload TLV is present if the ValidationAlgorithm TLV
is present. The type field is omitted. is present. The Type field is omitted.
6.3.3. Dispatch Extension 6.3.3. Dispatch Extension
The "EXT_0" byte follows the description in Section 4.1.1 and is The EXT_0 byte follows the description in Section 4.1.1 and is
illustrated in Figure 23. illustrated in Figure 23.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| NCS | RSV |EXT| | NCS | RSV |EXT|
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 23: EXT_0 format Figure 23: EXT_0 Format
NCS: Name Compression Strategy NCS: Name Compression Strategy
00: Names are compressed with the default name compression
strategy (see Section 5.2).
00: Names are compressed with the default name 01: Reserved.
compression strategy (see Section 5.2).
01: Reserved.
10: Reserved. 10: Reserved.
11: Reserved. 11: Reserved.
RSV: Reserved Must be set to 0. RSV: Reserved
Must be set to 0.
EXT: Extension EXT: Extension
0: No extension byte follows.
0: No extension byte follows. 1: A further extension byte follows immediately.
1: A further extension byte follows immediately.
6.4. Content Objects 6.4. Content Objects
6.4.1. Uncompressed Content Objects 6.4.1. Uncompressed Content Objects
An uncompressed Content object uses the base dispatch format (see An uncompressed Content Object uses the base dispatch format (see
Figure 4) and sets the C flag to "0", the P and M flags to "1" Figure 4) and sets the C flag to 0 and the P and M flags to 1
(Figure 24). The Content object is handed to the CCNx network stack (Figure 24). The Content Object is handed to the CCNx network stack
without modifications. without modifications.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 24: Dispatch format for uncompressed CCNx Content objects Figure 24: Dispatch Format for Uncompressed CCNx Content Objects
6.4.2. Compressed Content Objects 6.4.2. Compressed Content Objects
The compressed Content object uses the extended dispatch format The compressed Content Object uses the extended dispatch format
(Figure 5) and sets the C, P, as well as the M flag to "1". If a (Figure 5) and sets the C, P, and M flags to 1. If a Content Object
Content object contains TLVs that are not mentioned in the following contains TLVs that are not mentioned in the following compression
compression rules, then this message MUST be sent uncompressed. rules, then this message MUST be sent uncompressed.
By default, the Content object is compressed with the following base By default, the Content Object is compressed with the following base
rule set: rule set:
1. The PacketType field is elided from the Fixed Header. 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 2. The PacketType field is elided from the fixed header.
are obtained from the Fixed Header on decompression.
3. 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 25. The compressed CCNx LoWPAN Data message is visualized in Figure 25.
T = Type, L = Length, V = Value T = Type, L = Length, V = Value
Lc = Compressed Length, Vc = Compressed Value Lc = Compressed Length, Vc = Compressed Value
: = optional field, | = mandatory field : = optional field, | = mandatory field
+-----------------------------+ +-------------------------+ +-----------------------------+ +-------------------------+
| Uncompr. Fixed Header | | Compr. Fixed Header | | Uncompr. Fixed Header | | Compr. Fixed Header |
+-----------------------------+ +-------------------------+ +-----------------------------+ +-------------------------+
skipping to change at page 30, line 33 skipping to change at page 14, line ?
+---------+---------+---------+ +---------+---------+ +---------+---------+---------+ +---------+---------+
: EXPT T : EXPT L : EXPT V : : VALG Lc : VALG Vc : : EXPT T : EXPT L : EXPT V : : VALG Lc : VALG Vc :
+---------+---------+---------+ +---------+---------+ +---------+---------+---------+ +---------+---------+
: PAYL T : PAYL L : PAYL V : : VPAY Lc : VPAY V : : PAYL T : PAYL L : PAYL V : : VPAY Lc : 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 25: Compression of CCNx LoWPAN Data Message Figure 25: 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 26. Figure 26.
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 | 1 |CID|EXT|VER|FLG|FRS|PAY|RCT|MGH| PLTYP |EXP|VAL|RSV| | 0 | 1 | 1 | 1 |FLG|FRS|PAY|RCT|MGH| PLTYP |EXP|VAL|RSV|CID|EXT|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 26: Dispatch format for compressed CCNx Content objects Figure 26: Dispatch Format for Compressed CCNx Content Objects
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.
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 appears in the fixed header.
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. FLG: Flags field in the fixed header
See Section 6.3.2.
RCT: Optional Hop-By-Hop RecommendedCacheTime TLV FRS: Reserved field in the fixed header
See Section 6.3.2.
0: The Recommended Cache Time TLV is absent. PAY: Optional Payload TLV
See Section 6.3.2.
1: The Recommended Cache Time TLV is present and the type as RCT: Optional hop-by-hop Recommended Cache Time TLV
well as the length fields are elided. 0: The Recommended Cache Time TLV is absent.
MGH: Optional Hop-By-Hop MessageHash TLV 1: The Recommended Cache Time TLV is present, and the Type and
Length fields are elided.
See Section 6.4.2.1 for further details on the ordering MGH: Optional hop-by-hop MessageHash TLV
of hop-by-hop TLVs. 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 This TLV is expected to contain a T_SHA-256 TLV. If another hash
another hash is contained, then the Content Object MUST is contained, then the Content Object MUST be sent uncompressed.
be sent uncompressed.
0: The MessageHash TLV is absent. 0: The MessageHash TLV is absent.
1: A T_SHA-256 TLV is present and the type as well as the 1: A T_SHA-256 TLV is present, and the Type and Length fields
length fields are removed. The length field is assumed are removed. The Length field is assumed to represent 32
to represent 32 bytes. The outer Message Hash TLV is bytes. The outer Message Hash TLV is omitted.
omitted.
PLTYP: Optional PayloadType TLV PLTYP: Optional PayloadType TLV
00: The PayloadType TLV is absent.
00: The PayloadType TLV is absent. 01: The PayloadType TLV is absent, and T_PAYLOADTYPE_DATA is
assumed.
01: The PayloadType TLV is absent and T_PAYLOADTYPE_DATA
is assumed.
10: The PayloadType TLV is absent and T_PAYLOADTYPE_KEY 10: The PayloadType TLV is absent, and T_PAYLOADTYPE_KEY is
is assumed. assumed.
11: The PayloadType TLV is present and uncompressed. 11: The PayloadType TLV is present and uncompressed.
EXP: Optional ExpiryTime TLV EXP: Optional ExpiryTime TLV
0: The ExpiryTime TLV is absent.
0: The ExpiryTime TLV is absent. 1: The ExpiryTime TLV is present, and the Type and Length fields
are elided.
1: The ExpiryTime TLV is present and the type as well as the VAL: Optional ValidationAlgorithm and ValidationPayload TLVs
length fields are elided. See Section 6.3.2.
VAL: Optional ValidationAlgorithm and ValidationPayload TLVs See Sec RSV: Reserved
tion 6.3.2. Must be set to 0.
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.
6.4.2.1. Hop-By-Hop Header TLVs Compression 6.4.2.1. Hop-By-Hop Header TLVs Compression
Hop-By-Hop Header TLVs are unordered. For a Content Object message, Hop-by-hop header TLVs are unordered. For a Content Object message,
two optional Hop-By-Hop Header TLVs are defined in [RFC8609], but two optional hop-by-hop header TLVs are defined in [RFC8609], but
several more can be defined in higher level specifications. For the several more can be defined in higher-level specifications. For the
compression specified in the previous section, the Hop-By-Hop TLVs compression specified in the previous section, the hop-by-hop TLVs
are ordered as follows: are ordered as follows:
1. Recommended Cache Time TLV 1. Recommended Cache Time TLV
2. Message Hash TLV 2. Message Hash TLV
Note: Other Hop-By-Hop Header TLVs than those two remain uncompressed Note: Other hop-by-hop header TLVs than those two remain uncompressed
in the encoded message and they appear in the same order as in the in the encoded message, and they appear in the same order as in the
original message, but after the Recommended Cache Time TLV and original message but after the Recommended Cache Time TLV and Message
Message Hash TLV. Hash TLV.
6.4.3. Dispatch Extension 6.4.3. Dispatch Extension
The "EXT_0" byte follows the description in Section 4.1.1 and is The EXT_0 byte follows the description in Section 4.1.1 and is
illustrated in Figure 27. illustrated in Figure 27.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| NCS | RSV |EXT| | NCS | RSV |EXT|
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 27: EXT_0 format Figure 27: EXT_0 Format
NCS: Name Compression Strategy NCS: Name Compression Strategy
00: Names are compressed with the default name 00: Names are compressed with the default name compression
compression strategy (see Section 5.2). strategy (see Section 5.2).
01: Reserved. 01: Reserved.
10: Reserved. 10: Reserved.
11: Reserved. 11: Reserved.
RSV: Reserved Must be set to 0. RSV: Reserved
Must be set to 0.
EXT: Extension EXT: Extension
0: No extension byte follows.
0: No extension byte follows. 1: A further extension byte follows immediately.
1: A further extension byte follows immediately.
7. Compressed Time Encoding 7. Compressed Time Encoding
This document adopts the 8-bit compact time representation for This document adopts the 8-bit compact time representation for
relative time values described in Section 5 of [RFC5497] with the relative time-values described in Section 5 of [RFC5497] with the
constant factor "C" set to "C := 1/32". constant factor C set to C := 1/32.
Valid time offsets in CCNx and NDN reach from a few milliseconds Valid time offsets in CCNx and NDN range from a few milliseconds
(e.g., lifetime of low-latency Interests) to several years (e.g., (e.g., lifetime of low-latency Interests) to several years (e.g.,
content freshness periods in caches). Therefore, this document adds content freshness periods in caches). Therefore, this document adds
two modifications to the compression algorithm. two modifications to the compression algorithm.
The first modification is the inclusion of a subnormal form The first modification is the inclusion of a subnormal form
[IEEE.754.2019] for time-codes with exponent 0 to provide an [IEEE.754.2019] for time-codes with exponent 0 to provide an
increased precision and a gradual underflow for the smallest numbers. increased precision and a gradual underflow for the smallest numbers.
The formula is changed as follows (a := mantissa; b := exponent): The formula is changed as follows (a := mantissa, b := exponent):
Subnormal (b == 0): (0 + a/8) * 2 * C Subnormal (b == 0): (0 + a/8) * 2 * C
Normalized (b > 0): (1 + a/8) * 2^b * C (see [RFC5497]) Normalized (b > 0): (1 + a/8) * 2^b * C (see [RFC5497])
This configuration allows for the following ranges: This configuration allows for the following ranges:
o Minimum subnormal number: 0 seconds * Minimum subnormal number: 0 seconds
* 2nd minimum subnormal number: ~0.007812 seconds
o 2nd minimum subnormal number: ~0.007812 seconds * Maximum subnormal number: ~0.054688 seconds
* Minimum normalized number: ~0.062500 seconds
o Maximum subnormal number: ~0.054688 seconds * 2nd minimum normalized number: ~0.070312 seconds
* Maximum normalized number: ~3.99 years
o Minimum normalized number: ~0.062500 seconds
o 2nd minimum normalized number: ~0.070312 seconds
o Maximum normalized number: ~3.99 years
The second modification only applies to uncompressible time offsets The second modification only applies to uncompressible time offsets
that are outside any security envelope. An invalid time-value MUST that are outside any security envelope. An invalid time-value MUST
be set to the largest valid time-value that is smaller than the be set to the largest valid time-value that is smaller than the
invalid input value before compression. invalid input value before compression.
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 the context state at
nodes and omitted from communication. Second, redundancy in a single all nodes and omitted from communication. Second, redundancy in a
Interest-data exchange may be removed from ICN stateful forwarding on single Interest-Data exchange may be removed from ICN stateful
a hop-by-hop bases and memorized in en-route state tables. forwarding on a hop-by-hop basis and memorized in en-route state
tables.
8.1. LoWPAN-local State 8.1. LoWPAN-Local State
A context identifier (CID) is a byte that refers to a particular A Context Identifier (CID) is a byte that refers to a particular
conceptual context between network devices and MAY be used to replace conceptual context between network devices and MAY be used to replace
frequently appearing information, such as name prefixes, suffixes, or frequently appearing information, such as name prefixes, suffixes, or
meta information, such as Interest lifetime. meta information, such as Interest lifetime.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| X | ContextID | | X | ContextID |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 28: Context Identifier. Figure 28: Context Identifier
The 7-bit ContextID is a locally-scoped unique identifier that The 7-bit ContextID is a locally scoped unique identifier that
represents contextual state shared between sender and receiver of the represents the contextual state shared between the sender and
corresponding frame (see Figure 28). If set the most significant bit receiver of the corresponding frame (see Figure 28). If set, the
indicates the presence of another, subsequent ContextID byte (see most significant bit indicates the presence of another, subsequent
Figure 33). ContextID byte (see Figure 33).
Context state shared between senders and receivers is removed from The context state shared between senders and receivers is removed
the compressed packet prior to sending, and reinserted after from the compressed packet prior to sending and reinserted after
reception prior to passing to the upper stack. reception prior to passing to the upper stack.
The actual information in a context and how it is encoded are out of The actual information in a context and how it is encoded are out of
scope of this document. The initial distribution and maintenance of scope of this document. The initial distribution and maintenance of
shared context is out of scope of this document. Frames containing shared context is out of scope of this document. Frames containing
unknown or invalid CIDs MUST be silently discarded. unknown or invalid CIDs MUST be silently discarded.
8.2. En-route State 8.2. En-Route State
In CCNx and NDN, Name TLVs are included in Interest messages, and In CCNx and NDN, Name TLVs are included in Interest messages, and
they return in data messages. Returning Name TLVs either equal the they return in Data messages. Returning Name TLVs either equal the
original Name TLV, or they contain the original Name TLV as a prefix. original Name TLV or contain the original Name TLV as a prefix. ICN
ICN LoWPAN reduces this redundancy in responses by replacing Name LoWPAN reduces this redundancy in responses by replacing Name TLVs
TLVs with single bytes that represent link-local HopIDs. HopIDs are with single bytes that represent link-local HopIDs. HopIDs are
carried as Context Identifiers (see Section 8.1) of link-local scope carried as Context Identifiers (see Section 8.1) of link-local scope,
as shown in Figure 29. as shown in Figure 29.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| X | HopID | | X | HopID |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 29: Context Identifier as HopID. Figure 29: Context Identifier as HopID
A HopID is valid if not all ID bits are set to zero and invalid 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) otherwise. This yields 127 distinct HopIDs. If this range (1...127)
is exhausted, the messages MUST be sent without en-route state is exhausted, the messages MUST be sent without en-route state
compression until new HopIDs are available. An ICN LoWPAN node that compression until new HopIDs are available. An ICN LoWPAN node that
forwards without replacing the name by a HopID (without en-route forwards without replacing the name by a HopID (without en-route
compression) MUST invalidate the HopID by setting all ID-bits to compression) MUST invalidate the HopID by setting all ID bits to
zero. zero.
While an Interest is traversing, a forwarder generates an ephemeral While an Interest is traversing, a forwarder generates an ephemeral
HopID that is tied to a PIT entry. Each HopID MUST be unique within HopID that is tied to a Pending Interest Table (PIT) entry. Each
the local PIT and only exists during the lifetime of a PIT entry. To HopID MUST be unique within the local PIT and only exists during the
maintain HopIDs, the local PIT is extended by two new columns: HIDi lifetime of a PIT entry. To maintain HopIDs, the local PIT is
(inbound HopIDs) and HIDo (outbound HopIDs). 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 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 resulting PIT entry in the HIDi column. The HopID is replaced with a
newly generated local HopID before the Interest is forwarded. This newly generated local HopID before the Interest is forwarded. This
new HopID is stored in the HIDo column of the local PIT (see new HopID is stored in the HIDo column of the local PIT (see
Figure 30). Figure 30).
PIT of B PIT Extension PIT of C PIT Extension PIT of B PIT Extension PIT of C PIT Extension
+--------+------++------+------+ +--------+------++------+------+ +--------+------++------+------+ +--------+------++------+------+
| Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo |
+========+======++======+======+ +========+======++======+======+ +========+======++======+======+ +========+======++======+======+
| /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | | | /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | |
+--------+------++------+------+ +--------+------++------+------+ +--------+------++------+------+ +--------+------++------+------+
^ | ^ ^ | ^
store | '----------------------, ,---' store store | '----------------------, ,---' store
| send v | | send v |
,---, /p0, h_A ,---, /p0, h_B ,---, ,---, /p0, h_A ,---, /p0, h_B ,---,
| A | ------------------------> | B | ------------------------> | C | | A | ------------------------> | B | ------------------------> | C |
'---' '---' '---' '---' '---' '---'
Figure 30: Setting compression state en-route (Interest). Figure 30: Setting Compression State En-Route (Interest)
Responses include HopIDs that were obtained from Interests. If the Responses include HopIDs that were obtained from Interests. If the
returning Name TLV equals the original Name TLV, then the name is returning Name TLV equals the original Name TLV, then the name is
entirely elided. Otherwise, only the matching name prefix is elided entirely elided. Otherwise, only the matching name prefix is elided,
and the distinct name suffix is included along with the HopID. When and the distinct name suffix is included along with the HopID. When
a response is forwarded, the contained HopID is extracted and used to a response is forwarded, the contained HopID is extracted and used to
match against the correct PIT entry by performing a lookup on the match against the correct PIT entry by performing a lookup on the
HIDo column. The HopID is then replaced with the corresponding HopID HIDo column. The HopID is then replaced with the corresponding HopID
from the HIDi column prior to forwarding the response (Figure 31). from the HIDi column prior to forwarding the response (Figure 31).
PIT of B PIT Extension PIT of C PIT Extension PIT of B PIT Extension PIT of C PIT Extension
+--------+------++------+------+ +--------+------++------+------+ +--------+------++------+------+ +--------+------++------+------+
| Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo | | Prefix | Face || HIDi | HIDo |
+========+======++======+======+ +========+======++======+======+ +========+======++======+======+ +========+======++======+======+
| /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | | | /p0 | F_A || h_A | h_B | | /p0 | F_A || h_A | |
+--------+------++------+------+ +--------+------++------+------+ +--------+------++------+------+ +--------+------++------+------+
| ^ | | ^ |
send | '----------------------, ,---' send send | '----------------------, ,---' send
v match | v v match | v
,---, h_A ,---, h_B ,---, ,---, h_A ,---, h_B ,---,
| A | <------------------------ | B | <------------------------ | C | | A | <------------------------ | B | <------------------------ | C |
'---' '---' '---' '---' '---' '---'
Figure 31: Eliding Name TLVs using en-route state (data). Figure 31: Eliding Name TLVs Using En-Route State (Data)
It should be noted that each forwarder of an Interest in an ICN It should be noted that each forwarder of an Interest in an ICN
LoWPAN network can individually decide whether to participate in en- LoWPAN network can individually decide whether to participate in en-
route compression or not. However, an ICN LoWPAN node SHOULD use en- route compression or not. However, an ICN LoWPAN node SHOULD use en-
route compression whenever the stateful compression mechanism is route compression whenever the stateful compression mechanism is
activated. activated.
Note also that the extensions of the PIT data structure are required Note also that the extensions of the PIT data structure are required
only at ICN LoWPAN nodes, while regular NDN/CCNx forwarders outside only at ICN LoWPAN nodes, while regular NDN/CCNx forwarders outside
of an ICN LoWPAN domain do not need to implement these extensions. of an ICN LoWPAN domain do not need to implement these extensions.
8.3. Integrating Stateful Header Compression 8.3. Integrating Stateful Header Compression
A CID appears whenever the CID flag is set (see Figure 5). The CID A CID appears whenever the CID flag is set (see Figure 5). The CID
is appended to the last ICN LoWPAN dispatch byte as shown in is appended to the last ICN LoWPAN dispatch byte, as shown in
Figure 32. Figure 32.
...-------+--------+-------...-------+--...-+-------... ...-------+--------+-------...-------+--...-+-------...
/ ... | Page | ICN LoWPAN Disp.| CIDs | Payload / / ... | Page | ICN LoWPAN Disp.| CIDs | Payload /
...-------+--------+-------...-------+--...-+-------... ...-------+--------+-------...-------+--...-+-------...
Figure 32: LoWPAN Encapsulation with ICN LoWPAN and CIDs Figure 32: LoWPAN Encapsulation with ICN LoWPAN and CIDs
Multiple CIDs are chained together, with the most significant bit Multiple CIDs are chained together, with the most significant bit
indicating the presence of a subsequent CID (Figure 33). This allows indicating the presence of a subsequent CID (Figure 33). This allows
to use multiple shared contexts in compressed messages. to use multiple shared contexts in compressed messages.
The HopID is always included as the very first CID. The HopID is always included as the very first CID.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1| CID / HopID | --> |1| CID | --> |0| CID | |1| CID / HopID | --> |1| CID | --> |0| CID |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 33: Chaining of context identifiers. Figure 33: Chaining of Context Identifiers
9. ICN LoWPAN Constants and Variables 9. ICN LoWPAN Constants and Variables
This is a summary of all ICN LoWPAN constants and variables. This is a summary of all ICN LoWPAN constants and variables.
DEFAULT_NDN_HOPLIMIT: 255 DEFAULT_NDN_HOPLIMIT: 255
10. Implementation Report and Guidance 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 for NDN over ICN version on RIOT [RIOT]. An experimental evaluation for NDN over ICN
LOWPAN with varying configurations has been performed in [ICNLOWPAN]. LoWPAN with varying configurations has been performed in [ICNLOWPAN].
Energy profilings and processing time measurements indicate Energy profiling and processing time measurements indicate
significant energy savings, while amortized costs for processing show significant energy savings, and the amortized costs for processing
no penalties. show no penalties.
10.1. Preferred Configuration 10.1. Preferred Configuration
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 Signed time offsets compress as per Section 7 without the need for * Signed time offsets compress, per Section 7, without the need for
rounding. rounding.
o Contextual state (e.g., prefixes) is distributed, such that long * The contextual state (e.g., prefixes) is distributed such that
names can be elided from Interest and data messages. long names can be elided from Interest and Data messages.
o Frequently used TLV type numbers for CCNx and NDN stay in the * Frequently used TLV type numbers for CCNx and NDN stay in the
lower range (< 255). lower range (< 255).
Name components are of GenericNameComponent type and are limited to a Name components are of type GenericNameComponent and are limited to a
length of 15 bytes to enable compression for all messages. length of 15 bytes to enable compression for all messages.
10.2. Further Experimental Deployments 10.2. Further Experimental Deployments
An investigation of ICN LoWPAN in large-scale deployments with An investigation of ICN LoWPAN in large-scale deployments with
varying traffic patterns using larger samples of the different board varying traffic patterns using larger samples of the different board
types available remains as future work. This document will be types available remains as future work. This document will be
revised to progress it to the Standards Track, once sufficient revised to progress it to the Standards Track, once sufficient
operational experience has been acquired. Experience reports are operational experience has been acquired. Experience reports are
encouraged, particularly in the following areas: encouraged, particularly in the following areas:
o The name compression scheme (Section 5.2) is optimized for short * The name compression scheme (Section 5.2) is optimized for short
name components of GenericNameComponent type. An empirical study name components of type GenericNameComponent. An empirical study
on name lengths in different deployments of selected use cases, on name lengths in different deployments of selected use cases,
such as smart home, smart city, and industrial IoT can provide such as smart home, smart city, and industrial IoT can provide
meaningful reports on necessary name component types and lengths. meaningful reports on necessary name component types and lengths.
A conclusive outcome helps to understand whether and how extension A conclusive outcome helps to understand whether and how extension
mechanisms are needed (Section 5.3.3). As a preliminary analysis, mechanisms are needed (Section 5.3.3). As a preliminary analysis,
[ICNLOWPAN] investigates the effectiveness of the proposed [ICNLOWPAN] investigates the effectiveness of the proposed
compression scheme with URLs obtained from the WWW. Studies on compression scheme with URLs obtained from the WWW. Studies on
CoAP [RFC7252] deployments can offer additional insights on naming deployments of Constrained Application Protocol (CoAP) [RFC7252]
schemes in the IoT. can offer additional insights on naming schemes in the IoT.
o The fragmentation scheme (Section 4.2) inherited from 6LoWPAN * The fragmentation scheme (Section 4.2) inherited from 6LoWPAN
allows for a transparent, hop-wise reassembly of CCNx or NDN allows for a transparent, hop-wise reassembly of CCNx or NDN
packets. Fragment forwarding [RFC8930] with selective fragment packets. Fragment forwarding [RFC8930] with selective fragment
recovery [RFC8931] can improve the end-to-end latency and recovery [RFC8931] can improve the end-to-end latency and
reliability, while it reduces buffer requirements on forwarders. reliability while it reduces buffer requirements on forwarders.
Initial evaluations ([SFR-ICNLOWPAN]) show that a naive Initial evaluations [SFR-ICNLOWPAN] show that a naive integration
integration of these upcoming fragmentation features into ICN of these upcoming fragmentation features into ICN LoWPAN renders
LoWPAN renders the hop-wise content replication inoperative, since the hop-wise content replication inoperative, since Interest and
Interest and data messages are reassembled end-to-end. More Data messages are reassembled end-to-end. More deployment
deployment experiences are necessary to gauge the feasibility of experiences are necessary to gauge the feasibility of different
different fragmentation schemes in ICN LoWPAN. fragmentation schemes in ICN LoWPAN.
o Context state (Section 8.1) holds information that is shared * The context state (Section 8.1) holds information that is shared
between a set of devices in a LoWPAN. Fixed name prefixes and between a set of devices in a LoWPAN. Fixed name prefixes and
suffixes are good candidates to be distributed to all nodes in suffixes are good candidates to be distributed to all nodes in
order to elide them from request and response messages. More order to elide them from request and response messages. More
experience and a deeper inspection of currently available and experience and a deeper inspection of currently available and
upcoming protocol features is necessary to identify other protocol upcoming protocol features is necessary to identify other protocol
fields. fields.
o The distribution and synchronization of contextual state can * The distribution and synchronization of the contextual state can
potentially be adopted from Section 7.2 of [RFC6775], but requires potentially be adopted from Section 7.2 of [RFC6775] but requires
further evaluations. While 6LoWPAN uses the Neighbor Discovery further evaluations. While 6LoWPAN uses the Neighbor Discovery
protocol to disseminate state, CCNx and NDN deployments are protocol to disseminate state, CCNx and NDN deployments are
missing out on a standard mechanism to bootstrap and manage missing out on a standard mechanism to bootstrap and manage
configurations. configurations.
o The stateful en-route compression (Section 8.2) supports a limited * The stateful en-route compression (Section 8.2) supports a limited
number of 127 distinct HopIDs that can be simultaneously in use on number of 127 distinct HopIDs that can be simultaneously in use on
a single node. Complex deployment scenarios that make use of a single node. Complex deployment scenarios that make use of
multiple, concurrent requests can provide a better insight on the multiple, concurrent requests can provide a better insight on the
number of open requests stored in the Pending Interest Table of number of open requests stored in the PIT of memory-constrained
memory-constrained devices. This number can serve as an upper- devices. This number can serve as an upper bound and determines
bound and determines whether the HopID length needs to be resized whether the HopID length needs to be resized to fit more HopIDs at
to fit more HopIDs to the cost of additional header overhead. the cost of additional header overhead.
o Multiple implementations that generate and deploy the compression * Multiple implementations that generate and deploy the compression
options of this memo in different ways will also add to the options of this memo in different ways will also add to the
experience and understanding of the benefits and limitations of experience and understanding of the benefits and limitations of
the proposed schemes. Different reports can help to illuminate on the proposed schemes. Different reports can help to illuminate
the complexity of implementing ICN LoWPAN for constrained devices, the complexity of implementing ICN LoWPAN for constrained devices,
as well as on maintaining interoperability with other as well as on maintaining interoperability with other
implementations. implementations.
11. 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
and purges them only after a packet is reassembled, which requires a fragments and purges them only after a packet is reassembled, which
buffering of all fragments. This scheme is able to handle fragments requires a buffering of all fragments. This scheme is able to handle
for distinctive packets simultaneously, which can lead to overflowing fragments for distinctive packets simultaneously, which can lead to
packet buffers that cannot hold all necessary fragments for packet overflowing packet buffers that cannot hold all necessary fragments
reassembly. Implementers are thus urged to make use of appropriate for packet reassembly. Implementers are thus urged to make use of
buffer replacement strategies for fragments. Minimal fragment appropriate buffer replacement strategies for fragments. Minimal
forwarding [RFC8930] can potentially prevent fragment buffer fragment forwarding [RFC8930] can potentially prevent fragment buffer
saturation in forwarders. saturation in forwarders.
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. IEEE 802.15.4, e.g., provides link layer should be deployed. IEEE 802.15.4, e.g., provides
capabilities to protect frames and restrict them to a point-to-point capabilities to protect frames and restrict them to a point-to-point
link, or a group of devices. link or a group of devices.
12. IANA Considerations 12. IANA Considerations
12.1. Reserving Space in the 6LoWPAN Dispatch Type Field Registry 12.1. Updates to 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 2 represents updates to the registry.
+-------------+------+-------------------------------------------+ IANA has assigned dispatch values for ICN LoWPAN in the "Dispatch
| Bit Pattern | Page | Header Type | Type Field" subregistry [RFC4944] [RFC8025] of the "IPv6 Low Power
+-------------+------+-------------------------------------------+ Personal Area Network Parameters" registry. Table 2 represents the
| 00 000000 | TBD1 | Uncompressed NDN Interest messages | updates to the registry.
| 00 100000 | TBD1 | Uncompressed NDN Data messages |
| 01 000000 | TBD1 | Uncompressed CCNx Interest messages |
| 01 100000 | TBD1 | Uncompressed CCNx Content Object messages |
| 10 0xxxxx | TBD1 | Compressed NDN Interest messages |
| 10 1xxxxx | TBD1 | Compressed NDN Data messages |
| 11 0xxxxx | TBD1 | Compressed CCNx Interest messages |
| 11 1xxxxx | TBD1 | Compressed CCNx Content Object messages |
+-------------+------+-------------------------------------------+
Table 2: Dispatch types for NDN and CCNx with page TBD1. +=============+======+=========================+===========+
| Bit Pattern | Page | Header Type | Reference |
+=============+======+=========================+===========+
| 00 000000 | 14 | Uncompressed NDN | RFC 9139 |
| | | Interest messages | |
+-------------+------+-------------------------+-----------+
| 00 01xxxx | 14 | Compressed NDN Interest | RFC 9139 |
| | | messages | |
+-------------+------+-------------------------+-----------+
| 00 100000 | 14 | Uncompressed NDN Data | RFC 9139 |
| | | messages | |
+-------------+------+-------------------------+-----------+
| 00 11xxxx | 14 | Compressed NDN Data | RFC 9139 |
| | | messages | |
+-------------+------+-------------------------+-----------+
| 01 000000 | 14 | Uncompressed CCNx | RFC 9139 |
| | | Interest messages | |
+-------------+------+-------------------------+-----------+
| 01 01xxxx | 14 | Compressed CCNx | RFC 9139 |
| | | Interest messages | |
+-------------+------+-------------------------+-----------+
| 01 100000 | 14 | Uncompressed CCNx | RFC 9139 |
| | | Content Object messages | |
+-------------+------+-------------------------+-----------+
| 01 11xxxx | 14 | Compressed CCNx Content | RFC 9139 |
| | | Object messages | |
+-------------+------+-------------------------+-----------+
13. References 13. References
13.1. Normative References 13.1. Normative References
[IEEE.754.2019] [IEEE.754.2019]
Institute of Electrical and Electronics Engineers, C/MSC - IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE
Microprocessor Standards Committee, "Standard for Std 754-2019, <https://standards.ieee.org/content/ieee-
Floating-Point Arithmetic", June 2019, standards/en/standard/754-2019.html>.
<https://standards.ieee.org/content/ieee-standards/en/
standard/754-2019.html>.
[ieee802.15.4] [ieee802.15.4]
"IEEE Std. 802.15.4-2015", April 2016, IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE
<https://standards.ieee.org/findstds/ Std 802.15.4-2015, <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>.
[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,
skipping to change at page 41, line 30 skipping to change at line 1798
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>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>. <https://www.rfc-editor.org/info/rfc6775>.
[RFC8174] Leiba, B., "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>.
13.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-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] [ICNLOWPAN]
Gundogan, C., Kietzmann, P., Schmidt, TC., and M. Gündogan, C., Kietzmann, P., Schmidt, TC., and M.
Waehlisch, "ICNLoWPAN -- Named-Data Networking in Low Wählisch, "ICNLoWPAN - Named-Data Networking in Low Power
Power IoT Networks", Proc. of 18th IFIP Networking IoT Networks", Proc. of 18th IFIP Networking Conference,
Conference, May 2019, May 2019,
<https://doi.org/10.23919/IFIPNetworking.2019.8816850>. <https://doi.org/10.23919/IFIPNetworking.2019.8816850>.
[NDN] Jacobson, V., Smetters, D., Thornton, J., and M. Plass, [ICNRG-FLIC]
"Networking Named Content", 5th Int. Conf. on emerging Tschudin, C., Wood, C., Mosko, M., and D. Oran, Ed.,
Networking Experiments and Technologies (ACM CoNEXT), "File-Like ICN Collections (FLIC)", Work in Progress,
2009, <https://doi.org/10.1145/1658939.1658941>. Internet-Draft, draft-irtf-icnrg-flic-02, 4 November 2019,
<https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-
flic-02>.
[NDN-EXP1] [NDN] Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
Baccelli, E., Mehlis, C., Hahm, O., Schmidt, TC., and M. Briggs, N., and R. Braynard, "Networking named content",
Waehlisch, "Information Centric Networking in the IoT: 5th Int. Conf. on emerging Networking Experiments and
Experiments with NDN in the Wild", Proc. of 1st ACM Conf. Technologies (ACM CoNEXT), December 2009,
<https://doi.org/10.1145/1658939.1658941>.
[NDN-EXP1] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, TC., and M.
Wählisch, "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. 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] Gündoğan, C., Kietzmann, P., Lenders, M., Petersen, H.,
Gundogan, C., Kietzmann, P., Lenders, M., Petersen, H., Schmidt, TC., and M. Wählisch, "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. 159-171, September 2018, DL, pp. 159-171, September 2018,
<https://doi.org/10.1145/3267955.3267967>. <https://doi.org/10.1145/3267955.3267967>.
[NDN-MAC] Kietzmann, P., Gundogan, C., Schmidt, TC., Hahm, O., and [NDN-MAC] Kietzmann, P., Gündoğan, C., Schmidt, TC., Hahm, O., and
M. Waehlisch, "The Need for a Name to MAC Address Mapping M. Wählisch, "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)
2017) ACM DL, pp. 36-42, September 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",
<https://named-data.net/doc/NDN-packet-spec/0.3/>. <https://named-data.net/doc/NDN-packet-spec/0.3/>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
skipping to change at page 43, line 36 skipping to change at line 1905
[RFC8930] Watteyne, T., Ed., Thubert, P., Ed., and C. Bormann, "On [RFC8930] Watteyne, T., Ed., Thubert, P., Ed., and C. Bormann, "On
Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6
Network", RFC 8930, DOI 10.17487/RFC8930, November 2020, Network", RFC 8930, DOI 10.17487/RFC8930, November 2020,
<https://www.rfc-editor.org/info/rfc8930>. <https://www.rfc-editor.org/info/rfc8930>.
[RFC8931] Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal [RFC8931] Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal
Area Network (6LoWPAN) Selective Fragment Recovery", Area Network (6LoWPAN) Selective Fragment Recovery",
RFC 8931, DOI 10.17487/RFC8931, November 2020, RFC 8931, DOI 10.17487/RFC8931, November 2020,
<https://www.rfc-editor.org/info/rfc8931>. <https://www.rfc-editor.org/info/rfc8931>.
[RIOT] Baccelli, E., Gundogan, C., Hahm, O., Kietzmann, P., [RIOT] Baccelli, E., Gündoğan, C., Hahm, O., Kietzmann, P.,
Lenders, MS., Petersen, H., Schleiser, K., Schmidt, TC., Lenders, MS., Petersen, H., Schleiser, K., Schmidt, TC.,
and M. Waehlisch, "RIOT: an Open Source Operating System and M. Wählisch, "RIOT: An Open Source Operating System
for Low-end Embedded Devices in the IoT", IEEE Internet of for Low-End Embedded Devices in the IoT", IEEE Internet of
Things Journal Vol. 5, No. 6, p. 4428-4440, December 2018, Things Journal Vol. 5, No. 6, p. 4428-4440, December
<https://doi.org/10.1109/JIOT.2018.2815038>. 2018, <https://doi.org/10.1109/JIOT.2018.2815038>.
[SFR-ICNLOWPAN] [SFR-ICNLOWPAN]
Lenders, M., Gundogan, C., Schmidt, TC., and M. Waehlisch, Lenders, M., Gündoğan, C., Schmidt, TC., and M. Wählisch,
"Connecting the Dots: Selective Fragment Recovery in "Connecting the Dots: Selective Fragment Recovery in
ICNLoWPAN", Proc. of 7th ACM Conf. on Information-Centric ICNLoWPAN", Proc. of 7th ACM Conf. on Information-Centric
Networking (ICN-2020) ACM DL, pp. 70-76, September 2020, Networking (ICN-2020) ACM DL, pp. 70-76, September 2020,
<https://doi.org/10.1145/3405656.3418719>. <https://doi.org/10.1145/3405656.3418719>.
[TLV-ENC-802.15.4] [TLV-ENC-802.15.4]
"CCN and NDN TLV encodings in 802.15.4 packets", Mosko, M. and C. Tschudin, "CCN and NDN TLV encodings in
802.15.4 packets", January 2015,
<https://datatracker.ietf.org/meeting/interim-2015-icnrg- <https://datatracker.ietf.org/meeting/interim-2015-icnrg-
01/materials/slides-interim-2015-icnrg-1-2>. 01/materials/slides-interim-2015-icnrg-1-2>.
[WIRE-FORMAT-CONSID] [WIRE-FORMAT-CONSID]
"CCN/NDN Protocol Wire Format and Functionality Wang, G., Tschudin, C., and R. Ravindran, "CCN/NDN
Considerations", <https://datatracker.ietf.org/meeting/ Protocol Wire Format and Functionality Considerations",
January 2015, <https://datatracker.ietf.org/meeting/
interim-2015-icnrg-01/materials/slides-interim-2015-icnrg- interim-2015-icnrg-01/materials/slides-interim-2015-icnrg-
1-8>. 1-8>.
Appendix A. Estimated Size Reduction Appendix A. Estimated Size Reduction
In the following a theoretical evaluation is given to estimate the In the following, a theoretical evaluation is given to estimate the
gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages. gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages.
We assume that "n" is the number of name components, "comps_n" We assume that n is the number of name components; comps_n denotes
denotes the sum of n name component lengths. We also assume that the the sum of n name component lengths. We also assume that the length
length of each name component is lower than 16 bytes. The length of of each name component is lower than 16 bytes. The length of the
the content is given by "clen". The lengths of TLV components is content is given by clen. The lengths of TLV components are specific
specific to the CCNx or NDN encoding and outlined below. to the CCNx or NDN encoding and are outlined below.
A.1. NDN A.1. NDN
The NDN TLV encoding has variable-sized TLV fields. For simplicity, The NDN TLV encoding has variable-sized TLV fields. For simplicity,
the 1 byte form of each TLV component is assumed. A typical TLV the 1-byte form of each TLV component is assumed. A typical TLV
component therefore is of size 2 (type field + length field) + the component therefore is of size 2 (Type field + Length field) + the
actual value. actual value.
A.1.1. Interest A.1.1. Interest
Figure 34 depicts the size requirements for a basic, uncompressed NDN Figure 34 depicts the size requirements for a basic, uncompressed NDN
Interest containing a CanBePrefix TLV, a MustBeFresh TLV, a Interest containing a CanBePrefix TLV, a MustBeFresh TLV, an
InterestLifetime TLV set to 4 seconds and a HopLimit TLV set to 6. InterestLifetime TLV set to 4 seconds, and a HopLimit TLV set to 6.
Numbers below represent the amount of bytes. Numbers below represent the amount of bytes.
------------------------------------, ------------------------------------,
Interest TLV = 2 | Interest TLV = 2 |
---------------------, | ---------------------, |
Name | 2 + | Name | 2 + |
NameComponents = 2n + | NameComponents = 2n + |
| comps_n | | comps_n |
---------------------' = 21 + 2n + comps_n ---------------------' = 21 + 2n + comps_n
CanBePrefix = 2 | CanBePrefix = 2 |
MustBeFresh = 2 | MustBeFresh = 2 |
Nonce = 6 | Nonce = 6 |
InterestLifetime = 4 | InterestLifetime = 4 |
HopLimit = 3 | HopLimit = 3 |
------------------------------------' ------------------------------------'
Figure 34: Estimated size of an uncompressed NDN Interest Figure 34: Estimated Size of an Uncompressed NDN Interest
Figure 35 depicts the size requirements after compression. Figure 35 depicts the size requirements after compression.
------------------------------------, ------------------------------------,
Dispatch Page Switch = 1 | Dispatch Page Switch = 1 |
NDN Interset Dispatch = 2 | NDN Interest Dispatch = 2 |
Interest TLV = 1 | Interest TLV = 1 |
-----------------------, | -----------------------, |
Name | | Name | |
NameComponents = n/2 + = 10 + n/2 + comps_n NameComponents = n/2 + = 10 + n/2 + comps_n
| comps_n | | comps_n |
-----------------------' | -----------------------' |
Nonce = 4 | Nonce = 4 |
HopLimit = 1 | HopLimit = 1 |
InterestLifetime = 1 | InterestLifetime = 1 |
------------------------------------' ------------------------------------'
Figure 35: Estimated size of a compressed NDN Interest Figure 35: Estimated Size of a Compressed NDN Interest
The size difference is: The size difference is 11 + 1.5n bytes.
11 + 1.5n bytes.
For the name "/DE/HH/HAW/BT7", the total size gain is 17 bytes, which For the name /DE/HH/HAW/BT7, the total size gain is 17 bytes, which
is 43% of the uncompressed packet. is 43% of the uncompressed packet.
A.1.2. Data A.1.2. Data
Figure 36 depicts the size requirements for a basic, uncompressed NDN Figure 36 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 and the value is encoded using 1 byte. An 1 minute is assumed, and the value is encoded using 1 byte. An
HMACWithSha256 is assumed as signature. The key locator is assumed HMACWithSha256 is assumed as a signature. The key locator is 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 |
---------------------' | ---------------------' |
---------------------, | ---------------------, |
skipping to change at page 47, line 27 skipping to change at line 2026
Content = 2 + clen | Content = 2 + clen |
---------------------, | ---------------------, |
SignatureInfo | | SignatureInfo | |
SignatureType | | SignatureType | |
KeyLocator = 41 + klen | KeyLocator = 41 + klen |
SignatureValue | | SignatureValue | |
DigestSha256 | | DigestSha256 | |
---------------------' | ---------------------' |
------------------------------------' ------------------------------------'
Figure 36: Estimated size of an uncompressed NDN Data Figure 36: Estimated Size of an Uncompressed NDN Data
Figure 37 depicts the size requirements for the compressed version of Figure 37 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 = 2 | NDN Data Dispatch = 2 |
-----------------------, | -----------------------, |
Name | | Name | |
NameComponents = n/2 + | NameComponents = n/2 + |
| comps_n = 38 + n/2 + comps_n + | comps_n = 38 + n/2 + comps_n +
-----------------------' | clen + klen -----------------------' | clen + klen
Content = 1 + clen | Content = 1 + clen |
KeyLocator = 1 + klen | KeyLocator = 1 + klen |
DigestSha256 = 32 | DigestSha256 = 32 |
FreshnessPeriod = 1 | FreshnessPeriod = 1 |
------------------------------------' ------------------------------------'
Figure 37: Estimated size of a compressed NDN Data Figure 37: Estimated Size of a Compressed NDN Data
The size difference is: The size difference is 15 + 1.5n bytes.
15 + 1.5n bytes.
For the name "/DE/HH/HAW/BT7", the total size gain is 21 bytes. For the name /DE/HH/HAW/BT7, the total size gain is 21 bytes.
A.2. CCNx A.2. CCNx
The CCNx TLV encoding defines a 2-byte encoding for type and length The CCNx TLV encoding defines a 2-byte encoding for Type and Length
fields, summing up to 4 bytes in total without a value. fields, summing up to 4 bytes in total without a value.
A.2.1. Interest A.2.1. Interest
Figure 38 depicts the size requirements for a basic, uncompressed Figure 38 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
is assumed to be 1 and the reserved field is assumed to be 0. A 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 KeyIdRestriction TLV with T_SHA-256 is included to limit the
responses to Content Objects containing the specific key. responses to Content Objects containing the specific key.
------------------------------------, ------------------------------------,
Fixed Header = 8 | Fixed Header = 8 |
Message = 4 | Message = 4 |
---------------------, | ---------------------, |
Name | 4 + = 56 + 4n + comps_n Name | 4 + = 56 + 4n + comps_n
NameSegments = 4n + | NameSegments = 4n + |
| comps_n | | comps_n |
---------------------' | ---------------------' |
KeyIdRestriction = 40 | KeyIdRestriction = 40 |
------------------------------------' ------------------------------------'
Figure 38: Estimated size of an uncompressed CCNx Interest Figure 38: Estimated Size of an Uncompressed CCNx Interest
Figure 39 depicts the size requirements after compression. Figure 39 depicts the size requirements after compression.
------------------------------------, ------------------------------------,
Dispatch Page Switch = 1 | Dispatch Page Switch = 1 |
CCNx Interest Dispatch = 2 | CCNx Interest Dispatch = 2 |
Fixed Header = 3 | Fixed Header = 3 |
-----------------------, | -----------------------, |
Name | = 38 + n/2 + comps_n Name | = 38 + n/2 + comps_n
NameSegments = n/2 + | NameSegments = n/2 + |
| comps_n | | comps_n |
-----------------------' | -----------------------' |
T_SHA-256 = 32 | T_SHA-256 = 32 |
------------------------------------' ------------------------------------'
Figure 39: Estimated size of a compressed CCNx Interest Figure 39: Estimated Size of a Compressed CCNx Interest
The size difference is: The size difference is 18 + 3.5n bytes.
18 + 3.5n bytes.
For the name "/DE/HH/HAW/BT7", the size is reduced by 53 bytes, which For the name /DE/HH/HAW/BT7, the size is reduced by 53 bytes, which
is 53% of the uncompressed packet. is 53% of the uncompressed packet.
A.2.2. Content Object A.2.2. Content Object
Figure 40 depicts the size requirements for a basic, uncompressed Figure 40 depicts the size requirements for a basic, uncompressed
CCNx Content Object containing an ExpiryTime Message TLV, an CCNx Content Object containing an ExpiryTime Message TLV, an
HMAC_SHA-256 signature, the signature time and a hash of the shared 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 secret key. In the fixed header, the protocol version is assumed to
be 1 and the reserved field is assumed to be 0 be 1 and the Reserved field is assumed to be 0
------------------------------------, ------------------------------------,
Fixed Header = 8 | Fixed Header = 8 |
Message = 4 | Message = 4 |
---------------------, | ---------------------, |
Name | 4 + | Name | 4 + |
NameSegments = 4n + | NameSegments = 4n + |
| comps_n | | comps_n |
---------------------' | ---------------------' |
ExpiryTime = 12 = 124 + 4n + comps_n + clen ExpiryTime = 12 = 124 + 4n + comps_n + clen
Payload = 4 + clen | Payload = 4 + clen |
---------------------, | ---------------------, |
ValidationAlgorithm | | ValidationAlgorithm | |
T_HMAC-256 = 56 | T_HMAC-256 = 56 |
KeyId | | KeyID | |
SignatureTime | | SignatureTime | |
---------------------' | ---------------------' |
ValidationPayload = 36 | ValidationPayload = 36 |
------------------------------------' ------------------------------------'
Figure 40: Estimated size of an uncompressed CCNx Content Object Figure 40: Estimated Size of an Uncompressed CCNx Content Object
Figure 41 depicts the size requirements for a basic, compressed CCNx Figure 41 depicts the size requirements for a basic, compressed CCNx
Data. Data.
------------------------------------, ------------------------------------,
Dispatch Page Switch = 1 | Dispatch Page Switch = 1 |
CCNx Content Dispatch = 3 | CCNx Content Dispatch = 3 |
Fixed Header = 2 | Fixed Header = 2 |
-----------------------, | -----------------------, |
Name | | Name | |
NameSegments = n/2 + | NameSegments = n/2 + |
| comps_n = 89 + n/2 + comps_n + clen | comps_n = 89 + n/2 + comps_n + clen
-----------------------' | -----------------------' |
ExpiryTime = 8 | ExpiryTime = 8 |
Payload = 1 + clen | Payload = 1 + clen |
T_HMAC-SHA256 = 32 | T_HMAC-SHA256 = 32 |
SignatureTime = 8 | SignatureTime = 8 |
ValidationPayload = 34 | ValidationPayload = 34 |
------------------------------------' ------------------------------------'
Figure 41: Estimated size of a compressed CCNx Data Object Figure 41: Estimated Size of a Compressed CCNx Data Object
The size difference is: The size difference is 35 + 3.5n bytes.
35 + 3.5n bytes.
For the name "/DE/HH/HAW/BT7", the size is reduced by 70 bytes, which For the name /DE/HH/HAW/BT7, the size is reduced by 70 bytes, which
is 40% of the uncompressed packet containing a 4-byte payload. is 40% of the uncompressed packet containing a 4-byte payload.
Acknowledgments Acknowledgments
This work was stimulated by fruitful discussions in the ICNRG This work was stimulated by fruitful discussions in the ICNRG and the
research group and the communities of RIOT and CCNlite. We would communities of RIOT and CCNlite. We would like to thank all active
like to thank all active members for constructive thoughts and members for constructive thoughts and feedback. In particular, the
feedback. In particular, the authors would like to thank (in authors would like to thank (in alphabetical order) Peter Kietzmann,
alphabetical order) Peter Kietzmann, Dirk Kutscher, Martine Lenders, Dirk Kutscher, Martine Lenders, Colin Perkins, and Junxiao Shi. The
Colin Perkins, Junxiao Shi. The hop-wise stateful name compression hop-wise stateful name compression was brought up in a discussion by
was brought up in a discussion by Dave Oran, which is gratefully Dave Oran, which is gratefully acknowledged. Larger parts of this
acknowledged. Larger parts of this work are inspired by [RFC4944] work are inspired by [RFC4944] and [RFC6282]. Special mention goes
and [RFC6282]. Special mentioning goes to Mark Mosko as well as G.Q. to Mark Mosko, as well as G.Q. Wang and Ravi Ravindran, as their
Wang and Ravi Ravindran as their previous work in [TLV-ENC-802.15.4] previous work in [TLV-ENC-802.15.4] and [WIRE-FORMAT-CONSID] provided
and [WIRE-FORMAT-CONSID] provided a good base for our discussions on a good base for our discussions on stateless header compression
stateless header compression mechanisms. Many thanks also to Carsten mechanisms. Many thanks also to Carsten Bormann and Lars Eggert, who
Bormann and Lars Eggert, who contributed in-depth comments during the contributed in-depth comments during the IRSG review. This work was
IRSG review. This work was supported in part by the German Federal supported in part by the German Federal Ministry of Research and
Ministry of Research and Education within the projects I3 and Education within the projects I3 and RAPstore.
RAPstore.
Authors' Addresses Authors' Addresses
Cenk Gundogan Cenk Gundogan
HAW Hamburg HAW Hamburg
Berliner Tor 7 Berliner Tor 7
Hamburg D-20099 D-20099 Hamburg
Germany Germany
Phone: +4940428758067 Phone: +4940428758067
EMail: cenk.guendogan@haw-hamburg.de Email: cenk.guendogan@haw-hamburg.de
URI: http://inet.haw-hamburg.de/members/cenk-gundogan URI: http://inet.haw-hamburg.de/members/cenk-gundogan
Thomas C. Schmidt Thomas C. Schmidt
HAW Hamburg HAW Hamburg
Berliner Tor 7 Berliner Tor 7
Hamburg D-20099 D-20099 Hamburg
Germany Germany
EMail: t.schmidt@haw-hamburg.de Email: t.schmidt@haw-hamburg.de
URI: http://inet.haw-hamburg.de/members/schmidt URI: http://inet.haw-hamburg.de/members/schmidt
Matthias Waehlisch Matthias Wählisch
link-lab & FU link-lab & FU Berlin
Berlin
Hoenower Str. 35 Hoenower Str. 35
Berlin D-10318 D-10318 Berlin
Germany Germany
EMail: mw@link-lab.net Email: mw@link-lab.net
URI: http://www.inf.fu-berlin.de/~waehl URI: https://www.mi.fu-berlin.de/en/inf/groups/ilab/members/
waehlisch.html
Christopher Scherb Christopher Scherb
University of University of Basel
Basel
Spiegelgasse 1 Spiegelgasse 1
Basel CH-4051 CH-4051 Basel
Switzerland Switzerland
EMail: christopher.scherb@unibas.ch Email: christopher.scherb@unibas.ch
Claudio Marxer Claudio Marxer
University of University of Basel
Basel
Spiegelgasse 1 Spiegelgasse 1
Basel CH-4051 CH-4051 Basel
Switzerland Switzerland
EMail: claudio.marxer@unibas.ch Email: claudio.marxer@unibas.ch
Christian Tschudin Christian Tschudin
University of University of Basel
Basel
Spiegelgasse 1 Spiegelgasse 1
Basel CH-4051 CH-4051 Basel
Switzerland Switzerland
EMail: christian.tschudin@unibas.ch Email: christian.tschudin@unibas.ch
 End of changes. 337 change blocks. 
826 lines changed or deleted 794 lines changed or added

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