Pascal Thubert, profile picture
Uploaded byPascal Thubert
PPTX, PDF126 views

IPv6 ND 2020

This document discusses several topics related to IPv6 and low power and lossy networks (LLNs): 1. It outlines the agenda for discussing IPv6 neighbor discovery for point-to-point and transit links, wireless neighbor discovery, RPL routing, and RPL extensions. 2. It notes that LLNs comprise billions of constrained devices interconnected by wireless links, and several standards groups are working on protocols for these networks, including 6LoWPAN, ROLL, and 6TiSCH at the IETF. 3. It argues that IPv6 is necessary for the Internet of Things given the tens of billions of additional smart objects that will be connected, and that the RIPE NCC has now

Embed presentation

Download to read offline
1 / 223
2 / 223
3 / 223
4 / 223
5 / 223
6 / 223
7 / 223
8 / 223
9 / 223
10 / 223
11 / 223
12 / 223
13 / 223
14 / 223
15 / 223
16 / 223
17 / 223
18 / 223
19 / 223
20 / 223
21 / 223
22 / 223
23 / 223
24 / 223
25 / 223
26 / 223
27 / 223
28 / 223
29 / 223
30 / 223
31 / 223
32 / 223
33 / 223
34 / 223
35 / 223
36 / 223
37 / 223
38 / 223
39 / 223
40 / 223
41 / 223
42 / 223
43 / 223
44 / 223
45 / 223
46 / 223
47 / 223
48 / 223
49 / 223
50 / 223
51 / 223
52 / 223
53 / 223
54 / 223
55 / 223
56 / 223
57 / 223
58 / 223
59 / 223
60 / 223
61 / 223
62 / 223
63 / 223
64 / 223
65 / 223
66 / 223
67 / 223
68 / 223
69 / 223
70 / 223
71 / 223
72 / 223
73 / 223
74 / 223
75 / 223
76 / 223
77 / 223
78 / 223
79 / 223
80 / 223
81 / 223
82 / 223
83 / 223
84 / 223
85 / 223
86 / 223
87 / 223
88 / 223
89 / 223
90 / 223
91 / 223
92 / 223
93 / 223
94 / 223
95 / 223
96 / 223
97 / 223
98 / 223
99 / 223
100 / 223
101 / 223
102 / 223
103 / 223
104 / 223
105 / 223
106 / 223
107 / 223
108 / 223
109 / 223
110 / 223
111 / 223
112 / 223
113 / 223
114 / 223
115 / 223
116 / 223
117 / 223
118 / 223
119 / 223
120 / 223
121 / 223
122 / 223
123 / 223
124 / 223
125 / 223
126 / 223
127 / 223
128 / 223
129 / 223
130 / 223
131 / 223
132 / 223
133 / 223
134 / 223
135 / 223
136 / 223
137 / 223
138 / 223
139 / 223
140 / 223
141 / 223
142 / 223
143 / 223
144 / 223
145 / 223
146 / 223
147 / 223
148 / 223
149 / 223
150 / 223
151 / 223
152 / 223
153 / 223
154 / 223
155 / 223
156 / 223
157 / 223
158 / 223
159 / 223
160 / 223
161 / 223
162 / 223
163 / 223
164 / 223
165 / 223
166 / 223
167 / 223
168 / 223
169 / 223
170 / 223
171 / 223
172 / 223
173 / 223
174 / 223
175 / 223
176 / 223
177 / 223
178 / 223
179 / 223
180 / 223
181 / 223
182 / 223
183 / 223
184 / 223
185 / 223
186 / 223
187 / 223
188 / 223
189 / 223
190 / 223
191 / 223
192 / 223
193 / 223
194 / 223
195 / 223
196 / 223
197 / 223
198 / 223
199 / 223
200 / 223
201 / 223
202 / 223
203 / 223
204 / 223
205 / 223
206 / 223
207 / 223
208 / 223
209 / 223
210 / 223
211 / 223
212 / 223
213 / 223
214 / 223
215 / 223
216 / 223
217 / 223
218 / 223
219 / 223
220 / 223
221 / 223
222 / 223
223 / 223
1 IPv6 ND 2020 Pascal Thubert, Rennes January 15th, 2020
2 • The any-to-any paradigm Art: Any par of global addresses can reach one another IoT: Many devices of all sorts, need isolation GAFA: 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 (1980) NCP generation with: All Transmission Groups to L2 peers All Physical Units type 4 nodes, All Virtual Routes (1990) Router CLI with: ID, keys. All links to L2 peers Routes are discovered => Single ‘GRID’ (2000) Router only knows “self” with: ID, certificates Peers are discovered Links are discovered Routes are discovered =>Infinity of self-centric networks
4 Open Standards vs. proprietary COTS* suppliers drive costs down but Reliability, Availability and Security up IP abstraction vs. per MAC/App 802.11, 802.15.4, Sat, 3G, UWB Keep L2 topology simple To Infinity and Beyond… But End-to-End. No intermediate gateway, tunnel, middle boxes & other trick * Commercial, off-the-shelf
5 The current Internet comprises several billion devices Smart Objects will add tens of billions of additional devices IPv6 is the only viable way going forward 1~2 Billions PCs & servers Tens of Billions Smart ObjectsThings Mobile Fixed 2~4 Billions Phones & cars The RIPE NCC has run out of IPv4 Addresses “Today, at 15:35 (UTC+1) on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses.”
6 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 meetsWireless: Mobile Routers (LISP, NEMO) (Proxy) MIPv6 6LoWPAN 6TiSCH ROLL/RPL CoAP ISA100.11a ZigBee/IP
7 • Non-Broadcast Multi-Access network / MultiLinkL subnet IPv6 only supports P2P and transit (ethernet) but by nature, a radio network is NBMA WiND / RPL solves the problem in the IOT space • L3 «VLAN » So far only available with MPLS. New attempts (MTR, RPL instances, SR Flex Algo) • L4/5 hints Flow Label given away to fwd plane; DetNet Flow indication? • Microflows / compound flows InWSN, a flow has multiple sources • Local and Global IP Mobility Unification (eg MANEMO, LISP+RPL)
8 We are in for a change: Basic Internet structures and expectations reconsidered Revisiting classical end-to-end and any-to-any Revisiting best effort to new levels of guarantees (deterministic) New function placement, new operations Merge IOT data at the Information layer, Gossip IOT information at the knowledge layer Impacts network, transport, security models
9 Agenda (part 1, Introduction) IOT Standards IEEE and LLNs IETF and 6LoWPAN IETF 6TiSCH Routing Concepts Forms of Routing Loopless structures Routing Over Radios
10 Agenda (part 2, IPv6 ND for P2P and transit links) The IPv6 Neighbor Discovery Protocol RFC 4861: Discovery and Resolution RFC 4862: SLAAC Applying Classical ND toWireless Link Model Can and cannot do
11 Agenda (part 3, Wireless ND) Wireless Neighbor Discovery (WiND) Registration (RFC 8505) Backbone Router Address Protection and SAVI MultiLink Subnet Classical RPL RPL-Unware Leaves Using RPL Packet Information
12 Agenda (part 4, RPL Route Projection and extras) RPL Route Projection Shortening Long SRH Transversal Routes In Non-Storing Mode In Storing Mode Fast Reroute in RPL (non standard) Using the Data Plane Using the Control Plane
13 IOT Standards
14
15 Cheap Install Deploying wire is slow and costly Global Coverage From Near Field to Satellite via 3/4G Everywhere copper/fiber cannot reach Cheap multipoint access New types of devices (Internet Of Things) New usages (X-automation, Mobile Internet)
16 LLNs comprise a large number of highly constrained devices (smart objects) interconnected by predominantly wireless links of unpredictable quality LLNs cover a wide scope of applications Industrial Monitoring, Building Automation, Connected Home, Healthcare, Environmental Monitoring, Urban Sensor Networks, Energy Management, AssetTracking, 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
17 LLNs operate with a hard, very small bound on state LLNs are optimised for saving energy in the majority of cases Traffic patterns can be MP2P, P2P and P2MP flows 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
18 IEEE Wireless Standards 802.11 Wireless LAN 802.15 Personal Area Network 802.16 Wireless Broadband Access 802.22 Wireless Regional Area Network WiFi 802.11a/b/g/n/ah IEEE 802 LAN/MAN 802.15.1 Bluetooth 802.15.2 Co-existence 802.15.3 High Rate WPAN 802.15.4 Low Rate WPAN 802.15.5 Mesh Networking 802.15.6 Body Area Networking 802.15.7 Visible Light Communications 802.15.4e MAC Enhancements 802.15.4f PHY for RFID 802.15.4g Smart Utility Networks TV White Space PHY 15.4 Study Group 802.15.4d PHY for Japan 802.15.4c PHY for China • Industrial strength • Minimised listening costs • Improved security • Improved link reliability • Support smart-grid networks • Up to 1 Km transmission • >100Kbps • Millions of fixed endpoints • Outdoor use • Larger frame size • PHY Amendment • Neighborhood Area Networks TSCH Amendments retrofitted in 802.15.4-2015
Cisco Confidential© 2012 Cisco and/or its affiliates. All rights reserved. 19 Initial activities focused on wearable devices “PersonalArea 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 toTHz Various applications not necessarily IP based Focus is on “specialty”, typically short range, communications If it is wireless and not a LAN, MAN, RAN, orWAN, it is likely to be 802.15 (PAN) The only IEEE 802Working Group with multiple MACs http://www.ieee802.org/15/pub/TG4.html IEEE 802.15 WPAN™ Task Group 4 (TG4) Charter
20 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
21 • Specifies PHY and MAC only • Medium Access Control Sub-Layer (MAC) Responsible for reliable communication between 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)
22
23
24 LAKE 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
25 • Gateways vs. end-to-end principle • Hindrance from proprietary technologies • Vertical solutions, hard to generalize to large scale driving costs down
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 • ProprietaryWSN 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 • IETFWG 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 forWSN 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-ietf-6tisch-architecture Bluetooth Low Energy DECT Ultra Low Energy Zwave PLC Near Field Comms BACNET 802.11ah 802.15.4eTSCH
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) ~ now 6LoWPAN + RPL stack ( that’s 6TiSCH ! ) 6LoWPAN HC + ND < 2022 6LoWPAN + RPL stack (that will be 6IoT, generalizing 6TiSCH stack on all LLN links) Next Reliable and Available Wireless, Call Admission control and Traffic Engineering Notes: • With Wireless ND we claim that Low Power Wi-Fi is an LLN link => extend to Wi-Fi and 802.11 OCB
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 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
33 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 inThread, ZigbeeIP, … Now generalizing on all LLN technologies with IETF 6lo GW
34
35 Deterministic IPv6 over IEEE802.15.4TimeSlotted Channel Hopping (6TiSCH) TheWorking Group will focus on enabling IPv6 over theTSCH mode of the IEEE802.15.4 standard.The scope of theWG 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.4TSCH 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. 6TiSCH builds a MultiLink Subnet (MLSN) CombiningWiND for 6LN<->6LR and RPL for 6LR<->6LR Also Reliable andAvailableWireless (RAW) Scheduling => Mostly NOT specific to 802.15.4TSCH WG charter
36 6TiSCH has to make components work together and push new work https://tools.ietf.org/html/rfc8505 https://tools.ietf.org/html/draft-ietf-6lo-backbone-router https://tools.ietf.org/html/draft-ietf-6lo-ap-nd https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery https://tools.ietf.org/html/draft-thubert-roll-unaware-leaves 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-architecture https://tools.ietf.org/html/draft-ietf-6tisch-msf https://tools.ietf.org/html/rfc8480 (6P Protocol) https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-zerotouch-join WG deliveries
37 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 Scheduling functions IEEE 802.15.4 TSCH 6LoWPAN HC / 6LoRH HC IPv6 RPL 6top TCP UDP ICMP PCEP/PCC CoAP/OSCORE 6LoWPAN ND } Applications CoJP SF
38 BBR A BBR B BBR C BBR D
39 BBR A BBR B BBR C BBR D
40 Next problem: Reliable and Available Wireless • Due to uncontrolled interferences, including the self-induced multipath fading, deterministic networking can only be approached on wireless links. • The radio conditions may change -way- faster than a centralized PCE can adapt and reprogram, in particular when the controller is distant and connectivity is slow and limited. • RAW separates the path computation time scale at which a complex path is recomputed from the path selection time scale at which the forwarding decision is taken for one or a few packets. • RAW operates at the path selection time scale. The RAW problem is to decide, within the redundant solutions that are proposed by the PCE, which will be used for each packet to provide a Reliable andAvailable service while minimizing the waste of resources. Controller Wireless network FAST SLOW LARGE SMALL SLOW Reliability & Availability vs. Energy & Bandwidth
41 Routing Concepts
42
43 • Hidden terminal • Interference domains grows faster that range • Density => low power => multihop => routing
44 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 SinceARPANET, 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, manualTE Need additions for reroute / fast reroute
45 RFC 4861 is Reactive, RFC 8505 is Proactive) Aka Stateful vs. On-demand routing Note: on-demand breaks control vs. Data plane separation P2P-RPL RIP IS-IS AODV-RPL
46 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
47 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)
48 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
49 • Conventional IGPs are Isotropic Meaning that they advertise the same information in all directions This enables shortest path but leads to intense flooding at scale • Some Network have a sense of “North” or “Up” Towards IOT Sinks (e.g., RPL Root) Towards DC Superspine (e.g., RIFTToF) Anisotropic Routing exploits that inherent structure for optimization Different forms of advertisements Aggregated routes Northwards, with disaggregated exceptions
50 • 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 useTunnels / Source Routing around (see Segment Routing) PLAN B can be computed centrally
51
52 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
53 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 DestinationOriented 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
54 • 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
55 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) Preferred parent tree Potential link
56 Clusterhead / Root 5 0 1 1 1 2 2 2 2 2 3 3 3 3 3 3 2 3 5 4 4 4 4 Expose sibling Information to Root Root <-> PCE over southboundAPI Computes a redundantTrack As aggregated Segments => Redundancy (PAREO) SDN /Traffic Engineering Install additional routes “Projected” in the Network RAW Forwarding Decision Delivery SLA (PDR, latency) Optimiez bandwidth and Energy Preferred parent tree Potential link projected Track SDN Controller / PCE Southbound API
57
58 1000*scale => No leak in Internet => Opaque operations Reachability => Radio (IEEE) Addressing => IPv6 (IETF) Density => spatial reuse => Routing
59 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
60 Potentially Large Peer Set Highly Variable Capabilities Selection Per Objective Metrics (e.g. RSSI, ETX…) L3 Reachability (::/0, …) Constraints (Power …)
61 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)
62 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
63 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
64 IPv6 ND
65
66 • Replacement / Modernization of IPv4 Address Resolution Protocol • And ICMP Router Discovery and Redirect • Based on ICMPv6 • Reactive Protocol, heavy usage of multicast / broadcast • Initially defined in 1998 (obsoleting 1996 version) for Ethernet wire • Operate on one hop • Advertises Routers and Parameters • Resolves Layer-2 addresses and maintains a cache (NCE)
67 Unidirectional Links: Not Supported (need reflexive) Broadcast link (e.g., Ethernet): Supported (needTransitive) Multicast capable: benefits from multicast optimization. Point-to-Point (P2P): Supported Shared Media (Non-overlapping prefixes): Supported Non-Broadcast Multi Access (NBMA): Not Supported => No concept of Multi-Link Subnet (MLSN) in classical IPv6
68 • ND resolves mapping of IPv6 and LLA for on-link addresses • Advertising self with Source LLA Option (SLLAO) provides the LLA associated to the IP source of the ND message • Advertising third party address withTarget LLA Option (TLLAO) Mapping the IPv6 address in theTarget field • Source Address can be all-zero (:: aka UNSPECIFIED_ADDRESS) Response is therefore multicast to all hosts • Multiple tricks Responding with RA unicast vs. multicast using unicast MAC for mcast packet
69 Layer-3 unicast and multicast (allows IP auth) Router Discovery included (RA messages) Provides the router Link-Local Address Allow router association independent of prefix (Multiple) Prefix Information in RA msg MTU in RA msg StatelessAddress Autoconfiguration + DHCPv6 Target link-layer address in Redirect (on-link) Neighbor Unreachability Detection (NUD) Hop Limit of 255 contains IPv6 ND on link Reactive Lookup and DAD only (in practice) • Layer-2 broadcast • ICMP Router Discovery and Redirect • No LLA (initially) • Router known only by Global address • One Address, one Prefix per link • Hosts may have different MTUs • Only DHCP • Separate resolution • No equivalent method, half link undetected, no FSM • Off link nodes can spoof ICMP redirect messages • Inverse ARP and reverse ARP for NBMA
70 • Router Solicitation: When an interface becomes enabled, hosts may send out Router Solicitations that request routers to generate Router Advertisements immediately rather than at their next scheduled time. • Router Advertisement: Routers advertise their presence together with various link and Internet parameters either periodically, or in response to a Router Solicitation message. Router Advertisements contain prefixes that are used for determining whether another address shares the same link (on-link determination) and/or address configuration, a suggested hop limit value, etc. Many options have been added since RFC 4861, e.g., RIO • Both can be unicast or multicast, and can announce Link Layer Address (LLA) aka MAC address
71 • Neighbor Solicitation: DuplicateAddress Detection (DAD, S=::, D=Mcast SNMA) Determine the link-layer address of a neighbor (Address Lookup akaAddress Resolution (S=Ucast, D= Mcast SNMA) Verify that a neighbor is still reachable via a cached link-layer address with Neighbor Unreachability Detection (NUD, S=Ucast, D= Ucast). • Neighbor Advertisement: A response to a Neighbor Solicitation message (multicast if source is :: ) Also Unsolicited (akaGratuitous) NeighborAdvertisements to announce a LLA change. • Redirect: Used by routers to inform hosts of a better first hop for a destination
72 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... (SLLAO) +-+-+-+-+-+-+-+-+-+-+-+-
73 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O| Reserved | Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... (SLLAO, PIO, MTU, RIO,…, 6CIO, ABRO, 6LoWPAN Context) +-+-+-+-+-+-+-+-+-+-+-+-
74 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Target Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... (SLLAO, note: TLLAO in RFC 8505) +-+-+-+-+-+-+-+-+-+-+-+-
75 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S|O| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Target Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... (TLLOA) +-+-+-+-+-+-+-+-+-+-+-+-
76 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Target Address + | | + (better first hop) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... (TLLOA, redirected header) +-+-+-+-+-+-+-+-+-+-+-+-
77
78 Form one or many IPv6 LL / UL / GU Address, anytime Controlled by A bit in PIO (vs. DHCP by M and O bits in RA) Host in control of the address, network cannot refuse Neighbor Caches in peers, not hard state NS(DAD) procedure: typically wait one second Alt: RFC 4429 Optimistic DAD Doable with limitation NS / NA done reactively, the router keeps one packet pending!!! Causes loss of response and bad assessment of connectivity draft-linkova-6man-grand/ proposes to push a NA to the routers
79 • RFC 2464 (IPv6 / Eth) and 4291: Address Architecture Defines IPv6 Adresses (LinkLocal vs. ULA vs. GUA, Unicast,Anycast, unspecified, loopback…) Interface ID (IID) based on EUI-64 (derived from MAC address) => deprecated by RFC 8064 • RFC 5292 provides Modern AddressText Representation e.g., 2001:db8:aaaa:bbbb:cccc:dddd::1 • RFC 4941 SLAAC Privacy Extensions (still a need for stable IIDs) • RFC 7136 Significance of IPv6 IID (meaning none) • RFC 7217 Stable and Opaque IIDs (enable private static IIDs) • RFC 7721 Privacy Considerations / RFC 8065 for 6lo / IOT • RFC 8064 Recommendation on Stable IPv6 Interface Identifier updates RFC 2464, RFC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, and RFC 5121 !!!!!!!
80 Applying Classical ND to Wireless
81 • IPv6 ND is designed for P2P andTransit Links Wireless is usually reflexive but natively non-transitive Requires extensions for NBMA (without MAC-layer emulated transitive properties) • IPv6 ND over MAC-layer transit emulation is not wireless friendly E.g., over L2R, learning bridges, Wi-Fi Infrastructure Mode Broadcast intensive (no support for multicast) • Other mismatches Fast Roaming ‘11r’ (ND has no sense of order of events) Intermittent Connectivity (fails all of NUD, DAD and lookup) Fast Initial Link Setup ‘11ai’ (ND is reactive, causes loss of first packets) Increased sensitivity to DoS attacks (Use ND to trigger broadcasts remotely) A B C Non transitive: B can talk to A and C but A and C cannot see reach other
82
83 • A plain radio Interface connects to a physical radio broadcast domain (vs. a MAC-layer emulated broadcast domain) • An IPv6 bidirectional Link can be created where radio broadcast domain overlap enough that A sees B and B sees A. • Link-Local Addresses need to be unique for a communicating pairs only • The IPv6 Link is usually reflexive though often asymmetrical • The IPv6 Link is usually not transitive unless special measures taken • As a node moves, it meets other nodes and IPv6 Links are formed Spoke_C B::C/64 Spoke_A B::A/64 Hub_B B::B/64
84 B b::b/64 C c::c/64 • Matching source IP to router A must with radio mobility E.g., car A attached to RSUs B & C Each RSU enforcing SAVI for its prefix Providing reachability back to a CoA based on its prefix • Aggressive DNA (Detecting Network attachment) Rapid discovery (advertisement interval option in RA) Permanently assess reachability of DRL and prune rapidly May reuse a GUA if come back within reg. lifetime A belongs to 2 subnets at a time A b::a/64 c::a/64
85 SubNet models Spoke_C B::C/64 Spoke_A B::A/64 Hub_B B::B/64 Hub and Spoke HUB_B maintains state for visitors for their registration lifetime and relays packet Node_A MESH::A/64 Node_B MESH::B/64 Node_C MESH::C/64 Node_D MESH::D/64 Node_E MESH::E/64 Route-Over Mesh, requires a routing protocol A B P2P, the simplest subnet model
86
87 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) The backbone router limits the broadcast domain to the backbone VM, NFV,Wireless or IoT device moves: Server
88 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 IPv6 is proxied at the backbone router on behalf of device Packet comes in for 2001:db8::A1
89 No Multicast group, all is broadcasted, all devices must receive and filter Energy wasted when self is not recipient of the multicast A device sends a unicast to the AP and the AP reflects as broadcast Unicast are acknowledged, but broadcast are not A broadcast fromAP must reach all associated nodes: it is sent at the lowest speed and highest energy level Can be 100 times slower that unicast: detrimental to unicast Maw power => Maximum interferences with other wireless transmissions Battery operated devices (e.g. your phone) often ignore 80-90% of broadcasts Saves battery but defeats the protocols, e.g., Duplicate Address Detection
90 Wireless Neighbor Discovery (WiND)
91 • Solicited node multicast requires highly scalable L2 multicast IEEE does not provide it => turns everything into broadcast IPv6 ND appears to work with broadcast on 802.1 fabrics up to some scale ~10K nodes • IPv6 ND requires reliable and cheap broadcast Radios do not provide that => conserving 802.1 properties over wireless is illusory RFC 4862 cannot operate as designed on wireless Address uniqueness is an unguaranteed side effect of entropy • 802.11 expects proxy operation and broadcast domain separation 802.11 provides a registration and proxy bridging at L2 Requires the same at L3, which does (well… did) not exist Implementations provide proprietary techniques based on snooping => widely imperfect  RFC 6775 solves the problem for DAD in one LL  RFC 8505 enables establishing proxy services directly
92 A proactive setting of proxy/routing state to avoid multicast due to reactive Duplicate address detection and lookup in IPv6 ND RFC 6775 (11/2012) and RFC 8505 (11/2018 update) RFC 6775 is the original registration mechanism, mostly for DAD and NCE proactive setting RFC 8505 updates for registration to proxy and routing services, enables RPL unaware leaves draft-ietf-6lo-backbone-router (RFC to be next year) Federates 6lo meshes over a high speed backbone ND proxy analogous to 802.11 ESS bridging but at Layer 3 draft-ietf-6lo-ap-nd (RFC to be next year) Protects addresses against theft (Crypto ID in registration
93 6LN (as a host) proactively registers to the 6LR (as the router) with NS(ARO) Registers the SourceAddress (not the target…) 6LR does Duplicate Address Detection using a central registrar (called 6LBR) New Duplicate Address Request / Confirmation (DAR/DAC) 6LR to 6LBR 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 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
94 Registers theTarget so it can be proxied (backbone router) New ROVR field forAddress Protection (ap-nd) Lifetime and RID to map to RPL path lifetime and sequence + R flag to request proxy or routing services (RPL unaware leaves) 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 | Status | Opaque | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd | I |R|T| TID | Registration Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... Registration Ownership Verifier (ROVR) ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
95 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
96 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
97 Directly upon NS(EARO) or indirectly upon EDAR message, the backbone router performs DAD on behalf of the wireless device. DAR NS (EARO) DADNS DAD (EARO)
98 NA(EARO) or EDAC 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 (EARO) Optional NA(O)
99 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)
100 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
101 DAD option has: Unique ID TID (SeqNum) Defend with NA if: Different ROVR Newer TID NS DAD (EARO) NA (EARO) NS (EARO)
102 DAD option has: Unique ID TID (SeqNum) Defend with NA if: Different ROVR Newer TID EDAR NA (ARO) DAD
103 RPL DAO Optional NA(EARO) Host Route DAD option has: Unique ID TID (SeqNum) Defend with NA if: Different ROVR Newer TID NA (EARO) with older TID (loses)
104 Packet NS lookup BBR proxies the NA in response to NS (Optionally polls the device if not sleeping) NA (EARO)
105 NS lookup Mixed mode ND BBR proxying over the backbone NA (EARO) Packet
106 6BBR (AP) 6LBR Router/Server6LN (STA) RA (PIO, unicast) Router/ServerIPv6 Router / IPv6 ServerEthernet BackboneWi-Fi RS (mcast) Classical NDRFC 8505RFC 8505 NS (EARO) EDAR EDAC RS (no SLLAO, for ODAD) NS DAD (EARO, multicast) NA (EARO, optimistic, not override, EARO) RA(unicast) (if no fresher BCE) NS(lookup, multicast) NA (EARO) Traffic using optimistic address DAD Time Out e.g., Wi-Fi FILS flow <DAD time out>
107
108  Association allows a proactive setting of the bridging state Allows the APs to eliminate broadcast lookups Compares to reactive learning bridge  WiND Reproduces the association model at L3 Leverages the state for address protection and SAVI Routing inside the subnet replaces bridging Proxy ND at the wire / wireless edge
109 6LR 6LBR6LN RA (unicast) RA (u|mcast) Radio 1 Hop SLLA 6CIO PIO MTU SLLA CONTEXT 6CIO PIO MTU SLLA CONTEXT ABRO 6CIO RS (mcast) RFC 8505 RFC 8505
110 6LR 6LBRLP Node NS (EARO) EDAR Radio 1 Hop SRC = 6LR * DST = 6LBR REG = LPN UID = LPN TID included SRC = LPN_LL * DST = 6LR_LL * TGT = LPN ** SLLA = LPN UID = LPN TID included opt: AP-ND * Global / ULA Create binding state * link local unique EUI-64 ** ULA or GUA 6LR 6LBR6LN RFC 8505RFC 8505
111 6LR 6LBRLP Node NA (EARO) EDAC Radio 1 Hop SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = 6LR_ll DST = LPN_ll TGT = LPN TLLA = LPN UID = LPN TID included 6LR 6LBR6LN RFC 8505RFC 8505
112 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 6LBR6LN
113
114 6LN/6LBR 6BBR Router/Serve r Ethernet Router/Serve r Router/Serve r Ethernet / Wi-Fi PIO MTU RA (u|mcast) RA (u|mcast) PIO MTU SLLA Classical ND RFC 8505
115 6LBR 6BBR Router/Serve r Ethernet NS DAD (ARO) NS (ARO) Router/Serve r Router/Serve r Ethernet / Wi-Fi SRC = UNSPEC DST = SNMA TGT = LPN UID = LPN TID included SRC = 6LBR DST = 6BBR * TGT = LPN SLLA = 6LBR UID = LPN TID included * Can be Anycast Create binding state Create proxy state 6LN/6LBR 6BBR Router/Serve r Router/Serve r Router/Serve r Classical NDRFC 8505
116 6LBR 6BBR Router/Serve r Ethernet NA (O) * NA (ARO) Router/Serve r Router/Serve r Ethernet / Wi-Fi 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 6LN/6LBR 6BBR Router/Serve r Router/Serve r Router/Serve r Classical NDRFC 8505
117
118 First come first Serve address registration First registration for an address owns that address till it releases it The network prevents hijacking Source address validation (SAVI) Address must be topologically correct Source of the packet owns the source address First Hop Security only? Proxy ownership and routing advertisements not protected yet
119 6LRLP Node NS (EARO, CIPO*, Nonce and NDPSO**) Radio 1 Hop 6LR6LN AP-ND NA (EARO(status=0)) NS (EARO(ROVR=Crypto-ID)) NA (EARO(status=Validation Requested), Nonce) * Crypto-ID Parameters Option ** NDP Signature Option 6LBR Radio Mesh EDAR 6LBR RFC 8505 Ethernet
120 • We made the size of the ROVR tunable so we can get high security. 64 bits seems inappropriate. • At the moment a joining 6LN is challenged from the 6LR The 6LBR MUST trust the 6LR A rogue 6LR may pretend that it represents a 6LN that passed the challenge Should we challenge all the way from the 6LBR? Can the Crypto-ID be used in routing protocols, how?
121 Multi-Link Subnet
122 IPv6 registration mechanism Authoritative Registrar / 6LBR gives full visibility on IP activity, address allocation and source address ownership Layer-3 routed (non broadcast) fringe aggregated in a single large IPv6 subnet Centralized control for deterministic routing and scheduling (PCE) Backbone router (ND proxy) enables Multi-Link subnet RPL distributed routing & scheduling for best effort Deterministic control loops including deterministic wired, wireless, and execution of control logic Industrial control logic running deterministically in carpeted floor (Fog) For Wi-Fi: best effort fringe using 2.4GHz band For Wi-Fi: converged wireless mesh Backhaul using 6TiSCH over .11 AC PHY in 5GHz band, shared with Factory Automation Fully scheduled wireless backbone Black: standard work Green: well advanced Orange: in progress Brick: Not started
123 Authoritative Registrar Authoritative Registrar / 6LBR Intermediate Registrar / 6LR Intermediate Registrar option. ND proxy Backbone router (ND proxy) - Scalable and Multi-Link - Reliable tracking - IP guard (admin knows what’s where) - Reliable (link) proxy operations, layer-2 or layer-3 - Support for legacy IPv6 devices - Support for IPv4 Multicast & broadcast suppression Reliable Registration Scalable registrar Well defined link-proxy operations …
124 • Scale an IOT subnet to the tens of thousands With device mobility (no renumbering) Controlled Latency and higher Reliability using a backbone • DeterministicAddress presence Route towards the latest location of an address Remove stale addresses • Deterministic Networking / Reliable and AvailableWireless • Low Power Edge devices
125 6LR 6LBR 6BBR Router/Serve r LP Node RPL Ethernet NA (~O) NS (EARO) Proxy NS (EARO) RPL DAO Router/Serve r Router/Serve r Ethernet / Wi-FiRadio 1 Hop Classical NDRFC 6550RFC 8505 RFC 8505 NA (EARO) DAO-ACK NA (EARO) 6LR RPL Root 6BBR Router/Serve r LP Node Router/Serve r Router/Serve r NS lookup Packet
126 DCO (status) 6LR 6LBR 6BBR Router/Serve r LP Node RPLv2 Ethernet NA (~O) NS (EARO) Proxy NS (EARO) RPL DAO Router/Serve r Router/Serve r Ethernet / Wi-FiRadio 1 Hop Classical NDRFC 6550RFC 8505 RFC 8505 NA (EARO, status) DAO-ACK NA (EARO) 6LR RPL Root 6BBR Router/Serve r LP Node Router/Serve r Router/Serve r NS DAD NA (EARO, status)
127 6LR 6LBR 6BBR Router/Serve r LP Node RPL Ethernet NA (~O) NS (ARO) NS (ARO) RPL DAO Router/Serve r Router/Serve r EthernetRadio 1 Hop SRC = 6BBR DST = NS SRC TGT = LPN TLLA = 6LBR SRC = 6LR DST = Parent * or Root TGT = LPN (ROVR opt.) 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 6LR 6LBR/Root 6BBR Router/Serve r LP Node Router/Serve r Router/Serve r
128
129 RPLv1 An extension of IPv6 ND for MLSN Optimized for MP2P, P2MP with Root Optional support of P2P P2P reactive extension (AODV) L3: agnostic to L2 though aware of radios RPLv2 brings SDN /TE Model with Projected Routes for P2P RPL Unaware Leaves Brown field updates Sync of configuration and capabilities exchange
130 • Minimum topological awareness (DV) • Proactive setup; lazy/reactive cleanup • Multi-Topology Routing (RPL Instances) Instantiation per constraints/metrics • Autonomic Subnet G/W Protocol • Optimized Diffusion over NBMA • Data Path validation • Non-Equal Cost Multipath Fwd
131 At a given point of time connectivity is as illustrated and rather fuzzy Radio link
132 Clusterhead1st 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
133 : : 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
134 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
135 Clusterhead B can reparent a same Rank so B’s subDAG is safe The rest ofA’s subDAG is isolated Either poison or 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
136 Clusterhead Once poisoned 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
137 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
138 • RFC 6206:TheTrickle 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 •
139
140 ZeroTrust: the RUL could be all sorts of devices in the future and can become an attack vector against the RPL infra.With RFC 8505 and the optional AP-ND work we isolate the RUL from RPL, and control at the interface what gets injected in RPL Lower code / data footprint in the RUL: RUL devices supports IPv6 (RFC 8200) but not RPL (RFC 6550).The RUL as a 6LN uses RFC 8505 as specified by RUL draft. RFC 8505 is a simple abstraction, the complexity for in the 6LR. So a similar RUL implementation could connect to other types of networks. Easier upgrade of the RPL network: no need to update the RUL leaves, which could become a lot more numerous that the routers Less messaging:The RUL draft avoids the duplication of ND messages (NS and then DAR) and RPL (DAO). It’s only ND at the host to router interface, and only RPL at the router to router interface.
141 6LBRRPL Root6LR 6LBRLP Node RPL NS (EARO) keepalive EDAR RPL DAO Radio 1 Hop RFC 6550RFC 8505 DAO-ACK NA (EARO) 6LRLP Node keepalive EDAC First EDAR First EDAC Proxy NS (EARO) Proxy NA (EARO) 6BBR Ethernet / Serial RFC 8505 Ethernet / Wi-Fi RFC 8505 … DAD
142 6LBRRPL Root6LR 6LBRLP Node RPL NS (EARO) keepalive EDAR RPL DAO Radio 1 Hop RFC 6550RFC 8505 DAO-ACK NA (EARO) 6LRLP Node keepalive EDAC Proxy NS (EARO) Proxy NA (EARO) 6BBR Ethernet / Serial RFC 8505 Ethernet / Wi-Fi RFC 8505
143
144 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Src: Internet Dest: 56 Stuff Src: Internet Dest: 56 Stuff Src: Root Dest: 56 RPI
145 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
146 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Src: 51 Dest: Root Stuff RPI Same packet format from RAL to: • Other RAL • Root • The Internet Due to RPI option type now 0x23 Src: 51 Dest: Internet Stuff RPI Src: 51 Dest: 52 Stuff RPI Src: Root Dest: 56 Stuff RPI
147 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 Via: 32 Via: 42 Src: Root Dest: 52 RPI Src: 51 Dest: 52 Stuff RPIRPI
148 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: 52 RPI
149 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Src: Root Dest: 56 RPI Dest: Src: 51 Stuff Src: 41 Dest: Root RPI Dest: Internet Src: 51 Stuff Dest: 56 Src: 51 Stuff Dest: Src: 51 Stuff
150 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Src: Dest: 56 Stuff Src: Internet Dest: 56 Stuff Src: Root Dest: 46 RPI Src: 51 Dest: 56 Stuff Src: Root Dest: 56 Stuff RUL addresses injected in non-storing mode so packet flies to the Root which encapsulated Src: Dest: 56 Stuff
151 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Src: Dest: 56 Stuff Src: Internet Dest: 56 Stuff Src: Root Dest: 46 RPI Src: 51 Dest: 56 Stuff Src: Root Dest: 56 Stuff RUL addresses injected in non-storing mode so packet flies to the Root which encapsulated Src: Dest: 56 Stuff Via: 13 Via: 24 Via: 35
152 RPL Route Projection
153 • 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?
154
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 Via: 46 Src: Root Dest: 56 RPI
156 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
157 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 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 (alt: non storing DAO) unicast, self 35 as parent, final destination 56 as target
159 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
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 Non source routed DATA Path Loose Source routed DATA Path Packet to 13, RH 24, 35, 56
162 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
163 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
164 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
165 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
166 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
167 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Non source routed DATA Path
168 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
169 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
170 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Storing mode DAO with lifetime along segment
171 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
172 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
173 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
174 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
175
176
177 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56
178 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56
179 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56
180 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
181 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 DAO ACK
182 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Packet for 41
183 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 IP in IP encapsulation with SRH 42, 41
184 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)
185 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Packet for 51
186 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 IP in IP encapsulation with SRH 42, 41
187 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Packet for 51
188
189 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)
190 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Storing mode DAO with lifetime along segment
191 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56 Storing mode DAO with lifetime along segment
192 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
193 11 12 13 25242322 3534333231 464544434241 DAG Root Application Server D 51 52 53 55 56
194
195 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
196 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. 196
197 Root Rank 1 Rank 110 P: Rank 250 Rank 260 B: Rank 540 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 ∞ 197
198
199 Non-Standard Extras
200
201 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: 201
202 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 Root. 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 202
203 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 203
204 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 204
205
206 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
207 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 207
208 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 208
209 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
210 - 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 210
211 R A D L B K J C E F G H I M M 211
212 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 212
213 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 213
214 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 214
215 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 215
216 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 216
217 In short
218 DV, stretch optimized for P2MP/MP2P Peer selection /Trickle and OFs Anisotropy, lazy maintenance, Non-Storing Mode, Decoupled Metrics, NECM DAGs, Datapath validation Local and Global Recovery Coupling with MIPv6 and NEMO Dynamic Topologies Density Constrained Objects Fuzzy Links Routing, local Mobility Global Mobility New Radios issues: Addressed in RPL by:
219 • 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
© 2012 Cisco and/or its affiliates. All rights reserved.IoT6 220Unclassified “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. 221UnclassifiedBRKEWN-3012 Questions
223 THX!

