6lowpan met on 2005-08-04 at IETF 63.
Notes taken by Christian Schumacher, Dirk Kutscher, Joerg Ott; compiled by Carsten Bormann.
(Slides: IETF63-6lowpan-slides.pdf)
The chairs reminded the audience that the 6lowpan WG currently has two deliverables, which already are late:
- The Problem Statement:
- The Encapsulation/Format draft:
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 slideset), asking whether anything in these documents was requiring changes to the existing working group drafts.
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.
After a short discussion about 16-bit addresses, it again was agreed that no changed were required to the format document.
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.
This draft discusses assignment of 16-bit addresses, covered above. No changes to format document required.
draft-daniel-6lowpan-load-adhoc-routing, which is updating 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.
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.