pub/sub networking

PUB/SUB networkinG – packet forwarding with iBFS 31.10.2011 t-110.5111 Petri Jokela Ericsson Research, NomadicLab Some slides by M. Särelä, W. Wong, J. Kjällman

!

Ericsson AB | 2011-10-03 |

Background

› EU FP7 – PSIRP (2008-2010) – PURSUIT (2010-2013)

› New architecture for Future Internet – Clean slate approach – Don’t assume anything from the existing network

› Content Centric Networking – Various projects around the world

Ericsson AB | 2011-10-03 |

Slide title

32 pt

Text

24 pt

Bullets level 2-5

20 pt › !"# $%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~¡¢£¤¥¦§¨©ª«¬®¯°±²³´¶·¸¹º»¼½ÀÁÂÃÄÅÆÇÈËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿĀāĂăąĆćĊċČĎďĐđĒĖėĘęĚěĞğĠġĢģĪīĮįİıĶķĹĺĻļĽľŁłŃńŅņŇňŌŐőŒœŔŕŖŗŘřŚśŞşŠšŢţŤťŪūŮůŰűŲųŴŵŶŷŸŹźŻż�Ž�žƒȘșˆˇ˘˙˚˛˜˝ẀẁẃẄẅỲỳ–—‘’‚“”„†‡•…‰‹›⁄€™−≤≥fifl

Do not add objects or text in

the footer area

© Ericsson AB 2009 | 4.10.2010

Background

› Think DATA as the first class citizen – Users interested in data, not in the hosts – Publisher’s identity important – Topic based publish/subscribe

Publisher Shop

Ericsson AB | 2011-10-03 |

Slide title

32 pt

Text

24 pt

Bullets level 2-5



the footer area

© Ericsson AB 2009 | 4.10.2010

Background

› Data published once, received multiple times – Asynchronous multicast, timely separated requests – Data delivery from caches instead of the actual source

› Caching becomes an essential function Publisher

Shop 09:30 12:14

17:30 04:15

Data

Printing

Ericsson AB | 2011-10-03 |

Slide title

32 pt

Text

24 pt

Bullets level 2-5



the footer area

© Ericsson AB 2009 | 4.10.2010

Background

› DDoS problem in current networks – Network serves the sender – Unwanted traffic against the receiver’s will – Target: Data delivery only when explicitly requested

Unwanted traffic

Ericsson AB | 2011-10-03 |

Slide title

48 pt

Slide subtitle

30 pt

ARCHITECTURE

Ericsson AB | 2011-10-03 |

Slide title

32 pt

Text

24 pt

Bullets level 2-5



the footer area

© Ericsson AB 2009 | 4.10.2010

Architectural components

› Rendezvous - matching publish and subscribe events

Rendezvous Rendezvous Rendezvous

Topology Topology Topology

Publisher fwd fwd fwd fwd fwd fwd Subscriber

Matching

Ericsson AB | 2011-10-03 |

Slide title

32 pt

Text

24 pt

Bullets level 2-5



the footer area

© Ericsson AB 2009 | 4.10.2010


› Rendezvous - matching publish and subscribe events › Topology - network topology knowledge, path creation




Matching

Path creation

Ericsson AB | 2011-10-03 |

Slide title

32 pt

Text

24 pt

Bullets level 2-5



the footer area

© Ericsson AB 2009 | 4.10.2010


› Rendezvous - matching publish and subscribe events › Topology - network topology knowledge, path creation › Forwarding - fast delivery




Matching

Path creation

Data delivery

FID

Ericsson AB | 2011-10-03 |

PURSUIT architecture

Ericsson AB | 2011-10-03 |

Slide title

48 pt

Slide subtitle

30 pt

IDENTIFIERS

Ericsson AB | 2011-10-03 |

Identifiers

› AId – Application level identifier › RId – Rendezvous identifier › SId – Scope Identifier › FId – Forwarding Identifier › AlgId – Algorithmic identifier

Ericsson AB | 2011-10-03 |

Identifiers – AId

› Application Level Identifier

› Depends on the applications – Can be human readable – Resolvable to other identifiers (SId, RId)

› Examples: – Flat labels – Structured names (FQDN) – Global Unique Identifier (GUID) – …

