In traditional networks, the control and data planes are combined. Each node is responsible for both functionalities. The control plane is responsible for node configuration and path programming. Once paths have been determined, they are pushed down to the data plane. Examples of existing network nodes that achieve this are Ethernet switches. Ports used to serve inbound and outbound traffic represent the data plane. These are controlled and configured by the control logic, containing the forwarding logic for the switch. Based on rules represented in this logic, traffic is either forwarded to the proper port or flooded in case no match is found. In most cases, switches and other network elements are combined to form distributed network architecture, offering, in comparison to a centralized one, improved scalability, and redundancy. In contrast, the control networks in decoupled architectures are closer to client-server networks. Forwarding devices have limited decision-making capabilities and implement decisions made by controllers. However, it should be noted that configuration changes and other updates are applicable only by directly updating each device. Inevitably, large-scale networks that require, for example, adaptation to traffic demands (through corresponding bandwidth allocation) need both time and resources to be updated. Furthermore, in the traditional architecture resources and policy controls are updated each time the requirements of external applications are updated. There is, finally, no exposure of information to these applications regarding network state.<\/p>\n\n\n\n
On the other hand, SDN is a model based on the idea of moving from the traditional fully distributed model to a more centralized approach. This is achieved by separating the functionalities related to each plane into different elements. In SDN, switches are decoupled from the control plane and serve only the data plane while controllers are responsible for manipulating them. Control decisions, in this case, are made considering a global view of the network state. In SDN, the control plane acts as a single, logically centralized network operating system in terms of both scheduling and resolving resource conflicts, as well as abstracting away low-level device details, e.g., electrical vs. optical transmission. However, this does not imply that the controller is physically centralized. For performance, scalability, and reliability reasons, the logically centralized SDN Controller can be distributed, so that several physical controller instances cooperate to control the network and serve the applications. Since the controller is aware of the whole network topology, it can easily adapt to requirements regarding scalability and flexibility. For example, the problem of bandwidth allocation is solved by dynamically programming the controller through the exposed northbound API. This architecture gives applications more information about the state of the entire network from the controller, as opposed to traditional networks where the network is not application-aware.<\/p>\n\n\n\n
The SDN architecture APIs (Application Programming Interfaces) are often referred to as the northbound (Business Support System) and southbound (Operation Support System) interfaces. Many devices from the data layer can be connected to a single centralized control plane which enables the controller to have a network-wide view of topology hence providing flexibility for traffic engineers to develop and deploy applications like routing and security. Control networks for SDNs may take any form, including a star (a single controller), a hierarchy, or even a dynamic ring.<\/p>\n\n\n\n
<\/p>\n\n\n\n
SDN Planes<\/strong><\/p>\n\n\n\n The first fundamental characteristic of SDN is the separation of the forwarding and control planes. We will understand three major horizontal groupings (planes or layers) of the SDN architecture (Data, Control, and Application). A brief description is given below:<\/p>\n\n\n\n Data Plane<\/strong><\/p>\n\n\n\n Data Plane (Forwarding Plane or Data Path) is responsible for handling packets in the data path based on the instructions received from the control plane. Actions of the forwarding plane include: forwarding, dropping, replicating, and changing packets. The forwarding plane is usually the termination point for control-plane services and <\/p>\n\n\n\n Control Plane<\/strong><\/p>\n\n\n\n The Control plane is responsible for making decisions on how packets should be forwarded by one or more network devices and pushing such decisions down to the network devices for execution. The control plane usually focuses mostly on the forwarding plane and on the operational plane of the device. The control plane may be interested in operational plane information. Management functionalities are also part of the control plane (in some cases, these constitute a separate plane). These refer to monitoring, configuring, and maintaining network devices, e.g., making decisions regarding the state of a network device. The management plane may be used to configure the forwarding plane. For instance, the management plane may set up all or part of the forwarding rules at once.<\/p>\n\n\n\n Application Plane<\/strong><\/p>\n\n\n\n The application plane is the plane where applications and services that define network behavior reside. Applications that directly support the operation of the forwarding plane (such as routing processes within the control plane) are not considered part of the application plane.<\/p>\n\n\n\n Components and Building Blocks of SDN<\/strong><\/p>\n\n\n\n The SDN switch, the SDN controller, southbound and northbound interfaces, and SDN applications are the fundamental building blocks of the SDN architecture.<\/p>\n\n\n\n SDN Switch<\/strong><\/p>\n\n\n\n Network devices can be implemented in hardware or software and can be either physical or virtual. In SDN, network devices are responsible for forwarding and data processing. Switches in an SDN are often represented as basic forwarding hardware accessible via an open interface, as the control logic and algorithms are offloaded to a controller. Such forwarding devices are commonly referred to, in SDN terminology, as \u201cswitches\u201d. The SDN data plane, as described above, consists of network elements, which expose their capabilities to the control plane via interfaces southbound from the controller. Many SDN switches behave much like a standard Ethernet switch and flood traffic out of all ports for Ethernet frames destined to broadcast, multicast or unknown MAC addresses. Most SDN switches also flood normal ARP (Address Resolution Protocol) traffic like a typical hardware-based Ethernet switch. However, it is possible to put an SDN switch into an explicit forwarding mode, whereby only flows allowed or configured by the controller are allowed.<\/p>\n\n\n\n SDN switches that offer high performance are used to speed data center operations. Finally, virtual switches are available and can be used for developing services over SDN or to test an application.<\/p>\n\n\n\n SDN Controller<\/strong><\/p>\n\n\n\n The SDN Controller is a logical entity that receives instructions or requirements from the SDN application layer and relays them to the networking components. The controller is also responsible for extracting information about the network from the hardware devices and communicating it back to the SDN applications. Using the southbound API, the controller can add, update, and delete flow entries, both reactively and proactively. The SDN controller represents the SDN control plane and has complete control of the data plane.<\/p>\n\n\n\n Controllers constitute the core of the SDN architecture. They are the central point of the network, responsible for enabling and orchestrating the communication between applications, which represent business logic and network devices (switches routers, etc.). This communication is feasible through northbound and southbound APIs that allow the simplification and automation of the above process. Ideally, controllers should contribute to the intelligence, flexibility, scalability, and cost-effectiveness of the overall SDN infrastructure.<\/p>\n\n\n\n Southbound Interface<\/strong><\/p>\n\n\n\n Southbound APIs facilitate efficient control over the network and enable the SDN controller to dynamically make changes according to real-time demands and needs. OpenFlow, which was developed by the ONF, is the first and probably most well-known southbound interface. It is an industry-standard that defines the way the SDN controller should interact with the forwarding plane to adjust the network, so as to adapt to changing business requirements. While OpenFlow is the most well-known of the SDN protocols for southbound APIs, it is not the only one available or in development.<\/p>\n\n\n\n OpenFlow<\/strong><\/p>\n\n\n\n The OpenFlow protocol can be viewed as one possible implementation of controller-switch (southbound) interactions, as it defines the communication between the switching hardware and a network controller. This provides an abstraction for business applications to use facilities provided by the control layer without going into the details of their implementation. The OpenFlow switch is the basic forwarding element, which is accessible via the OpenFlow protocol and interface. OpenFlow switches may be either hybrid (OpenFlow enabled) or pure OpenFlow. SDN controller uses a secure channel to communicate with the switch. OpenFlow packets are sent over this channel.<\/p>\n\n\n\n Northbound Interface<\/strong><\/p>\n\n\n\n Northbound communication refers to the communication between the business application layer and the control layer. A northbound API is used to implement and develop vendor-independent applications for network management and monitoring, load balancing, etc. Another advantage of northbound APIs is that they are easily modifiable using high-level languages like Python, Java, C++, etc. At present, no accepted standard protocol exists. Existing APIs have been implemented on an ad-hoc basis for specific applications. External management systems or network services may wish to extract information about the underlying network or control an aspect of network behavior or policy. Additionally, controllers may find it necessary to communicate with each other for a variety of reasons. For example, an internal control application may need to reserve resources across multiple domains of control. The northbound interface is defined entirely in software, while controller-switch interactions must be enabled by the hardware implementation.<\/p>\n\n\n\n Network Applications<\/strong><\/p>\n\n\n\n Network applications are programs that communicate with the SDN controller via APIs. These applications can build an abstracted view of the network by collecting information from the controller for decision-making purposes. These applications could include networking management, analytics, or business applications. For example, an analytics application might be built to recognize network activity for security purposes. In an SDN-enabled network, service providers can create several applications, aiming at cutting costs, improving customer experience, and others. It is expected that not all the SDN applications will be completely new. A lot of them replicate or improve applications that are currently running on routers and switches (control and data plane). For example, routing applications will enable routing decisions based on application-level insights and characteristics. Furthermore, using SDN applications, content routing can be designed to perform service availability checks before provisioning flows to the network switches. It is concluded that although SDN is focused mostly on control and data plane, network applications are also responsible for bringing improvements to both operators and users.<\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" Hello folks, Welcome back to learning SDN with Learnizo Global. This article focuses on the Architecture and components of SDN. Software-defined network (SDN) architecture defines how a networking and computing system can be built using a combination of open, software-based technologies and commodity networking hardware. As already mentioned in our previous article, the main aim […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-178","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/learnizoglobal.com\/blog\/wp-json\/wp\/v2\/posts\/178","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/learnizoglobal.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/learnizoglobal.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/learnizoglobal.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/learnizoglobal.com\/blog\/wp-json\/wp\/v2\/comments?post=178"}],"version-history":[{"count":1,"href":"https:\/\/learnizoglobal.com\/blog\/wp-json\/wp\/v2\/posts\/178\/revisions"}],"predecessor-version":[{"id":180,"href":"https:\/\/learnizoglobal.com\/blog\/wp-json\/wp\/v2\/posts\/178\/revisions\/180"}],"wp:attachment":[{"href":"https:\/\/learnizoglobal.com\/blog\/wp-json\/wp\/v2\/media?parent=178"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/learnizoglobal.com\/blog\/wp-json\/wp\/v2\/categories?post=178"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/learnizoglobal.com\/blog\/wp-json\/wp\/v2\/tags?post=178"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"](\"https:\/\/learnizoglobal.com\/blog\/wp-content\/uploads\/2021\/09\/image-2.png\")
<\/figure>\n\n\n\n