6lowpan WG meeting at 70th IETF ------------------------------- Slot: Wed, 2007-12-05 13:00..15:00 Room: Salon 3 (Vancouver, BC, CA) ================================= Notes taken by: Dominik Kaspar Philip Levis Minutes assembled by: Carsten Bormann $Id: 6lowpan-minutes.txt,v 1.4 2008/01/09 18:48:18 cabo Exp $ ================================= Agenda: 13:00 Introduction, Agenda 13:05 Rechartering Status 13:15 Current I-Ds 13:30 Architecture JP Vasseur / D Culler -- draft-culler-6lowpan-architecture-00 13:43 Integration of 6LoWPAN into IP networks C Williams -- draft-cansever-6lowpan-integration-00 13:53 ISA100 input G Mulligan -- no I-D yet 14:03 Application Recommendations E Kim / JP Vasseur -- draft-ekim-6lowpan-scenarios-01.txt 14:11 Commissioning, Bootstrapping K Kim -- draft-daniel-6lowpan-commissioning-00.txt 14:25 Security D Park -- draft-daniel-6lowpan-security-analysis-01 14:40 Routing Requirements D Kaspar -- draft-dokaspar-6lowpan-routreq-03.txt 14:50 Stateful HC Kris Pister -- no I-D yet ** Introduction, Agenda -- Chairs Unfortunately, due to a changing corporate situation, Christian Schumacher is no longer available as our WG secretary. The chairs thank him for his contribution. We need a WG secretary. If you are interested, please contact the chairs. (Usual introduction, note well slide.) There were no changes to the (somewhat full) agenda, which paralleled the proposed new charter, with the addition of a short item about routing requirements. When Carsten did his usual quick presentation of the objectives of 6lowpan (chairs' slides), Ian Chakeres immediately asked about the somewhat nebulous usage of the term "link" in that introduction. Carsten pointed to the definition in RFC 2460. Carsten: There is a long discussion of how you make a link out of these radios: mesh under versus route over. I assume you are concerned about this as a chair of MANET WG. ** Rechartering status In the text proposed by the chairs for the recharter, one thing that was perhaps improperly left out was routing requirements (discussed some more below). The five items in there are: architecture, commissioning/bootstrapping, security analysis, stateful header compression, and scenarios/use cases. The chairs mentioned there have been some concerns about the nebulous nature of an architecture document. Mark Townsley commented that, not being caught up with the WG list discussion, he so far only was aware of private discussions. As there were no comments to the current charter proposal on the list, Mark asked the WG to read it, comment on it, and to indicate active involvement from the group to justify the large amount of work proposed before taking it to the IESG. Carsten summarized the current status on the five items: 1) There is a document on neighbor discovery optimization, with work needed on bootstrapping and commissioning. 2) A problem statement is needed on additional forms of header compression, with a presentation (no draft) on today's agenda. 3) We have an architecture document and an additional document about the 6lowpan-specific routing requirement statement, but the latter is not in the current charter proposal. 4) We do not have a document on recommendations for applications, but we have a scenario document that can grow into this. 5) Finally, there is a first outline of a security document. In summary, we have seeds for each of these items, but we need to grow them. JP Vasseur questioned using the term application recommendations, contrasted it to application requirements and asked whether this could be something like an applicability ID. Carsten responded that the intentions was not that of an applicability statement, but about looking at applications and seeing how 6lowpan can solve some requirements of those applications. Geoff mentioned the term "use cases" used in the charter proposal. Mark asked about the level of active participation, as a BoF style question. Quite a few people raised their hands. ** Current IDs The chairs asked Daniel Park about the status of his security analysis document, which hasn't been updated in a while. Daniel answered that further work was waiting for the rechartering to go through. The chairs mentioned that 6lowpan has a large number of individual submissions about routing protocols. At IETF 69, we agreed that we would not be taking on the concepts of mesh under or route over, those are out of scope. The routing requirements are specific to 6lowpan, about the kinds of ways we need to move packets around, and these are intended as input to the routing area. The HC1G proposal is another interesting situation. It talks about how to compress headers for globally routable addresses. That's not a specific charter item, but would fit in as an extension of the current format document. Another interesting area is interoperability. We should look at Daniel's and the more recent interop draft. In order to move things forward in the IETF, we need multiple interoperable implementations. So we need to talk about this. Carsten mentioned that in ROHC, there was an "implementers guide" draft that went through 23 revisions to collect observations and clarifications from implementation and interoperability testing. This at some point became a proposed standard [RFC 4815] because it defined changes that were necessary to the base document in order to improve interoperability. So we want a repository of this kind of information that is under WG review. Geoff asked whether we should put a MIB and interoperability work specifically in the charter to cover those things. Mark responded that these two are very different. MIBs need to have a goal and deliverable to be a work item and be in the charter. Interoperability work is tough to have as a goal and milestone -- could be added as a work item, but, while a great idea, it seems tough to make a milestone, as it's continuous. Jonathan Hui said that there also is a question about what's required in a node, e.g., is IPsec is required for 6lowpan nodes. Carsten responded that it would be useful to have a document from someone who is doing an implementation who explains where the problems are in the node requirements (RFC 4294). It would be good to have something more precise than "IPsec is hard" versus "I tried doing this on that device, and it took 15 seconds to compute!" Unless we have real input from real implementers, we will have a hard time making progress. Mark: note that this is the kind of data that you have to collect to move from proposed to standards track. Mark said that 6lowpan is its own special IPv6 anyways. He had no specific objection to working on 6lowpan node requirements, as long as they are clearly defined, with the caveat that, at some point, this has to be vetted through IETF consensus. ** Architecture Document, JP Vasseur / D Culler David: The thrust of this document is to fill in the operational framework. RFC 4944 dictates the representation, but does not speak to the how. There's a lot of discussion around how networks might be organized, but it does not directly address these questions. So the purpose of the document is to provide an operational framework to guide realization of these networks. David: The first piece is separating organizing a PAN from link specification or the IP architecture. This gives the net admin the option to do things in a number of ways, but not to tell the only way to do it. As Carsten pointed out, sometimes these links are deployed in a fashion that are not a complete broadcast domain. So we want to address how to deal with this. Once we do this, we can deal with, e.g., addressing. The document also tries to lay out what we mean as we back from a Complete Broadcast Domain (CBD) to a Partial Broadcast Domain (PBD). It talks about the mechanisms you can use, say, in the case of mesh under, route over, or routed meshes. David: It also then tries to articulate what are the 15.4 issues that are not simple artifacts that should guide the architecture. In particular, small MTU, dual addresses, non-CBD. Range is only one reason a PAN is not a CBD. They can be next to each other, but have different PAN ids. They could have different channels. They might bounce around between a variety of channels. They might turn off some of the time. What comes out of this is that interoperability requires careful link management, not in the sense of the MAC, but with respect to what to do when anybody is listening at all. The document also talks about the variation in link quality due to external factors. David: To dig in, the topic the document addresses most fully is addressing. The document takes an IPv6 perspective and looks down, saying, how to make this IP, rather than 15.4 looking up. No DAD required, HC1 elided when IP source or dest, link local multicast addresses. Once we have these mechanisms, we can take an IPv6 point of view. The other issue that demands a lot of attention is the assignment of the short address. RFC4944 goes a bit into this. The architecture document says that this short address needs to be assigned in some unique fashion, at which point no configuration is needed. There are a lot of ways you can do it: stateful DHCPv6, stateless, router present, etc. Of course, you can always do it statically or manually. The architecture document tries to lay out the options. And if none of these are true, then we can also look at the question looking from 15.4, where there is a PAN coordinator. David: What things brings out is that link-local multicast is critical to IPv6 in all organizations. There are different mechanisms. This can get interesting with overlapping link local scopes when you have routing. HC1g defines SA16 for common multicast groups, but can't talk about link local, while HC1 has it inline. Or we could talk about an HC1l, which addresses this. This talks to why an architecture document is useful in addition to the format document. David: (Slide 8) Routing is of course a big deal. We need it for talking outside the PAN. We can always have full IPv6 addresses. Conventional ICMPv6 mechanisms apply. Ian: These mechanisms down here are not about routing. David: Router advertisements are how routers advertise their presence. Router solicitations allow nodes to discover them. So the question is if these are not sufficient. Ian: This is about host configuration. These mechanisms are generally built for the CBD case, don't work in PBDs, don't handle asymmetrical reachability. David: Right, but if we are in a PBD situation, we need to consider making them work. Ian: What I am saying is that these documents have explicitly said that they do not work in PBD. David: Great point. Tim Salo: This is a great step forward. But I would like something said about sleeping nodes. What does multicast mean when most nodes are always asleep? What does duplicate detection mean when only a small number of nodes are asleep? We should really define what we mean by multicast or broadcast. This is important because it might break what protocols assume in multicast and broadcast. David: That's right. But what I'm trying to get to is that this isn't always about range. There are other issues. Tim: But this document seems to assume we'll have a good solution for multicast, and I think we don't need know how to do it. I'm not convinced that we can do multicast here. David: You're right, the concept of "this communication must reach all nodes" is difficult,. Geoff: What Tim means is that we need to talk about sleeping nodes. David: There is a real issue here. But I'm trying to address this independently of a particular MAC. Erik Nordmark: Sleeping nodes are not unique to 6lowpan. There are other groups addressing this. So don't feel that you have to write your own solution. *** Integration of 6lowpan into IP networks, C Williams Carl Williams: This is a draft on a project Geoff, SI, and I have done for the military. It talks about integration scenarios for 6lowpan and the Internet and wireless infrastructure. Carl: Scenario 1 is to monitor an area with a set of networked sensors. The network is stationary, but external connectivity can change, particularly with the access network. For example, vehicles might come in, or there might be temporary satellites. We wanted to provide global reachability. An end user can monitor the network through a dashboard. Geoff: The idea here is that the network itself is stationary, but has changing access points. So this means that the network hasn't moved, but might have moved halfway across the world in terms of the networks it touches the larger internet with. Carl: Scenario 2: This is scenario 1, where the network itself is moving. Carl: Here's the connectivity strategy for remote networks. E.g., we could have a NEMO client, or a lowpan border router. For securing neighbor discovery, we put the SEND enabled router, to secure the neighbor router discovery, so as it comes up it provides access to this NEMO client. This then goes through the home agent. All of this was done with no changes to the 6lowpan network, just the NEMO client at the edge. Carl: Our goal was to document these strategies. So we need to be able to have a 6lowpan network maintain access even though its gateways to the larger Internet might be changing. The observation is that the usage of SeND and NEMO allow this. Gabriel Montenegro: If you are interested in these things, then you might be interested in the CSI BOF later this week. Is there anything specific to lowpan that you talked about in these slides? Carl: Our goal was just to integrate lowpan into the larger Internet. Gabriel: I take it that the answer is no, which is a good thing. Carl: Right, we didn't have any problems. Daniel: These kinds of use cases, they are going to be part of the architecture of 6lowpan? This draft is trying to deal with mobility issues. But I am concerned because it is not in the charter. Geoff: Good question. Since I am up next, and talk a bit about mobility... you're right, it is not part of the current charter. *** ISA100 input, G Mulligan Geoff: Following on the same thing, what I wanted to talk about was, there's another standards organization that's defining a standard for industrial organizations, ISA100. They're using 6lowpan, and want to use IP when possible. So I wanted to talk about ISA100 and how it relates to 6lowpan. So there's a group called .11a, that has nothing to do with 802.11a. Yes, we chose that name badly, Sorry. Smart people make bad choices. Geoff: .11a is to define wireless sensor networks for wireless automation. They decided on 802.15.4 PHY for ISA100.11a. The WG is defining a link layer that provides a "mesh under" capability. It uses a hybrid CSMA and TDMA approach. Uses 6lowpan/IPv6/UDPv6 and TFTP. There are a lot of control applications, and I won't go into the details here. There's a concept of a backbone router. It connects data link layer networks, or what we call link-local networks. Geoff: So there's a lot more stuff, like gateways, network managers, and security managers. So a DLL subnet has a 15.4 radio that talks to the networks. SP100 does not specify what the backbone network might be. Geoff: Here's a picture out of the ISA100 document, we we have this DLL mesh. The interesting thing we came upon as we tried to build these networks is, unlike ZigBee, which says getting from A to B might be multihop within the wireless, in SP100, getting out of the wireless as fast as possible is a good idea. So get to your gateway, get out of the DLL, route it along to a node that can maybe go single hop in wireless, thereby reducing your wireless contention domain. Geoff: Again, the idea is get off the RF space, find the closest border router, and be able to support lots and lots of border routers. So the packet flow, as the packet comes down, within a 6lowpan network, the packets are meshed across this DLL mesh that's created. Packets that are just traversing within 15.4 don't get IP routed. When it's going to a legacy control system that's IP, then you need to expand the elided 15.4 headers and make it a full IP packet. We do not leak 6lowpan elsewhere into the network. Geoff: So the draft that's there was partially to show a use case for industrial wireless, but also to discuss the requirements for backbone routers. So we can maybe leverage the original work on neighbor discovery to make use of the backbone router. So the idea is that the backbone router periodically sends broadcast router advs. Utilize unicast to router rather than bcast over the DLL. This can create a binding cache in the router. It would use mobile IPv6 binding requests, so use NS and NA messages. Geoff: So here's an example. A sends a binding update to a BR. B does the same thing. When A sends to B, it sends to the BR, which then talks to B's BR, to discover B's actual address. Carsten brought up an issue (see below). Geoff: 2 things. First, ISA100, I'd like to solicit support and involvement. It's going on, ISA is part of the ANSI standard, so another international standards organization. We're working on this as we speak. We'd love input from companies around the world to make sure we are developing the solutions that you need. The typical question now is whether this draft and its problems apply to bootstrapping and should we take it on. Erik: So, in terms of optimality, I think you need to pass a lot of info between L2 and L3 routing. I can understand wanting to get off the network, to the backbone router, through the wired, then out. But if it's right next to you. You have to pass information between the L2 and L3, so that you can figure out who's closer. Geoff: The way that it works today, within SP100, there's graph routing and contact IDs. Erik: So you are extending the L2 mesh. Carsten: Right. The border routers "R" need some connectivity and need to collude, knowing they are part of the L2 network and have lower "mesh under" cost between them than other radio-only nodes. ** Application Recommendations, E Kim / JP Vasseur Eunsook Kim: The goal of the application spaces draft is to come up with recommendations for 6lowpan, with respect to deployment and their primary characteristics. We are not trying to be exhaustive. Eunsook: Last meeting, we talked about this, and had strong support. We discussed a lot of the important properties and options, such as deployment, routing, mobility, connectivity, and security threat models. We had a lot of nice feedback on the mailing list, and so last time we talked about 4 scenarios. Eunsook: In the new version, we added four parameters. Security level, power source, QoS, and traffic pattern. We have also added two new scenarios, making six. The two new are industrial monitoring and connected home. Eunsook: Industrial monitoring. It has a lot of uses: storage monitoring, machine surveillance. The goal is to improve plant productivity with a continuous self-controlling loop. In this scenario, we thought about the main parameters, which are listed on this slide. Eunsook: Another scenario is the connected home. Now there are some cities that have smart homes, for things like gas gauges, smoke detectors, lights, etc. In this application field, the dominant parameters are multihop and small mobility. The rest of the parameters are on this slide. Eunsook: This was only a brief overview. You can get more information from the draft. We would love feedback from the group. Does the WG agree that such a document is useful? If so, what is the next step for the ID? Daniel: I love this work, and I support this kind of activity in the IETF. But I have some high-level questions to high-level questions to the group. How many scenarios do we have to spell out? What is the right venue for this kind of publication? Journal? Conference? RFC? Mark: We want to avoid marketing documents. We want to be factual. We want information that's helpful for people building products. This sounds kind of like the applicability statement JP was talking about. Geoff: we might need more depth, not more breadth. For example the requirements in industrial monitoring are very different from home automation! We need more depth. and it's critical for us to understand the application space really well in order to understand what for ex. bootstrapping means. what works for home with 10s of nodes, how will it work in a huge building (oil refinery)? Anything we can do to understand the applications better. Anything that we can do to understand the differences in requirements. JP: Would you take this work and push it forward in greater depth, so we can repeat it for other scenarios? Geoff: Yes... (Time started to run very low) ** Commissioning, Bootstrapping K Kim Ki-Hyung Kim: The goal of commissioning is to define how 6lowpan nodes start up. This involves bootstrapping a network, adding new nodes, and configuring IP. In the last meetings, we discussed some parts, and some other parts have been updated. I'd like to talk about the higher level, because the exact detailed scope of the draft has not been determined. Ki-Hyung Kim: Bootstrapping is the process of associating with a network and getting an IPv6 address. This includes security provisions for 6lowpan. Obtaining an IPv6 address, this has to be done with the IPv6 routers. So we have to talk about the EUI-64 identifier. So we need to talk about the PAN id + the short address, and detecting duplicate addresses. Ki-Hyung Kim: Moving forward, feedback is welcome. Should this draft become a WG work item? David C.: It seems like it would be nice if we started making progress in a consistent direction. This seems like this is a possible fork. Currently 6lowpan is defined in terms of the format spec, not the underlying MAC protocol. We could take the position that, to be 6lowpan, you must be a 15.4 MAC, with PAN coordinators, RFDs, FFDs, etc. But the way the format document is written, that's not true: it talks about format. So if we want to say "you are on top of this specific MAC," fine, OK. But IPv6 has a lot of mechanisms that can just be applied. So rather than go round and round, we should decide which way to want to go: do we assume the L2 mechanisms and become deeply wedded to specifics of the MAC protocol, which few use in practice, or do we want to remain agnostic. Geoff: If you don't like the draft, then make comments, and we can move it in the direction the WG likes. David C: My comment is that this draft requires specific 15.4 mechanisms for neighbor discovery that the format document does not. Geoff: Right. We should lodge this as a point. But the WG needs to decide whether taking advantage of those mechanisms is good or not. Jonathan: So how does the second part of the draft, which deals with neighbor discovery, relate to autoconf? Last IETF we talked about how we should collaborate. But how do we want to interface? Erik: I think the corollary of how much we want to get into the MAC is how much we want to optimize. There's a give and take. So how much do we want to rely on this. So we could say take advantage of this if you have it. David: Right -- becoming dependent is a problem, because it's not sure that these mechanisms are the right ones. Many of these L2 mechanisms are not that easily accessible Eric: Well, there are lots of ways of optimizing. Kris: I just want to support what David said. It's tricky, once you start talking about L2. Anything that ties us to the 15.4 MAC packet flow is a non-starter. All industrial companies have made that clear. 15.4e has started for this reason. Phil: Let's optimize once we know what needs optimization. ** Security, D Park Daniel: Security draft. I'm sorry for the long delay. Version of June 2006, for informational track. I got feedback from Samita and Julien. Based on this, I hope to go to the next version. Here's the basic structure of the draft. The draft comes from two security concerns in RFC4919. The goal is for this draft to feed these two requirements, and I hope to get the new version out as soon as possible. I hope to bridge between Internet area and Security area. Hopefully ready for WG adoption in Philadelphia. ** Routing Requirements, D Kaspar Dominik Kaspar: Routing requirements draft. We decided to make the draft more general, and leave out the discussion between mesh under and route over. Eunsook: We want to consider the 15.4 primitives as part of the routing issues. The draft now focuses on 6lowpan-only requirements. Important: 6lowpan has special requirements because nodes have different roles! ** Stateful HC, K Pister Kris Pister: I am very interested in stateful header compression. I do not like sending or receiving bits. I like filling in bits when I can. 6lowpan has done a good job. The IEEE is trying to fix the header and security overhead. So my goal is to get down to single-digit headers. For example, if I wake up once a second and send a piece of data every second, then I can use this information. Carsten: Thank you for this quick presentation. I want to point you back to the slide that Geoff showed. We have to start making hard decisions -- which drafts will become real work items.