6lowpan at 68th IETF meeting WG -------------------------------- Slot: Mon, 2007-03-19 9:00 - 11:30 Room: Athens/Barcelona/Berlin (Prague, Hilton Prague) ================================= Notes taken by: Christian Peter Pii Schumacher Pascal Thubert Minutes assembled by: Carsten Bormann Christian Peter Pii Schumacher $ID$ ================================= (voice recordings were not used for these minutes, but may be available from http://www.ietf.org) Agenda: Segments: 1. 9:00 - Introduction - Chairs (10) 2. 9:15 -- Document Status - Chairs (30) 4. 9:45 -- Rechartering Process - All (10) 5. 9:55 -- Downselecting potential topics -- All (60) 6. 10:55 -- Input on chater topics (35) 7. 11:40 - 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 -- 9:00 -- Introduction -- Chairs (10) Document(s): I. Chairs slides Conversation: --- Segment 2 -- 9:10 Documents: I: Chairs slides (which include a few slides from Gabriel Montenegro) Conversation: Current charter Milestones way behind, but finally progress. Both documents submitted to IESG Problem Statement approved by IESG as Informational Format still under consideration format: 2 items to be discussed today Item 1) datagram tag size. IESG review asked what's the calculation behind the choice of 10 bits; wrap problem: ipv6 fragment timeout is 60 seconds where our 10-bit tag would wrap in 30 seconds if one sender used the entire 802.15.4 bandwidth for reassembly 18 bits enables up to 100Mbps bandwidth scalability, as explained on the list. This is the remaining big change coming up. David Culler: This added cost is amortized over big packets (they must have been big enough to cause fragmentation in the first place), so it's not too bad. One issue is whether this byte should just be added, or whether some bits should be reserved. There was consensus to just add the byte, and not reserve any bits. A side discussion occurred on how strict the mandate that the sender has to assign the tags in ascending order needs to be taken. The Document says the source should increment. Carsten said it was not clear whether this counter was one per sender or one per sender-receiver pair; i.e., does the document imply a source has to maintain a per destination tag increment? If the counter is global, there's no way to force consecutive tags. David noted that the resulting tag size of 18 is a pretty unnatural choice for procesing by embedded cpus. The difference in reassembly cost between 16 and 18 bute is worth paying attention to. Be clear about constraints on receiving end. Item 2) Clarifications. Prefix vs. Pan ID: The text in the document might suggest that instead of using existing IPv6 mechanisms to announce prefixes, 6lowpan always computed this from the PAN ID. The simple fix of removing the sentence that only suggested a mapping from the PAN ID to the prefix. 2 ways to support Multicast: Again, the simple fix is to support multicast functionality only in mesh lowpans: As it stands, multicast needs mesh routing underneath. Suggestion: make an explicit statement that multicast is used only if mesh routing is present. UDP header compression P value -- special way to do stateless header compression for port numbers in UDP packets. (Values P to P+15 can be compressed down to 4 bits.) The document does not define where the value P comes from. One suggestion was to ask IANA for a set of 16 consecutive UDP ports, which might require significant explanation. Carsten mentioned that once these are reserved, application protocols are going to fight for the 16 port numbers, so it was preferable to treat this space as dynamic space. Mark Townsley said that IANA has an internal expert that looks at UDP port allocation, so you need a very very good argument (like RFC on standards track). He proposed to keep the encoding, but make P configurable/discoverable and postpone the choice of P to a separate document. "Anyone can just select ports". Magnus also approved this approach. Geoff mentioned that this opens up the question of discovery: by bootstrapping or IANA. David asked whether we need to deal with dynamic discovery. The question was raised whether stateless UDP port compression might be an option. Carsten voiced a strong opinion that there should not be option... we don't have options. David reasoned that this implies all nodes must receive the UDP header compression -- when you join lowpan there needs to be a way to find out P. Mark asked whether there weren't already a set of things to be discovered -- P could be put in there. Allocating 16 port would be a couple of weeks for approval. Erik Nordmark noticed that it seems this results in a "you MUST implement that protocol" that is not fully specified described. Either you defer the all thing or you remove the MUST support. Carsten said that we had many places in the IETF where we had to manage a small number space. 7 bits for payload type in RTP, etc. All attempts to manage small number spaces like this turn out to be a problem. Solution for RTP in AVT was to stop allocating statically and do dynamic allocation. In 6lowpan we are likely to do the same thing, be dynamic: If you have more than 16 possible protocols in a PAN, you need to adapt the 16 ports with the case at hand. We need coordination to do that mapping like a bootstrapping configuration protocol. Knowing where the efficient port number range starts helps implementation. We can use 49152 to 65535 already allocated by IANA for dynamic ports. Carsten opined that a value of 66666 would be nice for P, but this is unfortunately out of range; the exact value in the dynamic space were to be decided on the mailing list. There appeared to be consensus for this procedure. Carsten: We can have a revved draft tomorrow morning David again brought up the issue of 16 vs. 18 bits in the datagram tag. Geoff opined that 16 is an attractive size (word vs dword) and should be enough for the foreseeable future. Carsten then proposed to extend the discriminator bits to 5 bits, and only allocate 16 bits, and to swap around tag and size so everything is aligned again. Consensus. 3. Segment Documents: Chairs slides Conversation: Recharter Agreed at 66th IETF vancouver meeting. Needs to be validated on mailing list. And re-validated after this meeting. Has anything changed? We'll look at the 5 items agreed and examine if new topics fit in. - Bootstrapping and ND optimizations (proposed standard) We do not want to change ND but optimize the packet usage. From there we know how a node finds its place in a lowpan. - Problem Statement for Stateful Header Compression in 6lowpans. Stateless assume to be light weight and suitable, so purpose is to explains why stateful may or may not be applicable for 6lowpan. (Informational) - Recommendations for 6lowpan applications people thought architecture, red lights go up... example "architectures" is what we do here. More like "ways things work". (Informational) - 6lowpan Mesh routing (?x proposed standards) this may not be a new document, but references existing documents (from like MANET) and explain the deltas like routing on 64 bit MAC addresses. - 6lowpan security analysis (informational document) point to IPSec or 15.4 sec, but may not be enough. Carsten: Mobility is very related to bootstrapping, will be very important for item 1) Geoff: what does the network actually look like, is there or is there not a PAN coordinator? How how how? So this is relevant for the bootstrapping . How do you bootstrap if you don't have the key, secure vs non-secure. ZigBee have come up with their solution, We need a framework for explaining Bootstrapping. Kim: We had no opportunity to discuss that architecture to date, but now we do, and we have many drafts describing each their own protocols ... this may divert from a unified document. I think in addition to mobility and boot strapping and ND, we have to discuss architecture.. what are the possible scenarios, do we allow several routers.... multiple PANs ? Needs to be discussed and clarified in architecture document. Extension of format document would I propose as seperate charter. Exploring the capability of the format document for future extensions. Carsten: getting mired in architecture may make us lose focus. Geoff: scares me, we took some time to complete current set. One goal is trying not byte off too much but choose a couple (2-3) topics, divide and conquer. Wassim Haddad: We have an ongoing war on ND and security. SEND protocol and optimized SEND. Daniel Park: Prior to considering security, WG should decide how to deal with SEND (and optimization). Not strong objection, but should be part of Security Analysis document. Behcet: The ND document, you want bootstrapping and ND. Currently no bootstrapping in ND? Why not seperate document. Geoff: Not intention one document Carsten? Carsten: Makes sense to have ND and bootstrapping in one document, since issues are relevant. Erik: when we're done, it will be nice for implementers to have one document, but developing the document, maybe the process is helped by splitting them for now. Don't integrate mobility in bootstrapping? David: Meta criteria, use "and running code?". Is the topic critical for fulfilling "and running code?". Enable work in other WG. We almost have the actual bits in their air... Geoff: are there anyone willing to work on a specific item? Kim: bootstrapping, agree with david on bootstrapping doc. How to ensure interoperability. Propose scalable routing protocol ? Mention first priority Carsten: should spend time prioritizing Eunwok: What kind of scenarios we are working on. Which scenarios do you want to see. For example sensor networks applications. Carsten: reasoning I ask, you can buy big books on scenarios.... important here is to select small amount of scenario. Eunwok: What kind of scenarios do we want to focus on... Carsten: how do you find that out? Because since we founded this WG I've tried to get reasonable requirements from the people who want to use this, but it is not really possible. Geoff: lets asks on the list again, what scenarios ... get industry input. If you guys out there have a specific application, bring it here! Now is the time (not only time). Kim: IPUSN aims to have a bigger picture than 6lowpan. Find the killer application, may be the ubiquitous city (pipelines, traffic lights ... ), what are the requirements / functionality of 6lowpan .... we focus 3 items: -integrated network managements (SNMP) -scalability -mobility ???: MANEMO Carsten: tech or scenario? Geoff: tech. Pascal: building a manet , nested NEMO topology -> Thu BOF (it is after plenary) Geoff: Killer application? ISA SP100, wireless sensor networks for industrial space, pharmaceutical, replace Profibus etc. Maybe we could address something for those guys. Shell not concerned about a couple of 100000 bucks for radio, it is big loss when they go offline. Nicholas ?: health care environment, there you can sell many units. Body-area network for instance. Hospitals. Geoff: Home health-care Metering David: Great to have applications. But discussion is only fruitful if it boils down to ????something for us. Internet was build around file transfer A-B, what is the application for TCP??? If already there Eunwok: Maybe not just ubiquitous city but environment! Geoff: if you're gonna put in cars, mobility because important. Anyway we're not collect all scenarios, but these work load are pretty interesting, right David? David: not if you can't boil them down. Kim: we did some installations based on 802.11g with directional antennas. Managed by a simple platform pseudo SNMP. Coastline watching possible based on IP. Geoff: Let's pull out of this list. Carsten: put them all under "App Recommendations" works inward for us and outward for our "virtual" customer. Item1 <= bootstrapping, ND and "SEND" (maybe seperate) Item2 <= "boring" Item3 <= all scenarios => "app recommendations" Item4 <= we need to this. Item5 <= is it wise to do separate security analysis? ? : Security topic is very big in this area. Why do separate document. Mark: sorry to jump in. I think threat analysis is a very good thing to do, this is exactly what security guys will ask you for. Geoff: back to Item4, everything can do whatever you want on top. I'm guess I'm saying, i'm not sure we need to do mesh routing document. Or maybe we want to? Maybe MANET should carry this? Will MANETs work in practice in 6lowpan? Proof-of-concept important here. Carsten: we can't use DYMO as is, we need "new" packet format. Maybe not use word EVALUATE in charter topic... Geoff: but we are comparing them, which ones are critical for 6lowpan? We have not been the most stellar group on hitting a milestone. Pascal: Maybe put your requirements in MANEMO... Geoff: think we're a success (as david says) it other WG's take on our work. Mark: I see many mini BOF's around here. ND for 6lowpan you need to do, but once you get into routing, maybe you need to go Routing area. Geoff: one quick thing. There is a bunch work going on 6lowpan-mips. So we have started to infest (invest) into other groups. David: kinda suggest a less aggressive variant. Agree on a strategy ? Recognize from the beginning, not winner take all. What is strategy? Do we down-size or distill ? Not focus on NEMO or whatever. Carsten: I haven't heard anyone propose a protocol that solves everything. I think we need to support more ideas. Ian: My concern where do you want interoperability ... you need to define where to have routing. Geoff: i'm not sure we're gonna define that but if we want to enable the opportunity to build interoperable or not. It doesn't seem anyone can say whether DYMO, OLSR is good for all. Ian: where do you want to break up the problem, do you want to pass the buck to the guys making the products. Maybe not good to do that. Allow optionables? Geoff: how long has manet been working on this? Years! Don't think 6lowpan can reach consensus. I hate for us to say that this is number one task for 6lowpan. Mark: There is a lot of expertise on routing in IETF. You would think that there would be a way to do at least one way of routing. Or state that for each application space state this routing works here. If there is a thing we really don't understand, we have research groups for this. ?: Why not have a mix of protocols? Why does routing protocol have to be below IP layer. Elaborate because I disagree. Carsten: It doesn't give you a link . ?: It does. Carsten: no not in standard IPv6 link. Erik: Questions where are you IP sub boundaries. Well if you say that we don't care about subnet boundaries. It is exactly whatever the radio topology comes up with, so that we'll be hard to manage. ?: ? Geoff: different PHY/MACs ? ?: yes Geoff: we've already begun going that path... potentially different PHY's Erik: There is IAB document : link-model . which points out the issues in this case. It is a good document (background info). Ian: It is my understanding that 6lowpan will operate on different PHYs, but every single network will be using the same PHY . Geoff: I can see that 6lowpan is big enough to cover multiple PHYs, but I'm not sure I'm ready to say that 6lowpan is for a specific PHYs. Ian: If you are not running the same PHY you cant ...? Behcet: Before we close, bring up another issue, device identification? I think it is important. Daniel: My answer, should take place in bootstrapping doc. We don't have a solution. David: Say it doesn't work a specific PHY, but can be used for different PHY's, but requires some basic things for the MAC. Erik: One way of solving IP mobility ... you make your sub-net be bigger... there are trade-offs you put in mobility space. Geoff: As David said, we don't need to make a choice. Mark: Start thinking about have a different PHY, the layer above could be interesting. christian makes rechartering item texts Segment 6 Carsten showed one slide from Dominik's slide set