15 SDN Resilience: API Availability

15.1 Start With the Decision

Write the request in plain words first. Name who may ask, which ward is in scope, what must change, when the change must end, and what result will count as proof.

15.2 Route Overview

This is part 1 of 2. Continue with SDN Resilience: Failover Validation.

15.3 Part Objectives

• Define api and availability decision route with explicit inputs, errors, and change rules.
• Validate controller cluster responsibilities with a concrete scenario and pass criteria.

15.4 Chapter Roadmap

• Start With the Request That Must Survive
• API and Availability Decision Route
• Northbound and Southbound Boundaries
• Request Lifecycle
• Northbound Contract Design
• Southbound Action Checks
• Controller Cluster Responsibilities

15.5 Start With the Request That Must Survive

Trace One Change From Request to Proof

Picture a hospital wing where a nurse asks the building system to give one ward a safer data path. The ward must stay online while a control computer fails and its partner takes over. The service owner needs to know that the right request reached the right switches and that no old rule survived by mistake.

Write the request in plain words first. Name who may ask, which ward is in scope, what must change, when the change must end, and what result will count as proof. Then follow that same request through the control pair and down to the installed rule. Keep one request id in every record so the trail can be joined later.

Test a lost control node, stale shared state, a split pair, a late reply, and a switch that reconnects with old rules. Check both the service result and the recorded path. A healthy control screen is not proof that the ward received the intended service.

Keep any urgent safe action available when central control is unsure. A change should fail closed or fall back to a known rule when its owner cannot prove current state.

This opening does not select a product or prove every failure mode. Practitioner turns the request into a boundary and recovery plan. Under the Hood examines state sharing, leader choice, rule order, and the records needed to explain a change.

APIs and clustering matter because a service request has to survive translation, controller failure, state movement, and switch action. If the request cannot be traced, availability claims are just slogans.

Start simple: follow one northbound request through authorization, controller state, southbound action, and failover. The API contract and cluster design are good only when that trace stays understandable.

15.6 API and Availability Decision Route

Use Figure 15.1 when checking an SDN controller API or high-availability design.

For api and availability decision route, inspect Figure 15.1 at Requester. Its visible premise is: SDN API and availability decision route. Then compare action.

Before making the decision in this section, inspect Figure 15.1. It makes the decision concrete by showing SDN API and availability decision route, so the relationships can be checked before they are turned into a design claim.

Read Figure 15.1 as an ordered argument. Read the labels in their presented order, trace the connectors or contrasts between them, and finish at the stated outcome or review evidence. Notice which boundary, comparison, or transition explains SDN API and availability decision route. That observation connects this visual to the chapter’s running narrative: use it to justify the next design decision and to record what evidence would confirm it in operation.

Start with the requester—an application, workflow, operator, or automation that is permitted to request a network change—and define a northbound contract containing intent fields, authorisation, scope, idempotency, response shape, and expected proof. Assign an owner for topology, policy, flow records, counters, and conflict decisions so the controller state behind that contract is explicit.

The corresponding southbound action may install or remove a rule, query a counter, change a role, issue a barrier, or apply a fallback. Test that action through quorum loss, stale state, switch-controller role changes, reconnection, and degraded mode. Receiver evidence, counters, alerts, rollback results, and the next review condition then verify whether the original request survived both the API boundary and the availability path.

15.7 Northbound and Southbound Boundaries

Northbound and southbound APIs should not be treated as two names for the same interface. They cross different responsibility boundaries.

Make the northbound and southbound boundaries premise visible in the diagram Figure 15.2: SDN northbound and southbound API boundary map. Begin by distinguishing Applications from service outcome proof.

Interrogate Applications first, then find service outcome proof in Figure 15.2. Apply the service outcome proof review question before receiver outcome, and operations check. Those answers support northbound and southbound boundaries; the figure states: SDN northbound and southbound API boundary map.

Common northbound styles include REST-style request/response APIs, streaming RPC-style APIs, and configuration-model APIs. Common southbound actions include flow-rule changes, statistics requests, role changes, barrier checks, and device-state queries. The decision question is not “which interface is newest?” It is “which interface carries the right responsibility with enough proof?”

15.8 Request Lifecycle

A safe API design describes what happens after an application request arrives and before the network is allowed to change.

Do not apply request lifecycle until its premise is visible near Intent in Figure 15.3: SDN API request lifecycle from application intent through authorization, validation, rule computation, southbound install, switch enforcement, and proof response. Inspect the span to Install.

Read Figure 15.3 from Intent toward Install. Use receiver proof, and rollback state as the request lifecycle endpoint. The resulting visual statement is: SDN API request lifecycle from application intent through authorization, validation, rule computation, southbound install, switch enforcement, and proof response.

Lifecycle check:

• Receive intent: capture the requester, service objective, affected traffic class, scope, and requested duration.
• Authorize: confirm that the application or workflow may make this specific change.
• Validate: check topology, policy conflicts, protected traffic, fallback behavior, and rollback conditions.
• Translate: convert intent into rules, priorities, counters, timeouts, and affected devices.
• Install and confirm: send southbound changes and verify whether devices accepted the request.
• Observe outcome: compare switch proof with receiver or service proof.
• Respond and record: return a clear API result and store enough proof for later checks.

15.9 Northbound Contract Design

An SDN northbound API should be designed as a contract, not just as a URL or method name.

The chapter needs visual evidence for northbound contract design. Figure 15.4 provides it: SDN northbound API contract elements. Examine API together with accepted or degraded.

