Up to this point, the µONOS subsystems have been largely aimed at providing means to configure devices (H/W or software entities) via gNMI API, and for controlling RAN environments via E2T protocol. We do not yet have a platform subsystem for supporting P4RT. However, you can certainly use a P4RT client to connect to switches directly and control them that way.
The onos-topo sybsystem can be used to assist with that by storing information about the P4 switches (address, port, certs, etc.). To do that, you will likely have to define an aspect (a protobuf message) to hold such information and to store it attached to the entity representing the P4 switch. You can then using the onos-topo gRPC API, the onos-topo CLI, or the onos-operator topo CRDs to inject this information into the topology subsystem for your application to use.
We will be working on a small proof of concept in this area in the coming months and will be likely creating a new onos-topo aspect for this purpose. We will likely also be defining new entity and relation kinds to represent the switch, its ports, links and other information required by control applications. So keep an eye on the list for announcements related to this; perhaps it can be of use and perhaps if can be an opportunity to collaborate.
You received this message because you are subscribed to the Google Groups "ONOS Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to onos-dev+u...@onosproject.org.
To view this discussion on the web visit https://groups.google.com/a/onosproject.org/d/msgid/onos-dev/3e45785f-f998-4822-b8c7-b35717fada7dn%40onosproject.org.
Well, this depends on what it is you’re trying to do. My assumption based on your question is that you’re purely interested in control via P4RT. For this purpose, onos-config will not be of any use; perhaps only indirectly for configuring the switch a priori.
Yes, the onos-control repo was created initially for the purpose of programming and reconciling the flow information. However, since this was out of scope up to this point, the repo is merely a skeleton with no usable content. We may still use it later to house abstracted form of control, but before we do this, we’re likely to first work specifically on the P4/P4RT-based control on very narrow use-cases initially.
P.S.: Please leave the list address in the To field.
On 6/17/22, 2:40 PM, "Παναγιώτης Παυλίδης" <panpav...@gmail.com> wrote:
Thank you very much for your response.
So, as an alternative to make a topology, shoud i go through the onos-config in order to configure devices via gNMI API?
Is there any documentation or something that i can get a look about how can i do it?
Also i want to clarify another onos service, the onos-control service, i think this service is for flow rules for a switch and generally for controlling a network device.
Is this truly the point of it?
Yes, you’re understanding correctly. You can use the topology subsystem as it is today, but you may need to introduce new kinds of entities and relations to represent the switch and its ports, and the links between those ports. That information can then be populated using the onos-topo gRPC API, CLI or using CRD YAML via onos-operator. Using that information, you can then write a separate application that would use P4RT talking directly to the switches – for now.
It might be possible that some of the work on defining the topology schema will overlap with the work we will be doing in the next few weeks, but it should not be difficult to eliminate that overlap.
To view this discussion on the web visit https://groups.google.com/a/onosproject.org/d/msgid/onos-dev/CAJgTQ_hTo4ik6D_MeQhZoamw-neySXVduRFmgAyhd5xG%2Bh%2BxEg%40mail.gmail.com.