The com­pos­i­tion and ad­min­is­tra­tion of network struc­tures poses great chal­lenges to many companies. Since con­ven­tion­al networks based on physical hardware only rarely meet the re­quire­ments of modern companies, the choice of external In­fra­struc­ture-as-a-Service solutions (Iaas) is becoming more and more common. Compared to tra­di­tion­al in-house in­fra­struc­tures, these cloud services, which give customers access to vir­tu­al­ised computer resources, are char­ac­ter­ised by a high degree of flex­ib­il­ity and excellent cost control – unlike a fixed hardware framework, the desired resources can be scaled at any time at the push of a button.

Defin­i­tion

Software Defined Net­work­ing (SDN) is a network concept that enables the central, in­tel­li­gent man­age­ment and control of in­di­vidu­al hardware com­pon­ents using software. The use of open protocols such as OpenFlow allows access to network devices such as switches, routers or firewalls that would otherwise not be con­trol­lable due to pro­pri­et­ary firmware.

In most cases, the pro­vi­sion­ing and scaling of virtual resource – both on the part of the customer and on the part of the provider – is ac­com­plished with the help of software, without the need for manual access to the in­di­vidu­al physical network com­pon­ents. The un­der­ly­ing network concept is also known as Software Defined Net­work­ing (SDN).

What is Software Defined Net­work­ing (SDN)?

Software Defined Net­work­ing describes a network ar­chi­tec­ture that enables a purely software-based man­age­ment of the network. For this purpose, the control plane im­ple­men­ted as standard in the hardware com­pon­ents of the control logic is ab­strac­ted from the hardware – in this context, one also speaks of the in­tel­li­gence of the hardware, which is nothing more than its specific operating software (firmware). Put simply, the SDN concept stands for the sep­ar­a­tion of in­fra­struc­ture and its con­fig­ur­a­tion.

The data plane, on the other hand, remains part of the in­di­vidu­al network devices (i.e. all routers, switches, and firewalls in­teg­rated in the network). With SDN, however, its task is ex­clus­ively to forward packets, which is why it requires little computing power. Among other things, this has the advantage that the devices do not require any elab­or­ately developed firmware and are generally much cheaper than other network concepts.

The task field of the ab­strac­ted control plane, which is re­spons­ible for the proper data traffic in the SDN ar­chi­tec­ture and therefore has to carry out all relevant analyses, is con­sid­er­ably more complex. However, detached from the hardware and im­ple­men­ted in cent­ral­ised software, it is highly pro­gram­mable in software defined net­work­ing and therefore much more flexible in terms of network ad­min­is­tra­tion than is the case with other ar­chi­tec­tures.

How does SDN function?

A specific com­mu­nic­a­tion interface between control plane and data plane is required for the SDN software operating on the control layer to send in­struc­tions for proper packet traffic to the embedded network com­pon­ents. The best known solution for this is OpenFlow. Managed by the Open Net­work­ing Found­a­tion (ONF), the com­mu­nic­a­tion protocol is the first stand­ard­ised interface between the control and data levels of a software-defined net­work­ing ar­chi­tec­ture. In many SDN networks, it replaces the in­di­vidu­al in­ter­faces of the network devices, which also reduces the de­pend­ency on the hardware man­u­fac­tur­ers.

Note

OpenFlow is by far the most common, but by no means the only protocol for managing software defined networks: With NETCONF (RFC 6241), BGP (Border Gateway Protocol), XMPP (Ex­tens­ible Messaging and Presence Protocol), OVSDB (Open vSwitch Database Man­age­ment Protocol) and MPLS-TP (MPLS Transport Profile) there are al­tern­at­ives which do not replace the standard protocol one to one, but which can nev­er­the­less play a decisive role in the im­ple­ment­a­tion of software defined networks. Pro­pri­et­ary protocols from Cisco Systems and Nicira are also used in some ar­chi­tec­tures.

Once com­mu­nic­a­tion between hardware and software is es­tab­lished, the ad­min­is­trat­or can quickly and easily get a good overall view of the network via the control layer and the re­spect­ive SDN software, and manage the network devices through the central, software based control. This allows data streams to be managed with much greater ef­fi­ciency than in networks where the various com­pon­ents each have their own control logic – greatly sim­pli­fy­ing vir­tu­al­isa­tion and resource scalab­il­ity. This is also fa­cil­it­ated by the fact that routing and topology in­form­a­tion is no longer dis­trib­uted in fragments across all routers, but instead converges at a central location.

