MC-SDN: Supporting Mixed-Criticality Scheduling on Switched-Ethernet Using Software-Defined Networking

Transcription

1 MC-SDN: Supporting Mixed-Criticality Scheduling on Switched-Ethernet Using Software-Defined Networking Kilho Lee, Taejune Park, Minsu Kim, Hoon Sung Chwa, Jinkyu Lee* Seungwon Shin, and Insik Shin * 1

2 Background: CPS network A fundamental element of CPS CPSs generally rely on network connected sensors, actuators, and computing units State of the art automotive/avionics standard: switched Ethernet BroadR-Reach, AFDX, IEEE TSN BMW, Jaguar, Airbus A380 Mixed-Criticality applications on common networking system ISO-26262, DO-178B 2

3 Research Goal Our objective: supporting mixed-criticality flows on switched Ethernet First work on switched Ethernet Conflicting goals: 1) Logical separation between flows with different criticality 2) Efficient resource use to reduce cost 3

4 Mixed-criticality scheduling Assumption for HI mode LO mode HI mode Mode violation Assumption for LO mode L H L H H Mode violation Mode-based scheduling Multiple criticality modes with different assumptions Different guarantees according to the mode LO mode: guarantee all flows HI mode: guarantee only high criticality flows Widely studied for processors [1] [1] A. Burns and R. Davis, Mixed criticality systems a review, 2018, 4

5 Software-Defined Networking (SDN) Limitation of Ethernet: static nature Cannot support dynamic behavior of MC scheduling Software-Defined networking (SDN) Separate the control plane and implement it as a software running on a centralized controller. Key enabler of MC scheduling dynamic network management 5

6 Benefits of MC scheduling 6

7 Benefits of MC scheduling (demo) 7

8 Challenge: mode change delay Empirical CDF Latency (ms) Up to 86 ms L LO mode H L H L Mode violation H HI mode Deadline misses! Long & unpredictable delay for mode change Unpredictable delay: Unbounded interference on high-criticality flows Long delay (tens of ms): significant damage on control applications Ex> Camera sensor 60Hz) 8

9 Challenge: where the delay comes from SW 1 (Starter) Controller SW 2 (Follower) t Time (t 0 : Mode violation detection) Mode change steps in a networking system 1 Mode change arrangement 2 New rule update 3 Out-of-mode packet handling 9

10 Challenge: where the delay comes from Mode change arrangement Communication (OpenFlow) Complicated software layers OpenFlow message transmission cost New rule update Communication (OpenFlow + Intra-switch) Complicated switch internal structure Out-of-mode packet handling Wait for transmission Enqueued packets with the old mode rules Control Plane Network applications Northbound interface Controller abstraction Southbound interface (OpenFlow) OpenFlow communication Data Plane OpenFlow interface Switch management abstraction Datapath interface Datapath 10

11 Approach: switch-driven mode change SW 1 (Starter) Proactively deploy other mode rules t 0 SW 2 (Follower) SW 3 (Follower) Time (t 0 : Mode violation detection) Mode change arrangement OpenFlow comm. Inter-switch signal propagation New rule update OpenFlow comm. Update with proactively deployed rules Intra-switch comm. Simple operation Out-of-mode packet handling Wait Apply new rules to the out-of-mode packets 11

12 MC-SDN: system design Data Plane Datapath Module Flow Behavior Monitor Rule update Mode change Mode Change Arranger MC Rule Manager Other mode rules stored in Shadow Table Extend SDN switch with new components Queueing Module MC Queue Controller 1 st priority Mode change signal Priority Queue propagate packet Packets Enqueue Forward Forwarding Table 12

13 MC-SDN: system design Data Plane Datapath Module Flow Behavior Monitor Mode change Mode Change Arranger Queueing Module MC Queue Controller MC Rule Manager Other mode rules stored in Shadow Table Priority Queue Packets Enqueue Forward Forwarding Table Flow Behavior Monitor detects a mode violation 13

14 MC-SDN: system design Data Plane Datapath Module Flow Behavior Monitor Mode change Mode Change Arranger MC Rule Manager Other mode rules stored in Shadow Table Queueing Module MC Queue Controller 1 st priority Mode change signal Priority Queue propagate packet Packets Enqueue Forward Forwarding Table 1 Mode change arrangement Mode Change Arranger broadcasts the mode change signal OpenFlow comm. Inter-switch signal propagation 14

15 MC-SDN: system design Data Plane Datapath Module Flow Behavior Monitor Rule update Mode change Mode Change Arranger MC Rule Manager Other mode rules stored in Shadow Table Queueing Module MC Queue Controller 1 st priority Mode change signal Priority Queue propagate packet Packets Enqueue Forward Forwarding Table 2 New rule update MC Rule Manager updates the forwarding table with proactively deployed other mode rules in Shadow Table OpenFlow comm. Update with proactively deployed rules Intra-switch comm. Simple operation 15

