OCP: Wedge switch (open-source design) Switch chip! 3 - - PowerPoint PPT Presentation

Programming the Forwarding Plane

Nick ¡McKeown ¡

Stanford ¡University ¡ ¡

Programming the Forwarding Plane

Nick ¡McKeown ¡

Stanford ¡University ¡ ¡

“Why is there a blackbox in my whitebox?”

OCP: ¡Wedge ¡switch ¡(open-­‑source ¡design) ¡

3 ¡

Switch ¡chip! ¡

Linux ¡

Feature ¡ Code ¡

Control ¡Plane ¡

2014: ¡The ¡bare-­‑metal ¡switch ¡

Feature ¡ Code ¡ Feature ¡ Code ¡

Now ¡I ¡can ¡tailor ¡my ¡network ¡to ¡meet ¡my ¡needs! ¡ I ¡can…. ¡

• 1. Quickly ¡deploy ¡new ¡protocols. ¡ ¡
• 2. See ¡what ¡my ¡forwarding ¡plane ¡is ¡doing. ¡
• 3. Put ¡expensive ¡middlebox ¡funcSons ¡into ¡the ¡network. ¡
• 4. Try ¡out ¡beauSful ¡new ¡ideas. ¡Tailor ¡my ¡network ¡to ¡meet ¡my ¡needs. ¡
• 5. DifferenSate. ¡Now ¡I ¡own ¡my ¡intellectual ¡property. ¡

“BeauSful ¡ideas” ¡

• 1. Deploy ¡new ¡protocols ¡and ¡new ¡headers ¡
• 2. Simplify ¡the ¡data ¡plane. ¡Throw ¡out ¡unused ¡protocols. ¡
• 3. Reallocate ¡resources ¡in ¡switches: ¡tables, ¡packet ¡buffers, ¡etc. ¡
• 4. Add ¡new ¡telemetry ¡for ¡debugging ¡and ¡diagnosScs ¡
• 5. Verify ¡network ¡behavior ¡
• 6. Embed ¡“middlebox” ¡funcSons ¡into ¡the ¡network: ¡load-­‑balancing, ¡gateways ¡

and ¡firewalls. ¡

• 7. In-­‑network ¡congesSon ¡control ¡
• 8. New ¡rouSng ¡ ¡and ¡reliability ¡algorithms ¡
• 9. … ¡

Linux ¡

Feature ¡ Code ¡

Control ¡Plane ¡

Driver ¡

Tailoring ¡my ¡network ¡switches ¡today ¡

Feature ¡ Code ¡ Feature ¡ Code ¡ New ¡Feature ¡ Code ¡

Can ¡the ¡CPU ¡forward ¡all ¡my ¡packets? ¡

Packet ¡Forwarding ¡Speeds ¡

0.1 1 10 100 1000 10000 100000 1990 1995 2000 2005 2010 2015 2020 Switch Chip CPU

9 ¡

Gb/s ¡

(per ¡chip) ¡

3.2Tb/s ¡

Packet ¡Forwarding ¡Speeds ¡

0.1 1 10 100 1000 10000 100000 1990 1995 2000 2005 2010 2015 2020 Switch Chip CPU

10 ¡

50x ¡

Gb/s ¡

(per ¡chip) ¡

3.2Tb/s ¡

ConvenSonal ¡Wisdom: ¡ ¡ “Programmable ¡devices ¡are ¡10-­‑100x ¡slower. ¡ They ¡consume ¡much ¡more ¡power ¡and ¡area.” ¡

Wedge ¡

12 ¡

Whitebox ¡CPU ¡

Blackbox ¡switch ¡

My ¡whitebox ¡switch ¡ ¡ has ¡a ¡blackbox ¡switch ¡inside ¡

Domain ¡Specific ¡Processors ¡

GPU ¡

Graphics ¡

Compiler ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡

ApplicaSons ¡ DSP ¡

Signal ¡ Processing ¡

Compiler ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡

ApplicaSons ¡

My ¡codec ¡ My ¡renderer ¡

ConvenSonal ¡wisdom ¡said: ¡programmability ¡too ¡expensive ¡

