1 of 86

P4 Developer Day Spring 2019

Advanced Track��Building an SRv6-enabled fabric

with P4 and ONOS

These slides:

http://bit.ly/onos-p4-srv6

Exercises and VM:�http://bit.ly/onos-p4-srv6-repo

2 of 86

Instructors

Yi Tseng 曾毅�ONF

Brian O’Connor�ONF

Carmelo Cascone�ONF

3 of 86

Before we start...

Get USB keys with VM from instructors

Or download: http://bit.ly/onos-p4-srv6-repo

Copy and import VM into VirtualBox

User: sdn - Password: rocks

Update ONOS inside VM (requires Internet access)

cd ~/tutorial
git pull origin master
make onos-upgrade
make app-build

4 of 86

Why SDN?

All of the exercises could be completed with a traditional, embedded control plane, but SDN:

Makes programming the devices a data structures problem rather than a distributed protocols problem
Vastly simplifies the set of protocols “on the wire”
Makes it easier to reason and verify end-to-end network state
Means less code (which, hopefully, can be implemented more quickly and with fewer bugs)

5 of 86

Why SRv6?

Improves the status-quo for tunnelling (VxLAN, GRE) with similar overhead and superior visibility
Improves the status-quo for segment routing (MPLS) by enabling non-SR nodes to participate and reusing the RIB
Enables policies to include data plane processing functions that can either be defined in P4 or offloaded to CPU/FPGA/etc.

SRv6 is a good example of an up and coming protocol that is easy to implement quickly and iterate on in P4.

6 of 86

Goal of this session

Learn the basics of P4, P4Runtime and ONOS
Show you the “big picture” of P4

Acquire enough knowledge to build full-stack network applications
Go from a P4 idea to an end-to-end solution

Learn the tools to practically experiment with it

ONOS

Your P4 program

Your App

P4 switch

P4Runtime

Runtime control

SDN control plane

SDN apps

7 of 86

Exercise 1: Packet I/O

Goal: Enable the control plane to do link and host discovery

Exercise: Add support for packet-ins from the switch to the control plane and packet-outs from the control plane to the switch

ONOS (Control Plane)

switch

8 of 86

Exercise 2: Bridging

Goal: Enable hosts on the same IPv6 subnet that are connected to the same switch (leaf) to send and receive Ethernet frames to each other

Exercise: Add support for Ethernet bridging in the P4 program, then populate bridging entries using the control plane

h1a

h1b

leaf1

h1c

9 of 86

Exercise 3: Routing

Goal: Enable hosts connected to different leaves in the leaf-spine topology to send IPv6 packets to each other using multiple paths

Exercise: Add support for IPv6 routing to the P4 program, then insert static ECMP-based routing rules using static routes from the topology

leaf1

leaf2

spine1

spine2

10 of 86

Exercise 4: Segment Routing

Goal: Steer traffic between hosts to use a specific path that is defined at the source node using an SRv6 policy

Exercise: Add support for part of the SRv6 draft standard, then insert SRv6 policies using the ONOS CLI

h2

leaf1

leaf2

spine1

spine2

h4

11 of 86

Tutorial Topology

h1a

MAC: 00:00:00:00:00:1a

IP: 2001:1:1::a/64

ONOS (Control Plane)

spine1

MAC: 00:bb:00:00:00:00:01

SID: 3:201:2::

spine1

MAC: 00:bb:00:00:00:00:02

SID: 3:202:2::

leaf1

MAC: 00:aa:00:00:00:00:01

SID: 3:101:2::

leaf2

MAC: 00:aa:00:00:00:00:01

SID: 3:102:2::

h1b

MAC: ...:00:1b

IP: 2001:1:1::b/64

h1c

MAC: ...:00:1c

IP: 2001:1:1::c/64

h2

MAC: 00:00:00:00:00:20

IP: 2001:1:2::1/64

h3

MAC: 00:00:00:00:00:30

IP: 2001:2:3::1/64

h4

MAC: 00:00:00:00:00:40

IP: 2001:2:4::1/64

IPv6 Gateway Addresses on leaf interfaces are in the same subnet as the host with address ending with …::ff

12 of 86

Software tools introduction

13 of 86