More Related Content

PPTX
Rpl2018
byPascal Thubert
 
PPTX
Luxbg fringe
byPascal Thubert
 
PPTX
6TiSCH @Telecom Bretagne 2015
byPascal Thubert
 
PPTX
6Tisch telecom_bretagne_2016
byPascal Thubert
 
PDF
TRUST BASED ROUTING METRIC FOR RPL ROUTING PROTOCOL IN THE INTERNET OF THINGS
bypijans
 
PDF
Mobility, traffic engineering and redundancy using RPL
byMaxime Denis
 
PPTX
6TiSCH + RPL @ Telecom Bretagne 2014
byPascal Thubert
 
PDF
Towards the Internet of Relevant Things: the IEEE 802.15.4e Standard
byGiuseppe Anastasi
 
Rpl2018
byPascal Thubert
 
Luxbg fringe
byPascal Thubert
 
6TiSCH @Telecom Bretagne 2015
byPascal Thubert
 
6Tisch telecom_bretagne_2016
byPascal Thubert
 
TRUST BASED ROUTING METRIC FOR RPL ROUTING PROTOCOL IN THE INTERNET OF THINGS
bypijans
 
Mobility, traffic engineering and redundancy using RPL
byMaxime Denis
 
6TiSCH + RPL @ Telecom Bretagne 2014
byPascal Thubert
 
