Download - OpenFlow Extensions

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


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


Cool Features in OpenFlow 1.4 ONF Extensibility WG


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


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


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.


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…


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


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


Themes under discussion for OpenFlow 1.5ONF Extensibility WG


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


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.


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


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


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

Download - OpenFlow Extensions

Top Related