Posted by This post will help me synthetize some of my current understanding of this topic. “ONOS” stands for “Open Network Operating System”, a control plane application developed by the Open Networking Foundation (ONF) to, initially, be a distributed-systems approach of an OpenFlow controller with vendor-agnostic primitives. The project grew and started to receive a lot of other resources and technologies to become a one-fits-all control plane implementation.
If you’re not understanding what I’m saying by “control plane”, you can take a look at the Computer Networks Basics part 2 post where I cover a basic part of the Software-Defined Networking idea.
Why an I studying that?
I’m currently working in a project related to a SDN implementation based in the Programming Protocol-Independent Packet Processors (P4) language where we’ll need to have a more complex control plane than just a python script capturing packets and insert rules in a single programmable switch. From all available possible control plane implementations, ONOS seemed as one of the most interesting for this specific project, so I’m getting used to configuring, administrating and developing to it.
Basically, when you make your own P4 program for a target switch, you’ll need to have some kind of “contract layer” to make it clear for the control plane which tables to operate in your program to achieve some specific behavior. If you’re working with a simple python script, then you can simply take the actions you need to insert a rule in the switch’s tables based on the perception it has from the network. We say this control plane is pipeline-aware, since it knows the tables available in the P4 program beforehand. But ONOS has a differente approach: the idea is the applications being as pipeline-agnostic as possible, so it doesn’t have to know what tables are available, some other component will handle that and map those to the system’s understanding.
For example, if I want to discover links between switches using the LLDP protocol, then it only has to have a way to send the LLDP packet out through all the ports from a switch and then get the received packet in all other switches and it’ll be able to draw the topology map. The Topology Discovery App is not responsible for giving the way for sending and receiving the packets, but the Pipeconf, Device Driver and the Southbound interface implementation are. If I’m working with a BMv2 running with the P4Runtime protocol, then I’ll need to supply the Pipeconf app for mapping those capabilities to ONOS while the P4Runtime Provider and the BMv2 Driver will handle the communication and insertion of the rules in the switch pipeline using the map I gave to it.
What’s the current situation?
This is just the beginning of what I’m doing. I’ll need to develop an App to at least insert the initial configuration into the switches. We already do that using a Python script shipped with the P4 dev env we are using for the dataplane development, but we need to move it to ONOS to make it more reliable and production-aligned. So I’m currently trying to learn the ONOS basics through several fronts:
- Revisiting the exercises from ONF’s NGSDN Tutorials github repo;
- Reading ONOS documentation available at the project website;
- Watching Cascone’s presentation on ONF Connect 2019 about the NGSDN exercise 3 where he covers the Pipeconf app and the ONOS app development guidelines;
- Trying to first implement the Basic.p4 code to communicate with the org.onosproject.pipelines.basic app to map and communicate with the upper-layer apps like Host discovery and LLDP Provider in our own testbed topo.
What’s to do next?
Once I’m familiar enough with the ONOS architecture, I’ll need to get at least the basics from Java language (I don’t program Java since 2010! OMG) to get a better reading of the basic.p4 pipeconf implementation and start derivating it to our implementation. Then I’ll need to get a way to read the configurations from the files we use and make it insert all the rules in the correct tables. Basically, I’ll need to develop 2 ONOS apps: our own pipeconf for our current implementation and the auto-configuration App that will use the pipeconf to insert the correct rules.
I think the pipeconf app isn’t actually vital to our project, I guess if I studied the P4Runtime implementation and the BMv2 driver from ONOS I could simply devel a app to directly insert the rules from the files. I’d be simply translating our Python script to Java. But since it could be interesting to have some of the upper-layers Apps from ONOS, I guess giving a try to develop the Pipeconf app will be really good.
That’s all for now, folks!
I guess it’s enough for now, I still need to spend some time with that to have any better progress to report here, but at least I already have a clearer roadmap to what I have to do. I Just hope I can do that in a satisfying time.
Cya!