The Control Plane (text)

by Sasha Shkrebets — last modified Mar 06, 2023 01:01 PM

We are now starting a new module where we will explore the nuts and bolts of the network control plane.

Welcome back.

We are now starting a new module where we will

explore the nuts and bolts of the network control plane.

This module has three lessons.

The first will be on basics of the control plane.

We'll talk about the details of OpenFlow version 1.0

as well as recent evolutions to the OpenFlow protocol.

Then we'll talk about examples of different SDN controllers.

And finally, we will explore how to

use SDN controllers to customize network control.

There will be a programming assignment and quiz based on the

assignment as well as a quiz on the concepts in this module.

Let's now jump in and explore some of the control plane basics.

Let's start with the basics of the OpenFlow protocol specification.

In a nutshell, OpenFlow separates the data and

control plane in the following way as we've discussed.

The controller speaks to the OpenFlow switch over a secure

channel and the protocol effectively instructs the OpenFlow

switch to update its flow table entries to take different

actions on various traffic flows that pass through the switch.

The purpose of the control channel is

effectively to update this flow table and all

of the logic concerning how the flow table

entries are updated are contained at the controller.

All of the smarts of the network are

resident at the controller and the switches job

is simply reduced to forwarding traffic based on

the flow table entries that the controller installs.

The OpenFlow protocol specification defines a number

of things including the complements of the switch,

the message format, and what types of actions

the flow table should be capable of performing.

Let's take a closer look at

certain aspects of the OpenFlow protocol specification.

The protocol specification defines two switch components.

The first is the flow table, the flow table performs packet look up.

The lookup function compares the fields in each packet to a

flow table that resides in the switch and looks for a match.

In other words, it looks to see whether or not the headers of the packets that are

passing through the switch match any of the entries in the switch's flow table.

The actions that the switch takes then depend on how or whether the packets

passing through that switch match any of those particular flow table entries.

If there is no match, the traffic is sent to the controller.

The other aspect of an SDN switch is the secure channel, which

is how the switch communicates with the external controller.

Let's take a quick look at how OpenFlow performs

matching using the flow table entries in a particular switch.

This particular flowchart, which is taken from the OpenFlow version 1.0

specification, specifies how a switch should process a packet as it arrives.

When a packet arrives at the switch, it parses the header fields, and

based on the values of those header fields, it will attempt to match that

packet against flow table entries in any one of several flow tables.

If there is no match in any of

those tables, the traffic is sent to the controller.

Otherwise, actions are performed based on the actions

that are specified in the matching flow table entries.

So to summarize, packet header fields are matched against one of the N

tables and if there's no match the packet is sent to the controller.

For scalability reasons, it does make sense to try to match as many packets in

the switch as possible to avoid having too much traffic diverted to the controller.

Let's take a closer look at the match

fields that are part of the OpenFlow 1.0 specification.

The specification defines a 12-tuple.

In other words, 12 different fields in a packet

header on which a flow table entry could match.

In addition to the ten that are shown

in this figure, there are also two extra ones.

Other fields that the switch can match on include the incoming

switchboard, the source and destination MAC address, the

ethernet type, the VLAN ID, the source and destination IP

address, the protocol type, for example, whether or not the

packet is a TCP or a UDP packet and if it's a TCP packet, the source and

destination port.

Once the switch identifies a matching flow table entry, it will perform

the action that is specified in that flow table entry.

Two mandatory actions in the OpenFlow protocol

specification are forwarding the packet and dropping it.

Now forwarding can include several possibilities.

One, is to forward the packet out all of the

interfaces not including the interface on which the packet arrived.

Another is to simply encapsulate the packet and send it to the controller.

Another option is to divert the packet to the switch's local networking stack.

Another is to simply just perform the actions in the flow table.

Finally, the switch could send the packet back out the input port.

The OpenFlow 1.0 specification also specifies some optional

actions such as forwarding the packet as the switch normally

would and forwarding the packet according to a spanning tree.

The other mandatory action is the drop action whereby a flow entry with no

specified action indicates that all matching packets

for that flow table entry should be dropped.

In addition, there are several optional

actions that the OpenFlow 1.0 specification describes.

One is the modify action whereby the switch might modify various packet

