OF-Config Evolution

V1.0 (Jan 2012): Based on OpenFlow V1.2

Assign controllers to logical switches

Retrieve logical switch configurations

Configure ports and queues

V1.1 (May 2012): Based on OpenFlow V1.3

Configuration of certificates

Capability Discovery: Retrieve logical switch capabilities

Configure logical tunnels (VXLAN, NVGRE, …)

V1.1.1 (Jan 2013): Bug Fix. Versioning support

V1.2 (Not published yet): Based on OpenFlow V1.4

Simple topology Detection

Assigning resources to logical switches

Ref: https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow-config/of-config1dot0-final.pdf https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow-config/of-config-1.1.pdf https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow-config/of-config-1-1-1.pdf

14-33

OpenFlow Notification Framework

Notification: Event triggered messages, e.g., link down

Publish/subscribe model: Switch = publisher. OpenFlow controller or OpenFlow config points, and others can subscribe. They will be notified about the events they subscribe.

Use ITU-T M.3702 Notifications: Attribute value change, Communication alarm, Environmental alarm, Equipment alarm, QoS alarm, Processing error alarm, Security alarm, State change, Object creation and deletion

Pre-existing Notifications: Do not fit in the framework but will be recognized.

OpenFlow: Packet-in, Flow removed, Port Status, Error, Hello, Echo request, Echo reply, Experimenter

OpenFlow Config: OpenFlow logical switch instantiation, OpenFlow capability switch capability change, Successful OpenFLow session establishment, Failed OpenFlow session

establishment, Port failure or recovery

Ref: https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow-config/of-notifications-framework-1.0.pdf

14-34

Implementation Issues

40+ matching fields in a flow

Multiple tables, each with a large number of flow entries

Instructions and actions for each table

Need VXLAN, NVGRE, etc. support

For a large network, flow level programming can take a long time

Logical Ports

Port Management VxLAN NVGRE

Physical Ports

Ref: R. Oshana and S. Addepalli, “Networking TrendsSoftware Defined Networking, Network Virtualization and Cloud Orchestration,” Asia Power Arch. Conf,

Oct 2012, https://www.power.org/wp-content/uploads/2012/10/13.-FSL-SDN-Openflow-and-Cloud-computing-UPD_Rob-Oshana.pdf

Washington University in St. Louis http://www.cse.wustl.edu/~jain/cse570-13/ ©2013 Raj Jain

14-35

OpenFlow: Future Work Items

Each controller has its own way to program. Need a common standard “Northbound API”

No standard API for communication between controllers of overlapping domain Need an East-West API

Ability to continue operation when the controller is down

Many other packet formats (non-IP, non-Ethernet, …)

Flow Decide once, use many times Performance

But does not help non-flow based request/response apps

Need API to encrypt data plane packets

Need API to inject packets

Need API to instantiate a service, such as a firewall, IDS, on the switch

14-36