On the experimentation of the novel GCMR multicast routing in a large-scale testbed Davide Careglio * , Dimitri Papadimitriou † , Fernando Agraz * , Sahel Sahhaf ‡ , Jordi Perell´ o * , Wouter Tavernier ‡ * CCABA - Universitat Polit´ ecnica de Catalunya, Barcelona, 08034 Spain † Alcatel-Lucent Bell Labs, Antwerp, Belgium ‡ iMinds, Ghent, B-9050 Belgium I. I NTRODUCTION AND MOTIVATION Originally defined in the 90s, multicast is nowadays (re)gaining interest given the increasing popularity of mul- timedia streaming/content traffic and the explosion of cloud services. In fact, multicast yields bandwidth savings com- plementing cached content distribution techniques and its potential benefits have been verified by studies several times since then (see e.g. [1]). By multicast routing, we refer to a distributed algorithm that, given a group identifier, allows any node to route multicast traffic to a group of destination nodes, usually called multicast group. To enable one-to-many traffic distribution, the multicast routing protocol configures the involved routers to build a (logical) delivery tree between the source and the multicast group, commonly referred to as the Multicast Distribution Tree (MDT). Nevertheless, the scal- ing problems faced in the 90s still remain mostly unaddressed and worst-case projections predict indeed that routing engines could have to process and maintain in the order of 1 million active routes within the next 5 years [2]. During last decade, some multicast routing schemes have been standardized but only the Sparse Mode (SM) and the Single Source Multicast (SSM) variant of Protocol Independent Multicast (PIM-SM [3] and PIM-SSM [4] respectively) have been deployed in the context of IPTV systems for routing multicast streams between VLANs, subnets or access net- works [5]. However, the adoption of inter-domain multicast has failed, as it relies on an overlay routing executing on top of the unicast routing topology, which suffers from the same scaling limits. Additional issues are: i) the indirection added by the multicast address space, ii) the limits of shared trees between domains, iii) management and security complexity, iv) the limited number of applications making use of one-to- many connectivity via Internet multicast routing, and many others. A complete analysis of the deployment issues for the IP multicast routing architecture can be found in [6]. As part of the work conducted in the EULER FP7- project [7], we designed the Greedy Compact Multicast Rout- ing (GCMR) scheme [8]. In this demonstration, we exhibit the successful operation of GCMR in the context of inter-domain routing over a large-scale network topology and compare its performance with the standard PIM protocol. II. GCMR IN BRIEF The main objective of GCMR is to minimize (i.e., to com- pact) the routing table size at each router by taking local (i.e., greedy) decisions at expenses of i) routing packets on paths with relative small deviation compared to the optimal tree; ii) increasing the number of messages required to create the MDT. Instead of using unicast topology storage information to derive the multicast routing entries (as in the case of all multicast rout- ing protocols such as PIM), in GCMR, the information needed to reach a given multicast source S is acquired by means of a two-stage search process. The algorithm search process is triggered whenever a node decides to join a source-specific multicast group G, denoted by (S,G). In addition, it can be triggered whenever a failure occurs and part of the MDT needs to be restored. It is worth mentioning that the information exchanged in the search process between the nodes is limited to the (S,G) identifier, a sequence identifier, a branching cost metric and a couple of code/subcode fields to identify the type of message; neither topological nor confidential information needs to be disseminated. A detailed description of the GCMR algorithm can be found in [8], theoretical performance analysis and simulation comparison with other major multicast routing paradigms are documented in [9]. As GCMR does not rely on any unicast routing protocol, it can work together with any addressing scheme like IPv4, IPv6 or even geometric coordinates. In addition, GCMR can be implemented directly in any host, as its scope is not limited to routers, not requiring any host-router protocol like IGMP. Therefore, to the authors knowledge, it is the first name- independent, receiver-initiated, dynamic, distributed, end-to- end multicast routing algorithm. Finally, although GCMR has been designed to improve scalability of multicast routing in inter-domain environments, it can perform in other environ- ments where routing scalability is also a main issue and only limited topology/routing information is available. III. GCMR DEMONSTRATION In this demonstration, we execute a prototype of the GCMR multicast scheme and evaluate its functionality and perfor- mance compared to the standard PIM on the iLab.t virtual wall (VW) 1 platform. iLab.t VW is a large-scale experimental Linux machine-based emulation testbed located in Ghent, Belgium. The prototypes of the GCMR and the PIM routing engines have been developed using the libraries of the Quagga 2 open source routing suite. The iLab.t VW is a generic test environment, which as- sists researchers to validate and evaluate the performance of innovative network prototypes. Each of the 3 VW facilities 1 http://www.iminds.be/en/develop-test/ilab-t/virtual-wall 2 http://www.nongnu.org/quagga/ © 2014 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. DOI 10.1109/INFCOMW.2014.6849177