Ericsson AB | 2011-10-03 |

Identifiers – RId

› Rendezvous Identifier

› Uniquely identifies a piece of information – 256-bit identifier – SHA-256 hash over the data – E.g. a single memory page, one part of a file

› RId used for matching publications to subscriptions in RVS

Ericsson AB | 2011-10-03 |

Identifiers – SId

› Scope Identifier

› SId defines a collection of publications – A set of RIds can be collected under a single SId

› Example – A family photo album has a SId – Each photo (or part of the photo) has a RId

Ericsson AB | 2011-10-03 |

Scoping

Ericsson AB | 2011-10-03 |

Identifiers – FId

› Forwarding Identifier

› 256-bit long network identifier

› Used in the forwarding fabric –  Identifies a path, or a partial path, through the network – Forwarding nodes make forwarding decision based on FId – Fast path (SId/RId in slow path)

› Balancing between state in the packet and state in the network

Ericsson AB | 2011-10-03 |

Identifiers – AlgId

› Algorithmic Identifier › Automatic generation of IDs

› E.g. sequence numbering

Rendezvous

Publisher Subscriber

Publish (AlgID)

ID1 = hash (AlgId) ID2 = hash (ID1) ID3 = hash (ID2)

Subscribe (AlgID)

Ericsson AB | 2011-10-03 |

Slide title

48 pt

Slide subtitle

30 pt

PUBLICATION FORWARDING

Ericsson AB | 2011-10-03 |

Slide title

32 pt

Text

24 pt

Bullets level 2-5



the footer area

© Ericsson AB 2009 | 4.10.2010

Publication delivery

› Topic delivery with IP addresses – Problem with the delivery model; sender is always in control – Firewalls (and other middle-boxes) needed for blocking unwanted

traffic

“To Wall Street”

Ericsson AB | 2011-10-03 |

Slide title

32 pt

Text

24 pt

Bullets level 2-5



the footer area

© Ericsson AB 2009 | 4.10.2010


› Topic delivery with IP addresses – DDoS still possible

“To Wall Street”

Ericsson AB | 2011-10-03 |

Slide title

32 pt

Text

24 pt

Bullets level 2-5



the footer area

© Ericsson AB 2009 | 4.10.2010


›  Instead of naming end-hosts, we can name the data – But how to deliver the data?

› For each topic, we have to – Locate the actual pieces – Create a way to deliver the data – Physically forward the required pieces to the subscriber

“D”

??

“I want A”

A1

A2

A3

“A”

Ericsson AB | 2011-10-03 |

Slide title

32 pt

Text

24 pt

Bullets level 2-5



the footer area

© Ericsson AB 2009 | 4.10.2010


› Routing based on Topic ID: State in the routers – 10^11 topics => enormous amount of state in forwarders – State need to be changed based on subscriptions – => Not scalable

Topic A => 1 Topic B => 3,4 Topic C => 1,2 Topic D => 2 Topic E => 4.. .. ..

A

X

New forwarding info (AGAIN): E => 3 D => 1,2 C => REMOVE

Post office!

Ericsson AB | 2011-10-03 |

Slide title

32 pt

Text

24 pt

Bullets level 2-5



the footer area

© Ericsson AB 2009 | 4.10.2010


› How about storing the state in the packet? – Define the path from the source to the destination

›  IP: include all visited IP addresses in a list - A long list of IP addresses, and we do not solve the DDoS

› Without IP: Include all visited nodes in the packet - Long list of Node IDs!

A: {HOP1; HOP2;

HOP3; HOP4;

HOP5; ... HOP 40}

Ericsson AB | 2011-10-03 |

› Requirements – Multicast, security (Ddos protection), efficiency, no global

addressing assumed

› A new solution needed for packet forwarding – Early suggestions: “MPLS” style label swapping? – Do we have something else?

› An old idea from 2006 – BISTRO

Forwarding ideas

Ericsson AB | 2011-10-03 |

Forwarding ideas

› BISTRO -> zFilters -> iBF forwarding – Became one potential packet forwarding mechanism for PSIRP – Supports multicast natively – No global addressing needed – Does not reveal the path – Petri Jokela, András Zahemszky, Christian Esteve,

