QoS-Aware Hierarchical Multicast Routing on Next Generation Internetworks

QoS-Aware Hierarchical Multicast Routing on Next Generation Internetworks Satyabrata Pradhan, Yi Li, and Muthucumaru Maheswaran Advanced Networking Research Laboratory Department of Computer Science University of Manitoba Winnipeg, MB R3T 2N2, Canada {pradhan@mackerel.cs, umliy1@cs, maheswar@cs}.umanitoba.ca Abstract Quality of service (QoS) based routing and scalability are two key features of multicast routing for the next generation Internetworks. This paper proposes a new protocol called QoS-aware hierarchical multicast routing protocol (QHMRP) that achieves scalability by organizing the network as a hierarchy of domains using the full-mesh aggregation technique. The protocol uses a novel reverse flooding approach with hierarchical, topological and QoS forwarding conditions to construct the multicast tree while minimizing message overhead and satisfying QoS requirements. The distributed algorithm used in the protocol constructs loop-free tree. Simulations are performed to evaluate the performance of QHMRP under different situations and compare it with a flat routing algorithm. 1. Introduction Multicasting a message is far more efficient than sending a copy of the message from the source to each destination. Many real-time Internet applications such as IP Telephony, radio and television over IP, video conferencing cannot operate with the best effort service provided by current IP networks. To serve such applications, IP networks should provide quality of service (QoS) guarantees. The importance of QoS-based multicast routing has prompted several research initiatives in this area. Most of these initiatives focus on flat routing schemes, which model the entire network as a single domain. The flat protocols are not well suited for large networks. The scalability issue can be addressed by organizing the network in a hierarchy of domains [1, 6]. This paper presents a QoS-aware Hierarchical Multicast Routing Protocol (QHMRP) that can efficiently handle large networks. The QHMRP uses the full-mesh approach to organize the network into multiple levels where a domain is represented by its border routers. The concept of domain controller is used for coordinating the construction of shared multicast trees. The protocol uses a novel reverse flooding approach to connect new hosts with the tree while satisfying endto-end QoS constraints. The paper is organized as follows. The next section reviews the related work. Section 3 presents the network model used in the study. Section 4 provides a detailed description and analysis of the proposed protocol. Simulation results are examined in Section 5. 2. Related Work The QoS-aware multicast routing protocol (QMRP) [3] constructs a shared tree by unicasting a Request message from the host router towards the core. If a router in the unicast path does not satisfy the QoS requirement, the Request message back tracks one router and is sent along all other links as unicast messages towards the core. When an on-tree router or the core receives a Request message it sends and Ack message back to the host router. After receiving the Ack messages, the host router selects a path to connect to the tree. QHMRP is different from QMRP is several ways. Our approach uses a hierarchical network model and uses flooding. Because it is based on flooding it is more robust and is more likely to find a path if it exists. Several schemes to reduce the message overhead are also examined. This research was supported by the NSERC under grant number RGP 22278 and equipment used was supported under a Canada Foundation for Innovation grant.

