6lowpan at 67th IETF meeting WG -------------------------------- Slot: Tue, 2006-11-08 15:10 - 16:10 Room: Spinnaker (San Diego, Sheraton Marina) ================================= Notes taken by: Christian Peter Pii Schumacher Philip Levis Minutes assembled by: Christian Peter Pii Schumacher $Id: 6lowpan-IETF67.txt,v 1.3 2006/11/16 17:46:38 cabo Exp $ ================================= (voice recordings were not used for these minutes, but should be available from http://www.ietf.org) Agenda: Segments: 1. 15:10 - Administrivia - Chairs (10) 2. 15:20 - New header encoding proposal - Hui (15) 3. 15:35 - Chances and risks of the proposal - Chairs (10) 4. 15:45 - Discussion on header format document - All (20) 5. 16:05 - Closing - Chairs 6. 16:10 - Done (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 ... Segment 1 - 15:10 - Administriva - Chairs (10) Document(s): I. Chairs' slides - "http://www3.ietf.org/proceedings/06nov/slides/6lowpan-0.pdf" Conversation: I. The milestones have not been met. Recently the milestones were believed to be near completion but then a new proposal for the encoding aspects of the format document was submitted as WG last call comments. The WG needs to complete its milestones before rechartering. The problem document will not be discussed today but the WG will spend the rest of the meeting discussing the new proposal for the format document. Segment 2 - 15:20 - New header encoding proposal - Hui (15) Document(s): I. New header encoding proposal - "http://www3.ietf.org/proceedings/06nov/slides/6lowpan-1.pdf" Conversation: I. Jonathan Hui gives his presentation to the audience: First concern: parsing in the current format is hard. Not byte aligned, etc. Second concern: inefficient. Carrying bits on protocols even when not used. Third concern: no room for extensions. Seems problematic to bake in particular protocols given how initial this work is. So we want a format that's easier to parse, more concise, and supports protocol extensibility. If we look at past extension attempts, such as sequence numbers, and variably sized fields, this became complicated. E.g., we saw the emergence of the B bit. This also broke alignment, needed to add padding. In the end, it was pretty messy. There was talk about using the proto_type field for extensibility, but this is not given in packets that transport subsequent fragments (it's replaced by the offset field). Modifying adaptation header in the future will very difficult, especially if it becomes standard and widely adopted. If we take a lesson from IPv6, let's start with a basic header. Then we can add additional optional headers. Stacking headers separate orthogonal concepts, enable extensibility, and lead to a clean ordering. Applying these concepts to 6lowpan, we see that all of the different bits are intermingled throughout the header. So why not take IPv6 and take it to guide us in designing a new header format. Goals: 1) Preserve current functionality 2) Reduce concerns: complexity, improve alignment, etc. Each header in the stack has a header type and a header. Three types: Dispatch type, Mesh type, Fragmentation type. (Pictures of example headers.) For example, basic packet has a 2 byte header. Headers can just stack. We took the ordering from IPv6, so fragmentation can be ignored by intermediate nodes. Details. Dispatch type. They are huffman encoded. So the MSB of a basic dispatch byte is 0. The following 7 bits declare the header that follows. IPv6, LOWPAN_HC1, source route, etc. Next one is mesh header. MSBs: 1 then 0. The hops left field is now 4 bits instead of 6. So to preserve functionality a 0xf means adding another hops byte (0 to 255). Third is fragmentation. MSBs: 110 is first packet (offset = 0), 111 is subsequent packets. If we look at comparisons in packet formats, this format is shorter than the current format. In all three cases shown, we've saved a byte, while preserving all of the functionality. The place where we run even is when hops > 4 bits, where both current and proposed are 6 bytes. But we're also supporting more hops: 256. So we get byte savings in almost all cases, equal in one case. Keeps every bit of functionality. Extensibility. We can extend to deep networks. We can extend to new mesh protocol header dispatch values, insert the appropriate header. If we want new upper-layer protocols, we can just use a new value. You could allocate a large number of dispatch values (not advocating this, just saying you could). Summary: Simpler, more concise, follows IPv6 methodology, more extensible. Questions/Comments: Comment: On extensibility if you want to have things you don't know about, you need to include info about how long the header is, whether or not you can ignore it. That's going to take more bits. Result: The WG may define a hop-by-hop header that has a length byte. Comment: Fixed length headers are simpler. Result: Correct, but neither the old nor the current proposal are fixed length headers. Comment: Concerning header diagram number 4 (slide 12). One problem with these levels of header is that you might not know how big they are. One way to do this is to specify a well-known set, but then have new headers have length fields. We might not need it, but we can always put in the document and be done with it. You could always just drop, but there are all kinds of issues with dropping, we don't have the mechanisms for that now. Result: The WG could add IPv6 hop by hop in this scheme. Right now the encoding is TLV free, which many might consider a feature. Comment: When you start changing header size, then fragments end up in different places, all sorts of funny things can happen. Although you get more optimum use of the wire. Another approach is to take the full fixed-length approach and make it simple. Could there be one header? Result: Document defines an ordering, a la V6. Segment 3 - 15:35 - Chances and risks of the proposal - Chairs (10) Document(s): I. Chairs' slides - "http://www3.ietf.org/proceedings/06nov/slides/6lowpan-0.pdf" Conversation: I. The risks and opportunities are: Risks: - Delay format work further - Lose current implementations - Miss market window: zigbee 1.1 is out there - Attitude of "let's do this later": we might put off important things Opportunity: - Orthogonality makes easier to parse - Extensibility can increase usable lifetime - Flexiblity lets us figure things out later, adapt to changes The success factors are: - Be done within two months. - Finish full spec within a week (Nov 15) - Significant review by Nov. 22. - Get two implementations within a month. - WG Last Call Dec 8th. - Can submit by early January. Segment 4 - 15:45 - Discussion on header format document - All (20) Document(s): I. Chairs' slides - "http://www3.ietf.org/proceedings/06nov/slides/6lowpan-0.pdf" Conversation: I. Comments/Questions: Question: Have we already decided this is the right thing? Result: No. Comment: Maybe moving the bits of the current proposal around to make it more parsable. The new proposal seems more flexible and is better. Result: The feel is not that the current proposal is broken rather that there seems to be many opportunities in the new proposal so that it is worth investigating. Comment: The new draft/format has a lot of benefits. Conciseness, fast parsing, lots of good things. But we need to take a close look at these issues. 2 months seems like too short. Compactness of parsing code needs to be validated. Those kinds of compactness based on the reorganization could be made up by reorganizing current header. Question: Is there any extensibility in the existing proposal? Result: No. Comment: 2 implementations in 1 month not very likely. Result: A problem only if you're starting from scratch. Question: How many current implementations? Result: Half a dozen Comment: WG shouldn't only be concerned with short term, but also long term; how likely is the document to be accepted by IESG. Comment: Ordering rules must be defined; the details are complex. Can't judge how hard that is. Conclusion on proposal: The chairs put up the question: Should the WG delay the current process and spend another 2 months fleshing out and deciding on the new proposal? A hum showed clear consensus in the room to do this. Segment 5 - 16:05 - Closing - Chairs N/A Segment 6 - 16:10 - Done N/A