Lesson 9.1 - Programming SDNs

Question 1

The OpenFlow API does not provide…

Answer 1

Specific guarantees about the level of consistency that packets along an end-to-end path can experience

Question 2

What are 2 consistency problems with SDNs?

Answer 2

Packet-level consistency problems

Flow-level consistency problems

Question 3

Packet-level consistency problem

Answer 3

Updates to multiple switches along a path in a network that occur at different times may result in problems such as forwarding loops

Question 4

Flow-level consistency problem

Answer 4

If updates to switches along an end-to-end path occur in the middle of a flow, packets from the same flow may be subjected to 2 different network states

Question 5

3 steps of SDN program

Answer 5

1. Controller needs to read/monitor network state as well as various events that may be occurring in the network
   * Events may include failures, topology changes, security events, etc.
2. Compute policy based on the state that the controller sees from the network
   * Roughly the role of the decision plane, deciding the behavior of the network in response to various events
3. Write policy back to the switches by installing the appropriate flow table state into the switches

• Consistency problems can arise in steps 1 and 3:
  * In step 1: Controller may read state from network switches at different times, resulting in an inconsistent view of the network-wide state
  * In step 3: Controller may be writing policy as traffic is actively flowing through the network, which can disrupt packets along an end-to-end path or packets that should be treated consistently because they’re part of the same flow

Reading and writing network state can be challenging because OpenFlow rules are simple match-action predicates, so it can be difficult to express complex logic. Need more sophisticated predicates.

Question 6

3 approaches to help guarantee consistency in reading state

Answer 6

Predicates
Rule unfolding
Suppression

Question 7

Reasons a controller might want to write policy to change state in network

Answer 7

• Maintenance
  * Unexpected failure
  * Traffic engineering

*** These all require updating state in the network switches

Question 8

When writing policy changes, we want to make sure forwarding remains…

Answer 8

correct and consistent

Question 9

When writing policy changes, we’d like to maintain the following invariants…

Answer 9

• No forwarding loops
  * No black holes (a router or switch receives a packet and doesn’t know what to do with it)
  * No security violations (traffic is going where it shouldn’t be allowed to go)

Question 10

What can happen if policies are written in an inconsistent fashion?

Answer 10

• You could have a forwarding loop.
  * If rules are installed out of order, packets may reach a switch before the new rules do.
  * We need atomic updates to the entire configuration.

Question 11

Solution to inconsistent policy writing?

Answer 11

• Use a two-phase commit:
• Packets are either subjected to the old config on all switches, or the new config on all switches. Not a mix.
• Idea: tag the packet on ingress such that the switches maintain copies of both P1 and P2 for some time.
• Once all switches receive rules corresponding to the new policy, then incoming packets can be tagged with P2.
• Once we know that no more packets of P1 are being forwarded through the network, we can only then remove the rules corresponding to policy P1.
• Naive version of 2-phase commit requires doing this on all switches at once, which essentially doubles the rule space requirements.
• We can limit the scope/optimize by only applying this mechanism on switches that involve the affected portions of the traffic or the affected portions of the topology.

Question 12

What problems can arise from inconsistent “writes” of network state?

• Inability to respond to failures
• Forwarding loops
• A flood of traffic at the controller
• Security policy violations

Answer 12

• Forwarding loops
• A flood of traffic at the controller
• Security policy violations

Question 13

How do you cope with inconsistency?

• Different controllers for different switches
• Keeping a “hot spare” replica
• Keeping the old and new state on the routers/switches
• Resolving conflicts on the routers

Answer 13

-Keeping the old and new state on the routers/switches

Question 14

What is network virtualization?

Answer 14

• An application of SDN
• One example is Mininet
• An abstraction of the physical network where multiple logical networks can be run on the same underlying physical substrate
• Each logical network has its own view, even though it may share nodes with other logical networks, as if it were running its own private version of the network.
  * Nodes need to be shared or sliced. They are typically virtual machines (VMs)
  * A single link in a logical topology might actually map to multiple links in the physical topology. The mechanism to achieve these virtual links is typically through tunneling. For example, a packet from A->B in the logical topology below might be encapsulated as a packet that goes from A->X->B in the physical topology.

