This is a general image for a software defined network.

Monday Jan 14th 2013 by Paul Rubens

Software Defined Networking (SDN) promises to change the way data packets are switched to provide a more flexible and cheaper way to maintain and operate the network, whether on premises or in the cloud.

software defined networkIn an SDN (Software Defined Network), the switch's role is one of packet forwarding only. The controller plane is removed from the switch and placed in a (usually) centralized device known as an SDN controller. The controller makes the routing decisions and then communicates these decisions to all the devices on the network using a communication protocol - typically OpenFlow - that allows the controller to modify the behavior of the networking devices. Each switch uses a "flow table" to switch traffic flowing from one place to another. It is these flow tables, or updates to them, that the switches receive from the network controller.

A good analogy is a pilot flying a plane. If the pilot is flying by sight, then as well as being responsible for manipulating the controls to actually fly the plane, the pilot must also make decisions about which direction to go, and what actions to take to avoid other aircraft. This is like a conventional switch with a data plane and a control plane.

An alternative way of flying is for the pilot to maintain control of the aircraft, but to hand over responsibility for the precise path they should take to a centralized air traffic controller. The air traffic controller has an overall view of all the aircraft flying around, and can make decisions about the best routes for individual aircraft to take. The air traffic controller communicates those decisions to the individual aircraft by sending control messages, which are acted upon by the pilots.

Network controllers are available as commercial products from the likes of Nicira (now owned by VMware) and Big Switch Networks, and there are also many open source controllers such as Beacon, developed at Stanford University for academic purposes, and Floodlight, a more production-oriented project that was forked from Beacon. The Floodlight controller is the core controller at the heart of Big Switch's commercial Big Network Controller platform.

Floodlight is just one of a number of libraries that are bundled together to make a working Floodlight network controller. Others include Endpoint Manager -- which tracks physical hosts, VMs, and routers; Topology Manager -- which uses LLDP and multi-cast probes to infer topology; and Path Calculator -- which computes paths between devices.

In a network controlled by a Floodlight controller, when a packet leaves a server and hits an OpenFlow enabled switch -- a physical switch or perhaps a hypervisor based vSwitch if the packet comes from a virtual machine -- the packet header is forwarded over a control VLAN to the Floodlight controller. Floodlight then does a series of database lookups to find information about the source, destination, available physical paths and tunnels between the two, examines ACLs (access control lists) to check whether the packet should be dropped, and decides if any tunnel encapsulation or other rewrites are needed.

Once this has been done the controller sends flow table entries to every switch on the path from the source to the destination so that they know how to handle the packet when it comes in. From that point on, all subsequent matching packets flow at line rate through the switches -- without the need to consult the controller -- unless some change is made to the topology of the network, a port or switch fails, or the physical location of the source or destination servers changes. In that case the network controller automatically updates the flow tables in all effected switches. This automation is the basis of the flexibility found in SDN controllers when compared to traditional switching environments.

This type of packet flow is known as a reactive packet flow, but there's another possibility too - especially in smaller networks - called a proactive packet flow. In this case flow tables are created in advance and sent to switches. In simple terms they might dictate that Application X can talk to Application Y, and Application A can talk to Application B. That means that the first time a packet from Application X is sent to Application Y, the switches already know where to send it. Updates to these flow tables may still be made by the network controller from time to time as changes occur to the infrastructure.

The Floodlight controller is available under the Apache license and supports a range of OpenFlow virtual and physical switches, routers and access points that support OpenFlow.

Instructions for downloading, building and running Floodlight from source, and Floodlight virtual appliances, are available from here.

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved