Applications and controllers express policy through software interfaces, while switches, routers, virtual network functions, or other forwarding elements apply the resulting rules.
An SDN architecture usually includes application-facing interfaces, a logically centralized control function, and interfaces to managed network elements. “Logically centralized” does not require one physical controller: the control system can be distributed for scale and resilience while presenting a coherent policy view. Interfaces and data models may be open, standardized, or proprietary, so portability and multi-vendor interoperability are not automatic.
Key points
AbstractionApplications can express intent without managing every device command, while controllers translate higher-level policy into forwarding behavior.
Operational usesSDN can support consistent configuration, virtual networks, traffic engineering, and policy changes driven by applications or telemetry.
Interface designController, application, and device interfaces require defined authentication, authorization, data models, versioning, and failure behavior.
Important limitationConcentrated control and broad automation privileges increase the impact of controller compromise, software defects, and incorrect policy. Secure controller access, authenticated interfaces, validation, redundancy, monitoring, and protected recovery paths remain necessary; SDN is not inherently secure.