## 4 Mechanisms and Optimizations
### Preference-Based Scheduling Strategies
Both mechanisms alleviate resource contention issues in the soft state to some extent, improving the scheduling success rate. Furthermore, each SN in IPCRSA maintains a computing routing flow table. When the local resource status information table is updated, the computing routing flow table is updated accordingly. Computing resource request packets in the IPCRSA route based on IDs, enabling dynamic late-binding of IP addresses. In the aforementioned scheduling scenario, the resource request packet corresponding to request C can be promptly matched

Figure 6: An example of computing resource scheduling in IPCRSA. with the updated flow table based on changes in resource status information. This enables timely rescheduling, forwarding the packet to other candidate CRNs for resource invocation, and enhancing the overall scheduling success rate. ## 5 Simulation

This section centers on the performance analysis of IPCRSA. Section 5.1 provides a brief overview of the simulation setup and relevant assumptions. Sections 5.2 and 5.3 validate and analyze the scheduling performance of IPCRSA under the combined influence of the on-path scheduling mechanism and the preference-based scheduling strategies from the two metrics of the success rate of scheduling and the average value of priority indicators corresponding to preferences, respectively. Section 5.4 provides a comparative discussion and summary of the method described in this paper and other methods in the simulation experiment. ### Simulation Setup and Assumptions

NetworkX is a Python library designed for the creation, analysis, and visualization of complex networks [53]. It offers Users a concise API that is easy to learn and use. The simulation experiment utilized NetworkX to create a hierarchical topology, as depicted in Figure 7, to simulate the topology structure of IPCRSA. In the diagram, blue and red nodes represent root SNs in the L\({}_{3}\) and L\({}_{2}\) level scheduling domains, respectively, while black nodes are leaf SNs within the L\({}_{3}\) level scheduling domains. Overall, the simulation topology includes nine L\({}_{3}\) level domains, three L\({}_{2}\) level domains, and one L\({}_{1}\) level domain. The intra-domain link delays between SNs in L\({}_{3}\), L\({}_{2}\), and L\({}_{1}\) level domains are set to random values within the ranges \([1\,ms,5\,ms]\), \([5\,ms,15\,ms]\), and \([15\,ms,30\,ms]\), respectively. Considering the nanosecond-level high-speed matching, processing, and forwarding capabilities of the SN's data plane for packets [54], the processing delay of packets at SNs can be neglected. Additionally, in this simulation experiment, it is assumed that each SN has a stable and minimal communication delay with its corresponding GN, which is negligible compared to the link delays between SNs. Therefore, the link delays between SNs become the primary factor that affects resource scheduling delays. It is important to note that, to focus on the computing resource scheduling process itself and make simulated topology more straightforward and understandable, GNs and CRNs are not labeled in the simulated topology diagram in Figure 7. However, they still exist and maintain the connectivity relationships with the SNs, as described in Section 3.1 in this simulation experiment. Figure 7: Topology in simulation experiment. Furthermore, given that the simulated topology is situated within an evolutionary ICN environment that routes based on IDs, this simulation experiment introduces a hashing algorithm to generate flat IDs for Users, SNs, and CRNs within the simulation environment. When implementing the resource scheduling function on each SN, a separate subprocess is included to facilitate the late-binding for IP addresses, allowing for the late-binding of scheduling targets in subsequent experiments.