Group tables enable Openflow to process forwarding decisions on multiple links. Examples include: load-balancing, multicast, and active/standby.
The above figure illustrates how group-tables can simplify the configuration required to consolidate forwarding decisions for flows in an Openflow pipeline.
An OpenFlow group is an abstraction that facilitates more complex and specialized packet operations that cannot easily be performed through a flow table entry. Each group receives packets as input, and performs any OpenFlow actions on these packets. A group is not capable of performing any OpenFlow instructions, so it cannot send packets to other flow tables or meters. Furthermore, it is expected that packets have been matched appropriately prior to entry to a group, as groups do not support matching on packets. Groups are merely mechanisms to perform advanced actions, or sets of actions.
As shown in the above figure, the power of a group is that it contains separate lists of actions, and each individual action list is referred to as an OpenFlow bucket. Thus, it is said that a group contains a bucket list (or a list of lists of actions). Each bucket or list of buckets can be applied to entering packets; the exact behavior depends on the group type. There are certain types of groups that make use of additional parameters within a bucket. The details of these parameters will be discussed with each group type, where applicable.
There are four types of groups: ALL, SELECT, INDIRECT, and FAST-FAILOVER.
- PicOS OVS supports group tables in Openflow 1.2 Openflow 1.3 and Openflow 1.4
- The number of buckets supported is dependent on the TCAM size in the ASIC. So there is a possibility that all defined group tables will not be installed in hardware.
- Max group number is 512, and max bucket number in one group is 128.
The ALL Group
Starting with one of the simplest, the ALL group, illustrated in the following figure, will take any packet received as input, and duplicate it to be operated on independently by each bucket in the bucket list. In this way, an ALL group can be used to replicate and then operate on separate copies of the packet defined by the actions in each bucket. Different and distinct actions can be in each bucket, which allows different operations to be performed on different copies of the packet.
Limitation in PicOS switch:
Due to limitation in the ASIC, PicOS OVS switches do not support replicating the packet and then operating by the actions in each bucket. So if user wants to configure type=all group, the actions of different buckets must be same. In other word, all the buckets need be uniform.
The INDIRECT Group
The INDIRECT group illustrated in the figure below, can be difficult to comprehend as a “group,” since it contains only a single bucket, where all packets received by the group are sent to this lone bucket. In other words, the INDIRECT group does not contain a list of buckets but a single bucket (or single list of actions) instead. The purpose of the INDIRECT group is to encapsulate a common set of actions used by many flows. For example, if flows A, B, and C match on different packet headers but have a common set or subset of actions, these flows can send packets to the single INDIRECT group as opposed to having to duplicate the list of common actions for each flow. The INDIRECT group is used to simplify an OpenFlow deployment and reduce the memory footprint of a set of similar flows.
The FAST-FAILOVER Group
Lastly, the FAST-FAILOVER group is the topic of conversation for this tutorial and is designed specifically to detect and overcome port failures. Like the SELECT and ALL groups, the FAST-FAILOVER group, as indicated in Figure 5, has a list of buckets. In addition to this list of actions, each bucket has a watch port and/or watch group as a special parameter. The watch port/group will monitor the “liveness” or up/down status of the indicated port/group. If the status is deemed to be down, then the bucket will not be used. If it is determined to be up, then the bucket can be used. Only one bucket can be used at a time, and the bucket in use will not be changed unless the status of the watch port/group transitions from up to down. When such an event occurs, the FAST-FAILOVER group will quickly select the next bucket in the bucket list with a watch port/group that is up.
Actually, watch group is not supported in PicOS.
There is no guarantee on the transition time to select a new bucket when a failure occurs. The transition time is dependent on search time to find a watch port/group that is up and on the switch implementation. However, the motivation behind using a FAST-FAILOVER group is that it is almost guaranteed to be quicker than consulting the control plane to handle the port down event, and inserting a new flow or set of flows. With FAST-FAILOVER groups, link failure detection and recovery takes place entirely in the data plane.
The SELECT Group
Next, there is the SELECT group, which is primarily designed for load balancing. As indicated in the following figure, each bucket in a SELECT group has an assigned weight, and each packet that enters the group is sent to a single bucket. The bucket selection algorithm is undefined and is dependent on the switch’s implementation; however, weighted round robin is perhaps the most obvious and simplest choice of packet distribution to buckets. The weight of a bucket is provided as a special parameter to each bucket. Each bucket in a SELECT group is still a list of actions, so any actions supported by OpenFlow can be used in each bucket, and the buckets need not be uniform.
PicOS does not support weight. Because OVS forward is based on priority of entries in TCAM, the traditional ECMP in routing table cannot be used. For a typical IP flow, PicOS implements a "dummy ECMP" by splitting the matching fields of a flow. For a group-table with type=select, PicOS support set-select-group-hash-fields and the packets will hash according to the value of set-select-group-hash-fields.
The command added for setting select-group hash fields is:
Description: This command takes at most 1 argument that specifies match fields to do hash for select-group, these match fields should be spliced by “,” with descending priority and must use the constrained fields list above. If there is 0 argument token or 1 argument with string “default”, the default mode will take effect.
The priority for match fields means that when match fields are set, they will be checked in sequence to select one can do hash. If select fails, the first field in the configured match fields will be picked on and only one bucket can be used.
In default mode, the check order is “nw_src, nw_dst, dl_src, dl_dst” with non-zero field mask. If select failed, check the order “nw_src, nw_dst, dl_src, dl_dst” with field mask equals zero again.
If the selected field is an exact value, means all mask bits are “1”, then only one bucket can be used.
When user want the traffic match nw_src or nw_dst to hash, the flow entry match field must include dl_type=0x0800. If not include dl_type=0x0800, the flow entry only hash by dl_src and dl_dst.
ovs-ofctl add-flow br0 in_port=1,dl_type=0x0800,actions=output:2
Modify Bucket in a Group Table
The following configuration shows modification of buckets in a group table.
Delete Group Table
In following configuration, users can delete the group table with following CLI.
Display the Information of Group Table
Users can display the information of all group tables.