ICN Adaptation to LoWPAN
Networks (ICN LoWPAN)HAW HamburgBerliner Tor 7HamburgD-20099Germany+4940428758067cenk.guendogan@haw-hamburg.dehttp://inet.haw-hamburg.de/members/cenk-gundoganHAW HamburgBerliner Tor 7HamburgD-20099Germanyt.schmidt@haw-hamburg.dehttp://inet.haw-hamburg.de/members/schmidtlink-lab & FU
BerlinHoenower Str. 35BerlinD-10318Germanymw@link-lab.nethttp://www.inf.fu-berlin.de/~waehlUniversity of
BaselSpiegelgasse 1BaselCH-4051Switzerlandchristopher.scherb@unibas.chUniversity of
BaselSpiegelgasse 1BaselCH-4051Switzerlandclaudio.marxer@unibas.chUniversity of
BaselSpiegelgasse 1BaselCH-4051Switzerlandchristian.tschudin@unibas.chICN Research GroupThis document defines a convergence layer for CCNx and NDN over IEEE
802.15.4 LoWPAN networks. A new frame format is specified to adapt CCNx
and NDN packets to the small MTU size of IEEE 802.15.4. For that,
syntactic and semantic changes to the TLV-based header formats are
described. To support compatibility with other LoWPAN technologies that
may coexist on a wireless medium, the dispatching scheme provided by
6LoWPAN is extended to include new dispatch types for CCNx and NDN.
Additionally, the fragmentation component of the 6LoWPAN
dispatching framework is applied to ICN chunks. In its second part, the
document defines stateless and stateful compression schemes to improve
efficiency on constrained links. Stateless compression reduces TLV
expressions to static header fields for common use cases. Stateful
compression schemes elide state local to the LoWPAN and replace names in
data packets by short local identifiers.This document is a product of the IRTF Information-Centric
Networking Research Group (ICNRG).The Internet of Things (IoT) has been identified as a promising
deployment area for Information Centric Networks (ICN), as
infrastructureless access to content, resilient forwarding, and
in-network data replication demonstrated notable advantages over the
traditional host-to-host approach on the Internet , . Recent studies have shown that an appropriate mapping to link layer
technologies has a large impact on the practical performance of an ICN.
This will be even more relevant in the context of IoT communication
where nodes often exchange messages via low-power wireless links under
lossy conditions. In this memo, we address the base adaptation of data
chunks to such link layers for the ICN flavors NDN
and CCNx , .The IEEE 802.15.4 link layer is used in
low-power and lossy networks (see LLN in
), in which devices are typically
battery-operated and constrained in resources. Characteristics of LLNs
include an unreliable environment, low bandwidth transmissions, and
increased latencies. IEEE 802.15.4 admits a maximum physical layer
packet size of 127 bytes. The maximum frame header size is 25 bytes,
which leaves 102 bytes for the payload. IEEE 802.15.4 security features
further reduce this payload length by up to 21 bytes, yielding a net of
81 bytes for CCNx or NDN packet headers, signatures and content.6LoWPAN , is a
convergence layer that provides frame formats, header compression and
adaptation layer fragmentation for IPv6 packets in IEEE 802.15.4 networks. The
6LoWPAN adaptation introduces a dispatching framework that prepends
further information to 6LoWPAN packets, including a protocol identifier
for payload and meta information about fragmentation.Prevalent Type-Length-Value (TLV) based packet formats such as in
CCNx and NDN are designed to be generic and extensible. This leads to
header verbosity which is inappropriate in constrained environments of
IEEE 802.15.4 links. This document presents ICN LoWPAN, a convergence
layer for IEEE 802.15.4 motivated by 6LoWPAN. ICN LoWPAN compresses
packet headers of CCNx as well as NDN and allows for an increased
effective payload size per packet. Additionally, reusing the dispatching
framework defined by 6LoWPAN enables compatibility between coexisting
wireless deployments of competing network technologies. This also allows to reuse
the adaptation layer fragmentation scheme specified by 6LoWPAN for ICN LoWPAN.ICN LoWPAN defines a more space efficient representation of CCNx and
NDN packet formats. This syntactic change is described for CCNx and NDN
separately, as the header formats and TLV encodings differ notably. For
further reductions, default header values suitable for constrained IoT
networks are selected in order to elide corresponding TLVs. Experimental
evaluations of the ICN LoWPAN header compression schemes in illustrate a reduced message overhead, a shortened
message airtime, and an overall decline in power consumption for typical
Class 2 devices compared to uncompressed ICN messages.In a typical IoT scenario (see ), embedded devices are interconnected via a quasi-stationary
infrastructure using a border router (BR) that connects the constrained
LoWPAN network by some Gateway with the public Internet. In ICN based
IoT networks, non-local Interest and Data messages transparently travel
through the BR up and down between a Gateway and the embedded devices
situated in the constrained LoWPAN.
The document has received fruitful reviews by members of the ICN community and the research group (see Acknowledgments) for a period of two years.
It is the consensus of ICNRG that this document should be published in the IRTF Stream of the RFC series.
This document does not constitute an IETF standard.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 . The use of the term, "silently ignore" is not
defined in RFC 2119. However, the term is used in this document and can
be similarly construed.This document uses the terminology of , , and for ICN entities.The following terms are used in the document and defined as follows:
Information-Centric Networking over
Low-power Wireless Personal Area NetworkLow-Power and Lossy NetworkContent-Centric Networking ArchitectureNamed Data Networking Architecturesynonym for octetsynonym for 4 bitsa time offset measured in secondsan 8-bit encoded time-valueICN LoWPAN provides a convergence layer that maps ICN packets onto
constrained link-layer technologies. This includes features such as
link-layer fragmentation, protocol separation on the link-layer level,
and link-layer address mappings. The stack traversal is visualized in
. of this document defines the
convergence layer for IEEE 802.15.4.ICN LoWPAN also defines a stateless header compression scheme with
the main purpose of reducing header overhead of ICN packets. This is
of particular importance for link-layers with small MTUs. The
stateless compression does not require pre-configuration of global
state.The CCNx and NDN header formats are composed of Type-Length-Value
(TLV) fields to encode header data. The advantage of TLVs is its
native support of variably structured data. The main disadvantage of
TLVs is the verbosity that results from storing the type and length of
the encoded data.The stateless header compression scheme makes use of compact bit
fields to indicate the presence of optional TLVs in the uncompressed
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
specifying default values and reducing the range of certain header
fields. demonstrates the stateless
header compression idea. In this example, the first type of the first
TLV is removed and the 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 the length fields are removed. The third TLV
represents a boolean TLV (e.g., the MustBeFresh selector in NDN) for
which the type, length and the value fields are elided.Stateless TLV compression for NDN is defined in . defines the stateless
TLV compression for CCNx.The extensibility of this compression is described in and allows future documents to update the
compression rules outlined in this manuscript.ICN LoWPAN further employs two orthogonal stateful compression
schemes for packet size reductions which are defined in . These mechanisms rely on shared
contexts that are either distributed and maintained in the entire
LoWPAN, or are generated on-demand hop-wise on a particular
Interest-data path.The shared context identification is defined in . The hop-wise name compression
"en-route" is specified in .The IEEE 802.15.4 frame header does not provide a protocol
identifier for its payload. This causes problems of misinterpreting
frames when several network layers coexist on the same link. To
mitigate errors, 6LoWPAN defines dispatches as encapsulation headers
for IEEE 802.15.4 frames (see Section 5 of ).
Multiple LoWPAN encapsulation headers can precede the actual payload
and each encapsulation header is identified by a dispatch type. further specifies dispatch pages to switch
between different contexts. When a LoWPAN parser encounters a Page switch LoWPAN encapsulation header, then all
following encapsulation headers are interpreted by using a dispatch
table as specified by the Page switch
header. Page 0 and page 1 are reserved for 6LoWPAN. This document uses
page TBD1 (1111 TBD1 (0xFTBD1)) for ICN LoWPAN.The base dispatch format () is used
and extended by CCNx and NDN in and .The message is compressed.The message is uncompressed.The included protocol is NDN.The included protocol is CCNx.The payload contains an Interest message.The payload contains a Data message.ICN LoWPAN frames with compressed CCNx and NDN messages (C=0) use
the extended dispatch format in .No context identifiers are present.Context identifier(s) are present (see ).No extension bytes are present.Extension byte(s) are present (see ).The encapsulation format for ICN LoWPAN is displayed in .The IEEE 802.15.4 header.Optional additional dispatches
defined in Section 5.1 of Page Switch. TBD1 for ICN LoWPAN.Dispatches as defined in and .The actual (un-)compressed CCNx or NDN
message.Extension bytes allow for the extensibility of the initial
compression rule set. The base format for an extension byte is
depicted in .No other extension byte follows.A further extension byte follows.Extension bytes are numbered according to their order. Future
documents MUST follow the naming scheme EXT_0, EXT_1, ...,
when updating or referring to a specific dispatch extension byte.
Amendments that require an exchange of configurational parameters
between devices SHOULD use manifests to encode structured data in a
well-defined format, as, e.g., outlined in .Small payload sizes in the LoWPAN require fragmentation for various
network layers. Therefore, Section 5.3 of
defines a protocol-independent fragmentation dispatch type, a
fragmentation header for the first fragment, and a separate
fragmentation header for subsequent fragments. ICN LoWPAN adopts this
fragmentation handling of .The Fragmentation LoWPAN header can encapsulate other dispatch
headers. The order of dispatch types is defined in Section 5 of . shows the
fragmentation scheme. The reassembled ICN LoWPAN frame does not
contain any fragmentation headers and is depicted in .The 6LoWPAN Fragment Forwarding (6FF) is an alternative
approach that enables forwarding of fragments without
reassembling packets on every intermediate hop. By reusing the
6LoWPAN dispatching framework, 6FF integrates into ICN LoWPAN
as seamless as the conventional hop-wise
fragmentation. Experimental evaluations , however, suggest that a more refined
integration can increase the cache utilization of forwarders
on a request path.The NDN packet format consists of TLV fields using the TLV encoding
that is described in . Type and length
fields are of variable size, where numbers greater than 252 are
encoded using multiple bytes.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 greater or equals 253 and
fits into 2 bytes, then the type or length field is set to 253 and the number is encoded in the next
following 2 bytes in network byte order, i.e., from the most
significant byte (MSB) to the least significant byte (LSB). If the
number is greater than 2 bytes and fits into 4 bytes, then the type
or length field is set to 254 and the
number is encoded in the subsequent 4 bytes in network byte order.
For larger numbers, the type or length field is set to 255 and the number is encoded in the subsequent 8
bytes in network byte order.In this specification, compressed NDN TLVs make use of a different
TLV encoding scheme that reduces size. Instead of using the first
byte as a marker for the number of following bytes, the compressed
NDN TLV scheme uses a method to chain a variable number of bytes
together. If a byte equals 255 (0xFF),
then the following byte will also be interpreted. The actual value of
a chain equals the sum of all constituents.If the type or length number is less than 255,
then that number is encoded into the actual type or length field
( a). If the type or length
number (X) fits into 2 bytes, then the first byte is set to 255 and the subsequent byte equals X mod 255 (
b). Following this scheme, a variable-sized number (X) is encoded
using multiple bytes of 255 with a
trailing byte containing X mod 255 ( c).This Name TLV compression encodes length fields of two consecutive
NameComponent TLVs into one byte, using a nibble for each.
The most significant nibble indicates the length of an immediately following NameComponent TLV.
The least significant nibble denotes the length of a subsequent NameComponent TLV.
A length of 0 marks the end of the compressed Name TLV.
The last length field of an encoded NameComponent is either 0x00 for a name with an even number of components,
and 0xYF (Y > 0) if an odd number of components are present.
This process limits the length of a NameComponent TLV to 15 bytes, but allows for an unlimited number of components.
An example for this encoding is presented in .An uncompressed Interest message uses the base dispatch format
(see ) and sets the C flag to
1 and the P as well as the M
flag to 0 ().
The Interest message is handed to the NDN network stack without modifications.The compressed Interest message uses the extended dispatch format
() and sets the P flag to 0,
the C flag to 0 and the M flag to 0.
If an Interest message contains TLVs that are not mentioned in the
following compression rules, then this message MUST be sent
uncompressed.This specification assumes that a HopLimit TLV is part of the
original Interest message. If such HopLimit TLV is not present, it
will be inserted with a default value of DEFAULT_NDN_HOPLIMIT prior to
the compression.In the default use case, the Interest message is compressed with
the following minimal rule set: The Type field of the outermost
MessageType TLV is removed.The Name TLV is compressed according to . For this, all NameComponents
are expected to be of type GenericNameComponent with a length
greater than 0. An ImplicitSha256DigestComponent or
ParametersSha256DigestComponent MAY appear at the end of the
name. In any other case, the message MUST be sent
uncompressed.The Nonce TLV and InterestLifetime TLV are moved to the end of the compressed
Interest as illustrated in .
The InterestLifetime is encoded as described in . If a lifetime is not a valid time-value,
then the lifetime is rounded up to the nearest valid time-value
as specified in .The Type and Length fields of Nonce TLV, HopLimit TLV and
InterestLifetime TLV are elided. The Nonce value has a length of
4 bytes and the HopLimit value has a length of 1 byte. The
compressed InterestLifetime () has a
length of 1 byte. The presence of a Nonce and InterestLifetime TLV is
deduced 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 a nonce, and a length of 5 indicates
the presence of both TLVs.The compressed NDN LoWPAN Interest message is visualized in .Further TLV compression is indicated by the ICN LoWPAN dispatch
in .See .No extension byte follows.Extension byte EXT_0
follows immediately. See .The uncompressed message does not include a
CanBePrefix TLV.The uncompressed message does include a
CanBePrefix TLV and is removed from the compressed
message.The uncompressed message does not include a
MustBeFresh TLV.The uncompressed message does include a
MustBeFresh TLV and is removed from the compressed
message.The uncompressed message does not include a
ForwardingHint TLV.The uncompressed message does include a
ForwardingHint TLV. The Type field is removed from the
compressed message. Further, all link delegation types and
link preference types are removed. All included names are
compressed according to . If any name is not
compressible, the message MUST be sent uncompressed.The uncompressed message does not include
an ApplicationParameters TLV.The uncompressed message does include an
ApplicationParameters TLV. The Type field is removed from
the compressed message.The name does not include an
ImplicitSha256DigestComponent as the last TLV.The name does include an
ImplicitSha256DigestComponent as the last TLV. The Type and
Length fields are omitted.Must be set to 0.The EXT_0 byte follows the
description in and is illustrated
in .Names are compressed with the default name
compression strategy (see ).Reserved.Reserved.Reserved.Must be set to 0.No extension byte follows.A further extension byte follows
immediately.An uncompressed Data message uses the base dispatch format and
sets the C as well as the M flag to 1 and the P flag to
0 ().
The Data message is handed to the NDN network stack without modifications.The compressed Data message uses the extended dispatch format
() and sets the C as well as the P flag to 0. The M
flag is set to 1. If a Data message
contains TLVs that are not mentioned in the following compression
rules, then this message MUST be sent uncompressed.By default, the Data message is compressed with the following
base rule set: The Type field of the outermost
MessageType TLV is removed.The Name TLV is compressed according to . For this, all NameComponents
are expected to be of type GenericNameComponent and to have a
length greater than 0. In any other case, the message MUST be
sent uncompressed.The MetaInfo TLV Type and Length fields are elided from the
compressed Data message.The FreshnessPeriod TLV MUST be moved to the end of the
compressed Data message. Type and
Length fields are elided and the value is encoded as described
in as a 1-byte time-code. If the freshness period is not
a valid time-value, then the message MUST be sent uncompressed
in order to preserve the security envelope of the Data message.
The presence of a FreshnessPeriod TLV is deduced from the
remaining one byte length to parse.The Type fields of the SignatureInfo TLV, SignatureType TLV
and SignatureValue TLV are removed.The compressed NDN LoWPAN Data message is visualized in .Further TLV compression is indicated by the ICN LoWPAN dispatch
in .See .No extension byte follows.Extension byte EXT_0
follows immediately. See .The uncompressed message does not include a
FinalBlockId TLV.The uncompressed message does include a
FinalBlockId and it is encoded according to . If the FinalBlockId TLV
is not compressible, then the message MUST be sent
uncompressed.The uncompressed message does not include a
ContentType TLV.The uncompressed message does include a
ContentType TLV. The Type field is removed from the
compressed message.If the included SignatureType requires a
KeyLocator TLV, then the KeyLocator represents a name and is
compressed according to . If the name is not
compressible, then the message MUST be sent
uncompressed.If the included SignatureType requires a
KeyLocator TLV, then the KeyLocator represents a KeyDigest.
The Type field of this KeyDigest is removed.Must be set to 0.The EXT_0 byte follows the
description in and is illustrated
in .Names are compressed with the default name
compression strategy (see ).Reserved.Reserved.Reserved.Must be set to 0.No extension byte follows.A further extension byte follows
immediately.The generic CCNx TLV encoding is described in . Type and Length fields attain the common fixed
length of 2 bytes.The TLV encoding for CCNx LoWPAN is changed to the more space
efficient encoding described in .
Hence NDN and CCNx use the same compressed format for writing
TLVs.Name TLVs are compressed using the scheme already defined in for NDN. If a Name TLV contains
T_IPID, T_APP, or organizational TLVs, then the name remains
uncompressed.An uncompressed Interest message uses the base dispatch format
(see ) and sets the C as well as the P flag to 1.
The M flag is set to 0 ().
The Interest message is handed to the CCNx network stack without modifications.The compressed Interest message uses the extended dispatch format
() and sets the C and M flags to 0. The P flag is set to 1.
If an Interest message contains TLVs that are not mentioned in the
following compression rules, then this message MUST be sent
uncompressed.In the default use case, the Interest message is compressed with
the following minimal rule set: 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
.Further TLV compression is indicated by the ICN LoWPAN dispatch
in .See .No extension byte follows.Extension byte EXT_0
follows immediately. See .The Version field equals 1 and is removed
from the fixed header.The Version field appears in the fixed header.The Flags field equals 0 and is removed
from the Interest message.The Flags field appears in the fixed header.The PacketType field is elided and assumed
to be PT_INTEREST.The PacketType field is elided and assumed
to be PT_RETURN.The HopLimit field appears in the fixed header.The HopLimit field is elided and assumed to
be 1.The Reserved field appears in the fixed header.The Reserved field is elided and assumed to
be 0.The Payload TLV is absent.The Payload TLV is present and the type
field is elided.See for further details
on the ordering of hop-by-hop TLVs.No InterestLifetime TLV is present in the
Interest message.An InterestLifetime TLV is present with a
fixed length of 1 byte and is encoded as described in . The type and length fields are
elided. If a lifetime is not a valid time-value, then the
lifetime is rounded up to the nearest valid time-value (see
).See for further details
on the ordering of hop-by-hop TLVs.This TLV is expected to contain a T_SHA-256 TLV. If
another hash is contained, then the Interest MUST be sent
uncompressed.The MessageHash TLV is absent.A T_SHA-256 TLV is present and the type as
well as the length fields are removed. The length field is
assumed to represent 32 bytes. The outer Message Hash TLV
is omitted.This TLV is expected to contain a T_SHA-256 TLV. If
another hash is contained, then the Interest MUST be sent
uncompressed.The KeyIdRestriction TLV is absent.A T_SHA-256 TLV is present and the type as
well as the length fields are removed. The length field is
assumed to represent 32 bytes. The outer KeyIdRestriction
TLV is omitted.This TLV is expected to contain a T_SHA-256 TLV. If
another hash is contained, then the Interest MUST be sent
uncompressed.The ContentObjectHashRestriction TLV is
absent.A T_SHA-256 TLV is present and the type as
well as the length fields are removed. The length field is
assumed to represent 32 bytes. The outer
ContentObjectHashRestriction TLV is omitted.No validation related TLVs are present in
the Interest message.Validation related TLVs are present in the
Interest message. An additional byte follows immediately
that handles validation related TLV compressions and is
described in .Hop-By-Hop Header TLVs are unordered. For an Interest message,
two optional Hop-By-Hop Header TLVs are defined in , but several more can be defined in higher
level specifications. For the compression specified in the
previous section, the Hop-By-Hop TLVs are ordered as follows:
Interest Lifetime TLVMessage Hash TLVNote: 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 original message, but after the Interest Lifetime TLV and Message Hash TLV.An uncompressed ValidationAlgorithm
TLV is included.A T_CRC32C ValidationAlgorithm TLV is
assumed, but no ValidationAlgorithm TLV is included.A T_CRC32C ValidationAlgorithm TLV is
assumed, but no ValidationAlgorithm TLV is included.
Additionally, a Sigtime TLV is inlined without a type and
a length field.A T_HMAC-SHA256 ValidationAlgorithm
TLV is assumed, but no ValidationAlgorithm TLV is
included.A T_HMAC-SHA256 ValidationAlgorithm
TLV is assumed, but no ValidationAlgorithm TLV is included.
Additionally, a Sigtime TLV is inlined without a type and
a length field.Reserved.Reserved.Reserved.Reserved.Reserved.Reserved.Reserved.Reserved.Reserved.Reserved.Reserved.The KeyId TLV is absent.The KeyId TLV is present and
uncompressed.A T_SHA-256 TLV is present and the type
field as well as the length fields are removed. The length
field is assumed to represent 32 bytes. The outer KeyId
TLV is omitted.A T_SHA-512 TLV is present and the type
field as well as the length fields are removed. The length
field is assumed to represent 64 bytes. The outer KeyId
TLV is omitted.Must be set to 0.The ValidationPayload TLV is present if the ValidationAlgorithm
TLV is present. The type field is omitted.The EXT_0 byte follows the
description in and is illustrated
in .Names are compressed with the default name
compression strategy (see ).Reserved.Reserved.Reserved.Must be set to 0.No extension byte follows.A further extension byte follows
immediately.An uncompressed Content object uses the base dispatch format (see
) and sets the C, P and M flags to
1 ().
The Content object is handed to the CCNx network stack without modifications.The compressed Content object uses the extended dispatch format
() and sets the P as well
as the M flag to 1.
The C flag is set to 0.
If a Content object
contains TLVs that are not mentioned in the following compression
rules, then this message MUST be sent uncompressed.By default, the Content object is compressed with the following
base rule set: The PacketType field is elided from the Fixed Header.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 .Further TLV compression is indicated by the ICN LoWPAN dispatch
in .See .No extension byte follows.Extension byte EXT_0
follows immediately. See .The Version field equals 1 and is removed
from the fixed header.The Version field appears in the fixed header.See .See .See .The Recommended Cache Time TLV is
absent.The Recommended Cache Time TLV is present
and the type as well as the length fields are elided.See for further details
on the ordering of hop-by-hop TLVs.This TLV is expected to contain a T_SHA-256 TLV. If
another hash is contained, then the Content Object MUST be
sent uncompressed.The MessageHash TLV is absent.A T_SHA-256 TLV is present and the type as
well as the length fields are removed. The length field is
assumed to represent 32 bytes. The outer Message Hash TLV
is omitted.The PayloadType TLV is absent.The PayloadType TLV is absent and
T_PAYLOADTYPE_DATA is assumed.The PayloadType TLV is absent and
T_PAYLOADTYPE_KEY is assumed.The PayloadType TLV is present and
uncompressed.The ExpiryTime TLV is absent.The ExpiryTime TLV is present and the type
as well as the length fields are elided.See
.Must be set to 0.Hop-By-Hop Header TLVs are unordered. For a Content Object
message, two optional Hop-By-Hop Header TLVs are defined in , but several more can be defined in higher
level specifications. For the compression specified in the
previous section, the Hop-By-Hop TLVs are ordered as follows:
Recommended Cache Time TLVMessage Hash TLVNote: 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 original message, but after the Recommended Cache Time TLV and Message Hash TLV.The EXT_0 byte follows the
description in and is illustrated
in .Names are compressed with the default name
compression strategy (see ).Reserved.Reserved.Reserved.Must be set to 0.No extension byte follows.A further extension byte follows
immediately.This document adopts the compact time representation for relative time values.
Exponent and mantissa values are encoded in a 1-byte wide
representation as depicted in .
The exponent occupies the most significant bits, while the mantissa uses the least significant bits.The mantissa size is set to 3 bits, the exponent size to 5 bits, and
a bias of -5 is applied. This allows for a time representation that
ranges from tens of milliseconds with high precision to days with low precision.
The base unit for time values are seconds. A time-value is calculated
using the following formula, where (e) represents the exponent, (m) the
mantissa, (m_max = 8) the maximum mantissa value, and (b) the bias.
(0 + m/m_max) * 2^(1+b)(1 + m/m_max) * 2^(e+b) The subnormal form provides a gradual underflow from the
smallest normalized number towards zero.This configuration allows for the following ranges: Minimum subnormal number: 0 secondsMaximum subnormal number: ~0.054688 secondsMinimum normalized number: ~0.062500 secondsMaximum normalized number: ~3.987284 yearsValid time-values are positive numbers, including 0. An invalid time-value
(t, in seconds) MUST be rounded down to the nearest valid time-value
using this algorithm, where (e) represents the number of bits for the
exponent, (m) the number of bits for the mantissa, and (m_max = 8) the
maximum mantissa value. The bias (b) is set to -5 as before. e := floor( log2( t/(2^-b) ))m := floor( 8 * (t / 2^(e+b) - 1 ))Stateful header compression in ICN LoWPAN enables packet size
reductions in two ways. First, common information that is shared
throughout the local LoWPAN may be memorized in context state at all
nodes and omitted from communication. Second, redundancy in a single
Interest-data exchange may be removed from ICN stateful forwarding on a
hop-by-hop bases and memorized in en-route state tables.A context identifier (CID) is a byte that refers to a particular
conceptual context between network devices and MAY be used to replace
frequently appearing information, such as name prefixes, suffixes, or
meta information, such as Interest lifetime.The 7-bit ContextID is a locally-scoped unique identifier that
represents contextual state shared between sender and receiver of the
corresponding frame (see ).
If set the most significant bit indicates the presence of another, subsequent
ContextID byte (see ).Context state shared between senders and receivers is removed from the
compressed packet prior to sending, and reinserted after reception
prior to passing to the upper stack.The actual information in a context and how it is encoded are out of scope of this document.
The initial distribution and maintenance of shared context is out
of scope of this document. Frames containing unknown or invalid CIDs MUST be silently discarded.In CCNx and NDN, Name TLVs are included in Interest messages, and
they return in data messages. Returning Name TLVs either equal the
original Name TLV, or they contain the original Name TLV as a prefix.
ICN LoWPAN reduces this redundancy in responses by replacing Name TLVs
with single bytes that represent link-local HopIDs. HopIDs are
carried as Context Identifiers (see ) of link-local scope as shown in .A HopID is valid if not all ID bits are set to zero and invalid
otherwise. This yields 127 distinct HopIDs. If this range (1...127) is
exhausted, the messages MUST be sent without en-route state
compression until new HopIDs are available. An ICN LoWPAN node that
forwards without replacing the name by a HopID (without en-route
compression) MUST invalidate the HopID by setting all ID-bits to
zero.While an Interest is traversing, a forwarder generates an ephemeral
HopID that is tied to a PIT entry. Each HopID MUST be unique within
the local PIT and only exists during the lifetime of a PIT entry. To
maintain HopIDs, the local PIT is extended by two new columns: HIDi
(inbound HopIDs) and HIDo (outbound HopIDs).HopIDs are included in Interests and stored on the next hop with
the resulting PIT entry in the HIDi column. The HopID is replaced with
a newly generated local HopID before the Interest is forwarded. This
new HopID is stored in the HIDo column of the local PIT (see ). Responses include HopIDs that were obtained from Interests. If the
returning Name TLV equals the original Name TLV, then the name is
entirely elided. Otherwise, only the matching name prefix is elided and
the distinct name suffix is included along with
the HopID. When a response is forwarded, the contained HopID is
extracted and used to match against the correct PIT entry by
performing a lookup on the HIDo column. The HopID is then replaced
with the corresponding HopID from the HIDi column prior to forwarding
the response (). It should be noted that each forwarder of an Interest in an ICN
LoWPAN network can individually decide whether to participate in
en-route compression or not. However, an ICN LoWPAN node SHOULD use
en-route compression whenever the stateful compression mechanism is
activated.Note also that the extensions of the PIT data structure are
required only at ICN LoWPAN nodes, while regular NDN/CCNx forwarders
outside of an ICN LoWPAN domain do not need to implement these
extensions.A CID appears whenever the CID flag is set (see ). The CID is appended to the last ICN
LoWPAN dispatch byte as shown in .Multiple CIDs are chained together, with the most significant bit
indicating the presence of a subsequent CID (). This allows to use multiple shared contexts in compressed messages.The HopID is always included as the very first CID.This is a summary of all ICN LoWPAN constants and variables. 255The ICN LoWPAN scheme defined in this document has been implemented as
an extension of the NDN/CCNx software stack in
its IoT version on RIOT . An experimental
evaluation for NDN over ICN LOWPAN with varying configurations has been
performed in . Energy profilings and
processing time measurements indicate significant energy savings, while
amortized costs for processing show no penalties.The header compression performance depends on certain aspects and
configurations. It works best for the following cases: Relative time values use a compressible encoding as per .Contextual state (e.g., prefixes) is distributed, such that
long names can be elided from Interest and data messages.Frequently used TLV type numbers for CCNx and NDN stay
in the lower range (< 255).
Name components are of GenericNameComponent type and are limited to a
length of 15 bytes to enable compression for all messages.An investigation of ICN LoWPAN in large-scale deployments
with varying traffic patterns using larger samples of the
different board types available remains as future work. This
document will be revised to progress it to the Standards
Track, once sufficient operational experience has been
acquired. Experience reports are encouraged, particularly in
the following areas:
The name compression scheme () is optimized for short
name components of GenericNameComponent type. An empirical
study on name lengths in different deployments of selected
use cases, such as smart home, smart city, and industrial
IoT can provide meaningful reports on necessary name
component types and lengths. A conclusive outcome helps to
understand whether and how extension mechanisms are needed
(). As a preliminary
analysis, investigates the
effectiveness of the proposed compression scheme with URLs
obtained from the WWW. Studies on CoAP deployments can offer additional insights
on naming schemes in the IoT.The fragmentation scheme () inherited from 6LoWPAN allows
for a transparent, hop-wise reassembly of CCNx or NDN
packets. Fragment forwarding with selective
fragment recovery can improve the
end-to-end latency and reliability, while it reduces buffer
requirements on forwarders. Initial evaluations () show that a naive integration of
these upcoming fragmentation features into ICN LoWPAN
renders the hop-wise content replication inoperative, since
Interest and data messages are reassembled end-to-end. More
deployment experiences are necessary to gauge the
feasibility of different fragmentation schemes in ICN
LoWPAN.
Context state () holds information
that is shared between a set of devices in a LoWPAN. Fixed
name prefixes and suffixes are good candidates to be
distributed to all nodes in order to elide them from request
and response messages. More experience and a deeper
inspection of currently available and upcoming protocol
features is necessary to identify other protocol fields.The distribution and synchronization of contextual state
can potentially be adopted from Section 7.2 of , but requires further evaluations. While
6LoWPAN uses the Neighbor Discovery protocol to disseminate
state, CCNx and NDN deployments are missing out on a
standard mechanism to bootstrap and manage
configurations.The stateful en-route compression () supports a limited
number of 127 distinct HopIDs that can be simultaneously in
use on a single node. Complex deployment scenarios that make
use of multiple, concurrent requests can provide a better
insight on the number of open requests stored in the Pending
Interest Table of memory-constrained devices. This number
can serve as an upper-bound and determines whether the HopID
length needs to be resized to fit more HopIDs to the cost of
additional header overhead.Multiple implementations that generate and deploy the
compression options of this memo in different ways will also
add to the experience and understanding of the benefits and
limitations of the proposed schemes. Different reports can
help to illuminate on the complexity of implementing ICN
LoWPAN for constrained devices, as well as on maintaining
interoperability with other implementations.Main memory is typically a scarce resource of constrained networked
devices. Fragmentation as described in this memo preserves fragments and
purges them only after a packet is reassembled, which requires a
buffering of all fragments. This scheme is able to handle fragments for
distinctive packets simultaneously, which can lead to overflowing packet
buffers that cannot hold all necessary fragments for packet reassembly.
Implementers are thus urged to make use of appropriate buffer
replacement strategies for fragments. The upcoming minimal fragment forwarding
can potentially prevent fragment buffer saturation in forwarders.The stateful header compression generates ephemeral HopIDs for
incoming and outgoing Interests and consumes them on returning Data
packets. Forged Interests can deplete the number of available HopIDs,
thus leading to a denial of compression service for subsequent content
requests.To further alleviate the problems caused by forged fragments or
Interest initiations, proper protective mechanisms for accessing the
link-layer should be deployed. IEEE 802.15.4, e.g., provides capabilities to protect frames and restrict them to a point-to-point link, or a group of devices.IANA has assigned dispatch values of the 6LoWPAN Dispatch Type Field
registry with Page
TBD1 for ICN LoWPAN. represents updates to the registry.Bit PatternPageHeader Type00 000000TBD1Uncompressed NDN Interest messages00 100000TBD1Uncompressed NDN Data messages01 000000TBD1Uncompressed CCNx Interest messages01 100000TBD1Uncompressed CCNx Content Object messages10 0xxxxxTBD1Compressed NDN Interest messages10 1xxxxxTBD1Compressed NDN Data messages11 0xxxxxTBD1Compressed CCNx Interest messages11 1xxxxxTBD1Compressed CCNx Content Object messagesIEEE Std. 802.15.4-2015CCN-lite: A lightweight CCNx and NDN implementationRIOT: an Open Source Operating System for Low-end Embedded
Devices in the IoTINRIAHAW HamburgINRIA and FU BerlinHAW HamburgFU BerlinFU BerlinINRIA and FU BerlinHAW HamburgFU BerlinInformation Centric Networking in the IoT: Experiments with
NDN in the WildINRIAFU BerlinINRIAHAW HamburgFU BerlinNDN, CoAP, and MQTT: A Comparative Measurement Study in the
IoTHAW HamburgHAW HamburgFU BerlinFU BerlinHAW HamburgFU BerlinThe Need for a Name to MAC Address Mapping in NDN: Towards
Quantifying the Resource GainHAW HamburgHAW HamburgHAW Hamburgriot-os.orgFU BerlinConnecting the Dots: Selective Fragment Recovery in
ICNLoWPANFU BerlinHAW HamburgHAW HamburgFU BerlinNetworking Named ContentNDN Packet Format SpecificationCCN and NDN TLV encodings in 802.15.4 packetsCCN/NDN Protocol Wire Format and Functionality
ConsiderationsICNLoWPAN -- Named-Data Networking in Low Power IoT
NetworksHAW HamburgHAW HamburgHAW HamburgFU BerlinAn Alternative Delta Time encoding for CCNx using Interval
Time from RFC5497In the following a theoretical evaluation is given to estimate the
gains of ICN LoWPAN compared to uncompressed CCNx and NDN messages.We assume that n is the number of name
components, comps_n denotes the sum of n
name component lengths. We also assume that the length of each name
component is lower than 16 bytes. The length of the content is given by
clen. The lengths of TLV components is
specific to the CCNx or NDN encoding and outlined below.The NDN TLV encoding has variable-sized TLV fields. For simplicity,
the 1 byte form of each TLV component is assumed. A typical TLV
component therefore is of size 2 (type field + length field) + the
actual value. depicts the
size requirements for a basic, uncompressed NDN Interest containing
a CanBePrefix TLV, a MustBeFresh TLV, a InterestLifetime TLV set to
4 seconds and a HopLimit TLV set to 6. Numbers below represent the
amount of bytes. depicts the
size requirements after compression.The size difference is: 11 + 1.5n bytes.For the name /DE/HH/HAW/BT7, the
total size gain is 17 bytes, which is 43% of the uncompressed
packet. depicts the size
requirements for a basic, uncompressed NDN Data containing a
FreshnessPeriod as MetaInfo. A FreshnessPeriod of 1 minute is
assumed and the value is encoded using 1 byte. An HMACWithSha256 is
assumed as signature. The key locator is assumed to contain a Name
TLV of length klen. depicts the size
requirements for the compressed version of the above Data
packet.The size difference is: 15 + 1.5n bytes.For the name /DE/HH/HAW/BT7, the
total size gain is 21 bytes.The CCNx TLV encoding defines a 2-byte encoding for type and
length fields, summing up to 4 bytes in total without a value. depicts the
size requirements for a basic, uncompressed CCNx Interest. No
Hop-By-Hop TLVs are included, the protocol version is assumed to be
1 and the reserved field is assumed to be 0. A KeyIdRestriction TLV
with T_SHA-256 is included to limit the responses to Content Objects
containing the specific key. depicts the
size requirements after compression.The size difference is: 18 + 3.5n bytes.For the name /DE/HH/HAW/BT7, the size
is reduced by 53 bytes, which is 53% of the uncompressed
packet. depicts the size
requirements for a basic, uncompressed CCNx Content Object
containing an ExpiryTime Message TLV, an HMAC_SHA-256 signature, the
signature time and a hash of the shared secret key. In the fixed
header, the protocol version is assumed to be 1 and the reserved
field is assumed to be 0 depicts the size
requirements for a basic, compressed CCNx Data.The size difference is: 35 + 3.5n bytes.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.This work was stimulated by fruitful discussions in the ICNRG
research group and the communities of RIOT and CCNlite. We would like to
thank all active members for constructive thoughts and feedback. In
particular, the authors would like to thank (in alphabetical order)
Peter Kietzmann, Dirk Kutscher, Martine Lenders, Colin Perkins, Junxiao Shi. The
hop-wise stateful name compression was brought up in a discussion by
Dave Oran, which is gratefully acknowledged. Larger parts of this work
are inspired by and .
Special mentioning goes to Mark Mosko as well as G.Q. Wang and Ravi
Ravindran as their previous work in
and provided a good base for our
discussions on stateless header compression mechanisms.
Many thanks also to Carsten Bormann, who contributed in-depth comments during the IRSG review.
This work was supported in part by the German Federal Ministry of Research and
Education within the projects I3 and RAPstore.