draft-ietf-lwig-terminology-00.txt   draft-ietf-lwig-terminology-01.txt 
LWIG Working Group C. Bormann LWIG Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Intended status: Informational M. Ersue Intended status: Informational M. Ersue
Expires: August 22, 2013 Nokia Siemens Networks Expires: August 29, 2013 Nokia Siemens Networks
February 18, 2013 February 25, 2013
Terminology for Constrained Node Networks Terminology for Constrained Node Networks
draft-ietf-lwig-terminology-00 draft-ietf-lwig-terminology-01
Abstract Abstract
The Internet Protocol Suite is increasingly used on small devices The Internet Protocol Suite is increasingly used on small devices
with severe constraints, creating constrained node networks. This with severe constraints, creating constrained node networks. This
document provides a number of basic terms that have turned out to be document provides a number of basic terms that have turned out to be
useful in the standardization work for constrained environments. useful in the standardization work for constrained environments.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 August 22, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
skipping to change at page 4, line 6 skipping to change at page 4, line 6
There are multiple facets to the constraints on nodes, often applying There are multiple facets to the constraints on nodes, often applying
in combination, e.g.: in combination, e.g.:
o constraints on the maximum code complexity (ROM/Flash); o constraints on the maximum code complexity (ROM/Flash);
o constraints on the size of state and buffers (RAM); o constraints on the size of state and buffers (RAM);
o constraints on the available power. o constraints on the available power.
Section 3 defines a small number of interesting classes ("class-N" Section 3 defines a small number of interesting classes ("class-N"
for N=1,2) of constrained nodes focusing on relevant combinations of for N=0,1,2) of constrained nodes focusing on relevant combinations
the first two constraints. With respect to available power, of the first two constraints. With respect to available power,
[RFC6606] distinguishes "power-affluent" nodes (mains-powered or [RFC6606] distinguishes "power-affluent" nodes (mains-powered or
regularly recharged) from "power-constrained nodes" that draw their regularly recharged) from "power-constrained nodes" that draw their
power from primary batteries or using energy harvesting. power from primary batteries or using energy harvesting.
The use of constrained nodes in networks often also leads to The use of constrained nodes in networks often also leads to
constraints on the networks themselves. However, there may also be constraints on the networks themselves. However, there may also be
constraints on networks that are largely independent from those of constraints on networks that are largely independent from those of
the nodes. We therefore distinguish _constrained networks_ and the nodes. We therefore distinguish _constrained networks_ and
_constrained node networks_. _constrained node networks_.
skipping to change at page 7, line 22 skipping to change at page 7, line 22
cores for constrained devices. While it is expected that the cores for constrained devices. While it is expected that the
boundaries of these classes will move over time, Moore's law tends to boundaries of these classes will move over time, Moore's law tends to
be less effective in the embedded space than in personal computing be less effective in the embedded space than in personal computing
devices: Gains made available by increases in transistor count and devices: Gains made available by increases in transistor count and
density are more likely to be invested in reductions of cost and density are more likely to be invested in reductions of cost and
power requirements than into continual increases in computing power. power requirements than into continual increases in computing power.
Class 0 devices are very constrained sensor-like motes. Most likely Class 0 devices are very constrained sensor-like motes. Most likely
they will not be able to communicate directly with the Internet in a they will not be able to communicate directly with the Internet in a
secure manner. Class 0 devices will participate in Internet secure manner. Class 0 devices will participate in Internet
communications with the help of larger devices acting as proxies or communications with the help of larger devices acting as proxies,
gateways. Class 0 devices generally cannot be secured or managed gateways or servers. Class 0 devices generally cannot be secured or
comprehensively in the traditional sense. They will be most likely managed comprehensively in the traditional sense. They will be most
preconfigured and if ever will be reconfigured rarely with a very likely preconfigured and if ever will be reconfigured rarely with a
small data set. For management purposes, they could answer keepalive very small data set. For management purposes, they could answer
signals and send on/off or basic health indications. keepalive signals and send on/off or basic health indications.
Class 1 devices cannot easily talk to other Internet nodes employing Class 1 devices cannot easily talk to other Internet nodes employing
a full protocol stack such as using HTTP, TLS and related security a full protocol stack such as using HTTP, TLS and related security
protocols and XML-based data representations. However, they have protocols and XML-based data representations. However, they have
enough power to use a protocol stack specifically designed for enough power to use a protocol stack specifically designed for
constrained nodes (e.g., CoAP over UDP) and participate in meaningful constrained nodes (e.g., CoAP over UDP) and participate in meaningful
conversations without the help of a gateway node. In particular, conversations without the help of a gateway node. In particular,
they can provide support for the security functions required on a they can provide support for the security functions required on a
large network. Therefore, they can be integrated as fully developed large network. Therefore, they can be integrated as fully developed
peers into an IP network, but they need to be parsimonious with state peers into an IP network, but they need to be parsimonious with state
skipping to change at page 9, line 13 skipping to change at page 9, line 13
2012. 2012.
[I-D.ietf-6lowpan-btle] [I-D.ietf-6lowpan-btle]
Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 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-12 over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12
(work in progress), February 2013. (work in progress), February 2013.
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-10 (work in Networks", draft-ietf-roll-terminology-11 (work in
progress), January 2013. progress), February 2013.
[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", draft-mariager- Packets over DECT Ultra Low Energy", draft-mariager-
6lowpan-v6over-dect-ule-02 (work in progress), May 2012. 6lowpan-v6over-dect-ule-02 (work in progress), May 2012.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, April 2007. Networking Architecture", RFC 4838, April 2007.
 End of changes. 6 change blocks. 
14 lines changed or deleted 14 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/