Rpl telecom bretagne

RPL and wireless fringe
Telecom Bretagne, Mars 2013

Pascal Thubert

1000*scale => No leak in the Internet
=> Opaque Fringe operations

Reachability => Radio

Addressing => IPv6

Density => spatial
reuse

=> Routing
Telecom Bretagne © 2012 Cisco and/or its affiliates. All rights reserved. Unclassified 2

Agenda (part 1)

The Fringe of the Internet
Radios and LLNs
IEEE 802.15.4
Mesh-Under Fringe
Route-Over Fringe
Overlay Fringe


Agenda (Part 2)

The RPL Fringe protocol
Going IP
Routing IP
Routing over Radio
RPL concepts
Applying RPL


The Fringe
of
the
Internet

BRKEWN-3012 © 2010 Cisco and/or its affiliates. All rights reserved. Unclassified 5

The routing Infrastructure today

 The Internet
Fully engineered
Hierarchical, Aggregations, ASs, Wire links
Fully distributed States
Shows limits (BGP tables, addr. depletion)

Reached adult size, mature to aging
Conceptually unchanged by IPv6

 IPv4 Intranets
Same structure as the Internet
Yet decoupled from the Internet
NAT, Socks, Proxies

First model for Internet extension


The emerging Fringe of the Internet
L2 mesh Under
A Multi-hop Public Access Points,
4 Proprietary mission specific products
3 Address the scale issue at L2/ND
2 Edge
1 L3 Route Over
Migration to IETF Protocols (RPL)
NEMO Internet of Things (IOT, M2M)
B’s Different IPv6 (6LoWPAN, SDN)
A’s
Home Home
Mobile Overlays
Fixed wired Global reachability
Infrastructure Route Projection
Network virtualization
5 MANET
Mesh 6 The Fringe DOES NOT LEAK
7
8 into the
B C Routing Infrastructure


Radios and LLNs


Wireless: the evolution trait

Cheap multipoint access
New types of devices (Internet Of Things)
New usages (X-automation, Mobile Internet)

Cheap Install
Deploying wire is slow and costly

Global Coverage
From Near Field to Satellite via 3/4G
Everywhere copper/fiber cannot reach


Low Power Lossy Network (LLN)
 LLNs comprise a large number of highly
constrained devices (smart objects)
interconnected by predominantly wireless
links of unpredictable quality
 LLNs cover a wide scope of applications
Industrial Monitoring, Building Automation,
Connected Home, Healthcare, Environmental
Monitoring, Urban Sensor Networks, Energy
Management, Asset Tracking, Refrigeration
 Several IETF working groups and Industry
Alliance addressing LLNs
IETF - CoRE, 6Lowpan, ROLL
Alliances - IP for Smart Objects Alliance (IPSO)

World’s smallest web server


Characteristics of LLNs

 LLNs operate with a hard, very small bound on state
 LLNs are optimised for saving energy in the majority of
cases
 Traffic patterns can be MP2P, P2P and P2MP flows
 Typically LLNs deployed over link layers with restricted
frame-sizes
Minimise the time a packet is enroute (in the air/on the wire)
hence the small frame size
The routing protocol for LLNs should be adapted for such
links
 LLN routing protocols must consider efficiency versus
generality
Many LLN nodes do not have resources to waste


IETF LLN Related Workgroups
Constrained Restful
Application Core Environments
Charter to provide a framework for resource-
oriented applications intended to run on
constrained IP networks.
General 6TSCH

IPv6 over Low power WPAN
Charter is to develop protocols to support IPv6
Internet 6LowPAN running over IEEE 802.15.4 low-power radio
networks.

Lightweight Implementation Guidance
IETF Ops and Mgmt Charter is to provide guidance in building
LWIG
minimal yet interoperable IP-capable devices for
the most constrained environments. .

Routing over Low Power Lossy
Routing ROLL Networks
Charter focusses on routing issues for low power
lossy networks.

Security

Reuse work done here where possible

Transport


IEEE 802.15.4

© 2012 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 13

 Initial activities focused on wearable
devices “Personal Area Networks”
 Activities have proven to be much more
diverse and varied
Data rates from Kb/s to Gb/s
Ranges from tens of metres up to a
Kilometre
Frequencies from MHz to THz
Various applications not necessarily IP
based
 Focus is on “specialty”, typically short
