SDN SEMINAR 2017 ARCHITECTING A CONTROL PLANE

Transcription

1 SDN SEMINAR 2017 ARCHITECTING A CONTROL PLANE

2 NETWORKS ` 2

3 COMPUTER NETWORKS 3

4 COMPUTER NETWORKS EVOLUTION Applications evolve become heterogeneous increase in traffic volume change dynamically traffic patterns move location (migration and cloud trends) The network should match application needs 4

5 COMPUTER NETWORKS EVOLUTION Conventional networks are rigid and slow to evolve. Programmable networks offer quick adaptability and service-lisation. Key component: the control plane 5

6 COMPUTER NETWORKS PURPOSE & FUNCTION What is the purpose of a network? What is a control plane? How does it do what it should? What interactions take place? 6

7 CONVENTIONAL NETWORKS PUSHING TRAFFIC: SINGLE SWITCH Physical infrastructure > data plane 7

8 CONVENTIONAL NETWORKS PUSHING TRAFFIC: SINGLE SWITCH Physical infrastructure > data plane How are gates activated? 8

9 CONVENTIONAL NETWORKS PUSHING TRAFFIC: SINGLE SWITCH Activation logic > control plane forwarding table: match a device address to a port MAC address Port MAC A 1 MAC B 2 MAC C 2 MAC A MAC B MAC C in: port 1 out: port 2 9

10 CONVENTIONAL NETWORKS PUSHING TRAFFIC: DATA CENTRE NETWORK Fat tree topology 10

11 CONVENTIONAL NETWORKS PUSHING TRAFFIC: DATA CENTRE NETWORK Fat tree topology Activation logic > distributed protocols 11

12 CONVENTIONAL NETWORKS PUSHING TRAFFIC: DATA CENTRE NETWORK Open Shortest Path First (OSPF) protocol each switch constructs a single source shortest path tree S A B C D 12

13 CONVENTIONAL NETWORKS THE CHALLENGES Applications evolve fast Integrated data and control plane obstructs innovation Adding new functionality is a slow, costly process Monopoly by few equipment manufacturers No programmability Cumbersome low-level configurations 13

14 PROGRAMMABLE NETWORKS A NEW DESIGN PARADIGM Innovation through divide and conquer separate the data plane from the control plane logically-centralised control > controller having a global view drives optimisation 14

15 PROGRAMMABLE NETWORKS A NEW DESIGN PARADIGM Innovation through divide and conquer separate the data plane from the control plane logically-centralised control > controller having a global view drives optimisation Pure solution Data plane ONLY moves packets ALL control decision are taken by the controller 15

16 PROPAGATING CONTROL DECISIONS SOUTHBOUND INTERFACE Formalises communication to the data plane Hides implementation details from the controller Hides control logic from the switches OpenFlow protocol P4 (Programming Protocol-Independent Packet Processors) 16

17 PROPAGATING CONTROL DECISIONS SOUTHBOUND INTERFACE rule-based Match-action processing 17

18 PROPAGATING CONTROL DECISIONS SOUTHBOUND INTERFACE Open Flow Objectives: protocol dependent platform dependent hard to reconfigure Components: Headers Actions Tables P4 Objectives: protocol independent platform independent reconfigure processing Components: Headers Parsers Actions Tables Control chain 18

19 PROPAGATING CONTROL DECISIONS SOUTHBOUND INTERFACE: OF Components: message types switch and controller behaviour Features: fix set of packet headers, ever growing fix set of actions (drop, forward, modify header, send to controller) pipelined table processing 19

20 PROPAGATING CONTROL DECISIONS SOUTHBOUND INTERFACE: P4 Objectives: protocol independent: P4 programs can be compiled against many different types of execution machines, e.g., generalpurpose CPUs, FPGAs, SoC, NPU, and ASICs. platform independent: no native support for known protocols. A P4 programmer describes the header formats and field names of the required protocols, which are in turn interpreted and processed by the compiled program and target device. reconfigure: change the way packets are processed (perhaps multiple times) after they are deployed 20

21 PROPAGATING CONTROL DECISIONS SOUTHBOUND INTERFACE: P4 Components: Headers: describe packet formats and provide names for the fields within the packet. Parsers: a finite state machine that walks an incoming bytestream and extracts headers based on the programmed parse graph. Actions: describe manipulations on packets, packet fields or metadata. Tables: lookup keys (header sets) and a corresponding set of actions and their parameters. Control chain: determines the relative sequence of tables. 21

22 A BASE FOR TRAFFIC DECISIONS CONTROLLER DESIGN What of we need to know to generate the flow rules? 22

23 A BASE FOR TRAFFIC DECISIONS TOPOLOGY DISCOVERY Topology: the physical and logical connectivity of devices. 23

24 A BASE FOR TRAFFIC DECISIONS TOPOLOGY DISCOVERY Topology: the physical and logical connectivity of devices. LLDP: Link Layer Discovery Protocol 24

25 A BASE FOR TRAFFIC DECISIONS TOPOLOGY DISCOVERY LLDP: Link Layer Discovery Protocol A switch is configured with a master controller and a flow rule to forward LLDP messages. On boot a switch contacts the controller: we now know all switches there are. Controller sends out LLDP messages. A switch forwards LLDP message from a non-controller port to the controller. We now know all links (port-to-port connectivity). 25

26 A BASE FOR TRAFFIC DECISIONS CONTROL LOGIC IN APPLICATIONS Function-specific logic that addresses different traffic processing aspects routing load balancing security policies (firewalls) monitoring Execute algorithms on incoming packets (firewalls), the topology (routing) or metadata (application load balancing). 26

27 A BASE FOR TRAFFIC DECISIONS CONTROL LOGIC IN APPLICATIONS What are the advantages of a global topology view? Routing: All Pairs Shortest Paths: find the shortest path for all pairs of nodes in the graph. Disjoint Paths: find paths between a pair of nodes that do not share edges. 27

28 A BASE FOR TRAFFIC DECISIONS CONTROL LOGIC IN APPLICATIONS Monolithic applications are hard to program, debug, test and extend > modular design Composition parallel: for processing tasks that do not interfere sequential: for processing tasks that interfere in decisions 28

29 A BASE FOR TRAFFIC DECISIONS CONFIGURATION WITH HIGH LEVEL POLICIES Policy: specifies in high abstract term how packets should be handled by the network elements does not instruct low-level implementation A simple routing policy: match(dstip= ) >> fwd(1) 29

30 A BASE FOR TRAFFIC DECISIONS CONFIGURATION WITH HIGH LEVEL POLICIES Policies are written in network programming languages Frenetic, Pyretic, Merlin Nettle, Maple Queries q ::= Select(a) * Where(fp ) * GroupBy([qh1,..., qhn]) * SplitWhen([qh1,..., qhn]) * Every(n) * Limit(n) Aggregates a ::= packets sizes counts Headers qh ::= inport srcmac dstmac ethtype vlan srcip dstip protocol srcport dstport switch Patterns fp ::= true fp() qh fp(n) and fp([fp1,...,fpn]) or fp([fp1,...,fpn]) diff fp(fp1, fp2 ) not fp(fp) 30

31 PROGRAMMABLE NETWORKS A NEW DESIGN PARADIGM Packet processing in pure SDN. Pure solutions do not scale well. Why? require per packet decision in the controller long communication delay between controller and switches communication overhead repeated decision taking for similar flows 31

32 CONTROLLER DESIGN TRAFFIC MANAGEMENT SEPARATION Traffic type separation mice vs elephant flows Proactive decision taking: push rules before traffic arrives generic vs on-the-fly rules Rule aggregation & rule partitioning Outsource traffic handling logic to switches local logic specifies how simple traffic procedures can be executed without the controller participation 32

33 CONTROLLER DESIGN DEPLOYMENT STRATEGIES Single control plane (physical or logical controller) Physically distributed but logically centralised Logically distributed Hierarchical controllers 33

34 CONTROLLER DESIGN DEPLOYMENT STRATEGIES Host-based traffic management: decisions on how the traffic is handled by the network elements are taken at the host. Effectively the ultimate distributed controller: each host runs part of the controller logic. 34

35 SEMINAR OUTLINE Topic 1: Distributed control applications Topic 2: Distributed controller design Topic 3: Consistency management Topic 4: Abstractions for programmability Topic 5: Alternative control plane design Topic 6: Programmable switches Topic 7: Network statistics collection Topic 8: Network load balancing Topic 9: Legacy systems interoperation 35