Somaya Arianfar, and Pekka Nikander, “LIPSIN: Line speed Publish/Subscribe Inter-Networking”, ACM SIGCOMM 2009

Ericsson AB | 2011-10-03 |

Slide title

48 pt

Slide subtitle

30 pt

BLOOM FILTERS (BURTON HOWARD BLOOM, 1970)

Ericsson AB | 2011-10-03 |

Bloom filters

› Probabilistic data structure, space efficient › Used to test if an element has been added to a set

0 0 0 0 0 0 0 0 0 0

10-bit Bloom Filter

Hash 1 Hash 2

Ericsson AB | 2011-10-03 |

Bloom filters: Inserting items

› Hash the data k times, get index values, and set the bits

Data 1

Hash 1 Hash 2

Hash 1(Data1) = 9 Hash 2(Data1) = 3

10-bit Bloom Filter

0 0 1 0 0 0 0 0 1 0

Ericsson AB | 2011-10-03 |

Bloom filters: Inserting items

› Hash the data k times, get index values, and set the bits

Data 1

Data 2


10-bit Bloom Filter

0 0 1 0 0 0 1 0 1 0

Hash 1 Hash 2

Ericsson AB | 2011-10-03 |

Bloom filters: Verifying (positive)

› All corresponding bits have been set → positive response

Data 1

Verifying: Hash and check if set Hash 1(Data1) = 9 Hash 2(Data1) = 3

10-bit Bloom Filter

0 0 1 0 0 0 1 0 1 0

Hash 1 Hash 2

Ericsson AB | 2011-10-03 | © Ericsson AB 2009 | 4.10.2010

Bloom filters: Verifying (negative)

› Some bits do not match → negative response

Data 3


10-bit Bloom Filter

0 0 1 0 0 0 1 0 1 0

Hash 1 Hash 2

Verifying: Hash and check if set

Ericsson AB | 2011-10-03 |

Bloom filters: False positives

› Bits match the BF although “Data 4” was never added

Data 4


10-bit Bloom Filter

0 0 1 0 0 0 1 0 1 0

Hash 1 Hash 2

Verifying: Hash and check if set

Ericsson AB | 2011-10-03 |

Slide title

48 pt

Slide subtitle

30 pt

IN-PACKET BLOOM FILTERS AKA ZFILTERS

Ericsson AB | 2011-10-03 |

Forwarding with zFilters

› Source routing › Explicitly enumerating all hops requires a lot of space – so instead we encode this information into a Bloom filter

{HOP1; HOP2; HOP3; HOP4; HOP5; …}

<Bloom Filter>

Ericsson AB | 2011-10-03 |

Link IDs

› No names for nodes – Each link is identified with a

unidirectional (outgoing) Link ID

› Link IDs – No hashing required,

generate the 1-bits otherwise (e.g. randomly)

– Size e.g. 256 bits of which 5 bits set to 1

›  2 x the size of an IPv6 addr ›  Statistically unique

A

D

B C

0 1 0 0 0 1 0 0 1

1 0 0 0 0 1 1 0 0

B→C

A->B

B->C

Ericsson AB | 2011-10-03 |

Link IDs and zFilters

› Strict source routing – Create a path, collect all Link IDs –  Include (OR) all path’s/tree’s

Link IDs into a Bloom filter

› Multicast support –  Include multiple outgoing links

from one router

› Stateless (almost) – Only Link IDs stored on the

router

› Packet forwarding – Always to the correct destination – False positives possible

A

D

B C

0 1 0 0 0 1 0 0 1

1 0 0 0 0 1 1 0 0

1 1 0 0 0 1 1 0 1

B→C

A->B

B->C

A->C

Ericsson AB | 2011-10-03 |

Topology manager’s role

› Collects the network link information –  Intra-network – E.g. OSPF-like system, or PCE

› Calculates paths on request › Creates the zFilter using the Link Identifier information

› Gives the zFilter to the source node

00101001

Topology: zFilter formation

00001001 00100001

Source node

OR

Topic DATA 00101001

LID1 LID2

Ericsson AB | 2011-10-03 |

Forwarding decision

› Forwarding decision based on binary AND and a comparison – zFilter in the packet matched with all outgoing Link IDs – Forward if: zFilter AND LID = LID

