Rpl2016

1
RPL 2016
Pascal Thubert,
Telecom Bretagne
January 26th 2016

2
• The any-to-any paradigm
Art: Any pair of global addresses can reach one another
IoT: Many devices of all sorts, no hotfixes
Corridors to the cloud?
• The end-to-end paradigm
Art: Intelligence at the edge, dumb routing nodes
Infinite bandwidth to all powerful clusters?
• The best-effort paradigm
Art: Stochastic packet distribution and RED
Can we make the whole Internet deterministic?

3
Trillion devices in the Internet
The core technologies will not change
Leakless Autonomic Fringe
Leakless Route Projection
Million devices in a Subnet
New models for the subnet protocols
IPv6 ND, RPL, Service Discovery …
Fiber + Copper + Wi-Fi Backbone
Femto + 802.11 + 802.15.4 + … Access
Unhindered Mobility
Location / ID Separation (LISP, NEMO)
10’s
of K

4
Data: Capillary Wireless
Acquisition of large amounts
of live Big Data
Information: DiM/Fog to
add descriptive meta-tags,
allowing for compression
and correlation
Knowledge: Prediction
from self-learned models
and Knowledge Diffusion
Wisdom: Machine Learnt
Expertise, auto-Generating
Prescriptions and Actionable
Recommendations
(Data)
ACQUISITION
(Knowledge)
DIFFUSION
(Wisdom)
OPEN LOOP
(Information)
AGGREGATION
5G
femtocell Data in
Motion / Fog
Learning
Machines
/ Cloud
6TiSCH

5
Aka Time Sensitive Networking (TSN)
For traffic known a priori (control loops…)
Time Synchronization and Global Schedule
NP-complete optim. problem => centralized computation
Fully controlled local network

6
We are in for a change:
Basic Internet structures and expectations reconsidered
Revising classical end-to-end and any-to-any
Revising best effort to new levels of guarantees (deterministic)
New function placement, new operations
Merge at the Information layer,
Gossip at the knowledge layer
Impacts network, transport, security models

7
Agenda (part 1, IOT Networks)
Open Standards
IEEE and LLNs
IETF and 6LoWPAN
Routing
Loopless structures
Forms of Routing
Over Radios

8
Agenda (part 2, RPL)
RPL Concepts
DODAG and its maintenance
Instances and Objective Functions
RPL messages and modes
DIS and parent discovery
DIO and parent selection
DAO Storing mode and RPI
DAO Non storing mode and RH3
Data packets
Headers and Compression

9
Agenda (part 3, Putting it all together)
The backbone router
Problem
High level exchanges
Deeper dive in flows
… Conclusion ?

12
Cheap Install
Deploying wire is slow and costly
Global Coverage
From Near Field to Satellite via 3/4G
Everywhere copper/fiber cannot reach
Cheap multipoint access
New types of devices (Internet Of Things)
New usages (X-automation, Mobile Internet)

13
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

14
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

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

16
• 802.15.4u – High Rate PHY
2 Mb/s backward compatible with original 250 kb/s PHY in 2450 MHz band
• 802.15.9 – KMP (Key Management Protocol)
• 802.15.10 – L2R (Layer 2 Routing Mesh)
• 802.15.12 – Study Group for ULI project
(From Pat Kinney)

17
Expected Date of submission of draft for Sponsor Ballot: 2/2017
Projected Completion Date for Submittal to RevCom: 08/2017
Scope: This amendment defines a physical layer for IEEE Std. 802.15.4 current revision, capable
of supporting 2 Mb/s data rates, utilizing the 2400 - 2483.5 MHz band, having backwards-
compatibility to, and the same occupied bandwidth as, the present 2450 MHz O-QPSK physical
layer, and capable of simple implementation. Target range should be at least 10 meters. This
amendment defines modifications to the Medium Access Control (MAC) layer needed to support this
new physical layer.
Need: …higher data rates while supporting backward compatibility and continuing
to reduce the energy consumption of IEEE Std. 802.15.4 devices even further.
(From Pat Kinney)

18
Expected Date of submission of draft for Sponsor Ballot: 12/2017
Projected Completion Date for Submittal to RevCom: 08/2018
Scope: This standard defines an Upper Layer Interface (ULI) sublayer in the Data Link Layer
(DLL), between Layer 3 (L3) and the IEEE 802.15.4 Media Access Control (MAC) sublayer. The
ULI adapts L3 protocols and provides operational configuration including network and regulatory
(see 8.1) of the IEEE 802.15.4 MAC. Furthermore, the ULI integrates Layer 2 (L2) sub-layer
functionalities such as Key Management Protocols (KMP), L2 routing (L2R) protocols for IEEE Std.
802.15.4. Additional L2 sublayer functionalities and protocol extensions for the IEEE 802.15.4 MAC
are candidates for inclusion in the ULI (see 8.1). Finally, the ULI provides protocol differentiation to
support multiple, diverse higher layer protocols.
Purpose: This standard integrates sublayer protocols developed to support the IEEE 802.15.4
MAC and harmonize their ancillary functionality, e.g. fragmentation and protocol differentiation,
along with providing the IEEE 802.15.4 MAC and PHY configuration that is required by IEEE Std.
802.15.4.
(From Pat Kinney)

19
Need for the Project: As IEEE 802.15.4 has become widely deployed, deficiencies in IEEE Std. 802.15.4
became apparent as an expanding set of applications were addressed. Many sublayer protocols independently
developed for IEEE 802.15.4 MAC sublayer to address IEEE Std. 802.15.4 deficiencies, such as KMP, L2R,
network layer abstraction, replicated ancillary functionality, e.g. fragmentation and protocol differentiation, in an
inconsistent and often incompatible manner. The ULI is needed to harmonize the sublayer protocols and
provide necessary IEEE 802.15.4 MAC and PHY configuration to:
Enable IEEE 802.15.4 devices to support multiple diverse higher layer protocols by using the EtherType
mechanism and also fragmentation to allow longer datagrams/packets
Integrate DLL protocols that interface to the IEEE 802.15.4 MAC providing services such as Key
Management Protocol (KMP) and L2 routing (L2R)
Enhance L3 IP connectivity by providing network layer IP abstraction
Fulfill IEEE 802.15.4 MAC and PHY configuration needs for operation such as:
network configuration
configuration for regulatory requirements
channel configuration
transmit power control configuration
modulation encoding configuration
(From Pat Kinney)

Cisco Confidential© 2012 Cisco and/or its affiliates. All rights reserved. 20
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)
The only IEEE 802 Working Group with
multiple MACs
http://www.ieee802.org/15/pub/TG4.html
IEEE 802.15 WPAN™ Task Group 4
(TG4) Charter

21
Star Topology Cluster TreeMesh Topology
P
R F
F
R
R
P
F F
F
R
F
R
All devices communicate to
PAN co-ordinator which
uses mains power
Other devices can be
battery/scavenger
Single PAN co-ordinator exists for all topologies
Devices can communicate
directly if within range
F F
F
F
P
R
R
F
R
Operates at Layer 2
R
R
RR
Higher layer protocols like
RPL may create their own
topology that do not follow
802.15.4 topologies

22
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)

