2.3.1 IPv6 over Low power WPAN (6lowpan)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-07-08

Chair(s):

Carsten Bormann <cabo@tzi.org>
Geoffrey Mulligan <geoff.mulligan@invensysclimate.com>

Internet Area Director(s):

Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Margaret Wasserman <margaret@thingmagic.com>

Mailing Lists:

General Discussion: 6lowpan@lists.ietf.org
To Subscribe: 6lowpan-request@lists.ietf.org
In Body: subscribe
Archive: https://www1.ietf.org/mailman/listinfo/6lowpan

Description of Working Group:

Background/Introduction:

Note: Given that there is not much precedent for this type of activity
at the IETF, the text that follows is of an introductory
nature. Hence, its objective is to give a general idea of the
application area and motivations for the work. In particular, this
section is not to be construed as detailing work items for the working
group. That is done in the following section entitled "Scope of the
Working Group."

Well-established fields such as control networks, and burgeoning ones
such as "sensor" (or transducer) networks, are increasingly being
based on wireless technologies. Most (but certainly not all) of these
nodes are amongst the most constrained that have ever been networked
wirelessly. Extreme low power (such that they will run potentially for
years on batteries) and extreme low cost (total device cost in single
digit dollars, and riding Moore's law to continuously reduce that
price point) are seen as essential enablers towards their deployment
in networks with the following characteristics:

* Significantly more devices than current networks

* Severely limited code and ram space (e.g., highly desirable to
fit the required code--MAC, IP and anything else needed to
execute the embedded application-- in, for example, 32K of flash
memory, using 8-bit microprocessors)

* Unobtrusive but very different user interface for configuration
(e.g., using gestures or interactions involving the physical
world)

* Robustness and simplicity in routing or network fabric

A chief component of these devices is wireless communication
technology. In particular, the IEEE 802.15.4 standard is very
promising for the lower (physical and link) layers. As for higher
layer functions, there is considerable interest from non-IETF groups
in using IP technology (the ZigBee alliance, for example, is currently
studying what such a work item might entail). The working group is
expected to coordinate and interact with such groups.

The required work includes items in the following (incomplete) list:

* IP adaptation/Packet Formats and interoperability
* Addressing schemes and address management
* Network management
* Routing in dynamically adaptive topologies
* Security, including set-up and maintenance
* Application programming interface
* Discovery (of devices, of services, etc)
* Implementation considerations

Whereas at least some of the above items are within the purview of the
IETF, at this point it is not clear that all of them are. Accordingly,
the 6LoWPAN working group will address a reduced, more focused set of
objectives.

Scope of 6lowpan:

Produce "Problems Statement, Assumptions and Goals for IPv6 for
LoWPANs" (draft-ietf-lowpan-goals-assumptions-xx.txt) to define the
problem statement and goals of 6lowpan networks.

Produce "Transmission of IPv6 Packets over IEEE 802.15.4 WPAN
Networks" (draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt) to define the
basic packet formats and sub-IP adaptation layer for transmission of
IPv6 packets over IEEE 802.15.4. This includes framing, adaptation,
header compression and address generation. Furthermore, IEEE 802.15.4
devices are expected to be deployed in mesh topologies.

As such, the working group may also work on an informational document
to show how to apply an existing MANET protocol to LoWPANs (e.g.,
AODV, OLSR, DYMO, etc).

The working group will reuse existing specifications whenever
reasonable and possible.

The working group will also serve as a venue for ongoing discussions
on other topics related to the more complete list outlined above.
Additional related milestones may be added in the future via a
rechartering operation.

Note: As may be obvious from its official name above, this particular
working group will not work on IPv4 over IEEE 802.15.4 specifications.
Given the limitations of the target devices, dual-stack deployments
are not practical. Because of its higher potential for header
compression, its support for the huge number of devices expected and
of cleanly built-in features such as address autoconfiguration, IPv6
is the exclusive focus of the working group.

Goals and Milestones:

Mar 05  Working group last call on draft-ietf-lowpan-goals-assumptions-xx.txt
Apr 05  Submit draft-ietf-lowpan-goals-assumptions-xx.txt to IESG for consideration of publication as Informational
May 05  Working Group Last Call on draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt
Jul 05  Submit draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt to IESG for consideration of publication as Proposed Standard

