introduction to content centric networking - bnrg

Introduction to Content Centric

NetworkingVan [email protected]

FISS 09Bremen, Germany

22 June 2009

2

This talk describes ongoing PARC work on

CCN (Content-centric Networking) by:

• Jim Thornton

• Diana Smetters

• Nick Briggs

• Michael Plass

• Rebecca Braynard

• Elaine Shi

• Simon Barber

• Ignacio Solis

• Mark Mosko

• JJ Garcia-Luna

• and me

CCN goals

• Matches today’s communication problems

• Matches today’s application design patterns

• Is at least as scalable & efficient as TCP/IP

• Is much more secure

• Requires far less configuration

3

Create a simple, universal, flexible communication architecture that:

Universal?

• Any architecture designed to run over anything is necessarily an overlay.

• What matters are capabilities: IP started as an overlay on the phone system; today the phone system is an overlay on IP ... IP has a universality independent of any layer-2.

• CCN has the same character: it can run over anything, including IP, and anything can run over CCN, including IP.

4

Talk Plan

• History and motivation

• Content Model

• Security Model

• Node Model

• Routing

• Transport

5

Networking was inventedin this world

6

Networking was inventedin this world

6

It was about sharing resources, not data.

• The central abstraction is a host identifier.

• The fundamental communication model is a point-to-point conversation between two hosts.

7

Networking created today’s world of content but was

never designed for it

8

• Networking hates wireless, mobility and intermittent connectivity.

• Cognitive mismatch - user/app model is ‘what’, network wants ‘who’. Mapping between models requires a lot of convention and configuration (middleware & wetware).

• No useful security - content is opaque to the net and it can’t secure something it knows nothing about.

Unfortunate consequences

• There is a lot of content: As of Dec 2008 the Internet was moving 8 Exabytes/month.

• IDC reports that 180 Exabytes of new content was created in 2006.

• More than a Zettabyte is expected in 2010 (60% annual growth).

9

Data Communications today is about moving content

John Gantz, IDC (March, 2008). "An Updated Forecast of Worldwide Information Growth Through 2011".

Andrew Odlyzko, UMN, Minnesota Internet Traffic Studies (MINTS)

http://www.emc.com/digital_universe/

http://www.emc.com/digital_universe/

http://www.dtc.umn.edu/mints/home.php

http://www.dtc.umn.edu/mints/home.php

Networking & storage cost evolution

10

1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 20000.01

0.1

1

10

1

10

US

OC

-3 $

per

Mbp

s pe

r M

ile

IBM

dis

k $

per

MB

at i

ntro

duct

ion

Disc

long-haul OC-3

Year

Disk: D. Thompson, IBM JR&D, May 2000 Telco: Douglas Galbi, Chief Economist, US FCC, July 2000

Networking & storage cost evolution

10

1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 20000.01

0.1

1

10

1

10

US

OC

-3 $

per

Mbp

s pe

r M

ile

IBM

dis

k $

per

MB

at i

ntro

duct

ion

Disc

long-haul OC-3

Year

Disk: D. Thompson, IBM JR&D, May 2000 Telco: Douglas Galbi, Chief Economist, US FCC, July 2000

Disk cost/byte has fallen 3%/week for the last 25 years!

and storage is going to get a lot cheaper ...

11

Max Planck Institute, June 2008

200 Gb/in2 PZT nano-capacitor non-volatile memory

10 Tb/in2 co-polymer magnetic memory

LBL, Feb. 2009

Tb/in2 carbon nanotube magnetic memory

LBL, May 2009

4 Tb/in2 MEMSmemory array

Univ. Twente, July 2009

Can we create a network architecture based on named data instead of named hosts?

Cost evolution favors trading storage for bandwidth but ...

Storage names say what we want,Network names say who we want.

Mapping between these two models requires a lot of plumbing (middleware & wetware).

12

13

Making content move itself

13

van’s calendar?

pointless mtg 08:30

• Devices express ‘interest’ in data collections.

• Devices with data in collection respond.

Making content move itself

14

• Users specify the objective, not how to accomplish it.

• Data appears wherever it needs to be.

• Model loves wireless and broadcast(802.11, RFID, Bluetooth, NFC, ...).

• There’s no distinction between bits in a memory and bits in a wire.

• Data security and integrity are the architectural foundation, not an add-on.


• Content Model

• Security Model

• Node Model

• Routing

• Transport

15

Self-managing information needs context

• Ontology (the relationship of this to other information)

