Takeru INOUE@NTT Network Innovation Labs.

1

Multicast Forwarding Plane in Future NWs:

Source Routing Has a Competitive EdgeTakeru Inoue

Yohei Katayama

Hiroshi Sato

Takahiro Yamazaki

Noriyuki Takahashi (NTT Labs., Japan)

2010-12-10 GLOBECOM FutureNet III

Takeru INOUE@NTT Network Innovation Labs.

2

Gap between design and usage of Internet Internet (TCP/IP)

Originally designed for 1:1 conversation model (60’s-70’s) telnet, ftp, …

NOW: Mainly used for 1:N distribution model Audio-video streaming, pub/sub services, file sharing,

data-center, …

Efficient distribution model Data is replicated at nodes and delivered to a

group Source and overall network overhead is decreased

Future NWs will support efficient distribution In accordance with the usage

replication

Takeru INOUE@NTT Network Innovation Labs.

3

Trend in multicast research History in multicast research

Twenty-year history Main focus was group size, not group numbers

Recent trends Supporting many groups (> 1T)

Increase in contents themselves and long-lived services

1. Dr. multicast [Vigfusson08] and MAD [Cho09] Extend IP multicast for many groups Handle only large groups and reduce forwarding state

2. FRM and LIPSIN [Ratnasamy06, Jokela09] Based on source routing Have no state limit, but suffer from small headers

No clear direction on multicast research for future networks

Takeru INOUE@NTT Network Innovation Labs.

4

Our contribution and outline Our contribution

Most promising research direction in multicast Focused on forwarding plane, because it directly affects quality and is

designed before control plane

Outline Taxonomy of multicast forwarding plane

1. Table-driven forwarding2. Packet-driven forwarding (source routing)

Scalability improvement techniques: virtual ports, Bloom filters, and hierarchy

Assessment of multicast forwarding plane Scalability on group number and group size Forwarding performance Control architecture State management

Takeru INOUE@NTT Network Innovation Labs.

5

External definition of multicast forwarding Nodes independently determine their output

ports S = F(n, g)

S: set of output ports F(n,g): function to determine S

n: node ID g: group ID

Forwarding state maintained by overall network

Packet of Group1p1

p2 p3

To Ports 2 and 3

Group＼Node

n1 n2 …

g1 n1:p2 n1:p3 n2:p1

g2 φ n2:p1 n2:p3

:

Takeru INOUE@NTT Network Innovation Labs.

6

Taxonomy Table-driven forwarding

Nodes maintain columns (forwarding tables) and search them by group ID in packet Max group # is limited by table size e.g. IP multicast

Packet-driven forwarding Source puts row on packet header Nodes finds ports No limit on group #, but group size is limited by header Kind of source routing (nodes are stateless)

Group＼Node

n1 n2 …

g1 n1:p2 n1:p3 n2:p1

g2 φ n2:p1 n2:p3

:

Table-driven forwarding

Packet-drivenforwarding

g1

g1: p2 p3:

n1:p2 n1:p3 …

Forwarding state

p1

p2 p3

p1

p2 p3

Packet

Takeru INOUE@NTT Network Innovation Labs.

7

Review of scalability improvement techniques:Virtual ports Virtual ports [Tian98, Jokela09]

Set of physical ports Fork (ports on single node, e.g. vp1 in Fig) Tunnel (ports on different nodes, e.g. vp2 in Fig)

Reduce forwarding state (tables or headers) Nodes maintain mapping

Much smaller than forwarding tablevp1 …

vp1

vp2

vp1: p2 p3:

Mapping of virtual ports

p1

p2 p3

Packet-driven forwarding

Takeru INOUE@NTT Network Innovation Labs.

9

Review of scalability improvement techniques:Bloom filters Bloom filters

Probabilistic data structure for set Has great space efficiency at risk of false positive

e.g. 10 bits per element with 1 % error Can be checked in constant time

Table-driven forwarding Bloom filter is assigned to each port and has groups of ports [Gronvall02]

Packet-driven forwarding Headers are replaced by Bloom filters [Ratnasamy06]