( (zFilter AND LID) XOR LID = 0)

zFilter

Link ID

& =

zFilter Yes/No

Interfaces

1 1 0 0 0 1 1 0 1

& 0 1 0 0 0 1 0 0 1

0 1 0 0 0 1 0 0 1

Ericsson AB | 2011-10-03 |

Using Link Identity Tags (LIT)

› Goal: Better false positive rate – Define n different LITs instead of a single LID – LIT has the same size as LID, and also k bits set to one – Power of choices

› Route creation and packet forwarding – Calculate n different candidate zFilters – Select the best performing zFilter (index d) and use that

Link ID

LIT 1

LIT 2

LIT n

Link ID

LIT 1

LIT 2

LIT n

Candidate zFilter

zFilter 1

zFilter 2

zFilter n

Host 1: Iface out Host 2: Iface out

Ericsson AB | 2011-10-03 |

Slide title

32 pt

Text

24 pt

Bullets level 2-5



the footer area

© Ericsson AB 2009 | 4.10.2010

Using Link Identity Tags (LIT)

BF

LIT1

& =

Yes/No

LIT2

LITn

d

d? & =

& =

BF d

Interfaces

Ericsson AB | 2011-10-03 |

Slide title

32 pt

Text

24 pt

Bullets level 2-5



the footer area

© Ericsson AB 2009 | 4.10.2010

zFilter collection › During packet traversal, the reverse zFilter can be easily generated

– Add a field in the packet for collected zF – All routers forwarding the packet add the incoming LID to the field – Once the packet arrives to the destination, the collected zF can be

used to forward data to the reverse direction – Simple especially with symmetric links/paths

Node 2 IF 2-2!

Interface Link ID IF 1-1 00110000 IF 1-2 00001001

IF 2-1!

DATA

Node 1

zF

IF 1-2!IF 1-1!

zFC

Interface Link ID IF 2-1 01010000 IF 2-2 10000010

Matching for outgoing zFC = zFC OR LID1-1

Ericsson AB | 2011-10-03 |

Slide title

48 pt

Slide subtitle

30 pt

EVALUATION

Ericsson AB | 2011-10-03 |

Forwarding speed

› Measured on a NetFPGA › Results

– No routing table lookups → lower latency compared to IP

– zF latency stays constant, independent of the network size

– Line speed

Path Avg. latency Std dev.

Plain wire 94 µs 28 µs IP router 102 µs 44 µs zFilter 96 µs 28 µs

Ericsson AB | 2011-10-03 |

Forwarding efficiency

› Simulations with – Rocketfuel – SNDlib

› Forwarding efficiency with 20 subscribers

– ~80%

› AS6461 – 138 nodes, 372 links

Ericsson AB | 2011-10-03 |

Forwarding efficiency

› Simulations with – Rocketfuel – SNDlib

› Forwarding efficiency with 20 subscribers

– ~80% – LIT Optimized: 88%

› AS6461 – 138 nodes, 372 links

n

Ericsson AB | 2011-10-03 |

Changing zFilter size AS3967: 79 nodes, 147 bi-directional links

Ericsson AB | 2011-10-03 |

Security

›  IP vs. zFilters? –  IP: can be routed from anywhere – zFilter: works only on a certain path → Better (although not complete) DDoS resistance

› zFilter doesn’t reveal (directly) which nodes are involved in the communication → Better privacy

Ericsson AB | 2011-10-03 |

Slide title

48 pt

Slide subtitle

30 pt

ENHANCEMENTS SCALABILITY

Ericsson AB | 2011-10-03 |

Scalability issues

›  Inter-domain forwarding – Too many LIDs in a single BF

results in too many false positives

Ericsson AB | 2011-10-03 |

Scalability: Virtual trees

› Popular paths can be merged into virtual trees – A single Link ID for the tree – Additional state in the forwarding nodes –  Increase scalability

› A virtual tree is not bound to a certain publication – E.g. a single tree for all AS transit traffic

B

F

C D

0 0 1 0 1 0 0 0 1

A E

Virtual B->C->D->E

Ericsson AB | 2011-10-03 |

Scalability: Relay Nodes

