1. Slide #1IETF 75 – Roll WG – July 2009 RPL (pronounced ripple) Routing Protocol for Low Power and Lossy Networks IETF 75 status draft-dt-roll-rpl-01.txt Anders Brandt Thomas Heide Clausen Stephen Dawson-Haggerty Jonathan W. Hui Kris Pister Pascal Thubert Tim Winter

2. Slide #2IETF 75 – Roll WG – July 2009 Some Background

3. Wireless sensor networks Distance Vector is widely used –trade off between capabilities and resources Improvements proposed –trickle –loop detection –dominating set election Reduced states in nodes (vs. Link State) Simplicity => more control cost over time Slide #3IETF 75 – Roll WG – July 2009

4. Wireless sensor networks (2) Multipath is a requirement –Use DAGs as opposed to shortest path trees –Enable (re)route around loss/interference –A MUST in many requirement drafts Routing along the DAG for –P2MP, MP2P –scarce P2P flows (though sub-optimal) Can be augmented with other mechanisms for further P2P optimization Slide #4IETF 75 – Roll WG – July 2009

5. Wireless sensor networks (3) Expected Transmission Count –is a measure of the quality of a path between two nodes in a wireless packet data network –A lot more relevant than hop count in wireless Wikipedia: “ETX is the number of expected transmissions of a packet necessary for it to be received without error at its destination. This number varies from one to infinity. An ETX of one indicates a perfect transmission medium, where an ETX of infinity represents a completely non-functional link. Because ETX is an expected transmission count for a future event, as opposed to an actual count of a past event, it represents a probability, and is therefore a real number, and not an integer. For example, if it took 1898 transmissions to transfer 1024 packets without error, the ETX on the link is 1898/1024, or approximately 1.85. Due to varying characteristics of the transmission medium, the number may vary widely.” Slide #5IETF 75 – Roll WG – July 2009

6. Wireless sensor networks (4) Loop detection –Packets received from a node that is on the way to the destination cause routing control Trickle (adaptive adv period + suppression) –Limits the degradations due to density Explicit link evaluation –Prior to selecting a parent as feasible Slide #6IETF 75 – Roll WG – July 2009

7. Non Wireless LLNs Powerline (PLC) –Also lossy –Constraints in size and bandwidth –High Burst Error Rate Slide #7IETF 75 – Roll WG – July 2009

8. DV protocol in IP Networks RIP –Unfit for large, unstable & complex topologies –Sync effect, transient loops, count to infinity –Partial fixes by split horizon (poison reverse) More recent protocols –Trade RIP’s loops for temporary black holes –Path hold-down then route poisoning –Quarantine path for which hop counts goes up Slide #8IETF 75 – Roll WG – July 2009

9. DV protocol in IP Networks (2) Distance Increase Condition (as proven by Jaffe and Moss) –One cannot create a loop by adopting a lower cost path upon a decrease information or the lowest path cost ever at any time Current Successor or Source Node cond. (as proven by Garcia-Luna-Aceves) –One cannot create a loop by adopting a next hop that’s nearer than either the current next hop or self ever was. Slide #9IETF 75 – Roll WG – July 2009

10. DV protocol in IP Networks (3) In short, it is safe to pick a shortest path upon a neighbor distance decrease or if that yields the shortest path ever for either self or a next hop. This translates into picking a parent that’s shallower then self ever was is safe whereas picking a parent that’s deeper is not safe. Question is how to restart ever Slide #10IETF 75 – Roll WG – July 2009

11. DV protocol in IP Networks (4) DUAL (J.J. Garcia-Luna-Aceves) –Always adopt and announce a lower cost path –Ignore cost increase from non next hop –If increase from next hop, recompute next hop –A neighbor closer than self is a feasible next –If any, adopt and announce the resulting path –Else engage diffusion and freeze the routing table. This happens recursively in subgraph. –Unfreeze and respond when all neighbors did. Slide #11IETF 75 – Roll WG – July 2009

12. Slide #12IETF 75 – Roll WG – July 2009 Illusions