What SDN models are available?

The ideas and ap­proaches for im­ple­ment­ing SDN struc­tures vary depending on the provider or operator and com­mu­nic­a­tion standard used. However, it is not always possible to draw a sharp dividing line between the in­di­vidu­al models, so it could be that a software defined network has elements from different ap­proaches.

Sym­met­ric­al vs. Asym­met­ric­al SDN

Although the software-based principle basically provides the best possible cent­ral­isa­tion of network device in­tel­li­gence, there are SDN ap­proaches where the control plane’s scope is dis­trib­uted across multiple control units. With such an asym­met­ric­al model, the in­di­vidu­al systems typically have the minimal in­form­a­tion required for immediate operation, so that they will continue to function even if the central control unit fails. However, compared to the tra­di­tion­al sym­met­ric­al model, this also creates un­ne­ces­sary in­form­a­tion­al re­dund­an­cies.

  Basic principle Ad­vant­ages Dis­ad­vant­ages
Symmetric SDN approach Maximum cent­ral­isa­tion of in­tel­li­gence Avoidance of re­dund­an­cies; relief of the in­di­vidu­al com­pon­ents Avail­ab­il­ity and stability of the network stand and fall with the central control unit
Asym­met­ric SDN approach Dis­tri­bu­tion of in­tel­li­gence The in­di­vidu­al function even in the event of control logic failure Re­dund­an­cies of in­form­a­tion; man­age­ment of the network is more complex

Host-based vs. Network-based SDN

Another way to char­ac­ter­ise Software Defined Net­work­ing is to look at the position of the control logic. In highly vir­tu­al­ised en­vir­on­ments, for example, it makes sense to have the control plane processes handled by the system on which the hy­per­visor, i.e. the virtual machine manager, is hosted. If the SDN software is run on this host system, you can be sure that the necessary ca­pa­cit­ies are available for the resulting data load. The al­tern­at­ive to this host-based approach is to dis­trib­ute SDN pro­cessing to dedicated routers as is common in tra­di­tion­al networks and therefore handle it based in a network.

Flood-based (proactive) vs. floodless (reactive) SDN

A third software-defined network model focuses on the way in­form­a­tion is passed between the control plane and data plane. On the one hand, there is the option for the control instance to forward new in­form­a­tion and changes to all par­ti­cip­at­ing network nodes through broadcast or multicast. This so-called flood-based or proactive SDN concept is ad­vant­age­ous if the cent­ral­isa­tion of in­tel­li­gence does not play a role, e.g. because a sym­met­ric­al approach is used.

However, the more nodes a network has, the higher the network load will be with such a message trans­mis­sion concept, which results in limited scalab­il­ity. In larger networks, the floodless or reactive SDN model is therefore a popular al­tern­at­ive: In this case, the control plane ensures the correct func­tion­ing of all com­pon­ents by means of a con­trolled, reactive in­form­a­tion transfer in which only the affected devices are clamped. The relevant in­form­a­tion is usually obtained from special lookup tables, where dis­trib­uted hashtag and caching methods are used.

  Message trans­mis­sion Ad­vant­ages Dis­ad­vant­ages
flood-based SDN Broadcast, Multicast Easy to move; parcels are shipped the shortest way possible The network load auto­mat­ic­ally increases with each new node
floodless SDN Lookup tables All devices receive in­form­a­tion relevant only to them Problems with delivery of the in­form­a­tion auto­mat­ic­ally lead to delays

What dis­tin­guishes Software Defined Net­work­ing from the classic network concept?

In the previous sections, the basic dif­fer­ences between a network based on the SDN approach and a classic network have become clear. The crucial point here is un­doubtedly the sep­ar­a­tion of hardware and software, which was un­think­able years ago. Only since 2013 have there been devices that can implement this ele­ment­ary aspect of software defined net­work­ing. It is therefore hardly sur­pris­ing that future oriented tech­no­logy has not yet been an issue in many companies.

