RPL pronounced ripple Routing Protocol for Low Power

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

RPL Status • New draft-dt-roll-rpl-01 • From DT named by chairs • Topics – – – Why Distance Vector? Why Directed Acyclic Graphs? What is the Objective Function? Why detach / merge? Why handle loops this way? Why route stretching? • Currently discussed issues Slide #2 IETF 75 – Roll WG – July 2009

Why Distance Vector? Trade-off between capabilities and resources for highly constrained devices Slide #3 IETF 75 – Roll WG – July 2009

Why Distance Vector? • Trade off between capabilities and resources for highly constrained devices • Distance Vector is widely used in WSN • Simplicity => more control cost over time • Need to handle classical DV issues • Improvements proposed – Trickle, loop detection, dominating set Slide #4 IETF 75 – Roll WG – July 2009

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

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

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

Predictable routing behavior? • Unpredictable network characteristics – variable metrics, – Unpredictable reachability • Goal: – acceptable result, – most time for most nodes • Many ways this can be arranged – None perfect – None permanent Slide #8 IETF 75 – Roll WG – July 2009

Why Directed Acyclic Graphs? DAGs enable (re)route around transient loss Slide #9 IETF 75 – Roll WG – July 2009

DAG • As opposed to trees – Enable (re)route around loss/interference – Adapt to transient changes – A MUST in requirement drafts • Route along the DAG – Adapted for P 2 MP and MP 2 P patterns – Enables P 2 P as well • Can be extended for optimum P 2 P Slide #10 IETF 75 – Roll WG – July 2009

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

What is the Objective funtion? That’s a plugin that generalizes the notion of depth Slide #12 IETF 75 – Roll WG – July 2009

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

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

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

Why detach / merge for ? Why handle loops this way? This implement advanced DV concepts (from DUAL) to avoid some loops and Count to Infinity Slide #16 IETF 75 – Roll WG – July 2009

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

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

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

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

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

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

Route stretching? Acceptable trade-off Inherent with constrained states. Slide #23 IETF 75 – Roll WG – July 2009

Non shortest path ? • Usually Very small stretch • Avoid wasting invested resoures to get the packet half way. Slide #24 IETF 75 – Roll WG – July 2009

Missed anything? • Why Distance Vector? => DV Enables decent trade off between capabilities and resources for highly constrained devices • Why Directed Acyclic Graphs => DAGs Enable (re)route around transient loss • What is the Objective Function? => That’s a plugin that generalizes the notion of depth • Why detach / merge? Why handle loops this way? => This implement advanced DV concepts (from DUAL) to avoid some loops and Count to Infinity • Why route stretching? => That’s Acceptable trade-off - Inherent with constrained states. Slide #25 IETF 75 – Roll WG – July 2009

Issues under discussion Slide #26 IETF 75 – Roll WG – July 2009

Source Routing • Needs to be supported • Needs fleshing out in the draft • Address compression Slide #27 IETF 75 – Roll WG – July 2009

Binding to Neighboring protocol • RPL binds to IPv 6 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 #28 IETF 75 – Roll WG – July 2009

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