IETF ROLL Meeting – San Francisco – 3/23/09 Thanks to Arsalan Tavakoli for the minutes. - Charter Review and Milestones (JP) JP> Need to close on one final issue for protocol-survey. Phil and Ian should discuss and clear-up. - New ROLL WG charter JP> Goal is one protocol to address requirements and unicast/multicast, will need to recharter if we need more. Realize that timeline is relatively fast, but believe we have people with design and deployment experience, and truly hope that MANET people play an active part in this next stage. David C.> We need to be thorough, but move fast. Rough consensus and running code. - Routing Metrics use for Path Calculation (Kris Pister) Kris> Running through changes in -03. Memory should be a focus, CPU is not. In terms of power and energy, don’t want something overly complicated, but something overly simplified is not useful either. Link reliability is about RF interference, not about hardware reliability. Kris> Next steps: figure out how to set and update these metrics, and co-evolve with routing protocol. David C.> Ready to adopt as WG document? (Majority favor, a few abstain). Kris> Security Draft? What are the next steps? We need to move fast. JP> Agreed. Somebody from the security directorate has agreed to help out. - The Tree Discovery Protocol suite (Pascal Thubert) Pascal> (Question about Clusterhead coordination) Clusterheads don’t coordinate. Node’s make the decision locally. Phil> You can just use data to detect loops and form the topology. If you wait, you risk overloading forwarding nodes’ queues. David Oran> Does this only work if there are layer-2 addressing mechanisms? Pascal> Yes; currently you do need layer-2 addressing for this to work. JP> Important to also consider the case of layer-2 with no addressing mechanism. Thomas Clausen> Does this current scheme require hierarchical addressing to work, as in prefix-based routing? Pascal> In this current example, it seems like that, but not necessarily the case. David Oran> It seems though that with the process of boulevard being created, if this causes a node to be moved to another avenue, there seems to be the need for an entirely new route computation, which can be extremely expensive. You should revert to tree routing, and forgot the need for costly recomputations. JP> Agree JP> When will you post a draft so people can read it? Pascal> Waiting for people to help me. If people say it’s not useful, then we don’t need to do it. Charles Perkins> So what is this concept of a plug-in? Should technically be a simple metric because want all nodes to use a coherent policy, so don’t quite understand the role of the plug-in? Pascal> Trying to use it as a mechanism for dictating application specific routing logic. Technically should be network wide, not just node-specific. However, perhaps there are cases where nodes are making different decisions locally, need to make sure that there is some element of consistency. Charles Perkins> Is Park formation dynamic, or pre-configured. Pascal> This work is still rudimentary JP> Need for a modular design approach. David C.> Need to clean up some terminology here. We’ve called them ‘tree’, ‘DAG’, forest. In essence, links don’t exist in actuality; rather they are artifacts of the routing topology. So in essence, need to separate physical and logical routing - HYDRO (Stephen Dawson-Haggerty) David Oran> Do you only look at unidirectional links? Arsalan Tavakoli> No, we make the assumption that layer 2 acknowledgements can help us select bidirectional links. Emmanuel> Is your Topology Report periodical? Arsalan> Yes, we bound it by the data rate. Thomas Clausen> Source routes break down with large addresses don’t they? Stephen> This is true, but we depend on compressable addresses. We also have some thoughts on how to mitigate these problems, with landmark routing and hop-by-hop options. JP> Not that addresses may not always be compressed. David Oran> When do you time out state? Stephen> We don’t. If it breaks, we just route through default routes, and depend on Border Router to install updated routes. Zach Shelby> Couple comments. Taken a really 802.15.4/6LowPAN specific approach. Fine for a first draft, but need to generalize this more in future drafts. Things such as 16-bit addresses for low power WiFi, IPv6 as general. JP> Yes the protocol is by no mean tied to 15.4. David Culler> Some of those issues cut both ways. For example, on WiFi, much bigger MTU. Zach Shelby> About source routing. Fragility of border routers. You depend on them too much. JP> On the other hand, reduce the state at the nodes. But there are many other issues such as convergence and overhead. David Culler> If your border router goes down, you’re in trouble anyway. In general, there are tradeoffs between stretch and footprint. You have to make some choices. David Oran> I’m not worried as much about the 15.4 dependence, I thought it was actually pretty loose. I would just encourage you to not just use a layer-2 mechanism because it’s there, because we have a lot of simpler layer-2 protocols. Also, in terms of scalability, need to figure out a way to be scalable to 10,000 nodes. David Culler> What are the simpler L2s that you’re thinking of? David Oran> I want to run IP directly over a layer 1 physical layer. Don’t want to deal with all the bloat in L2. -- Trickle (Phil Levis) David Oran> What about if you have a node with a faulty receiver? Phil> Well, it will just keep broadcasting once a period, until it reaches t{h}, forcing others to suppress. Charles Perkins> What protocols were you using for your reduction numbers? Phil> Distance-vector algorithms in Sensor Networks called CTP and MintRoute. Pascal> Do you have something that shows what happens when you have a Trickle based network, when some nodes don’t obey Trickle? Phil> So you will have times when they suppress you, and other times when you both transmit. You will never suppress them. David Culler> To clear up something, that energy cost is not just transmission, but the combination of transmission and reception, so energy cost must be measured accurately. Pascal> My question: is it a good idea to mandate a network to all run Trickle? Phil> Well, if you don’t have it, then you just have a network with fixed beaconing, which will work, but just won’t be optimal. If all run Trickle, will have more consistent state across the network. Emmanuel> You intend to use Trickle for routing? David Culler> Its already used. Often times use it for dissemination, DHCP, Router Advertisements, Topology Reports, etc.