› Relay node maintains mapping state – Map: SId,RId = zF1, zF2, …

› RNs change the zF

Relay Node

Relay Node

Ericsson AB | 2011-10-03 |

Scalability: Relay Nodes

Ericsson AB | 2011-10-03 |

Scalability: Splitting the tree

› No need for additional state › Requires more bandwidth at the source

Ericsson AB | 2011-10-03 |

Scalability: Stacked filters

› Stacking multiple filters in the header – “Used” BF removed from the header – Limits multicast usage

› Using dual layer filter – First filter used for intra-domain traversal

› Changed at the edge router – Second filter used for determining next edge router

Ericsson AB | 2011-10-03 |

Slide title

48 pt

Slide subtitle

30 pt

ENHANCEMENTS FAILING LINKS

Ericsson AB | 2011-10-03 |

Fast reroute – Backup path

› Node B maintains backup path information ›  In case of broken link, add backup path

–  Increases temporarily the false positive probability until a new path is calculated at the topology manager

– No additional signaling

B

F

C

D

Add backup path: zF = zF | LBF | LFD

Ericsson AB | 2011-10-03 |

Fast reroute – Virtual trees

› zFilter unmodified › Activate backup path in case of node failure

– Adds signaling

B

F

C

D

Link broken, signal the activation of the backup path to F LID1

Virtual tree: LID1

Virtual tree: LID1

Ericsson AB | 2011-10-03 |

Slide title

48 pt

Slide subtitle

30 pt

ENHANCEMENTS LOOP PREVENTION

Ericsson AB | 2011-10-03 |

Forwarding anomalies

› E.g. packet storms, forwarding loops, and flow duplication › Accidental or maliciously created

false positive

floodedsubtree

duplicatedsubtree

false positive

Ericsson AB | 2011-10-03 |

Avoiding loops

›  Instead of fixed d determining the used LIT, change the d e.g. with d=(d+1) MOD e

›  In case of a loop, the packet will have the same d only if the loop is e hops long

› Simple, stateless solution

Link ID LIT 1 LIT 2 LIT 3

Host 1 Link ID

LIT 1 LIT 2 LIT 3

Host 2 Link ID

LIT 1 LIT 2 LIT 3

Host 3

zFilter

Ericsson AB | 2011-10-03 |

Permutations

› Goal: Prevent forwarding loops and flow duplication ›  Idea: Make forwarding decision depend on the packet’s path and hop-count

› Solution: Per-hop bit permutation – “Mix” the BF bits in incoming packets according to a function

specific to the incoming interface – Simple to implement, no additional space in the packet, randomizes

the BF in case of false positives – Requirements

› Reversible operation, no significant increase in number of 1-bits › Multicast zFilters

– ORing is not enough, must be computed from the leaves of the tree

Ericsson AB | 2011-10-03 |

Forming the permuted zFilter

› Especially suitable when zF is collected on reverse path › zFilter verification to the other direction

– Permute with the function – Match outgoing interfaces

01010000 Host 1

00011000

01011000

OR

Permute

00010110

LID1-1

00010110 Host 2

01010000

01010110 Permute

OR

11011000

LID 2-1

IF 1-1

IF 1-2

IF 2-1

IF 2-2

Ericsson AB | 2011-10-03 |

Slide title

48 pt

Slide subtitle

30 pt

ENHANCEMENTS SECURITY

Ericsson AB | 2011-10-03 |

Security weaknesses with static LID/LITs

› zFilter replay attacks – Sending data with the same zFilter

› Traffic injection attack – Using existing zFilter, send data from the middle of the path

› Computational attack – Collect zFilters from packets – Correlate zFilters to learn link IDs

Ericsson AB | 2011-10-03 |

Secure forwarding

› Goal: to ensure (probabilistically) that hosts cannot send un-authorized traffic

› Solution (z-Formation): Compute LIT in line speed and bind it to

– path: in-coming and out-going port –  time: periodically changing keys –  flow: flow identifier (e.g. content ID)

Ericsson AB | 2011-10-03 |

Secure case: z-Formation

› Form LITs algorithmically – at packet handling time – LIT(d) = Z (I , K (t), In, Out, d),

› Secure periodic key K ›  Input port index › Output port index