• Provenance (some basis for trust in the information)

• Locality (proximity awareness and management)

16

van’s calendar?

pointless mtg 08:30

van’s calendar?pointless mtg 08:30

Friction

Moving up-level is an amplifier.

‣ We shouldn’t amplify mistakes.(E.g., if you accidentally delete a file anywhere, FolderShare makes sure it’s deleted everywhere.)

‣ We shouldn’t amplify attacks.(Machines need a very high level of confidence in context & data integrity).

17

van’s calendar?

pointless mtg 08:30

van’s calendar?pointless mtg 08:30

• CCN gets rid of a useless abstraction (the host and file that contain the bits) and captures:

- Ontology via hierarchical names and links.

- Provenance via signing the binding between the bits and their name (“Z asserts that X is his name for Y”)

- Locality via a “guided diffusion” dissemination model.

• CCN reduces friction by moving from a ‘container’ to a ‘collection’ model.

18

Why is networking & data security so bad?

• Files and network connections are containers for information.

• Containers are inherently insecure (contents can be replaced).

• Containers are not intrinsic (think SVN or git versioning).

• It is very hard to secure a container. It’s relatively easy to secure content.

19

CCN gets rid of containers

• CCN Names identify an information

collection (not an information container).

• Name hierarchy indicates membership.

• The same information can have many names (web-like links).

20

21

What’s in a Name(user/app view)

/parc.com/van/cal/417.vcf/v3/s0/0x3fdc96a4...

⎧｜⎨｜⎩

App supplied name ⎧｜⎨｜⎩Content or proxy

(e.g., SHA256 checksum)⎧⎨⎩Versioning &

segmentation

Note that this binding is immutable (the data associated with the name can’t

change). This changes the coherency problem to a communication problem:

A remote change makes your knowledge incomplete but cannot make it wrong.

⎧ ｜ ⎨ ｜ ⎩Signed by parc.com/van

22

Establishing Provenance


⎧｜⎨｜⎩Signed by parc.com

0x1b048347

Metadata contains encrypted cryptographic checksum and locator for the public key of the producer. Producer’s key is typically hierarchically structured.

signed checksum

key

parc.com/van/cal/desktop public key


• Content Model

• Security Model

• Node Model

• Routing

• Transport

23

24

• Content is opaque to TCP/IP so security is a one-size-fits-all wrapper with no notion of context and very weak notions of provenance.

• All trust is delegated to highly-suspect ‘root’ certification authorities (263 in M$ IE).

• Because it can’t name content, fine-grain keying is almost impossible.

• Security policies are expressed in terms of ‘what can be shared’, network enforcement is in terms of ‘who can talk to who’. It’s hard to make these congruent.

CCN signing

25

• Packets in CCN are authenticated and publicly verifiable (as opposed HMACed and verifiable only by the endpoints).

- This doesn’t mean computing a digital signature on every packet. For example, Merkle hash trees or ticket-signing mechanisms can be used to amortize signing cost.

• Public verifiability enables scalable, cooperative consistency checking even with massive replication.

Trust model

26

• We are doing straight-up SDSI for the trust model with a lot of control over local namespace linkage.

• It is intuitive and fully distributed yet very strong (fully axiomatized and verified).

R. Rivest, A Simple Distributed Security Architecture (SDSI), 1996

J. Halpern, A logic for SDSI's linked local named spaces, 1999

http://theory.ocs.mit.edu/~cis/sdsi.html

http://theory.ocs.mit.edu/~cis/sdsi.html

http://www.cs.cornell.edu/home/halpern/abstract.html%23conf110

http://www.cs.cornell.edu/home/halpern/abstract.html%23conf110

Key distribution

27

• CCN is an ideal communication model for fine-grained trust and privacy: signing and encryption key names can be derived from content names then retrieved via CCN.

• Everyone doesn’t have to establish trust in the same key the same way.

• CCN doesn’t care how you encrypt your data or encode your decryption keys; we just offer some suggestions to help.

‘Identity creates organism’

• The only configuration a CCN node needs is its ‘identity’ (signing key).

• Signing creates a robust “sense of self” that:

- Tells an element what configuration and coordination information it can trust.

- Tells it who to cooperate with.

- Lets elements recognize and help repel invaders. E.g., “defending” a name space.

28

– John Maynard Smith, 1920-2004


• Content Model

• Security Model

• Node Model

• Routing

• Transport

29

30

CCN packets

There are just two CCN packet types -