Towards the Internet of Relevant Things: the IEEE 802.15.4e Standard
byGiuseppe Anastasi
 

What's hot

PPTX
5G Cellular D2D RDMA Clusters
byYitzhak Bar-Geva
 
PDF
IoT Gent meetup
bywaltercolitti
 
PPTX
NetSim - Implementing LEACH in WSN
byDESHPANDE M
 
PPTX
Rpl2016
byPascal Thubert
 
PDF
Research and Experimentation of LoRa in Heavy Multipath
byHaystack Technologies
 
PDF
IoT Field Area Network Solutions & Integration of IPv6 Standards by Patrick G...
bygogo6
 
PPTX
Iot rpl
byDESHPANDE M
 
PDF
How To Disrupt The Internet of Things With Unified Networking
byHaystack Technologies
 
PDF
Benefits of programmable topological routing policies in RINA-enabled large s...
byICT PRISTINE
 
PDF
LISP_in_Secure_Networks_WP
byCraig Hill
 
PDF
Cnam2015 m2 m -iot - course 2 - warming - v(0.2)
byThierry Lestable
 
PDF
LoRaWAN vs Haystack
byHaystack Technologies
 
PDF
The IoT Hunger Games 2015
byHaystack Technologies
 
PPTX
LPWAN Technology ~ What is Weightless-P?
byJay Wey 魏士傑
 