¡ Then, ¡someone ¡idenSfied: ¡

• 1. The ¡right ¡model ¡for ¡data-­‑parallelism ¡
• 2. Basic ¡underlying ¡processing ¡primiSves ¡

¡ Domain-­‑specific ¡processors ¡were ¡built ¡ Domain-­‑specific ¡languages, ¡compilers ¡and ¡tool-­‑chains ¡ ¡

Fixed ¡Func*on ¡Broadcom ¡Tomahawk: ¡3.2 ¡Tb/s ¡ Programmable ¡Cavium ¡Xpliant: ¡3.2 ¡Tb/s ¡

16 ¡

2010: ¡Why ¡can’t ¡we ¡do ¡the ¡same ¡in ¡networking? ¡

The ¡“match ¡+ ¡acSon ¡pipeline” ¡was ¡emerging ¡

• 1. Suggests ¡a ¡good ¡model ¡for ¡data ¡parallelism ¡
• 2. Suggests ¡a ¡set ¡of ¡basic ¡plumbing ¡primi+ves ¡

¡ We ¡would ¡need ¡a ¡domain-­‑specific ¡chip ¡ We ¡would ¡need ¡a ¡domain-­‑specific ¡language, ¡compilers ¡and ¡tool ¡chains ¡

Can ¡we ¡design ¡a ¡protocol-­‑independent ¡switch ¡chip? ¡ ¡ If ¡so, ¡how ¡expensive ¡is ¡the ¡programmability? ¡

First ¡ajempt: ¡Stanford ¡+ ¡Texas ¡Instruments ¡

[Sigcomm ¡2013] ¡

• Protocol ¡independent ¡switch ¡chip ¡
• Small ¡primiSve ¡acSon ¡set ¡– ¡about ¡6 ¡primiSves ¡
• Huge ¡parallelism ¡possible ¡
• 10-­‑15% ¡chip ¡area ¡and ¡power ¡penalty ¡

This ¡led ¡to ¡a ¡more ¡general ¡architecture… ¡

PISA: ¡Protocol ¡Independent ¡Switch ¡Architecture ¡

21 ¡

¡Programmable ¡ Parser ¡

Match ¡

Memory ¡

AcSon ¡

ALU ¡

PISA: ¡Protocol ¡Independent ¡Switch ¡Architecture ¡

22 ¡

¡Programmable ¡ Parser ¡

Match ¡

Memory ¡

AcSon ¡

ALU ¡

Why ¡now? ¡

Switching ¡Chip ¡Area ¡

Serial ¡ I/O ¡ Serial ¡ I/O ¡ Serial ¡ I/O ¡ Serial ¡ I/O ¡ Serial ¡ I/O ¡ Serial ¡ I/O ¡ Serial ¡ I/O ¡ Serial ¡ I/O ¡ Serial ¡ I/O ¡ Serial ¡ I/O ¡ Serial ¡ I/O ¡ Serial ¡ I/O ¡ Serial ¡ I/O ¡ Serial ¡ I/O ¡ Serial ¡ I/O ¡ Serial ¡ I/O ¡ Serial ¡ I/O ¡ Serial ¡ I/O ¡ Serial ¡ I/O ¡ Serial ¡ I/O ¡ Serial ¡ I/O ¡ Serial ¡ I/O ¡

Parser ¡

40% ¡Serial ¡I/O ¡

¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡

Switching ¡Chip ¡Area ¡

40% ¡Memory ¡ 10% ¡Wire ¡ 10% ¡Logic ¡ Wire ¡ ¡ Logic ¡

2013: ¡programmability ¡cost ¡10-­‑15% ¡increase ¡in ¡area/power ¡

¡ By ¡2018: ¡Difference ¡will ¡be ¡negligible ¡

We ¡need ¡to ¡be ¡able ¡to ¡program ¡PISA ¡devices ¡

P4: Programming Protocol-Independent Packet Processors

Pat Bosshart†, Dan Daly*, Glen Gibb†, Martin Izzard†, Nick McKeown‡, Jennifer Rexford**, Cole Schlesinger**, Dan Talayco†, Amin Vahdat¶, George Varghese§, David Walker**

