AT&T’s white paper “Towards an Open, Disaggregated Network Operating System” is breathtaking in its scope. I believe its goal is to create a community to build and maintain a universal NOS for hardware and software network devices.

Open Architecture for a Disaggregated Network Operating System (dNOS) . Our goal is to start an industry discussion on technical feasibility, build interest in participating in the formulation of technical detail, and determine suitable vehicles (standards bodies, open source efforts, consortia, etc.) for common specification and architectural realization.

Breathtaking. An architecture for NOS that would be universal, usable on any network device and modular. If adopted by enough customers, this would dramatically change the landscape.

Customers could choose to buy applications for their network devices while using a shared Linux operating system. Where hardware integration is required, the maker would supply the hardware drivers and OS integration necessary.

Today, the transition to application focus in the network is slow and meeting substantial resistance. There are plenty of reasons to believe that this effort could fail unless key stakeholders choose to participate. OTOH, the hardware makers are desperate to move into recurring or subscription revenue and this could be a way out. 

Functional Components

The following diagram from AT&T shows the functional components:

• NOS to be independent of hardware including chassis, line card, modules, routers, switches, etc.
• Applications to be separate from Operating System (OS).

Hardware Independence – The OS will be independent of specific hardware via the use of abstraction layers such as those that exist today (for example, SAI and P4). A forwarding abstraction layer is proposed to isolate those functions.

The goal of the FAL is to have ASIC supplier diversity and that multiple ASIC’s share a common abstraction layer that is target independent.

NFV –  Also suitable for use as software-only devices for use in hypervisors or containers.

Software Architecture

The paper describes a series of functional components as a starting point for the project: 

Observations

• Control Plane is obvious enough. I’ve always been confused when vendors tell me they can’t write a YANG module or a REST interface when every startup on the Internet can do it with a headcount of 5. Heck, CompSci students do it.
• We are past the time when a vendor implementation of BGP/SNMP etc. was unique value proposition. It’s the same outcome for everyone. There is good code and bad code, and most vendor implementations are bad because few people use them. Cisco has been clear that features that aren’t used by many customers aren’t tested properly because there is no feedback from the field.
• Because the forwarding plane is unique to the ASIC/silicon inside the hardware, the switch maker should maintain this code.
• Most likely we will let ASIC designers make their own data plane drivers and put them into the public domain for use.
• Vendors who want to offer Ethernet chassis switches can offer more data plane complex code while maintaining compatibility with the control and management plane.

Business / Commercial

It might be possible for new vendors to enter the market that focus on data plane only, and let other companies offer the higher levels in the stack. This would move closer to the server model, where applications/OS/server hardware are separate for each element.

Can existing network makers such as Cisco and Juniper find incentives to join the effort? Their current business focuses on making full-stack products.

Operating System

• Assumed to be Linux
• Basic function of the system including bootstrapping, device drivers, process management, shell access, etc.
• Authoritative ownership of the basic network state information
• “Base Operating System should support multiple CPU architectures for system portability”

Data Plane Layer

• Provide a forwarding abstraction layer between the control and management planes and the hardware/software data planes
• Provide general packet forwarding functions in hardware and software

Support for both chassis and TOR switch “A control plane may manage a single or multiple data planes. Those data planes may be co-resident on the same hardware as the control plane, or they may be distributed across a network.”

Will It Work ?

The final paragraph is a clear statement. dNOS could become a substantial effort simply because AT&T wants to buy and use it:

In parallel, as the effort matures, AT&T will evolve its router-platform sourcing process to give preference to dNOS vendors whose products (or committed product-roadmap) are based on using this platform.

That, potentially, is a lot of money. And it would be attractive to ASIC makers and smaller software companies.

AT&T calls on hardware and software vendors to support the effort, but will they? Cisco has more than ten internal ‘companies/business units’ each developing their own operating system, applications, and silicon in isolation. They don’t even share software code for obvious things like YANG, SNMP, or AAA – how would they ever reach agreement on a shared operating system?

Based on recent moves by AT&T where a number of open source, collaborative efforts have gained momentum (e.g. ONAP) there is a reasonable chance this could happen.

On the other hand, dNOS is much more likely to see network vendors raise the barricades and dispatch the army to fight the invaders who are stealing their birthright of making easy money by selling mystical black boxes that only inducted brethren can operate.

Let the fight begin.

---

References

Link: Towards an Open , Disaggregated Network Operating S ystem – AT&T CTO Office http://about.att.com/content/dam/innovationblogdocs/att-routing-nos-open-architecture_FINAL%20whitepaper.pdf