## 3 Multi-Scope State Area (MSSA)
### MSSA Structure
If a state is only used by one flow, it can be stored in the flow state area associated with the matching flow entry. Moreover the number of states in a flow state area is significantly less than the total number of states in the switch, and this makes sense. Even for stateful applications that require the storage of multi-flow sharing states (such as MAC learning and stateful firewalls), a majority of shared-state flows are bidirectional. Two-way flow will enter the same table, allowing the shared state to be recorded in the table state area. Figure 4: MSSA associate with the multilevel match-action tables. MSSA can fine-grainedly divide a large number of switch states into various tables, entries, and packet state areas. The state-sharing scope limitation can narrow the search range and avoid the long search or insertion times that occur when the state is stored in the one big table. The state's storage location is close to the use state's packet, allowing for faster state querying. Any kind of state sharing. MSSA is able to meet any state sharing needs, despite the sharing scope's restrictions on state access in the state area. The state shared by packets from different flows can be placed in the nearest common parent node of the packet state area in MSSA's tree structure. At time \(t\), packet a matches Table 1 entry 1, packets b and c match Table 1 entry \(i\), and packet d matches table \(t\) entry \(j\), as shown in Figure 5. Because both \(c\) and \(d\) will match Table 1 entry \(i\), the shared state of them must be placed in the Table 1 entry \(i\)'s flow state area. Meanwhile, packets \(a\) and \(d\) enter different tables, so the state shared by both of them need to be placed in the global state area. Although the sharing scope limits state access, the packet in the switch can share the state with any other packet. In the worst-case scenario, the state is recorded in the global state area. While a large number of table state areas and flow state areas can relieve the pressure on the global state area. Rapid state space recovery and reuse  
It is difficult to determine whether a state shared by multiple flows can be deleted, even if some of the flows have left the switch. Because the state recorded on the data plane is not backed up, an accidental deletion of the state will not only affect the logic of the network application, but it will also be irreversible. As a result, using a table to record the status and setting a timeout period for the states is risky. MSSA is linked to the match-action table, and the state area with a shared scope can specify the state's deletion time. When an entry is deleted, the state in the flow state area associated with the entry can be deleted as well. Because the flow-state area's state is only shared by packets that match the entry. There will be no more packets matching the entry after the entry is deleted, so the related state can be safely deleted. Similarly, the state in the table's associated state area can be deleted after the table is deleted. Therefore, MSSA not only allows for fine-grained state division and narrows the scope of state search, but it also allows for the safe and timely deletion of states, freeing up storage space for the continued storage of new states. In summary, Table 2 summarizes the four types of states' sharing scope, life cycle, and amount. Figure 5: MSSA satisfies any kind of state sharing. At time \(t\), the state shared by packets \(a\) and \(d\) is recorded in the global state area, and the state shared by packets \(b\) and \(c\) is recorded in the Table 1 entry \(i\)’s flow state area.