## 2 Match-Action Model  
The match-action model is the most widely used model for data-plane programmable devices to process packets. This is primarily due to its abstraction of \"flow\", that is, the set of traffic defined by the wildcard rule on the packet's header field. Additionally, the flow abstraction makes it possible for the programmer to effectively implement L2/L3 forwarding, firewall, and QoS logic familiar to the processing logic in the traditional data-plane device [34]. The match-action model is widely used in data-plane programming languages (OpenFlow1.1+ [35], P4 [30]), reconfigurable ASICs (RMT [36]), software switches (OVS [37], Eswitch [38]), and programmable core data paths (eBPF/XDP [39]) (FastClick [40], BESS [41], NetBricks [42]). To describe the packet processing logic, the match-action model uses a series of tables containing user-defined two-tuples (rules-actions) [43]. As shown in Figure 1, the switch's pipeline processes packets through one or more match-action tables (MAT). The pipeline always starts with the first MAT to match packets. Table entries include packet match fields and packet processing actions. A packet is processed if an entry in the MAT matches it, and the action in that entry can direct the packet to another MAT to continue matching. If not, the packet is processed by the table's default entry. Normally, the default entry will either send the packet to the controller or discard it. Extract the matching field to match the MAT and get the highest priority matching entry, where the matching field can come from the packet's ingress port, packet header fields, or metadata. (2) The action in the matching table entry may modify the packet or metadata. (3) The action in the matching table entry will send the packet to other flow tables, forward the packet to the port, or discard the packet [35]. As can be seen, the match-action model focuses on packet field processing and lacks state processing capabilities. Even though metadata can be used to store user-defined states, the data in metadata are  
Figure 1: Pipeline process packets. (**a**) The packet matches the match–action table in the Pipeline. (**b**) Match–action table processing packet. only available for a limited time. As soon as the packet leaves the pipeline, the state data are lost [44]. To understand the difficulty of processing state on the data plane, we first introduce the concept of state [22]. The network defines state as the data that should be stored in the network device to process future packets. For example, a stateful firewall tracks the connection state and decides whether to allow or reject a packet based on that state. Reference [23] summarizes the three key features of the stateful data plane: (1) the state can be saved in the data plane, (2) the data plane can update its own saved state, and (3) the data plane is programmable. It is not easy to satisfy all three characteristics on the data plane while also acting as the state to help the switch process future packets. The problem is as follows:  
1. The state storage structure affects storage space utilization and search speed. As previously stated, using the match-action table to record the states of tens of millions of connections requires far more space than the switch's SRAM can provide. Using the match-action table to record states is a bit wasteful. As shown in Table 1, the table must record the state, as well as the matching key used to get it. These keys may already exist in other tables, and storing them multiple times wastes space. Furthermore, all states are stored in a single table, likely to result in state explosion and a slow search speed [31]. (2) Multi-flow state sharing. We now know that the state helps the switch in packet processing. If the state-recording packet and the state-using packet do not belong to the same flow, that is, if a state is shared by two or more flows, storing this state in a single table becomes difficult, because these flows may not have the same field value as the key used to identify the state.