Compact forwarding : Uma abordagem probabilística para o encaminhamento de pacotes em redes orientadas a conteúdo

1. Compact forwarding : Uma abordagem probabilística para o encaminhamento de pacotes em redes orientadas a conteúdo Christian Esteve Rothenberg Exame de defesa de Doutorado, 15/12/2010 Universidade Estadual de Campinas (Unicamp)

2. Agenda • Motivation: Beyond TCP/IP • Problem: Forwarding in • Content-Oriented Networks • Approach: Compact Forwarding • Questions • Contributions • Probabilistic Forwarding • Principles • Algorithmic techniques • Enablers • Applications

3. Background and Motivation - radical research - What is needed? What is possible? information-centrism PSIRP DONA content-centric networking New ID spaces TRIAD ROFL id-loc 3 Interconnecting information CDN clean-slate DPI P2P overlays IPv6 networking (r)evolution middleboxes NAT patching TCP/IP 2 Interconnecting hosts Telephony 1 Interconnecting wires

4. Content-oriented Networking Rethinking fundamentals ? • Send / Receive → Publish / Subscribe • Sender-driven → Receiver-driven • Host names → Data names • Host reachability → Information scoping • Channel security → Self-certified metadata • Unicast → Multicast

5. Problem • Data forwardingchallenges of content-orientednetworks • Focuson data, notonend-points • Re-thinkthepacketforwardingplane • What is a suitable forwarding substrate for content-centric networks departing from the host-centric paradigm of IP? • Which are candidate features and enabling data structures? • Main abstraction is a flat label • Bit string representing any higher level information (e.g. content object, network link, multicast tree, endpoint ID). • Howto forward packets labeled with flat (location-independent, unstructured, random looking) identifiers?

6. Longest IP prefix vs. flat label matching human machine Aggr. flat ID forwarding is expensive @ wire speed

7. Scale by aggregation • Global networks are able to scale by aggregating the address space so that state is needed only for each aggregate. • Scalability principle also known as information hiding. • Examples: • Public switched telephone number aggregation on geographical location • Domain Name System (DNS): Zone aggregation of hierarchical names • Hierarchical routing: Aggregation of IP addresses on address blocks • Problem: • Flat labels are not aggregatable • How to provide efficient wire-speed forwarding on a large universe (e.g., 256-bit) of flat identifiers? • A probabilistic approach: • Synthetic aggregation through suitable (lossy) compression methods applied to packet forwarding. • Transform the packet forwarding into a set membership problem solved by probabilistic data structures (i.e., Bloom filter variations).

8. The role of Bloom and family Well-known probabilistic data structure • Efficient data set aggregator • False positive rate : f (memory / # elements) Suits wire-speed forwarding requirements • Low (bounded) packet processing time (time to hash) • Scarcity of high-speed memory Compact forwarding approach: • Forwarding as a set membership-problem solved by variations of the Bloom filter probabilistic data structure • Relax algorithmic correctness: trade state for over-deliveries (bandwidth efficiency) Insert_element() Check_element() “yes” / no ?

9. A probabilistic approach to packet forwarding Compact forwarding as two extreme setmembership-problems solved with probabilistic data structures (i.e., Bloom filters): • SPSwitch: Is packet labelX in forwarding port P? • State in the network • Large Bloom filters maintained in forwarding tables • iBFs: Is outbound link A in packet header Z? • State in the packet header • Small in-packet Bloom filter representing a source route

10. Compact forwarding • We can define compact forwarding as “a study of the trade-offs of in-network and in-packet forwarding methods that guarantee the correct delivery of packets in function of forwarding efficiency.” • Definition 1: We say a forwarding method is compact if each forwarding table entry requires less than log(n)-bits per routable object in an n-dimension universe. • Definition 2: We say a forwarding method is compact if the datagram header size is of fixed size with independence of the forwarding directives included. • Notion of compactness: • Striving for minimal forwarding information base • Forwarding methods based on probabilistic data structures(i.e. one-sided error prone Bloom filter inspired data structures)

11. Transport efficiency Routing / forwarding information in packets(i.e. packet header bits) (Stretch, (Stretch, Bandwidth) 4-dimensional solution space Multicast-readycompact forwarding This Thesis packet routing Traditional unicast & compact routing Previous work State in network elements(i.e. FIB bits) Adaptation costs(e.g.signaling)

12. Contributions • Principles • Collection of generic and technicalprinciplesfor scalable forwarding in content-oriented networks • Algorithmictechniques • Conception and application of algorithmic techniques to cope with the limitations of previous work in probabilistic data structures and deal with anomalies of probabilistic forwarding. • Applications • Validation of the compact forwarding methods in practical networking scenarios: • Internet-scale publish/subscribe networking • Scalable cloud data center networking • Inter-domain multicast

13. Principles • Principle 1: Separate routing from forwarding • Content-oriented routing protocols should be functionally separated from the forwarding elements. (Separation of concerns and evolvability) • Sub-Principle A: Generality: The forwarding methods should be generic enough with regard to the identifiers • Sub-Principle B: Simplicity: The forwarding methods should be based on simple per-packet primitives • Principle 2: Allow a flexible operation point • The forwarding system should enable the network architect/operator to find a sweet spot for a given networking scenario • Principle 3: Multicast-friendliness • The forwarding methods should provide native multicast capabilities • Principle 4: Receiver-controlled data plane security • The forwarding methods should be designed with security in mind, empowering the receiver with control over the delivered traffic

14. Compact forwarding Algorithmic techniques Compact forwarding as two extreme setmembership-problems solved with probabilistic data structures (i.e., Bloom filters): • SPSwitch: Is packet labelX in forwarding port P? • State in the network • Large Bloom filters maintained in forwarding tables • iBFs: Is outbound link A in packet header Z? • State in the packet header • Small in-packet Bloom filter representing a source route

15. In-network compact forwarding Bloom-filter-inspired • Efficient data set aggregator • Answers set membership questions (“yes”/no) • No false negatives: Inserted elements return always true • False positive performance: f (memory / # elements) • Does not depend on the nature (form, size) of the element • Low (constant) processing time and low memory requirements per entry. Our first naïve p-bank Bloom-filter-based switching approach: • Bloom filter membership-problem Is labelx in outportPy? ? 110010100110010 … 011111001010

16. The SPSwitch switching engine • Is packet labelX in forwarding port P?

17. Limitations of standard BFs a) lack of associated values b) expensive deletion c) no notion of time d) unbalanced usage of memory per outport We need a more flexible (probabilistic) data structure! • → d-left Fingerprint Compressed Filter (FCF)* • *recent results by Bonomi et al. (2006)