interest (similar to http “get”) and data (similar to http response). Both are encoded in an efficient binary XML.

Selector(order preference, publisher !lter, scope, ...)

Nonce

Content NameContent Name

Data

Data packetInterest packet

Signature(digest algorithm, witness, ...)

Signed Info(publisher ID, key locator, stale time, ...)

“data”“interest”

31

Internally, CCN names are opaque, structured byte strings


The only assumption CCN makes about names is hierarchical structure.

E.g., names or components can be encrypted or contain arbitrary binary data.

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 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 IP’s.

32

(see hashing work by Rasmus Pagh and Martin Dietzfelbinger)

Using Names

http://www.itu.dk/~pagh/

http://www.itu.dk/~pagh/

http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/d/Dietzfelbinger:Martin.html

http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/d/Dietzfelbinger:Martin.html

• 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/FISS09might be the name of a presentation’s data and /thisRoom/projectorthe 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 sensitive—it refers to different objects depending on the room you’re in.

33

Names and meaning

• Consumer ‘broadcasts’ an ‘interest’ over any & all available communications media: Want ‘/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>

34

Basic CCN forwarding

This isn’t google - it’s how IP works at the packet level

• Node announces (via ‘promiscuous ARP’) interest in packets sent to its IP address: arp 1.2.3.4 is-at 02:07:01:00:01:c4

• Interest is propagated via IP routing (with host-level granularity aggregated to subnet then net-level as interest gets farther away).

• Packets bound for node follow trail of interests (routes) back to it.

35

36

IP route propagation and aggregation

1.2.3.4

1.2.3

1.2

1.2

1.2

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 expessed (similar to TCP window).

37

TCP works this way at the packet level

• a TCP Ack expresses interest in new data on a connection.

• Sending new data consumes the Ack and another must generated to get more data.

• Multiple Acks (and associated data packets) may be in transit simultaneously.

• System always operates in bounded flow balance regime which is robust and stable under arbitrary aggregate demand. (see “Reversibility and Stochastic Networks”, Frank Kelly, 1979)

38

39

IP node model

Interface 0

Interface 1

Interface 2

Transport

Y

N

Pre!x

10.* 2

FIBInterface

FIBlookup

Dst isme?

Check &decr. TTL

CCN node model

40

Face 0

Face 1

Face 2

Pre!x

/parc.com 0, 1

FIBFace list

Application

DataNameContent Store

Pre!x

Pending Interest Table (PIT)Requesting

Face(s)

Indexptr type

P

C = Content storeP = PITF = FIB

C

F

/parc.com/videos/WidgetA.mpg/v3/s1


0

. . .

CCN node model

40

Face 0

Face 1

Face 2

Pre!x

/parc.com 0, 1

FIBFace list

Application


Pre!x


Face(s)

Indexptr type

P


C

F



0

. . .get /parc.com/videos/WidgetA.mpg/v3/s2

CCN node model

41

Face 0

Face 1

Face 2

Pre!x

/parc.com 0, 1

FIBFace list

Application


Pre!x


Face(s)

Indexptr type

P


C

F



0

. . .

CCN node model

41

Face 0

Face 1

Face 2

Pre!x

/parc.com 0, 1

FIBFace list

Application


Pre!x


Face(s)

Indexptr type

P


C

F



0

. . .

data: /parc.com/videos/WidgetA.mpg/v3/s1 ...

Interface 0

Interface 1

Interface 2

Transport

Y

N

Pre!x

10.* 2

FIBInterface

FIBlookup

Dst isme?

Check &decr. TTL

42

Comparison

Face 0

Face 1

Face 2

Pre!x

/parc.com 0, 1

FIBFace list

Application


Pre!x


Face(s)

Indexptr type

P


C

F



0

. . .

Interface 0

Interface 1

Interface 2

Transport

Y

N

Pre!x

10.* 2

FIBInterface

FIBlookup

Dst isme?

Check &decr. TTL

42

Comparison

Content Store is same as buffer memory -

same contents, different replacement policy.

Face 0

Face 1

Face 2

Pre!x

/parc.com 0, 1

FIBFace list

Application


Pre!x


Face(s)

Indexptr type

P


C

F



0

. . .

Interface 0

Interface 1

Interface 2

Transport

Y

N

Pre!x

10.* 2

FIBInterface

FIBlookup

Dst isme?

Check &decr. TTL

43

Comparison

Face 0

Face 1

Face 2

Pre!x

