Protocol Oblivious Forwarding: Unleash the Power of SDN through a Future-Proof Forwarding Plane

1. Protocol Oblivious Forwarding: • Unleash the Power of SDN through a Future-Proof Forwarding Plane • Haoyu Song • Networks Business Unit, Technology Strategy, IP Research • Huawei Technologies, USA

2. What Happened to Your Mobile Phone: A Metaphor Past Now • Download only the apps you need • New features in new software release • Write your own apps • Preloaded with all the features • Get new models for new apps • No way to customize Decoupling the platform and the apps is the key for smart phone’s success. The real value exists in services provided by software. Better hardware can carry and deliver the value better.

3. Network Device Programming Models I can only use the device as- is. I can do what the device has supported. I can do whatever I want. Control Plane Control Plane Management Control Program Control Plane OpenFlow 1.x OpenFlow+ “Black Box” “Gray Box” “White Box” Data Plane Data Plane Data Plane Device Vendor-driven Programmability Device Vendor/Service Provider Split Programmability Service Provider-driven Programmability Closed and proprietary design that meets the pre-defined service requirements Open interface using existing technology building blocks for limited programmability Open interface using generic network programming model, enabling full programmability

4. Current OpenFlow-enabled Device is a “Gray Box” New service required Yes • Does the OF • Spec. support it? Ideal path No Wait for new revision of OF Spec. Wait for the device upgrade to support the new spec. Deploy the software to enable the service • Plane coupling • Protocol/instruction explosion • Stateless/Limited expressivity • Not future-proof • Slow innovation process Protocol-specific semantics forces the forwarding elements (FE) to understand the packet formats and retain the specific packet processing knowledge. The reactive evolving path needs incessant standard revisions to accommodate new features and new protocols.

5. SDN: Operate your Network Device like a PC • Simple & generic instruction set • Ultimate flexibility & extensibility • Upgrade only on performance Service Application API Sys. Call Controller Operating System Driver Instruction Set Forwarding Element CPU system Peripheral SDN Computer System Computer system components have been decoupled from the vertical integration model. SDN is on the track to mimic this transition. But current OpenFlow still doesn’t embrace this model to the full extent.

6. Protocol Oblivious Forwarding: Core Concept ~40 matching header fields defined yet still many uncovered protocols/headers {offset, length} covers any frame based formats Match Table search keys are defined as {offset, length} tuples Instructions/Actions access packet data or metadata using {offset, length} tuples Include other math, logic, move, branching, and jump instructions OFPAT_COPY_TTL_OUT OFPAT_COPY_TTL_IN OFPAT_SET_MPLS_TTL OFPAT_DEC_MPLS_TTL OFPAT_PUSH_VLAN OFPAT_POP_VLAN OFPAT_PUSH_MPLS OFPAT_POP_MPLS OFPAT_SET_NW_TTL OFPAT_DEC_NW_TTL OFPAT_PUSH_PBB OFPAT_POP_PBB and on and on and on … POFAT_SET_FIELD POFAT_ADD_FIELD POFAT_DELETE_FIELD POFAT_MOD_FIELD Period. Action Current OpenFlow POF Packet field parsing and handling are abstracted as generic instructions to enable flexible and future proof forwarding elements. This is simple yet has profound implications to SDN.

7. How to Ask a Dumb FE to Do Smart Things • The fine-grained bit-level manipulations used to be hardcoded or micro-coded in the FE are now explicitly described by controller Is this an IP packet? Data @ {12B, 2B} = 0x0800? DMAC SMAC Type Payload FCS Extract Data @ {30B, 4B}; Use it as key to search LPM table x Use destination IP to search FIB Decrement Data @ {22B, 1B}; If result is 0, drop the packet Process TTL Clear Data @ {24B, 2B}; Use algorithm y to calculate checksum over Data @ {14B, 20B}; Write result @ {24B, 2B} Update Checksum Conventional FE Forwarding Flow POF Forwarding Flow Ethernet/IPv4 Packet Format OpenFlow’shigh level semantics (“what”) is simple in communication but demands forwarding plane intelligence; POF’s low level semantics (“how”) moves all the intelligence up to the controller

8. Other POF Features to Enhance OpenFlow • Enable active & stateful data-path • Add general flow-based metadata beyond counters • Statistics • Time stamps • Anomaly • Flow states • Add data-path instructions that can create and modify flow tables • MAC learning • Active firewall • Dynamic load balancing • Controller offloading key instructions metadata Flow Entry Table Update Instruction Execution Module Flow Table Table Search The flow metadata and data-path table manipulation instructions enrich the forwarding plane programmability and flexibility

