## 3 Design Overview
### Architecture Overview  
In previous works [14; 37], we proposed an ICN multipath transmission system compatible with IP infrastructure. The system treats multipath transmission as a service within the ICN network and assigns identifiers for its management. It also constructs multipath topologies derived from relay node selection. These studies primarily aimed to optimize the selection criteria for multipath service nodes and to refine scheduling mechanisms for improved transmission efficiency. In this paper, we further explore how to deploy this system in large-scale IP network environments using gateways, thereby introducing the performance benefits of ICN multipath transmission. Specifically, we focus on enhancing gateway functionality, designing the reordering module, and optimizing buffer management strategies. As shown in Figure 1, an 'island' of ICN multipath transmission service area is formed within the 'ocean' of IP-based networks. The routing domains of the two networks remain separate, and IP terminal devices require no modifications. By communicating with the gateway using the TCP/IP protocol, they can benefit from the performance advantages provided by ICN multipath transmission services.  
We use an ICN architecture based on the independent Name Mapping and Resolution System (NMRS) [38]. In this ICN paradigm, all devices, content, and services are considered network entities and are assigned unique Entity-IDs (EIDs) for identification, with the NMRS maintaining the mapping between identifiers and locators. An Identifier Protocol (IDP) [31] is extended over the IP protocol to introduce an identifier-address separation mechanism, without requiring significant modifications to the existing IP network. By using IP addresses (NA) as network locators, this approach ensures compatibility with existing IP infrastructure. This compatibility enables ICN nodes to effectively handle both ICN and IP traffic. Therefore, the gateway system can be easily deployed at the edge routers of the ICN network (e.g., GW-A, GW-B) in practical deployments. All gateway nodes collectively maintain a Protocol Conversion Information Table (PCIT). Once an IP device establishes communication with a nearby gateway, the mapping between the user's IP and the gateway's EID is stored in the PCIT to define the user range serviced by the gateway. For example, in the data transmission process from S1 to C1 in Figure 1, after receiving a packet, GW-A extracts the destination IP address and retrieves the corresponding service gateway (GW-B)'s device EID from the PCIT, then queries GW-B's Network Address (NA) through NMRS. In a TCP/IP packet, a five-tuple identifies the flow, and we use this five-tuple information to construct a URI, which is then hashed to generate a unique flow identifier (Flow EID). Based on the identifier and locator information obtained in Steps 1-4, GW-A can construct an ICN packet (Step 5), which can then be routed within the ICN network. Since the operation of hashing the URI to obtain the EID is irreversible, GW-B cannot extract the destination IP device's address from the EID information carried by the ICN packet. To reconstruct the TCP/IP packet at the egress gateway, we refer to commonly used methods [39; 40] by including additional control information within the ICN packet. Specifically, before each flow's data transmission begins, the ingress gateway sends a separate ICN packet to the egress gateway containing information related to the flow, which the egress gateway caches for reconstructing the connection with the destination IP node. The service EID field in the IDP enables differentiation between control information packets and multipath transmission data packets, allowing different routing modes to be applied within the ICN and different packet processing methods to be used at the gateway nodes.