/parc.com 0, 1

FIBFace list

Application


Pre!x


Face(s)

Indexptr type

P


C

F



0

. . .

Interface 0

Interface 1

Interface 2

Transport

Y

N

Pre!x

10.* 2

FIBInterface

FIBlookup

Dst isme?

Check &decr. TTL

43

Comparison

Face 0

Face 1

Face 2

Pre!x

/parc.com 0, 1

FIBFace list

Application


Pre!x


Face(s)

Indexptr type

P


C

F



0

. . .

FIBs are almost identical except CCN has list of

output faces.

Interface 0

Interface 1

Interface 2

Transport

Y

N

Pre!x

10.* 2

FIBInterface

FIBlookup

Dst isme?

Check &decr. TTL

44

Comparison

Face 0

Face 1

Face 2

Pre!x

/parc.com 0, 1

FIBFace list

Application


Pre!x


Face(s)

Indexptr type

P


C

F



0

. . .

Interface 0

Interface 1

Interface 2

Transport

Y

N

Pre!x

10.* 2

FIBInterface

FIBlookup

Dst isme?

Check &decr. TTL

44

Comparison

Face 0

Face 1

Face 2

Pre!x

/parc.com 0, 1

FIBFace list

Application


Pre!x


Face(s)

Indexptr type

P


C

F



0

. . .

Half the transport state becomes the (multi-point)

Pending Interest table

Interface 0

Interface 1

Interface 2

Transport

Y

N

Pre!x

10.* 2

FIBInterface

FIBlookup

Dst isme?

Check &decr. TTL

45

Comparison

Face 0

Face 1

Face 2

Pre!x

/parc.com 0, 1

FIBFace list

Application


Pre!x


Face(s)

Indexptr type

P


C

F



0

. . .

Interface 0

Interface 1

Interface 2

Transport

Y

N

Pre!x

10.* 2

FIBInterface

FIBlookup

Dst isme?

Check &decr. TTL

45

Comparison

There’s no “me” test since CCN demuxing & forwarding are the same

Face 0

Face 1

Face 2

Pre!x

/parc.com 0, 1

FIBFace list

Application


Pre!x


Face(s)

Indexptr type

P


C

F



0

. . .

Interface 0

Interface 1

Interface 2

Transport

Y

N

Pre!x

10.* 2

FIBInterface

FIBlookup

Dst isme?

Check &decr. TTL

46

Comparison

Face 0

Face 1

Face 2

Pre!x

/parc.com 0, 1

FIBFace list

Application


Pre!x


Face(s)

Indexptr type

P


C

F



0

. . .

Interface 0

Interface 1

Interface 2

Transport

Y

N

Pre!x

10.* 2

FIBInterface

FIBlookup

Dst isme?

Check &decr. TTL

46

Comparison

There’s no TTL decrement since nothing can loop.

(CCN packets are never modified in transit.)

Face 0

Face 1

Face 2

Pre!x

/parc.com 0, 1

FIBFace list

Application


Pre!x


Face(s)

Indexptr type

P


C

F



0

. . .

Faces vs. Interfaces

47

• No Queues (data comes from Content Store)

• No ARP or ES-IS (no layer-3 abstraction to bind to layer-2 address)

• Have to do Suppression (see SRM or NORM) on multi-user broadcast links but can amortise to low cost by content-based prioritisation plus adaptive affinity.

QoS• In the current Internet, problems that

require QoS are highly localized.

• Roughly half the problem is caused by the serial dependencies created by queues.

• The other half is caused the lack of receiver based control of bottleneck links.

• Unlike IP, CCN is local, doesn’t have queues and receivers have complete, fine-grained control.

• But it does aggregate traffic and has face-specific controls on the aggregation.

48


• Content Model

• Security Model

• Node Model

• Routing

• Transport

49

50

• There are many (emerging) ways to do routing, e.g., Small Worlds, Geographic Hyperbolic, Pseudo-potential Gradient, Epidemic percolation.

• In general they’re 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 routing’s and adds security.

• I’m just 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 intuitions on scaling (same scaling as IP routing).

- The basics are the same for any routing scheme.

51

IGP routing

52

A

B

DC

EF

hello fr

om B

B sends a ‘hello’ out all its links

IGP routing

53

A

B

DC

EF

C adj B

C floods that it’s adjacent to B

IGP routing

54

A

B

DC

EF

Same thing happens in C→B direction. When ‘B adj C’ announcement flooded, everyone adds B-C link to map.

