Zappala, D., Braden, R., Estrin, D., and S. Shenker, Interdomain Multicast Routing Support for Integrated Services Networks: A White Paper. December 1996. 13  Home/Search   Document Details and Download   Summary   Related Articles   Check

....Our architecture also allows the processing of requests to be done locally by allowing an application to request the computation of a local path or alternate path. In this case, the local multicast routing manager invokes a route computation algorithm that locally updates the multicast tree as in [13]. Again, the local multicast routing manager can ask the application to adapt if only a lower QoS can be granted. An important feature of our architecture is stability. Instabilities could result if join and QoS requests are honored without accounting for the QoS requirements of already existing ....

D. Zappala, B. Braden, D. Estrin, and S. Shenker. Interdomain Multicast Routing Support for Integrated Services Networks. Internet Draft, March 1997.

....this pinning even when they adapt, unless a request for unpinning is later received. A dissatisfied application may also request the computation of an alternate path. In this case, the multicast routing manager invokes a route computation algorithm that locally updates the multicast tree as in [22]. 6.2 Switching between Multicast Trees Algorithms Our architecture supports multiple (parameterized) multicast routing protocols. This allows a multicast routing manager to flexibly switch to a different multicast tree(s) This switching requires coordination between multicast managers, and a ....

....and periodically recomputes the tree to restore its near optimality. The architecture does not address the need for multiple multicast algorithms or issues related to major characteristics and requirements of CSCW environments (for example, clustering, QoS requirements) Zappala et al. in [22] propose an architecture where the multicast tree is locally updated in response to a receiver initiated request. This local route computation is readily supported in our architecture. Compared to [22] our architecture is more general and addresses CSCW characteristics and requirements such as ....

[Article contains additional citation context not shown here]

D. Zappala, B. Braden, D. Estrin, and S. Shenker. Interdomain Multicast Routing Support for Integrated Services Networks. Internet Draft, March 1997.

....Our architecture also allows the processing of requests to be done locally by allowing an application to request the computation of a local path or alternate path. In this case, the local multicast routing manager invokes a route computation algorithm that locally updates the multicast tree as in [13]. Again, the local multicast routing manager can ask the application to adapt if only a lower QoS can be granted. An important feature of our architecture is stability. Instabilities could result if join and QoS requests are honored without accounting for the QoS requirements of already existing ....

D. Zappala, B. Braden, D. Estrin, and S. Shenker. Interdomain Multicast Routing Support for Integrated Services Networks. Internet Draft, March 1997.

....router QoS managers. A request coming from a router QoS manager can be the result of an application entity requesting the computation of a local path or alternate path. In this case, the multicast routing manager invokes a route computation algorithm that locally updates the multicast tree as in [16]. 6.1 Switching Multicast Tree Algorithm Our architecture supports multiple (parameterized) multicast routing protocols. This allows a group s router agent, which is responsible for processing all requests (e.g. for QoS change) made by members of its group, to flexibly initiate the switching to ....

D. Zappala, B. Braden, D. Estrin, and S. Shenker. Interdomain Multicast Routing Support for Integrated Services Networks. Internet Draft, March 1997.

....but its performance is yet to be evaluated. The above protocols take a soft state approach, in which the unicast routing determines the current multicast routing. While soft state approaches are robust during failures, they could potentially cause service disruption to QoS sensitive applications[16]. CBT[17] is an ST approach based on hard state routing in which the route does not change as long as there are no failures. OCBT[18] suggests modifications to make CBT loop free. OCBT and another approach called CGBT[19] introduce a hierarchy of cores into CBT. The work in [20] maps the CBT ....

D. Zappala, B. Braden, D. Estrin, and S. Shenkar. Interdomain Multicast Routing Support for Integrated Services Networks. Technical report, University of Southern California, November 1996.

....reservations must be coupled to provide the desired service. Our investigation of this coupling has led to the design of a number of specific services that routing must provide to resource reservation; these include route lookup, route change notification, route pinning, and alternate path joining [Zappala96]. The first two of these services require only very minor implementation extensions to existing routing protocols. However, the last two require significant routing extensions; they fall into the functional category that is called quality of service (QoS) routing. The approach that we have been ....

....However, the last two require significant routing extensions; they fall into the functional category that is called quality of service (QoS) routing. The approach that we have been developing for QoS routing services to support RSVP involves establishing soft routing state in switching nodes [Zappala96]. The (routing) protocol to create and manage this soft state is another signaling protocol. Economy of mechanism as well as packet efficiency would design a unified state setup protocol that handles both reservations and this routing state. Designing and building a prototype of such a unified ....

Zappala, D., Braden, R., Estrin, D., and S. Shenker, Interdomain Multicast Routing Support for Integrated Services Networks: A White Paper. December 1996. 13

....Route Setup March 1997 1 Introduction This document describes a multicast route setup protocol that can be used to install alternate paths and pinned routes when they are requested by receivers. This protocol is designed as part of the interdomain multicast routing architecture described in [7]. In general, this protocol is useful when multicast routers wish to install explicit routes in a multicast tree without coordinating the routing of the entire tree according to a globally defined metric. Thus, in addition to being used as prescribed in [7] this protocol may also be used to ....

....routing architecture described in [7] In general, this protocol is useful when multicast routers wish to install explicit routes in a multicast tree without coordinating the routing of the entire tree according to a globally defined metric. Thus, in addition to being used as prescribed in [7], this protocol may also be used to install a QoS route for a receiver. We have focused on designing a multicast route setup protocol; a later section describes the relevance of our work to unicast route setup. For the purposes of this document, we assume that receivers use a reservation protocol ....

[Article contains additional citation context not shown here]

Daniel Zappala, Bob Braden, Deborah Estrin, and Scott Shenker. "Interdomain Multicast Routing Support for Integrated Services Networks". work in progress, March 1997.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC