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 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.

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.

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.