Rpl2016

1

RPL 2016

Pascal Thubert,

Telecom Bretagne

January 26th 2016

2

How does IoT affect the design of the Internet?

• The any-to-any paradigmArt: Any pair of global addresses can reach one anotherIoT: Many devices of all sorts, no hotfixesCorridors to the cloud?

• The end-to-end paradigmArt: Intelligence at the edge, dumb routing nodesInfinite bandwidth to all powerful clusters?

• The best-effort paradigmArt: Stochastic packet distribution and REDCan we make the whole Internet deterministic?

3

Trillion devices in the InternetThe core technologies will not changeLeakless Autonomic Fringe Leakless Route Projection

Million devices in a SubnetNew models for the subnet protocols

IPv6 ND, RPL, Service Discovery …

Fiber + Copper + Wi-Fi BackboneFemto + 802.11 + 802.15.4 + … Access

Unhindered MobilityLocation / ID Separation (LISP, NEMO)

~ Any to Any

Overlays, Overlays, Overlays10’s of K

4

~ End-to-EndData: 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

5Gfemtocell Data in

Motion / Fog

Learning Machines

/ Cloud

6TiSCH

5

~ Stochastic: Deterministic NetworksAka Time Sensitive Networking (TSN)

For traffic known a priori (control loops…)Time Synchronization and Global ScheduleNP-complete optim. problem => centralized computationFully controlled local network

6

Key Take-Aways

We are in for a change:Basic Internet structures and expectations reconsidered

Revising classical end-to-end and any-to-anyRevising best effort to new levels of guarantees (deterministic)

New function placement, new operationsMerge 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 ?

10

IOT Networks

11

Open standards:

The IEEE and LLNs

12

Wireless: the evolution trait

Cheap InstallDeploying wire is slow and costly

Global CoverageFrom Near Field to Satellite via 3/4GEverywhere copper/fiber cannot reach

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

13

Low Power Lossy Network (LLN)

LLNs comprise a large number of highly constrained devices (smart objects) interconnected by predominantly wireless links of unpredictable quality

LLNs cover a wide scope of applicationsIndustrial 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, ROLLAlliances - IP for Smart Objects Alliance (IPSO)

World’s smallest web server

14

Characteristics of LLNsLLNs 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-sizesMinimise the time a packet is enroute (in the air/on the wire) hence the small frame sizeThe routing protocol for LLNs should be adapted for such links

LLN routing protocols must consider efficiency versus generalityMany 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.1Bluetooth

802.15.2Co-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.4eMAC Enhancements

802.15.4fPHY for RFID

802.15.4gSmart Utility Networks

TV White Space PHY 15.4 Study Group

802.15.4dPHY for Japan

802.15.4cPHY 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 in802.15.4-2015

16

Recent IEEE 802.15 Subgroups of Interest

• 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

Approved PAR for 802.15.4u

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

Draft PAR for 802.15.12

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

Draft PAR for 802.15.12 (continued)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

802.15.4 Scope

Initial activities focused on wearable devices “Personal Area Networks”

Activities have proven to be much more diverse and variedData rates from Kb/s to Gb/sRanges from tens of metres up to a KilometreFrequencies from MHz to THzVarious 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

“The IEEE 802.15 TG4 was chartered to investigate a low data rate solution with multi-month to multi-year battery life and very low complexity. It is operating in an unlicensed, international frequency band. Potential applications are sensors, interactive toys, smart badges, remote controls, and home automation.”

http://www.ieee802.org/15/pub/TG4.htmlIEEE 802.15 WPAN™ Task Group 4 (TG4) Charter

http://www.ieee802.org/15/pub/TG4.html

21

Star Topology Cluster TreeMesh Topology

IEEE 802.15.4 Topologies

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

IEEE 802.15.4 FeaturesDesigned 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

802.15.4 Protocol Stack• Specifies PHY and MAC only

• Medium Access Control Sub-Layer (MAC)Responsible for reliable communication between two devices

Data framing and validation of RX framesDevice addressing

Channel access management

Device association/disassociationSending ACK frames

• Physical Layer (PHY)Provides bit stream air transmission

Activation/Deactivation of radio transceiver

Frequency channel tuningCarrier 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

IEEE 802.15.4e (inc. TimeSlotted Channel Hopping)

Amendment to the 802.15.4-2006 MAC needed for the applications served by 802.15.4f PHY Amendment for Active RFID802.15.4g PHY Amendment for Smart Utility NetworksAll retrofitted in new revision IEEE 802.15.4-2015initially for Industrial applications (such as those addressed by wiHART and the ISA100.11a standards)

