From OpenFlow Wiki

Contents 1 Hardware Abstractions for OpenFlow Switching 1.1 Overview 1.2 High Level Architecture 1.3 The Primitive Data Objects 1.3.1 Ports 1.3.1.1 Native Ports 1.3.1.2 Derived Ports 1.3.2 Flows 1.3.3 Other Primitive Abstractions 1.3.3.1 Queues 1.3.3.2 Rate Limiters and Rate Limiter Binding 1.3.3.3 Mirror Egresses and Mirror Binding 1.3.3.4 TBD 1.4 Data Object Abstractions Defined 1.4.1 Port Type Definition 1.4.2 Derived Ports 1.4.3 Queues 1.4.3.1 Rate Limiters and Rate Limiter Binding 1.4.3.2 Mirror Egresses and Mirror Binding 1.4.3.3 TBD 1.5 Functional API Description 1.5.1 Port Query 1.5.2 Port Configuration Operations 1.5.3 Derived Port Add/Remove/Configure 1.5.4 Asynchronous Port Status Notification 1.5.5 Flow Operations 1.5.6 Statistics Query Operations 1.5.7 Packet I/O 1.5.7.1 Send Packet 1.5.7.2 Packet Poll 1.5.7.3 Packet Receive Register

Hardware Abstractions for OpenFlow Switching

See OpenFlow Switching Hardware Roadmaps for an introduction to this section.

Overview

The OpenFlow Switching Hardware Abstraction is very simple from one point of view (though there remain a few ambiguities to be worked out). But in the context of a real life deployment of a switch that supports the OpenFlow Switching protocol in parallel with other traditional switch features, the situation becomes much more complex.

The following is an attempt to identify the native OpenFlow Switching abstractions and then to provide reasonable extensions of those to a fully functional managed switch with an extensible system architecture.

High Level Architecture

Need a reasonable picture that shows the following. Note that even numbered layers are implementations and odd numbered layers are interfaces.

5: 5A: OF interface           5B: Other configuration 
         |                     mechanism(s) interface
         |                               |
4:   4A: OF          4B: Other       4C: Config
      agent          functions         Agent
         |               |               |
         +-----+-------------------+-----+
               |                   |
3:       3A: Pure OF          3B: Extended 
          Interface            Interface
               |                   |
               +---------+---------+
                         |
2:      Semi-proprietary HAL implementation
          written to hardware specific API
                         |
1:               Proprietary HW API
                         |
0:                   Hardware

The Primitive Data Objects

Ports

Goal: Use the OpenFlow numbers to refer to all port objects above 3.

Let's distinguish between two types of ports: Native and Derived. These might normally be called "physical" and "virtual".

Native Ports

These ports are determined by the underlying hardware. Layers 1 and 2 determine the mapping of the physical ports and how they will be exposed as OpenFlow ports (the mapping from OpenFlow port numbers to hardware representations). This numbering is exposed by API calls in 3A allowing the upper layers to query the presence and capabilities of ports.

Derived Ports

Derived ports are those that are configured by API calls in 3B depending on the functionality of the underlying hardware. The HAL will define a list of recognized derived ports, some of which will be defined in the OpenFlow standard (in OpenFlow 1.1 and later); others may be extensions of OpenFlow. Examples include:

• An LACP trunk of physical links
• An ECMP interface
• An L3 interface
• An L2 in L3 tunnel interface

The interface of 3B provides an API to communicate the types of derived ports supported by a particular implementation.

Each derived port type has a set of parameters that define its configuration as indicated in the HAL API definition.

A derived port is added to the system by an API call from 3B. This does two things:

• Configures the derived port in the hardware
• Associates an OpenFlow port number for the derived port

The port number may be specified by the caller or generated by the code in 2.

The same API calls mentioned above for native ports will also expose derived ports. It is recommended that an asynchronous notification mechanism be provided across 3A that supports not only port state changes, but also the addition of new derived ports.

Flows

Goal: Keep the flow definition as close to the spec as possible.

Flows are built from match structures and action lists. See the spec.

Port references in flow definitions should always be OpenFlow port numbers, though those may be native or derived ports.

TBD: Discuss extended actions; specifically, for rate limiters.

TBD: Do we need to support extending the match structure? Would really prefer not to.

Other Primitive Abstractions

Queues

OpenFlow native concept. See the spec.

Rate Limiters and Rate Limiter Binding

Define a stateful counter which can be bound to some class of packet flow. Results in packet marking or packet dropping depending on the implementation.

Mirror Egresses and Mirror Binding

Mirroring in OpenFlow is pretty easy to implement: Just add and output/enqueue action to the flows that require mirroring. Some hardware supports other mirroring mechanisms such as "mirror all packets on an ingress". This requires defining an egress interface as the target and binding the mirror operation to some part of the packet flow (like the ingress interface).

TBD

Data Object Abstractions Defined

This section should run in parallel with the data representation parts of the API description providing an explanation of each parameter required to define a particular object.

Port Type Definition

TBD: Define the base characteristics to be provided for ports. Identify which characteristics are optional and which are required.

1. Port link state
2. Forwarding state (define completely)
3. (Nominal link characteristics: speed, duplex, pause...)
4. Extended port characteristics: These are for the "derived" ports and are basically the parameters defining the extended type.

Derived Ports

TBD: List the derived port types with detailed descriptions of the parameters; or provide pointers to the pbuf definitions of these objects.

Queues

Rate Limiters and Rate Limiter Binding

Mirror Egresses and Mirror Binding

TBD

Functional API Description

This section runs in parallel with the functional API descriptions defining each operation and the data objects involved. It will also define the error codes and meanings of those errors that can be returned from these operations.

Port Query

Get one (by OF port number) or all port descriptions.

Port Configuration Operations

As per spec port_config_set

Derived Port Add/Remove/Configure

Allows creation, reconfiguration and removal of a derived port. For example, adding physical ports to a LAG?

Asynchronous Port Status Notification

Includes things like link change as well as addition of derived port.

Flow Operations

From the spec.

Statistics Query Operations

• Table
• Port
• Flow: Specific and aggregate

Packet I/O

For packet reception, both polling and asynchronous models should be supported.

TBD: Provide mechanism for mapping packet I/O through the native OS network interfaces? Requires some additional work to define how to bind port objects to the native OS network representation.

Send Packet

Packet Poll

Packet Receive Register

Either bind function (in C header format) or indicate ability to handle messages of ingress packets (in protocol buffer format) for packets coming from the hardware.