13. The link model LLN connectivity might not match the traditional wired link model –Links are not a given. –Statistical connectivity might cause transient unreachability from/to a rather good neighbor –and might enable to receive a packet from far far away from an improbable neighbor –Not a RPL specific issue but a LLN issue that ROLL needs to consider Slide #13IETF 75 – Roll WG – July 2009

14. One scalar metric fits it all Parent selection is a case specific logic –Different objectives for different networks –E.g. compare battery (levels?) then compare RSSI then ETX then bandwidth (available?)… That Objective Function accounts for –statistical information (ETX, use, loss) –boolean information (battery operated) –physical information (max bandwidth) –configuration (preference, security level…) Slide #14IETF 75 – Roll WG – July 2009

15. The perfect DAG Since there no perfect wires with constant properties there’s hardly a perfect DAG Conditions change, batteries deplete Need to arbiter between conflicting metrics and goals Build a structure that is satisfactory for all Maintain with probably a slow evolution Slide #15IETF 75 – Roll WG – July 2009

16. Predictable routing behavior The characteristics of the network, including the metrics, are unpredictable. What we really want is that every node gets an acceptable result most of the time. There are many ways in which acceptable can be arranged (for some time). We do not look for the illusory “perfect DAG” so we could reach any of a large number of acceptable solutions. Slide #16IETF 75 – Roll WG – July 2009

17. Slide #17IETF 75 – Roll WG – July 2009 New concepts

18. The DAG ID The network is split is drainage systems identified by DAG ID. This enables to limit the consequences of a sink loss Also enables to mark a frozen subgraph The protocol enables a smooth DAG split and merge using the Dag hop timer Slide #18IETF 75 – Roll WG – July 2009

19. The Objective Function Varies per use case. –The idea is to specify a few ones –Will move to metrics draft if this is adopted –Let SDOs and suppliers define alternates RA-DIO {{Metrics}, Objective Function, Depth computation} –OFs should prefer a matching DAG. –Loop avoidance is generic based on “depth” IN: information from potential parents OUT: “depth metric”, preferred parent list Slide #19IETF 75 – Roll WG – July 2009

20. The abstract “depth” metric Stable and Scalar for simple comparison Strictly monotonous to orient the parent links and sort out siblings Universal thus very abstract Coarse grained to enable multiple parents and siblings Constrained in range to count rapidly to infinity if that can happen in the protocol Slide #20IETF 75 – Roll WG – July 2009

21. Slide #21IETF 75 – Roll WG – July 2009 FAQ

22. Loop avoidance vs. detection RPL can not afford the extra cost of ack and/or Reliable Multicast. Because of radio conditions, nodes might be temporarily unreachable anyway So the choice is this: positive assurance of a new path OR reactive loop detection We need both if the positive assurance is optionally executed. Slide #22IETF 75 – Roll WG – July 2009

23. Say we loose D->B D does not have a parent anymore If D could move deeper it might select I and be lucky Or it might select H and create a loop D->H->F->D Remember the distance increase condition: only reducing the depth is safe Slide #23 IETF 75 – Roll WG – July 2009 Why not reattach deeper? 1 3 2 1 1 11 1 4 1 1 11 1 A LBR-1 GH F 7 E BC D I 2 3 3

24. Say we loose D->B D can not reattach deeper But it can attach to a different tree Remember the DUAL freezing: we need to identify which nodes are impacted and cut them off That’s when “ever” starts in the “shortest path ever” Slide #24 IETF 75 – Roll WG – July 2009 What is that detaching business? 1 3 2 1 1 11 1 4 1 1 11 1 A LBR-1 GH F 7 E BC D I 2 3 3

25. Say we loose D->B Then D detaches and we want to reattach Without DHT, F would attach to A and maybe even H to F. Then F would have to move to D and H to I, causing churn in the sub-DAG. DHT makes D jump first because it ends up shallower, then H and F, then G Slide #25 IETF 75 – Roll WG – July 2009 What is the DAG Hop Timer for? 1 3 2 1 1 11 1 4 1 1 11 1 A LBR-1 GH F 7 E BC D I 2 3 3

