ROLL Working Group Interim Meeting - ROLLE (Switzerland) - September, 30 - 2009 Thanks to Sung Lee and Jerald Martocci for taking the minutes Agenda ###### 11:00 am Agenda/admin (JP - 5min) [5] 11:05 am WG Status (JP - 5 min) [10] 11:10 am RPL: draft-dt-roll-rpl-02 (Pascal - 120min) [130] 1:10 pm Break 1:40 pm "Siblings for MP2P routing in RPL" (Dominique - 15mn) [145] 1:55 pm "A loop detection proposal" (Sung Lee - 15mn) [160] 2:10 pm A Security Framework for ROLL Networks (Tzeta - 60min) [220] draft-tsao-roll-security-framework-01 3:10 pm Meeting End. Note that attendees agreed to prolong the meeting by 2 hours to allow for more discussion JP: Working Group status update The protocol is nearing completion. We still need to step back and simplify the protocol. We should focus on core specification with a modular approach: some features should be added as optional components outside of the core specification. Many nice items have been added, but now we need to be sure to only include those that are most necessary. New revision of the Metric ID is expected soon. We have found a resource to develop the MIB, but that resource is not a RPL expert. We need a RPL expert to volunteer to work with the MIB expert. Adrian> Why do we want a MIB for LLN networks? JP> Some devices in the LLN, such as the LBR may have enough power to support SNMP. Developping a management architectural framework is the right thing to do. Discussion on RPL ################# Multiple DAG Discussion Richard (Kelsey): explained the use case – Multi DAGs needed to support (smart energy) customers where, in particular, electric meters and broad band routers communicate to two different destinations (two different DAGs) Emmanuel (Baccelli) noted one DAG per unique destination Many expressed the problem of keeping traffic in one DAG when multiple DAGs are allowed. Discussion of how to keep “colored” DAG and traffic Thomas (Watteyne): what happens when multiple DAGs are fragmented (that is no default route exists) Someone noted that “White” DAG can be used as default route Anders (Brandt) noted that he would like to make sure that unimportant traffic not waste resources in the white DAG Pascal (Thubert): expressed his concern over complexity involved in keeping traffic in one DAG JP: Do you have a consensus to simplify RPL specification to describe how to build *one* DAG. Applicability statements could discuss how one could use a colored DAG to meet specification requirements. EXCELLENT consensus in the room Separate out sensors to sink and sensors to sensors communication Separate out Multiple DAG, constraints/policy Thomas Clausen will draft the simplified RPL (purpose and outstanding issues, etc ) and send it out to Pascal Pascal> The items referenced in the presentation as ëhottestí are not the exhaustive list of items to be worked on. Jerry> if the list of hottest issues is the exhaustive list of issues to be worked on by the DT, noting that to date there has been no discussion whatsoever about sleeping nodes. Pascal> they were not and that Appendix D (which is supposed to list the exhaustive list of issues will need to be refreshed on the next version of RPL. Many questions were asked about the meaning and use of DAGs. Clearly the audience participants had different views of the use of DAGs. Some felt that once the source node transmitted a packet onto the DAG, the packet must traverse the DAG only using the DAG selected by the source. Others felt that at each hop the node could decide to shift to an alternate DAG. Examples were brought up where DAGs could be stratified and a packet could not reach its destination if alternate DAG selection was disallowed. This further brought up the topic of the dependence or independence of the DAG definition. Thomas C.> asked that we be sure to clear this up since it may have impact the simplicity or complexity of the ongoing discussions and the draft narrative. Broken sub DAG Discussion Richard> when there is a fair amount of churn, it is not practical to create DAG from scratch Richard proposed the use of sequence number in handling broken DAG (detaching and reattaching) Richard noted that when Root increments DAG sequence number, the effect cascades down (All sub nodes are free to move to different DAGs) Question then becomes how fast, when to increment this number Nice property is that it is decentralized and if necessary, it rebuilds entire DAG Downside is that there is no mechanism for local repair (collection tree mechanism has a good local repair mechanism) Want to keep sequence number in RPL, but want local repair mechanism that is not too costly. RPL has local repair capability (detach and declare) Complexity lies in coordination with other nodes and interactions among devices JP suggested that we should consider the use of simple sequence number and consider options later. Pascal noted that one must study what it means if some nodes do and other don’t. Tim noted that there could be periodic and reactive updates. Anders expressed that he would like to see sensitivity to battery operated nodes Action Item: Richard and Pascal to send an email describing what is baseline and what is optional (deadline within 2 weeks) MP2P, P2MP, and P2P traffic support discussion Emanuel> Someone suggested the use of “sensors to sink”, “sink to sensors”, and “sensor to sensor” communication JP> RPL can support all communications, but asked if it is good enough for “sink to sensors” and “sensor to sensor” communications as well Sink to Sensor Communication Discussion As some sensors require “ACK,” this needs to be addressed soon. Jerry> in wireless network, asymmetric routes are common. Anders> building a larger routing table is not an option as it would require more resource and latency. Pascal> if one uses metrics in DIO, the one can also have metrics for the other way in DIO. This will help determine the best route. ?> Parents send NA-DIO, receiving node can determined which one to choose as its parent based on how good it is. Anders> asked, when a light module moves to a different DAG (and waiting on commands), how the controller finds the light module after it moves to a different DAG. Richard> if a device is waiting to receive a packet, then it needs to advertise. Question still remains how it know when to announce and to whom (the details) Emmanuel> how the sink knows that destination? Jerry> noted that the destination doesn’t know that itself is the destination. JP mentioned that one can use “flag” Source Route No path discovery needed Risk of saturation at the root (only root is capable of storing) Another necessary evil for certain nodes JP noted that source routing is the way to go if there is no way to store state. Answers asked if proactive announcement is always the right thing to do. He questioned if we still need reactive mechanism. Someone noted that RA-DIO messages are going out periodically. Pascal> if one doesn’t hear for some time, can use trickle. Tim> note that there is still a route solicitation NA-DIO multicast -> NA-DIO unicast Anders> what timing interval should be used. Richard> a field can be used to indicate what you want. P2P Discussion There was an agreement to break the discussion down to multiple points. Discussion of these topics using clear terminology such as: 1) Sensor to LBR (MP2P) 2) LBR to Sensor (P2MP) 3) Sensor to Sensor (P2P) We further subdivided LBR to Sensor flows as 2) LBR to Sensor a) Initiated beyond the LBR b) Initiated at the LBR All> Quickly dismissed the need to discuss item 1 (Sensor to LBR) at any length since this was the basis of the morning discussion and seemed to be well understood. Thomas C.> iterate that having thought about MP2P communication and expected implementations - even in collection networks there will be a need to move packets from the LBR to the Sensor since in all likelihood MP2P collection architectures will still want to perform application layer ACKs from the LBR to the source. ALL> Discussion on LBR to Sensor communication. Jerry> expressed a concern that the current RPL approach (i.e. using the DAG and preferred parents) would likely only allow a single path to be defined between the LBR and a sensor. Further discussion indicated that it might be necessary for the LBR to maintain a complete connection list for all nodes in the LLN since all nodes in the LLN would have the same prefix. JP> There are at least two means to do source routing. Discussion on sensor to sensor (P2P) traffic flow. Thomas C.> laid the groundwork for the discussion by noting that the room in which this meeting took place had as many as 50 lights, all controlled locally by light switches and dimmers. Jerry> this was just the viewable devices and above the ceiling tiles was another set of sensors and controllers to manage airflow, heating, cooling and fire control and monitoring. Also on the walls were light switches, occupancy switches and shade controllers and actuators. The point being that each room is a control system in itself, where most of the data is sourced and consumed locally. JP> in all likelihood this myriad of sensors would be in direct radio range of each other. JP> for packets not in direct range, how sub-optimal is the DAG compared to the shortest path Richard> in addition to a direct P2P message, it is also simple to support a 1-hop message when there is a common parent between the sensors. Jerry> these two constructs added into RPL would help the P2P case. However, there is a need to occasionally get data from across the LNN such as when an energy controller needs to read outside air temp that is provided on a single sensor in the LLN, but needed by most rooms for energy savings algorithm calculation. Anders> mentioned the latency issue especially how it applies to lighting systems. The rule of thumb on lighting systems is that the lights must react uniformly to a command within 300ms, else the latency will be apparent to the user. Anders (and Jerry)> mentioned the need for support of battery powered sleeping devices. The issue is how does RPL deal with sleeping devices that need to receive data and how much battery drain may there be on these devices. Thomas C.> one cannot assume symmetric routes. Richard> the quality of both directions and takes the quality of link that is the worse of the two (pessimistic appraisal). Based on testing, in a highly asymmetric links, good side tends to fluctuate a lot. Thomas C.> How the destination makes the network aware that it wants to be destination JP> One has to advertise local prefix (otherwise packets cannot be delivered) Julien> what happens if not everyone can record. Anders> concern over resource limited devices when many DIO communications are involved. Emmanuel> how many sensors expect to receive messages. Jerry> roughly 20% does. Anders> would like to have some discovery mechanism built into it. JP> asked what the group feels about reaching common parent. Julien> asked how close to each other are these sensors are. If close to each other, then most likely to have the same parent. Anders> pointed out that one cannot assume proximity and network topology. JP> asked Jerry if DAG was sufficient for his use case (building and automation) Jerry> Mukul will simulate as soon as there is enough content in RPL Richard> it would be configured for one hop away. Pascal> a node can join multicast Adrian> noted that there are two things being discussed – whom do I need to talk to and how do I reach them. Historically IETF split them. If you want to merge, it is OK, but you need to call it out very clearly. Application layer finds the identity of lights. Routing layer is finding routing only. MP2P routing through siblings in RPL (Dominique) Siblings are useful – having siblings help parents and other children the parent has. Proposa: Restrict MP2P to use no more than one sibling; then loop free Simulated RPL organization One DAG with sibling Estimated connectivity to root 10 parents and 10 siblings Over 2 weeks operation Just few siblings add a lot Richard> pointed out that the proposed mechanism will work well if the chosen sibling leads the path. A Security Framework for ROLL Networks (Tzeta - 60min) [220] draft-tsao-roll-security-framework-01 Changes since V00 • Was question about physical security – that was beyond routing • Added two subsections – not adopting any position • Architecture Looked at how other routing protocols did it. • OSPF v2, header containing security material with different options (null, plain, password, authentication, integrity protection) • OSPF v3 (layer3 – based on IPv6 and utilize IP v6 security; How to do IPv6 security to do RPL, e.g.), Link layer protection (if going to the next neighbor, then justifiable to use link layer service) JP> Don’t do any security at routing layer; and can’t assume anything about lower layer (deployment choice) Tzeta Tzao (TT)> what mechanism should you rely on to do security Anders> all equivalent security provided at lower layer Mechanisms and operations Which security services to use. May or may not wish to offer specific mechanism Pascal> Secure ND, worth exploring if SND can be integrated ; could adopt Anders> support several options (a lot of them, first key exchange is open, e.g.) Providing reference (without being too specific) Indirectly affecting protocol Flooding vs. aggregation Hop-by-hop mutating field Pascal> mostly one hop communication; decrypt at each hop Pascal> if you use 15.4 radio, then there are some features you can take advantage Hierarchical routing JP> how much of CPU, power, requirements? Comparison for options Pascal> per hop, different security mechanism, how to tune to be on the same level. TT> Zigbee might use network-wide shared key. All part of secure design for the routing protocol. JP> asked if the document is ready to be WG draft. Thomas> what does Rene (security advisor) think of this? Tzeta noted that he doesn’t think Rene has any objection Thomas C. noted that then he thinks we can move forward (make it as a WG draft) JP> will ask security advisor and poll the list Meeting adjourned.