1 / 43

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

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. Some Background. Wireless sensor networks.

ophira
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related