Content-Centric Networking (CCN) is a new approach that moves from addressing end systems to naming content directly. This allows content to be cached within the network close to consumers for improved performance and reduces traffic by satisfying multiple requests from the same cached copy. CCN uses hierarchical content names, in-network caching, and interest and data packet types to enable content retrieval and routing. The architecture has in-network caching, no routing loops, and built-in security features to authenticate content.

1. Content-Centric
Networking (CCN)
CS4482 High Performance Networking
Dilum Bandara
Dilum.Bandara@uom.lk

2. Outline
 V. Jacobson, D. K. Smetters, J. D. Thornton, M.
Plass, N. Briggs, and R. Braynard, “Networking
Named Content,” In Proc ACM CoNext ‘09, Dec.
2009.
 What?
 Why?
 How?
2

3. Motivation
 60’s & 70’s
 Internet was designed to
share resources
 2 end points talking to each
other
 Today
 Content is the key
 Location is irrelevant
 Content name  End point
 Use network to reach the
end point
3

4. Motivation (Cont.)
 Issue – Traffic aggregation
 Scalability
 Availability
 Security
 Location dependent
 End is not the true end
 Solution is not wrong, problem
has changed
 CCN/NDN solution
 Hierarchy of warehouses
 Spatial & temporal locality
 Name & secure content
 Route using name
 Cache contents
4

5. Incentives
 Content providers
 Lower traffic
 Better security, scalability,
performance
 Consumers
 Better QoS, QoE
 Free local access
 Edge & Tier 2/3 ISPs
 Reduce transit traffic
 Diminishing return from
caching at higher levels
 Tier 1 ISPs & routers close
to content providers
 Starve
5

6. CCN Applications
 Content Delivery Networks (CDN)
 Streaming
 IPTV, Video on Demand (VoD)
 VoIP, teleconferencing
 Gathering sensor data & streaming
 Controlling actuators
 Light control
6

7. CCN Features
 In-network caching
 Unicast, multicast, broadcast
 Flow control
 No routing loops – nonce
 Ability to name non-existing data
 Enable them to be routed to potential data sources
 Security
 Mobility
 Incremental deployment
 Route symmetry
 Performance measuring, security
 Fine grained control of FIB entries & policies
 No need for DNS
7

8. Architecture
 Bits are bits whether they are in routers, wires,
or disks
8

9. Packet Format
 Datagram packets
 XML-based packets
 Receiver driven communication
 An interest packet must be send to get a data packet
 Clocking, Window of interests, Flow control
 Use 1st interest packet to find segment names
 CCNx implementation 9

10. Naming Content
10

11. Naming Content (Cont.)
 Unique names
 Binary or human readable
 Favor hierarchical names
 Large content is segmented
 Can invoke remote methods & pass data
 /seti.org/resources/update/check_status
 /seti.org/resources/update/node102/free_CPU_90
 Name unavailable contents
 /nws.org/radar9/data_x1_x2_y1_y2/
11

12. Node Architecture
 All nodes have
same architecture
 Size of tables &
capabilities may vary
 Multiple faces
 CS – exact match
 4KB packets
 PIT – exact match
 4 sec timeout
 FIB – longest prefix
match
12
PIT – downstream data path
FIB – upstream interest path
FIB – Forwarding information base

13. In-Network Caching
 ISPs
 Benefit from caching its transit traffic
 Can charge content providers to cache
 Different policies for content providers
 Varying cache sizes – static & dynamic
 Content provider can set cache validity
 Cache replacement policies
 IP routers – MRU replacement
 CCN routers – LRU or LFU replacement
13

14. Routing & Policies
 IS-IS or OSPF can be used
to fill in FIB
 Control plane policies
 Prefix forwarding
 Multi-path routing
 Default route at edge routers
 Data plane policies
 Policies per FIB entry
 Advertise/block specific
prefixes
 Priorities for faces
 e.g., WiFi preferred
over 3G
 Cache access/sharing 14
Settlement-free peering
Consumer-provider
relationship

15. Security
 In current Internet we trust the server & not the content
 Content authentication – Digital signatures
 Content is secured, not its location
 Self-signing or hierarchical certificates
 Private content can be encrypted
 DoS/DDoS
 Hard to attack ends
 Don’t know where interest packet will be answered
 Interest /data flooding is limited to a link
 Drop packets without a matching PIT entry
 Routers can check whether interests are getting data
 Content provider can ask routers to block
15

16. Issues
 Size of CS, PIT, & FIB
 CCN name not just a TV but its components
 Billions of domains, contents, & chunks
 State full routers
 Solutions – IP Tunneling, CCN interest tagged with IP
 Doesn’t support asynchronous communication
 1 message in IP  2/4 CCN messages
 Block m-to-1 communication
 No TTL  no constrained flooding
 Packets are not modified
 When should PIT time out?
 No clear boundaries
 Hard to separate issues in node architecture, naming, & security
16