Internet-Drafts:

  • draft-ietf-6lowpan-format-00.txt
  • draft-ietf-6lowpan-problem-00.txt

    No Request For Comments

    Current Meeting Report
    6lowpan met on 2005-08-04 at [http://www.ietf.org/meetings/IETF-63.html IETF 63].

    Notes taken by Christian Schumacher, Dirk Kutscher, Joerg Ott; compiled by Carsten Bormann.

    (Slides: attachment:IETF63-6lowpan-slides.pdf)

    The chairs reminded the audience that the 6lowpan WG currently has two deliverables, which already are late:

    * The Problem Statement:
    [http://tools.ietf.org/id/draft-ietf-6lowpan-problem draft-ietf-6lowpan-problem]
    * The Encapsulation/Format draft:
    [http://tools.ietf.org/id/draft-ietf-6lowpan-format draft-ietf-6lowpan-format]

    The chair focussed the meeting on finishing these drafts and delivering the documents before taking on new work.

    == Problem Statement ==

    There was a short discussion about the problem statement document.

    Joerg Ott noted that the security considerations section is still TBD.
    Gabriel Montenegro proposed mining the security considerations section of the format document for possible input.

    Joerg also said that there are some application assumptions that sound definitive although there may be many other 6lowpan applications.
    Bob Hinden stated that a requirements document should better retain a narrow focus.

    The room agreed that the problem statement can go forward to ["WGLC"] once the security considerations have been written and some editorial tweaking to address Joerg's concerns has been applied.
    To this end, further input was solicited from the WG.

    == Format Document ==

    Gabriel Montenegro summarized the changes that led to the current document. Apart from a bug fix (M-bit was missing in packet format 3, which required removing one bit from the fragment tag) and editorial improvements, the main change was to the protocol type field.

    Previously, the protocol type was 5 bits, allowing a single-byte fixed overhead. In the current format document, this was changed to 11 bits, requiring two bytes.

    Gabriel clarified that the fragmentation and reassembly function of the encapsulation would be needed not just for IP itself and its various header compression variants, but also for the intra-mesh routing protocol (e.g., AODV).

    Christian Huitema suggested looking at existing IANA registries for protocol types to avoid having to set up another one. Specifically, he suggested looking at IP protocol identifiers. Other people suggested looking at link-layer registries such as Ethertype and PPP protocol IDs. This item requires further work.

    Some discussion ensued about the M-bit and the compression of source addresses in a multi-hop environment. As this discussion could not be completed on-line, Ki Hyung Kim will send an example scenario where this matters to the mailing list.

    When the chairs asked whether the document was ready to go as soon as these two items (protocol type, M-bit/source address) are addressed, Jim Bound noted that the document could benefit from some additional explanation and ASCII art. Once these additions and changes have been made, the sense of the room was that the document is ready to go.

    == New submissions ==

    Six new Internet-Drafts have been submitted for this meeting, with material much of which is clearly out of the current charter of the WG. The chairs quickly went through the documents (one slide each, see [attachment:IETF63-6lowpan-slides.pdf slideset]), asking whether anything in these documents was requiring changes to the existing working group drafts.

    * [http://tools.ietf.org/id/http://www.ietf.org/internet-drafts/draft-chakrabarti-lowpan-ipv6-nd-00.txt draft-chakrabarti-lowpan-ipv6-nd]

    Bob Hinden stood up to correct the slide (of course, IPv6 NeighborDiscovery has been designed having more than just Ethernet in mind).

    Christian Huitema commented that, reading the format document, one could arrive at the conclusion that NeighborDiscovery is not used at all and that MAC addresses could be obtained just by extracting the interface identifier from the IPv6 address, excluding alternatives such as cryptographically generated addresses (CGA).

    It was agreed that the language of the format document should be clarified in this respect.

    Charlie Perkins pointed out that the MANET WG is starting work on NeighborDiscovery for MANETs. It would be a tragedy of both 6lowpan and specific MANET protocols required their own versions of NeighborDiscovery, each.

    After discussion of the options for improving the performance characteristics of NeighborDiscovery for 6lowpan, it was agreed that these approaches could be pursued independently, not requiring any changes in the format document.

    * [http://tools.ietf.org/id/http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-interoperability-01.txt draft-daniel-6lowpan-interoperability]

    After a short discussion about 16-bit addresses, it again was agreed that no changed were required to the format document.

    * [http://tools.ietf.org/id/http://www.ietf.org/internet-drafts/draft-chakrabarti-mobopts-lowpan-req-00.txt draft-chakrabarti-mobopts-lowpan-req]

    This raised the discussion whether a 6lowpan link (Lowpan for short) is one 802.15.4 PAN or a mesh of multiple PANs. After some discussion, it was agreed that the simple approach of having a one-to-one mapping between these two concepts was to be preferred for now. In other words, communication beyond a single PAN requires IPv6 routing.

    It was noted that, currently, it is not defined how arrive at a PAN ID.

    In summary, the mobility considerations were considered interesting, but again independent of the format draft.

    * [http://tools.ietf.org/id/http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-hilow-hierarchical-routing-00.txt draft-daniel-6lowpan-hilow-hierarchical-routing]

    This draft discusses assignment of 16-bit addresses, covered above.
    No changes to format document required.

    * [http://tools.ietf.org/id/http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-load-adhoc-routing-01.txt draft-daniel-6lowpan-load-adhoc-routing], which is updating [http://www.ietf.org/internet-drafts/draft-montenegro-lowpan-aodv-00.txt draft-montenegro-lowpan-aodv]

    Routing is not in the scope of the WG. The document is a good existence proof of an AODV profile tailored to 6lowpan.

    Some discussion about the best way to integrate RFDs (802.15.4 reduced function devices) into the routing ensued.

    No changes to format document required.

    * [http://tools.ietf.org/id/http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-sslp-00.txt draft-daniel-6lowpan-sslp]

    Discovery is not in the scope of the WG. The document is a good existence proof of an SLPv2 variant tailored to 6lowpan.
    No changes to format document required.

    = Conclusion =

    The summary of the discussion was that none of these issues require changes to the current working group drafts, which will progress once re-submitted with the changes discussed. After ["WGLC"], the working group will request a rechartering, in which the submissions will be reconsidered.

    = Activities outside the meeting =

    After the meeting, Christian Schumacher polled the audience for implementation activities. A few hands went up.

    There also was a ["Hallway meeting on 2005-08-01"], which did produce some interesting discussion.

    Slides

    Agenda