haoyu song hotsdn, 2013 presented by ye tian for course cs05112
TRANSCRIPT
Protocol Oblivious Forwarding: Unleash the Power of SDN through a
Future-Proof Forwarding PlaneHaoyu Song
HotSDN, 2013
Presented by Ye Tian for Course CS05112
OverviewBackground and MotivationMake SDN FE a White BoxPOF OverviewPrototype and Use CaseReview
Challenges of OpenFlowOpenFlow has become the de facto standard SDN south-
bound interface.Challenges
Follows a reactive rather than proactive evolving path.The forwarding plane is almost stateless. Lacks the
capability to actively monitor flow status and change flow behavior without the involvement of the controller.
Challenges of OpenFlowConsequences
The control plane and the forwarding plane are not sufficiently decoupled. FE needs to have the knowledge of the protocol
There is no easy way to modify the packet format or add auxiliary data to the packets traveling in the network, let alone to apply user-defined protocols. Innovation is in feasible with OpenFlow Still need overlay, tunnel, etc.
Challenges of OpenFlowConsequences
Adding new forwarding protocol features requires an overhaul to both FE and controller, and in the worst case, a total redesign of the FE chip-set and hardware. New protocols keep emerging, e.g., VXLAN, NVGRE
The limited expressivity can seriously impact the forwarding plane programmability.
OverviewBackground and MotivationMake SDN FE a White BoxPOF OverviewPrototype and Use CaseReview
What Happened to Your Mobile Phone: A Metaphor
Preloaded with all the features Get new models for new apps No way to customize
Download only the apps you need New features in new software release Write your own apps
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.
Past Now
Network Device Programming Models
Control Plane
Data Plane
“Black Box”
Closed and proprietary design that meets the pre-defined service requirements
Device Vendor-driven Programmability
Managem
ent
I can only use the device as- is.
Device Vendor/Service Provider Split Programmability
Control Plane
Data Plane
OpenFlow 1.x“Gray Box”
Open interface using existing technology building blocks for limited programmability
Control
I can do what the device has supported.
Service Provider-driven Programmability
Control Plane
Data Plane
Open interface using generic network programming model, enabling full programmability
“White Box”
Program
OpenFlow+
I can do whatever I want.
Current network devices are black boxes.OpenFlow and some other flavors of SDN proposed today
make the network devices gray boxes with limited programmability.The FEs maintain a fair amount of intelligence and the
controller can do nothing beyond that.What the SDN really needs is a fully programmable
forwarding plane in which the FEs are all white boxes.
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.
Plane coupling Protocol/instruction explosion Stateless/Limited expressivity
Current OpenFlow-enabled Device is a “Gray Box”
New service required
Does the OF Spec. support it?
Wait for new revision of OF Spec.
Wait for the device upgrade to support the new spec.
Deploy the software to enable the service
Yes
No
Ideal path
Not future-proof Slow innovation process
SDN Computer System
APISys. Call
DriverInstruction Set
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.
SDN: Operate your Network Device like a PC
Simple & generic instruction set
Ultimate flexibility & extensibility
Upgrade only on performance
Service
Controller
Forwarding Element
Application
OperatingSystem
CPU systemPeripheral
The FEs should have a CPU-like role in the framework of SDN to ensure their flexibility and extensibility. That is, the FEs should not require any priori knowledge and understand the application semantics.
A concise set of protocol independent instructions are sufficient to compose any network services from the control plane. For CPU, RISC, CISC, MIPS, …We name such instructions a Flow Instruction Set (FIS).
Users are free to use their own network protocols and packet formats, enabling an even further departure from the status quo.
OverviewBackground and MotivationMake SDN FE a White BoxPOF OverviewPrototype and Use CaseReview
In POF, the FEs have no knowledge on any forwarding protocols.
The packet parsing is directed by the controller through a sequence of generic key assembly and table lookup instructions.
A search key is simply defined by one or more {offset, length} tuples offset indicates the skipped bits from the current cursor
within the packet (or metadata)length indicates the number of bits that should be included
in the key starting from the offset position.
All the forwarding instructions are purposely made protocol agnostic.
Instead, in FIS, for the instructions that manipulate the packet or metadata (e.g. insert, delete, and modify), {offset, length} is used to locate the target data.
Example, OpenFlow 1.3: push VLAN, MPLS, PBB headers require
separate actions.POF: one instruction -- AddField
Protocol Oblivious Forwarding: Core Concept
OFPAT_COPY_TTL_OUTOFPAT_COPY_TTL_INOFPAT_SET_MPLS_TTLOFPAT_DEC_MPLS_TTLOFPAT_PUSH_VLANOFPAT_POP_VLANOFPAT_PUSH_MPLSOFPAT_POP_MPLSOFPAT_SET_NW_TTLOFPAT_DEC_NW_TTLOFPAT_PUSH_PBBOFPAT_POP_PBBand on and on and on …
POFAT_SET_FIELDPOFAT_ADD_FIELDPOFAT_DELETE_FIELDPOFAT_MOD_FIELDPeriod.
~40 matching header fields defined yet still many uncovered protocols/headers
{offset, length} covers any frame based formats
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.
Match
Action
Current OpenFlow POF
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
Is this an IP packet?
Use destination IP to search FIB
Process TTL
Update Checksum
Data @ {12B, 2B} = 0x0800?
Extract Data @ {30B, 4B}; Use it as key to search LPM table x
Decrement Data @ {22B, 1B}; If result is 0, drop the packet
Clear Data @ {24B, 2B};Use algorithm y to calculate checksum over Data @ {14B, 20B}; Write result @ {24B, 2B}
DMAC SMAC Type Payload FCS
Conventional FE Forwarding
Flow
POF Forwarding Flow
Ethernet/IPv4 Packet Format
OpenFlow’s high 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
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
Enhance the forwarding planeWe prefer the data-path to be able to keep track of the
flow status with metadata. A flow metadata has a life span of a flow.Assign flow metadata to flows on an on-demand basis.
Allow the data-path to actively manipulate the flow tables.
Other POF Features to Enhance OpenFlow
key metadata
instructions
Flow Entry
Table Update
Table Search
FlowTable
InstructionExecutionModule
The flow metadata and data-path table manipulation instructions enrich the forwarding plane programmability and flexibility
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
Enhance the forwarding plane 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)
OverviewBackground and MotivationMake SDN FE a White BoxPOF OverviewPrototype and Use CaseReview
POF-based SDN Architecture
Programming Languages
Compiler
Flow Instruction Set
Application API
• Programmable• Network
optimized
• Runtime & Remote reprogrammable
• Table driven & protocol blind
• Flow instruction set
• Flexible• Generic• Standard• Low level
instruction set
NPU
CPU
• High performance
Flex Flow Processor
ASIC
Novel Applications &Services
Protocol SpecificApplication
Protocol AgnosticTables/Instructions
Controller
FlowTables
POFInstructions
POF Data Path
OpenFlow+ Hardware Abstraction Layer
Driver
ControllerForw
arding Elements
Controller Forwarding Elements
Based on Floodlight with POF extension
Open source, cross platform, Apache licensed, and Java-based software
POF System Prototypes
NP-based hardware implementation on NE5000E or NE40E router platform
Open source software switch on Linux server
POFGUI
POFManager
PMDatabase
Bypass Manager Module
Floodlight Provider(Controller)
OtherOFMessage
Process Modules
ProtocolOblivious
Forwarding
Controller Controller
OpenFlow Connection Management
Forwarding Engine Driver
ForwardingEngine
OpenFlow Connection Management
OpenFlow Parse OpenFlow Encap
Resouce of POFSwitch
ForwardingEngine
MPU
LPU
Switch Control Module
Resouce Module
Datapath Module
HUAWEI Core Router
OpenFlow Parse OpenFlow Encap
HAL of POF
POFSwitch
L2IPv4 IPv6 MPLS…
NVGRE VXLAN TRILLIPXFibre Channel…
User DefinedSource Routing NDNCCNSCN…
Network Service Enabling
VPLS, Stateful Firewall, DPI, L4~L7 Applications
Forwarding Protocol Enabling
Other innovation possibilitiesNetwork processing simplification - reduce tunneling, overlay, and transformation
User defined scratch space in packets for in-band info communication (OAM)
POF Use Cases
POF offers unmatched flexibility to the forwarding plane. With it, we can either deploy sophisticated network services or greatly simplify the network forwarding process.
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
• POF has the potential to truly commoditize the forwarding elements while nourishing an independent controller/application software market.
How to realize POF
www.poforwarding.org
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
Conclusions
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.
ReviewWhat are the challenges of OpenFlow?Why need a white box FE? Why POF is future proof?