6lowpan met on 2005-11-07 13-15h at IETF 64.
Notes taken by Carl Williams and Greg Daley; compiled by Carsten Bormann.
(Slides: see MMM for now.)
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 WG will need to focus on finishing these drafts and delivering the documents before taking on new work; however, some discussion of new work is scheduled for the end of the meeting.
Problem Statement
Nandakishore Kushalnagar (Nandu) gave a quick status update on the problem statement. There was consensus that this draft is ready for submission to the IESG except for the security considerations section. The need for a threat model for 6lowPAN devices was expressed. We need to find out how IPsec fits in. Bob Moskowitz volunteered to help drafting requirements for securing 6lowpan devices.
Format Document
Gabriel Montenegro summarized the changes that led to the current -01 document (see slides, p. 16), including support for 16-bit 802.15.4 adresses, some further changes to the bit allocations and to the mesh delivery mechanisms.
A discussion ensued on multicasts and broadcasts. As 802.15.4 does not support link-layer multicasting, IPv6 multicast needs to be mapped to 15.4 broadcasts. There was some uncertainty whether the 15.4 broadcast was the "right kind" of broadcast for the assumptions that IPv6 multicast users such as IPv6 ND make. The PAN ID needs to be set to identify the link in environments with multiple 802.15.4 networks. Broadcasts can be sent using 16-bit short addresses. Gabriel pointed out that the protocol that is used to build forwarding tables for the mesh also needs to deal with broadcast; Nandu said that the sequence number in the frame might be useful for broadcast. Gabriel promised to add a figure about mesh delivery in the next version of the draft.
A related issue is the relationship between PAN IDs and 6lowpan meshes (= IPv6 links). Gabriel stated that one mesh/link maps to one PAN ID. There was some concern about the stability of PAN IDs, in particular if the PAN ID is used as part of an IPv6 address.
The need for a version field in the packet format was shortly discussed. Nandu pointed out that the protocol type can provide most of the benefits of a version field, at least in packet formats 1 and 2; some remaining uncertainty about how much flexibility this leaves in format 3 was not considered a convincing argument to expend bits for a version field.
As 802.15.4 allows some mixing of long (64-bit) and short (16-bit) MAC addresses, the size of the address in the mesh delivery field is currently not entirely clear. One bit may be taken out of the hop limit field for this purpose, restricting the diameter of the mesh to 63 (from 127). Some considered even 63 to be unrealistically large for a wireless mesh (the packet arrival probabilities multiply). This needs to be discussed further on the mailing list.
to be continued...