<<6lowpan rev2.txt>> Dear Carsten and Geoff. The cutoff date 21st of April for submitting my revised minutes to "IETF65 Preliminary & Interim Materials" is drawing near.
I sent you these minutes on 6th of April, but you have yet to react on them :-( Can I submit these minutes myself? Or how do we proceed? To 6lowpanners: This second version of minutes has not been posted on the mailing list until now, but here you go. Major change is the conversation sections, which are now a bit more narrative and easier to digest. Regards Christian -----Original Message----- From: Schumacher Christian Peter Pii Sent: 6. april 2006 16:17 To: Carsten Bormann; 'Geoff Mulligan' Subject: minutes, updated Importance: High Hi Carsten and Geoff. Here are the new minutes, modified as suggested by Carsten. Regards Christian
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) Segment X: 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 The WG was informed that Gabriel Montenegro will finish the format document. I. Slide 4 - What is 6lowpan? The WG was given a short introduction to 6lowpan, where it was mentioned that unlike other IP over foo, 6lowpan has to reach all the nodes in the network. I. Slide 5 - 6lowpan Wiki The wiki http://6lowpan.tzi.org was promoted. I. Slide 6 - WG secretary Christian Peter Pii Schumacher was unofficially selected as secretary for 6lowpan. It is unofficial since the AD (Mark Townsley) wasn't present. I. Slide 7 - Open Milestones (from WG charter page): The problem statement draft is almost finished. 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 for both 16 and 64 bit addresses. The question was not answered, and the discussion then evolved around how the multicast address mapping works. The answer was that the idea is similar to what Ethernet does. The mapping between L2/L3 address is the last octet of the address. The question was raised whether 64 bit multicast should be supported. No conclusion. An idea was raised to carve up some address space, designated for multicast, unicast and reserved (anycast / mumblecast etc.) addresses. There was some concern whether it makes sense to hardwire this space right now, and it was pointed out that maybe a seperate document could define this address space structure. Summary notes: Latest changes: * Interface identifier derivation 16 zero bits: PAN ID: 16 bit short address * Work 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. * 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 (Carsten) o 8 bits chosen for efficiency reasons (Gabriel) o Have a separate address for the PAN coordinator (Erik) or 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. o Half of address space to unicast. 1/8th to multicast and keep 3/8th for future allocations. (Carstens 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 proposed new charter items were described. It was mentioned that 6lowpan only uses stateless header compression, and 6lowpan should therefore also look into the existing work on stateful header compression. 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. He pointed out 6lowpan will do 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. It was answered that 6lopwan assume stateful is too complex for 6lowpan, given current RFCs, but that we need to work on this topic to assert 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 will give requirements to MANET group (i.e. no multiple interfaces). This should be done before DYMO is submitted for review, which should be end of 2006 DYMO is completely applicable for 6lowpan if one modifies the address and 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. It was 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 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 stuff will actually work. I. & II. Slide 17 - Milestones Milestones are expected to be finished by Decemeber 2006. The chairs asked if people agreed on the current charter suggestion. A question was raised whether the work done by the autoconfig group regarding configuration of MANETs could be applicable, and reduce our charter. The reply was that the work of autoconf is because L3 MANET defined not to have an IP-link model consistent with Ethernet reference and therefore 6lowpan don't need to do anything special. It was pointed out that 6lowpan might benefit from referincing a multi-link draft by Taylor. The charter topic on recommendations for applications mentions TCP. It was mentioned that TCP is regarded as a bad solution in 6lowpan. The reply to this is that 6lowpan will not do new transport protocols. 6lowpan define 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 is a generic ND problem, and that such interoperability issues should be solved people who make the products. It was mentioned that 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, or 6lowpan could risk to end up with broken solutions. The WG will add ND bootstrapping to the topic of ND optimizations, 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 tentatively volunteered to look at 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 document in this area and on RF co-existence. After the feedback the charter received enough consensus. 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 consensus for 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 and requires multicast . Proposed solution uses 15.4 network structure and obviate 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 too simple and stateful ones (RFC 2507, ROHC) too complex . Document problem of why the existing stateful approaches do not make sense for 6lowpans o Recommendations for applications transport, app, discovery/ configuration/commissioning . Document relevant choices . Transport options in IETF tcp, udp, sctp and one more? o Mesh routing . Problem is that existing routing protocols are at L3, need something at L2 . We probably should not do routing protocols itself, but use stuff from MANET . Need to define packet formats for a routing protocol to work with 6lowpan . 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 : Rather than using Hello messages of AODV, 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 . Trying to use MANET specs may not fit timeline (Geoff) . 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 Taylors 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: 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 address, 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 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
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
