21
Forwarding in Content-Oriented Networks: Challenges and Probabilistic approaches Christian Esteve Rothenberg University of Campinas (Unicamp) 05.12.10 - 08.12.10, Seminar 10492 Information-Centric Networking

Forwarding in Content-Oriented Networks: Challenges and Probabilistic approaches Christian Esteve Rothenberg University of Campinas (Unicamp) 05.12.10

Embed Size (px)

Citation preview

Forwarding in Content-Oriented Networks:Challenges and Probabilistic approaches

Christian Esteve RothenbergUniversity of Campinas (Unicamp)

05.12.10 - 08.12.10, Seminar 10492Information-Centric Networking

Intro

Back in early 2008:

At University of Campinas,

how to fast forward packets in content-oriented networks?

This Talk

How to fast forward packets in content-oriented networks?

• Goals of this discussion starter talk– Requirements and Challenges of forwarding

(i.e., forward this packet to interface x?) on content identifiers (flat vs. structured)

– Compact (probabilistic) approaches to forwarding:(approximate) network state vs. packet state

• Non-goals– Routing (protocols, security, multipath), fwding strategies– Caching (only partly covered)– Technology details (e.g., fast memory specs)

Content-Oriented Forwarding Requirements

Same as high speed packet switching...

High speed (i.e. Low lookup time) 100Byte packets @ 10 Gbps -> 12.5 Mpps

Low storage

Amenable to hardware (e.g pipelined, memory BW, max pin number)

Low pre-processing time & Low update time

Content-Oriented Forwarding Challenges

Higher than traditional packet switching...

High speed (i.e. Low lookup time) 100Byte packets @ 10 Gbps -> 12.5 Mpps

Low storage

Amenable to hardware (e.g pipelined, memory BW, max pin number)

Low pre-processing time & Low update time

32 (or 128) bit IP vs. Content IDs

+ Line-speed cache support (pull/push)

+ (optional) signature verification

IP LPM vs. Content ID matching

IPv4 Dec. 81.216.171.106Bin. 01010001 11011000 10101011 01101010

IPv6 Hex. ca12:b9fa:655a:0000:0000:ac2f:ccef:f0abBin. 11001010 00010010 10111001 11111010 11001010 01011010 00000000 00000000

10101100 00000000 00000000 00101111 11001100 11101111 11110000 10101011

256-bitflat

label

Hex. 08090A0B0D0E0F10121314151718191A1C1D1E1F21222324262728292B2C2D2E

Bin. 11111010 11001010 01011010 00000000 00000000 10101100 00000000 00000000 10101100 00000000 00000000 00101111 11001100 11101111 11110000 10101011 11001010 00010010 10111001 11111010 01011010 00000000 00000000 10101100 11101111 11110000 10101011 11001010 00010010 10111001 11111010 11001010

human

machine

Content ID forwarding is challenging @ wire speed

CCN-like

label

Hex. /a/b/c/d/ : hash

Bin.. Total-components: #Length(a):a:Length(…):…:Length(d):d: hash

Fast Forwarding on Content Identifiers

Flat identifiers(e.g., 256-bit hash)

• Easy encoding• Fixed length• Non-aggregatable• Easy “exact” match

lookup

Structured identifiers(e.g., a/b/c/d:hash)

• Binary encoding (?)• Unbound length with non-

fixed size components• Aggregatable• Costly “LPM” matching

onerous task Need of content-oriented equivalents for fast forwarding algorithms (e.g., patricia trie, Lulea, tree bitmaps, etc.)... think many year research on LPM for IP... current work on security, DPI, NIDS, etc.E.g., transform forwarding into a signature matching problem?

Content ID forwarding is challenging @ wire speed

Compact forwarding: A probabilistic approach

Express the packet forwarding problem as two set membership-problems solved with probabilistic data structures (Bloom-filter-inspired):

FF

Floc

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Cache BF

Ploc

PublicationData Cache

Lin Lout Pout

X Y 1

W WZ 7, 14

A * 3, 4

… … …

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

F

… SPSwitch: Is packet label X in forwarding port P? • Approximate state in the network• Large Bloom filters maintained in forwarding• [Re-Arch08] tables

zFilters: Is outbound link A in packet header Z? • State in the packet header• Small in-packet Bloom filter representing a source route•[SIGCOMM09, Infocom11]

4-dimensional solution space

