OpenFlow Extensions
Download as PPTX, PDF6 likes5,566 views
The document discusses OpenFlow extensions, highlighting features in OpenFlow 1.4 and themes for OpenFlow 1.5. Key improvements include enhanced extensibility, refined packet-in reasons, configuration change notifications, and synchronized tables. It also addresses future capabilities related to tunnel support, flow state, L4-L7 service support, error handling, and the fitness for carrier use.
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