OpenFlow Extensions a presentation by Ben Mack-Crane, Huawei at the US Ignite ONF GENI workshop on October 8, 2013

1. Ben Mack-Crane
Huawei
1
OpenFlow Extensions

2. © 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

3. © 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

4. © 2013 Open Networking Foundation
Cool Features in OpenFlow 1.4
ONF Extensibility WG

5. © 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

6. © 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. */
};

7. © 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.

8. © 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…

9. © 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

10. © 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).

11. © 2013 Open Networking Foundation
Themes under discussion for OpenFlow 1.5
ONF Extensibility WG

12. © 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

13. © 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.

14. © 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

15. © 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

16. © 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