› Flow ID from the packet, e.g.

–  Information ID –  IP addresses & ports

› d from the packet

Z IN port #

OUT port #

K(t)

& =

LIT(d)

yes/no

Flow ID

BF d

Ericsson AB | 2011-10-03 |

Security properties

› Binding a zFilter only to the outgoing port – Traffic injection possible – Correlation attacks possible

› Bind to the incoming and outgoing ports – Traffic injection difficult (due to binding to incoming port)

›  Very hard to construct one without knowing keys along the path – Correlation attacks possible only for a given flow ID

›  Bound to the packet stream (flow ID)

› Need a cryptographically good Z-algorithm

Ericsson AB | 2011-10-03 |

Slide title

48 pt

Slide subtitle

30 pt

IMPLEMENTATION

Ericsson AB | 2011-10-03 |

Blackhawk

› Pub/Sub prototype that implements the core ideas from PSIRP/PURSUIT

› Blackboard-based architecture ›  Integrated with the OS kernel

– E.g., virtual memory management

› Objectives: efficiency, natural interface, object deduplication, etc.

› Works in FreeBSD

Ericsson AB | 2011-10-03 |

Publications as Memory Objects

› A publication is an object in the blackboard – i.e., in the computer’s memory

– A (concept) publication is identified by a RId – A version is a specific piece of data identified by a vRId

›  version-RId: hash tree root

– A page is a block of data identified by a pRId ›  page-RId: hash of content

› Sub-object relationships – Concept publications can have several different versions – Versions have a specific set of pages in a specific order

› Scopes are special publications that are identified by SIds and store collections of RIds

Ericsson AB | 2011-10-03 |

Blackboard: Objects

›  Publication – A piece of content – Related metadata

›  Identifiers, size, type, …

› Objects have their own identifiers

– E.g. 256 bits; an opaque or a hierarchical structure

– Could be tied to the data and/or an entity

– Single global identifier space assumed (by default)

›  Scope – Collection of data

publications (their IDs) –  Information aggregation,

access control ›  Data

– Placeholder for a ”concept”, i.e., mutable content

›  Version –  Immutable instance of a data

publication ›  Page

– A chunk of actual data (e.g. in the OS kernel or in network packets)

– E.g., 4096 bytes

Ericsson AB | 2011-10-03 |

Object Hierarchy Scope 0

Scope 2 Scope 1

Pub 1 Pub 4 Pub 2 Pub 3

Version 3 Version 1

Root Scope

Subscopes

Publications

Version 2 Version 4 Version 5 Versions

Page 1

Page 2

Page 3

Page 4

Page 5

Page 6

Page 7 ...

Pages Page 8

Page 9

Page 10

Page 11 ...

Page 12

Ericsson AB | 2011-10-03 |

Pub/Sub API: Operations

› Create – Create a piece of content to be published –  I.e., allocate virtual memory objects for data and metadata

› Publish – Make content available to others – Results in a new version

› Subscribe – Request and get content

› Register, Listen – Get notified about publication events

(e.g., when a new version appears)

Ericsson AB | 2011-10-03 |

System Architecture

RZV node

Kernel-‐level Click

Blackboard

Userlevel Click

Data publisher

RZV client

pub/sub API

Data subscriber

fs

RZVif

Forwarder

…

socket

Kernel interface

Userlevel interface

TM

… Network devices

Ericsson AB | 2011-10-03 |

VM System Integration

› Metadata object – One page (currently) – Object’s own ID, its size, etc. – List of sub-object IDs

›  Pub: versions ›  Version: pages

› Data object – Pages contain actual content

Ericsson AB | 2011-10-03 |

VM System Integration

› Metadata and data objects mapped to applications’ memory spaces (when created or subscribed to)

› Data is copy-on-write – Can be modified

›  results in a new shadow object ›  unmodified pages shared – don’t need to be copied

– Re-publishing results in a new version that can be subscribed to

1 ... ...

2 ... ...

Ericsson AB | 2011-10-03 |

Slide title

48 pt

Slide subtitle

30 pt

APPLICATIONS

Ericsson AB | 2011-10-03 |

Slide title

32 pt

Text

24 pt

Bullets level 2-5



the footer area

