30 Implementing SDN
Prof. Bhushan Trivedi
Introduction
We looked at the need for SDN in the previous module and also described some other solutions attempted in past. We will see how data and control parts are separated, how forwarding devices are controlled by the controllers and how the conventional network is managed to communicate amongst them in this module.
Separating the controller
When the issue about multiple devices to be managed individually was highlighted by the administrators, some vendors started providing the management plane for managing their own devices. Now one can manage those devices in a far simpler way and even from remote places. Unfortunately, such solutions were confined to those vendor’s devices and so designed for the specific OS they run, the specific hardware they use and network applications that they run on top of their devices. A common network does not usually have devices from a single vendor. It is common to find routers from one company and IDS from some other company, some switches from one company and few others from some other company. Having separate solutions for each of these heterogeneous devices introduced many additional problems. Generally, one needs a uniform access control system for the entire bunch of devices of the network or balance load between multiple switches or routers from different vendors in a conventional network. Admins demand traffic being properly engineered through the entire network consisting of devices from multiple vendors. For example, consider Network A and Network B are connected with two different lines Line A and Line B. Also consider both lines have different vendor’s routers connected to them. If the administrators want the traffic between Network A and Network B to be balanced, they might need to inform routers along line A and Line B accordingly. It is not possible to do this using a consistent interface as both types of routers usually have different interfaces provided by their vendors. It is also important that such load balance is to be an automated process and to be done continuously. Unless there is a consistent and common interface to both different types of switches and such a solution is programmable, it is not possible to load balance automatically.
In the conventional network design, due to its inherent complexity, many other network elements need to be introduced, for example, middleboxes like network and personal firewalls, IDS (Intrusion Detection Systems), Deep packet inspection (which also looks at the data and not only header of a packet) used primarily for security assessment. Such devices added substantial complexity to the network design. As per one report, such middleboxes are on par with a number of the routers and switches in most networks. The biggest issue is the placement of these devices. If one does not place them strategically to right places in the network, they cannot monitor complete traffic they are supposed to monitor. Moreover, more than one devices are needed to find out the complete picture. For example, generally, IDS sensors are placed before and after firewall to determine total attacks tried vs. total attacks go through the firewall. Such multiple devices and their interaction make the scenario complex and inflexible.
Once we have looked at the problems, let us see how SDN aims to handle them.
SDN is designed to separate data and control planes. Once these two components are separated, the control plane is removed from the switches. Thus the switches are reduced to forwarding devices. The control plane, now, is located at a central place, known as a controller, under the control of the administrator or the user. Thus it breaks the vertical integration. There may be more than one controllers in a network, each of them managing some part of the network; i.e. controlling a typical set of network devices. The idea is to disintegrate the controlling logic from the switch and keep it where administrators can use it to control switches from a remote place. Another point, the control plane, when was part of the switch, was a proprietary solution. Different makes of switch need different lower-level commands to control them. Once the control plane is moved out, it is operated in a vendor-neutral manner and use general commands which can be mapped to device from any vendor (which should be compatible with the SDN technology being used). That is why it is now called OPEN.
The controller is where the policy enforcement, network reconfiguration, and evolution logic is employed. The controller sends commands to switches (and other networking devices) accordingly to which those devices function.
Moving the controller away from the switch has an interesting consequence. Earlier, the control plane could talk to data plane of a switch without any problem as both were part of the same switch. Now, the controller has to communicate to switch via some networking path. The SDN designers have chosen that path to be the same network it manages. That means controller use the same networking cables and other switches to send messages to devices it controls. When somebody wants to program the controller to send commands to switches and receive messages, an API is a usually provided. The API helps a controller to send commands to switches in a vendor-neutral manner. The most noteworthy of such specification is OpenFlow which we will look at in Module 33. An OpenFlow Controller controls OpenFlow switches (that means set of switches which are compliant to OpenFlow specification). Basically, an OpenFlow switch contains tables for packet handling rules which are inserted by the controller. Once controllers insert all such rules, the switches can start forwarding packets. The rules help switches to match with incoming packets and decide whether to forward, drop or modify some part of the packet. Though most of the devices that controller manages are switches; other networking devices can also be controlled. For example, it is possible to control firewalls, proxy servers, Intrusion detection systems etc. Interestingly, the controller can decide to deploy a typical set of rules over the device in such a way that it acts like a firewall, or a proxy server or a router or switch or dedicated to some other typical network function. Such functions can include load balancing, traffic shaping (which buffers the incoming burst and smoothens the outgoing line traffic to a steady value), Network address translation etc. That means we can have a generic device which can function as the firewall at one point of time and load balancer at the other point of time, based on what types of rules controller provide for it to make decisions.
Separating control from the data plane allows a lot of flexibility. It simplifies the network management process as now the management is centralized and programmable using higher level languages. It also facilitates easier network evolution and innovation as adding new switches or devices or reconfiguring them is a single click job1.
The idea is to allow the user to program the network as per his need and scale and configure the network to leverage maximum out of it.
SDN can also be deployed in two different ways. First is to provide an overlay network over the existing network which allows administrators to command the overlay network which in turn convert those commands into existing network commands. This approach is used when the legacy network infrastructure is not possible to change. The SDN, in this case, provide an additional layer on top of the networks to be controlled as a kind of overlay network. Another approach is to provide SDN solution from the scratch. Many vendors like Juniper and Cisco are providing their SDN solutions to customers. Here the networking devices are SDN-compliant and provide SDN functionality from the word go. In this case, the customers buy controllers and forwarding devices which are connected and work as SDN without needing any overlays. The advantages that SDN offers lure many customers to go for ‘SDN from the scratch’ approach.
Let us learn about control and data planes little more.
The control plane accepts commands from people who manage networks. For example, a router allows the administrator to set the routing algorithms to use, set specific routes, allow troubleshooting, set filtering rules etc. A firewall allows the administrators adding, removing and changing rules for filtering incoming and outgoing packets on the basis of IP address and port number values. Intrusion detection systems allow the administrators to describe signatures for malicious packets, or describe the nature of malicious packets.
1 Google, after deploying SDN for its data centers across the globe recently, claims that they have improved their operational efficiency and reduced cost significantly. For larger networks, when administrators can manage networks from a single place and as per the management policies, such advantages are expected.
Setting these values or configuring such devices is, once in a while job but critical for the management. Such setting reflects the organization policies on routing, forwarding, dropping and inspecting packets.
The data pane is the processing the packets itself (based on those set policies). Once the configuration is done, the processing of each packet is to be done as per the set configuration. For example, the routers start forwarding packets according to the routing table and firewall starts blocking and allowing packets based on rules and so on. The second part, unlike the first part, happens for every packet, and require less intelligence but need to work at high speed.
The data plane needs a high bandwidth data path as compared to control plane as it has to cater to packets in real time. The data path should be at least as big as the bandwidth of the incoming line. On the contrary, the control path is usually of much lesser bandwidth as it is not used in real time.
Apart from data and control planes, we also know that there is a third part called management plane which allows vendors to configure the controllers for use. For example, a VLAN switch controller is informed about which are the VLANs available and which port is associated with which network or node. The controller might instruct forwarding devices (switches) to forward traffic accordingly. The switches then follow those rules for forwarding all the incoming packets.
The difference between management plane and control plane is worth noticing. The management plane allows administrators to interact with the controller, i.e. the admin configures the control plane using the management plane. Once configured, the control plane controls the forwarding devices automatically as per that configuration. The control plane, situated in the controller, is for controlling forwarding devices in an automated manner. For example, an admin uses management plane to fill the table containing signatures for malicious programs and instruct the control plane to use that database for intrusion detection. The control plane, then onwards, use that database and set of instruction signatures (usually in form of some rules using a typical syntax) to generate the logic for testing if the incoming packet is malicious. The data plane implements that logic and actually test the incoming packets. For a router, the management plane describes administrator interface to insert set of policies, the control plane converts those policies to rules that are to be used by data plane for forwarding packets. The data plane process each packet based on those rules and decide whether to forward, drop or change the contents of the packet. Another example, from management plane, the admin defines a rule that after 1Gb volume of data consumed, a typical connection should be degraded to 2G from 4G. Once that is done, the control plane keeps track of the volume consumed and whenever it crosses 1Gb, instructs the forwarding plane to use another (slower) route for packets traveling over that connection. All switches along the path obey that verdict and act accordingly.
The management plane also exists there in the conventional switch. The problem is the management plane which vendor provides, suffice only his requirements. The vendor has no idea about the organizational policies and thus he won’t provide any interface for that job. The need is to have an additional interface which can provide a customized interface for the organization. There are a few ways this can be done. One is to invite the vendor to provide an OPEN interface which the administrators of the organization can configure. That is the best solution but the existing devices are to be thrown away and entirely new setup is to be produced. Most of the current solutions are actually working in that direction.
Most vendors have started providing their own SDN solutions where the vendor specific legacy management plane is replaced by vendor-neutral, open management plane. Many organizations are developing SDN-based new networks in this fashion and most vendors provide an option of SDN from scratch. In this architecture, vendors provide a controller with an open interface for the management plane at the top and open interface at the bottom for forwarding devices. The open interfaces allow controller from any vendor and forwarding devices from any vendor, managed by a standard interface. A programmer can use that interface (API) to write network applications for network functions like firewall, routing, intrusion detection etc. That application talks to the controller (or control plane) using the API. The controller uses another API to communicate the same to forwarding devices and middleboxes.
Sometimes the administrators prefer to reconfigure existing switches to be used in SDN. In this method, the existing vendor management plane is removed but control plane is not. The control plane is now managed by an additional management plane. This solution is preferred when administrators want to leverage the existing infrastructure and also like to have the benefits of having an additional control. It is important to understand that this system uses the vendor’s original control plane for managing the device but does not use the vendor’s interface or management plane. It uses a new interface which allows the administrator to control the device exactly as vendors could do, by manipulating the vendor’s control plane, plus able to control device as per their own need, using the new plane that they have added themselves. Figure 32.1 depicts the conventional switch architecture. Network admin, sitting at the switch, use management plane to configure the control plane of the switch. This management plane is based on the vendor specified interface and thus proprietary.
In this hybrid approach, the network device has an additional handle for control. We can easily conclude that having an additional control is not enough if you had closely observed the problem that we are trying to address. With this additional control provided with the individual devices, the problem still remains. Each device is to be managed individually and separately. A better way to do so is to combine all these additional control planes together as a single, central plane. Thus, the administrator can now control each network device, based on the policies, from a single place; the central controller. It is also important to note that not all devices are from the same vendor and even devices from the same vendor does not work the same. When the administrator wants to control them from a remote place, they expect consistent interface. Figure 32.2 depicts the changed architecture. The proprietary management plane, which was local, is replaced by a remote client (called controller) which operates through the network.
This process is similar to having IO devices of varieties of types interacting with different OS. The problem is resolved by providing device drivers. Each device comes with a typical device driver for a typical OS. When that device is to be used by a particular OS, a typical device driver for that OS is installed. For example, when a hard disk is to be used on Windows platform, it needs a Windows device driver to be installed and when the same hard disk is to be installed on Linux, a Linux device driver is installed. The job of the device driver is to convert the OS commands into device specific commands and device’s typical responses to ones which the OS can understand. For example, if when the Windows user issues a dir command, the file allocation table of the device is fetched and responded back. A similar operation is done when ls command is issued by an Ubuntu OS user. In that case, the directory of the specific file system is returned back. The Operating system has a consistent interface which is converted by device drivers into a native interface of the specific device from a specific vendor. The device drivers provide a communication link between a device and an OS. Hard disks from various manufacturers work with their native commands but the device drivers make them work with any operating system and their specific commands.
A similar trick is employed here. There is a small network device driver installed at the network device which can interpret generic command issued by a central control plane and map that to vendor specific command. Thus it is possible for a single central control plane to control multiple heterogeneous network devices. The device drivers connect to hardware while the network device driver connects to the control plane of the device for specific operation.
One more thing is to be noticed, the original vendor management plane is of no use now, we will not use that proprietary interface to communicate to and control that network device, however, the control plane is still useful as it was.
One more clarification is needed. When the SDN approach is used from scratch, the control part which resides on the forwarding device is minimal. It only contains that hardware specific control information and the device driver. The rest of the control plane is moved out of the device to an external controller.
Whichever approach is chosen, keeping controller plane outside the switch, or at least the management plane is a major idea. Whenever we have an external management plane where the control plane physically located in the device still but logically a separate module, we have an external logical controller.
Having an external controller has a few obvious advantages.
1. Now the network-wide policies can be deployed and individual devices are not required to be configured separately
2. Devices, if misconfigured, can be detected as we have network wide vision to the configuration. For example, if router-1 sends the packet to router-2 when destined for D, and router-2 sends it to router-3 and router-3 back to router-1, a network-wide view can easily capture this cycle and report back.
3. Administrators can express their policies by providing generic commands based on policies and do not require to learn typical vendor specific commands for those devices. The management plane of SDN is programmable and thus high-level languages can be used to program such applications.
4. The switch only needs to have forwarding logic and thus become lightweight and cheaper.
5. Administrators have finer control over routing process. Vendor specific interfaces and control planes usually do not have such controls. In conventional routing process that part is managed by routing protocol implementations which, as we have seen, is purely based on routing table generation process and the destination IP address. Now administrators can provide their own routing rules which may be entirely different. They can and generally use packet classification hardware. They can attend each individual packet and decide how to forward it.
6. The control plane, is the most part, is moved out to an external controller and thus the vendor’s management plane, used to control the control plane of the device, is no longer used.
Before we embark on the SDN technical details, let us learn how the term SDN evolved over a period of time and what exactly it entails.
SDN for entire network
We have already stated the advantage of extending this external controller services to multiple networking devices. That will enable the controller to manage the devices of the complete network together and in a global fashion. The idea is to make sure the control plane to provide consistent control over an entire bunch of network devices running in the network. The management plane can be set of applications which work as per management policies and provide related commands to the control plane. The control plane, in turn, communicates with multiple network devices for decisions to be made about forwarding and other processing of packets.
Once we have controllers connected to all network devices, we can have that global view of the network and it becomes easy for the management applications to communicate with the complete network and deploy network-wide decisions. The process includes coordinating multiple devices running in the network to make sure they remain in sync and avoid problems like misconfigured routes and paths containing cycles.
Having a central controller for a single network leads to a single point of failure. If that single controller fails, the network comes to a grinding halt. Thus multiple controllers are used. The next issue is, how many we need and how they sync with other controllers. The synchronization between multiple controllers is critical as otherwise the very idea of SDN is defeated. The answers to both questions depend on the network and the type of SDN solution sought for. A single controller can usually handle multiple devices if the devices are of a simple type like modems and low-end switches or routers. If a network is small and devices to be controlled are a few only, a single controller may suffice. However, if the device is complex like an IDPS system (Intrusion Detection and Prevention System) or a UTM (unified threat management, a device which manages many security functions in a single box), where there are multiple layers of security are used (one popular device uses seven layers), Administrators have to manually look at and decide number of controllers needed for his network.
Synchronization between controllers can be achieved by providing a network-wide service using the management plane which communicates to them and provides synchronization. One may ask, why there is a need for the controllers to communicate with each other. Let us take an example. Suppose a Controller C1 is managing one part of the big network and C2 is managing the other part. There are multiple paths between both parts of the network and the administrators want to load balance. Thus the controllers need to make sure each path is utilized in a fair way. This is only possible if both controllers can communicate with each other. It is important to note that this management plane has an interface which allows the administrators to manage all these SDN controllers as a single unit. The same management plane allows controllers to pass information from one another. The admin machine is also part of the management plane so he can control the entire network sitting on his machine.
Thus we have an architecture where the management applications running on top, communicating to a management plane, management plane coordinating multiple SDN controllers and SDN controllers managing network devices. In fact, the network devices, in turn, work on top of data networks. For example, if we have two switches connected to a computer laboratory in our university, the switches cannot work in an isolated manner, they must make sure that the lab traffic is load balanced and optimized routing as per policy. If the switches are VLAN switches, that means they might connect to multiple virtual networks, they must coordinate for VLAN traffic forwarding. Such complex scenarios, where machines of a computer laboratory connected to (virtual) faculty network, (virtual) student network as well as (virtual) operator network, but physically connected to either of the switches, are hard to be managed by conventional solutions. SDN can easily manage such complexity as the controller does not look at physical proximity but logical grouping.
SDN with conventional setup
There are two possible ways to implement SDN like solutions. One way to make sure the SDN controllers and Management applications and network devices talk to each other using a separate and different network than one that they manage. Thus the original data networks are not used for communication between controllers and controllers to devices or management applications. The other approach is to use the same data network for this traffic. Both approaches are used in practice for different cases. For example, when storage networks are used, they prefer to have their own network. When different network for storage information transfer is chosen, it adds lots of complexities and thus is usually complex and expensive. On the contrary, systems like IDS sensors use the very data network for their data transfer. Using the same data network simplifies the operation and one can utilize the network in more optimized manner and that is the reason SDN also follows that approach. Thus, communication between controllers is carried out by the same data network they are controlling.
The SDN data, therefore, competes with the data network data (conventional packets carrying data) for transmission and thus needs to enhance the data network capacity for installation. However, this creates another problem. Let us try to understand.
Assume there is a switch S where a controller C is connected to. C sends commands for S and other switches in the network. What care should switch S should take? It must clearly know that the port on which C is connected is really a controller and not a normal desktop. Another point, it should only accept command from a genuine controller like C and not normal nodes. Second, and more important requirement, how commands from C reaches other switches? S may be connected to many nodes and a few switches depending on how the network topology is laid out. The commands from C should only reach to those switches and not to other nodes. There are a few ways to do so. One of the most common methods is to have a kind of overlay network of all switches and C is connected to that network logically. It can be deployed using IP level grouping (having a multicast group at network layer) which is preferred for heterogeneous types of members and members spread across multiple networks, or data link layer grouping (having a multicast group at data link layer) if all members are of the same type and belong to a single network. This is a critical step to be carried out before SDN controller starts working. If the grouping is not properly done, it is possible that a switch or two might not be able to receive commands from the controller. Look at figure 32.3. Switch S connects Controller C to switch O which it connects. The commands from C should reach O and no other switch. S should only relay the commands.
Evolution of SDN
The term SDN was coined in Stanford University while academicians researched about the problem and tried decoupling the control plane from the data plane for solving it. Later on, other dimensions added to the idea of SDN. The first idea was to enable forwarding devices to make their decisions based on flow or tags rather than IP addresses, quite identical to what we have looked at, in module 24 describing MPLS. The idea was to provide a similar type of service to all packets belong to the same flow.
Other devices, like firewalls and middleboxes, joined the movement soon after that. Actually, the idea of SDN was so generic that it can work with any of these devices and provide a consistent interface to control all of them. The users now able to configure devices remotely and create flow tables for switches. The switches are now possible to be managed remotely. The control logic is shifted to a controller now. Now administrator’s policy is used to generate flow tables which are followed by all devices irrespective of the make and type they belong to across entire network.
The next big thing added to SDN was programmability. This was considered to be the biggest plus for SDN. The applications which run on top of the controller enabled the administrator to control the routing, forwarding, and packet inspection process (managed by Firewalls) altogether from the single location. They can now design rules based on their convenience, freed from any layer, and implemented as flows. As we mentioned it before, this is known as per-flow control. Additionally, these policies and rules are based on global knowledge about entire network and not on local knowledge. This helps reduce errors like the wrong placement of IDS or routers which contain cycles or a path bypassing firewalls etc.
This central controller and flexibility-to-program provided many other advantages. We only need one interface for multiple devices, making it simpler to operate. The number of errors was also reduced. It had become easier to manage as one can use higher level languages for implementing policies instead of low-level commands.
To improve administrator’s convenience to manage networks, and concentrate on policies rather than their implementation, the approach is simplified by a number of services (sometimes known as abstractions). Let us study about them.
Abstractions for flexibility
A forwarding process should be able to indicate what is to be forwarded to where without really being aware of the underlying hardware. Once such a forwarding process is possible, a single forwarding process can work for multiple devices. This is known as forwarding abstraction. Thus when forwarding process is abstracted, users, with a simple and single interface, can manage a Cisco router or a Linksys router or whatever another router in the similar fashion.
Another process is to collect state related information from all connected devices and provide a global network view. The forwarding commands should be modeled into this process such that specific commands for a specific job are sent to respective devices. The idea is to have an abstraction which shields the distributed nature and provide a single global view. This is a critical service as otherwise, one needs to deploy systems like IDS at multiple places in the network to get a better idea of the network situation. This strategic placement of devices inhibits further changes in the network topology. SDN’s global view removes any such need for strategic placements of devices.
Third critical service is about asking what the application needs, without telling exactly how to do it for a specific device. The application can specify their requirements in the common terms which are implemented in the device as a specific command by this service. All applications also have complete information about the network in a global fashion and thus can initiate action from any part of the network. Such applications can also be sequenced properly, for example, a load balancer decides which switch should perform the operation and that switch, then, perform routing, as per the global policy set.
Summary
In this module we learned how the SDN is deployed in different planes, what is the role of each plane and how they interact with each other in an OPEN fashion to enable vendor neutral controlling. We have also looked at how conventional network or switch can be made to act in the SDN way. We have also looked at how SDN evolved over a period of time and how controllers communicate to the switches they control. We concluded the module by three abstractions provided by the SDN architecture.
| you can view video on Implementing SDN | |
References
1. Computer Networks by Bhushan Trivedi, Oxford University Press
2.Data Communication and Networking, Bhushan Trivedi, Oxford University Press
3.Internetworking with TCP/IP, Douglas Comer, Pearson
4.Software-Defined Networking: A Comprehensive Survey Diego Kreutz,Member,IEEE,