Concluded WG Application Protocols for Low-power V6 Networks (6lowapp)
Note: The data for concluded WGs is occasionally incorrect.
| WG | Name | Application Protocols for Low-power V6 Networks | |
|---|---|---|---|
| Acronym | 6lowapp | ||
| Area | Applications Area (app) | ||
| State | Concluded | ||
| Charter | charter-ietf-6lowapp-01 Approved | ||
| Document dependencies | |||
| Personnel | Chairs | Carsten Bormann, Cullen Fluffy Jennings |
Final Charter for Working Group
The 6LoWPAN and ROLL WGs are laying the groundwork to make the
Wireless Embedded Internet a reality, but what application protocols
will we use? Request-response protocols like HTTP are a poor fit to a
communication model with battery-operated, mostly sleeping nodes. In
addition, the usual data formats (both headers and body) are perceived
to be too chatty for the 50-60 byte payloads possible in LoWPANs and
to require too much code for the 8-bit and 16-bit processors
dominating the Internet of Things. Still, it would be a mistake to
start a new silo of application protocols that do not benefit from
existing application area Internet experience.
In the 6lowapp Bar BOF discussion at IETF 75 in Stockholm, five areas
of work were identified. (Section references point to the problem
statement document, http://tools.ietf.org/html/6lowapp-problem .)
a -- Security (section 6).
b -- Transport (section 3).
TCP is often considered relatively heavyweight while UDP lacks the
necessary reliability and ordering services. Results of
6LowApp-related activities might include a "profiling" of TCP that
just includes the necessary elements without losing compatibility,
and/or a set of "building blocks" that could be used in a specific
application protocol to enhance UDP by just the functions actually
required.
c -- Data Representation, both for the application data and for the
protocols themselves. This is often referred to as "binary
encoding"; the main benefits come less from being binary than from
being efficient, easily processable and in particular predictable
(reducing code size). W3C EXI was one of the schemes mentioned.
d -- Base Application Protocols. HTTP and SNMP were mentioned; there is
a strong relationship to the Transport problem on one side and the
data representation problem on the other side. A related area is
the choice of Namespaces, e.g., HTTP has URIs, SNMP has Object
Identifiers.
e -- Service Discovery (section 4).
The BOF will focus on the last three items (c to e), with a clear
emphasis on application (d) and service discovery (e) protocols.
(Rationale: a and b probably require longer time frames and may fan
out to different IETF areas. This does not mean we should ignore them.)
The goal of the BOF is to build up the content for a WG charter
proposal for one initial working group in the APP area.