## 3 Architecture
### IPCRSA Overview
#### 3.1.1 Scheduling Node  
The SNs in IPCRSA also serve as ICN nodes, implementing computing resource scheduling based on ICN. As depicted in Figure 2, the composition structure of SNs can be divided into the control plane and the data plane. The main function modules in the control plane include the ID Management Module, Topology Construction Module, Resource Status Notification Module, and Computing Resource Scheduling Module. The data plane is responsible for receiving, processing, and forwarding computing resource request packets. The ID Management Module oversees the management of identifiers and network addresses mapping relationships of SNs, ensuring the addressability of SNs within the ICN. Leveraging the ID Management Module, the Topology Construction Module accomplishes the construction of logical topology for resource status notification and resource scheduling, ultimately forming the hierarchical logical topology structure of IPCRSA, as illustrated in Figure 1 (The logical topology describes the way data packets flow within a network, determined by network protocols and configurations). The Resource Status Notification Module, based on the hierarchical topology structure, synchronizes resource status informa  
Figure 1: IPCRSA overview. tion among SNs, forming a resource status information table in each SN. The Computing Resource Scheduling Module, relying on the resource status information table, executes computing resource scheduling strategies. In collaboration with the Computing Resource Scheduling Module, the data plane of each SN processes and forwards computing resource request packets, thereby conducting on-path computing resource scheduling. The specific functionalities of each module and their interrelationships will be further elucidated in the subsequent sections. * ID Management Module  
As shown in Table 2, in IPCRSA, SNs within the scheduling domains at the L\({}_{x}\) level possess identical and flat resource scheduling service identifiers, denoted as RSS_ID_L\({}_{x}\), indicating that they can provide resource scheduling service in the corresponding scheduling domain at level L\({}_{x}\). The mapping relationship between the SN's RSS_ID_L\({}_{x}\) and IP is maintained by a hierarchical ICN name resolution system similar to the one discussed in SEANet [50]. The basic structure of the hierarchical name resolution system is illustrated in Figure 3. The resolution domains (the scope within which name resolution services can be provided) are divided into three levels: L\({}_{3}\), L\({}_{2}\), and L\({}_{1}\), adhering to the principle of inter-layer nesting and intra-layer non-intersection. From level L\({}_{3}\) to L\({}_{1}\), the coverage scope of the resolution domains gradually expands. RNs within each level's resolution domains are the main components of this hierarchical name resolution system. They are responsible for maintaining the mapping relationships between IDs and IP addresses of all entities (such as SNs, Users, etc.) within their resolution domains in the ICN environment. The RNs themselves \begin{table}
\begin{tabular}{l l} \hline \hline
**ID** & **Meaning** \\ \hline RSS\_ID\_L\({}_{1}\) & Provide Resource Scheduling Service in L\({}_{1}\) \\ RSS\_ID\_L\({}_{2}\) & Provide Resource Scheduling Service in L\({}_{2}\) \\ RSS\_ID\_L\({}_{3}\) & Provide Resource Scheduling Service in L\({}_{3}\) \\ CRS\_ID\_T\({}_{1}\) & Provide Computing Resource Service with Type T\({}_{1}\) \\ CRS\_ID\_T\({}_{2}\) & Provide Computing Resource Service with Type T\({}_{2}\) \\ CRS\_ID\_T\({}_{3}\) & Provide Computing Resource Service with Type T\({}_{3}\) \\ USER\_ID & Represent A Computing Resource Requestor in IPCRSA \\ \hline \hline \end{tabular}
\end{table} 
Table 2: IDs in IPCRSA. Figure 2: Architecture and function modules of SN. follow a multi-layered tree structure, providing name resolution services within the scope of different levels' resolution domains.