## 3 Architecture
### IPCRSA Overview
#### 3.1.1 Scheduling Node
* Resource Status Notification Module  
The primary responsibilities of the Resource Status Notification Module are as follows: (1) Fetching communication delay information among SNs within the domain as measured by the Topology Construction Module. (2) Receiving and processing local CRNs' status information reported by connected SNs. (3) Receiving CRNs' status information from other SNs within its scheduling domain. (4) Notifying local CRNs' status information to other SNs within the domain. (5) Aggregating CRNs' status information, performing the fetch of communication delay among SNs and resource status information notification in the corresponding scheduling domain at the upper level, in the condition that the associated SN of the module is the root node of the scheduling domain. (6) Forming a resource status information table and storing it locally. The GNs can perceive and monitor the status information of CRNs connected to them and report it to the SNs, as elaborated in Section 3.1.2 below. CRNs can be categorized into various types based on their purposes. CRNs of the same type share the same computing resource service identifier, CRS_ID_T\({}_{x}\), indicating that these CRNs can provide computing resource services of the corresponding type T\({}_{x}\). A detailed introduction is provided in the subsequent Section 3.1.3. The notification of computing resource status information relies on the topology constructed by the Topology Construction Module and is disseminated using a flooding mechanism. The relevant fields of the resource status information table and their meanings are shown in Table 3 above. Each entry in the table records network and computing resource status information related to a CRN. * Computing Resource Scheduling Module  
The Computing Resource Scheduling Module serves as the execution unit for computing resource scheduling strategies. In IPCRSA, user resource requests are sent from the Clients to the SN's data plane in the form of computing resource request packets, and the Clients query the IP addresses of the SNs corresponding to the RSS_ID_L\({}_{x}\) through the ICN name resolution system, then send the packets to the designated SN. This process will be elaborated in Section 3.3 of the following text. The Computing Resource Scheduling Module, relying on the status information of various CRNs in the local resource status information table, executes the corresponding computing resource scheduling strategy. It precomputes and generates a computing routing flow table, which is then sent to the data plane based on the southbound interface protocol. This flow table guides the processing and forwarding of computing resource request packets. The flow table matching process of in-transit packets is akin to the execution of scheduling strategies. In other words, by on-path matching, processing, and forwarding the request packets, the module seeks CRNs that meet the User's demands, implementing computing resource scheduling. Furthermore, in the ICN environment where routing is based on IDs, the data plane of the SN can adjust the scheduling targets of the request packets based on the current resource status information during their routing process, thereby enhancing the flexibility of resource scheduling. The specific computing resource scheduling strategies and the data plane's processing and forwarding mechanisms for computing resource request packets during the flow table matching process will be elaborated in Sections 4.1 and 4.2, respectively.