PDF
Introducing the new HayTag 2.0
byHaystack Technologies
 
PDF
Bringing Better Networking to LTE IoT
byHaystack Technologies
 
PDF
Lo ra
byOded Rotter
 
PPTX
Advancing LTE architecture with NFV and SDN
byAlberto Diez
 
PDF
Haystack Technology Overview
byHaystack Technologies
 
PDF
Protocol and Integration Challenges for SDN
byGerardo Pardo-Castellote
 
5G Cellular D2D RDMA Clusters
byYitzhak Bar-Geva
 
IoT Gent meetup
bywaltercolitti
 
NetSim - Implementing LEACH in WSN
byDESHPANDE M
 
Rpl2016
byPascal Thubert
 
Research and Experimentation of LoRa in Heavy Multipath
byHaystack Technologies
 
IoT Field Area Network Solutions & Integration of IPv6 Standards by Patrick G...
bygogo6
 
Iot rpl
byDESHPANDE M
 
How To Disrupt The Internet of Things With Unified Networking
byHaystack Technologies
 
Benefits of programmable topological routing policies in RINA-enabled large s...
byICT PRISTINE
 
LISP_in_Secure_Networks_WP
byCraig Hill
 
Cnam2015 m2 m -iot - course 2 - warming - v(0.2)
byThierry Lestable
 
LoRaWAN vs Haystack
byHaystack Technologies
 
The IoT Hunger Games 2015
byHaystack Technologies
 
LPWAN Technology ~ What is Weightless-P?
byJay Wey 魏士傑
 
Introducing the new HayTag 2.0
byHaystack Technologies
 
Bringing Better Networking to LTE IoT
byHaystack Technologies
 
Lo ra
byOded Rotter
 
Advancing LTE architecture with NFV and SDN
byAlberto Diez
 
Haystack Technology Overview
byHaystack Technologies
 
Protocol and Integration Challenges for SDN
byGerardo Pardo-Castellote
 

Similar to IPv6 ND 2020

PPTX
UNIT III- 1.RPL.pptx
bySangeetha Prakash
 
PPTX
6LowPAN etc.pptx computer network and IOT devices in future technology
byHRJEETSINGH
 
PDF
internet-of-things-2.....................pdf
byrajeswaria21
 
PPTX
communication_technologies_Internet of things topic
byDurgaDeviP2
 
PDF
ConnectingSmartObjects..........................pdf
byTinotendaChagaka
 
PPTX
Lecture 8 - Connectivity Technologies – Part II- IOT.pptx
bytaheenaamir
 
PPT
Module 3 INTERNET OF THINGS
byDr. Mallikarjunaswamy N J
 
PPT
L6 6 lowpan
bybimal2638
 
PPTX
WPAN technologies and its wipe spread usage
byhodcse768718
 
PDF
Scaling the Web to Billions of Nodes: Towards the IPv6 “Internet of Things” b...
bygogo6
 
PPTX
Final_IoT_Protocol Stack.pptx
byjainam bhavsar
 
PPTX
6 lowpan
bySiva Kumar
 
PPTX
IOT_PPT.pptx
byanilkumar5114
 
PDF
IoT PROTOCOLS IoT Access Technologies Physical and MAC layers, topology and S...
bygirishgandhi4
 
PDF
IOT_MODULE_3.pdf simple example notes for use
byshreyarrce
 
PPTX
6lowpan 110828234426-phpapp01
bymrmr2010i
 
PDF
IPv6 and IoT
byAPNIC
 
PPTX
Elements of IoT connectivity technologies
byusman sarwar
 
PPT
Eemerging Wireless Internet Standar-2011.ppt
byNurCHolis624165
 
PDF
About IoT Protocols and Security Techniques
byBalasundaramSr
 
UNIT III- 1.RPL.pptx
bySangeetha Prakash
 
6LowPAN etc.pptx computer network and IOT devices in future technology
byHRJEETSINGH
 
internet-of-things-2.....................pdf
byrajeswaria21
 
communication_technologies_Internet of things topic
byDurgaDeviP2
 
ConnectingSmartObjects..........................pdf
byTinotendaChagaka
 