header values such as the VLAN ID or the destination IP address.

Modifying the destination IP address could be useful, for example, for performing

higher level operations such as wide area network load balancing.

Another optional action is to send the packet through

a queue that's attached to say an output port.

One possible use for this action would be

to apply quality of service or traffic shaping.

An OpenFlow switch by default listens on a control

port and even in the absence of a controller we can

talk to the switch using a program called dpctl.

The dpctl programs allows us to perform operations such as inspecting the flow

table entries on the switch, modifying flow table entries and so forth.

Let's take a quick look at dpctl in action using the topology that we've shown here.

We can tell mininet to start a single network with

three hosts all connected by a single switch where the

single switch is controlled by a remote controller as

can be seen here with the controller remote option.

We can now use dpctl to connect to the controller.

For example, we can use the show command

to tell us more information about the switch.

Now you'll note, if we try to ping between

two hosts in this topology, that there's no connectivity.

The reason for that is evidence if we

look at the flow table entries in the controller.

Let's have a quick look at that using the dump-flows command.

As we can see, the switch has no flow table entries and therefore it

does not know what to do with a ping packet that arrives from host one.

Let's try to fix this by adding a few flow table entries.

We can again use dpctl to add a flow table entry that says, if a packet

arrives on input port one, take the action of sending it out port two.

We need a similar flow table rule for the reverse direction that

says, if packets arrive on input port two, send them out port one.

We can dump the flows again, and now we see

two flow table entries that we just installed using dpctl.

We can now return to mininet, and we see

that host one is now able to ping host two.

More recent OpenFlow protocol specifications

such as version1.3 specify various enhancements.

One is the notion of an action set whereby

the switch might perform multiple actions on each packet.

Another is a notion of a group, which is essentially a list of action sets.

A group effectively allows the switch to refer to a common

set of actions that might be performed on multiple sets of matching flows.

In the OpenFlow 1.3 pipeline each table in the pipeline

can update packet header fields and potentially add to

the set of actions that will be performed on

the packet before it is sent on the output port.

There are various options for specifying actions in an action group.

One option is to execute all of the action sets in a particular group.

This option is useful for implementing multicast whereby one packet

might be cloned for each action set in the group.

Another example of a group option is something called an indirect

group whereby the one action set in the group is executed.

This might be useful for performing the

same set of operations on multiple flow entries.

For example, if a switch had multiple flow table entries

all of which were to be forwarded to the next top

IP address, indirect groups would allow the switch to point

all of those flow table entries to the same indirect group.

Various example actions include decrementing the TTL,

copying the TTL to various parts of a header, applying MPLS

tags to a packet, and applying quality of service actions.

There are many more details about the OpenFlow specifications in the OpenFlow

specification White Papers, which are available

on the Open Network Foundation webpage.

It is worthwhile noting that there are other SDN control architectures.

We have looked at several in the course already as far as history is concerned.

For example, the RCP is one example of an

SDN control architecture that is very specific to the border gateway protocol.

More recently, various vendors have been devising their own control architectures.

Juniper's Contrail Controller uses XMPP as the control plane and has mechanisms

for instantiating virtual networks at both layer two and layer three.

Much of the software for Juniper's Contrail Controller will be

contributed to the OpenDaylight community, which is a community devoted to

maintaining open source implementations of various SDN control architectures.

Another SDN control architecture is Cisco's

Open Network Environment, which specifies a centralized

software controller, a programmable data plane,

and the ability to provide virtual overlays.

In summary, in this lecture we've looked at various basics of the control plane.

We've explored the various components of an OpenFlow

switch including the secure channel, the flow tables, as

well as the newer group tables which are under

development as part of more modern OpenFlow protocol specifications.

It's worth noting that the OpenFlow protocol is evolving.

And in this course, when we get our

hands dirty with specific OpenFlow switches, and in particular

Open vSwitch, that particular switch implementation has not implemented

many of the options specified in later protocol specifications.

Most of what we will deal with in

this course relates to the OpenFlow version 1.0 specification.

We took a brief look at dpctl, which connects directly to a

switch and can be used to poll and manipulate flow table entries.

In the next lesson, we'll explore different SDN controllers

that can be used for more sophisticated network control logic.