The Fundamentals Of SDN

There are five fundamental traits involved when we look at SDN these consist of plane separation, a simplified device, a centralized controller, network automation and vitalization. These five traits are the fundamentals that SDN is built on.  It is important to fully understand the concept behind these five traits as this will allow us to fully understand the technology itself. If we look at the concept of plane separation first as this is one of the driving factors within SDN this refers to the separating of the forwarding and control planes. The role of the forwarding plane is to forward, drop, consume or replicate an incoming packet. This is done by referencing the address table in the hardware and sending the packet out the correct port. In cases where the packet does not meet a certain criteria as specified by Quality of Service (QoS) filtering or from a buffer overflow condition the packet is dropped.

This rule changes in the event that the hardware receives a multicast packet in this instance the packet must be replicated and then forwarded out different ports. The protocols logic and algorithms for making these decisions that are required to program the forwarding plane are stored in the control plane. The majority of these protocols require a global knowledge of the network that they are operational on. The control plane is responsible for determining how the forwarding table and logic in the data plane are to be programmed or configured.

In tradition networks every device would have its own control plane that would look after the primary functions of running routing and switching protocols so that all distributed forwarding tables on the devices within a network would stay synchronized. The reason for this was to avoid the creation of loops in a network. If we look at the SDN model we can see that the control plane is moved away from the switching device and is relocated to a centralized controller. By doing this we are simplifying devices allowing them to be run by a centralized management system i.e the controller where all of the management and control software is situated. This allows the controller to use high-level policies to govern the network the controller sends primitive instructions to the now simplified devices allowing them to make fast decisions on incoming packets where it is appropriate to do so.

If we consider the centralized software-based controller in SDN in terms of network automation and virtualization and look deeper at this concept we can see that SDN provides an open interface on the controller to allow for automated control of the network. The terms northbound and southbound are often used to describe this automation by distinguishing if the interface is been used to connect applications or devices on the network. To distinguish between the two interfaces the southbound API is used by the controller to program network devices and the northbound API is used by the controller to allow software plug-ins that provide the protocols necessary for the network to run efficiently. This allows the network to react quickly and dynamically to changes in the network and call on different applications depending on what is required like reacting to a network attack in real-time to prevent services been disrupted. One of the key elements of the northbound API is that it allows the software above it to operate without any knowledge of the individual traits of the network devices themselves. This is key to allowing applications to be developed that can work over multiple different vendors hardware even if the specification of the devices differ in their implementation details. This is all aided by the open approach taken with SDN to ensure that applications and protocols are not vendor specific and can run on multiple devices across a network infrastructure.

Now that we have analyzed the makeup of SDN we can break its operation into 3 blocks the centralized controller the SDN devices and the applications. To fully understand this we can break it down further to state that the SDN devices are responsible for forwarding functionality and are responsible for what to do with incoming packets. The SDN devices contain data that indicates the actions to be taken in making these forwarding decisions. The controller has predefined these decisions by associating the data with flows and passing this information onto the devices. This simplified nature allows for quick detection of unusual data patterns if the device does not recognize a flow it sends the packets to the controller for closer inspection, this allows the controller to take a granular look at the packets and determine in real-time if they are malicious or not before directing the device on what action to take or implementing a defense strategic that is programmed to deal with the attack on hand.

The Evolution of Networking a Brief History

In the early days of computing the idea of computer networking did not exist computers or mainframes as they were known were large structures that took up entire floors of buildings. To transfer any data from these mammoth machines you would need to use a physical media such as magnetic tapes. As mainframes started to evolve they needed new ways in which they could move data these new mediums presented themselves in the form of remote terminal controllers or card readers that operated as subservient devices known as peripherals directly controlled by the mainframe. The first network connections that started to emerge at this point in time were very simple point to point or point to multipoint links. This limited the communications on a network to a small chain of physically connected devices where the mainframe controlled what communications were sent.

Over time these mainframe systems got smaller and more like the computer systems we are all familiar with so as the technologies evolved a new way to connect all of these separate systems to share communications without a mainframe arose. This need for a new method of communication brought about the emergence of the local area network (LAN) and along with it new technologies arrived such as IEEE 802.3 and IEEE 802.5.

