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!