6lowpan at 65th IETF meeting WG -------------------------------- Slot: Fri. 9:00 - 11:30 Room: Monet ================================= Notes taken by: Christian Peter Pii Schumacher Rahul C. Shah Minutes assembled by: Christian Peter Pii Schumacher ================================= (voice recordings were not used for these minutes, but should be available from http://www.ietf.org) Agenda: Segments: 1. 09:00 - Intro and agenda, Bormann (10) 2. 09:10 - Format Spec, Montenegro (40) 3. 09:50 - Rechartering, Chairs (60) 4. 10:50 - New Work a. 10:50 - ND, Chakrabarti/Nordmark (25) b. 11:15 - Routing updates, Kim (15) c. 11:30 - Serial interfacing, Sarikaya (5) (Outline for each segment's minutes:) Document(s): I. Document presented during segment X. II. Document presented during segment X. ... Conversation: Conversation during document I. presentation Conversation during document II. presentation ... Summary notes: Conclusions from segment X Segment 1. 09:00 - Intro and agenda, Bormann (10) Document(s): I. "Chairs' slides" http://www3.ietf.org/proceedings/06mar/slides/6lowpan-5.pdf Conversation: I. Slide 3 - 65th IETF: 6lowpan WG Agenda Accepted as proposed. I. Slide 4 - What is 6lowpan? Carsten gave a short introduction to 6lowpan. He mentioned that unlike most other IP over foo, 6lowpan has to do work to reach all the nodes in the network. I. Slide 5 - 6lowpan Wiki Carsten promoted the WG wiki at http://6lowpan.tzi.org I. Slide 6 - WG secretary The chairs noted that they intend to appoint Christian Peter Pii Schumacher as WG secretary for 6lowpan. At the time of the meeting, this was still unofficial since the AD (Mark Townsley) hadn't been contacted to confirm. I. Slide 7 - Open Milestones (from WG charter page): The problem statement draft is essentially finished except for editorial nits. Summary notes: None Segment 2. 09:10 - Format Spec, Montenegro (40): Document(s): I. "(Segment 2): Format spec update" http://www3.ietf.org/proceedings/06mar/slides/6lowpan-2.ppt Conversation: I. Slide 4 - To Discuss The WG was asked whether it makes sense to support unicast address resolution simultaneously for both 16 and 64 bit addresses (sending unavailable addresses as all zero, which therefore needs to be reserved). There was some support, and there seems to be little downside. The discussion then evolved around how the multicast address mapping works. The answer was that the idea is similar to what Ethernet does, but it is based on 16-bit addresses, leaving much less space for distinguishing different L3 multicast addresses. There is a mistake in the current document, as well as another one on the slide showing the fix; the mapping between L2/L3 address is based just on the last octet of the address. Currently, 64 bit addresses are not supported for multicast. The question was raised whether this should be done. Nobody made the argument there was a need; 16-bit is also the address format used for broadcast. An idea was raised to carve up the 16-bit address space and designate the spaces to be used for multicast, unicast and reserved (anycast / mumblecast etc.) addresses. There was some concern whether it makes sense to hardwire this assignment right now, and it was pointed out that maybe a separate document could define this address space structure, possibly as an IANA registry. Carsten proposed to give half of the 16-bit space to unicast, one eighth to multicast (providing 13 bits for the address mapping), and reserve the rest to standards action. Summary notes: Latest changes: * Interface identifier derivation -- 16 zero bits: PAN ID: 16 bit short address * Word of caution on the transient nature of 16 bit short addresses * Reassembly now keyed on destination and datagram size plus the source id and tag * Mesh delivery header now allowing a mix of 16/64 bit addresses (1 bit used for that) leaving 6 bits for hops_left, limiting the diameter of 6lowpans to 63 (more than is actually used in the Internet). * Multicast address mapping patterned after Ethernet: 0 0 1 1 0 0 1 1 | last_8_bits_of_IPv6_mcast_addr o Just 8 bits for multicast address may be less than needed; also it is not clear how multicast and unicast addresses are distinguished at L2 here (Carsten) o 8 bits chosen for efficiency reasons (Gabriel) o 16-bit addresses are allocated by the PAN coordinator (Erik) which would need to know about this allocation; one 16-bit address might be reserved for the PAN coordinator; might have a reserved address space to allow for special things later such as anycast o Need a separate doc to deal with address allocations (Carsten). Erik said that we should not allocate more than half the addresses at the beginning since adding later is not difficult, but gives us room to work. An IANA registry might be the way to organize this allocation. o Half of address space to unicast. 1/8th to multicast and keep 3/8th for future allocations. (Carsten's suggestion) * Mesh layer mcast could map to things like flooding, unicasting to PAN coordinator * All zero address should not be used (16 or 64 bit) Discussion on unicast address mapping to optionally allow both 16 and 64 bit addresses: * How to handle two L2 addresses with different stability characteristics? * Not yet discussed, so left out for now. * Can be put in for now and can be ripped out later without a problem if people do not see a need to support 16 bit addresses (Erik and Carsten). Segment 3. 09:50 - Rechartering, Chairs (60): Document(s): I. "Chairs' slides" http://www3.ietf.org/proceedings/06mar/slides/6lowpan-5.pdf II. "Chairs' slides as modified during the meeting" http://www3.ietf.org/proceedings/06mar/slides/6lowpan-6.pdf Conversation: I. & II. Slide 11 - 6lowpan: Proposed New Charter Items The chairs described the proposed new charter items. It was mentioned that 6lowpan only uses stateless header compression, and 6lowpan should therefore also look into the existing work on stateful header compression and write a brief problem statement how this does (or more likely does not) apply to 6lowpan. It was also mentioned that 6lowpan should define recommendations for protocol selection for applications, and that mesh routing is a very important topic for 6lowpan. The last item is an initial security analysis (threats and gap analysis) I. & II. Slide 12 - Network Setup and IPv6 ND Optimizations (PS) It was determined that the ND optimizations document should also look at network bootstrapping. I. & II. Slide 13 - Problem statement stateful HC (Inf) The question was raised whether we need stateful header compression for 6lowpan. The conclusion was that there was a general assumption that existing stateful work is too complex for 6lowpan, given current RFCs, but that we need to work on this topic to ascertain and document that assumption. I. & II. Slide 15 - Mesh Routing (PS) IETF has created a big hurdle which aims to discourage people from building their own routing protocols within the IETF. Given this, 6lowpan will attempt not to build routing protocols from scratch and preferably reference work from the MANET group. It was asked if IEEE802.15.4 doesn't specify routing protocols. The reply was that ZigBee does (sort of AODV), but not IEEE802.15.4. The work of ZigBee cannot be referenced due to required membership. 6lowpan is an open specification. It was asked if the routing work of IEEE802.11s could be used in 6lowpan. The reply was that we already do something similar. A new question was raised, what the actual difference between DYMO/AODV is. The answer was that DYMO in 6lowpan context is a dumbed simplified version of AODV, which operates very similar to other dumbed down AODV. MANET built core spec upon this for DYMO. DYMO maintains extensibility but does not require everyone to do so. Therefore it was almost built perfectly for 6lowpan. The question of DYMOs compatability with work of IEEE802.11s was asked. The reply was major feature is path accumulation. Second major feature support of non-supported options, transmission of these additional options. 6lowpan is not going to have these additional options. I. & II. Slide 15 - Mesh Routing (PS) continued... 6lowpan needs an L2 ("mesh") routing protocol. Existing work in MANET is on L3 routing. 6lowpan will not define a new routing protocol, but at least needs specific formats for this, and might want to "profile" existing protocols. 6lowpan will give requirements to MANET that also consider its simplifying assumptions (e.g. no multiple interfaces). This should be done before DYMO is submitted for review, which should be end of 2006 Ian Chakeres asserted that DYMO is completely applicable for 6lowpan if one modifies the address format to use L2 instead L3. How 6lowpan references it normatively is an area where the WG must talk to IESG, to frame argument in correct way. Ian also mentioned that MANET has done a lot of work on reducing duplicate packet transmission and non-tree based multicast solutions. A reduced relay-set is recommended for 6lowpan, which means only certain notes retransmit multicast packets instead of every single node. I. & II. Slide 16 - Security Analysis (Inf) 6lowpan will look at security, beyond "being good IETF citizens", and explain different approaches to ensure 6lowpans will actually work (without generating new security specifications). I. & II. Slide 17 - Milestones Milestones are expected to be finished by December 2006. The chairs asked if people agreed on the current charter suggestion. A question was raised whether the work done by the autoconf group regarding configuration of MANETs could be applicable, and reduce our charter. The reply was that the work of autoconf is because L3 MANET goes beyond the IP-link model consistent with Ethernet reference and therefore 6lowpan doesn't need to do anything special. It was pointed out that 6lowpan might benefit from looking at the multi-link subnet draft by Dave Thaler, draft-thaler-intarea-multilink-subnet-issues-00.txt The charter topic on recommendations for applications mentions TCP. One comment was that TCP is often regarded as a bad solution in the sensor network community. The reply to this is that 6lowpan will not do new transport protocols. 6lowpan defines requirements, but will not do the actual tuning of the protocols. The issue of whether 6lowpan should also consider documenting how to merge multiple 6lowpans was raised. One reply was that 6lowpan does not need to solve the generic ND problem (of merging links), but that there may be 6lowpan-specific issues that need solving: the PAN coordinator is a single-point of failure if it fails and loses the mapping to short addresses. The conclusion was that it would be a good idea for 6lowpan to look into this problem. The WG will add ND bootstrapping to the topic of ND optimization, in order to deal with this problem in future work. It was suggested the charter topics should better reflect what documents will actually be produced, since some topics potentially could cover multiple documents (i.e. mesh routing may have both DYMO and AODV) Gabriel Montenegro proposed to look at the specific charter items and to separate work into multiple documents. E.g., he tentatively volunteered to look at network setup/bootstrapping but not ND bootstrapping. 6lowpans potential interoperability with ZigBee was discussed. A recommendation for a beacon extension may be needed. The conclusion is that 6lowpan may need a short document in this area, possibly as part of bootstrap, and on RF co-existence. After discussion, there was consensus in the room to go forward with the charter and the milestones listed. I. & II. Slide 18 - Interim? The interim in January was productive and the chairs polled the interest for having another interim in end of May. There was great interest in having an interim. In terms of location Europe was favored over the US. Summary notes: Rechartering: * Need to see what other protocols and components are missing to make 6lowpan actually work in reality. o Neighbor discovery optimizations (doc mostly exists) . IPv6 ND is too expensive for 6lowpan (requires multicast) . Proposed solution uses 15.4 network structure and obviates multicast by talking to coordinator . Changed ND multicast semantics . Define 6lowpan network setup o Stateful header compression (can we use existing IETF specs on that?) . Stateless may be too simple and existing stateful schemes (RFC 2507, ROHC) too complex . Document problem of why the existing stateful approaches do not apply for 6lowpans o Recommendations for applications -- transport, app, discovery/ configuration/commissioning . Document relevant choices . Transport options in IETF -- tcp, udp, sctp and dccp o Mesh routing . Problem is that existing routing protocols are at L3, need something at L2 . We should not do routing protocols in 6lowpan, but use results from MANET . Need to define packet formats for a routing protocol to work with 6lowpan mesh routing (L2!) . We have an AODV adaptation in draft right now . DYMO could be another choice -- has features of AODV and DSR . Prof. Kim presented some routing optimizations : Use 64 or 16 bit addresses : Use prot-type field to indicate AODV control messages rather than UDP ports : Route cost can utilize the LQI of the PHY layer (There was significant push-back on this, as this does not seem to have left the research stage.) : Rather than using "Hello" messages of AODV, can use 15.4 link layer mechanisms such as ACKs, beacon responses etc. : Minimize power consumption and complexity: - Do not use destination sequence number - Only allow a destination to reply to RREQ (to prevent routing loops) - Do not use local repair - Report back to the originator by RERR upon a link break - Do not maintain the precursor list - Utilize efficient RERR reporting : Reuse existing specs such as AODV and DYMO as much as possible . Change control of the routing specs should lie with MANET (Carsten). However, a concern is that trying to use MANET specs might not fit our timeline (Geoff) On the other hand, doing it in 6lowpan would take several years (Ian) . We can use a MANET protocol like DYMO which is directly applicable, except that the IP addresses need to be changed to IEEE addresses. Can we reference the DYMO spec normatively? That is something that needs to be discussed with IESG, IAB etc. . Ian mentioned that MANET is also working on a proactive protocol, a non-tree based multicast protocol, which are almost directly applicable to 6lowpan. o Security analysis . Security in lowpans is hard . Define threat model . Document suitability of existing key management schemes . Discuss bootstrapping/installation/commissioning/setup issues . Need to look at Dave Thaler's draft (Gabe) o New suggestion -- How separate 6lowpans can join together (Geoff)? Inter-PAN routing, PAN merging and partition. * Can we do these 5 items and finish this round in Dec 06? Charter (see also revised slides): PS: proposed standard Inf: Informational document * 6lowpan Bootstrapping (PS) and 6lowpan IPv6 ND optimizations (PS) * Problem statement stateful header compression (Inf) * Recommendations for 6lowpan applications (Inf) o Transport, app, discovery/configuration/commissioning * 6lowpan mesh routing (n x PS) * 6lowpan security analysis (Inf) Future meetings: * 2 more IETF meetings this year (July and Nov) * Interim meeting? o End of May o Two days o Europe Segment 4. 10:50 - New Work: Document(s): I.. (Segment 4): IPv6 ND optimization http://www3.ietf.org/proceedings/06mar/slides/6lowpan-1.pdf II. (Segment 4): LOAD update http://www3.ietf.org/proceedings/06mar/slides/6lowpan-4.ppt Conversation: I.. (Segment 4): IPv6 ND optimization ====================================== I.. Slide 9 - L2 Mesh Topology Support The topology has a simple assumption: PAN coordinator is IPv6 router. I.. Slide 13 - Avoid multicast DAD Security is important, but we will not reinvent the flavor of SEND. I.. Slide 16 - Minimize unicast NUD? A question was raised whether the semantics are changed with regards to the Neighbor Cache entry. It was clarified there is no cache but an authoritative list of neighbors. I.. Slide 17 - How does router know all hosts? If a host has multiple IPv6 addresses, it might not be reachable by two different addresses. A sender can do nothing about that. If it has a TCP connection with underlying NUD, TCP would happily recast until TCP gives up. IP layer can do nothing about fact that recipient has other address. A host must assume it is dead until it hears a router. The WG should mandate every node makes an address registration to avoid any node avoids doing this. Particularly in the case of 16 bits address, reliable address registration is needed. II. (Segment 4): LOAD update ============================ II. Slide 2 - Change Log It was mentioned that whatever value (LQI) the WG defines should be manufacturer independent. It was concluded that the goal is to define a weak LQI value which is manufacturer independent. In LOAD the measure of LQI gives the option of at least avoiding the weak LQI, which is a conservative approach. II. Slide 3 - Prototype Implementation Hi-low not considered in 6lowpan right now (The third presentation that was planned for segment 4 did not take place as the speaker had to leave before we finally got there.) Summary notes: 6lowpan AODV -- LOAD (Prof. Kim): * Define route cost by LQI and weak links, use hop counts while * avoiding weak links * Several comments: o Default value of weak LQI o Need sequence number to prevent routing loops o Interaction between QoS metric and distance vector routing o Lifetime definition o Link monitoring (route timeout by timers?) o Weak link indicator by LQI o Unidirectional links o RERR for low battery and "route cost not supported" should by avoided * Prototype implementation o http://www.6lowpan.org o Testbed implementation