ABSTRACT

P4 is a high-level language for programming protocol-inde- pendent packet processors. P4 works in conjunction with SDN control protocols like OpenFlow. In its current form, OpenFlow explicitly specifies protocol headers on which it

• perates. This set has grown from 12 to 41 fields in a few

years, increasing the complexity of the specification while still not providing the flexibility to add new headers. In this paper we propose P4 as a strawman proposal for how Open- Flow should evolve in the future. We have three goals: (1) Reconfigurability in the field: Programmers should be able to change the way switches process packets once they are

• deployed. (2) Protocol independence: Switches should not

be tied to any specific network protocols. (3) Target inde- pendence: Programmers should be able to describe packet- processing functionality independently of the specifics of the underlying hardware. As an example, we describe how to use P4 to configure a switch to add a new hierarchical label.

1. INTRODUCTION

Software-Defined Networking (SDN) gives operators pro- grammatic control over their networks. In SDN, the con- trol plane is physically separate from the forwarding plane, and one control plane controls multiple forwarding devices. While forwarding devices could be programmed in many ways, having a common, open, vendor-agnostic interface (like OpenFlow) enables a control plane to control forward- ing devices from different hardware and software vendors.

Version Date Header Fields OF 1.0 Dec 2009 12 fields (Ethernet, TCP/IPv4) OF 1.1 Feb 2011 15 fields (MPLS, inter-table metadata) OF 1.2 Dec 2011 36 fields (ARP, ICMP, IPv6, etc.) OF 1.3 Jun 2012 40 fields OF 1.4 Oct 2013 41 fields

Table 1: Fields recognized by the OpenFlow standard The OpenFlow interface started simple, with the abstrac- tion of a single table of rules that could match packets on a dozen header fields (e.g., MAC addresses, IP addresses, pro- tocol, TCP/UDP port numbers, etc.). Over the past five years, the specification has grown increasingly m plicated (see Table 1), with many more multiple stages of rule tables, to allow switches to expose more of their capabilities to the controller. The proliferation of new header fields shows no signs of

• stopping. For example, data-center network operators in-

creasingly want to apply new forms of packet encapsula- tion (e.g., NVGRE, VXLAN, and STT), for which they re- sort to deploying software switches that are easier to extend with new functionality. Rather than repeatedly extending the OpenFlow specification, we argue that future switches should support flexible mechanisms for parsing packets and matching header fields, allowing controller applications to leverage these capabilities through a common, open inter- face (i.e., a new “OpenFlow 2.0” API). Such a general, ex- tensible approach would be simpler, more elegant, and more future-proof than today’s OpenFlow 1.x standard. Figure 1: P4 is a language to configure switches. Recent chip designs demonstrate that such flexibility can be achieved in custom ASICs at terabit speeds [1, 2, 3]. Pro- gramming this new generation of switch chips is far from easy. Each chip has its own low-level interface, akin to microcode programming. In this paper, we sketch the de- sign of a higher-level language for Programming Proto independent Packet Processors (P4). Figu relationship between P4—used t it how packets are to as Open

ACM Sigcomm Computer Communications Review July 2014

George ¡ Varghese ¡ Amin ¡ ¡ Vahdat ¡ Jen ¡ Rexford ¡ Dan ¡ Daly ¡ Pat ¡ Bosshart ¡ Glen ¡ Gibb ¡ MarSn ¡ Izzard ¡ Dave ¡ Walker ¡ Cole ¡ Schlesinger ¡ Dan ¡ Talayco ¡ Nick ¡ McKeown ¡

P4: ¡Programming ¡protocol-­‑independent ¡packet ¡processors ¡

[ACM ¡CCR ¡2014] ¡

• 1. An ¡intuiSve ¡declaraSve ¡language ¡to ¡describe ¡how ¡packets ¡should ¡

be ¡processed. ¡

• 2. Portable ¡code: ¡Target ¡independence. ¡
• 3. Reconfigure ¡PISA ¡devices ¡in ¡the ¡field ¡(and ¡eventually ¡on ¡the ¡fly). ¡

