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 GroupIn this document, a convergence layer for CCNx and NDN over IEEE
802.15.4 LoWPAN networks is defined. A new frame format is specified to
adapt CCNx and NDN packets to the small MTU size of IEEE 802.15.4. 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 link 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.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 octets. The maximum frame header size is 25 octets,
which leaves 102 octets for the payload. IEEE 802.15.4 security features
further reduce this payload length by up to 21 octets, yielding a net of
81 octets for CCNx or NDN packet headers, signatures and content.6LoWPAN , is a
convergence layer that provides frame formats, header compression and
link 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 IEEE 802.15.4 payload and meta information about link
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 that compresses packet
headers of CCNx as well as NDN and allows for an increased payload size
per packet. Additionally, reusing the dispatching framework defined by
6LoWPAN enables compatibility between coexisting wireless networks of
competing technologies. This also allows to reuse the link 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 largely. 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 uplinks 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 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 ArchitectureICN 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 variable-sized 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 mandatory and 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
codomain 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) and
is missing the type, length and the value field.Stateless TLV compression for NDN is defined in . defines the stateless
TLV compression for CCNx.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 prepend 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 2 (1111 0010 (0xF2)) for NDN and page
3 (1111 0011 (0xF3)) for CCNx.The base dispatch format () is used
and extended by CCNx and NDN in and .The message is uncompressed.The message is compressed.The payload contains an Interest message.The payload contains a Data message.ICN LoWPAN frames with compressed CCNx and NDN messages (C=1) use
the extended dispatch format in .No context identifiers are present.1..n context identifiers are present.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. 2 for NDN and 3 for CCNx.Dispatches defined in and .The actual (un-)compressed CCNx or NDN
message.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 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 octets.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 octets, then the type or lengh field is set to 253 and the number is encoded in the next
following 2 octets 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 octets and fits into 4 octets, then the type
or length field is set to 254 and the
number is encoded in the subsequent 4 octets 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
octets 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
octet as a marker for the number of following octets, the compressed
NDN TLV scheme uses a method to chain a variable number of octets
together. If an octet equals 255 (0xFF),
then the following octet will also be interpreted. The actual value of
a chain equals the sum of all links.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 octets, then the first octet is set to 255 and the subsequent octet equals X mod 255 (
b). Following this scheme, a variable-sized number (X) is encoded
using multiple octets of 255 with a
trailing octet containing X mod 255 ( c).This Name TLV compression encodes length fields of two consecutive
NameComponent TLVs into one octet, using 4 bits each. This process
limits the length of a NameComponent TLV to 15 octets. A length of 0
marks the end of the compressed Name TLV.An uncompressed Interest message uses the base dispatch format
(see ) and sets the C as well as the M
flag to 0 (). resv
MUST be set 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 C flag to 1 and the M flag to 0.
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. Otherwise, the
message MUST be sent uncompressed.The InterestLifetime TLV length is set to 2 and the time 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 ).The Nonce TLV, InterestLifetime TLV and HopLimit TLV MUST be
moved to the end of the compressed Interest, keeping the order
1) Nonce TLV, 2) InterestLifetime TLV and 3) HopLimit TLV.The Type and Length fields of Nonce TLV, InterestLifetime TLV
and HopLimit TLV are elided. The presence of each TLV is deduced
from the remaining length to parse. The Nonce TLV has a fixed
length of 4, the InterestLifetime TLV has a fixed length of 2
and the HopLimit TLV has a fixed length of 1. Any combination
yields a distinct value that matches the remaining length to
parse.The compressed NDN LoWPAN Interest message is visualized in .Further TLV compression is indicated by the ICN LoWPAN dispatch
in .See .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.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.The uncompressed message does not include a
Parameters TLV.The uncompressed message does include a
Parameters TLV. The Type field is removed from the
compressed message.An uncompressed Data message uses the base dispatch format and
sets the C flag to 0 and the M flag to
1 (). resv
MUST be set 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 flag as well
as the M flag to 1. 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. Otherwise, the
message MUST be sent uncompressed.The MetaInfo Type and Length fields are elided from the
compressed Data message.If present, the FinalBlockId TLV is encoded according to
.The ContentType TLV length is set to 1. Messages with
ContentTypes that require more than 1 octet MUST be sent
uncompressed.The FreshnessPeriod TLV length is set to 2 and the time is
encoded as described in .
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 FreshnessPeriod TLV and ContntType TLV MUST be moved to
the end of the compressed Data, keeping the order 1)
FreshnessPeriod TLV and 2) ContentType TLV.The Type and Length fields of ContentType TLV and
FreshnessPeriod TLV are elided. The presence of each TLV is
deduced from the remaining length to parse. The FreshnessPeriod
TLV has a fixed length of 2 and the ContentType TLV has a fixed
length of 1. Any combination yields a distinct value that
matches the remaining length to parse.The compressed NDN LoWPAN Data message is visualized in .Further TLV compression is indicated by the ICN LoWPAN dispatch
in .See .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.The uncompressed message does not include a
FinalBlockId TLV.The uncompressed message does include a
FinalBlockId.The uncompressed message does not include a
Content TLV.The uncompressed message does include a
Content TLV. The Type field is removed from the compressed
message.The Type fields of the SignatureInfo TLV,
SignatureType TLV and SignatureValue TLV are removed.Reserved.Reserved.Reserved.The generic CCNx TLV encoding is described in . Type and Length fields attain
the common fixed length of 2 octets.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 M
flag to 0 (). resv
MUST be 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 flag to 1 and the M flag to 0.
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 .The Version field equals 1 and is removed
from the fixed header.The Version field is carried in-line.The Flags field equals 0 and is removed
from the Interest message.The Flags field is carried in-line.The PacketType field is elided and assumed
to be PT_INTERESTThe PacketType field is elided and assumed
to be PT_RETURNThe HopLimit field is carried in-lineThe HopLimit field is elided and assumed to
be 1The Reserved field is carried in-lineThe Reserved field is elided and assumed to
be 0The 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 2 octets 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 octets. 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 octets. 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 octets. 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 octet follows immediately
that handles validation related TLV compressions and is
described in .No extension octet follows.An extension octet follows immediately.
Extension octets are used to extend the compression scheme,
but are out of scope of this document.Must be set to 0.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 a compressed
representation, this document defines the following ordering of
Hop-By-Hop TLVs: Interest Lifetime TLVMessage Hash TLVNote: If the original Interest message includes Hop-By-Hop
Header TLVs that follow a different ordering, then the message
MUST be sent uncompressed.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 inclued.
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 octets. 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 octets. The outer KeyId
TLV is omitted.The ValidationPayload TLV is present if the ValidationAlgorithm
TLV is present. The type field is omitted.An uncompressed Content object uses the base dispatch format (see
) and sets the C flag to 0 and the M flag to 1
(). resv
MUST be set to 0. The Content object is handed to the CCNx network
stack without modifications.The compressed Content object uses the extended dispatch format
() and sets the C flag as well
as the M flag to 1. 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 .The Version field equals 1 and is removed
from the fixed header.The Version field is carried in-line.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 octets. 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.Must be set to 0.See
.See .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 better compression, an
ordering of Hop-By-Hop TLVs is required as follows: Recommended Cache Time TLVMessage Hash TLV With this ordering in place, Type fields are elided from
the Recommended Cache Time TLV and Message Hash TLV.Note: If the original Content Object message includes
Hop-By-Hop Header TLVs with a different ordering, then they remain
uncompressed.This document defines a compressed TLV encoding format for time-values that is
inspired from . 16-bit time-codes are used to represent
time-values ranging from milliseconds to days.
Time-codes are constructed using the formula:
time-code := 2048 * b + a
where a is the mantissa and b the exponent of a time-value that follows the form:
time-value := (1 + a/2048) * 2^b * C
The least significant 11 bits of a time-code represents the mantissa (a) and the most
significant 5 bits represent the exponent (b). C is set to 1/1024 seconds in order to
achieve a millisecond resolution.
A time-code of all-bits zero MUST be decoded as a time-value of all-bits zero.
The smallest representable time-value is thus 0 (a=0, b=0), the second smallest is ~0.9 ms (a=1, b=0),
and the largest time-value is ~48 days (a=2047, b=31).
An invalid time-value (t, in seconds) MAY be rounded up to the nearest valid time-value using this algorithm:
set b := floor(log2(t/C))set a := 2048 * (t / (C * 2^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 ommitted 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 an octet that refers to a particular
conceptual context between network devices and MAY be used to replace
frequently appearing information, like name prefixes, suffixes, or
meta information, such as Interest lifetime.The ContextID refers to a locally-scoped unique identifyer that
represents contextual state shared between sender and receiver of the
corresponding frame (see ).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 octets that represent link-local HopIDs. HopIDs are
carried as Context Identifiers 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...128) 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, the distinct suffix is included along with
the HopID. When a response is forwarded, the contained HopID is
extracted and used to match against the correct PIT entry by
performing a lookup on the HIDo column. The HopID is then replaced
with the corresponding HopID from the HIDi column prior to forwarding
the reponse (). It should be noted that each forwarder of an Interest in an ICN
LoWPAN network can individuall decide whether to paricipate 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 octet as shown in .Multiple CIDs are chained together, with the most significant bit
indicating the presence of a subsequent CID ().The HopID is always included as the very first CID.The 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
with varying configurations is performed in .The header compression performance depends on certain aspects and configurations.
It works best for the following cases:
Each name component is of GenericNameComponent type and is limited to a length of 15 bytes.Time-values for content freshness TLVs represent valid time-values as per . Interest lifetimes will round up to the nearest valid encoded time-value.Contextual state is distributed, such that long names are elided from Interest and data messages.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 which cannot hold all necessary fragments for packet reassembly.
Implementers are thus urged to make use of appropriate buffer
replacement strategies for fragments.The stateful header compression generates ephemeral HopIDs for
incoming and outgoing Interests and consumes them on returning Data
packets. Forged Interests can deplete the number of available HopIDs,
thus leading to a denial of compression service for subsequent content
requests.To further alleviate the problems caused by forged fragments or
Interest initiations, proper protective mechanisms for accessing the
link-layer should be deployed.This document makes use of Page 2 from
the existing paging dispatches in .IEEE Std. 802.15.4-2015CCN-lite: A lightweight CCNx and NDN implementationRIOT OS: Towards an OS for the Internet of ThingsINRIAFU BerlinINRIAHAW 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 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 BerlinIn 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 octet 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 octets. depicts the
size requirements after compression.The size difference is: 12 + 1.5n octets.For the name /DE/HH/HAW/BT7, the
total size gain is 18 octets, which is 46% 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. The value is thereby encoded using 2 octets. 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 octets.For the name /DE/HH/HAW/BT7, the
total size gain is 21 octets.The CCNx TLV encoding defines a 2-octet encoding for type and
length fields, summing up to 4 octets 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 octets.For the name /DE/HH/HAW/BT7, the size
is reduced by 53 octets, 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 octets.For the name /DE/HH/HAW/BT7, the size
is reduced by 70 octets, which is 40% of the uncompressed packet
containing a 4-octet payload.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. 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. This work was supported in
part by the German Federal Ministry of Research and Education within the
projects I3 and RAPstore.