Security: support for secured ack

Low Energy MAC extensionCoordinated Sampled Listening (CSL)

Channel HoppingNot built-in, subject to vendor design. Open standard work started at IETF with 6TiSCH

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

25

IEEE 802.15.4 Node TypesFull 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 requirementsCan only communicate with FFDIntended for extremely simple applications

P

R F

F

R

R

26

Open standards:

The IETF and 6LoWPAN

29

IETF LLN Related Workgroups

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 NetworksCharter focusses on routing issues for low power lossy networks.

Lightweight Implementation GuidanceCharter is to provide guidance in building minimal yet interoperable IP-

capable devices for the most constrained environments.

6TiSCHIPv6 over TSCH

Charter is to develop best practice and Architecture for IPv6 over 802.15.4 TSCH.

{

30

Why IPv6 in sensors ?

• 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

Protocol Evolution

Little work on adapting IPv4 to radiosRather adapt radios to IPv4 e.g. WIFI infrastructure mode

« Classical » IPv6 Large, Scoped and Stateful addressesNeighbor Discovery, RAs (L3 beacons)SLAAC (quick and scalable)Anycast Addresses

IPv6 evolution meets Wireless:

Mobile Routers (LISP, NEMO) (Proxy) MIPv66LoWPAN 6TiSCH ROLL/RPL CoAPISA100.11a Thread ZigBee/IP

32

Ten years Ago (only!) ...

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:

http://dunkels.com/adam/ewsn2004.pdf

http://dunkels.com/adam/ewsn2004.pdf

http://www.eecs.harvard.edu/~mdw/course/cs263/papers/ipv6-sensys08.pdf

http://www.eecs.harvard.edu/~mdw/course/cs263/papers/ipv6-sensys08.pdf

33

Goal for 6LoWPAN

• 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

How does 6LoWPAN compare to Zigbee & al. ?

• 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

What’s missing now ? • 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-lowpanzhttp://tools.ietf.org/html/draft-popa-6lo-6loplc-ipv6-over-ieee19012-networkshttp://tools.ietf.org/html/draft-hong-6lo-ipv6-over-nfc http://tools.ietf.org/html/draft-ietf-6lo-6lobachttp://tools.ietf.org/html/draft-delcarpio-6lo-wlanahhttp://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer

Bluetooth Low EnergyDECT Ultra Low EnergyZwavePLCNear Field CommsBACNET802.11ah802.15.4e TSCH

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

36

What about 6TiSCH ?• 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-dispatchhttps://tools.ietf.org/html/draft-ietf-6lo-backbone-router

http://tools.ietf.org/html/draft-ietf-6tisch-tsch

http://tools.ietf.org/html/draft-ietf-6tisch-architecture

https://tools.ietf.org/html/draft-ietf-6lo-routing-dispatch



https://tools.ietf.org/html/draft-ietf-6lo-backbone-router

https://tools.ietf.org/html/draft-ietf-6lo-backbone-router

37

The big (and hopeful) picture…

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

http://tools.ietf.org/html/draft-thubert-6lo-rfc6775-update-reqs

https://tools.ietf.org/html/draft-ietf-6tisch-architecture

38

RFC 6282: 6LoWPAN Adaptation Layer

Preamble SPD PHY Header

AuxiliarySecurity Header

Payload FCSFrameControl

DataSeq.Nbr

Addressing

Simple MAC allows coexistence with other network protocols over same link, similar to Ethernet, although not seen in deployment

IEsHeader & Payload

DSTPAN ID

MeshAddress

6LoWPANCompressed Hdr Payload

DST MAC Address

SRCPAN ID

SRC MAC Address

DSP

X00

10

0111

Not a LoWPAN frame

LoWPAN IPv6 addressing Hdr

LoWPAN mesh Hdr

LoWPAN fragmentation Hdr

Frag. 6LoWPANCompressed Hdr Payload

Frag. 6LoWPANCompressed Hdr Payload

DSP + IPHC Other 6LoWPANHdr field Payload

Header Dispatch (DSP) – understand what is coming

MeshAddressMesh + Fragmentation

Frame Fragmentation

Mesh (L2 Routing)

6LoWPAN

3939

RFC 6282: 6LoWPAN IPv6 Header Compression

0 1 1 HLIM SAM DAM

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 510

TF 2 bits Traffic Class and Flow LabelNH 1 bit Next Header

HLIM 2 bits Hop LimitCID 1 bit Context Identifier ExtensionSAC 1 bit Source Address ContextSAM 2 bits Source Address Mode

M 1 bit Multicast Address CompressionDAC 1 bit Destination Address ContextDAM 2 bits Destination Address Mode

CIDTF NH SAC M DAC

Addressing

40

6LR 6LBRLP Node

NS (ARO)

DAR (ARO)

SRC = 6LRDST = 6LBRREG = LPNUID = LPN

SRC = LPN_llDST = 6LR_llTGT = ??SLLA = LPNUID = LPN

Check Collision of binding state (DAD)

NA (ARO, s=1)

DAC (ARO, s=0,1==dup)


SRC = 6LR_llDST = LPN_ll

TGT = LPNTLLA = LPN

UID = LPN

RFC 6775:6LoWPAN Neighbor Discovery

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 mechanismFor duplicate detectionGoal to save multicast

Address Registration Option

Radio Mesh

Radio 1 Hop

41

Next generation Backbone

Scalable and Multi-LinkDeterministic e2eIP guard (admin knows what’s where)

=> Authoritative Registrar(s)Backbone Routers

RPL root, ND proxyLegacy IPv6 devices

AuthoritativeRegistrar

AuthoritativeRegistrar / 6LBR

IntermediateRegistrar / 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

Key take-aways

43

Routing:

Loopless structures

44

Routing TreesMost 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

01

3

1 12

22

223

3

33

3

2

4

4

5

0

65

4

ROOT

45

DAG, DODAGIn 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

01

3

1 12

22

22

3

3

3

33

3

2

4

4

5

0

65

4

46

SubDAG, and Fanout DAG

• In Green: A’s subDAG. Impacted if A’s connectivity is brokenDomain for routing recovery

• In Red: B’s fanout DAG (or reverse subDAG)Potential SPAN on B’s DAOThus potential return pathsFanout must be controlled to limit intermediate states

Clusterhead

5

4

4

01

3

1 12

22

22

3

3

3

33

3

2

4

4

5

0

65

4

A

B

47

Clusterhead

5

Clusterhead0

1

1 12

22

22

3

3

3

33

3

23

5

4

4

4

4

Siblings Walkable Structures

e.g. ARC of siblingsAllows more alternatesARCs and walkable structures in general are walked with no routing progressRouting between DAGs of ARCs

Forwarding over DAG AND ARCsReduces congestions of upper links of the DAGStill LORA for P2P

IGP subarea (bidirectional)

Link selected and oriented by TD

Potential link

48

Routing:

Forms of Routing

49

Routing for Spatial Reuse

• Hidden terminal

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

50

Proactive vs. Reactive

Aka

Stateful vs.

On-demand routing

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

AODV

DSR

P2P-RPL LOAD

RIP

BABELOSPF

OLSRIS-IS

EIGRP

RPL

51

Link State vs. Distance Vector Aka Dijkstra vs. Bellman-Ford

LS requires full state and convergenceEvery node draws a same graph Then run teh shortest path first algorithm to get to all other nodesThen associates node with reachable destinations

LS can be very quiet on stable topologies

DV learns costs to destination asynchronously per destinationNodes advertise their distance to a destinationRecursively other nodes learn their best successorand compute their own cost

DV hides topolical complexities and changes

RIPRPLBABEL

OSPF OLSRIS-IS

EIGRP

52

0

Route stretch and fisheyeOptimized 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

53

Routing:

Over Radios

54

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

Reachability => Radio (IEEE)

Addressing => IPv6 (IETF)

Density => spatial reuse

=> Routing

Scaling to Pervasive IoE/T

55

Dynamic topologiesNo preexisting physical topology

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

Movement natural and unescapableYet difficult to predict or detect

Topology Update

Routing Update

quick and knowledgeable => expensive

56

Peer selection

Potentially Large Peer Set

Highly Variable Capabilities

Selection Per Objective{ Metrics (e.g. RSSI, ETX…)

L3 Reachability (::/0, …)

Constraints (Power …)

57

Constrained Objects

Smart object are usually Small & Numerous« sensor Dust »

Battery is criticalDeep SleepLimited memorySmall CPU

Savings are REQUIREDÞ Control plane Þ Data plane (Compression)

58

Fuzzy (non-deterministic) links

Neither transit nor P2P

More like a changing NBMAa new paradigm for routing

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

Inefficient floodingSelf interfering

Quality of Service ?

Call Admission Control => TSCH

59

Local Routing & MobilityStretch vs. Control

Optimize table sizes and updates

Optimized Routing Approach (ORA) vs

Least Overhead Routing Approach (LORA)on-demand routes (reactive)

Forwarding and retriesSame vs. Different next hopValidation 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

Global Mobility

Pervasive AccessSatellite 3/4G coverage802.11, 802.15.4

Always Reachableat a same identifier (MIPv6, LISP*…)Preserving connectionsOr not ? (REST**, DTN***)

Fast roamingWithin technology (L2) Between Technologies (L3)

* Locator/Identifier Separation Protocol

** Representational state transfer

*** Delay-Tolerant Networking

61

Work In Progress

A radio abstraction 802.21, L2 triggers, OmniRAN

Roaming within and between technologies

Deterministic Properties

A subnet model for IPv6NBMA, interference awareness

Federation via backbone / backhaul

Broadcast and look up optimizationLarge scale

non-aggregatable numbering and naming schemes

62

RPL (RFC 6550 and then more)

63

Routing With RPL

Dynamic Topologies

Peer selection

Constrained Objects

Fuzzy Links

Routing, local Mobility

Global Mobility

Low Power Lossy Networks Issues Addressedin RPL ?

64

RPL key concepts

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 LLNsAgnostic to underlying link layer technologies (802.15.4, PLC, Low Power WiFi)

65

Controlling the control … by design

Distance Vector as opposed to Link StateKnowledge of SubDAG addresses and children linksLesser topology awareness => lesser sensitivity to changeNo database Synchronization => Adapted to movement

Optimized for Edge operationOptimized for P2MP / MP2P, stretch for arbitrary P2P Least Overhead Routing Approach via common ancestor

Proactive as opposed to ReactiveActually both with so-called P2P draft

Datapath validation

66

RPL Concepts:

DODAG and its maintenance

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

Directed Acyclic Graph for NECM

68

RPL Terminology

5

3

5

4

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

UP

(DA

O M

essages)

DODAG RootIdentified by DODAG ID

(Node IPv6 address)

Direction Oriented DAG (DODAG)Comprises DAG with a single root

Rank

Towards

DO

DA

G

Root

Rank = n

Rank < n

Node(OF

configured)

2

1

5

4

3

3

Rank decreases

DODAG parent to child “5”s

2

DODAG RootRank is always “1”(Typically an LBR - LLN Border Router)

1

3

2

Sub-DODAG

DODAG

DO

WN

(DIO

Mes

sage

s)

Tow

ards

D

OD

AG

le

afs

Rank > n

Rank = n

Ran

k in

crea

ses

Non-LLN Network

(IPv6 Backbone)

Siblings

44

DODAG

Sensor Node

69

Example radio connecticity

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

Radio link

70

Clusterhead

1st pass (DIO)Establishes a logical DAG topologyTrickle Subnet/config InfoSets default routeSelf forming / self healing

2nd pass (DAO) paints with addresses and prefixesAny to any reachabilityBut forwarding over DAG onlysaturates upper links of the DAGAnd does not use the full mesh properly

Applying RPL

Link selected as parent link

Potential link

Clusterhead0

1

1 1

44

4

46

3

3

3

3

3

2

22

22

2

5

55

71

Global versus Local Repair

Global repair: : A new DODAG iterationRebuild the DAG … Then repaint the prefixes upon changesA new Sequence number generated by the rootA router forwards to a parent or as a host over next iteration

Local Repair: 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 failsA loses connectivityEither poisons or detaches a subdag

In black: the potentially impacted

zoneThat is A’s subDAG

Local repair (step 1)


Potential link

Clusterhead0

1

1 1

44

4

46

3

3

3

3

3

2

22

22

2

5

55

A

1

1 1

3

3

3

3

3

2

22

22

2

5

55

44

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 illustratedIn the floating DAG A is rootThe structure is preserved



Potential link

Clusterhead0

1

1

44

4

46

3

3

3

2

2

2

22

21

5

55

AB

0

1

74

Clusterhead

Once poisined nodes are identifiedIt 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

Clusterhead0

1

1 2

44

4

46

3

3

3

4

4

2

22

23

3

5

55

A

75

Clusterhead

A new DAG iterationIn 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

Global repair


Potential link

Clusterhead0

1

1 1

44

4

46

3

3

3

3

3

3

22

22

2

5

55

76

Generic Rank-based Loop Avoidance

1) A root has a Rank of 1. A router has a Rank that is higher

than that of its DAG parents.

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

77

RPL Concepts:

Instances and Objective Functions

78

Instances and Objectives

RPL is objective drivene.g. reach a certain gateway, concept of a goalInstances are built to reach certain goalsInstance ID tagged in packets

RPL is generic and extensibleRFC 6550 is a core distance vector functionalityObjective functions plug in to adapt to use case / needObjective functions enforce policies

79

Objective Function (OF)Extend the generic behavior

For a specific need / use case

Used in parent selectionContraints

Policies Position in the DAGMetrics

Computes the Rank incrementBased 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 loopsMay be done under CTI control

Multiple DODAGs within Instance

Link selected and oriented by DIO

Potential link

01

3

1 12

22

22

3

3

3

33

3

2

4

4

5

0

65

4

81

Multiple Instances

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

Clusterhead0

1

1 12

22

22

3

3

3

33

3

23

5

4

4

4

4

Clusterhead

Constrained instance

Default instance

Potential link

A

82

Messages and Modes:

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

RPL control message

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

84

Messages and Modes:

DIO and parent selection

85

Multicast over radio NBMA

Flooding interferes with itself

B

C

D

A

Hidden node/terminal/station

1

2 ’’2’

86

Trickle: An Optimized Diffusion

Suppression of redundant copies Do not send copy if K copies received

Jitter for Collision AvoidanceFirst half is mute, second half is jittered

Exponential backoffDouble I after period I, Reset I on inconsistency

I

2*I

K = 4

87

Routing Metrics in LLNsNode Metrics Link Metrics

Node State and Attributes ObjectPurpose is to reflects node workload (CPU,

Memory…)“O” flag signals overload of resource“A” flag signal node can act as traffic

aggregator

Throughput ObjectCurrently 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

LatencyCan be used as a metric or constraintConstraint - max latency allowable on pathMetric - additive metric updated along path

Hop Count ObjectCan be used as a metric or constraintConstraint - max number of hops that can be

traversedMetric - total number of hops traversed

Link ReliabilityLink Quality Level Reliability (LQL)

0=Unknown, 1=High, 2=Medium, 3=LowExpected Transmission Count (ETX)

(Average number of TX to deliver a packet)

Link ColourMetric or constraint, arbitrary admin value

For YourReference

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

DIO Base Object: forming the DODAG

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

DIO Base Object: route construction rules

90

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

91

Messages and Modes:

DIS and parent discovery

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

DIS Base Object: DAG query

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

DIS Base Object: DAG query

94

Improvement proposals

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 Containerfor constraints on the responder

Response Spreading Option to spread responses over an interval

https://tools.ietf.org/html/draft-zhong-roll-dis-modifications



https://tools.ietf.org/html/draft-goyal-roll-dis-modifications



95

Messages and Modes:

DAO Storing mode and RPI

96

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

97

Owned prefix routing (storing mode)

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::AA:: connected

B:: connected

C:: via B::CD:: via B::D

C:::/0 via B::BB:: connected

C:: connected

A:A:: connected

B:: via A::BC:: via A::BD:: via A::B

D:::/0 via B::BB:: connected

D:: connected

A::B

B::C B::D

B::B

A::A

98

Subnet Routing (storing mode)

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::AA::A connected

A::B self

A::C connected

A::D connected

A:: ~onlink

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

A::C self

A:: ~onlink

A:A::A self

A::B connected

A::C via A::BA::D via A::BA:: ~onlink

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

A::D self

A:: ~onlink

A::B

A::C A::D

A::A

99

Datapath Validation

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

RPL Packet Information

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

6LoRH – RPI encoding

103

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

e.g. 6LoRH – RPI only, UDP

IPv6 header HbH header UDP header UDP PayloadRPL option

<=>

104

Messages and Modes:

DAO Non-Storing mode and RH3

105

Subnet Routing (non-storing mode)

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::AA::A connected

A::B self

A:: ~onlink

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

A::C self

A:: ~onlink

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

A::D self

A:: ~onlink

Target A::C viaTransit A::BA::B

A::C A::D

A::A

A: (root)A::A self

A::B connected

A::C via A::BA::D via A::BA:: ~onlink

A::D via A::B connectedRH3:

106

Owned prefix routing (non-storing mode)

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::AA:: connected

B:: connected

C:::/0 via B::BB:: connected

C:: connected A: (root)A:: connected

B:: via A::BC:: via B::CD:: via B::D

D:::/0 via B::BB:: connected

D:: connected

Target C::/ viaTransit B::C

D::3 via B::D via A::B connected

A::B

B::C B::D

B::B

A::A

RH3:D::3

107

Routing Header type 3

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

6LoRH – RH3 encoding

Packet source is reference for compressioDifferent compressed size => multiple RH3-6LoRHPlacement 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

RH3-6LoRHoperation

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

e.g. 6LoRH – from root

<=>

IPv6 header Routing header Hop Hop Dec.Hop Hdrs + Payload

112

RRRRRRRRRRRRRRRRRRRR ++ CCCCCCC -------------------- RRRRRRRRRRRRRCCCCCCC

Address Coalescence

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 Type 2 RH3-6LoRH Size = 1 CCCC CCCC 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

Popping; Packet as received by node A

114

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

Popping; Packet as received by node B

115

Type 3 RH3-6LoRH Size = 0 AAAA AAAA CCCC CCCC 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

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

Popping; Packet as received by node C

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.

Popping; Packet as received by node D

117

Data packets:

Headers and Compression

118

Need for IP in IP

(Hateful stuff)Only end points may add / remove headersSome 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 requiredIf the packet leaves the RPL domain since HbH header must be removedIf the packet enters the RPL domain since HBH header or RH3 must be insertedIn 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

IP-in-IP 6LoRH

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.

6LoRH headers order

05/01/2023

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

Order related to non-6LoRH headers

<=>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 rootthat is the source of the IP-in-IP header is elided and inferred from theInstanceID in the RPI. Once found from a local context, that address isused as Compression Reference to expand addresses in the RH3-6LoRH.

UDP packet forwarded by the root

<=>IPv6 header UDP hdr UDP PayloadRouting hdr Hop Dec.HopHbH RPIIPv6 header

123

Summary

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

Simulation Results

Traffic Control

Traffic Holes – Global Repair only

Routing Table Sizes

For YourReference

125

Next steps…

• Standard track Reactive model (P2P RPL rfc6997 is experimental)

• Centralized route computation push (e.g. draft-thubert-roll-dao-projection )

• DAG limitationsSibling 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

https://tools.ietf.org/html/rfc6997

https://tools.ietf.org/html/draft-thubert-roll-dao-projection




126

RPL – IETF suite• 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

128

The backbone router:

The Problem

129

Problem: Use AND implementation of mCast

1. IPv6 Discovery protocols use multicast floodingAssuming 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 fabric5.Broadcast self interferes on attached wireless mesh and

drains the batteries on all nodes

130

Multiple L3Multicast

messages

RAMultiple L2Broadcastmessages

IPv6 Pb: flooding for mobility

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 SolicitationL3 Multicast

L2 broadcast

Packet to Target that ismissing in router ND cache

Nbr Advertisement Unicast

IPv6 Pb: flooding for Neighbor Discovery

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 00A13. Targets answers unicast NA4. Target revalidates ND cache for

the router, usually unicast5. Router creates ND cache entry

6TiSCH proxies at the backbone router on behalf of device

Packet comes in for 2001:db8::A1

132

Wireless ND

Multicast AvoidanceRegistration for DADBinding (location, owner, MAC) to IPv6 addressRegistrar 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@ floodsNew ND methods between registrars and other devices (e.g. LISP)

IETF draftsdraft-ietf-6lo-backbone-routerdraft-chakrabarti-nordmark-6man-efficient-nddraft-thubert-6man-wind-sail

133

Next generation Backbone

Scalable and Multi-Link

Deterministic e2e (DetNet)

Registration based ND

IP guard (admin knows what’s where)=> Authoritative Registrar(s)

Backbone RoutersRPL root, ND proxy

Legacy IPv6 devices

AuthoritativeRegistrar

AuthoritativeRegistrar / 6LBR

IntermediateRegistrar / 6LR

Intermediate Registrar option. ND proxy

Backbone router(ND proxy)

134

6TiSCH

6TiSCH

A Multilink Subnet for unhindered mobility

Sensor

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

6LOWPAN ND / RPL

PROXY ND / ROUTING

Wireless Router

Mesh Root Mesh Root

Wireless RouterWireless Router

DRAFT IETF BACKBONE ROUTER

136


High level exchanges

137

Enhanced Address Registration Option

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

Initial timeRouters 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

ConnectedRoute to subnet

139

First advertisements from GW (RA, IGP, RPL)

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

DefaultRouteIn RIB

140

IPv6 ND Registration to 6LR and 6LBR

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

IPv6 ND Registration and Proxy for NS ARO

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

IPv6 ND Proxy for RPL

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.

RPLDAO

HostRoute

Optional NA(O)

143

RPL over the backbone

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

RPLDAO

RPL DAO

HostRoute

144

Duplication DAD option has:Unique ID

TID (SeqNum)

Defend with NA if:Different OUID

Newer TID

NS DAD(ARO)

NA (ARO)NS

(ARO)

145

Duplication (2) DAD option has:Unique ID

TID (SeqNum)


Newer TID

DAR

NA(ARO)

DAD

146

Mobility

RPLDAO

Optional NA(ARO)

HostRoute

DAD option has:Unique ID

TID (SeqNum)


Newer TID

NA (ARO) with older TID (loses)

147

Resolution

Packet

NSlookup

NA ARO option has:Unique ID

TID (SeqNum)

NA (ARO)

148

Resolution (2)NSlookup

Mixed mode NDBBR proxying over

the backbone

NA (ARO)

Packet

149


Deeper dive in flows

150

6LR 6LBR 6BBR Router/ServerLP Node

RPL Ethernet

RA (unicast)

RA (u|mcast)

DIO

Router/ServerRouter/

ServerEthernetRadio 1 Hop

SLLA

PIOMTUSLLA

CONTEXT

PIOMTUSLLA

CONTEXT

PIOMTU

RA (u|mcast)

RS (mcast)

PIO

RA (u|mcast)

PIOMTUSLLA

CONTEXT

151


Radio Mesh

Ethernet

NA (~O)

NS (ARO)

NS (ARO)DAR, RPL DAO


Server

EthernetRadio 1 Hop

NS lookup

NS DADNS (ARO)

Create proxy state

Classical NDRPL6LoWPAN ND Efficient ND

NA (ARO)

DAC (ARO)

NA (ARO)

6LR 6LBR 6BBR Router/ServerLP Node Router/

ServerRouter/Server

152


RPL Ethernet

NS DAD (ARO)

NS (ARO)

NS (ARO)

DAR (ARO)



SRC = UNSPECDST = SNMATGT = LPNUID = LPNTID included

SRC = 6LR *DST = 6LBRREG = LPNUID = LPNTID included

SRC = LPN_ll *DST = 6LR_ll *TGT = LPN **SLLA = LPNUID = LPNTID included

SeND?

SRC = 6LBRDST = 6BBR *TGT = LPNSLLA = L6BRUID = LPNTID 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

targetbut src


ServerRouter/Server

153


RPL Ethernet

NA (O) *

NA (ARO)

NA (ARO)

DAC (ARO)




TID included


TGT = LPNTLLA = LPN

UID = LPNTID included

SRC = 6BBRDST = 6LBRTGT = LPN

TLLA = L6BRUID = LPN

TID included * Omitted in general** link local

DAD time out

SRC = 6BBR_ll **DST = NS SRCTLLA = L6BRTGT = LPN

Adding TLLAO since dest. is

not target


ServerRouter/Server

154


RPL Ethernet

NA (~O)

NS (ARO)

NS (ARO)

RPL DAO



SRC = 6BBRDST = NS SRCTGT = LPNTLLA = 6LBR

SRC = 6LRDST = Parent * or RootTGT = LPNUID missing : (TID included

SRC = LPN_llDST = 6LR_ll TGT = LPNSLLA = LPNUID = LPNTID included

SRC = 6LBRDST = 6BBRTGT = LPNSLLA = L6BRUID = LPN *TID included

* Parent in storing mode

* From binding state

NS lookup

RPL cannot DAD

for lackof UID


ServerRouter/Server

155


Duplicate registration

156

6LR 6LBRLP Node

NS (ARO)

DAR (ARO)

SRC = 6LRDST = 6LBRREG = LPNUID = LPNTID included

SRC = LPN_llDST = 6LR_llTGT = LPN **SLLA = LPNUID = LPNTID included

Collision of binding statewithin RPLDODAGDifferent UID for addr. LPN

NA (ARO, s=1)

DAC (ARO, s=1)


TID included


TGT = LPNTLLA = LPN


6LR 6LBRLP Node

157

6LR 6LBR 6BBRLP Node

RPL

NS (ARO)

NS (ARO)

DAR (ARO)

EthernetRadio 1 Hop


SRC = LPN_ll DST = 6LR_ll TGT = LPN SLLA = LPNUID = LPNTID 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 = 6BBRDST = 6LBRTGT = LPNUID = LPN

TID included


158


ServerRouter/Server


RPL Ethernet

NS DAD (ARO)

NS (ARO)

NS (ARO)

DAR (ARO)

EthernetRadio 1 Hop



SRC = 6LBRDST = 6BBRSLLA = L6BRTGT = LPNUID = LPNTID included


Create proxy state

Collision with legacy device attached to the backbone


ServerRouter/Server

159

Router/Server6LR 6LBR 6BBRLP Node

RPL EthernetRadio 1 Hop

NA (ARO, s=1)

NA (ARO, s=1)

DAC (ARO, s=1)

SRC = NODEDST = 6BBR

TGT = LPNUID = LPN

TID included

Collision with legacy device

Ethernet

NA (O)

SRC = 6BBRDST = 6LBRTGT = LPNUID = LPN

TID included


TID included


TGT = LPNUID = LPN

TID included

6BBRRouter/ServerRouter/

Server

6LR 6LBR 6BBRLP Node Router/ServerRouter/

ServerRouter/Server

160

RPL Ethernet

NS DAD (ARO)

NS (ARO)

NS (ARO)

DAR (ARO)

EthernetRadio 1 Hop



SRC = 6LBRDST = 6BBRTGT = LPNSLLA = L6BRUID = LPNTID included


Create proxy state

Collision of proxy statebetween 6BBRs attached to a same backbone

Router/Server6LR 6LBR 6BBRLP Node Router/

ServerRouter/Server

161



NA (ARO, s=1)

NA (ARO, s=1)

DAC (ARO, s=1)

SRC = 6BBR2DST = 6BBRTGT = LPN2UID = LPN2

TID2 included

Collision of proxy state

Ethernet

NA (ARO, s=1)


TID included


TID included


TGT = LPNUID = LPN

TID included

6BBR6BBR

6BBR6LR 6LBR 6BBR Router/

ServerLP Node Router/ServerRouter/

Server

162


Mobility

163

6LR 6LBRLP Node

NS (ARO)

DAR (ARO)


SRC = LPN_llDST = 6LR_llTGT = LPN **SLLA = LPNUID = LPNTID included

Matches a binding statewithin RPLDODAGsame UID for addr. LPN

NA (ARO, s=0)

DAC (ARO, s=0)


TID included


TGT = LPNTLLA = LPN



164


ServerRouter/Server


RPL

NS (ARO)

NS (ARO)

DAR (ARO)

EthernetRadio 1 Hop



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



165

6LR 6LBR 6BBR 6BBRLP Node

RPL Ethernet

NS DAD (ARO)

NS (ARO)

NS (ARO)

DAR (ARO)

6BBR6BBR

EthernetRadio 1 Hop





Create proxy state

Matches a proxy state in another6BBR attached to a same backbone


ServerRouter/Server

166



NA (ARO, s=0)

NA (ARO, s=0)

DAC (ARO, s=0)SRC = 6BBR2

DST = 6BBRTGT = LPNUID = LPN

TID2 included

Collision withOlder TID

Ethernet


TID included


TID included


TGT = LPNUID = LPN

TID included

6BBR6BBR

6BBR

NA (O)

Yield silently


ServerRouter/Server

167



NA (ARO, s=3)

NA (ARO, s=3)

DAC (ARO, s=3)

SRC = 6BBR2DST = 6BBR

TGT = LPNUID = LPN

TID2 included

Collision withNewer TID

Ethernet

NA (ARO, s=3)


TID included


TID included


TGT = LPNUID = LPN

TID included

6BBR6BBR

6BBR6LR 6LBR 6BBR Router/

ServerLP Node Router/ServerRouter/

Server

168


Routing Proxy vs. Bridging Proxy

169

6LR 6BBR Router/ServerLP Node

RPL Ethernet

NA (~O)


ServerRadio 1 Hop

SRC = 6BBRDST = NS SRCSLLA = 6BBRTGT = LPN

NS lookup


ServerRouter/Server

Data packetData packet

Data packet

Data packet

170

6LR 6BBR Router/ServerLP Node

RPL

NA (~O)


ServerRadio 1 Hop

SRC = 6BBRDST = NS SRCSLLA = 6LBRTGT = LPN

NS lookup


ServerRouter/Server

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.”

174

THX!

Rpl2016

Technology

Transcript of Rpl2016