P4 ¡and ¡PISA ¡

P4 ¡code ¡ Compiler ¡ Compiler ¡Target ¡

¡Programmable ¡ Parser ¡

Why ¡it’s ¡called ¡ “protocol-­‑independent ¡packet ¡processing” ¡

Logical ¡Data-­‑plane ¡View ¡ (your ¡P4 ¡program) ¡ Switch ¡Pipeline ¡

Forwarding ¡plane ¡does ¡not ¡know ¡any ¡ ¡ protocols ¡unSl ¡it ¡is ¡programmed ¡

Queues ¡

Programmable ¡ Parser ¡ Fixed ¡AcSon ¡ Match ¡Table ¡ Match ¡Table ¡ Match ¡Table ¡ Match ¡Table ¡ L2 ¡ IPv4 ¡ IPv6 ¡ ACL ¡ AcSon ¡ALUs ¡ AcSon ¡ALUs ¡ AcSon ¡ALUs ¡ AcSon ¡ALUs ¡ CLK ¡

Match ¡Table ¡ AcSon ¡ALUs ¡

Mapping ¡logical ¡data-­‑plane ¡design ¡ ¡ to ¡physical ¡resources ¡ ¡[NSDI ¡2015] ¡

Queues ¡

Match ¡Table ¡ Match ¡Table ¡ Match ¡Table ¡ L2 ¡Table ¡ IPv4 ¡Table ¡ IPv6 ¡Table ¡ ACL ¡Table ¡ AcSon ¡ALUs ¡ AcSon ¡ALUs ¡ AcSon ¡ALUs ¡ L2 ¡ IPv4 ¡ IPv6 ¡ ACL ¡ Logical ¡Data-­‑plane ¡View ¡ ¡ (your ¡P4 ¡program) ¡ Switch ¡Pipeline ¡ L2 ¡ IPv6 ¡ ACL ¡ IPv4 ¡ L2 ¡AcSon ¡Macro ¡ v4 ¡AcSon ¡Macro ¡ v6 ¡AcSon ¡Macro ¡ ¡ ACL ¡AcSon ¡Macro ¡

33 ¡

Programmable ¡ Parser ¡ CLK ¡

Logical ¡Data-­‑plane ¡View ¡ (your ¡P4 ¡program) ¡ Switch ¡Pipeline ¡

Re-­‑configurability ¡

Queues ¡

L2 ¡Table ¡ IPv4 ¡Table ¡ ACL ¡Table ¡ IPv6 ¡Table ¡

MyEncap ¡

L2 ¡ IPv4 ¡ IPv6 ¡ ACL ¡ MyEncap ¡ L2 ¡AcSon ¡Macro ¡ v4 ¡AcSon ¡Macro ¡ ACL ¡AcSon ¡Macro ¡ AcSon ¡ MyEncap ¡ v6 ¡AcSon ¡Macro ¡ IPv4 ¡ AcSon ¡ IPv4 ¡ AcSon ¡

34 ¡

IPv6 ¡ AcSon ¡ IPv6 ¡ Programmable ¡ Parser ¡ CLK ¡

What ¡does ¡a ¡P4 ¡program ¡look ¡like? ¡

35 ¡

L2 ¡ IPv4 ¡ ACL ¡

MyEncap ¡

MyEncap ¡ IPv6 ¡

header_type ethernet_t { fields { dstAddr : 48; srcAddr : 48; etherType : 16; } } parser parse_ethernet { extract(ethernet); return select(latest.etherType) { 0x8100 : parse_vlan; 0x800 : parse_ipv4; 0x86DD : parse_ipv6; } }

TCP ¡ IPv4 ¡ IPv6 ¡ MyEncap ¡ Eth ¡

header_type my_encap_t { fields { foo : 12; bar : 8; baz : 4; qux : 4; next_protocol : 4; } }

What ¡does ¡a ¡P4 ¡program ¡look ¡like? ¡

36 ¡

L2 ¡ IPv4 ¡ ACL ¡

MyEncap ¡

