openflow extensions
DESCRIPTION
OpenFlow Extensions a presentation by Ben Mack-Crane, Huawei at the US Ignite ONF GENI workshop on October 8, 2013TRANSCRIPT
1
Ben Mack-CraneHuawei
OpenFlow Extensions
© 2013 Open Networking Foundation
Topics
• Cool Features in OpenFlow 1.4 – Enhancing extensibility– Packet-in reasons refined– Configuration change notifications– Bundles– Synchronized tables– Change default TCP port
• Themes under discussion for OpenFlow 1.5– Tunnel support– Flow state– L4-L7 service support– Error handling– Fitness for carrier use
© 2013 Open Networking Foundation
OpenFlow versions
• OpenFlow 1.0 – Dec 2009– First widely implemented/deployed version– Single table, fixed 12 tupples
• OpenFlow 1.1 – Feb 2011– Not popular - incompatible with 1.0– Multi-table, groups, full VLAN and MPLS support
• OpenFlow 1.2 – Dec 2011– First ONF release – fix 1.1– More flexibility, get closer to implementations– Flexible match, flexible rewrite, IPv6, role change
• OpenFlow 1.3 – Apr 2012– Long term release : 1.3.1, 1.3.2, 1.3.3– Flexible capabilities, Meters, PBB, event filters
• OpenFlow 1.4 – Aug 2013– Bundles, optical ports, flow monitoring, eviction
© 2013 Open Networking Foundation
Cool Features in OpenFlow 1.4 ONF Extensibility WG
© 2013 Open Networking Foundation
Enhancing Extensibility
5
Flexibility goals 2011…• Modularity
– Small core of common functions– Many independent protocols and
features
• Extensibility– Higher level description of data– Extend the data without breaking it– Third party extensions
• Interoperability– Capability discovery– Profiles : predefined set of feature
(convention)
• Consistency– Same conventions throughout the
specification
Areas improved in OF1.4…
• Port structures• Table structures• Queue structures• Set-async structures• Instruction structures• Actions structures• Experimenter structures• Properties errors
© 2013 Open Networking Foundation
Packet-in reasons refined
6
In OF1.3 different parts of the pipeline use same reason – OFPR_ACTION
New reasons (highlighted):
Detailed reasons help debug pipeline
/* Why is this packet being sent to the controller? */enum ofp_packet_in_reason { OFPR_TABLE_MISS = 0, /* No matching flow (table-miss flow entry). */ OFPR_APPLY_ACTION = 1, /* Output to controller in apply-actions. */ OFPR_INVALID_TTL = 2, /* Packet has invalid TTL */ OFPR_ACTION_SET = 3, /* Output to controller in action set. */ OFPR_GROUP = 4, /* Output to controller in group bucket. */ OFPR_PACKET_OUT = 5, /* Output to controller in packet-out. */};
© 2013 Open Networking Foundation
Configuration change notifications
7
Some switches allow confguration via other interfaces– CLI, Routing subsystem, MAC Learning, etc.
The controller needs to know!• Flow tables
– Set flow monitors on the switch ofp_flow_monitor_request
– Flow monitor update events sent to controller, with• full details using ofp_flow_update_full or • abbreviated using ofp_flow_update_abbrev.
– Flow control mechanism to avoid backlog of monitor updates.
• Group / Meter tables– "group-mod" and "meter-mod" requests encapsulated in a OFPT_REQUESTFORWARD message sent to other controllers.
© 2013 Open Networking Foundation
Bundles
8
The capability to build a bundle of commands and execute the bundle as an atomic* (all or none) operation
• Bundle control message– OFPT_BUNDLE_CONTROL to create, destroy and commit bundles.
• Bundle add message– OFPT_BUNDLE_ADD_MESSAGE to add a message into a bundle.
• Bundle error message– OFPET_BUNDLE_FAILED to report bundle operation errors.
*Atomic from the point of view of the Controller, not atomic with respect to packet processing…
© 2013 Open Networking Foundation
Synchronized tables
9
• Many switches can perform multiple lookups on the same lookup data.– For example, a standard Ethernet learning bridge performs learning
lookup and forwarding lookup on the same set of MAC addresses.– Another example is RPF checks which reuse the IP forwarding data.
• The synchronised tables feature represents this relationship as two tables whose entries are synchronised.
• New table feature property OFPTFPT_TABLE_SYNC_FROM• Defines the synchronisation relationship• Does not define the transformation
© 2013 Open Networking Foundation
Change default TCP port
10
OOPS! (forgot to request 6633 in time)
• IANA allocated to ONF the TCP port number 6653 to be used by the OpenFlow-Switch protocol.
• All uses of the previous port numbers, 6633 and 976, should be discontinued.
• OpenFlow switches and OpenFlow controllers must use 6653 by default (i.e., when not using a user specified port number).
© 2013 Open Networking Foundation
Themes under discussion for OpenFlow 1.5ONF Extensibility WG
© 2013 Open Networking Foundation
Tunnel Support
• Tunnels are outside of the OF-Switch protocol– e.g., configured using OF-Config or some other means
• But Tunnels are flows (or flow endpoints)• Can we use OF-Switch to configure tunnels?
– Stateful / complex behavior, e.g. fragment/reassemble,de/encrypt, OAM, fault recovery
– Push / pop new headers, e.g. Ethernet, IP– Act on nested headers (not just the first in packet)?
• Need for a framework for Tunnel support– Relationship with Logical Port– Support a variety of Tunnel types– Support Tunnel stacking, relax match prerequisite rules
© 2013 Open Networking Foundation
Flow State
The capability to store / access flow metadata that persists for lifetime of flow (not just current packet)
Potential to enable a variety of new capabilities:• Fragment handling without reassembly• Relation between bidirectional flows (e.g., RDI)• Autonomous flow learning + flow state tracking
– MAC learning– TCP proxy
• Hierarchies of flows– e.g. FTP control / data, all belonging to a user, etc.
© 2013 Open Networking Foundation
L4-L7 Service Support
Service Chaining, L4-L7 Processing
• Steering of traffic to local or remote service – Service Chaining– Classification: selecting Service Chain– Transport: encapsulation (preserving metadata)
• Mirror vs. divert• Local service insertion with ability to resume processing
– Model as logical port, packet processor, custom action...• Potential to control/program L4-L7 processing functions
– Deeper header parsing, more varied/complex actions– (related to Flow State)
• Question of OF1.x vs. OF2.0
© 2013 Open Networking Foundation
Error handling
SDN robustness and OpenFlow completeness
• If x disappears / enters error condition, what happens to y which referred to it / was connected to it– x & y are entities in switch (e.g. flow/port/group entries)– x is in switch and y is in controller
• Recovery process, e.g. resync after hand over between controllers• Address error conditions for which behavior is currently unspecified
© 2013 Open Networking Foundation
Fitness for Carrier Use
Some capabilities are missing or too limited to support carrier SDN
• Support for OAM in its various forms– Monitoring (fault, performance)– Diagnostics (including new forms for SDN)– Fault recovery
• More dataplane technologies / more varied combinations– Not just Ethernet physical interfaces– Common layering structures (related to Tunnel Support)
• Hybrid operation– Clarify and improve interaction between OF and built-in functions– Migration support