## 3 System Design
### Background and Motivation  
One of the methods for achieving smooth evolution of future network architectures is to incrementally deploy ICN routers on top of existing network infrastructure [26]. In the context of IP-compatible ICN protocol stack design, one approach is to incrementally deploy an identifier protocol (IDP) on top of the IP layer [27], thereby empowering the implementation of network functions. The identifier protocol defines a set of rules that govern how packets should act on addresses based on ID, including actions such as addition, deletion, and modification. Figure 1 provides a design diagram of IP compatible ICN packets from the perspective of Ethernet frame structure. The IDP protocol is located at the network layer and can be implemented based on the extension header of IPv6. At the same time, a hierarchical resolution system called NMRS is utilized in our ICN to maintain the mapping relationship between ID and addresses [12]. Specifically, it is divided into Global Name Mapping and Resolution System (GNMRS) and Local Name Mapping and Resolution System (LNMRS). GNMRS maintains global identity address mapping and provides services to all users to ensure the accessibility of name resolution services. LNMRS maintains local identity address mapping and provides on-site services to users, with global and on-site resolution complementing each other. NMRS is a distributed autonomous system and can divide the entire network into hierarchical administrative domains (AD) based on constraints such as delay [28] and deploy a name mapping and resolution node in each administrative domain to accelerate name resolution services. Figure 2 illustrates the structure of NMRS. The figure shows a three-level administrative domain structure, with each administrative domain providing different levels of name resolution service latency protection. The number of administrative domain levels can be changed according to actual needs. Software-Defined Networking (SDN) [29] technology separates the control logic and forwarding plane of network devices, providing convenience for validating new network protocols and architectures. Currently, many SDN-based ICN architectures [30; 31] have been proposed. In our ICN architecture [12], we also use an SDN controller to manage the ICN routers. The SDN controller is responsible for collecting network topology and status information, and after route calculation, it pushes the forwarding information base to the data plane through a southbound interface. The data plane then performs ICN packet routing and forwarding based on the forwarding table. Drawing on the deployment scheme of ICN in [32], we consider using the overlay approach to deploy the ICN. IP routers form a underlay network, while ICN routers form an overlay network. ICN routers have computing and storage resources, can forward ICN packets and provide corresponding packet forwarding strategies, and are interconnected through IP logical links. The NA of data packets can be modified based on the local computation module's policy when passing through ICN routers. The following are examples of the extended functionalities of ICN on top of the IP network infrastructure: In a multipath transmission scenario [33], some ICN routers register their NA and Multipath Transmission Service ID (MPSID) mapping with the NMRS. These ICN routers are considered as relay  
Figure 1: Structure of ICN packet. nodes for end-to-end transmission. The data source can select multiple suitable relay ICN routers to construct multiple parallel single-hop relay paths between the data source and the receiver. In terms of mobility support [34], when a terminal device changes its network address due to a cellular change, it can register its device ID and new network address on the resolution system. The router or sending source can query the resolution system to obtain its network address, ensuring that there is no interruption during transmission.