The QoS sensitive multicast Internet protocol (QoSMIC) [5] uses a concept of manager to construct shared multicast trees. It uses two approaches to join a multicast tree: local search and multicast tree search. In local search, flooding is used to join an on-tree router. In multicast tree search, the host router sends an M-Join message to the manager, which knows addresses of all on-tree routers. The manager selects certain on-tree routers and asks them to unicast Bid messages towards the host router. After receiving the Bid messages, the host router selects the best path to connect to the multicast tree. Because QHMRP is based on a hierarchical network model, it is more scalable. 3. System Model The network is modeled as a set of nodes that are connected by a set of unsymmetric links. The network is organized hierarchically into L levels of domains. A domain in level i is called an i-domain. The routers form -domains. A group of routers (- domains) form a 1-domain. In general, a group of i- domains form an (i+1)-domain. Inside an i-domain there can be several (i-1)-domains and there can be peer-type connections among the domains. Specifically, for a 3-level hierarchy, the 1- domain consists of a network of routers. A router that defines the edge of a domain and connects to an external domain is called a border router. For each i- domain, i >, one border router is selected as the controller and is responsible for maintaining information regarding the multicast trees inside the domain. This selection can be done by an election process or can be pre-configured. The controllers of the parent domains are called parent controllers. The address of the parent controller is either specified or can be obtained from the session directory [7]. In this model, an n-tuple addressing scheme is used to uniquely identify a router in the network. The address of a router is expressed as (i L 1.i L 2. i 3.i 2.i 1.i ), where i j, j =,1,2, (L 2), (L 1), are nonzero positive integers. Here, i j is the number of the sub-domain of a (j+1)-domain to which the router belongs. An example 3-level hierarchical network shown in Figure 1 illustrates the router numbering scheme. Modified routing tables are used to reduce the message overhead of the proposed protocol. These tables specify the minimum distance between a router and all other routers in the domain via different neighboring routers. Topology aggregation using full mesh approach [9] is used to achieve scalability by reducing the size of the routing tables. In this approach, each router uses a multi-level routing table. The algorithm to construct the modified routing table is presented in [11]. 1.1.1 1.1.2 Controller 1.1.3 1.2.4 1.2.1 Border Router Router 1.2.3 1.2.2 2.1.1 2.2.2 2.2.3 Figure 1: Hierarchical network model. 4. QHMRP: QoS-Aware Hierarchical Multicast Routing Protocol The controllers of different domains store information on multicast trees and facilitate the operation of QHMRP. Unlike the core in CBT and RP in PIM-SM, controllers do not directly participate in the multicast tree. A controller of a 1-domain has a list of all on-tree routers in its domain for each multicast tree. The higher level controllers have the controller address of the sub-domains having one or more on-tree routers. Therefore, if a multicast tree exists, then there is at least one controller in every level that is aware of it. 4.1. Description of the Protocol 2.1.4 2.1.3 2.1.2 2.2.1 When a host router wants to join a multicast tree, it sends a JoinRequest message to its parent controller. If the controller is aware of the multicast tree, then it forwards the JoinRequest message to all the on-tree routers or controllers that has on-tree routers. Otherwise, the controller forwards the JoinRequest message to its parent controller. If a multicast tree exists, then it is guaranteed that the JoinRequest message will arrive at a controller that is aware of the multicast tree. The on-tree routers receiving the JoinRequest message send Flooding messages towards the host router. The process of flooding from on-tree routers towards the host router is called reverse flooding. The pseudo-code for

processing the JoinRequest message is presented in Figure 2. The path followed by the Flooding message that arrives first at the host router is a feasible path for connecting to the tree. After receiving the first Flooding message, the host router sends a Join message along the feasible path to establish the connection. The data stored at each router while forwarding Flooding messages are used to find this feasible path. JoinRequest(multicast, host, path, QoSIndex, QoSReq) { if (current router is on the tree) send Flooding messages towards the host else if (on-tree controllers or routers exist in the domain) forward JoinRequest message to all on-tree controllers and routers else if (current router is the highest level controller) initiate creation of the multicast tree discard the JoinRequest message else forward the JoinRequest message to current router's parent controller end if } Figure 2: Pseudo-code for processing the JoinRequest message. To reduce message overhead during reverse flooding, the Flooding messages are forwarded only in those directions that satisfy the forwarding conditions that are explained in the next subsection. While forwarding the Flooding messages, each router maintains a data structure defined by F(multicast, host).forwardstatus, F(multicast, host).qospath, and F(multicast, host).prerouter. The information in this data structure is used for controlling the flooding and for establishing connection during the join process. Here, F(multicast, host).prerouter is the address of the neighboring router which sent the most recent flooding message that has been forwarded by the current router, F(multicast, host).forwardstatus is a boolean variable that shows whether the flooding message has been forwarded by the current router or not, and F(multicast, host).qospath is the QoSPath of the most recent message that has been forwarded by the router and is initialized to zero. The variable F(multicast, host).forwardstatus has a default value FALSE and is set to TRUE when a flooding message from the multicast tree is forwarded towards the host router. Because of the QoS forwarding condition, all the Flooding messages that arrive at the host router satisfy the QoS requirement. After receiving the first Flooding message, the host router sends a Join message along a path that is opposite of the path traversed by the Flooding message. The variables in the data structure F(multicast, host) at each router are used to find the path for the Join message. All the routers in the path of the Join message become part of the branch that connects the host router with the tree. When a router receives a Join message, it reserves the resources for the multicast tree, updates tree information at the current router, sends an update message to its parent controller for updating the multicast tree information, and forwards the message to F(multicast, host).prerouter. The pseudo-code for the Join message is presented in Figure 3. Join(multicast, host, PreRouter, QoSIndex, QoSReq) { add PreRouter to the list of neighboring on-tree routers if ( the current router is on the tree ) discard the Join message else if (current router is not the highest level controller) send update message to current router's parent controller end if reserve the required resources update the tree information at the current router send Join message to F(multicast, host).prerouter end if } Figure 3: Pseudo-code for processing the Join message. Even though a router has sufficient resource to meet the QoS requirement when it forwards the Flooding message, it may not have the required resource to reserve while processing the Join message. 4.2. Reverse Flooding High message overhead in one of the major limitation of a flooding based protocol. In this paper, three forwarding conditions: hierarchical, topological and QoS forwarding are used to reduce the message overhead. The forwarding conditions use a distributed algorithm that is implemented at each router and only uses state information local to the router The hierarchical forwarding condition limits the flooding within the lowest level domain, called flooding domain that contains the host router and some on-tree routers. The lowest level domain that contains the current router and the host router is called as the local flooding domain. If the flooding at each router is limited within the local flooding domain, then it can be shown that the whole flooding is limited to the flooding domain. Therefore, this forwarding condition can be implemented by

allowing each router to flood within only the local flooding domain. Let the addresses of the current c c c c c router and the host router are ( il 1. il 2.. i2. i1. i ) h h h h h and ( il 1. il 2.. i2. i1. i ), respectively. If the current and host routers have a j-th level local c h flooding domain, then i x = ix, x > ( j 1) and, c h i j 1 i j 1. A neighboring router belongs to the same local flooding domain if it is in the same k-level as the current router, where k j. The topological forwarding condition uses modified routing tables to forward Flooding messages to only those routers that are on a path towards the host router. The QoS forwarding condition is based on the forwarding condition proposed in [2] for unicast routing. For additive QoS metrics, the Flooding messages carry the cumulative state metric as they traverse the network. A Flooding message is forwarded along all links that satisfy the forwarding condition except the incoming link. This does not guarantee loop-free flooding. By allowing only one Flooding message for a particular join request, loops can be prevented. For non-additive QoS metrics, this is enforced by allowing only one message to pass through a router per join request. For an additive QoS metric such as delay, this technique may not find an existing feasible path [2]. The problem occurs when a Flooding message with higher path delay arrives at a router before messages with smaller path delay. In this case, the router forwards the message with the higher path delay. This message may fail to satisfy the QoS requirement before arriving at the host router and, hence, the protocol may not find the feasible path. In the context of unicast routing, the problem was solved in [2] by delaying the Flooding message at each router by t, where t = β (node delay) with β = 1. This guarantees that the message with lowest path delay arrives before the messages with higher path delay. However, introducing additional delay at each router increases the connection time for joining a multicast tree. To reduce the connection time while increasing the chances of finding a feasible path, two additional flooding techniques are proposed. Let QoSPath denote the QoS metric of the path followed by the Flooding message up to the current router. Let D be the difference between QoSPath of the current message and that of a previously forwarded message. The current message is forwarded only if D > α 3 QoSReq, where < α 3 < 1. By forwarding subsequent messages that have significantly lower path delay, this method increases the chances of finding a feasible path. Another alternate technique is to combine the above approach with the technique used in [2]. In this case, if D > (α QoSReq), then the message is forwarded after a delay that is less than the node delay, i.e. β < 1. In this case, if D = ( α 4 QoSReq), where α 3 < α4 < 1, then the message is forwarded after a delay that is less than the node delay, i.e. β < 1. All four flooding techniques for delay QoS requirement are summarized in Table 1. The algorithm implementing forwarding conditions and flooding techniques to process the Flooding message is presented in Figure 4. 4.3. Protocol Analysis Message overhead is a very important performance metric flooding-based routing algorithms. For bandwidth requirement and delay requirement with flooding technique-1 and technique-2, the protocol sends at most one Flooding message per link. The total number of Flooding messages is thus bounded by e where, e is the number of links in the flooding domain. Thus, the worst-case message overhead is O(e+l 1 +l 2 ), where l 1 and l 2 are the path length (in terms of hop count) of JoinRequest and Join messages, respectively. For flooding technique-3 and technique-4, the worst-case message overhead per connection request can be expressed as O(N p +e+l 1 +l 2 ), where N p is the total number of links in all possible paths between the ontree routers and the host router within the flooding domain. Table 1: Parameters for specifying different flooding techniques. Tech. α β Comments 1 α 1 = 1 β 1 = Allows one message per link without any extra delay 2 α 2 = 1 β 2 = 1 Allows one message per link with a delay equal to node delay 3 < α 3 β 3 = Allows more than one message per link without any extra delay < 1 4 α 3 < α 4 < 1 β 4 < 1 Allows more than one message per link with delay less than node delay For non-additive QoS requirements such as bandwidth, only one Flooding message is allowed to pass through a router for a particular join request thus preventing any loops. For additive QoS requirements, in technique-1 and technique-2, only one Flooding message for a join request is allowed to pass through a router. When technique-3 and technique-4 are used with additive QoS requirement, second and subsequent Flooding messages are discarded if their path delay is larger than that of the previously forwarded message. The path delay of a message after it has gone through a loop will be higher than

that of the message when it was forwarded for the first time. Therefore, the forwarding condition will prevent a message from passing through the same router more than once. Flooding (multicast, host, PreRouter, QoSIndex, QoSReq, QoSPath) { if ( (QoSIndex = bandwidth) and (F(multicast, host).forwardstatus = FALSE) ) update variables send Flooding message to all neighbors except PreRouter satisfying all three forwarding conditions else if ( (QoSIndex = delay) and (F(multicast, host).qospath QoSPath) > D) update variables send Flooding message to all neighbors except PreRouter satisfying all three forwarding conditions after time t else discard the message end if } Figure 4: Pseudo-code for processing the Flooding message. 5. Simulation Results This section evaluates the performance of QHMRP through simulation under different conditions. The studies are performed in two stages. In the first stage, a network with 56 nodes and 77 links is used in the simulation study [8]. The network is organized hierarchically into domains. A controller is specified for each domain. The bandwidth capabilities of all links in 1-domain are 155 Mbps and all other links are 622 Mbps. The background traffic load on each link is randomly generated from the range [, 155] Mbps for 1-domains and [, 622] for higher domains. The node-delay, i.e., delay for multicast data processing and transmission at each node is randomly generated from [, 2] ms. In this stage, the QHMRP is compared with a flat routing protocol. The flat routing is emulated by placing all the routers in the same domain while maintaining the same topology. Further, the performances of the various flooding strategies are compared under different network conditions. Three performance metrics, success ratio, average message overhead and average connection time are used in the examination. The success ratio is defined as the ratio between the number of new hosts accepted and the total number of join requests. Average message overhead and average connection time are defined as the average number of flooding messages generated and the connection time per join request, respectively. A subset of the results is shown in the graphs in Figure 5 and Figure 6. Each data point in a graph is obtained by averaging over 15 simulation runs. In each run, a random multicast tree with a specified number of nodes (5, 1, 15 or 28) was generated. A host router was randomly selected from the off-tree nodes. The bandwidth and delay QoS requirements are randomly selected from the range [1, 15] Mbps and [4, 6] ms, respectively. From Figure 5 it can be observed that the average message overhead during reverse flooding when delay is the QoS requirement is quite smaller than the estimated worst case message overhead of 77 messages. The advantage of the hierarchical routing in terms of the lower message overhead is due to smaller flooding domains in the hierarchical approach. Similar reduction in message overhead is observed for connections that specify bandwidth requirements. message overhead message overhead 6 4 2 6 4 2 5 node tree Flat Hierarchical 44 45 46 47 48 49 5 avg. delay req. 28 node tree Flat Hierarchical 44 45 46 47 48 49 5 avg. delay req. Figure 5: Message overhead for different delay QoS requirements. The comparison of different flooding techniques shown in Figure 6 uses parameter values: α 3 =.25, α 4 =.5 and β 4 =.5. The success ratios are similar for all techniques. Because technique-3 allows more than one message to pass through a router for a single request it has the highest message overhead. The forwarding delay at each router is

