SlideShare a Scribd company logo

Rpl2018

Download as PPTX, PDF
Pascal Thubert, profile picture
Pascal Thubert

The document discusses routing concepts for low-power and lossy networks (LLNs). It outlines several standards organizations and working groups developing protocols in this area, including IEEE 802.15.4 and various IETF working groups. It also summarizes the RPL and 6TiSCH routing protocols which allow IPv6 connectivity in LLNs using technologies like 6LoWPAN.

Internet
1 of 292
Downloaded 80 times
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
1 RPL 2018 Pascal Thubert, Rennes January 24th 2018
2 • The any-to-any paradigm Art: Any pair of global addresses can reach one another IoT: Many devices of all sorts, no hotfixes Corridors to the cloud? • The end-to-end paradigm Art: Intelligence at the edge, dumb routing nodes Infinite bandwidth to all powerful clusters? • The best-effort paradigm Art: Stochastic packet distribution and RED Can we make the whole Internet deterministic?
3 Trillion devices in the Internet The core technologies will not change Leakless Autonomic Fringe Leakless Route Projection Million devices in a Subnet New models for the subnet protocols IPv6 ND, RPL, Service Discovery … Fiber + Copper + Wi-Fi Backbone Femto + 802.11 + 802.15.4 + … Access Unhindered Mobility Location / ID Separation (LISP, NEMO) 10’s of K
4 Data: Capillary Wireless Acquisition of large amounts of live Big Data Information: DiM/Fog to add descriptive meta-tags, allowing for compression and correlation Knowledge: Prediction from self-learned models and Knowledge Diffusion Wisdom: Machine Learnt Expertise, auto-Generating Prescriptions and Actionable Recommendations (Data) ACQUISITION (Knowledge) DIFFUSION (Wisdom) OPEN LOOP (Information) AGGREGATION 5G femtocell Data in Motion / Fog Learning Machines / Cloud 6TiSCH
5 Aka Time Sensitive Networking (TSN) For traffic known a priori (control loops…) Time Synchronization and Global Schedule NP-complete optim. problem => centralized computation Fully controlled local network
6 We are in for a change: Basic Internet structures and expectations reconsidered Revising classical end-to-end and any-to-any Revising best effort to new levels of guarantees (deterministic) New function placement, new operations Merge at the Information layer, Gossip at the knowledge layer Impacts network, transport, security models
7 Agenda (part 1, Introduction) IOT Standards IEEE and LLNs IETF and 6LoWPAN IETF 6TiSCH Routing Concepts Forms of Routing Loopless structures 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, New Work on RPL) RPL Route Projection (SDN) Shortening Long SRH Transversal Routes BIT Indexing (BIER) Un- vs. reliable BIER RPL Fast Reroute in RPL Using Data Plane Using Control Plane On-Demand RPL
10 Additional material The backbone router Problem High level exchanges Deeper dive in flows
11 IOT Standards
12
13 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)
14 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 Alliances and consortiums addressing LLNs IETF - CoRE, 6lo/LoWPAN, ROLL, ACE, LPWAN, 6TiSCH… Alliances – IPSO, Thread, ISA, HCF World’s smallest web server
15 LLNs operate with a hard, very small bound on state LLNs are optimised for saving energy in the majority of cases Traffic patterns can be MP2P, P2P and P2MP flows Typically LLNs deployed over link layers with restricted frame-sizes Minimise the time a packet is enroute (in the air/on the wire) hence the small frame size The routing protocol for LLNs should be adapted for such links LLN routing protocols must consider efficiency versus generality Many LLN nodes do not have resources to waste
16 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
Cisco Confidential© 2012 Cisco and/or its affiliates. All rights reserved. 17 Initial activities focused on wearable devices “Personal Area Networks” Activities have proven to be much more diverse and varied Data rates from Kb/s to Gb/s Ranges from tens of metres up to a Kilometre Frequencies from MHz to THz Various applications not necessarily IP based Focus is on “specialty”, typically short range, communications If it is wireless and not a LAN, MAN, RAN, or WAN, it is likely to be 802.15 (PAN) The only IEEE 802 Working Group with multiple MACs http://www.ieee802.org/15/pub/TG4.html IEEE 802.15 WPAN™ Task Group 4 (TG4) Charter
18 Star Topology Cluster TreeMesh Topology P R F F R R P F F F R F R All devices communicate to PAN co-ordinator which uses mains power Other devices can be battery/scavenger Single PAN co-ordinator exists for all topologies Devices can communicate directly if within range F F F F P R R F R Operates at Layer 2 R R RR Higher layer protocols like RPL may create their own topology that do not follow 802.15.4 topologies
19 • 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 (IEEE Std. 802.15.12, Network & App)
20
21
22
23 Reuse work done here where possible Application General Internet Ops and Mgmt Routing Security Transport Core 6lo ROLL IETF LWIG Constrained Restful Environments Charter to provide a framework for resource-oriented applications intended to run on constrained IP networks. IPv6 over Networks of Resource-constrained Nodes (succeeds 6LoWPAN) Charter is to develop protocols to support IPv6 IoT networks. Routing over Low Power Lossy Networks Charter focusses on routing issues for low power lossy networks. Lightweight Implementation Guidance Charter is to provide guidance in building minimal yet interoperable IP- capable devices for the most constrained environments. LPWAN IPv6 over TSCH Charter is to develop best practice and Architecture for IPv6 over 802.15.4 TSCH.6TiSCH
24 • 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
25 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 LPWAN Thread ZigBee/IP
26 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:
27 • 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
28 • 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
29 • 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 https://tools.ietf.org/html/rfc7668 https://tools.ietf.org/html/rfc8105 https://tools.ietf.org/html/rfc7428 https://tools.ietf.org/html/draft-hou-6lo-plc https://tools.ietf.org/html/draft-ietf-6lo-nfc https://tools.ietf.org/html/rfc8163 https://tools.ietf.org/html/draft-delcarpio-6lo-wlanah https://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
30 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-ietf-6lo-rfc6775-update we claim that Low Power Wi-Fi is an LLN link
31 Preamble SPD PHY Header Auxiliary Security Header Payload FCS Frame Control Data Seq. Nbr Addressing Simple MAC allows coexistence with other network protocols over same link, similar to Ethernet, although not seen in deployment IEs Header & Payload DST PAN ID Mesh Address 6LoWPAN Compressed Hdr Payload DST MAC Address SRC PAN ID SRC MAC Address 11000 00 10 01 11 Not a LoWPAN frame LoWPAN Header Dispatch (DSP) LoWPAN mesh Hdr LoWPAN fragmentation Hdr and other stuff 1st Frag. 6LoWPAN Compressed Hdr Payload 1st Frag. 6LoWPAN Compressed Hdr Payload IPHC Other 6LoWPAN Hdr field Payload Header Dispatch (DSP) – understand what is coming Mesh AddressMesh + Fragmentation Frame Fragmentation Mesh (L2 Routing) 6LoWPAN 01 10 11000 01 01 6LoWPAN Compressed Hdr 01 01
32 3 00 xxxxxx 0 Not a LoWPAN RFC 4944 1-14 Unassigned 15 Experimental Use RFC 8025 01 000000 0 ESC RFC 6282 1-14 Unassigned 15 Experimental Use RFC 8025 01 1xxxxx 0-1 IPHC RFC 6282 2-14 Unassigned 15 Experimental Use RFC 8025 Bit Pattern Page Header Type Reference 11 11xxxx 0-15 Page switch RFC 8025 … … … … … …
33 3 0 1 1 HLIM SAM DAM 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 10 TF 2 bits Traffic Class and Flow Label NH 1 bit Next Header HLIM 2 bits Hop Limit CID 1 bit Context Identifier Extension SAC 1 bit Source Address Context SAM 2 bits Source Address Mode M 1 bit Multicast Address Compression DAC 1 bit Destination Address Context DAM 2 bits Destination Address Mode CIDTF NH SAC M DAC DSP Addressing
34 3 1st Frag. Payload Frame Fragmentation 6LoWPAN + RPL Page 1 switch IPHC Other 6LoWPAN Hdr field DSP 11000 6LoRH Payload Page 1 switch IPHC Other 6LoWPAN Hdr field DSP6LoRH RH3-6LoRH RPI-6LoRH IP-in-IP-LoRH
35 6LR 6LBRLP Node NS (ARO) DAR (ARO) SRC = 6LR DST = 6LBR REG = LPN UID = LPN SRC = LPN_ll DST = 6LR_ll TGT = ?? SLLA = LPN UID = LPN Check Collision of binding state (DAD) NA (ARO, s=1) DAC (ARO, s=0,1==dup) SRC = 6LR DST = 6LBR REG = LPN UID = LPN SRC = 6LR_ll DST = LPN_ll TGT = LPN TLLA = LPN UID = LPN 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length = 2 | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Registration Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + EUI-64 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A registration mechanism For duplicate detection Goal to save multicast Being updated Address Registration Option Radio Mesh Radio 1 Hop
36 Scalable and Multi-Link Deterministic e2e IP guard (admin knows what’s where) => Authoritative Registrar(s) Backbone Routers RPL root, ND proxy Legacy IPv6 devices Authoritative Registrar Authoritative Registrar / 6LBR Intermediate Registrar / 6LR Intermediate Registrar option. ND proxy Backbone router (ND proxy)
37 6LoWPAN is an open standard, NOT a silo’ed solution 6LoWPAN is how you do IPv6 over low-power lossy networks Provides an Adaptation Layer and a novel IPv6 Neighbor Discovery 6LoWPAN started small with the 802.15.4-2003 WPAN Updated to fit in ISA100.11a, used in Thread, ZigbeeIP, … Now generalizing on all LLN technologies with IETF 6lo GW
38
39 • Reduces frame loss  Time and Frequency Diversity  Reduces co-channel interference • Optimizes bandwidth usage  No blanks due to IFS and CSMA-CA exponential backoff  While Increasing the ratio of guaranteed critical traffic • Saves energy  Synchronizes sender and listener  Thus optimizes sleeping periods  By avoiding idle listening and long preambles
40 Controlling time of emission Can achieve ~10ms sync on 802.15.4 Can guarantee time of delivery Protection the medium ISM band crowded, no fully controlled all sorts of interferences, including self Can not guarantee delivery ratio Improving the Delivery ratio Different interferers => different mitigations Diversity is the key
41 Code diversity Code Division Multiplex Access Network Coding (WIP) Frequency diversity Channel hopping B/W listing Time Diversity ARQ + FEC (HARQ) TDM Time slots Spatial diversity Dynamic Power Control DAG routing topology + ARCs Duo/Bi-casting (live-live) Use all you can!
42 16channeloffsets e.g. 31 time slots (310ms) A BC D E F G H I J Schedule every transmission (they all do it!) to maintain the medium free at critical times e.g. TDM, and TimeSlotted Channel Hopping (TSCH) Used in wireless HART, ISA100.11a and 6TiSCH
43 Source: DUST Networks / Linear Technology With TSCH, ARQ (retries) are scheduled at different times over different channels to maximize diversity.
44 Type of traffic Type of MAC Deterministic (e.g. Control Loops) Stochastic (e.g. classical IP) Deterministic (e.g. 802.15.4 TSCH) Good fit Adapted to centralized routing and fully scheduled operation All industrial protocols are here Difficult but achievable: requires dynamic allocation of transmission resources (6TiSCH) Stochastic (e.g. Zigbee, Wi-Fi) Problems with channel access (guard time) Lead to gross over-provisioning CSMA cannot provide hard guarantees Good fit Adapted for IP traffic, distributed routing and statistical multiplexing with RED
46 • 6TiSCH also specifies an IPv6-over-foo for 802.15.4 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.4 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
47 Scope • Radio Mesh: Range extension with Spatial reuse of the spectrum • TSCH with Centralized routing, optimized for Time-Sensitive flows  Mission-critical data streams (control loops)  Deterministic reach back to Fog for virtualized loops  And limitations (mobility, scalability) • RPL Distributed Routing and scheduling for large scale monitoring  Enabling co-existence with IPv6-based Industrial Internet  Separation of resources between deterministic and stochastic Leveraging IEEE/IETF standards (802.15.4, 6LoWPAN …)
48 Deterministic IPv6 over IEEE802.15.4 TimeSlotted Channel Hopping (6TiSCH) The Working Group will focus on enabling IPv6 over the TSCH mode of the IEEE802.15.4 standard. The scope of the WG includes one or more LLNs, each one connected to a backbone through one or more LLN Border Routers (LBRs). 6TiSCH also specifies an IPv6-over-foo for 802.15.4 TSCH but does not update 6LoWPAN (that’s pushed to 6lo). Rather 6TiSCH defines the missing Data Link Layer. The 6TiSCH architecture defines the Layer-3 operation. It incorporates 6LoWPAN but also RPL, DetNet (PCE) for deterministic networking, COMAN, SACM, CoAP, DICE … => Mostly NOT specific to 802.15.4 TSCH WG charter
49 6TiSCH has to make components work together and push new work https://tools.ietf.org/html/draft-ietf-6lo-backbone-router https://tools.ietf.org/html/draft-ietf-6lo-rfc6775-update https://tools.ietf.org/html/draft-thubert-6lo-forwarding-fragments https://tools.ietf.org/html/draft-ietf-roll-dao-projection Active 6TiSCH drafts and RFCs https://tools.ietf.org/html/rfc7554 https://tools.ietf.org/html/rfc8180 (Minimal support, slotted Aloha) https://tools.ietf.org/html/draft-ietf-6tisch-terminology https://tools.ietf.org/html/draft-ietf-6tisch-architecture https://tools.ietf.org/html/draft-ietf-6tisch-6top-sfx https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-secure-join WG deliveries
50 Centralized route and track computation and installation Management and Setup Discovery Pub/Sub Authentication for Network Access Wireless ND (NPD proxy) Time Slot scheduling and track G-MPLS forwarding Distributed route and track computation and installation Distributed route and track computation and installation IEEE 802.15.4 TSCH 6LoWPAN HC IPv6 RPL 6top TCP UDP ICMP CCAMP PCEP/PCC CoAP/DTLS AAA 6LoWPAN ND }
51
52 BBR A BBR B BBR C BBR D
53 BBR A BBR B BBR C BBR D
54 6TiSCH Backbone Router Intelligent device Management Wireless Controller Backbone Router Limit of IPv6 subnet(s)Limit of IPv6 subnet End to end IPv6 routing NAC /Firewall VPN Concentrator
55 6TiSCH 6TiSCHSensor Actuator Backbone Router Management Wireless Controller Backbone Router Single Multilink IPv6 Subnet with free inner mobility (same subnet == no renumbering) Virtual Service Engine (virtual PLC, PCE …) + IPv6 ND registrar + Network Function Virtualization (NFV) NAC /Firewall VPN Concentrator IPv6 ND registration and proxy operation Full virtualization and chaining
56 Routing Concepts
57
58 • Hidden terminal • Interference domains grows faster that range • Density => low power => multihop => routing
59 Centralized: A controller sets up the routes Pros God’s view, enables global optimization Elastic resource management / NFV Traffic Engineering, may compute per flow paths Non Equal Cost Multipath, Replication & Elimination Cons Delays learning about breakage Delays fixing breakage NP complete optimization => limits scalability Distributed: A routing protocol sets up the routes Pros Since ARPANET, enables high resilience Different IGPs for different needs Installed base Cons Microloops Tends to build crowded avenues, wastes bandwidth Same costs for all, NECM difficult, manual TE Need additions for reroute / fast reroute
60 Aka Stateful vs. On-demand routing Note: on-demand breaks control vs. Data plane separation P2P-RPL RIP IS-IS AODV-RPL
61 LS requires full state and convergence Every node draws a same graph Then run the 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 topological complexities and changes DV enables multiple NECM feasible successors RIP IS-IS
62 Stateful: routing decision at every hop Pros Resilient (DARPA), autonomic Cons Requires routing state in every router Tends to concentrate flows Routing Loops Source Routing: The path is in the packet Pros Saves state in routers Enables per flow routing (segment routing) Cons Larger packets / Source Route Header (SRH)
63 0 Optimized Routing Approach (ORA) spans advertisements for any change Routing overhead can be reduced if stretch is allowed: Least Overhead Routing Approach (LORA) => (Nothing to do with the LoRa LPWAN protocol !!!) For instance Fisheye and zone routing provide a precise routing when closeby and sense of direction when afar
64 • Conventional routing protocols are Greedy Meaning that a packet must always “progress” towards a destination for a particular metric This causes issues like micro-loops or freezing when the greedy path is lost • Fast Reroute enables lossless rerouting of packets FR may require a step back before progressing again Made possible by new routing approaches (see LFA, ARC and MRT) Can also use Tunnels / Source Routing around (see Segment Routing) PLAN B can be computed centrally
65
66 Most classical routing structure Typically what Internet Gateway Protocols (IGPs) Build or each reachable destination Only thing Link State builds, though Distance Vector has feasible successors Must be reconstructed upon connectivity loss, service is interrupted FRR techniques must be added (MRT, LFA with SR …) on top No inner load balancing capabilities Walkable structure (e.g. depth first) ROOT 5 4 4 0 1 3 1 1 2 2 2 2 23 3 3 3 3 2 4 4 5 0 6 5 4 ROOT
67 In the context of routing, a Directed Acyclic Graph (DAG) is formed by a collection of vertices (nodes) and edges (links). Each edge connecting one node to another (directed) in such a way that it is not possible to start at Node X and follow a directed path that cycles back to Node X (acyclic). Greedy => Not all nodes have 2 solutions even in biconnected networks A Destination Oriented DAG (DODAG) is a DAG that comprises a single root node. Here a DAG that is partitioned in 2 DODAG Clusterhead 5 4 4 0 1 3 1 1 2 2 2 2 2 3 3 3 3 3 3 2 4 4 5 0 6 5 4
68 • In Green: A’s subDAG. Impacted if A’s connectivity is broken Domain for routing recovery • In Red: B’s fanout DAG (or reverse subDAG) Potential SPAN on B’s DAO Thus potential return paths Fanout must be controlled to limit intermediate states Clusterhead 5 4 4 0 1 3 1 1 2 2 2 2 2 3 3 3 3 3 3 2 4 4 5 0 6 5 4 A B
69 Clusterhead 5 Clusterhead 0 1 1 1 2 2 2 2 2 3 3 3 3 3 3 2 3 5 4 4 4 4 e.g. ARC of siblings Allows more alternates ARCs and walkable structures in general are walked with no routing progress Routing between DAGs of ARCs Forwarding over DAG AND ARCs Reduces congestions of upper links of the DAG Still LORA for P2P IGP subarea (bidirectional) Link selected and oriented by TD Potential link
70
71 1000*scale => No leak in Internet => Opaque operations Reachability => Radio (IEEE) Addressing => IPv6 (IETF) Density => spatial reuse => Routing
72 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
73 Potentially Large Peer Set Highly Variable Capabilities Selection Per Objective Metrics (e.g. RSSI, ETX…) L3 Reachability (::/0, …) Constraints (Power …)
74 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)
75 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
76 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
78 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
79 RPL (RFC 6550 and then more)
80 Dynamic Topologies Peer selection Constrained Objects Fuzzy Links Routing, local Mobility Global Mobility Low Power Lossy Networks Issues Addressed in RPL ?
81 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)
82 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
83
84 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).
85 5 3 5 4 RPL Instance Consists of one or more DODAGs sharing SAME service type (Objective Function) Identified by RPL INSTANCE ID UP(DAOMessages) DODAG Root Identified by DODAG ID (Node IPv6 address) Direction Oriented DAG (DODAG) Comprises DAG with a single root Rank Towards DODAG Root Rank = n Rank < n Node (OF configured) 2 1 5 4 3 3 Rankdecreases DODAG parent to child “5”s 2 DODAG Root Rank is always “1” (Typically an LBR - LLN Border Router) 1 3 2 Sub- DODAG DODAG DOWN(DIOMessages) Towards DODAG leafs Rank > n Rank = n Rankincreases Non-LLN Network (IPv6 Backbone) Siblings 44 DODAG Sensor Node
86 At a given point of time connectivity is as illustrated and rather fuzzy Radio link
87 Clusterhead 1st pass (DIO) Establishes a logical DAG topology Trickle Subnet/config Info Sets default route Self forming / self healing This is what nay classical DV will do but for all destinations not just the root 2nd pass (DAO, in storing mode) paints with addresses and prefixes Any to any reachability But forwarding over DAG only saturates upper links of the DAG And does not use the full mesh properly Link selected as parent link Potential link Clusterhead 0 1 1 1 4 4 4 46 3 3 3 3 3 2 2 2 2 2 2 5 5 5
88 : : 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
89 Clusterhead A’s link to root fails A loses connectivity Either poisons or detaches a subdag In black: the potentially impacted zone That is A’s subDAG Link selected as parent link Potential link Clusterhead 0 1 1 1 4 4 4 46 3 3 3 3 3 2 2 2 2 2 2 5 5 5 A 1 1 1 3 3 3 3 3 2 2 2 2 2 2 5 5 5 4 4 4 4
90 Clusterhead B can reparent a same Rank so B’s subDAG is safe The rest of A’s subDAG is isolated Either poison ar build a floating DAG as illustrated In the floating DAG A is root The structure is preserved Link selected as parent link Potential link Clusterhead 0 1 1 4 4 4 46 3 3 3 2 2 2 2 2 2 1 5 5 5 A B 0 1
91 Clusterhead Once poisined nodes are identified It is possible for A to reparent safely A’s descendants inherit from Rank shift Note: a depth dependent timer can help order things Link selected as parent link Potential link Clusterhead 0 1 1 2 4 4 4 46 3 3 3 4 4 2 2 2 2 3 3 5 5 5 A
92 Clusterhead A new DAG iteration In Green, the new DAG progressing Metrics have changed, the DAG may be different Forwarding upwards traffic from old to new iteration is allowed but not the other way around Link selected as parent link Potential link Clusterhead 0 1 1 1 4 4 4 46 3 3 3 3 3 3 2 2 2 2 2 5 5 5
93 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
94
95 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
96 Extend the generic behavior For a specific need / use case Used in parent selection Contraints Policies Position in the DAG Metrics Computes the Rank increment Based on hop metrics Do NOT use OF0 for adhoc radios! (OF 0 uses traditional weighted hop count)
97 Clusterhead 5 4 4 A second root is available (within the same instance) The DAG is partitioned 1 root = 1 DODAG 1 Node belongs to 1 DODAG (at most, per instance) Nodes may JUMP from one DODAG to the next Nodes may MOVE up the DODAG Going Down MAY cause loops May be done under CTI control Link selected and oriented by DIO Potential link 0 1 3 1 1 2 2 2 2 2 3 3 3 3 3 3 2 4 4 5 0 6 5 4
98 Running as Ships-in-the-night 1 instance = 1 DAG = 1 OF A DAG implements a set of constraints Multiple instances may be serving different Objective Functions => For different optimizations Forwarding is along a DODAG => Provides isolation like a vlan Clusterhead 0 1 1 1 2 2 2 2 2 3 3 3 3 3 3 2 3 5 4 4 4 4 Clusterhead Constrained instance Default instance Potential link A
99
100 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICMP Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Base Object . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Option(s) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0x00 (DIS) DODAG Information Solicitation 0x01 (DIO) DODAG Information Object 0x02 (DAO) Destination Advertisement Object 0x03 (DAO-ACK) Destination Advertisement Object Acknowledgment 155 == RPL control message
101
102 Flooding interferes with itself B C D A Hidden node/terminal/station
103 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
104 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
105 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)... +-+-+-+-+-+-+-+-+
106 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)... +-+-+-+-+-+-+-+-+
107 +-----+-----------------------------------------------------+ | 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 | | 4 | P2P Route Discovery Mode of Operation (RFC 6997) | | | | | | All other values are unassigned | +-----+-----------------------------------------------------+
108 Storing: Stateful Advertisement Tell about self and all children to parents Pros Lower route stretch Cons Consumes uncontrolled memory Non-Storing: Source Routing Advertisement Tell about self and parents to root Pros Enables per flow routing (segment routing) Cons Larger packets / Source Route Header (SRH)
109
110 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | Option(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: The DIS Base Object Options: 0x00 Pad1 0x01 PadN 0x07 Solicited Information Goal: ask routers around to generate DIO
111 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 | +-+-+-+-+-+-+-+-+
112 draft-ietf-roll-dis-modifications Based on earlier work draft-goyal-roll-dis-modifications New Flags to control Trickle behavior response mode Unicast vs. Broadcast Metric Container for constraints on the responder Response Spreading Option to spread responses over an interval
113
114 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
115 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
116 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Src: 51 Dest: 52 Stuff RPI
117 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)... +-+-+-+-+-+-+-+-+
118 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
119 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
120 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-... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
121 +- ... -+- ... -+-+-+-+-+- ... -+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+... |11110001| RPI-6LoRH | NH = 0 | NH = 58 | ICMP message |Page 1 | type 5 | 6LOWPAN-IPHC | (ICMP) | (no compression) +- ... -+- ... -+-+-+-+-+- ... -+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+... <- RFC 6282 -> No RPL artifact IPv6 header HbH header ICMP header ICMP PayloadRPL option <=>
122 +- ... -+- ... -+-+-+-+- ... +-+-+-+-+-+-+-+-+-+- ... +-+-+-+-+-+... |11110001| RPI-6LoRH | NH = 1 |11110|C| P | Compressed | UDP |Page 1 | type 5 | 6LOWPAN-IPHC | UDP | | | UDP header |Payload +- ... -+- ... -+-+-+-+- ... +-+-+-+-+-+-+-+-+-+- ... +-+-+-+-+-+... <- RFC 6282 -> IPv6 header HbH header UDP header UDP PayloadRPL option <=>
123
124 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::BA::B A::C A::D A::A A: (root) A::A self A::B connected A::C via A::B A::D via A::B A:: ~onlink A::D via A::B connected
125 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
126 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Src: X Dest: 56 Via: 13 Via: 24 Stuff Src: X Dest: 56 Stuff Via: 35 Via: 46 Src: Root Dest: 56 RPI
127 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Src: X Dest: 52 Via: 11 Via: 22 Stuff Src: 51 Dest: 52 Stuff Via: 32 Via: 42 Src: 51 Dest: Root RPI Src: Root Dest: 56 RPI Src: 51 Dest: 52 Stuff RPI OR
128
129 (Hateful stuff) Only end points may add / remove headers Some headers are mutable (and if they are recoverable they may be secured) e.g. of mutable and partially recoverable is RPI (to secure the instance ID) So IP in IP is required If the packet leaves the RPL domain since HbH header must be removed If the packet enters the RPL domain since HBH header or RH3 must be inserted In non storing mode for a packet not going to or from the root (RPI to RH3 conversion at root). https://tools.ietf.org/html/draft-robles-roll-useofrplinfo-02
130 Not a critical header, may be skipped so Length is in bytes. Placed last in the header chain. 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. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
131 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. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type | Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CmprI | CmprE | Pad | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Addresses[1..n] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3
132 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ |1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ Size indicates the number of compressed addresses +-----------+----------------------+ | 6LoRH | Length of compressed | | Type | IPv6 address (bytes) | +-----------+----------------------+ | 0 | 1 | | 1 | 2 | | 2 | 4 | | 3 | 8 | | 4 | 16 | +-----------+----------------------+ Packet source is reference for compression Different compressed size => multiple RH3-6LoRH Placement first in the chain to be easily consumed as we go (address coalescence)
133 +- ... -+- ... -+-+-+- ... -+-+-+-+-+ ... +-+-+-+-+-+-+ ... +-+-+... |11110001|RH3(128bits)| RH3(3*16bits) |NH=1 |11110CPP| Compressed | UDP |Page 1 | 6LoRH | 6LoRH |6IPHC| UDP | UDP header | Payload +- ... -+- ... +-+-+-+- ... -+-+-+-+-+ ... +-+-+-+-+-+-+ ... +-+-+... <- RFC 6282 -> Note: With RPL this is only when the source is the root IPv6 header UDP header UDP Payload <=> Routing hdr Hop Hop Dec.Hop
134 RRRRRRRRRRRRRRRRRRRR ++ CCCCCCC -------------------- RRRRRRRRRRRRRCCCCCCC RR…RRRR is reference address for compression, may be compressed or not CCC…CC is compressed address, to shorter or same size as reference RR…RRCCC…CC is the Coalesced address, same size as reference
135 Leaving the root: Leaving A Leaving B C removes the header and the IP-in-IP if nothing else in IP-in-IP B’s suffix RH3-6LoRH Type 4 RH3-6LoRH Type 3 IPv6 Prefix B’s suffix C’s suffix A’s suffixRH3-6LoRH Type 4 IPv6 Prefix C’s suffix RH3-6LoRH Type 4 RH3-6LoRH Type 3 IPv6 Prefix B’s suffix A’s suffix C’s suffix Root = encaps B C = decaps DestA
136 +- ... -+-+- ... -+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+... |11110001| RH3(128bits)| RH3(2*16bits)| RFC 6282 Dispatch |Page 1 | 6LoRH type 4| 6LoRH Type 1 | + LOWPAN_IPHC +- ... -+- ... +-+-+-+- ... -+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+... <- RFC 6282 -> +-----------+-----------+ | Type | Size Unit | +-----------+-----------+ | 0 | 1 | | 1 | 2 | | 2 | 4 | | 3 | 8 | | 4 | 16 | +-----------+-----------+ <=> IPv6 header Routing header Hop Hop Dec.Hop Hdrs + Payload
137 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
138 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
139 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
140 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.
141 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.
142 •+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+... •|Frag type|Frag hdr |11110001| RPI | IP-in-IP | RFC 6282 Dispatch •|RFC 4944 |RFC 4944 | Page 1 | 6LoRH | 6LoRH | + LOWPAN_IPHC •+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+... • <- RFC 6282 -> • •+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+... •|Frag type|Frag hdr | •|RFC 4944 |RFC 4944 | Payload (cont) •+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+... •+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+... •|Frag type|Frag hdr | •|RFC 4944 |RFC 4944 | Payload (cont) •+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+... <=> IPv6 header HbH header IPv6 header Hdrs + PayloadRPI in RPL option
143 +-+-+-+-+-+-+- ... +-+-+- ... -+-+-- ... -+-+- ... -+-+-+-+-+ ... +-+-+-... |11110001 |SRH-6LoRH | RPI-6LoRH | IP-in-IP | NH=1 |11110CPP| UDP | UDP |Page 1 |Type1 S=2 | | 6LoRH | IPHC | UDP | hdr |payload +-+-+-+-+-+-+- ... +-+-+- ... -+-+-- ... -+-+- ... -+-+-+-+-+ ... +-+-+-... <-8bytes-> <- RFC 6282 -> No RPL artifact One may note that the RPI is provided. This is because the address of the root that is the source of the IP-in-IP header is elided and inferred from the InstanceID in the RPI. Once found from a local context, that address is used as Compression Reference to expand addresses in the RH3-6LoRH. <=> IPv6 header UDP hdr UDP PayloadRouting hdr Hop Dec.HopHbH RPIIPv6 header
144 New Work on RPL
145
146 • Adds Centralized routing (Traffic Engineering) to RPL E.g. Root coordinates with PCE • Add limited Storing in Non-Storing mode and vice versa Enough topology info in non-storing route optimization at the root Local compression; RPL source route header becomes loose • Also support for transversal route in Storing Mode Works for storing and non storing routes • Need topological information and / or device constraints e.g. how many routes can a given RPL router store?
147
148 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Src: X Dest: 56 Via: 13 Via: 24 Stuff Src: X Dest: 56 Stuff Via: 35 Via: 46 Src: Root Dest: 56 RPI
149 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 New (projected) DAO with path segment unicast to target 56 via 35 (ingress) and 46 (egress) 56
150 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Storing mode DAO with lifetime along segment
151 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 DAO-ACK (alt: non storing DAO) unicast, self 35 as parent, final destination 56 as target
152 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 DAO from 46 installs a route to 56 in 35 (all nodes in projected route from ingress included to egress excluded) => egress should already have a route to target 56 via 46 Preexisting connected route to 56
153 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Non source routed DATA Path
154 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Non source routed DATA Path Loose Source routed DATA Path Packet to 13, RH 24, 35, 56
155 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Src: X Dest: 56 Via: 13 Via: 24 Stuff Src: X Dest: 56 Stuff Via: 35 Src: Root Dest: 56 RPI Via: 46
156 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 Adding New (projected) DAO with path segment unicast to target 56 via 13 (ingress), 24, and 35 (egress) 56
157 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Storing mode DAO (forced) with lifetime along segment Storing mode DAO with lifetime along segment
158 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 DAO-ACK unicast, self 13 as parent, final destination 56 as target
159 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 56 via 46 Preexisting connected route to 56 56 via 35 56 via 24
160 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Non source routed DATA Path
161 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Src: X Dest: 56 Via: 13 Via: 24 Stuff Src: X Dest: 56 Stuff Via: 35 Src: Root Dest: 56 RPI Via: 46
162 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 ALT: Adding New (projected) DAO with path segment unicast to target 35 via 13 (ingress) and 24 (egress) 56
163 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Storing mode DAO with lifetime along segment
164 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 DAO-ACK unicast, self 13 as parent, final destination 56 as target
165 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 56 via 46 Preexisting connected route to 56 Preexisting connected route to 35 35 via 24
166 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 routed DATA Path Loose Source routed DATA Path Packet to 35, RH 56 routed DATA Path
167 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Src: X Dest: 56 Via: 13 Via: 24 Stuff Src: X Dest: 56 Stuff Via: 35 Src: Root Dest: 56 RPI Via: 46
168
169
170 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56
171 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56
172 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56
173 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 New non-storing P-DAO with path segment unicast to target 41 via 42 + 43
174 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 DAO ACK
175 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Packet for 41
176 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 IP in IP encapsulation with SRH 42, 41
177 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 storing P-DAO with path segment unicast to target 51 via 41 (egress)
178 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Packet for 51
179 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 IP in IP encapsulation with SRH 42, 41
180 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Packet for 51
181
182 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56
183 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56
184 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56
185 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 New (projected) DAO with path segment unicast to target 53 via 41 (ingress), 42 and 43 (egress)
186 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Storing mode DAO with lifetime along segment
187 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Storing mode DAO with lifetime along segment
188 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 DAO-ACK unicast, self 41 as parent, final destination 53 as target
189 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56
190
191 • In conventional IP multicast forwarding, the packets of a given multicast "flow" are forwarded along a tree that has been constructed for the specific purpose of carrying that flow. This requires transit nodes to maintain state on a per-flow basis, and requires the transit nodes to participate in multicast-specific tree building protocols. The flow to which a packet belongs is determined by its IP source and destination address fields. • BIER (Bit Index Explicit Replication) is an alternative method of multicast forwarding. It does not require any multicast-specific trees, and hence does not require any multicast- specific tree building protocols. Within a given "BIER domain", an ingress node encapsulates a multicast data packet in a "BIER header". • The BIER header identifies the packet's egress nodes in that domain. Each possible egress node is represented by a a single bit within a bitstring; to send a packet to a particular set of egress nodes, the ingress node sets the bits for each of those egress nodes, and clears the other bits in the bitstring. Each packet can then be forwarded along the unicast shortest path tree from the ingress node to the egress nodes. Thus there are no per-flow forwarding entries.
192 • A Bloom filter is a space-efficient probabilistic data structure, conceived by Burton Howard Bloom in 1970, that is used to test whether an element is a member of a set. False positive matches are possible, but false negatives are not – in other words, a query returns either "possibly in set" or "definitely not in set". Elements can be added to the set, but not removed (though this can be addressed with a "counting" filter); the more elements that are added to the set, the larger the probability of false positives. • draft-ietf-roll-ccast-01 Constrained-Cast: Source-Routed Multicast for RPL uses Bloom filters as a compressed form of a bitmap. It is Source-Routed minded so the elements in the set are the hops as opposed to the destinations. A packet is forwarded if the downward link appears to belong to the set. A false positive has a packet going deeper than it should. IOW Bloom trades space in the packet with unwanted transmissions.
193
194 BBR A BBR B BBR C BBR D
195 BBR A BBR B BBR C BBR D
196 BBR A BBR B BBR C BBR D
197 B A F G H I J C D E K
198 B A F G H I J C D E K I’m F, my parent is B
199 B A F G H I J C D E K Target Transit J K I K E K D E C D B C F B A B …
202 BBR D 00000000001 00000000100 00010000000 00000000010 00000010000 00100000000 00001000000 00000001000 00000100000 01000000000 10000000000
203 Addres s Bit A 9 B 11 C 8 D 6 E 2 F 4 G 10 H 7 I 3 J 5 K 1 BBR D 00000000001 00000000100 00010000000 00000000010 00000010000 00100000000 00001000000 00000001000 00000100000 01000000000 10000000000 B A F G H I J C D E K
204 BBR D 00010000101 00000000100 00010000000 00000000010 00000010010 00100000000 00001000000 00010001101 00010101101 11010111111 11111111111 B A F Node sends a DAO to its parent, advertising: n Node’s bitmap = OR (child I’s bitmap) OR Node’s bit i=1 K
205 BBR D 00010000101 00000000100 00010000000 00000000010 00000010010 00100000000 00001000000 00010001101 00010101101 11010111111 11111111111 B A F B sends a DAO to its parent, advertising B’s bitmap = (A’s bitmap OR F’s bitmap OR B’s bit) K
206 BBR D 00010000101 00000000100 00010000000 00000000010 00000010010 00100000000 00001000000 00010001101 00010101101 11010111111 11111111111 B A F Child BitMap A 00000000100 F 00010000000 K
207 BBR D 00010000101 00000000100 00010000000 00000000010 00000010010 00100000000 00001000000 00010001101 00010101101 11010111111 11111111111 B A F Child BitMap E 11010111111 I 00100000000 J 00001000000 K I J E
208 BBR D 00010000101 00000000100 00010000000 00000000010 00000010010 00100000000 00001000000 00010001101 00010101101 11010111111 11111111111 B A F K I J E Root computes destination bitmap as: n Dest bitmap = OR (node i’s bit) i=1
209 BBR D 00010000101 00000000100 00010000000 00000000010 00000010010 00100000000 00001000000 00010001101 00010101101 11010111111 11111111111 B A F K I J E Node computes (Dest bitmap AND child’s bitmap) for all children When result is TRUE (non-zero), node copies the packet as a MC level unicast to child.
210 BBR D 00010000101 00000000100 00010000000 00000000010 00000010010 00100000000 00001000000 00010001101 00010101101 11010111111 11111111111 B A F K I J E If most of the children are targeted, it makes sense to broadcast the message to all children. In that case, receiving children perform the OR operation with the bitmap they advertise in DAO and drop on receive is the result is not TRUE
211 BBR D 00010000101 00000000100 00010000000 00000000010 00000010010 00100000000 00001000000 00010001101 00010101101 11010111111 11111111111 B A F K I J E Root computes destination bitmap as Dest bitmap = (A’s bit OR F’s bit OR J’s bit) = 00011000100
212 BBR D 00010000101 00000000100 00010000000 00000000010 00000010010 00100000000 00001000000 00010001101 00010101101 11010111111 11111111111 B A F K I J E Dest bitmap = 00011000100 (Dest bitmap AND J’s bitmap) = 00001000000 -> MAC unicast to J (Dest bitmap AND I’s bitmap) = 00000000000 -> NO copy to I (Dest bitmap AND E’s bitmap) = 00010000100 -> MAC unicast to E
213 BBR D 00010000101 00000000100 00010000000 00000000010 00000010010 00100000000 00001000000 00010001101 00010101101 11010111111 11111111111 B A F K I J E Dest bitmap = 00011000100 In B: (Dest bitmap AND B’s bitmap) = most bits set -> B broadcasts In A: (Dest bitmap AND A’s bitmap) = 00000000100 -> A accepts In F: (Dest bitmap AND F’s bitmap) = 00010000000 -> F accepts
214
215 Source S (J is 00001000000) Packet to 00011000100 B A F K I J E Root computes destination bitmap as Dest bitmap = (A’s bit OR F’s bit OR J’s bit) = 00011000100 Forwarding expected to follow (A is 00000000100) (F is 00010000000) Packet to 00011000100
216 Source S Ack = 00001000000 B A F K I J E Acks are aggregated on the return path Ack = 00011000100 Ack = 00010000000 Ack = 00000000100 Ack = 00010000100 Ack = 00010000100
217 Source S 00001000000 Packet to 00011000100 B A F K I J E loss on the way in the branch that leads to A and F 00000000100 00010000000
218 Source S Ack = 00001000000 B A F K I J E Ack = 00001000000 Root computes destination bitmap – ack bitpmap Retrans bitmap = Dest bitmap - Ack bitmap = 00011000100 - 00001000000 = 00010000100
219 Source S (J is 00001000000) Packet to 00010000100 B A F K I J E Retransmission bitmap indicates only along failed branch(es) Forwarding expected to follow (A is 00000000100) (F is 00010000000) Packet to 00010000100
220 Source S B A F K I J E Acks are aggregated on the return path Ack = 00010000100 Ack = 00010000000 Ack = 00000000100 Ack = 00010000100 Ack = 00010000100
221
222 Root Rank 1 Rank 110 P: Rank 250 Rank 260 B: Rank 530 D: Rank 510 C: Rank 610 E: Rank 620 A: Rank 380 Initial situation; • Rank is computed on some metric e.g. LQI. • Node A has a single parent, node P • A can hear D and C which are in its subdag • A can hear B and E which are not
223 Root Rank 1 Rank 110 P: Rank 250 Rank 260 A: Rank 380 B: Rank 530 D: Rank 510 C: Rank 610 E: Rank 620 Say that the radio connectivity between A and P dies. A looses it only feasible parent. Its neighbors are all deeper (higher Rank) so it cannot reattach without risking a loop. Attaching to D and C would create a loop. Attaching to E or B would not create a loop. Trouble is A does not know. 223
224 Root Rank 1 Rank 110 P: Rank 250 Rank 260 B: Rank 530 D: Rank ∞ C: Rank ∞ E: Rank 620 RRFC 6550 says that node A must detach, freeze, and wait for the resulting of the freezing. Freezing may be done by poisoning, IOW sending infinite rank. A (preferable IMHO) alternative is to form a floating DAG, which spreads the freezing differently with the advantage to maintain the shape of the DODAG in place After some time, the devices that depended on A are (mostly) frozen or re-parented elsewhere. From that point, RPL says that the frozen nodes can all reparent, that’s A, D and C here, and then the network is fixed The problem is the “After some time” above. That is disruptive to traffic, which can be unacceptable A: Rank ∞ 224
225
226 Root Rank 1 Rank 110 P: Rank 250 Rank 260 B: Rank 530 D: Rank 510 C: Rank 610 E: Rank 620 A selects a number if neighbors as prospective parents. (Optional) We create a new RPI flag for loop detection. A sends packets using them randomly setting its Rank in RPI to OxFFFF, and sets a new RPI “P” flag. (Alt is set rank to 0xFFFE) A node that receives a packet with RPI “P” flag from a parent returns it with the RPI “F” flag set, indicating forwarding error and A removes it from the prospective parents. Alt, it may forward via another parent. During that period, A destroys any packet coming back with the RPI ”P” flag on. A: Rank 380 Proposal use to keep forwarding and to use the data path to detect lower nodes that are feasible successors: 226
227 Root Rank 1 Rank 110 P: Rank 250 Rank 260 B: Rank 530 D: Rank 510 C: Rank 610 E: Rank 620 Proposal use the datapath to select a parent faster: A selects a number if neighbors as prospective parents. We create a new OAM which allows A to “ping” the Poot. The packet indicates the selected parent. (Optional) The nodes that forward the packet add their IP address as a trace root A sends a version of that packet unicast to all the selected neighbors A: Rank 380 227
228 Root Rank 1 Rank 110 P: Rank 250 Rank 260 B: Rank 530 D: Rank 510 C: Rank 610 E: Rank 620 The messages that are responded by the root contain feasible successors. Getting that back may be slow. A picks them as they come, keeping the best so far as preferred parent A: Rank 380 228
229 Root Rank 1 Rank 110 P: Rank 250 Rank 260 B: Rank 530 D: Rank 510 C: Rank 610 E: Rank 620 Loops will cause the packet to come back to A. A recognizes them (e.g. source address is A, a new flag in RPI), and eliminates the neighbor indicated in the packet from the potential parents A: Rank 380 229
230
231 An Arc is a 2 ended reversible path Edges are directed outwards; links within are reversible An arc is resilient to any link or Junction break by returning links Links are oriented from cursor to edges and returned by moving the cursor. C Rev Rev Rev Rev EdgeCursor
232 An infrastructure Arc is multihop An Edge Junction terminates one reversible link An Intermediate Junction terminates two reversible links Links are oriented from a mobile cursor (C) Junction outwards R A collapsed Arc does not have an Intermediate Junction An Edge Junction may belong to multiple collapsed Arcs C Rev Rev Rev Rev Edge JunctionIntermediate Junction 232
233 Junctions may have multiple incoming links An Edge Junction might have multiple outgoing links An intermediate Junction has no outgoing link but along the Arc J C Rev Rev Rev Rev 233
234 ROOT A B Software-defined Projected ARROW Arcs for RPL Routing Over Wireless - Metrics are accumulated as usual in RPL (separated from Rank) - Siblings are allowed (all ARC members have the same Rank) - Rank of ARC members defines ARC height
235 - Sparrow requires non-storing mode (NS-mode). - Nodes must advertise at least 2 parents and report metrics - Root computes ARC Set based on NS-mode DAO - Need to update DAO projection to enable inverting parent->child links 235
236 R A D L B K J C E F G H I M M 236
237 In blue the preferred parent path In red the alt path as RPL computes them based on Rank relationship. These « arrows » are advertised to the root using NS-Mode We see that most nodes do not have 2 non-congruent solutions (in fact, only J does!) R A D L B K J C E F G H I M N Rank = 1 Rank = 3 Rank = 2 Rank = 4 Rank = 5 Rank = 6 Rank = 5 Rank = 7 Rank = 10 Rank = 8 Rank = 5 Rank = 10 Rank = 9 Rank = 10 Rank = 12 237
238 Original RPL DAG R A D L B K J C E F G H I M N ARC Re-organized DAG R A D L B K J C E F G H I Rev Rev Rev Rev Rev Rev M N Rev 238
239 DAG visualization == ARC visualization R A D L B K J C E F G H I M N R A D L B K J C E F G H I Rev Rev Rev Rev Rev Rev M N Rev 239
240 1) Root considers changes made on DODAG and notifies nodes, e.g. it tells C that D is not more a feasible successor and it tells D that C is a feasible successor. Same goes between E and F. This can be done with a novel variation of the DAO projection 2) For collapsed ARCs, e.g. D, we are all set 3) For other nodes that are not on collased ARCs, the root computes a path along the ARC towards the other exit of the ARC. For Node C that is Node B. R A D L B K J C E F G H I M N R A D L B K J C E F G H I Rev Rev Rev Rev Rev Rev M N Rev Use C as alt parent Do Not Use D as alt parent 240
241 1) The path to B is installed as either storing or non storing projected DAO 2) In NS Mode the source route path from the node to the other ARC edge is indicated to each node 3) In Storing Mode, a route is created from both ends of the ARC allowing each edge (a,d all nodes in between) to route to the other edge 4) If C loses connectivity to A, it uses a tunnel to B till RPL completes local repair. Tunnel has a routing header in NS mode. 5) When the Edge decaps, it must forward outside the ARC; it cannot reinject in the ARC. R A D L B K J C E F G H I Rev Rev Rev Rev Rev Rev M N Rev Non storing DAO: indicating Source Route path to B Source Route path to B Projected DAOR A D L B K J C E F G H I Rev Rev Rev Rev Rev Rev M N Rev DAO Ack Storing mode Route to B Projected DAO 241
242
243 • P2P RPL, RFC 6997 (experimental) DIO with one or more target options build a DODAG with a limited diameter Nodes that see a DAO back become participants and learn a path Other nodes forget about the DIO after a time out • AODV RPL (WIP) Similar but builds 2 DODAGs, one in each direction Expects asymmetrical links, different paths in both direction
244 In short
245 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:
246 Traffic Control Traffic Holes – Global Repair only Routing Table Sizes For Your Reference
247 • AODV RPL to be Standard track Reactive model (P2P RPL rfc6997 is experimental) • Centralized route computation (e.g. draft-ietf-roll-dao-projection ), SDN-Like • BIER unicast and multicast routing, Storing vs. Non-Storing, bit-index vs. Bloom Filters • DAG limitations and Fast Reroute 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
248 • 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 •
© 2012 Cisco and/or its affiliates. All rights reserved.IoT6 249Unclassified “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.”
© 2010 Cisco and/or its affiliates. All rights reserved. 250UnclassifiedBRKEWN-3012 Questions
Rpl2018
252 THX!
253 Extra material: The Backbone Router
254
255 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
256 Multiple L3 Multicast messages RA Multiple L2 Broadcast messages 1. MAC address reachability flooded over L2 switch fabric 2. Device sends RS to all routers link scope mcast 3. Router answers RA (u or m) 4. Device sends mcast NS DAD to revalidate its address(es) 5. Device sends mcast NA(O) 6TISCH uses a backbone router, limits the broadcast domain to the backbone VM, NFV,Wireless or IoT device moves:
257 Nbr Solicitation L3 Multicast L2 broadcast Packet to Target that is missing in router ND cache Nbr Advertisement Unicast 1. Router looks up ND cache (say this is a cache miss) 2. Router sends NS multicast to solicited-node multicast @; here that is 3333 FF00 00A1 1. Targets answers unicast NA 2. Target revalidates ND cache for the router, usually unicast 3. Router creates ND cache entry 6TiSCH proxies at the backbone router on behalf of device Packet comes in for 2001:db8::A1
258 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
259 Scalable and Multi-Link Deterministic e2e (DetNet) Registration based ND IP guard (admin knows what’s where) => Authoritative Registrar(s) Backbone Routers RPL root, ND proxy Legacy IPv6 devices Authoritative Registrar Authoritative Registrar / 6LBR Intermediate Registrar / 6LR Intermediate Registrar option. ND proxy Backbone router (ND proxy)
260 6TiSCH 6TiSCHSensor Actuator Backbone Router Management Wireless Controller Backbone Router Single Multilink IPv6 Subnet with free inner mobility (same subnet == no renumbering) Virtual Service Engine (virtual PLC, PCE …) + IPv6 ND registrar + Network Function Virtualization (NFV) NAC /Firewall VPN Concentrator IPv6 ND registration and proxy operation
261 Wireless Router Wireless Router Mesh Root Mesh Root Wireless RouterWireless Router
262
263 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 ) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
264 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
265 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
266 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)
267 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)
268 The BR maintains a route to the WSN node for the DAO Lifetime over instance VRF. VFR may be mapped onto a VLAN on the backbone. RPL DAO Host Route Optional NA(O)
269 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
270 DAD option has: Unique ID TID (SeqNum) Defend with NA if: Different OUID Newer TID NS DAD (ARO) NA (ARO) NS (ARO)
271 DAD option has: Unique ID TID (SeqNum) Defend with NA if: Different OUID Newer TID DAR NA (ARO) DAD
272 RPL DAO Optional NA(ARO) Host Route DAD option has: Unique ID TID (SeqNum) Defend with NA if: Different OUID Newer TID NA (ARO) with older TID (loses)
273 Packet NS lookup NA ARO option has: Unique ID TID (SeqNum) NA (ARO)
274 NS lookup Mixed mode ND BBR proxying over the backbone NA (ARO) Packet
275
276 6LR 6LBR 6BBR Router/Serv er LP Node RPL Ethernet RA (unicast) RA (u|mcast) DIO Router/Serv er Router/Serv er EthernetRadio 1 Hop SLLA PIO MTU SLLA CONTEXT PIO MTU SLLA CONTEXT PIO MTU RA (u|mcast) RS (mcast) PIO RA (u|mcast) PIO MTU SLLA CONTEXT
277 6LR 6LBR 6BBR Router/Serv er LP Node Radio Mesh Ethernet NA (~O) NS (ARO) NS (ARO) DAR, RPL DAO Router/Serv er Router/Serv er EthernetRadio 1 Hop NS lookup NS DAD NS (ARO) Create proxy state Classical NDRPL6LoWPAN ND Efficient ND NA (ARO) DAC (ARO) NA (ARO) 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er
278 6LR 6LBR 6BBR Router/Serv er LP Node RPL Ethernet NS DAD (ARO) NS (ARO) NS (ARO) DAR (ARO) Router/Serv er Router/Serv er EthernetRadio 1 Hop SRC = UNSPEC DST = SNMA TGT = LPN UID = LPN TID included SRC = 6LR * DST = 6LBR REG = LPN UID = LPN TID included SRC = LPN_ll * DST = 6LR_ll * TGT = LPN ** SLLA = LPN UID = LPN TID included SeND? SRC = 6LBR DST = 6BBR * TGT = LPN SLLA = L6BR UID = LPN TID included * Global / ULA * Can be Anycast Create binding state Create proxy state * link local unique EUI-64 ** any LPN IPv6 address RFC 6775 does not use target but src 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er
279 6LR 6LBR 6BBR Router/Serv er LP Node RPL Ethernet NA (O) * NA (ARO) NA (ARO) DAC (ARO) Router/Serv er Router/Serv er EthernetRadio 1 Hop SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = 6LR_ll DST = LPN_ll TGT = LPN TLLA = LPN UID = LPN TID included SRC = 6BBR DST = 6LBR TGT = LPN TLLA = L6BR UID = LPN TID included * Omitted in general ** link local DAD time out SRC = 6BBR_ll ** DST = NS SRC TLLA = L6BR TGT = LPN Adding TLLAO since dest. is not target 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er
280 6LR 6LBR 6BBR Router/Serv er LP Node RPL Ethernet NA (~O) NS (ARO) NS (ARO) RPL DAO Router/Serv er Router/Serv er EthernetRadio 1 Hop SRC = 6BBR DST = NS SRC TGT = LPN TLLA = 6LBR SRC = 6LR DST = Parent * or Root TGT = LPN UID missing : ( TID included SRC = LPN_ll DST = 6LR_ll TGT = LPN SLLA = LPN UID = LPN TID included SRC = 6LBR DST = 6BBR TGT = LPN SLLA = L6BR UID = LPN * TID included * Parent in storing mode * From binding state NS lookup RPL cannot DAD for lack of UID 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er
281
282 6LR 6LBRLP Node NS (ARO) DAR (ARO) SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = LPN_ll DST = 6LR_ll TGT = LPN ** SLLA = LPN UID = LPN TID included Collision of binding state within RPL DODAG Different UID for addr. LPN NA (ARO, s=1) DAC (ARO, s=1) SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = 6LR_ll DST = LPN_ll TGT = LPN TLLA = LPN UID = LPN TID included 6LR 6LBRLP Node
283 6LR 6LBR 6BBRLP Node RPL NS (ARO) NS (ARO) DAR (ARO) EthernetRadio 1 Hop SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = LPN_ll DST = 6LR_ll TGT = LPN SLLA = LPN UID = LPN TID included Create binding state Collision of proxy state between 6LBRs attached to a same 6BBR NA (ARO, s=1) NA (ARO, s=1) DAC (ARO, s=1) SRC = 6BBR DST = 6LBR TGT = LPN UID = LPN TID included 6LR 6LBR 6BBRLP Node
284 Router/Serv er Router/Serv er Router/Serv er 6LR 6LBR 6BBRLP Node RPL Ethernet NS DAD (ARO) NS (ARO) NS (ARO) DAR (ARO) EthernetRadio 1 Hop SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = LPN_ll DST = 6LR_ll TGT = LPN SLLA = LPN UID = LPN TID included SRC = 6LBR DST = 6BBR SLLA = L6BR TGT = LPN UID = LPN TID included Create binding state Create proxy state Collision with legacy device attached to the backbone 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er
285 Router/Serv er 6LR 6LBR 6BBRLP Node RPL EthernetRadio 1 Hop NA (ARO, s=1) NA (ARO, s=1) DAC (ARO, s=1) SRC = NODE DST = 6BBR TGT = LPN UID = LPN TID included Collision with legacy device Ethernet NA (O) SRC = 6BBR DST = 6LBR TGT = LPN UID = LPN TID included SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = 6LR_ll DST = LPN_ll TGT = LPN UID = LPN TID included 6BBRRouter/Serv er Router/Serv er 6LR 6LBR 6BBRLP Node Router/Serv er Router/Serv er Router/Serv er
286 RPL Ethernet NS DAD (ARO) NS (ARO) NS (ARO) DAR (ARO) EthernetRadio 1 Hop SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = LPN_ll DST = 6LR_ll TGT = LPN SLLA = LPN UID = LPN TID included SRC = 6LBR DST = 6BBR TGT = LPN SLLA = L6BR UID = LPN TID included Create binding state Create proxy state Collision of proxy state between 6BBRs attached to a same backbone Router/Serv er 6LR 6LBR 6BBRLP Node Router/Serv er Router/Serv er
287 6LR 6LBR 6BBRLP Node RPL EthernetRadio 1 Hop NA (ARO, s=1) NA (ARO, s=1) DAC (ARO, s=1) SRC = 6BBR2 DST = 6BBR TGT = LPN2 UID = LPN2 TID2 included Collision of proxy state Ethernet NA (ARO, s=1) SRC = 6BBR DST = 6LBR TGT = LPN UID = LPN TID included SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = 6LR_ll DST = LPN_ll TGT = LPN UID = LPN TID included 6BBR 6BBR 6BBR 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er
288
289 6LR 6LBRLP Node NS (ARO) DAR (ARO) SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = LPN_ll DST = 6LR_ll TGT = LPN ** SLLA = LPN UID = LPN TID included Matches a binding state within RPL DODAG same UID for addr. LPN NA (ARO, s=0) DAC (ARO, s=0) SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = 6LR_ll DST = LPN_ll TGT = LPN TLLA = LPN UID = LPN TID included 6LR 6LBR 6BBRLP Node
290 Router/Serv er Router/Serv er Router/Serv er 6LR 6LBR 6BBRLP Node RPL NS (ARO) NS (ARO) DAR (ARO) EthernetRadio 1 Hop SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = LPN_ll DST = 6LR_ll TGT = LPN SLLA = LPN UID = LPN TID included Create binding state Matches a proxy state associated to another 6LBR attached to a same 6BBR NA (ARO, s=0) NA (ARO, s=0) DAC (ARO, s=0) Update proxy state SRC = 6LBR DST = 6BBR TGT = LPN SLLA = L6BR UID = LPN TID included 6LR 6LBR 6BBRLP Node
291 6LR 6LBR 6BBR 6BBRLP Node RPL Ethernet NS DAD (ARO) NS (ARO) NS (ARO) DAR (ARO) 6BBR 6BBR EthernetRadio 1 Hop SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = LPN_ll DST = 6LR_ll TGT = LPN SLLA = LPN UID = LPN TID included SRC = 6LBR DST = 6BBR TGT = LPN SLLA = L6BR UID = LPN TID included Create binding state Create proxy state Matches a proxy state in another 6BBR attached to a same backbone 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er
292 6LR 6LBR 6BBRLP Node RPL EthernetRadio 1 Hop NA (ARO, s=0) NA (ARO, s=0) DAC (ARO, s=0) SRC = 6BBR2 DST = 6BBR TGT = LPN UID = LPN TID2 included Collision with Older TID Ethernet SRC = 6BBR DST = 6LBR TGT = LPN UID = LPN TID included SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = 6LR_ll DST = LPN_ll TGT = LPN UID = LPN TID included 6BBR 6BBR 6BBR NA (O) Yield silently 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er
293 6LR 6LBR 6BBRLP Node RPL EthernetRadio 1 Hop NA (ARO, s=3) NA (ARO, s=3) DAC (ARO, s=3) SRC = 6BBR2 DST = 6BBR TGT = LPN UID = LPN TID2 included Collision with Newer TID Ethernet NA (ARO, s=3) SRC = 6BBR DST = 6LBR TGT = LPN UID = LPN TID included SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = 6LR_ll DST = LPN_ll TGT = LPN UID = LPN TID included 6BBR 6BBR 6BBR 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er
294
295 6LR 6BBR Router/Serv er LP Node RPL Ethernet NA (~O) Router/Serv er Router/Serv er Radio 1 Hop SRC = 6BBR DST = NS SRC SLLA = 6BBR TGT = LPN NS lookup 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er Data packet Data packet Data packet Data packet
296 6LR 6BBR Router/Serv er LP Node RPL NA (~O) Router/Serv er Router/Serv er Radio 1 Hop SRC = 6BBR DST = NS SRC SLLA = 6LBR TGT = LPN NS lookup 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er Data packet Data packet Data packet Ethernet (Switched)

More Related Content

PPTX
IPv6 ND 2020
Pascal Thubert
 
PPTX
Luxbg fringe
Pascal Thubert
 
PPTX
6TiSCH @Telecom Bretagne 2015
Pascal Thubert
 
PDF
TRUST BASED ROUTING METRIC FOR RPL ROUTING PROTOCOL IN THE INTERNET OF THINGS
pijans
 
PPTX
6Tisch telecom_bretagne_2016
Pascal Thubert
 
PPTX
Rpl telecom bretagne
Pascal Thubert
 
PDF
Mobility, traffic engineering and redundancy using RPL
Maxime Denis
 
PPTX
6TiSCH + RPL @ Telecom Bretagne 2014
Pascal Thubert
 
IPv6 ND 2020
Pascal Thubert
 
Luxbg fringe
Pascal Thubert
 
6TiSCH @Telecom Bretagne 2015
Pascal Thubert
 
TRUST BASED ROUTING METRIC FOR RPL ROUTING PROTOCOL IN THE INTERNET OF THINGS
pijans
 
6Tisch telecom_bretagne_2016
Pascal Thubert
 
Rpl telecom bretagne
Pascal Thubert
 
Mobility, traffic engineering and redundancy using RPL
Maxime Denis
 
6TiSCH + RPL @ Telecom Bretagne 2014
Pascal Thubert
 

What's hot (20)

PDF
Towards the Internet of Relevant Things: the IEEE 802.15.4e Standard
Giuseppe Anastasi
 
PDF
Understanding limitations of lo rawan
mafole
 
PPTX
Rpl2016
Pascal Thubert
 
PPTX
5G Cellular D2D RDMA Clusters
Yitzhak Bar-Geva
 
PPTX
Iot rpl
DESHPANDE M
 
PDF
Research and Experimentation of LoRa in Heavy Multipath
Haystack Technologies
 
PDF
IoT Field Area Network Solutions & Integration of IPv6 Standards by Patrick G...
gogo6
 
PDF
IoT Gent meetup
waltercolitti
 
PDF
How To Disrupt The Internet of Things With Unified Networking
Haystack Technologies
 
PPTX
NetSim - Implementing LEACH in WSN
DESHPANDE M
 
PDF
LoRaWAN vs Haystack
Haystack Technologies
 
PDF
The IoT Hunger Games 2015
Haystack Technologies
 
PPTX
LPWAN Technology ~ What is Weightless-P?
Jay Wey 魏士傑
 
PDF
Cnam2015 m2 m -iot - course 2 - warming - v(0.2)
Thierry Lestable
 
PDF
LoRaWAN101_What is it
Birdz
 
PDF
Bringing Better Networking to LTE IoT
Haystack Technologies
 
PDF
LISP_in_Secure_Networks_WP
Craig Hill
 
PDF
wp233
Nick Possley
 
PDF
Lo ra
Oded Rotter
 
PDF
Haystack Technology Overview
Haystack Technologies
 
Towards the Internet of Relevant Things: the IEEE 802.15.4e Standard
Giuseppe Anastasi
 
Understanding limitations of lo rawan
mafole
 
Rpl2016
Pascal Thubert
 
5G Cellular D2D RDMA Clusters
Yitzhak Bar-Geva
 
Iot rpl
DESHPANDE M
 
Research and Experimentation of LoRa in Heavy Multipath
Haystack Technologies
 
IoT Field Area Network Solutions & Integration of IPv6 Standards by Patrick G...
gogo6
 
IoT Gent meetup
waltercolitti
 
How To Disrupt The Internet of Things With Unified Networking
Haystack Technologies
 
NetSim - Implementing LEACH in WSN
DESHPANDE M
 
LoRaWAN vs Haystack
Haystack Technologies
 
The IoT Hunger Games 2015
Haystack Technologies
 
LPWAN Technology ~ What is Weightless-P?
Jay Wey 魏士傑
 
Cnam2015 m2 m -iot - course 2 - warming - v(0.2)
Thierry Lestable
 
LoRaWAN101_What is it
Birdz
 
Bringing Better Networking to LTE IoT
Haystack Technologies
 
LISP_in_Secure_Networks_WP
Craig Hill
 
wp233
Nick Possley
 
Lo ra
Oded Rotter
 
Haystack Technology Overview
Haystack Technologies
 
Ad

Similar to Rpl2018 (20)

PPTX
UNIT III- 1.RPL.pptx
Sangeetha Prakash
 
PPTX
Final_IoT_Protocol Stack.pptx
jainam bhavsar
 
PDF
Scaling the Web to Billions of Nodes: Towards the IPv6 “Internet of Things” b...
gogo6
 
PDF
internet-of-things-2.....................pdf
rajeswaria21
 
PPTX
Lecture 8 - Connectivity Technologies – Part II- IOT.pptx
taheenaamir
 
PPTX
communication_technologies_Internet of things topic
DurgaDeviP2
 
PDF
ConnectingSmartObjects..........................pdf
TinotendaChagaka
 
PPT
Module 3 INTERNET OF THINGS
Dr. Mallikarjunaswamy N J
 
PDF
IoT PROTOCOLS IoT Access Technologies Physical and MAC layers, topology and S...
girishgandhi4
 
PPTX
6 lowpan
Siva Kumar
 
PPTX
6LowPAN etc.pptx computer network and IOT devices in future technology
HRJEETSINGH
 
PPT
L6 6 lowpan
bimal2638
 
PDF
About IoT Protocols and Security Techniques
BalasundaramSr
 
PPTX
IOT Protocols
Nagesh Rao
 
PDF
IPv6 and IoT
APNIC
 
PPTX
WPAN technologies and its wipe spread usage
hodcse768718
 
PPT
Zigbee technology
VELAMMAL INSTITUTE OF TECHNOLOGY
 
PPTX
Elements of IoT connectivity technologies
usman sarwar
 
PDF
”モノ”のインターネットへのつながり方：L3より下層について
Shoichi Sakane
 
PPTX
6lowpan 110828234426-phpapp01
mrmr2010i
 
UNIT III- 1.RPL.pptx
Sangeetha Prakash
 
Final_IoT_Protocol Stack.pptx
jainam bhavsar
 
Scaling the Web to Billions of Nodes: Towards the IPv6 “Internet of Things” b...
gogo6
 
internet-of-things-2.....................pdf
rajeswaria21
 
Lecture 8 - Connectivity Technologies – Part II- IOT.pptx
taheenaamir
 
communication_technologies_Internet of things topic
DurgaDeviP2
 
ConnectingSmartObjects..........................pdf
TinotendaChagaka
 
Module 3 INTERNET OF THINGS
Dr. Mallikarjunaswamy N J
 
IoT PROTOCOLS IoT Access Technologies Physical and MAC layers, topology and S...
girishgandhi4
 
6 lowpan
Siva Kumar
 
6LowPAN etc.pptx computer network and IOT devices in future technology
HRJEETSINGH
 
L6 6 lowpan
bimal2638
 
About IoT Protocols and Security Techniques
BalasundaramSr
 
IOT Protocols
Nagesh Rao
 
IPv6 and IoT
APNIC
 
WPAN technologies and its wipe spread usage
hodcse768718
 
Zigbee technology
VELAMMAL INSTITUTE OF TECHNOLOGY
 
Elements of IoT connectivity technologies
usman sarwar
 
”モノ”のインターネットへのつながり方：L3より下層について
Shoichi Sakane
 
6lowpan 110828234426-phpapp01
mrmr2010i
 
Ad

Recently uploaded (20)

PDF
Triggering QUIC, presented by Geoff Huston at IETF 123
APNIC
 
PPTX
INTERNET------BASICS-------UPDATED PPT PRESENTATION
poonam62133
 
PPTX
Internet___Basics___Styled_ presentation
poonam62133
 
PPTX
QR Codes Qr codecodecodecodecocodedecodecode
SRMediaZone
 
PDF
Tenda Login Guide: Access Your Router in 5 Easy Steps
tendawifi16
 
PDF
Cloud-Scale Log Monitoring _ Datadog.pdf
MuhammadDhomanhuriMa
 
PDF
Vigrab.top – Online Tool for Downloading and Converting Social Media Videos a...
Vigrab Top
 
PPTX
PptxGenJS_Demo_Chart_20250317130215833.pptx
itruongva
 
PDF
WebRTC in SignalWire - troubleshooting media negotiation
Giacomo Vacca
 
PPT
Design_with_Watersergyerge45hrbgre4top (1).ppt
DiogoRibeiro730590
 
PPTX
artificial intelligence overview of it and more
yafotin445
 
PPTX
innovation process that make everything different.pptx
SoumyadipPaul18
 
PDF
Unit-1 introduction to cyber security discuss about how to secure a system
shivangisharma636228
 
PDF
Testing WebRTC applications at scale.pdf
Giacomo Vacca
 
PDF
An introduction to the IFRS (ISSB) Stndards.pdf
farhankhan13694
 
PPTX
522797556-Unit-2-Temperature-measurement-1-1.pptx
msar8888
 
PDF
💰 𝐔𝐊𝐓𝐈 𝐊𝐄𝐌𝐄𝐍𝐀𝐍𝐆𝐀𝐍 𝐊𝐈𝐏𝐄𝐑𝟒𝐃 𝐇𝐀𝐑𝐈 𝐈𝐍𝐈 𝟐𝟎𝟐𝟓 💰
GRAB
 
PDF
Best Practices for Testing and Debugging Shopify Third-Party API Integrations...
CartCoders
 
PPTX
SAP Ariba Sourcing PPT for learning material
NKKumar16
 
PPTX
introduction about ICD -10 & ICD-11 ppt.pptx
naveenithkrishnan
 
Triggering QUIC, presented by Geoff Huston at IETF 123
APNIC
 
INTERNET------BASICS-------UPDATED PPT PRESENTATION
poonam62133
 
Internet___Basics___Styled_ presentation
poonam62133
 
QR Codes Qr codecodecodecodecocodedecodecode
SRMediaZone
 
Tenda Login Guide: Access Your Router in 5 Easy Steps
tendawifi16
 
Cloud-Scale Log Monitoring _ Datadog.pdf
MuhammadDhomanhuriMa
 
Vigrab.top – Online Tool for Downloading and Converting Social Media Videos a...
Vigrab Top
 
PptxGenJS_Demo_Chart_20250317130215833.pptx
itruongva
 
WebRTC in SignalWire - troubleshooting media negotiation
Giacomo Vacca
 
Design_with_Watersergyerge45hrbgre4top (1).ppt
DiogoRibeiro730590
 
artificial intelligence overview of it and more
yafotin445
 
innovation process that make everything different.pptx
SoumyadipPaul18
 
Unit-1 introduction to cyber security discuss about how to secure a system
shivangisharma636228
 
Testing WebRTC applications at scale.pdf
Giacomo Vacca
 
An introduction to the IFRS (ISSB) Stndards.pdf
farhankhan13694
 
522797556-Unit-2-Temperature-measurement-1-1.pptx
msar8888
 
💰 𝐔𝐊𝐓𝐈 𝐊𝐄𝐌𝐄𝐍𝐀𝐍𝐆𝐀𝐍 𝐊𝐈𝐏𝐄𝐑𝟒𝐃 𝐇𝐀𝐑𝐈 𝐈𝐍𝐈 𝟐𝟎𝟐𝟓 💰
GRAB
 
Best Practices for Testing and Debugging Shopify Third-Party API Integrations...
CartCoders
 
SAP Ariba Sourcing PPT for learning material
NKKumar16
 
introduction about ICD -10 & ICD-11 ppt.pptx
naveenithkrishnan
 

Rpl2018

  • 2. 2 • The any-to-any paradigm Art: Any pair of global addresses can reach one another IoT: Many devices of all sorts, no hotfixes Corridors to the cloud? • The end-to-end paradigm Art: Intelligence at the edge, dumb routing nodes Infinite bandwidth to all powerful clusters? • The best-effort paradigm Art: Stochastic packet distribution and RED Can we make the whole Internet deterministic?
  • 3. 3 Trillion devices in the Internet The core technologies will not change Leakless Autonomic Fringe Leakless Route Projection Million devices in a Subnet New models for the subnet protocols IPv6 ND, RPL, Service Discovery … Fiber + Copper + Wi-Fi Backbone Femto + 802.11 + 802.15.4 + … Access Unhindered Mobility Location / ID Separation (LISP, NEMO) 10’s of K
  • 4. 4 Data: Capillary Wireless Acquisition of large amounts of live Big Data Information: DiM/Fog to add descriptive meta-tags, allowing for compression and correlation Knowledge: Prediction from self-learned models and Knowledge Diffusion Wisdom: Machine Learnt Expertise, auto-Generating Prescriptions and Actionable Recommendations (Data) ACQUISITION (Knowledge) DIFFUSION (Wisdom) OPEN LOOP (Information) AGGREGATION 5G femtocell Data in Motion / Fog Learning Machines / Cloud 6TiSCH
  • 5. 5 Aka Time Sensitive Networking (TSN) For traffic known a priori (control loops…) Time Synchronization and Global Schedule NP-complete optim. problem => centralized computation Fully controlled local network
  • 6. 6 We are in for a change: Basic Internet structures and expectations reconsidered Revising classical end-to-end and any-to-any Revising best effort to new levels of guarantees (deterministic) New function placement, new operations Merge at the Information layer, Gossip at the knowledge layer Impacts network, transport, security models
  • 7. 7 Agenda (part 1, Introduction) IOT Standards IEEE and LLNs IETF and 6LoWPAN IETF 6TiSCH Routing Concepts Forms of Routing Loopless structures Routing Over Radios
  • 8. 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. 9 Agenda (part 3, New Work on RPL) RPL Route Projection (SDN) Shortening Long SRH Transversal Routes BIT Indexing (BIER) Un- vs. reliable BIER RPL Fast Reroute in RPL Using Data Plane Using Control Plane On-Demand RPL
  • 10. 10 Additional material The backbone router Problem High level exchanges Deeper dive in flows
  • 12. 12
  • 13. 13 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)
  • 14. 14 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 Alliances and consortiums addressing LLNs IETF - CoRE, 6lo/LoWPAN, ROLL, ACE, LPWAN, 6TiSCH… Alliances – IPSO, Thread, ISA, HCF World’s smallest web server
  • 15. 15 LLNs operate with a hard, very small bound on state LLNs are optimised for saving energy in the majority of cases Traffic patterns can be MP2P, P2P and P2MP flows Typically LLNs deployed over link layers with restricted frame-sizes Minimise the time a packet is enroute (in the air/on the wire) hence the small frame size The routing protocol for LLNs should be adapted for such links LLN routing protocols must consider efficiency versus generality Many LLN nodes do not have resources to waste
  • 16. 16 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
  • 17. Cisco Confidential© 2012 Cisco and/or its affiliates. All rights reserved. 17 Initial activities focused on wearable devices “Personal Area Networks” Activities have proven to be much more diverse and varied Data rates from Kb/s to Gb/s Ranges from tens of metres up to a Kilometre Frequencies from MHz to THz Various applications not necessarily IP based Focus is on “specialty”, typically short range, communications If it is wireless and not a LAN, MAN, RAN, or WAN, it is likely to be 802.15 (PAN) The only IEEE 802 Working Group with multiple MACs http://www.ieee802.org/15/pub/TG4.html IEEE 802.15 WPAN™ Task Group 4 (TG4) Charter
  • 18. 18 Star Topology Cluster TreeMesh Topology P R F F R R P F F F R F R All devices communicate to PAN co-ordinator which uses mains power Other devices can be battery/scavenger Single PAN co-ordinator exists for all topologies Devices can communicate directly if within range F F F F P R R F R Operates at Layer 2 R R RR Higher layer protocols like RPL may create their own topology that do not follow 802.15.4 topologies
  • 19. 19 • 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 (IEEE Std. 802.15.12, Network & App)
  • 20. 20
  • 21. 21
  • 22. 22
  • 23. 23 Reuse work done here where possible Application General Internet Ops and Mgmt Routing Security Transport Core 6lo ROLL IETF LWIG Constrained Restful Environments Charter to provide a framework for resource-oriented applications intended to run on constrained IP networks. IPv6 over Networks of Resource-constrained Nodes (succeeds 6LoWPAN) Charter is to develop protocols to support IPv6 IoT networks. Routing over Low Power Lossy Networks Charter focusses on routing issues for low power lossy networks. Lightweight Implementation Guidance Charter is to provide guidance in building minimal yet interoperable IP- capable devices for the most constrained environments. LPWAN IPv6 over TSCH Charter is to develop best practice and Architecture for IPv6 over 802.15.4 TSCH.6TiSCH
  • 24. 24 • 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
  • 25. 25 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 LPWAN Thread ZigBee/IP
  • 26. 26 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:
  • 27. 27 • 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
  • 28. 28 • 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
  • 29. 29 • 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 https://tools.ietf.org/html/rfc7668 https://tools.ietf.org/html/rfc8105 https://tools.ietf.org/html/rfc7428 https://tools.ietf.org/html/draft-hou-6lo-plc https://tools.ietf.org/html/draft-ietf-6lo-nfc https://tools.ietf.org/html/rfc8163 https://tools.ietf.org/html/draft-delcarpio-6lo-wlanah https://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
  • 30. 30 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-ietf-6lo-rfc6775-update we claim that Low Power Wi-Fi is an LLN link
  • 31. 31 Preamble SPD PHY Header Auxiliary Security Header Payload FCS Frame Control Data Seq. Nbr Addressing Simple MAC allows coexistence with other network protocols over same link, similar to Ethernet, although not seen in deployment IEs Header & Payload DST PAN ID Mesh Address 6LoWPAN Compressed Hdr Payload DST MAC Address SRC PAN ID SRC MAC Address 11000 00 10 01 11 Not a LoWPAN frame LoWPAN Header Dispatch (DSP) LoWPAN mesh Hdr LoWPAN fragmentation Hdr and other stuff 1st Frag. 6LoWPAN Compressed Hdr Payload 1st Frag. 6LoWPAN Compressed Hdr Payload IPHC Other 6LoWPAN Hdr field Payload Header Dispatch (DSP) – understand what is coming Mesh AddressMesh + Fragmentation Frame Fragmentation Mesh (L2 Routing) 6LoWPAN 01 10 11000 01 01 6LoWPAN Compressed Hdr 01 01
  • 32. 32 3 00 xxxxxx 0 Not a LoWPAN RFC 4944 1-14 Unassigned 15 Experimental Use RFC 8025 01 000000 0 ESC RFC 6282 1-14 Unassigned 15 Experimental Use RFC 8025 01 1xxxxx 0-1 IPHC RFC 6282 2-14 Unassigned 15 Experimental Use RFC 8025 Bit Pattern Page Header Type Reference 11 11xxxx 0-15 Page switch RFC 8025 … … … … … …
  • 33. 33 3 0 1 1 HLIM SAM DAM 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 10 TF 2 bits Traffic Class and Flow Label NH 1 bit Next Header HLIM 2 bits Hop Limit CID 1 bit Context Identifier Extension SAC 1 bit Source Address Context SAM 2 bits Source Address Mode M 1 bit Multicast Address Compression DAC 1 bit Destination Address Context DAM 2 bits Destination Address Mode CIDTF NH SAC M DAC DSP Addressing
  • 34. 34 3 1st Frag. Payload Frame Fragmentation 6LoWPAN + RPL Page 1 switch IPHC Other 6LoWPAN Hdr field DSP 11000 6LoRH Payload Page 1 switch IPHC Other 6LoWPAN Hdr field DSP6LoRH RH3-6LoRH RPI-6LoRH IP-in-IP-LoRH
  • 35. 35 6LR 6LBRLP Node NS (ARO) DAR (ARO) SRC = 6LR DST = 6LBR REG = LPN UID = LPN SRC = LPN_ll DST = 6LR_ll TGT = ?? SLLA = LPN UID = LPN Check Collision of binding state (DAD) NA (ARO, s=1) DAC (ARO, s=0,1==dup) SRC = 6LR DST = 6LBR REG = LPN UID = LPN SRC = 6LR_ll DST = LPN_ll TGT = LPN TLLA = LPN UID = LPN 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length = 2 | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Registration Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + EUI-64 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A registration mechanism For duplicate detection Goal to save multicast Being updated Address Registration Option Radio Mesh Radio 1 Hop
  • 36. 36 Scalable and Multi-Link Deterministic e2e IP guard (admin knows what’s where) => Authoritative Registrar(s) Backbone Routers RPL root, ND proxy Legacy IPv6 devices Authoritative Registrar Authoritative Registrar / 6LBR Intermediate Registrar / 6LR Intermediate Registrar option. ND proxy Backbone router (ND proxy)
  • 37. 37 6LoWPAN is an open standard, NOT a silo’ed solution 6LoWPAN is how you do IPv6 over low-power lossy networks Provides an Adaptation Layer and a novel IPv6 Neighbor Discovery 6LoWPAN started small with the 802.15.4-2003 WPAN Updated to fit in ISA100.11a, used in Thread, ZigbeeIP, … Now generalizing on all LLN technologies with IETF 6lo GW
  • 38. 38
  • 39. 39 • Reduces frame loss  Time and Frequency Diversity  Reduces co-channel interference • Optimizes bandwidth usage  No blanks due to IFS and CSMA-CA exponential backoff  While Increasing the ratio of guaranteed critical traffic • Saves energy  Synchronizes sender and listener  Thus optimizes sleeping periods  By avoiding idle listening and long preambles
  • 40. 40 Controlling time of emission Can achieve ~10ms sync on 802.15.4 Can guarantee time of delivery Protection the medium ISM band crowded, no fully controlled all sorts of interferences, including self Can not guarantee delivery ratio Improving the Delivery ratio Different interferers => different mitigations Diversity is the key
  • 41. 41 Code diversity Code Division Multiplex Access Network Coding (WIP) Frequency diversity Channel hopping B/W listing Time Diversity ARQ + FEC (HARQ) TDM Time slots Spatial diversity Dynamic Power Control DAG routing topology + ARCs Duo/Bi-casting (live-live) Use all you can!
  • 42. 42 16channeloffsets e.g. 31 time slots (310ms) A BC D E F G H I J Schedule every transmission (they all do it!) to maintain the medium free at critical times e.g. TDM, and TimeSlotted Channel Hopping (TSCH) Used in wireless HART, ISA100.11a and 6TiSCH
  • 43. 43 Source: DUST Networks / Linear Technology With TSCH, ARQ (retries) are scheduled at different times over different channels to maximize diversity.
  • 44. 44 Type of traffic Type of MAC Deterministic (e.g. Control Loops) Stochastic (e.g. classical IP) Deterministic (e.g. 802.15.4 TSCH) Good fit Adapted to centralized routing and fully scheduled operation All industrial protocols are here Difficult but achievable: requires dynamic allocation of transmission resources (6TiSCH) Stochastic (e.g. Zigbee, Wi-Fi) Problems with channel access (guard time) Lead to gross over-provisioning CSMA cannot provide hard guarantees Good fit Adapted for IP traffic, distributed routing and statistical multiplexing with RED
  • 45. 46 • 6TiSCH also specifies an IPv6-over-foo for 802.15.4 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.4 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
  • 46. 47 Scope • Radio Mesh: Range extension with Spatial reuse of the spectrum • TSCH with Centralized routing, optimized for Time-Sensitive flows  Mission-critical data streams (control loops)  Deterministic reach back to Fog for virtualized loops  And limitations (mobility, scalability) • RPL Distributed Routing and scheduling for large scale monitoring  Enabling co-existence with IPv6-based Industrial Internet  Separation of resources between deterministic and stochastic Leveraging IEEE/IETF standards (802.15.4, 6LoWPAN …)
  • 47. 48 Deterministic IPv6 over IEEE802.15.4 TimeSlotted Channel Hopping (6TiSCH) The Working Group will focus on enabling IPv6 over the TSCH mode of the IEEE802.15.4 standard. The scope of the WG includes one or more LLNs, each one connected to a backbone through one or more LLN Border Routers (LBRs). 6TiSCH also specifies an IPv6-over-foo for 802.15.4 TSCH but does not update 6LoWPAN (that’s pushed to 6lo). Rather 6TiSCH defines the missing Data Link Layer. The 6TiSCH architecture defines the Layer-3 operation. It incorporates 6LoWPAN but also RPL, DetNet (PCE) for deterministic networking, COMAN, SACM, CoAP, DICE … => Mostly NOT specific to 802.15.4 TSCH WG charter
  • 48. 49 6TiSCH has to make components work together and push new work https://tools.ietf.org/html/draft-ietf-6lo-backbone-router https://tools.ietf.org/html/draft-ietf-6lo-rfc6775-update https://tools.ietf.org/html/draft-thubert-6lo-forwarding-fragments https://tools.ietf.org/html/draft-ietf-roll-dao-projection Active 6TiSCH drafts and RFCs https://tools.ietf.org/html/rfc7554 https://tools.ietf.org/html/rfc8180 (Minimal support, slotted Aloha) https://tools.ietf.org/html/draft-ietf-6tisch-terminology https://tools.ietf.org/html/draft-ietf-6tisch-architecture https://tools.ietf.org/html/draft-ietf-6tisch-6top-sfx https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-secure-join WG deliveries
  • 49. 50 Centralized route and track computation and installation Management and Setup Discovery Pub/Sub Authentication for Network Access Wireless ND (NPD proxy) Time Slot scheduling and track G-MPLS forwarding Distributed route and track computation and installation Distributed route and track computation and installation IEEE 802.15.4 TSCH 6LoWPAN HC IPv6 RPL 6top TCP UDP ICMP CCAMP PCEP/PCC CoAP/DTLS AAA 6LoWPAN ND }
  • 50. 51
  • 53. 54 6TiSCH Backbone Router Intelligent device Management Wireless Controller Backbone Router Limit of IPv6 subnet(s)Limit of IPv6 subnet End to end IPv6 routing NAC /Firewall VPN Concentrator
  • 54. 55 6TiSCH 6TiSCHSensor Actuator Backbone Router Management Wireless Controller Backbone Router Single Multilink IPv6 Subnet with free inner mobility (same subnet == no renumbering) Virtual Service Engine (virtual PLC, PCE …) + IPv6 ND registrar + Network Function Virtualization (NFV) NAC /Firewall VPN Concentrator IPv6 ND registration and proxy operation Full virtualization and chaining
  • 56. 57
  • 57. 58 • Hidden terminal • Interference domains grows faster that range • Density => low power => multihop => routing
  • 58. 59 Centralized: A controller sets up the routes Pros God’s view, enables global optimization Elastic resource management / NFV Traffic Engineering, may compute per flow paths Non Equal Cost Multipath, Replication & Elimination Cons Delays learning about breakage Delays fixing breakage NP complete optimization => limits scalability Distributed: A routing protocol sets up the routes Pros Since ARPANET, enables high resilience Different IGPs for different needs Installed base Cons Microloops Tends to build crowded avenues, wastes bandwidth Same costs for all, NECM difficult, manual TE Need additions for reroute / fast reroute
  • 59. 60 Aka Stateful vs. On-demand routing Note: on-demand breaks control vs. Data plane separation P2P-RPL RIP IS-IS AODV-RPL
  • 60. 61 LS requires full state and convergence Every node draws a same graph Then run the 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 topological complexities and changes DV enables multiple NECM feasible successors RIP IS-IS
  • 61. 62 Stateful: routing decision at every hop Pros Resilient (DARPA), autonomic Cons Requires routing state in every router Tends to concentrate flows Routing Loops Source Routing: The path is in the packet Pros Saves state in routers Enables per flow routing (segment routing) Cons Larger packets / Source Route Header (SRH)
  • 62. 63 0 Optimized Routing Approach (ORA) spans advertisements for any change Routing overhead can be reduced if stretch is allowed: Least Overhead Routing Approach (LORA) => (Nothing to do with the LoRa LPWAN protocol !!!) For instance Fisheye and zone routing provide a precise routing when closeby and sense of direction when afar
  • 63. 64 • Conventional routing protocols are Greedy Meaning that a packet must always “progress” towards a destination for a particular metric This causes issues like micro-loops or freezing when the greedy path is lost • Fast Reroute enables lossless rerouting of packets FR may require a step back before progressing again Made possible by new routing approaches (see LFA, ARC and MRT) Can also use Tunnels / Source Routing around (see Segment Routing) PLAN B can be computed centrally
  • 64. 65
  • 65. 66 Most classical routing structure Typically what Internet Gateway Protocols (IGPs) Build or each reachable destination Only thing Link State builds, though Distance Vector has feasible successors Must be reconstructed upon connectivity loss, service is interrupted FRR techniques must be added (MRT, LFA with SR …) on top No inner load balancing capabilities Walkable structure (e.g. depth first) ROOT 5 4 4 0 1 3 1 1 2 2 2 2 23 3 3 3 3 2 4 4 5 0 6 5 4 ROOT
  • 66. 67 In the context of routing, a Directed Acyclic Graph (DAG) is formed by a collection of vertices (nodes) and edges (links). Each edge connecting one node to another (directed) in such a way that it is not possible to start at Node X and follow a directed path that cycles back to Node X (acyclic). Greedy => Not all nodes have 2 solutions even in biconnected networks A Destination Oriented DAG (DODAG) is a DAG that comprises a single root node. Here a DAG that is partitioned in 2 DODAG Clusterhead 5 4 4 0 1 3 1 1 2 2 2 2 2 3 3 3 3 3 3 2 4 4 5 0 6 5 4
  • 67. 68 • In Green: A’s subDAG. Impacted if A’s connectivity is broken Domain for routing recovery • In Red: B’s fanout DAG (or reverse subDAG) Potential SPAN on B’s DAO Thus potential return paths Fanout must be controlled to limit intermediate states Clusterhead 5 4 4 0 1 3 1 1 2 2 2 2 2 3 3 3 3 3 3 2 4 4 5 0 6 5 4 A B
  • 68. 69 Clusterhead 5 Clusterhead 0 1 1 1 2 2 2 2 2 3 3 3 3 3 3 2 3 5 4 4 4 4 e.g. ARC of siblings Allows more alternates ARCs and walkable structures in general are walked with no routing progress Routing between DAGs of ARCs Forwarding over DAG AND ARCs Reduces congestions of upper links of the DAG Still LORA for P2P IGP subarea (bidirectional) Link selected and oriented by TD Potential link
  • 69. 70
  • 70. 71 1000*scale => No leak in Internet => Opaque operations Reachability => Radio (IEEE) Addressing => IPv6 (IETF) Density => spatial reuse => Routing
  • 71. 72 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
  • 72. 73 Potentially Large Peer Set Highly Variable Capabilities Selection Per Objective Metrics (e.g. RSSI, ETX…) L3 Reachability (::/0, …) Constraints (Power …)
  • 73. 74 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)
  • 74. 75 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
  • 75. 76 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
  • 76. 78 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
  • 77. 79 RPL (RFC 6550 and then more)
  • 78. 80 Dynamic Topologies Peer selection Constrained Objects Fuzzy Links Routing, local Mobility Global Mobility Low Power Lossy Networks Issues Addressed in RPL ?
  • 79. 81 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)
  • 80. 82 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
  • 81. 83
  • 82. 84 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).
  • 83. 85 5 3 5 4 RPL Instance Consists of one or more DODAGs sharing SAME service type (Objective Function) Identified by RPL INSTANCE ID UP(DAOMessages) DODAG Root Identified by DODAG ID (Node IPv6 address) Direction Oriented DAG (DODAG) Comprises DAG with a single root Rank Towards DODAG Root Rank = n Rank < n Node (OF configured) 2 1 5 4 3 3 Rankdecreases DODAG parent to child “5”s 2 DODAG Root Rank is always “1” (Typically an LBR - LLN Border Router) 1 3 2 Sub- DODAG DODAG DOWN(DIOMessages) Towards DODAG leafs Rank > n Rank = n Rankincreases Non-LLN Network (IPv6 Backbone) Siblings 44 DODAG Sensor Node
  • 84. 86 At a given point of time connectivity is as illustrated and rather fuzzy Radio link
  • 85. 87 Clusterhead 1st pass (DIO) Establishes a logical DAG topology Trickle Subnet/config Info Sets default route Self forming / self healing This is what nay classical DV will do but for all destinations not just the root 2nd pass (DAO, in storing mode) paints with addresses and prefixes Any to any reachability But forwarding over DAG only saturates upper links of the DAG And does not use the full mesh properly Link selected as parent link Potential link Clusterhead 0 1 1 1 4 4 4 46 3 3 3 3 3 2 2 2 2 2 2 5 5 5
  • 86. 88 : : 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
  • 87. 89 Clusterhead A’s link to root fails A loses connectivity Either poisons or detaches a subdag In black: the potentially impacted zone That is A’s subDAG Link selected as parent link Potential link Clusterhead 0 1 1 1 4 4 4 46 3 3 3 3 3 2 2 2 2 2 2 5 5 5 A 1 1 1 3 3 3 3 3 2 2 2 2 2 2 5 5 5 4 4 4 4
  • 88. 90 Clusterhead B can reparent a same Rank so B’s subDAG is safe The rest of A’s subDAG is isolated Either poison ar build a floating DAG as illustrated In the floating DAG A is root The structure is preserved Link selected as parent link Potential link Clusterhead 0 1 1 4 4 4 46 3 3 3 2 2 2 2 2 2 1 5 5 5 A B 0 1
  • 89. 91 Clusterhead Once poisined nodes are identified It is possible for A to reparent safely A’s descendants inherit from Rank shift Note: a depth dependent timer can help order things Link selected as parent link Potential link Clusterhead 0 1 1 2 4 4 4 46 3 3 3 4 4 2 2 2 2 3 3 5 5 5 A
  • 90. 92 Clusterhead A new DAG iteration In Green, the new DAG progressing Metrics have changed, the DAG may be different Forwarding upwards traffic from old to new iteration is allowed but not the other way around Link selected as parent link Potential link Clusterhead 0 1 1 1 4 4 4 46 3 3 3 3 3 3 2 2 2 2 2 5 5 5
  • 91. 93 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
  • 92. 94
  • 93. 95 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
  • 94. 96 Extend the generic behavior For a specific need / use case Used in parent selection Contraints Policies Position in the DAG Metrics Computes the Rank increment Based on hop metrics Do NOT use OF0 for adhoc radios! (OF 0 uses traditional weighted hop count)
  • 95. 97 Clusterhead 5 4 4 A second root is available (within the same instance) The DAG is partitioned 1 root = 1 DODAG 1 Node belongs to 1 DODAG (at most, per instance) Nodes may JUMP from one DODAG to the next Nodes may MOVE up the DODAG Going Down MAY cause loops May be done under CTI control Link selected and oriented by DIO Potential link 0 1 3 1 1 2 2 2 2 2 3 3 3 3 3 3 2 4 4 5 0 6 5 4
  • 96. 98 Running as Ships-in-the-night 1 instance = 1 DAG = 1 OF A DAG implements a set of constraints Multiple instances may be serving different Objective Functions => For different optimizations Forwarding is along a DODAG => Provides isolation like a vlan Clusterhead 0 1 1 1 2 2 2 2 2 3 3 3 3 3 3 2 3 5 4 4 4 4 Clusterhead Constrained instance Default instance Potential link A
  • 97. 99
  • 98. 100 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICMP Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Base Object . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Option(s) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0x00 (DIS) DODAG Information Solicitation 0x01 (DIO) DODAG Information Object 0x02 (DAO) Destination Advertisement Object 0x03 (DAO-ACK) Destination Advertisement Object Acknowledgment 155 == RPL control message
  • 99. 101
  • 100. 102 Flooding interferes with itself B C D A Hidden node/terminal/station
  • 101. 103 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
  • 102. 104 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
  • 103. 105 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)... +-+-+-+-+-+-+-+-+
  • 104. 106 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)... +-+-+-+-+-+-+-+-+
  • 105. 107 +-----+-----------------------------------------------------+ | 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 | | 4 | P2P Route Discovery Mode of Operation (RFC 6997) | | | | | | All other values are unassigned | +-----+-----------------------------------------------------+
  • 106. 108 Storing: Stateful Advertisement Tell about self and all children to parents Pros Lower route stretch Cons Consumes uncontrolled memory Non-Storing: Source Routing Advertisement Tell about self and parents to root Pros Enables per flow routing (segment routing) Cons Larger packets / Source Route Header (SRH)
  • 107. 109
  • 108. 110 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | Option(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: The DIS Base Object Options: 0x00 Pad1 0x01 PadN 0x07 Solicited Information Goal: ask routers around to generate DIO
  • 109. 111 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 | +-+-+-+-+-+-+-+-+
  • 110. 112 draft-ietf-roll-dis-modifications Based on earlier work draft-goyal-roll-dis-modifications New Flags to control Trickle behavior response mode Unicast vs. Broadcast Metric Container for constraints on the responder Response Spreading Option to spread responses over an interval
  • 111. 113
  • 112. 114 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
  • 113. 115 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
  • 114. 116 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Src: 51 Dest: 52 Stuff RPI
  • 115. 117 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)... +-+-+-+-+-+-+-+-+
  • 116. 118 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
  • 117. 119 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • 118. 120 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-... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • 119. 121 +- ... -+- ... -+-+-+-+-+- ... -+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+... |11110001| RPI-6LoRH | NH = 0 | NH = 58 | ICMP message |Page 1 | type 5 | 6LOWPAN-IPHC | (ICMP) | (no compression) +- ... -+- ... -+-+-+-+-+- ... -+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+... <- RFC 6282 -> No RPL artifact IPv6 header HbH header ICMP header ICMP PayloadRPL option <=>
  • 120. 122 +- ... -+- ... -+-+-+-+- ... +-+-+-+-+-+-+-+-+-+- ... +-+-+-+-+-+... |11110001| RPI-6LoRH | NH = 1 |11110|C| P | Compressed | UDP |Page 1 | type 5 | 6LOWPAN-IPHC | UDP | | | UDP header |Payload +- ... -+- ... -+-+-+-+- ... +-+-+-+-+-+-+-+-+-+- ... +-+-+-+-+-+... <- RFC 6282 -> IPv6 header HbH header UDP header UDP PayloadRPL option <=>
  • 121. 123
  • 122. 124 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::BA::B A::C A::D A::A A: (root) A::A self A::B connected A::C via A::B A::D via A::B A:: ~onlink A::D via A::B connected
  • 123. 125 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
  • 124. 126 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Src: X Dest: 56 Via: 13 Via: 24 Stuff Src: X Dest: 56 Stuff Via: 35 Via: 46 Src: Root Dest: 56 RPI
  • 125. 127 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Src: X Dest: 52 Via: 11 Via: 22 Stuff Src: 51 Dest: 52 Stuff Via: 32 Via: 42 Src: 51 Dest: Root RPI Src: Root Dest: 56 RPI Src: 51 Dest: 52 Stuff RPI OR
  • 126. 128
  • 127. 129 (Hateful stuff) Only end points may add / remove headers Some headers are mutable (and if they are recoverable they may be secured) e.g. of mutable and partially recoverable is RPI (to secure the instance ID) So IP in IP is required If the packet leaves the RPL domain since HbH header must be removed If the packet enters the RPL domain since HBH header or RH3 must be inserted In non storing mode for a packet not going to or from the root (RPI to RH3 conversion at root). https://tools.ietf.org/html/draft-robles-roll-useofrplinfo-02
  • 128. 130 Not a critical header, may be skipped so Length is in bytes. Placed last in the header chain. 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. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
  • 129. 131 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. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type | Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CmprI | CmprE | Pad | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Addresses[1..n] . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3
  • 130. 132 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ |1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ Size indicates the number of compressed addresses +-----------+----------------------+ | 6LoRH | Length of compressed | | Type | IPv6 address (bytes) | +-----------+----------------------+ | 0 | 1 | | 1 | 2 | | 2 | 4 | | 3 | 8 | | 4 | 16 | +-----------+----------------------+ Packet source is reference for compression Different compressed size => multiple RH3-6LoRH Placement first in the chain to be easily consumed as we go (address coalescence)
  • 131. 133 +- ... -+- ... -+-+-+- ... -+-+-+-+-+ ... +-+-+-+-+-+-+ ... +-+-+... |11110001|RH3(128bits)| RH3(3*16bits) |NH=1 |11110CPP| Compressed | UDP |Page 1 | 6LoRH | 6LoRH |6IPHC| UDP | UDP header | Payload +- ... -+- ... +-+-+-+- ... -+-+-+-+-+ ... +-+-+-+-+-+-+ ... +-+-+... <- RFC 6282 -> Note: With RPL this is only when the source is the root IPv6 header UDP header UDP Payload <=> Routing hdr Hop Hop Dec.Hop
  • 132. 134 RRRRRRRRRRRRRRRRRRRR ++ CCCCCCC -------------------- RRRRRRRRRRRRRCCCCCCC RR…RRRR is reference address for compression, may be compressed or not CCC…CC is compressed address, to shorter or same size as reference RR…RRCCC…CC is the Coalesced address, same size as reference
  • 133. 135 Leaving the root: Leaving A Leaving B C removes the header and the IP-in-IP if nothing else in IP-in-IP B’s suffix RH3-6LoRH Type 4 RH3-6LoRH Type 3 IPv6 Prefix B’s suffix C’s suffix A’s suffixRH3-6LoRH Type 4 IPv6 Prefix C’s suffix RH3-6LoRH Type 4 RH3-6LoRH Type 3 IPv6 Prefix B’s suffix A’s suffix C’s suffix Root = encaps B C = decaps DestA
  • 134. 136 +- ... -+-+- ... -+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+... |11110001| RH3(128bits)| RH3(2*16bits)| RFC 6282 Dispatch |Page 1 | 6LoRH type 4| 6LoRH Type 1 | + LOWPAN_IPHC +- ... -+- ... +-+-+-+- ... -+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+... <- RFC 6282 -> +-----------+-----------+ | Type | Size Unit | +-----------+-----------+ | 0 | 1 | | 1 | 2 | | 2 | 4 | | 3 | 8 | | 4 | 16 | +-----------+-----------+ <=> IPv6 header Routing header Hop Hop Dec.Hop Hdrs + Payload
  • 135. 137 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
  • 136. 138 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
  • 137. 139 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
  • 138. 140 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.
  • 139. 141 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.
  • 140. 142 •+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+... •|Frag type|Frag hdr |11110001| RPI | IP-in-IP | RFC 6282 Dispatch •|RFC 4944 |RFC 4944 | Page 1 | 6LoRH | 6LoRH | + LOWPAN_IPHC •+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+... • <- RFC 6282 -> • •+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+... •|Frag type|Frag hdr | •|RFC 4944 |RFC 4944 | Payload (cont) •+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+... •+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+... •|Frag type|Frag hdr | •|RFC 4944 |RFC 4944 | Payload (cont) •+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+... <=> IPv6 header HbH header IPv6 header Hdrs + PayloadRPI in RPL option
  • 141. 143 +-+-+-+-+-+-+- ... +-+-+- ... -+-+-- ... -+-+- ... -+-+-+-+-+ ... +-+-+-... |11110001 |SRH-6LoRH | RPI-6LoRH | IP-in-IP | NH=1 |11110CPP| UDP | UDP |Page 1 |Type1 S=2 | | 6LoRH | IPHC | UDP | hdr |payload +-+-+-+-+-+-+- ... +-+-+- ... -+-+-- ... -+-+- ... -+-+-+-+-+ ... +-+-+-... <-8bytes-> <- RFC 6282 -> No RPL artifact One may note that the RPI is provided. This is because the address of the root that is the source of the IP-in-IP header is elided and inferred from the InstanceID in the RPI. Once found from a local context, that address is used as Compression Reference to expand addresses in the RH3-6LoRH. <=> IPv6 header UDP hdr UDP PayloadRouting hdr Hop Dec.HopHbH RPIIPv6 header
  • 143. 145
  • 144. 146 • Adds Centralized routing (Traffic Engineering) to RPL E.g. Root coordinates with PCE • Add limited Storing in Non-Storing mode and vice versa Enough topology info in non-storing route optimization at the root Local compression; RPL source route header becomes loose • Also support for transversal route in Storing Mode Works for storing and non storing routes • Need topological information and / or device constraints e.g. how many routes can a given RPL router store?
  • 145. 147
  • 146. 148 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Src: X Dest: 56 Via: 13 Via: 24 Stuff Src: X Dest: 56 Stuff Via: 35 Via: 46 Src: Root Dest: 56 RPI
  • 147. 149 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 New (projected) DAO with path segment unicast to target 56 via 35 (ingress) and 46 (egress) 56
  • 148. 150 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Storing mode DAO with lifetime along segment
  • 149. 151 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 DAO-ACK (alt: non storing DAO) unicast, self 35 as parent, final destination 56 as target
  • 150. 152 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 DAO from 46 installs a route to 56 in 35 (all nodes in projected route from ingress included to egress excluded) => egress should already have a route to target 56 via 46 Preexisting connected route to 56
  • 151. 153 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Non source routed DATA Path
  • 152. 154 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Non source routed DATA Path Loose Source routed DATA Path Packet to 13, RH 24, 35, 56
  • 153. 155 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Src: X Dest: 56 Via: 13 Via: 24 Stuff Src: X Dest: 56 Stuff Via: 35 Src: Root Dest: 56 RPI Via: 46
  • 154. 156 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 Adding New (projected) DAO with path segment unicast to target 56 via 13 (ingress), 24, and 35 (egress) 56
  • 155. 157 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Storing mode DAO (forced) with lifetime along segment Storing mode DAO with lifetime along segment
  • 156. 158 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 DAO-ACK unicast, self 13 as parent, final destination 56 as target
  • 157. 159 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 56 via 46 Preexisting connected route to 56 56 via 35 56 via 24
  • 158. 160 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Non source routed DATA Path
  • 159. 161 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Src: X Dest: 56 Via: 13 Via: 24 Stuff Src: X Dest: 56 Stuff Via: 35 Src: Root Dest: 56 RPI Via: 46
  • 160. 162 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 ALT: Adding New (projected) DAO with path segment unicast to target 35 via 13 (ingress) and 24 (egress) 56
  • 161. 163 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Storing mode DAO with lifetime along segment
  • 162. 164 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 DAO-ACK unicast, self 13 as parent, final destination 56 as target
  • 163. 165 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 56 via 46 Preexisting connected route to 56 Preexisting connected route to 35 35 via 24
  • 164. 166 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 routed DATA Path Loose Source routed DATA Path Packet to 35, RH 56 routed DATA Path
  • 165. 167 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Src: X Dest: 56 Via: 13 Via: 24 Stuff Src: X Dest: 56 Stuff Via: 35 Src: Root Dest: 56 RPI Via: 46
  • 166. 168
  • 167. 169
  • 168. 170 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56
  • 169. 171 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56
  • 170. 172 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56
  • 171. 173 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 New non-storing P-DAO with path segment unicast to target 41 via 42 + 43
  • 172. 174 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 DAO ACK
  • 173. 175 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Packet for 41
  • 174. 176 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 IP in IP encapsulation with SRH 42, 41
  • 175. 177 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 storing P-DAO with path segment unicast to target 51 via 41 (egress)
  • 176. 178 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Packet for 51
  • 177. 179 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 IP in IP encapsulation with SRH 42, 41
  • 178. 180 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Packet for 51
  • 179. 181
  • 180. 182 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56
  • 181. 183 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56
  • 182. 184 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56
  • 183. 185 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 New (projected) DAO with path segment unicast to target 53 via 41 (ingress), 42 and 43 (egress)
  • 184. 186 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Storing mode DAO with lifetime along segment
  • 185. 187 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Storing mode DAO with lifetime along segment
  • 186. 188 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 DAO-ACK unicast, self 41 as parent, final destination 53 as target
  • 187. 189 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56
  • 188. 190
  • 189. 191 • In conventional IP multicast forwarding, the packets of a given multicast "flow" are forwarded along a tree that has been constructed for the specific purpose of carrying that flow. This requires transit nodes to maintain state on a per-flow basis, and requires the transit nodes to participate in multicast-specific tree building protocols. The flow to which a packet belongs is determined by its IP source and destination address fields. • BIER (Bit Index Explicit Replication) is an alternative method of multicast forwarding. It does not require any multicast-specific trees, and hence does not require any multicast- specific tree building protocols. Within a given "BIER domain", an ingress node encapsulates a multicast data packet in a "BIER header". • The BIER header identifies the packet's egress nodes in that domain. Each possible egress node is represented by a a single bit within a bitstring; to send a packet to a particular set of egress nodes, the ingress node sets the bits for each of those egress nodes, and clears the other bits in the bitstring. Each packet can then be forwarded along the unicast shortest path tree from the ingress node to the egress nodes. Thus there are no per-flow forwarding entries.
  • 190. 192 • A Bloom filter is a space-efficient probabilistic data structure, conceived by Burton Howard Bloom in 1970, that is used to test whether an element is a member of a set. False positive matches are possible, but false negatives are not – in other words, a query returns either "possibly in set" or "definitely not in set". Elements can be added to the set, but not removed (though this can be addressed with a "counting" filter); the more elements that are added to the set, the larger the probability of false positives. • draft-ietf-roll-ccast-01 Constrained-Cast: Source-Routed Multicast for RPL uses Bloom filters as a compressed form of a bitmap. It is Source-Routed minded so the elements in the set are the hops as opposed to the destinations. A packet is forwarded if the downward link appears to belong to the set. A false positive has a packet going deeper than it should. IOW Bloom trades space in the packet with unwanted transmissions.
  • 191. 193
  • 197. 199 B A F G H I J C D E K Target Transit J K I K E K D E C D B C F B A B …
  • 199. 203 Addres s Bit A 9 B 11 C 8 D 6 E 2 F 4 G 10 H 7 I 3 J 5 K 1 BBR D 00000000001 00000000100 00010000000 00000000010 00000010000 00100000000 00001000000 00000001000 00000100000 01000000000 10000000000 B A F G H I J C D E K
  • 200. 204 BBR D 00010000101 00000000100 00010000000 00000000010 00000010010 00100000000 00001000000 00010001101 00010101101 11010111111 11111111111 B A F Node sends a DAO to its parent, advertising: n Node’s bitmap = OR (child I’s bitmap) OR Node’s bit i=1 K
  • 201. 205 BBR D 00010000101 00000000100 00010000000 00000000010 00000010010 00100000000 00001000000 00010001101 00010101101 11010111111 11111111111 B A F B sends a DAO to its parent, advertising B’s bitmap = (A’s bitmap OR F’s bitmap OR B’s bit) K
  • 202. 206 BBR D 00010000101 00000000100 00010000000 00000000010 00000010010 00100000000 00001000000 00010001101 00010101101 11010111111 11111111111 B A F Child BitMap A 00000000100 F 00010000000 K
  • 203. 207 BBR D 00010000101 00000000100 00010000000 00000000010 00000010010 00100000000 00001000000 00010001101 00010101101 11010111111 11111111111 B A F Child BitMap E 11010111111 I 00100000000 J 00001000000 K I J E
  • 204. 208 BBR D 00010000101 00000000100 00010000000 00000000010 00000010010 00100000000 00001000000 00010001101 00010101101 11010111111 11111111111 B A F K I J E Root computes destination bitmap as: n Dest bitmap = OR (node i’s bit) i=1
  • 205. 209 BBR D 00010000101 00000000100 00010000000 00000000010 00000010010 00100000000 00001000000 00010001101 00010101101 11010111111 11111111111 B A F K I J E Node computes (Dest bitmap AND child’s bitmap) for all children When result is TRUE (non-zero), node copies the packet as a MC level unicast to child.
  • 206. 210 BBR D 00010000101 00000000100 00010000000 00000000010 00000010010 00100000000 00001000000 00010001101 00010101101 11010111111 11111111111 B A F K I J E If most of the children are targeted, it makes sense to broadcast the message to all children. In that case, receiving children perform the OR operation with the bitmap they advertise in DAO and drop on receive is the result is not TRUE
  • 207. 211 BBR D 00010000101 00000000100 00010000000 00000000010 00000010010 00100000000 00001000000 00010001101 00010101101 11010111111 11111111111 B A F K I J E Root computes destination bitmap as Dest bitmap = (A’s bit OR F’s bit OR J’s bit) = 00011000100
  • 208. 212 BBR D 00010000101 00000000100 00010000000 00000000010 00000010010 00100000000 00001000000 00010001101 00010101101 11010111111 11111111111 B A F K I J E Dest bitmap = 00011000100 (Dest bitmap AND J’s bitmap) = 00001000000 -> MAC unicast to J (Dest bitmap AND I’s bitmap) = 00000000000 -> NO copy to I (Dest bitmap AND E’s bitmap) = 00010000100 -> MAC unicast to E
  • 209. 213 BBR D 00010000101 00000000100 00010000000 00000000010 00000010010 00100000000 00001000000 00010001101 00010101101 11010111111 11111111111 B A F K I J E Dest bitmap = 00011000100 In B: (Dest bitmap AND B’s bitmap) = most bits set -> B broadcasts In A: (Dest bitmap AND A’s bitmap) = 00000000100 -> A accepts In F: (Dest bitmap AND F’s bitmap) = 00010000000 -> F accepts
  • 210. 214
  • 211. 215 Source S (J is 00001000000) Packet to 00011000100 B A F K I J E Root computes destination bitmap as Dest bitmap = (A’s bit OR F’s bit OR J’s bit) = 00011000100 Forwarding expected to follow (A is 00000000100) (F is 00010000000) Packet to 00011000100
  • 212. 216 Source S Ack = 00001000000 B A F K I J E Acks are aggregated on the return path Ack = 00011000100 Ack = 00010000000 Ack = 00000000100 Ack = 00010000100 Ack = 00010000100
  • 213. 217 Source S 00001000000 Packet to 00011000100 B A F K I J E loss on the way in the branch that leads to A and F 00000000100 00010000000
  • 214. 218 Source S Ack = 00001000000 B A F K I J E Ack = 00001000000 Root computes destination bitmap – ack bitpmap Retrans bitmap = Dest bitmap - Ack bitmap = 00011000100 - 00001000000 = 00010000100
  • 215. 219 Source S (J is 00001000000) Packet to 00010000100 B A F K I J E Retransmission bitmap indicates only along failed branch(es) Forwarding expected to follow (A is 00000000100) (F is 00010000000) Packet to 00010000100
  • 216. 220 Source S B A F K I J E Acks are aggregated on the return path Ack = 00010000100 Ack = 00010000000 Ack = 00000000100 Ack = 00010000100 Ack = 00010000100
  • 217. 221
  • 218. 222 Root Rank 1 Rank 110 P: Rank 250 Rank 260 B: Rank 530 D: Rank 510 C: Rank 610 E: Rank 620 A: Rank 380 Initial situation; • Rank is computed on some metric e.g. LQI. • Node A has a single parent, node P • A can hear D and C which are in its subdag • A can hear B and E which are not
  • 219. 223 Root Rank 1 Rank 110 P: Rank 250 Rank 260 A: Rank 380 B: Rank 530 D: Rank 510 C: Rank 610 E: Rank 620 Say that the radio connectivity between A and P dies. A looses it only feasible parent. Its neighbors are all deeper (higher Rank) so it cannot reattach without risking a loop. Attaching to D and C would create a loop. Attaching to E or B would not create a loop. Trouble is A does not know. 223
  • 220. 224 Root Rank 1 Rank 110 P: Rank 250 Rank 260 B: Rank 530 D: Rank ∞ C: Rank ∞ E: Rank 620 RRFC 6550 says that node A must detach, freeze, and wait for the resulting of the freezing. Freezing may be done by poisoning, IOW sending infinite rank. A (preferable IMHO) alternative is to form a floating DAG, which spreads the freezing differently with the advantage to maintain the shape of the DODAG in place After some time, the devices that depended on A are (mostly) frozen or re-parented elsewhere. From that point, RPL says that the frozen nodes can all reparent, that’s A, D and C here, and then the network is fixed The problem is the “After some time” above. That is disruptive to traffic, which can be unacceptable A: Rank ∞ 224
  • 221. 225
  • 222. 226 Root Rank 1 Rank 110 P: Rank 250 Rank 260 B: Rank 530 D: Rank 510 C: Rank 610 E: Rank 620 A selects a number if neighbors as prospective parents. (Optional) We create a new RPI flag for loop detection. A sends packets using them randomly setting its Rank in RPI to OxFFFF, and sets a new RPI “P” flag. (Alt is set rank to 0xFFFE) A node that receives a packet with RPI “P” flag from a parent returns it with the RPI “F” flag set, indicating forwarding error and A removes it from the prospective parents. Alt, it may forward via another parent. During that period, A destroys any packet coming back with the RPI ”P” flag on. A: Rank 380 Proposal use to keep forwarding and to use the data path to detect lower nodes that are feasible successors: 226
  • 223. 227 Root Rank 1 Rank 110 P: Rank 250 Rank 260 B: Rank 530 D: Rank 510 C: Rank 610 E: Rank 620 Proposal use the datapath to select a parent faster: A selects a number if neighbors as prospective parents. We create a new OAM which allows A to “ping” the Poot. The packet indicates the selected parent. (Optional) The nodes that forward the packet add their IP address as a trace root A sends a version of that packet unicast to all the selected neighbors A: Rank 380 227
  • 224. 228 Root Rank 1 Rank 110 P: Rank 250 Rank 260 B: Rank 530 D: Rank 510 C: Rank 610 E: Rank 620 The messages that are responded by the root contain feasible successors. Getting that back may be slow. A picks them as they come, keeping the best so far as preferred parent A: Rank 380 228
  • 225. 229 Root Rank 1 Rank 110 P: Rank 250 Rank 260 B: Rank 530 D: Rank 510 C: Rank 610 E: Rank 620 Loops will cause the packet to come back to A. A recognizes them (e.g. source address is A, a new flag in RPI), and eliminates the neighbor indicated in the packet from the potential parents A: Rank 380 229
  • 226. 230
  • 227. 231 An Arc is a 2 ended reversible path Edges are directed outwards; links within are reversible An arc is resilient to any link or Junction break by returning links Links are oriented from cursor to edges and returned by moving the cursor. C Rev Rev Rev Rev EdgeCursor
  • 228. 232 An infrastructure Arc is multihop An Edge Junction terminates one reversible link An Intermediate Junction terminates two reversible links Links are oriented from a mobile cursor (C) Junction outwards R A collapsed Arc does not have an Intermediate Junction An Edge Junction may belong to multiple collapsed Arcs C Rev Rev Rev Rev Edge JunctionIntermediate Junction 232
  • 229. 233 Junctions may have multiple incoming links An Edge Junction might have multiple outgoing links An intermediate Junction has no outgoing link but along the Arc J C Rev Rev Rev Rev 233
  • 230. 234 ROOT A B Software-defined Projected ARROW Arcs for RPL Routing Over Wireless - Metrics are accumulated as usual in RPL (separated from Rank) - Siblings are allowed (all ARC members have the same Rank) - Rank of ARC members defines ARC height
  • 231. 235 - Sparrow requires non-storing mode (NS-mode). - Nodes must advertise at least 2 parents and report metrics - Root computes ARC Set based on NS-mode DAO - Need to update DAO projection to enable inverting parent->child links 235
  • 233. 237 In blue the preferred parent path In red the alt path as RPL computes them based on Rank relationship. These « arrows » are advertised to the root using NS-Mode We see that most nodes do not have 2 non-congruent solutions (in fact, only J does!) R A D L B K J C E F G H I M N Rank = 1 Rank = 3 Rank = 2 Rank = 4 Rank = 5 Rank = 6 Rank = 5 Rank = 7 Rank = 10 Rank = 8 Rank = 5 Rank = 10 Rank = 9 Rank = 10 Rank = 12 237
  • 234. 238 Original RPL DAG R A D L B K J C E F G H I M N ARC Re-organized DAG R A D L B K J C E F G H I Rev Rev Rev Rev Rev Rev M N Rev 238
  • 235. 239 DAG visualization == ARC visualization R A D L B K J C E F G H I M N R A D L B K J C E F G H I Rev Rev Rev Rev Rev Rev M N Rev 239
  • 236. 240 1) Root considers changes made on DODAG and notifies nodes, e.g. it tells C that D is not more a feasible successor and it tells D that C is a feasible successor. Same goes between E and F. This can be done with a novel variation of the DAO projection 2) For collapsed ARCs, e.g. D, we are all set 3) For other nodes that are not on collased ARCs, the root computes a path along the ARC towards the other exit of the ARC. For Node C that is Node B. R A D L B K J C E F G H I M N R A D L B K J C E F G H I Rev Rev Rev Rev Rev Rev M N Rev Use C as alt parent Do Not Use D as alt parent 240
  • 237. 241 1) The path to B is installed as either storing or non storing projected DAO 2) In NS Mode the source route path from the node to the other ARC edge is indicated to each node 3) In Storing Mode, a route is created from both ends of the ARC allowing each edge (a,d all nodes in between) to route to the other edge 4) If C loses connectivity to A, it uses a tunnel to B till RPL completes local repair. Tunnel has a routing header in NS mode. 5) When the Edge decaps, it must forward outside the ARC; it cannot reinject in the ARC. R A D L B K J C E F G H I Rev Rev Rev Rev Rev Rev M N Rev Non storing DAO: indicating Source Route path to B Source Route path to B Projected DAOR A D L B K J C E F G H I Rev Rev Rev Rev Rev Rev M N Rev DAO Ack Storing mode Route to B Projected DAO 241
  • 238. 242
  • 239. 243 • P2P RPL, RFC 6997 (experimental) DIO with one or more target options build a DODAG with a limited diameter Nodes that see a DAO back become participants and learn a path Other nodes forget about the DIO after a time out • AODV RPL (WIP) Similar but builds 2 DODAGs, one in each direction Expects asymmetrical links, different paths in both direction
  • 241. 245 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:
  • 242. 246 Traffic Control Traffic Holes – Global Repair only Routing Table Sizes For Your Reference
  • 243. 247 • AODV RPL to be Standard track Reactive model (P2P RPL rfc6997 is experimental) • Centralized route computation (e.g. draft-ietf-roll-dao-projection ), SDN-Like • BIER unicast and multicast routing, Storing vs. Non-Storing, bit-index vs. Bloom Filters • DAG limitations and Fast Reroute 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
  • 244. 248 • 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 •
  • 245. © 2012 Cisco and/or its affiliates. All rights reserved.IoT6 249Unclassified “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.”
  • 246. © 2010 Cisco and/or its affiliates. All rights reserved. 250UnclassifiedBRKEWN-3012 Questions
  • 250. 254
  • 251. 255 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
  • 252. 256 Multiple L3 Multicast messages RA Multiple L2 Broadcast messages 1. MAC address reachability flooded over L2 switch fabric 2. Device sends RS to all routers link scope mcast 3. Router answers RA (u or m) 4. Device sends mcast NS DAD to revalidate its address(es) 5. Device sends mcast NA(O) 6TISCH uses a backbone router, limits the broadcast domain to the backbone VM, NFV,Wireless or IoT device moves:
  • 253. 257 Nbr Solicitation L3 Multicast L2 broadcast Packet to Target that is missing in router ND cache Nbr Advertisement Unicast 1. Router looks up ND cache (say this is a cache miss) 2. Router sends NS multicast to solicited-node multicast @; here that is 3333 FF00 00A1 1. Targets answers unicast NA 2. Target revalidates ND cache for the router, usually unicast 3. Router creates ND cache entry 6TiSCH proxies at the backbone router on behalf of device Packet comes in for 2001:db8::A1
  • 254. 258 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
  • 255. 259 Scalable and Multi-Link Deterministic e2e (DetNet) Registration based ND IP guard (admin knows what’s where) => Authoritative Registrar(s) Backbone Routers RPL root, ND proxy Legacy IPv6 devices Authoritative Registrar Authoritative Registrar / 6LBR Intermediate Registrar / 6LR Intermediate Registrar option. ND proxy Backbone router (ND proxy)
  • 256. 260 6TiSCH 6TiSCHSensor Actuator Backbone Router Management Wireless Controller Backbone Router Single Multilink IPv6 Subnet with free inner mobility (same subnet == no renumbering) Virtual Service Engine (virtual PLC, PCE …) + IPv6 ND registrar + Network Function Virtualization (NFV) NAC /Firewall VPN Concentrator IPv6 ND registration and proxy operation
  • 257. 261 Wireless Router Wireless Router Mesh Root Mesh Root Wireless RouterWireless Router
  • 258. 262
  • 259. 263 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 ) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • 260. 264 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
  • 261. 265 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
  • 262. 266 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)
  • 263. 267 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)
  • 264. 268 The BR maintains a route to the WSN node for the DAO Lifetime over instance VRF. VFR may be mapped onto a VLAN on the backbone. RPL DAO Host Route Optional NA(O)
  • 265. 269 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
  • 266. 270 DAD option has: Unique ID TID (SeqNum) Defend with NA if: Different OUID Newer TID NS DAD (ARO) NA (ARO) NS (ARO)
  • 267. 271 DAD option has: Unique ID TID (SeqNum) Defend with NA if: Different OUID Newer TID DAR NA (ARO) DAD
  • 268. 272 RPL DAO Optional NA(ARO) Host Route DAD option has: Unique ID TID (SeqNum) Defend with NA if: Different OUID Newer TID NA (ARO) with older TID (loses)
  • 269. 273 Packet NS lookup NA ARO option has: Unique ID TID (SeqNum) NA (ARO)
  • 270. 274 NS lookup Mixed mode ND BBR proxying over the backbone NA (ARO) Packet
  • 271. 275
  • 272. 276 6LR 6LBR 6BBR Router/Serv er LP Node RPL Ethernet RA (unicast) RA (u|mcast) DIO Router/Serv er Router/Serv er EthernetRadio 1 Hop SLLA PIO MTU SLLA CONTEXT PIO MTU SLLA CONTEXT PIO MTU RA (u|mcast) RS (mcast) PIO RA (u|mcast) PIO MTU SLLA CONTEXT
  • 273. 277 6LR 6LBR 6BBR Router/Serv er LP Node Radio Mesh Ethernet NA (~O) NS (ARO) NS (ARO) DAR, RPL DAO Router/Serv er Router/Serv er EthernetRadio 1 Hop NS lookup NS DAD NS (ARO) Create proxy state Classical NDRPL6LoWPAN ND Efficient ND NA (ARO) DAC (ARO) NA (ARO) 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er
  • 274. 278 6LR 6LBR 6BBR Router/Serv er LP Node RPL Ethernet NS DAD (ARO) NS (ARO) NS (ARO) DAR (ARO) Router/Serv er Router/Serv er EthernetRadio 1 Hop SRC = UNSPEC DST = SNMA TGT = LPN UID = LPN TID included SRC = 6LR * DST = 6LBR REG = LPN UID = LPN TID included SRC = LPN_ll * DST = 6LR_ll * TGT = LPN ** SLLA = LPN UID = LPN TID included SeND? SRC = 6LBR DST = 6BBR * TGT = LPN SLLA = L6BR UID = LPN TID included * Global / ULA * Can be Anycast Create binding state Create proxy state * link local unique EUI-64 ** any LPN IPv6 address RFC 6775 does not use target but src 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er
  • 275. 279 6LR 6LBR 6BBR Router/Serv er LP Node RPL Ethernet NA (O) * NA (ARO) NA (ARO) DAC (ARO) Router/Serv er Router/Serv er EthernetRadio 1 Hop SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = 6LR_ll DST = LPN_ll TGT = LPN TLLA = LPN UID = LPN TID included SRC = 6BBR DST = 6LBR TGT = LPN TLLA = L6BR UID = LPN TID included * Omitted in general ** link local DAD time out SRC = 6BBR_ll ** DST = NS SRC TLLA = L6BR TGT = LPN Adding TLLAO since dest. is not target 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er
  • 276. 280 6LR 6LBR 6BBR Router/Serv er LP Node RPL Ethernet NA (~O) NS (ARO) NS (ARO) RPL DAO Router/Serv er Router/Serv er EthernetRadio 1 Hop SRC = 6BBR DST = NS SRC TGT = LPN TLLA = 6LBR SRC = 6LR DST = Parent * or Root TGT = LPN UID missing : ( TID included SRC = LPN_ll DST = 6LR_ll TGT = LPN SLLA = LPN UID = LPN TID included SRC = 6LBR DST = 6BBR TGT = LPN SLLA = L6BR UID = LPN * TID included * Parent in storing mode * From binding state NS lookup RPL cannot DAD for lack of UID 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er
  • 277. 281
  • 278. 282 6LR 6LBRLP Node NS (ARO) DAR (ARO) SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = LPN_ll DST = 6LR_ll TGT = LPN ** SLLA = LPN UID = LPN TID included Collision of binding state within RPL DODAG Different UID for addr. LPN NA (ARO, s=1) DAC (ARO, s=1) SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = 6LR_ll DST = LPN_ll TGT = LPN TLLA = LPN UID = LPN TID included 6LR 6LBRLP Node
  • 279. 283 6LR 6LBR 6BBRLP Node RPL NS (ARO) NS (ARO) DAR (ARO) EthernetRadio 1 Hop SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = LPN_ll DST = 6LR_ll TGT = LPN SLLA = LPN UID = LPN TID included Create binding state Collision of proxy state between 6LBRs attached to a same 6BBR NA (ARO, s=1) NA (ARO, s=1) DAC (ARO, s=1) SRC = 6BBR DST = 6LBR TGT = LPN UID = LPN TID included 6LR 6LBR 6BBRLP Node
  • 280. 284 Router/Serv er Router/Serv er Router/Serv er 6LR 6LBR 6BBRLP Node RPL Ethernet NS DAD (ARO) NS (ARO) NS (ARO) DAR (ARO) EthernetRadio 1 Hop SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = LPN_ll DST = 6LR_ll TGT = LPN SLLA = LPN UID = LPN TID included SRC = 6LBR DST = 6BBR SLLA = L6BR TGT = LPN UID = LPN TID included Create binding state Create proxy state Collision with legacy device attached to the backbone 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er
  • 281. 285 Router/Serv er 6LR 6LBR 6BBRLP Node RPL EthernetRadio 1 Hop NA (ARO, s=1) NA (ARO, s=1) DAC (ARO, s=1) SRC = NODE DST = 6BBR TGT = LPN UID = LPN TID included Collision with legacy device Ethernet NA (O) SRC = 6BBR DST = 6LBR TGT = LPN UID = LPN TID included SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = 6LR_ll DST = LPN_ll TGT = LPN UID = LPN TID included 6BBRRouter/Serv er Router/Serv er 6LR 6LBR 6BBRLP Node Router/Serv er Router/Serv er Router/Serv er
  • 282. 286 RPL Ethernet NS DAD (ARO) NS (ARO) NS (ARO) DAR (ARO) EthernetRadio 1 Hop SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = LPN_ll DST = 6LR_ll TGT = LPN SLLA = LPN UID = LPN TID included SRC = 6LBR DST = 6BBR TGT = LPN SLLA = L6BR UID = LPN TID included Create binding state Create proxy state Collision of proxy state between 6BBRs attached to a same backbone Router/Serv er 6LR 6LBR 6BBRLP Node Router/Serv er Router/Serv er
  • 283. 287 6LR 6LBR 6BBRLP Node RPL EthernetRadio 1 Hop NA (ARO, s=1) NA (ARO, s=1) DAC (ARO, s=1) SRC = 6BBR2 DST = 6BBR TGT = LPN2 UID = LPN2 TID2 included Collision of proxy state Ethernet NA (ARO, s=1) SRC = 6BBR DST = 6LBR TGT = LPN UID = LPN TID included SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = 6LR_ll DST = LPN_ll TGT = LPN UID = LPN TID included 6BBR 6BBR 6BBR 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er
  • 284. 288
  • 285. 289 6LR 6LBRLP Node NS (ARO) DAR (ARO) SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = LPN_ll DST = 6LR_ll TGT = LPN ** SLLA = LPN UID = LPN TID included Matches a binding state within RPL DODAG same UID for addr. LPN NA (ARO, s=0) DAC (ARO, s=0) SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = 6LR_ll DST = LPN_ll TGT = LPN TLLA = LPN UID = LPN TID included 6LR 6LBR 6BBRLP Node
  • 286. 290 Router/Serv er Router/Serv er Router/Serv er 6LR 6LBR 6BBRLP Node RPL NS (ARO) NS (ARO) DAR (ARO) EthernetRadio 1 Hop SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = LPN_ll DST = 6LR_ll TGT = LPN SLLA = LPN UID = LPN TID included Create binding state Matches a proxy state associated to another 6LBR attached to a same 6BBR NA (ARO, s=0) NA (ARO, s=0) DAC (ARO, s=0) Update proxy state SRC = 6LBR DST = 6BBR TGT = LPN SLLA = L6BR UID = LPN TID included 6LR 6LBR 6BBRLP Node
  • 287. 291 6LR 6LBR 6BBR 6BBRLP Node RPL Ethernet NS DAD (ARO) NS (ARO) NS (ARO) DAR (ARO) 6BBR 6BBR EthernetRadio 1 Hop SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = LPN_ll DST = 6LR_ll TGT = LPN SLLA = LPN UID = LPN TID included SRC = 6LBR DST = 6BBR TGT = LPN SLLA = L6BR UID = LPN TID included Create binding state Create proxy state Matches a proxy state in another 6BBR attached to a same backbone 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er
  • 288. 292 6LR 6LBR 6BBRLP Node RPL EthernetRadio 1 Hop NA (ARO, s=0) NA (ARO, s=0) DAC (ARO, s=0) SRC = 6BBR2 DST = 6BBR TGT = LPN UID = LPN TID2 included Collision with Older TID Ethernet SRC = 6BBR DST = 6LBR TGT = LPN UID = LPN TID included SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = 6LR_ll DST = LPN_ll TGT = LPN UID = LPN TID included 6BBR 6BBR 6BBR NA (O) Yield silently 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er
  • 289. 293 6LR 6LBR 6BBRLP Node RPL EthernetRadio 1 Hop NA (ARO, s=3) NA (ARO, s=3) DAC (ARO, s=3) SRC = 6BBR2 DST = 6BBR TGT = LPN UID = LPN TID2 included Collision with Newer TID Ethernet NA (ARO, s=3) SRC = 6BBR DST = 6LBR TGT = LPN UID = LPN TID included SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = 6LR_ll DST = LPN_ll TGT = LPN UID = LPN TID included 6BBR 6BBR 6BBR 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er
  • 290. 294
  • 291. 295 6LR 6BBR Router/Serv er LP Node RPL Ethernet NA (~O) Router/Serv er Router/Serv er Radio 1 Hop SRC = 6BBR DST = NS SRC SLLA = 6BBR TGT = LPN NS lookup 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er Data packet Data packet Data packet Data packet
  • 292. 296 6LR 6BBR Router/Serv er LP Node RPL NA (~O) Router/Serv er Router/Serv er Radio 1 Hop SRC = 6BBR DST = NS SRC SLLA = 6LBR TGT = LPN NS lookup 6LR 6LBR 6BBR Router/Serv er LP Node Router/Serv er Router/Serv er Data packet Data packet Data packet Ethernet (Switched)