26. Split horizon in RIP prevents a one hop feedback loop by not advertizing a destination to a corresponding next hop This draft prevents all RADIO feedback loops by forcing all nodes to ignore RADIOs from deeper FOR STABILITY. All nodes look towards the sink and are not impacted by changes in their back. Slide #26IETF 75 – Roll WG – July 2009 Why Ignore RAs from deeper? 1 1 1 G H F Depth n Depth n+1 1 1 G Depth n+2 1 H 1 Depth n+3

27. Slide #27IETF 75 – Roll WG – July 2009 Open issues

28. Carrying IPv6 Addresses High communication overhead –Carried in DIO, DAO, source routes High state overhead –Maintain destination routing state Options for compressing –Use a new namespace (e.g. labels) –Compress IPv6 addresses

29. In a pure DAG, H can select G as parent and set depth to n+2  Thus depriving G from an alternate Or H can select F as preferred parent and set depth to n+1  Thus wasting the G H link In sibling mode, H selects F as parent and sets depth to n+1  The G H connectivity can be used both ways and loops must be avoided on a per packet basis Slide #29IETF 75 – Roll WG – July 2009 Pure DAG vs. Sibling F Depth n 1 G Depth n+1 1 H 1 Depth n+2

30. Sibling loops Right now the loop avoidance is simple –Do not pass a packet back –Always prefer a parent vs. a sibling –But that does not fix triangular loops Proposals: –Use a more aggressive TTL decrease on sibling hops. –Do not pass to sibling if from sibling Slide #30IETF 75 – Roll WG – July 2009

31. RA-DIO loss Might cause a child to ignore that a parent has detached Might end up in a loop unless a positive assurance of a loop free path –Proposal in the draft: a sequence number –Alt: test the path (probe sink via candidate) Also possible: a reliable multicast for RAs Note: EIGRP acks update as and queries Slide #31IETF 75 – Roll WG – July 2009

32. Binding to Neighboring protocol RPL binds to IPv6 ND for a number of reasons: –It’s there –It’s reactive to traffic Potential for other bindings –Hello, NHDP … –Thomas to propose a more generic view though ND still preferred for reasons above Slide #32IETF 75 – Roll WG – July 2009

33. Depth incremement Right now it’s 1 per hop by default Though under OF discretion Proposal: –allow.25 to 4 by.25 increments to enable to qualify better each hop. –IOW the default increment is 4, expressed in ¼ of an average hop –And the maximum increment is 16 Slide #33IETF 75 – Roll WG – July 2009

34. What is infinity? Proposal: let the root decide what infinity is and pass it in DIO A router can not act as a router if is deeper than infinity Slide #34IETF 75 – Roll WG – July 2009

35. Objective Code point zero That’ s the default Objective function To which node default when they can node serve the required one Also a reference to all for depth increment Proposal: –define it in the draft –Have IANA administer code points –Std, exp, mil and private ranges Slide #35IETF 75 – Roll WG – July 2009

36. Formation of a delta Need to synchronize the sinks More text needed to explain that In particular for the 6LoWPAN backbone. Slide #36IETF 75 – Roll WG – July 2009

37. Multiple DAGs Which ones should a node join? Constrained by resources OF decision  might require OF specific suboptions Multi-Topology Routing is discussed But tagging is still TBD Slide #37IETF 75 – Roll WG – July 2009

38. ND options DIOs cause RAs on certain events that might be undesirable per RFC 4861 Is RA the right method? Similarily should DAO be NA option or hop by hop? –or both? Slide #38IETF 75 – Roll WG – July 2009

39. Unidirectional links With ND bindings, they can not be used Future work? Slide #39IETF 75 – Roll WG – July 2009

40. Route Aggregation DAOs can be aggregated But there’s complexities involved –If multiple aggregators –If aggregated nodes are not all in subDAG Slide #40IETF 75 – Roll WG – July 2009

41. Slide #41IETF 75 – Roll WG – July 2009 -END-

42. Slide #42IETF 75 – Roll WG – July 2009 backup

43. The perfect routing protocol The shortest path “perfection” yield to highly used avenues and unused alternate links. –avenues deplete the batteries on the best path rapidly and induce congestions. The shortcomings must be addressed manually by a traffic engineering. –manual interventions are antagonistic to one of ROLL’s main goals, that is autonomy. Slide #43IETF 75 – Roll WG – July 2009