Networking Named Content Van 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!