P4 support in ONOS P4 Brigade Work Days, Seoul (Korea) September 18-29, 2017

Introduction ● In ONOS we care about control and configuration of network devices ● How can we control and configure P4-enabled devices? ● Challenge ○ ONOS initially designed around OpenFlow dataplane ■ ■

Same match/actions as OpenFlow Immutable pipeline

○ With P4… ■ ■

Arbitrary match/actions as defined in a P4 program Mutable pipeline, the same device can support different pipelines

P4 Brigade ● Work started in April 2017 ● Short-term scope: focus on runtime control and protocol independence ○ Assume devices are already configured with a given P4 program ■

Support only first configuration at device connection

○ Allow only minimal amendments to NB APIs ■ ■

E.g. support for non-standard match/actions in flow rules Produce recommendations to later rethink new NB API

● First working support of P4Runtime delivered in ONOS 1.11 “Loon”

Architecture overview Pipeline-agnostic applications

Pipeline-aware application

Events (packet, topology, etc.)

FlowObjectives Intents

FlowRules

2 modes of operations: ● Standard match, actions (i.e. OpenFlow ones) ● Pipeline-specific ones

PI Framework Flow Rule Translation Serv.

Core

Other devices

Driver Protocol

Default

P4Runtime Controller/Client

new

Pipeconf Serv. Future Work

Tofino

BMv2 P4Runtime

gRPC Controller

Device (BMv2, Tofino, Smart NICs, NetFPGA etc.)

Contains everything needed to: ● Understand a P4 program/pipeline ● Control that pipeline (driver) ● Deploy P4 program to device

PI Framework ● PI = protocol/program/pipeline independent ● Set of classes and services to aid in the control of programmable data planes ○

All starting with Pi*, e.g. PiPipeconf, PiTableEntry, etc.

● Modelled around P4 and PSA ○

Define table entries, counters, etc.

● @beta: expect changes

Pipeconf ● Pack together data and code necessary to let ONOS: ○ Understand a P4-defined pipeline ○ Control that pipeline ○ Deploy it to a P4-enabled device

pipeconf.oar

● Provided to ONOS as applications 1. Pipeline Model: Pipeline entities description (i.e. parsed P4 programs) 2. Pipeline-specific driver behaviors (e.g. Pipeliner, Interpreter, etc.) 3. Target-specific extensions ○ Compiled P4 program binaries (e.g. for Tofino, BMv2, etc.) ○ P4Info, needed by driver for ID-name mapping

Pipeconf registered via PipeconfService → available to all ONOS components

Device discovery My-pipeconf Extensions: BMV2_JSON P4INFO

REGISTER

Pipeconf Service Get pipeconf

General Device Provider

PUSH

DeviceID: bmv2:1 P4Runtime Server addr: 192.168.56.1 Port: 5001 PipeconfID: my-pipeconf Driver: bmv2

Connect device Deploy pipeconf

BMv2 driver Open TCP socket to gRPC server Set pipeline config (JSON + P4Info)

netcfg.json

Flow operations Two phase translation: ● Flow Objectives to Flow Rules ● Flow Rules to P4 program-specific table entries

Pipeline-agnostic applications

Intents ONOS Core

FlowObjective API

Device Driver Pipeconf

Flow Objective Pipeliner Flow Rule FlowRuleProgrammable

PI FlowRule Translation Serv.

PI Table Entry P4RuntimeClient

Program Interpreter

Interpreter ● Pipeline-specific driver behaviour (included in the pipeconf) ● Expose methods to let ONOS “understand” a given P4 program ○ Maps protocol-dependent ONOS constructs and PI entities ● Example: flow rule translation ○ Match ■

1:1 mapping between ONOS criteria and P4 header names

○ Action ■ ■ ■

Problem: P4 allows only one action per table entry, ONOS many E.g. header rewrite + output: 1 action with 2 parameters in P4, 2 actions in ONOS How to map many actions to one? Need interpretation logic (i.e. Java code)!

● Used also for other purposes ○

Map ONOS table integer IDs to names, packet I/O operations, table counters, etc.

Flow rules ● ONOS standard criteria and instructions ○

Mapped via interpreter

● P4 program-specific match fields/actions ○

PiCriterion: specify all field matches using ■ ■ ■

○

Field name (e.g. my_tunnel_header.tunnel_id) Match type (exact, ternary, LPM) Value/mask (bytes)

PiInstruction: wrapper around PI table action ■ ■

Action name (as in the P4 program, e.g. set_agress_port) Action parameters ● ●

Parameter name (as in the P4 program, e.g. port_id) Parameter value (bytes)

Packet I/O operations ●

●

●

Packet-in: packet received at a switch port encapsulated and sent to the controller Packet-out: packet generated at the controller sent through a switch port Encapsulation format is defined in the P4 program ○ E.g. field with physical ingress port in packet-in, egress port in packet-out ○ Need interpreter!

App

Packet Request/Manager API

Packet Provider

Program Interpreter

InboundPacket OutboundPacket PacketProgrammable PI Packet Operation P4RuntimeClient

ONOS Core Device Driver Pipeconf

Architecture recap Pipeline-agnostic applications Apps independent from control protocol, device, and pipeline details

Pipeline-aware application

Northbound API (Intents, Flow Objectives, Flow Rules, PI Framework, etc.)

PI Framework independent from southbound protocols (e.g. P4Runtime)

Core Southbound API (Driver/Protocol/Provider)

Different Protocols and Drivers Driver ONOS-P4 integration not mandated to P4Runtime, other protocols can be supported

Protocol

Takeaway ONOS offers capabilities to: ● Store, parse and understand any given P4 program ● Deploy the program to a device ● Control any P4 entities: ○ Table entries, counters, packets I/O, etc. ● Allow for both pipeline-aware and pipeline-agnostic applications ○ Mapping via interpreter ● Integrate P4-enabled devices into heterogenous networks (i.e. P4 + OpenFlow + Netconf) and program them through high level network centric APIs.

While maintaining high availability, scalability and performance key characteristics to the ONOS platform

Questions?

Evolving control and configuration OpenConfig

control control P4Runtime

configuration ONOS

config gNMI

15

gNMI: configuration ● RPCs and behaviors for managing state on a device ○

set/get config, retrieve capabilities, subscribe to notifications

● supports state retrieval (via streaming telemetry or snapshots) ● built on the open source gRPC framework (gRPC ⊂ gNMI) ● gNMI defines a gRPC service using protobuf IDL designed to carry any tree-structured data (not limited to YANG-modeled data) ○ ○

addressable via paths has well-defined serialization

gNMI: configuration ● Port description, port statistics, manage LEDs, etc. ● P4.org API WG suggests using existing OpenConfig Yang based data models → not reinventing the wheel ○

Currently OpenConfig Yang models are supported in ONOS

● gNMI → support from BMv2, PI (switch-side server for runtime control)