P4Runtime recap
Stratum-BMv2
ONOS
Packet Test Framework (PTF)

14 of 86

P4Runtime�Runtime control API for P4-defined data planes

15 of 86

P4Runtime v1.0

Released on Jan 2019
Open source specification

Started by Google and Barefoot in mid-2016
Contributions by many industry professionals

Based on continuous implementation feedbacks from Google and ONF

First ONOS demo in Oct 2017

https://p4.org/p4-spec/

https://github.com/p4lang/p4runtime

16 of 86

P4Runtime overview

Protobuf-based API definition

Efficient wire format
Automatically generate code to serialize/deserialize messages for many languages

gRPC-based transport

Automatically generate high-performance client/server stubs in many languages
Pluggable authentication and security
Bi-directional stream channels

P4-program independent

Allow pushing new P4 programs to reconfigure the pipeline at runtime

Equally good for remote or local control plane

With or without gRPC

16

P4Runtime client�(ONOS)

p4runtime.proto (API)

P4Runtime server

(e.g. Stratum)

Target driver

P4 target

17 of 86

P4Runtime main features

Batched read/writes

Table entries, action groups, counters, registers, etc.

Master-slave arbitration

For control plane high-availability and fault-tolerance

Multiple master controllers via role partitioning

E.g. local control plane for L2, remote one for L3

Flexible and efficient packet I/O

OpenFlow-like packet-in/out with arbitrary metadata
Digests, i.e. batched notification to controller with subset of packet headers

Designed around PSA architecture

But can be extended to others via Protobuf “Any” messages

18 of 86

P4 compiler workflow

P4 compiler generates 2 outputs:

Target-specific binaries

Used to realize switch pipeline�(e.g. binary config for ASIC, BMv2 JSON, etc.)

P4Info file

“Schema” of pipeline for runtime control

Captures P4 program attributes such as tables, actions, parameters, etc.

Protobuf-based format
Target-independent compiler output

Same P4Info for SW switch, ASIC, etc.

18

test.p4

test.json

P4Runtime client

p4runtime.proto

P4Runtime server

Target driver

BMv2 simple_switch

p4c-bm2-ss�(compiler)

test.p4info

Full P4Info protobuf specification:

https://github.com/p4lang/p4runtime/blob/master/proto/p4/config/v1/p4info.proto

19 of 86

P4Info example

19

...

action ipv4_forward(bit<48> dstAddr,

bit<9> port) {

eth.dstAddr = dstAddr;

metadata.egress_spec = port;

ipv4.ttl = ipv4.ttl - 1;

}

...

�table ipv4_lpm {

key = {

hdr.ipv4.dstAddr: lpm;

}

actions = {

ipv4_forward;

...

}

...

}

basic_router.p4

