+ All Categories
Home > Documents > Slide #1IETF 75 – Roll WG – July 2009 RPL (pronounced ripple) Routing Protocol for Low Power and...

Slide #1IETF 75 – Roll WG – July 2009 RPL (pronounced ripple) Routing Protocol for Low Power and...

Date post: 27-Mar-2015
Category:
Upload: isaiah-montgomery
View: 213 times
Download: 0 times
Share this document with a friend
Popular Tags:
29
Slide #1 IETF 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
Transcript
Page 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.

Slide #1 IETF 75 – Roll WG – July 2009

RPL (pronounced ripple)Routing Protocol for Low Power

and Lossy Networks

IETF 75 statusdraft-dt-roll-rpl-01.txt

Anders BrandtThomas Heide Clausen

Stephen Dawson-HaggertyJonathan W. Hui

Kris PisterPascal Thubert

Tim Winter

Page 2: 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.

RPL Status

• New draft 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

Page 3: 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.

Slide #3 IETF 75 – Roll WG – July 2009

Why Distance Vector?

Trade-off between capabilities and resources for highly constrained devices

Page 4: 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.

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

Page 5: 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.

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

Page 6: 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.

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

Page 7: 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.

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

Page 8: 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.

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

Page 9: 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.

Slide #9 IETF 75 – Roll WG – July 2009

Why Directed Acyclic Graphs?

DAGs enable (re)route around transient loss

Page 10: 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.

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 P2MP and MP2P patterns– Enables P2P as well

• Can be extended for optimum P2PSlide #10 IETF 75 – Roll WG – July 2009

Page 11: 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.

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

Page 12: 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.

Slide #12 IETF 75 – Roll WG – July 2009

What is the Objective funtion?

That’s a plugin that generalizes the notion of depth

Page 13: 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.

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

Page 14: 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.

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

Page 15: 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.

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

Page 16: 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.

Slide #16 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

Page 17: 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.

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

Page 18: 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.

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

Page 19: 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.

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

What is that detaching business?

1

3

2

11

11

1

4

1

1

1 1

1

A

LBR-1

G H

F

7

E

B C

D

I

23

3

Page 20: 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.

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

Why not reattach deeper?

1

3

2

11

11

1

4

1

1

1 1

1

A

LBR-1

G H

F

7

E

B C

D

I

23

3

Page 21: 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.

• Say we loose D->B

• Then D detaches and we want to reattach

• Without Dag Hop Timer, 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 #21IETF 75 – Roll WG – July 2009

What is the DAG Hop Timer for?

1

3

2

11

11

1

4

1

1

1 1

1

A

LBR-1

G H

F

7

E

B C

D

I

23

3

Page 22: 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.

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

Why Ignore RAs from deeper?

1 1

1G H

F Depth n

Depth n+1Depth n+1

1

1

G

Depth n+2

1

H

1

Depth n+3

Page 23: 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.

Slide #23 IETF 75 – Roll WG – July 2009

Route stretching?

Acceptable trade-off

Inherent with constrained states.

Page 24: 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.

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

Page 25: 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.

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

Page 26: 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.

Slide #26 IETF 75 – Roll WG – July 2009

Issues under discussion

Page 27: 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.

Source Routing

• Needs to be supported

• Needs fleshing out in the draft

• Address compression

Slide #27 IETF 75 – Roll WG – July 2009

Page 28: 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.

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

Page 29: 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.

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


Recommended