Hop By Hop Multicast Routing Protocol ∗ Lu´ıs Henrique M. K. Costa1,2, Serge Fdida1, and Otto Carlos M. B. Duarte2 [email protected], [email protected], [email protected] 1 Laboratoire d’Informatique de Paris 6 2 Grupo de Teleinformatica´ e Automac¸ao˜ Université Pierre et Marie Curie Universidade Federal do Rio de Janeiro 4, place Jussieu - 75252 P.O. Box 68504 - 21945-970 Paris Cedex 05 - France Rio de Janeiro - RJ - Brasil ABSTRACT The IP Multicast architecture is completed by group ad- IP Multicast is facing a slow take-off although it is a hotly dressing and routing protocols. A multicast group is iden- debated topic since more than a decade. Many reasons are tified by a class-D IP address which is not related to any responsible for this status. Hence, the Internet is likely to topological information, as opposed to the hierarchical uni- be organized with both unicast and multicast enabled net- cast addressing model. Therefore, multicast address alloca- works. Thus, it is of utmost importance to design protocols tion is complicated and multicast forwarding state is diffi- that allow the progressive deployment of the multicast ser- cult to aggregate. Currently, there is no scalable solution vice by supporting unicast clouds. This paper proposes HBH to inter-domain multicast routing. The approach used is to (Hop-By-Hop multicast routing protocol). HBH adopts the connect different domains through MBGP (Multiprotocol source-specific channel abstraction to simplify address allo- Extensions to BGP)[2] and MSDP (Multicast Source Dis- cation and implements data distribution using recursive uni- covery Protocol)[18]. MBGP is used to announce differ- cast trees, which allow the transparent support of unicast- ent unicast and multicast-capable routes whereas MSDP is only routers. Additionally, HBH is original because its tree able to exchange active source information among the differ- construction algorithm takes into account the unicast rout- ent domains. The configuration complexity of this solution ing asymmetries. As most multicast routing protocols rely works against multicast deployment. On the other hand, on the unicast infrastructure, these asymmetries impact the backbone operators are currently overprovisioning their net- structure of the multicast trees. We show through simula- works so they have little interest in using multicast. tion that HBH outperforms other multicast routing proto- Nevertheless, ISPs (Internet Service Providers) could be cols in terms of the delay experienced by the receivers and interested in multicast to face the increasing demand for the bandwidth consumption of the multicast trees. network resources and content distribution. As a conse- quence, the Internet is likely to be organized with both uni- cast and multicast enabled networks. Therefore, it is of 1. INTRODUCTION utmost importance to design protocols that allow the pro- IP Multicast is facing a slow take-off although it is a hotly gressive deployment of the multicast service by supporting debated topic since more than a decade. Many reasons are unicast clouds. responsible for this status. The IP Multicast architecture Different solutions that simplify the multicast service by is composed of a service model that defines a group as an reducing the distribution model were proposed [8]. EX- open conversation from M sources to N receivers, an ad- PRESS [16] restricts the multicast conversation to 1toN dressing scheme based on IP class-D addresses, and routing (the channel abstraction), simplifying address allocation and protocols. In IP Multicast any host can send to a multicast data distribution, and still covering most of the current mul- group and any host can join it and receive data [5]. The IP ticast applications. The source-specific multicast service, Unicast service model is also completely open, but the po- currently being standardized at the IETF (Internet Engi- tential burden caused by unauthorized senders is amplified neering Task Force), can be implemented by Version 3 of by the group size in multicast. IGMP (Internet Group Management Protocol)[4] and by a modified version of PIM-SM (Protocol Independent Multi- ∗ This work was sponsored by FUJB, CNPq, CAPES, cast - Sparse Mode)[11], named PIM-SSM [3]. Neverthe- COFECUB, and IST Project GCAP N0 1999-10504. less, source-specific multicast does not allow the progressive deployment of the multicast service. Currently, the only alternative is to use tunnels to go through unicast-only net- works. There is some work in progress specific to multi- Permission to make digital or hard copies of all or part of this work for cast tunnelling. One such mechanism is the UDP Multi- personal or classroom use is granted without fee provided that copies are cast Tunneling Protocol (UMTP)[13]. UMTP encapsulates not made or distributed for pro£t or commercial advantage and that copies UDP multicast datagrams inside UDP unicast datagrams, bear this notice and the full citation on the £rst page. To copy otherwise, to so it can be implemented as a user-level process at end- republish, to post on servers or to redistribute to lists, requires prior speci£c hosts. The work in [14, 17] propose different mechanisms permission and/or a fee. SIGCOMM’01, August 27-31, 2001, San Diego, California, USA.. to automate the generation of UMTP tunnels. Automatic Copyright 2001 ACM 1-58113-411-8/01/0008 ...$5.00. 249 Multicast Tunnelling (AMT)[22] is an alternative scheme multicast trees, the majority of routers simply forward pack- that does not rely on UDP, it provides tunneling capabil- ets from one incoming interface to one outgoing interface, in ity through pseudo network interfaces that serve as default other words, the minority of routers are branching nodes. routes to multicast traffic. We do not propose a new au- Nevertheless, all multicast protocols keep per group infor- tomatic tunnelling scheme to connect the multicast-enabled mation in all routers of the multicast tree. Therefore the parts of the Internet, but instead proposes a new multicast idea is to separate multicast routing information in two ta- routing protocol that inherently supports unicast routers. bles: a Multicast Control Table (MCT) that is stored in Additionally, the protocol design takes into account the uni- the control plane and a Multicast Forwarding Table (MFT) cast routing asymmetries that may affect the structure of the installed in the data plane. Non-branching routers simply multicast distribution tree, especially if unicast-only routers keep group information in their MCT, as branching nodes are present. keep MFT entries which are used to recursively create packet The ability to transparently support unicast routers is the copies as to reach all group members. main motivation of the Hop-By-Hop multicast routing pro- REUNITE identifies a conversation by a <S,P > tuple, tocol (HBH) we propose in this paper. HBH implements where S is the unicast address of the source and P is a port multicast distribution through recursive unicast trees, ap- number allocated by the source. Class-D IP addresses are proach originally proposed in REUNITE [21]. REUNITE not used. As receivers join the group REUNITE populates does not use class-D IP addresses for group identification, its tables to construct the distribution tree. REUNITE uses completely abandoning the IP Multicast addressing model. two message types: join and tree. Join messages travel up- HBH uses the unicast infrastructure to do packet forward- stream from the receivers to the source, as tree messages are ing with smaller routing tables, just as REUNITE does, but periodically multicast by the source to refresh soft-state of uses EXPRESS’ channel abstraction to identify a group. the tree. Only the branching nodes for the group <S1,P1> Thus HBH preserves compatibility with IP Multicast as it keep <S1,P1 > entries in their MFT. The control table, uses class-D IP addresses in group identification. HBH con- MCT, is not used for packet forwarding. Non-branching structs Shortest-Path Trees (SPT) instead of Reverse SPTs routers in the <S1,P1> tree have MCT entries for <S1,P1> as most routing protocols do [6, 7, 9, 23]. Consequently, but no MFT entry. HBH potentially provides best routes in asymmetric net- works and is suitable for an eventual implementation of 2.2 Multicast distribution through recursive Quality of Service (QoS) based routing. Additionally, HBH unicast has a tree management algorithm that provides enhanced The basic idea of the recursive unicast approach is that tree stability in the presence of group dynamics and poten- packets have unicast destination addresses. The routers that tially reduces tree bandwidth consumption in asymmetric act as branching nodes for a specific multicast group are re- networks. sponsible of creating packet copies with modified destination This paper is organized as follows: Section 2 presents the address in such a way that all group members receive the related work, motivations and basic ideas of HBH, Section information. 3 describes the HBH protocol and Section 4 presents a per- Figure 1(a) shows how the recursive unicast data distri- formance comparison of HBH and other multicast protocols bution works for HBH. S sends data addressed to H1. H1 through simulation. Section 5 concludes the paper. creates two packet copies and sends them to H4 and H5 (the next branching nodes). H3 simply forwards the packets in 2. THE BASIC PRINCIPLES OF HOP-BY- unicast. H5 receives the data and sends a modified packet H r H HOP MULTICAST copy to 7 and 8. Finally, 7 creates one packet copy to r4, r5,andr6. Data distribution is symmetric on the other This section presents previous work related to this pa- side of the tree. per, namely the EXPRESS and REUNITE protocols, and Figure 1(b) gives an example of the recursive unicast data then introduce the basic principles of HBH and the prob- distribution in REUNITE.