Users Guide

Table 77. Supported error types (continued)
Error types Supported/Not supported
OFPQOFC_BAD_QUEUE = 1 Not supported
OFPQOFC_EPERM = 2 Not supported
Switch configuration failed code
OFPSCFC_BAD_FLAGS = 0 Not supported
OFPSCFC_BAD_LEN = 1 Not supported
OFPSCFC_EPERM = 2 Not supported
Role request failed code
OFPRRFC_STALE = 0 Not supported
OFPRRFC_UNSUP = 1 Not supported
OFPRRFC_BAD_ROLE = 2 Not supported
Table features failed code
OFPTFFC_BAD_TABLE = 0 Supported
OFPTFFC_BAD_METADATA = 1 Not supported
OFPTFFC_BAD_TYPE = 2 Not supported
OFPTFFC_BAD_LEN = 3 Not supported
OFPTFFC_BAD_ARGUMENT = 4 Not supported
OFPTFFC_EPERM = 5 Not supported
OpenFlow use cases
OS10 OpenFlow protocol support allows the flexibility of using vendor-neutral applications and to use applications that you
create. For example, the OS10 OpenFlow implementation supports L2 applications similar to the ones found in the following
websites:
● https://github.com/osrg/ryu/tree/master/ryu/app (only L2 applications are supported)
● https://github.com/osrg/ryu/tree/master/ryu/app
NOTE: OS10 supports applications based on OpenFlow versions 1.0 and 1.3.
● Switching loop removal
Consider the case of a single broadcast domain where switching loops are common. This issue occurs because of redundant
paths in an L2 network.
Switching loops create broadcast storms with broadcasts and multicasts being forwarded out of every switch port. Every
switch in the network repeatedly re-broadcasts the messages and floods the entire network.
To solve broadcast storms in an OpenFlow network, a centralized controller makes all the control plane decisions and
manages the switches. The controller has the complete view of the topology. MAC address learning is centralized. OpenFlow
identifies the correct path and forwards the packets to the relevant switch thereby avoiding switching loops.
● Reactive flow installation
OpenFlow
1219