highest for technique-2 resulting in the highest overall connection time. The simulations indicate that technique-4, which is a combination of technique-2 and technique-3, performs the best overall. success ratio (%) 12 1 8 6 4 2 flooding tech.-1 flooding tech.-2 flooding tech.-3 flooding tech.-4 message overhead 6 5 4 3 2 1 connection time (ms) 3 2 1 4 6 8 1 avg. node delay (ms) Figure 6: A comparison of the different flooding approaches. In the second stage, the network topologies are randomly generated using an Internet topology generator called the Tiers [4]. In this stage, the QHMRP was compared with another QoS-based routing algorithm called the QoSMIC [5]. In the QoSMIC algorithm, the multicast tree search procedure uses the centralized candidate selection process. The manager is assumed to have sufficient global knowledge so that the manager can directly select the candidate nodes. This assumption is known to give QoSMIC the best performance. Further, the time-to-live was set to two. For QHMRP, all three forwarding conditions were implemented, i.e., a probe is forwarded only when all three conditions are satisfied. The flooding technique is set to technique- 3. This technique prevents probes from going in loops. Figure 7(a), Figure 7(b), and Figure 8(a) compare the QHMRP with QoSMIC for a bandwidth requirement of 1mbps. The above graphs indicate that the connection time for QHMRP is significantly lower than the connection time for QoSMIC. This may be due to the aggregation of the state information. The JoinRequest message can reach a candidate on-tree faster in the QHMRP. The success ratio on the other hand is slightly better for the QoSMIC when the bandwidth requirement in 1mbps. The success ratio increases as the network size increases for both algorithms. This is due to the increased level of connectivity that is present in the larger network. As the connectivity increases, multiple candidate paths will be available to connect any two given points in the network. Figure 8(b), Figure 9(a), and Figure 9(b) compare the QHMRP with QoSMIC for a delay requirement of 5 ms. The results are same as in the experiments with bandwidth requirements. Only exception is the success ratio which decreases with increasing network size. This is due to the fact that the number of paths with a given delay bound decreases as the network size increases.

