SDN Concepts and Architecture

SDN Concepts and Architecture

Quick Answer: SDN separates the control plane (routing/policy decisions) from the data plane (packet forwarding). A controller becomes the network brain; southbound interfaces program devices, and northbound interfaces let applications request intent. Compared with fully distributed per-device control, SDN improves agility, programmability, and consistent policy. NFV virtualizes functions on servers and is related but not identical to SDN.

HCIA-Datacom V3.0 expands beyond classic switching and routing into network programmability. You do not design a full SDN fabric on this exam, but you must explain why enterprises adopt SDN language, name the architectural layers, and avoid equating “software” with “replacing all hardware.” Huawei’s product face of this idea is iMaster NCE (next section); this section builds the vendor-neutral and Huawei-aligned foundations first.

Control plane versus data plane

Every networking device conceptually has two jobs:

In a traditional distributed network, each switch and router runs its own control-plane protocols. OSPF neighbors form hop by hop; STP elects a root independently of a central brain; operators log into many boxes and hope configurations stay aligned. That model works and is still how most campus OSPF labs on HCIA operate—but it scales poorly when policy must change everywhere at once, when multi-vendor orchestration is required, or when cloud-style APIs must drive the network.

SDN’s defining idea is to logically centralize (or heavily assist) control-plane decision-making in a controller, while the data plane continues to forward on switches, routers, or white-box devices. Devices receive forwarding instructions, flow rules, or configuration models from the controller instead of—or in addition to—running every control protocol in isolation.

Exam trap: Plane separation does not mean “no protocols run on devices.” Many practical SDN deployments still use distributed protocols for underlay reachability or hybrid control. The exam cares that you can name the separation and the controller role, not that you claim every campus must disable OSPF tomorrow.

Traditional distributed control versus centralized SDN

Benefits you should recite on the exam:

1. Agility — New services (VLAN segments, ACLs, QoS, path policies) can be expressed once and applied network-wide instead of hand-editing dozens of VRPs.
2. Programmability — Applications and orchestration systems can call APIs instead of screen-scraping CLI.
3. Consistent policy — Security and QoS intent is less likely to diverge between edge switches.
4. Simplified O&M — Topology, inventory, and some troubleshooting move to a central view (especially with Huawei NCE-style platforms).
5. Innovation velocity — Features can evolve in software on the controller without waiting for every ASIC microcode change (within hardware capability limits).

Trade-offs (awareness level): Controller high availability, southbound protocol maturity, staff skill shift from pure CLI to models/APIs, and clear underlay design still matter. SDN is architecture, not magic.

SDN architecture layers and interfaces

A classic three-layer SDN picture is enough for HCIA:

┌─────────────────────────────────────┐
│  Application / Orchestration layer  │  ← business apps, OSS/BSS, portals
└─────────────────┬───────────────────┘
                  │ Northbound APIs (REST, etc.)
┌─────────────────▼───────────────────┐
│     SDN Controller / NMS brain      │  ← topology, policy, path, intent
└─────────────────┬───────────────────┘
                  │ Southbound APIs (NETCONF, OpenFlow-class, etc.)
┌─────────────────▼───────────────────┐
│   Network devices (data plane)      │  ← switches, routers, APs, firewalls
└─────────────────────────────────────┘

Northbound APIs

Northbound interfaces face upward from the controller toward applications, portals, and higher orchestration. They expose abstract capabilities: “create a campus VN,” “apply QoS for voice,” “report health of site A.” REST-style APIs are common in product literature. On the exam, remember direction: apps → northbound → controller.

Southbound APIs

Southbound interfaces face downward from the controller toward devices. They deliver configuration, flow programming, and state collection. In Huawei datacom contexts you will repeatedly meet NETCONF (often over SSH) with YANG models, plus traditional SNMP and streaming telemetry. Historical OpenFlow is the classic textbook southbound protocol; know the role, not OpenFlow message formats.

Direction trap: Northbound is not “toward the Internet north of the building.” North/south is relative to the controller stack drawing.

East–west (optional awareness)

Some materials mention east–west APIs between controller cluster members for scale-out and high availability. HCIA may not drill this, but if a question mentions multi-controller clustering, east–west is the usual label for controller-to-controller communication.

What still happens on the device

Even under SDN control, the data plane must:

• Look up destination MAC or IP in hardware tables
• Enforce ACLs and QoS at line rate
• Maintain local link state so failed ports stop forwarding

The controller’s job is to make global decisions and keep device tables aligned with intent. Hybrid models are normal: for example, underlay OSPF for IP reachability plus controller-driven overlay or policy. HCIA expects conceptual fluency, not a single “pure SDN only” dogma.

SDN and network automation relationship

SDN is an architectural answer to control centralization. Network automation is the broader practice of using scripts, Ansible, Python, OPS, and APIs to reduce manual work—even on traditional distributed networks. You can automate CLI today without a full SDN controller; a controller makes structured, multi-device automation more natural. Later chapters cover Python, OPS, and Ansible; this chapter focuses on the SDN control model and Huawei NCE + model-driven protocols.

NFV awareness (conceptual only)

NFV (Network Functions Virtualization) moves network functions—firewalls, load balancers, CPE functions, and more—from dedicated appliances onto virtual machines or containers on commodity servers. SDN and NFV often appear together in marketing (“software-defined everything”), but they solve different problems:

They complement each other: an SDN controller might steer traffic into an NFV-based firewall chain. On HCIA-Datacom, do not design NFV MANO stacks—just recognize the definition and that it is not synonymous with SDN plane separation.

Huawei positioning at a glance

Huawei markets intent-driven networking with iMaster NCE as the brain for campus, WAN, and data-center domains. Devices remain Huawei switches, routers, and APs; NCE provides centralized management, automation, and analytics. The next section expands NCE; keep this mental model: devices forward, NCE/controller coordinates, APIs connect apps and models connect configuration.

Exam traps for this section

• SDN ≠ “no hardware switches.” Hardware still forwards; software defines control and policy.
• Controller failure thinking: Real designs use HA and often local fallback—do not invent a single absolute answer unless the question states assumptions.
• Northbound vs southbound: Apps sit above northbound; devices sit below southbound.
• NFV vs SDN: Virtual functions versus control/data plane separation—different axes.
• Traditional routing still matters: Underlay IP, VLANs, and STP knowledge from earlier chapters remain prerequisites for understanding what a controller programs.

Study checklist

• Define control plane, data plane, and management plane in one sentence each.
• Contrast distributed traditional control with centralized SDN control.
• List at least three SDN benefits relevant to enterprise O&M.
• Sketch northbound and southbound directions relative to the controller.
• State one-sentence definitions of SDN and NFV that do not mix them up.