18. Statefull d-left FCF approach

19. Experimental results • Problem: Still O(n) entries

20. Compact forwarding Algorithmic techniques Compact forwarding as two extreme setmembership-problems solved with probabilistic data structures (i.e., Bloom filters): • SPSwitch: Is packet labelX in forwarding port P? • State in the network • Large Bloom filters maintained in forwarding tables • Limitations: O(n) entries (compact: few bits per element but state required per content object or per flow) • iBFs: Is outbound link A in packet header Z? • State in the packet header • Small in-packet Bloom filter representing a source route

21. In-packet Bloom filter compact forwarding Statein 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 iBF representing a source route • Formedbytopologyfunctionsorcollectedonpath (cf. IP switching) Basic operation: “Is outbound link A in packet header Z?” • Small forwarding tables • Very fast switching (bitwise AND operations) iBF = LID1 OR LID2 LID1 LID2

22. Stateless multicast with 256-bit iBFs (2 x IPv6 addresses) Enough for Internet-wide unicast and sparse multicast in typical WAN (35 links -> approx. 20 edge nodes) iBF forwarding Practical results # Users Zipf distribution of multicast traffic # Groups stateful stateless

23. Compact forwardingAlgorithmic techniques Compact forwarding as two extreme setmembership-problems solved with probabilistic data structures (i.e., Bloom filters): • SPSwitch: Is packet labelX in forwarding port P? • State in the network • Large Bloom filters maintained in forwarding tables • Limitations: O(n) entries (compact: few bits per element but state required per content object or per flow) • iBFs: Is outbound link A in packet header Z? • State in the packet header • Small in-packet Bloom filter representing a source route • Limitations: False positives (efficiency, loops, & security)

24. iBFalgorithmicextensions:Power of choices • Better forwarding efficiency with a simple trick • Define d different Link ID Tags (LITs) instead of a single LID • LIT has the same size as LID, and also k bits set to 1 • Route creation and packet forwarding • Calculate d different candidate zFilters • Select the best performing zFilter, based on some policy

25. iBFalgorithmicextensions:d Link ID Tags • Performance gains (better false positive rates) • better forwarding efficiency | more links • + Functional gains: Avoid system critical false positives (e.g., inter-domain links, low BW links, loops)

26. iBFalgorithmicextensions:Security Shortcomings of plain iBF forwarding • Replay attacks • Computational attacks • Traffic injection attack Goal: Secure the data path and empower the receiver. • Ensure (probabilistically) that hosts cannot send un-authorized traffic Solution: (z-Formation): Dynamically compute LIT at line speed and bind it to: • path: in-coming and out-going port • time: periodically changing keys (per node/group) • flow: packet identifier (e.g. IP 5-tuple / content id)