Connection time (msec) 7 6 5 4 3 2 1 QoSMIC QHMRP 2 4 6 8 1 12 reduced by more than a factor of two by using the hierarchical strategy. These comparisons, however, do not use the topology forwarding condition, i.e., only the hierarchical and QoS-based forwarding conditions are used. Further, several approaches for reducing the flooding message overhead are examined. A hybrid scheme proposed here is shown to outperform the various existing techniques. The simulations performed to compare the QHMRP with QoSMIC indicate that the QHMRP is capable of achieving similar success ratios as the other algorithm while incurring significantly less message overhead. Further, the connection time of the QHMRP is much smaller than the QoSMIC. (a) Success ratio (%) 1..8 QoSMIC QHMRP.6.4.2. 2 4 6 8 1 12 (b) Message overhead 24 2 QoSMIC QHMRP 16 12 8 4 2 4 6 8 1 12 (a) Figure 7: The comparison of QoSMIC and QHMRP using (a) connection time and (b) success ratio for a bandwidth requirement of 1mbps. 6. Conclusions This paper proposes a new QoS-aware hierarchical protocol for multicast routing in large IP networks. The proposed protocol is simple, and builds scalable, efficient, robust, and loop-free multicast trees. Scalability comes from the hierarchical structure and topology aggregation. Efficiency is achieved by forwarding conditions that use different strategies to prune the flooding messages. Because messages are flooded along all feasible paths, the protocol is robust against link failure in the network. The simulation studies that compare the various versions of the QHMRP and the generic flat routing protocol indicates that the message overhead is Connection time (msec) 7 6 5 4 3 2 1 QoSMIC 2 4 6 8 1 12 (b) QHMRP Figure 8: The comparison of QoSMIC and QHMRP using (a) message overhead for a bandwidth requirement of 1mbps and (b) connection time for a delay requirement 5 ms.

Message overhead Success ratio (%) 1..8.6.4.2 QoSMIC QHMRP. 2 4 6 8 1 12 (a) 2 QoSMIC QHMRP 16 12 8 4 2 4 6 8 1 12 [3] S. Chen, K. Nahrstedt, and Y. Shavitt, A QoS-Aware Multicast Routing Protocol, to appear in Proceedings of IEEE INFOCOM', Tel-Aviv, Israel, March 26-3, 2. [4] M. B. Doar, A Better Model for Generating Test Networks, Proceedings of IEEE Global Internet, Nov. 1996. [5] M. Faloutsos, A. Banerjea, and R. Pankaj, QoSMIC: Quality of Service sensitive Multicast Internet protocol, ACM SIGCOMM 98, Vancouver, Canada, September 1998. [6] R. Guerin and A. Orda, QoS-based Routing in Networks with Inaccurate Information: Theory and Algorithms, Proceedings of the IEEE INFOCOM 97, April 1997, Kobe, Japan. [7] M. Handley, and V. Jacobson, SDP: Session Directory Protocol (draft 2.1), Internet Draft - Work in Progress, February 1996. [8] F. Hao and E. W. Zegura, On Scalable QoS Routing: Performance Evaluation of Topology Aggregation, Technical Report GIT-CC-99-4, College of Computing, Georgia Tech, 1999. [9] W. C. Lee, Spanning Tree Method for Link State Aggregation in Large Communication Networks, Proceeding of the IEEE INFOCOM 95 Vol. 1, 1995, pp. 297-32. [1] M. Montgomery, and G. de Veciana, Hierarchical Source Routing Through Clouds, Proceedings of the IEEE INFOCOM 98, San Francisco, CA, 1998, pp. 685-692. [11] S. Pradhan, QoS-Aware Hierarchical Multicast Routing on Next Generation Internetworks, M.Sc. Thesis, Department of Computer Science, University of Manitoba, Winnipeg, Canada, 2. (b) Figure 9: The comparison of QoSMIC and QHMRP using (a) success ratio and (b) message overhead for a delay requirement of 5 ms. In summary, this paper introduces a new hierarchical QoS-based multicasting algorithm. Simulation studies are performed to analyze the performance of the algorithm under different conditions and to compare it with an existing QoSbased multicasting algorithm. The results indicate that the new algorithm can deliver the similar connection efficiency as the existing algorithm with a significantly lower overhead. References [1] J. Behrens, and Garcia-Luna-Aceves, Hierarchical Routing Using Link Vectors, Proceedings of the IEEE INFOCOM 98, San Francisco, CA, 1998. [2] S. Chen and K. Nahrstedt, Distributed Quality-of- Service Routing in High-Speed Networks Based on Selective Probing, Proceedings of the Conference on Local Networks 98 (LCN 98).