# 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 un-trusted 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](/lectures/acn/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 end-points

**ICNs**

- Data-Centric communications addressing information
- Decoupling in space - neither sender nor receiver need 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, multi-cast, 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 & association with 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 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

* Consumer *broadcasts* and *interest* over all available communication media
* Interest identifies a *collection of data* whose name has the interest as a prefex.
* 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 integral part of the ICN service
* All nodes potentially have caches. Requests for data can be satisfied by any node holding a copy in it's cache.
* ICN combines caching at the network edge with in-network caching.