1. SNS COLLEGE OF TECHNOLOGY
Coimbatore-35.
An Autonomous Institution
COURSE NAME : Internet of Things
III YEAR/ V SEMESTER
UNIT – III Evolving IoT Standards and Protocols
Topic: IPV6 Routing Protocol for RPL
Dr.K.Sangeetha
HoD
Department of Computer Science and Engineering
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?
2
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
3
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
4
5. 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
5
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
New function placement, new operations
Impacts network, transport, security models
6
7. Why Standards?
Developing IP/routing/transport/web protocols subsets that scale down to IOT
devices; specifically, lightweight routing protocols for the IoT;
Describing architectures that employ gateways and middleware;
Developing mobility management;
Internetworking of IoT things;
Lightweight implementations of cryptographic stacks; and building a suitable
security infrastructure: end-to-end security capabilities for the IoT things;
Developing standards for applications, specifically, data formats; and
Discouraging on domain-specific solutions.
7
8. • The Internet Engineering Task Force (IETF) IPv6 routing protocol for low
power and lossy networks (RPL)/routing over low power and lossy
networks(ROLL);
• IETF constrained application protocol (CoAP);
• IETF constrained RESTfull environments (CoRE);
• IETF IPv6 over low power WPAN (6LoWPAN);
• 3GPP MTC; and
• ETSI M2M. Recall that M2M involves communication without (or only
limited) human intervention where the human is not the input agent but
possibly (but not always) the output agent.
• For example, ETSI TS/TR 102 addresses M2M architecture and services
(e.g., smart metering, e-health, auto, and city).
8
10. 10
(i)ETSI: for end-to-end framework for M2M;
(ii) 3GPP: to enable operators to support
services
(iii) IEEE: to optimize the radio access/physical
layer.
11. 11
Open Standards
IEEE and LLNs
IETF and 6LoWPAN
Routing
Loopless structures
Forms of Routing Over Radios
12. 12
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
15. 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)
15
16. 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
16
17. 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
17
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 beadapted for such links
LLN routing protocols must consider efficiency versus generality
Many LLN nodes do not have resources to waste
18. 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
18
19. • 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) 19
20. Operates at Layer 2
Star Topology
R
F R
P
R F
All devices communicate to
PAN co-ordinator which
uses mains power
Other devices can be
battery/scavenger
Mesh Topology
F R
F P
F
F F
R R
Devices can communicate
directly if within range
Cluster Tree
R R
R F F
R P
F F
R R
Higher layer protocols like
RPL may create their own
topology that do not follow
802.15.4 topologies
Single PAN co-ordinator exists for all topologies
20
21. 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)
21
22. • 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)
22
23. Amendment to the 802.15.4-2006 MAC needed for the applications served by
23
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)
24. 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
24
28. Application
General
Internet
Ops and Mgmt
Routing
Security
Reuse work done here where possible
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.
28
29. • 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
29
30. 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
30
31. • 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:
http://dunkels.com/adam/ewsn2004.pdf
http://www.eecs.harvard.edu/~mdw/course/cs263/papers/ipv6-sensys08.pdf
31
32. • 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
32
33. • 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
33
34. • Generalize to all technologies, provide generic abstraction
• 6lo now chartered to define IPv6 over IOT Links
• Current work on:
34
• 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
35. • 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
35
36. 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
36
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
37. Simple MAC allows coexistence with other network protocols over same link, similar to Ethernet, although not seen
in deployment
DST
PAN ID
DST MAC
Address
SRC
PAN ID
SRC MAC
Address
Preamble SPD
PHY
Header
Frame
Control
Data
Seq.
Nbr
Addressing
Auxiliary
Security
Header
IEs
Header &
Payload
DSP Payload FCS
Mesh
Address
6LoWPAN
Compressed Hdr
Payload
0 0 X
0 1
1 0
1 1
Not a LoWPAN frame
LoWPAN IPv6 addressing Hdr
LoWPAN mesh Hdr
LoWPAN fragmentation Hdr
Frag.
6LoWPAN
Compressed Hdr
Payload
Mesh
Address
Frag.
6LoWPAN
Compressed Hdr
Payload
DSP + IPHC
Other 6LoWPAN
Hdr field
Payload
Header Dispatch (DSP) – understand
what is coming
Mesh + Fragmentation
Frame Fragmentation
Mesh (L2 Routing)
6LoWPAN
37
38. 0 1 1 TF NH HLIM CID SAC SAM M DAC DAM
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
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
Addressing
38
41. 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
41
43. 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
4
0
1
3
1 1
2
2
2
2
2
3
3
3
3
3
2
4
55
0
6
44 5
4
ROOT
43
44. 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
0
1
3
1 1
2
2
2
2
2
3
3
3
3
3
3
2
4
5
0
6
44 5
4
44
45. • 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
4
0
1
3
1 1
2
2
2
2
3
3
3
3
3
3
2
4
55
0
6
44 5
4
2A
45
B
46. 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
46
50. 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
50
51. 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
51
53. 54
1000*scale => No leak in Internet
=> Opaque operations
Reachability => Radio (IEEE)
=> IPv6 (IETF)
=> spatial reuse
Addressing
Density
=> Routing
54. 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
55
55. 56
Potentially Large Peer Set
Highly Variable Capabilities
Selection Per Objective
Metrics (e.g. RSSI, ETX…)
L3 Reachability (::/0, …)
Constraints (Power …)
56. 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)
56
57. 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
57
58. 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
58
59. 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
60. 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
60
63. 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)
63
64. 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
66. 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).
66
67. 5
3
5
4
DODAG Root
Identified by DODAG ID
(Node IPv6 address)
RPL Instance
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
(OF
configured)
Rank
Rank = n
Rank < n
Rank
decreases
UP
(DAO
Messages)
Towards
DODAG
Root
2
1
5
4
3
3
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
Rank > n
Rank = n
Towards
DODAG
leafs
DOWN
(DIO
Messages)
Rank
increases
Non-LLN
Network
(IPv6 Backbone)
Siblings
4
4
DODAG
Sensor
Node
67
68. At a given point of
time connectivity is
as illustrated and
rather fuzzy
Radio link
6
69. 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
4
6
3
3
3
3
3
2
2
2
2
2
2
5
5
5
69
70. : : 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
7
71. 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
Potential link
Link selected as parent link
Clusterhead
0
6
A
1
1
1
3
3
3
3
3
2
2
2
2
2
2
5
5
5
4
4
4
4
71
72. 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
Link selected as parent link
Potential link
Clusterhead
0
1
1
4
4
4
4
6
3
3
3
2
2
2
2
2
1
5
5
5
A
2 B
0
1
72
73. 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
Link selected as parent link
Clusterhead
0
1
1
2
4
4
4
4
6
3
3
3
4
4
2
2
2
2
3
3
5
5
5
A
73
74. 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
Link selected as parent link
Clusterhead
0
1
1
1
4
4
4
4
6
3
3
3
3
3
3
2
2
2
2
2
5
5
5
74
75. 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
75
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
77. 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
7
78. Extend the generic behavior
For a specific need / use case
Used in parent selection
Contraints
Policies
Metrics
Position in the DAG
Computes the Rank increment
Based on hop metrics
Do NOT use OF0 for adhoc radios!
(OF 0 uses traditional weighted hop count)
7
79. Clusterhead
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
55
0
6
4 5
4
7
80. 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
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
8
85. 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
8
86. 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
86
93. draft-zhong-roll-dis-modifications
9
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. 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
96
97. 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
97
98. Control Information in Data Packets:
RPI in IPv6
Hop-By-Hop Header
Instance ID
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
9
99. 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.
99
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
104. 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 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::B
A::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
104
105. A
B
C D
Parent is default GW, advertizes owned PIO (L bit on)
RPL Router autoconfigures Address from parent PIO
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
105
106. 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.
106
Encoding: RFC 6554 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CmprI | CmprE | Pad | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type3| Segments Left |
|
.
. Addresses[1..n]
|
.
.
.
|
.
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
107. 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+
| 6LoRH | Length of compressed
| Type | IPv6 address (bytes)
+-----------+---
| 0 |
| 1 |
| 2 |
| 3 |
|
+-
4 |
+-
|1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+
Size indicates the number of compressed addresses
+- +- +
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)
107
108. +- ... -+- ... -+-+-+- ... -+-+-+-+-+ ... +-+-+-+-+-+-+ ... +-+-+...
|11110001|RH3(128bits)| RH3(3*16bits) |NH=1 |11110CPP| Compressed | UDP
|Page 1 | 6LoRH | 6LoRH |6IPHC| UDP | UDP header | Payload
+- ... -+- ... +-+-+-+- ... -+-+-+-+-+ ... +-+-+-+-+-+-+ ... +-+-+...
<- RFC 6282 ->
With RPL this is only when the source is the root
Note:
IPv6 header UDP header UDP Payload
<=>
Routing hdr Hop Hop Hop Dec.
108
109. 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 suffix
RH3-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 Dest
A
1
112. 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
Type 2 RH3-6LoRH Size = 1 CCCC CCCC
DDDD DDDD
Step 3:
Type 3
recursion
RH3-6LoRH
ended,
Size =
coalescing BBBB with the
0 AAAA AAAA AAAA BBBB
first entry
Step 4: routing based on next segment endpoint to B 112
113. Type 3 RH3-6LoRH Size = 0 AAAA AAAA AAAA BBBB
Type 2 RH3-6LoRH Size = 1 CCCC CCCC
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 3 RH3-6LoRH Size = 0 AAAA AAAA AAAA BBBB
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
1
114. Type 3 RH3-6LoRH Size = 0
Type 2 RH3-6LoRH Size = 0
AAAA AAAA CCCC CCCC
DDDD DDDD
Step 1 popping DDDD DDDD, the first entry of the next RH3-6LoRH
Step 2 the RH3-6LoRH is removed
Type 3 RH3-6LoRH Size = 0 AAAA AAAA CCCC CCCC
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
114
115. 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.
115
117. (Hateful stuff)
1
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
118. 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.
118
Encoding: RFC 2460 then 6LoRH
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
119. 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
RH3-6LoRH* RPI-6LoRH IP-in-IP-LoRH RH3-6LoRH* RPI-6LoRH IP-in-IP-LoRH RPI-6LoRH IPHC data
IP-in-IP RPI RH3 IP blah vs. IP-in-IP IP RPI RH3 blah
You cannot tell : (
With a format like MAC IP-in-IP-LoRH RH3-6LoRH* RPI-6LoRH IPHC blah
With this format we have a clear separation for IP in IP in IP all the way
MAC
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
1
121. +-+-+-+-+-+-+- ... +-+-+- ... -+-+-- ... -+-+- ... -+-+-+-+-+-+-+ ... -+-+-+-+...
|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 Payload
Routing hdr Hop Dec.
Hop
HbH RPI
IPv6 header
121
122. 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:
122
124. • 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
124
125. • 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
•
125
126. Bringing it all together:
draft-ietf-6lo-backbone-router
126
128. 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
128
129. 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)
1
6TISCH uses a backbone
router, limits the broadcast
domain to the backbone
VM, NFV,Wireless or IoT device moves:
130. 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
3. Targets answers unicast NA
4. Target revalidates ND cache for
the router, usually unicast
5. Router creates ND cache entry
6TiSCH proxies at the backbone
router on behalf of device
1
Packet comes in for 2001:db8::A1
131. 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
1
136. Used to resolve conflicts
1
Need In ND: TID to detect movement ->eARO
Need In RPL: Object Unique ID if we use RPL for DAD
01 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 )
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
137. 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
137
138. 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
138
139. Directly upon NS(ARO) or indirectly upon DAR
message, the backbone router performs DAD on
behalf of the wireless device.
DAR
NS
(ARO)
1
DAD
NS DAD
(ARO)
140. 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
Optional
NA(O)
NA
(ARO)
140
141. 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
1
Optional
NA(O)
142. 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
1
143. DAD option has:
Unique ID
TID (SeqNum)
Defend with NA if:
Different OUID
Newer TID
NS DAD
(ARO)
NA (ARO)
NS
(ARO)
143
144. DAD option has:
Unique ID
TID (SeqNum)
Defend with NA if:
Different OUID
Newer TID
DAR
NA
(ARO)
DAD
144
149. 6LR 6LBR 6BBR
outer/Serv
er
LP Node
RPL Ethernet
RA (unicast)
RA (u|mcast)
DIO
outer/Serv
er
R
R
Router/Serv
er
Ethernet
Radio 1 Hop
SLLA
PIO
MTU
SLLA
CONTEXT
PIO
MTU
SLLA
CONTEXT
PIO
MTU
RA (u|mcast)
RS (mcast)
PIO
RA (u|mcast)
149
PIO
MTU
SLLA
CONTEXT
150. 6LR 6LBR 6BBR
outer/Serv
er
LP Node
Radio
Mesh
Ethernet
NA (~O)
outer/Serv
er
R
R
Router/S
Ethernet
Radio 1 Hop
NS lookup
Create proxy state
Classical ND
RPL
6LoWPAN ND Efficient ND
NS (ARO)
DAR, RPL DAO
NS (ARO)
NS DAD
NA (ARO)
DAC (ARO)
NA (ARO)
6LR 6LBR 6BBR
outer/Serv
er er
LP Node outer/Serv
v
er
er
R
R
Router/Serv
er
1
151. 6LR 6LBR 6BBR
outer/Serv
er
LP Node
RPL Ethernet
NS DAD (ARO)
NS (ARO)
NS (ARO)
DAR (ARO)
outer/Serv
er
R
R
Router/S
Ethernet
Radio 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
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 u
U
sIe
D = LPN
target
but src
6LR 6LBR 6BBR
outer/Serv
er er
LP Node outer/Serv
er v
er
R
R
Router/Serv
er
151
152. 6LR 6LBR 6BBR
outer/Serv
er
LP Node
RPL Ethernet
NA (O) *
NA (ARO)
NA (ARO)
DAC (ARO)
outer/Serv
er
R
R
Router/S
Ethernet
Radio 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
outer/Serv
er er
er
LP Node outer/Serv
er v
R
R
Router/Serv
er
152
153. 6LR 6LBR 6BBR
outer/Serv
er
LP Node
RPL Ethernet
NA (~O)
NS (ARO)
NS (ARO)
RPL DAO
outer/Serv
er
R
R
Router/S
Ethernet
Radio 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
outer/Serv
er er
LP Node outer/Serv
v
er
er
R
R
Router/Serv
er
153
155. 6LR 6LBR
LP 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
6LBR
LP Node
1
156. 6LR 6LBR 6BBR
LP Node
RPL
NS (ARO)
NS (ARO)
DAR (ARO)
Ethernet
Radio 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
6LR 6LBR
6BBR
LP Node
1
157. outer/Serv
er
outer/Serv
er
R
R
Router/S
6LR 6LBR 6BBR
LP Node
RPL Ethernet
NS DAD (ARO)
NS (ARO)
NS (ARO)
DAR (ARO)
Ethernet
Radio 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
outer/Serv
er er
er
LP Node outer/Serv
er
v
R
R
Router/Serv
er
157
158. Router/Serv
er
6LR 6LBR 6BBR
LP Node
RPL Ethernet
Radio 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
6BBR
outer/Serv
er
R
Router/S
6LR 6LBR 6BBR
LP Node
outer/Serv
er er
outer/Serv
v
er
er
R
R
Router/Serv
er
158
159. RPL Ethernet
NS DAD (ARO)
NS (ARO)
NS (ARO)
DAR (ARO)
Ethernet
Radio 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
outer/Serv
er
6LR 6LBR 6BBR
LP Node outer/Serv
er
R
R
Router/Serv
er
159
160. 6LR 6LBR 6BBR
LP Node
RPL Ethernet
Radio 1 Hop
NA (ARO, s=1)
NA (ARO, s=1)
DAC (ARO, s=1)
SRC = 6BBR2
DST = 6BBR
TGT = LPN2
UID = LPN2
TID2 included
Ethernet
Collision of proxy state
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
6LR 6LBR 6BBR
outer/Serv
er
6BBR
LP Node outer/Serv
er
R
R
Router/Serv
er
160
162. 6LR 6LBR
LP 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
6LR 6LBR
6BBR
LP Node
1
163. outer/Serv
er
outer/Serv
er
R
R
Router/Serv
er
6LR 6LBR 6BBR
LP Node
RPL
NS (ARO)
NS (ARO)
DAR (ARO)
Ethernet
Radio 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)
DAC (ARO, s=0)
NA (ARO, s=0)
Update proxy state
SRC = 6LBR
DST = 6BBR
TGT = LPN
SLLA = L6BR
UID = LPN
TID included
6LR 6LBR 6BBR
LP Node
163
164. 6LR 6LBR 6BBR 6BBR
LP Node
RPL Ethernet
NS DAD (ARO)
NS (ARO)
NS (ARO)
DAR (ARO)
6BBR
Ethernet
Radio 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
outer/Serv
er
6BBR
LP Node outer/Serv
er
R
R
Router/Serv
er
164
165. 6LR 6LBR 6BBR
LP Node
RPL Ethernet
Radio 1 Hop
NA (ARO, s=0)
DAC (ARO, s=0) DST = 6BBR
TGT = LPN
UID = LPN
TID2 included
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
NA (O)
Collision with
Older TID
Yield silently
NA (ARO, s=0)
SRC = 6BBR2
6LR 6LBR 6BBR
outer/Serv
er
6BBR
LP Node outer/Serv
er
R
R
Router/Serv
er
165
166. 6LR 6LBR 6BBR
LP Node
RPL Ethernet
Radio 1 Hop
NA (ARO, s=3)
NA (ARO, s=3)
DAC (ARO, s=3)
SRC = 6BBR2
DST = 6BBR
TGT = LPN
UID = LPN
TID2 included
Ethernet
Collision with
Newer TID
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
6LR 6LBR 6BBR
outer/Serv
er
6BBR
LP Node outer/Serv
er
R
R
Router/Serv
er
166
168. 6LR 6BBR
outer/Serv
er
LP Node
RPL Ethernet
outer/Serv
er
R
R
Router/S
Radio 1 Hop
6LR 6LBR 6BBR
outer/Serv
er er
LP Node outer/Serv
v
er
er
R
R
Router/Serv
er
NS lookup
NA (~O)
SRC = 6BBR
DST = NS SRC
SLLA = 6BBR
TGT = LPN
Data packet
Data packet
Data packet
Data packet
1
169. 6LR 6BBR
outer/Serv
er
LP Node
RPL
outer/Serv
er
R
R
Router/S
Radio 1 Hop
6LR 6LBR 6BBR
outer/Serv
er er
LP Node outer/Serv
v
er
er
R
R
Router/Serv
er
NS lookup
NA (~O)
SRC = 6BBR
DST = NS SRC
SLLA = 6LBR
TGT = LPN
Data packet
Data packet
Data packet
Ethernet (Switched)
1
174. Embedded Systems :
It is a combination of hardware and software used to perform special tasks.
It includes microcontroller and microprocessor memory, networking units (Ethernet Wi-Fi
adapters), input output units (display keyword etc. ) and storage devices (flash memory).
It collects the data and sends it to the internet.
Embedded systems used in
Digital camera
DVD player, music player
Industrial robots
Wireless Routers etc.
174
175. 1.Daniel Minoli, Building the Internet of Things with IPv6 and MIPv6: The Evolving World
of M2M Communications, Wiley Publications, First Edition, 2013. (UNIT I-IV)
2. Arsheep Bahga , Vijay Madisetti , Internet of Things: A Hands-On Approach,
Universities Press, First Edition , 2014.(UNIT I & V)
References :
06/08/2020 27
Introduction/Data Analytics/Sangeetha K/CSE/SNSCT 175
