The document outlines the functions of the control plane in Software-Defined Networking (SDN), including shortest path forwarding, notification management, security mechanisms, and topology management. It describes the role of the Network Operating System (NOS) in managing network infrastructure and the various interfaces (southbound and northbound) that facilitate communication between the control and data planes. Additionally, it highlights the importance of standardizing northbound APIs to simplify the development of SDN applications.
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0 ratings0% found this document useful (0 votes)
20 views9 pages
Control Plane
The document outlines the functions of the control plane in Software-Defined Networking (SDN), including shortest path forwarding, notification management, security mechanisms, and topology management. It describes the role of the Network Operating System (NOS) in managing network infrastructure and the various interfaces (southbound and northbound) that facilitate communication between the control and data planes. Additionally, it highlights the importance of standardizing northbound APIs to simplify the development of SDN applications.
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 9
Functions of Control Plane
Shortest path forwarding: Uses routing information collected from
switches to establish preferred routes. Notification manager: Receives, processes, and forwards to an application events, such as alarm notifications, security alarms, and state changes. Security mechanisms: Provides isolation and security enforcement between applications and services. Topology manager: Builds and maintains switch interconnection topology information. Statistics manager: Collects data on traffic through the switches. Device manager: Configures switch parameters and attributes and manages flow tables. The functionality provided by the SDN controller can be viewed as a network operating system (NOS). NOS provides essential services, common application programming interfaces (APIs), and an abstraction of lower-layer elements to developers. NOS is the software that manages and controls the network infrastructure. It enables the developers to define network policies and manage networks without concern for the details of the network device characteristics. Southbound Interface It provides the logical connection between the SDN controller and the data plane switches. Some controller products and configurations support only a single southbound protocol. A more flexible approach is the use of a southbound abstraction layer that provides a common interface for the control plane functions while supporting multiple southbound APIs The most commonly implemented southbound API is OpenFlow Open vSwitch Database Management Protocol (OVSDB): Open vSwitch (OVS) an open source software project which implements virtual switching that is interoperable with almost all popular hypervisors. VS uses OpenFlow for message forwarding in the control plane for both virtual and physical ports. OVSDB is the protocol used to manage and configure OVS instances Forwarding and Control Element Separation (ForCES): An IETF effort that standardizes the interface between the control plane and the data plane for IP routers. Protocol Oblivious Forwarding (POF): This is advertised as an enhancement to OpenFlow that simplifies the logic in the data plane to a very generic forwarding element that need not understand the protocol data unit (PDU) format in terms of fields at various protocol levels. Rather, matching is done by means of (offset, length) blocks within a packet. Intelligence about packet format resides at the control plane level. Northbound Interface The northbound interface enables applications to access control plane functions and services without needing to know the details of the underlying network switches. The northbound interface is more typically viewed as a software API rather than a protocol. Unlike the southbound and eastbound/westbound interfaces, where a number of heterogeneous interfaces have been defined, there is no widely accepted standard for the northbound interface The result has been that a number of unique APIs have been developed for various controllers, complicating the effort to develop SDN applications. To address this issue the Open Networking Foundation formed the Northbound Interface Working Group (NBI-WG) in 2013, With the objective of defining and standardizing a number of broadly useful northbound APIs.