27. iBFalgorithmicextensions:z-Formation (secure iBFs) • Form LITs algorithmically • at packet handling time • LIT(d) = Z (I , K (t), In, Out, d) • Secret periodic key K • K(t) and K(t-1) • Input port index • Output port index • Flow ID from the packet, e.g. • Content ID • IP addresses & ports • d from the packet header

28. iBFalgorithmicextensions:self-routing capabilities Secure iBF works both as a forwarding ID and a capability • To send, a host needs to know or guess a valid iBF • iBF become expirable and content-dependent • z-Formation • Traffic injection difficult (due to binding to incoming port) • Very hard to construct one valid iBF without knowing keys along the path • Correlation attacks limited to flow IDs • Need a cryptographically good and fast Z implementation • Allowthe receiver to control theiBFrenewal (feedbacklooptothesender)

29. BF algorithmicextensions:Compactly removing elements • How to delete elements from the iBF? Requirements: • No false negatives upon element deletion. • Fixed memory allocation (m bits). • Low impact on the false positive rate (fpr), No previous work provides memory-efficient element deletions: • Counting Bloom filter designs extend 1-bit cells to c-bit counters i.e., c*m . • The d-left CBF requires about 2*m. • BF with variable-length signatures (VLF) are prone to false-negatives. • Spectral Bloom filters, and “an optimal Bloom filter replacement” are complex and static unpractical solutions.

30. BF algorithmicextensions:The deletable Bloom filter (DlBF) Key idea: Small bitmap to keep record of the bit regions where collisions happen.

31. BF algorithmicextensions:DlBF: Fromtheorytopractice • How many elements can be removed in practice?

32. Compact forwarding in practice Applications

33. Publish/Subscribe Architecture: RTFM Where iBFs were born… [LIPSIN] rendezvous layer establishes contact topology layer selects routes forwarding layer delivers data

34. Data Center Networking

35. Some issues with conventional DC designs • Networking constraints of traditional L2/L3 hierarchical forwarding: • Fragmentation of resources (VLAN, subnetting) • Limited server-to-server capacity (high oversubscription) • Ethernet scalability (FIB size, STP, flooding, ARP broadcast) • Low performance under cloud application traffic patterns • Reliability: 2 is a poor choice for redundancy at scale

36. iBF-based Data Center Networking • Compactly represent a source route between ToRs using a Bloom filter • Carry the 96-bit iBF in the source and destinationMACfields • Stateless forwarding by querying next-hop switches in the iBF • MAC re-writing at source and destination ToRs (per flow state reqs.) Benefits: Large L2 domains, VM agility, app-specific load-balancing, resource-friendly...

37. Inter-Domain Multicast

38. Summary of thecontributions and futurework Conclusions

39. Conclusions • Forwarding in content-oriented networks is challenging. • This Thesis contributes to question the commonly held view that networking needs to be centred on endpoint (network interface) identifiers. • The proposed compact forwarding methods explore a new avenue by relaxing the port forwarding function on arbitrary labels to tolerate extra outcomes - trading state for bandwidth efficiency. • We have contributed to turn one-sided error data structures into practical forwarding components, paving the way for a correct, secure, and scalable content-oriented forwarding plane.

40. Contributions and Publications

41. Trabalhos Publicados Pelo Autor A. C. 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. B. P. Jokela, A. Zahemszky, C. Esteve Rothenberg, S. Arianfar, and P. Nikander. “LIPSIN: Line SpeedPublish/Subscribe Inter-Networkings.” In ACM SIGCOMM’09, Aug. 2009, Barcelona, Spain. C. A. Zahemszky, A. Császár, P. Nikander and C. Esteve Rothenberg. “Exploringthe Pub/Sub Routing& Forwarding Space.” In IEEE ICC, Workshop on the Network of The Future, Jun. 2009, Dresden, Germany. D. C. Esteve Rothenberg, P. Jokela, P. Nikander, M. Särela and J. Ylitalo. “Self-routingDenial-of-ServiceResistant Capabilities using In-packet Bloom Filters.” In 5th European Conference on Computer Network Defense (EC2ND), Nov. 2009, Milan, Italy. 5. C. Esteve Rothenberg. “Re-architecting the Cloud Data-Center Networks.” In IEEE ComSoc Optical Networking Technical Committee (ONTC) Newsletter PRISM, Vol 1. No 2. March 2010. 6. F. L. Verdi, C. Esteve Rothenberg, R. Pasquini and M. F. Magalhães. “Novas Arquiteturas de Data Center para Cloud Computing.” Book Chapter, SBRC, Gramado, Brazil, May 2010 E. C. Esteve Rothenberg, C. A. Macapuna, F. L. Verdi, M. F. Magalhães and A. Zahemszky. “Data center networking with in-packet Bloom filters.” In 28th Brazilian Symposium on Computer Networks (SBRC), Gramado, Brazil, May 2010.