23
• 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
Channel access management
Device association/disassociation
Sending ACK frames
• Physical Layer (PHY)
Provides bit stream air transmission
Activation/Deactivation of radio transceiver
Frequency channel tuning
Carrier sensing
Received signal strength indication (RSSI)
Link Quality Indicator (LQI)
Data coding and modulation, Error correction
Physical Layer
(PHY)
MAC Layer
(MAC)
Upper Layers
(Network & App)

24
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
All retrofitted in new revision IEEE 802.15.4-2015
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 standard work started at IETF with 6TiSCH
New Frame Types
Enhanced (secure) Acknowledgement (EACK)
Enhanced Beacon and Beacon Request (EB and EBR)
Optional Information Elements (IE)

25
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
P
R F
F
R
R

29
Reuse work done here where possible
Application
General
Internet
Ops and Mgmt
Routing
Security
Transport
Core
6lo
ROLL
IETF LWIG
Constrained Restful Environments
Charter to provide a framework for resource-oriented applications
intended to run on constrained IP networks.
IPv6 over Networks of Resource-constrained Nodes
(succeeds 6LoWPAN)
Charter is to develop protocols to support IPv6 IoT networks.
Routing over Low Power Lossy Networks
Charter focusses on routing issues for low power lossy networks.
Lightweight Implementation Guidance
Charter is to provide guidance in building minimal yet interoperable IP-
capable devices for the most constrained environments.
6TiSCH
IPv6 over TSCH
Charter is to develop best practice and Architecture for IPv6 over
802.15.4 TSCH.

30
• Gateways vs. end-to-end principle
• Hindrance from proprietary technologies
• Vertical solutions, hard to generalize to large
scale driving costs down
=> We’re still mostly there today (eg 1552S vs. WU)
• IP to the device justifies Cisco technology near the
device
=> A powerful argument ever since

31
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 6TiSCH ROLL/RPL CoAP
ISA100.11a Thread ZigBee/IP

32
http://dunkels.com/adam/ewsn2004.pdf
http://www.eecs.harvard.edu/~mdw/course/cs263/papers/ipv6-sensys08.pdf
• No IP at all is sensors, deemed impossible, too expensive
• Proprietary WSN technologies
And then …
• IEEE 802.15.4-2003 ratified December 14, 2004
• ZigBee 2004 Specification 1.0 on June 13, 2005
And then …
• Pioneer work From Adam Dunkels, and then others:

33
• IPv6 to the end node however small
• IETF WG formed in March 2005
• Chartered for IPv6 over LoWPAN (802.15.4)
• Now closed, replaced by 6lo
• Defined:
Header Compression (HC) RFC 4944 and RFC 6282
Fragmentation and mesh header (mostly unused)
Registration-based IPv6 Neighbor Discovery (ND) RFC 6775

34
• Standards such as Zigbee(IP), ISA100.11a and WirelessHART all
define whole stacks and application profiles whereas 6LoWPAN is
(just) an adaptation layer for IP (version 6)
• ISA100.11a <= 6LoWPAN Header Compression (HC) RFC 6282
• ZigbeeIP & Thread use 6LoWPAN HC + Neighbor Discovery (ND)
• Yet 6LoWPAN marks the transition for WSN towards IP
• So the popular image is that 6LoWPAN means IP in sensors
• 6LoWPAN failed to deliver routing. ROLL WG took over with RPL

35
• Generalize to all technologies, provide generic abstraction
• 6lo now chartered to define IPv6 over IOT Links
• Current work on:
• 6lo also handles 6LoWPAN maintenance e.g. as stimulated
by 6TiSCH to improve 6LoWPAN - RPL interworking
http://tools.ietf.org/html/draft-ietf-6lo-btle
http://tools.ietf.org/html/draft-ietf-6lo-dect-ule
http://tools.ietf.org/html/draft-brandt-6man-lowpanz
http://tools.ietf.org/html/draft-popa-6lo-6loplc-ipv6-over-ieee19012-networks
http://tools.ietf.org/html/draft-hong-6lo-ipv6-over-nfc
http://tools.ietf.org/html/draft-ietf-6lo-6lobac
http://tools.ietf.org/html/draft-delcarpio-6lo-wlanah
http://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer
Bluetooth Low Energy
DECT Ultra Low Energy
Zwave
PLC
Near Field Comms
BACNET
802.11ah
802.15.4e TSCH

36
• 6TiSCH also specifies an IPv6-over-foo for 802.15.4e TSCH
but does not update 6LoWPAN (that’s pushed to 6lo).
Rather 6TiSCH defines the missing Data Link Layer.
• The 6TiSCH architecture defines the global Layer-3 operation.
• It incorporates 6LoWPAN but also RPL, DetNet (PCE), COMAN,
SACM, CoAP, DICE …
=> Mostly NOT specific to 802.15.4e but for the deterministic tracks
• Thus 6TiSCH has to make those components work together
E.g. of work being pushed to other WGs:
https://tools.ietf.org/html/draft-ietf-6lo-routing-dispatch
https://tools.ietf.org/html/draft-ietf-6lo-backbone-router

37
TimeFrame 802.15.4 Other IoT links
< 2004 Non IP (zigbee…) Non IP (BACNet, Zwave…)
< 2011 IPv6 via 6LoWPAN HC Non IP
< 2013 6LoWPAN HC + 6LoWPAN ND IPv6 via 6LoWPAN HC (ongoing)
< 2016 6LoWPAN + RPL stack ( that’s 6TiSCH ! ) 6LoWPAN HC + ND
< 2020 6LoWPAN + RPL stack (that will be 6IoT, generalizing 6TiSCH stack on all LLN links)
< 2022 Deterministic capabilities, Call Admission control and Traffic Engineering
Notes:
• In draft-thubert-6lo-rfc6775-update-reqs we claim that Low Power Wi-Fi is an LLN link
• The 6IoT architecture generalized from 6TiSCH architecture to apply on Wi-Fi ad-hoc mode as well

38
Preamble SPD
PHY
Header
Auxiliary
Security
Header
Payload FCS
Frame
Control
Data
Seq.
Nbr
Addressing
Simple MAC allows coexistence with other network protocols over same link, similar to Ethernet, although not seen
in deployment
IEs
Header &
Payload
DST
PAN ID
Mesh
Address
6LoWPAN
Compressed Hdr
Payload
DST MAC
Address
SRC
PAN ID
SRC MAC
Address
DSP
X00
10
01
11
Not a LoWPAN frame
LoWPAN IPv6 addressing Hdr
LoWPAN mesh Hdr
LoWPAN fragmentation Hdr
Frag.
6LoWPAN
Compressed Hdr
Payload
Frag.
6LoWPAN
Compressed Hdr
Payload
DSP + IPHC
Other 6LoWPAN
Hdr field
Payload
Header Dispatch (DSP) – understand
what is coming
Mesh
AddressMesh + Fragmentation
Frame Fragmentation
Mesh (L2 Routing)
6LoWPAN

39 3
0 1 1 HLIM SAM DAM
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
10
TF 2 bits Traffic Class and Flow Label
NH 1 bit Next Header
HLIM 2 bits Hop Limit
CID 1 bit Context Identifier Extension
SAC 1 bit Source Address Context
SAM 2 bits Source Address Mode
M 1 bit Multicast Address Compression
DAC 1 bit Destination Address Context
DAM 2 bits Destination Address Mode
CIDTF NH SAC M DAC
Addressing

