6lowpan WG -- IETF 79, Beijing TUESDAY, November 9, 2010, 1520-1810 Valley Ballroom A Scribe: Jonathan Hui, with some additions by Carsten Bormann ---------------------------------------------- Agenda: Chair Intro * Completing 6LoWPAN-ND (work item 1) draft-ietf-6lowpan-nd-14.txt * Status Security (work item 6) draft-qiu-6lowpan-secure-router-01.txt (to be discussed in ROLL) draft-oflynn-core-bootstrapping-02.txt (to be discussed in CoRE) draft-moskowitz-hip-rg-dex-02.txt * New work: Header Compression -- TCP header compression draft-aayadi-6lowpan-tcphc-01.txt -- Generic header compression draft-bormann-6lowpan-ghc-01.txt * New work: status of miscellaneous submissions draft-thubert-6lowpan-simple-fragment-recovery-07.txt draft-thubert-6lowpan-backbone-router-02.txt * Next steps ----------------------------------- AB - Anders Brandt BS - Behcet Sarikaya CB - Carsten Bormann DG - Daniel Gavelle DR - David Ros DS - Don Sturek EN - Erik Nordmark GM - Geoff Mulligan JH - Jonathan Hui JV - J.P. Vasseur PS - Pete St. Pierre PT - Pascal Thubert RC - Robert Cragie RD - Ralph Droms SC - Samita Chakrabarti ZS - Zach Shelby * Chair Intro CB: [The usual introduction, IPR principles, overview of the WG milestones, agenda bashing; see slides 1-4.] * Completing 6LoWPAN-ND (work item 1) draft-ietf-6lowpan-nd-14.txt ZS: [Summarizing draft changes, see slides 5-12.] Had three versions of the draft since Maastricht. No major changes, many implementations in interop testing. WGLC on nd-14. Working on resolving issues brought up during WGLC; e.g., context life cycle management. To release nd-15 within couple weeks of IETF. SC: [Summarizing draft changes, see slides 13-20.] Clarification on NCE and NextHop Determination. (1) Tentative NCE only created when Multihop DAD is performed by the 6LR. (2) Should not use Tentative NCE for on-link determination. (3) Should adjust registration lifetime relative to expected mobility characteristics. RC: Clarification on slide 15: the 6LR is not one hop away from the 6LBR (SC: no). Question: how do you find a garbage collected NCE? (SC: it's in the draft) EN: Original semantics of RFC 4861. EN: [Summarizing draft changes, see slides 21-28.] Introduce separate ICMP types (DAR/DAC, maybe misleading names) to clarify and simplify implementation of multihop DAD messages; logic has not changed. Clarify what "reasonable" lifetimes mean w.r.t. 6lowpan context distribution, based on the "default router" lifetime. CB: [Presenting 6CO state machine, slides 28-30.]. One would normally design this to make sure that a context cannot transition from Active directly to No-State, so nodes can decompress packets while others are still learning the state goes away. In ND-14, border router has the responsibility to enforce that sequencing -- that's not that good. EN: (On slide 30: don't call the state Deprecated, call it Receive-Only.) One way to fix this is including a fixed protocol timeout, or we could use the additional reserved bits in the second word to specify an additional lifetime -- then we could get rid of the C bit. CB: One number that could be used as the receive-only lifetime is twice the default router lifetime or something like that -- so we don't have to send that lifetime around with the packets. GM: Can we increase the registration lifetime granularity from 10 s to 1 min? Then we can get something like 45 days rather than 1 week. ZS: Default router lifetime max is 18 hours. If you have been sleeping for more than that, you'll need to RS and refresh the information anyway. AB: My issue is if I have a very low cost sensor that must shut down all memory and process while sleeping, would need to use non-volatile memory to maintain the lifetime. DG: Would rather leave the context as it was rather than introducing a context finished lifetime. DG: For the lifetime, maybe we should use power of 2 -- could go from seconds to months. PT: Agree with Daniel. We should express the lifetime as an exponential. EN: Don't understand the flash memory issue. There should be some kind of clock that runs while sleeping. Need to record the expiration of the lifetime, no need to change until there is a packet changing that. CB: So, on context lifecycle, we just need to decide, taking one of the several ways of solving this. GM: In a couple places, it says that redirects are illegal. That may be too strong; redirects are useful in a mesh. EN: I don't see a problem letting people do redirects; they are actually unicast. We need to figure out the wording/recommendations, but no need to prohibit it. EN: Followup question: Does it make sense to apply exponential to all lifetimes or just particular ones? CB: We tried this in CoRE with an 8-bit lifetime that spanned 1 second to a couple of months. Not sure we want to touch this at this point in time. DG: Probably does make sense to apply to all lifetimes, because it makes storage much less. CB: No you can't save on storage. CoRE's 8-bit format is a transmission format. You still need to use more bits storing it to be able to count it down. ZS: We went from 32 bits (of seconds) down to 16 bits (of 10-seconds) because implementers said that 32 bits was too costly to maintain. * Status Security (work item 6) draft-qiu-6lowpan-secure-router-01.txt (to be discussed in ROLL) draft-oflynn-core-bootstrapping-02.txt (to be discussed in CoRE) draft-moskowitz-hip-rg-dex-02.txt CB: What should we do with the security analysis document on our charter? We have had a hard time getting this document done. Can we unceremoniously bury it or is there energy to work on this? GM: There is interest within IPSO who said they were interested in supporting the security work within 6lowpan; I'm waiting for feedback next week on whether there will be input from IPSO. SC: We have an existing security analysis document (individual submission). Wondering whether the IPSO document will consider the existing document as a base. GM: In talking with Kurt, the plan was not to start from scratch. CB: So, conclusion is that we eagerly wait for this document. (There has been good security work in both ROLL and CoRE.) ??: I am one of the co-authors of the security analysis draft. Did not get any sense that the WG wanted to move this forward; we didn't get enough feedback. But if we do, would be glad to start working on this again. CB: Who in this room would be willing to provide this feedback? (Couple of hands.) * New work: Header Compression CB: New work on Header Compression (while our main Header Compression document is waiting for the IESG). Want to explore whether we should take up new work in these areas: other headers like ICMP, ND, RPL -- can we address this using HC's extension point "next header compression" (NHC)? RD: Why is the prior work in header compression not useful here? CB: The existing work in header compression (RFC 1144, 2507 etc.) assumes installing per-flow state into the adaptation layers at every hop for every flow that is being compressed. So far, the consensus here is that installing per-flow state is too expensive. The standards we have in this space not only have a large amount of state but are also highly complex (see, e.g., RFC 3095). That's why we came up with per-network state in 6LoWPAN. RD: Have you discussed this with anybody in the transport area? CB: Not yet. RD: Please do. -- TCP header compression draft-aayadi-6lowpan-tcphc-01.txt DR: [Presentation on TCP Header Compression draft, slides 33-41.] The proposed TCPHC is implemented on the Edge Router and on the TCP end-point in the LoWPAN. PT: Very interested by this work. Anxious that all bits were used in the previous slide. DR: Yes. GM: What happens when you have multiple edge routers? How is the state management. DR: This is out of scope of the draft. We have to look into this. GM: Can't be out of scope. If it doesn't work, it can't be out of scope. GM: There are certain options that are eliminated at the edge router. How does it know which options to eliminate? DR: There are cases where the edge router can reply on behalf of the end node. GM: If the ER is able to eliminate the context. If that happens, then the ER just sends a reset. Doesn't that leave a half open connection? DR: That may be a bug. CB: I was co-chair of ROHC WG for some six years, including most of the time we were working on TCP header compression. There is an RFC out there, but probably 10x more complex. Good idea to make it less complex. CB: There are several issues we need to understand. For example, where do we leave state? Currently on the end-points or edge router and the end-point. This is different from the usual header compression in that the routing part usually only sees decompressed packets. How do we transport those packets? DR: It is transparent in intermediate nodes. CB: It can't be transparent because they are forwarding different data. Also, one of the important points: if one of the nodes goes down, the state is gone. It is a problem with the border router going down, or with multiple border routers. CB: Also need to work on surviving lost packets, reordered packets, and such. Those can cause the states between the two ends to get out of sync. There are several models of solving them in ROHC; your work will look much more complex after doing that, in particular as we have reordering in 6LoWPANs. DR: Yes, I agree. One of the things we are trying to figure out. CB: My gut feeling is that this will take about 2 years to get this done. DR: I hope not. GM: How many people read the draft? (Not many.) JH: Are people waiting on TCP header compression? ??: Need much more work to evaluate on real cases. You say 15% savings, but need to understand what the numbers are in real-world cases. Maintaining state will be an issue when nodes move around. These long-lived connections will be really long especially with sleepy devices. DS: For the smart energy work: We are using TCP. It would be nice to have TCP header compression. Did look at existing drafts but nothing fit the bill. Not sure that this draft solves the problem. GM: For short-lived connections, adding per-connection overhead may not be compensated by savings within the connection. ZS: Agree with Geoff's concern about short connections. For ZigBee/IP this is 2 years 2 late. Not clear that, where we are using TCP (with XML etc.), TCP is where the overhead is. GM: Reason I was asking ZigBee, would be good to get ahead of the curve. That's probably what Jonathan was asking about w.r.t. should the WG take this on. ZS: This would need a lot more thought and pre-work before taking on as a WG item. We need to understand what is possible and what are the use-cases before considering this as WG work. RC: I'm concerned about the state. Have you looked into stateless TCP header compression? PT: Have you considered DLSW? I.e., not using TCP between device and Edge Router? DR: No. GM: I think this is interesting. I don't think this draft is nearly ready for us to take on as a WG item. There is a lot of work that the authors need to do. SC: TCPHC seems to be important and interesting work to do. What is the charter in mind for 6lowpan going forward for deployment of 802.15.4g. In those cases we don't have the problem of frame size. CB: If there is interest in adapting 6LoWPAN to the new characteristics we'll find in 802.15.4g, that would be an interesting point. Can we discuss it at the appropriate time in the agenda? ZS: She didn't mean that. We do not need a 6lowpan over 802.15.4g document. 802.15.4g may not need this. CB: Pretty clear that this document is not ready for WG item. Also clear that there are people here that want to continue work in this space on the level of individual submissions until it is worked out enough that we can judge it. DS: If you are going to charter this work, we owe it to him to provide him some requirements, e.g. stateless/stateful, failover between border routers. There's a whole bunch of things that could guide this work in a better direction. PT: Last time we had two drafts that are in the same boat about making WG items. We were to vote on the mailing list, but that never happened. So what now? CB: That's a couple of slides later. -- Generic header compression draft-bormann-6lowpan-ghc-01.txt CB: Header compression of ICMPv6, ND, RPL, DHCP, DNS. Do we need another NHC for each header that comes up? [Summary of draft on Generic Header Compression, slides 42-44.] RD: Compression factor of 1.65 - 1.85 means you're reducing by almost half? CB: Yes AB: Curious on the code size. CB: Didn't write it in C. Implementations don't need to have a general compressor/decompressor. Possible to have constrained implementations. PT: Love it. The thing it may not do well is when you have ASCII characters. CB: Briefly discussed a way to do compressed URIs in CoRE; that mechanism could be used here. Main drawback would be that the spec wouldn't fit on a single page anymore. JH: I like it as well. I wish we had the fragment offset not specify offset of uncompressed bytes. CB: In the 6LoWPAN-HC framework, this cannot be used outside the first fragment. Would still be useful for getting lots of bytes into the first fragment. CB: Remaining problem: Need to figure out how to negotiate that the two nodes talking to each other support GHC -- as soon as we put in something that's optional, we need to know when to switch it on. AB: These types of messages are the infrequent ones? CB: Not so sure about that -- sleeping nodes may send a lot of ND messages. -- New work: status of miscellaneous submissions draft-thubert-6lowpan-simple-fragment-recovery-07.txt draft-thubert-6lowpan-backbone-router-02.txt CB: [Discussing miscellaneous items, slide 46.] CB: 1) Using multiple edge routers with a 6LoWPAN, used to be part of ND, now separate draft. PT likes it. Who has read it? [More than ten.] (A) Who would be interested in continuing work in the WG [three hands], (B) encourage PT to work on it [4.5 hands], (C) stop working on this [0 hands]. Slight preference for B in this room; need to validate on the list. CB: 2) Fragment recovery draft PT: We have added the capability to forward fragments separately over route-over, which you couldn't do before. CB: Conceptually, you couldn't; in practice you can. Who of the implementers here is aware of the hack you use to forward fragments instead of reassembling at every hop? [Half a dozen of hands.] RC: You describe it as a hack; there could be interop issues unless it's written down. CB: I'm not aware of interop issues unless people start sending fragments backwards. CB: Back to the Fragment Recovery Draft, (A)? [three hands] (B)? [five hands] (C)? [0 hands]. Similar split as with 1; validate on the list. -- Next steps CB: Where do we take it from here? We have one more proposal. BS: [Slide 48.] Secure ND for 6LoWPAN. CB: What is the specific gain from just securing ND? Most people secure the entire network. BS: Could be important in 802.15.4. RC: There does need to be text on how to secure ND without this. However, does this SEND work fit into the remit of 6LoWPAN? CB: Where is the expertise? That is in the CSI WG. BS: CSI is almost finished. ?? (Tony?): There are a set of constraints. RD: Expertise is in CSI, but that is in the process of considering its future. So please do write down what is needed to secure 6LoWPAN-ND. CB: Who would be interested in working on this area [six hands], who would be interested in writing specs in this area [three hands]. -- CB: Is there anything else we should be doing? PS: We used to do all this in both mesh-under and route-over. Route-over has clearly got a lot of attention. Need to make sure we don't preclude mesh under. What is the interest in the room in coming up with an interoperable solution here? ZS: Two separate questions: 1) Does ND take into account mesh-under sufficiently? It does. 2) The other thing -- what is the issue? PS: We've put together a framework for route-over and mesh-under. Looking around the room, there's a lot of mesh-under expertise, but not seeing anything being done within the IETF. Is this a good place for the mesh-under people to get together. ZS: The IETF is not the right place to this work. Especially not this WG. CB: Would be good to see who wants this work done and who can contribute. GM: I'm absolutely interested in this. The original concept was that there was going to be a mesh-under. Lots of benefit could be provided if this group looked at mesh-routing protocols. IEEE is not going to do it. We do have the expertise in the IETF. PT: This is the Internet Area not Routing Area. There was a broad question of mesh-under interest. This is a bit broad for something specialized. RD: As a counter example, the Internet Area has the Trill WG that does pretty much the same thing. Just as a counter example, not a value judgement -- that happened before I became an AD. JV: We've got about 2 decades of experience to do multi-layer routing. Never managed to make it work (PNNI...). At the beginning of 6LoWPAN, there was no routing solution; now there is. We should not have this discussion without the routing ADs. GM: Need to have a discussion here and see if there's interest first. RD: There is an AD in the room and we will make sure the right process happens. DG: Implemented both route-over and mesh-under and found mesh-under to be more efficient and to be much easier to implement. ZS: There are mesh-under solutions done in IEEE. GM: IEEE did *not* standardize. It is *not* a prescriptive standard, just informational; they are not going to continue. ZS: There is little benefit in L2-independent meshing; you get the benefits by designing for a specific L2. Also, MANET work, DYMO and AODV might work well. RC: This work fits into this group. Talking about sub layer-3 work. GM: IP over 802.15.4. Not about creating a completely generic mesh layer -- we can take advantage of our expertise on 15.4. JV: Are you aware of IEEE P1901.2? The conclusion there is not to combine both mesh-under and route-over. GM: I would argue that you don't need routing on all those. ZS: Is this working group about 802.15.4? Last thing we want to do -- we worked hard to make us PHY independent. I would not like to see 802.15.4 in our next charter. RC: Doesn't have to be specific to 802.15.4. 6LoWPAN is indeed being used on other PHYs. PS: Re MANET -- ROLL analyzed them, a lot of work has been done for us. JH: 802.15.4 itself has many PHYs each with very different characteristics. ZS: We dropped this three years ago. GM: We had our plate full. CB: Who here would be interested in working on mesh-under specs, e.g. mapping existing routing protocols to mesh-under [large number of hands], who would be willing to write specs [five hands]. JV: Does it make sense to ask the question to the IAB? Multi-layer routing. RD: Yes, separate question. Let's talk about this offline. CB: In summary, ... who thinks that mesh-under should not be done in this WG? [ten hands]. CB: Returning to GHC -- who would be interested in doing work on this? [ten hands] Who thinks we should not be doing this [two hands]. PT: What does it mean to continue working? Doesn't seem like there's much interest on my drafts, no comment for six months. GM: There were some specific questions, e.g. from Margaret. PT: Yes, on backbone-router. Not on fragments. RD: What is the status? Ready for WG adoption? PT: One was a WG document; decision was to split (backbone router). Re fragment, there is a variation of interest in the room. GM: PT has worked on this for a long time. We need some commitment from the WG that they will read it and comment on it. RD: Formal call in the WG. GM: So we'll do a formal question about both documents. RC: When we say not much interest -- is it because people haven't read it or because it is not applicable to them? CB: So we continue this on the mailing list.