Hierarchically Distributed PCE for Flexible Multicast Traffic Engineering

Transcription

1 Hierarchically Distributed PCE for Flexible Multicast Traffic Engineering Hiroshi Matsuura, Naotaka Morita, Isami Nakajima NTT Service Integration Laboratories Midori-Cho, Musashino-Shi, Tokyo , Japan {matsuura.hiroshi, morita.naotaka, Kazumasa Takami Faculty of Engineering Soka University Tangi-cho, Hachioji-city, Tokyo , Japan Abstract The IPTV service, in which high-capacity content is broadcast from the IPTV server to a huge number of users, is becoming very popular. To establish an effective IPTV network, we need to minimize the cost of the IPTV multicast tree. That tree consists of a node, to which an IPTV server is connected, as the root node and other nodes, to which users are connected. In addition, we have to consider users who belong to multiple network domains. In this paper, we apply hierarchically distributed path computation elements (HDPCEs) to cooperatively create appropriate IPTV trees for multidomain users. Each HDPCE shares the burden of creating a multidomain multicast tree. Thus, we can reduce the computational burdens of creating a multicast tree. In addition, we enable choosing three different algorithms to create the cheapest multicast trees in individual domains. One of them is a new multiplex-aware-routeselection () algorithm. We evaluated the applicability of the three algorithms to various types of domains depending on network conditions. Keywords- multicast; traffic engineering; PCE; IPTV I. INTRODUCTION Recently, multicast services such as the IPTV service have become more popular than ever because of broadband networks, and requirements for the IPTV service are now being standardized [1]. Multicast traffic engineering (TE) [3] on the Generalized Multiprotocol Label Switching (GMPLS) [2] network is the key technology to assure end-to-end QoS such as required bandwidth for an IPTV multicast. The path computation element protocol (PCEP) [4] is now being introduced between the path computation element (PCE), which determines the traffic engineering routes, and the GMPLS router. The PCE requirement for multicast TE [5] was also presented. We presented hierarchically distributed PCEs (HDPCEs) [6] [7] that are distributed to their corresponding domains, and those HDPCEs respond with a required point-to-point route for each route request. One feature of an HDPCE is updating the intra- and inter-domain point-to-point routes in each domain and setting them in its route list. Therefore, when an HDPCE receives a route request with some constraints such as required bandwidth, it quickly returns the appropriate route satisfying the constraints. In addition, the route-selection algorithm in each HDPCE is independent from those of other HDPCEs. Thus, each HDPCE can choose a route-selection algorithm on the basis of the domain features and traffic situation in the domain. In this study, we apply the HDPCEs to a bandwidthassured static multicast tree within the IPTV service. One feature of an IPTV network is that we have to set up routes in the content-flow direction. Therefore, we have to minimize the tree cost from the root of the tree to other nodes. We applied three tree-creation algorithms that are used in each HDPCE. One of them uses the shortest path between the root node and one of the destination nodes. That is the shortest path tree () algorithm. Once we use this algorithm, we can use an HDPCE route list to determine the route of each multicast branch. The route list is obtained by running the shortest path first (SPF) algorithms: either Dijkstra s SPF [8] in the underlying domain or the interdomain SPF [6] in the interdomain. The tree created on the basis of these shortest paths is called the. The second algorithm we adopt is the destination-driven multicast () algorithm [9]. was originally used for the intradomain multicast tree that consists of undirected links. However, we expand the capability of the algorithm to deal with multidomain multicasts that consist of directed links. The reason for applying the algorithm is that using the algorithm reduces the tree cost compared with using the. At the same time, the algorithm has relatively lower computational complexity compared with other Steinerminimum-tree heuristic algorithms [9]. The third algorithm was developed by the authors, and we call it the multiplexaware-route-selection () heuristic algorithm. uses the point-to-point route list in each HDPCE to create the optimal multicast tree. However, in a different manner from that of the, during the process of creating the tree, all the multiplexed sections among multicast branches are considered. Therefore, accurate branch costs are compared by considering these multiplexed sections to determine the shortest branch. We compare these three algorithms by applying them to various types of domains and network traffic conditions and analyze the applicability of these algorithms to actual networks. II. RELATED WORK There are various Steiner-tree heuristic algorithms [10] [11] [12] that create minimum-cost multicast trees in a network. However, they target undirected links and do not target directed links. The multicast routing method, which 2439

2 emphasizes the balanced link utilization of a multicast tree with directed links, is presented in [13], but the method does not deal with minimizing the tree cost nor with the multidomain environment. The Border Gateway Multicast Protocol (BGMP) [14] and Decentralized-Core-based Tree (DCBT) [15], which are used for multidomain multicasts, are extensions of a corebased tree (CBT) [16]. However, they are not supposed to be utilized to find the cheapest multicast tree for traffic engineering purposes. The Multicast Source Discovery Protocol (MSDP) [17] was proposed to find multicast routers in multiple domains. However, the protocol that is used for the route selection between domains is based on the hop number between the domains, and link costs and bandwidth between domains are not considered. III. HDPCE-BASED MULTICAST ARCHITECTURE HDPCEs are distributed to corresponding GMPLS domains in a hierarchical manner, as shown in Fig. 1. Each HDPCE deals with route setup requests from the routers in the domain. In Fig. 1, the route-setup request for creating a multicast tree, which starts from root node R11 and ends at destinations R13, R22, and R23, is shown as an example. We explain this procedure by using steps (1) - (5) in the figure. (1) R11 sends the route-setup request to HDPCE 1 by a PCEP [4] [5] request. (2) HDPCE 1, which recognizes the destination routers are not confined within D_1, thus asks the interdomain HDPCE to determine the multicast tree among underlying domains. Interdomain HDPCE determines the multicast tree by using its route list [6], which holds point-to-point route information in the interdomain, and by using a multicast tree creation algorithm. (3) After the determination of edge routers for the multicast tree in underlying domains, the interdomain HDPCE asks the underlying HDPCEs to determine the underlying subtrees in individual domains by specifying the edge, source, and end routers. Control plane Underlying domains HDPCE 1 Data plane Interdomain (1) (5) (2) (4) R11 (root) D_1 ER11 R12 ER12 (3) Interdomain HDPCE HDPCE 2 Interdomain CR1 CR2 ER21 R: router, ER: edge router, D_2 R21 (end) CR: core router R22 R23 end : multicast tree : links (1): route request (source R11 - ends R13, R22, R23), (2): route request (R11-R13,R22,R23) (3): route requests/responses between interdomain HDPCE and underlying HDPCEs (To HDPCE 1: R11-ER11,ER12, To HDPCE 2 ER21-R22,R23, To HDPCE 3: ER31-R13) (4), (5): route request responses (R11-R13, R22, R23) (3) Fig.1. Multicast routing by HDPCEs. (3) ER31 D_3 ER32 HDPCE 3 R13 end (4) After receiving all the responses from underlying HDPCEs, the interdomain HDPCE concatenates all the subtrees into a multicast tree, creates an explicit route object (ERO) [3] for the tree, and returns the ERO to the HDPCE 1. (5) HDPCE 1 forwards the response by a PCEP reply message. R11 sets up the explicit routes from R11 to destination routers by using RSVP-TE [3] messages. An interdomain HDPCE manages only the interdomain among underlying domains without knowing information in each underlying domain. HDPCEs are hierarchically distributed, so each underlying HDPCE manages only its corresponding domain. Therefore, the burden for creating multicast trees is shared by the interdomain HDPCE and underlying HDPCEs. In addition, the number of hierarchies and number of HDPCEs are not restricted. Thus, flexible HDPCE deployment is possible depending on the policies of the HDPCE operator. Moreover, the multicast tree creation algorithm in one domain is independent and hidden from other domains. Therefore, an appropriate algorithm depending on the domain s characteristics is achieved. Though this paper focuses on the control of multicast trees, route information in each HDPCE can be used for the configuration and fault management of multicast trees. IV. MULTICAST TREE ALGORITHMS APPLIED IN HDPCES We enable the application of three multicast tree algorithms in one HDPCE. The first is the algorithm, the second is the algorithm, and the third is the new algorithm. We show these algorithms and their computational complexities as follows. A. algorithm Once we apply the algorithm, we can use the route list in each HDPCE. In the route list, the shortest point-to-point route and other short routes between any two nodes, which are directly underlying domains or routers, are stored. In addition, each route has information about its cost and component links. For example, in Fig. 1, an interdomain HDPCE has routes between any two underlying domains, between any two underlying core routers, and between a core router and an underlying domain. In addition, the route list holds information about the route direction. Therefore, the cost of the route in one direction may be different from the cost of the route in the opposite direction. These route lists are periodically updated by the interdomain SPF algorithm in the interdomain HDPCE and by Dijkstra s SPF in an underlying HDPCE as a background process of each HDPCE. The computational complexity f(n, N) of the algorithm is f ( n, N ) = O( nn ), (1) where n is the number of nodes in the domain and N is the number of multicast destinations in the domain. This is because in a route list there are route groups that are demarcated by the source nodes, and in one route group there are less than cn routes, where c is a constant. The algorithm uses a route list N times to determine the N multicast branches. 2440

3 Initial conditions Step 1 Select all directed links that start from Vs and do not end at nodes that belong to F. Add the links to the leg selected in Step 2 and add the new created legs to PQ. End of algorithm Vs vertex node (initially root node (domain or router), otherwise it is the end node of selected branch), E = {destination nodes of multicast that are not selected}, F = {source node}: holds nodes which are targeted, PQ = : holds branch candidates, R = : holds selected branches Step 2: Select the cheapest branch from the PQ. Select the end node of the branch as Vs, and add Vs to F. Step 3: Vs E Step 4: Add the leg to R, and set the branch cost in PQ to 0. Remove Vs from E. Step 5: E = Fig. 2. algorithm flow in HDPCE. B. algorithm We applied the algorithm because it has a small amount of computer complexity compared with other Steiner tree algorithms [9]. The algorithm was originally proposed as an improvement on the Prim [18] algorithm and is not applicable to a network that consists of directed links. We apply the algorithm to a domain that has directed links and to multidomain situations. The initial conditions used for running the algorithm and the algorithm flowchart that runs in an HDPCE are shown in Fig. 2. There are a vertex node in spanning tree (Vs) and four defined groups, which are E, F, PQ, and R. Vs indicates the root node of the multicast tree at the beginning of the algorithm and later the Vs indicates the end node of the selected branch in Step 2. The E group consists of unselected destination nodes. The F group consists of targeted nodes in the algorithm, and initially, only the root node belongs to F. The PQ group holds multicast branch candidates. The R group consists of selected multicast branches. Once an HDPCE wants to assure the required bandwidth, only the links that satisfy the required bandwidth are selected in Step 1. The difference between the original and the algorithm in the HDPCE is that the algorithm in the HDPCE deals with directed links, which start from Vs, in Step 1. In addition, the interdomain HDPCE deals with an underlying domain as a Vs. The interdomain HDPCE has the link lists that start from each domain. Therefore, an HDPCE could select links that start from every Vs in Step 1. As shown in Step 4, once a branch reaches one of the multicast destinations, the cost of the branch is set to 0, so branches that have passed through the destination are more likely to be chosen in Step 2. The computational complexity g(n,l) of the algorithm is g ( l, n) = O( l log( n)), (2) where l is the number of links in the domain and n is the number of nodes in the domain. This is because our expansion Vs vertex node (initially root node (domain or router), Initial otherwise it is end node of the shortest branch), conditions : E = {end nodes of multicast that are not selected}, PQ= : holds leg candidates, T= holds nodes that are on the selected branches, R= : holds selected branches Step 1 Remove Vs from E. Add all nodes on the shortest branch except source node to T. Vs is also added to T. End of Step 2: E = algorithm Step 3: Select all shortest branches from each node in T to each node in E, and add them to PQ. As a condition, each shortest branch has to satisfy the required bandwidth. After that remove all the nodes from T. Step 4: Exception PQ = (no required bandwidth) Step 5: Remove the shortest branch in PQ and add it to R. Step 6: If a leg in PQ has the same subroute from the source node to the middle of the branch as that on the shortest branch, the end node of the subroute is set as the source node of the branch. (*1) (*1) If there are branches that have the same end nodes as the shortest branch, they are removed from PQ. Fig. 3. algorithm flow in HDPCE. of the algorithm does not increase the computational complexity of the original algorithm. As shown in g(l,n), the computational complexity of the algorithm is not affected by the number of multicast destinations. At the same time, the up-to-date link cost is always taken into consideration, which is not necessarily considered by the and algorithms, because the route list in an HDPCE is updated within a certain interval. C. algorithm We developed the algorithm to maximize the effect of using the route list in each HDPCE. The route cost and route components are included in a route list. Thus, identifying the multiplexed sections among multicast branches is possible. The initial conditions and flowchart of, which runs in an HDPCE, are shown in Fig. 3. There are a vertex node Vs and four defined groups, which are E, PQ, T, and R, for the algorithm. Vs indicates the root node of the multicast tree at the beginning of the algorithm and later the Vs indicates the end node of the shortest branch selected in Step 5. The E group consists of unselected destination nodes. The PQ group consists of multicast branch candidates. The T group consists of nodes on the shortest branch except for the source node. The R group consists of selected multicast branches. In Step 1, the HDPCE selects the Vs and adds nodes on the shortest branch to group T. At the beginning of the algorithm, there is no shortest path, which should be selected in Step 5. Therefore, only Vs is added to T in Step 1. In Step 2, an HDPCE judges if all the multicast destinations are targeted within the algorithm by checking the destination nodes in group E, where the unselected destination nodes are stored. If there are no members left in E, the algorithm ends. In Step 3, from the Vs and from other nodes on the shortest branch selected in Step 5, the HDPCE obtains the shortest route to the multicast destinations. Therefore, all possible routes to the destinations from the shortest branch are added to PQ as candidate branches. However, only routes that satisfy 2441

4 the bandwidth requirement are chosen. Therefore, there is a possibility that there are no branches remaining in PQ even though there are still undetermined multicast branches. This case is judged in Step 4, and if there are no branches left in PQ, the HDPCE sends a no-bandwidth exception. In Step 5, the HDPCE selects the cheapest branch in PQ, removes it from PQ, and adds it to R. In Step 6, the HDPCE resets the branch whose subroute from its source node is the same as the route of the shortest branch. In this case, the HDPCE selects the end node of the subroute and sets the end node as the source node of the branch. After that, the HDPCE searches the route list for the shortest route that has the new source node and original destination node and sets the shortest route to PQ as the revised candidate branch. In Step 6, in the process of determining the revised branch, if the HDPCE finds the branches that have the same destination as that of the shortest branch, the HDPCE deletes them to reduce the number of members of PQ. In this manner, by using the algorithm, an HDPCE can create multicast branches among which there are no multiplexed sections. Therefore, there is no need to find the multiplexed sections among the branches after running, which is required if the HDPCE chooses the or algorithm. The computational complexity h(n,n) of the algorithm is 2 h ( n, N ) = O( nn log( n)), (3) where n is the number of nodes in the domain, and N is the number of multicast destinations in the domain. In Step 3, there are supposed to be less than log(n) nodes in T because a router is supposed to have at least two router outputs when one data stream comes from a router input. The number of destinations targeted in Step 3 is less than N. When the HDPCE selects the shortest branches from the route list, computer complexity O(n) is needed, as we discussed for the algorithm. Therefore, the computer complexity of Step 3 is O(nNlog(n)). The computer complexity of Step 5 is O(log(nN)) because there are at most nn branch candidates in PQ, and PQ is sorted by a heap sort. The computer complexity for Step 6 is O(nN) because there are at most nn branch candidates in PQ. Therefore, the computer complexity of one loop of the algorithm is O(nNlog(n)+log(nN)+nN). However, log(nn) and nn can be deleted because nnlog(n) is the dominant element to determine the computer complexity. This loop is repeated N times. Thus, the computer complexity for the algorithm is O(nN 2 log(n)). According to this analysis, we can estimate that once the number of destinations becomes bigger, the algorithm suffers a relatively larger burden in multicast route selection. V. EVALUATION OF THREE ALGORITHMS In this section, we evaluate the tree cost and processing time of each of the three algorithms, and speculate on the applicability of each algorithm to the various types of domains. Throughout this evaluation, we used the network shown in Fig. 4. We adopted Abilene [19] network routers: PEs and Ps, in the network provider domain D21. CE1 C1 D11 CE2 D12 C4 CE5 CE6 PE1 PE2 PE3 AP1 P1 AP3 D21 AP2 P2 P3 AP4 Fig. 4. Network used for evaluation. To make the network multidomain, we connected four customer domains, D11-D14, to D21. In customer domains, there are customer routers Cs and CEs. In addition, in expecting the number of IPTV users to increase, we set up additional routers, APs, in the provider domain. We evaluated two cases: one of them is when an IPTV server is adjacent to router C1 in customer domain D11; the other is when an IPTV server is adjacent to central router P2 in the provider domain. The customer domains are not so complex compared with the provider domain, so route selection in the provider network is the key to lowering the cost of multicast trees. In both cases, we applied the same algorithms to these five domains. That is, once we apply the algorithm in the provider domain, the algorithm is applied to the other four customer domains. The interdomain HDPCE is applied to the provider domain, and four HDPCEs are applied to the corresponding four customer domains. However, to eliminate the communication overhead, which could affect the processing time, we allocate the five HDPCEs in one computer and evaluate the processing time for creating the multidomain multicast trees. A. Evaluation when IPTV server is in customer domain In this evaluation, an IPTV server is supposed to be connected to C1, and two cases of multicast destination patterns are evaluated. In one case, there are three destinations: C2, C4, and C5, and in the other case, there are seven destinations: C3, C4, CE8, PE3, PE4, P2, and P3. To evaluate various types of directed-link cost patterns, we randomly allocate the remaining directed-link bandwidth between any two different routers in the network from 10 to 100 Mbps in 10-Mbps intervals. Link costs are determined by the least-loaded (LL) algorithm [20] and take values of the inverse of remaining bandwidth on the links. We evaluate the tree costs and processing time calculated by each of the three algorithms for creating the tree. To evaluate the various types of link patterns, we conduct five trials randomly changing the bidirectional link costs, and we compare the sum of the multicast tree costs and processing time among the three algorithms. The sum of tree costs obtained by applying the three algorithms in five trials is shown in Fig. 5(1). In the three-destination case, the algorithm has about a 5% lower tree cost compared with the other two algorithms. The algorithm has difficulty in multiplexing the multicast branches, namely D11-D13 and D11-D14, because in the interdomain HDPCE, the algorithm does not reset the P5 P4 AP5 P6 AP6 PE4 PE5 CE3 C2 CE4 D13 CE7 C3 C5 CE8 D14 C: router in customer domain, CE: customer edge router, PE: provider edge router, P: router in provider interdomain, AP: added router to Abilene network in interdomain 2442

5 branch cost to 0, as explained in Step 4 in Fig. 2, until the algorithm reaches nodes D13 or D14. Therefore, the probability of considering the multiplex sections among them is small. Even if the algorithm reaches D13 or D14, PE4 and PE5 are highly likely to be targeted already. These nodes have been added to F in Step 2, as shown in Fig. 2. Therefore, D11-D13 and D11-D14 are rarely multiplexed. Even compared to the algorithm, the algorithm is ineffective for choosing the branches. There is one case in which the algorithm chooses D11-PE5 as the multiplexed section shared by D11-D13 and D11-D1 branches. In that case, the algorithm has the same section, D11-PE5, as the algorithm. However, when the algorithm reaches D14, the cost of branch D11-D14 is initialized to 0. Therefore, the D14-PE4-D13 route is chosen instead of the PE5-C1E4 route even though the cost of PE5-C1E4 is much smaller than D14-PE4-D13. The algorithm considers all the multiplex sections by adding all transit nodes on the shortest branch to T in Step 1 and by resetting source nodes in PQ in Step 6, as shown in Fig. 3. Therefore, the multicast tree, where all multiplexed sections are considered, is created. Thus, the tree cost calculated by the algorithm becomes the smallest among the three algorithms. In the seven-destination case, the algorithm has about a 17% lower tree cost compared to that of the algorithm and about a 10% lower tree cost compared to that of the algorithm. In addition, has almost the same cost as that in the three-destination case because of its effective multiplexing among seven branches. The algorithm considers the multiplex sections in the provider domain because there are two PEs and two Ps in D21 where the branch candidate cost becomes 0. Therefore, a 7% lower tree cost is achieved compared with that of the algorithm. The comparison of processing times of the three algorithms is shown in Fig. 5(2). Once there are three destinations, the and algorithms take only about 40% of the processing time of that of the algorithm. This is because the computational complexities of the and algorithms depend on the number of destinations N. However, the computational complexity of the algorithm depends on the scale of the domain and does not depend on N. Therefore, once N = 7, the algorithm processing time becomes shorter than that of the algorithm. When N = 3, the processing time of the algorithm is a little bit shorter than that of. We speculate this is due to the burden of the algorithm in finding the multiplex section among the branches. In particular, when there are underlying domains, the algorithm takes more time to find the multiplexed sections because detailed multiplexed sections are not found until underlying HDPCEs return the results. B. Evaluation when IPTV server is in center of provider domain In this evaluation, an IPTV server is supposed to be connected to P2, and two cases of multicast destination patterns are evaluated. In one case, there are five PE destinations, and in the other case, there are ten destinations: five PEs and Ps except for P2. As explained in the previous evaluation, bidirectional link costs are set at random in each of five trials, and we compare the sum of the tree costs and processing time of the five trials. The comparison of tree costs calculated by the three algorithms is shown in Fig. 6(1). The and algorithms have about a 20% smaller tree cost than the algorithm in the ten-destination case and a 15% smaller tree cost in the five-destination case. Compared with the last evaluation, the algorithm enables considering more multiplexed sections because from the P2 to destination routers there is only a small number of routers. In the case of ten destinations, there is one trial where the algorithm slightly outperforms the algorithm. That demonstrates that even though the algorithm considers all the multiplexed sections among the multicast branches, the restriction to choose the point-to-point shortest branch as the multicast branch may prevent choosing the best branch for the multicast tree. The comparison of processing times of the three algorithms is shown in Fig. 6(2). In the case of five destinations, the algorithm outperforms the algorithm, but in the case of ten destinations, the algorithm takes almost a three-fold-longer processing time than that of the algorithm. This is because, as shown in formula (3), in the algorithm, the number of destinations N affects the processing time by the order of N 2, whereas the processing time of the algorithm is not affected by N. 7 destinations 3 destinations Tree cost normalized by with 3 destinations (1) Tree cost comparison Processing time (normalized to with 3 destinations) (2) Processing time comparison Fig. 5. Evaluation result when server is in customer domain Tree cost (normalized by with 5 desttinations) (1) Tree cost comparison 10 destinations 5 destinations Fig. 6. Evaluation result when server is in center of provider domain. 7 destinations 3 destinations 10 destinations 5 destinations Processing time (normalized by with 5 destinations) (2) Processing time comparison 2443

6 C. Speculation of applicability of each algorithm Each algorithm has pros and cons. Thus, we have to choose the best algorithm depending on the requirements of IPTV and traffic and network characteristics in each domain. Even in one domain, we can change the applied algorithms depending on conditions such as the number of multicast destinations N. The algorithm is useful for IPTV content that requires the minimum routing delay. In addition, the algorithm is essential for the underlying domain that has to create two or more subtrees at the same time. This case sometimes happens when there are two or more edge routers in an underlying domain. An interdomain HDPCE might choose two different multicast branches that reach the different edge routers in the domain. In that situation, only the algorithm can handle the subtree creation in the domain. The algorithm is most effective for the domain where IPTV servers are connected to the central routers of the domain and there are not so many nodes and links. The algorithm is also effective for domains where the corresponding HDPCE seldom updates its route list because the algorithm does not use the route list and can always update the up-to-date bidirectional link cost in the algorithm. The algorithm should be applied to any domains where the smallest tree costs are required because it can create the cheapest tree irrespective of the domain topologies and locations of IPTV servers. However, once the number of destinations N is large, the processing time deteriorates rapidly compared with the other two algorithms. Therefore, as one of the options, changing from the to the algorithm once the N exceeds some number may be effective. VI. CONCLUSION We presented the application of HDPCE to multicast traffic engineering. The HDPCE enables calculating the multicast tree considering directed link costs in the multidomain environment. The HDPCE also enables flexibly changing the multicast tree creation algorithm depending on the domain characteristics and number of multicast destinations. We applied three algorithms to the multicast tree creation:,, and algorithms. In particular, the algorithm is a new algorithm that maximizes the effect of the route list, which is prepared in the HDPCE beforehand, and creates a multicast tree considering all the multiplexed sections. We evaluated the three algorithms in various domain conditions. The result was that the algorithm creates the cheapest multicast tree among the three algorithms irrespective of the domain conditions. However, the performance deteriorates once the multicast tree has many destinations. REFERENCES [1] Focus Group On IPTV, Working Document: IPTV Services Requirements, ITU-T FG IPTV-DOC-0060, [2] A. Bonerjee, J. Drake, J. P. Lang, and B. Turner, Generalized multiprotocol label switching: an overview of routing and management enhancements, IEEE Commun. Mag., vol. 39, no. 1, pp , Jan [3] R. Aggarwal, D. Papademitriou, and S. Yasukawa, Extensions to RSVP- TE for Point to Multipoint TE LSPs, IETF Internet Draft, draft-ietfmpls-rsvp-te-p2mp-03, (work in progress). [4] J. P. Vasseur, J. L. Roux, A. Ayyangar, E. Oki, A. Atlas, and A. Dolganow, Path Computation Element (PCE) communication Protocol (PCEP) Version 1, IETF Internet Draft, draft-vasseur-pce-pcep-02.txt, Sep. 2005, (work in progress). [5] S. Yasukawa and A. Farrel, PCC-PCE Communication Requirements for Point to Multipoint Traffic Engineering, IETF Internet Draft, draftyasukawa-pec-p2mp-req-00.tet, Feb. 2006, (work in progress). [6] H. Matsuura, N. Morita, T. Murakami, and K. Takami, Hierarchically Distributed PCE for GMPLS Multilayered Networks, IEEE Globecom 2005, St. Louis, Missouri, USA, Nov [7] H. Matsuura and K. Takami, GMPLS-Based VPN Service to Realize End-to-End QoS and Resilient Paths, APMS 2006 Proceedings, LNCE 4238, pp , Sep [8] E. W. Dijkstra, A Note on Two Problems in Connexion with Graphs, Numerische Mathemakik, 1, pp , [9] A. Shaikh and K. Shin, Destination-driven routing for low-cost multicast, IEEE Journal on Selected Areas in Communications, vol. 15, No 3, April [10] L. Kou, G. Markowsky, and L. Berman, A Fast Algorithm for Steiner Trees, Acta Informatica, Springer-Verlag, 1981: vol. 15, pp [11] H. Takahashi and A. Matsuyama, An approximate solution for the Steiner problem in graphs, Math. Japonica, pp , [12] T. Alrabiah and T. F. Znati, A Simulation framework for the analysis of multicast tree algorithms, IEEE Simulation Symposium, pp , April [13] Y. Seok, Y. Lee, Y. Choi, and C. Kim, Explicit Multicast Routing Algorithms for Constrained Traffic Engineering, Proceedings of the 7 th ISCC, pp , July [14] D. Thaler, Border Gateway Multicast Protocol (BGMP): Protocol Specification, IETF Internet Draft, draft-ietf-bgmp-spec-06.txt, Jan. 2004, (work in progress). [15] W. Kim and Y. Park, DCBT: an efficient multicast architecture for wide scale and large group multimedia communications, IEEE ICC, vol. 1, pp , June [16] T. Ballardie, Core Based Trees (CBT version 2) Multicast Routing: Protocol Specification, RFC2189, Sep [17] B. Fenner and D. Meyer, Multicast Source Discovery protocol (MSDP), RFC3618, Oct [18] R. C. Prim, Shortest connection networks and some generalization, Bell Sys. Tech. J., vol. 1, pp , [19] [20] Q. Ma and P. Steenkiste, On Path Selection for Traffic with Bandwidth Guarantees, In Proceedings of IEEE International Conference on Network Protocols, Oct