Content Centric Networking

Uichin Lee
KAIST KSE

Based on Van Jacobsons slide decks

http://www.ccnx.org/
 Talk Plan
A Brief History of Networking (+Motivation)
Node Model
Routing
Transport
 A Brief History of Networking
Generation 1: the phone system
(focus on the wires)

Generation 2: the Internet

(focus on the endpoints)

Generation 3? dissemination
(focus on the data)
 The Phone System is not about
phones, its about connecting wires to
other wires

The utility of the system depends on running

wires to every home & office
The wires are the dominant cost
Revenue comes from dynamically constructing
a path from caller to callee
A business model built on side effects
For a telco, a call is not the conversation you
have with your mom in Phoenix, its a PATH
between two end-office line cards
A phone number is not the name of your
moms phone, its a program for the end-
office switch fabric to build a path to the
destination line card
 Some ways to build paths

Sequential switch sequencing

(Strowger stepper)

Switchboard coordinate
(AT&T Operators, 1959)
 Structural problems with
phone systems
Path building is non-local and encourages
centralization and monopoly
Calls fail if any element in path fails so
reliability goes down exponentially as the
system scales up
Data cant flow until a path is set up so
efficiency decreases when setup time or
bandwidth increases or holding time
decreases
 Gen 2: packet switching
Paul Baran, 1964

Change point view to focus on

endpoints rather than paths
Data sent in independent chunks
and each chunk contains the name
of the final destination
(Transitivity) If node gets a chunk for
a different destination, tries to
forward it using static configuration
or distributed routing computation
Don Davies, 1963
Packet switching used the existing
wires, it just used them differently

In 1964 these ideas were lunatic fringe anyone

who knew anything about communications
knew this could never work
 ARPAnet
September, 1971
 ARPAnet
The ARPAnet was built on top of the existing
phone system
It needed cheap, ubiquitous wires
It needed a digital signaling technology (but not
anything like the state of the art)
At the outset, the new network looked like an
inefficient way to use the old network
The rest of the research community put
enormous effort into the details of circuit
switched data. In the end it didnt matter
 The CATENET and TCP/IP
Bob Kahn, 1973
Packet switching worked so well
that by 1973 everyone wanted a
network
Each was done as a clean slate so
they didnt interoperate
Since Paul had already abstracted
out all the topological details Vint
realized that a common
encapsulation & addressing
structure could glue together
arbitrary networks
Vint Cerf, 1973
Multinetwork Demonstration 1977
 TCP/IP wins
Adaptive routing lets system repair
failures and hook itself up initially.
Reliability increases exponentially
with system size.
No call setup means high efficiency
at any bandwidth, holding time or
scale.
Distributed routing supports any
topology and tends to spread load
and avoid a hierarchys hot spots.
 TCP/IP issues
Connected is a binary attribute: youre
either part of the internet and can talk to
everything or youre isolated.
Becoming part of the internet requires a
globally unique, globally known IP address
thats topologically stable on routing time
scales (minutes to hours).
connecting is a heavy weight operation
the net doesnt like things that move
 Like the phone system before it, TCP/IP solved the
problems it set out to solve so well that even today its
hard to conceive of an alternative.
TCP/IPs issues dont reflect an architectural failing but
rather its massive success in creating a world rich in
information & communication.
When TCP/IP was invented there were few machines
and many users per machine. Today there are many
machines and many machines per user, all with vast
amounts of data to be synchronized & shared.
And that creates an entirely new class of problem . . .
 The raison dtre of todays
networking, both circuit switched
and TCP/IP is to allow two machines
to have a conversation
The overwhelming use (>99% by
most measurements) of todays
networks is for a machine to acquire
named chunks of data (like web
pages, or email messages)

Acquiring named chunks of data is not a

conversation, its a dissemination (the computer
equivalent of Does anybody have the time?)
 In a dissemination the data matters,
not the supplier
Its possible to disseminate via conversation and get the
data as a side effect, But:

Security is an afterthought. Channels are secured, not

data, so theres no way to know if what you got is
complete, consistent or even what you asked for.
Its inefficient (hotspots, poor reliability, poor
utilization).
Users have to do the translation between their goal &
its realization and manually set up the plumbing to
make things happen.
 Dissemination networking
Data is request by name, using any and all
means available (IP, VPN tunnels, multicast,
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)
 Content Centric Networking (CCN): Goals

Create a simple, universal, flexible

communication architecture that:
Matches todays communication problems
Matches todays application design patterns
Is at least as scalable & efficient as TCP/IP
Is much more secure
Requires far less configuration
 Universal?
Any architecture that runs over anything is an
overlay (IP is an overlay).
IP started as a phone system overlay; today much
of the phone system is an IP overlay. System
theorists would say IP is universal.
CCN has the same character: it can run over
anything, including IP, and anything can run over
CCN, including IP.
And CCN has a simpler, more general relationship
with lower layers than IP.
 There are two ways
to view CCN

a universal middleware
an IP for content

The difference between these is

deployment time horizon
 IP to chunks of named content
Strategy: exploit multiple simultaneous connectivities for data delivery
(e.g., ethernet, 3G, WiFi) due to its simpler relationship with layer 2

Current Internet CCN

 Talk Plan
A Brief History of Networking (+Motivation)
Node Model
Routing
Transport
 CCN packets

There are two CCN packet types:

interest (similar to http get) and data
(similar to http response). Both are
encoded in an efficient binary XML.
 Content-Based Security
Name-content mapping verification via per-data
packet signature
Data packet is authenticated with digital signature

CCN trust establishment by associating

content namespaces w/ public keys
 Basic CCN forwarding
