draft-ietf-lwig-guidance-02.txt   draft-ietf-lwig-guidance-03.txt 
LWIG Working Group C. Bormann, Ed. LWIG Working Group C. Bormann, Ed.
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Intended status: Informational August 09, 2012 Intended status: Informational February 25, 2013
Expires: February 10, 2013 Expires: August 29, 2013
Guidance for Light-Weight Implementations of the Internet Protocol Suite Guidance for Light-Weight Implementations of the Internet Protocol Suite
draft-ietf-lwig-guidance-02 draft-ietf-lwig-guidance-03
Abstract Abstract
Implementation of Internet protocols on small devices benefits from Implementation of Internet protocols on small devices benefits from
light-weight implementation techniques, which are often not light-weight implementation techniques, which are often not
documented in an accessible way. documented in an accessible way.
This document provides a first outline of and some initial content This document provides a first outline of and some initial content
for the Light-Weight Implementation Guidance document planned by the for the Light-Weight Implementation Guidance document planned by the
IETF working group LWIG. IETF working group LWIG.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 10, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Call for contributions . . . . . . . . . . . . . . . . . . 6 1.2. Call for contributions . . . . . . . . . . . . . . . . . 5
2. Terminology and Scope . . . . . . . . . . . . . . . . . . . . 7 1.3. Terminology used in this document . . . . . . . . . . . . 5
2.1. Constrained Nodes . . . . . . . . . . . . . . . . . . . . 7 1.4. Scope of the present document . . . . . . . . . . . . . . 6
2.2. Constrained Networks . . . . . . . . . . . . . . . . . . . 8 1.5. Terminology boilerplate . . . . . . . . . . . . . . . . . 6
2.2.1. Challenged Networks . . . . . . . . . . . . . . . . . 8 2. Drawing the Landscape . . . . . . . . . . . . . . . . . . . . 6
2.3. Constrained Node Networks . . . . . . . . . . . . . . . . 9 2.1. Design Objectives . . . . . . . . . . . . . . . . . . . . 6
2.3.1. LLN ("low-power lossy network") . . . . . . . . . . . 9 2.2. Implementation Styles . . . . . . . . . . . . . . . . . . 7
2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 10 2.3. Roles of nodes . . . . . . . . . . . . . . . . . . . . . 8
2.4. Scope of this document . . . . . . . . . . . . . . . . . . 10 2.4. Overview over the document . . . . . . . . . . . . . . . 8
2.5. Terminology boilerplate . . . . . . . . . . . . . . . . . 10 3. Data Plane Protocols . . . . . . . . . . . . . . . . . . . . 8
3. Drawing the Landscape . . . . . . . . . . . . . . . . . . . . 11 3.1. Link Adaptation Layer . . . . . . . . . . . . . . . . . . 8
3.1. Classes of Devices . . . . . . . . . . . . . . . . . . . . 11 3.1.1. Fragmentation in a 6LoWPAN Route-Over Configuration . 8
3.2. Design Objectives . . . . . . . . . . . . . . . . . . . . 11 3.1.1.1. Implementation Considerations for Not-So-
3.3. Implementation Styles . . . . . . . . . . . . . . . . . . 12 Constrained Nodes . . . . . . . . . . . . . . . . 10
3.4. Roles of nodes . . . . . . . . . . . . . . . . . . . . . . 13 3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 10
3.5. Overview over the document . . . . . . . . . . . . . . . . 13 3.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 10
4. Data Plane Protocols . . . . . . . . . . . . . . . . . . . . . 14 3.3.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Link Adaptation Layer . . . . . . . . . . . . . . . . . . 14 3.3.1.1. Absolutely required TCP behaviors for proper
4.1.1. Fragmentation in a 6LoWPAN Route-Over Configuration . 14 functioning and interoperability . . . . . . . . 11
4.1.1.1. Implementation Considerations for 3.3.1.2. Strongly encouraged, but non-essential, behaviors
Not-So-Constrained Nodes . . . . . . . . . . . . . 15 of TCP . . . . . . . . . . . . . . . . . . . . . 12
4.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 15 3.3.1.3. Experimental extensions that are not yet standard
4.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 15 practices . . . . . . . . . . . . . . . . . . . . 13
4.3.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3.1.4. Others . . . . . . . . . . . . . . . . . . . . . 13
4.3.1.1. Absolutely required TCP behaviors for proper 3.4. Application Layer . . . . . . . . . . . . . . . . . . . . 14
functioning and interoperability . . . . . . . . . 16 3.4.1. General considerations about Application Programming
4.3.1.2. Strongly encouraged, but non-essential, Interfaces (APIs) . . . . . . . . . . . . . . . . . . 14
behaviors of TCP . . . . . . . . . . . . . . . . . 17 3.4.2. Constrained Application Protocol (CoAP) . . . . . . . 14
4.3.1.3. Experimental extensions that are not yet 3.4.2.1. Message Layer Processing . . . . . . . . . . . . 15
standard practices . . . . . . . . . . . . . . . . 19 3.4.2.2. Message Parsing . . . . . . . . . . . . . . . . . 16
4.3.1.4. Others . . . . . . . . . . . . . . . . . . . . . . 19 3.4.2.3. Storing Used Message IDs . . . . . . . . . . . . 17
4.4. Application Layer . . . . . . . . . . . . . . . . . . . . 19 3.4.3. (Other Application Protocols...) . . . . . . . . . . 20
4.4.1. General considerations about Application 4. Control Plane Protocols . . . . . . . . . . . . . . . . . . . 20
Programming Interfaces (APIs) . . . . . . . . . . . . 19 4.1. Link Layer Support . . . . . . . . . . . . . . . . . . . 20
4.4.2. Constrained Application Protocol (CoAP) . . . . . . . 20 4.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 20
4.4.2.1. Message Layer Processing . . . . . . . . . . . . . 21 4.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.2.2. Message Parsing . . . . . . . . . . . . . . . . . 22 4.4. Host Configuration and Lookup Services . . . . . . . . . 21
4.4.2.3. Storing Used Message IDs . . . . . . . . . . . . . 23 4.5. Network Management . . . . . . . . . . . . . . . . . . . 21
4.4.3. (Other Application Protocols...) . . . . . . . . . . . 26 4.5.1. SNMP . . . . . . . . . . . . . . . . . . . . . . . . 21
5. Control Plane Protocols . . . . . . . . . . . . . . . . . . . 27 4.5.1.1. Background . . . . . . . . . . . . . . . . . . . 21
5.1. Link Layer Support . . . . . . . . . . . . . . . . . . . . 27 4.5.1.2. Revisiting SNMP implementation for resource
5.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 27 constrained devices . . . . . . . . . . . . . . . 22
5.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.5.1.3. Proposed approach for building an memory
5.4. Host Configuration and Lookup Services . . . . . . . . . . 27 efficient SNMP agent . . . . . . . . . . . . . . 22
5.5. Network Management . . . . . . . . . . . . . . . . . . . . 27 4.5.1.4. Example . . . . . . . . . . . . . . . . . . . . . 23
5.5.1. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.5.1.5. Further improvements . . . . . . . . . . . . . . 25
5.5.1.1. Background . . . . . . . . . . . . . . . . . . . . 28 4.5.1.6. Conclusion . . . . . . . . . . . . . . . . . . . 26
5.5.1.2. Revisiting SNMP implementation for resource 5. Security protocols . . . . . . . . . . . . . . . . . . . . . 26
constrained devices . . . . . . . . . . . . . . . 28 5.1. Cryptography for Constrained Devices . . . . . . . . . . 26
5.5.1.3. Proposed approach for building an memory 5.2. Transport Layer Security . . . . . . . . . . . . . . . . 26
efficient SNMP agent . . . . . . . . . . . . . . . 29 5.3. Network Layer Security . . . . . . . . . . . . . . . . . 26
5.5.1.4. Example . . . . . . . . . . . . . . . . . . . . . 29 5.4. Network Access Control . . . . . . . . . . . . . . . . . 26
5.5.1.5. Further improvements . . . . . . . . . . . . . . . 32 5.4.1. PANA . . . . . . . . . . . . . . . . . . . . . . . . 26
5.5.1.6. Conclusion . . . . . . . . . . . . . . . . . . . . 32 5.4.1.1. PANA AVPs . . . . . . . . . . . . . . . . . . . . 27
6. Security protocols . . . . . . . . . . . . . . . . . . . . . . 33 5.4.1.2. PANA Phases . . . . . . . . . . . . . . . . . . . 27
6.1. Cryptography for Constrained Devices . . . . . . . . . . . 33 5.4.1.3. PANA session state parameters . . . . . . . . . . 29
6.2. Transport Layer Security . . . . . . . . . . . . . . . . . 33 6. Wire-Visible Constraints . . . . . . . . . . . . . . . . . . 31
6.3. Network Layer Security . . . . . . . . . . . . . . . . . . 33 7. Wire-Invisible Constraints . . . . . . . . . . . . . . . . . 31
6.4. Network Access Control . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
6.4.1. PANA . . . . . . . . . . . . . . . . . . . . . . . . . 33 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32
6.4.1.1. PANA AVPs . . . . . . . . . . . . . . . . . . . . 33 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
6.4.1.2. PANA Phases . . . . . . . . . . . . . . . . . . . 34 10.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 32
6.4.1.3. PANA session state parameters . . . . . . . . . . 36 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
7. Wire-Visible Constraints . . . . . . . . . . . . . . . . . . . 39 11.1. Normative References . . . . . . . . . . . . . . . . . . 33
8. Wire-Invisible Constraints . . . . . . . . . . . . . . . . . . 40 11.2. Informative References . . . . . . . . . . . . . . . . . 33
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34
10. Security Considerations . . . . . . . . . . . . . . . . . . . 42
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
11.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . 43
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
12.1. Normative References . . . . . . . . . . . . . . . . . . . 44
12.2. Informative References . . . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
Today's Internet is experienced by users as a set of applications, Today's Internet is experienced by users as a set of applications,
such as email, instant messaging, and social networks. There are such as email, instant messaging, and social networks. There are
substantial differences in performance between the various end substantial differences in performance between the various end
devices with these applications, but in general end devices devices with these applications, but in general end devices
participating in the Internet today are considered to have relatively participating in the Internet today are considered to have relatively
high performance. high performance.
skipping to change at page 6, line 13 skipping to change at page 5, line 37
rarely an acceptable approach. rarely an acceptable approach.
1.2. Call for contributions 1.2. Call for contributions
The present draft of the document is an outline that will grow with The present draft of the document is an outline that will grow with
the contributions received, which are expressly invited. As this the contributions received, which are expressly invited. As this
document focuses on experience from existing implementations, this document focuses on experience from existing implementations, this
requires implementer input; in particular, participation is required requires implementer input; in particular, participation is required
from the implementers of existing small IP stacks. "Small" here is from the implementers of existing small IP stacks. "Small" here is
intended to be applicable approximately to what is described in intended to be applicable approximately to what is described in
Section 3 -- where it is more important that the technique described Section 2 -\u002D where it is more important that the technique
is grounded in actual experience than that the experience is actually described is grounded in actual experience than that the experience
from a (very) constrained system. is actually from a (very) constrained system.
Only a few subsections are fleshed out in this initial draft; Only a few subsections are fleshed out in this initial draft;
additional subsections will quickly be integrated from additional additional subsections will quickly be integrated from additional
contributors. contributors.
2. Terminology and Scope 1.3. Terminology used in this document
The main focus of the present work appears to be _scaling_:
o Scaling up Internet technologies to a large number [50billion] of
inexpensive nodes, while
o scaling down the characteristics of each of these nodes and of the
networks being built out of them, to make this scaling up
econmically and physically viable.
The need for scaling down the characteristics of nodes leads to
_constrained nodes_.
2.1. Constrained Nodes
The term "constrained node" is best defined on not meeting certain
widely held expectations:
Constrained Node: A node where some of the characteristics that are
otherwise pretty much taken for granted for Internet nodes in 2012
are not attainable, often due to cost constraints and/or physical
constraints on characteristics such as size, weight, and available
power.
While this is less than satisfying as a rigorous definition, it is
grounded in the state of the art and clearly sets apart constrained
nodes from server systems, desktop or laptop computers, powerful
mobile devices such as smartphones etc.
There are multiple facets to the constraints on nodes, often applying
in combination, e.g.:
o constraints on the maximum code complexity (ROM/Flash);
o constraints on the size of state and buffers (RAM);
o constraints on the available power.
Section 3.1 defines a small number of interesting classes ("class-N"
for N=1,2) of constrained nodes focusing on relevant combinations of
the first two constraints. With respect to available power,
[RFC6606] distinguishes "power-affluent" nodes (mains-powered or
regularly recharged) from "power-constrained nodes" that draw their
power from primary batteries or using energy harvesting.
The use of constrained nodes in networks often also leads to
constraints on the networks themselves. However, there may also be
constraints on networks that are largely independent from those of
the nodes. We therefore distinguish _constrained networks_ and
_constrained node networks_.
2.2. Constrained Networks
We define "constrained network" in a similar way:
Constrained Network: A network where some of the characteristics
pretty much taken for granted for Internet link layers in 2012 are
not attainable.
Again, there may be several reasons for this:
o cost constraints on the network
o constraints of the nodes (for constrained node networks)
o physical constraints (e.g., power constraints, media constraints
such as underwater operation, limited spectrum for very high
density).
Constraints may include:
o low achievable bit rate
o high packet loss, packet loss (delivery rate) variability
o severe penalties for using larger packets (e.g., high packet loss
due to link layer fragmentation)
o lack of (or severe constraints on) advanced services such as IP
multicast
2.2.1. Challenged Networks
A constrained network is not necessarily a _challenged_ network
[FALL]:
Challenged Network: A network that has serious trouble maintaining
what an applicaton would today expect of the end-to-end IP model,
e.g., by:
o not being able to offer end-to-end IP connectivity at all;
o exhibiting serious interruptions in end-to-end IP connectivity;
o exhibiting delay well beyond the MSL defined by TCP.
All challenged networks are constrained networks in some sense, but
not all constrained networks are challenged networks. There is no
well-defined boundary between the two, though. Delay-Tolerant
Networking (DTN) has been designed to cope with challenged networks
[RFC4838].
2.3. Constrained Node Networks
Constrained Node Network: A network whose characteristics are
influenced by being composed of a significant portion of
constrained nodes.
A constrained node network always is a constrained network because of
the network constraints stemming from the node constraints, but may
also have other constraints that already make it a constrained
network.
2.3.1. LLN ("low-power lossy network")
A related term that has been used recently is "low-power lossy
network" (LLN). The ROLL working group currently is struggling with
its definition [I-D.ietf-roll-terminology]:
LLN: Low power and Lossy networks (LLNs) are typically composed of
many embedded devices with limited power, memory, and processing
resources interconnected by a variety of links, such as IEEE
802.15.4 or Low Power WiFi. There is a wide scope of application
areas for LLNs, including industrial monitoring, building
automation (HVAC, lighting, access control, fire), connected home,
healthcare, environmental monitoring, urban sensor networks,
energy management, assets tracking and refrigeration.. [sic]
It is not clear that "LLN" is much more specific than "interesting"
or "the network characteristics that RPL has been designed for".
LLNs do appear to have significant loss at the physical layer, with
significant variability of the delivery rate, and some short-term
unreliability, coupled with some medium term stability that makes it
worthwhile to construct medium-term stable directed acyclic graphs
for routing and do measurements on the edges such as ETX. Actual
"low power" does not seem to be required for an LLN
[I-D.hui-vasseur-roll-rpl-deployment], and the positions on scaling
of LLNs appear to vary widely [I-D.clausen-lln-rpl-experiences].
Also, LLNs seem to be composed of constrained nodes; otherwise
operation modes such as RPL's "non-storing mode" would not be
sensible. So an LLN seems to be a constrained node network with
certain constraints on the network as well.
2.3.2. LoWPAN, 6LoWPAN
One interesting class of a constrained network often used as a The present document has originally also been used to develop
constrained node network is the "LoWPAN" [RFC4919], a term inspired pertinent terminology. This has been factored out into a separate
from the name of the IEEE 802.15.4 working group (low-rate wireless document, [I-D.ietf-lwig-terminology], which is now a prerequisite to
personal area networks (LR-WPANs)). The expansion of that acronym, reading the present document.
"Low-Power Wireless Personal Area Network" contains a hard to justify
"Personal" that is due to IEEE politics more than due to an
orientation of LoWPANs around a single person. Actually, LoWPANs
have been suggested for urban monitoring, control of large buildings,
and industrial control applications, so the "Personal" can only be
considered a vestige. Maybe the term is best read as "Low-Power
Wireless Area Networks" (LoWPANs) [WEI]. Originally focused on IEEE
802.15.4, "LoWPAN" (or when used for IPv6, "6LoWPAN") is now also
being used for networks built from similarly constrained link layer
technologies [I-D.ietf-6lowpan-btle]
[I-D.mariager-6lowpan-v6over-dect-ule].
2.4. Scope of this document 1.4. Scope of the present document
Using the above terminology, we can now more precisely define the Using this terminology, we can now more precisely define the scope of
scope of the present document: the present document:
This document is about implementation techniques that enable This document is about implementation techniques that enable
constrained nodes to form constrained node networks. constrained nodes to form constrained node networks.
Delay-Tolerant Networks (DTNs) are out of scope. (See Section 1.1 Delay-Tolerant Networks (DTNs) are out of scope. (See Section 1.1
above for a further list of non-goals.) above for a further list of non-goals.)
2.5. Terminology boilerplate 1.5. Terminology boilerplate
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. As this is document are to be interpreted as described in RFC 2119. As this is
an informational document, the [RFC2119] keywords will only be used an informational document, the [RFC2119] keywords will only be used
to underscore requirements where similar key words apply in the to underscore requirements where similar key words apply in the
context of the specifications the light-weight implementation of context of the specifications the light-weight implementation of
which is being discussed. which is being discussed.
The term "byte" is used in its now customary sense as a synonym for The term "byte" is used in its now customary sense as a synonym for
"octet". "octet".
3. Drawing the Landscape 2. Drawing the Landscape
There is not a single kind of constrained, Internet-connected device. There is not a single kind of constrained, Internet-connected device.
To the contrary, the trend is towards much more functional variety of To the contrary, the trend is towards much more functional variety of
such devices than is customary today in the Internet. This section such devices than is customary today in the Internet. The
introduces a number of terms that will be used to locate some of the terminology document [I-D.ietf-lwig-terminology] introduces a number
technique described in the following sections within certain areas of of terms that will be used here to locate some of the technique
described in the following sections within certain areas of
applications. applications.
3.1. Classes of Devices 2.1. Design Objectives
Despite the overwhelming variety of Internet-connected devices that
can be envisioned, it may, be worthwhile to have some succinct
terminology for different classes of constrained devices. In this
document, the following class designations may be used as rough
indications of device capabilities:
+---------+-----------------------+-------------------------+
| Name | data size (e.g., RAM) | code size (e.g., Flash) |
+---------+-----------------------+-------------------------+
| Class 1 | ~ 10 KiB | ~ 100 KiB |
| | | |
| Class 2 | ~ 50 KiB | ~ 250 KiB |
+---------+-----------------------+-------------------------+
As of the writing of this document, these characteristics correspond
to distinguishable sets of commercially available chips and design
cores for constrained devices. While it is expected that the
boundaries of these classes will move over time, Moore's law tends to
be less effective in the embedded space than in personal computing
devices: Gains made available by increases in transistor count and
density are more likely to be invested in reductions of cost and
power requirements than into continual increases in computing power.
3.2. Design Objectives
o Consideration for design or implementation approaches for o Consideration for design or implementation approaches for
implementation of IP stacks for constrained devices will be implementation of IP stacks for constrained devices will be
impacted by the RAM usage for these designs. Here the impacted by the RAM usage for these designs. Here the
consideration is what is the best approach to minimize overhead. consideration is what is the best approach to minimize overhead.
o In addition, the impact on throughput in terms of IP protocol o In addition, the impact on throughput in terms of IP protocol
implementation must take into consideration the methods that implementation must take into consideration the methods that
minimize overhead but balance performance requirements for the minimize overhead but balance performance requirements for the
light-weight constrained devices. light-weight constrained devices.
o Protocol implementation must consider its impact on CPU o Protocol implementation must consider its impact on CPU
utilization. Here guidance will be provided on how to minimize utilization. Here guidance will be provided on how to minimize
tasks that require additional CPU execution time. tasks that require additional CPU execution time.
How does the implementation of the IP stack effect the application How does the implementation of the IP stack effect the application
both in terms of performance but also of those same attributes and both in terms of performance but also of those same attributes and
requirements (RAM, CPU usage, etc.) that we are examining for the IP requirements (RAM, CPU usage, etc.) that we are examining for the IP
protocol stack? protocol stack?
From performing a synthesis of implementation experiences we will be From performing a synthesis of implementation experiences we will be
able to understand and document the benefits and consequences of able to understand and document the benefits and consequences of
varied approaches. Scaling code and selected approaches in terms of varied approaches. Scaling code and selected approaches in terms of
scaling from, say, a 8-bit micro to a 16-bit micro. Such scaling for scaling from, say, a 8-bit micro to a 16-bit micro. Such scaling for
the approach will aid in the development of single code base when the approach will aid in the development of single code base when
possible. possible.
3.3. Implementation Styles 2.2. Implementation Styles
Compared to personal computing devices, constrained devices tend to Compared to personal computing devices, constrained devices tend to
make use of quite different classes of operating systems, if that make use of quite different classes of operating systems, if that
term is even applicable. term is even applicable.
... ...
o Single-threaded/giant mainloop o Single-threaded/giant mainloop
o Event-driven vs. threaded/blocking o Event-driven vs. threaded/blocking
* The usual multi-threaded model blocks a thread on primitives * The usual multi-threaded model blocks a thread on primitives
such as connect(), accept() or read() until an external event such as connect(), accept() or read() until an external event
takes place. This model is often thought to consume too much takes place. This model is often thought to consume too much
RAM and CPU processing. RAM and CPU processing.
* The event driven model uses a non-blocking approach: E.g., when * The event driven model uses a non-blocking approach: E.g., when
an application interface sends a message, the routine would an application interface sends a message, the routine would
return immediately (before the message is sent). A call-back return immediately (before the message is sent). A call-back
facility notifies the application or calling code when the facility notifies the application or calling code when the
desired processing is completed. Here the benefit is that no desired processing is completed. Here the benefit is that no
thread context needs to be preserved for long periods of time. thread context needs to be preserved for long periods of time.
o Single/multiple processing elements o Single/multiple processing elements
o E.g., separate radio/network processor o E.g., separate radio/network processor
Introduce these briefly: Some techniques may be applicable only to Introduce these briefly: Some techniques may be applicable only to
some of these styles! some of these styles!
3.4. Roles of nodes 2.3. Roles of nodes
Constrained nodes are by necessity more specialized than general Constrained nodes are by necessity more specialized than general
purpose computing devices; they may have a quite specific role. Some purpose computing devices; they may have a quite specific role. Some
implementation techniques may also implementation techniques may also
o Constrained nodes o Constrained nodes
o Nodes talking to constrained nodes o Nodes talking to constrained nodes
o Gateways/Proxies o Gateways/Proxies
In all these cases, constrained nodes that are "sleepy" pose In all these cases, constrained nodes that are "sleepy" pose
additional considerations. (Explain sleepy...) E.g., a node talking additional considerations. (Explain sleepy...) E.g., a node talking
to a sleepy node may need to make special arrangements; this is even to a sleepy node may need to make special arrangements; this is even
more true where a gateway or proxy interfaces the general Internet more true where a gateway or proxy interfaces the general Internet
o Bandwidth/latency considerations o Bandwidth/latency considerations
3.5. Overview over the document 2.4. Overview over the document
The following sections will first go through a number of specific The following sections will first go through a number of specific
protocol layers, starting from layers of the data plane (link protocol layers, starting from layers of the data plane (link
adaptation, network, transport, application), followed by control adaptation, network, transport, application), followed by control
plane protocol layers (link layer support, network layer and routing, plane protocol layers (link layer support, network layer and routing,
host configuration and lookup services). We then look at security host configuration and lookup services). We then look at security
protocols (general cryptography considerations, transport layer protocols (general cryptography considerations, transport layer
security, network layer security, network access control). Finally, security, network layer security, network access control). Finally,
we discuss some specific, cross-layer concerns, some "wire-visible", we discuss some specific, cross-layer concerns, some "wire-visible",
some of concern within a specific implementation. Clearly, many some of concern within a specific implementation. Clearly, many
topics could be discussed in more than one place in this structure. topics could be discussed in more than one place in this structure.
The objective is not to have something for each of the potential The objective is not to have something for each of the potential
topics, but to document the most valuable experience that may be topics, but to document the most valuable experience that may be
available. available.
4. Data Plane Protocols 3. Data Plane Protocols
4.1. Link Adaptation Layer 3.1. Link Adaptation Layer
6LoWPAN 6LoWPAN
4.1.1. Fragmentation in a 6LoWPAN Route-Over Configuration 3.1.1. Fragmentation in a 6LoWPAN Route-Over Configuration
Author: Carsten Bormann Author: Carsten Bormann
6LoWPAN [RFC4944] is an adaptation layer that maps IPv6 with its 6LoWPAN [RFC4944] is an adaptation layer that maps IPv6 with its
minimum MTU of 1280 bytes to IEEE 802.15.4, which has a physical minimum MTU of 1280 bytes to IEEE 802.15.4, which has a physical
layer MTU of only 127 bytes (some of which are taken by MAC layer and layer MTU of only 127 bytes (some of which are taken by MAC layer and
adaptation layer headers). Therefore, the adaptation layer provides adaptation layer headers). Therefore, the adaptation layer provides
a fragmentation and reassembly scheme that can fragment a single IPv6 a fragmentation and reassembly scheme that can fragment a single IPv6
packet of up to 1280 bytes into multiple adaptation layer fragments packet of up to 1280 bytes into multiple adaptation layer fragments
of up to 127 bytes each (including MAC and adaptation layer of up to 127 bytes each (including MAC and adaptation layer
skipping to change at page 14, line 49 skipping to change at page 9, line 35
Instead of performing a full reassembly, implementations may be able Instead of performing a full reassembly, implementations may be able
to optimize this process by not keeping a full reassembly buffer, but to optimize this process by not keeping a full reassembly buffer, but
just a runt buffer (called "virtual reassembly buffer" in [WEI]) for just a runt buffer (called "virtual reassembly buffer" in [WEI]) for
each IP packet. This buffer caches only the datagram_tag field (as each IP packet. This buffer caches only the datagram_tag field (as
usual combined with the sender's link layer address, the usual combined with the sender's link layer address, the
destination's link layer address and the datagram_size field) and the destination's link layer address and the datagram_size field) and the
IPv6 header including the relevant addresses. Initial fragments are IPv6 header including the relevant addresses. Initial fragments are
then forwarded independently (after header decompression/compression) then forwarded independently (after header decompression/compression)
and create a runt reassembly buffer. Non-initial fragments (which and create a runt reassembly buffer. Non-initial fragments (which
don't require header decompression/compression in 6LoWPAN) are don't require header decompression/compression in 6LoWPAN) are
matched against the runt buffers by datagram_tag etc. and forwarded matched against the runt buffers by datagram_tag etc. and forwarded
if an IPv6 address is available. (This simple scheme may be if an IPv6 address is available. (This simple scheme may be
complicated a bit if header decompression/compression of the initial complicated a bit if header decompression/compression of the initial
fragment causes an overflow of the physical MTU; in this case some fragment causes an overflow of the physical MTU; in this case some
overflow data may need to be stored in the runt buffers to be overflow data may need to be stored in the runt buffers to be
combined with further fragments or may simply be forwarded as a combined with further fragments or may simply be forwarded as a
separate additional fragment.) separate additional fragment.)
If non-initial fragments arrive out of order before the initial If non-initial fragments arrive out of order before the initial
fragment, a route-over router may want to keep the contents of the fragment, a route-over router may want to keep the contents of the
non-initial fragments until the initial fragment is available, which non-initial fragments until the initial fragment is available, which
skipping to change at page 15, line 22 skipping to change at page 10, line 10
constrained route-over router may simply discard out-of order non- constrained route-over router may simply discard out-of order non-
initial fragments, possibly taking note that there is no point in initial fragments, possibly taking note that there is no point in
forwarding any more fragments with the same combination of 6LoWPAN forwarding any more fragments with the same combination of 6LoWPAN
datagram_tag field, L2 addresses and datagram_size. datagram_tag field, L2 addresses and datagram_size.
Runt buffers should time out like full reassembly buffers, and may Runt buffers should time out like full reassembly buffers, and may
either keep a map of fragments forwarded or they may simply be either keep a map of fragments forwarded or they may simply be
removed upon forwarding the final fragment, assuming that no out-of- removed upon forwarding the final fragment, assuming that no out-of-
order fragments will follow. order fragments will follow.
4.1.1.1. Implementation Considerations for Not-So-Constrained Nodes 3.1.1.1. Implementation Considerations for Not-So-Constrained Nodes
[RFC4944] makes no explicit mandates about the order in which [RFC4944] makes no explicit mandates about the order in which
fragments should be sent. Because it is heavily favored by the above fragments should be sent. Because it is heavily favored by the above
implementation techniques, it is highly advisable for all implementation techniques, it is highly advisable for all
implementations to always send adaptation layer fragments in natural implementations to always send adaptation layer fragments in natural
order, i.e., starting with the initial fragment, continuing with order, i.e., starting with the initial fragment, continuing with
increasing datagram_offset. increasing datagram_offset.
4.2. Network Layer 3.2. Network Layer
IPv4 and IPv6 IPv4 and IPv6
4.3. Transport Layer 3.3. Transport Layer
TCP and UDP TCP and UDP
Both TCP and UDP employ 16-bit one's-complement checksums to protect Both TCP and UDP employ 16-bit one's-complement checksums to protect
against transmission errors. A number of RFCs discuss efficient against transmission errors. A number of RFCs discuss efficient
implementation techniques for computing and updating Internet implementation techniques for computing and updating Internet
Checksums [RFC1071] [RFC1141] [RFC1624]. (Updating the Internet Checksums [RFC1071] [RFC1141] [RFC1624]. (Updating the Internet
Checksum, as opposed to computing it from scratch, may be of interest Checksum, as opposed to computing it from scratch, may be of interest
where a pre-computed packet is provided, e.g., in Flash ROM, and a where a pre-computed packet is provided, e.g., in Flash ROM, and a
copy is made in RAM and updated with some current values, or when the copy is made in RAM and updated with some current values, or when the
actual transmitted packet is composed from pre-defined parts in ROM actual transmitted packet is composed from pre-defined parts in ROM
and new parts in RAM.) and new parts in RAM.)
4.3.1. TCP 3.3.1. TCP
Ed. Note: Ed. Note:
The following outline of a section is an attempt to provide The following outline of a section is an attempt to provide
substructure for a future discussion of TCP-related issues based on substructure for a future discussion of TCP-related issues based on
the TCP Roadmap, [RFC4614]. The indented text, as well as the RFC the TCP Roadmap, [RFC4614]. The indented text, as well as the RFC
citations, are copied (and redacted) from there; this certainly needs citations, are copied (and redacted) from there; this certainly needs
to be refined in a future version. (Some additional adaptation of to be refined in a future version. (Some additional adaptation of
the material may also be required as RFC 2581 was since obsoleted by the material may also be required as RFC 2581 was since obsoleted by
RFC 5681, and RFC 3782 was obsoleted by RFC 6582.) RFC 5681, and RFC 3782 was obsoleted by RFC 6582.)
skipping to change at page 16, line 30 skipping to change at page 11, line 13
describe absolutely required TCP behaviors for proper functioning and describe absolutely required TCP behaviors for proper functioning and
interoperability. Further RFCs describe strongly encouraged, but interoperability. Further RFCs describe strongly encouraged, but
non-essential, behaviors. There are also experimental extensions non-essential, behaviors. There are also experimental extensions
that are not yet standard practices, but that potentially could be in that are not yet standard practices, but that potentially could be in
the future. the future.
In this subsection, the influence of resource constrained nodes on In this subsection, the influence of resource constrained nodes on
TCP implementations are summarized according to the lists of TCP implementations are summarized according to the lists of
[RFC4614]. [RFC4614].
4.3.1.1. Absolutely required TCP behaviors for proper functioning and 3.3.1.1. Absolutely required TCP behaviors for proper functioning and
interoperability interoperability
RFC 793 S: "Transmission Control Protocol", STD 7 (September 1981) RFC 793 S: "Transmission Control Protocol", STD 7 (September 1981)
In RFC793, the TCP state machine and event processing, and TCP's In RFC793, the TCP state machine and event processing, and TCP's
semantics for data transmission, reliability, flow control, semantics for data transmission, reliability, flow control,
multiplexing, and acknowledgment. For this part, the constraint of multiplexing, and acknowledgment. For this part, the constraint of
memory will limit the multiplexing capability of TCP. /_text needed memory will limit the multiplexing capability of TCP. /_text needed
for RFC793_/ for RFC793_/
RFC 1122 S: "Requirements for Internet Hosts - Communication Layers" RFC 1122 S: "Requirements for Internet Hosts - Communication Layers"
(October 1989) (October 1989)
RFC 2460 S: "Internet Protocol, Version 6 (IPv6) Specification RFC 2460 S: "Internet Protocol, Version 6 (IPv6) Specification
(December 1998) (December 1998)
RFC 2873 S: "TCP Processing of the IPv4 Precedence Field" (June 2000) RFC 2873 S: "TCP Processing of the IPv4 Precedence Field" (June 2000)
skipping to change at page 17, line 35 skipping to change at page 12, line 20
component of any widely deployed TCP implementation and is component of any widely deployed TCP implementation and is
required for the avoidance of congestion collapse and to ensure required for the avoidance of congestion collapse and to ensure
fairness among competing flows. fairness among competing flows.
RFC 2988 S: "Computing TCP's Retransmission Timer" (November 2000) RFC 2988 S: "Computing TCP's Retransmission Timer" (November 2000)
Abstract: "This document defines the standard algorithm that Abstract: "This document defines the standard algorithm that
Transmission Control Protocol (TCP) senders are required to use to Transmission Control Protocol (TCP) senders are required to use to
compute and manage their retransmission timer. compute and manage their retransmission timer.
4.3.1.2. Strongly encouraged, but non-essential, behaviors of TCP 3.3.1.2. Strongly encouraged, but non-essential, behaviors of TCP
RFC 1323 S: "TCP Extensions for High Performance" (May 1992) RFC 1323 S: "TCP Extensions for High Performance" (May 1992)
This document [RFC1323] defines TCP extensions for window scaling, This document [RFC1323] defines TCP extensions for window scaling,
timestamps, and protection against wrapped sequence numbers, for timestamps, and protection against wrapped sequence numbers, for
efficient and safe operation over paths with large bandwidth-delay efficient and safe operation over paths with large bandwidth-delay
products. products.
RFC 2675 S: "IPv6 Jumbograms" (August 1999) RFC 2675 S: "IPv6 Jumbograms" (August 1999)
IPv6 supports longer datagrams than were allowed in IPv4. IPv6 supports longer datagrams than were allowed in IPv4.
RFC 3168 S: "The Addition of Explicit Congestion Notification (ECN) RFC 3168 S: "The Addition of Explicit Congestion Notification (ECN)
to IP" (September 2001) to IP" (September 2001)
4.3.1.2.1. Congestion Control and Loss Recovery Extensions 3.3.1.2.1. Congestion Control and Loss Recovery Extensions
RFC 3042 S: "Enhancing TCP's Loss Recovery Using Limited Transmit" RFC 3042 S: "Enhancing TCP's Loss Recovery Using Limited Transmit"
(January 2001) (January 2001)
Abstract: "This document proposes Limited Transmit, a new Abstract: "This document proposes Limited Transmit, a new
Transmission Control Protocol (TCP) mechanism that can be used to Transmission Control Protocol (TCP) mechanism that can be used to
more effectively recover lost segments when a connection's more effectively recover lost segments when a connection's
congestion window is small congestion window is small
RFC 3390 S: "Increasing TCP's Initial Window" (October 2002) RFC 3390 S: "Increasing TCP's Initial Window" (October 2002)
skipping to change at page 18, line 30 skipping to change at page 13, line 14
RFC 3782 S: "The NewReno Modification to TCP's Fast Recovery RFC 3782 S: "The NewReno Modification to TCP's Fast Recovery
Algorithm" (April 2004) Algorithm" (April 2004)
This document [RFC3782] specifies a modification to the standard This document [RFC3782] specifies a modification to the standard
Reno fast recovery algorithm, whereby a TCP sender can use partial Reno fast recovery algorithm, whereby a TCP sender can use partial
acknowledgments to make inferences determining the next segment to acknowledgments to make inferences determining the next segment to
send in situations where SACK would be helpful but isn't send in situations where SACK would be helpful but isn't
available. available.
4.3.1.2.2. SACK-Based Loss Recovery and Congestion Control 3.3.1.2.2. SACK-Based Loss Recovery and Congestion Control
RFC 2018 S: "TCP Selective Acknowledgment Options" (October 1996) RFC 2018 S: "TCP Selective Acknowledgment Options" (October 1996)
This document [RFC2018] defines the basic selective acknowledgment This document [RFC2018] defines the basic selective acknowledgment
(SACK) mechanism for TCP. (SACK) mechanism for TCP.
RFC 2883 S: "An Extension to the Selective Acknowledgement (SACK) RFC 2883 S: "An Extension to the Selective Acknowledgement (SACK)
Option for TCP" (July 2000) Option for TCP" (July 2000)
This document [RFC2883] extends RFC 2018 to cover the case of This document [RFC2883] extends RFC 2018 to cover the case of
acknowledging duplicate segments. acknowledging duplicate segments.
RFC 3517 S: "A Conservative Selective Acknowledgment (SACK)-based RFC 3517 S: "A Conservative Selective Acknowledgment (SACK)-based
Loss Recovery Algorithm for TCP" (April 2003) Loss Recovery Algorithm for TCP" (April 2003)
4.3.1.2.3. Dealing with Forged Segments 3.3.1.2.3. Dealing with Forged Segments
RFC 1948 I: "Defending Against Sequence Number Attacks" (May 1996) RFC 1948 I: "Defending Against Sequence Number Attacks" (May 1996)
RFC 2385 S: "Protection of BGP Sessions via the TCP MD5 Signature RFC 2385 S: "Protection of BGP Sessions via the TCP MD5 Signature
Option" (August 1998) Option" (August 1998)
4.3.1.3. Experimental extensions that are not yet standard practices 3.3.1.3. Experimental extensions that are not yet standard practices
The experimental extensions are not mature yet. The contents need to The experimental extensions are not mature yet. The contents need to
be validated to be safe and logical behavior. It is not recommended be validated to be safe and logical behavior. It is not recommended
for the resource constrained node to implement. for the resource constrained node to implement.
4.3.1.4. Others 3.3.1.4. Others
RFC 2923 I: "TCP Problems with Path MTU Discovery" (September 2000) RFC 2923 I: "TCP Problems with Path MTU Discovery" (September 2000)
From abstract: "This memo catalogs several known Transmission From abstract: "This memo catalogs several known Transmission
Control Protocol (TCP) implementation problems dealing with Path Control Protocol (TCP) implementation problems dealing with Path
Maximum Transmission Unit Discovery (PMTUD), including the long- Maximum Transmission Unit Discovery (PMTUD), including the long-
standing black hole problem, stretch acknowlegements (ACKs) due to standing black hole problem, stretch acknowlegements (ACKs) due to
confusion between Maximum Segment Size (MSS) and segment size, and confusion between Maximum Segment Size (MSS) and segment size, and
MSS advertisement based on PMTU." [RFC2923] MSS advertisement based on PMTU." [RFC2923]
4.4. Application Layer 3.4. Application Layer
4.4.1. General considerations about Application Programming Interfaces 3.4.1. General considerations about Application Programming Interfaces
(APIs) (APIs)
Author: Carl Williams Author: Carl Williams
Constrained devices are not necessarily in a position to use APIs Constrained devices are not necessarily in a position to use APIs
that would be considered "standard" for less constrained environments that would be considered "standard" for less constrained environments
(e.g., Berkeley sockets or those defined by POSIX). (e.g., Berkeley sockets or those defined by POSIX).
When an API implements a protocol, this can be based on proxy methods When an API implements a protocol, this can be based on proxy methods
for remote invocations that underneath rely on the communication for remote invocations that underneath rely on the communication
skipping to change at page 20, line 13 skipping to change at page 14, line 45
use as they are less direct and take a lot of serializing, de- use as they are less direct and take a lot of serializing, de-
serializing and dispatching type logic. serializing and dispatching type logic.
So the connection of the API and the protocols on a constrained So the connection of the API and the protocols on a constrained
device becomes even more important to balance the requirements of device becomes even more important to balance the requirements of
RAM, CPU and performance. RAM, CPU and performance.
_** Here we will proceed to collect and document ... insert _** Here we will proceed to collect and document ... insert
experiences from existing API on constrained devices (TBD) **_ experiences from existing API on constrained devices (TBD) **_
4.4.2. Constrained Application Protocol (CoAP) 3.4.2. Constrained Application Protocol (CoAP)
Author: Olaf Bergmann Author: Olaf Bergmann
The Constrained Application Protocol [I-D.ietf-core-coap] has been The Constrained Application Protocol [I-D.ietf-core-coap] has been
designed specifically for machine-to-machine communication in designed specifically for machine-to-machine communication in
networks with very constrained nodes. Typical application scenarios networks with very constrained nodes. Typical application scenarios
therefore include building automation and the Internet of Things. therefore include building automation and the Internet of Things.
The major design objectives have been set on small protocol overhead, The major design objectives have been set on small protocol overhead,
robustness against packet loss, and high latency induced by small robustness against packet loss, and high latency induced by small
bandwidth shares or slow request processing in end nodes. To bandwidth shares or slow request processing in end nodes. To
leverage integration of constrained nodes with the world-wide leverage integration of constrained nodes with the world-wide
Internet, the protocol design was led by the architectural style that Internet, the protocol design was led by the architectural style that
accounts for the scalability and robustness of the Hypertext Transfer accounts for the scalability and robustness of the Hypertext Transfer
Protocol [RFC2616]. Protocol [RFC2616].
Lightweight implementations benefit from this design in many Lightweight implementations benefit from this design in many
respects: First, the use of Uniform Resource Identifiers (URIs) for respects: First, the use of Uniform Resource Identifiers (URIs) for
skipping to change at page 20, line 36 skipping to change at page 15, line 20
accounts for the scalability and robustness of the Hypertext Transfer accounts for the scalability and robustness of the Hypertext Transfer
Protocol [RFC2616]. Protocol [RFC2616].
Lightweight implementations benefit from this design in many Lightweight implementations benefit from this design in many
respects: First, the use of Uniform Resource Identifiers (URIs) for respects: First, the use of Uniform Resource Identifiers (URIs) for
naming resources and the transparent forwarding of their naming resources and the transparent forwarding of their
representations in a server-stateless request/response protocol make representations in a server-stateless request/response protocol make
protocol-translation to HTTP a straightforward task. Second, the set protocol-translation to HTTP a straightforward task. Second, the set
of protocol elements that are inevitable for the core protocol and of protocol elements that are inevitable for the core protocol and
thus must be implemented on every node has been kept very small to thus must be implemented on every node has been kept very small to
avoid unnecessary accumulation of optional features. Options that -- avoid unnecessary accumulation of optional features. Options that
when present -- are critical for message processing are explicitly -\u002D when present -\u002D are critical for message processing are
marked as such to force immediate rejection of messages with unknown explicitly marked as such to force immediate rejection of messages
critical options. Third, the syntax of protocol data units is easy with unknown critical options. Third, the syntax of protocol data
to parse and is carefully defined to avoid creation of state in units is easy to parse and is carefully defined to avoid creation of
servers where possible. state in servers where possible.
Although these features enable lightweight implementations of the Although these features enable lightweight implementations of the
Constrained Application Protocol, there is still a trade-off between Constrained Application Protocol, there is still a trade-off between
robustness and latency of constrained nodes on one hand and resource robustness and latency of constrained nodes on one hand and resource
demands (such as battery consumption, dynamic memory needs and static demands (such as battery consumption, dynamic memory needs and static
code-size) on the other. This section gives some guidance on code-size) on the other. This section gives some guidance on
possible strategies to solve this trade-off for very constrained possible strategies to solve this trade-off for very constrained
nodes (Class 1 in Section 3.1). The main focus is on servers as this nodes (Class 1 in [I-D.ietf-lwig-terminology]). The main focus is on
is deemed the predominant case where CoAP applications are faced with servers as this is deemed the predominant case where CoAP
tight resource constraints. applications are faced with tight resource constraints.
Additional considerations for the implementation of CoAP on tiny Additional considerations for the implementation of CoAP on tiny
sensors are given in [I-D.arkko-core-sleepy-sensors]. sensors are given in [I-D.arkko-core-sleepy-sensors].
4.4.2.1. Message Layer Processing 3.4.2.1. Message Layer Processing
For constrained nodes of Class 1 or even Class 2, limiting factors For constrained nodes of Class 1 or even Class 2, limiting factors
for (wireless) network communication usually are RAM size and battery for (wireless) network communication usually are RAM size and battery
lifetime. Most applications therefore try to avoid dealing with lifetime. Most applications therefore try to avoid dealing with
fragmented packets on the network layer and minimize internal buffer fragmented packets on the network layer and minimize internal buffer
space for both transmit and receive operations. One of the most space for both transmit and receive operations. One of the most
expensive operations hence is the retransmission of messages as it expensive operations hence is the retransmission of messages as it
implies additional energy consumption for the (radio) network implies additional energy consumption for the (radio) network
interface and occupied RAM storage for the send buffer. interface and occupied RAM storage for the send buffer.
Where multi-threading is not an option at all because no full-fledged Where multi-threading is not an option at all because no full-fledged
operating system is present, all operations are triggered by a big operating system is present, all operations are triggered by a big
main loop in a send-receive-dispatch cycle. To implement the packet main loop in a send-receive-dispatch cycle. To implement the packet
retransmission, CoAP implementations at least need a separate send retransmission, CoAP implementations at least need a separate send
buffer and a decent notion of time, e.g. as a strictly monotonic buffer and a decent notion of time, e.g. as a strictly monotonic
increasing tick counter. For platforms that disable clock tick increasing tick counter. For platforms that disable clock tick
interrupts in sleep states, the application must take into interrupts in sleep states, the application must take into
consideration the clock deviation that occurs during sleep (or ensure consideration the clock deviation that occurs during sleep (or ensure
to remain in idle state until the message has been acknowledged or to remain in idle state until the message has been acknowledged or
the maximum number of retransmissions is reached). Since CoAP allows the maximum number of retransmissions is reached). Since CoAP allows
up to four retransmissions with a binary exponential back-off it up to four retransmissions with a binary exponential back-off it
could take up to 45 seconds until the send operation is complete. could take up to 45 seconds until the send operation is complete.
Even in idle state, this means substantial energy consumption for Even in idle state, this means substantial energy consumption for
low-power nodes. Implementers therefore might choose a two-step low-power nodes. Implementers therefore might choose a two-step
strategy: First, do one or two retransmissions and then, in the later strategy: First, do one or two retransmissions and then, in the later
skipping to change at page 22, line 13 skipping to change at page 16, line 45
technique is that the server must be prepared to receive technique is that the server must be prepared to receive
retransmissions of the previous (confirmable) request to which a new retransmissions of the previous (confirmable) request to which a new
acknowledgement must be generated. If memory is an issue, a single acknowledgement must be generated. If memory is an issue, a single
buffer can be used for both tasks: Only the message type and code buffer can be used for both tasks: Only the message type and code
must be updated, changing the message id is optional. Once the must be updated, changing the message id is optional. Once the
resource representation is known, it is added as new payload at the resource representation is known, it is added as new payload at the
end of the stub response. Acknowledgements still can be sent as end of the stub response. Acknowledgements still can be sent as
described before as long as no additional options are required to described before as long as no additional options are required to
describe the payload. describe the payload.
4.4.2.2. Message Parsing 3.4.2.2. Message Parsing
Both CoAP clients and servers must construct outgoing CoAP PDUs and Both CoAP clients and servers must construct outgoing CoAP PDUs and
parse incoming messages. The basic message header consists of only parse incoming messages. The basic message header consists of only
four octets and thus can be mapped easily to an internal data four octets and thus can be mapped easily to an internal data
structure, considering the actual byte order of the host. Once the structure, considering the actual byte order of the host. Once the
message is accepted for further processing, the set of options message is accepted for further processing, the set of options
contained in the received message must be decoded to check for contained in the received message must be decoded to check for
unknown critical options. To avoid multiple passes through the unknown critical options. To avoid multiple passes through the
option list, the option parser might maintain a bit-vector where each option list, the option parser might maintain a bit-vector where each
bit represents an option number that is present in the received bit represents an option number that is present in the received
request. The delta-encoded option number indicates the number of request. The delta-encoded option number indicates the number of
left-shift operations to apply on a bit mask to set the corresponding left-shift operations to apply on a bit mask to set the corresponding
bit. bit.
In addition, the byte index of every option is added to a sparse list In addition, the byte index of every option is added to a sparse list
(e.g. a one-dimensional array) for fast retrieval. This particularly (e.g. a one-dimensional array) for fast retrieval. This
enables efficient reduced-function handling of options that might particularly enables efficient reduced-function handling of options
occur more than once such as Uri-Path. In this implementation that might occur more than once such as Uri-Path. In this
strategy, the delta is zero for any subsequent path segment, hence implementation strategy, the delta is zero for any subsequent path
the stored byte index for option 9 (Uri-Path) will be overwritten to segment, hence the stored byte index for option 9 (Uri-Path) will be
hold a pointer to the last occurrence of that option, i.e., only the overwritten to hold a pointer to the last occurrence of that option,
last path component actually matters. (Of course, this requires i.e., only the last path component actually matters. (Of course,
choosing resource names where the combination of (final Uri-Path this requires choosing resource names where the combination of (final
component, final Uri-Query component) is server-wide unique. Uri-Path component, final Uri-Query component) is server-wide unique.
Note: Where skipping all but the last path segment is not feasible Note: Where skipping all but the last path segment is not feasible
for some reason, resource identification could be ensured by some for some reason, resource identification could be ensured by some
hash value calculated over the path segments. For each segment hash value calculated over the path segments. For each segment
encountered, the stored hash value is updated by the current encountered, the stored hash value is updated by the current
option value. This works if a cheap _perfect hashing_ scheme can option value. This works if a cheap _perfect hashing_ scheme can
be found for the resource names. be found for the resource names.
Once the option list has been processed at least up to the highest Once the option list has been processed at least up to the highest
option number that is supported by the application, any known option number that is supported by the application, any known
critical option and all elective options can be masked out to critical option and all elective options can be masked out to
determine if any unknown critical option was present. If this is the determine if any unknown critical option was present. If this is the
case, this information can be used to create a 4.02 response case, this information can be used to create a 4.02 response
accordingly. (Note that the remaining options also must be processed accordingly. (Note that the remaining options also must be processed
to add further critical options included in the original request.) to add further critical options included in the original request.)
4.4.2.3. Storing Used Message IDs 3.4.2.3. Storing Used Message IDs
If CoAP is used directly on top of UDP (i.e., in NoSec mode), it If CoAP is used directly on top of UDP (i.e., in NoSec mode), it
needs to cope with the fact that the UDP datagram transport can needs to cope with the fact that the UDP datagram transport can
reorder and duplicate messages. (In contrast to UDP, DTLS has its reorder and duplicate messages. (In contrast to UDP, DTLS has its
own duplicate detection.) CoAP has been designed with protocol own duplicate detection.) CoAP has been designed with protocol
functionality such that rejection of duplicate messages is always functionality such that rejection of duplicate messages is always
possible. It is at the discretion of the receiver if it actually possible. It is at the discretion of the receiver if it actually
wants to make use of this functionality. Processing of duplicate wants to make use of this functionality. Processing of duplicate
messages comes at a cost, but so does the management of the state messages comes at a cost, but so does the management of the state
associated with duplicate rejection. Hence, a receiver may have good associated with duplicate rejection. Hence, a receiver may have good
skipping to change at page 25, line 15 skipping to change at page 19, line 46
+----------+----------------+-----------------+ +----------+----------------+-----------------+
| MID base | K-bit bitfield | base time value | | MID base | K-bit bitfield | base time value |
+----------+----------------+-----------------+ +----------+----------------+-----------------+
| MID_0 | 010010101001 | t_0 | | MID_0 | 010010101001 | t_0 |
| | | | | | | |
| MID_1 | 111101110111 | t_1 | | MID_1 | 111101110111 | t_1 |
| | | | | | | |
| ... etc. | | | | ... etc. | | |
+----------+----------------+-----------------+ +----------+----------------+-----------------+
Table 1: A per-peer table for storing MIDs based on MID\\_i Table 1: A per-peer table for storing MIDs based on MID\_i
The presence of a table row with base MID_i (regardless of the The presence of a table row with base MID_i (regardless of the
bitfield values) indicates that a value MID_i has been received at a bitfield values) indicates that a value MID_i has been received at a
time t_i. Subsequently, each bitfield bit k (0...K-1) in a row i time t_i. Subsequently, each bitfield bit k (0...K-1) in a row i
corresponds to a received MID value of MID_i + k + 1. If a bit k is corresponds to a received MID value of MID_i + k + 1. If a bit k is
0, it means a message with corresponding MID has not yet been 0, it means a message with corresponding MID has not yet been
received. A bit 1 indicates such a message has been received already received. A bit 1 indicates such a message has been received already
at approximately time t_i. This storage structure allows e.g. with at approximately time t_i. This storage structure allows e.g. with
k=64 to store in best case up to 130 MID values using 20 bytes, as k=64 to store in best case up to 130 MID values using 20 bytes, as
opposed to 260 bytes that would be needed for a non-sequential opposed to 260 bytes that would be needed for a non-sequential
storage scheme. storage scheme.
The time values t_i are used for removing rows from the table after a The time values t_i are used for removing rows from the table after a
preset timeout period, to keep the MID store small in size and enable preset timeout period, to keep the MID store small in size and enable
these MIDs to be safely re-used in future communications. (Note that these MIDs to be safely re-used in future communications. (Note that
the table only stores one time value per row, which therefore needs the table only stores one time value per row, which therefore needs
to be updated on receipt of another MID that is stored as a single to be updated on receipt of another MID that is stored as a single
bit in this row. As a consequence of only storing one time value per bit in this row. As a consequence of only storing one time value per
row, older MID entries typically time out later than with a simple row, older MID entries typically time out later than with a simple
per-MID time value storage scheme. The end-point therefore needs to per-MID time value storage scheme. The end-point therefore needs to
ensure that this additional delay before MID entries are removed from ensure that this additional delay before MID entries are removed from
the table is much smaller than the time period after which a peer the table is much smaller than the time period after which a peer
starts to re-use MID values due to wrap-around of a peer's MID starts to re-use MID values due to wrap-around of a peer's MID
variable. One solution is to check that a value t_i in a table row variable. One solution is to check that a value t_i in a table row
is still recent enough, before using the row and updating the value is still recent enough, before using the row and updating the value
t_i to current time. If not recent enough, e.g. older than N t_i to current time. If not recent enough, e.g. older than N
seconds, a new row with an empty bitfield is created.) [Clearly, seconds, a new row with an empty bitfield is created.) [Clearly,
these optimizations would benefit if the peer were much more these optimizations would benefit if the peer were much more
conservative about re-using MIDs than currently required in the conservative about re-using MIDs than currently required in the
protocol specification.] protocol specification.]
The optimization described is less efficient for storing randomized The optimization described is less efficient for storing randomized
MIDs that a CoAP end-point may encounter from certain peers. To MIDs that a CoAP end-point may encounter from certain peers. To
solve this, a storage algorithm may start in a simple MID storage solve this, a storage algorithm may start in a simple MID storage
mode, first assuming that the peer produces non-sequential MIDs. mode, first assuming that the peer produces non-sequential MIDs.
While storing MIDs, a heuristic is then applied based on monitoring While storing MIDs, a heuristic is then applied based on monitoring
some "hit rate", for example, the number of MIDs received that have a some "hit rate", for example, the number of MIDs received that have a
Most Significant Byte equal to that of the previous MID divided by Most Significant Byte equal to that of the previous MID divided by
the total number of MIDs received. If the hit rate tends towards 1 the total number of MIDs received. If the hit rate tends towards 1
over a period of time, the MID store may decide that this particular over a period of time, the MID store may decide that this particular
CoAP end-point uses sequential MIDs and in response improve CoAP end-point uses sequential MIDs and in response improve
efficiency by switching its mode to the bitfield based storage. efficiency by switching its mode to the bitfield based storage.
4.4.3. (Other Application Protocols...) 3.4.3. (Other Application Protocols...)
5. Control Plane Protocols
5.1. Link Layer Support 4. Control Plane Protocols
ARP, ND; 6LoWPAN-ND 4.1. Link Layer Support
5.2. Network Layer ARP, ND; 6LoWPAN-ND
4.2. Network Layer
ICMP, ICMPv6, IGMP/MLD ICMP, ICMPv6, IGMP/MLD
5.3. Routing 4.3. Routing
RPL, AODV/DYMO, OLSRv2 RPL, AODV/DYMO, OLSRv2
5.4. Host Configuration and Lookup Services 4.4. Host Configuration and Lookup Services
DNS, DHCPv4, DHCPv6 DNS, DHCPv4, DHCPv6
5.5. Network Management 4.5. Network Management
SNMP, netconf? SNMP, netconf?
5.5.1. SNMP 4.5.1. SNMP
Author: Brinda M C Author: Brinda M C
This section describes an approach for developing a light-weight SNMP This section describes an approach for developing a light-weight SNMP
agent for resource constrained devices running the 6LoWPAN/RPL agent for resource constrained devices running the 6LoWPAN/RPL
protocol stack. The motivation for the work is driven by two major protocol stack. The motivation for the work is driven by two major
factors: factors:
o SNMP plays a vital role in monitoring and managing any operational o SNMP plays a vital role in monitoring and managing any operational
network; 6LoWPAN based WSN is no exception to this. network; 6LoWPAN based WSN is no exception to this.
o There is a need for building a light-weight SNMP agent which o There is a need for building a light-weight SNMP agent which
consumes less memory and less computational resources. consumes less memory and less computational resources.
The following subsections are organized as follows: The following subsections are organized as follows:
o Section 5.5.1.1 provides some background. o Section 4.5.1.1 provides some background.
o In Section 5.5.1.2, we revisit existing SNMP implementation in the o In Section 4.5.1.2, we revisit existing SNMP implementation in the
context of memory constrained devices. context of memory constrained devices.
o In Section 5.5.1.3, we present our approach for building a memory o In Section 4.5.1.3, we present our approach for building a memory
efficient SNMP agent. efficient SNMP agent.
o Using a realistic example, in Section 5.5.1.4, we illustrate how o Using a realistic example, in Section 4.5.1.4, we illustrate how
the proposed method can be implemented. the proposed method can be implemented.
o In Section 5.5.1.5, we explore a few ideas which can further help o In Section 4.5.1.5, we explore a few ideas which can further help
in improving the memory utilization. in improving the memory utilization.
5.5.1.1. Background 4.5.1.1. Background
Our initial SNMP agent implementation was completely based on Net- Our initial SNMP agent implementation was completely based on Net-
SNMP, well-known open-source network monitoring and management SNMP, well-known open-source network monitoring and management
software. After porting the agent on to the TelosB mote, we observed software. After porting the agent on to the TelosB mote, we observed
that it occupies a text program memory of more than 8 KiB on TinyOS that it occupies a text program memory of more than 8 KiB on TinyOS
and Contiki OS platforms. (Note that both these platforms already and Contiki OS platforms. (Note that both these platforms already
use compiler optimizations to minimize the memory footprint.) 8 KiB use compiler optimizations to minimize the memory footprint.) 8 KiB
is already non-negligible given the 48 KiB program memory limit of is already non-negligible given the 48 KiB program memory limit of
TelosB. Added to this, the memory taken up by 6LoWPAN and the TelosB. Added to this, the memory taken up by 6LoWPAN and the
related protocol stacks are ever growing, causing serious memory related protocol stacks are ever growing, causing serious memory
crunch in the resource constrained devices. We reached a situation crunch in the resource constrained devices. We reached a situation
where we could not build an image on the TinyOS/Contiki OS platforms where we could not build an image on the TinyOS/Contiki OS platforms
with our SNMP agent. with our SNMP agent.
We came across SNMPv1 agent implementations elsewhere in the We came across SNMPv1 agent implementations elsewhere in the
literature which also report similar memory consumption. This literature which also report similar memory consumption. This
motivated us to have a re-look at the existing SNMP agent motivated us to have a re-look at the existing SNMP agent
implementation, and explore the possibility of an alternate implementation, and explore the possibility of an alternate
implementation using altogether a different approach. implementation using altogether a different approach.
5.5.1.2. Revisiting SNMP implementation for resource constrained 4.5.1.2. Revisiting SNMP implementation for resource constrained
devices devices
If we look at a typical SNMP agent implementation, we can see that If we look at a typical SNMP agent implementation, we can see that
much of the memory consuming code is pertaining to ASN.1 related SNMP much of the memory consuming code is pertaining to ASN.1 related SNMP
PDU parsing and SNMP PDU build operations. The SNMP parsing mainly PDU parsing and SNMP PDU build operations. The SNMP parsing mainly
recovers various fields from the incoming PDU, such as the OIDs, recovers various fields from the incoming PDU, such as the OIDs,
whereas the SNMP PDU build is the reverse operation of building the whereas the SNMP PDU build is the reverse operation of building the
response PDU from the OIDs. response PDU from the OIDs.
The key observation is that, for a given MIB definition, an OID of The key observation is that, for a given MIB definition, an OID of
interest contained in the incoming SNMP PDU is already available, interest contained in the incoming SNMP PDU is already available,
albeit in an encoded form. This enables identifying the OID from the albeit in an encoded form. This enables identifying the OID from the
packet in its "raw" form, simplifying parser operation. packet in its "raw" form, simplifying parser operation.
We also can make use of this observation while building the response We also can make use of this observation while building the response
SNMP PDU. For a given MIB definition, we can think of statically SNMP PDU. For a given MIB definition, we can think of statically
having a pre-composed ASN.1 encoded version of OIDs, and use them having a pre-composed ASN.1 encoded version of OIDs, and use them
while constructing the response SNMP PDU. while constructing the response SNMP PDU.
5.5.1.3. Proposed approach for building an memory efficient SNMP agent 4.5.1.3. Proposed approach for building an memory efficient SNMP agent
As noted in the previous section, since an SNMP OID is already As noted in the previous section, since an SNMP OID is already
_contained_ in the incoming network PDU, we came up with a simple OID _contained_ in the incoming network PDU, we came up with a simple OID
signature identification method performed directly on the network PDU signature identification method performed directly on the network PDU
through simple memory comparisons and table look-ups. Once the OID through simple memory comparisons and table look-ups. Once the OID
has been identified from the packet "in situ", the corresponding per- has been identified from the packet "in situ", the corresponding per-
OID processing is carried out. Through this scheme we completely OID processing is carried out. Through this scheme we completely
eliminated expensive SNMP parse operations. eliminated expensive SNMP parse operations.
For the SNMP PDU build, we use _pre-encoded_ OID variables which can For the SNMP PDU build, we use _pre-encoded_ OID variables which can
skipping to change at page 29, line 27 skipping to change at page 23, line 17
depending on the request OID. Now that the expensive build operation depending on the request OID. Now that the expensive build operation
is taken care, what remains is the construction of the overall SNMP is taken care, what remains is the construction of the overall SNMP
pdu which can be built through simple logic. Through this scheme we pdu which can be built through simple logic. Through this scheme we
completely eliminated expensive SNMP build operations. completely eliminated expensive SNMP build operations.
Based on these ideas, we have re-architected our original SNMP agent Based on these ideas, we have re-architected our original SNMP agent
implementation and with our new implementation we were able to bring implementation and with our new implementation we were able to bring
down its text memory usage all the way down to 4 KiB from the native down its text memory usage all the way down to 4 KiB from the native
SNMP agent implementation which occupied 8 KiB. SNMP agent implementation which occupied 8 KiB.
5.5.1.3.1. Discussion on memory usage 4.5.1.3.1. Discussion on memory usage
With respect to the memory usage, while we have achieved major With respect to the memory usage, while we have achieved major
reduction in terms of text program memory, which occupies a major reduction in terms of text program memory, which occupies a major
chunk of memory, a question might come to mind with regard to the chunk of memory, a question might come to mind with regard to the
static memory allocation for maintaining the tables. We found that static memory allocation for maintaining the tables. We found that
this is not very significant to start with. Through an efficient this is not very significant to start with. Through an efficient
table representation, we further optimized the memory consumption. table representation, we further optimized the memory consumption.
We could do so because a typical OID description is mainly dominated We could do so because a typical OID description is mainly dominated
by a fixed part of the hierarchy. This enables us to define few by a fixed part of the hierarchy. This enables us to define few
static prefixes, each corresponding to a particular hierarchy level static prefixes, each corresponding to a particular hierarchy level
of the OID. In the context of 6LoWPAN, it can be expected that the of the OID. In the context of 6LoWPAN, it can be expected that the
number of hierarchy levels will be small. number of hierarchy levels will be small.
5.5.1.4. Example 4.5.1.4. Example
This section illustrates the simplicity and practicality of our This section illustrates the simplicity and practicality of our
approach with an example. Let us consider the fragment of a approach with an example. Let us consider the fragment of a
representative MIB definition depicted in Figure 1 representative MIB definition depicted in Figure 1
iso iso
| |
org org
| |
dod dod
| |
internet internet
| |
mgmt.mib-2 mgmt.mib-2
| |
skipping to change at page 30, line 29 skipping to change at page 24, line 13
| |
+-- -R-- INTEGER lowpanMoteBatteryVoltageP(1) +-- -R-- INTEGER lowpanMoteBatteryVoltageP(1)
+-- -R-- Counter lowpanFramesReceivedP(2) +-- -R-- Counter lowpanFramesReceivedP(2)
+-- -R-- Counter lowpanFramesSentP(3) +-- -R-- Counter lowpanFramesSentP(3)
+-- -R-- Counter ipv6ForwardedMsgP(4) +-- -R-- Counter ipv6ForwardedMsgP(4)
+-- -R-- Counter OUTSolicitationP(5) +-- -R-- Counter OUTSolicitationP(5)
+-- -R-- Counter OUTAdvertisementP(6) +-- -R-- Counter OUTAdvertisementP(6)
Figure 1: A fragment of a MIB hierarchy Figure 1: A fragment of a MIB hierarchy
5.5.1.4.1. Optimized SNMP Parsing 4.5.1.4.1. Optimized SNMP Parsing
Let us consider a GET request for the OIDs lowpanMoteBatteryVoltageP Let us consider a GET request for the OIDs lowpanMoteBatteryVoltageP
and lowpanFramesSentP. Corresponding to these OIDs, a C array dump and lowpanFramesSentP. Corresponding to these OIDs, a C array dump
of the network PDU of SNMP packet with two OIDs in a variable binding of the network PDU of SNMP packet with two OIDs in a variable binding
would look as in Figure 2. would look as in Figure 2.
char snmp_get_req_pkt[] = { char snmp_get_req_pkt[] = {
0x30, 0x81, 0x3d, 0x02, 0x01, 0x00, 0x04, 0x06, 0x30, 0x81, 0x3d, 0x02, 0x01, 0x00, 0x04, 0x06,
0x70, 0x75, 0x62, 0x6c, 0x69, 0x63, 0xa0, 0x30, 0x70, 0x75, 0x62, 0x6c, 0x69, 0x63, 0xa0, 0x30,
0x02, 0x04, 0x28, 0x29, 0xe4, 0x5d, 0x02, 0x01, 0x02, 0x04, 0x28, 0x29, 0xe4, 0x5d, 0x02, 0x01,
skipping to change at page 31, line 27 skipping to change at page 25, line 9
0x90, 0x12, 0x0a, 0x01, 0x03, 0x05, 0x00] 0x90, 0x12, 0x0a, 0x01, 0x03, 0x05, 0x00]
There is a significant overlap between the two OIDs, which can be There is a significant overlap between the two OIDs, which can be
used to simplify the parsing process. We can, for instance, define used to simplify the parsing process. We can, for instance, define
one statically initialized array containing elements common between one statically initialized array containing elements common between
these OIDs. Using this notion of common prefix idea, we can come up these OIDs. Using this notion of common prefix idea, we can come up
with an optimized table and the OID identification then boils down to with an optimized table and the OID identification then boils down to
simple memory comparisons within this table. The optimized table simple memory comparisons within this table. The optimized table
construction will also result in scalability. construction will also result in scalability.
5.5.1.4.2. Optimized SNMP Build 4.5.1.4.2. Optimized SNMP Build
Extending the same approach as described above, we can build the GET Extending the same approach as described above, we can build the GET
response by plugging in pre-encoded OIDs into the response packets. response by plugging in pre-encoded OIDs into the response packets.
So, corresponding to the GET request for the OIDs as given in section So, corresponding to the GET request for the OIDs as given in section
4.1, we can define C arrays containing pre-encoded OIDs which can go 4.1, we can define C arrays containing pre-encoded OIDs which can go
into the response packet as in Figure 3. into the response packet as in Figure 3.
pdu_batt_volt[] = { pdu_batt_volt[] = {
0x30, 0x11, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02, 0x30, 0x11, 0x06, 0x0b, 0x2b, 0x06, 0x01, 0x02,
0x01, 0x83, 0x90, 0x12, 0x0a, 0x01, 0x01, 0x02, 0x01, 0x83, 0x90, 0x12, 0x0a, 0x01, 0x01, 0x02,
skipping to change at page 32, line 9 skipping to change at page 25, line 40
within the encoded OID where the value needs to be filled-in can be within the encoded OID where the value needs to be filled-in can be
obtained from the length field. obtained from the length field.
The table size optimization discussed in the previous section can be The table size optimization discussed in the previous section can be
applied here, too. applied here, too.
Note: Though we have taken a simple example to illustrate the Note: Though we have taken a simple example to illustrate the
efficacy of the proposed approach, the ideas presented here can efficacy of the proposed approach, the ideas presented here can
easily be extended to other scenarios as well. easily be extended to other scenarios as well.
5.5.1.5. Further improvements 4.5.1.5. Further improvements
A few simple methods can reduce the code size as well as generate A few simple methods can reduce the code size as well as generate
computationally inexpensive code. These methods might sound obvious computationally inexpensive code. These methods might sound obvious
and trivial but are important for constrained devices. and trivial but are important for constrained devices.
o If possible, avoid using memory consuming data types such as o If possible, avoid using memory consuming data types such as
floating point while representing a monitored variable when an floating point while representing a monitored variable when an
equivalent representation of the same that occupies less memory is equivalent representation of the same that occupies less memory is
adequate. For example, while a battery voltage indication could adequate. For example, while a battery voltage indication could
take a fractional value between 0 and 3 V, opt for an 8-bit take a fractional value between 0 and 3 V, opt for an 8-bit
skipping to change at page 32, line 35 skipping to change at page 26, line 18
deployments. Using the same example of battery voltage, one might deployments. Using the same example of battery voltage, one might
think of an OID which represents fewer levels of the battery think of an OID which represents fewer levels of the battery
voltage signifying high, medium, low, very low. voltage signifying high, medium, low, very low.
o While a multi-level hierarchy for MIB definition might improve OID o While a multi-level hierarchy for MIB definition might improve OID
segregation the flip side is that it increases the overall length segregation the flip side is that it increases the overall length
of the OID and results in extra memory and processing overhead. of the OID and results in extra memory and processing overhead.
One may have to make a judicious choice while coming up with the One may have to make a judicious choice while coming up with the
MIB. MIB.
5.5.1.6. Conclusion 4.5.1.6. Conclusion
This subsection proposes a simple SNMP packet processing based This subsection proposes a simple SNMP packet processing based
approach for building a light-weight SNMP agent. While there is approach for building a light-weight SNMP agent. While there is
scope for further improvement, we believe that the proposed method scope for further improvement, we believe that the proposed method
can be a reasonably good starting point for resource constrained can be a reasonably good starting point for resource constrained
6LoWPAN based networks. 6LoWPAN based networks.
6. Security protocols 5. Security protocols
6.1. Cryptography for Constrained Devices 5.1. Cryptography for Constrained Devices
6.2. Transport Layer Security 5.2. Transport Layer Security
TLS, DTLS, ciphersuites, certificates TLS, DTLS, ciphersuites, certificates
6.3. Network Layer Security 5.3. Network Layer Security
IPsec, IKEv2, transforms IPsec, IKEv2, transforms
Advice for a minimal implementation of IKEv2 can be found in Advice for a minimal implementation of IKEv2 can be found in
[I-D.kivinen-ipsecme-ikev2-minimal]. [I-D.kivinen-ipsecme-ikev2-minimal].
6.4. Network Access Control 5.4. Network Access Control
(PANA, EAP, EAP methods) (PANA, EAP, EAP methods)
6.4.1. PANA 5.4.1. PANA
Author: Mitsuru Kanda Author: Mitsuru Kanda
PANA [RFC5191] provides network access authentication between clients PANA [RFC5191] provides network access authentication between clients
and access networks. The PANA protocol runs between a PANA Client and access networks. The PANA protocol runs between a PANA Client
(PaC) and a PANA Authentication Agent (PAA). PANA carries UDP (PaC) and a PANA Authentication Agent (PAA). PANA carries UDP
encapsulated EAP [RFC3748] and includes various operational options. encapsulated EAP [RFC3748] and includes various operational options.
From the point of view of minimal implementation, some of these are From the point of view of minimal implementation, some of these are
not necessary for constrained devices. This section describes a not necessary for constrained devices. This section describes a
minimal PANA implementation for these devices. minimal PANA implementation for these devices.
The minimization objective for this implementation mainly targets The minimization objective for this implementation mainly targets
PaCs because constrained devices often are installed as network PaCs because constrained devices often are installed as network
clients, such as sensors, metering devices, etc. clients, such as sensors, metering devices, etc.
6.4.1.1. PANA AVPs 5.4.1.1. PANA AVPs
Each PANA message can carry zero or more AVPs (Attribute-Value Pairs) Each PANA message can carry zero or more AVPs (Attribute-Value Pairs)
within its payload. [RFC5191] specifies nine types of AVPs (AUTH, within its payload. [RFC5191] specifies nine types of AVPs (AUTH,
EAP-Payload, Integrity-Algorithm, Key-Id, Nonce, PRF-Algorithm, EAP-Payload, Integrity-Algorithm, Key-Id, Nonce, PRF-Algorithm,
Result-Code, Session-Lifetime, and Termination-Cause). All of them Result-Code, Session-Lifetime, and Termination-Cause). All of them
are required by all minimal implementations. But there are some are required by all minimal implementations. But there are some
notes. notes.
Integrity-Algorithm AVP and PRF-Algorithm AVP: Integrity-Algorithm AVP and PRF-Algorithm AVP:
skipping to change at page 34, line 13 skipping to change at page 27, line 35
message integrity protection and PRF_HMAC_SHA1 for pseudo-random message integrity protection and PRF_HMAC_SHA1 for pseudo-random
function (PRF) specified in [RFC5191]. Both of these are based on function (PRF) specified in [RFC5191]. Both of these are based on
SHA-1, which therefore needs to be implemented in a minimal SHA-1, which therefore needs to be implemented in a minimal
implementation. implementation.
Nonce AVP: Nonce AVP:
As the basic hash function is SHA-1, including a nonce of 20 bytes in As the basic hash function is SHA-1, including a nonce of 20 bytes in
the Nonce AVP is appropriate ([RFC5191], section 8.5). the Nonce AVP is appropriate ([RFC5191], section 8.5).
6.4.1.2. PANA Phases 5.4.1.2. PANA Phases
A PANA session consists of four phases -- Authentication and A PANA session consists of four phases -\u002D Authentication and
authorization phase, Access phase, Re-Authentication phase, and authorization phase, Access phase, Re-Authentication phase, and
Termination phase. Termination phase.
Authentication and authorization phase: Authentication and authorization phase:
There are two types of PANA session initiation, PaC-initiated session There are two types of PANA session initiation, PaC-initiated session
and PAA-initiated session. The minimal implementation must support and PAA-initiated session. The minimal implementation must support
PaC-initiated session and does not need to support PAA-initiated PaC-initiated session and does not need to support PAA-initiated
session. Because a PaC (a constrained device) which may be a session. Because a PaC (a constrained device) which may be a
sleeping device, can not receive an unsolicited PANA-Auth-Request sleeping device, can not receive an unsolicited PANA-Auth-Request
skipping to change at page 36, line 41 skipping to change at page 29, line 45
Termination Phase: Termination Phase:
The PaC and PAA should not send a PANA-Termination-Request message The PaC and PAA should not send a PANA-Termination-Request message
except for explicitly terminating a PANA session within the lifetime. except for explicitly terminating a PANA session within the lifetime.
Both the PaC and PAA know their own PANA session lifetime expiration. Both the PaC and PAA know their own PANA session lifetime expiration.
This means the PaC and PAA should not send a PANA-Termination-Request This means the PaC and PAA should not send a PANA-Termination-Request
message when the PANA session lifetime expired because of reducing message when the PANA session lifetime expired because of reducing
message processing cost. message processing cost.
6.4.1.3. PANA session state parameters 5.4.1.3. PANA session state parameters
All PANA implementations internally keep PANA session state All PANA implementations internally keep PANA session state
information for each peer. At least, all minimal implementations information for each peer. At least, all minimal implementations
need to keep PANA session state parameters below (in the second need to keep PANA session state parameters below (in the second
column storage sizes are given in bytes): column storage sizes are given in bytes):
+------------------+----------+-------------------------------------+ +----------------------+------------+-------------------------------+
| State Parameter | Size | Comment | | State Parameter | Size | Comment |
+------------------+----------+-------------------------------------+ +----------------------+------------+-------------------------------+
| PANA Phase | 1 | Used for recording the current PANA | | PANA Phase | 1 | Used for recording the |
| Information | | phase. | | Information | | current PANA phase. |
| | | | | | | |
| PANA Session | 4 | | | PANA Session | 4 | |
| Identifier | | | | Identifier | | |
| | | | | | | |
| PaC's IP address | 6 or 18 | IP Address length (4 bytes for IPv4 | | PaC's IP address and | 6 or 18 | IP Address length (4 bytes |
| and UDP port | | and 16 bytes for IPv6) plus 2 bytes | | UDP port number | | for IPv4 and 16 bytes for |
| number | | for UDP port number. | | | | IPv6) plus 2 bytes for UDP |
| | | | | | | port number. |
| PAA's IP address | 6 or 18 | IP Address length (4 bytes for IPv4 | | | | |
| and UDP port | | and 16 bytes for IPv6) plus 2 bytes | | PAA's IP address and | 6 or 18 | IP Address length (4 bytes |
| number | | for UDP port number. | | UDP port number | | for IPv4 and 16 bytes for |
| | | | | | | IPv6) plus 2 bytes for UDP |
| Outgoing message | 4 | Next outgoing request message | | | | port number. |
| sequence number | | sequence number. | | | | |
| | | | | Outgoing message | 4 | Next outgoing request message |
| Incoming message | 4 | Next expected incoming request | | sequence number | | sequence number. |
| sequence number | | message sequence number. | | | | |
| | | | | Incoming message | 4 | Next expected incoming |
| A copy of the | variable | Necessary to be able to retransmit | | sequence number | | request message sequence |
| last sent | | the message (unless it can be | | | | number. |
| message payload | | reconstructed on the fly). | | | | |
| | | | | A copy of the last | variable | Necessary to be able to |
| Retransmission | 4 | | | sent message payload | | retransmit the message |
| interval | | | | | | (unless it can be |
| | | | | | | reconstructed on the fly). |
| PANA Session | 4 | | | | | |
| lifetime | | | | Retransmission | 4 | |
| | | | | interval | | |
| PaC nonce | 20 | Generated by PaC and carried in the | | | | |
| | | Nonce AVP. | | PANA Session | 4 | |
| | | | | lifetime | | |
| PAA nonce | 20 | Generated by PAA and carried in the | | | | |
| | | Nonce AVP. | | PaC nonce | 20 | Generated by PaC and carried |
| | | | | | | in the Nonce AVP. |
| EAP MSK | 4 | | | | | |
| Identifier | | | | PAA nonce | 20 | Generated by PAA and carried |
| | | | | | | in the Nonce AVP. |
| EAP MSK value | *) | Generated by EAP method and used | | | | |
| | | for generating PANA_AUTH_KEY. | | EAP MSK Identifier | 4 | |
| | | | | | | |
| PANA_AUTH_KEY | 20 | Necessary for PANA message | | EAP MSK value | *) | Generated by EAP method and |
| | | protection. | | | | used for generating |
| | | | | | | PANA_AUTH_KEY. |
| PANA PRF | 4 | Used for generating PANA_AUTH_KEY. | | | | |
| algorithm number | | | | PANA_AUTH_KEY | 20 | Necessary for PANA message |
| | | | | | | protection. |
| PANA Integrity | 4 | Necessary for PANA message | | | | |
| algorithm number | | protection. | | PANA PRF algorithm | 4 | Used for generating |
+------------------+----------+-------------------------------------+ | number | | PANA_AUTH_KEY. |
| | | |
| PANA Integrity | 4 | Necessary for PANA message |
| algorithm number | | protection. |
+----------------------+------------+-------------------------------+
*) (Storage size depends on the key derivation algorithm.) *) (Storage size depends on the key derivation algorithm.)
Note: EAP parameters except for MSK have not been listed here. These Note: EAP parameters except for MSK have not been listed here. These
EAP parameters are not used by PANA and depend on what EAP method you EAP parameters are not used by PANA and depend on what EAP method you
choose. choose.
7. Wire-Visible Constraints 6. Wire-Visible Constraints
o Checksum o Checksum
o MTU o MTU
o Fragmentation and reassembly o Fragmentation and reassembly
o Options -- implications of leaving some out o Options -\u002D implications of leaving some out
o Simplified TCP optimized for LLNs o Simplified TCP optimized for LLNs
o Out-of-order packets o Out-of-order packets
8. Wire-Invisible Constraints 7. Wire-Invisible Constraints
o Buffering o Buffering
o Memory management o Memory management
o Timers o Timers
o Energy efficiency o Energy efficiency
o API o API
o Data structures o Data structures
o Table sizes (somewhat wire-visible) o Table sizes (somewhat wire-visible)
o Improved error handling due to resource overconsumption o Improved error handling due to resource overconsumption
9. IANA Considerations 8. IANA Considerations
This document makes no requirements on IANA. (This section to be This document makes no requirements on IANA. (This section to be
removed by RFC editor.) removed by RFC editor.)
10. Security Considerations 9. Security Considerations
(TBD.) (TBD.)
11. Acknowledgements 10. Acknowledgements
Much of the text of the introduction is taken from the charter of the Much of the text of the introduction is taken from the charter of the
LWIG working group and the invitation to the IAB workshop on LWIG working group and the invitation to the IAB workshop on
Interconnecting Smart Objects with the Internet. Thanks to the Interconnecting Smart Objects with the Internet. Thanks to the
numerous contributors. Angelo Castellani provided comments that led numerous contributors. Angelo Castellani provided comments that led
to improved text. to improved text.
11.1. Contributors 10.1. Contributors
The RFC guidelines no longer allow RFCs to be published with a large The RFC guidelines no longer allow RFCs to be published with a large
number of authors. As there are many authors that have contributed number of authors. As there are many authors that have contributed
to the sections of this document, their names are listed in the to the sections of this document, their names are listed in the
individual section headings as well as alphabetically listed with individual section headings as well as alphabetically listed with
their affiliations below. their affiliations below.
+-------------+-----------------------+-----------------------------+ +------------+--------------------+---------------------------------+
| Name | Affiliation | Contact | | Name | Affiliation | Contact |
+-------------+-----------------------+-----------------------------+ +------------+--------------------+---------------------------------+
| Brinda M C | Indian Institute of | brinda@ece.iisc.ernet.in | | Brinda M C | Indian Institute | brinda@ece.iisc.ernet.in |
| | Science | | | | of Science | |
| | | | | | | |
| Carl | MCSR Labs | carlw@mcsr-labs.org | | Carl | MCSR Labs | carlw@mcsr-labs.org |
| Williams | | | | Williams | | |
| | | | | | | |
| Carsten | Universitaet Bremen | cabo@tzi.org | | Carsten | Universitaet | cabo@tzi.org |
| Bormann | TZI | | | Bormann | Bremen TZI | |
| | | | | | | |
| Esko Dijk | Philips Research | esko.dijk@philips.com | | Esko Dijk | Philips Research | esko.dijk@philips.com |
| | | | | | | |
| Mitsuru | Toshiba | mitsuru.kanda@toshiba.co.jp | | Mitsuru | Toshiba | mitsuru.kanda@toshiba.co.jp |
| Kanda | | | | Kanda | | |
| | | | | | | |
| Olaf | Universitaet Bremen | bergmann@tzi.org | | Olaf | Universitaet | bergmann@tzi.org |
| Bergmann | TZI | | | Bergmann | Bremen TZI | |
| | | | | | | |
| Yuanchen Ma | Hitachi (China) R&D | ycma@hitachi.cn | | Yuanchen | Hitachi (China) | ycma@hitachi.cn |
| | Corporation | | | Ma | R&D Corporation | |
| | | | | | | |
| ... | ... | | | ... | ... | |
+-------------+-----------------------+-----------------------------+ +------------+--------------------+---------------------------------+
12. References 11. References
12.1. Normative References 11.1. Normative References
[I-D.ietf-lwig-terminology]
Bormann, C. and M. Ersue, "Terminology for Constrained
Node Networks", draft-ietf-lwig-terminology-00 (work in
progress), February 2013.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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, September 2007. Networks", RFC 4944, September 2007.
12.2. Informative References 11.2. Informative References
[50billion]
"More Than 50 Billion Connected Devices", ericsson white
paper 284 23-3149 Uen, February 2011, <http://
www.ericsson.com/res/docs/whitepapers/wp-50-billions.pdf>.
[FALL] Fall, K., "A Delay-Tolerant Network Architecture for
Challenged Internets", SIGCOMM 2003.
[I-D.arkko-core-sleepy-sensors] [I-D.arkko-core-sleepy-sensors]
Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O.
Novo, "Implementing Tiny COAP Sensors", Novo, "Implementing Tiny COAP Sensors", draft-arkko-core-
draft-arkko-core-sleepy-sensors-01 (work in progress), sleepy-sensors-01 (work in progress), July 2011.
July 2011.
[I-D.clausen-lln-rpl-experiences]
Clausen, T., Verdiere, A., Yi, J., Herberg, U., and Y.
Igarashi, "Observations of RPL: IPv6 Routing Protocol for
Low power and Lossy Networks",
draft-clausen-lln-rpl-experiences-04 (work in progress),
July 2012.
[I-D.hui-vasseur-roll-rpl-deployment]
Vasseur, J., Hui, J., Dasgupta, S., and G. Yoon, "RPL
deployment experience in large scale networks",
draft-hui-vasseur-roll-rpl-deployment-01 (work in
progress), July 2012.
[I-D.ietf-6lowpan-btle] [I-D.ietf-6lowpan-btle]
Nieminen, J., Patil, B., Savolainen, T., Isomaki, M., Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets
over Bluetooth Low Energy", draft-ietf-6lowpan-btle-09 over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12
(work in progress), July 2012. (work in progress), February 2013.
[I-D.ietf-core-coap] [I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank, Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)", "Constrained Application Protocol (CoAP)", draft-ietf-
draft-ietf-core-coap-11 (work in progress), July 2012. core-coap-13 (work in progress), December 2012.
[I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-06 (work in
progress), September 2011.
[I-D.kivinen-ipsecme-ikev2-minimal] [I-D.kivinen-ipsecme-ikev2-minimal]
Kivinen, T., "Minimal IKEv2", Kivinen, T., "Minimal IKEv2", draft-kivinen-ipsecme-
draft-kivinen-ipsecme-ikev2-minimal-00 (work in progress), ikev2-minimal-01 (work in progress), October 2012.
February 2011.
[I-D.mariager-6lowpan-v6over-dect-ule] [I-D.mariager-6lowpan-v6over-dect-ule]
Mariager, P. and J. Petersen, "Transmission of IPv6 Mariager, P. and J. Petersen, "Transmission of IPv6
Packets over DECT Ultra Low Energy", Packets over DECT Ultra Low Energy", draft-mariager-
draft-mariager-6lowpan-v6over-dect-ule-02 (work in 6lowpan-v6over-dect-ule-02 (work in progress), May 2012.
progress), May 2012.
[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer,
"Computing the Internet checksum", RFC 1071, "Computing the Internet checksum", RFC 1071, September
September 1988. 1988.
[RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the [RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the
Internet checksum", RFC 1141, January 1990. Internet checksum", RFC 1141, January 1990.
[RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via [RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via
Incremental Update", RFC 1624, May 1994. Incremental Update", RFC 1624, May 1994.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
RFC 3748, June 2004. 3748, June 2004.
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap
for Transmission Control Protocol (TCP) Specification for Transmission Control Protocol (TCP) Specification
Documents", RFC 4614, September 2006. Documents", RFC 4614, September 2006.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, April 2007.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, August 2007.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008. Access (PANA)", RFC 5191, May 2008.
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing",
RFC 6606, May 2012.
[WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded [WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded
Internet", ISBN 9780470747995, 2009. Internet", ISBN 9780470747995, 2009.
Author's Address Author's Address
Carsten Bormann (editor) Carsten Bormann (editor)
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28359 Bremen D-28359
Germany Germany
 End of changes. 109 change blocks. 
510 lines changed or deleted 292 lines changed or added

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