40
6LR 6LBRLP Node
NS (ARO)
DAR (ARO)
SRC = 6LR
DST = 6LBR
REG = LPN
UID = LPN
SRC = LPN_ll
DST = 6LR_ll
TGT = ??
SLLA = LPN
UID = LPN
Check Collision
of binding state
(DAD)
NA (ARO, s=1)
DAC (ARO, s=0,1==dup)
SRC = 6LR
DST = 6LBR
REG = LPN
UID = LPN
SRC = 6LR_ll
DST = LPN_ll
TGT = LPN
TLLA = LPN
UID = LPN
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 2 | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EUI-64 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A registration mechanism
For duplicate detection
Goal to save multicast
Address Registration Option
Radio
Mesh
Radio 1 Hop

41
Scalable and Multi-Link
Deterministic e2e
IP guard (admin knows what’s where)
=> Authoritative Registrar(s)
Backbone Routers
RPL root, ND proxy
Legacy IPv6 devices
Authoritative
Registrar
Authoritative
Registrar / 6LBR
Intermediate
Registrar / 6LR
Intermediate Registrar
option. ND proxy
Backbone router
(ND proxy)

42
6LoWPAN is an open standard, NOT a silo’ed solution
6LoWPAN is how you do IPv6 over low power networks
Provides an Adaptation Layer and a novel IPv6 Neighbor Discovery
6LoWPAN started small with the 802.15.4-2003 WPAN
Updated under Cisco lead to fit in ISA100.11a
Now generalizing on all LLN technologies with IETF 6lo GW

44
Most classical routing structure
Typically what Internet Gateway Protocols
(IGPs) Build or each reachable destination
Only thing Link State builds, though
Distance Vector has feasible successors
Must be reconstructed upon connectivity
loss, service is interrupted
FRR techniques must be added (MRT, LFA
with SR …) on top
No inner load balancing capabilities
Walkable structure (e.g. depth first)
ROOT
5
4
4
0
1
3
1 1
2
2
2
2
23
3
3
3
3
2
4
4
5
0
6
5
4
ROOT

45
In the context of routing, a Directed Acyclic
Graph (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).
Greedy => Not all nodes have 2 solutions
even in biconnected networks
A Destination Oriented DAG (DODAG) is a
DAG that comprises a single root node.
Here a DAG that is partitioned in 2 DODAG
Clusterhead
5
4
4
0
1
3
1 1
2
2
2
2
2
3
3
3
3
3
3
2
4
4
5
0
6
5
4

46
• In Green: A’s subDAG.
Impacted if A’s connectivity is
broken
Domain for routing recovery
• In Red: B’s fanout DAG
(or reverse subDAG)
Potential SPAN on B’s DAO
Thus potential return paths
Fanout must be controlled to
limit intermediate states
Clusterhead
5
4
4
0
1
3
1 1
2
2
2
2
2
3
3
3
3
3
3
2
4
4
5
0
6
5
4
A
B

47
Clusterhead
5
Clusterhead
0
1
1
1
2
2
2
2
2
3
3
3
3
3
3
2
3
5
4
4
4
4
e.g. ARC of siblings
Allows more alternates
ARCs and walkable structures in
general are walked with no routing
progress
Routing between DAGs of ARCs
Forwarding over DAG AND ARCs
Reduces congestions of upper links of
the DAG
Still LORA for P2P
IGP subarea (bidirectional)
Link selected and oriented by TD
Potential link

49
• Hidden terminal
• Interference domains grows faster that range
• Density => low power => multihop => routing

50
Aka
Stateful vs.
On-demand routing
Note: on-demand breaks control vs. Data plane separation
P2P-RPL
RIP
IS-IS

51
Aka Dijkstra vs. Bellman-Ford
LS requires full state and convergence
Every node draws a same graph
Then run teh shortest path first algorithm to get to all other nodes
Then associates node with reachable destinations
LS can be very quiet on stable topologies
DV learns costs to destination asynchronously per destination
Nodes advertise their distance to a destination
Recursively other nodes learn their best successor
and compute their own cost
DV hides topolical complexities and changes
RIP
IS-IS

52
0
Optimized Routing Approach (ORA) spans
advertisements for any change
Routing overhead can be reduced if
stretch is allowed: Least Overhead
Routing Approach (LORA)
=> (Nothing to do with the LoRa LPWA
protocol !!!)
For instance Fisheye and zone routing
provide a precise routing when closeby
and sense of direction when afar

54
1000*scale => No leak in Internet
=> Opaque operations
Reachability => Radio (IEEE)
Addressing => IPv6 (IETF)
Density => spatial reuse
=> Routing

55
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

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

57
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)

58
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
Quality of Service ?
Call Admission Control => TSCH

59
Stretch vs. Control
Optimize table sizes and updates
Optimized Routing Approach (ORA) vs
Least Overhead Routing Approach (LORA)
on-demand routes (reactive)
Forwarding and retries
Same vs. Different next hop
Validation of the Routing plane
Non Equal Cost multipath
Directed Acyclic Graphs (DAG) a MUST
Maybe also, Sibling routing
Objective Routing
Weighted Hop Count the wrong metric
Instances per constraints and metrics

60
Pervasive Access
Satellite
3/4G coverage
802.11, 802.15.4
Always Reachable
at a same identifier (MIPv6, LISP*…)
Preserving connections
Or not ? (REST**, DTN***)
Fast roaming
Within technology (L2)
Between Technologies (L3)
* Locator/Identifier Separation Protocol
** Representational state transfer
*** Delay-Tolerant Networking

61
A radio abstraction
802.21, L2 triggers, OmniRAN
Roaming within and between
technologies
Deterministic Properties
A subnet model for IPv6
NBMA, interference awareness
Federation via backbone / backhaul
Broadcast and look up optimization
Large scale
non-aggregatable
numbering and naming schemes

62
RPL (RFC 6550 and then more)

63
Dynamic Topologies
Peer selection
Constrained Objects
Fuzzy Links
Routing, local Mobility
Global Mobility
Low Power Lossy Networks Issues Addressed
in RPL ?

64
Minimum topological awareness
Data Path validation
Non-Equal Cost Multipath Fwd
Instantiation per constraints/metrics
Autonomic Subnet G/W Protocol
Optimized Diffusion over NBMA
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)

65
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

67
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).

68
5
3
5
4
RPL Instance
Consists of one or more DODAGs sharing SAME service type
(Objective Function)
Identified by RPL INSTANCE ID
UP(DAOMessages)
DODAG Root
Identified by DODAG ID
(Node IPv6 address)
Direction Oriented DAG (DODAG)
Comprises DAG with a single root
Rank
Towards
DODAG
Root
Rank = n
Rank < n
Node
(OF
configured)
2
1
5
4
3
3
Rankdecreases
DODAG
parent
to child
“5”s
2
DODAG Root
Rank is always “1”
(Typically an LBR - LLN
Border Router)
1
3
2
Sub-
DODAG
DODAG
DOWN(DIOMessages)
Towards
DODAG
leafs
Rank > n
Rank = n
Rankincreases
Non-LLN
Network
(IPv6 Backbone)
Siblings
44
DODAG
Sensor
Node

