ROLL Virtual Working Group Minutes - June 2010 Thanks to Phil Levis for taking the notes Agenda ###### Agenda/admin (Chairs - 5mn) [5] 1) WG Status (Chairs - 5 mn) [10] 2) RPL: Routing Protocol for Low power and Lossy networks (Pascal/Phil/Tim - 45 mn) draft-ietf-roll-rpl [55] 3) Mechanisms to Support Point-to-Point Routing in Low Power and Lossy Networks (Mukul - 45mn) ? draft-dt-roll-p2p-rpl?[100] 4) The Minimum Rank Objective Function with Hysteresis (MRHOF) (Omprakash- 5mn) draft-gnawali-roll-minrank-hysteresis-of-00 [105] 5) Performance Evaluation of Routing Protocol for Low Power and LossyNetworks - (Jaudelice - 10mn) draft-tripathi-roll-rpl-simulation-04 [115] Minutes ####### JP: Charter review and milestones. Progress on current drafts, requirements, metrics, of0, terminology. Lots of progress on RPL specification: new security section, over 10 implementations in progress, interop reports frop IPSO and Zigbee-IP. Focus is on core specification, slide 6 presents our major next steps. David C.: A key think here is the discipline of minimum viable protocol. It's hard to do something simple, especially when it's the result of a group process. But this domain really calls for it, and so we need to stay focused on this goal. Pascal: We have added two big pieces: security and manageability. We have also added a new ICMP error for source routing. There are 6man drafts for needed mechanisms and some minor changes to sequence number handling. Pascal: Everyone please participate in 6man to support adoption of the needed RPL headers. JP: 6man WG chairs have polled the list for adoption. Now is a good time to express your opinion. Pascal: One question is what we should do with the S bit. Emmanuel: I think we should just cut it. Let's keep things simple. Pascal: Path MTU. Do we want this? It means the network doesn't need code for PMTUD. Phil: I disagree on this claim. Pascal: Well, if we know the network has an MTU larger, then as long as we are not talking to something in the Internet with a smaller MTU.. Samita: Everyone on the list seems to be against it. Pascal: I disagree. David C.: Let's move on. JP: Status update. If you look at our to-do requirment list (MUST), there's a lot of red. This all has to do with security. With the security section in place, I'm going to move through the to-do list and update. This relates to ticket #25 that has been updated in light of RPL version 09. JP: Ticket 30 (multicast): Richard or Jonathan, quick update? Richard: Really a forwarding, not a routing, issue. So though is that this is a separate draft, does not go into the RPL document. Pascal: I will come back to the sequence counter later. The current text is not quite correct, we'll fix it in 10. Let's go on to targeted DIO. Pascal: Target in DIO is important for a few cases. Fast repair, packet from outside, P2P. Emmanuel: How does this relate to the P2P draft? David C.: The question is whether there's a decision. Let's talk about the decision process. Part 1: Is this part of the minimum viable protocol? I'd like to get beyond anecdotal observation: "Here's a case where it seems to help." Let's get to science. We need the minimum protocol so that we can then make quality decision making. I'd rather be making these decisions based on evaluation rather than my anecdote versus your anecdote. Mukul: In the P2P draft, there is a target address. So there is some application use. But the P2P draft already handles this through an option, so this target mechanism seems redundant. Pascal: OK, let's take it offline. Let's go on to security. JP: Before we move on to security. The plan is to come up with -10 by next week. So if you have comments or feedback, please do so soon. JP: Rene, OK, why don't you present. Rene: The RPL spec covers a few needed basic security services (slide 24). Rene: We support keys between two parties, a set of parties, or the whole network. There are also signatures. Rene: The design needs to handle the set of application domains. We have a set of crypto mechanisms that can be configured to meet the different application requirements. Rene: The slides are wordy. Here are some details on packet protection. This is about time delay support. Security uses a counter, a nonce-based construction. THere's support for a counter that's connected to a clock. Emmanuel: Tiny question. You said the granularity is tenth of nanoseconds. Rene: Time-based counters are 1 kHz, so one millisecond. Suppose you have an industrial application, with accurate clocks on board. Let's say you have a 50ppm clock. You can always use compressed counters. One of the advantages of using this timeliness feature, you can't replay packets much later. Michael: So I could have a dump implementation that just increments the counter on each packet. Or do I have to synchronize with the rest of the network? Sometimes units are in packets, sometimes in milliseconds? Rene: We talked about this on the security DT, also the issue of having clock-based and non-clock nodes interoperating. Phil: The short answer is yes. David C.: Do we want something in the routing document that would require a clock on every node? We're not requiring a synchronized clock on every node. Michael: The issue with the counters, you can replay the packet. Then you have 2.9 days to replay the packet. Not all nodes have seen the packet. You can inject it. David C.: The tradeoff is the degree of delay protection versus the energy spent to protect against it. Definitely one of these questions where there is a tradeoff. Michael: What I see is that in a relatively sleepy network that sends few packets, you can almost always compress. My concern is that a receiver has to handle both clocks and counters. Unless you can set in a DIO that there's a global setting. Rene: Still some open issues. 1) Timer versus counter. 2) Processing front, there's a question of whether there's sufficient detail, I think we need more. 3) Currently some support for key management, this area of initializing keys needs some more work. 4) There is also a question of what you do not have the correct security policy parameter. Some support in -09 for the consistency check mechanism. Question is what needs to be in RPL protocol, comes from another layer, or is outside scope. David C.: One comment. Important distinction: it addresses bootstrapping rather than key management. With that distinction, the bootstrappng mechanism needs to be specified as part of RPL. How the keys within that exchange are managed, that makes sense to move to a higher level. It does say how DIO DIS relate to the level of security. That piece, relationship of authentication to underlying RPL actions, that belongs in RPL. Rene: This is something we really have to review the whole draft, make sure it works. JP: What's the plan? The goal was to come up with -10 that we would run by some directorate and AD and of course the entire WG? Can the missing security pieces make the next revision? David C.: I think we absolutely could. Alex: One short comment. Is the use of IPSec, AH, planned for RPL messages. Is there any intention of IPSec AH in RPL. Michael: My opinion is that AH is too big for LLNs, we should do this within the RPL message itself, DIO. David C.: This was the conclusion of the security DT. The goal isn't to cover all IP traffic. Rather, cover DIO DAO DIS DAO-Ack, etc., as needed in case there are not other mechanisms available. JP: Let's start the P2P discussion. We need to go a little faster. Mukul: There are two major limitations with current P2P: congestion around DODAG Root, suboptimal routes. Mukul: We require source-initiated, on-demand discovery of routes, and being able to measure the quality of these routes. Mukul: The mechanism being proposed is very simple. A source sends a discovery message. This discovery states the nature of routing cost, direction, number, source or hop-by-hop, and a max distance. Mukul: Important concept: distance versus good enough. Good enough might be too complex for an intermediate router to calculate this. Phil: Can you explain why this is important? Emmanuel: You MAY separate them. Phil: I guess that having that MAY means that you need end-to-end measurement; if you removed the MAY then would remove that need. David C.: Many parts of this proposal seem to be MVP-challenged, but given that you need to suppress duplicates, use caching, packet lookups, the question of whether you can compute something doesn't seem that relevant. The point there more generally is that we don't need to go through a revisiting of AODV, TinyAODV, but rather we need to see that if there is another information dissemination mechanism, then we should see if it's part of the Minimum Viable Protocol. Mukul: Route discovery is pretty straightforward. Discovery message passes forward to destination. Nodes can cache the result, send response back saying I was able to discover this route. JP: If you could focus on issues where you would like feedback, that would be better. Please refer to the number of comments that I provided on the list yesterday. Mukul: Distinction between good-enough and distance criteria. We are saying discovery message can be carried in DIO. We can use a temporary DAG to propagate discovery messages. Let's look at the discovery message. There are a few flags. There's a max Rank field, 7 bits, 128 values. This is the upper limit on Rank that a node may have within the temporary DAG. Pascal: I am trying to understand if this proposal has implications to the main spec. We need to know that very soon. What I would like the group to think about is whether this information would be helpful in the main spec. Phil: Can you talk about how the presence of an OCP affects other options, due to how OCPs are now independent of metrics? Mukul: If the route disovery can't use the same OCP that's used for DAG, then it sets the O flag. The one other thing we're saying as a MUST, if the O flag is set and there's an OCP, then there MUST be a metric container that's relevant for route discovery. The main question is what is the, what are the metrics relevant for route discovery, they go after the route discovery option, but the ones for DAG go before the route discovery option. David C.: Is there any place where we have prevented the flexibility that is need to incorporate this in the future. Mukul: No. This is currently completely complementary, does not conflict with RPL in any way. David C.: Is there something that is required to do this, is there some flexibility we need to do this, that isn't in there now. Mukul: As I told you, I think the base spec is fine. It doesn't need any modification to accomodate this particular draft. Emmanuel: Mukul, could you talk about the DRO? Mukul: Here are some examples. We can have two metric containers. There is a new RPL control message, discovery reply object. Slide 28. This DRO has three functions. It can serve as an acknowledgement for source routes. It can also establish hop-by-hop routes. There can be up to 7 source route options. Each option contains the entire source route. The option looks a lot like RH4. JP: We have a few minutes, have time for a few questions. OK, thank you, Mukul. Om: Let's start. First major question: how, if the OF is metric independent, how does it convert the metric to Rank? For example, ETX is 16 bits, latency is 24, how does the OF translate them to Rank? JP: that's a topic that deserves some discussion. I'll open a ticket. Om: This OF, it finds a route with the smallest path cost. So one issue is that we don't want too much churn due to metric value. Some metrics might have lots of jitter, others don't. So how does a metric-independent OF handle this? There are other issues. How often should Rank be updated? Should it be periodic, or reactive? I kind of cheated by putting in some constants, but they are kind of ETX specific. David C.: This is a really useful piece of work. If there's a bunch of implementations, how are they pushing into this space, or do they just use baseline. One question: if we were to futher constrict the generality, do these issues become resolved? Om: Good question. Phil: Maybe OFs can be either general or specific? We can have an OF that is metric independent, or a metric that is metric specific. JP: We don't want an exception. Phil: But pushing general means we lose something. JP: I don't think that's true. Phil: OK. JP: Let's go over the last slot in 6 minutes. Jaudelice: Brief overview of where the draft stands. I'm mostly going to talk about scalability. We use Castalia, based on Omnet++. Here are some details on the simulation setup. Juadelice: Comparing the ETX path RPL computes versus the shortest path, we find that RPL is not optimal, but it is only slightly worse. Fractional metric stretch, we find it's small. Phil: This agrees with the configuration parameters earlier. Joudelice: Tiny control overhead, increases with global repair timers. Poisoning the sub-dag improve convergence. Jaudelice: Our goal is to make this an informational RFC. David C.: Can I respond to that? It's wonderful to be driving these decisions from data. Great to see these results and this process going. To me, the question isn't whether we should have a simulation working group document, but in what form. The issue is that the conclusions we reach are so based on a set of assumptions. Underlying topology, churn, traffic pattern, etc. What I'd like to see is to build up an understanding of what needs to be in the WG document to be useful. We should set out what the simulation methodology is, this is more important than any particular study. David C.: That's my biggest concern, going from the individual draft into a document that the working group could benefit from. There should be a WG document on anaylsis and how to do this going forward, and I'd want to hear from the WG an understanding of what is important. JP: since I am a co-author, David could you start a discusison thread on the list? David: yes.