idnits 2.17.1 draft-zappala-multicast-routing-ar-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 26, 1997) is 9893 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Historic RFC: RFC 1819 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Historic RFC: RFC 1058 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Historic RFC: RFC 904 (ref. '8') ** Obsolete normative reference: RFC 1583 (ref. '9') (Obsoleted by RFC 2178) -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 1654 (ref. '12') (Obsoleted by RFC 1771) -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' Summary: 14 errors (**), 0 flaws (~~), 1 warning (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Daniel Zappala 3 Expiration: September 1997 USC Information Sciences Institute 4 File: draft-zappala-multicast-routing-ar-00.txt Bob Braden 5 USC Information Sciences Institute 6 Deborah Estrin 7 USC Computer Science Department 8 Scott Shenker 9 Xerox Palo Alto Research Center 11 Interdomain Multicast Routing Support for Integrated Services Networks 13 March 26, 1997 15 Status of Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 To learn the current status of any Internet-Draft, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ds.internic.net (US East Coast), nic.nordu.net 30 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 31 Rim). 33 Abstract 35 This document describes an architecture for interdomain multicast 36 routing support of integrated services networks. The key features of 37 this architecture are a multicast route setup protocol and local 38 route construction agents. Together, these two components enable 39 multicast routing to install alternate paths and pinned routes on 40 behalf of receivers that request these services. 42 1. Introduction 44 The Internet, with its best-effort service and adaptive routing, has 45 been extremely successful supporting elastic applications [1]. 46 However, best effort service can result in large, and widely varying, 47 end-to-end packet delays. To better support real-time and other 48 inelastic applications for which such vagaries are detrimental, the 49 IETF is in the process of adopting extensions to the Internet's 50 service model and architecture that would allow flows or flow 51 aggregates to reserve specific qualities of service (QoS). These 52 extensions, commonly known as "integrated service", allow state to be 53 installed in routers along the data delivery paths to provide 54 preferential QoS for particular flows or aggregations of flows. This 55 aspect of the architecture is usually known as "resource 56 reservation". 58 Most of the research on integrated services networks has focussed on 59 the service model extensions and the resource reservation protocol. 60 In contrast, this note is concerned with the routing mechanisms that 61 can improve integrated service. We concentrate on routing-in-the- 62 large, that is, the interdomain routing problem, for which issues of 63 scaling are more acute than for the intradomain routing case. The 64 purpose of this note is to briefly outline our line of research into 65 this problem. 67 An important component of this new integrated services architecture 68 is the reservation protocol RSVP [16]. This protocol is designed to 69 operate on top of the current routing infrastructure. The current 70 routing infrastructure of the Internet provides "opportunistic 71 shortest-path routing" [5,8,6,10,12,9]. By " opportunistic" we mean 72 that routing always utilizes the current shortest path, even if the 73 previously shortest path is still functioning. By "shortest path" we 74 mean that routing uses a single "cost" metric (often just hop-count) 75 and then chooses the "least-cost" path. 77 At least two problems arise when one relies on the current routing 78 infrastructure to determine the route along which reservation 79 requests and data flow: the "failed primary route problem" and the " 80 opportunistic routing problem". 82 o "Failed primary route problem": An application is limited to 83 using the shortest path as defined by the routing metric. If 84 service is not acceptable along this path, the application has 85 no alternative. In particular, if a flow has requested service 86 along this path and been denied, the application cannot obtain 87 service along any other path. This may lead to situations where 88 many flows are denied service even though other paths could 89 accommodate their service requests. 91 o "Opportunistic routing problem": When the shortest path route 92 changes (which may happen not only when the current route fails, 93 but when a "lower cost" route becomes available), the data will 94 immediately change over to this new path, even though no 95 reservation has yet been established. Thus, an application may 96 experience a service disruption even if the previous route is 97 still usable. The length of the service disruption will depend 98 on how quickly RSVP can re-establish the reservation along the 99 new route. If the reservation request is denied, the service 100 disruption could be indefinite. The extent of this problem is 101 determined by the persistence of routes in the Internet; a 102 recent study [11] indicates that while a significant portion of 103 routes persisted for days, 9% of the routes studied underwent 104 frequent route changes (with a mean time between changes on the 105 order of an hour). With opportunistic routing, there is no 106 guarantee a given route will remain unchanged. 108 There are two possible approaches to the failed primary route 109 problem: (1) try to choose a primary route that is known a priori to 110 have sufficient resources, thereby ensuring that the service 111 delivered over the path is adequate and that few reservation requests 112 will be denied, or (2) provide a mechanism to choose an alternate 113 route if the primary route has (or other alternate routes have) 114 failed. 116 There is an effort to realize the first of these approaches, a priori 117 computation of a resource-adequate route, for intradomain routing 118 [15]. This approach requires global distribution and synchronization 119 of link resources and individual flow reservations. Global 120 distribution of such rapidly varying quantities is not, we believe, 121 viable for interdomain routing where issues of scale are paramount. 123 There have been several proposals for a simplified version of a 124 priori computation that does scale adequately for interdomain 125 routing. In this approach, several different static routing metrics 126 are used; the routers calculate the "least-cost" path for each such 127 metric and keep a routing table for each. This enables routing to 128 provide a few alternate routes with distinctive static service 129 characteristics, such as maximal bandwidth or minimal latency. For 130 example, it can distinguish satellite paths from terrestrial paths, 131 or distinguish very small links from large links. In these 132 proposals, which we refer to as "QoR routing", applications would 133 specify the appropriate static metric, i.e., the desired quality-of- 134 route (QoR), and the routers would use the appropriate routing entry 135 when forwarding data. Because these metrics are static, this 136 approach has none of the scaling problems of the more dynamic 137 approaches discussed above. QoR routing could provide significant 138 benefits for best-effort service by allowing, for instance, 139 interactive applications to avoid routes involving satellite links, 140 while applications involving asynchronous bulk data transfers could 141 seek out maximal bandwidth paths. For similar reasons, QoR routing 142 could benefit real-time and other inelastic applications. However, 143 the essence of the failed primary route problem remains; an 144 application could only avail itself of one minimal-latency route, and 145 one maximal-bandwidth route, etc.. If a service request was denied 146 along one of these a priori routes, there would be no way of 147 utilizing available bandwidth along other routes with similar 148 properties. 150 To provide interdomain routing for integrated service, we therefore 151 turn to the second approach, computing an alternate route when 152 necessary. That is, when a reservation request fails, receivers can 153 request that an "alternate path" be constructed. This approach does 154 not have the scaling problems of the first approach, since alternate 155 routes are only computed on demand, and are computed locally, so they 156 do not require globally synchronized state. We propose to "augment" 157 existing routing services with (1) localized route construction, and 158 (2) interdomain routing mechanisms to install and maintain the 159 constructed routes on demand. In particular, we focus on the use of 160 alternate paths for multicast routing. 162 Even with these architectural extensions, we are still left with the 163 opportunistic routing problem, whereby routes may change while a flow 164 is in progress resulting in service disruption. Our approach to this 165 problem allows receivers to request that routes be "pinned" so that 166 they will only change if the current route ceases to function. We 167 integrate this mechanism into receiver-based multicast routing, 168 allowing receivers with reservations to choose between opportunistic 169 and pinned routes, depending on their preference. 171 The purpose of this note is to provide a very brief overview of 172 alternate path routing and route pinning within the context of a 173 routing architecture; a more detailed description of the route setup 174 mechanism can be found in [14]. While these routing enhancements 175 were originally motivated by the need to better support certain 176 applications using reservations, they might also be valuable for 177 applications whose service requirements are flexible enough to use 178 (i.e., adapt to) best effort packet delivery, but not flexible enough 179 to cope with arbitrarily long queueing delays that can occur along 180 best effort paths. The rest of the paper is organized as follows. 181 In Section 2 we discuss how the routing enhancements fit into our 182 routing architecture. In Section 3 we discuss how applications use 183 alternate paths and route pinning and briefly describe some of the 184 mechanism involved. Finally, in Section 4 we outline the status of 185 our research in this area, including other possible routing services 186 under consideration. 188 2. Routing Architecture 190 We divide routing into three components: a routing protocol, a local 191 route construction agent, and a route setup protocol. The routing 192 protocol uses static routing metrics to install opportunistic routes 193 based on resource capability. The local route construction agent 194 supplements these routes by computing alternate paths. A route setup 195 protocol installs these alternate paths for use by applications and 196 in doing so may override the opportunistic nature of current routing. 197 We separate these facets of routing from reservation setup so that 198 routing services may be used from any reservation protocol, and also 199 so that they may used by applications that don't require a resource 200 reservation. 202 2.1 Routing Protocol 204 As discussed above, an internet QoR routing protocol can use 205 static characteristics to calculate and install a limited number 206 of paths conforming to different routing metrics, such as maximal 207 bandwidth and minimal latency. A multicast routing protocol can 208 build QoR multicast trees by using unicast QoR routes to construct 209 the multicast tree. For example, the PIM multicast protocol [2] 210 builds shortest-path multicast trees by sending Join messages 211 along the shortest-path route from receivers to the sender. To 212 instead build a minimal latency multicast tree, PIM could send the 213 Join messages along the minimal latency unicast routes. Note that 214 this leaves open a key design choice. Multicast routing could keep 215 separate trees for each QoR and use ToS bits to determine the tree 216 a given packet uses. Alternatively, multicast routing could keep 217 a single tree, and use some mechanism to enforce homogeneity among 218 the QoRs that receivers choose. 220 2.2 Route Construction Agent 222 When needed, a router can also use a local route construction 223 agent to take advantage of a wider range of alternate paths than 224 those the routing protocol could scalably install via a priori 225 calculations. This agent operates independently from a route 226 setup protocol and from other route construction agents. Because 227 it does not need to coordinate its routing decisions with other 228 agents, it can utilize information not captured by the routing 229 protocol's static metrics. This information can include the 230 status of local reservation requests, or resource availability 231 information that is not flooded globally. Because of its 232 independence, the route construction agent may also choose routes 233 that are not necessarily "least-cost"; i.e., the route computation 234 is not distributed and thus need not follow the least-cost route 235 computation approach inherent in the distributed routing. 237 The local route construction agent also serves an important role 238 in multicast route construction. Due to the dynamic nature of 239 multicast group membership, it is difficult to perform scalable 240 internet multicast route construction. Both centralized 241 computation and global distribution of membership changes are 242 inefficient solutions. To perform scalable route construction, we 243 distribute the computation to the first-hop routers of each local 244 receiver. By using a local route construction agent, a router can 245 construct a route to the source of a multicast tree for any local 246 receivers. A receiver-oriented route setup mechanism can then 247 resolve any conflicts between the computed routes as it installs 248 each route. 250 2.3 Route Setup 252 Some routing protocols perform route setup and reservation setup 253 simultaneously [4,3,13]. One of our goals is to offer route setup 254 to any resource reservation protocol. In addition, we also want 255 applications not using reservations to have access to these 256 routing services. Moreover, we would like to offer reservation 257 services over opportunistic routes, as well as those using route 258 setup. This requires that we not embed route setup in the 259 reservation establishment protocol itself, but rather incorporate 260 it into the basic routing infrastructure. 262 We split route setup into several pieces. First, "alternate path 263 setup" installs an alternate path for forwarding. The alternate 264 path may specify a complete path between a source and destination, 265 or it may specify only a portion of that path. Second, "route 266 pinning" allows routing to choose to install "non-opportunistic" 267 routes. If a route is pinned, it will remain fixed unless a 268 failure occurs somewhere along the route. Upon failure, the route 269 may be removed or degraded to an opportunistic route. 271 Most route setup protocols assume that every alternate path must 272 also be pinned. However, in some cases an application may simply 273 want to reach a destination by routing through ProviderA rather 274 than ProviderB. In this case, routing may pin only the portion of 275 the route through ProviderA. This will result in an alternate 276 path of two pieces: an opportunistic path from the source to 277 Provider A and then another opportunistic path from Provider A to 278 the destination. 280 In addition, while route pinning may be used with alternate paths, 281 it may also be used to convert a current opportunistic route into 282 a pinned route. For example, in some cases an application may be 283 using an opportunistic route and be satisfied with its service 284 over this route. While some routes may remain stable for a long 285 period of time [11], there is no guarantee that the route will 286 remain unchanged. Particularly if the application has obtained a 287 reservation along this route, it may want to convert the route to 288 a pinned route. Having this capability allows the network to use 289 current scalable routing protocols to support route pinning. 291 3. Using the Architecture 293 Figure 1 shows a simple block diagram of the routing architecture and 294 its application interfaces. Applications have access to route setup 295 and reservation setup through two separate interfaces. Note that 296 there is no application interface to the local route construction 297 agent; the application's first-hop router contacts the agent when it 298 needs a route. By not allowing the application to determine the 299 routes being used, we prevent a malicious or malfunctioning user from 300 providing its own route and undermining the integrity or efficiency 301 of a given tree. 303 [See postscript version for figures] 305 Figure 1: Routing and Reservation Architecture 307 In the most simplistic model of how this architecture would be used, 308 applications would make requests for these services directly from 309 routing or from RSVP. In fact, given the complexity of the service 310 options available, we assume that many operating systems will offer 311 some form of support for managing quality of service; such a "QoS 312 manager" could act as an agent on behalf of an application, managing 313 the reservation establishment and the routing services procurement 314 process. A user (or a monitoring program) may simply indicate that 315 service is unacceptable. The QoS manager could then choose from a 316 number of actions, including asking for any of the available routing 317 services, depending on the application. Thus, the QoS management 318 function could reside either in the application itself, or in a QoS 319 manager, or in some other form of operating system support. All of 320 these possibilities fit within our proposed architecture. 322 To illustrate the use of our routing architecture, we will discuss 323 several examples, showing how applications may request alternate path 324 setup and route pinning. In these examples, we focus on multicast 325 routing. In order to perform scalable internet route setup for 326 multicast groups with dynamic sets of receivers, we assume that the 327 route setup protocol must use a receiver-oriented mechanism. 329 To initiate alternate path setup, an application or a QoS manager 330 prompts routing for a different route, as shown in Figure 2. This 331 signal may be prompted by many behaviors, including an admission 332 control failure along the shortest path or a user's unhappiness with 333 packet delays. The first-hop router then contacts the local route 334 computation agent to get an alternate path, which returns an explicit 335 (or source) route. The first-hop router embeds the explicit route in 336 a Join message, and forwards the Join along the route, re-configuring 337 the multicast tree at each hop (subject to constraints described 338 later). 340 [See postscript version for figures] 342 Figure 2: Alternate Path Joining Example 344 [See postscript version for figures] 346 Figure 3: Route Pinning Example 348 The QoS manager can request route pinning at the same time it 349 requests an alternate path. Normally, when asked for an alternate 350 path, the local route construction agent can return an explicit route 351 that lists only the few hops necessary to reach an alternate route. 352 However, when asked for route pinning as well, the local route agent 353 returns a strict explicit route, which lists every hop between the 354 first-hop router and the source of the multicast tree. Because the 355 alternate path setup mechanism in effect pins each hop listed in the 356 alternate path, a strict route necessarily implies that the entire 357 route is pinned. 359 If an application is satisfied with its current opportunistic route, 360 it can request route pinning alone, meaning that routing will convert 361 its route into a non-opportunistic or pinned route. This situation 362 can occur when the QoS manager has invoked RSVP over shortest path 363 routing (perhaps according to a specific QoR request). As shown in 364 Figure 3, the application or QoS manager prompts routing to pin the 365 current route. The first-hop router then probes the multicast tree 366 to determine the current route, and encodes this route as a strict 367 explicit route. Note that the extra trip for probing the route 368 allows routing to prevent loops during pinning by using an explicit 369 route. The first-hop router finally embeds this route in a Join 370 message, which it sends upstream to notify each router not to adapt 371 unless its parent fails. 373 It may appear that an even simpler mechanism for route pinning would 374 be for RSVP to notify routing, at each hop where it makes a 375 reservation, that it needs that hop to be pinned [15]. However, this 376 approach has several disadvantages. First, because RSVP is designed 377 to transparently operate through non-RSVP routers, the portions of 378 the route between RSVP routers would not be correctly configured. 379 Moreover, because RSVP operates on top of opportunistic routing, the 380 sequence of hops RSVP notifies for pinning might not, at any instant, 381 form a coherent route. For example, during routing changes, RSVP 382 leaves behind reservation state along the old route that eventually 383 times out. The old (but not yet timed-out) reservations and the new 384 reservations may not only lie along incompatible routes, but may even 385 form a loop. The routing protocol would have a difficult time 386 determining how to form a consistent, pinned route from the 387 collection of reservations made over a set of opportunistic routes. 388 This approach serves to illustrate how important it is that routing 389 control the construction of routes. Requests for route pinning, 390 issued by RSVP or the QoS manager, are limited to the endpoints of 391 the network. The selection of routes is limited to the routing 392 protocol. Note that while the mechanisms in [15] are designed for a 393 link-state protocol, we believe that a hop-by-hop explicit join 394 mechanism can be integrated into such a protocol. The protocol could 395 still distribute link-state advertisements notifying other nodes 396 about pinned hops, so that they could take this into account when 397 constructing opportunistic portions of multicast trees. 399 Both alternate path setup and route pinning are also applicable to 400 unicast routing. We have concentrated on multicast because the 401 issues in that area are less straight-forward. For unicast 402 applications, the unicast routing protocol can embed an explicit 403 route in the source's packets if the application needs an alternate 404 path or a pinned route. To save on processing overhead, routing 405 could use an IPv6 flow label and some simple flow-setup protocol, 406 with service degrading to regular hop-by-hop forwarding if flow state 407 is lost. While the multicast model focuses on receiver actions, in 408 the unicast case the source could control routing or use some out- 409 of-band signalling to ask the destination about its capabilities. 411 4. Research Status 413 As a part of our research, we have designed interdomain route pinning 414 and alternate path joining mechanisms for multicast routing. As 415 shown in Section 3, these mechanisms are based on control messages 416 that carry explicit routes. For an alternate path join, routing uses 417 a loose explicit route; for route pinning it uses a strict route. By 418 restricting the types of explicit routes used, the mechanisms are 419 lightweight and provide loop freedom when re-configuring multicast 420 trees by preventing even temporary loops. Further details of how 421 alternate path joining and route pinning are implemented may be found 422 in [14]. 424 We are currently simulating these two routing services using a simple 425 route construction prototype to examine the effects of these 426 mechanisms on multicast trees. Our route construction prototype 427 finds local access points to the network and constructs alternate 428 paths by building a set of explicit routes listing only a single 429 access point and the target (i.e. the source of the multicast tree). 430 One of our goals is to determine whether local information is 431 adequate to provide alternate paths; for large multicast groups this 432 may produce good results. We are also interested in characterizing 433 the "distortion" a multicast tree may exhibit when re-configured with 434 an alternate path, and examine route construction techniques that 435 limit this effect. 437 In this note we have focussed on two particular routing issues, 438 failed primary route and opportunistic changes, that arise in 439 integrated services networks. However, there are several other 440 issues that arise, and addressing them may require some support from 441 routing. Below we describe these issues, and possible routing 442 mechanisms that could be used to address them. We are not proposing 443 that these mechanisms be adopted. Our purpose is to evaluate these 444 services and the role of routing in terms of their functional 445 benefits and mechanistic complexity. It seems clear that for some, 446 and perhaps all, of these issues, the benefits of the mechanism do 447 not outweigh the cost of additional complexity. However, an informed 448 decision about these services cannot be made without exploring the 449 complexity of the routing support. 451 o The purpose of route pinning is to prevent service disruption. 452 However, by sticking with the current route even though "better" 453 ones have become available in the meantime means that routing 454 pinning can result in flows using sub-optimal routes. One 455 proposal to increase network efficiency is to introduce "smooth 456 switching", whereby routing gracefully transitions a flow from a 457 reserved pinned route to a reserved opportunistic route. This 458 would require routing to install a second route for a flow, 459 allow RSVP to reserve that route, and then switch the forwarding 460 to that route. This prevents the service disruption without 461 requiring the flow to always stick with the route it first used. 462 While this would be a beneficial service we currently doubt that 463 this service can be implemented efficiently in multicast 464 routing. 466 o Multicast applications involving a number of senders, for 467 example a set of video sources, may want to rapidly switch 468 between senders. RSVP has considered, but does not currently 469 support, a "dynamic filter" style to allow a receiver to keep a 470 reservation in place for each sender, thus facilitating the 471 switch between senders. Without routing support, data from all 472 sources would still be delivered to the receiver, but only the 473 data associated with the selected source would be given the 474 reserved service. To keep reserved but temporarily unneeded 475 data from overwhelming the links close to the receiver (and 476 thereby perhaps severely perturbing the best effort service 477 there), routing could use a proposed service called "sender 478 deactivation" to inactivate the forwarding state for a sender, 479 but allow RSVP control traffic to still maintain a reservation 480 for the sender. The modifications needed for this service 481 appear to be a simple extension of current multicast routing 482 protocols; however, it is still unclear whether this is a 483 reservation style that RSVP needs to support explicitly. 484 Receivers may be able to obtain adequate service simply by 485 dynamically changing their explicit filters as a means of 486 channel switching. Because of this uncertainty, it is premature 487 to assume the need for this service. 489 o Finally, applications using hierarchical encoding of video may 490 send the data for different encoding levels over separate 491 multicast groups [7]. Some have proposed that the multicast 492 trees for each encoding level should use the same routes, thus 493 allowing the network to use priority dropping during times of 494 congestion. Routing could use a service called "bundling" to 495 denote such a set of multicast groups. The routing protocol 496 could then handle routing control messages uniformly for the 497 bundled set to ensure that their trees use the same routes. On 498 the other hand, bundling will generally happen by default for 499 multicast trees using shortest path routes. It is unclear 500 whether support for bundling is needed for alternate path 501 joining and route pinning, or whether receivers could instead 502 issue separate requests for each group. 504 We plan to continue investigation of these and other proposals and 505 evaluate the appropriate role (or non-role) of routing in their 506 support. 508 5. Acknowledgments 510 We wish to thank Lee Breslau for comments on an earlier draft, and 511 the IETF community for helpful discussion of these issues. 513 References 515 [1] David D. Clark, "The Design Philosophy of the DARPA Internet 516 Protocols", In "ACM SIGCOMM", August 1988. 518 [2] Stephen Deering, Deborah Estrin, Dino Farinacci, Van Jacobson, 519 Ching-Gung Liu, and Liming Wei, An Architecture for Wide-Area 520 Multicast Routing, In "ACM SIGCOMM", August 1994. 522 [3] L. Delgrossi and L. Berger, "Internet Stream Protocol Version 2 523 (ST2): Protocol Specification Version ST2+", RFC 1819, August 1995. 525 [4] Domenico Ferrari, Anindo Banerjea, and Hui Zhang, "Network support 526 for multimedia: A Discussion of the Tenet Approach", "Computer 527 Networks and ISDN Systems", 1994. 529 [5] C. Hedrick, "Routing Information Protocol", RFC 1058, STD 0034, June 530 1988. 532 [6] Charles L. Hedrick, "An Introduction to IGRP", Technical report, The 533 State University of New Jersey, October 1989. 535 [7] Steven McCanne, Van Jacobson, and Martin Vetterli, "Receiver-driven 536 Layered Multicast", In "ACM SIGCOMM", August 1996. 538 [8] D. L. Mills, "Exterior Gateway Protocol for Formal Specification", 539 RFC 904, April 1984. 541 [9] J. Moy, "OSPF Version 2", RFC 1583, March 1994. 543 [10] International Standards Organization, "Protocol for the Exchange of 544 Inter-Domain Routing Information among Intermediate Systems to 545 Support Forwarding of ISO 8473 PDUs", ISO/IEC JTC1/SC6 CD10747, 546 1993. 548 [11] Vern Paxson, "End-to-End Routing Behavior in the Internet", In "ACM 549 SIGCOMM", October 1996. 551 [12] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 552 1654, July 1994. 554 [13] Burkhard Stiller, "A Survey of UNI Signalling Systems and Protocols 555 for ATM Networks", "ACM SIGCOMM Computer Communication Review", 556 25(2), April 1995. 558 [14] Daniel Zappala, "A Route Setup Mechanism For Interdomain Multicast 559 Routing", work in progress, March 1997. 561 [15] Zhang, Sanchez, Salkewicz, and Crawley, "Quality of Service 562 Extensions to OSPF", work in progress, June 1996. 564 [16] Lixia Zhang, Steve Deering, Deborah Estrin, Scott Shenker, and 565 Daniel Zappala, "RSVP: A New Resource ReSerVation Protocol", "IEEE 566 Network", September 1993.