...
- Device discovery: connection / disconnection events
JSON configuration swap
Packet-ins and packet-outs
Match-action table population (via flow rules, flow objectives, or intents)
Port statistics collectionscollection
Flow statistics collection
...
On the northbound, ONOS provides a new Java API called "BMv2 Device Context Service" that can be used by applications to specify at runtime the JSON configuration of a given BMv2 device. Match-action tables can be populated using existing northbound APIs such as flow rule, flow objective or intents, with native support for non-standard P4 match and actions ( via ONOS extension selectors and treatments).
On the southbound, ONOS speaks with BMv2 using Thrift. This project has been based on a customized version of fork of the official BMv2 repo, called onos-bmv2. We customized the BMv2 “simple_switch” target that, differently from the original one, supports primitives to send in order to support SDN-like control features such that sending of "hello" messages and packet-in events to the a remote controller, and primitives to receive and transmit transmit packets over a given port similarly to OpenFlow packet-outs. The source code of onos-bmv2 is available here.
BMv2 device context
In order to enforce a given JSON configuration on a device, ONOS applications need to provide a “BMv2 BMv2 Device Context”Context. Device contexts are used to bind together in a Java class a BMv2 JSON configuration and an “Interpreter” implementation Interpreter. Interpreters are The latter is used by ONOS to “understand” a given P4 program. They provide Indeed, it provides a mapping between ONOS objects and program-specific P4 objects (e.g. headers, actions, table names, etc.), allowing existing services and apps (e.g. host tracking, LLDP discovery, ARP proxy, reactive forwarding, etc.) to work with virtually any P4 program.
...
ONOS table ID ↔ P4 table name
Criterion's type ↔ P4 header instance’s field name
- Flow rule's treatment instance → BMv2 action instance
Applications are expected to provide an implementation of such interface. While for criteria and tables it is possible to specify a 1-to-1 relationship through a Java map, for Instructions instructions the same is not possible or at least it's not convenient. The reason is that Instructions instructions in ONOS are modeled after OpenFlow actions (which are protocol-dependent), while flow rule treatments (to be applied as a consequence of a match) are usually defined as a list of multiple instructions. In P4 instead, actions are defined as a compound of low-level protocol-independent primitives (not expressible using ONOS Instructions), and, most important, P4 allows to specify only one action per table entry. Extracting the "meaning" of a given treatment instance and mapping it to a P4 action is not straightforward and it's usually program-specific. That’s why we expect a P4 programmer using ONOS to write its own interpretation logic (i.e. Java code) that can map a given treatment instance to a BMv2 action instance.
...