Minutes IETF ROLL Working Group Meeting IETF-75 - July 2009 - Sweeden Meeting agenda: http://www.ietf.org/proceedings/75/agenda/dnsext.txt Many Thanks to Thomas Heide Clausen for taking the notes and to Adrian Farrel for Jabber Scribing. 1) Agenda/admin (Chairs - 5mn) [5] 2) WG Status (Chairs - 10 mn) [15] Slides: http://www.ietf.org/proceedings/75/slides/roll-0.ppt (Unfortunately, no pdf version supplied) Rene Struik has joined as Technical advisor / security advisor - Welcome Rene First RFC 5548 out Various routing reqd. I-Ds still pending discusses for a couple of documents, WG chairs iterating with the ADs to resolve issues. Protocol survey - all issues resolved, tremendous amount of work, thanks to the team working on this. Allowed rechartering, and served its purpose. No plan for publishing of this document. Metrics document (draft-ietf-roll-routing-metrics-00) as WG document, awaiting the routing protocol documents to be adopted as WG document to sync up and progress. A number of routing protocol submissions (individual I-Ds), which are the main agenda item for today. WG rechartered, now working on protocol design. Chair rehashes what a design team is, small, focused, kick-starting work -- but results are individual submission and do not have any special status compared to other I-Ds. The DT worked hard for a couple of months, wekkly conf calls, submitted a document that is coherent. DT existence should by no means be excluding other people's contributions. DT/RPL work based on tremendous existence proof from heap of work inside and outside the IETF on this. Tim Winter was editor, thanks to Tim. A little behind on the charter schedule. Architecture, security, metrics, routing docs need to move forward together, or closely together. Were concerned that there would be at this state a pandoras box of documents and protocols emerging, but proceeding with dicipline. Reminder of LLN Characteristics o Classic stub networks, traffic flows are mostly "inwards" - data collection, whereas "outwards" is command and control. Some exchange "between" nodes within the LLN. Still solutions providing routing for both PM2P, MP2P and P2MP. o Trade-offs made with respect to the flows carried in routing protocols. o There are no links, no graph - connectivity discovered through continued usage. 3) Distributed Autonomous Depth-first Routing Protocol in LLN draft-iwao-roll-dadr-00.txt (Iwao - 25mn) [40] Distributed Autonomous Depth-first Routing Protocol in LLN (Sung Lee) I-D: draft-iwao-roll-dadr-00.txt Slides: http://www.ietf.org/proceedings/75/slides/roll-3.pdf Submitted draft about 2 months ago. draft-iwao-roll-dadr-00.txt Aims for urban and industrial routing requirement Build and field-tested system with 1500 nodes - up to 30 hops experienced, but average is 6-8 hops. Started 6 years ago, using AODV as routing protocol. Encoutered certain problems, tried to understand how to resolve them. for example, o Signal Strength fluctures significantly within a 24h period for a node. o Smaller packets increase chance of transmission success o Smaller packets to construct routing - not same result as with larger packets. Hence, worked on DADR. DADR: o Modified reactive approach, send HELLO messages to exchange the information o Using this to *guide* the route formation and packet forwarding, but not exclusively - data delivery (or failure) used to convey routing information, date packets embed routing ctrl o Use data transmission success rate for path formation / distance metrics. Question MRichardson: o how does the feedback work? Is there some internal path from the ULP to the routing protocol, or is it application->routing protocol? Answer: o Keep record of packet, L3 only, no ULP interaction. Strength and weeknesesses Strength: - integrated security, loop detection with forwarding, low control Weaknesses: - packet transmission record must be kept - required network wide synch for security. Showing various performance graphs. Question Emmanuel Baccelli: o Are these results simulation or tests. Answer: o Slide 1 (OLSR/AODV/DADR) was simulation, slide 2 was real-world test. Don Sturek: Size of routing table: do you hold entry for each destination (global dest)? Answer: yes, we actually keep multiple entries per global destination Henning Rogge: Did you use routing metrics for OLSR/OLSRv2, as such are very important for the routing protocol? Which metrics did you use for these protocols, as in your protocol you use your own protocol Answer: For AODV we use hop numbers. For OLSR same - but for their protocol used cost metrics Henning Rogge: Metrics is of extreme importance, Ulrich Herberg: Suggests using flexible packet format such as packetbb Answer: Maybe, we can discuss this Geoff Mullingan: IPR? Answer: We have patents on it, is working on what we can do, ready to work with you. INTERMISSION: Chairs ask that questions be held until the end of following 2 presentations, rather than during the presentations themselves. RPL Walkthrough (Jonatan Hui) I-D: draft-dt-roll-rpl-01.txt Slides: http://www.ietf.org/proceedings/75/slides/roll-1.ppt (Unfortunately, no pdf version supplied) Tutorial of RPL basics: o DAG construction o Loop detection and handeling o Trickle RPL "FAQ" (Pascal Thubert) I-D: draft-dt-roll-rpl-01.txt Slides: http://www.ietf.org/proceedings/75/slides/roll-2.ppt (Unfortunately, no pdf version supplied) Addressing the following topics: o Why Distance Vector? o Why DAGs "reroute around transisnt loss" "fast reroute" o What is the Objective Function? "plugin, generating the notion of depth" o Why detach/merge? Why handle loops this way? "implements advanced DV concepts to avid loops and count-to-infinity" o Route Stretching "Acceptable trade-off" "Inherent with constrained states" Issues under Discussion: o Source Routing needs to be supported. Can build source route path, but we need to find a way of making representing that path "small enough" that it can fit within a path Richard Calssey: Example showed a tree, but you talk about a DAG all the time. So you may have multiplicative effect and send a lot of data, this is not addressed in the draft? Upwards paths not a lot of storage, downwards may be a lot Answer (Culler): Draft doesn't address it, but degree of redundancy limited to 3 and there is compression. A tradeoff, redundancy could be further limited. Richard C: if naifly fwd up everything you will enumerate all possible paths through DAG for everyone Baccelli: Depth vs. metrics vs ....confused Thubert: Metrics are used for path computation Then, you have to decide for an abstract number, which we call "depth". It is NOT the distance used to find parents and siblings. Don: p2p support, can that be added later or must it be included in the proposal? Answer: That's something that you'll want, you can run multiple instances of multiple protocols on the router, the arbitration is on the RIB - business as usual JP: p2p is already there, but can be improved. Dave Culler: Can always go up, then down, to do p2p - basic support, but can do better. Don: When having an ungrounded DAG, you relied on the RAs of the neighboring devices to indicate route back to sink. So you get rid of the state, but all the childs info remains? Answer: That, we will see on the next slide. Open RPL Quetions, generally (Apologies for the poor quality minutes henceforth, as the minute taker both asked questions and channeled Jabber questions - much of this is copied from or edited from the excellent Jabber scribing done by Adrian Farrel) Alex Petrescu: so why two words: "ETX" and "Depth"; they seem to say the same thing. MRichardson: I think, ETX is a specific word that refers to metric, but includes a great number of other considerations. distance, battery cost, etc. Dave: Depth makes sense if there is a graph, but not if no graph to compute depth over Depth is number of hops in an induced graph So Etx is a good measure of depth on a particular graph Pascal: In reality if your Etx has too many bits, you have to mask of LSB to get at the thing you want. When you define depth you will mask of a number of bits from the ETX. It is one way of doing it. We are just abstracting. Depth is abstract to allow comparison between networks or different techniques. MRichardson: Given that the objective function is a plugin, is RPL resilient in the face of different nodes using different objective functions? Do objective functions need to be standardized so that we can show that we actually get interoperability? JP: We had a similar issue in another WG (PCE). There, we chose to std a few OF so we knew that we were comparing apples and apples. MRichardson: On slide 16... how does G<->H communicate? Both emit RAs so advertise objective depth. If we have this link they realise they are sibling by hearing RAs with same depth. So in that case, when G communicate with H does it go up down (to parent) or direct? In other words, can G communicate directly with H, or must it go via F? Pascal: G is entitled to pass to H because it is a sibling Chris Dearlove: Many questions, but this work is a novel combination of pieces (some well-known, others not at all). What about running code? Dave Culler: Accurate assessment, No we do not have running code of it all, but of components. There are open-source 30K code that exists of "similar" protocols such as hydra Chris: More thinking of behavioral stability of the combined protocol etc. When we put such a collection of pieces together we may get a resulting combined behavior we didn't predict? Dave Culler: Fair question. Ulrich Herberg: Security is intended to be inside this draft or elsewhere? Pascal: Not intended to be in this document, no. Maybe use SEND etc, if we can afford it. Existing mechanisms are good. Do L2 security in place, this may be enough/sufficient? Next Steps on the ROLL routing protocol (Chairs) WG document should happen when there is consensus on a document, hugh work ahead for whichever document becomes the wg document. We need to move on, for the IETF and for the industry. Said over past 12 months, even more true these days. Rely on us to provide a solution. Several companies ready to implement and test ROLL protocol as soon as wg ID is present. About 10 ready, IPSO is ready to take part in such. Selecting a base protocol does not mean that good ideas from other documents are excluded, on the contrary, the base protocol is just that, the base protocol to which additional components can be added possibly from other documents. Chairs call for raised hands on "Who has read...." RPL ~30 people DADR a bit less, 25ish Chairs: To what extend do people feel that we have enough basis to adopt a WG design doc? Expect the answer to be yes Consensus-call (paraphrased) Ask ourselves this: o Does RPL (draft-dt-roll-rpl-01.txt) form a good basis architectural structure for a candidate protocol? o In areas where RPL is not quite fleshed out, does other contributions to the WG (I-Ds) have components that can be used (integrated or orthogonally)? o Any holes left? => In light of the above, is there consensus for adopting draft-dt-roll-rpl-01.txt Hand-raising showed reasonable consensus in favor of this. Chairs will verify on the list. A Security Framework for Routing over Low Power and Lossy Networks (Tzeta) I-D: draft-tsao-roll-security-framework-00 Slides: http://www.ietf.org/proceedings/75/slides/roll-4.ppt (Unfortunately, no pdf version supplied) o Enumerate security issues in LLN specific to routing o Facilitate assessment of RP threats o ID necessary features of a secured ROLL protocol o Provide framework applicable to a generic RP. Bjrn Pahlsson: Why focus on protocol security, when the doc also talks about hardware security. Should hw security not be broken out in a seperate document? A small section on physical sec is confusing - there's more to it (e.g. water) Tsao: Will try to address in coming version. Alex Petrescu: Is the RPL security risk having any impact on the Internet? Or is it local? JP: Even if local, if you shut down the grid there will be trouble. Culler: Disagree with the musts on slide 11: if I go steal your DNS server, obviously I have stolen your DNS server - but that doesn't imply that every other DNS server needs to be physically secured. Is this any more relevant here than anywhere else? Should physical restriction be part of the DNS spec? Physical tamper resistence is out of scope. Security Advisor (Rene) at the mike, asked by JP to share his view. o suggests limit the impact of compromising, rather than stipulating compromize-prevention o Good to phrase security in terms of the impact of compromise o Have had fruitful discussions with the authors, and consider security a holistic (whole-systems) thing, especially in this context Meeting adjourned.