Multicast Forwarding Plane in Future NWs : Source Routing Has a Competitive Edge

1. 2010-12-10 GLOBECOM FutureNetIII Multicast Forwarding Plane in Future NWs: Source Routing Has a Competitive Edge Takeru Inoue Yohei Katayama Hiroshi Sato Takahiro Yamazaki Noriyuki Takahashi (NTT Labs., Japan) 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 • Dr. multicast [Vigfusson08] and MAD [Cho09] • Extend IP multicast for many groups • Handle only large groups and reduce forwarding state • 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 • Table-driven forwarding • 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 Group1 p1 p2 p3 To Ports 2 and 3 Takeru INOUE@NTT Network Innovation Labs.

6. Taxonomy g1 Forwarding state g1: p2 p3 : • 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) p1 p2 p3 Packet n1:p2 n1:p3 … p1 p2 p3 Table-driven forwarding Packet-driven forwarding 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 table vp1 … Mapping of virtual ports vp1: p2 p3 : p1 p2 p3 vp1 vp2 Packet-driven forwarding Takeru INOUE@NTT Network Innovation Labs.

8. 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] Bloom filters g1 p1: … p2: g1 … p3: g1 … p1 p2 p3 Table-driven forwarding Bloom filter in packet n1:p2 n1:p3 … p1 p2 p3 Packet-driven forwarding Takeru INOUE@NTT Network Innovation Labs.

9. 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 g1 n1:p2 n1:p3 … Headers table g1: n2:p1 … : Domain border g1 n2:p1 … Packet-driven forwarding Takeru INOUE@NTT Network Innovation Labs.

10. 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.

11. 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.

12. Scalability on group number and size Forwarding table: 18 Mbits Packet header: 800 bits • 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 1T 1.8M 6-order Bloom 93.8K Group size (log-scale) 410K 640 Virtual ports and Bloom Hierarchy 6 1M Takeru INOUE@NTT Network Innovation Labs.

13. 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 Multiple elements in TCAM are checked against Bloom filter at once Set of virtual ports in Bloom filter TCAMs vp1 … p1: … p2: vp1 … p3: vp1 … p1 p2 p3 vp1 Packet-driven forwarding Takeru INOUE@NTT Network Innovation Labs.

14. 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.

15. 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.

16. 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 Takeru INOUE@NTT Network Innovation Labs.