Software-Defined Networking

In the early 2000s, the networking community started to get interested in software-defined networking (SDN). While the idea of programmable networks was not new – indeed, a number of related ideas had been explored in previous work – the formulation of SDN was particularly simple and addressed several practical problems. So unlike some earlier efforts, SDN gained momentum was quickly adopted in industry.

At a technical level, SDN can be distilled into two key ideas:

  • Generalize network devices and allow them to be programmed using standard APIs (e.g., OpenFlow).

  • Relocate the control-plane onto a general-purpose machine called the controller, and allow each controller to manage multiple devices.

This is in contrast to conventional networks, where data planes implement fixed functionality and is tightly integrated with the distributed protocols executing on the control plane of each device.

As an example, suppose we wish to isolate authenticate and guest traffic in a campus or enterprise network. Even if we know which hosts are owned by each class of users, it would not be easy to modify a distance-vector protocol to enforce the desired isolation policy, especially under arbitrary topology changes and failure scenarios. In practice, operators typically rely on lower-level solutions such as Virtual Local-Area Networks (VLANs). But VLANs do not completely solve the problem either – e.g., the isolation they provide can be broken by devices such as hubs, which users sometimes attach to the network.

Software-Defined Networking

Now let us see how software-defined networking can simplify the specification and implementation of network-wide functionality, including basic forwarding as well as extensions with more sophsticated policies.

Model

For simplicity, assume that there is a single controller that maintains a graph that represents the network topology and the network-wide configuration is computed using a function that maps the graph into a packet-processing function for each switch (along with any mutable state maintained by the controller).

Of course, in any real-world SDN deployment, using a single controller would not be practical – it does not scale and it is a single point of failure. Instead, one typically uses several controllers which manage a subset of the switches and execute a simple distributed protocol to replicate the controller state. Since the number of controllers is small compared to the overall size of the network, it is reasonable to use protocols that provide strong guarantees such as Paxos, which would otherwise be prohibitively expensive.

More formally, if \(F\) is the function, \(G\) is the graph reprsenting the topology, \(S_i\) represents the packet-processing function on the \(i\)th switch, and \(\sigma\) and \(\sigma’\) represent the controller state:

The switch function \(S_i\) will be implemented using a match-action table, as we have seen in previous lectures. However, we will give switches a new primitive action, CONTROLLER, that redirects packets to the controller. We will also allow the controller to inject packets into the network.

To compute the topology graph, the controller can use a simple discovery protocol that keeps track of which switches are connected to the controller and which ports are up. It periodically injects special “probe” packets out each port that are redirected to the controller, enabling it to learn the links between switches.

OpenFlow

To make the basic SDN model more concrete, we now introduce OpenFlow, which was designed to be an abstraction that is both general, able to implement the functionality of switches, routers, firewalls, etc., and feasible, able to be realized on existing hardware platforms. These two objectives are obviously in tension, since existing platforms were designed to implement fixed-function behavior.

Match-Action Tables

OpenFlow models the capabilities of each device as a match-action table. At run-time, the table will contain a set of entries that describe how packets matching that entry should be processed. Each entry comprises:

  • A pattern that encodes a predicate on packet headers,
  • A list of actions that encodes a function on packet headers,
  • A priority that is used to disambiguate between rules with overlapping patterns, and
  • A set of counters that keep track of the total number and total size of packets processed using the entry.

The entries are supplied by the control plane, using a simple configuration protocol that will be described later. Since the only state maintained on an OpenFlow switch are the counters, a match-action table can be interpreted as a function from packets to packets, where a packet includes headers parsed from the bit representation of the packet as well as metadata such as the ingress port that the packet arrived on.

Patterns

OpenFlow allows patterns to be constructed from twelve different header fields, with various bit widths:

  • Ingress Port: target-specific width
  • Ethernet Destination: 48 bits
  • Ethernet Source: 48 bits
  • Ethernet Type: 16 bits
  • VLAN Id: 12 bits
  • VLAN Priority: 3 bits
  • IP Source: 32 bits
  • IP Destination: 32 bits
  • IP Protocol: 8 bits
  • IP Type of service: 6 bits
  • TCP Source Port: 16 bits
  • TCP Destination Port: 16 bits

A pattern may either specify a pattern for each of these headers or a special wildcard which indicates a don’t-care value. In addition, for IP addresses, the bit pattern can be interpreted as a longest prefix match.