Question 15

In network virtualization, a single link in a logical topology might actually map to multiple links in the physical topology. The mechanism to achieve these virtual links is typically through:

Answer 15

tunneling

For example, a packet from A->B in the logical topology in the lecture might be encapsulated as a packet that goes from A->X->B in the physical topology.

Question 16

Network virtualization can also be thought of as an analogy to…

Answer 16

virtual machines

• In VMs, a hypervisor arbitrates access to the underlying physical resources, providing to each virtual machine the illusion that it’s operating on its own dedicated version of the hardware.
• Similarly, with virtual networking, a network hypervisor of sorts arbitrates to the underlying physical network to multiple virtual networks.

Question 17

Why use network virtualization?

Answer 17

• One of the main motivations: the ossification of Internet architecture
  * In particular, because IP so pervasive, makes it difficult to make fundamental changes to the underlying internet architecture and how it operates.
  * Lots of work done in the early 2000s on network overlays, but 1-size fits all architectures very difficult to deploy. So, rather than trying to replace existing network architectures, network virtualization was intended to allow for easier evolution.
  
  • Network virtualization enables evolution by letting multiple architectures exist in parallel. We didn’t have to pick a winner for a replacement for IP.
  • In practice, network virtualization has really taken off in multi-tenant data centers, where there may be multiple tenants/applications running on a shared cluster of servers. Well-known examples of this include Amazon’s EC2, Rackspace, and things like Google App Engine.
  • Service providers such as Google, Yahoo, and so forth also use network virtualization to adjust the resources devoted to any particular service at a given time.

Question 18

Network virtualization has really taken off in…

Answer 18

Multi-tenant data centers where there may be multiple tenants/applications running on a shared cluster of servers. Well-known examples of this include Amazon’s EC2, Rackspace, and things like Google App Engine.

Question 19

Motivation for virtual networking?

• Easier troubleshooting
• Facilitating research/evolution by allowing coexistence
• Better forwarding performance
• Adjusting resources to demand

Answer 19

• Facilitating research/evolution by allowing coexistence

- Adjusting resources to demand

Question 20

Promised benefits of network virtualization

Answer 20

1. More rapid innovation, since innovation can proceed at the rate at which software evolves, rather than on hardware development cycles
2. Allowing for new forms of network control
3. Potentially simpler programming

Question 21

Important to make a distinction between SDN and Network Virtualization

Answer 21

• Network Virtualization is arguably one of the first killer applications for SDN, and in some sense SDN is a tool for implementing network virtualization, but they are not the same thing.
• Defining tenant of SDN is separation of data and control planes
• Defining tenant of network virtualization is separation of underlying physical network from logical networks that lie on top of it.
• SDN can be used to simplify many aspects of network virtualization, but it does not inherently abstract the details of the underlying physical network

Question 22

Which are characteristics of network virtualization?

• Allowing multiple tenants to share underlying physical topology
• Controlling behavior from a centralized controller
• Separating logical and physical networks
• Separating data and control planes

Answer 22

• Allowing multiple tenants to share underlying physical topology
• Separating logical and physical networks

*** The 2 other answers below are defining characteristics of SDN but not of network virtualization

Question 23

What are the various design goals of virtual networks?

Answer 23

• Flexible: support different topologies, routing and forwarding architectures, and independent configurations
• Manageable: separate the policy that a network operator is trying to specify form the mechanisms of how those policies are implemented
• Scalable: maximize the number of coexisting virtual networks
• Secure: isolating different logical networks from one another
• Programmable
• Heterogeneous: support different technologies

Question 24

2 components of virtual networks

Answer 24

• Nodes: physical nodes are virtualized. One possible way is a VM.
  * A more lightweight way of virtualizing a node is using a virtual environment, such as a V-server or a Jail
  * Examples of node virtualization include virtual machine environments such as Xen, VMWare, or what’s called OS-level virtualization or virtual environments, such as Linux Vservers.
