Add acn
This commit is contained in:
102
docs/lectures/acn/07_information_centric_networks.md
Normal file
102
docs/lectures/acn/07_information_centric_networks.md
Normal file
@@ -0,0 +1,102 @@
|
||||
# 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
|
||||
|
||||

|
||||
|
||||
**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)
|
||||
|
||||

|
||||
|
||||
* 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.
|
||||
Reference in New Issue
Block a user