Internames: Name-Centric Network Framework

• Internames is a framework that uses persistent names to address, link, and interact with users, content, and devices across networks.
• The architecture decouples identifiers from locators, enabling seamless mobility, multi-path routing, and gradual migration from legacy IP/DNS systems.
• Internames also supports automated cross-network identity resolution using profile, content, and network similarity metrics with proven accuracy in linking social accounts.

Internames denotes architectural and algorithmic frameworks centered on the use of names as the core abstraction for addressing, linking, and interacting with entities—users, content, devices, or services—across networked environments. Within this paradigm, names are decoupled from their network locations, allowing for dynamic, mobility-adaptive communication and identity linkage that transcends the limitations of static, host-centric addressing. Two principal systems exemplifying the Internames concept are: (1) name-to-name communication architectures for the future Internet (Melazzi et al., 2013), and (2) algorithms for automatic cross-network user identity reconciliation, as instituted in the “Finding Nemo” system (Jain et al., 2012).

1. The Internames Principle and Motivation

The Internames framework generalizes the role of names from a mere alias for an IP address to a first-class identifier for any communicating entity. All objects—user accounts, files, devices, logical endpoints—are addressed and discovered via persistent names, while their actual network reachability is dynamically determined as a function of location, time, context, and service availability (Melazzi et al., 2013).

Motivation for this name-centric abstraction arises from the limitations of classical host-to-host communication models, which are bound to static IP addressing and lack robust mechanisms for mobility, service-level interactions, or seamless operation across heterogeneous and intermittently connected networks. Internames addresses challenges such as user/service mobility, opportunistic and multi-path networking, information-centric delivery, and gradual migration toward next-generation Internet architectures.

2. Core Components of Internames Architecture

Fundamental building blocks of the Internames architectural blueprint are as follows (Melazzi et al., 2013):

1. Name-based Application Programming Interface (API): Internames exposes primitives—fetch, push, publish, subscribe, and search—enabling retrieval and interaction with named entities. The API is agnostic to underlying network location and supports both synchronous and asynchronous communication paradigms.
2. Separation of Identifiers and Locators: Every named-entity (NE) maintains a persistent identifier (name), e.g., n2n://nriA:Alice.com/cell, mapped at runtime to one or more locators, i.e., concrete network attachment points (NAPs). This enables seamless entity mobility and multi-homing, as locators are bound or updated independently of the name.
3. Name Resolution Service (NRS): The NRS is a distributed, DNS-compatible service that, upon input of a name (and optionally context), returns one or more Service Descriptors (SDs), each specifying a protocol, forwarding name, next-hop type, and next-hop address. Formally, the resolution function is:

$$R : \mathcal{N} \times \mathcal{C} \times \mathcal{T} \rightarrow 2^{SD}$$

where $\mathcal{N}$ is the set of names, $\mathcal{C}$ denotes context (such as location, QoS), and $\mathcal{T}$ is time.

1. Evolution and Migration Mechanisms: Internames is designed for coexistence with and incremental migration from legacy IP/DNS infrastructure. Content providers and ISPs can deploy NRS and introduce ICN (Information Centric Network) islands at the edge, with end-users remaining backward compatible until full stack transition.

3. Internames for Cross-Network Identity Resolution

In social computing, Internames also refers to the problem of automatically linking a single real-world user’s multiple online social identities in the absence of a global identifier. The “Finding Nemo” system (Jain et al., 2012) formalizes this as mapping, for each Twitter user $u_i^T$, the corresponding Facebook account $u_j^F$, if any, by exploiting three orthogonal similarity dimensions: profile, content, and network.

3.1 Similarity Dimensions

• Profile Similarity ($S_\mathrm{prof}$):

Includes normalized edit-distance and Jaccard similarity on username, display name, and location fields, along with image-histogram correlation of profile pictures.

$$S_{\mathrm{prof}}(u^T,u^F) = \frac{1}{4} \Big( \mathrm{ED}(\mathit{uname}^T, \mathit{uname}^F) + J(\mathit{name}^T, \mathit{name}^F) + J(\mathit{loc}^T, \mathit{loc}^F) + \mathrm{ImgSim}(T, F) \Big)$$

