Welcome back. In our last lesson, we deconstructed the architecture of Software-Defined Networking (SDN), establishing its core principle: the separation of the network's control plane (its intelligence) from the data plane (its forwarding hardware). This leaves us with a centralized controller and a fleet of network devices awaiting instructions. The critical question we ended on was: how do these now-separate components communicate with each other?
Today, we will answer that question by exploring the Application Programming Interfaces (APIs) that serve as the communication channels within an SDN architecture. Our focus will be on explaining the distinct roles of northbound APIs (NBIs) and southbound APIs (SBIs). Understanding these interfaces is key to appreciating how network programmability and automation are practically achieved.
The Compass of Communication
In the SDN landscape, the controller is the center of the universe. All communication flows either to it or from it. To keep track of this flow, a simple directional analogy is used:
- Northbound: Communication flowing "up" from the controller to the applications and business logic.
- Southbound: Communication flowing "down" from the controller to the network devices (switches, routers).
Let's look at this in a diagram.
This simple "north" and "south" distinction defines the two primary types of APIs in any SDN environment. Let's examine each one's specific role and the technologies they employ.
Southbound APIs: The Controller's Voice
The southbound API is the language the controller speaks to command the network hardware. It is the mechanism through which the centralized control plane programs the distributed data planes.
When the controller makes a decision—for example, calculating a new best path for traffic or deciding to block a malicious IP address—it uses southbound APIs to translate that decision into specific, device-level instructions. These instructions might include:
- Adding or removing flow entries in a switch's forwarding table.
- Pushing a new Access Control List (ACL) to a router.
- Updating a VLAN configuration.
- Requesting statistics or status updates from a device.
Essentially, the southbound interface allows the controller to exert direct, programmatic control over the forwarding behavior of every device in the network.
There are several protocols used for southbound communication, each with different characteristics. You've likely encountered some of them during your CCNA studies, though perhaps not in this context.
- OpenFlow: This is the original, "classic" SDN southbound protocol. It provides a standardized way for a controller to define and manipulate the flow tables within a network switch, giving it granular control over packet forwarding.
- NETCONF (Network Configuration Protocol): A more modern and robust protocol designed to install, manipulate, and delete the configuration of network devices. It uses an XML-based data encoding and a well-defined set of operations, making it a powerful replacement for legacy CLI scripting. It often works with YANG, a data modeling language used to describe the structure of configuration data.
- SNMP (Simple Network Management Protocol): While primarily used for monitoring, SNMP can also be used by controllers as a southbound interface to gather operational data and, to a limited extent, make configuration changes.
- CLI (Command-Line Interface) via SSH: In some cases, a controller might fall back to managing a device by sending CLI commands over an SSH session, especially when dealing with legacy hardware that doesn't support more modern APIs.
Northbound APIs: The Network's Intent
While the southbound API is about how the controller controls the network, the northbound API is about why. It exposes the network's capabilities "upwards" to applications, orchestration tools, and network administrators, allowing them to express their intent.
Instead of manually configuring dozens of switches, a developer or administrator can interact with a single northbound API on the controller to make a high-level request, such as:
- "Create a new isolated network for a new customer."
- "Guarantee 10 Mbps of bandwidth for all video-conferencing traffic."
- "Show me a topology map of the entire network."
- "Block all traffic from this list of known malicious IPs."
The controller's job is to take this high-level intent, received via the NBI, and translate it into the specific device-level configurations required, which it then pushes out via the SBIs. The northbound API abstracts away the complexity of the underlying hardware. The application doesn't need to know what brand of switches are being used or what specific commands are needed; it only needs to speak to the controller.
The most common style for northbound APIs today is REST (Representational State Transfer). Given your IT background, you may already be familiar with REST from web development. It uses standard HTTP verbs (like GET, POST, PUT, DELETE) and common data formats, most notably JSON (JavaScript Object Notation), to interact with resources. This makes the network accessible and programmable using the same tools and techniques used for web services.
Reading: A Deeper Dive into NBI and SBI
The following article from NetsTuts provides an excellent and concise breakdown of Northbound and Southbound APIs, including helpful tables that summarize the protocols and characteristics of each.
This resource clearly defines and contrasts the two API types, which directly aligns with our learning goal. It will help solidify your understanding of their distinct purposes and the technologies associated with each.
Please read the first three sections of the article: Section 2: Northbound APIs Section 3: Southbound APIs Section 4: Northbound vs. Southbound – Side-by-Side Comparison As you read, focus on the "who exposes it" versus "who consumes it" aspect, and note the different sets of protocols listed for each direction.
The End-to-End Workflow
To see how these interfaces work together, let's watch a short, animated example. The following video from Indiana University walks through a practical scenario where a security application uses the NBI and SBI to block a threat.
North- and southbound APIs: An introduction
This video provides a clear, visual explanation of the entire communication flow in an SDN environment, from application intent to device-level action.
Please watch the entire video (it's only about 3 minutes). Pay close attention to the sequence of events described in the simplified example. Notice how the request starts at the application (northbound), is processed by the controller, and results in rules being pushed to the hardware (southbound).
As the video illustrates, the workflow is a closed loop:
- Intent: An application makes a request to the controller via the Northbound API. (e.g., "Block IP 1.1.1.1").
- Translation: The controller processes this high-level request and translates it into specific, low-level rules for the relevant network devices.
- Action: The controller uses the Southbound API to push these rules to the network devices. (e.g., "Device Z, drop all packets from source IP 1.1.1.1").
- Feedback: The devices report their status back to the controller via the SBI, and the controller can then report the outcome back to the application via the NBI.
This flow is the engine of modern network automation.
Conclusion
In this lesson, we demystified the communication pathways that make Software-Defined Networking function. We established the clear distinction between the interfaces that sit "above" and "below" the SDN controller.
Key Takeaways:
- Southbound APIs (SBIs) are used by the controller to communicate down to the physical and virtual network devices. Their purpose is configuration and control. Common protocols include OpenFlow, NETCONF, and SNMP.
- Northbound APIs (NBIs) are used by applications and administrators to communicate up to the controller. Their purpose is to express intent and abstract the network. The most common style is REST, typically using JSON over HTTP.
- The SDN controller acts as a translator, converting high-level intent received from the NBI into low-level configuration instructions sent via the SBI.
- This two-way communication flow enables the centralized management, automation, and programmability that are the core benefits of SDN.
We have now covered the "what" (separation of planes) and the "how" (NBI/SBI communication) of SDN architecture. In our next lesson, we will look at a concrete, real-world implementation of these concepts by exploring the capabilities and purpose of Cisco DNA Center, a prominent SDN controller in enterprise networking.