Languages for SDN (Frenetic)

Transcription

1 Languages for SDN (Frenetic) Software Defined Networking: The Data Centre Perspective Seminar Informatikdienste A. Pantelopoulos

2 SDN is useful Direct network control. Enables new applications, simplifies existing ones. Informatikdienste A. Pantelopoulos

3 SDN is useful Direct network control. Enables new applications, simplifies existing ones. Energy aware network management. Informatikdienste A. Pantelopoulos

4 SDN is useful Direct network control. Enables new applications, simplifies existing ones. Energy aware network management. Fine grained access policies. Informatikdienste A. Pantelopoulos

5 SDN is useful Direct network control. Enables new applications, simplifies existing ones. Energy aware network management. Fine grained access policies. Load balancing... Informatikdienste A. Pantelopoulos

6 Why use an SDN language? Abstractions manage complexity. Informatikdienste A. Pantelopoulos

7 Why use an SDN language? Abstractions manage complexity. Where is the complexity? Openflow resembles the actual hardware. Informatikdienste A. Pantelopoulos

8 Why use an SDN language? Abstractions manage complexity. Where is the complexity? Openflow resembles the actual hardware. Rules interfere. Informatikdienste A. Pantelopoulos

9 Why use an SDN language? Abstractions manage complexity. Where is the complexity? Openflow resembles the actual hardware. Rules interfere. Network is a distributed system. Informatikdienste A. Pantelopoulos

10 Frenetic offers declarative abstractions implemented and combined by a runtime system in order to query the network state, define policies and consistently update them. Focus on high level goals, not fiddly details. Informatikdienste A. Pantelopoulos

11 Querying Network State Monitoring traffic via rule counters. Need fine-grained rules with priorities. Rules for different applications collide. Frenetic : Programmers simply express what they want to monitor, not how. Informatikdienste A. Pantelopoulos

12 Language Design Considerations High-level Predicates Specify OF headers, network location with various operators. Dynamic Unfolding Monitor rules installed upon first packet. Limiting Traffic Limit packets that programmer observes. Statistics Query interval for statistics set by programmer. All complexity is handled by the runtime system. Informatikdienste A. Pantelopoulos

13 MAC Learning Traffic Histogram Informatikdienste A. Pantelopoulos

14 Composing Network Policies Orthogonal functionality should be composed separately and combined together by programs. Example : A module that implements a repeater and a module that implements a web-traffic monitor. Informatikdienste A. Pantelopoulos

15 NOX Frenetic Informatikdienste A. Pantelopoulos

16 The run time system combines policies and generates final rule combinations. How to compose? Parallel : Multiple forwarding policies. With filters : Firewall policy. Sequential : Load balance and then route. Informatikdienste A. Pantelopoulos

17 The Run Time System Ensures correct and independent module execution. Re-active microflow strategy - Upon packetin : Traverse queries and forwarding policies and collect a list of actions If no queries depend on packet, install a single rule that applies the actions Otherwise, perform actions without installing the rule. Works, but slow (Devoflow reported 2.5 msec controller round trip) Informatikdienste A. Pantelopoulos

18 Proactive microflow strategy Pre-install wildcard rules where possible. if not, use reactive specialization algorithm and install rules on-demand. Express forwarding policies with NetCore language, compile NetCore to OpenFlow rules. Informatikdienste A. Pantelopoulos

19 Pro-active rule generation is not always possible Query that groups per IP address. Policy implementing a complex function. eg. Predicate that matches 90.* No space in the switch. Multiple policies and modules may result in rule blow-up. Informatikdienste A. Pantelopoulos

20 Consistent Updates Graceful policy transitions. Application invariants should be preserved during policy migration. Programmer should use high level operations that implement consistency. Per-Packet or Per-Flow Informatikdienste A. Pantelopoulos

21 Per-Packet Consistency On transition from policy A to B, every packet will be processed by one set of rules, on all switches. Trace Properties are satisfied during the updates and as policies evolve. eg. Connectivity and access control properties are enforced. Automatic Verification for trace properties persistance is possible with NetCore policies. Informatikdienste A. Pantelopoulos

22 Two-Phase Update mechanism Mechanism for enforcing consistent updates. 1. Differentiate policies with different version numbers, stamp packets at network ingress ( VLAN / MPLS fields). 2. Install updated policy rules on all internal switches, matching also with version number. 3. Gradually update policy rules at the ingress switches of the network. Any packet will be handled by one policy, since it is stamped only once. May lead to rule table blow-up, optimize transitions where possible. Informatikdienste A. Pantelopoulos

23 Per-flow Consistency On transition from policy A to B, all packets from the same flow are handled by the same policy. Preserves trace and per-path properties across transition. Simple Mechanism for per-flow consistency: 1. Install rules on internal switches as before, with low priority. 2. Set soft timeouts on old policy rules and wait to expire. In general, per-flow consistency is more complex and tedious to implement correctly. Informatikdienste A. Pantelopoulos

24 Conclusions Powerful abstractions reduce complexity for controller application programmers. Most SDN related problems persist, but they are easier tackled under the umbrella of a runtime system. Informatikdienste A. Pantelopoulos