Draft 6LoWPAN WG Minutes ------------------------ MONDAY, March 23, 2009, 15:20..17:20 ROOM: Imperial B CHAIRS: Geoff Mulligan Carsten Bormann Reported by Carsten Bormann, based on notes from Zach Shelby and Carles Gomez Montenegro. Thanks! The 6LoWPAN WG met once at the 74th IETF in San Francisco. The meeting was attended by approximately 65 people. Opening ------- Carsten opened the WG meeting, mentioning that Geoff was not able to attend. No Jabber scribe volunteered. Carsten gave the usual reminder about the IETF "IPR" policy. No change to the agenda. Carsten presented his overview slides and gave an overview of the milestones (slide 3). He gave his personal opinion that the security analysis and architecture documents are far behind and probably not going forward in the WG during this charter period, while the other drafts are in good form. Mark Townsley (outgoing AD) warned about dropping security, "pay me now or pay me later": Security considerations need to be taken into account carefully, or there is a danger that progress will be slowed down in the IESG process. If the security analysis document would be dropped, then the other drafts need a heavier security considerations section. Samita Chakrabarti pointed out that deciding on an architecture is a prerequisite to elaborated work on the security sections, in particular deciding between L3 security vs. L2 security vs. app-layer security. Carsten asked the meeting to focus on solving the remaining problems on the drafts nearing completion. draft-ietf-6lowpan-hc-04 ------------------------ Jonathan Hui presented his slides (slides 7 to 24) and gave the motivation for revisiting header compression: improving compression of global addresses, multicast addresses, traffic class, flow label, hop limit etc.; by switching to context-based header compression. Changes from -03 include: Discussion of what a context database is, 4-bit context ID. Maintenance of context database out of scope. Updated UDP header compression, port compression, make it clear that an equivalent integrity check and permission from the source is required to enable eliding the UDP checksum. Zach Shelby said he was happy with the draft, but compression of multicast could be simplified a bit more, as we don't use multicast that much in 6LoWPANs, apart from FF02::1 and FF02::2. We might be trying to cover too many cases, should cover most common cases first. FF02::1 and FF02::2 should be supported directly in the SAM field, so the address could be compressed to zero bytes for common cases. How much multicast are you doing in 6LoWPANs today? Jonathan: SAM=1 is used e.g. with DHCP. Christopher Dearlove: ROLL has stressed in its charter that multicast is important. David Culler: Multicast is important for ROLL for application groups, such as "all the lights in that switch". Carsten mentioned that in the last meeting, he had one slide the gist of which was "we don't do multicast in 6LoWPANs" -- was he wrong? Half of the bulk of the HC document seemed to him to be multicast compression. Jonathan reminded that FF02::1/FF02::2 will be used. Pascal Thubert: an application might need to disseminate packets through the entire LoWPAN, and since each multicast packet might be relayed a lot, compression might be useful. Mark repeated that ROLL charter mentions not multicast but point-to-multipoint dissemination of packets. Jonathan: We looked at an IPv6 implementation and what multicast format does it use. Zach asked for a check that we are really compressing the most common multicast cases *for 6LoWPAN*. Carsten pointed out that not supporting a specific case wouldn't mean it wouldn't work, just that it would be somewhat less efficient, and asked to continue the multicast discussion on the list. Jonathan continues the presentation, discussing IPv6 Extension Header compression and usability with LOWPAN_NHC. One proposal is to define LOWPAN_NHC codes for each type of extension header. Also, compression of the length to a multiple of bytes might be possible. Zach: ROLL's HYDRO proposal uses extension headers, it would be good to have compression of extension headers for routing protocols in roll. I like the "byte" proposal, maybe even compressing a bit more. David Culler asked about compressing hop-by-hop source routing with this. Jonathan answered that this could be done by defining a new routing type which is not 6lowpan specific. Pascal argued for the proposal, as it doesn't cost more bits and is opening the door to future things. Carsten asked whether there is text for this: Jonathan answered it currently is just slideware. Jonathan also mentioned that ISA100 has decided to use the HC format defined in draft-04, asked for discussing the support of extension headers on the list. Draft is stable, should go to WG last call soon. Carsten asked for how much leeway was left by the adoption of HC-04 by ISA100. Robert Assimiti mentioned that Nivis had implemented this and he liked it, but that multicast is not covered by ISA100. JP Vasseur asked about the status of HC1 as defined in RFC4944: are you planning to deprecate HC1? Carsten summarized his sense of consensus from previous discussions: We will do what implementers appear to have already done: deprecating HC1 and indicating that RFC4944 is updated by the new HC. JP said it would be good to have a timeline for giving a message to the industry that this replaces 4944. Carsten: the strong message will actually be the IESG message that the new HC document is approved. Carsten: But a WG last call on this specific item would be a good idea. Kris Pister: The draft looks great, if we are done that's fine, but if bits need to be changed, we should change them. ISA100 will follow what IETF specifies; there certainly will be other changes in ISA100. Carsten: OK, I read this as if we need to change things, we should change them, but we probably should not go ahead and scramble the whole format. Carsten summarized: We have agreed here to reexamine multicast, look at extension headers. Jonathan: we need to generate discussion on the list and I'll put in a new draft. draft-ietf-6lowpan-nd-02 ------------------------ Zach presented the slides (see the separate ND slide deck). Zach: (Slide 7) What if we have a duplicate Interface Identifier in the network? Initially, a nonce mechanism was pursued, but then the design team came up with a lollipop numbering mechanism on the transaction ID. Pascal: We want to be able to move from one ER to another ER smoothly. We want to reactively fix if there was a mistake. Zach: We want to gracefully ignore the later duplicate. Zach: (Slide 8) The second new feature is fault tolerance, primary and secondary registrations, e.g., to prepare for a move, and to prepare an automatic failover. Could use this for bicasting as well. Pascal: Example: if the primary dies, and the secondary sees that, it can start failing over before the node sees that, which could take a long time. Zach: This can deal with an ER failure on the backbone very quickly. Daniel: This is a good feature -- do we need ND modifications for fault tolerance? Zach: This is using the existing mechanisms, we are just discussing the right way to use the mechanisms for this. You do need some keepalive mechanism, but you could use any mechanism for that. Pascal: The *node* selects the nearest as primary and another as secondary. Zach: (Slide 9) Ad-hoc LoWPANs. First, need to generate a prefix. Use ULAs (RFC 4193); elect one of the routers as (lightweight) ER, mostly to generate and disseminate that prefix. Optionally, that ER could implement a basic whiteboard for DAD and NS. 6LoWPANs are not very often ad-hoc, so this is a special case. Open issue: How to elect the edge router; we don't define that mechanism yet. Carsten was scared about a group of nodes isolating and then connecting back to the 6LoWPAN. How do nodes find out that they should do this? Zach: by listening to RAs; after some timeout the node finds out there is no prefix. Carsten: The reason might be that your radio is dead and cannot receive, only transmit. Zach: This could even be manually configured. Erik Nordmark: If you have a working network with an ER, you continue. How long? Configure candidate ERs. Zach: There is a lot of difficulty with automatic detection and election. Samita: Should we clarify that the ad-hoc ER is a subset of the other ER? Is the ad-hoc LoWPAN always isolated or could it be connected? Zach: Maybe to a PC? But not to global IPv6 Internet. The issue is the prefix. Samita: What would be the application of this case? Zach: Using 6LoWPAN outside the global Internet, a PC and a set of sensors that are not connected to the Internet. Samita: The PC can then act as the ER. David Culler: I'm getting nervous of the format dictating a particular network organization. Do we have sensor networks that are not connecting to anything? Of course, all the time. 6LoWPAN has to permit tiny hosts. We don't dictate what is the host you attach to. Cf. IP over standalone Ethernet LANs. Zach: Your comment is about ad-hoc or more in general? David Culler: The ad-hoc scenario has to work. I'm much more concerned about dictating a specific network management policy. Zach offered that his own personal opinion is that the WG is not just about format, but also about bootstrapping these networks -- ND is much more than a format. We're just defining the operation of those (bootstrap, etc.). But I agree, we don't want to mandate this has to be the only organization that can be used for building up the network. Zach: (Slide 10) Where is the Trickle algorithm actually defined? Philip Levis offered to write the draft about Trickle. Carsten asked whether this is a normative reference of the ND document. Jonathan pointed out that there is more to this than just "use Trickle" -- Trickle needs a sequence number, a way to identify freshness. Zach: We have that in the multi-hop information option. But we have to say how we would use Trickle. Jonathan: E.g., when do you reset the timer. Erik: a future draft might specify the details for Trickle? Should we assume that the ND draft can be completed without Trickle? Zach: We are not using Trickle now. Erik: We can have a forward reference that says a future version could use Trickle. Pascal: if some nodes do Trickle and some others don't, then the nodes that do Trickle will always yield. We should be careful. Samita would like to see this draft move forward. Phil: There are publications about Trickle that could be referenced. Carsten: So the protocol works independent of whether you are using Trickle or not and independent of what variant of Trickle we are using. Zach: You have to be careful about mixing. Carsten: how does a node find out if they are using trickle or which trickle? Would it be easy to define an option in the RAs that says whether and what kind of Trickle is being used? Zach: Let's move this question to the list Zach: Finally, there was the question of which router a host should choose for registration, if it is not participating in a routing algorithm. Preference bits are not enough. A simple depth indicator might be enough. Carsten separated this into two questions. 1) would it be good for a host to get some indication from routers how good they are, 2) would it be good to tie this indication to edge router hop count? Jonathan: we have to be careful of walking the slippery slope of defining a routing protocol. Zach: we need something really simple. Hosts are not participating in a routing algorithm. Carsten: Let me answer my two questions. I think it would be a good thing for a router to indicate some value of goodness, with a couple more bits than we have in IPv6. I would be very careful about defining that value of goodness -- ER hop count might be fine if you don't have a routing protocol, but ND should simply define a large enough value, such as a 16-bit value and a way to compare it. On editorial issues, Zach mentioned he was looking for a better term for RR, as that acronym is already used for many other things. Also, the document might be improved to be easier to understand for outsiders. Newcomers have to look at format and ND first. Ralph Droms (incoming AD) volunteered to provide some input on this. (This led to another discussion about the lack of an architecture document.) Zach indicated that we would like to go for WG last call before Stockholm. JP asked how many implementations are known, Zach knew about 3 for sure and 3 or 4 working on it, with no known implementations however of the ER-backbone. JP pointed out that the IPSO alliance might be a good place to do interop testing. Carsten reminded everyone that having interoperable implementations is not a prerequisite for going to WG last call, but certainly increases the confidence on them. Carsten summarized that there's work to be done, but the core of ND optimization appears to be solid. draft-ietf-6lowpan-usecases-02 ------------------------------ Eunah presented slides (27 to 29 in main deck). 02 clarified the terminology, and aligned it with ND and HC since last draft; the connected home case is to be added. The plan is to be ready for LC within a month. draft-ietf-6lowpan-routing-requirements-01 ------------------------------------------ Eunah presented slides (30 to 35 in main deck). 01 clarified the use of 802.15.4 issues, discussion of hibernation, routing vs. header compression, editorial improvements. Aligned terminology with ND, explained mesh-under and route-over differences. Waiting for some comments, want to go to -02 quickly and then become ready for WG last call. Carsten summarized that these two documents are getting close to conclusion; they are not big documents but have a purpose; let's finish them and last-call them. draft-thubert-6lowpan-simple-fragment-recovery ---------------------------------------------- Pascal presented slides (35 to 45 in main deck). Problem: Increased number of fragments, and increased losses because of multi-hop wireless networks. Waste may cause congestion collapse. Proposal: 32-bit entry SAck bitmap, variable window size, round-robin for multipath. ECN. This requires 4 new dispatch types. JP indicated his support for this work, but is not sure ECN needs to be done in the same document. Pascal gave the reason why ECN is in this as the ACK can also be used for pacing. JP was concerned that, for flow control, we should not be reinventing TCP at the MAC layer. Pascal: The algorithm is a bit like TCP without slow start. Carsten offered his personal opinion: What this essentially does is add transport to the link layer. We wrote the "advice for subnetwork designers" [RFC3819] and we tried to define the situations where link layer might do something like this, e.g. for considerable optimization or where you can't make it work without. But there are also considerations on the impact of link on transport. If you run TCP over this, there will be some interactions between the control loops. Pascal argued that what we are doing here won't be seen by TCP, because we are doing this within a segment. Carsten replied that this is adding delay which might cause TCP retransmits. Look at the TCP RTO calculations. Try to answer the specific questions written up in RFC 3819. JP: Have some applicability section discussing side-effects on TCP, but it will help TCP. Carsten posed as a related question, what would be a good MSS for running TCP over 6LoWPAN. Robert: I believe it is very valuable mechanism. It is very useful to do this in an interoperable manner. ISA100 has a definite need for fragment recovery. Not so sure about ECN. JP asked to add some recommendation on how to use the mechanism. Jonathan: If you have a link where a fragment might traverse multiple radio hops, you need fragment recovery. If you reassemble at every hop, the synchronous acknowledgment at the MAC layer may be enough. Pascal: the fragments might go through different paths. Carsten: We are handling a big cannon, how big is the target we are aiming it at. I would like to see some validation through simulations or experiments in real networks. Carsten asked who in the room would be interested in implementing this, reading the draft, and then said he thought the response was quite a good number for this WG.