9. Other POF Features to Enhance OpenFlow (cont’d) • Add entry-specific parameters and allow multiple flow entries share the same instruction block • Save instruction memory and enable fast updates • Treat statistics counters and flow metadata as shared resource pool and assign the resource to flow entries on demand • Aggregated and multi-purpose counters for statistics • Message communication vehicle for flows • Distinguish logical tables and physical tables • The same physical table used by multiple logical tables (e.g. IP/RPF, MAC Learning/forwarding) • One physical table resource shared by multiple unrelated logical tables (e.g TCAM, Hash) These new features facilitate the efficient hardware implementation, otherwise it would be difficult or even impossible for FE to figure out the optimization opportunities.

10. POF-based SDN Architecture Novel Applications &Services Protocol Specific Application Application API Programming Languages Controller Compiler Protocol Agnostic Tables/Instructions Flow InstructionSet Controller Flex Flow Processor OpenFlow+ Hardware Abstraction Layer Driver Forwarding Elements NPU Flow Tables POF Instructions • Programmable • Network optimized • Flexible • Generic • Standard • Low level instruction set CPU • Runtime & Remote reprogrammable • Table driven & protocol blind • Flow instruction set ASIC POF Data Path • High performance

11. POF System Prototypes Controller Forwarding Elements Controller Controller HUAWEI Core Router POFSwitch MPU Switch Control Module OpenFlow Connection Management OpenFlow Connection Management OpenFlow Parse OpenFlowEncap POFGUI Protocol Oblivious Forwarding LPU OpenFlow Parse OpenFlowEncap Resouce Module Resouce of POFSwitch Bypass Manager Module Floodlight Provider (Controller) POFManager HAL of POF Forwarding Engine Driver Datapath Module Other OFMessage Process Modules PMDatabase Forwarding Engine Forwarding Engine • Based on Floodlight with POF extension • Open source, cross platform, Apache licensed, and Java-based software • NP-based hardware implementation on NE5000E or NE40E router platform • Open source software switch on Linux server

12. Using NPU to Implement POF • Proprietary NPU runs in RTC (Run To Completion) programming model • Two modes for POF implementation • Function Mode: Each FIS instruction is implemented in FE NPU as a function written in micro-code. Each instruction is essentially a function call. • Simple but has a performance hit • Compiling Mode: Controller or the FE driver compiles the FIS instructions into NPU micro-code directly and load the code to the program memory. • Better performance but more complex • Current prototype used Function Mode and we are working on Compiling Mode • We see up to 30% performance loss • Mainly due to table search key constructions • Still satisfy typical application scenarios for the 40G line card It is feasible to use NPU to implement POF, in the long run we prefer to have some POF-optimized silicon to reduce the cost and boost the performance.

13. POF Use Cases Forwarding Protocol Enabling User Defined Source Routing NDN CCN SCN … NVGRE VXLAN TRILL IPX Fibre Channel … L2 IPv4 IPv6 MPLS … Network Service Enabling VPLS, Stateful Firewall, DPI, L4~L7 Applications Other innovation possibilities Network processing simplification - reduce tunneling and transformation User defined scratch space in packets for in-band info communication (OAM) POF offers unmatched flexibility to the forwarding plane. With it, we can either deploy sophisticated network services or greatly simplify the network forwarding process.

14. How to realize POF • Define low-level instruction set FIS • Platform-independent generic primitives • Expressive for a wide range of applications • Programming in “assembly” style • Allows layered abstraction and virtualization • No need to be the same as the chip instruction set • Standardization is the key • Stabilize a future-proof OpenFlow specification (OpenFlow 2.0?) • Need industry-wide collaboration involving all the player • Many hard problems (technical and non-technical) to attack • We publish the open-source website to advocate open research and encourage contributions and adoptions www.poforwarding.org POF has the potential to truly commoditize the forwarding elements while nourishing an independent controller/application software market.

15. Conclusions • POF thoroughly decouples the SDN control plane and the forwarding plane • Controller-side software can construct flexible applications without any underlying constraints • Controller applies high level languages and compilers to program the FEs through the standard instruction set • POF advocates a standard, flexible and future-proof forwarding plane • Allow FEs to focus on performance rather than functionality • FE will become simpler and more flexible • POF calls for continuous research to improve • Standardize the interface and the FIS, leave the other details for innovation • Service providers will benefit from this technology through: • (1) using standard, simple, and future-proof FEs to save CAPEX/OPEX • (2) quickly deploying customized and innovative services in the form of application software to generate new revenues.

16. For more information, please go to www.poforwarding.org and subscribe ONF SDN-Future Discussion Group mailing list.