Routing / forwarding information in packets

(packet header size)

Adaptation costs (e.g., signaling)

Transport efficiency (Stretch, Bandwidth)

packetrouting

State in network elements(FIB size)

Multicast-readycompact forwarding

Traditional unicast & compact routing

SPSwitch forwarding engine

FF

Floc

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Cache BF

Ploc

PublicationData Cache

Lin Lout Pout

X Y 1

W WZ 7, 14

A * 3, 4

… … …

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

F

…Pub/Sub Control Plane T

Assumption!

Rid DataSidFid

Flat IDs

Is packet label X in forwarding port P?

Bucket (b)

Count : 3

11000110110101110010101011110110100110111010000110100001101000011010101110100010101010110101010110101110101110100011 101

010101101011

011 … 1010001100011011010111001010101110110 10011011

Label (s) Port-Out (p)

d = 0 d = 1 d = 2

h

b

C

H0(s) H2(s)H1(s)

InsertDBRdlBF(s, p):

model

implementation(FCF d-left hash Table)

Problem: Still O(n) entries

[Re-Arch08]

[Re-Arch10]

Publish/Subscribe Architecture: 3 Layers

forwarding layer delivers data

topology layer selects routes

rendezvous layer establishes contact

iBFs: routable in-packet Bloom filters

State in the packet headers– Each network link has an identity and (a series of) Link IDs:

Bloomed LID: 256 bit vector with just k=5 bit positions set to one– Forwarding on small, fixed size in-packet Bloom filter representing a

source route – Formed by topology functions or collected on path (cf. IP switching)

Basic operation

“Is outbound link A in packet header Z?” – Small forwarding tables, very fast switching (bitwise AND operations)– Plus Extensions (Link ID Tags, virtual links, security, etc.)

LID1 LID2

iBF = LID1 OR LID2

Practical results

Stateless multicast with 256-bit zFilters (35 links -> approx. 20 subscribers)

Enough for sparse multicast in typical WAN

Zipf distribution of multicast traffic

# Users

# Groups

statelessstateful

iBF forwarding 2.0

From basic [LIPSIN] to iBF on steroids:• Secure self-routing capabilities [EC2ND]

– Address iBF replay attacks and empower the receiver.– Dynamic (keyed) computation of

LinkIDs based on:In/Out interfaces, packet content, node secret K(t)

– iBFs become expirable andcontent-dependent

• Deletable [DlBF]– Compact bitmap header with collision-free regions

• Loop-free – Per-hop permutations [Infocom11]

LIT (d, Pout)

Z

diBF

d

In Port # Out Port #

Flow ID secret K(t)

& = Yes/NoForward(Pout)?

256-bit256-bit (only k 1’s)

…for each OutPort:

CCN forwarding

CCN with iBFs

Attempt to solve the PIT state issue• INTEREST packets are forwarded based on FIB

collect iBF back to the requester(s)

Link ID = Z (face in, face out, content ID, Ki(t) )

LID1

Cache

FIB

Interest 0000000

LID2LID3

iBF

Interest 0100110iBF

CCN with iBFs

Attempt to solve the PIT state issue• INTEREST packets are forwarded based on FIB

collect iBF back to the requester(s)• DATA packets are forwarded back to requester(s)

based on the iBFPreserves flow symmetry, adds security, at the expense of BW efficiency

Link ID = Z (face in, face out, content ID, Ki(t) )

LID1

Cache

LID2LID3

DATA 0100110iBF

Z-forw

Compact forwarding in content-oriented networks

Traditional Forwarding• Scale by

– Structural aggregation(hierarchical IP)

– Timely information (Ethernet)

• Deterministic algorithms– Forward on longest prefixes

(Tree bitmap IP lookup)– Exact lookup matches

(MPLS, Ethernet)• Focus on unicast• Sender-oriented

Compact Forwarding• Scale by

– Synthetic aggregation (lossy compression)

– Moving (approximate) forwarding state to packets

– Trading state for over deliveries (flexible operation point)

• Probabilistic algorithms– Trade correctness for

space/memory time requirements– Prone to one-sided errors (port-

forwarding w/ extra packet dupls)• Focus on multicast• Receiver -oriented

Conclusions

• Forwarding on content identifiers is challenging• As in the past and in related engineering problems,

probabilistic techniques represent an aid to the feasibility of routing on content labels via new space/time trade-offs

