Minutes ROLL Working Group Meeting - IETF-72 Dublin - July 2008 =============================================================== Thanks to Jakob and Pascal for the notes. Agenda ====== 1) Agenda/admin (Chairs - 5mn) [5] 2) Charter Review and Milestones (Chairs - 10mn) [15] 3) Home Automation Routing Requirement in Low Power and Lossy Networks draft-ietf-roll-home-routing-reqs-02 (Jacob - 15mn) [30] 4) Industrial Routing Requirements in Low Power and Lossy Networks draft-ietf-roll-indus-routing-reqs-01 (Pascal - 20mn) [50] 5) Urban WSNs Routing Requirements in Low Power and Lossy Networks draft-ietf-roll-urban-routing-reqs-00 (Christian/Tim - 10mn) [60] 6) Commercial Routing Requirements in Low Power and Lossy Networks draft-martocci-roll-commercial-routing-reqs-00 (Jerry - 15mn) [75] 7) Survey of Existing Routing Protocols for Low Power and Lossy Networks draft-levis-roll-overview-protocols-00 (Phil - 25mn) [100] 8) Routing Metrics used for Path Calculation in Low Power and Lossy Networks draft-mjkim-roll-routing-metrics-00 (Kim - 10mn) [110] 9) In-Vehicle Routing Requirements in Low Power and Lossy Networks draft-wakikawa-roll-invehicle-reqs-00 (Ryuji - 5mn) [115] 10) Sensor Network Routing Requirements of Structural Health Monitoring draft-manner-roll-shm-requirements-00 (Jukka - 5mn) [120] AF: Adrian Farrell CB: Carsten Bohrmann DC: David Culler JB: Jakob Buron JM: Jerry Martocci JP: JP Vasseur Ju: Jukka Manner LB: Lou Berger ML: Miika Laaksonen PL: Phil Levis PT: Pascal Thubert RW: Ryuji Wakikawa TB: Teco Boot TC: Tim Chown TW: Tim Winther DW: Dave Ward NR: Nicolas Riou DO: Dave Oran Meeting ======= JP: Introduction and welcome. Status of the WG and charter review (see the WG slides) JP: Still a bit too much discussion offline. Keep comments on the list, please. Looking for security volunteers to work on the requirements IDs and the Security Framework. JP: 6Lowpan has rechartered to make routing-requirements draft. Purpose of document is quite unclear. CB: Not sure either. Intention is that 6lowpan-specific requirements are spelled out. Current draft does that, but needs to be more focused. JP: Hope to finish review of the routing requirements IDs by end of August. All, please review soon. And check that your requirements are covered in routing-survey. 3) Home Automation Routing Requirement in Low Power and Lossy Networks draft-ietf-roll-home-routing-reqs-02 (Jacob - 15mn) [30] ML: If valuable resources like central heating is controlled by the network, it needs strong security. It needs to be standardized to allow interoperability. JB: Strong security should be in application layer. That way it is optional for devices if they want to support it or not. Prevention of accidental inclusion in a foreign network should be provided at a lower layer, of course. Not sure if the application layer security solution should be standardized by ROLL DC: Strong encryption comes for free in most radios today. We should look into this. JP: Please extract routing reqs from use cases and list them in a separate chapter. And open an ML thread on security issues. Please spell out traffic requirements, esp. the multipoint-to-multipoint nature of traffic. TC: The security considerations section confuses the concepts of authentication, encryption etc. Suggest to replace with concrete examples of use cases. DW: backbone network? neighbor area network -> we should have an IP gateway. We should focus on lp devices. JP: Yes focus on routing between the LLN nodes. NR: against assmption that you do not need encryption by default to isolate networks. -> can use unique ID. NR: some apps need to be secured like power management (heating) at home. -> should be app layer protection JP: need a routing security expert DW: you'll get a security expert. 4) Industrial Routing Requirements in Low Power and Lossy Networks draft-ietf-roll-indus-routing-reqs-01 (Pascal - 20mn) [50] JP: What traffic patterns should be supported? Both peer-to-peer and unidirectional flow from sensor nodes to data sinks? PT: Yes, e.g. from sensor to actuator as an example of peer-to-peer. Actually also constrained-based routing. PT: Reluctance in the industrial area to move to IP in process control networks, because of mission critical apps. Currently this industry is using its own standards. ROLL must address those concerns. JP: On your slide it says "Converged network - Flow isolation: Potential interferences on Shared media" What do you mean by flow isolation? PT: Office and control networks should be running in separate network topologies (at east logically). TB: Could it be a requirement or constraint to use a wired path (i.e. avoid wireless links)? JP: No, we cannot make such an architectural constraint related to L1 issues. We're working at layer 3. Use of link attributes can be made. DC: There is not a lot of new material in this revision. Presentation is mostly about last version. What are the major changes? AFAIK Layer 2 mgmt. cleanup. PT: Those changes are actually from two versions ago, when it was a non-WG document. Specifics about L1/L2 technology has been removed, like TDM and frequency hopping. A node has many peers to choose from, but only a few should be selected. The question of how to choose the "best" peers is still open. ??: There is prior work on the tradeoff between power control and multicasting. And how you can arrive at an overall metric. Need to build a topology reflecting energy conservation. Has that been considered in the WG? PT: Can you post a reference to the list? JP: Next steps for this draft is to Wait 3-4 weeks for comments. Then send the document forward. 5) Urban WSNs Routing Requirements in Low Power and Lossy Networks draft-ietf-roll-urban-routing-reqs-00 (Christian/Tim - 10mn) [60] TW: Pin-pointing the location of power outages is a use case. This will release a flood of alerts from the affected area. The routing protocol should be able to handle this. TW: Next steps - get rev. -02 out, add text on mobility and prepare for LC. 6) Commercial Routing Requirements in Low Power and Lossy Networks draft-martocci-roll-commercial-routing-reqs-00 (Jerry - 15mn) [75] JM: From the ML, I can see that large parts of the documents is out of scope. I am an IETF rookie, but am learning fast. See a lot of similar requirements to home automation and also an overlap with industrial routing requirements. Have solid empirical data from 30+ years of wired installation. I will cut out out of scope material from draft. Feedback on this welcome. Routing solution must encompass both wired and wireless links, since both will be used in coming years. Processors are typically 8-bit with 128kB Flash/8kB RAM. Installed by electricians, no knowledge of routing protocols etc. These devices are installed before building is complete. So there is no network to attach to. It should be possible to locally test the installation in each room. Network requirements: It must be possible to make run-time device and object binding. Across vendors. Peer-to-peer communications. Dominantly vertical (to data center), but also device to device comm. Packet prioritization needed. Security requirements ranging from none to very high. JP: The extra (but out-of-scope) material gave us a very solid background to understand this area - very good. Now we focus on routing requirements. Some of the cutout parts may be Appendix material. Will you update the draft in next few weeks? JM: Yes. DC: Is there enough guidance on routing requirements in the protocol survey? PL: I can help to work backwards from survey to routing reqs. PT: It would be a good idea to use a common terminology in all drafts. It should be defined in a separate document. DC: Better to align terminology section in each draft. JP: Having a terminology ID is also useful and avoid discrepancies. PT: Who will do this work? 7) Survey of Existing Routing Protocols for Low Power and Lossy Networks draft-levis-roll-overview-protocols-00 (Phil - 25mn) [100] Basic approach: common requirements. Compare to existing protocols. Common requirements necessary, not sufficient. Five criteria, Evaluation Fails if table scales with nodes or local density. DO: Any control rate not going to 0 when data rate goes to 0 will fail? PL: Right ??: This scheme is dismissing any proactive scheme? DC: Please hold your questions until after presentation. ??: (difficult to hear speaker) Your slide says: "Protocols should not waste energy maintaining unused state." What if network overall power usage can be reduced if the node keeps information it is not using locally? ??: (difficult to hear speaker) What if N goes to infinity? Does a protocol fail if control cost is O(N) and hence goes to infinity? PL: Yes DC: We are also interested in "reasonably" small values of N. ??: Do the evaluation criteria take into account what is possible with protocol extensions? There are, for example, extensions to OSPF using temporal/local filters to limit message exchange. PL: Yes, that would be a question mark in the table. ??: Then you should put a reference in along with the question mark - referring to the extensions in question. DC: We need to make this protocol survey concrete and narrow down the choices. Cannot analyze every extension/idea out there. JP: At the next meeting, we will have a whole session devoted to protocol evaluation. ?: Last time same message was given. ROLL should contact e.g. OSPF WGs to hear about new development. PL: That is very welcome. The resulting document will be better, the more experienced people we can get to contribute. ??: Path computation is much easier if node knows about node cost/capabilities of neighbors. Maybe not communicating this info via RAs. But the node may still know this. JP: Who is for adopting this as WG item? (around 30 hands up) AF: (voting against): Document is not ready yet. LB: (voting against): Same thing DC: Did this discussion help to clarify routing requirements in the drafts? .... (silence) Not clear if it did. 8) Routing Metrics used for Path Calculation in Low Power and Lossy Networks draft-mjkim-roll-routing-metrics-00 (Kim - 10mn) [110] JP: This is first attempt at defining metrics. Typo: Draft was missing "normal" link costs. This idea was too list all metrics. We all know from the Arpanet that use of dynamic routing metrics is not easy and with no doubt some of these metrics will have to be dropped. DO: Are these metrics meant to be scalar? JP: Not just scalar. PT: What about triggers on metric values, so updates are only sent when the metric exceeds a certain threshold? JP: Definitely. Pascal: if all values are not scalar you cannot compute the magic number. Some logic will be used to select a best of 2 path. That logic might depend on the use case and should be described separately. ??: Can you discern between routing metrics and data for constraining the path? DC: You are distinguishing between information used in the routing and ...? ??: (difficult to hear) An example is TE and LSA updates. JP: Note taken. PT: Difficult to compute the "magic number/correct link cost if there is too much routing info. Exactly what routing info to use should be a plug-in to the protocol so it can be changed easily. ??: There is a lot of good, related work in the OSPF WG. Can you reuse some of that? JP: Most metrics here are unique to LLNs, right? ??: Yes. JP: Too soon to vote for working group adoption. Please review and comment on the ML. 9) In-Vehicle Routing Requirements in Low Power and Lossy Networks draft-wakikawa-roll-invehicle-reqs-00 (Ryuji - 5mn) [115] RW: Motivation is that lots of wires in a car adds weight and cost. Lots of sensors installed already. Many car vendors are interested in ROLL networks. 10) Sensor Network Routing Requirements of Structural Health Monitoring draft-manner-roll-shm-requirements-00 (Jukka - 5mn) [120] Ju: Describe important use case. Non-goals are equally important. Document will be enhanced on this front. Non-goals: small network, initial bootstrap may take days. No physical mobility of nodes. JP: Okay, we are done. All, please review these drafts and report back.