• Content Similarity ($S_\mathrm{cont}$):

Compares tf–idf vectors of recent posts and applies cosine similarity:

$$S_\mathrm{cont}(u^T, u^F) = \frac{\mathbf{v}^T \cdot \mathbf{v}^F}{\|\mathbf{v}^T\| \|\mathbf{v}^F\|}$$

• Network Similarity ($\mathcal{N}$0):

Computes neighborhood overlap between friends/followers lists:

$\mathcal{N}$1

3.2 Integrated Algorithm

A linear combination aggregates these signals:

$\mathcal{N}$2

with $\mathcal{N}$3, e.g., $\mathcal{N}$4. The decision rule applies a threshold $\mathcal{N}$5 (e.g., $\mathcal{N}$6) to $\mathcal{N}$7 for match declaration. This approach yields 40.5% accuracy for Twitter→Facebook linking on a ground-truth set of 543 accounts, with 99.5% of correctly linked users found among the top 10 candidates (Jain et al., 2012).

4. Operational Properties: Mobility, Scalability, and Consistency

Internames provides intrinsic support for sender and receiver mobility, multipath forwarding, and operation across heterogeneous and disconnected network realms (Melazzi et al., 2013). Upon movement, entities update their locator(s) in the NRS, which invalidates caches and notifies affected parties for seamless handover. Multipath selection is realized by name-routers or applications that choose among multiple SDs based on policy. Caching with time-to-live (TTL) values ensures low NRS lookup latency—comparable to DNS—while scalable NRS implementations use hierarchical or DHT-based schemes, attaining $\mathcal{N}$8 or $\mathcal{N}$9 lookup costs. Consistency across replicas is controlled by update propagation policies, supporting both strong (immediate propagation) and eventual (bounded delay, error-bounded mapping) models.

5. Deployment Scenarios and Migration Path

Internames is specifically architected to facilitate smooth transition from legacy host-centric networking to a name-driven paradigm. Initial deployment repurposes the existing DNS name field, with NRS modules backward compatible with DNS protocols. Content providers substitute authoritative DNS servers with NRS, operators incrementally introduce name-realms and network-realms (e.g., ICN islands, CCN, PURSUIT), and end-users are supported by DNS-compatible or native name-API stacks (Melazzi et al., 2013).

Actor	Today’s Infra	Step 1	Step 2
Content Provider	DNS, HTTP, proxies	Replace DNS with NRS	Deploy private ICN field
ISP / Carrier	IP transit	Nest name-routers	ICN transit field
End Users	IP+DNS clients	DNS-compatible NRS	Name-API stacks

Routing state remains manageable by confining large name tables to ICN domains. Resolution latency stays in the tens of milliseconds through caching, and mobility handover is typically bounded by NRS update propagation delay (hundreds of milliseconds for wide-area).

6. Limitations and Advanced Extensions

The Internames methodology, in both architectural and identity resolution contexts, is subject to fundamental limitations:

• Reliance on Public Information:

User linkage is impaired if profile/content/network information is private or manipulated (Jain et al., 2012).

• Content and Network Signal Scarcity:

Absence of cross-posting or mutual friends restricts the efficacy of respective similarity dimensions.

• API and Update Rate Constraints:

Large-scale, real-time operations are bottlenecked by social network API rate limits or NRS synchronization intervals.

Opportunities for extension include integration of stylometric/temporal/location-based features for user identity mapping, supervised or non-linear combination of similarity signals, and use of graph embeddings to represent cross-network structural similarity (Jain et al., 2012). In network architecture, context-dependent resolution, cross-field routing, and sophisticated cache consistency models can further enhance robustness and flexibility.

7. Significance in Contemporary Networked Systems

Internames provides a principled bridge from the IP host-centric Internet toward an information-centric, name-driven future (Melazzi et al., 2013). Its dual relevance to protocol architecture and identity resolution addresses key requirements in mobility, heterogeneity, and secure, context-aware communication. Empirical results from social identity linkage (Jain et al., 2012) and the deployment blueprint for incremental infrastructure migration (Melazzi et al., 2013) demonstrate the framework’s pragmatic value for the evolution of both online identity management and Internet architecture.