If a table contains two entries with overlapping entries, which can happen due to the use of wildcards, the higher prority rule is used. However, exact-match rules – i.e., rules that specify the value of all headers – always take precedence over non-exact-match rules.

The behavior of a switch when a packet misses in the match-action table can be configured by the controller. Many OpenFlow switches send packets that miss to the controller for further processing. Another common choice is to drop such packets.

Many protocols have dependencies between headers – e.g., the VLAN Id and Priority fields only make sense if the Ethernet type is 0x810. If the dependencies for a given header are not satisfied, the value associated with that header is ignored in a pattern. This can lead to confusing errors in OpenFlow applications.

The headers listed above make sense for TCP/IP packets. But there are other protocols such as ARP, PING, UDP, etc. These are encoded into OpenFlow in various ways – e.g., if the packet has Ethernet type 0x806, the IP fields are repurposed to represent the ARP opcode, source, and target addresses.

Actions

OpenFlow provides a number of actions for manipulating packets, and each table entry can combine multiple actions in a list.

Forward

The FORWARD action which causes the packet to be forwarded out one or more of the ports on the switch. OpenFlow supports several different ports and psuedo-ports:

  • PHYSICAL: forwards out a physical port on the switch specified as an additional parameter
  • ALL: forwards out all ports, except the one the packet arrived on
  • CONTROLLER: forwards the packet to the controller
  • IN_PORT: forwards the packet out the ingress port

In addition, switches may support the following optional pseudo-ports:

  • FLOOD: forward to the ports on a pre-configured Ethernet spanning tree
  • NORMAL: forward using the “normal” legacy processing on the switch

Drop

The DROP action drops the packet, which ceases further processing.

Modify Field

OpenFlow provides actions for modifying many of the headers that can be specified in patterns:

  • Modify Ethernet Destination
  • Modify Ethernet Source
  • Set VLAN Id
  • Set VLAN Priority
  • Strip VLAN
  • Modify IPv4 Source
  • Modify IPv4 Destination
  • Modify IPv4 Type of service
  • Modify TCP Source
  • Modify TCP Destination

Note that some modifications may require changing the format of the packet – e.g., modifying the Ethernet type.

Enqueue

The ENQUEUE action allows packets to be enqueued on pre-confiured queues associated with each output port. This feature can be used to implement simple forms of Quality of Service (QoS), such as differentiated service.

Control Messages

To allow a controller to manage one or more switches, OpenFlow also provides an API for manipulating the state of a switch, including the match-action tables.

Flow Modification

The FLOW_MOD message can be used to change the contents of a table. It takes the operation to perform, as well as one or more arguments that depend on the operation.

  • ADD: add a new entry to a table
  • MODIFY: modify an existing entry
  • MODIFY_STRICT: modify an existing entry, matching patterns in strict fashion.
  • DELETE: delete an existing entry
  • DELETE_STRICT: delete an existing entry, matching patterns in strict fashion.

When the controller installs a rule using the ADD operation, it may specify a hard or idle timeout. The switch evicts the rule when the timeout expires. This feature can be used to simplify many OpenFlow controller applications, as we will see in the next lecture.

Barriers

Switches may reorder control messages, so OpenFlow provides a simple form of synchronization in barrier requests and replies. When it receives a request, a switch must process all pending messages before it may issue the reply.

Statistics

The controller can poll the values associated with each entry using a statistics requests message. The switch responds with the counters for all matching rules. Hence, the controller can request the counters for all rules by specifying the all-wildcard action.

Discussion

Implementing complex network applications using OpenFlow can be challenging. Following are several of the issues we will discuss over the next few lectures:

  • Proactive vs. reactive control: does the controller proactively install coare-grained rules that handle all packets? Or does it reactively install fine-grained rules as new flows are initiated?

  • Resources: how does the controller manage the limited resources available on switches, especially ternary content-addressable memories (TCAMs).

  • Latency: some applications require making frequent updates to switch tables, but implementing an update can take on the order of minutes on many switches, depending on the number of rules already installed in the table.

  • Advanced features: how can one implement functionality such as Ethernet learning or equal-cost multipath routing (ECMP) in OpenFlow?

  • Interoperability: how can OpenFlow switches interoperate with existing devices running conventional protocols?

Reading