• Edges: Each virtual machine or virtual environment has its own view of the network stack, and we may want to provide the appearance that these nodes are connected to one another over a layer 2 topology, even if they are in fact separated by multiple IP hops.
  * One way of doing that is to encapsulate the ethernet packet as it leaves the VM on the left in an IP packet. The IP packet can then be destined for the IP address of the machine on the right, and when it arrives, the host can decapsulate the packet and pass the original ethernet packet to the VM or the virtual environment that’s residing on that physical node.
  * Each physical host may host multiple virtual machines or virtual environments, which creates the need for a virtual switch which resides on a host.
  * Virtual switch provides the function of networking virtual machines together over a virtual layer 2 topology.
  * Example of a software switch that can perform this type of function is the Linux Bridge. Another example is Open VSwitch (http://openvswitch.org)

Question 25

Virtual networks facilitate…

Answer 25

agile development, by enabling rapid innovation at the pace of software, vendor independence, and scale.

Question 26

What makes SDN programming hard?

Answer 26

• Unfortunately, programming OpenFlow is NOT easy.
  
  • It offers a very low level of abstraction in the form of match-action rules
  • The controller only sees events that switches don’t know how to handle
  • There can be race conditions if switch-level rules are not installed properly (like we saw in the lesson on consistent updates)

Question 27

Solution to the difficulties of SDN programming

Answer 27

• Provide some kind of “Northbound” API, which is a programming interface that allows applications or other orchestration systems to program the network
  * Apps and Orchestration systems are used to perform more sophisticated tasks, such as path computation, loop avoidance, and so forth
  * Need a higher level programming interface that enables these applications to talk to the controller, without worrying about low-level things like whether the rules are being installed in a consistent and correct fashion
  * Various people may write these applications, including network operators, service providers, researchers, and anyone who wants to develop capabilities on top of OpenFlow

Question 28

Benefits of a northbound API

Answer 28

• Vendor independence
• Ability to quickly modify/customize control through various popular programming languages
• Examples of such applications include:
  * Implementation of a large virtual switch abstraction
  * Security applications
  * Services that may need to integrate traffic processing with middle boxes
• Currently, the standard for the southbound API is OpenFlow, but there is currently no standard for the northbound API

Question 29

Frenetic

Answer 29

• One example of a programming language that sits on top of a northbound API is Frenetic, which is a SQL-like query language
  
  • For example, it can allow a programmer to count the number of bytes grouped by destination MAC address and report the updates to these counters every 60 seconds (see example below)
  • WHERE allows restrictions to only count certain traffic (from a server, coming in on a particular port)
  • More info at frenetic-lang.org
  • We’ll be using Pyretic which is based on the same underlying theory as Frenetic except that it’s embedded in Python

Question 30

Composition operators

Answer 30

Ways that specify how individual modules can be combined or composed into a single coherent application

This helps prevent the issues of overlapping network policies: issue with programming at higher level of abstraction – an operator might write multiple modules, each of which affects the same traffic (e.g., one module for each of the green topics in the slide below)

Question 31

Composing Network Policies with Pyretic

Answer 31

• One way of composing policies is to perform both operations simultaneously/in parallel.
  
  • For example: counting and forwarding traffic at the same time.
• Another way is in sequence (perform one operation, then the next, etc.)
  
  • For example: perform firewall, and whatever traffic makes it through the firewall then is subjected to the switching policy

Question 32

What’s an example of sequential composition

Answer 32

Load balancer

    * Re-route half the traffic to one server replica, and the other half of the traffic to another replica
    * Then, need a routing module to forward the traffic out the appropriate port on the switch
    * Sequentially apply a routing policy that forwards the traffic out the appropriate port depending on the resulting destination IP address after the rewrite has taken place
    * Notice we can use predicates to specify which traffic traverses which modules. They can apply specific actions based on things like the input port and packet header fields.

* This leaves some flexibility so that one module can implement a small part of the network function, leaving functions for others. This also allows for modular re-use.

Question 33

Pyretic language

Answer 33

• Pyretic is an SDN language and runtime that implements some of the composition operators that we discussed in the last lesson.
  
  • Language: a way of expressing these policies
  • Runtime: provides the function of compiling these policies to the Openflow rules that eventually are installed on the switches

Question 34

What is a key abstraction in Pyretic?

Answer 34

The notion of “located” packets

    * Idea that we can apply a policy based on a packet and its location in the network (i.e. the switch at which the packet is located, or the port on which it arrives)

Question 35

Features offered by Pyretic

Answer 35

• Network policy as a function: Ability to take packet as input and return packets at different locations in the network.
  * Contrasts with OpenFlow style, where policies are simply bit patterns (match statements), which are difficult to reason about. In contrast, Pyretic policies are functions that map packets to other packets. Some example functions in Pyretic include:
  * Identity: returns original packet
  * none or drop: returns the empty set
  * match(f=v): returns identity if the field f matches the value v, and returns none/drop otherwise
  * mod(f=v) returns the same packet with the field f set to v
  * fwd(a): simply syntactic sugar on mod, allows output port yielding the packet should be modified to the parameter specified
  * flood(): returns 1 packet for each port on the network spanning tree
  * In OpenFlow, packets either match on a rule or simply fall through to the next rule, so OR, NOT, etc. are tough to reason about
  * Pyretic also offers the notion of virtual packet header fields, which is a unified way of representing metadata.
  * In Pyretic, a packet is nothing more than a dictionary that maps a field name (such as destination IP address) to a value. They can correspond to fields in an actual packet header, and they can also be virtual.
• Boolean predicates: unlike OpenFlow rules which do not permit simple conjunctions such as and/or or negations like NOT, Pyretic allows the expressions of policies interns of these predicates
• Notion of virtual packet header fields: allows programmer to refer to packet locations and tag packets so that specific functions can be applied at different portions of the program.
• Composition operators such as parallel land sequential composition
• Traffic monitoring functionality as a policy.
• Dynmic Policies
• Topology Abstraction - apply policy functions to an abstract view of the underlying network.

Question 36

Pyretic enables _____ and _____ composition

Answer 36

Parallel and sequential

Question 37

How do you express sequential composition in Pyretic?

Answer 37

> >

Question 38

How do you express parallel composition in Pyretic?

Answer 38

+

Question 39

Pyretic callbacks

Answer 39

Functions that are registered on packet streams. They are are invoked to handle each new packet that arrives for that query

Question 40

What are dynamic policies in Pyretic?

Answer 40

• Dynamic Policies are policies whose forwarding behavior can change
• Represented as a time series of static policies
  
  • Current value of the policy at any time is self.policy

Question 41

Common programming idiom in Pyretic is to

Answer 41

1. Set a default policy

2. Register a callback that updates that policy

Question 42

What 4 capabilities does Pyretic allow?

Answer 42

• Network policy as a function
• Predicates on packets
• Virtual packet headers
• Policy composition
• Topology abstraction

Question 43

What is the appropriate Pyretic rule for sending traffic form source IP address 10.0.0.1 to destination IP address 10.1.2.3 and traffic from source IP address 10.0.0.2 to destination IP address 10.2.3.4?

Answer 43

(match(srcip=10.0.0.1)&raquo_space; mod(dstip=10.1.2.3)) + (match(srcip=10.0.0.2)&raquo_space; mod(dstip=10.2.3.4))

Question 44

Flow switching behavior

Answer 44

• OpenFlow makes modifying forwarding behavior easy because forwarding decisions are based on matches on the OpenFlow 10-tuple
  * If all of the fields are specified for forwarding out of a particular output port, then we have flow switching behavior
  * If all of the flow specifications are wild carded except for, say, the source MAC address, then we have a firewall.

Question 45

What is the basic abstraction that NOX supports?

Answer 45

Switch control

    * OpenFlow is the prevailing protocol. Control is defined at the granularity of flows, specified in a 10-tuple. Flow = {srcport = “”, dstport = “”, etc….}
    * Flow is defined by header (10-tuple), counter, and actions to be performed (forwarding, dropping, sending to controller, etc.)
        * Counter = # packets that belong to that flow
        * Controller can process different types of events
    * CPQD supports OF 1.1-1.3. NOX supports 1.0