RPL (pronounced ripple) Routing Protocol for Low Power and Lossy Networks IETF 75 status

1. RPL (pronounced ripple)Routing Protocol for Low Power and Lossy NetworksIETF 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 IETF 75 – Roll WG – July 2009

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

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 IETF 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 IETF 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.” IETF 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 IETF 75 – Roll WG – July 2009

7. Non Wireless LLNs • Powerline (PLC) • Also lossy • Constraints in size and bandwidth • High Burst Error Rate IETF 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 IETF 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. IETF 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 IETF 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. IETF 75 – Roll WG – July 2009

12. Illusions IETF 75 – Roll WG – July 2009

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 IETF 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…) IETF 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 IETF 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. IETF 75 – Roll WG – July 2009

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

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 IETF 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 IETF 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 IETF 75 – Roll WG – July 2009

21. FAQ IETF 75 – Roll WG – July 2009

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. IETF 75 – Roll WG – July 2009

23. Why not reattach deeper? • 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 LBR-1 1 2 3 A 1 B 1 C 1 1 1 7 F 1 D E 4 2 1 1 1 3 3 1 G H I IETF 75 – Roll WG – July 2009

24. What is that detaching business? • 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” LBR-1 1 2 3 A 1 B 1 C 1 1 1 7 F 1 D E 4 2 1 1 1 3 3 1 G H I IETF 75 – Roll WG – July 2009

25. What is the DAG Hop Timer for? • 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 LBR-1 1 2 3 A 1 B 1 C 1 1 1 7 F 1 D E 4 2 1 1 1 3 3 1 G H I IETF 75 – Roll WG – July 2009

26. Why Ignore RAs from deeper? • 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. F Depth n 1 1 1 H G 1 1 1 Depth n+1 Depth n+1 G 1 Depth n+2 H Depth n+3 IETF 75 – Roll WG – July 2009

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

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. Pure DAG vs. Sibling • 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 F Depth n 1 1 G 1 Depth n+1 H Depth n+2 IETF 75 – Roll WG – July 2009

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 IETF 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 IETF 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 IETF 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 IETF 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 IETF 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 IETF 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. IETF 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 IETF 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? IETF 75 – Roll WG – July 2009

39. Unidirectional links • With ND bindings, they can not be used • Future work? IETF 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 IETF 75 – Roll WG – July 2009

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

42. backup IETF 75 – Roll WG – July 2009

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. IETF 75 – Roll WG – July 2009