Consumer broadcasts an interest over any
& all available communications media:
get /parc.com/van/presentation.pdf

Interest identifies a collection of data - all data

items whose name has the interest as a prefix.
Anything that hears the interest and has an
element of the collection can respond with
that data:
HereIs /parc.com/van/presentation.pdf/p1 <data>
 Basic CCN transport
Data that matches an interest consumes it.
Interest must be re-expressed to get new data.
(Controlling the re-expression allows for traffic
management and environmental adaptation.)
Multiple (distinct) interests in same collection
may be expressed (similar to TCP window).
 Internally, CCN names are
opaque, structured byte strings
/parc.com/van/cal/417.vcf/v3/s0/0x3fdc96a4...

is represented as a component count

then, for each component, a byte count
followed by that many bytes:
7 8: parc.com 3: van 3: cal 32: 3FDC96

The only assumption CCN makes about names is hierarchical structure.

E.g., names or components can be encrypted or contain arbitrary binary data.
 Using Names
The hierarchical structure is used to do
longest match lookups (similar to IP prefix
lookups) which helps guarantee log(n) state
scaling for globally accessible data.
Although CCN names are longer than IP
identifiers, their explicit structure allows
lookups as efficient as IPs.

(see hashing work by Rasmus Pagh and Martin Dietzfelbinger)

 Names and meaning
Like IP, a CCN node imposes no semantics on names.
Meaning comes from application, institution and global
conventions reflected in prefix forwarding rules.
For example,
/parc.com/people/van/presentations/FISS09
might be the name of a presentations data and
/thisRoom/projector
the name of the projector it should display on.
The former is a globally meaningful name leveraging
the DNS global naming structure. The latter is local and
context sensitiveit refers to different objects
depending on the room youre in.
IP node model
CCN node model

Get /parc.com/videos/
WidgetA.mpg/v3/s2
Comparison
 Strategy layer
(mobility management)
When you dont care who youre talking to,
you dont care if they change.
When youre not having a conversation,
theres no conversation state to migrate.
Multi-point gives you multi-interface for free.
When all communication is locally flow
balanced, your stack knows exactly whats
working and how well.
 Quality of Service (QoS)
In the current Internet, QoS problems are highly
localized.
Roughly half the problems arise from the serial
dependencies created by queues.
The other half are caused the lack of receiver
based control of bottleneck links.
Unlike IP, CCN is local, doesnt have queues and
receivers have complete, fine-grained control.
But it does aggregate traffic and has face-specific
controls on the aggregation.
 Talk Plan
A Brief History of Networking (+Motivation)
Node Model
Routing
Transport
 There are many (emerging) ways to do routing,
e.g., Small Worlds, Geographic Hyperbolic,
Pseudo potential Gradient, Epidemic percolation.
In general theyre easier to implement and work
better for CCN than for IP:
no looping data no convergence issues.
multi-destination state can be approximate (false
positives ok).
CCN transport model matches routings and adds
security.
 Im only going to talk about embedding CCN in
existing Internet routing.
This is an easy evolutionary path (it allows for
immediate, incremental deployment).
It offers some intuition on scaling (same scaling as
IP routing).
The basics are the same for any routing scheme.
 Existing link-state routing
protocols can be used, unmodified,
to construct a CCN FIB
data src advertisement:
data src advertisement:
/parc.com/media/art
/parc.com/media/art
/parc.com/media
B
A

D
F

E Es FIB
/parc.com/media/art A, B
CCN Router /parc.com/media B
Example: Content Distribution
Example: Content Distribution
Example: Content Distribution
Example: Content Distribution
 Content goes only where theres
interest.

It takes at most one trip across any link.

Average latency is minimized.

Total bandwidth is minimized.

Theres no routing or control traffic

associated with the replicas.
 Talk Plan
A Brief History of Networking (+Motivation)
Node Model
Routing
Transport
Transport State

Conversation transport
state is very compact:
One dynamic state variable
(tcp sequence / ack number)
conveys what ends know.
Additional static variable (tcp
window) conveys what they
want.
Annotated path in CCN name
tree serves as transport state

Conventions:
name tree child nodes are lexically ordered
<next> assumed if no relationship specified
Annotated path in CCN name
tree serves as transport state
Most recent version of slides for this talk:
parc.com/van/talks/mit10-08 <rightmost child>

Conventions:
name tree child nodes are lexically ordered
<next> assumed if no relationship specified
Annotated path in CCN name
tree serves as transport state
Most recent version of slides for this talk:
parc.com/van/talks/mit10-08 <rightmost child>

Newest version after v2:

parc.com/van/talks/mit10-08/v2 <rightmost
sibling> (fails since there is no newer version)

Conventions:
name tree child nodes are lexically ordered
<next> assumed if no relationship specified
Annotated path in CCN name
tree serves as transport state
Most recent version of slides for this talk:
parc.com/van/talks/mit10-08 <rightmost child>

Newest version after v2:

parc.com/van/talks/mit10-08/v2 <rightmost
sibling> (fails since there is no newer version)

Next available chunk after s1:

parc.com/van/talks/mit10-08/v2/s1

Conventions:
name tree child nodes are lexically ordered
<next> assumed if no relationship specified
 Bulk-data transfer
performance comparison

TCP
Throughput (Mbps)

CCN

Pipeline size (like TCP window size)

 Shared-content
performance comparison

TCP
Download delay

CCN

# of clients
 Wrapup
CCN node is as simple as an IP node:
same memory requirements
same computational requirements (with option to
increase security)
CCN offers simple, robust, secure single-point
configuration.
CCN does near optimal content distribution.
Network, applications and users all share the
same model of communication.