The following sections therefore summarise the main dif­fer­ence between SDN and tra­di­tion­al net­work­ing before con­clud­ing with the goals and benefits as well as the concrete ap­plic­a­tions scenarios of SDN.

The dif­fer­ences between SDN and tra­di­tion­al net­work­ing in a tabular overview

Software Defined Net­work­ing (SDN) Tra­di­tion­al Net­work­ing
Cent­ral­ized su­per­vis­ory authority Device-specific control instances
Celar sep­ar­a­tion between hardware and control level Control of the hardware is in­teg­rated in the hardware
Freely pro­gram­mable control plane Device-specific control plane
Stand­ard­ized protocols (e.g. via OpenFlow) Man­u­fac­turer-specific protocols
Software access to data layer possible Access to the data layer must be made directly on the hardware
Flexible, easily scalable ar­chi­tec­ture Static, difficult to adapt ar­chi­tec­ture

What are SDN’s goals and benefits?

Parallel to the demands placed on the computer’s computing power, the demands placed on the per­form­ance of networks are also con­tinu­ously in­creas­ing: While digital networks are becoming larger and more complex, the degree of vir­tu­al­isa­tion and the desire for maximum flex­ib­il­ity and scalab­il­ity are also in­creas­ing at the same time. Since con­ven­tion­al devices, which are equipped with their own in­tel­li­gence and process a large part of the processes in­de­pend­ently, have not been able to meet these demands for some time, the software-defined net­work­ing concept was developed. With specific hardware without its own control instance, these goals can be achieved and demands met. The ad­vant­ages over tra­di­tion­al networks can be sum­mar­ised as follows:

  • No con­fig­ur­a­tion of in­di­vidu­al devices or operating systems required
  • Low main­ten­ance and ad­min­is­tra­tion costs for the entire network
  • Lower hardware and operating costs
  • Enables dynamic al­loc­a­tion and mon­it­or­ing of resources in real time
  • Low de­pend­ence on hardware man­u­fac­tur­ers

Possible ap­plic­a­tion scenarios for Software Defined Net­work­ing

Thanks to its numerous ad­vant­ages over the classic network concept, SDN is in­ter­est­ing for a large number of ap­plic­a­tions. Among other things, the software-defined network model is suitable for the following purposes:

  • Quality of Service (QoS): The central overview of all network nodes makes it easier for the ad­min­is­trat­or to track how often a single con­nec­tion is used. The ad­min­is­trat­or can react in real time to the knowledge gained and regulate data traffic ac­cord­ingly in order to be able to deliver the promised bandwidth to all par­ti­cipants at all times.
  • Man­u­fac­turer-in­de­pend­ent device man­age­ment: The focus on a uniform protocol such as OpenFlow makes SDN an excellent solution when devices from different man­u­fac­tur­ers are to be combined and managed in a network.
  • Man­u­fac­turer-in­de­pend­ent func­tion­al expansion of the network: The freedom of SDN tech­no­logy is also a good solution for scenarios in which networks should be easily ex­pand­able with new functions at any time – and the in­de­pend­ence of device man­u­fac­tur­ers also plays into the cards of users.
  • Ap­plic­a­tion-driven packet routing: SDN creates the basis for third-party ap­plic­a­tions to intervene in packet routing, i.e. change and adjust routes in the network. The pre­requis­ite for this is that the control unit has a suitable interface.
  • Central defin­i­tion and dis­tri­bu­tion of security policies: Security policies can be passed on to the in­di­vidu­al network switches simply and ef­fi­ciently through the central control unit.
Note

Together with other software-defined services, vir­tu­al­ised network struc­tures are required, among other things, for setting up a Software Defined Data Centre (SDDC).

Con­clu­sion: Flexible network ar­chi­tec­tures thanks to software defined net­work­ing

It is no co­in­cid­ence that the SDN approach has been adopted by various network providers in recent years: Software defined net­work­ing optimises the basic approach of hardware vir­tu­al­iz­a­tion by removing man­u­fac­turer-specific re­stric­tions and con­sid­er­ably sim­pli­fy­ing the ad­min­is­tra­tion of a network. By de­coup­ling the logic from the un­der­ly­ing hardware and the as­so­ci­ated ability to control the network via software, network operators are well prepared for future de­vel­op­ments and chal­lenges in the IT industry.

Go to Main Menu