42. Trabalhos Publicados Pelo Autor 8. A. Zahemszky, B. Gajic, C. Esteve Rothenberg, C. Reason, D. Trossen, D. Lagutin, J. Tuononen and K. Katsaros. “Experimentally-driven research in publish/subscribe information-centric inter-networking.” In Tridentcom 2010, May. 2010, Berlin, Germany. F. C. Esteve Rothenberg, C. A. Macapuna, F. L. Verdi and M. F. Magalhães. “TheDeletableBloomFilter: A new member of the Bloom family.” In IEEE Communication Letters, June 2010. G. C. Esteve Rothenberg, C. A. Macapuna, F. L. Verdi, M. F. Magalhães and A. Wiesmaier. “In-packetBloomfilters: Design and networking applications.” Accepted in Elsevier Computer Networks. • M. Särela, C. Esteve Rothenberg, A. Zahemszky, J. Ött and P. Nikander. “BloomCasting: Security in Bloom filter based multicast.” In Nordsec 2010, Oct. 2010, Espoo, Finland. • M. Särela, C. Esteve Rothenberg, T. Aura, A. Zahemszky, J. Ött and P. Nikander. “Forwarding Anomalies in Bloom Filter BasedMulticast.” Accepted in IEEE Infocom 2011. 13. Carlos A. B. Macapuna, C. Esteve Rothenberg and M. F. Magalhães. "In-packet Bloom filter based data center networking with distributed OpenFlow controllers". In 2nd IEEE MENS 2010, Dec. 2010, Miami, Florida, USA 14. 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..

43. Resultados de Propriedade Intelectual • International Patent Application PCT/EP2008/063647, Patent: “Packet Forwarding in a Network,” Applicant: Ericsson AB, Publication number: WO 2010/022799 (A1), Publication date: 2010-03-04, Date of Filing: 2008-10-10, Inventors: JOKELA, Petri, ESTEVE, Christian, KJÄLLMAN, Jimmy, NIKANDER, Pekka, RINTA-AHO, Teemu, YLITALO, Jukka, • International Patent Application PCT/EP2009/062785, Patent: “Secure In-Packet Bloom filter applications,” Applicant: Ericsson AB, Date of Filing: 2009-06-10, Inventors: ESTEVE, Christian, JOKELA, Petri, NIKANDER, Pekka, SÄRELÄ, Mikko, YLITALO, Jukka.

44. Future work • Active area of networking with iBFs • GMPLS, mobility, inter-domain [PURSUIT], optical • Open questions: E.g., DlBF dynamics (Keep doing insertion and deletions). Other compact and more flexible bitmaps? • Explore more applications and networking scenarios • SiBF: Remove middlebox Bloomed Service IDs + beyond VLB • BloomCasting: Remove AS edges (permutating DlBFs) • CCN: Relief the core from PIT entries with topology-carrying iBFs. SPSwitch engine for structured CCN names (e.g., a/b/c/d/:hash) ? • iBFs: fault-carrying, multi-path, path information (e.g., measurements) • Right balance between edge-, network- and packet state? • Plus many broader architectural questions of content-oriented networks

45. Questions?

46. BACKUP

47. Compact forwarding in content-oriented networks Traditional Forwarding Compact Forwarding Scale by Synthetic aggregation (lossy compression) Trading state for over deliveries (flexible operation point) Moving (approximate) forwarding state to packets Probabilistic algorithms Trade correctness for space/time requirements Prone to one-sided errors (port-forwarding w/ extra packet dups.) Focus on multicast Receiver-oriented • Scaleby • Structuralaggregation(hierarchical IP) • Timelyinformation(e.g. Ethernet) • Deterministicalgorithms • Forward onlongestprefixes(e.g., Treebitmap IP lookup) • Exactlookupmatches(e.g., MPLS, Ethernet) • Focusonunicast • Sender-oriented

48. Principles in action

49. Observation Fundamentals of the Internet • Collaboration • Reflected in forwarding & routing • Cooperation • Reflected in trust among participants • Endpoint-centric services • Mail, FTP, even Web • Reflected in E2E principle • Reality in the Internet • Current economics favor senders • Receivers are forced to carry the cost of unwanted traffic • Phishing, spam, viruses • There is no trust any more • Information-centric services • Do end-points really matter? • Information retrieval through, e.g., CDNs, P2P IP, full end-to-end reachability IP with middleboxes & significant decline in trust Source: EU FP7 PSIRP Project

50. SPSwitch forwarding engine • model • implementation(FCF d-left hash Table) [Re-Arch08] • Is packet label X in forwarding port P? • Problem: Still O(n) entries