In the last section, we touched upon the term Software-Defined Networking or SDN but did not discuss it in much detail. In this section, we will discuss SDN in more detail and try to give an overview of the key ideas underlying this architectural concept.
C on tro l Pl an e
Application Application
…
ApplicationASP 1 ASP 2 ASP N
Ap pl ica tio ns Northbound APIs OpenFlow Forwarding HW Forwarding HW Forwarding HW Forwarding HW D at a Pl an e FlowVisor OpenDayLight
…
FloodLight C on tro l Pl an eNetwork Controller Software
Southbound APIs East-West APIs
Figure 2.2: Software Defined Networking (SDN) Architecture
The SDN architecture comprises of four key ideas:
• Separation of control and data planes: Networking protocols are often arranged in three planes: data, control, and management. The data plane consists of all the mes- sages that are generated by the users. To transport these messages, the network needs to do some housekeeping work, such as finding the shortest path using L3 routing pro- tocols such as Open Shortest Path First (OSPF) [59] or L2 forwarding protocols such as the Spanning Tree Protocol [110]. The messages used for this purpose are called control messages and are essential for network operation. In addition, the network manager may want to keep track of traffic statistics and the state of the various net- working equipments. This is done via network management. Management, although
important, is di↵erent from control in that it is optional and is often not done for small networks such as home networks. One of the key innovations of SDN is that the con- trol should be separated from the data plane. The data plane consists of forwarding the packets using the forwarding tables prepared by the control plane. The control logic is separated and implemented in a controller that prepares the forwarding table. The switches implement data plane (forwarding) logic that is greatly simplified. This reduces the complexity and cost of the switches significantly.
• Centralization of the control plane: The U.S. Department of Defense funded Advanced Research Project Agency Network(ARPAnet) research in the early 1960s to counter the threat that the entire nationwide communication system could be disrupted if the telecommunication centers, which were highly centralized and owned by a single company at that time, were to be attacked. ARPAnet researchers therefore came up with a totally distributed architecture in which the communication continues and pack- ets find the path (if one exists) even if many of the routers become non-operational. Both the data and control planes were totally distributed. For example, each router participates in helping prepare the routing tables. Routers exchange reachability in- formation with their neighbors and neighbors neighbors, and so on. This distributed control paradigm was one of the pillars of the Internet design and unquestionable up until a few years ago. Centralization, which was considered a bad thing until a few years ago, is now considered good, and for good reason. Most organizations and teams are run using centralized control. If an employee falls sick, he/she simply calls the boss, and the boss makes arrangements for the work to continue in his/her absence. Now consider what would happen in an organization that is totally distributed. The sick employee, say John, will have to call all his co-employees and tell them that he/she is sick. They will tell other employees that John is sick. This will take quite a bit of time before everyone will know about Johns sickness, and then everyone will decide what, if anything, to do to alleviate the problem until John recovers. This is quite inefficient, but is how current Internet control protocols work. Centralization of control makes sensing the state and adjusting the control dynamically based on state changes much faster than with distributed protocols. Of course, centralization has scaling issues but so do distributed methods. For both cases, we need to divide the network into subsets or areas that are small enough to have a common control strategy. A clear advantage of centralized control is that the state changes or policy changes propagate much faster
than in a totally distributed system. Also, standby controllers can be used to take over in case of failures of the main controller. Note that the data plane is still fully distributed.
• Programmable control plane: Now that the control plane is centralized in a cen- tral controller, it is easy for the network manager to implement control changes by simply changing the control program. In e↵ect, with a suitable API, one can imple- ment a variety of policies and change them dynamically as the system states or needs change. This programmable control plane is the most important aspect of the SDN. A programmable control plane in e↵ect allows the network to be divided into several virtual networks that have very di↵erent policies and yet reside on a shared hardware infrastructure. Dynamically changing the policy would be very difficult and slow with a totally distributed control plane.
• Standardized API’s: As shown in Fig. 2.2, SDN consists of a centralized control plane with a southbound API for communication with the hardware infrastructure and a northbound API for communication with the network applications. The control plane can be further subdivided into a hypervisor layer and a control system layer. A number of controllers are already available. Floodlight [43] is one example. OpenDaylight [112] is a multi-company e↵ort to develop an open source controller. A networking hypervisor called FlowVisor [122] that acts as a transparent proxy between forwarding hardware and multiple controllers is also available. The main southbound API is OpenFlow [78, 46] , which is being standardized by the Open Networking Foundation. A number of proprietary southbound APIs also exist, such as OnePK [24] from Cisco. These later ones are especially suitable for legacy equipment from respective vendors. Some argue that a number of previously existing control and management protocols, such as Extensible Messaging and Presence Protocol (XMPP) [118, 119], Interface to the Routing System (I2RS [57]), Software Driven Networking Protocol (SDNP)[63], Active Virtual Network Management Protocol (AVNP) [14], Simple Network Management Protocol (SNMP) [17], Network Configuration (Net-Conf) [36], Forwarding and Control Element Separation (ForCES) [142, 34, 54], Path Computation Element (PCE) [93, 9, 74], and Content Delivery Network Interconnection (CDNI) [51], are also potential southbound APIs. However, given that each of these was developed for another specific application, they have limited applicability as a general-purpose southbound control
API. Northbound APIs have not been standardized yet. Each controller may have a di↵erent programming interface. Until this API is standardized, development of network applications for SDN will be limited. There is also a need for an east-west API that will allow di↵erent controllers from neighboring domains or in the same domain to communicate with each other.
Networking industry has shown enormous interest in SDN. SDN is expected to make the net- works programmable and easily partitionable and virtualizable. These features are required for cloud computing where the network infrastructure is shared by a number of competing entities. Also, given simplified data plane, the forwarding elements are expected to be very cheap standard hardware. Thus, SDN is expected to reduce both capital expenditure and operational expenditure for service providers, cloud service providers, and enterprise data centers that use lots of switches and routers. SDN is like a tsunami that is taking over other parts of the computing industry as well. More and more devices are following the software defined path with most of the logic implemented in software over standard processors. Thus, today we have software defined base stations, software defined optical switches, software defined routers, and so on. Regardless of what happens to current approaches to SDN, it is certain that the networks of tomorrow will be more programmable than today. Programma- bility will become a common feature of all networking hardware so that a large number of devices can be programmed (a.k.a orchestrated) simultaneously. The exact APIs that will become common will be decided by transition strategies since billions of legacy networking devices will need to be included in any orchestration.