range,
communications
If it is wireless and not a LAN, MAN, RAN,
or WAN,
it is likely to be 802.15 (PAN)
http://www.ieee802.org/15/pub/TG4.html
 The only IEEE 802 Working Group with IEEE 802.15 WPAN™ Task Group 4
multiple MACs (TG4) Charter

© 2012 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 14

IEEE Wireless Standards
802.15.4
Amendments
802.11 Wireless WiFi
LAN 802.11a/b/g/n/ah

802.15 Personal 802.15.1 802.15.4c
Area Network Bluetooth PHY for China
IEEE 802 TSCH
LAN/MAN
802.15.2 802.15.4d
802.16 Wireless Co-existence PHY for Japan
Broadband Access
• Industrial strength
802.15.4e • Minimised listening costs
802.15.3
MAC • Improved security
High Rate WPAN
802.22 Wireless Enhancements • Improved link reliability
Regional Area Network
802.15.4 802.15.4f
Low Rate WPAN PHY for RFID • Support smart-grid networks
• Up to 1 Km transmission
• >100Kbps
802.15.5 802.15.4g • Millions of fixed endpoints
Mesh Networking Smart Utility Networks • Outdoor use
• Larger frame size
• PHY Amendment
802.15.6 Body Area TV White Space PHY • Neighborhood Area Networks
Networking 15.4 Study Group

802.15.7 Visible
Light
Communications

IEEE 802.15.4 Features
 Designed for low bandwidth, low transmit power, small frame size
More limited than other WPAN technologies such as Bluetooth
Basic packet size is 127 bytes (802.15.4g is up to 2047 bytes) (Smaller packets, less
errors)
Transmission Range varies (802.15.4g is up to 1km)

 Fully acknowledged protocol for transfer reliability

 Data rates of 851, 250, 100, 40 and 20 kbps (IEEE 802.15.4-2011 05-Sep-2011)
Frequency and coding dependent

 Two addressing modes; 16-bit short (local allocation) and 64-bit IEEE (unique
global)

 Several frequency bands (Different PHYs)
Europe 868-868.8 MHz – 3 chans , USA 902-928 MHz – 30 chans, World 2400-2483.5
MHz – 16 chans
China - 314–316 MHz, 430–434 MHz, and 779–787 MHz Japan - 920 MHz

 Security Modes: None, ACL only, Secured Mode (using AES-CCM mode)

 802.15.4e multiple modes including Time Synchronized Channel Hopping (TSCH)

802.15.4 Protocol Stack

 Specifies PHY and MAC only
 Medium Access Control Sub-Layer (MAC)
Responsible for reliable communication between two devices
Data framing and validation of RX frames
Device addressing Upper
Layers
Channel access management
(Network &
Device association/disassociation App)
Sending ACK frames

 Physical Layer (PHY) MAC Layer
Provides bit stream air transmission (MAC)
Activation/Deactivation of radio transceiver
Frequency channel tuning
Carrier sensing Physical
Received signal strength indication (RSSI) Layer
Link Quality Indicator (LQI) (PHY)
Data coding and modulation, Error correction


 Amendment to the 802.15.4-2006 MAC needed for the applications
served by
802.15.4f PHY Amendment for Active RFID
802.15.4g PHY Amendment for Smart Utility Networks
initially for Industrial applications
(such as those addressed by wiHART and the ISA100.11a standards)

 Security: support for secured ack
 Low Energy MAC extension
Coordinated Sampled Listening (CSL)

 Channel Hopping
Not built-in, subject to vendor design. Open std work started with 6TSCH

 New Frame Types
Enhanced (secure) Acknowledgement (EACK)
Enhanced Beacon and Beacon Request (EB and EBR)
Optional Information Elements (IE)

R

F R

IEEE 802.15.4 Node Types P

R F

 Full Function Device (FFD)
Can operate as a PAN co-ordinator (allocates local
addresses, gateway to other PANs)
Can communicate with any other device (FFD or RFD)
Ability to relay messages (PAN co-ordinator)

 Reduced Function Device (RFD)
Very simple device, modest resource requirements
Can only communicate with FFD
Intended for extremely simple applications


