- Parthenon Software Group
Computer networking is a valuable tool that has been used time and time again with all kinds of success. In a conventional setup, physical switches and routers are required along with configurations for each one. Such an arrangement can be quite complicated, thus a different approach was formed. Software-Defined Networking (SDN), seeks to simplify the process. What all does it encompass? Let’s pop the hood.
SDN is a networking technology that operates via management of network services through abstracted lower level functionality. Couple that with open standards and you’ve got the means to facilitate clear-cut design and operations. The process involves the separation of two key pieces of network architecture -the control plane and the data plane (also called the forwarding plane). It also makes use of application programmatic interfaces (APIs) through their incorporation into network equipment.
First of all, it's important to understand the role of the control plane and the forwarding plane. In a traditional setup, the control setup administers operations within a network and issues directions for what to do with network packets. The data plane is the means by which the network packets are moved.
In simplified terms, the decoupling of the control plane and data plane allows command and control to change hands from the switching/routing devices to a controller which handles and distributes control plane operations to data plane elements. This controller stems from control plane function that has been centralized so network operations can work with devices as a single entity. In other words, a central control console is formed and each individual configuration deemed unnecessary. In addition, control occurs in the form of global network abstraction rather than from individual devices. This controller also has knowledge of the network as a whole.
The separation of the planes may seem like it’s enough to take care of network issues, but honestly, if SDN were to focus solely on the decoupling, then it would be limited to reducing network latency. This is where APIs come in. The SDN controller provides a set of APIs for network equipment and from which applications can be written. As such, it supports network services and applications.
SDN is geared toward allowing developers to program the network/s by writing simple software. If that doesn't work, there are also vendor services (which may end up costing more). In order for things to work properly a protocol is needed to allow the controller full access. There are several mechanisms hat can function in this way. OpenFlow is the more commonly known, but command-line interfaces, Netconf, XMPP, SNMP and others can work just as well. The point is, there should be relative ease in creating new network management and control applications.
The benefits aren’t too shabby. Think flexibility, performance, agility, global connections and so on. Moreover, the idea is that operational costs will be reduced due to the different setup. There's even been talk about having the ability to purchase cheap IP switches so enterprises can focus the majority of their funds on software.
At the end of the day, the goal is to meet constantly business needs and objectives. With growing network demands, it’s becoming more difficult for current setups to handle the load. Not only is the aim of SDN to lighten this load, but also provide a range of benefits. That being said, a SDN approach is an undertaking. There are factors to consider before opting for a SDE route. They include things like purchasing decisions, budget, reporting structure, and performance metrics. It's also important to note that SDN isn’t alone in the software-defined field. With Software-defined data centers, software-defined storage and software-defined infrastructure coming up in recognition, there's little doubt that we'll be seeing more of the same kind of thing translated into different spheres of the business world.