Solving SDN Challenges with a Single Solution: Stratum

Next-generation software-defined networking is closer than you think, and we are here to bring a next-gen SDN solution from labs into real life.

Meet Stratum, an open-source project that enables a truly software-defined data plane. Its goal is to build an open white box switch solution to assure the interchangeability of devices and programmability of behaviors. In other words, Stratum strives to deliver the promise of SDN: real software-defined capabilities.

Our team is excited to participate in a game-changing project like this, along with other software companies, cloud providers Google and Tencent, telecom operators, most prominent chip vendors and OEMs. Let us explain what Stratum is and why it’s so significant for SDN.

Starting with the basics: what’s SDN?

To be able to respond to the changing requirements quickly, cloud computing and network engineers need a centralized control console. Software-defined networking includes various technologies and methods that aim at separating the network’s control from hardware data plane resources. This way, centralized network control becomes more flexible and directly programmable. All SDN solutions have similar architecture: a controller, southbound APIs and northbound APIs.

SDN APIs

You’ve probably heard of OpenFlow, the communication protocol that enables SDN controller interaction with network devices such as routers and switches, both physical and virtual. OpenFlow or other protocol specifications relate to the southbound interfaces. It was developed by the Open Networking Foundation (ONF) in 2008 and became an industry standard. OpenFlow defines the way an SDN controller should interact with a data plane for better management and adjustments. Simply put, OpenFlow helps engineers dynamically set the rules for traffic forwarding.

Another well-known southbound API is Cisco OpFlex.

Northbound interface, in its turn, aims at supporting protocol-based communication between the controller and apps or other high-level control programs (OSS/BSS, orchestrators). The purpose of the controller is to keep a consistent view of the network topology, state and traffic flows. Then, applications on top of the northbound protocols use the data to implement the logic of the network behavior.

Issues with the OpenFlow protocol and what’s P4

The OpenFlow protocol can be used on a number of brand switches and routers, such as Cisco, Juniper, Dell, IBM, etc. The thing is, they are expensive to use. As an alternative, the so-called SDN white boxing has emerged: cheaper options of brand routers and switches. White box network switches can be programmed to use OpenFlow or any other southbound API. Instead of proprietary software, they use open-source software stacks. They also support more diverse network processor architectures.

With time, some limitations of OpenFlow have been discovered, and the need for more flexible solutions has appeared. Every switch vendor designs data path hardware in their own way. Each of them arranges different traffic processing components in a different order. This variation adds complexity when you need to manage various types of them. As a result,  specific code is required for every particular piece of hardware. Alternatively, you may need to introduce another layer of abstraction that increases the complexity and amount of code on the controller side. Furthermore, protocols like OpenFlow lack operational and administrative interfaces. Another problem is that adding new protocols support to OpenFlow is rather time-consuming.

The SDN community has been working to reduce the time needed to implement new protocols and extend the existing ones. This led to the creation of an alternative to fixed-functioned switches: programmable devices that use the P4 language to define the process of packet forwarding in hardware. It addresses a more general problem within the network: instead of just opening up the forwarding plane, P4 defines its behavior.

Programming Protocol-Independent Packet Processors (P4) is an open-source domain-specific language that describes the data plane behavior for particular use cases. The scope of P4 has extended to cover hardware and software switches, network interface cards and routers. P4 is the next step in SDN evolution that has made further improvements possible.

What should the next generation SDN look like?

P4 can be used to upgrade the structure of the switch pipeline dynamically: network OS and data plane can negotiate new pipeline configurations, while OpenFlow requires specifications revision. This way, next-generation SDN interfaces enable the flexibility of control and management. So, the list of requirements to the new, improved SDN can look like this:

• provides an abstraction to all kinds of the switching silicon (supports datapath models regardless of the vendor)
• defines both interface and behavior
• is extendable for new protocols
• operational interfaces are consistent: they work in the same way for troubleshooting, certificate management and software upgrade

