6lowpan at 69th IETF meeting WG -------------------------------- Slot: Tue, 2007-07-24 9:00 - 11:30 Room: Crystal (Chicago, IL, US) ================================= Notes taken by: David Culler Philip Levis Minutes assembled by: Carsten Bormann $Id: 6lowpan-69.txt,v 1.1 2007/09/07 16:52:53 cabo Exp $ ================================= a voice recording of the meeting may be available at: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf69/ietf69-channel6-tue-am.mp3 (minute 00:12:15 to the end of that recording) Agenda: Segments: 1. 09:00 Introduction, Agenda 2. 09:05 Document Status 3. 09:15 Rechartering Status 4. 09:30 Application Scenarios/Architecture 5. 10:00 Bootstrapping (ND, Commissioning) 6. 10:40 Header Compression for Global 7. 11:00 Interop Testing 8. 11:15 Routing Requirements * Segment 1 -- 09:00 -- Introduction, Agenda -- Chairs Carsten Bormann gives the usual introduction: - We assume people have read the drafts; meeting is not presenting drafts but about working out the tough parts - Be aware of the IPR principles - Full agenda - discussed relationship of presentations to the rechartering What is 6LoWPAN? - Interesting L2 network (small MTU, low BW) - Make it look like an IP link * Segment 2 -- 09:05 -- Document Status -- Chairs (see slides) Discussion: David Culler: Question about process. To go from PS to DS, we need to demonstrate interop? Carsten Bormann: Yes. David Culler: So we're not done until that happens. Geoff Mulligan: There's also a time requirement: 4 to 6 months or so. * Segment 3 -- 09:15 -- Rechartering Status -- Chairs (15) 9:14 Geoff Mulligan: On the mailing list, we sent out a proposed rechartering text with 5 bullet point items on it, that, as far as the WG chairs understand, represent the consensus of the WG. There is now a question about item 5 mesh-under vs. route-over; e.g., which working group will be responsible for routing, whether it be mesh-under or route over, so we propose to scratch the item of routing from the charter for now so we can move forward with remaining elements of the recharter. Mark Townsley: Plenty of work in the areas of the recharter; that work should not be held up. There is a debate going on -- I'm not sure where that's going to happen, but it needs to happen in full before the routing part of the rechartering can go forward. Debate about routing in the large needs to be resolved before IESG knows which aspects happen within the 6LoWPAN. Can add that to the charter if it make sense to have this work go on. Gabriel Montenegro: I think this is a significant change from the consensus that we had at least 1 year ago; consensus was that IP routing belonged elsewhere but that 6LoWPAN would adapt them to what we are doing here. Example TRILL, which uses IS-IS from the routing area. We would work with routing area, e.g. MANET, but somewhere in the routing area, and integrate that here. Geoff Mulligan: not suggesting that we are not do mesh under, but it is clear that L3 routing (Gabriel: routing algorithms) is outside our scope. Some questions about whether L2 meshing is necessary or not, do we want to wait till this is resolved for rechartering? Mark Townsley: The whole IESG has to sign off a new charter; putting putting routing in WG charter at this stage will at least cause questions with Routing Area. Still forming their opinions about what should go on wrt low-power in their area. We can instead fasttrack the other aspects of the recharter. Can still talk about routing issues, but we don't have to charter them just yet. Carsten Bormann: would it help to reduce routing charter item to requirements, such as FFD and RFD. 6LoWPAN specific requirements. Mark Townsley: L2 or L3? Carsten Bormann: Maybe both? Mark Townsley: Sounds fuzzy to me. Kim: Why do we have to consider "route over" in 6LoWPAN WG. What is the relationship to a WG in routing area. Mark Townsley: That is why it makes sense to charter the other items and delay this one. JP Vasseur: Re Carsten -- Seems it would be hard to identify requirements of routing without saying where it takes place. L2 or L3. Also, too early to decide since Routing Area WG is not yet decided. Mark Townsley: Should such a WG to form, than this group may want to define what it needs from routing. Requirements analysis should not presuppose a solution. Geoff: We are done with our work. We need to recharter, as there are important topics that must be tackled for there to be working 6lowpan networks. It sounds like you are guiding us on how to recharter so that we can continue our work while figuring out the issues and getting the lay of the land. It's going to take a while for people to understand the specific requirements of low-power routing. We need to do something, and get on with our work. Mark Townsley: I don't want to prevent you from having the under/over debate. I just don't want it to get in the way of progress elsewhere. Tim Salo: I think that it's important to look at requirements. These networks are different and we need to capture the differences and document them. Mark Townsley: I think it is reasonable to have that discussion if not pre-supposing a solution. David Culler: I want to separate routing protocols from format. Most of what we do here is decide on format, what bits you put in. There's a whole family of discussions which are solely about format, which we can go forward on. For example, whether the format is expressive enough for this community to do mesh under. E.g., we're going to discuss compressibility of global addresses. Our job is to make sure that the format is adequate to express Myeong? Lee: This WG has to be rechartered with respect to the devices available now. Discussing RSN is holding up this WG; there is enough requirements to work on. Tim Salo: change topic -- suggest delete problem statement for justification for stateless header compression -- there is a justification in the problem statement already in the RFC editor queue. Carsten Bormann: but issues of stateful keep coming up -- we even have some item about HC on the agenda today. Tim Salo: Change topic again -- WG may be impeeded by lack of an architectural document. ND document had to propose an architecture to make progress. Mark Townsley: An Architecture draft should be right at the top. Architecture Doc wuld help resolve the debate. It would be great thing to put in the charter. Ki-Hyung Kim: Tight relationship between applications and arch. request on mailing list to divide the charter item to address the two issues. Mark Townsley: at end of meeting today, try to get a sense from WG an whether to strike routing item from the charter, reduce it to requirements that does not presuppose solution, or go ahead and ask that the WG will take on routing. Time thru IESG will increase with scope. Regardless of history -- the current state of affairs is that there is other work going on. Ki-Hyung Kim: Please clarify what is problem with proceeding with routing work. Mark Townsley: getting everybody to understand where the line is between the two routing methods. Not saying that working on mesh routing is out of scope for IETF, but until we understand the requirements, and which requirements the IP routing will be able to meet, it is hard to proceeds without understanding the problem. Don't want to have two directly competing efforts trying to invalidate each other. (Geoff cuts short the discussion for lack of time) ----- * Segment 4 -- 09:30 -- Application Scenarios/Architecture -- EK, GM (30) 9:43 Application Scenarios (Eun-Sook Kim, Nicholas Chevrollier, and Dominik Kaspar) (see slides) Scenario 1 - structural monitoring - some sensors on pillars of a bridge - essentially collection of stars, each static. Scenario 2 - hospital - essentially single low- to medium sized star - moving in an infrastructue of sink nodes - periodic Scenario 3 - vehicular - mobility, multi-hop; energy efficient routing required - car-to-car is Work in Progress Scenario 4 - Home (TBD) Scenario 5 - agricultural - static, multihop network (no mobility), manually configured Identify out of scope scenarios, e.g., ones that are not 802.15.4 PAN, such as RFID tags Carsten Bormann: justified inclusion of this "seemingly boring" topic in WG meeting; encouraged WG members to provide input to authors Tim Salo: good effort, will help clarify requirements, good to include non-802.15.4 scenarios Geoff Mulligan: 6lowpan has 802.15.4 ingrained into its DNA... Phil Levis: great to sketch application areas, but several parts of the document drew conclusions rather than limit themselves to stating requirements. Daniel Park: make sure we clarify here why we actually need IP Nicholas Chevrollier: There is a small section in the draft about why we need IP Ashish: new to 6lowpan, haven't read draft, but: another important area would be industrial sensing and monitoring. Geoff Mulligan: Network Transport Working group of ISA SP100 has adopted 6lowpan; includes industrial players David Culler: in the requirements, include information about the workload, i.e. include traffic patterns, not just topology, include density, not just count; I'd like to suggest that we be sure to discuss the traffic patterns that applications introduce, as that's an important requirement. Not just the number of nodes, but also how dense they are, as protocols for dense and sparse networks can be quite different. 10:04 Architecture - JP Vasseur - Plan to have 1st revision of Architecture document in Sept, please comment on draft. - Table of contents Tutorial Nature of devices Components ("the big section") ND, Bootstrapping, Routing (to be small), QoS, Performance, Security, Mgmt Mesh-under vs Route over Areas of Standardization Things outside the scope JP Vasseur: it is useful to have such a document because you don't have to explain everything again and again Carsten Bormann: This looks like a good textbook proposal; but the IETF is a badly inefficient place to write a textbook. We should not fall into trap of writing a textbook; instead focus on documenting the crucial decisions JP Vasseur: point is to encourage exchange. Carsten Bormann: We have a 6lowpan, we use the Wiki to collect information. Samita Chakrabarti: Good effort. Like more detail on the content of the material. Our ND draft assumes some architecture; we have some part that we want to contribute. Geoff Mulligan: don't want to debate ToC here. Because that is a bit of a change; let's get sense vote on moving forward with arch draft. (Hum indicates consensus in the room that this is a good thing to move forward with.) ----- * Segment 5 -- 10:00 -- Bootstrapping (ND, Commissioning) SC, KK (40) 10:13 Samita Chakrabarti - Neighbor Discovery Optimization (see slides) ND draft assumes some architecture (slides 4 and 5); assumes one PAN coordinator provides PAN ID for entire network and is also the router. (sort of mesh, as in "embed a DAG that covers the network") Ki-Hyung Kim: comments on these slides (before completion of presentation) - assumption of association may not be mandatory, perhaps secondary option - how to handle mobile nodes? - may want to allow multiple IPv6 routers, even if single PAN coordinator Architecture should be discussed in the architecture document. Samita Chakrabarti: - should ND and Bootstrapping documents be combined or separate? - todo - short addresses, bootstrapping, more on security - should draft be published as WG item? - should this be a generic ND solution for non-broadcast, non-multicast networks? Carsten Bormann: When you generalize, you either add or lose complexity. I wouldn't mind generalizing and losing complexity, but we shouldn't add some by generalizing. David Culler: in many cases we can define what we require without becoming overly specified by the particular mechanisms of the 15.4 mac. Example: embed a rooted tree or DAG versus a PAN coordinator and FFD Tim Salo: Think about sleeping nodes, which may e.g. not be able to take part in DAD. Also, do we need to bring in time synchronization? Samita Chakrabarti: out of scope for ND Dave Thaler: There is value in a generic document. - Many of the generic issues appear in other places, e.g. ISATAP. (There even is an RFC called "IPv6 over NBMA", but it seems ATM specific.) - Generic and specific should be separate documents, but it may not make sense for one to wait for the other. In any case, this document should not be the generic one. Jonathan Hui: concern that 15.4 SPEC has no peer-to-peer power mgmt strategy defined, just for stars. So need to be careful about over-depending on aspects that are undefined. Gabriel Montenegro: Fine-grained synchronization would appear to be an IEEE thing. This points out a potential gap in the new charter: do we have formal liason with IEEE WG? Re generality: only generalize if we identify one potential other client. The effort here should stay 15.4 specific. Re SEND -- there is published work that shows that ECC is doable on this kind of devices (Sun Labs), but SEND does not allow other public key families; we might want to entertain something like a SEND extension BOF for this. David Culler: It's not a question of overgeneralizing, but overspecializing. The question of how large a subset of 802.15.4 MAC do we want to assume. One way is to say we need a DAG; another is to say some nodes are FFDs and some are RFDs. The problem with the latter is that there are precise technical meanings to FFD and RFD; specifically, there are no power management techniques for FFD-FFD communication. So we need to be careful on how much we bind ourselves unnecessarily to particular mechanisms that will constrain us in the future. 10:42 Commissioning Draft (Ki-Hyung Kim) (see slides) Joining with or without association among others controls whether a 16-bit address can be used. Carsten Bormann: We can't discuss whether this should be adopted as a WG item because we don't even have a rechartering item. As another comment, commissioning (turning on a device for the first time) is different from bootstrapping (turning on the network at any other time). David Culler: Partial feedback. There seem to be a few questions that hinge on basic architectural questions, such as what MAC mechanisms we carry up, such as beacons. There's also questions of what we autoconfigure. 802.11, for example, we just pick a channel. The architecture document might be able to help figure out what's auto-generated and what's management. Keys are another example, which might be done beforehand or might be commissioning. It seems like the architecture document could help a lot in working these issues out. (?): derive requirements from applications ----- * Segment 6 -- 10:40 -- Header Compression for Global -- David Culler I'd like to distinguish this proposal from stateful HC. There are several places in 6lowpan when we use shared context to do things more efficiently. That's what this is about. 6lowpan has always allowed communication with global addresses. But we can't compress them. HC1 works for link local. But if you use 6lowpan for what IP is typically used for -- internetworking -- you lose much of the virtue of 6lowpan. So the proposal is to extend HC1 to HC1g, extending to the global prefix. Motivation: internetworking. HC1 supports arbitrary addresses, but only alows compression of the link-local prefix. Uncompressed addresses are 32 bytes. When we want to route off the PAN, such as monitoring or control, we're going to a not 802.15.4 device. Most sensornets have this as a piece of their architecture. We can use a gateway, but what about gluing two PANs together, e.g., PANs with different channels, MACs, etc. You also need this if nodes use their real names, rather than their autoconf names. So HC1g says let's have a global as well as a local prefix. Compression of interfaces IDs derived from short addrs. Similar to HC1. Compresses to 2 octets. Allows arbitrary v6 addresses. Supports well-known compressed multicast addrs. HC1 and HC1g identified by different dispatch values. PAN has A compressible global prefix (CGP) associated with it. Prefix is elided when it matches the CGP. HC1g has four addressing modes. HC1g encoding is a single byte. Jonathan Hui: The basic idea is that if you want to use an IID that's derived from a 16-bit address, you can assume the upper 48-bits of IID to be 0. David Culler: We've also done some with multicast address compression. Beyond that, there's a little bit of cleanup. Really applying HC2 approach to L3, rather than a mix of L4/L3, as it is in HC2. Same compression as HC1 for addresses that are not link local. Compression of IIDs derived from short addresses. We didn't get a lot of feedback -- it doesn't seem to be the style of the mailing list to say something like "yeah, that's a good idea". Gabriel Montenegro: Really good work; I agree with the motivation. Wef looked at this with Erik Nordmark a long time ago. We first had some provision for compression of global prefixes. We couldn't figure out how to pull it off. You might have more than one router for an IPv6 link. You might have different routers advertising different IPv6 prefixes, and there's no way to specify the order. So there's no way to say what THE global prefix is. So for expediency, we decided that we'd tackle this later. I don't think you're quite there in terms of multiple prefixes. David Culler: Great point. It gets to the question of format vs. protocol. In a PAN, not only is there a shared PAN id, there's also a shared prefix. This is only saying "when there is a shared prefix, there is a way of expressing the encoding," which is different from "how might that prefix be decided on or advertised." Gabriel Montenegro: You should be clear what assumptions you make in the draft. Going forward, this looks like a great start. David Culler: You're right that you can have multiple IP addresses. This approach applies for the most commonly used prefix. Gabriel Montenegro: But which one? Samita Chakrabarti: I would also like to support working on this draft. Global prefixes and addresses are very important, and so work on this draft is good. David Culler: And if we can achieve convergence, if there is consensus around it. This will involve an IANA step. Carsten Bormann: I'm hearing there is interest in this work, so this should be on the charter. The reason I was saying this isn't quite stateless is that agreeing on the prefix is a state. David Culler: Do you even have to materialize the IP address? * Segment 7 -- 11:00 -- Interop Testing -- Jonathan Hui 11:10 (see slides) Ki-Hyung Kim: agree with this approach. It takes time to build a testbed; there are many independent implementations in the world. Carsten Bormann: Given the reaction from this romm, this WG wants to continue looking at this document, even though it may not be one of its deliverables. * Segment 8 -- 11:15 -- Routing Requirements -- Dominik Kaspar 11:19 (see slides) * Wrapup (11:25) -- consensus calls Carsten Bormann: presents the rechartering alternative 1 strike routing from the charter prooposal (smooth rechartering process) 2 put requirements work for routing into the charter (can it be done independent of L2/L3?) 3 boldly go ahead and ask to do the work, maybe incur some delays Gabriel Montenegro: not development of the routing protocols themselves Carsten Bormann: Yes, this is number 3 JP Vasseur: If the question is to adapt the routing protocol, without knowing which routing protocol? One question we raised was what will happen with RSN. One of the outcomes might be to say, we don't assume, another might be, we have a WG looking at that which we feed requirements, while we do the adaptation. Gabriel: I think waiting to have one single one which everyone thinks is the best might just delay us more. Look at MANET: it's spent over a decade on this, and yet there isn't one, even when the requirements are simpler. JP: One of the slides for this afternoon is looking at a reduced scope. RSN is probably going to narrow the scope. Culler: I also had a comment on a third path, but I guess it's a fourth. It speaks more directly to our charter, in terms of format. 6 months ago, we asked, is this format flexible enough to support mesh -- no source routing, no traceroute, ... If we just asked the question: do we have the formats to support mesh routing? Is our work done in this regard? Layer 3 routing is built on top of ICMP and IP, so we're OK there. Is there work we should be doing to allow this mesh work to take place, including node specific information. Have we put the vocabulary in place to express that? Carsten Bormann: alternative 1 might include knowing "there will be routing"? Mark Townsley: Would the format be different, if we were doing layer 3 versus layer 2? David Culler: Today, we can do layer 3 above. There's a question of how efficiently we can express those packets. Arguably, in that realm, we're more done. We're less clear on whether we can support a layer 2. We haven't done the things ICMP does to provide visibility. Mark Townsley: This is the crux of my hesitation on moving on charter option 3. Until we understand what the deficiences of layer 3 routing will be, we can't weigh the need to do the mesh routing work, and all this extra format work. It's hard for me to say, go forward, if it turns out that layer3 is good enough, and so we could spend our effort on all of these other critical problems needed to have a working 6lowpan network. Ki-Hyung Kim: unclear why we need L3 routing, would RSN be closely tied to 6LoWPAN? Mark Townsley: yes, RSN will be closely tied to 6lowpan; routing requirements would likely come from 6LoWPAN and feed into routing work -- that's how I understand it. Ki-Hyung Kim: would RSN limit itself to L3? Geoff Mulligan: YES, RSN is route-over. - the question for us is "are we going to define L2 routing and are we putting in in the charter - alternative, focus on defining format that woudl enable meshing Mark Townsley: don't understand how you work format, without doing the routing work too. Ki-Hyung Kim: question about fragmentation Eun-Sook Kim: Under the assumption that we need mesh under, substantial work remains to implementat load / dymo. Gabriel Montenegro: L3 routing, when we were chartered autoconf was also being chartered. It was easier for us to get chartered doing sub-IP routing, routing may be well understood, but routing for mesh is not so well understood. Right now autoconf partitioning the node Might discover issues that delay us further. Mark Townsley: want to make sure that the two efforts should be in concert, not completely overlapping or in competition Dave Ward: similar issues are coming up from a variety of places. What is relationship of Manemo, etc. Clear that there needs to be a desire for a routing solution. So requirements must be given. Packet format is not necc. focused on requirements. Advice - focus on req's that drive protocol design, not format. Good engineering sense to start from what exists. Mark Townsley: work on requirements that don't presuppose a solution (L2 vs L3).