Lecture 8 - Connectivity Technologies – Part II- IOT.pptx
bytaheenaamir
 
Module 3 INTERNET OF THINGS
byDr. Mallikarjunaswamy N J
 
L6 6 lowpan
bybimal2638
 
WPAN technologies and its wipe spread usage
byhodcse768718
 
Scaling the Web to Billions of Nodes: Towards the IPv6 “Internet of Things” b...
bygogo6
 
Final_IoT_Protocol Stack.pptx
byjainam bhavsar
 
6 lowpan
bySiva Kumar
 
IOT_PPT.pptx
byanilkumar5114
 
IoT PROTOCOLS IoT Access Technologies Physical and MAC layers, topology and S...
bygirishgandhi4
 
IOT_MODULE_3.pdf simple example notes for use
byshreyarrce
 
6lowpan 110828234426-phpapp01
bymrmr2010i
 
IPv6 and IoT
byAPNIC
 
Elements of IoT connectivity technologies
byusman sarwar
 
Eemerging Wireless Internet Standar-2011.ppt
byNurCHolis624165
 
About IoT Protocols and Security Techniques
byBalasundaramSr
 

Recently uploaded

PDF
Build Next-Gen Spatial & Sensor Workflows: Secure, Scalable Processing in Sno...
bySafe Software
 
PDF
The Enterprise Web3 Landscape - a view from Kaleido based on the past 10 year...
byPeter Broadhurst
 
PDF
Dev Dives: Build and deploy agentic automations - the unified way
byUiPathCommunity
 
PDF
January 2026 OpenMetadata Community Spotlight - OpenMetadata @ Wix.pdf
byOpenMetadata
 
PPTX
Retrieval Augmented Generation- The Synergistic Power of Prompt Engineering
bySemantic SEO BD
 
PDF
Designing a Blog Using Wordpress
bymarkzubi50
 
PDF
"Painless Major Upgrade: A Strategy for Updating Large Codebases", Andrii Yat...
byFwdays
 
PPTX
Introduction to Industrial-Arts Grade 8 ppt Lesson 1
byFSBTLEDNathanVince
 
PDF
Analyze and Preserve Logs - RHCSA (RH134).pdf
byLinuxCert Guru
 
PDF
ICT500 - CRITICAL AND CREATIVE THINKING FOR INFORMATION TECHNOLOGY SOLUTIONS:...
by2024432452
 
PDF
Getting Started with Apache Spark: Big Data Made Simple [Free Meetup]
byHaim Michael
 
PDF
Startup Formation Collapses While Acquisition Activity Hits New High!
byMemoori
 
PDF
Mesh WiFi Router: The Smart Solution for Fast, Seamless, Whole-Home Internet
byAeroMesh Systems
 
PDF
What Is the Azure AI Foundry and Why Does It Matter for Enterprises?
byjohncarterjn
 
PDF
Why Many Smart Device Platforms Fail to Scale?
byPromeraki Developments
 
PDF
Title Installing Windows, Linux, MacOS.pdf
byGeraldAbadajos
 
PDF
UiPath Automation Developer Associate Training Series 2026 - Session 1
byDianaGray10
 
PPTX
TechSprint Inauguration at SJB Institute of Technology held on 18 December 2025
bysuhasspgdg
 
PPTX
The Lex Wire Precedent: A Technical Standard for Machine-Mediated Authority ...
byJeff Howell
 
PDF
Writing GPU-Ready AI Models in Pure Java with Babylon
byAna-Maria Mihalceanu
 
Build Next-Gen Spatial & Sensor Workflows: Secure, Scalable Processing in Sno...
bySafe Software
 
The Enterprise Web3 Landscape - a view from Kaleido based on the past 10 year...
byPeter Broadhurst
 
Dev Dives: Build and deploy agentic automations - the unified way
byUiPathCommunity
 
January 2026 OpenMetadata Community Spotlight - OpenMetadata @ Wix.pdf
byOpenMetadata
 
Retrieval Augmented Generation- The Synergistic Power of Prompt Engineering
bySemantic SEO BD
 
Designing a Blog Using Wordpress
bymarkzubi50
 
"Painless Major Upgrade: A Strategy for Updating Large Codebases", Andrii Yat...
byFwdays
 
Introduction to Industrial-Arts Grade 8 ppt Lesson 1
byFSBTLEDNathanVince
 
Analyze and Preserve Logs - RHCSA (RH134).pdf
byLinuxCert Guru
 
ICT500 - CRITICAL AND CREATIVE THINKING FOR INFORMATION TECHNOLOGY SOLUTIONS:...
by2024432452
 
Getting Started with Apache Spark: Big Data Made Simple [Free Meetup]
byHaim Michael
 
Startup Formation Collapses While Acquisition Activity Hits New High!
byMemoori
 
Mesh WiFi Router: The Smart Solution for Fast, Seamless, Whole-Home Internet
byAeroMesh Systems
 
What Is the Azure AI Foundry and Why Does It Matter for Enterprises?
byjohncarterjn
 
Why Many Smart Device Platforms Fail to Scale?
byPromeraki Developments
 
Title Installing Windows, Linux, MacOS.pdf
byGeraldAbadajos
 
UiPath Automation Developer Associate Training Series 2026 - Session 1
byDianaGray10
 
TechSprint Inauguration at SJB Institute of Technology held on 18 December 2025
bysuhasspgdg
 
The Lex Wire Precedent: A Technical Standard for Machine-Mediated Authority ...
byJeff Howell
 
Writing GPU-Ready AI Models in Pure Java with Babylon
byAna-Maria Mihalceanu
 

