Bringing OpenFlow s Power to Real Networks

Transcription

1 Bringing OpenFlow s Power to Real Networks Curt Beckmann, Brocade Forwarding Abstractions Working Group ( ONF) April

2 Overview of this preso The Two Schools of OpenFlow OpenFlow Implementation Approaches How Those Work with Devices / Use Cases What s on the Horizon April

3 The Two Schools of OpenFlow The Innovate in the Control Plane School Early OpenFlow grew on normal boxes with OF Decoupling control allows for big, fast innovation Of course, dataplane changes will come too, as before Example: Google s Use Case on Broadcom chips The Innovate in Both Planes School Let s make the data plane fully programmable! Both control and data plane are fertile areas Example: OpenVSwitch with VxLAN, etc, tunnels Keep these in mind April

4 OF Implementation Options Basic OpenFlow Switch 1.0 ( OF1.0 now OFS1.0) OpenFlow Switch 1.0 plus extensions OF Switch 1.3 with a single table OF Switch 1.3 with multiple tables Coming OF Switch 1.4 Negotiable Datapath Models OpenFlow Schools OFS1.0 limits both schools, but especially DP innovation Extensions help both, but especially DP innovation Multiple tables almost seems to depend on DP innovation! Possible that multiple tables were pushed by DP innovator school? April

5 Basic OpenFlow Switch 1.0 The version of OpenFlow in most products today Single Limited match and action capabilities, but useful Other limitations: Fail over, extensibility Flow Entry Matching Fields Actions Stats OpenFlow-Enabled Router Control Plane OpenFlow Client Data Plane OpenFlow Controller OpenFlow protocol Forward packet to a port list Add/remove/modify VLAN Tag Drop packet Send packet to the controller Layer 2 Layer 3 Ingress Port MAC DA MAC SA EtherType VLAN ID P-bits Src Dst Protocol DSCP TCP/UDP src port TCP/UDP dst port April

6 OF Switch 1.0 plus extensions In use today: OpenVSwitch, Google use case Enables near-term solutions to specific problems Weak interop: few apps/controllers/devices support But extensions can (?!) help push OpenFlow forward Same OpenFlow switch architecture Flow Entry Matching Fields Actions Stats OpenFlow-Enabled Router Control Plane OpenFlow Client Data Plane OpenFlow Controller OpenFlow protocol Forward packet to a port list Add/remove/modify VLAN Tag Drop packet Send packet to the controller Layer 2 Layer 3 Ingress Port MAC DA MAC SA EtherType VLAN ID P-bits Src Dst Protocol DSCP TCP/UDP src port TCP/UDP dst port April

7 OF Switch 1.3 with a single table 1 Under development now or soon by many vendors OFS1.1 and OFS1.2 got very little traction, ONF pushed for 1.3 Has many features not in 1.0 (v6, failover, MPLS, groups ) Still gaps, but single-table OFS1.3 is way ahead of 1.0 With single table, same switch architecture as 1.0 Complex forwarding can be supported with clever extensions Flow Entry Matching Fields Actions Stats OpenFlow-Enabled Router Control Plane OpenFlow Client Data Plane OpenFlow Controller OpenFlow protocol Forward packet to a port list Add/remove/modify VLAN Tag Drop packet Send packet to the controller Layer 2 Layer 3 Ingress Port MAC DA MAC SA EtherType VLAN ID P-bits Src Dst Protocol DSCP TCP/UDP src port TCP/UDP dst port April 2013 Note 1: Single table is not listed in spec; it s merely an attractive subset 7

8 OF Switch 1.3 with Multiple Tables Multiple s Multiple flow tables added in OFS1.1 Multiple tables allows for standardized complex forwarding Multiple tables offer lots of power, plus challenges Big architectural changes vs. OFS1.0 What s a flow? Matching Fields Actions Stats Ingress Port MAC DA Flow Entry Forward packet to a port list Add/remove/modify VLAN Tag Drop packet Send packet to the controller Adds GOTO TableN instruction MAC SA Layer 2 Layer 3 EtherType VLAN ID P-bits Src Dst OpenFlow-Enabled Router Control Plane OpenFlow Client Data Plane Protocol DSCP TCP/UDP src port TCP/UDP dst port OpenFlow Controller OpenFlow protocol April