IEEE 802.15.4 Topologies
Operates at Layer 2

• Star Topology • Mesh Topology • Cluster Tree
R F R R R

F R F P R F F

P F R P

R F F F F F

• All devices R R R R
communicate to PAN
• Devices can • Higher layer protocols
co-ordinator which
communicate directly like RPL may create
uses mains power
if within range their own topology
• Other devices can be that do not follow
battery/scavenger 802.15.4 topologies
Single PAN co-ordinator exists for all topologies

The Mesh-Under Fringe


Wireless Industrial
• Better process optimization and more
accurate predictive maintenance increase
profit; 1% improvement in a refinery with a
$1.5B annual profit leads to $40k/day
($15M/yr) more profit
• Thus more and different sensors can be
justified economically, if they can be
connected
• But wire buried in conduit has a high
installation and maintenance cost, with long
lead times to change, and is difficult to
repair
• The solution: wireless sensors in non-critical
applications, designed for the industrial
environment: temperature, corrosion,
intrinsic safety, lack of power sources
(particularly when there is no wire)
• For critical control loops, use wireless
control room links with controllers located in
the field, possibly connected over local
wiring

ISA100: Wireless Systems
for Industrial Automation

ISA100.11a industrial WSN
Wireless systems for industrial automation
Process control and related applications

Leverages 802.15.4(e) + IPv6
Link Local Join process
Global Address runtime
6LoWPAN Header Compression
Yet specific routing and ND
Next: Backbone Router

ISA100.15 backhaul


The Route-Over Fringe


Swarming

! IPv6

IPv6

Mobile Router
SOS

Emergency
HotSpot IPv6

(roadside)
Mobile Router


Sensor Dust

“Sensor dust” spread over a territory
Sensors assume a fixed arbitrary
geographical distribution
Numerous sensors with limited
capabilities (battery …)
A limited number of relays (MR)
MRs run an SGP (RPL)
2 to 3 uplinks (MR with backhaul
capability)


Fleet

Global motion plus relative
mobility TLMR

Managed hierarchy over
dynamic topology
Secured uplink to base
Dark Zone coverage and
range extension (nesting)


Nested NEMO Route optimization
HA1 CN1
CN2

HA2

CN

Internet
MR1
HA

HA1: HA of MR1 VMN
HA2: HA of MR2
HA-VMN: HA of VMN
CR: Correspondent Router MR2

Couple LISP/MIP/NEMO LISP /
with global mobility with MIP /
NEMO
local meshing/routing 1
0
Clusterhead
(typically RPL) 2
1
1
2
Locator is root, routing 3
2

between device 3
2
2
identifiers 3
4 2
e.g. Home Network 3
3
Potential link 3
4

Default routing 3
5 4

Constrained routing 4


RPL (pronounced ripple)
The
Fringe
Routing
Protocol


Why IPv6 ?
Going IP


Why IP ?

Open Standards vs. proprietary
COTS* suppliers drive costs down but
Reliability, Availability and Security up

IP abstraction vs. per MAC/App
802.11, 802.15.4 (e), Sat, 3G, UWB
Keep L2 topology simple

To Infinity and Beyond… But End-to-End.
No intermediate gateway, tunnel, middle boxes & other trick

* Commercial, off-the-shelf


Which IP
version ?

The current Internet comprises
several billion devices
Smart Objects will add tens of
billions of additional devices
IPv6 is the only viable way forward IPv4 Unallocated pool exhausted March 2011 !
APNIC: May 2011; RIPE NCC: Sept 2012 (last /8)

Tens of
Things Billions
Smart Objects

Mobile 2~4 Billions
Phones & cars
Fixed 1~2 Billions
PCs & servers

Protocol Evolution
Little work on adapting IPv4 to radios
Rather adapt radios to IPv4 e.g. WIFI
infrastructure mode
« Classical » IPv6
Large, Scoped and Stateful addresses
Neighbor Discovery, RAs (L3 beacons)
SLAAC (quick and scalable)
Anycast Addresses
IPv6 evolution meets Wireless:

Mobile Routers (LISP, NEMO) (Proxy) MIPv6
6LoWPAN 6TSCH ROLL/RPL CoAP
ISA100.11a ZigBee/IP


IPv6 still lacks
 NBMA / ML subnet
