Draft 6LoWPAN WG Minutes ------------------------ TUESDAY, July 28, 2009, 09:00..11:30 ROOM: Cabaret CHAIRS: Geoff Mulligan Carsten Bormann Reported by Carsten Bormann, based on notes from Dave Culler and Mathilde Durvy. Thanks! $Revision: 1.3 $ The 6LoWPAN WG met once at the 75th IETF in Stockholm. Opening ------- Carsten opened the WG meeting and gave the usual reminder about the "note well" statement and the IETF "IPR" policy. Carsten presented his overview slides and gave an overview of the milestones (slide 3) with the usual colors: Yellow is late, Red is hopelessly late. No change to the proposed agenda. IEEE 802.15.4e update (slide 7...) --------------------- Rene Struik gave a quick overview over recent work at IEEE 802.15.4e, an amendment of 802.15.4 in particular to better serve the needs of industrial applications such as HART and ISA. Several aspects are being addressed, e.g.: -- Channel Diversity -- Low energy usage of network -- Overhead reduction The timeline calls for a ballot-ready version in November 2009. For 6lowpan, the following could be relevant among others: -- The frame format now allows eliding information that can be inferred from other fields -- A secure acknowledgment, with payload that allows piggybacking additional information -- Reduced size for some header fields (for reducing latency) Rene argued for considering to accommodate some of these updates into 6LoWPAN. Dave Culler added that there is work to arrive at a true, working low power MAC (scheduled listening, sampled listening, etc). We will finally have a low power MAC that works, which will be a 6LoWPAN enabler that was needed for interoperability. Carsten: Something we have to act on? Geoff: How do chips differentiate versions? Rene: There is a version number. Jonathan Hui: 15.4e should have no fundamental impact on Header Compression. Just another form of compression at link layer. Ki-Hyung Kim: How might 15.4e impact ND issues, bootstrapping, commissioning (MAC parameters). Geoff: MAC has to hide MAC parameters such as channel-hopping anyway. A quick discussion of document availability ensued. IEEE 802 policy is that, for 6 months after approval, the documents have to be paid for, so the recommendation is to get the last draft before you have to pay for it. draft-ietf-6lowpan-hc-05 ------------------------ Jonathan Hui presented his slides (slides 17 to 22) and gave the motivation for revisiting header compression: improving compression of global addresses, multicast addresses, traffic class, flow label, hop limit, UDP header etc.; by switching to a combination of stateless and context-based header compression. Jonathan quickly summarized the changes from -04 (see slides). Because of only two bits for stateless mode, support for compressing the unspecified address was removed. The next-header encoding has been fleshed out. Jonathan then outlined planned changes for a -06. Open issue: One of the IPHC dispatch values conflicts with ESC dispatch, would like to discuss it here. Jonathan stated that the draft is now pretty stable and raised the WGLC question. Geoff asked to clarify that the next-header compression values (1110xxxx etc.) is from a different code space than the dispatch byte. After a quick discussion clarifying the position of the next header field (processing in order still possible), Geoff reiterated his concern about the somehat arbitrarily chosen hop limit values of 1, 64, 255. How do we know that 64 is right? In particular, Geoff voiced a concern about hybrid mesh-under/route-over LoWPANs. Jonathan pointed out that you can always choose to not compress (and lose a byte). Carsten mentioned that a mesh-under edge router might want to reduce the hop limit to one to enable better compression, which might conflict with further hops. Geoff summarized: if compressing out hop limit is not fully understood, perhaps those 2 bits (currently used to save 6) might be better used elsewhere. Pascal Thubert: hop limit compression is intended for mesh under! Zach Shelby stated that he is *not* concerned, and that with the changes now planned for 06, HC is definitely ready for LC. JP Vasseur: what is the plan for 4944 header compression? Carsten: HC will explain which parts of 4944 are being updated. The RFC-Index entry for HC will indicate "updates RFC 4944", and an "updated by" will be added on 4944 so people will find the new document. Carsten: We should make the point on the mailing list that we do indeed intend to deprecate 4944. Erik Nordmark: revise RFC?: If parts of 4944 are dead get rid of them to avoid confusion. Carsten: Better combine that with other pending revisions, like the ones for 15.4e. draft-ietf-6lowpan-nd-04 ------------------------ Zach presented the slides (slide 24-35). He mentioned that Carsten is a co-author, just not officially yet, because Zach found out how to coax XML2RFC to show 6 authors only after submitting. The objective is to optimize and simplify ND, enabling DAD over whole LoWPANs. The current document is a combination of 5 drafts since IETF73, with 26 tickets closed so far. There are 4 technical issues on the table and a need for fine tuning and minor editing, but people are already using 6LoWPAN-ND, and Zach would like to know about other implementation efforts beyond those already known. Zach quickly summarized the changes from 02 via 03 to 04, with a focus on simplifying node implementations by removing options, resolving the ad-hoc LoWPAN issue, and improving the detection algorithms. Zach then explained the duplicate identifier detection techniques, now based on a "nonce on boot", and a lollipop TID (got rid of TID history), and quickly explained the NR message processing using a table that "should be included in the I-D". Re the fault tolerance discussion on mailing list, there is new text on recovery from whiteboard crash, no technical change. Ad-hoc LoWPANs can be supported using ULA addresses, with very few changes. Open issues: -- Timeouts and periods, differences from 4861 need to be motivated. -- Optimization of whiteboard state (TID reduced thanks to nonce) - TID can be reduced to 8 bits - lifetime can be reduced to 16 bits -- New issue: unspecified address, cannot be compressed with HC-05. Samita Chakrabarti: But HC not mandatory? Zach: No, not mandatory. But pretty inefficient to send it uncompressed. No special options in the draft whether you are using HC or not in the draft. -- Proposal to remove 6LoWPAN prefix information option (CID field) from the draft and do it somewhere else. Zach: We got good comments and now need comments from a wider audience. Next step: WGLC. Comments from Carsten/Geoff: Lifetime issues -- might need a month sleep cycle. Is 10 s the right unit? Maybe a minute. Need to be discussed in the group. Carsten: Don't remove the CID dissemination -- we'll have to write another spec with a tight coupling to the working of ND -- little value in separation. Of course, ISA100 can do their own CID dissemination, that's not the point. Pascal: what we do is not just 6LoWPAN specific, but ND for non-transitive links. Why put 6LoWPAN very specific stuff there? Zach: Don't tell anybody :-) Carsten: It's called an *option*, because it is *optional*. Erik Nordmark: This is a different option, similar to the 4861 one. Zach: But nodes don't want to be able to process both. Carsten: may have confusion of default CID, that is just the one to save a byte. Concern about transition. Not all CID-filling options define a prefix and v.v. Zach: might need an undefined value for CID! Carsten: let's revisit CID transition mechanisms. Jonathan: Debate about best way how context gets distributed. Currently via RA over multicast with option. Could be unicast over whatever transport. Would not have to repeat context information in all the RAs. Carsten: Spreading different context information to different nodes only works in mesh-under. Pascal: Could do Mobile IP. Multiple contexts need to be spread. How do we define the scope of the context? Geoff: could bind context to SA/DA pair. Zach/Carsten: Right now LoWPAN wide. Dave: keep it simple and get *done*! -> More discussion on mailing list. Keep timeline. draft-ietf-6lowpan-usecases-03 ------------------------------ Eunsook "Eunah" Kim presented slides (50 to 51 in main deck) and stated the draft is now ready for WGLC. The chairs agreed and asked that WGLC comments also include positive comments, not just requests for changes, as we have to make sure the document is supported by the WG. draft-ietf-6lowpan-routing-requirements-03 ------------------------------------------ Eunah presented slides (52 to 54 in main deck) and stated the draft is now ready for WGLC. JP reiterated: The main issue (reference to diagram in doc) is changing the layering architecture of the Internet. If you specify mesh under go to IEEE. There appears to be a normative statement, a MUST for mesh under. Is this document presenting requirements for Layer 2 routing, Layer 3 routing (ROLL)? What is the purpose of the document? A lot of good stuff in there, valuable data. Eunsook: Mainly very 6lowpan specific requirement doc. It's generic for mesh-under and route-over. JP: send the picture to IAB and see what happens... Erik: nothing wrong with the picture, only with the terminology; there are many words for routing at layer 2. Carsten: lots of discussion about architecture these days. We use the model defined in RFC 1122, these layers are descriptive, unlike the OSI model that is prescriptive and assigns specific functions to specific layers. Need flexibility to put just about any functionality at just any layer. JP: MPLS does not do any routing at all. It does forwarding. (Comment from crowd: And "path computation"!) Samita: One more comment about terminology. 4944 already mentioned mesh under. Important information to describe what we say in 4944. ??: Routing is not confined to layer 3. Is "generic term". Terminology not mechanism. Kim (PY?): In any network there should be routing, not just in IP -- routing is a generic term. The question is only at which layer. Ralph Droms: It is an informational doc. Writing it in the document, "if this then this", does not imply WG will do the work. Keep it observational, implications of design choices. In certain situations you need different types of technologies. Geoff: I don't see why we shouldn't last call this now. Security -------- New version, -03 of security analysis; Author could not make it to the WG meeting -- please provide comments on draft on the mailing list. draft-thubert-6lowpan-simple-fragment-recovery-06 ------------------------------------------------- Pascal presented slides (57 to 67 in main deck) and cited the big in-room support at previous meetings for this functionality. Loss of fragments may case (reassembly) buffers to be locked up in small devices. Newest draft removed ECN, added discussion on sizes, and added text on RFC 4944 deprecation (completely replace the fragment headers in RFC 4944). Pascal asked to adopt this draft as a WG document. Carsten: Context: Fragmentation is ugly but needed. We have a basic mechanism in place for fragment recovery each hop: we already have link layer acknowledgments. This draft is an additional safety net. But it should not replace the mechanism in 4944 which works well. Geoff: RFC 4944 is deployed working fine without that. Deprecating 4944 is not an option. Dave: Based on both implementations I know, you can do it with 4944. We could always improve 4944, but the most important thing now is to get things out and widely used. Loss characteristics are quite bursty. There are problems, timers, etc. but I'm very reticent to get into yet another polishing act -- consensus, running code is way more important than this hypothetical case. Richard Kelsey: In my experience it is very important to have fragment recovery without reassembly at every hop. Dave: Retransmission at every hop doesn't require reassembling at every hop. Richard: Yes, but want to attend to this potential issue. Carsten: In summary, there is interest in the work, no consensus to deprecate RFC 4944 fragmentation. draft-hamid-6lowpan-snmp-optimizations-01.txt --------------------------------------------- Juergen Schoenwaelder presented his slides on using SNMP in 6LoWPANs and SNMP optimization (69-87 in the consolidated deck). He presented various fully cooked architectural models from the SNMP world that could be applied to 6LoWPAN with no or limited additional work. Ralph: indirect access to individual 6lowpan nodes a plus? Juergen: Good question. JP: do you think we could incorporate DTLS? Juergen: Chartered in ISMS, supposed to be delivered in January 2010. Samita: Why would we need HC? Juergen: SNMPv3 header: A lot of fields (similar to e.g. the IPv6 flow header) are often zeros. Not saying it's a nice solution, but should think about it. Pascal: does the proxy help to do compression? Juergen: The proxy doesn't help with respect to HC. SNMP has an architectural model, tries to maintain that. Could define a new transport, e.g. using something else in place of BER. Could use proxy to switch between SNMP versions; also solves NAT traversal. Could discuss use of existing proxies in applicability statement. This discussion should be continued on the list. draft-daniel-6lowpan-mib-00.txt ------------------------------- (Time ran out, please read the slides (92-100).) End note -------- Carsten pointed to the 6lowapp Bar BOF on application protocols for constrained nodes and networks at 18:30 in room 202; inter-area discussion.