# Information-Centric Networks

#### Problems with today's Networks

- URLs and IP addresses are overloaded with locator and identifier functionality.
- No consistent way to keep track of *identical copies*.
- Information dissemination is inefficient.
    - Cannot benefit from existing copies
    - Can lead to problems like Flash-Crowd effect and Denial of service
- Can't trust a copy received from an untrusted node
    - Security is host-centric
    - Based on *securing channels* (encryption) and trusting servers (authentication)
- Application and content providers are independent of each other
    - CDNs focus on web content distributions for major players

![img](img/i.png)

**Important requirements for ICNs** (Information Centric Networks)

1. Accessing named resources - not hosts
2. Scalable distribution through replication and caching
3. Good control of resolution / routing and access

## Content-based Routing for ICNs

Apart from routing protocols that use direct identifiers of nodes, networking can take place based directly on content.

- Content can be **collected** from the network, **processed** in the network and **stored** in the network.
- The goal is to provide a network infrastructure capable of providing services better suited to today's application requirements
    - Content distribution and mobility
    - More resilience to disruption and failures

#### Network Evolution

**Traditional networking**

- Host-centric communications, addressing and endpoints

**ICNs**

- Data-centric communications addressing information
- Decoupling in space - neither sender nor receiver needs to know their partner.
- Decoupling in time - *answer* not necessarily directly triggered by a *question*. **asynchronous communication**.

#### Approach

- Named Data Objects (NDOs)
- In-network caching/storage
- Multi-party communication through replication
- Senders decoupled from receivers

### Dissemination Networking

- Data is requested by name, using any and all means available (IP, VPN tunnels, multicast, proxies etc.)
- Anything that hears the request and has a valid copy of the data can respond.
- The returned data is signed, and optionally secured, so its integrity and association with its name can be validated (data-centric security)

![ICN Stack](img/j.png)

- Change of network abstraction from **named host** to **named content** (content chunks).
- Security is built in - **secures content** and **not the hosts**.
- **Mobility** is present by design.
- Can handle **static** and **dynamic** content.

#### Naming Data

###### Solution 1 - Name the data

- **Flat** - non-human-readable identifiers
    - `1HJKRH535KJH252JLH3424JLBNL`
- **Hierarchical** - meaningful structured names
    - `/nytimes/sport/baseball/mets/game0224143`

###### Solution 2 - Describe the data

- With a set of tags
    - `baseball, new york, mets`
- With a schema that defines attributes, values and relations among attributes

##### Using Names in CCNs (Content Centric Networks)

- The hierarchical structure is used to do *longest-match look-ups*, which guarantees $log(n)$ state scaling for globally accessible data.
- Although CCN names are longer than IP identifiers, their **explicit structure** allows look-ups as efficient as IP's.

### ICN Forwarding

- The consumer *broadcasts* an *interest* over all available communication media
- The interest identifies a *collection of data* whose name has the interest as a prefix.
- Anything that hears the interest and has an element of the collection can respond with that data.

### ICN Transport

- Data that matches an interest *consumes* it.
- Interest must be re-expressed to get new data.
    - Controlling re-expressions allows for traffic management and congestion control.
- Multiple (distinct) interests in the same collection may be expressed

### ICN Caching

- Storage and caching are an integral part of the ICN service
- All nodes potentially have caches. Requests for data can be satisfied by any node holding a copy in its cache.
- ICN combines caching at the network edge with in-network caching.