Versions Compared

Old Version 5

changes.mady.by.user Carmelo Cascone

Saved on

compared with

New Version 54

changes.mady.by.user Carmelo Cascone

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Add pointers to NG-SDN Tutorial and BNG disaggregation

Table of Contents
absoluteUrltrue

Brigade Members

...

  • Carmelo Cascone / ON.Lab (carmelo@onlab.us)

Brigade Members:

Contact the brigade:

Brigade Mailing List

Brigade Status

Active. Find here the JIRA tasks we are currently working on:

https://jira.onosproject.org/secure/RapidBoard.jspa?rapidView=32&view=planning.nodetail

Weekly meetings

Every Tuesday at alternate times: 9:00 AM PST and 10:00 PM US Pacific time.

Find here the next meeting time and agenda.

Contacts

For any information or to join the brigade please contact Carmelo Cascone (carmelo@onalb.us) or David Boswell (david@onlab.us).carmelo@opennetworking.org)

Background

...

P4 is a domain-specific language (DSL) designed to allow the programming of packet forwarding devices. P4 can be used to program different targets such as software switches, FPGA-based NICs or switches based on reconfigurable ASICs. P4 enables protocol-independent programmability at different levels, for example:

  • Parsing and modification (actions) of new, non-standard headers.

  • Configure table properties such as size, type of match (exact, ternary, LPMlongest-prefix), counters, etc.

  • Stateful processing, i.e. per-packet custom actions that can access and manipulate state maintained by the switch.

P4 allows programming of many devices in an 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, a P4-enabled device 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 device 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 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, i.e. to parse P4 programs to be aware of the capabilities of a given device and to expose higher-level APIs to control them. Speak, i.e. to generate or modify to deploy new capabilities, e.g. generating or modifying existing P4 programs, that can be later controlled to satisfy the application needs of applications.

Runtime control of P4 devices

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? There is no standard control protocol/API yet specifically targeted for P4, so far it is up to the switch target to expose a suitable API. 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 should be is abstracted from applications.

Scope

Short-term focus:

...

The scope of this brigade is to make ONOS aware of this new dimension of programmability, in which support for new forwarding/processing capabilities can be added by writing and deploying P4 programs.

The P4 paradigm is very different from the current fixed-function one derived from OpenFlow and abstracted by ONOS. Today, capabilities are tightly coupled to a specific device vendor and model. Different devices expose different capabilities, e.g. match on different headers and support for different actions. Once the network infrastructure has been deployed, capabilities cannot be changed, ONOS can just control them, e.g. installing flow rules. Instead with P4, the capabilities of a device can change in time. P4 programs can be provided by switch vendors, operators, applications or ONOS itself. Moreover, the type of capabilities that can be described with P4 go well beyond that described by OpenFlow.

ONOS APIs and services should capture this new dimension of flexibility. On how this should be done, this is up to the brigade. Before explaining the roadmap, it is useful to clarify two points.

Roadmap

[work in progress]

Short-term focus in 2017:

  • Design and implement southbound support for P4Runtime (via BMv2)
  • Define and implement use cases to assess P4 southbound

How to get involved:

  • 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

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

      • Residential BNG with PPPoE termination DONE - Integrated with fabric.p4 


Long-term focus:
  • Rethink northbound APIs to capture enhanced capabilities of programmable data planes
  • Services to support incremental reprogramming, i.e. deploy a new P4 program to devices while traffic is flowing.

  • Optimize existing P4 programs or auto-generate new ones based on application needs and traffic workload.

Learn more

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

ONOS support for P4 targets

To learn more about P4Runtime

How to get involved

Support for P4 will affect the whole ONOS platform, from Support for P4, and protocol-independence in general, will affect the whole ONOS platform, fromt the southbound to the northbound. The P4 brigade is looking for members willing to contribute! Contact Carmelo Subscribe to the P4 mailing list and introduce yourself or contact Carmelo Cascone (carmelo@onalb.us) or David Boswell (david@onlab.uscarmelo@opennetworking.org) if you are interested.