69
At a given point of
time connectivity is
as illustrated and
rather fuzzy
Radio link

70
Clusterhead
1st pass (DIO)
Establishes a logical DAG topology
Trickle Subnet/config Info
Sets default route
Self forming / self healing
2nd pass (DAO)
paints with addresses and prefixes
Any to any reachability
But forwarding over DAG only
saturates upper links of the DAG
And does not use the full mesh
properly Link selected as parent link
Potential link
Clusterhead
0
1
1
1
4
4
4
46
3
3
3
3
3
2
2
2
2
2
2
5
5
5

71
: : 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

72
Clusterhead
A’s link to root fails
A loses connectivity
Either poisons or detaches a subdag
In black:
the potentially impacted
zone
That is A’s subDAG
Link selected as parent link
Potential link
Clusterhead
0
1
1
1
4
4
4
46
3
3
3
3
3
2
2
2
2
2
2
5
5
5
A
1
1
1
3
3
3
3
3
2
2
2
2
2
2
5
5
5
4
4
4
4

73
Clusterhead
B can reparent a same
Rank so B’s subDAG is safe
The rest of A’s subDAG is
isolated
Either poison ar build a
floating DAG as illustrated
In the floating DAG A is root
The structure is preserved
Potential link
Clusterhead
0
1
1
4
4
4
46
3
3
3
2
2
2
2
2
2
1
5
5
5
A
B
0
1

74
Clusterhead
Once poisined nodes are
identified
It is possible for A to reparent
safely
A’s descendants inherit from Rank
shift
Note: a depth dependent timer
can help order things
Potential link
Clusterhead
0
1
1
2
4
4
4
46
3
3
3
4
4
2
2
2
2
3
3
5
5
5
A

75
Clusterhead
A new DAG iteration
In Green, the new DAG
progressing
Metrics have changed, the DAG
may be different
Forwarding upwards traffic
from old to new iteration is
allowed but not the other way
around
Potential link
Clusterhead
0
1
1
1
4
4
4
46
3
3
3
3
3
3
2
2
2
2
2
5
5
5

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

78
RPL is objective driven
e.g. reach a certain gateway, concept of a goal
Instances are built to reach certain goals
Instance ID tagged in packets
RPL is generic and extensible
RFC 6550 is a core distance vector functionality
Objective functions plug in to adapt to use case / need
Objective functions enforce policies

79
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)

80
Clusterhead
5
4
4
A second root is available
(within the same instance)
The DAG is partitioned
1 root = 1 DODAG
1 Node belongs to 1 DODAG
(at most, per instance)
Nodes may JUMP
from one DODAG to the next
Nodes may MOVE
up the DODAG
Going Down MAY cause loops
May be done under CTI control
Link selected and oriented by DIO
Potential link
0
1
3
1 1
2
2
2
2
2
3
3
3
3
3
3
2
4
4
5
0
6
5
4

81
Running as Ships-in-the-night
1 instance = 1 DAG = 1 OF
A DAG implements a set of
constraints
Multiple instances may be serving
different Objective Functions
=> For different optimizations
Forwarding is along a DODAG
=> Provides isolation like a vlan
Clusterhead
0
1
1
1
2
2
2
2
2
3
3
3
3
3
3
2
3
5
4
4
4
4
Clusterhead
Constrained instance
Default instance
Potential link
A

83
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICMP Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Base Object .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Option(s) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x00 (DIS) DODAG
Information Solicitation
0x01 (DIO) DODAG
Information Object
0x02 (DAO) Destination
Advertisement Object
0x03 (DAO-ACK) Destination
Advertisement Object
Acknowledgment
155 == RPL control message

85
Flooding interferes with itself
B
C
D
A
Hidden node/terminal/station

86
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

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

88
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)...
+-+-+-+-+-+-+-+-+

89
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)...
+-+-+-+-+-+-+-+-+

90
+-----+-----------------------------------------------------+
| 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 |
+-----+-----------------------------------------------------+

92
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | Option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: The DIS Base Object
Options:
0x00 Pad1
0x01 PadN
0x07 Solicited Information
Goal: ask routers around to generate DIO

93
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x07 |Opt Length = 19| RPLInstanceID |V|I|D| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version Number |
+-+-+-+-+-+-+-+-+

94
draft-zhong-roll-dis-modifications
Based on earlier work draft-goyal-roll-dis-modifications
New Flags to control
Trickle behavior
response mode Unicast vs. Broadcast
Metric Container
for constraints on the responder
Response Spreading Option
to spread responses over an interval

96
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)...
+-+-+-+-+-+-+-+-+

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

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

99
Control Information in Data Packets:
RPI in IPv6 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

100
Down 'O': 1-bit flag indicating whether the packet is expected to progress Up or Down. A router sets the 'O' flag when the
packet is expected to progress Down (using DAO routes), and clears it when forwarding toward the DODAG root (to a
node with a lower Rank). A host or RPL leaf node MUST set the 'O' flag to 0.
Rank-Error 'R': 1-bit flag indicating whether a Rank error was detected. A Rank error is detected when there is a mismatch in
the relative Ranks and the direction as indicated in the 'O‘ bit. A host or RPL leaf node MUST set the 'R' bit to 0.
Forwarding-Error 'F': 1-bit flag indicating that this node cannot forward the packet further towards the destination. The 'F'
bit might be set by a child node that does not have a route to destination for a packet with the Down 'O' bit set. A host or
RPL leaf node MUST set the 'F' bit to 0.
RPLInstanceID: 8-bit field indicating the DODAG instance along which the packet is sent.
SenderRank: 16-bit field set to zero by the source and to DAGRank(rank) by a router that forwards inside the RPL network.
Encoding: RFC 6553 then 6LoRH
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|R|F|0|0|0|0|0| RPLInstanceID | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-TLVs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

101
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+
|1|0|0|O|R|F|I|K| 6LoRH Type=5 | Compressed fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|O|R|F|1|1| 6LoRH Type=5 | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|O|R|F|1|0| 6LoRH Type=5 | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|O|R|F|0|1| 6LoRH Type=5 | RPLInstanceID | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|O|R|F|0|0| 6LoRH Type=5 | RPLInstanceID | Sender-...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

103
+- ... -+- ... -+-+-+-+- ... +-+-+-+-+-+-+-+-+-+- ... +-+-+-+-+-+...
|11110001| RPI-6LoRH | NH = 1 |11110|C| P | Compressed | UDP
|Page 1 | type 5 | 6LOWPAN-IPHC | UDP | | | UDP header |Payload
+- ... -+- ... -+-+-+-+- ... +-+-+-+-+-+-+-+-+-+- ... +-+-+-+-+-+...
<- RFC 6282 ->
IPv6 header HbH header UDP header UDP PayloadRPL option
<=>

