Page History

P4 is a domain-specific language designed to allow programming of protocol-independent packet processors. Behavioral Model v2 (BMv2) is the reference P4 software switch. Initial support for this type of device Support for BMv2 has been included into in ONOS starting from the 1.6 (Goldeneye) release with 2 goals: i) provide the research community with a platform to experiment with P4-based applications and ii) define a common groundwork to support programmable data planes in the next versions of ONOS.

...

By using ONOS 1.6, you'll be able to program and control a network of BMv2 devices with all the benefits of a logically centralized SDN platform. The following features are currently supported:

...

The figure below sketches the high-level workflow and architecture of the BMv2 integration support in ONOS (click to zoom).

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. Eventually, the BMv2 service API will be merged into the core northbound API in the next versions of ONOS as a device-independent API for programmable data planes.

...

In order to enforce a given BMv2 JSON configuration on a devicenetwork node, ONOS applications need to provide a BMv2 Device Context. Device contexts are used to bind together in a Java class a BMv2 JSON configuration and an Interpreter. The latter is used by ONOS to “understand” a given P4 program. 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.

...

Applications are expected to provide an implementation of such interface. While for criteria criteria and tables it is possible to specify a 1-to-1 relationship through a Java map, for instructions the same is not possible or at least it's not convenient. The reason is that instructions in ONOS are modeled after OpenFlow actions (which are protocol-dependent), while flow rule treatments (ONOS wording to refer to the ensemble of actions to be applied as a consequence of a flow table match) are usually defined 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 Instructionsinstructions), 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.

...