How SDN Transforms Network Operations: Evolution, Automation, and DevOps

Preface

I am Zhang Yongfu from Dahe Cloud Union. After years of Cisco operations and joining Dahe Cloud Union in 2016, I focus on SDN network architecture design and automated operations. SDN is just starting in China, and more operators will encounter it in the coming years.

1. Network Technology Evolution

1.1 History Review

Network development can be divided into three stages.

First stage : from the 1970s to the 1980s, starting with the 1974 release of TCP/IP, which enabled larger‑scale network connectivity.

Second stage : from 1995 fast‑Ethernet standards, 1997 IETF MPLS, and 2005 China Telecom CN2 construction, marking a milestone for carrier‑grade Ethernet.

Third stage : 2006 SDN was born; 2009 OpenFlow 1.0 was released; 2011 ONF formed; 2012 Google B4 operated; 2013 OpenDaylight released; 2014 ONOS released, bringing many players into the SDN field.

1.2 Rise of SDN

On the left are three international SDN organizations (Linux Foundation, ONF, ON.LAB). In the middle are open‑source projects such as ONOS, ODL, OPNFV, and the merging of OPEN‑O and ECOMP into ONAP. On the right are hardware vendors (Barefoot, BigSwitch) and startups (Viptela, Velocloud) that provide SDN chips and appliances. International SDN development is rapid, while domestic commercial adoption remains limited.

2. Traditional Network Operations Status

Traditional network operations rely on vendor‑specific CLI commands (Cisco, Juniper, Huawei, H3C) and a plethora of operational rules that are often ignored in practice. Operators bear the brunt of service issues and are frequently blamed when upper‑level services fail.

Operations teams create policies, some have developers for secondary development of open‑source tools. Over the years, teams have doubled in size, handling 24/7 monitoring, continuous alarms, fault reports, and templates—typical of traditional network operations.

3. SDN Network Operations

3.1 DCN Architecture Changes

DCN architecture has evolved from a classic three‑tier topology to virtual network designs based on FABRIC, as illustrated by Facebook’s DCN architecture. Traditional three‑tier networks cannot support modern virtualization workloads; cloud and NFV demand soft‑hard combined designs.

3.2 Backbone Network Architecture Development

Regional backbone networks have become more spider‑web‑like, adding points and lines over a decade of evolution.

SDN‑designed backbone architectures (similar to Google’s design) consist of forwarding elements, a control plane, and a TE server for traffic engineering.

3.3 SDN NetDevOps

Network engineers often lack DevOps experience, which requires collaboration across planning, coding, testing, and release. By integrating network work with DevOps, NetDevOps bridges the gap, especially after SDN adoption.

Traditional network staff rarely script; combining scripting with DevOps enables NetDevOps, which gains more advantages in an SDN environment.

3.4 SDN Operations Work

SDN operations consist of daily tasks similar to traditional operations (monitoring, fault handling, meetings, reporting) and engineering projects that involve software development, architecture design, and optimization.

3.5 SDN Operations Tools

Common tools include Cacti, Smokeping, Nagios, and Zabbix. Open‑source tools are preferred, requiring engineers to develop custom extensions for daily operations.

4. SDN Automated Operations

4.1 Service Quality Design

Operations should focus on SLI and SLO rather than SLA. Typical metrics include latency < 50 ms and availability > 99.9%.

4.2 Monitoring and Alarm Design

Monitoring involves data collection, storage, module development, alarm channels, and user interfaces. Large‑scale networks require distributed collection and storage; Dahe Cloud Union’s SDN controller manages nearly 100 forwarding nodes worldwide, using both central and distributed storage.

4.3 Alarm Statistics Analysis

Raw alarm data must be categorized, then analyzed to produce reports that feed SLI/SLO metrics and support SLA calculations.

4.4 Log Statistics Analysis

Log collection covers the entire SDN stack—from control systems, OS, storage, orchestration, to forwarding elements. ELK is commonly used for log analysis and can be customized for specific business needs.

4.5 Traffic Statistics Analysis

Beyond device and port traffic, SDN enables end‑to‑end and business‑level traffic analysis, linking network flows with application performance.

4.6 System Analysis

System analysis includes physical server and OS resource monitoring. Continuous delivery for the SDN controller uses lean and agile practices, enabling rapid version iteration, automated deployment (e.g., Ansible), automated testing, and integration testing.

5. SDN Operations Architecture

The automation architecture consists of a resource layer (network devices, servers), collection layer (SNMP, Netconf, OpenFlow, CLI), independent storage (logs, configuration, knowledge base), CMDB‑based resource management, monitoring and alarm modules, data analysis, workflow and project management, fault self‑healing, security policy integration, and multi‑channel alarm delivery (email, WeChat, call center). Fault self‑healing correlates alarms and can automatically resolve issues without manual intervention.