Understanding OpenFlow Flows and Filters on Devices Running Junos OS
OpenFlow flows are defined by various elements. Table 1 outlines the support for flow elements in OpenFlow v1.0 and OpenFlow v1.3.1. The elements supported by the OpenFlow versions uniquely identify a flow.
Flow Element |
Supported In OpenFlow v1.0? |
Supported In OpenFlow v1.3.1? |
---|---|---|
Match conditions |
Yes |
Yes |
Set of actions |
Yes |
No |
Flow instructions |
No |
Yes |
Flow priority |
Yes |
Yes |
Flow timeout information |
Yes |
Yes |
Flow cookie and cookie mask |
No |
Yes |
Flow entries specify wildcard match conditions for fields that do not require an exact match. If a flow entry contains wildcards for all match conditions, then all packets match that flow entry.
To implement OpenFlow flow-based forwarding, devices running Junos OS use filters. For each logical interface configured to participate in OpenFlow, a single filter is created and applied to the logical interface in the input direction. The filter name is the concatenation of the interface name, including the logical unit number, and an internally assigned virtual switch ID, for example ge-1/1/0.0_0.
If you manually configure a filter name or a filter term
name that conflicts with an autogenerated OpenFlow filter name or
filter term name, Junos OS does not generate an error during a commit check
. If there is a conflict, the commit succeeds,
but one of the filters or filter terms is rejected based on the order
in which they were received.
A filter consists of one or more terms with match conditions,
and actions (for OpenFlow v1.0) or instructions (for OpenFlow v1.3.1).
OpenFlow flows are mapped to filter terms, and OpenFlow controller
requests to add, delete, and modify flows result in the addition,
deletion, or modification of terms in the filter. When the OpenFlow
controller sends a flow modification request, the flow entry match
condition for the ingress port determines which logical interface
filter is updated. The OpenFlow flow priority determines the order
of the terms in the filter, where higher priority terms are installed
above lower priority terms. Flow match conditions are mapped to the
filter term match conditions, and flow actions or instructions are
mapped to the filter term then
statement. Depending on
the flow action or instruction, the then
statement might
include actions for forwarding the packet to the next hop or OpenFlow
controller, or discarding the packet.
If the OpenFlow controller sends a request to modify a flow, but no flow entries match the conditions, OpenFlow v1.0 adds an entry for the flow to the flow table. However, in the same situation, OpenFlow v1.3.1 does not add this flow to the flow table, nor is an error logged.
Each OpenFlow flow entry corresponds to a filter term. However, each flow entry might map to a term in one or more filters depending on the match condition for the ingress port. If the ingress port is a wildcard match, the flow entry appears as a term in all of the interface filters for that OpenFlow virtual switch. For example, suppose that the OpenFlow controller sends a request to add a new flow entry with a wildcard match for the ingress port field. In this case, the flow is added as a new filter term for all OpenFlow logical interfaces configured under that virtual switch.
Devices running Junos OS support both strict and non-strict flow mod commands for modifying and deleting flows. OpenFlow controller strict-modify and strict-delete flow mod requests modify or delete only flows that exactly match the description for all header fields including wildcards and priorities. Non-strict modify and delete flow mod requests modify or delete flows that exactly match or are more specific than the request.
In addition to the functionality already described, OpenFlow v1.3.1 supports a flow cookie, which is an identifier that the OpenFlow controller can specify when a flow is installed in the flow table. This cookie enables OpenFlow to filter flows selected for flow modification and delete operations.
You can configure the default action for packets that do not
match on any flow entry as either drop
, which discards
the packet, or packet-in
, which accepts the packet and
forwards it to the controller. The default action is specific to the
OpenFlow virtual switch and is the same across all filters associated
with that virtual switch. If you do not explicitly configure the default
action, the default is packet-in
.
In the event that a logical interface becomes unavailable, the filter associated with that logical interface is removed from the Packet Forwarding Engine. Although the filter is removed, the Routing Engine retains flows that match the logical interface as the ingress port until such time as the flows are purged in response to OpenFlow timers. For information about OpenFlow timers, see Understanding OpenFlow Flow Entry Timers on Devices Running Junos OS. If the logical interface becomes available before the flows are purged, the filter and any flows retained by the Routing Engine at that point are reinstalled in hardware.
Similarly, when a logical interface becomes unavailable, flows that have that logical interface as the only active egress interface in their action set or instruction are considered invalid. The invalid flows are removed from the Packet Forwarding Engine but are indefinitely retained by the Routing Engine until the flows are purged in response to various OpenFlow timers. Alternatively, flows that include the logical interface as one of several active egress interfaces in their action set or instruction are still valid. In that case, the flow remains in the Packet Forwarding Engine, but the multicast next hop is updated to remove that logical interface as a valid egress interface.