29 Software Defined Networks (SDN)
Prof. Bhushan Trivedi
Introduction
We have hinted about SDNs when we looked at packet classification process in Module 5. The conventional process of network routing is already discussed in earlier modules. This module presents an alternative which is gaining popularity in the current era. The problem with current networking system and the conventional model of routing is; administrators do not have complete control over the process. They need to have typical security applied to the network under their control, for example, they need to have traffic originated by all accounts machines encrypted by 128 bit AES encryption and each communication related to banking must be logged, travel over some set of routers only. They also need a typical value based routing like separating 3G and 4G customer’s traffic for routing. They may need to provide a typical type of service for a typical set of customers, for example, some customers need strict filtering of packets while some other do not need them. They might need to dynamically provide resources to different customers based on the priorities set. For example, VOIP customers packet should be forwarded before a file download packet from another customer. When customer’s demand changes, it should be possible for the administrators to modify parameters for those networking services. For example, when the customer has consumed his quota of 3G services, now he should be provided a 2G service unless he pays for the 3G pack again. This type of control is not possible easily using conventional networking solutions. If the administrator wants to offload some work from one switch to another (known as load balancing) automatically over multiple paths, the conventional routing algorithms cannot do that. Current customers expect the network as a virtual product. They just want to connect to the Internet and demand a few switches and routers between other nodes of his own network connected over the Internet. The customer does not have any physical networking infrastructure in place, all nodes may not even be physically adjacent. All of them are just connected to the Internet. This kind of virtualized network only needs an internet connection for the customer using which all members become part of this ‘network’. The customer will be able to get ‘network on demand’ for his varying requirement from the cloud. He may demand a larger number of switches and higher end switches if his traffic increases and release them when the traffic reduces. This process is known as NFV or Network Function Virtualization. The onus is on the service provider for this NFV to work seamlessly for the customer. To enable such services, the service provider’s network administrator must have much better control over the networking infrastructure. SDN or software defined networking is an attempt to provide a solution for all these cases.
This problem is not new. Administrators have realized this and trying to solve it using many different ways so far. SDN is a better and more flexible version of all such attempts. It is important that we learn about those attempts before we embark on the SDN. We will begin with an idea called an overlay network. Here, an additional network abstraction is generated which covers one or more networks inside. It is kind of an additional layer (a kind of an application) which administrator interacts with. This application, in turn, deals with multiple networks below. Thus, the administrator deals with the overlay network while the overlay network itself controls the networks within. For example, assume there are 3 networks, network-1, network-2, and network-3. There are five different departments whose machines belong to all these networks, department-1 to department-5. Now, it is possible for the administrators to have five different overlay networks on top of three physical networks such that each overlay network connects all machines of a specific department. Each overlay network contains machines belong to that department. Those machines, regardless of their physical connection, act as if they are part of their departmental network, follow policies of that departmental network’s administrator and also receive broadcasts belong to their networks.
Another approach is to use a connection-oriented network instead of the connectionless network. The connection-oriented network allows a specific route for a given connection to be specified at the time of connection establishment process and thus forces all packets belonging to a specific connection to follow a specific path. Thus, the admins can design such networks in a way that they choose the route which administrators want them to travel on. When a company main branch wants to connect to other branches as if all of them are part of the same network, and communication between branches are routed through specific paths set by the administrator, connection-oriented networks can be handy.
Before we deal with SDNs, let us brief about these two approaches, routing overlays, and connection-oriented networks, in little more detail. We will later see how SDN is a better solution. For learning about routing overlays, we will have to learn a few more terms like Virtualization, Overlays, Virtual Private Networks etc. So we discuss them first. We will see why we need to route differently and then we will look at routing overlays and connection oriented networks. Here are common requirements of the modern day admin.
1. Packet classification is to be used but must have hardware implementation so that process happens faster and more complex and multiple forwarding rules, based on administrator’s wish and convenience, can be executed in real time.
2. Forwarding logic, for speed, may be embedded in hardware. The current routers cannot do so directly because they have to do both, routing and forwarding.
3. The solution is able to provide traffic engineering, thus network operators or administrators can choose the rules to route traffic based on their policies and not merely on the destination address
4. The solution should also be reliable; thus the operators can check if there is any problem with routing. Conventional routers and switches, when misconfigured, can lead to serious problems. Such problems are avoided in SDN. In fact, the reason is the lack of global view from individual routers. SDN is designed with that global view.
5. Thus they should have much finer control over routing; choosing every route for every packet, based on any item of the packet header or content they wish.
6. The solution should be scalable, that means, when the networks grow or shrink, the solution should be able to adjust accordingly.
7. The network control should be programmable. That means the administrators’ policies should be implemented as programs. There has to be an interface which can accept such programs and automate the implementation part of the policies. The programming is done in higher level languages instead of low-level vendor specific commands.
8. The control should be agile enough to dynamically adjust. That means network-wide policies can be implemented and changed with very few unambiguous steps.
9. The control is to be managed centrally. Network intelligence (how to route traffic, how to find a malicious process or a node, how to balance traffic etc.) is located in central part where the control is located. The idea is to use network intelligence to control network in a global and thus optimal way. When optimal routes based on specific quality is designed, for example, a common requirement is; there should not be any cycles in the route. The SDN solution will have data about all switches together located centrally and can see if there are cycles, immediately.
10. The network managers or administrators should be able to configure, manage, secure and optimize network resources in a programmable manner. Thus, once the policy is set and configured, it automatically decides what to do in a given situation. More importantly, it does not depend on the propitiatory solutions which differ with different vendors for those devices. The administrators can allocate and deallocate switches or firewalls or IDS (Intrusion Detection System which can help find intrusions or attacks in the system, while the system is running) as the need be.
11. The standards provided should be open and vendor neutral. That means the standards allow multiple devices to be controlled using a single, consistent interface. Being open, it is possible for anybody to manage.
The very idea of SDN begins with dividing the network device and eventually the network into different planes. Let us brief about that idea.
Shortcomings of traditional networking solution and need for SDN
The networks are managed by routers and switches forwarding packets across the network. These traditional networks are hard to be customized for higher level management policies. The higher level policies, for example, 2G traffic should be given lesser priority than 3G demand routers to have two queues, one of 2G and one for 3G packets and allow 3G packets to be processed in higher proportion with respect to 2G packets. One will have to configure each individual network device separately for deploying a typical policy. Thus each router and switch which may be from different vendors need to be configured accordingly. This configuration requires vendor specific and many times low-level commands to execute. For example, the way CISCO router needs to be programmed for this job may be very different than Linksys router. Traditional networks are less fault tolerant and lead to problems when the devices start malfunctioning. For example, when one port of a switch stops working, administrators will receive problems like a typical connection to a typical node not working and they will have to manually figure out what is wrong. After some investigation, when they find that a typical port is not working, they may have to route the traffic over another port manually. Administrators also have to load balance manually. For example, if there are multiple ports possible to be used to reach a given destination, administrators love to divide traffic over them in an even manner but that is hard to be automated in general case.
Two examples that we have seen before, using one of the multiple ports to load balance and fail over when a port is not working demands re-configuring the switch. There is no mechanism to re-configure the network switch automatically in conventional networks.
Achieving all of above goals need a better (and breakthrough) design. The idea is to identify the root cause of the problems and then eliminate that cause. Let us try to understand the problem first.
Network devices are designed to provide three primary functions. First, forwarding network traffic (the forwarding process) and how to treat different traffic differently (the logic for making the decisions about forwarding, usually done by routing and packet classification). The second function is implemented by protocols (routing protocols), which outputs the routing tables. These two functions are usually so tightly integrated that it is hard to separate them. One of the reasons for the transition from IPv4 to IPv6 took so long is due to the fact that these two different things are not separately modeled. Sometimes this tight coupling between these two components is called vertical integration. The third function is to participate in the network-wide management process. For example, when the administrator wants to configure switches to provide higher priority to one type of traffic in the entire network, he needs to provide that by (usually) configuring each switch manually in accordance with the need.
The component of the router which forwards the packets is known as a data plane while the component which decides the forwarding policy is known as a control plane. Devices working at the data plane are known as forwarding devices (but people still use word switch for them. The devices working at the control plane are known as the controllers. The interface to the controller is the management plane, which is important and is usually vendor-dependent and also adds to the problem. Many authors claim to have two planes, data, and control and describe management plane as the interface to control. Whatever architecture one chooses to describe the SDN, it is clear that data and control function needs to be separated. To implement network-wide functions (by instructing the control plane accordingly), one needs an open interface which networking applications should use. For example, if the administrator needs to provide all VOIP traffic of the network to be given highest precedence over all other traffic, the forwarding devices are to be instructed to do so by all controllers. How does the admin instruct the controller to do so? Using an open interface. Such an open interface is the management plane. It is OPEN because any type of controller will be able to be addressed using this plane.
In conventional network devices, both control and data planes are tightly integrated into the device and thus routing and forwarding process happens quickly, remain in sync and provide reasonably good performance. The router acts as a single unit for both operations. Not only that, the output of one unit is used by another unit. Such a design is better for managing issues related to faulty devices and faulty configurations of devices, as the fault is limited to the device. For example, if a router is not routing as per policy the problem is confined to that router and administrators can identify that router as a culprit and set it right easily. The routers only communicate their prescribed routing packets with other routers and if they are malfunctioning, their routing tables will be able to reveal their fault. This design worked well and thus in use so far. Also, when the network size, line speeds and density of devices increased, the designers need to increase the number of such devices. Each device has its own control and data plane and all devices have built-in intelligence for its work and thus self-contained, the networks grew without much of a trouble. However, this design is difficult to manage, especially when common management policies are to be implemented in heterogeneous devices, many times, from different vendors, which is now becoming a norm, across the entire network.
This tightly coupled architecture has one more problem. As network devices are to be manually and individually configured, and network administrators are heavily loaded, the “quick and dirty” ad hoc approach takes precedence over well planned, systematic approach. Such an approach resulted in many misconfigured devices in the networks. Forwarding loops (packets are roaming around in cycles in the network), sending data on wrong paths, violating SLA1s unintentionally, and even packet loss were results of such misconfigurations.
Virtualization and Overlay Networks
The idea of virtualization is to make sure the services provided to the upper layer in a transparent way, all underlying problems are handled by the layer which provides the service without passing the problems to the current layer. That means the problems faced while providing the service is not seen by the current layer which is taking that service. For example, TCP provides a reliable, circuit like, robust and fault tolerant service to the application. Virtual LANs are designed for the need of administrator to treat networks in a logical and not physical fashion. VPN (virtual private network, described later) solutions allow a customer to connect to a remote network as if he is physically part of that network and connecting locally to it. All problems are managed by the virtual network management system. Virtualization process began with storage and processor virtualization and has reached to providing virtual networks today. The details are not possible for us to explore in this course but reference-3 can throw some more light on the issue.
The overlay network is an extension of the virtualization idea2. The overlay network can have a remote member and provide a service to it as if it is a local member. A member may not always be a node, it can even be another network. That means an overlay network can provide service to the administrators of those networks and users of the underlying networks as if they are all connected to each other directly. The interconnection issues and other complexities are managed in a way that user does not realize that the network or the other node that he is communicating is not local.
Let us take an example to understand. Consider an education institute, having their central office situated in Ahmedabad and having other sister institutes in few other cities like Nadiad, Anand, Vadodara, and Mahesana, four cities in the close vicinity. The academic institute also has three campuses in Ahmedabad which run different courses. What are the needs of administrators and management of these institutes, located at the central office in Ahmedabad? Quite a few, but we will take two which help us understand the need for an overlay network.
First, they may want secure connections between these centers, even from other cities and within Ahmedabad. A question paper or mark sheet sent should not be seen by any third party. Examination orders and many other exams related information also should be kept and transmitted in a secret fashion. Also, accountants at these centers should communicate
1 The SLA or Service Level Agreements are between different ISPs indicating how and what is the amount of traffic is routed.
2 But it is not a true virtual network to the central office where chief accounts officer seats, in a way that others cannot poke into their communication, not even users of the network they belong to. In a way, these computers used by accountants should be separated from their own networks but required to be connected to this virtual network. There may be 100 other requirements but these two are enough for us to learn about the need to have an overlay network. The designers can solve this problem by providing an overlay network which we call Overlay-1. Routers at all four cities and three centers connect to each other using some tunneling protocol. In fact, not all lines are needed. All centers and cities, if only connects to the central office, above requirements can be met with. The tunnels may be designed as per required security criteria3. Additionally, another overlay network, let us call it Overlay-2, is formed between all accountants across all these networks. These machines are part of the overlay network Overlay-2 but no other networks. Even though they communicate over tunnels passing through the Internet, they cannot communicate to other machines of Internet if the routers are configured accordingly. Thus both problems are possible to be solved by overlay networks Overlay-1 and Overlay-2.
Once we have looked at overlay networks, another term which is common is called virtual private network. Let us try to learn what it is.
Virtual Private Network
The virtual private network or VPN helps a remote machine to communicate to a network as if it is locally connected, in a secure fashion. The process is enabled by a technique which provides two things,
3 One typical way to have IPsec connections between these routers.
1. The data is communicated from sending machine or sending network router to the router of the network where the machine would like to be part of.
2. The data is tunneled. That means the sending router encapsulates the entire packet inside another packet where sender’s address is his own and receiver as the destination network router. Before encapsulation, the data is also encrypted to make sure others do not get anything from snooping into the communication.
You can understand that the overlay networks extend this idea and allow even networks to be a member of a remote network. One more critical difference is, overlay networks are transparent; users does not realize that they are part of the overlay network and not a conventional network. They do not feel that difference. The VPN, on the contrary, has to be set and configured and the user is aware of the fact that he is using VPN and not a local network.
Need for routing differently
The basic idea of SDN is derived from the need of routing differently. Conventionally, when the routing tables are set up, the packet for the same destination follows the same path irrespective of the content of the packet. As we have seen during our discussion of packet classification, the customers demand routing packets based on many quality-of-service parameters and they expect routing process to follow those policies. We have also learned about MPLS where every packet is tagged with a special indicator tag. The routers, instead of routing based on destination address, route based on the tag value. Thus, two packets, destined to the same address, but belong to a different class of customers, can be given different routing treatment and thus, different service.
This QOS based routing process is known as traffic engineering as the traffic is manipulated, routed and given priorities based on the traffic parameters using specific demands. For example, routing VOIP traffic over a separate route as compared to data route is a common requirement. Giving higher priority to premium customers is another common requirement. Look at Figure 31.2. There are two paths between sender and receiver. The path using thicker line is short and used for VOIP while the path using dotted lines is used for normal traffic. When the traffic is designed to follow this requirement, it is an example of traffic engineering. Such traffic engineering is more important at higher level ISPs and data centers as they need to route packets based on who the sender ISP is and the MOU between themselves and the sending ISP. The traffic to be routed is based on mutual agreements and their own policies which otherwise is impossible to manage. For examples, they might have volume based agreements (you pass my 1 Gb, I will pass your 2Gb in return) or speed based agreements (you pass my 1Gb data at 25 Mb/sec and I pass your 1Gb data at 10 Mb/Sec) etc. or the payment, for example, if you pay ₹10,000, I will allow 20 Tb traffic of yours or based on priority, for example, class-A customers are routed to path A while class B customers are routed on path B. Here we do not need to use conventional routing protocols which find the shortest paths or datagram may decide its path on its own. When traffic engineering is deployed, the vendor or the administrator should decide how each packet is routed, irrespective of the destination address or other things. MPLS-like solutions work very well for such demands. When they do so, these networks are known to be traffic engineered. Each such routing decision is known as flow. When a packet is routed as per a given flow, the administrators are said to provide routing per-flow. When traffic engineering is possible, administrators have per-flow control over routing.
There are many other recent trends that drive the SDN movement. Let us brief about them. First, traffic patterns are changing. When data is located across the globe with distributed databases and servers needs very flexible traffic management. Let us take a few examples to understand. When a query is fired to a distributed database, the administrator would like to have some performance requirement, for example, all responses from all databases must come back by 2 msec. The queries are to be responded in real time irrespective of whether the database server is located in the US or in India.
When people bring their laptops and smartphones to the company, the “Bring your own device” mantra is being observed, treating those network devices with more flexible and stricter security is needed. The routing process and data movement should be tightly controlled. The network admins need much finer and stricter controls over packets moving across networks full of devices not completely under their control.
Cloud services are on the rise. If the organization prefers to provide services over a cloud, the first need is elasticity, i.e. service as per demand. Such flexibility is impossible to be achieved if the network traffic and servers are not under administrators’ complete control and they are able to deploy them as and when the demand arises.
The era of “Big Data” is arrived; many applications use varieties of data coming from various sources like social networking sites and different types of databases and in a huge volume are on the rise. For example, a company getting feedbacks and comments about their products from all such methods. Collecting such direct and indirect feedbacks are complicated for many reasons. First, the amount of data is huge, second the data, especially which are coming in form of social media posts etc. are not structured and are of varieties of types and third, they change very fast. All in all, these type of solutions demand to manage the huge bandwidth networks with varieties of data with changing volume again demand flexible network management.
The conventional networks have some serious issues handling these problems. When there are complex policies, which are to be deployed network-wide, the conventional networks demand manual intervention. For example, deploying different services for 3G and 4G customers, each network device is to be locally and specifically configured using low-level commands of that specific device manually, and separately. Most administrators avoid such steps as system disruption is a major problem and users dislike disruption the most. Another problem with conventional network solution is that it is hard to scale them, especially when the demands are dynamic. For example, assume we have two servers. They are handling dedicated customers. It is quite possible that sometimes the load on one server is high and sometimes the load on the other server is high. The servers are quite good and can handle that load. The problem is with the underlying network. The network should be designed in such a way that when the load on server-1 is high, the switches should distribute data going out from server-1 as much as possible and restrict the data going out from server 2 on a specific part of the network. Thus enabling flushing out data from both servers evenly. Similarly, when the server-2 is in high demand, the data going out from it should be distributed more. The network switches should be able to dynamically decide to either honor server-1 or server-2 as per the traffic volume. Such a solution is not possible to be provided automatically when the switches choose shortest paths. Ideally, the administrators should have a pool of switches (like other resources) and should be able to allocate them on demand. Another important point is, there is no standard for building network devices and their interfaces. A CISCO switch has a different interface than a Linksys switch. A Cyberoam Firewall has a different interface than a Fortinet firewall. Managing all switches or Firewalls of a network is always cumbersome with heterogeneous devices. It is always better to have a single consistent interface instead.
SDN can provide traffic engineering, resource sharing, vendor neutral centralized control and the finer level of control for the administrators. Before we look at SDNs, let us brief about connection oriented networks and routing overlays, the ideas which are extended in SDN.
Connection-oriented networks and routing overlays
For flow-based routing, one method is to use a connection-oriented network and another is to use a routing overlay. Let us try to understand what both of them are.
In connection-oriented network approach allows the users to specify the exact path between sender and receiver (unlike IP-based connectionless delivery mechanism). An independent path for each flow is laid down by a connection-oriented connection. When the connection establishment process starts, it follows the path based on the policy suggested and thus the packets travel the exact route which the administrator wanted.
The process requires the switch to follow management policies implemented for all packets coming in. The path selection and forwarding are based on those policies. Thus the connection request indicates the policy to be obeyed and only those switches which accept that policy should be part of the path. Each switch along the path accepts the connection request only if they can accept the policy. For example, if the switch as the sender allows different paths for VOIP calls and other protocols like SMTP and HTTP, it can have two different routes already defined. One route contains the minimum of hops and switches along the path are designed to provide real-time service. On the other path, we can have switches which are used in the conventional network. Whenever the sender wants to establish a connection, the switch decides which type of connection is needed based on the request. If it is VOIP, it will choose the first route, and for others, it chooses the second route. The connections are established and executed accordingly and thus both types of traffic get the treatment they demand. Thus the connection-oriented connection is a great way to make sure such policies are enforced. Additionally, this connection orientation process can be embedded in hardware. When hardware is used to classify and label the packets, it happens at the real time and there is no performance degradation. Very high data rates can be sustained by this design.
A routing overlay is a network of virtual links (tunnels). Virtual links are established based on required policies. Thus a virtual link between network 1 and network 2 should be designed as per the policies of routing between them. It is also possible to have multiple virtual links between two networks for different policies. For example, if two networks need two different routes, one each for real-time and non-real-time traffic, then one can create two virtual links between them. A routing overlay is basically a set of tunnels between potential senders and receivers. Each tunnel acts like a direct link which the routers can choose to route. Each such channel offers a typical service set according to a specific policy. The administrator can design and deploy virtual links to set the policies that they deem fit. It is possible that the administrators design three different channels for 2G, 3G and 4G traffic between same pair or networks. Unlike connection oriented networks created by hardware, overlays are deployed entirely in software and thus have both advantages and disadvantages of software deployment. They are much more flexible and allows changes in the virtual link deployment on the fly. That means, a typical route for a user is by default 3G but when his quota is over, he can be easily shifted to another route which offers slower services. When he pays for the 3G network or 4G network, he is again shifted to a faster route. It is also possible that for these three services, the same route is used but each switch along the path has three priority queues. They always give the highest priority to 4G traffic and 2nd priority to 3G and the lowest priority to 2G traffic. Three different queues, one each for 4G,3G and 2G traffic is deployed. Only when the 4G queue is empty or some specific time period is elapsed, a packet from the 3G queue is sent out. Only when both 4G and 3G queues are empty or a typical time period is elapsed, the packets belonging to the 2G queue is sent over the line.
Thus, routing overlays provide an excellent opportunity for the administrators to dynamically control the networks. On the other hand, the routing overlays are much slower compared to connection oriented networks (as they are managed completely by software). The overlays can help existing network setup (which is working over the Internet) to act as per administrator’s choice by just imposing the right type of overlay on top of it. Such an overlay can be easily changed if ISP’s MOUs change and can be redesigned with changes if need be. Connection-oriented networks, as they are embedded in hardware, are hard to change. One can have multiple overlays implemented together for different types of services and different members. One overlay, for example, connects all accounts computers while another overlay might contain all who would like to connect to attendance server to insert everyday attendance as we discussed in an example earlier in the same module.
Apart from being slow, overlays have other issues as well. They may result in routing which is not optimal. As the users are using virtual links to connect, they have no idea about associated actual links. The virtual link capacity (bandwidth) and delay (time to send the packet through) are set as per the underlying actual link in the beginning. However, we know that the actual link dimensions continuously vary and the bandwidth and delay assumed while establishing the virtual link may not remain true after some time. In that case, the routing over virtual link become incorrect or at least inefficient even if it remains correct. This is because the virtual link routing designed in overlays are independent of the actual links and both operate on their own.
The bottom line is, however useful, both connection-oriented networks and overlays look like, they do not solve the problem completely. We need a better solution, the SDN, which combines both of above approaches in a far more efficient way. It is the time that we look at SDNs.
SDN as a combined approach
Interestingly, it is possible to combine both of above approaches, overlays, and connection-oriented networks, to get best of the both worlds and avoid issues with both methods. Software Defined Networking or SDN answers that question quite efficiently. The packet processing is done in hardware in the forwarding devices but the controller controls the network using software based control. Next two modules throw light on this part further.
Summary
In this module, we have learned what a software defined network is, what is the need of it, what are the component of a conventional router or switch is and the role of each of these components popularly known as planes.
| you can view video on Software Defined Networks (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,Fernando M. V. Ramos,Member, IEEE,Paulo Verissimo,Fellow, IEEE,Christian EsteveRothenberg,Member, IEEE,SiamakAzodolmolky,Senior Member, IEEE, and SteveUhlig,Member, IEEE
5. IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, FIRST QUARTER 2014 493Network Innovation using OpenFlow: A Survey, Adrian Lara, Anisha Kolasani, and Byrav Ramamurthy1553-