## 3 Information-Centric Networking
### Why ICN for INC  
**Named Data. ** ICN uses unique, persistent names to identify content. Uniqueness guarantees that a particular name corresponds to a single piece of content only. Persistency ensures that names remain valid even if the content is moved, replicated, or cached in different locations. By doing so, the data are globally addressable and retrievable without the need for dynamic updates to a location-dependent routing system. Names can be _flat_ (opaque identifiers without structural semantics), or _hierarchical_ (structured, human-readable identifiers) [16]. Hierarchical names are particularly common in ICN architectures, as they resemble familiar constructs like URLs. In addition, the hierarchical structure enables intuitive organization, easier routing, and discovery of related content by leveraging meaningful prefixes and namespaces. Beyond identifying static content, ICN names can be extended to services and on-demand content. Indeed, services can also be named using a hierarchical scheme that reflects their functionality and context. Similarly, on-demand content, such as real-time sensor data or live video streams, can be named dynamically to represent the temporal or contextual state of the data (e.g., _/sensor/temperature/room1/timestamp_). As a result, named packets can be used by client applications to easily request computation services. This simplifies the invocation of in-network computations, as service requests and responses are inherently tied to named-based network primitives. Additionally, named software code can be requested by network nodes for local installation, enabling on-the-fly deployment of computation tasks or updates to existing services. This capability aligns with the principles of INC by allowing nodes to dynamically acquire and execute the required functionality without prior configuration. For instance, a node could retrieve named software modules to perform data compression on-the-fly for downstream clients. Similarly, computational workflows can be modularized and addressed by name, enabling nodes to fetch and compose the necessary components to fulfill complex processing requests. This adaptability reduces dependency on pre-installed software and enhances the agility of the network in responding to diverse application requirements. **In-Network Caching. ** In ICN, data can be cached at intermediate network nodes (e.g., routers) as they traverse the network: when a user requests specific content, the network can serve it directly from a nearby cache rather than fetching it from the original producer. By providing such a core INC service, ICN not only reduces redundant data transfers but also brings content closer to the user, resulting in faster content delivery, reduced latency,and lower network congestion. In parallel, by alleviating the load on origin servers and optimizing bandwidth utilization, in-network caching significantly enhances the scalability and efficiency of the network [22]. An important extension of this principle is the caching of service outputs [48]. In scenarios involving in-network computing, computational results (e.g., processed video/images, analytic outcomes) can also be cached at network nodes by enabling what is known as _compute reuse_[50]. This is another pillar of INC deployments, where results of a previously executed service are reused to fulfill similar requests without needing to re-execute the computation. Compute reuse is particularly advantageous in use cases such as video transcoding, machine learning inference, and IoT analytics, where identical or similar computations are frequently performed on the same data. For example, a node might cache the output of a video compression service. If another user requests the same video in the same compressed format, the network can directly serve the cached result, avoiding the need to rerun the compression process. This reduces computational overhead, conserves energy, and minimizes response times. Moreover, compute reuse enhances fault tolerance by providing a fallback mechanism.