IPv6 only supports P2P and transit (ethernet)
By nature, a radio network is NBMA
 L3 « VLAN »
So far only available with MPLS
Early attempts (MTR, RPL instances)
 L4/5 hints
Flow Label given away to fwd plane
 Microflows / compound flows
In WSN, a flow has multiple sources
 Local and Global IP Mobility Unification
(eg MANEMO, LISP+RPL)


Routing IP


Routing for Spatial Reuse

 Hidden terminal

 Interference domains grows faster that range
 Density => low power => multihop => routing


Proactive vs. Reactive

Aka
stateful
vs.
On-demand routing

Note: on-demand breaks
control vs. Data plane
separation


Link State vs. Distance Vector

 Aka SPF vs. Bellman-Ford
 LS requires full state and convergence
 LS can be very quiet on stable topologies
 DV hides topolical complexities and changes


Route stretch and fisheye

Optimized Routing Approach
0 (ORA) spans advertisements
for any change
Routing overhead can be
reduced if stretch is allowed:
Least Overhead Routing
Approach (LORA)
For instance Fisheye and
zone routing provide a
precise routing when closeby
and sense of direction when
afar


DAG, DODAG
In the context of routing, a 1
0
Clusterhead
Directed Acyclic Graph (DAG) is 2

formed by a collection 2
1 1
0
of vertices (nodes) and edges 3
2

(links). 3
2
2

Each edge connecting one node 3
4 2
to another (directed) in such a 3
way that it is not possible to start 3

at Node X and follow a directed 4
3

path that cycles back to Node X 5
3
(acyclic). 5

6
44 5
A Destination Oriented DAG 4

(DODAG) is a DAG that
comprises a single root node.
Here a DAG that is partitioned in
2 DODAG

SubDAG, and Fanout DAG
0
1 Clusterhead
 In Green: A’s subDAG. 2
1 1

Impacted if A’s connectivity is
2 0
2
broken 3 A
2
3 2
Domain for routing recovery 3
4 2
 In Red: B’s fanout DAG 3
3
(or reverse subDAG) 4
3

Potential SPAN on B’s DAO 5
3
5
Thus potential return paths 6
44 5
Fanout must be controlled to 4

limit intermediate states B


Routing over Radio


Dynamic topologies

No preexisting physical topology
Can be computed by a mesh under
protocol, but…
Else Routing must infer its topology

Movement
natural and unescapable
Yet difficult to predict or detect


Peer selection

Potentially Large Peer Set
Metrics (e.g. RSSI, ETX…)
Highly Variable Capabilities L3 Reachability (::/0, …)
Constraints (Power …)
Selection Per Objective


Constrained Objects

 Smart object are usually
Small & Numerous
« sensor Dust »

 Battery is critical
Deep Sleep
Limited memory
Small CPU

 Savings are REQUIRED
Control plane
Data plane (Compression)


Fuzzy links

Neither transit nor P2P
More like a changing NBMA
a new paradigm for routing

Changing metrics
(tons of them!)
(but no classical cost!)

Inefficient flooding
Self interfering

QoS and CAC


Local Routing & Mobility
Stretch vs. Control
Non Equal Cost multipath
Optimize table sizes and updates
Directed Acyclic Graphs (DAG) a MUST
Optimized Routing Approach (ORA) vs
Maybe also, Sibling routing
Least Overhead Routing Approach (LORA)
on-demand routes (reactive)

Objective Routing
Forwarding and retries
Weighted Hop Count the wrong metric
Same vs. Different next hop
Instances per constraints and metrics
Validation of the Routing plane


Global Mobility
Pervasive Access
Satellite
3/4G coverage
802.11, 802.15.4

Always Reachable
at a same identifier
Preserving connections
Or not ? (CORE*, DTN**)

Fast roaming
Within technology (L2)
Between Technologies (L3)

* Constrained RESTful Environments

** Delay-Tolerant Networking


What’s missing

 A radio abstraction
802.21, L2 triggers, OmniRAN
Roaming within and between technologies
TSCH model

 A subnet model
NBMA, interference awareness
Federation via backbone / backhaul

 Broadcast and look up optimization
Large scale
non-aggregatable
numbering and naming schemes


RPL concepts


Routing With RPL