105
A
B
C D
Parent is default GW, propagates root PIO (L-bit off)
Parent Address in the PIO (with R bit)
RPL Router advertises Address via Parent to Root
Root recursively builds a Routing Header back
B:
::/0 via A::A
A::A connected
A::B self
A:: ~onlink
C:
::/0 via A::B
A::B connected
A::C self
A:: ~onlink
D:
::/0 via A::B
A::B connected
A::D self
A:: ~onlink
Target A::C via
Transit A::BA::B
A::C A::D
A::A
A: (root)
A::A self
A::B connected
A::C via A::B
A::D via A::B
A:: ~onlink
A::D via A::B connected

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

107
Segments Left: 8-bit unsigned integer. Number of route segments remaining, i.e., number of explicitly listed
intermediate nodes still to be visited before reaching the final destination. The originator of an SRH sets this
field to n, the number of addresses contained in Addresses[1..n].
CmprI: 4-bit unsigned integer. Number of prefix octets from each segment, except than the last segment,
(i.e., segments 1 through n-1) that are elided. For example, an SRH carrying full IPv6 addresses
in Addresses[1..n-1] sets CmprI to 0.
CmprE: 4-bit unsigned integer. Number of prefix octets from the last segment (i.e., segment n) that are
elided. For example, an SRH carrying a full IPv6 address in Addresses[n] sets CmprE to 0.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CmprI | CmprE | Pad | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Addresses[1..n] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3

108
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+
|1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+
Size indicates the number of compressed addresses
+-----------+----------------------+
| 6LoRH | Length of compressed |
| Type | IPv6 address (bytes) |
+-----------+----------------------+
| 0 | 1 |
| 1 | 2 |
| 2 | 4 |
| 3 | 8 |
| 4 | 16 |
+-----------+----------------------+
Packet source is reference for compressio
Different compressed size => multiple RH3-6LoRH
Placement first in the chain to be easily consumed as
we go (address coalescence)

110
Leaving the root:
Leaving A
Leaving B
C removes the header and the IP-in-IP if nothing else in IP-in-IP
B’s suffix
RH3-6LoRH Type 4
RH3-6LoRH Type 3
IPv6 Prefix B’s suffix
C’s suffix
A’s suffixRH3-6LoRH Type 4 IPv6 Prefix C’s suffix
RH3-6LoRH Type 4
RH3-6LoRH Type 3
IPv6 Prefix
B’s suffix
A’s suffix
C’s suffix
Root = encaps B C = decaps DestA

111
•+- ... -+-+- ... -+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+...
•|11110001| RH3(128bits)| RH3(2*16bits)| RFC 6282 Dispatch
•|Page 1 | 6LoRH type 4| 6LoRH Type 1 | + LOWPAN_IPHC
•+- ... -+- ... +-+-+-+- ... -+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+...
• <- RFC 6282 ->
• +-----------+-----------+
• | Type | Size Unit |
• +-----------+-----------+
• | 0 | 1 |
• | 1 | 2 |
• | 2 | 4 |
• | 3 | 8 |
• | 4 | 16 |
• +-----------+-----------+
<=>
IPv6 header Routing header Hop Hop Dec.Hop Hdrs + Payload

112
RRRRRRRRRRRRRRRRRRRR
++ CCCCCCC
--------------------
RRRRRRRRRRRRRCCCCCCC
RR…RRRR is reference address for compression, may be compressed or not
CCC…CC is compressed address, to shorter or same size as reference
RR…RRCCC…CC is the Coalesced address, same size as reference

113
Type 3 RH3-6LoRH Size = 0 AAAA AAAA AAAA AAAA
Type 1 RH3-6LoRH Size = 0 BBBB
Type 2 RH3-6LoRH Size = 1 CCCC CCCC
DDDD DDDD
Step 1 popping BBBB the first entry of the next RH3-6LoRH
Step 2 next is if larger value (2 vs. 1) the RH3-6LoRH is removed
Type 3 RH3-6LoRH Size = 0 AAAA AAAA AAAA AAAA
DDDD DDDD
Step 3: recursion ended, coalescing BBBB with the first entry
Type 3 RH3-6LoRH Size = 0 AAAA AAAA AAAA BBBB
Step 4: routing based on next segment endpoint to B

114
DDDD DDDD
Step 1 popping CCCC CCCC, the first entry of the next RH3-6LoRH
Step 2 removing the first entry and decrementing the Size (by 1)
Type 2 RH3-6LoRH Size = 0 DDDD DDDD
Step 3: recursion ended, coalescing CCCC CCCC with the first entry
Type 3 RH3-6LoRH Size = 0 AAAA AAAA CCCC CCCC
Step 4: routing based on next segment endpoint to C

115
Type 2 RH3-6LoRH Size = 0 DDDD DDDD
Step 1 popping DDDD DDDD, the first entry of the next RH3-6LoRH
Step 2 the RH3-6LoRH is removed
Step 3: recursion ended, coalescing DDDD DDDDD with the first entry
Type 3 RH3-6LoRH Size = 0 AAAA AAAA DDDD DDDD
Step 4: routing based on next segment endpoint to D

116
Type 3 RH3-6LoRH Size = 0 AAAA AAAA DDDD DDDD
Step 1 the RH3-6LoRH is removed.
Step 2 no more header, routing based on inner IP header.

118
(Hateful stuff)
Only end points may add / remove headers
Some headers are mutable (and if they are recoverable they may be secured)
e.g. of mutable and partially recoverable is RPI (to secure the instance ID)
So IP in IP is required
If the packet leaves the RPL domain since HbH header must be removed
If the packet enters the RPL domain since HBH header or RH3 must be inserted
In non storing mode for a packet not going to or from the root (RPI to RH3
conversion at root).
https://tools.ietf.org/html/draft-robles-roll-useofrplinfo-02

119
Not a critical header, may be skipped so Length is in bytes. Placed last in the header chain (as of draft 04)
Root is reference for compressing the Encapsulator Address.
If the Length of an IP-in-IP-6LoRH header is exactly 1, then the Encapsulator Address is elided, which means that the
Encapsulator is a well-known router, in the case of RPL the root in a RPL graph.
When it cannot be elided, the destination IP address of the IP-in-IP header is transported in a RH3-6LoRH header as
the first address of the list.
With RPL, the destination address in the IP-in-IP header is implicitly the root in the RPL graph for packets going
upwards, and the destination address in the IPHC for packets going downwards. If the implicit value is correct, the
destination IP address of the IP-in-IP encapsulation can be elided.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
|1|0|1| Length | 6LoRH Type 6 | Hop Limit | Encaps. Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+