16 MC-SDN: system design Data Plane Datapath Module Flow Behavior Monitor Rule update Mode change Mode Change Arranger MC Rule Manager Other mode rules stored in Shadow Table Queueing Module MC Queue Controller 1 st priority Mode change signal Priority Queue propagate packet Packets Enqueue Forward Forwarding Table 3 Out-of-mode packet handling MC Queue Controller rearranges the queue Wait Apply new rules to the out-of-mode packets 16

17 MC-SDN: implementation Data Plane Datapath Module Flow Behavior Monitor Rule update Mode change Mode Change Arranger MC Rule Manager Other mode rules stored in Shadow Table Queueing Module MC Queue Controller 1 st priority Mode change signal Priority Queue propagate packet Packets Enqueue Forward Forwarding Table Prototype implementation Open vswitch (OVS), POX network controller 4,000 and 2,000 additional LoC in OVS and POX, respectively. Implementation challenge Details beyond the OpenFlow abstraction and the switch architecture 17

18 MC-SDN: implementation detail Flow Behavior Monitor Detecting period mode violation based on Sporadic invariants [2] Implemented as an OpenFlow extension action, OFPAT_FLOW_MONITOR Mode Change Arranger Flooding a short signal packet with 1 st priority Implemented as an OpenFlow extension action, OFPAT_MODE_ARRANGE [2] A. Burns et al., Mixed criticality on controller area network, in IEEE ECRTS, July 2013, pp

19 MC-SDN: implementation detail MC Rule Manager Storing rules for new mode in Shadow Table Address intra-switch communication delay including cache revalidation delay Shadow table Cached shadow table (Kernel datapath) MC Queue Controller Rearrange packets in the queue according to the new rules Implemented on top of Linux TC-PRIO queueing discipline Hook packets and re-queue or drop them 19

20 Result: mode change delay Up to 86 ms Up to 0.48 ms Empirical CDF 1 Empirical CDF 1 Upper bound Latency (ms) Latency (ms) MC-SDN: controller-driven switch-driven mode change Significantly reduce the delay More predictable delay with upper-bound 20

21 MC-SDN: mode change delay bound Total delay for a mode change Mode change arrange delay New rule update delay Out-of-mode packet handling delay 21

22 MC-SDN: mode change delay bound Upper-bound of each delay component By the physical property Empirically derived 99.5% confidence level based on execution samples on our testbed WCET analysis can be applied 22

23 Evaluation Questions Mode change delay improvement Impact of reduced mode-change delay Overhead Setup 29 single board computers 9 switches, 20 end nodes 100 Mbps Ethernet Star, grid, and linear topologies 23

24 Evaluation: delay Up to ms Up to 7.5 ms (a) Std-SDN (b) MC-SDN Baseline: Std-SDN The standard request-response protocol for mode change Effectively reduce and bound the delay Despite the increase in the number of rules to update Despite the presence of out-of-mode packets (100 vs 100+) 24

25 Evaluation: end-to-end transmission time (a) Std-SDN (b) MC-SDN Baseline: Std-SDN The standard request-response protocol for mode change Effectively limit interference 25

26 Evaluation: overhead Baseline: Vanilla OVS Open vswitch without any modification The overhead (i.e., flow monitoring) is effectively hidden and negligible 26

27 Case study: 1/10 scale autonomous vehicle Sensors (LIDAR, camera) End nodes (Jetson TK1, RPi3) Switches (Odroid-XU4) Actuators (motors) ss 11 (Sensors) ss 22 (Streaming) * Jetson TK1, Raspberry PI3, Odroid-XU4 cc 11 (SDN Controller) ssss 1 Shared Link ssss 2 dd 11 (Controllers & Actuators) dd 22 (Streaming) Question Effectiveness of MC-SDN in real-world applications Setup 7 single-board computers, 2 sensors, and 2 actuators 2 switch nodes, 4 end nodes, and 1 SDN controller LIDAR, a stereo camera, and DC/servo motors 27

28 Case study: 1/10 scale autonomous vehicle 1 Perception & Reaction Distance 2 Braking Distance 3 Total Stopping Distance Driving at ~2.1m/s Detection Range (2.0m) wall 0m 1m 2m 3m 4m 5m 6m 7m Detecting Point Braking Point Stopping Point Autonomous Emergency Braking (AEB) scenario Cam (HI criticality), Streaming (LO criticality) Mode violation at the detecting point Baseline: Static scheduling (LO Only and HI Only) Systems that only support fixed sensing rates 5 and 45 Hz in LO Only and HI Only, respectively System Safety EFF. LO Only HI Only MC-SDN 28

29 Conclusion MC-SDN: supporting mixed-criticality scheduling on switched-ethernet Reduce and bound mode change delay New way of mode management: Controller-driven Switch-driven Extensive evaluations Full implementation on top of OVS and evaluation on the network testbed Deployment to the 1/10 scale autonomous car 29

30 30