actions {

id: 16786453

params {

id: 1

bitwidth: 48

...

id: 2

bitwidth: 9

}

...

tables {

id: 33581985

match_fields {

id: 1

bitwidth: 32

match_type: LPM

}

action_ref_id: 16786453

}

basic_router.p4info

P4 compiler

20 of 86

P4Runtime table entry WriteRequest example

20

device_id: 1

election_id { … }

updates {

type: INSERT

entity {

table_entry {

table_id: 33581985

match {

field_id: 1

lpm {

value: "\n\000\001\001"

prefix_len: 32

}

action {

action_id: 16786453

params {

param_id: 1

value: "\000\000\000\000\000\n"

}

params {

param_id: 2

value: "\000\007"

…

action ipv4_forward(bit<48> dstAddr,

bit<9> port) {

/* Action implementation */

}�table ipv4_lpm {

key = {

hdr.ipv4.dstAddr: lpm;

}

actions = {

ipv4_forward;

...

}

...

}

hdr.ipv4.dstAddr=10.0.1.1/32� -> ipv4_forward(00:00:00:00:00:10, 7)

basic_router.p4

Logical view of table entry

WriteRequest message (protobuf text format)

Control plane�generates

21 of 86

Stratum

Production-grade reference implementation of P4Runtime server

22 of 86

Stratum overview

Multi-vendor switch implementation of 3 open APIs

Control: P4Runtime
Configuration: gNMI with OpenConfig models

Port discovery and configuration, stats collections
Power, temp, fans, other peripherals
etc.

Operations: gNOI (not used in this tutorial)

Device reboot, software upgrade, push certificates, etc.

23 of 86

Stratum architecture with HW switches

kernel

hardware

user

Common (HW agnostic)

Chip specific

Platform specific

Chip and Platform specific

P4Runtime

gNMI

gNOI

Switch Broker Interface

Table Manager

Node/Chip Manager

Chassis Manager

Chip Abstraction Managers

Platform Manager

Remote or Local Controller(s)

Switch SDK

Platform API

Switch Chip Drivers

Platform Drivers

Switch Chip(s)

Peripheral(s)

p4lang/PI and fpm-based implementations

Stratum switch agent

ONLP

24 of 86

Stratum-BMv2

kernel

user

Common (HW agnostic)

Chip specific

Platform specific

Chip and Platform specific

P4Runtime

gNMI

gNOI

Switch Broker Interface

Table Manager

Node/Chip Manager

Chassis Manager

Chip Abstraction Managers

Platform Manager

Remote or Local Controller(s)

BMv2 simple_switch

p4lang/PI

Stratum switch agent

veth

...

25 of 86

ONOS

A control plane for P4Runtime devices

26 of 86

What is ONOS?

Open Network Operating System (ONOS)
Provides the control plane for a software-defined network

Logically centralized remote controller
Provides APIs to make it easy to create apps to control a network

Runs as a distributed system across many servers

For scalability, high-availability, and performance

Focus on service provider for access/edge applications

In production with a major US telecom provider

26

27 of 86

ONOS releases

4-month release cycles

Avocet (1.0.0) 2014-12

…

Loon (1.11.0) 2017-08 (Initial P4Runtime support)

…

Raven (2.1.0) 2019-04 (latest release - used today)

27

28 of 86

ONOS architecture

28

OpenFlow

gNMI

P4Runtime

...more

OVS

BMv2

Barefoot

Cavium

Mellanox

Ciena

Cisco

Corsa

Fujitsu

HP

Huawei

Juniper

Lumentum

Microsemi

Polatis

...

FlowRule API

Topology API

FlowObjective API

Intent API

Packet API

...

Distributed core

State management, notifications, high-availability & scale-out

Northbound API

Device/protocol-agnostic

Java, REST, CLI, gRPC

Device driver

Allow device-specific variants of standard protocols

Shared protocol libraries

Apps

Control and configure the network

using a global topology view�and independently of the device-specific details

29 of 86

Network programming API

29

OpenFlow

P4Runtime

Netconf

...

Flow Rule

OF-DPA Pipeline

Single Table Pipeline

P4 Program

Defined Pipeline

Flow Objective

Host-Host

Single-Point to Multi-point

Protected

Intent

Abstract

to

concrete

Mapping through drivers

30 of 86

Flow objective example

30

BRCM OF-DPA OpenFlow 1.3 Pipeline

HP OpenFlow 1.3 Pipeline

Peering Router

Match on Switch port, MAC address, VLAN, IP

FlowObjective Service

HP Pipeliner

BRCM OF-DPA Pipeliner

31 of 86

Driver behaviors in ONOS

ONOS defines APIs to interact with device called “behaviors”

DeviceDescriptionDiscovery → Read device information and ports
FlowRuleProgrammable → Write/read flow rules
PortStatisticsDiscovery → Statistics of device ports (e.g. packet/byte counters)
Pipeliner → FlowObjective-to-FlowRules mapping logic
Etc.

Behavior = Java interface
Driver = collection of one or more behavior implementations

Implementations use ONOS protocol libraries to interact with device

31

Driver 1

P4Runtime

App

ONOS

Driver 2

OpenFlow

32 of 86

ONOS key takeaways

Apps are independent from switch control protocols

I.e., same app can work with OpenFlow and P4Runtime devices

Different network programming APIs

FlowRule API – pipeline-dependent
FlowObjective API – pipeline-independent

Drivers translate 1 FlowObjective to many FlowRule

FlowObjective API enables application portability

App using FlowObjectives can work with different pipelines
For example, switches with different P4 programs

32

33 of 86

P4 and P4Runtime support in ONOS

34 of 86

P4 and P4Runtime support in ONOS

ONOS originally designed to work with OpenFlow and fixed-function switches.

Extended it to:

Allow ONOS users to bring their own P4 program

For example, today’s tutorial

Allow existing built-in apps to control any P4 pipeline without changing the app

Today: topology and host discovery via packet-in / packet-out

Allow apps to control custom/new protocols as defined in the P4 program

35 of 86

Pipeconf - Bring your own pipeline!

Package together everything necessary to let ONOS understand, control, and deploy an arbitrary pipeline
Provided to ONOS as an app

Can use .oar binary format for distribution

35

pipeconf.oar

Pipeline model

Description of the pipeline understood by ONOS
Automatically derived from P4Info

Target-specific extensions to deploy pipeline to device

E.g. BMv2 JSON, Tofino binary, etc.

Pipeline-specific driver behaviors

E.g. “Pipeliner” implementation: logic to map FlowObjectives to P4 pipeline

36 of 86

Pipeconf support in ONOS

36

Pipeline-agnostic�app

Stratum

Pipeline-specific�FlowRules, Groups, Meters, etc

Translation services�Uses pipeconf’s pipeline drivers

Protocol

Core

Events�(packet, topology, etc.)

P4Runtime

Pipeline-aware�app

Pipeconf Store

Pipeconf

(.oar)

FlowObjectives

gRPC

ONOS

Device drivers

stratum-tofino

stratum-bmv2

gNMI

gNOI

37 of 86

Device discovery and pipeconf deploy

37

Device Provider

Pipeconf Service

Device Handshaker

ONOS core

Device/protocol driver

Pipeconf

Pipeline Programmable

my-pipeconf.oar

Extensions:

BMV2_JSON

P4INFO

REGISTER

1

Get pipeconf

Bind pipeconf+device driver

DeviceID: bmv2:1

Management address

- grpc://192.168.56.1:5001

Pipeconf: my-pipeconf

Driver: stratum-bmv2

PUSH

netcfg.json

2

ONOS

Device bmv2:1

Connect device

Open connection to gRPC server

3

Deploy pipeconf

SetPipelineConfig

4

38 of 86

Flow operations

38

Flow Rule

Translation Serv.

P4Runtime Client

Pipeliner

Pipeline-agnostic�App

Flow Objective API

P4Runtime Flow Rule Behaviour

Pipeconf-based 3 phase translation:�

1. Flow Objective → Flow Rule

Maps 1 flow objective to many flow rules

2. Flow Rule → Table entry

Maps standard headers/actions to P4-defined ones E.g. ETH_DST→“hdr.ethernet.dst_addr”

3. Table Entry → P4Runtime message

Maps P4 names to P4Info numeric IDs

Flow Rules�(many)

Table Entry

Pipeline Interpreter

ONOS Core

Device/protocol driver

Pipeconf driver

Pipeline-aware App

Flow Rule API

Flow Objective

P4Runtime protobuf messages

P4Info

Define flow rules using same headers/action names as in the P4 program. E.g match on “hdr.my_protocol.my_field”

39 of 86

P4Runtime support in ONOS 2.1.0 (Raven)

39

P4Runtime control entity	ONOS API
Table entry	Flow Rule Service, Flow Objective Service Intent Service
Packet-in/out	Packet Service
Action profile group/members, PRE multicast groups, clone sessions	Group Service
Meter	Meter Service (indirect meters only)
Counters	Flow Rule Service (direct counters) P4Runtime Client (indirect counters)
Pipeline Config	Pipeconf

Unsupported features - community help needed!�Parser value sets, registers, digests

40 of 86

ONOS+P4 workflow recap

Write P4 program and compile it

Obtain P4Info and target-specific artifacts (e.g. BMv2 JSON)

Create pipeconf

Implement pipeline-specific driver behaviours (Java):

Pipeliner (optional - if you need FlowObjective mapping)
Pipeline Interpreter (to map ONOS headers/actions to P4 program ones)
Other driver behaviors that depend on pipeline

Use existing pipeline-agnostic built-in apps

Apps that program the network using FlowObjectives

Write new pipeline-aware apps

Apps that use same string names of tables, headers, and actions as in the P4 program

40

41 of 86

Packet Test Framework (PTF)

42 of 86

PTF overview

Python-based dataplane test framework
Similar to OFTest framework

But focuses on the dataplane and is independent of OpenFlow/P4Runtime

P4Runtime lib provided with tutorial starter code

Add/remove table entries, groups, packet-in/out, etc.

PTF-based test

P4Runtime

Bmv2.json, P4Info

Table entries

Produce input (packet)

Verifies output

Stratum

BMv2 simple_switch

veth

43 of 86

Exercise 1

44 of 86

Environment overview

ONOS

single instance

LLDP Provider�(link discovery)

Host Provider�(host discovery)

SRv6�App

SRv6�Pipeconf

REGISTER

Mininet script

topo.py

BMv2’s simple_switch_target

stratum_bmv2

BMv2/Stratum Driver

P4Runtime, gNMI

netcfg.json

Pipeline-agnostic apps�use FlowObjective API

Pipeline-aware app�use FlowRule API

IPv6 hosts�(Linux net namespace)

45 of 86

LLDP Provider App

Provides means to discover network links by injecting LLDP packets in the network

Reacts to device events (e.g., new switch connection)

Periodically sends LLDP packets via packet-out for each switch port

Install packet-in requests (flow objective) on each device

Match: ETH_TYPE = LLDP, BDDP
Instructions: OUTPUT(CONTROLLER)

46 of 86

Host Provider App

Learns location of hosts and IP-MAC mapping by intercepting ARP, NDP and DHCP packets

Reacts to device events (e.g., new switch connection)

Install packet-in requests (flow objective) on each device

Match: ARP, NDP
Instructions: OUTPUT(CONTROLLER)

Parses sniffed packets to discover hosts

47 of 86

SRv6 pipeconf

ID: org.p4.srv6-tutorial
Driver behaviors:

Pipeliner

Maps FlowObjective from LLDP and Host provider apps
Use P4Runtime/v1model clone sessions to send packets to the CPU (packet-in)

Interpreter

Maps packet-in/out to/from ONOS internal representation
Maps ONOS known headers (e.g. ETH_TYPE) to P4Info-specific ones (e.g. “hdr.ethernet.type”)

Target-specific extensions

bmv2.json, p4info.txt

48 of 86

netcfg.json (devices)

{

"devices": {

"device:leaf1": {

"basic": {

"managementAddress": "grpc://127.0.0.1:50001?device_id=1",

"driver": "stratum-bmv2",

"pipeconf": "org.p4.srv6-tutorial"

},

"srv6DeviceConfig": {

"myStationMac": "00:aa:00:00:00:01",

"mySid": "3:101:2::",

"isSpine": false

}

},

...

49 of 86

ONOS terminology

Criteria

Match fields used in a FlowRule

Traffic Treatment

Actions/instructions of a FlowRule

Pi* classes

Classes used to describe protocol-independent constructs
Equivalent of P4Runtime entities
Examples

PiTableId: name of a table as in the P4 program
PiMatchFieldId: name of a match filed in a table
PiCriterion: match fields each one defined by its name and value
PiAction: action defined by its name and list of parameters

50 of 86

Exercise 1: Software tools basics and packet I/O

Goal: Enable ONOS to do link and host discovery using built-in apps

Exercise:

Modify packet-in/out handling in P4 code
Run PTF tests
Modify pipeconf Interpreter (to map packet-in/out)
Start ONOS; load app with pipeconf; start Mininet
Verify that link discovery works

51 of 86

Exercise 1: Get Started

Open:

~/tutorial/README.md

~/tutorial/EXERCISE-1.md

Or use GitHub markdown preview:

http://bit.ly/onos-p4-srv6-repo

Solution:

~/tutorial/solution

You can work on your own using the instructions.�Ask for instructors help when needed.

Slides: http://bit.ly/onos-p4-srv6

Update tutorial repo�(requires Internet access)

cd ~/tutorial

git pull origin master

make onos-upgrade

make app-build

P4 language cheat sheet:

http://bit.ly/p4-cs

52 of 86

Exercise 2 - Bridging

53 of 86

Exercise 2: Overview

Add basic L2 bridging functionality to leaf switches

Replicate packets to host-facing interfaces if the destination is multicast or broadcast, such as for NDP Neighbor Advertisement/Solicitation (NA/NS)
Provide unicast forwarding for “learned” hosts
ONOS learns about hosts by intercepting NDP NA/NS messages

54 of 86

Exercise topology overview

h1a

h1b

h1c

ONOS

leaf1

55 of 86

Host discovery (NDP NS)

h1a

h1b

h1c

leaf1

Multicast replication + CPU clone session

NDP NS message

(e.g. who has h1b MAC addr)

ONOS

Learn h1a

Insert L2 unicast entry for h1a

2

1

3

56 of 86

Host discovery (NDP NA)

h1a

h1b

h1c

leaf1

Unicast forwarding + clone session

NDP NA message

(e.g. h1b is at 00:00:...)

ONOS

Insert L2 unicast entry for h1b

1

2

3

57 of 86

Unicast forwarding

h1a

h1b

h1c

leaf1

Unicast forwarding

Unicast ethernet frame

ONOS

58 of 86

Exercise 2 Goal

Create P4 table(s) to handle both unicast and broadcast/multicast packets

Note you might need to handle IPv6 multicast addresses 33:33:**:**:**:** with ternary match

Modify PTF test case(s) to verify P4 implementation

ptf/tests/bridging.py

Modify L2 component in ONOS app

app/src/main/java/org/p4/p4d2/tutorial/L2BridgingComponent.java

Test on Mininet

59 of 86

Exercise 2: Get Started

Open:

~/tutorial/EXERCISE-2.md

Or use GitHub markdown preview:

http://bit.ly/onos-p4-srv6-repo

Solution:

~/tutorial/solution

Extra Credit Ideas:

Solve the host discovery race condition
Remove inactive/old host entries periodically
Explore the @name & @globalname annotations to shorten tables, actions, etc.

You can work on your own using the instructions.�Ask for instructors help when needed.

Slides: http://bit.ly/onos-p4-srv6

Update tutorial repo�(requires Internet access)

cd ~/tutorial

git pull origin master

make onos-upgrade

make app-build

P4 language cheat sheet:

http://bit.ly/p4-cs

60 of 86

Exercise 3 - IPv6 routing

61 of 86

Exercise 3: Overview

Make the topology behave like a standard IPv6 fabric.

Leaf switches should reply to NDP NS messages to resolve their “gateway” address
Process packets through the routing pipeline if the destination mac address is the “gateway” mac address
Map IPv6 prefixes (LPM) to next hops (routing table)
Allow mapping to multiple next hops for leaf switches, i.e., use ECMP when forwarding to spines.

62 of 86

IP unicast routing

Host 1

Router 1

Host 2

2001:1::/64

2001:3::/64

Packet

Eth Src: Host 1

Eth Dst: Router 1

IP Src: Host 1

IP Dst: Host 2

Router 2

63 of 86

IP unicast routing

Host 1

Router 1

Host 2

2001:1::/64

2001:3::/64

Router 2

Packet

Eth Src: Router 1

Eth Dst: Router 2

IP Src: Host 1

IP DSt: Host 2

64 of 86

IP unicast routing

Host 1

Router 1

Host 2

2001:1::/64

2001:3::/64

Packet

Eth Src: Router 2

Eth Dst: Host 2

IP Src: Host 1

IP DSt: Host 2

Router 2

65 of 86

Neighbor Discovery Protocol

Host 1

Router 1

2001:1::ff/64

2001:1::1a/64

Default gateway is 2001:1:ff

66 of 86

Neighbor Discovery Protocol

Host 1

Router 1

2001:1::ff/64

2001:1::1a/64

Router/Neighbor Solicitation

Who has MAC of 2001:1::ff?

NDP

67 of 86

Neighbor Discovery Protocol

Host 1

Router 1

2001:1::ff/64

2001:1::1a/64

Router/Neighbor Advertisement

2001:1::ff is at 00:c0:ff:ee:00

NDP

Generated by the P4 program!

68 of 86

Same-leaf routing

h1a

h1b

h1c

h2

h3

h4

leaf1

leaf2

spine1

spine2

2001:1:1::/64

2001:1:2::/64

2001:2:3::/64

2001:2:4::/64

69 of 86

Same-leaf routing

h1a

h1b

h1c

h2

h3

h4

leaf1

leaf2

spine1

spine2

2001:1:1::/64

2001:1:2::ff

2001:2:3::/64

2001:2:4::/64

IP unicast on same leaf

70 of 86

ECMP

h1a

h1b

h1c

h2

h3

h4

leaf1

leaf2

spine1

spine2

2001:1:1::/64

2001:1:2::/64

2001:2:3::/64

2001:2:4::/64

Route to other leaves via ECMP

71 of 86

Exercise 3: Overview

Add tables to P4 program to handle routing of IPv6 packets

Use P4 action selector groups to provide ECMP

Use PTF to verify your P4 code

Modify the ONOS IPv6 routing app

Test on Mininet

72 of 86

Exercise 3: Get Started

Open:

~/tutorial/EXERCISE-3.md

Or use GitHub markdown preview:

http://bit.ly/onos-p4-srv6-repo

Solution:

~/tutorial/solution

Extra Credit:

Use ONOS path service to compute paths for routes
Feed routes from a dynamic protocol agent (e.g. IS-IS, BGP, etc.)

You can work on your own using the instructions.�Ask for instructors help when needed.

Slides: http://bit.ly/onos-p4-srv6

Update tutorial repo�(requires Internet access)

cd ~/tutorial

git pull origin master

make onos-upgrade

make app-build

P4 language cheat sheet:

http://bit.ly/p4-cs

73 of 86

Exercise 4: Segment Routing v6

74 of 86

Segment Routing Primer

Segment routing is a source routing method
Source nodes define a path for the traffic as a list of waypoints (or segments)
Waypoint (or endpoint) nodes perform basic packet transformation (e.g. popping a label or modifying the destination address), then forward the packet to the next waypoint

Typically, MPLS labels are used to define segments, and the source routing policy is encoded as an MPLS label stack for each packet.

75 of 86

SRv6: What and Why?

An SRv6 endpoint is identified using 128 bit address called a Segment Identifier (SID)
SRv6 uses an IPv6 header called the Segment Routing Extension Header (SRH) to encode the list of segments

SRv6 packets use IPv6 routing tables to forward packets to the next segment, which means there isn’t another forwarding database (as is the case for MPLS) and non-SRv6 aware switches can participate in traffic forwarding (between segments).

76 of 86

SRv6 Segment Identifier (SID)

Locator: used to route packet to the endpoint (waypoint)

Function ID: specifies type of processing to be performed by the endpoint

Function Args: (optionally) specified parameters to be interpreted by the function (e.g. VRF ID, customer ID, QoS policy)

The network operator can determine the bit-length for each of these fields in the SID.

Locator

Function ID

Function Args

77 of 86

SRv6-aware Nodes

Endpoint Node

A participating waypoint in an SRv6 policy that will modify the SRv6 header and perform a specified function
Example function: “End”

Decrease the segments left field, update the IPv6 destination address, and forward the packet

Transit Node

A switch that will participate in traffic forwarding, but is not specified in the segment list
By default, perform the “T” behavior: forward the packet normally
Example function: “T.Insert”

Insert an SRv6 policy, update the IPv6 destination address, and forward the packet

78 of 86

Sending a ping from one host to another

Switch 1

C:1::

Source Host

A::

Switch 2

C:2::

Switch 4

C:4::

Destination Host

B::

Next Header: ICMPv6 (58)

Hop Limit: 64

Source: A::

Destination: B::

IPv6 Header

Switch 3

No SID

79 of 86

Switch 1 inserts SRv6 policy (T.Insert)

Source Host

A::

Next Header: Routing (43)

Hop Limit: 63

Source: A::

Destination: C:2:F::

Next Header: ICMPv6 (58)

Type: Segment Routing (4)

Segments Left: 2

Last Entry: 2

Segments[0]: B::

Segments[1]: C:4:F::

Segments[2]: C:2:F::

IPv6 Header

SRv6 Header

Destination Host

B::

Switch 1

C:1::

Switch 2

C:2::

Switch 4

C:4::

Switch 3

No SID

SRv6 Policy: Send traffic to B:: through C:2:: (function F) and then C:4:: (function F)

80 of 86

Switch 2 performs End function

Source Host

A::

Next Header: Routing (43)

Hop Limit: 62

Source: A::

Destination: C:4:F::

Next Header: ICMPv6 (58)

Type: Segment Routing (4)

Segments Left: 1

Last Entry: 2

Segments[0]: B::

Segments[1]: C:4:F::

Segments[2]: C:2:F::

IPv6 Header

SRv6 Header

Destination Host

B::

Switch 1

C:1::

Switch 2

C:2::

Switch 4

C:4::

Switch 3

No SID

Switch 2 (C:2::, function F) modifies the SRv6 and IPv6 headers, and then forwards the packet

81 of 86

Switch 3 forwards packet normally

Source Host

A::

Next Header: Routing (43)

Hop Limit: 61

Source: A::

Destination: C:4:F::

Next Header: ICMPv6 (58)

Type: Segment Routing (4)

Segments Left: 1

Last Entry: 2

Segments[0]: B::

Segments[1]: C:4:F::

Segments[2]: C:2:F::

IPv6 Header

SRv6 Header

Destination Host

B::

Switch 1

C:1::

Switch 2

C:2::

Switch 4

C:4::

Switch 3

No SID

Switch 3 simply forwards the packet

82 of 86

Switch 4 performs End function with PSP

Switch 1

C:1::

Source Host

A::

Switch 2

C:2::

Switch 4

C:4::

Destination Host

B::

Next Header: ICMPv6 (58)

Hop Limit: 60

Source: A::

Destination: B::

IPv6 Header

Switch 3

No SID

SRv6 Header Removed

Switch 4 (C:4::, function F) modifies the SRv6 and IPv6 headers, pops the SRv6 header, and then forwards the packet

83 of 86

Tutorial Topology

h1a

MAC: 00:00:00:00:00:1a

IP: 2001:1:1::a/64

ONOS (Control Plane)

spine1

MAC: 00:bb:00:00:00:00:01

SID: 3:201:2::

spine1

MAC: 00:bb:00:00:00:00:02

SID: 3:202:2::

leaf1

MAC: 00:aa:00:00:00:00:01

SID: 3:101:2::

leaf2

MAC: 00:aa:00:00:00:00:01

SID: 3:102:2::

h1b

MAC: ...:00:1b

IP: 2001:1:1::b/64

h1c

MAC: ...:00:1c

IP: 2001:1:1::c/64

h2

MAC: 00:00:00:00:00:20

IP: 2001:1:2::1/64

h3

MAC: 00:00:00:00:00:30

IP: 2001:2:3::1/64

h4

MAC: 00:00:00:00:00:40

IP: 2001:2:4::1/64

IPv6 Gateway Addresses on leaf interfaces are in the same subnet as the host with address ending with …::ff

84 of 86

Exercise 4: Overview

Add support for SRv6 endpoint and transit functionality in the P4 program

Populate the endpoint (srv6_my_sid) table with an entry that matches the switch’s SID

Complete the function that creates SRv6 policy rules in the transit table so that you can insert new policies using the ONOS CLI

Verify that traffic is being forwarded via the SRv6 policy using the ONOS UI and Wireshark

85 of 86

Exercise 4: Get Started

Open:

~/tutorial/EXERCISE-4.md

Or use GitHub markdown preview:

http://bit.ly/onos-p4-srv6-repo

Solution:

~/tutorial/solution

You can work on your own using the instructions.�Ask for instructors help when needed.

Slides: http://bit.ly/onos-p4-srv6

Update tutorial repo�(requires Internet access)

cd ~/tutorial

git pull origin master

make onos-upgrade

make app-build

P4 language cheat sheet:

http://bit.ly/p4-cs

86 of 86

Summary

What we did:

Implemented Packet I/O, L2, L3 and SRv6 in P4
Wrote a unit tests using PTF
Controlled the pipeline using an ONOS application
Tested the pipeline using Mininet and Stratum-BMv2

Have ideas about improving / extending the tutorial?

Send pull requests!