© Ericsson AB 2009 | 4.10.2010

Data centers

› zFilters only in the internal network › Easier to modify the routing in the network

– E.g. route packets via certain services: Load balancing, monitoring...

– Binding the flow to input and output ports allows flexible path control at the ingress point

Router Ingress router External

network (IP)

Monitoring

Filtering

Data center network - zF based forwarding Monitoring + filtering -> zF-1 Filtering -> zF-2

Decision for zF

Ericsson AB | 2011-10-03 |

Slide title

32 pt

Text

24 pt

Bullets level 2-5



the footer area

© Ericsson AB 2009 | 4.10.2010

(G)MPLS - Multiprotocol label switching

› Evolution: MPLS->MPLS-TE -> GMPLS ›  (G)MPLS is a rich set of protocols

– Setting up Label Switched Paths – Forwarding on the Label Switched Paths – Traffic Engineering, resiliency (e.g. fast reroute) – Enabler of VPN services – Control plane for many different technologies

PE P PE

IP Payload IP Payload Label1 IP Payload Label2 IP Payload

Provider Edge Router

Provider Router


Push label Switch label Pop label

Ericsson AB | 2011-10-03 |

Slide title

32 pt

Text

24 pt

Bullets level 2-5



the footer area

© Ericsson AB 2009 | 4.10.2010

MPSS - Multiprotocol stateless switching

› Advantages over label switching – There is not necessarily need for signaling –  In simpler case, no state required – Multicast support (setup, maintenance) much simpler than with

(G)MPLS

PE P PE

IP Payload IP Payload zF IP Payload zF IP Payload


Provider Router


Push zF zF forwarding Pop zF

Ericsson AB | 2011-10-03 |

Slide title

32 pt

Text

24 pt

Bullets level 2-5



the footer area

© Ericsson AB 2009 | 4.10.2010

Multicast VPN with MPSS

› Effective support of point-to-multipoint communication › The bandwidth efficiency vs. Multicast state trade-off eliminated

– (Though longer header sizes) › With zFilters: no multicast states, and acceptable bandwidth efficiency up to ~20 PEs

PE

PE PE

PE

CE

CE

CE

P P

CE

CE

CE CE

Ericsson AB | 2011-10-03 |

Optical packet forwarding

› All-optical packet forwarding – Matching LID from laser with the iBF – XOR with feedback goes to zero if one bit fails (= no forwarding)

ON/OFF

XOR (feedback)

Laser

Input

iBF

LID + 0000…

NAND

Payload + iBF

Ericsson AB | 2011-10-03 |

Summary

› New multicast forwarding mechanism – Suits pub/sub networking and synchronous multicast very well – Can also be applied outside our pub/sub model – Almost stateless – Good security properties

› But: Some scalability issues – especially due to false positives

– And also some security issues

› Many enhancements/changes/additions to the basic LIPSIN mechanism have been proposed

– Tradeoffs › E.g., work on inter-domain forwarding ongoing

Ericsson AB | 2011-10-03 |

Some references ›  Petri Jokela, András Zahemszky, Christian Esteve, Somaya Arianfar,

and Pekka Nikander, “LIPSIN: Line speed Publish/Subscribe Inter-Networking”, ACM SIGCOMM 2009

›  András Zahemszky and Somaya Arianfar, “Fast reroute for stateless multicast”, IEEE RNDM 2009

›  Christian Esteve et al., “Self-routing Denial-of-Service Resistant Capabilities using In-packet Bloom Filters”, EC2ND, 2009

›  Christian Esteve et al., “Data center networking with in-packet Bloom filters”, SBRC, 2010

›  András Zahemszky et al. “MPSS: Multiprotocol Stateless Switching”, IEEE Global Internet Symposium 2010

› Mikko Särelä et al., “Forwarding Anomalies in Bloom Filter Based Multicast”, IEEE INFOCOM 2010

›  Dirk Trossen et al., “PURSUIT Deliverable D2.2: Conceptual Architecture: Principles, patterns and sub-components descriptions”, Section 4.3: Forwarding, 2011

›  Sajjad Rizvi, “Performance analysis of bloom filter-based multicast”, Master’s thesis, Aalto university, 2011

pub/sub networking

Documents