## 5 Related Work  
We reviewed previous studies on the expansion of switch state capabilities. Open-State [24] is an early proposed stateful data plane that extends the OpenFlow abstraction with the EFSM abstraction (Extended Finite State Machine). OpenState records the flow state in the state table, and the state machine is implemented by using the XFSM table. To get the state, the packet can use header fields to look up the state table. It obtains the forwarding operation after traversing the XFSM table and updates the state table with the header fields to the new state. OpenState handles the state by extending the state table and the EFSM table, and obtaining the state requires a lookup. This paper proposes a method for storing states by linking the match-action table and MSSA, and then making use of the switch's already-existing action processing state. On the one hand, it avoids the complexity introduced by the addition of new types of tables, while also avoiding the time overhead introduced by looking up the state. FAST [26] includes a state machine similar to OpenState, but it reduces the size of the state table to avoid state explosion. The state machine is implemented in FAST by using four tables: the state machine filter, the state table, the state transition table, and the action table. FAST supports multiple state tables to improve state scalability. SDPA [27] created a co-processing unit called the FP (Forwarding Processor) to manage the switch's state. FP contains three tables: the state table, the state transition table, and the action table. SDPA supports multi-state applications by allowing multiple FPs in the switch. However, the first packet of the flow should be sent to the controller to determine which FP it enters. FAST and SDPA classify states into different state tables based on the application to which they belong. However, the state shared by multiple applications will be recorded in multiple tables, creating a redundancy issue. The redundant state also makes updating the state more difficult. Moreover, for applications that use state on a large scale, this application's state table still has the risk of state explosion. The method in this paper uses the state sharing scope to classify states into four types: global state, table state, flow state, and packet state, and then divides them into \(1+t+\sum_{i=0}^{t}f_{i}+\sum_{i=0}^{p}P_{i}\) fine-grained state areas. It meets all of the switch's possible state-sharing requirements and significantly reduces the number of states that can be stored in a single state area. FlowBlaze [28] improves state capabilities. One of the limitations of flow state is that it cannot be shared between different flows. FlowBlaze recommends using global registers to record the global state shared by multiple flows. The flow context table is used  
Figure 15: Compare the space consumption of using MSSA and hash table to record state. by FlowBlaze to store the flow state, and the EFSM table is used to implement the state machine. Banzai [19] and P4 [30] both support recording global status via registers, but neither supports recording flow states. Although global registers can be used to share state between any flows, the number of registers is limited and therefore unsuitable for large-scale state storage application scenarios. Furthermore, recording all flows sharing states in the global space will increase the global space's management difficulty. In general, the processing state on the data plane has drawn a lot of research attention, but existing solutions still have some issues: (1) store state by extending new tables--the state search time cannot be guaranteed, and slow insertion in the large-scale table will have a significant impact on the switch's throughput; (2) divide the state according to the using state application--the granularity of division is insufficient to effectively avoid the problem of state explosion that may exist in a single state table; and (3) use limited global registers to store shared state between flows.