• Still unresolved issue: Right balance between edge-, network- and packet state?

FF

Floc

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Cache BF

Ploc

PublicationData Cache

Lin Lout Pout

X Y 1

W WZ 7, 14

A * 3, 4

… … …

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

BF

F

SPSwitch: Port-based Bloomed forwarding decisions Secure source-routing with Bloomed link IDs

Routing / forwarding information in packets

Signaling overheadTransport efficiency (Bandwidth)

multicastrouting

Routing/forwarding state in network elements

Multicast routing & forwarding solution space

LIT PortOut

0010101 1

1000101 7

1000001 3

m bits 1 Byte

K*8bits 1 Byte

LIT PortOut

0010101 1

1000101 7

1000001 3

m bits 1 Byte

K*8bits 1 Byte

LIT PortOut

0010101 1

1000101 7

1000001 3

m bits 1 Byte

K*8bits 1 Byte

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Cache LinkID

Virtual links : : PortOut

PublicationData Cache

LIT PortOut

0010101 1

1000101 2

1000001 3

V001010 2

V100001 5

m bits 1 Byte

k*log(m) 1 Byte

LinkID i

LinkID f

LinkID g

LinkID h

LinkID i

LinkID j

LinkID k

LinkID l

LinkID a

LinkID b

LinkID c

LinkID d

LinkID e

LinkID f

LinkID g

LinkID h

iBF d LinkID in

d = 00d = 01d = 10d = 11

ReferencesC. Esteve Rothenberg, F. Verdi and M. Magalhães. “Towards a new generation of information-

oriented internetworking architectures.” In ACM CoNext, First Workshop on Re-Architecting the Internet (Re- Arch08), Dec. 2008, Madrid, Spain.

P. Jokela, A. Zahemszky, C. Esteve Rothenberg, S. Arianfar, and P. Nikander. “LIPSIN: Line Speed Publish/Subscribe Inter-Networkings.” In ACM SIGCOMM’09, Aug. 2009, Barcelona, Spain.

A. Zahemszky, A. Császár, P. Nikander and C. Esteve Rothenberg. “Exploring the Pub/Sub Routing & Forwarding Space.” In IEEE ICC, Workshop on the Network of The Future, Jun. 2009, Dresden, Germany.

C. Esteve Rothenberg, P. Jokela, P. Nikander, M. Särela and J. Ylitalo. “Self-routing Denial-of-Service Resistant Capabilities using In-packet Bloom Filters.” In 5th European Conference on Computer Network Defense (EC2ND), Nov. 2009, Milan, Italy.

C. Esteve Rothenberg, C. A. Macapuna, F. L. Verdi and M. F. Magalhães. “The Deletable Bloom Filter: A new member of the Bloom family.” In IEEE Communication Letters, June 2010.

C. Esteve Rothenberg, C. A. Macapuna, F. L. Verdi and M. F. Magalhães. “In-packet Bloom filters: Design and networking applications.” To appear in to Elsevier Computer Networks, March 2010.

ReferencesM. Särelä, C. Esteve Rothenberg, A. Zahemszky, P. Nikander and J. Ott. “BloomCasting: Security

in Bloom filter based multicast.” In proceedings of the 15th Nordic Conference in Secure IT Systems (Nordsec) 2010, Aalto University, Espoo, Finland, 27-30 October 2010.

M. Särelä, C. Esteve Rothenberg, T. Aura, A. Zahemszky, P. Nikander and J. Ott. “Forwarding Anomalies in Bloom Filter BasedMulticast,” Submitted to the 30th IEEE International Conference on Computer Communications (IEEE INFOCOM 2011), 2011

Somaya Arianfar, Pekka Nikander, and Joerg Ott, "On Content-Centric Router Design and Implications," in Workshop on Re-Architecting the Internet (ReArch 2010), an ACM CoNext workshop, Philadelphia, USA, November 30, 2010.

Walter Wong and Pekka Nikander, "Secure Naming in Information-Centric Networks," in Workshop on Re-Architecting the Internet (ReArch 2010), an ACM CoNext workshop, Philadelphia, USA, November 30, 2010.

S. Tarkoma, C. Esteve Rothenberg and E. Lagerspetz. “Theory and Practice of Probabilistic Filters for Distributed Systems.” To appear in IEEE Communications Surveys and Tutorials, Fev. 2010.