IGP routing

55

A

B

DC

EF

192.168/16

Some ‘external’ (non-IGP) agent injects a ‘prefix announcement’which B floods to all other IGP nodes

B: 192.168/16

Existing link-state routing protocols can be used, unmodified,

to construct a CCN FIB

56

A

B

/abc.com/media

DC

EF

/abc.com/media/art /abc.com/media/art

B

A,B/abc.com/media/abc.com/media/art

57

Architectural issues with IP routing

1.2.3.4

1.2.3

1.2

1.2

1.2

58


1.2.3.4

1.2.3

1.2

1.2

1.2

58


1.2.3.4

1.2.3

1.2

1.2

1.2

• It can take a long time to establish a forwarding topology.

• Single path to destination imposes global constraints on local forwarding decision.

CCN doesn’t need topology

• Content model suppresses duplicates so nothing can loop.

• Data bandwidth use is near theoretical min.

• Topology can reduce interest bandwidth use but factor is small - O(diameter*avg.degree).

• With no topology, interests will always find (dynamic) shortest path to source.

• CCN works well with sloppy topology and performance-based interest re-expression.

59


• Content Model

• Security Model

• Node Model

• Routing

• Transport

60

Transport State

61

TCP Sequence Space (232)

Old New

A(highest acked)

w

• One dynamic state variable (tcp sequence / ack number) conveys what ends know.

• Additional static variable (tcp window) conveys what they want.

Conversation transport state is very compact:

Annotated path in CCN name tree serves as transport state

62

parc.com

van

talks

mit10-08

v1 v2

s0 s1 s2 • name tree child nodes are lexically ordered• <next> assumed if no relationship specified

Conventions:


62

parc.com

van

talks

mit10-08

v1 v2


parc.com/van/talks/mit10-08 <rightmost child>

Most recent version of slides for this talk:

Conventions:


62

parc.com

van

talks

mit10-08

v1 v2




parc.com/van/talks/mit10-08/v2 <rightmost sibling>

(fails since there is no newer version)

Newest version after v2:

Conventions:


62

parc.com

van

talks

mit10-08

v1 v2




parc.com/van/talks/mit10-08/v2 <rightmost sibling>

(fails since there is no newer version)

Newest version after v2:

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

Next available chunk after s1:

Conventions:

63

A

B C

D E F G

H I J K

nytimes

client1 client2 client3

64

A

B C

D E F G

H I J K

nytimes


65

A

B C

D E F G

H I J K

nytimes


66

A

B C

D E F G

H I J K

nytimes


67

A

B C

D E F G

H I J K

nytimes


• Content goes only where there’s interest.

• It takes at most one trip across any link.

• Average latency is minimized.

• Total bandwidth is minimized.

• There’s no routing or control traffic associated with the replicas.

Bulk-data transfer performance comparison

68

0

20

40

60

80

100

0 10 20 30 40 50

Mbps

Pipeline Size

Throughput

link BWTCPCCN

Bulk-data transfer performance comparison

68

0

20

40

60

80

100

0 10 20 30 40 50

Mbps

Pipeline Size

Throughput

link BWTCPCCN

11%

23%

Shared-content performance comparison

69

5

10

15

20

25

30

1 2 3 4

Tim

e (s

ec)

Number of Clients

Total Download Time

CCNTCP

Random transport notes

70

• Unsatisfied interests are timed out. Consumer is responsible for re-expressing interest if they still care (fate-sharing soft-state model).

• Adaptive supression (as in SRM or NORM) avoids response implosions on broadcast faces.

• Basic CCN behaves as an efficient, secure, serverless, scalable distributed pub-sub plus intentional names.

Strategy layer(mobility management)• If you don’t care who you’re talking to, you

don’t care if they change.

• If you can only ask for a few small pieces at a time, it doesn’t matter much if one gets dropped.

• If you can use any and all your links simultaneously, it’s easy for the stack to run experiments.

• If all communication is flow balanced, you know exactly what’s working and how well.

71

Performance-based interest re-expression

72

BobIPC

AliceIPC

73

email WWW phone...

SMTP HTTP RTP...

TCP UDP…

IP

ethernet PPP…

CSMA async sonet...

copper fiber radio...

A New Layering

browser, chat, ...

File, Stream, ...

Security

Con

tent

Chu

nks

Strategy

TCP, P2P, Brdcast ...

copper fiber radio...

introduction to content centric networking - bnrg

Documents