Config Protocol Draft Proposal

From OpenFlow Wiki

The OpenFlow Configuration Protocol defines a mechanism for OpenFlow controllers to access and modify configuration data on an OpenFlow switch. It adds transactional consistency with an extensible, standard message format. This specification defines (section 1) an RPC and wire protocol for data access and modification, (section 2) Requirements for Intererability, and (section 3) a schema to represent OpenFlow switches.

For OpenFlow v1.0, the config protocol is optional, and all configuration data it describes can be accessed through OpenFlow binary-formatted messages. Post v1.0, the config protocol may become the preferred method for describing and modifying configuration data on an OpenFlow switch, even data not described in the OpenFlow spec.

Motivation

The OpenFlow Configuration Protocol is intended to simplify the job of writing an OpenFlow controller, by adding transactional consistency. Transactions are a set of configuration changes that are either applied all at once, or not at all. Consistency means an author can be sure that a value has not changed between a query for its value and an update to that value. The transactional consistency guarantee makes it easier for controllers to reason about network state and write correct applications.

The choice of a standard, self-describing, text-based format, JSON, is intended to make extensions easier than the current method of C structs via OpenFlow vendor extensions. Custom data can then be added to a table alongside OpenFlow-specific data, without breaking compatibility, by extending the column schema.

RPC and Wire Protocol

Mention that this is the OVS config protocol, verbatim.

Brief Overview

Ben, if you'd like to add this to the OVS do, go ahead.

The Open vSwitch Configuration Protocol defines RPC methods sent over a JSON-RPC channel which interact with named tables. Each table includes statically-defined data, row, and column schemas. The main RPC methods are transact and monitor. Transact executes a set of operations as a single atomic, consistent, isolated transaction, with optional durability. Monitor provides an up-to-date table view, by ensuring that future changes to a table are automatically reflected to the client.

A transaction includes a set of operations to execute in order. Insert, update, and delete modify row data. Select returns rows meeting a condition. The wait operation serves two disparate purposes. When the timeout is zero, it verifies that data has not changed, so that an update based on that data can be safely applied. Wait also enables triggers; when the timeout is nonzero, notification that the condition has been satisfied will be automatically sent, without requiring polling. Finally, commit applies the changes.

Transaction operators include numerical comparison and equality. Operators apply to data described by a number of data formats including, but not limited to, sets, maps, universally unique identifiers (UUIDs from RFC 4122), and scalar values. UUIDs can be used for references from one table to another as well as within a single table, but this spec does not mandate that an implementing database enforce referential integrity.

Formal RPC and Wire Protocl

Include full OVS config protocol text: http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=ovsdb/SPECS;hb=next

Requirements for Interoperability

[Need to define how a controller written only with knowledge of the OpenFlow Data Schema should handle extension data - is it sufficient to state the this should be ignored by the controller checking the data schema? Or does there need to be a bit indicating whether a field is part of the OpenFlow schema?]

[Need to define a subset (complete set would be simplest) of implemented functionality for a database implementation to be considered compliant.

OpenFlow-specific Data Schema

[Need to add this, based on the OVSDB example]

Credits

The Open vSwitch wire protocol was created by Ben Pfaff, Martin Casado, XXX etc with input from YYY.