Low Power Lossy Nets Addressed in RPL ?
Dynamic Topologies

Peer selection

Constrained Objects

Fuzzy Links

Routing, local Mobility

Global Mobility


RPL key concepts
RPL is an extensible proactive IPv6 DV protocol
Supports MP2P, P2MP and P2P
P2P reactive extension

RPL specifically designed for LLNs
Agnostic to underlying link layer technologies
(802.15.4, PLC, Low Power WiFi)

Minimum topological awareness
Data Path validation
Non-Equal Cost Multipath Fwd
Instantiation per constraints/metrics
Autonomic Subnet G/W Protocol
Optimized Diffusion over NBMA


Controlling the control … by design

Distance Vector as opposed to Link State
Knowledge of SubDAG addresses and children links
Lesser topology awareness => lesser sensitivity to change
No database Synchronization => Adapted to movement
Optimized for Edge operation
Optimized for P2MP / MP2P, stretch for arbitrary P2P
Least Overhead Routing Approach via common ancestor
Proactive as opposed to Reactive
Actually both with so-called P2P draft
Datapath validation


Datapath Validation
Control Information in Data Packets:

Instance ID
Hop-By-Hop Header Sender Rank
Direction (UP/Down)

Errors detected if:

- No route further down for packet going down
- No route for packet going down
- Rank and direction do not match


Directed Acyclic Graph for NECM

In the context of routing, a DAG is formed by a collection
of vertices (nodes) and edges (links), each edge connecting one node
to another (directed) in such a way that it is not possible to start at Node
X and follow a directed path that cycles back to Node X (acyclic).


Generic Rank-based Loop Avoidance

1) A root has a Rank of 1. A
router has a Rank that is higher
than that of its DAG parents. 4) But the Router MUST NOT move
down its DAG
2) A Router that is no more – but under controlled limits
attached to a DAG MUST poison whereby the router is allowed a
its routes, either by advertising limited excursion down
an INFINITE_RANK or by
forming a floating DAG. 5) A Router MAY jump from its
current DAG into any different
3) A Router that is already part DAG at any time and whatever
of a DAG MAY move at the Rank it reaches there,
any time in order to get closer unless it has been a member of
to the root of its current DAG the new DAG in which case rule
in order to reduce its own Rank 4) applies


DIO Base Object: forming the DODAG

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |Version Number | Rank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|0| MOP | Prf | DTSN | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+


Global versus Local Repair

 : : A new DODAG iteration
Rebuild the DAG … Then repaint the prefixes upon changes
A new Sequence number generated by the root
A router forwards to a parent or as a host over next iteration

 : find a “quick” local repair path
Only requiring local changes !
May not be optimal according to the OF
Moving UP and Jumping are cool.
Moving Down is risky: Count to Infinity Control


Objective Function

Extend the generic behavior
For a specific need / use case

Used in parent selection
Contraints
Policies Position in the DAG
Metrics

Computes the Rank increment
Based on hop metrics
Do NOT use OF0 for adhoc radios!
(OF 0 uses traditional weighted hop count)


DIO Base Object: route construction rules

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |Version Number | Rank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|0| MOP | Prf | DTSN | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+


Mode of Operation

+-----+-----------------------------------------------------+
| MOP | Description |
+-----+-----------------------------------------------------+
| 0 | No Downward routes maintained by RPL |
| 1 | Non-Storing Mode of Operation |
| 2 | Storing Mode of Operation with no multicast support |
| 3 | Storing Mode of Operation with multicast support |
| | |
| | All other values are unassigned |
+-----+-----------------------------------------------------+


DAO Base Object : route construction

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |K|D| Flags | Reserved | DAOSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID* +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+


Owned prefix routing (storing mode)

Parent is default GW, advertizes owned PIO (L bit on)
A::A RPL Router autoconfigures Addr from parent PIO
RPL Router advertises Prefix via self to parent
RPL Router also advertises children Prefix
A

C:
A::B
B::B ::/0 via B::B B:
A:
B:: connected ::/0 via A::A
B A:: connected
C:: connected A:: connected
B::D B:: via A::B
B::C B:: connected
D: C:: via A::B
C:: via B::C
C D ::/0 via B::B D:: via A::B
D:: via B::D
B:: connected
D:: connected