9 Categories of Network Device Devices range from fixed function to very soft ASICs / Merchant silicon: fairly fixed feature sets FPGAs are more flexible within some limits NPUs are essentially soft, some constraints General purpose CPUs are softest, not optimized Trade off: Flexibility has a price: speed/power/density/cost OpenFlow schools: All devices work with control plane innovation GP CPUs & NPUs best for data plane innovation April

10 Device / OF Option Alignment OFS1.0 ASIC / Merchant Si Doable, limited func, many products OFS1.0+ext Depends on the extension! Some products Single Table OFS1.3 Multi-Table OFS1.3 Not too hard, better func, some prods in development FPGA NPU GP Server Doable, limited func, many products Should work, but still depends. Some products Not too hard, better func, some prods in dev Doable, limited func, some products Doable, better functionality, products? (See below) Very hard 2 Very hard 2 Doable, offers very flexible DP forwarding Doable, limited func, some products Doable, better functionality, OpenVSwitch (See below) Doable, offers very flexible DP forwarding Note 2: It is currently very hard to support multiple tables on hardware platforms in a reliably interoperable way. April 2013 Forwarding Abstractions Working Group (FAWG) is focused on addressing this difficulty 10

11 Categories of Use Case Server-based Software Defined Datacenter VMware or Vyatta datacenter virtual networking Software Defined DC with HW gateways Vswitches plus high-bandwidth tunnel terminators Decoupled control, basic forwarding on hw Google Use Case, along with others Decoupled control, rich forwarding on hw E.g. L2 switch + L3 router + ACLs + PBR Layer 4 thru 7 networking services on C/NPU Server load balancing, NAT, firewalls, IDS/S April

12 Server-based SDDC Use Case Server switching changes the game Enables cloud, pushing new envelopes Need for orchestration, automated service deployment Mobility of workload, scale of multi-tenancy Prompting: VxLAN / NVGRE / STT / DOVE Practical Implementation Options GP CPU using OFS1.0/1.3 + ext s (or proprietary) Orchestration vendor can ship special version of OVS Vyatta in a VM as an SDN router Deployment timeframe: Very soon (already?) Interoperable timeframe: months April

13 SDDC w/ HW Gateways Use Case Hardware gateways imply equipment Equipment has higher barrier to change Stronger desire for standard API As compared to the all OVS case Practical Implementation Options CPU for OVS, ASIC/FPGA/NPU for Gateways OFS1.0/1.3 + extensions possible in near term Necessary while OFS is missing needed features Deployment timeframe: 6 months with ext s? Interoperable deployment: 12 to 24 months? April

14 Examples: Decoupled control plane with basic forwarding on hardware platforms Google Use case already deployed Using internally developed controller and equipment Many PoC efforts going on in customer labs now Practical Implementation Options ASIC / Merchant Single table OFS1.0/1.3, supports basic forwarding Single table OFS1.0 supported on all products Single table OFS1.3 in development on many platforms Deployment timeframe: Soon or now (Google) Interoperable deployment: Soon (now?) April

15 Examples: Decoupled control plane with rich forwarding on hardware platforms Google may actually fit here, hard to tell Some PoCs may use rich forwarding Practical Implementation Options ASIC and merchant Si using single table OFS1.0/1.3 with extensions Multiple tables help with rich forwarding, but still too hard Deployment timeframe: 12 to 18 months? Interoperable deployment:18 to 24 months? Likely requires multiple tables + FAWG framework April

16 Examples: Layer 4 thru 7 Networking Services on CPUs and NPUs Not yet viable on OF (the protocol lacks the features), but showing up in cloud orchestration stacks (e.g. OpenStack) Practical Implementation Options NPU and Server-based platforms running proprietary control protocols (using stack plug-ins) In theory, clever extensions to OpenFlow might work Deployment timeframe: now (Amazon) Interoperable deployment: > 18 months? April

17 What s on the Horizon FAWG is enabling Negotiable Datapath Models (NDMs) FAWG enables vendors or others to define common Datapath Models that support specific switch behaviors aimed at certain use cases These Datapath Models include precise (unambiguous) details about how controller will use multiple tables, what features are supported, etc Controllers and devices negotiate an agreed NDM at connect time These common models can make multi-table OF practical, interoperable Testing and Interop Working Group is very supportive of this approach Most architectural work is done, now writing spec OF Switch 1.4 Numerous enhancements identified: bundles Big effort now is creating the working code Board re-instated this requirement last Aug. Good idea, but that doesn t make it easy! April