The LAN was a shared media network and did not scale well so the solution that was devised to solve this issue was the emergence of bridged networks. The idea of a bridged network was to split the shared media network into separate segments to allow for better aggregation of bandwidth as now not all of the devices would be transmitting at the same time. The bridged network concept was later replaced by switches that allowed for many more improvements such as VLAN implementation and the spanning tree protocol that eliminated loops in a network just to mention a few.     

  

The final layer of communication that was added to these networks was routing, many different routing protocols were developed to allow networks to route traffic outside of a LAN and across the internet. As switches and routers developed so did the programmability of this hardware to deliver more secure and faster communications. If you refer to Fig 01.1 below it illustrates how software starts to play a role as the hardware becomes more efficient as it evolves over the years.

Fig 01.1

Before the emergence of Open Flow the protocol at the heart of SDN researchers were examining new ways to evolve the networks of the future. The earliest work recorded at programmable networks did not involve internet routers or switches but in fact surrounded ATM switches. Fig 01.2 below denotes the earliest technologies in existence that eventually led to the birth of Open Flow the protocol and the emergence of SDN.

Project	Description
Open signaling	Separating the forwarding and control planes in ATM switching (1999)
Active networking	Separating control and programmable switches (late 1990s)
DCAN	Separating the forwarding and control planes in ATM switching (1997)
IP switching	Controlling layer two switches as a layer three routing fabric (late 1990s)
MPLS	Separating control software, establishing semi-static forwarding paths for flows in traditional routers (late 1990’s)
RADIUS, COPS	Using admission control to dynamically provision policy (2010)
Orchestration	Using SNMP and CLI to help automate configuration of networking equipment (2008)
Virtualization Manager	Using plug-ins to perform network reconfiguration to support server virtualization (2011)
ForCES	Separating the forwarding and control planes (2003)
4D	Locating control plane intelligence in a centralized system(2005)
Ethane	Achieving complete enterprise and network access and control using separate forwarding and control planes and utilizing a centralized controller (2007)

Fig 01.2

The two technologies to take note of from Fig 01.2 are Devolved Control of ATM Networks (DCAN) and Open Signaling. As you can see from the above description DCAN and Open Signaling both separated the forwarding and control planes in ATM switches and gave the control to an external device very similar to the controller function in SDN networks. This technology never fully gained the trust of IT Administrators and as a result never became a mainstream technology.  The rest of the technologies in Fig 01.2 all played a part in the steps required to get to where we are today with SDN.  It wasn’t however until the arrival of Open Flow that SDN was actually born the year was 2008 and researchers along with vendors had started to play with the idea of Open Flow. Open Flow was designed to allow researchers to experiment and innovate with protocols in everyday network. This concept was to become a defining change how the industry approached networking. It wasn’t until 2011 that SDN actually started to make an impact on the networking industry as many big named vendors such as Cisco started to implement the Open Flow specification into their products. The Open Flow specification indicates the protocol to be used between the SDN controller and the switch it also specifies the behavior that is expected from the switch.

If we look at this specification in more detail we can break it down into a number of bullet points the basic operation of an Open Flow solution is.

·         The controller populates the flow table entries on the switches

·         The switch examines incoming packets when it identifies a matching flow it carries out the action associated with the flow

·         If the switch cannot find a matching flow it forwards the packet to the controller and waits for further instructions on how to deal with the packet

·         The controller will update the switch with new flow entries as new patterns are identified this allows the switch to deal with these packets locally.

The best resource for information on the Open Flow standard is the Open Networking Foundation (ONF) established in 2011 by Deutsche Telekom, Facebook, Google, Microsoft, Version and Yahoo. One of the most powerful aspects of Open Flow is the fact that it is open meaning researchers can contribute to new methods of network management, operation and control unlike the closed shop model of networking that exists in today’s network’s and as a result has lead to stifled innovation.

One major advantage of having an open source platform for networking is security; it is widely known that open source software tends to be a lot more secure than off the shelf distributions. This is due to the fact that open source can be peer reviewed by anyone interested in the field leading to faster discovery and patching of security issues and weakness before a product is introduced to a working environment. This is the type of innovation that networking has been lacking but with the introduction of SDN this is all starting to change.