Versions Compared

Old Version 45

changes.mady.by.user Carmelo Cascone

Saved on

compared with

New Version 53

changes.mady.by.user Carmelo Cascone

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Brigade Mailing List

...

P4 allows programming of many devices in a target-independent manner, using high-level constructs. In principle, P4 programs should be portable. The same program, when compiled for different targets, should produce the same forwarding behavior. Finally, P4 allows for reconfigurability in the field. In other words, once deployed, devices can be reconfigured with a new P4 program to provide support for new forwarding capabilities. 

Why should ONOS care about a data plane programming language?

In ONOS we are ultimately interested in the capabilities of networking devices and ways to ease the configuration and control of such capabilities. P4 is becoming the common language spoken by switch vendors and operators to agree on what the data plane can or should do. Indeed, P4 is meant as both a specification language, e.g. to formally specify how a fixed-function switch ASIC works, and a programming language. In its mission to ease the life of operators, and to promote faster innovation in the network, ONOS should be able to understand and potentially speak P4. Understand, to be aware of the capabilities of a given device and to expose higher-level APIs to control them. Speak, to deploy new capabilities, e.g. generating or modifying existing P4 programs, that can be later controlled to satisfy application needs.

...

P4 is not a protocol or device API for runtime control or configuration, i.e. once a P4 program is deployed to a device, P4 doesn’t tell us how that device can be controlled, for example, to add or remove entries in match+action tables, or to read the value of a counter. How can ONOS control a P4-enabled device? P4Runtime is an effort in the P4 community to create a standard control-plane API portable across targets, they propose a gRPC-based APIs (p4runtime.proto). The brigade will focus on P4Runtime as a southbound control protocol, however, different devices supporting P4 might expose different APIs. Similarly to how ONOS today deals with different flavors of OpenFlow, heterogeneity of control protocol/APIs is abstracted from applications.

...

  • Southbound support for P4 Runtime DONE - Available starting from ONOS 1.11
  • Enable support for existing applications with any P4 program (via manual ONOS-to-P4 mapping) DONE - Available starting from ONOS 1.11
  • Extend northbound APIs to support protocol-independence (e.g non-standard match/actions in flow rules) DONE - Available starting from ONOS 1.11

  • Switch configuration via OpenConfig over gNMI DONE - Initial support for OpenConfig Interfaces model available starting from ONOS 1.14

  • New use cases:

    • Fabric.p4 (CORD fabric with P4 switches) DONE - Available starting from ONOS 1.14

    • Support for In-band Network Telemetry (INT) DONE - Available starting from ONOS 1.14

    • CORD VNFs offloading to HW P4 switches

      • 45/5G Mobile Serving and Packet Gateway (spgw.p4) DONE - Integrated with fabric.p4

      • Residential BNG with PPPoE termination

...

Here are some pointers to learn more about the work of this brigade and current support for P4 in ONOS:

...