IPv6 ND 2020

  • 1.
    1 IPv6 ND 2020 PascalThubert, Rennes January 15th, 2020
  • 2.
    2 • The any-to-anyparadigm Art: Any par of global addresses can reach one another IoT: Many devices of all sorts, need isolation GAFA: 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 (1980) NCP generationwith: All Transmission Groups to L2 peers All Physical Units type 4 nodes, All Virtual Routes (1990) Router CLI with: ID, keys. All links to L2 peers Routes are discovered => Single ‘GRID’ (2000) Router only knows “self” with: ID, certificates Peers are discovered Links are discovered Routes are discovered =>Infinity of self-centric networks
  • 4.
    4 Open Standards vs.proprietary COTS* suppliers drive costs down but Reliability, Availability and Security up IP abstraction vs. per MAC/App 802.11, 802.15.4, Sat, 3G, UWB Keep L2 topology simple To Infinity and Beyond… But End-to-End. No intermediate gateway, tunnel, middle boxes & other trick * Commercial, off-the-shelf
  • 5.
    5 The current Internetcomprises several billion devices Smart Objects will add tens of billions of additional devices IPv6 is the only viable way going forward 1~2 Billions PCs & servers Tens of Billions Smart ObjectsThings Mobile Fixed 2~4 Billions Phones & cars The RIPE NCC has run out of IPv4 Addresses “Today, at 15:35 (UTC+1) on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses.”
  • 6.
    6 Little work onadapting 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 meetsWireless: Mobile Routers (LISP, NEMO) (Proxy) MIPv6 6LoWPAN 6TiSCH ROLL/RPL CoAP ISA100.11a ZigBee/IP
  • 7.
    7 • Non-Broadcast Multi-Accessnetwork / MultiLinkL subnet IPv6 only supports P2P and transit (ethernet) but by nature, a radio network is NBMA WiND / RPL solves the problem in the IOT space • L3 «VLAN » So far only available with MPLS. New attempts (MTR, RPL instances, SR Flex Algo) • L4/5 hints Flow Label given away to fwd plane; DetNet Flow indication? • Microflows / compound flows InWSN, a flow has multiple sources • Local and Global IP Mobility Unification (eg MANEMO, LISP+RPL)
  • 8.
    8 We are infor a change: Basic Internet structures and expectations reconsidered Revisiting classical end-to-end and any-to-any Revisiting best effort to new levels of guarantees (deterministic) New function placement, new operations Merge IOT data at the Information layer, Gossip IOT information at the knowledge layer Impacts network, transport, security models
  • 9.
    9 Agenda (part 1,Introduction) IOT Standards IEEE and LLNs IETF and 6LoWPAN IETF 6TiSCH Routing Concepts Forms of Routing Loopless structures Routing Over Radios
  • 10.
    10 Agenda (part 2,IPv6 ND for P2P and transit links) The IPv6 Neighbor Discovery Protocol RFC 4861: Discovery and Resolution RFC 4862: SLAAC Applying Classical ND toWireless Link Model Can and cannot do
  • 11.
    11 Agenda (part 3,Wireless ND) Wireless Neighbor Discovery (WiND) Registration (RFC 8505) Backbone Router Address Protection and SAVI MultiLink Subnet Classical RPL RPL-Unware Leaves Using RPL Packet Information
  • 12.
    12 Agenda (part 4,RPL Route Projection and extras) RPL Route Projection Shortening Long SRH Transversal Routes In Non-Storing Mode In Storing Mode Fast Reroute in RPL (non standard) Using the Data Plane Using the Control Plane
  • 13.
  • 14.
  • 15.
    15 Cheap Install Deploying wireis 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)
  • 16.
    16 LLNs comprise alarge 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, AssetTracking, 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
  • 17.
    17 LLNs operate witha 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
  • 18.
    18 IEEE Wireless Standards 802.11Wireless 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
  • 19.
    Cisco Confidential© 2012Cisco and/or its affiliates. All rights reserved. 19 Initial activities focused on wearable devices “PersonalArea 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 toTHz Various applications not necessarily IP based Focus is on “specialty”, typically short range, communications If it is wireless and not a LAN, MAN, RAN, orWAN, it is likely to be 802.15 (PAN) The only IEEE 802Working Group with multiple MACs http://www.ieee802.org/15/pub/TG4.html IEEE 802.15 WPAN™ Task Group 4 (TG4) Charter
  • 20.
    20 Star Topology ClusterTreeMesh 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
  • 21.
    21 • Specifies PHYand MAC only • Medium Access Control Sub-Layer (MAC) Responsible for reliable communication between 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)
  • 22.
  • 23.
  • 24.
    24 LAKE Reuse work donehere 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
  • 25.
    25 • Gateways vs.end-to-end principle • Hindrance from proprietary technologies • Vertical solutions, hard to generalize to large scale driving costs down
  • 26.
    26 http://dunkels.com/adam/ewsn2004.pdf http://www.eecs.harvard.edu/~mdw/course/cs263/papers/ipv6-sensys08.pdf • No IPat all is sensors, deemed impossible, too expensive • ProprietaryWSN 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 tothe end node however small • IETFWG 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 suchas 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 forWSN 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 alltechnologies, 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-ietf-6tisch-architecture Bluetooth Low Energy DECT Ultra Low Energy Zwave PLC Near Field Comms BACNET 802.11ah 802.15.4eTSCH
  • 30.
    30 TimeFrame 802.15.4 OtherIoT 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) ~ now 6LoWPAN + RPL stack ( that’s 6TiSCH ! ) 6LoWPAN HC + ND < 2022 6LoWPAN + RPL stack (that will be 6IoT, generalizing 6TiSCH stack on all LLN links) Next Reliable and Available Wireless, Call Admission control and Traffic Engineering Notes: • With Wireless ND we claim that Low Power Wi-Fi is an LLN link => extend to Wi-Fi and 802.11 OCB
  • 31.
    31 Preamble SPD PHY Header Auxiliary Security Header Payload FCS Frame Control Data Seq. Nbr Addressing SimpleMAC 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 0 11 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
  • 33.
    33 6LoWPAN is anopen 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 inThread, ZigbeeIP, … Now generalizing on all LLN technologies with IETF 6lo GW
  • 34.
  • 35.
    35 Deterministic IPv6 overIEEE802.15.4TimeSlotted Channel Hopping (6TiSCH) TheWorking Group will focus on enabling IPv6 over theTSCH mode of the IEEE802.15.4 standard.The scope of theWG 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.4TSCH 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. 6TiSCH builds a MultiLink Subnet (MLSN) CombiningWiND for 6LN<->6LR and RPL for 6LR<->6LR Also Reliable andAvailableWireless (RAW) Scheduling => Mostly NOT specific to 802.15.4TSCH WG charter
  • 36.
    36 6TiSCH has tomake components work together and push new work https://tools.ietf.org/html/rfc8505 https://tools.ietf.org/html/draft-ietf-6lo-backbone-router https://tools.ietf.org/html/draft-ietf-6lo-ap-nd https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery https://tools.ietf.org/html/draft-thubert-roll-unaware-leaves 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-architecture https://tools.ietf.org/html/draft-ietf-6tisch-msf https://tools.ietf.org/html/rfc8480 (6P Protocol) https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-zerotouch-join WG deliveries
  • 37.
    37 Centralized route and trackcomputation 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 Scheduling functions IEEE 802.15.4 TSCH 6LoWPAN HC / 6LoRH HC IPv6 RPL 6top TCP UDP ICMP PCEP/PCC CoAP/OSCORE 6LoWPAN ND } Applications CoJP SF
  • 38.
  • 39.
  • 40.
    40 Next problem: Reliableand Available Wireless • Due to uncontrolled interferences, including the self-induced multipath fading, deterministic networking can only be approached on wireless links. • The radio conditions may change -way- faster than a centralized PCE can adapt and reprogram, in particular when the controller is distant and connectivity is slow and limited. • RAW separates the path computation time scale at which a complex path is recomputed from the path selection time scale at which the forwarding decision is taken for one or a few packets. • RAW operates at the path selection time scale. The RAW problem is to decide, within the redundant solutions that are proposed by the PCE, which will be used for each packet to provide a Reliable andAvailable service while minimizing the waste of resources. Controller Wireless network FAST SLOW LARGE SMALL SLOW Reliability & Availability vs. Energy & Bandwidth
  • 41.
  • 42.
  • 43.
    43 • Hidden terminal •Interference domains grows faster that range • Density => low power => multihop => routing
  • 44.
    44 Centralized:A controller setsup 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 SinceARPANET, 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, manualTE Need additions for reroute / fast reroute
  • 45.
    45 RFC 4861 isReactive, RFC 8505 is Proactive) Aka Stateful vs. On-demand routing Note: on-demand breaks control vs. Data plane separation P2P-RPL RIP IS-IS AODV-RPL
  • 46.
    46 LS requires fullstate 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
  • 47.
    47 Stateful: routing decisionat 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)
  • 48.
    48 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
  • 49.
    49 • Conventional IGPsare Isotropic Meaning that they advertise the same information in all directions This enables shortest path but leads to intense flooding at scale • Some Network have a sense of “North” or “Up” Towards IOT Sinks (e.g., RPL Root) Towards DC Superspine (e.g., RIFTToF) Anisotropic Routing exploits that inherent structure for optimization Different forms of advertisements Aggregated routes Northwards, with disaggregated exceptions
  • 50.
    50 • Conventional routingprotocols 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 useTunnels / Source Routing around (see Segment Routing) PLAN B can be computed centrally
  • 51.
  • 52.
    52 Most classical routingstructure 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
  • 53.
    53 In the contextof 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 DestinationOriented 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
  • 54.
    54 • 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
  • 55.
    55 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 ofsiblings 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) Preferred parent tree Potential link
  • 56.
    56 Clusterhead / Root 5 0 1 1 1 2 2 2 2 2 3 3 3 3 3 3 2 3 5 4 4 4 4 Expose siblingInformation to Root Root <-> PCE over southboundAPI Computes a redundantTrack As aggregated Segments => Redundancy (PAREO) SDN /Traffic Engineering Install additional routes “Projected” in the Network RAW Forwarding Decision Delivery SLA (PDR, latency) Optimiez bandwidth and Energy Preferred parent tree Potential link projected Track SDN Controller / PCE Southbound API
  • 57.
  • 58.
    58 1000*scale => Noleak in Internet => Opaque operations Reachability => Radio (IEEE) Addressing => IPv6 (IETF) Density => spatial reuse => Routing
  • 59.
    59 No preexisting physicaltopology 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
  • 60.
    60 Potentially Large PeerSet Highly Variable Capabilities Selection Per Objective Metrics (e.g. RSSI, ETX…) L3 Reachability (::/0, …) Constraints (Power …)
  • 61.
    61 Smart object areusually Small & Numerous « sensor Dust » Battery is critical Deep Sleep Limited memory Small CPU Savings are REQUIRED Control plane Data plane (Compression)
  • 62.
    62 Neither transit norP2P 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
  • 63.
    63 Stretch vs. Control Optimizetable 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
  • 64.
  • 65.
  • 66.
    66 • Replacement /Modernization of IPv4 Address Resolution Protocol • And ICMP Router Discovery and Redirect • Based on ICMPv6 • Reactive Protocol, heavy usage of multicast / broadcast • Initially defined in 1998 (obsoleting 1996 version) for Ethernet wire • Operate on one hop • Advertises Routers and Parameters • Resolves Layer-2 addresses and maintains a cache (NCE)
  • 67.
    67 Unidirectional Links: NotSupported (need reflexive) Broadcast link (e.g., Ethernet): Supported (needTransitive) Multicast capable: benefits from multicast optimization. Point-to-Point (P2P): Supported Shared Media (Non-overlapping prefixes): Supported Non-Broadcast Multi Access (NBMA): Not Supported => No concept of Multi-Link Subnet (MLSN) in classical IPv6
  • 68.
    68 • ND resolvesmapping of IPv6 and LLA for on-link addresses • Advertising self with Source LLA Option (SLLAO) provides the LLA associated to the IP source of the ND message • Advertising third party address withTarget LLA Option (TLLAO) Mapping the IPv6 address in theTarget field • Source Address can be all-zero (:: aka UNSPECIFIED_ADDRESS) Response is therefore multicast to all hosts • Multiple tricks Responding with RA unicast vs. multicast using unicast MAC for mcast packet
  • 69.
    69 Layer-3 unicast andmulticast (allows IP auth) Router Discovery included (RA messages) Provides the router Link-Local Address Allow router association independent of prefix (Multiple) Prefix Information in RA msg MTU in RA msg StatelessAddress Autoconfiguration + DHCPv6 Target link-layer address in Redirect (on-link) Neighbor Unreachability Detection (NUD) Hop Limit of 255 contains IPv6 ND on link Reactive Lookup and DAD only (in practice) • Layer-2 broadcast • ICMP Router Discovery and Redirect • No LLA (initially) • Router known only by Global address • One Address, one Prefix per link • Hosts may have different MTUs • Only DHCP • Separate resolution • No equivalent method, half link undetected, no FSM • Off link nodes can spoof ICMP redirect messages • Inverse ARP and reverse ARP for NBMA
  • 70.
    70 • Router Solicitation: Whenan interface becomes enabled, hosts may send out Router Solicitations that request routers to generate Router Advertisements immediately rather than at their next scheduled time. • Router Advertisement: Routers advertise their presence together with various link and Internet parameters either periodically, or in response to a Router Solicitation message. Router Advertisements contain prefixes that are used for determining whether another address shares the same link (on-link determination) and/or address configuration, a suggested hop limit value, etc. Many options have been added since RFC 4861, e.g., RIO • Both can be unicast or multicast, and can announce Link Layer Address (LLA) aka MAC address
  • 71.
    71 • Neighbor Solicitation: DuplicateAddressDetection (DAD, S=::, D=Mcast SNMA) Determine the link-layer address of a neighbor (Address Lookup akaAddress Resolution (S=Ucast, D= Mcast SNMA) Verify that a neighbor is still reachable via a cached link-layer address with Neighbor Unreachability Detection (NUD, S=Ucast, D= Ucast). • Neighbor Advertisement: A response to a Neighbor Solicitation message (multicast if source is :: ) Also Unsolicited (akaGratuitous) NeighborAdvertisements to announce a LLA change. • Redirect: Used by routers to inform hosts of a better first hop for a destination
  • 72.
    72 0 1 23 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... (SLLAO) +-+-+-+-+-+-+-+-+-+-+-+-
  • 73.
    73 0 1 23 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O| Reserved | Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... (SLLAO, PIO, MTU, RIO,…, 6CIO, ABRO, 6LoWPAN Context) +-+-+-+-+-+-+-+-+-+-+-+-
  • 74.
    74 0 1 23 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Target Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... (SLLAO, note: TLLAO in RFC 8505) +-+-+-+-+-+-+-+-+-+-+-+-
  • 75.
    75 0 1 23 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S|O| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Target Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... (TLLOA) +-+-+-+-+-+-+-+-+-+-+-+-
  • 76.
    76 0 1 23 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Target Address + | | + (better first hop) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... (TLLOA, redirected header) +-+-+-+-+-+-+-+-+-+-+-+-
  • 77.
  • 78.
    78 Form one ormany IPv6 LL / UL / GU Address, anytime Controlled by A bit in PIO (vs. DHCP by M and O bits in RA) Host in control of the address, network cannot refuse Neighbor Caches in peers, not hard state NS(DAD) procedure: typically wait one second Alt: RFC 4429 Optimistic DAD Doable with limitation NS / NA done reactively, the router keeps one packet pending!!! Causes loss of response and bad assessment of connectivity draft-linkova-6man-grand/ proposes to push a NA to the routers
  • 79.
    79 • RFC 2464(IPv6 / Eth) and 4291: Address Architecture Defines IPv6 Adresses (LinkLocal vs. ULA vs. GUA, Unicast,Anycast, unspecified, loopback…) Interface ID (IID) based on EUI-64 (derived from MAC address) => deprecated by RFC 8064 • RFC 5292 provides Modern AddressText Representation e.g., 2001:db8:aaaa:bbbb:cccc:dddd::1 • RFC 4941 SLAAC Privacy Extensions (still a need for stable IIDs) • RFC 7136 Significance of IPv6 IID (meaning none) • RFC 7217 Stable and Opaque IIDs (enable private static IIDs) • RFC 7721 Privacy Considerations / RFC 8065 for 6lo / IOT • RFC 8064 Recommendation on Stable IPv6 Interface Identifier updates RFC 2464, RFC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, and RFC 5121 !!!!!!!
  • 80.
  • 81.
    81 • IPv6 NDis designed for P2P andTransit Links Wireless is usually reflexive but natively non-transitive Requires extensions for NBMA (without MAC-layer emulated transitive properties) • IPv6 ND over MAC-layer transit emulation is not wireless friendly E.g., over L2R, learning bridges, Wi-Fi Infrastructure Mode Broadcast intensive (no support for multicast) • Other mismatches Fast Roaming ‘11r’ (ND has no sense of order of events) Intermittent Connectivity (fails all of NUD, DAD and lookup) Fast Initial Link Setup ‘11ai’ (ND is reactive, causes loss of first packets) Increased sensitivity to DoS attacks (Use ND to trigger broadcasts remotely) A B C Non transitive: B can talk to A and C but A and C cannot see reach other
  • 82.
  • 83.
    83 • A plainradio Interface connects to a physical radio broadcast domain (vs. a MAC-layer emulated broadcast domain) • An IPv6 bidirectional Link can be created where radio broadcast domain overlap enough that A sees B and B sees A. • Link-Local Addresses need to be unique for a communicating pairs only • The IPv6 Link is usually reflexive though often asymmetrical • The IPv6 Link is usually not transitive unless special measures taken • As a node moves, it meets other nodes and IPv6 Links are formed Spoke_C B::C/64 Spoke_A B::A/64 Hub_B B::B/64
  • 84.
    84 B b::b/64 C c::c/64 • Matching sourceIP to router A must with radio mobility E.g., car A attached to RSUs B & C Each RSU enforcing SAVI for its prefix Providing reachability back to a CoA based on its prefix • Aggressive DNA (Detecting Network attachment) Rapid discovery (advertisement interval option in RA) Permanently assess reachability of DRL and prune rapidly May reuse a GUA if come back within reg. lifetime A belongs to 2 subnets at a time A b::a/64 c::a/64
  • 85.
    85 SubNet models Spoke_C B::C/64 Spoke_A B::A/64 Hub_B B::B/64 Hub andSpoke HUB_B maintains state for visitors for their registration lifetime and relays packet Node_A MESH::A/64 Node_B MESH::B/64 Node_C MESH::C/64 Node_D MESH::D/64 Node_E MESH::E/64 Route-Over Mesh, requires a routing protocol A B P2P, the simplest subnet model
  • 86.
  • 87.
    87 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) The backbone router limits the broadcast domain to the backbone VM, NFV,Wireless or IoT device moves: Server
  • 88.
    88 Nbr Solicitation L3 Multicast L2broadcast 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 IPv6 is proxied at the backbone router on behalf of device Packet comes in for 2001:db8::A1
  • 89.
    89 No Multicast group,all is broadcasted, all devices must receive and filter Energy wasted when self is not recipient of the multicast A device sends a unicast to the AP and the AP reflects as broadcast Unicast are acknowledged, but broadcast are not A broadcast fromAP must reach all associated nodes: it is sent at the lowest speed and highest energy level Can be 100 times slower that unicast: detrimental to unicast Maw power => Maximum interferences with other wireless transmissions Battery operated devices (e.g. your phone) often ignore 80-90% of broadcasts Saves battery but defeats the protocols, e.g., Duplicate Address Detection
  • 90.
  • 91.
    91 • Solicited nodemulticast requires highly scalable L2 multicast IEEE does not provide it => turns everything into broadcast IPv6 ND appears to work with broadcast on 802.1 fabrics up to some scale ~10K nodes • IPv6 ND requires reliable and cheap broadcast Radios do not provide that => conserving 802.1 properties over wireless is illusory RFC 4862 cannot operate as designed on wireless Address uniqueness is an unguaranteed side effect of entropy • 802.11 expects proxy operation and broadcast domain separation 802.11 provides a registration and proxy bridging at L2 Requires the same at L3, which does (well… did) not exist Implementations provide proprietary techniques based on snooping => widely imperfect  RFC 6775 solves the problem for DAD in one LL  RFC 8505 enables establishing proxy services directly
  • 92.
    92 A proactive settingof proxy/routing state to avoid multicast due to reactive Duplicate address detection and lookup in IPv6 ND RFC 6775 (11/2012) and RFC 8505 (11/2018 update) RFC 6775 is the original registration mechanism, mostly for DAD and NCE proactive setting RFC 8505 updates for registration to proxy and routing services, enables RPL unaware leaves draft-ietf-6lo-backbone-router (RFC to be next year) Federates 6lo meshes over a high speed backbone ND proxy analogous to 802.11 ESS bridging but at Layer 3 draft-ietf-6lo-ap-nd (RFC to be next year) Protects addresses against theft (Crypto ID in registration
  • 93.
    93 6LN (as ahost) proactively registers to the 6LR (as the router) with NS(ARO) Registers the SourceAddress (not the target…) 6LR does Duplicate Address Detection using a central registrar (called 6LBR) New Duplicate Address Request / Confirmation (DAR/DAC) 6LR to 6LBR 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 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • 94.
    94 Registers theTarget soit can be proxied (backbone router) New ROVR field forAddress Protection (ap-nd) Lifetime and RID to map to RPL path lifetime and sequence + R flag to request proxy or routing services (RPL unaware leaves) 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 | Status | Opaque | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd | I |R|T| TID | Registration Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... Registration Ownership Verifier (ROVR) ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • 95.
    95 Routers within subnethave 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
  • 96.
    96 Gateway to theoutside participate to some IGP with external network and attracts all extra- subnet traffic via protocols over the backbone Default Route In RIB
  • 97.
    97 Directly upon NS(EARO)or indirectly upon EDAR message, the backbone router performs DAD on behalf of the wireless device. DAR NS (EARO) DADNS DAD (EARO)
  • 98.
    98 NA(EARO) or EDACmessage 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 (EARO) Optional NA(O)
  • 99.
    99 The BR maintainsa 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)
  • 100.
    100 The BR maintainsa 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
  • 101.
    101 DAD option has: UniqueID TID (SeqNum) Defend with NA if: Different ROVR Newer TID NS DAD (EARO) NA (EARO) NS (EARO)
  • 102.
    102 DAD option has: UniqueID TID (SeqNum) Defend with NA if: Different ROVR Newer TID EDAR NA (ARO) DAD
  • 103.
    103 RPL DAO Optional NA(EARO) Host Route DAD option has: UniqueID TID (SeqNum) Defend with NA if: Different ROVR Newer TID NA (EARO) with older TID (loses)
  • 104.
    104 Packet NS lookup BBR proxies theNA in response to NS (Optionally polls the device if not sleeping) NA (EARO)
  • 105.
    105 NS lookup Mixed mode ND BBRproxying over the backbone NA (EARO) Packet
  • 106.
    106 6BBR (AP) 6LBRRouter/Server6LN (STA) RA (PIO, unicast) Router/ServerIPv6 Router / IPv6 ServerEthernet BackboneWi-Fi RS (mcast) Classical NDRFC 8505RFC 8505 NS (EARO) EDAR EDAC RS (no SLLAO, for ODAD) NS DAD (EARO, multicast) NA (EARO, optimistic, not override, EARO) RA(unicast) (if no fresher BCE) NS(lookup, multicast) NA (EARO) Traffic using optimistic address DAD Time Out e.g., Wi-Fi FILS flow <DAD time out>
  • 107.
  • 108.
    108  Association allowsa proactive setting of the bridging state Allows the APs to eliminate broadcast lookups Compares to reactive learning bridge  WiND Reproduces the association model at L3 Leverages the state for address protection and SAVI Routing inside the subnet replaces bridging Proxy ND at the wire / wireless edge
  • 109.
    109 6LR 6LBR6LN RA (unicast) RA(u|mcast) Radio 1 Hop SLLA 6CIO PIO MTU SLLA CONTEXT 6CIO PIO MTU SLLA CONTEXT ABRO 6CIO RS (mcast) RFC 8505 RFC 8505
  • 110.
    110 6LR 6LBRLP Node NS(EARO) EDAR Radio 1 Hop SRC = 6LR * DST = 6LBR REG = LPN UID = LPN TID included SRC = LPN_LL * DST = 6LR_LL * TGT = LPN ** SLLA = LPN UID = LPN TID included opt: AP-ND * Global / ULA Create binding state * link local unique EUI-64 ** ULA or GUA 6LR 6LBR6LN RFC 8505RFC 8505
  • 111.
    111 6LR 6LBRLP Node NA(EARO) EDAC Radio 1 Hop SRC = 6LR DST = 6LBR REG = LPN UID = LPN TID included SRC = 6LR_ll DST = LPN_ll TGT = LPN TLLA = LPN UID = LPN TID included 6LR 6LBR6LN RFC 8505RFC 8505
  • 112.
    112 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 6LBR6LN
  • 113.
  • 114.
    114 6LN/6LBR 6BBR Router/Serve r Ethernet Router/Serve r Router/Serve r Ethernet /Wi-Fi PIO MTU RA (u|mcast) RA (u|mcast) PIO MTU SLLA Classical ND RFC 8505
  • 115.
    115 6LBR 6BBR Router/Serve r Ethernet NS DAD(ARO) NS (ARO) Router/Serve r Router/Serve r Ethernet / Wi-Fi SRC = UNSPEC DST = SNMA TGT = LPN UID = LPN TID included SRC = 6LBR DST = 6BBR * TGT = LPN SLLA = 6LBR UID = LPN TID included * Can be Anycast Create binding state Create proxy state 6LN/6LBR 6BBR Router/Serve r Router/Serve r Router/Serve r Classical NDRFC 8505
  • 116.
    116 6LBR 6BBR Router/Serve r Ethernet NA (O)* NA (ARO) Router/Serve r Router/Serve r Ethernet / Wi-Fi 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 6LN/6LBR 6BBR Router/Serve r Router/Serve r Router/Serve r Classical NDRFC 8505
  • 117.
  • 118.
    118 First come firstServe address registration First registration for an address owns that address till it releases it The network prevents hijacking Source address validation (SAVI) Address must be topologically correct Source of the packet owns the source address First Hop Security only? Proxy ownership and routing advertisements not protected yet
  • 119.
    119 6LRLP Node NS (EARO,CIPO*, Nonce and NDPSO**) Radio 1 Hop 6LR6LN AP-ND NA (EARO(status=0)) NS (EARO(ROVR=Crypto-ID)) NA (EARO(status=Validation Requested), Nonce) * Crypto-ID Parameters Option ** NDP Signature Option 6LBR Radio Mesh EDAR 6LBR RFC 8505 Ethernet
  • 120.
    120 • We madethe size of the ROVR tunable so we can get high security. 64 bits seems inappropriate. • At the moment a joining 6LN is challenged from the 6LR The 6LBR MUST trust the 6LR A rogue 6LR may pretend that it represents a 6LN that passed the challenge Should we challenge all the way from the 6LBR? Can the Crypto-ID be used in routing protocols, how?
  • 121.
  • 122.
    122 IPv6 registration mechanism AuthoritativeRegistrar / 6LBR gives full visibility on IP activity, address allocation and source address ownership Layer-3 routed (non broadcast) fringe aggregated in a single large IPv6 subnet Centralized control for deterministic routing and scheduling (PCE) Backbone router (ND proxy) enables Multi-Link subnet RPL distributed routing & scheduling for best effort Deterministic control loops including deterministic wired, wireless, and execution of control logic Industrial control logic running deterministically in carpeted floor (Fog) For Wi-Fi: best effort fringe using 2.4GHz band For Wi-Fi: converged wireless mesh Backhaul using 6TiSCH over .11 AC PHY in 5GHz band, shared with Factory Automation Fully scheduled wireless backbone Black: standard work Green: well advanced Orange: in progress Brick: Not started
  • 123.
    123 Authoritative Registrar Authoritative Registrar / 6LBR Intermediate Registrar/ 6LR Intermediate Registrar option. ND proxy Backbone router (ND proxy) - Scalable and Multi-Link - Reliable tracking - IP guard (admin knows what’s where) - Reliable (link) proxy operations, layer-2 or layer-3 - Support for legacy IPv6 devices - Support for IPv4 Multicast & broadcast suppression Reliable Registration Scalable registrar Well defined link-proxy operations …
  • 124.
    124 • Scale anIOT subnet to the tens of thousands With device mobility (no renumbering) Controlled Latency and higher Reliability using a backbone • DeterministicAddress presence Route towards the latest location of an address Remove stale addresses • Deterministic Networking / Reliable and AvailableWireless • Low Power Edge devices
  • 125.
    125 6LR 6LBR 6BBR Router/Serve r LPNode RPL Ethernet NA (~O) NS (EARO) Proxy NS (EARO) RPL DAO Router/Serve r Router/Serve r Ethernet / Wi-FiRadio 1 Hop Classical NDRFC 6550RFC 8505 RFC 8505 NA (EARO) DAO-ACK NA (EARO) 6LR RPL Root 6BBR Router/Serve r LP Node Router/Serve r Router/Serve r NS lookup Packet
  • 126.
    126 DCO (status) 6LR 6LBR6BBR Router/Serve r LP Node RPLv2 Ethernet NA (~O) NS (EARO) Proxy NS (EARO) RPL DAO Router/Serve r Router/Serve r Ethernet / Wi-FiRadio 1 Hop Classical NDRFC 6550RFC 8505 RFC 8505 NA (EARO, status) DAO-ACK NA (EARO) 6LR RPL Root 6BBR Router/Serve r LP Node Router/Serve r Router/Serve r NS DAD NA (EARO, status)
  • 127.
    127 6LR 6LBR 6BBR Router/Serve r LPNode RPL Ethernet NA (~O) NS (ARO) NS (ARO) RPL DAO Router/Serve r Router/Serve r EthernetRadio 1 Hop SRC = 6BBR DST = NS SRC TGT = LPN TLLA = 6LBR SRC = 6LR DST = Parent * or Root TGT = LPN (ROVR opt.) 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 6LR 6LBR/Root 6BBR Router/Serve r LP Node Router/Serve r Router/Serve r
  • 128.
  • 129.
    129 RPLv1 An extension ofIPv6 ND for MLSN Optimized for MP2P, P2MP with Root Optional support of P2P P2P reactive extension (AODV) L3: agnostic to L2 though aware of radios RPLv2 brings SDN /TE Model with Projected Routes for P2P RPL Unaware Leaves Brown field updates Sync of configuration and capabilities exchange
  • 130.
    130 • Minimum topologicalawareness (DV) • Proactive setup; lazy/reactive cleanup • Multi-Topology Routing (RPL Instances) Instantiation per constraints/metrics • Autonomic Subnet G/W Protocol • Optimized Diffusion over NBMA • Data Path validation • Non-Equal Cost Multipath Fwd
  • 131.
    131 At a givenpoint of time connectivity is as illustrated and rather fuzzy Radio link
  • 132.
    132 Clusterhead1st pass (DIO) Establishesa 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
  • 133.
    133 : : Anew 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
  • 134.
    134 Clusterhead A’s link toroot 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
  • 135.
    135 Clusterhead B can reparenta same Rank so B’s subDAG is safe The rest ofA’s subDAG is isolated Either poison or 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
  • 136.
    136 Clusterhead Once poisoned nodesare 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
  • 137.
    137 Clusterhead A new DAGiteration 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
  • 138.
    138 • RFC 6206:TheTrickleAlgorithm • 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 •
  • 139.
  • 140.
    140 ZeroTrust: the RULcould be all sorts of devices in the future and can become an attack vector against the RPL infra.With RFC 8505 and the optional AP-ND work we isolate the RUL from RPL, and control at the interface what gets injected in RPL Lower code / data footprint in the RUL: RUL devices supports IPv6 (RFC 8200) but not RPL (RFC 6550).The RUL as a 6LN uses RFC 8505 as specified by RUL draft. RFC 8505 is a simple abstraction, the complexity for in the 6LR. So a similar RUL implementation could connect to other types of networks. Easier upgrade of the RPL network: no need to update the RUL leaves, which could become a lot more numerous that the routers Less messaging:The RUL draft avoids the duplication of ND messages (NS and then DAR) and RPL (DAO). It’s only ND at the host to router interface, and only RPL at the router to router interface.
  • 141.
    141 6LBRRPL Root6LR 6LBRLPNode RPL NS (EARO) keepalive EDAR RPL DAO Radio 1 Hop RFC 6550RFC 8505 DAO-ACK NA (EARO) 6LRLP Node keepalive EDAC First EDAR First EDAC Proxy NS (EARO) Proxy NA (EARO) 6BBR Ethernet / Serial RFC 8505 Ethernet / Wi-Fi RFC 8505 … DAD
  • 142.
    142 6LBRRPL Root6LR 6LBRLPNode RPL NS (EARO) keepalive EDAR RPL DAO Radio 1 Hop RFC 6550RFC 8505 DAO-ACK NA (EARO) 6LRLP Node keepalive EDAC Proxy NS (EARO) Proxy NA (EARO) 6BBR Ethernet / Serial RFC 8505 Ethernet / Wi-Fi RFC 8505
  • 143.
  • 144.
    144 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 Src: Internet Dest: 56 Stuff Src: Internet Dest: 56 Stuff Src: Root Dest: 56 RPI
  • 145.
    145 11 12 13 25242322 3534333231 464544434241 DAGRoot 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
  • 146.
    146 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 Src: 51 Dest: Root Stuff RPI Same packet format from RAL to: • Other RAL • Root • The Internet Due to RPI option type now 0x23 Src: 51 Dest: Internet Stuff RPI Src: 51 Dest: 52 Stuff RPI Src: Root Dest: 56 Stuff RPI
  • 147.
    147 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 Src: X Dest: 52 Via: 11 Via: 22 Stuff Via: 32 Via: 42 Src: Root Dest: 52 RPI Src: 51 Dest: 52 Stuff RPIRPI
  • 148.
    148 11 12 13 25242322 3534333231 464544434241 DAGRoot 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: 52 RPI
  • 149.
    149 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 Src: Root Dest: 56 RPI Dest: Src: 51 Stuff Src: 41 Dest: Root RPI Dest: Internet Src: 51 Stuff Dest: 56 Src: 51 Stuff Dest: Src: 51 Stuff
  • 150.
    150 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 Src: Dest: 56 Stuff Src: Internet Dest: 56 Stuff Src: Root Dest: 46 RPI Src: 51 Dest: 56 Stuff Src: Root Dest: 56 Stuff RUL addresses injected in non-storing mode so packet flies to the Root which encapsulated Src: Dest: 56 Stuff
  • 151.
    151 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 Src: Dest: 56 Stuff Src: Internet Dest: 56 Stuff Src: Root Dest: 46 RPI Src: 51 Dest: 56 Stuff Src: Root Dest: 56 Stuff RUL addresses injected in non-storing mode so packet flies to the Root which encapsulated Src: Dest: 56 Stuff Via: 13 Via: 24 Via: 35
  • 152.
  • 153.
    153 • Adds Centralizedrouting (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?
  • 154.
  • 155.
    155 11 12 13 25242322 3534333231 464544434241 DAGRoot 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
  • 156.
    156 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 New (projected) DAO with path segment unicast to target 56 via 35 (ingress) and 46 (egress) 56
  • 157.
    157 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 Storing mode DAO with lifetime along segment
  • 158.
    158 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 DAO-ACK (alt: non storing DAO) unicast, self 35 as parent, final destination 56 as target
  • 159.
    159 11 12 13 25242322 3534333231 464544434241 DAGRoot 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
  • 160.
    160 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 Non source routed DATA Path
  • 161.
    161 11 12 13 25242322 3534333231 464544434241 DAGRoot 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
  • 162.
    162 11 12 13 25242322 3534333231 464544434241 DAGRoot 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
  • 163.
    163 11 12 13 25242322 3534333231 464544434241 DAGRoot 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
  • 164.
    164 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 Storing mode DAO (forced) with lifetime along segment Storing mode DAO with lifetime along segment
  • 165.
    165 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 DAO-ACK unicast, self 13 as parent, final destination 56 as target
  • 166.
    166 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 56 via 46 Preexisting connected route to 56 56 via 35 56 via 24
  • 167.
    167 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 Non source routed DATA Path
  • 168.
    168 11 12 13 25242322 3534333231 464544434241 DAGRoot 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
  • 169.
    169 11 12 13 25242322 3534333231 464544434241 DAGRoot 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
  • 170.
    170 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 Storing mode DAO with lifetime along segment
  • 171.
    171 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 DAO-ACK unicast, self 13 as parent, final destination 56 as target
  • 172.
    172 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 56 via 46 Preexisting connected route to 56 Preexisting connected route to 35 35 via 24
  • 173.
    173 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 routed DATA Path Loose Source routed DATA Path Packet to 35, RH 56 routed DATA Path
  • 174.
    174 11 12 13 25242322 3534333231 464544434241 DAGRoot 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
  • 175.
  • 176.
  • 177.
    177 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56
  • 178.
    178 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56
  • 179.
    179 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56
  • 180.
    180 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 New non-storing P-DAO with path segment unicast to target 41 via 42
  • 181.
    181 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 DAO ACK
  • 182.
    182 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 Packet for 41
  • 183.
    183 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 IP in IP encapsulation with SRH 42, 41
  • 184.
    184 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 storing P-DAO with path segment unicast to target 51 via 41 (egress)
  • 185.
    185 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 Packet for 51
  • 186.
    186 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 IP in IP encapsulation with SRH 42, 41
  • 187.
    187 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 Packet for 51
  • 188.
  • 189.
    189 11 12 13 25242322 3534333231 464544434241 DAGRoot 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)
  • 190.
    190 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 Storing mode DAO with lifetime along segment
  • 191.
    191 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 Storing mode DAO with lifetime along segment
  • 192.
    192 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56 DAO-ACK unicast, self 41 as parent, final destination 53 as target
  • 193.
    193 11 12 13 25242322 3534333231 464544434241 DAGRoot Application Server D 51 52 53 55 56
  • 194.
  • 195.
    195 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
  • 196.
    196 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. 196
  • 197.
    197 Root Rank 1 Rank 110 P:Rank 250 Rank 260 B: Rank 540 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 ∞ 197
  • 198.
  • 199.
  • 200.
  • 201.
    201 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: 201
  • 202.
    202 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 Root. 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 202
  • 203.
    203 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 203
  • 204.
    204 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 204
  • 205.
  • 206.
    206 An Arc isa 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
  • 207.
    207 An infrastructure Arcis 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 207
  • 208.
    208 Junctions may havemultiple 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 208
  • 209.
    209 ROOT A B Software-defined Projected ARROW Arcsfor 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
  • 210.
    210 - Sparrow requiresnon-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 210
  • 211.
  • 212.
    212 In blue thepreferred 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 212
  • 213.
    213 Original RPL DAG R A D L B K J C E F G HI 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 213
  • 214.
    214 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 214
  • 215.
    215 1) Root considerschanges 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 215
  • 216.
    216 1) The pathto 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 216
  • 217.
  • 218.
    218 DV, stretch optimizedfor P2MP/MP2P Peer selection /Trickle and OFs Anisotropy, lazy maintenance, Non-Storing Mode, Decoupled Metrics, NECM DAGs, Datapath validation Local and Global Recovery Coupling with MIPv6 and NEMO Dynamic Topologies Density Constrained Objects Fuzzy Links Routing, local Mobility Global Mobility New Radios issues: Addressed in RPL by:
  • 219.
    219 • AODV RPLto 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
  • 220.
    © 2012 Ciscoand/or its affiliates. All rights reserved.IoT6 220Unclassified “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.”
  • 221.
    © 2010 Ciscoand/or its affiliates. All rights reserved. 221UnclassifiedBRKEWN-3012 Questions
  • 223.