Networking Named ContentVan Jacobson, Diana K. Smetters, James D.

Thornton, Michael F. Plass, Nicholas H. Briggs, Rebecca L. Braynard

Content Centric Networking

Network use has evolved since IP was designed Usage of the Internet is in terms of what not

where CCN: architecure built on named data rather than

named hosts Provides security, scalability, performance.

Content Centric Networking

Two packet types: Interest and Data Heirarchical content naming scheme

Allows dynamic content generation: active names CCN node has 3 components: FIB, Content Store

and PIT FIB: Forwarding table, allows multiple output

faces Content Store: Buffer, also caches Data packets PIT: Pending Interest Table

CCN Nodes

Processing an Interest:

– Matching Data is found in the Content Store => send it and consume Interest

– Pending Interest in PIT=> add this face to RequestingFaces list

– Use FIB to forward Interest on outgoing faces, add to PIT

Processing Data: Data follows a chain if PIT entries back to the

source Duplicate and unsolicited Data is discarded

Reliability and Flow Control

Interests serve the role of window advertisements Each packet is independent => TCP SACK is

implicit Flow balance is maintained at each hop, not end-

to-end like TCP Thus additional, TCP-like congestion control

mechanisms not required.

Naming Content

Hierarchical content names with a flexible format Individual name consists of a number of

components Names can be relative to some known name, e.g.

next/previous Same content can have multiple names! Problems

with caching? A source of data performs a Register operation

for a prefix

Routing

Routing between CCN nodes can occur over unmodified OSPF.

Incremental deployment of CCN nodes is possible Integration with BGP is also possible Routers do not construct spanning trees

Loops are not possible anyway Multiple paths can be used

Content Based Security

Security travels with the content, it is not a property of the connection

CCN authenticates name-content bindings by signing the name and content in each data packet

Arbitrary key management schemes can be used over CCN

Keys can be sent over CCN since they are just another piece of data

If we trust some public keys, we can infer more

Network Security

Sending a malicious packet to a host is difficult because CCN talks only about content, not to hosts

Data based DoS attacks are impossible because only one Data packet is forwarded per Interest

Interest flooding: Multiple Interests for the same content are

combined Limit the forwarding of unsuccesful interests

What if sender and receiver collude?

Evaluation

Transfer time vs Number of Sinks

Evaluation

Failover

An Architecture for Internet Data Transfer

Niraj Tolia, Michael Kaminsky, David G. Andersen, and Swapnil Patil

Data Oriented Transfer Service

Seperate control from data Control logic is application specific; use DOT for

all data transfer Benefits:

Transfer techniques can reused and new ones tried Coding, multi-pass compression, caching etc. can

be applied by the transfer service Multi-path transfers Cross application data processors

DOT

DOT provides an API and a plugin architecture

Transfer Plugins: eg. Multi-path, portable storage Storage Plugins: access to local data, divide data

into chunks, compute hashes Basic API:

Sender calls put with data, gets back an OID Receiver uses OID to get data

Evaluation

Multipath Plugin: Using two 100 Mbit/s Ethernet links, transfer time went down from 3.59 seconds to 1.90 seconds

Modified Postfix mail server to use DOT Minimal modification: 184 LoC DOT saves 20% of total message bytes transferred

Duplicated messages Partial redundancies in messages

Thank You!