For Your
Subnet Routing (storing mode) Reference

Parent is default GW, propagates root PIO (L-bit off)
Parent Address in the PIO (with R bit)
A::A RPL Router autoconfigures Address from parent PIO
RPL Router advertises Address via self to parent
RPL Router also advertises children Addresses
A
C:
::/0 via A::B
A::B B:
A::B connected
A:
::/0 via A::A
A::C self
B A::A self
A::A connected
A:: ~onlink
A::B connected
A::D A::B self
A::C D: A::C via A::B
A::C connected
::/0 via A::B A::D via A::B
C D A::D connected
A::B connected A:: ~onlink
A:: ~onlink
A::D self

A:: ~onlink


Subnet Routing (non-storing mode)
Parent is default GW, propagates root PIO (L-bit off)
Parent Address in the PIO (with R bit)
A::A RPL Router autoconfigures Address from parent PIO
RPL Router advertises Address via Parent to Root
Root recursively builds a Routing Header back
A
C:
::/0 via A::B Target A::C via
A::B Transit A::B A: (root)
A::B connected

A::C self A::A self
B B:
A:: ~onlink A::B connected
::/0 via A::A
A::C A::D A::C via A::B
D: A::A connected
A::D via A::B
::/0 via A::B A::B self
C D A:: ~onlink
A::B connected A:: ~onlink

A::D self

A:: ~onlink A::D via A::B connected


For Your
Owned prefix routing (non-storing mode) Reference

Parent is default GW, advertizes owned PIO (L bit on)
RPL Router autoconfigures Address from parent PIO
A::A
RPL Router advertises Prefix via Address to Root
Root recursively builds a Routing Header back
A
C:
Target C::/ via
::/0 via B::B Transit B::C
A::B
B::B B:: connected
C:: connected A: (root)
B B:
A:: connected
::/0 via A::A
B::C B::D B:: via A::B
A:: connected
D: C:: via B::C
B:: connected
C D ::/0 via B::B D:: via B::D
B:: connected
D:: connected D::3 via B::D via A::B connected


Multicast over radio NBMA

Hidden node/terminal/station
A

B
C

D Flooding interferes with itself


Trickle:
An Optimized Diffusion
Suppression of redundant copies
Do not send copy if K copies received

Jitter for Collision Avoidance
First half is mute, second half is jittered

Exponential backoff
Double I after period I, Reset I on inconsistency


For Your
Routing Metrics in LLNs Reference

Node Metrics Link Metrics

Node State and Attributes Object Throughput Object
Purpose is to reflects node workload (CPU, Currently available throughput (Bytes per
Memory…) second)
“O” flag signals overload of resource Throughput range supported
“A” flag signal node can act as traffic
aggregator
Node Energy Object Latency
“T” flag: Node type: 0 = Mains, 1 = Battery, 2 = Can be used as a metric or constraint
Scavenger Constraint - max latency allowable on path
“I” bit: Use node type as a constraint Metric - additive metric updated along path
(include/exclude)
“E” flag: Estimated energy remaining
Hop Count Object Link Reliability
Can be used as a metric or constraint Link Quality Level Reliability (LQL)
Constraint - max number of hops that can be 0=Unknown, 1=High, 2=Medium, 3=Low
traversed Expected Transmission Count (ETX)
Metric - total number of hops traversed (Average number of TX to deliver a
packet)
Link Colour
Metric or constraint, arbitrary admin value


Applying RPL


RPL Instance
RPL Terminology Consists of one or more DODAGs sharing SAME service type
(Objective Function)
Identified by RPL INSTANCE ID

Direction Oriented DAG (DODAG)
Comprises DAG with a single root
Node DODAG
Rank = n (OF Rank > n
DODAG
configured)
Siblings

DOWN (DIO Messages)
5
UP (DAO Messages)

Rank 5
Rank decreases

Rank increases
Sub-
Towards
DODAG

4 4 5

Towards
DODAG
4 4 DODAG
Root

leafs
DODAG
parent 3
3 Sensor
3 to child
Node
“5”s 2
3 2 2
Rank < n Rank = n
1 Non-LLN 1
DODAG Root DODAG Root
Network
Identified by DODAG ID Rank is always “1”
(IPv6 Backbone)
(Node IPv6 address) (Typically an LBR - LLN
Border Router)


