Minutes 6LowPAN Working Group - IETF 71 Philadelphia - March 2008 ----------------------------------------------------------------- Thanks to Mikko Saarnivala, Jonathan Hui and Samita Chakrabarti for taking minutes at the meeting Agenda: * Administrivia, Agenda bashing (5) Chairs * Status Update, Review of Re-chartering (10) Chairs * Working Group Documents (15) Chairs * Current status of ROLL (10) JP Vasseur * Update on Security Analysis Draft (20) Daniel Park * Update on Routing Requirements Draft (10) Eunsook Kim * Update on Application Profile Draft (10) Eunsook Kim * Short intro to SP100 DLL (10) Geoff Mulligan * Updates to RFC4944 (15) Geoff Mulligan * Update on HC1g (20) Jonathan Hui cb - Carsten Bormann gm - Geoff Mulligan jpv - JP Vasseur sc - Samita Chakrabarti kk - Ki-Hyung Kim jh - Jonathan Hui ek - Eusook Kim dp - Daniel Park wh - Wassim Haddad gk - Georgios Karagianis pd - Pieter Demil Discussion: cb: agenda bashing cb: 6lowpan intro -- Rechartering Status gk: What about service discovery? Is this covered only in the context of only 802.15.4? or can we work on an sd solution that works on other links as well? gm: Current charter doesn't include service discovery. We might define on the very high level what the service discovery would mean in our context. If we're going to define sd we might make it so that it is applicatble to other l2's also. It's not a topic at the moment cb: No shortage of subjects! Current charter are the things that we want to do during 2008. More items possible in the future. We need to focus on these items. None of the current items are to be rfc's any time soon. jpv: Want some clarification on why use cases is tied to routing requirements. cb: I didn't mean to imply that. gm: Purpose of routing requirements is to provide feedback to roll. cb: Assumption is that roll documents may not focus specifically on the 6lowpan requirements. gm: It may be redundant and we're perfectly fine if it is. jpv: As long as there's no conflict. Why not have people in 6lowpan work in roll to define the requirements? cb: Link MTU of 80 bytes is very specific to 6lowpan. It may not be that roll would want to specify the specific MTU of the 802.15.4 link. jpv: Should specify the routing requirements a bit better to make sure that it is specific to ieee 802.15.4. Concerned about geoff's comments that the wg may be thinking about other links. gm: Regarding my comments about expanding to other links, I didn't mean to say that we would be expanding the charter. jpv: Not clear to me that the routing requirements would cover. something that is completely specific to ieee 802.15.4 that won't be covered in roll. jpv: Why did it take so long to recharter? cb: Needed to make sure that the roll chartering worked together with the 6lowpan rechartering. We have been assured that 6lowpan will be on the iesg agenda. The AD requested that we not spend much time on discussing the rechartering again, but work on the wg deliverables. Also, to keep in mind our relationship to roll. so, let's just pretend we're recharted, let's move on. -- ID inventory cb: Some items missing? jh: Yes draft-chakrabarti-6lowpan-ipv6-nd-04.txt missing some things sc: Mesh under by your definition? jh: [explains mesh under: mesh under != ip layer routing] We should have ND for route-over. The current draft is only for mesh-under. sc: Don't think route-over should be in the same draft. - 2a: problem statement cb: Good idea to have stateful header compression problem statement. Need to understand the problem, need to understand what we are optimizing for, need to have a document that describes our objectives. Much of the discussion on the mailing list is where we need bits. Probably good to have a slightly larger picture of what we are trying to optimize for. On the other hand, if you don't know what you can do, then you might make some really bad requirements. If we go with a solution first, then it can shape the requriemnts. I think we need to have both problem statement and solution in parallel. 3a: 6lowpan architecture gm: Should we use the culler-architecture draft be the baseline for the WG document. kk: The architecture document should provide a bit of the broader picture. Management, service discovery, etc. We could envision a whole block diagram of the 6LoWPAN sensors and the network itself. pd: I'm willing to work on the "whole-picture" perspective. I'm also willing to work on how 6LoWPAN could apply to other links. jpv: The architecture document should remain within the charter. cb: We are chartered for 802.15.4. But we do have to find a way to work in the IEEE 802.15.4 framework. There's discussion of how much link mechanisms we assume/rely on. gm: We are definitly not doing 802.11, homeplug cc, etc. As we define things, I think we should anticipate their usage elsewhere, but we are currently here to define functionality for 802.15.4. jpv: The whole point of the architecture document is to provide the whole picture. Not in the sense of a textbook, but we do need to give a global picture. We can point to various drafts where things are already specified. gk: I support that completely and can help provide input. cb: Hum on using current architecture draft as WG doc baseline. Hum shows that we will. cb: Routing requirements, there is some major shifting required w.r.t. ROLL. jpv: The current draft is very similar to the original RL2N approach. We've already taken a step back and said that the approach isn't going to work well, so not sure if the 6LoWPAN RR is going to go anywhere. gm: Use cases in 6LoWPAN seprate from ROLL because it covers broader topics than just routing (e.g. security, service discovery, etc.). But maybe we can utilize some of the output from ROLL. jpv: The current draft is not specific to routing. It covers QoS, etc. So I'm okay with it. dp: Need to get more input from commercial networks to be useful. gm: ROLL is defining a set of use cases that may overlap with 6LoWPAN. All I'm suggesting is that we leverage some of the work that they are doing. ek: Also agree with DP comment that we need more input from commercial. There are already testbeds in Korea. If you read the draft, it does not focus on the routing. jpv: Just to reinforce what you said, I think the routing requirements in the draft is less than 5%. Most of the scenarios are inspired by field deployments. cb: Security analysis, talk after presentation. cb: No document on RFC 4944 maintenance. Lots of proposals of tinkering with the protocol. For instance, we have a fragment recovery document and certainly something should be discussed. But is different from trying to maintain RFC 4944 and making sure we get interoperable implementations. It would be most useful for the implementors. gm: We need to take charge in creating the implementors guide. Draft may not be completely clear in some caess. I'll actually volunteer. I'm working on creating an implementor's meeting outside the IETF. It will be folks that are building it, nuts and bolts. cb: 6LoWPAN interoperability draft. jh: Should be in the interop group for now. - 3a: 6lowpan architecture cb: We have already some material to use as an input gm: We propose that we start with the dculler arch doc as a baseline doc. Mic is open kk: Dculler doc. should discuss more about the bigger picture, SD, management, profile things... this is informational doc, block diagram of the whole system pd: Fully agree and willing to do some work on it... 6lowpan on other DLL's gm: The charter is 802.15.4 jpv: We should stay then on it cb: What does it mean then? jpv: It's a question for you cb: Addressing 15.4 might mean just to use the ... and losing some of the MAC features gm: It might mean that we just exclude 802.11lp jpv: The whole picture is the point in the arch document jpv: The idea was not to have a huge doc but to have references to more specific drafts/rfc's gm: We need to reitereate gk: Totally agree cb: Using this doc as the bsaeline for the arch doc? humming? hmmmmmm.... against, humming? okay then we'll use this doc - 3b: 6lowpan routing requirements cb: We will discuss this document later in the meeting need to work on it to distribute the work to ROLL jpv: Not sure if this doc will produce anything gm: Lets have a presenstation and discuss more after that - 4a: use cases for 6lowpan gm: Use case doc needs input also from ROLL dp: Alignment between use cases draft and existing networks. more input from the commercial vendors. not sure about aligning with ROLL gm: ROLL is defining a set of use cases which might be overlapping -> leveraging that ek: More input from commercial jpv: The routing part in this draft is very small kb: When we align with ROLL we still need to have a larger picture than just routing dp: We should limit the use cases? cb: Current draft is good to work on 5a: 6lowpan security analysis cb: We already have a doc on this 6a: implementers guide cb: Not a good starting point at the moment, although a nice doc on the fragment recovery by Pascal Thubert gm: We need to have someone to lead to effort. If not right now, present on the list ek: Design team among implementors? gm: Implementors meeting outside IETF, I will organize - 7a: 6lowpan interop guide cb: an id already expired gm: This would be integrated to the implementers group -- 6lowpan.ROLL update by jpv: jpv: BoF in Vancouver. Already chartered. Part of the routing area. Work items are to focus on the routing requirement I-Ds. First approach is to cover a bunch of different use cases, but that didn't work because the market is so segmented that there will be no solution that covers all use cases. So we are starting with industrial, home automation, and urban networks. Why those three? We need to draw the line at some point and focus on areas that are being deployed right now. However, ROLL is not limited to these use cases. jpv: Then we have a survey of existing protocols, including the MANET protocol. There was an agreement to look at all the existing protocols. If there are existing protocols that work, then we're done. If it requires modifications, then we work with those working groups. If we need to specify a new one, then we've got some work to do. jpv: Item for routing metrics, framework for routing at layer 3, routing security. jpv: We hope to be very aggressive here. sc: Does ROLL consider other networks? jpv: Absolutely, we are completely agnostic to layer 2. Low-power WiFi, Bluetooh, etc. gm: What about wired networks, such as RS-485, etc.? jp: Absolutely. -- 6lowpan security analysis draft by Daniel Park dk: I've presented this a few times already. I hope this will be the final presentation as an individual submission. dk: Changes from 01. Pull TBDs out, add new author, editorial improvements. dk: Draft focuses only on IP level security. MAC security is out of scope. Focusing on problem space, not solution space. Basic question is whether or not 6LoWPAN can support IPsec as it is? Answer is no. Draft describes difficulty of adapting current IPsec to 6LoWPAN networks. dk: Draft composed of several sections: security threat, key management, security considerations in bootstrapping, possible scenarios using different levels of security. dk: Moving forther, further contributions are necessary. Make this the baseline for the WG item. I'm fine with having a security expert take over as editor since I'm not a security expert. ??: We should wait for the use cases before looking at the security analysis. gm: I disagree. A common question we get is "why don't you just run IPsec", the answer is we can't and we should document why not. cb: We will make security the first issue of the week on the mailing list. Pete St Piere: Someone on the jabber server volunteered to work on the security draft. -- Problem Statement and reqs. for 6lowpan mesh routing - E. Kim ek: Updated problem statement. Skeleton has changed. ek: Need to a good way to cooperate with the ROLL work. What can be the next step for this work? jpv: It really depends on how you write the document. If you make it MAC specific then it works because ROLL is L2 agnostic. If you do so, it could work very well. But there are a lot of things here that are a part of the ROLL charter. As a suggestion, if you were willing to refocus on the MAC specific aspects, then it could make it easier to interact with ROLL. Also, you'll probably want to specify the metrics. dp: Curious about the scope of this draft. At the beginning meeting, the 6LoWPAN WG focuses on 802.15.4. But I think you mentioned that it may not be focussed on just 802.15.4 but on ther low power networks. ek: No, that's not right. What I meant to say is that some part of the requirements are very MAC specific, while others may be just general requirements that could apply to sensor space as a whole. The target at this moment is to focus on the MAC coupled characteristics. cb: What needs to be done is that this draft needs to be aligned with the ROLL drafts, providing the requirements. The MAC specific things will probably stay, but other more general things could just provide pointers to other documents where they are already specified. I don't think we need to specify them again within 6LoWPAN. gm: Do we use this as the baseline for the WG document? How about we take this up as the second topic after security. -- Design And Application Spaces for 6lowpan - E. Kim ek: Built consensus for the need of this draft at previous meeting. ek: Added two examples: Industrial Monitoring and Healthcare. Updated technical characteristics in structural and agricultural monitoring. ek: Plan is to enhance detailed technical characteristics for each scenario, want feedback, want next step. dp: I'd like to see 6lowpan benefits for each scenario kk: Also put some specifics about why we need IP connectivity to the nodes. Provide others some scenarios of why IP is useful. gm: The endpoint of the data transmission is not inside the WSN, this should be reflected in the use cases -- ISA100.11a gm: IEEE 802.15.4 MAC header but with our own ACK. 6LoWPAN RFC 4944 but doesn't quite meet the needs of the industrial environment. 6LoWPAN fragmentation when needed. Decided to do a low-power protocol separate from 802.15.4 because we needed low-power routing nodes. GM: Creating a bunch of extensions to the MAC within the 6LoWPAN framework by defining new dispatch values. -- Compression Format for ipv6 datagrams in 6lowpan networks - Jonathan Hui gm: Short addresses are unique to a single PAN... gm: You may end up with situation you migh have two different PAN's with same prefix jh: More discussion on the mailing list gm: If we elide hop limit, can we have problems with loops cb: You can't increase hoplimit. cb: Should this be a wg doc? sc: yes cb: There's a problem with the multicast mappings - you can't update them cb: A lot of space for work but a really good basis. As a WG chair, this is not in our charter. let's make a problem statement and proceed gm: We could take this as managing the RFC4944 as it seems it misses some issues gm: Some have raised suggestions that we might be doing opmizations without understanding the consequences