HTTP-over-ICN Anchoring via NAP Border Gateway Translation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The transition to information-centric networking (ICN) poses challenges in integrating IP-based services and applications, requiring significant modifications to user equipment, server components, and development environments, making it difficult to migrate existing IP-based services to ICN networks without disrupting current network functionalities.
Innovation Solution
The implementation of an ICN network attachment point (NAP) or border gateway (BGW) that anchors HTTP-level communication, allowing IP-based devices to communicate within and across ICN and IP networks by encapsulating HTTP requests and responses, using named content identifiers determined through hash functions of FQDNs and URLs, enabling seamless interaction between ICN and IP networks.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If ICN network architecture is implemented, then network-level functions such as multicast support and in-network caching are improved, but device complexity and ease of operation deteriorate due to required modifications in user equipment, server components, and development environments
Solution Approach 1:
The patent introduces an intermediary translation layer between ICN and IP networks that handles protocol conversion and mapping. This intermediary component absorbs the complexity of ICN implementation details, allowing existing IP-based devices and applications to operate without modification while still benefiting from ICN network-level functions.
Solution Approach 2:
The patent segments the network architecture into distinct translation layers and mapping components that separate ICN-specific functionality from general network operations. This segmentation isolates complexity to specific modules while maintaining simplicity in the overall system and existing devices.
2Productivity
If full transition to ICN-based solution is made, then network performance is improved, but ease of operation worsens due to difficulty of implementing changes to device operating systems and applications
Solution Approach 1:
The translation layer acts as a mediator that enables IP-based devices to access ICN network resources without requiring changes to device operating systems or applications. The intermediary handles all protocol conversions and mappings, maintaining ease of operation while enabling improved network performance through ICN capabilities.
Solution Approach 2:
The patent creates a universal translation mechanism that works with existing IP-based devices, applications, and protocols while enabling access to ICN network functions. This multi-functional approach allows the system to serve both traditional IP networks and modern ICN networks through a single translation infrastructure.
3Ease of operation
If IP-based services continue to operate without changes, then ease of operation is maintained, but adaptability to ICN network architecture deteriorates
Solution Approach 1:
The translation layer serves as an adaptable intermediary that can map various IP-based services and protocols to ICN network architecture. This intermediary provides adaptability by handling different service types (web browsing, file transfer, streaming) through unified translation mechanisms while maintaining ease of operation for existing applications.
Data Source
AI summary
Methods and systems anchor hypertext transfer protocol (HTTP) level communication in an information-centric networking (ICN) network. Both content requests and responses to servers within the ICN network and to servers located outside the ICN network, in an IP network for example, are disclosed. Communication may be between two IP capable only devices at the HTTP level, one connected to an ICN network while the other one is connected either to an ICN or IP network. The disclosed namespace 200 enables IP based HTTP communication within the ICN network. An information-centric networking (ICN) network attachment point (NAP) or border gateway (BGW) may receive an HTTP request packet and encapsulate the received HTTP request packet. The ICN NAP/BGW may then forward the HTTP request packet towards the local ICN network servers. The HTTP request packet may be published to a named content identifier (CID) that may be determined through a hash function of a fully qualified domain name (FQDN). The ICN NAP may receive a HTTP response packet for a subscribed information item, which may be included in a named rCID. The named rCID may be determined through a hash function of a uniform resource locator (URL). Instead of using the hash of a URL and an FQDN directly, a separate scope identifier, which may be a root identifier, may be chosen for HTTP-over-ICN communication for the overall ICN namespace. The scope identifier may include a particular structure for the ICN namespace being built up. Using a root identifier may allow for separating HTTP-over-ICN communication from other ICN communication, for example, for operational or migration reasons. Under the root scope identifier, there may be two sub-scope identifiers, a first sub-scope identifier (I) for communication within the ICN network and a second sub-scope identifier (O) for communication to IP addresses outside the ICN network. The ICN may be based on the PURSUIT publish-subscribe architecture or on the Named Data Networking (NDN) project and the like.