January 21, 2013

What is a Software Defined Network

Software Defined Networks (SDN) are gaining popularity for several reasons.  This post will outline the drivers for this evolution as well as important considerations that network administrators will be facing and the benefits of SDN that they stand to gain.

SDN technology is being promoted by some heavy hitters including Deutsche Telekom, Facebook, Google, Microsoft, Verizon, and Yahoo!  These cloud service companies are the founders of the Open Networking Foundation (ONF) which is the primary supporter of the SDN architecture.  Why is this consortium which has grown to 80+ companies pushing for the transformation to SDN?  For several reasons:

  • It is a collaboration technology where no single company is taking all the credit for development
  • It is open source
  • All major switch vendors are embracing it
  • It scales to meet the needs of larger IT infrastructures
  • It adds another security layer and institutes centralized network traffic control

SDN Architecture

To participate in a SDN, switches generally support some type of control protocol which is a technology used by the switches to communicate with a central controller to help determine how to handle certain flow types.  Seeing how the founders of ONF are all involved with cloud services, you can bet that scalability was of paramount importance in the architectural design.  Two years ago, Google was receiving 34,000 search requests per second. One control protocol document I read claimed that a single low end PC could process up to 10K flows per second.  One might guess that a high end computer could process several times more connection requests.

The 4 functions provided by the SDN Controller:

  1. The first packet(s) of a new flow are sent to a controller on a secure channel for decision making based on policies.
  2. The controller decides based on policies if the flow should be added or removed from the flow table in all the switches along the flow path. Because of policies, some flows (i.e. connection requests) could be dropped to the curb (e.g. DoS attacks, broadcast discovery traffic, etc). Example policies include:
    • Guests can communicate using HTTP but only via a web proxy.
    • VoIP phones are not allowed to communicate with laptops.
  3. Flows granted a connection are programmed into the switch fabric and forwarded at line rate.
  4. {optional} Support for traditional layer 2/3 forwarding logic for environments that are not ready to commit 100% to a SDN controller.  This function is probably going to play an important role in many implementations for reasons outlined below.

Lets digress a bit on the 1st function.  When a machine makes a request to communicate with a server on the network, the switch will decide whether to forward the request up to the controller for further instructions or based on the 4th function it will decide locally what to do with the traffic.

What is a Software Defined Network

Function 2: If the switch sends the request up to the controller, the controller will decide based on policies whether or not the connection request will be granted. It sort of reminds me of a traditional phone system or the LAN Emulation Server in Asynchronous Transfer Mode (ATM).

sdn control protocol

Function 3: If the controller granted the connection, it will setup the switches in the path.  See below:

sdn connection setup

Function 4: Based on locally implemented policies, the switch could decide to process a request locally and grant or not grant the flow request. Each switch in the path would have to make a forwarding decision locally unless (I’m assuming) the connection came in on a trunk interface.

Potential Connection Request Dilemma

An environment where the controller makes all flow forwarding decisions for dozens or hundreds of switches may not scale to meet the needs of an enterprise environment.  Enterasys believes that a typical data center with 1000 servers can sustain a new flow rate of 100k to 1M flows per second. Imagine a controller trying to setup this many flows per second across the entire network for dozens of switches.  The controller could be the source of a bottleneck even if multiple are deployed.  For this reason, the 4th option plays an important role as it allows the switch to make some forwarding decisions locally.   With the forwarding logic of the underlying network fabric changing, will the way we collect, monitor and analyze performance metrics change? Probably not.

NetFlow’s Role in SDN

NetFlow and IPFIX will continue to play an important role in SDNs because they provide accountability and network traffic visibility.  In most cases, SDN switches will continue to support SNMP as well as sflow, NetFlow or IPFIX technologies.  It is also possible to export details about the flows being granted by the controller which could provide additional benefits in network traffic monitoring routines.

SDN Evolution

Experts believe that the introduction of SDNs onto your network will occur at a pace similar to what many of us observed with Linux or even virtual servers.  Often these new technologies are deployed out of a business need. Ask yourself: is traditional networking not meeting the needs of your business applications? Most would say it is but, the keepers of some of the largest cloud services believe they have a need for SDNs today.

 

About The Contributor:
Mike PattersonCEO, Plixer

As one of the founders of the company, Michael has been involved in the development of Scrutinizer NetFlow and sFlow Analyzer as well as Flow Analytics at Plixer. He enjoys writing and blogging about all things NetFlow, IPFIX and sFlow related.

See My Other Posts