Figure 15.4 becomes useful when API is read alongside accepted or degraded. client compatibility adds the remaining acceptance cue. This supports northbound contract design. The visual summarizes: SDN northbound API contract elements.

Do not expose a raw switch-control surface as the first northbound design. Applications should not need to know every match field, rule priority, or device quirk to request a service outcome. The controller owns that translation and must make it traceable.

15.10 Southbound Action Checks

Southbound actions are low-level and device-facing. They should be treated as implementation details with strong proof.

Typical southbound action categories:

• Rule changes: install, modify, delete, or expire forwarding rules.
• Packet handling: request controller guidance for unmatched traffic or send a specific packet through a switch.
• Counter queries: read flow, port, queue, or table counters.
• Role and connection management: decide which controller instance may write to a device.
• Synchronization checks: confirm whether earlier rule updates have been processed.
• Fallback rules: preserve known safe behavior during controller or link degradation.

Check questions:

• Which application intent caused this southbound action?
• Which controller state version produced the rule?
• Which switch accepted, rejected, or partially applied the update?
• Which counters or receiver proof show the service objective?
• Which timeout or rollback removes stale rules?

15.11 Controller Cluster Responsibilities

A controller cluster is not automatically safer than one controller. It is safer only when the system can explain which instance owns decisions, what state is shared, and what happens to switches during changeover.

15.11.1 Controller Placement and Capacity

An OpenFlow switch is often drawn one line away from its controller. That is a logical attachment: the switch has a control session and controller role. The physical path may cross access, aggregation, routed WAN, firewall, load balancer, and encrypted tunnel hops. Every hop adds queueing and a failure domain, so placement must be calculated from both request capacity and path behavior.

Start with a request budget per switch group:

$$\lambda_{group}=\sum_{s=1}^{N}\left(\lambda_{miss,s}+\lambda_{stats,s}+\lambda_{event,s}+\lambda_{retry,s}\right).$$

Measure those terms under startup, reconnection, topology change, and attack—not only steady telemetry. An older single-thread example used about 200 requests/s as controller capacity. Keep that only as a worked baseline. Current capacity depends on controller code, policy work, state-store replication, message type, CPU, and transport security; benchmark the exact release path.

If $\mu=200$ requests/s and arrivals are approximated as Poisson with exponential service, the M/M/1 estimate is

$$W=\frac{1}{\mu-\lambda}.$$

At $\lambda=120$/s, mean service-plus-queue time is $1/80=12.5$ ms. At $180$/s it rises to 50 ms even though offered load is still below nominal capacity. That nonlinear rise is why “under 200” is not a safe admission rule. Choose a target utilization such as 50–70%, then verify percentile latency under the real burst distribution. For $k$ workers, do not assume $k\mu$ until shared locks, ordering, and replicated state have been measured.

Complete end-to-end control delay with the network path:

$$D_{control}=\sum_{h=1}^{H}(d_{prop,h}+d_{ser,h}+d_{queue,h})+D_{TLS}+W+D_{switch}.$$

For small control frames, serialization may be minor on a fast LAN, while queueing, WAN propagation, retransmission, and TLS/session recovery dominate. Measure one-way or round-trip distributions from each switch site; hop count alone is not a latency metric.

Placement question	Local controller	Regional controller	Remote/global controller
Miss latency	usually lowest	path-dependent	highest and most variable
Failure containment	site can retain authority	region can coordinate several sites	shared service can become a broad dependency
State scope	narrow topology and identity view	regional policy and mobility view	global optimisation and policy view
Operations burden	many instances to patch and observe	moderate instance count	simpler central operations but demanding WAN/fallback design

Place authority with the state needed for the decision, then bound what happens when that state is unavailable. A local controller may own emergency and gateway rules while a regional controller owns cross-site paths. During a partition, prohibit overlapping writers for the same match space; preserve already approved local rules; stop changes that require fresh global policy; and reconcile cookies, versions, counters, and expiries when connectivity returns.

A placement test should therefore inject a synchronized reconnect storm, link delay/loss, controller failover, stale replicated state, and physical loss of a shared network hop. Record arrival rate by message class, queue depth, decision and installation percentiles, state convergence, rule conflicts, receiver behavior, and recovery time. The diagram can remain logically one hop; the evidence must enumerate the real path.

Before approving controller cluster responsibilities, test the depicted proposition in Figure 15.5: A controller cluster keeps a primary and a hot standby in state sync, so the switch fabric keeps forwarding through a controller failover. Read from Enterprise SDN Three-Tier Architecture toward Active routing.

At Enterprise SDN Three-Tier Architecture, the diagram Figure 15.5 introduces a controller cluster responsibilities concern. The later labels Active routing and Leaf Switch 3 widen that review. With Leaf Switch 3 included, their combined meaning is: A controller cluster keeps a primary and a hot standby in state sync, so the switch fabric keeps forwarding through a controller failover.

Decision ownership

Only one authorized decision path should commit a conflicting policy update for the same scope.

Shared state

Topology, policy records, active rule records, and ownership leases need clear replication and freshness rules.

Local switch behavior

Switches should keep known safe forwarding behavior when possible, but the design must test what actually survives a controller loss.

Operations visibility

Operators need proof of which controller was active, which rules changed, what degraded, and what was rolled back.

15.12 Continue to the Next Part

Carry this evidence into SDN Resilience: Failover Validation, which begins with Failover Sequence Checks.