p1: …p2: g1 …p3: g1 …p1

p2 p3

Bloom filtersg1

n1:p2 n1:p3 …p1

p2 p3

Bloom filter in packet

Table-driven forwarding

Packet-driven forwarding

Takeru INOUE@NTT Network Innovation Labs.

10

Review of scalability improvement techniques:Hierarchy Table-driven forwarding

No improvement Inter-domain nodes maintain

same # of groups

Packet-driven forwarding [Zahemszky09]

Headers are replaced on domain border Group size is greatly

increased Overhead on border can

be distributed

g1n1:p2 n1:p3 …

g1n2:p1 …

Headers table

g1: n2:p1 …:

Domain border

Packet-driven forwarding

Takeru INOUE@NTT Network Innovation Labs.

11

Outline of assessment Multicast forwarding plane

Table-driven forwarding Group # is limited by forwarding table size Improved by virtual ports and Bloom filters

Packet-driven forwarding Group size is limited by packet header size Improved by virtual ports, Bloom filters, and hierarchy

Assessment Scalability with regard to group number and group size Forwarding performance Control architecture State management

Takeru INOUE@NTT Network Innovation Labs.

12

Scalability on group number and size Target

Group # is > 1 T Group size is < 1 M

Few large groups (Zipf distribution) # of all nodes on delivery path

Takeru INOUE@NTT Network Innovation Labs.

13

Scalability on group number and size Target

Group # is > 1T Group size is < 1M

Table-driven forwarding Group # is limited by table Far less than 1T groups

1M with Bloom filters More groups can be supported in

overall network, but gap is too large

Packet-driven forwarding Group size is limited by header Group # of nearly 1M is

supported 0.4M with all means

# of groups at node (log-scale)

Target

1M410K

HierarchyVirtual portsand Bloom

640

1T

Group size (log-scale)

6-order1.8M

Bloom

Forwarding table: 18 MbitsPacket header: 800 bits

6

93.8K

Takeru INOUE@NTT Network Innovation Labs.

14

Forwarding performance Table-driven forwarding

Performed in constant time by CAM other than with virtual ports

Repeated table lookup needed

Packet-driven forwarding Performed in constant time with virtual ports and Bloom filters

Each physical port has TCAM TCAM has virtual ports of the physical

port Bloom filter in packet is checked by all

TCAMs in parallel Packet is copied to all matched ports

vp1 … p1: …p2: vp1 …p3: vp1 …p1

p2 p3

TCAMs

Set of virtual ports in Bloom filter

vp1

Packet-driven forwarding

Multiple elements in TCAM are checked against Bloom

filter at once

Takeru INOUE@NTT Network Innovation Labs.

15

Control architecture Table-driven forwarding

Follows distributed route computation Joins are routed to a source and populate each hop with

forwarding entries Distributed computation complicates assurance of stable

operation

Packet-driven forwarding Follows central route computation

Source calculates delivery path and puts it in packet Simple and stable

Doesn’t impose heavy load on sources, because each source calculates a few trees rooted at themselves

Port list (used to calculate delivery trees) is equivalent to OSPF link state or BGP AS path

Takeru INOUE@NTT Network Innovation Labs.

16

State management Successful NW protocols

NW state is updated by trusted entities, because state failures can affect entire NW

Protocols not widely deployed NW state is updated by users

e.g. IP multicast, MobileIP, and IntServ

Table-driven forwarding Relies on joins by users Violates requirements of successful protocols

Packet-driven forwarding State (packet header) is created by source (trusted entity) Meets requirements of successful protocols

Takeru INOUE@NTT Network Innovation Labs.

17

Conclusions Taxonomy of multicast forwarding plane

Table-driven forwarding Packet-driven forwarding (source routing)

Assessment of multicast forwarding plane

Future work Quantitative analysis, control planes, and implementation issues

Table-driven forwarding

Packet-driven forwarding

Scalability Poor in group #, good in size

Excellent in group #, fair in size

Forwarding performance

Constant time (no virtual ports)

Constant time

Control architecture Distributed Central for each group (distributed for overall NW)

State management By users By trusted entities