The P4 language and the P4Runtime protocol are the tools for implementing these requirements. P4Runtime protocol remains unchanged no matter what protocols and features are supported by the forwarding plane. This gives us a single API that can be used to control several versatile switches. The API automatically updates once new features are introduced within a P4 program and is exposed to an external control scheme. The plan is easy: you need to specify the switch behavior in the P4 language and then use P4Runtime API to control it.

Next goes the device configuration management. The gNMI protocol is used to access and change configurations as well as stream telemetry data from a device. It is a gRPC-based protocol that uses OpenConfig (vendor-neutral data models) as a definition of device configuration structure.

One-time operations services, such as device rebooting, testing or pinging, are managed by gNOI (Network Operations Interface), another gRPC-based protocol with semantics defined under OpenConfig initiative.

These are the key components to deliver the next-gen SDN.

Stratum combines all layers into one powerful solution

Just think of Stratum as a software package that brings programmability all the way down to the silicon layer. To allow that, Stratum includes all the elements we’ve mentioned before:

• it uses the P4 language
• provides P4Runtime interface
• implements OpenConfig models with gNMI and gNOI interfaces

Being a groundbreaking SDN solution, Stratum is an open-source project with multiple contributors, where it’s the community that drives new features, not standards. The early version of the code was seeded by Google in 2018. Then, at the Mobile World Congress 2018, ONF demonstrated P4Runtime – Stratum’s core interface, running on Barefoot, Cavium and Mellanox chips – it had already leveraged three open-source protocols (P4Runtime, gNMI, gNOI).

Stratum’s Answer: Next-Gen SDN Interfaces. Source: ONF.

PLVision has decided to hop in on the project last summer, covering the gNOI part of Stratum. We’ve focused on administrative services and providing a baseline for device operation. As a result, we’ve created initial gNOI support for system reboot capabilities. The solution was ready for the ONS 2019 presentation of Stratum in April.

The gNOI Story – Stratum. Source: ONF.

We’ve built a sample application on top of system interfaces and taught the ONOS controller to update multiple switches. The app coordinates the updates of the switches by taking them out of operations one by one, applies new software to them, reboots and puts them back in the game.

Our goal is a hitless network update: we are going to update software that runs on switches while servers in the network continue operating without losing connectivity. The next step is an orchestrated update via a northbound interface: schedule an upgrade, migrate the workloads that can be affected to safe places, then update the network without influencing services.

Stratum’s perspectives

The preview version of the project, available only to the community members, has been released earlier this spring. The next release is scheduled for September, and it will be open to the public. Hopefully, the NOS product will be ready for lab trials, the support of several hardware platforms will be added, and the initial baseline for the testing framework will be defined.

ONF lists several use cases for Stratum that illustrate the flexibility of its applications:

• Cloud SDN data plane
• Cloud SDN fabric platform
• CORD
• Thick switches with embedded control

Stratum takes the place of SDK in the regular NOS layered architecture. It works as a common denominator and hides switching silicon specifics beneath.

Stratum Use Cases. Source: ONF.

There are also different types of hybrid models that provide a familiar NOS experience while enabling new Stratum interfaces. For a company working in the Networking Operating Systems development and customization, Stratum is a natural choice that allows flexibility and brings new opportunities to chase.

Summing up

Since Stratum is exceptionally versatile and suitable for many systems and forwarding silicon, it fills the critical gaps that affect the ultimate vision of SDN, making the network as easily programmable as a server. At the same time, Stratum doesn’t aim at replacing OpenFlow; its goal is to remove the limitations this standard carries.

“By lifting protocols out of hardware and into software, we will unleash a Cambrian explosion of innovation in networking, just as we have seen in compute. Because of its use of P4Runtime, Stratum opens the door for every network operator to tailor their network to best meet their needs, while benefiting from a rich open-source ecosystem and a choice of silicon providers.”

Nick McKeown, Co-founder, ONF

Taking part in an innovative project like this helps PLVision apply our networking expertise to next-gen SDN solutions and share the unique experience with our valued clients and the community. If you have any questions concerning our collaboration with ONF or our background in NOS, P4 programming and more, don’t hesitate to contact me.