Languages for Software-Defined Networks

1. Languages forSoftware-Defined Networks Nate Foster, ArjunGuha, Mark Reitblatt, and Alec Story, Cornell University Michael J. Freedman, Naga Praveen Katta, Christopher Monsanto, Joshua Reich, Jennifer Rexford, Cole Schlesinger, and David Walker, Princeton University Major Robert Harrison, U.S. Military Academy

2. Outline • Introduction • Querying Network State • Query language design considerations • Composing Network Policies • Creating modular programs • Efficient Runtime System • Consistent Update • Per-packet consistent updates • Per-flow Consistency • Conclusion

3. Introduction • Modern computer networks perform a bewildering array of tasks. • Solution: Software-defined networks (SDN) • What is SDN?

4. Introduction • To reach SDNs’ full potential, we need to identify the right higher-level abstractions for creating (and composing) applications. • What is Frenetic? • Frenetic project: • Monitoring network traffic. • Specifying and composing Packet forwarding policies. • Policies in a consistent way.

5. Querying Network State • Many SDN programs react to changes in network state • Topology changes • Link failures • Traffic load • Arrival of particular packets at specific switches. • Usually, to monitor traffic , the controller can poll the counters associated with the rules installed on switches. • Frenetic’s query language allows programmers to express what they want to monitor, leaving the details of how to actually collect the necessary traffic statistics to the runtime system.

6. Querying Network State • QUERY LANGUAGE DESIGN CONSIDERATIONS • High-Level Predicates • Dynamic Unfolding • Limiting Traffic • Polling and Combining Statistics

7. QUERY LANGUAGE DESIGN CONSIDERATIONS • High-Level Predicates • Rule 1: 1.2.3.4 & srcport=80 action=drop. • Rule 2: *.*.*.* & srcport=80 action=accept • In Frenetic: “ srcip !=1.2.3.4 & srcport=80” action=accept • Dynamic Unfolding • Switches have limited space for rules • In Frenetic: the programmer can register a query that uses operators such as “Select(bytes)” and “GroupBy([srcip])” and the runtime system dynamically generates the appropriate rules.

8. QUERY LANGUAGE DESIGN CONSIDERATIONS • Limiting traffic • Rule has priority and may affect each other. • Process the situation that “Multiple packets may arrive at the controller before the rules are Installed.” • In Frenetic: “ Limit(1) “. • Polling and Combining statics • Many programs need to receive periodic information about traffic statistics. • In Frenetic: “Every(60) “.

9. EXAMPLE FRENETIC QUERIES • MAC Learning — An Ethernet switch performs medium access control (MAC) learning to identify what interface to use to reach a host. MAC learning can be expressed in Frenetic as follows: Select(packets) * GroupBy([srcmac]) * SplitWhen([inport]) * Limit(1)

10. EXAMPLE FRENETIC QUERIES • Traffic Histogram — As another example, consider the following query, which measures the traffic volume by destination IP address on a particular link: Select(bytes) * Where(inport=2 & srcport=80) * GroupBy([srcip]) * Every(60)

11. Composing Network Policies • CREATING MODULAR PROGRAMS • Ex: a simple program that combines repeater functionality with web-traffic monitoring functionality.

12. Composing Network Policies • CREATING MODULAR PROGRAMS • Ex: a simple program that combines repeater functionality with web-traffic monitoring functionality.

13. Composing Network Policies • Efficient Runtime System • The run-time system ensures that each module runs correctly, independent of the other modules. • Strategy 1. microflow-based for install rule on switch. 2. Determine that whether any queries depend on receiving future packet ? • Issue: sending packets to the controller is expensive. • Solution : uses an intermediate language, called NetCore • Frenetic runtime system is proactiveuses wildcard rules.

14. Composing Network Policies • Efficient Runtime System • Three exception where the NetCorecannot generate rule: 1.The policy involves a query that groups by IP 2. The policy involves a function that cannot be implemented natively or efficiently on the switch hardware. ex: 90.80.*.60 vs 90.80.*.* 3. The switch does not have space for additional wildcard rules.

15. Consistent Update • Programs often need to transition from one policy to another — for example, due to topology changes, changes in network load or application behavior, planned maintenance, or unexpected failures. • Per-packetconsistent updates • Every packet flowing through the network is processed with exactly one forwarding policy. • Trace properties of path.

16. Consistent Update • Per-packetconsistent updates • The semantics of per-packet consistent update is very helpful with developers, also makes it possible to build verification tools • To implement per-packet consistency, we use a mechanism called two-phase update that stamps packets with a version. • 1. To update to a new configuration, the controller first pre-processes the rules in the new configuration, adding an action to stamp packets at the ingress. • 2. installs the rules for internal ports, leaving the rules for the old configuration in place

17. Consistent Update • Per-packetconsistent updates • Two-phase update mechanism works in any situation, but it is not always necessary. Ex: The policy changes affect only a portion of the network topology or a portion of the traffic.

18. Consistent Update • Per-Flowconsistent updates • Some applications require that streams of related packets be handled consistently. • Per-flow consistent update ensures that streamsof related packets are processed with the same policy. • Per-flow update preserves all trace properties. Strategy: A mechanism can be obtained by combining versioning with rule timeouts.

19. Consistent Update • Per-Flowconsistent updates 1. The runtime system can pre-install the new configuration on internal switches, leaving the old version in place. 2. The controller sets soft timeouts on the rules for the old configuration and installs the new configuration at lower priority. Potential problem: if several flows match a rule, the rule may be artificially kept alive even though the “old” flows have completed — if the rules are too coarse, they may never die!

20. Conclusion • The Frenetic language offers programmers a collection of powerful abstractions for writing controller programs for software-defined networks. • Monitoring network state • Computing new policies • Reconfiguring the networks • Next =>“Slicing” of the network • Goal: Lower the barrier for creating new and exciting applications on software defined networks.

21. THANKS~