Key SDN Protocols

Why This Matters

Software-Defined Networking fundamentally changes how we think about network architecture by separating the control plane from the data plane—but that separation only works if the pieces can talk to each other effectively. The protocols you'll encounter in SDN aren't just technical specifications; they represent different approaches to solving core networking challenges: how do we configure devices, compute optimal paths, manage traffic flows, and enable programmability at scale?

You're being tested on more than protocol names and port numbers. Exam questions will ask you to identify which protocol solves a specific problem, compare southbound versus northbound interfaces, and explain why certain protocols work together in production deployments. Don't just memorize what each protocol does—understand which layer of the SDN architecture it operates in and what problem it was designed to solve.

---

Southbound Protocols: Controller-to-Device Communication

These protocols handle communication between the SDN controller and network devices (switches, routers). They're the foundation of SDN's centralized control model, enabling the controller to push forwarding rules and receive network state information from the data plane.

OpenFlow

• The original SDN southbound protocol—defines how controllers communicate with switches to manage flow tables and forwarding behavior
• Flow-based forwarding enables granular traffic control; controllers can match on multiple header fields and specify actions like forward, drop, or modify
• Version differences matter: OpenFlow 1.0 supported single tables, while 1.3+ introduced multiple tables, groups, and meters for more sophisticated traffic handling

OF-Config (OpenFlow Configuration and Management Protocol)

• Complements OpenFlow by handling device-level configuration that OpenFlow itself doesn't address—think port settings, queue configurations, and certificate management
• Uses NETCONF as transport, leveraging XML-based data models for structured configuration management
• Separates flow management from device management—OpenFlow handles what to do with packets, OF-Config handles how the switch itself is set up

---

Configuration and Management Protocols

These protocols focus on device configuration, state management, and operational control. They enable automation and orchestration across network infrastructure, whether physical or virtual.

NETCONF

• XML-based network management protocol that provides structured operations for installing, modifying, and deleting device configurations
• Transaction-based model supports commit/rollback operations, ensuring configuration changes are atomic and recoverable
• Runs over SSH (typically port 830), providing secure, authenticated management sessions with clear separation between configuration and operational data

OVSDB (Open vSwitch Database Management Protocol)

• Purpose-built for Open vSwitch—manages virtual switch configurations including bridges, ports, interfaces, and tunnel endpoints
• JSON-RPC based with a schema-driven approach; the database schema defines what can be configured and how
• Enables controller-driven virtualization by allowing dynamic creation and modification of virtual network elements without service interruption

gRPC (gRPC Remote Procedure Call)

• High-performance RPC framework increasingly used for SDN management interfaces, especially in modern controller implementations
• Protocol Buffers for serialization provide strongly-typed, efficient data encoding compared to XML or JSON alternatives
• HTTP/2 transport enables bidirectional streaming, multiplexing, and lower latency—critical for real-time network telemetry and configuration

---

Traffic Engineering and Path Computation

These protocols enable intelligent path selection and traffic optimization. They provide network topology visibility and computational capabilities that allow SDN controllers to make informed routing decisions.

BGP-LS (Border Gateway Protocol - Link State)

• Exports link-state topology to SDN controllers—takes IGP information (OSPF, IS-IS) and makes it available via BGP to external applications
• Provides network-wide visibility including node attributes, link characteristics, and traffic engineering metrics
• Enables controller-based traffic engineering by giving the control plane complete topology awareness without requiring direct IGP participation

PCEP (Path Computation Element Communication Protocol)

• Dedicated protocol for path computation requests and responses between clients (PCCs) and computation servers (PCEs)
• Supports constraint-based routing—can compute paths based on bandwidth, latency, administrative policies, and other metrics
• Stateful PCE extensions allow the PCE to maintain path state and initiate updates, enabling dynamic traffic engineering without client requests

---

Programmability and Application Integration

These protocols and languages enable custom network behavior and application-level integration. They represent the programmable nature of SDN beyond simple configuration management.

P4 (Programming Protocol-Independent Packet Processors)

• Domain-specific language for data plane programming—defines how packets are parsed, matched, and processed at line rate
• Protocol independence means you're not limited to existing headers; P4 lets you define custom protocols and processing pipelines
• Compiles to target-specific code for programmable ASICs, FPGAs, or software switches—write once, deploy on multiple platforms

I2RS (Interface to the Routing System)

• Programmatic access to the routing information base (RIB)—allows applications to read routing state and inject ephemeral routes
• Faster than traditional protocols because changes bypass the routing protocol convergence process
• Ephemeral state model means I2RS-injected routes don't persist across restarts, maintaining clear separation from protocol-learned routes

XMPP (Extensible Messaging and Presence Protocol)

• Message-oriented middleware adapted for SDN use cases requiring real-time, asynchronous communication
• Presence and publish-subscribe capabilities enable event-driven architectures where components react to network state changes
• Federated architecture supports communication across administrative domains, useful for multi-controller deployments

---

Quick Reference Table

---

Self-Check Questions

1. Which two protocols would you use together to both configure an OpenFlow switch's ports and manage its flow tables? What does each one handle?

2. A network operator wants to compute optimal paths based on bandwidth constraints and then signal those paths to network devices. Which two protocols work together to accomplish this?

3. Compare NETCONF and OVSDB: what data encoding does each use, and in what deployment scenario would you choose one over the other?

4. An exam question describes a scenario where an application needs to temporarily inject routes into the network's RIB without affecting the underlying routing protocol state. Which protocol addresses this use case, and what key characteristic makes it appropriate?

5. Explain why P4 and OpenFlow are sometimes described as complementary rather than competing technologies. In what type of hardware deployment would you need P4 instead of (or in addition to) OpenFlow?