MyEncap ¡ IPv6 ¡

table ipv4_lpm { reads { ipv4.dstAddr : lpm; } actions { set_next_hop; drop; } } action set_next_hop(nhop_ipv4_addr, port) { modify_field(metadata.nhop_ipv4_addr, nhop_ipv4_addr); modify_field(standard_metadata.egress_port, port); add_to_field(ipv4.ttl, -1); } control ingress { apply(l2); apply(my_encap); if (valid(ipv4) { apply(ipv4_lpm); } else { apply(ipv6_lpm); } apply(acl); }

Mapping ¡P4 ¡programs ¡to ¡a ¡PISA ¡device ¡

Naïve ¡Mapping: ¡Control ¡Flow ¡Graph ¡

Programmable ¡Parser ¡ Match ¡Table ¡ Match ¡Table ¡ Match ¡Table ¡ Match ¡Table ¡ AcSon ¡Macro ¡ AcSon ¡Macro ¡ AcSon ¡Macro ¡ AcSon ¡Macro ¡

L2 ¡ v4 ¡ v6 ¡ ACL ¡

Control ¡Flow ¡ Switch ¡Pipeline ¡

Queues ¡

L2 ¡Table ¡ IPv4 ¡Table ¡ IPv6 ¡Table ¡ ACL ¡ Table ¡

L2 ¡ v6 ¡ ACL ¡ v4 ¡

AcSon ¡ v4 ¡AcSon ¡Macro ¡ v6 ¡AcSon ¡Macro ¡ AcSon ¡

38 ¡

Control ¡Flow ¡Graph ¡

L2 ¡

Table ¡Dependency ¡Graph ¡(TDG) ¡

v4 ¡ v6 ¡ ACL ¡

L2 ¡ v4 ¡ v6 ¡ ACL ¡

Table ¡Dependency ¡Graph ¡

39 ¡

Switch ¡Pipeline ¡

Efficient ¡Mapping: ¡TDG ¡

Queues ¡

Programmable ¡Parser ¡ L2 ¡Table ¡ IPv4 ¡Table ¡ IPv6 ¡Table ¡ Table ¡Dependency ¡Graph ¡ Control ¡Flow ¡Graph ¡

L2 ¡ v4 ¡ v6 ¡ ACL ¡ L2 ¡ v4 ¡ v6 ¡ ACL ¡

AcSon ¡ v4 ¡AcSon ¡Macro ¡ v6 ¡AcSon ¡Macro ¡

40 ¡

ACL ¡ Table ¡ AcSon ¡

Example ¡Use ¡Case: ¡Typical ¡TDG ¡

41 ¡

IPv6-­‑Mcast ¡ EG-­‑ACL1 ¡ EG-­‑Phy-­‑ Meta ¡ IG-­‑Agg-­‑Inu ¡ IG-­‑Dmac ¡ IPv4-­‑Mcast ¡ IPv4-­‑ Nexthop ¡ IPv6-­‑ Nexthop ¡ IG-­‑Props ¡ IG-­‑Router-­‑ Mac ¡ Ipv4-­‑Ecmp ¡ IG-­‑Smac ¡ Ipv4-­‑Ucast-­‑ LPM ¡ Ipv4-­‑Ucast-­‑ Host ¡ Ipv6-­‑Ucast-­‑ Host ¡ Ipv6-­‑Ucast-­‑ LPM ¡ Ipv6-­‑Ecmp ¡ IG_ACL2 ¡ IG_Bcast_St

• rm ¡

Ipv4_Urpf ¡ Ipv6_Urpf ¡ IG_ACL1 ¡ EG_Props ¡ IG_Phy_Meta ¡

ConfiguraSon ¡for ¡16-­‑stage ¡PISA ¡

Exact ¡ TCAM ¡

Mapping ¡Techniques ¡

[NSDI ¡2015] ¡ Compare: ¡Greedy ¡Algorithm ¡versus ¡Integer ¡Linear ¡Programming ¡(ILP) ¡

¡

Greedy ¡Algorithm ¡runs ¡100-­‑Smes ¡faster ¡ ILP ¡Algorithm ¡uses ¡30% ¡fewer ¡stages ¡

¡

RecommendaSons: ¡

• 1. If ¡enough ¡Sme, ¡use ¡ILP ¡
• 2. Else, ¡run ¡ILP ¡offline ¡to ¡find ¡best ¡parameters ¡for ¡Greedy ¡algorithm ¡

P4 ¡code, ¡switch ¡models ¡and ¡compilers ¡available ¡at: ¡hjp://github.com/p4lang ¡ ¡

How ¡to ¡learn ¡more ¡

P4.org ¡– ¡P4 ¡Language ¡ConsorSum ¡

Systems ¡ Targets ¡ Academia ¡ Operators ¡ Original ¡P4 ¡paper ¡authors ¡from ¡Barefoot, ¡Google, ¡Intel, ¡MicrosoF, ¡Princeton ¡University, ¡and ¡Stanford ¡University ¡ ¡

Our ¡current ¡research ¡projects ¡

• 1. PISCES: ¡P4 ¡as ¡a ¡front-­‑end ¡to ¡configure ¡OVS ¡(with ¡Ben ¡Pfaff ¡and ¡Princeton) ¡
• 2. PERC: ¡Fast ¡congesSon ¡control ¡by ¡proacSve, ¡direct ¡calculaSon ¡of ¡flow ¡rates ¡in ¡

the ¡forwarding ¡plane. ¡

• 3. Domino: ¡A ¡higher ¡level ¡language ¡(with ¡MIT). ¡Stateful ¡processing ¡for ¡P4. ¡ ¡
• 4. PIFO: ¡A ¡hardware ¡abstracSon ¡for ¡programmable ¡packet ¡scheduling. ¡

46 ¡

PISCES: ¡Protocol ¡Independent ¡Sozware ¡Hypervisor ¡Switch ¡

Mohammad ¡Shahbaz*, ¡Sean ¡Choi, ¡Jen ¡Rexford*, ¡Nick ¡Feamster*, ¡Ben ¡Pfaff, ¡NM ¡

Problem: ¡Adding ¡new ¡protocol ¡feature ¡to ¡OVS ¡is ¡complicated ¡

• Requires ¡domain ¡experSze ¡in ¡kernel ¡programming ¡and ¡networking ¡
• Many ¡modules ¡affected ¡
• Long ¡QA ¡and ¡deployment ¡cycle: ¡typically ¡9 ¡months ¡

Approach: ¡Specify ¡forwarding ¡behavior ¡in ¡P4; ¡compile ¡to ¡modify ¡OVS ¡

¡

QuesSon: ¡How ¡does ¡the ¡PISCES ¡switch ¡performance ¡compare ¡to ¡OVS? ¡

NaSve ¡OVS ¡expressed ¡in ¡P4 ¡

VLAN Ingress Processing

Match: ingress_port vlan.vid Action: add_vlan no_op

MAC Learning

Match: eth.src Action: learn no_op

Switching

Match: eth.dst vlan.vid Action: forward bcast

Routing

Match: ip.dst Action: nexthop drop

Routable

Match: eth.src eth.dst vlan.vid Action: no_op

ACL

Match: ip.src,ip.dst ip.prtcl, port.src,port.dst Action: no_op drop

VLAN Egress Processing

Match: egress_port vlan.vid Action: remove_vlan no_op

route

Complexity ¡Comparison ¡

40x ¡reducSon ¡in ¡LOC ¡ 20x ¡reducSon ¡in ¡method ¡size ¡

Code ¡mastery ¡no ¡longer ¡needed ¡

A ¡long-­‑term ¡aspiraSon ¡

NIC ¡ NIC ¡

P4 ¡Compiler ¡

P4 ¡ code ¡ P4 ¡ code ¡ P4 ¡ code ¡ P4 ¡ code ¡ P4 ¡ code ¡ P4 ¡ code ¡ P4 ¡ code ¡

AutomaScally ¡parSSon ¡ ¡ and ¡generate ¡code ¡

Declared ¡network ¡forwarding ¡behavior ¡

<The ¡End> ¡

51 ¡