120
MAC RH3-6LoRH* RPI-6LoRH IP-in-IP-LoRH IPHC blah optimizes operation on compressed form
Reason 1: We modify the RH3-6LoRH on the way, popping the first address as we go. It is easier to do if it is the first header of
the compressed packet so we always play with the very beginning of the packet
Reason 2: So that IP header always TERMINATES the 6LoRH encapsulation,
When there is no IP in IP , this is already true for instance MAC RPI-6LoRH IPHC
One needs to differentiate a case that in UNCOMPRESSED form is
IP-in-IP RPI RH3 IP blah vs. IP-in-IP IP RPI RH3 blah
With a format like MAC IP-in-IP-LoRH RH3-6LoRH* RPI-6LoRH IPHC blah You cannot tell : (
With this format we have a clear separation for IP in IP in IP all the way
MAC RH3-6LoRH* RPI-6LoRH IP-in-IP-LoRH RH3-6LoRH* RPI-6LoRH IP-in-IP-LoRH RPI-6LoRH IPHC data
The separation of which header is in which encapsulation is clearly delineated with the IP header that terminates the
encapsulated 6LoRH-headers.
4/3/2016

121
•+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+...
•|Frag type|Frag hdr |11110001| RPI | IP-in-IP | RFC 6282 Dispatch
•|RFC 4944 |RFC 4944 | Page 1 | 6LoRH | 6LoRH | + LOWPAN_IPHC
•+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+...
• <- RFC 6282 ->
•
•+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+...
•|Frag type|Frag hdr |
•|RFC 4944 |RFC 4944 | Payload (cont)
•+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+...
•+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+...
•|Frag type|Frag hdr |
•|RFC 4944 |RFC 4944 | Payload (cont)
•+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+...
<=>
IPv6 header HbH header IPv6 header Hdrs + PayloadRPI in RPL option

122
+-+-+-+-+-+-+- ... +-+-+- ... -+-+-- ... -+-+- ... -+-+-+-+-+-+-+ ... -+-+-+-+...
|11110001 |RH3-6LoRH | RPI-6LoRH | IP-in-IP | NH=1 |11110CPP| Compressed | UDP
|Page 1 |Type1 S=2 | | 6LoRH | IPHC | UDP | UDP header | Payload
+-+-+-+-+-+-+- ... +-+-+- ... -+-+-- ... -+-+- ... -+-+-+-+-+-+-+ ... -+-+-+-+...
<-8bytes-> <- RFC 6282 ->
No RPL artifact
One may note that the RPI is provided. This is because the address of the root
that is the source of the IP-in-IP header is elided and inferred from the
InstanceID in the RPI. Once found from a local context, that address is
used as Compression Reference to expand addresses in the RH3-6LoRH.
<=>
IPv6 header UDP hdr UDP PayloadRouting hdr Hop Dec.HopHbH RPIIPv6 header

123
DV, ORA P2MP/MP2P, LORA P2P
Objective Functions, Metrics
Controlling the control
NECM Directed Acyclic Graphs
Trickle and Datapath validation
Local and Global Recovery
N/A
Dynamic Topologies
Peer selection
Constrained Objects
Fuzzy Links
Routing, local Mobility
Global Mobility
New Radios issues: Addressed in RPL by:

124
Traffic Control
Traffic Holes – Global Repair only
Routing Table
Sizes
For Your
Reference

125
• Standard track Reactive model (P2P RPL rfc6997 is experimental)
• Centralized route computation push (e.g. draft-thubert-roll-dao-projection )
• DAG limitations
Sibling routing, more resilient schemes (ARCs)
• Better / Faster (re) join (with DIS message e.g. draft-zhong-roll-dis-modifications)
• Stimulated updates (lookup) with targetted DAO
• Asymmetrical links
• Multi-Topology routing and cascading

126
• RFC 6206: The Trickle Algorithm
• RFC 6550: RPL: IPv6 Routing Protocol for LLNs
• RFC 6551: Routing Metrics Used for Path Calculation in LLNs
• RFC 6552: Objective Function Zero for the Routing Protocol for LLNs
• RFC 6553: RPL Option for Carrying RPL Information in Data-Plane Datagrams
• RFC 6554: An IPv6 Routing Header for Source Routes with RPL
• RFC 6719: MRHOF Objective Function with hysteresis
• RFC 6997: Reactive Discovery of Point-to-Point Routes in LLNs
•

127
Bringing it all together:
draft-ietf-6lo-backbone-router

129
1. IPv6 Discovery protocols use multicast flooding
Assuming a lower layer multicast support
Not just IPv6 NDP but also mDNS, etc…
2. Layer-2 destination set to 3333XXXXXXXX
3. Layer-2 fabric handles as broadcast (all nodes)
4. Broadcast clogs the wireless access at low access
speed (typically 1Mbps) on all APs around the fabric
5.Broadcast self interferes on attached wireless mesh and
drains the batteries on all nodes

130
Multiple L3
Multicast
messages
RA
Multiple L2
Broadcast
messages
1. MAC address reachability
flooded over L2 switch fabric
2. Device sends RS to all
routers link scope mcast
3. Router answers RA (u or m)
4. Device sends mcast NS DAD
to revalidate its address(es)
5. Device sends mcast NA(O)
6TISCH uses a backbone
router, limits the broadcast
domain to the backbone
VM, NFV,Wireless or IoT device moves:

131
Nbr Solicitation
L3 Multicast
L2 broadcast
Packet to Target that is
missing in router ND cache
Nbr Advertisement
Unicast
1. Router looks up ND cache (say
this is a cache miss)
2. Router sends NS multicast to
solicited-node multicast @;
here that is 3333 FF00 00A1
1. Targets answers unicast NA
2. Target revalidates ND cache for
the router, usually unicast
3. Router creates ND cache entry
6TiSCH proxies at the backbone
router on behalf of device
Packet comes in for 2001:db8::A1

132
Multicast Avoidance
Registration for DAD
Binding (location, owner, MAC) to IPv6 address
Registrar hierarchy for lookups and policy enforcement
Scalable Backbone Operation
L2 routing (IS-IS) + proxy-ND in the backboneRegistration + L3 Routing in
attached networks (RPL RFC 6550)
Optional MAC address proxying to avoid MAC@ floods
New ND methods between registrars and other devices (e.g. LISP)
IETF drafts
draft-ietf-6lo-backbone-router
draft-chakrabarti-nordmark-6man-efficient-nd
draft-thubert-6man-wind-sail

133
Scalable and Multi-Link
Deterministic e2e (DetNet)
Registration based ND
IP guard (admin knows what’s where)
=> Authoritative Registrar(s)
Backbone Routers
RPL root, ND proxy
Legacy IPv6 devices
Authoritative
Registrar
Authoritative
Registrar / 6LBR
Intermediate
Registrar / 6LR
Intermediate Registrar
option. ND proxy
Backbone router
(ND proxy)

134
6TiSCH
6TiSCHSensor
Actuator
Backbone
Router
Management
Wireless Controller
Backbone
Router
Single Multilink IPv6 Subnet with free inner mobility (same subnet == no renumbering)
Virtual Service Engine
(virtual PLC, PCE …)
+ IPv6 ND registrar
+ Network Function
Virtualization (NFV)
NAC
/Firewall
VPN Concentrator
IPv6 ND registration and proxy operation

135
Wireless Router Wireless Router
Mesh Root Mesh Root
Wireless RouterWireless Router

137
Used to resolve conflicts
Need In ND: TID to detect movement ->eARO
Need In RPL: Object Unique ID if we use RPL for DAD
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 2 | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ OUID ( EUI-64 or equivalent ) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

138
Routers within subnet have a connected route
installed over the subnet backbone.
PCE probably has a static address in which
case it also has a connected route
Connected
Route to
subnet

139
Gateway to the outside participate to some IGP
with external network and attracts all extra-
subnet traffic via protocols over the backbone
Default
Route
In RIB

140
Directly upon NS(ARO) or indirectly upon DAR
message, the backbone router performs DAD on
behalf of the wireless device.
DAR
NS
(ARO)
DADNS DAD
(ARO)

141
NA(ARO) or DAC message carry succeful
completion if DAD times out.
NA(Override) is optional to clean up ND cache
stale states, e.g. if node moved.
DAC
NA
(ARO)
Optional
NA(O)

142
The BR maintains a route to the WSN node for
the DAO Lifetime over instance VRF. VFR may
be mapped onto a VLAN on the backbone.
RPL
DAO
Host
Route
Optional
NA(O)

143
The BR maintains a route to the WSN node for
the DAO Lifetime over instance VRF that is
continued with RPL over backbone.
RPL
DAO
RPL DAO
Host
Route

144
DAD option has:
Unique ID
TID (SeqNum)
Defend with NA if:
Different OUID
Newer TID
NS DAD
(ARO)
NA (ARO)
NS
(ARO)

145
DAD option has:
Unique ID
TID (SeqNum)
Defend with NA if:
Different OUID
Newer TID
DAR
NA
(ARO)
DAD

146
RPL
DAO
Optional
NA(ARO)
Host
Route
DAD option has:
Unique ID
TID (SeqNum)
Defend with NA if:
Different OUID
Newer TID
NA (ARO) with
older TID (loses)

147
Packet
NS
lookup
NA ARO option has:
Unique ID
TID (SeqNum)
NA (ARO)

148
NS
lookup
Mixed mode ND
BBR proxying over
the backbone
NA (ARO)
Packet

150
6LR 6LBR 6BBR
Router/Serv
er
LP Node
RPL Ethernet
RA (unicast)
RA (u|mcast)
DIO
Router/Serv
er
Router/Serv
er
EthernetRadio 1 Hop
SLLA
PIO
MTU
SLLA
CONTEXT
PIO
MTU
SLLA
CONTEXT
PIO
MTU
RA (u|mcast)
RS (mcast)
PIO
RA (u|mcast)
PIO
MTU
SLLA
CONTEXT

151
6LR 6LBR 6BBR
Router/Serv
er
LP Node
Radio
Mesh
Ethernet
NA (~O)
NS (ARO)
NS (ARO)
DAR, RPL DAO
Router/Serv
er
Router/Serv
er
EthernetRadio 1 Hop
NS lookup
NS DAD
NS (ARO)
Create proxy state
Classical NDRPL6LoWPAN ND Efficient ND
NA (ARO)
DAC (ARO)
NA (ARO)
6LR 6LBR 6BBR
Router/Serv
er
LP Node Router/Serv
er
Router/Serv
er

152
6LR 6LBR 6BBR
Router/Serv
er
LP Node
RPL Ethernet
NS DAD (ARO)
NS (ARO)
NS (ARO)
DAR (ARO)
Router/Serv
er
Router/Serv
er
EthernetRadio 1 Hop
SRC = UNSPEC
DST = SNMA
TGT = LPN
UID = LPN
TID included
SRC = 6LR *
DST = 6LBR
REG = LPN
UID = LPN
TID included
SRC = LPN_ll *
DST = 6LR_ll *
TGT = LPN **
SLLA = LPN
UID = LPN
TID included
SeND?
SRC = 6LBR
DST = 6BBR *
TGT = LPN
SLLA = L6BR
UID = LPN
TID included
* Global / ULA
* Can be
Anycast
Create binding
state
Create proxy state
* link local unique
EUI-64
** any LPN IPv6
address
RFC
6775 does not use
target
but src
6LR 6LBR 6BBR
Router/Serv
er
LP Node Router/Serv
er
Router/Serv
er

153
6LR 6LBR 6BBR
Router/Serv
er
LP Node
RPL Ethernet
NA (O) *
NA (ARO)
NA (ARO)
DAC (ARO)
Router/Serv
er
Router/Serv
er
EthernetRadio 1 Hop
SRC = 6LR
DST = 6LBR
REG = LPN
UID = LPN
TID included
SRC = 6LR_ll
DST = LPN_ll
TGT = LPN
TLLA = LPN
UID = LPN
TID included
SRC = 6BBR
DST = 6LBR
TGT = LPN
TLLA = L6BR
UID = LPN
TID included * Omitted in general
** link local
DAD time out
SRC = 6BBR_ll **
DST = NS SRC
TLLA = L6BR
TGT = LPN
Adding
TLLAO since dest. is
not
target
6LR 6LBR 6BBR
Router/Serv
er
LP Node Router/Serv
er
Router/Serv
er

154
6LR 6LBR 6BBR
Router/Serv
er
LP Node
RPL Ethernet
NA (~O)
NS (ARO)
NS (ARO)
RPL DAO
Router/Serv
er
Router/Serv
er
EthernetRadio 1 Hop
SRC = 6BBR
DST = NS SRC
TGT = LPN
TLLA = 6LBR
SRC = 6LR
DST = Parent *
or Root
TGT = LPN
UID missing : (
TID included
SRC = LPN_ll
DST = 6LR_ll
TGT = LPN
SLLA = LPN
UID = LPN
TID included
SRC = 6LBR
DST = 6BBR
TGT = LPN
SLLA = L6BR
UID = LPN *
TID included
* Parent in storing
mode
* From binding
state
NS lookup
RPL
cannot DAD
for lack
of UID
6LR 6LBR 6BBR
Router/Serv
er
LP Node Router/Serv
er
Router/Serv
er

156
6LR 6LBRLP Node
NS (ARO)
DAR (ARO)
SRC = 6LR
DST = 6LBR
REG = LPN
UID = LPN
TID included
SRC = LPN_ll
DST = 6LR_ll
TGT = LPN **
SLLA = LPN
UID = LPN
TID included
Collision of binding
state
within RPL
DODAG
Different UID for
addr. LPN
NA (ARO, s=1)
DAC (ARO, s=1)
SRC = 6LR
DST = 6LBR
REG = LPN
UID = LPN
TID included
SRC = 6LR_ll
DST = LPN_ll
TGT = LPN
TLLA = LPN
UID = LPN
TID included
6LR 6LBRLP Node

157
6LR 6LBR 6BBRLP Node
RPL
NS (ARO)
NS (ARO)
DAR (ARO)
EthernetRadio 1 Hop
SRC = 6LR
DST = 6LBR
REG = LPN
UID = LPN
TID included
SRC = LPN_ll
DST = 6LR_ll
TGT = LPN
SLLA = LPN
UID = LPN
TID included
Create binding
state Collision of proxy state
between 6LBRs
attached to a same
6BBR
NA (ARO, s=1)
NA (ARO, s=1)
DAC (ARO, s=1) SRC = 6BBR
DST = 6LBR
TGT = LPN
UID = LPN
TID included

158
Router/Serv
er
Router/Serv
er
Router/Serv
er
RPL Ethernet
NS DAD (ARO)
NS (ARO)
NS (ARO)
DAR (ARO)
EthernetRadio 1 Hop
SRC = 6LR
DST = 6LBR
REG = LPN
UID = LPN
TID included
SRC = LPN_ll
DST = 6LR_ll
TGT = LPN
SLLA = LPN
UID = LPN
TID included
SRC = 6LBR
DST = 6BBR
SLLA = L6BR
TGT = LPN
UID = LPN
TID included
Create binding
state
Create proxy state
Collision with legacy
device attached to the
backbone
6LR 6LBR 6BBR
Router/Serv
er
LP Node Router/Serv
er
Router/Serv
er

159
Router/Serv
er
RPL EthernetRadio 1 Hop
NA (ARO, s=1)
NA (ARO, s=1)
DAC (ARO, s=1)
SRC = NODE
DST = 6BBR
TGT = LPN
UID = LPN
TID included
Collision with legacy
device
Ethernet
NA (O)
SRC = 6BBR
DST = 6LBR
TGT = LPN
UID = LPN
TID included
SRC = 6LR
DST = 6LBR
REG = LPN
UID = LPN
TID included
SRC = 6LR_ll
DST = LPN_ll
TGT = LPN
UID = LPN
TID included
6BBRRouter/Serv
er
Router/Serv
er
Router/Serv
er
Router/Serv
er
Router/Serv
er

160
RPL Ethernet
NS DAD (ARO)
NS (ARO)
NS (ARO)
DAR (ARO)
EthernetRadio 1 Hop
SRC = 6LR
DST = 6LBR
REG = LPN
UID = LPN
TID included
SRC = LPN_ll
DST = 6LR_ll
TGT = LPN
SLLA = LPN
UID = LPN
TID included
SRC = 6LBR
DST = 6BBR
TGT = LPN
SLLA = L6BR
UID = LPN
TID included
Create binding
state
Create proxy state
Collision of proxy state
between 6BBRs
attached to a same
backbone
Router/Serv
er
6LR 6LBR 6BBRLP Node Router/Serv
er
Router/Serv
er

161
NA (ARO, s=1)
NA (ARO, s=1)
DAC (ARO, s=1)
SRC = 6BBR2
DST = 6BBR
TGT = LPN2
UID = LPN2
TID2 included
Collision of proxy state
Ethernet
NA (ARO, s=1)
SRC = 6BBR
DST = 6LBR
TGT = LPN
UID = LPN
TID included
SRC = 6LR
DST = 6LBR
REG = LPN
UID = LPN
TID included
SRC = 6LR_ll
DST = LPN_ll
TGT = LPN
UID = LPN
TID included
6BBR
6BBR
6BBR
6LR 6LBR 6BBR
Router/Serv
er
LP Node Router/Serv
er
Router/Serv
er

163
6LR 6LBRLP Node
NS (ARO)
DAR (ARO)
SRC = 6LR
DST = 6LBR
REG = LPN
UID = LPN
TID included
SRC = LPN_ll
DST = 6LR_ll
TGT = LPN **
SLLA = LPN
UID = LPN
TID included
Matches a binding
state
within RPL
DODAG
same UID for addr.
LPN
NA (ARO, s=0)
DAC (ARO, s=0)
SRC = 6LR
DST = 6LBR
REG = LPN
UID = LPN
TID included
SRC = 6LR_ll
DST = LPN_ll
TGT = LPN
TLLA = LPN
UID = LPN
TID included

164
Router/Serv
er
Router/Serv
er
Router/Serv
er
RPL
NS (ARO)
NS (ARO)
DAR (ARO)
EthernetRadio 1 Hop
SRC = 6LR
DST = 6LBR
REG = LPN
UID = LPN
TID included
SRC = LPN_ll
DST = 6LR_ll
TGT = LPN
SLLA = LPN
UID = LPN
TID included
Create binding
state Matches a proxy state
associated to another
6LBR attached to a
same 6BBR
NA (ARO, s=0)
NA (ARO, s=0)
DAC (ARO, s=0)
Update proxy state
SRC = 6LBR
DST = 6BBR
TGT = LPN
SLLA = L6BR
UID = LPN
TID included

165
6LR 6LBR 6BBR 6BBRLP Node
RPL Ethernet
NS DAD (ARO)
NS (ARO)
NS (ARO)
DAR (ARO)
6BBR
6BBR
EthernetRadio 1 Hop
SRC = 6LR
DST = 6LBR
REG = LPN
UID = LPN
TID included
SRC = LPN_ll
DST = 6LR_ll
TGT = LPN
SLLA = LPN
UID = LPN
TID included
SRC = 6LBR
DST = 6BBR
TGT = LPN
SLLA = L6BR
UID = LPN
TID included
Create binding
state
Create proxy state
Matches a proxy state
in another
6BBR attached to a
same backbone
6LR 6LBR 6BBR
Router/Serv
er
LP Node Router/Serv
er
Router/Serv
er

166
NA (ARO, s=0)
NA (ARO, s=0)
DAC (ARO, s=0)
SRC = 6BBR2
DST = 6BBR
TGT = LPN
UID = LPN
TID2 included
Collision with
Older TID
Ethernet
SRC = 6BBR
DST = 6LBR
TGT = LPN
UID = LPN
TID included
SRC = 6LR
DST = 6LBR
REG = LPN
UID = LPN
TID included
SRC = 6LR_ll
DST = LPN_ll
TGT = LPN
UID = LPN
TID included
6BBR
6BBR
6BBR
NA (O)
Yield silently
6LR 6LBR 6BBR
Router/Serv
er
LP Node Router/Serv
er
Router/Serv
er

167
NA (ARO, s=3)
NA (ARO, s=3)
DAC (ARO, s=3)
SRC = 6BBR2
DST = 6BBR
TGT = LPN
UID = LPN
TID2 included
Collision with
Newer TID
Ethernet
NA (ARO, s=3)
SRC = 6BBR
DST = 6LBR
TGT = LPN
UID = LPN
TID included
SRC = 6LR
DST = 6LBR
REG = LPN
UID = LPN
TID included
SRC = 6LR_ll
DST = LPN_ll
TGT = LPN
UID = LPN
TID included
6BBR
6BBR
6BBR
6LR 6LBR 6BBR
Router/Serv
er
LP Node Router/Serv
er
Router/Serv
er

169
6LR 6BBR
Router/Serv
er
LP Node
RPL Ethernet
NA (~O)
Router/Serv
er
Router/Serv
er
Radio 1 Hop
SRC = 6BBR
DST = NS SRC
SLLA = 6BBR
TGT = LPN
NS lookup
6LR 6LBR 6BBR
Router/Serv
er
LP Node Router/Serv
er
Router/Serv
er
Data packet
Data packet
Data packet
Data packet

170
6LR 6BBR
Router/Serv
er
LP Node
RPL
NA (~O)
Router/Serv
er
Router/Serv
er
Radio 1 Hop
SRC = 6BBR
DST = NS SRC
SLLA = 6LBR
TGT = LPN
NS lookup
6LR 6LBR 6BBR
Router/Serv
er
LP Node Router/Serv
er
Router/Serv
er
Data packet
Data packet
Data packet
Ethernet (Switched)

© 2012 Cisco and/or its affiliates. All rights reserved.IoT6 171Unclassified
“We might be at the eve of pervasive networking, a vision for the Internet
where every person and every device is connected to the network in the
ultimate realization of Metcalf's Law.”

Rpl2016

More Related Content

What's hot

Viewers also liked

Similar to Rpl2016

Recently uploaded

Rpl2016