Example radio connecticity

At a given point of
time connectivity is
(fuzzy)

Radio link


Applying RPL
0
1 Clusterhead
2
1
1st pass (DIO) 2
1

Establishes a logical DAG topology 3
2

2
Trickle Subnet/config Info 3 2

Sets default route 3
4 2
Self forming / self healing 4
4
3
5
2nd pass (DAO)
3
paints with addresses and prefixes 6 4

Any to any reachability 5
5
But forwarding over DAG only
saturates upper links of the DAG
And does not use the full mesh properly Potential link

Link selected as parent link


Local recovery (step 1)
0
1 Clusterhead
2
1
A’s link to root fails 2
1

A loses connectivity 3
2 A
2
Either poisons or detaches a subdag 3 2

3
4 2
In black: 4
4

the potentially impacted zone 5
3

That is A’s subDAG 6 4
3

5
5

Potential link



0
1 Clusterhead
2
1
B can reparent a same Rank so 2
0

B’s subDAG is safe 2 A
3
2 B
3 1

The rest of A’s subDAG is isolated 4
3
1
4
4
2
Either poison ar build a floating 5

DAG as illustrated 2
6 4

In the floating DAG A is root
5
5
The structure is preserved

Potential link



0
1 Clusterhead
2
1
Once poisined nodes are 2
2

identified 2 A
3
2
It is possible for A to reparent safely 3 3

A’s descendants inherit from Rank 3
4 3
shift 4
4
Note: a depth dependent timer can
4
help order things 5

4
6 4

5
5

Potential link



Global recovery
0
1 Clusterhead
3
1
A new DAG iteration 2
1

In Green, the new DAG progressing 3
2

2
Metrics have changed, the DAG may be 3 2
different 3
4 2
Forwarding upwards traffic from old to 4
new iteration is allowed but not the other 4

way around 5
3

3
6 4

5
5

Potential link



Multiple DODAGs within Instance
0
1 Clusterhead
A second root is available 2
1 1
(within the same instance) 2 0
2
The DAG is partitioned 3
2
3 2
1 root = 1 DODAG
3

1 Node belongs to 1 DODAG 4 2

3
(at most, per instance) 3
3
Nodes may JUMP 4

from one DODAG to the next 5
5
3

Nodes may MOVE 6
44 5

up the DODAG 4

Going Down MAY cause loops
May be done under CTI control Potential link

Link selected and oriented by DIO


Multiple Instances

0
Clusterhead
Running as Ships-in-the- 2
1

1
night 2
1

2
3
1 instance = 1 DAG 2
3 2

A DAG implements 4
3
2
constraints 3
3
3
Serving different Objective 4

Functions A 5 4
3

For different optimizations 4

Forwarding along a
DODAG (like a vlan) Potential link Constrained instance

Default instance


Simulation Results For Your
Reference

Traffic Control

Traffic Holes – Global Repair only

Routing Table
Sizes


Summary

New Radios issues: Addressed in RPL by:
Dynamic Topologies DV, ORA P2MP/MP2P, LORA P2P

Peer selection Objective Functions, Metrics

Constrained Objects Controlling the control

Fuzzy Links NECM Directed Acyclic Graphs
Trickle and Datapath validation

Routing, local Mobility Local and Global Recovery

Global Mobility N/A


Next steps…

 Reactive model (in IESG review, aka P2P RPL)
 PCE (ala TSMP/ISA100.11a/WiHART)
 DAG limitations
Sibling routing, more resilient schemes (ARCs)

 Stimulated updates (lookup)
 Asymmetrical links
 Multi-Topology routing and cascading
 A model for 802.15.4e


Conclusion

 The Internet is going through its most considerable
change since the first days
 Made possible by IPv6
But not at the core and unbeknownst to the core

 Stimulated by radio access
Enabling new devices and usages

 The change happens in the Fringe, which is in fact
a collection of virtualized fringes
L2 divide vs. L3 and L4
Home, IOT, cars, datacenters, industrial…


Rpl telecom bretagne

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (7)

Ähnlich wie Rpl telecom bretagne

Ähnlich wie Rpl telecom bretagne (20)

Rpl telecom bretagne

Hinweis der Redaktion