ONOS: An Open Network Operating System for Telecom Operators – Architecture, Features, and Deployments

Since the emergence of ONOS, discussions about its rivalry with OpenDaylight (ODL) have been frequent; service providers demand more agile and efficient networks to support innovative services, making SDN controllers a critical focus, with many options such as OpenDaylight, OpenContrail, Ryu, Floodlight, NOX, SPOX, and others.

OpenDaylight, driven by equipment vendors, claims openness but prefers proprietary interfaces to protect vendor interests, prompting operators to adopt the Open Network Operating System (ONOS) as an alternative.

ONOS was open‑sourced in December 2014 and has achieved notable milestones, though awareness in China remains limited; the author has been involved in ONOS development for the past two years.

AT&T, the largest supporter of ONOS, contributes $1 million annually and emphasizes performance, scalability, and reliability as the top design concerns for the platform.

ONOS originated from the collaboration between ON.LAB and Stanford University, where the founders of SDN and OpenFlow sought to guide the industry’s future through an open‑source controller.

In October 2015, ONOS became a Linux Foundation project, leveraging the foundation’s open‑source expertise to mature the project.

The ONOS ecosystem now includes 13 partners, 43 collaborators, over $7 million in sponsorship, major carriers such as AT&T, Verizon, China Unicom, NTT, and SK Telecom, leading equipment vendors, numerous universities, and more than 130 code contributors with over 1 000 Twitter followers; ON.LAB handles architecture, operators provide use cases, and vendors deliver solutions.

ONOS follows a rapid‑iteration release cycle of roughly three months, employing a “deploy‑feedback‑modify‑deploy” model to quickly incorporate user feedback and improve the product.

Deployments are primarily in education and research networks, using the SDN‑IP application; notable commercial deployments include Tianjin Unicom’s agile VPN, as well as European GEANT and Aarnet projects that built SDX‑L2/L3 and Castor applications on ONOS.

The SDN principles of separated control and data planes, logically centralized control, and open APIs are reflected in ONOS’s architecture: southbound plugins separate control and data planes, northbound APIs enable programmable networking, and a distributed cluster provides logical centralization.

Design priorities focus on performance first, simplicity, modularity, and abstracting protocols and device specifics so applications need not be aware of underlying differences.

The system hierarchy includes core modules (resource management and generic mechanisms) and an application layer covering WAN scenarios, security (AAA), NFV (vRouter, VTN, OLT, SFC), and operations (flow analysis, fault management).

Cluster communication uses two mechanisms: a Gossip protocol for weak consistency and the Raft algorithm for strong consistency, chosen based on resource consistency requirements.

High availability is ensured by automatic failover; when a node crashes, other nodes take over its control responsibilities, and a load‑balance command restores balanced control after recovery.

Performance tests show a single ONOS instance can manage 1 024 devices and 4 096 links; scaling tests demonstrate linear growth of flow‑table and Intent operation performance with the number of instances.

Five core characteristics of ONOS are summarized: (1) Operator‑ and academia‑driven open‑source platform, (2) Architecture focused on carrier‑grade scalability, performance, real‑time operation, and reliability, (3) Unified network resource model enabling third‑party SDN app interoperability, (4) Standardized northbound APIs and southbound plugins facilitating integration of third‑party devices and applications, (5) Support for multiple southbound protocols, protecting existing investments while preparing for future white‑box hardware.

The latest ONOS module diagram shows southbound plugins divided into three categories: topology collection (OSPF, BGP‑LS, ISIS), configuration protocols (NETCONF, SNMP, OVSDB), and forwarding protocols (OpenFlow, PCEP).

Core modules (resource management and generic mechanisms) are highlighted in red/black, while the application layer (WAN services, security, NFV, OAM) appears in blue.

Typical WAN use cases on ONOS include IP+Optical, SDN‑IP, segment routing, CORD, and IPRAN; CORD integrates SDN, NFV, and cloud infrastructure to deliver agile data‑center capabilities to operators.

Operator networks consist of multiple layers (IP and optical) that are traditionally managed separately; a centralized SDN control plane can streamline provisioning, reducing service activation from days or months to minutes.

Traditional optical transport networks built on ROADM devices require labor‑intensive wavelength configuration, leading to high operational costs and static, inflexible networks.

At the ONF 2015 conference, ONOS demonstrated multi‑vendor, multi‑layer network control using various southbound protocols (TL1 for Ciena/Fujitsu, PCEP for Huawei, OpenFlow for Corsa).

CORD (Central Office Re‑architected as a Data center) combines SDN, NFV, and cloud technologies to replace legacy CO equipment with white‑box devices and VNFs, offering solutions such as E‑CORD for enterprises, M‑CORD for mobile, and R‑CORD for residential use, with commercial deployment planned for 2017.

On 27 Nov 2015, Tianjin Unicom launched the world’s first commercial SDN‑IPRAN service based on ONOS, delivering a two‑layer VPN that enables rapid provisioning, dynamic bandwidth allocation, and policy‑based user permissions.

The IPRAN service enhances enterprise line competitiveness and provides a foundation for future value‑added services, aiming toward an “e‑commerce” style boutique line.

In February 2016, the OPNFV Brahmaputra release added multi‑tenant Layer 2/Layer 3 capabilities to ONOS, with future plans for service‑function chaining and Cloud VPN to bridge WAN and data‑center environments.

Performance testing (Blackbird version) evaluated six latency scenarios, confirming ONOS’s strong capabilities.

In summary, ONOS directly challenges OpenDaylight by targeting carrier‑grade agility and large‑scale deployment, offering high availability, scalability, and a highly abstracted system design that accelerates evolution and optimization.

Author: Jiang Rui, Beijing Institute of Technology graduate, Huawei SDN Platform Software Engineer and Market Technology Manager, contributing to ONOSFW, SFC, and PCEP southbound projects for about two years.