text:
RSVP: A NEW RESOURCE RESERVATION PROTOCOL Lixia Zhang, Stephen Deering, Deborah Estrin, Scott Shenker, and Daniel Zappala Originally published in IEEE Network Magazine September 1993 - Volume 7, Number 5 he origin of the RSVP protocol can be traced back to 1991, when a team of network researchers, including myself, started playing with a number of packet scheduling algo-rithms on the DARTNET ( DARPA Testbed NETwork), a network testbed made of open source, workstation- based routers. Because scheduling algo-rithms simply shuffle packet processing orders accord-ing to some established rates or priorities for different data flows, to test a scheduling algorithm requires set-ting up the appropriate control s t a t e a t each router along the data flow paths. I was challenged to design a set- up protocol that could support both unicast and many- to- many multicast applications. That effort led to the birth of RSVP. As a signaling protocol designed specifically to run over IP, RSVP distinguishes itself from previous signaling pro-tocols in several fundamental ways. The most profound ones include a soft- state approach, two- way signaling mes-sage exchanges, receiver- based resource reservation, and being independent from all other related components in a QOS support architecture, such as flow- specification, admission control, scheduling algorithm, and routing. As stated in the article, " RSVP is primarily a vehicle used by applications to communicate their requirements to the net-work in a robust and efficient way, independent of the spe-cific requirements." It has been more than 10 years since the original idea was first conceived. Over this time period many people contributed to the effort that has evolved RSVP from a lab toy to a Proposed Internet Standard Protocol. Other more recent protocol developments, such as MPLS ( Multi- Pro-tocol Label Switching), VPN ( Virtual Private Network), and OTN ( Optical Transport Network), to name a few, have adopted or considered RSVP for their own signaling use. I was stunned by RSVP's rapid adoption and develop-ment of usage. The protocol has moved on with a life of its own. I have learned many lessons from observing which features in the original design worked and which didn't. Among these lessons, I noticed that the proposal of sup-porting flexible resource reservations by individual users is yet to prove useful, and that the decision to make RSVP a generic messenger, which simply carries " a bag of bits" to pass to routers along the way, has proven to be a right one, which promoted the adoption of RSVP for various purpos-es other than QOS support. The effort that started RSVP design is but the first step in developing signaling protocols for the Internet. Although the debate on which kinds of QOS support the Internet would need continues, various signaling needs demand a generic signaling protocol. Independent from whether RSVP would be the lasting one t o fulfill that important role, I believe the basic principles and lessons we have gained from RSVP development will extend beyond the protocol itself into new protocol designs for the future Internet. AUTHOR' S INTRODUCTION 116 IEEE Communications Magazine 50th Anniversary Commemorative IssuelMay 2002 . he current Internet architecture, embodied in the Internet Protocol ( IP) network protocol, offers a very simple service model: point- to- point best- effort service. In recent years, several new classes of distributed applications have been developed, such as remote video, T multimedia conferencing, data fusion, visualization, and virtual reality. It is becoming increasingly clear that the Internet's primitive service model is inadequate for these new appli-cations. This inadequacy stems from the failure of the point- to- point best- effort service model to address two application requirements. First, many of these applications are very sensitive to the quality of service their packets receive. For a network to deliver the appropriate quality of service, it must go beyond the best- effort service model and allow flows ( which is the generic term we will use to identify data traffic streams in the network) to reserve network resources. Second, these new applications are not solely point- to- point, with a single sender and a single receiver of data; instead, they are often multi-point- to- multipoint, with several senders and receivers of data. Multipoint- to- multipoint com-munication occurs, for example, in multiparty conferencing where each participant is both a sender and a receiver of data, and also in remote learning applications, although in the latter case there are typically many more receivers than senders. In recent years there has been a flurry of research activity devoted to the development of new network architectures and service models to accommodate these new application require-ments. Even though fundamental differences exist between the proposed architectures, there is widespread agreement that any new architec-ture capable of accommodating multicast and a variety of qualities of service can be divided into five distinct components, which we identify and describe below. Flow Specification: The network and the vari-ous data flows need a common language, so a source can tell the network about the traffic characteristics of its flow and, in turn, the net-work can specify the quality of service to be delivered to that flow. Thus, the first component of this new architecture is a flow specification, or " flowspec," which describes both the characteris-tics of the traffic stream sent by the source, and the service requirements of the application. In some sense, the flowspec is the central compo-nent of the architecture, since it embodies the service interface that applications interact with; the details of all of the other components of the architecture are hidden from applications. Two proposals for a flowspec are described in the lit-erature [ l, 21. Routing: The network must decide how to transport packets from the source to the receiver of the flow ( or receivers of the flow, in the case of multicast). Thus, the second component of the architecture is a routing protocol that provides quality unicast and mul-ticast paths. There are many approaches to unicast routing, and several different approaches to multicast routing exist as well [ 2- 41. None of the current proposals have yet dealt sufficiently with the interaction between routing and quality of service constraints; that is the subject of future research. Resource Reservation: For the network to deliver a quantitatively specified quality of ser-vice ( e. g., a bound on delay) to a particular flow, it is usually necessary to set aside certain resources, such as a share of bandwidth or a number of buffers, for that flow. This ability to create and maintain resource reservations on each link along the transport path is the third component of the architecture. Two approaches to resource reservation are described elsewhere [ 2, 51; in this article, we describe another. Admission Control: Because a network's re-sources are finite, it cannot grant all resource reservation requests. In order to maintain the network load at a level where all quality of ser-vice commitments can be met, the network archi-tecture must contain an admission control algorithm that determines which reservation requests to grant and which to deny, thereby maintaining the network load at an appropriate level. Two such admission control algorithms are described in the literature [ 6, 71. Packet Scheduling: After every packet trans-mission, a network switch must decide whether or not to transmit the next packet, and which is next. These decisions are controlled by the pack-et scheduling algorithm, which lies at the heart of any network architecture because it deter-mines the qualities of service the network can provide. There are many proposed packet scheduling algorithms. A few examples are cited here [ S- 121. In this article, we present our proposal for the third component of the architecture, a new resource Reservation Protocol ( RSVP). Similar to previous work on resource reservation proto-cols, e. g., ST- I1 [ 2], RSVP is a simplex protocol, Le., it reserves resources in one direction. How-ever, several novel features in the RSVP design lead to the unique flexibility and scalability of the protocol. RSVP is receiver- oriented: the receiver of the data flow is responsible for the initiation of the resource reservation. This design decision enables RSVP to accommodate heterogeneous receivers in a multicast group. Specifically, each receiver may reserve a different amount of resources, may receive different data streams sent to the same multicast group, and may " switch channels" from time to time ( Le., change which data streams it wishes to receive) without changing its reservation. RSVP also provides sev-eral reservation styles that allow applications to specify how reservations for the same multicast group should be aggregated at the intermediate switches. This feature results in more efficient utilization of network resources. Finally, by using " soft- state" in the switches, RSVP supports dynamic membership changes and automatically adapts to routing changes. These features enable RSVP to deal gracefully and efficiently with large multicast groups. While the motivation for RSVP arose within the Internet context, our design is intended to be fully general. This article is organized as follows. We first list our design goals, and then discuss the basic design principles used to meet these goals. A more detailed description of the protocol opera- In recent years, several new classes of distributed applications have been developed, such as. remote video, multimedia conferencing, data fusion, visualization, and virtual reality. It is becoming increasingly clear that the Internet' s primitive service model is inadequate for these new applications. IEEE CommunicationsM agazine 50th Anniversary Commemorabe Issue/ May 2002 117 The strawman proposal here is incapable of dealing with the receivers individually, and so cannot address these heterogeneous needs. Therefore, our first design goal for RSVP is to pro-vide the ability for heterogeneous receivers to make reservations specifically tailored to their own needs. tion is then given, followed by a simple example of how the protocol would work. Next, the cur-rent state of our RSVP implementation is described. We delay consideration of related work until later, and follow that with a discus-sion of unresolved issues. Finally, we conclude with a brief summary. RSVP DESIGN GOALS In the traditional point- to- point case, one obvi-ous reservation paradigm would have the sender transmit a reservation request toward the receiv-er, with the switches along the path either admit-ting or rejecting the flow. For the point- to-multipoint case, one may trivially extend this paradigm to have the sender transmit the reser-vation request along a multicast routing tree to each of the receivers. When we have multipoint-to- multipoint data transmissions, the straightfor-ward extension of this paradigm would be to have each sender transmit a reservation request along its own multicast tree to each receiver. However, the special properties of having multi-ple, heterogeneous receivers and/ or multiple senders pose serious challenges that are not addressed by this simple extension of the basic reservation paradigm. We outline these various challenges below and detail how they are not met by the strawman proposal of straightfor-wardly extending the basic paradigm. In the pro-cess, we identify the seven goals that guided the design of RSVP. In a wide- area internetwork such as the Inter-net, receivers and paths to reach receivers can have very different properties from one another. In par-ticular, one must not assume that all the receivers of a multicast group possess the same capacity for processing incoming data, nor even necessarily desire or require the same quality of service from the network. For instance, a source may be sending a layered encoding of a video signal. Certain receivers decoding in software would only have sufficient processing power to decode the low- reso-lution signal, while those receivers with hardware decoding, or more processing power, could decode the entire signal. Furthermore, the paths to reach the receivers may not have the same capacity. In the layered encoding example above, certain receivers might only have low- bandwidth paths between them and the source and so could only receive the low- resolution signal. The strawman proposal above is incapable of dealing with the receivers individually, and so cannot address these heterogeneous needs. Therefore, our first design goal for RSVP is to provide the ability for hetero-geneous receivers to make reservations specifically tailored to their own needs. The presence of multiple receivers raises another issue: the membership in a multicast group can be dynamic. The strawman proposal would have to reinitiate the reservation protocol every time a new member joined or an existing member left the multicast group. Reinitiation of the reservation protocol is particularly burden-some for large groups because the larger the group size, the more frequent are changes in group membership. So our second design goal for RSVP is to deal gracefully with changes in the multicast group membership. The strawman proposal deals with multiple senders by having each sender make an indepen-dent resource reservation along its own multicast routing tree. This approach results in resources being reserved along multiple, independent trees, even though the branches of different trees often share common links. Although appro-priate for some applications, in other cases this duplication can lead to a significant wasting of resources. For example, in an audio conference with several people, usually only one person, or at most a few people, talk at any one time because of the normal dynamics of human con-versation. Thus, instead of reserving enough bandwidth for every potential speaker to speak simultaneously, in many circumstances it is ade-quate to reserve only enough network resources to handle a few simultaneous audio channels. Our third design goal for RSVP is to allow end users to specify their application needs, so the aggregate resources reserved for a multicast group can more accurately reflect the resources actually needed by that group. Furthermore, in a multiparty conference a receiver may only wish to ( or be able to) watch one or a few other participants at a time but would like the possibility of switching among various participants. The simple approach of delivering the data streams from all the sources and then dropping the undesired ones at the receiver does not address network resource usage considerations ( e. g., efficient use of limit-ed bandwidth, or reducing the charges incurred for bandwidth usage). A receiver should be able to control which packets are carried on its reserved resources, not only what gets displayed on its local screen. Moreover, a receiver should be able to switch among sources without the risk of having the change request denied, as could occur if a new reservation request had to be sub-mitted in order to " switch channels." Our fourth design goal for RSVP is to enable this channel-changing feature. RSVP is not a routing protocol and should avoid replicating any routing functions. RSVP's task is to establish and maintain resource reser-vations over a path or a distribution tree, inde-pendent of how the path or tree was created. In a large internetwork with a volatile topology and load, these routes may change from time to time. Adapting to such changes in topology and load is the explicit job of the routing protocol; it would be expensive and complicated to replicate such functions in RSVP. At the same time, how-ever, RSVP should be able to cope with the resulting routing changes. Our fifth design goal is that RSVP should deal gracefully with such changes in routes, automatically reestablishing the resource reservations along the new paths as long as adequate resources are available. The strawman proposal does not deal grace-fully with changes in routes, because there is no mechanism to discover the change and trigger a new resource reservation request. One could introduce such a mechanism by having each source periodically refresh its reservation over the multicast routing tree. However, in large multicast groups such refreshing would lead to S messages arriving at every receiver during every refresh period, where S is the number of sources. 118 IEEE Communications Magazine 50th Anniversoty Commemorative Issue/ May 2002 Our sixth design goal is to control protocol over-head. By this we mean both avoiding the explo-sion in protocol overhead when group size gets large, and also incorporating tunable parameters so that the amount of protocol overhead can be adjusted. Our last design goal is not specific to the problem at hand hut rather is a general matter of modular design. We hope to make the gen-eral design of RSVP relatively independent of the architectural components listed in the first section of this article. Clearly a particular implementation of RSVP will be tied quite closely to the flowspec and interfaces used by' the routing and admission control algorithms. However, the general protocol design should be independent of these. In particular, our pro-tocol should be capable of establishing reserva-tions across networks that implement different routing algorithms, such as IP unicast routing, 1P multicast routing ( 41, the recently proposed core- based tree ( CBT) multicast routing [ 3], or some future routing protocols. This design goal makes RSVP deployable in many contexts. For optimally efficient routing decisions, however, routing selection and resource reservation should be integrated, so the choice of route can depend on the quality of service requested, and the stability of the route can he main-tained over the duration of the reservation. Such an integration would lead to more coordi-nation bctwccn the choice of which resources to reserve and the mechanics of establishing the reservation ( which is RSVP's main focus). This integration is something that requires fur-ther research. In summary, we have identified seven impor-tant design goals ( see box this page). RSVP is primarily a vehicle used by applications to com-municate their requirements to the network in a robust and efficient way, independent of the specific requirements. RSVP delivers resource reservation requests to the relevant switches but plays no other role in providing network services. Thus, RSVP communicates require-ments for a wide range of network services but does not directly provide them. For instance, the synchronization requirements of flows or the need for reliable multicast delivery could be expressed in the flowspec that is distributed by RSVP and then realized by the switches. Simi-larly, the flowspec could also carry around information about advance reservations ( reser-vations made for a future time) and preempt-able reservations ( reservations that a receiver is willing to have preempted). RSVP is capable of supporting the delivery of these and other ser-vices, whenever these network services rely only on the state being established at the individual switches along the paths determined by the routing algorithm. Thus, although we described RSVP as a resource reservation protocol, it can he seen more generally as a " switch- state estab-lishment" protocol. ' BASIC, D ESIGNP RINClPlfS To achieve the seven design goals, we used six basic design principles ( see box this page). These principles are now described. The Seven Design Goals of RSVP * Accommodate heterogeneous receivers. * Exploit the resource needs of different applications in order to use * Mow receivers to switch channels. Adapt to changes in the underlying unicast and multicast routes. Adapt to changing multicast group membership. network resources efficiently. Controlprotocol overhead so that it does not grow linearly ( or worse) - with the number of participants. Make the design modular to accommodate heterogeneous underlying technologies. The Six Design Principles of RSVP Receiver- initiated reservation. . S epaiating reservation from packet filtering. Providing different reservation styles. *- Maintaining " soft- state" in the network. - Protocol overhead control. Modularity. RECEIVER- INITIATED RESERVAIIDN The strawman proposal discussed in the previous section - and all existing resource reservation protocols - are designed around the principle that the data source initiates the reservation request. In contrast, RSVP adopts a novel receiv-er- initiated design principle. Receivers choose the level of resources reserved and are reSpOnSi-hle for initiating and keeping the reservation active as long as they want to receive the data. We describe the motivation for this receiver- ini-tiated approach below. A source can always transmit data, whether or not adequate resources exist in the network to deliver the data. The receiver knows its own capacity limitations. Furthermore, the receiver is the only one who experiences, and thus is direct-ly concerned with, the quality of service of the incoming packets. Additionally, if network charg-ing is deployed in the future, the receiver would likely be the party paying for the requested qual-ity of service. Thus, it should be the receiver who decides which resources should be reserved. One could imagine the receivers send this information to the source, which would use this information in sending out the reservation request. To handle heterogeneous requests, however, the sender would have to bundle all requests together and pass them to the network, and the network would determine how much resource to reserve on which links, according to the location of individual receivers. For large multicast groups, this will likely cause a multicast implosion at the sender. This implosion problem becomes more serious when the multicast group membership changes dynamically and the reser-vation has to he periodically renewed. Consider, as an extreme example, a cable TV firm broad-casting several channels of programs. While there are relatively few sources, there are per-haps hundreds of thousands of receivers, each watching only one or a few channels at a time. In the strawman proposal, whenever any individ-ual receiver wants to switch between channels, it I IEEE Communirotions Mngozine Soh AnniveMV Cnmmemomfiue Inee/ Mny 2002 119 A separate function, called a packet filter, selects those packets that can use the resources; it is set by the reserving entity. One of the important design principles in RSVP is that we allow this filter to be dynamic; that is, the receiver can change it during the course of the reservation. sends a message to the source. In this case, where there are many receivers and frequent switching between channels, each source has to accommodate a deluge of change requests. This overhead is superfluous, however, since the resulting broadcast pattern changes relatively slowly ( because the resulting multicast trees are likely to be relatively stable except near the leaf nodes). Later in this article we show how our receiver- initiated design accommodates hetero-geneity among group members yet avoids such multicast implosion. The idea of the receiver- initiated approach was inspired by Deering's work on IP multicast routing [ 4]. The IP multicast routing protocol treats senders and receivers separately. A sender sends to a multicast group in exactly the same way as it sends to a single receiver, it merely puts in each packet a multicast group address in place of a host address. The multicast group membership is defined as the group of receivers. Deering's multicast routing design can be con-sidered a receiver- initiated approach: each receiver individually joins or leaves the group without affecting other receivers in the group, or affecting sources that send to the group. The routing protocol takes the responsibility of for-warding all multicast data packets to all the cur-rent members in the group. Analogous to our argument that a sender does not care whether adequate resources are available, a sender to a multicast group does not necessarily know who is currently a member of the multicast group ( i. e., receiving the data). In particular, it may not be a member of the multicast group itself. SEPARATING RESERVATION FROM PACKET FILTERING A resource reservation at a switch assigns cer-tain resources ( buffers, bandwidth, etc.) to the entity making the reservation. A distinction that is rarely made that will be crucial to our ability to meet our design goals is that the resource reservation does not determine which packets can use the resources, but merely specifies what amount of resources are reserved for whom. Here, " whom" does not refer to " which packets" can use the reserved resources; rather, it refers to " which entity" controls the resources. A separate function, called a packet filter, selects those packets that can use the resources; it is set by the reserving entity. Moreover, it can be changed without changing the amount of reserved resources. One of the important design principles in RSVP is that we allow this filter to be dynamic; that is, the receiver can change it during the course of the reservation. This dis-tinction between the reservation and the filter enables us to offer several different reservation styles, which we now describe. PROVIDING DIFFERENRTE SERVATIONS TYLES As we discussed briefly above, the service requirements of multicast applications dictate how the reservation requests from individual receivers should be aggregated inside the net-work. For example, the typical dynamics of human verbal interaction results in only one or a few people talking at any one time. Thus, in many conferencing situations it is feasible to have all senders of audio signals to a conference share the same set of reserved resources, where these resources were sufficient for a small num-ber of simultaneous audio streams. In contrast, there are no analogous limitations on video sig-nals. Therefore, if the conferencing application also includes video, then enough resources must be reserved for the number of video streams one desires to watch simultaneously. As in the usual multicast paradigm, if two receivers downstream of a particular link are watching the same video stream for the lifetime of the application ( e. g., when attending a remote lecture), only a single reservation need be made on this link to accom-modate their needs. However, if these two receivers wish to occasionally switch among the senders during the application lifetime ( e. g., when participating in a distributed group meet-ing), then separate reservations must be main-tained. To support different needs of various applications, while making the most efficient use of network resources, RSVP defines different reservation styles which indicate how intermedi-ate switches should aggregate reservation requests from receivers in the same multicast group. Currently there are three reservation styles: no- filter, fixed- filter, and dynamic- filter. We now describe these filter styles. For the sake of brevity we identify applications only by their multicast address, although in the current Inter-net context a multicast application may be iden-tified by the IP multicast address plus destination port number. When a receiver makes a resource reserva-tion for a multicast application, it can specify whether or not a data source filter is to be used. If no filter is used, then any packets destined for that multicast group may use the reserved resources. ( Although some enforcement mecha-nism is needed to ensure that the aggregate stream does not use more than the reserved amount, we will not discuss enforcement mecha-nisms here.) For example, the audio conference described above would use a no- filter reserva-tion, so that a single reserved pipe can be used by whoever is speaking at the moment. If source filtering is needed, the filter is specified by a list of sources. ( Again, in the Internet context a data source can be specified by the source host address plus source port number. We only refer to the source host address here.) Only the pack-ets from the specified sources can use the reserved resources. Filtered reservations are used to forward individual images in video con-ferencing, enabling participants to reserve resources for particular video streams. A filtered reservation can be either fixed or dynamic. A " fixed- filter" reservation allows a receiver to receive data only from the sources listed in the original reservation request, for the duration of the reservation. A " dynamic- filter" reservation allows a receiver to change its filter to different sources over time. To illustrate how intermediate, nodes use these reservation styles to aggregate reservation requests, consider the case of several receivers in the same multicast group making fixed- filter reservations over a common link. These reserva-tions may be shared if the source lists overlap, because the reservation will never be changed. Thus, only a single pipe ( with the largest amount 120 IEEE Communications Magazine 50th Anniversary Commemorative Issue/ May 2002 of resources from all the requests) is reserved for each source even when there are multiple requests. Such aggregation can occur when mem-bers of a multicast application all listen or watch the same audio or video signals, as in the case of a multicast lecture. Reservations using the no- fil-ter style can also be aggregated in this manner. If a receiver does not discriminate between indi-vidual sources, it cannot switch among the sources either. If a receiver expects to switch among differ-ent sources from time to time, it must make a dynamic- filter reservation to avoid affecting the reception of other receivers in the same multi-cast application. The intermediate nodes cannot aggregate this style of reservation because the receiver can change the list of sources in the fil-ter at any time during the course of the reserva-tion. In fact, this separation between the resource reservation and the filter is one of the key facets of RSVP. The resource reservation controls how much bandwidth is reserved, while the filter controls which packets can use that bandwidth. In the dynamic- filter reservation case, each receiver requests enough bandwidth for the maximum number of incoming streams it can handle at once and the network reserves enough resources to handle the worst case when all the receivers that requested dynamic- filter reservations take input from different sources, even though several receivers may actually tune to the same source( s) from time to time. Howev-er, note that the total amount of dynamic filter reservations made over any link should be limit-ed to the amount of bandwidth needed to for-ward data from all the upstream sources. In summary, having several different reserva-tion styles allows intermediate switches to decide how individual reservation requests for the same multicast group can be efficiently merged. The dynamic- filter reservation style allows receivers to change channels. Thus, we have met design goals 3 and 4. So far, RSVP has defined three reservation styles; other styles may be identified as new multicast applications with different needs are developed. MAINTAININ" SGO FT- STATE" IN THE NETWORK The typical multipoint- to- multipoint applications we have considered are rather long- lived. Over the lifetime of such an application, new mem-bers may join, existing members may leave, and routes may change due to dynamic status changes at intermediate switches and links. To be able to adjust resource reservations accord-ingly, in a way transparenk to end applications, RSVP keeps soft- state at intermediate switches and leaves the responsibility of maintaining the reservation to end users. The term " soft- state" was first used by Clark [ 13]. In our context, it refers to a state maintained at network switches which, when lost, will be automatically reinstated by RSVP soon thereafter. Thus, soft- state is appropriate in our context where frequent mem-bership changes and occasional service outages would render a more brittle ( Le., less self- stabi-lizing) state to become, and perhaps remain, obsolete or incorrect. More specifically, at each intermediate switch, RSVP distinguishes between state information of two kinds: path state and reservation state. Each data source periodically sends a path message that establishes or updates the path state, and each receiver periodically sends a reservation message that establishes or updates the reserva-tion state ( which is attached to the path state). Path messages are forwarded using the switches' existing routing table. In other words, the routing decision is made by the network's routing protocol, not by RSVP. Each path mes-sage carries a flowspec given by the data source, as well as an F- flag indicating if the application wishes to all reservations. In process-ing each pa , the switch updates its path state containing information about 1) the incoming link upstream to the source, and 2) the outgoing links downstream from that source to the receivers in the group ( as indicated by the multicast routing table). In addition, if the F- flag in the path message is on, the switch also keeps the information about the source and the previ-ous hop upstream to reach the source. This information allows the switch to accommodate any style of reservation. If the F- flag is off, the switch does not maintain information about the specific source of the path message except for adding its incoming link to the path state; the state kept at the switch is thereby minimized. Consequently, only no- filter style reservations can be made for data streams from such sources. As we show later in an example, not maintaining per- source information can, in some topologies, result in over- reserving resources over certain links. Each reservation message carries a flowspec, a reservation style, and ( if the reservation uses a fixed or dynamic filtered style) a packet filter. In processing each reservation message, the switch updates its reservation state ( which contains information for the outgoing link the message came from) by recording 1) the amount of resources reserved, 2) the source filter for the reserved resource, 3) the reservation style, and 4) if the style is dynamic- filtered, the reserver ( who is the sender of this reservation message, and one of the receivers of this multicast group). We see that the only time we need to keep per-receiver information in the reservation table is when the reservations involve dynamic filters. When all reservations are either no- filter or fixed- filter, we can assign the reservation to the multicast group as a whole and then only keep track of the total resources reserved on each downstream link. Reservation messages are forwarded back toward the sources by reversing the paths of path messages. In fact, the path information is maintained solely for this reverse- path fonvard-ing of reservation messages. More specifically, reservation messages of the no- filter style are forwarded to all incoming links to the multicast group, and those of filtered styles are forwarded to the previous hops of the sources that are list-ed in the filters. Both path messages and reservation messages carry a timeout value used by intermediate switches to set corresponding timers; the timers get reset whenever new messages are received. Whenever a timer expires, the corresponding state is deleted. This timeout- driven deletion Reservations along old routes, or along routes to inactive senders or receivers, time out automatically. Because path and reservation messages are sent periodically, the protocol toler-ates occasional corruption or loss of a few messages. This soft- state approach adds both adaptivity and robustness to RSVP. IEEE Communicotions Mogozine 50th Anniversary Commemorotive Issue/ Moy 2002 121 0 FIGURE 1. A simple nehvork topology with the muiticast routin tr& s HI on( H2 ore data sources, ond H3, H4, and H5 are receiveis. T e sobd bnes depict the. routing tree of H I ; the dotted lines depict the routing tree of H2. In general, the set oi sources and the set oi receivers may oveiiap prtiolly 01 compietely. For the sake of clarity, here they are disioint. f : . prevents resources from being orphaned when a receiver fails to send an explicit Tear- down mes-sage or the underlying route changes. It is also the only way to release the resources of no- filter or fixed- filter reservations. In these cases, the switch cannot determine if the reservation is being shared by multiple receivers, so the reser-vation can only be deleted when it times ont. It is the responsibility of both senders and receivers to maintain the proper reservation state inside the network by periodically refreshing the path and reservation state. When a route or membership changes, the routing protocol running underneath RSVP for-wards future path messages along the new route( s) and reaches new members. As a result, the path state at switches is updated, causing future reservation messages to traverse the new routes or new route segments. Reservations along old routes, or along routes to inactive senders or receivers, time out automatically. Because path and reservation messages are sent periodically, the protocol tolerates occasional corruption or loss of a few messages. This soft-state approach adds both adaptivity and robust-ness to RSW. The advantages of the soft- state approach, however, do not come for free. The periodic Refreshing messages add overhead to the proto-col operation. We next discuss how RSVP con-trols protocol overhead. PROTOCOL OVfRHEAD COIITROL The RSVP overhead is determined by three fac-tors: the number of RSVP messages sent, the size of these RSVP messages, and the refresh frequencies of both path and reservation mes-sages. As we describe in more detail in the RSVP overview section, RSVP merges path and reser-vation messages as they traverse the network. The merging of path messages means that, in general, each link carries no more than a single path message in each direction during each path-refresh period. Similarly, the merging of reserva-tion messages means that each link carries no more than a single reservation message in each direction during each reservation- refresh period. The maximum size of both the path and reserva-tion messages on a particular link is proportional to the number of data sources upstream. RSVP controls the third overhead factor, the refresh frequencies, by tuning the timeout values carried in path and reservation messages. The larger the timeout value, the less frequently the refresh messages have ta be sent. There exists, however, a tradeoff between the overhead one is willing to tolerate and RSVP's responsiveness in adapting to dynamic changes. For instance, reservation messages are fonvarded according to the path state maintained at intermediate switch-es, which in turn gets synchronized with the routing protocol state every time a path message is processed. When a route changes, reservations along the new route ( or new route, segments) are not established until a new path message is sent ( causing the path state to he updated), and a new reservation message is sent along the new route. Our current RSVP implementation uses stat-ic timer values chosen on the hasis of engineer-ing judgment. In the future, we will investigate adaptive timeout algorithms to optimally adjust the timer values according to observed dynamics in routes and membership changes, and the loss probability of RSVP messages. MODU~ ARITY In the context of real- time, multicast applica-tions, RSVP interfaces to three other compo-nents: * The flowspec, which is handed to RSVP by an application or some session- control pro-tocol on behalf of the application, when invoking RSVP. * The network routing protocol, which for-wards path messages toward all the receivers, causing the RSVP path state to - he established at intermediate switch nodes. The network admission control, which makes an acceptance decision hascd on the flowspec carried in the reservation mes-sages. We list modularity as one of RSVP's design goals because we would like to make RSVP as independent from the other components as pos-sible. We have attempted to make few assump-tions ahout these other components, and those assumptions we have made are described explic-itly. We make no assumptions about the flowspec to be carried by RSVP. RSVP treats the flowspec as a number of uninterpreted bytes of data that need to he exchanged among only the applica-tions and the network admission- control algo-rithm. We assume that the admission- control algorithm operates by having an RSVP reserva-tion packet containing a flowspec pass through the switches along the delivery path for that flow ( hut obviously in the reverse direction), with each switch returning an admit or reject signal. The resource reservation is established only if all switches along the path admit the flow. We also assume that the packet- scheduling algorithm can change packet filters, without needing to cstab-lish a new reservation. The only assumptions about the underlying routing protocol( s) are tliat it provides both uni- 122 IEEE ( ommunico& nr Mogazine 5% Anniverronj ( ammemorotive Irrue/ Moy 2002 cast and multicast routing, and that a sender to a multicast group can reach all group members under normal network conditions. Obviously, in thc case of a network partition, no routing pro-tocol can guarantee this reachahility. We do not assume that a sender to a multicast group is nec-essarily a member of the group, nor do we assume that the route from a sender to a receiv-er is the same as the route from the receiver to the sender. RSVP OPERATION OVERVIEW RSVP. and indeed any reservation protocol, is a vehicle for establishing and maintaining state in switches along the paths that each flow's data packets travel. Because reservation messages are initiated by each receiver, RSVP must make sure that thc reservation messages from a receiver follow exactly the reverse routes of the data streams from all the sources ( that the receiver is interested in). In othcr words, RSVP must estah-lish a sink tree from each receiver to all the sources to forward reservation messages. The sink tree for each receiver is formed by tracing the paths defined by the multicast rout-ing protocol - in the reverse direction - from the receiver to each of the sources ( Figs. 1 and 2). Periodic path messages are forwarded along the routing trees provided by the routing proto-col, and reservation refresh messages are for-warded along the sink trees to maintain current reservation state. A reservation message propa-gates only as far as the closest point on the sink tree where a reservation level greater than or equal to the reservation level being requested has already been made. Each switch uses the path states to maintain a table of incoming and outgoing interfaces for each multicast group. Each incoming interface keeps the information about the flowspecs it has forwarded upstream. ( This information is need-ed in merging reservation requests from multiple downstream links.) For each outgoing link, there is a list of senders; associated with each sender is the previous hop address from which data from that sender arrives at the current switch. There is also a set of reservations. Generally speaking, each reservation consists of a reserver, a filter, and the amount of resources reserved. For no-filter reservations, the first two fields are not needed; for fixed- filter reservations, the first field is not needed. We now review the process of creating and maintaining reservations in more detail. Before or when each data source starts transmitting, it sends a path message containing the flowspec of the data source. When a switch receives a path message, it first checks to see if it already has the path statc for the named target ( which can he either a single host or a multicast group, plus the destination port number); if not. it creates the path state for that target. The switch then obtains the outgoing interface( s) of the path message from' the routing protocol in use, and updates its table of incoming and outgoing links accordingly. The source address ( and port num-ber in the Internet context) carried in the path message is also recorded if the path message indicates that the application may require a fil- I I U W FIGURE 1. A simple network topology with the sink trees. H i ond H2 ore doto sources, ond H3, H4, ond H5 ore receivers sinksJ. The dotted lines depici the sink tree of H3; the soiid lines deoict the sink iree of H4. For clori-h/ the sink tree oi H5 is omitted. tered reservation. This path message is fonvard-ed immediately only if it is from a new source or indicates a change in routes. The switch can detect a change in routes by checking to see if the outgoing interfaces indicated by the routing protocol's routing table are different than the outgoing links maintained in the path state. Oth-erwise, the switch discards the incoming path message and instead periodically sends its own path messages which contain the path informa-tion carried in all the path messages that it has received so far. When a receiver receives a path message from a source for whose data it would like to create a reservation, the receiver sends a reser-vation message using the ( possibly modified) flowspec that came in the incoming path mes-sage. As described earlier, the reservation mes-sage is guided along the reverse route of the path messages to reach the data source( s). Along the way if any switch rejects the reservation, an RSVP reject mcssage is sent hack to the receiver and the reservation message is discarded. Other-wise, if the reservation message requires a new reservation to be made, it propagates as far as the closest point along the way to the sender( s) where a reservation level equal to or greater than that being requested has been made. Once the reservation is established, the receiver periodically sends reservation refresh messages ( which are identical in format to the original request). As the reservation requests are forwarded along the sink trees, the switches merge the requests for the same multicast group by pruning those that carry a request for reserv-ing a smaller, or equal, amount of resources than some previous request. As an example, assume H1 is a video source, and H4 has reserved enough bandwidth to receive the full video data stream while H5 wants to receive only low- resolution video data ( Fig. 2). In this case, when the reservation request from H5 reaches S4, S4 makes the requested reservation over the link from S4 to H5 and then drops the request ( i. e., does not forward it upstream) because suf-ficient resources have been reserved already by H4' s request. When a sender ( receiver) wishes to terminate . IBE Communicotionr Mogozine Soh Annivesory Commemorobve lrrue/ Moy 2002 I23 L6 0 FIGURE 3. Network topology. / the connection, the sender ( receiver) sends out a path ( reservation) teardown messagc to release the path state or reserved resources. There is no retransmission timer for this teardown message. In cases where the teardown message is lost, the intermediate nodes will eventually time out the corresponding state. As we noted above, no- fil-ter or fixed- filter reservations cannot be explicit-ly torn down because the switches do not maintain sufficient state. EXAMPLE We consider a simple network configuration to illustrate in more detail how RSVP works. The network has five hosts connected by seven point-to- point links and three switches ( Fig. 3). We assume that for links connecting hosts directly to a switch, the hosts act as switches in terms of reserving resources. To simplify the description, we assume adequate network resources exist for all reservation requests. Furthermorc, the exam-ple involves only a single multicast group, so we do not discuss the addressing used to distinguish reservations made for one multicast group from reservations made for other multicast groups. We describe the cases of no- filtcr and filtered reservations separately. We start with, the sim-pler case, no- filter reservations, and then discuss the case of filtered reservations. NO- FILTERR ESERVATIONS Let us consider an audio conference among five participants, one at each of the five hosts ( Fig. 3). In this case, each host behaves both as a source and a receiver at the same time. We make the following assumptions: * The routing protocol has built a multicast routing tree so each sender can reach all - the receivers. Each switch has received RSVP path mes-sages ( with the F- flag off from all the sources, so the switches do not record source information), and the complete path state for each switch has stored as described below, although in a real application sources may start at different times and the - path state would he built up over time. No reservations have been made yet. I ! 51 1 52 I 53 I 1 Incoming links L1, L2, L6 L5, L6, L7 L3, L4, L7 Outgoing links L1, L2. L! L5. L6. L7 L3, L4. L7 ll_ l___- We now describe how reservations are creat-ed. H1 wants to receive data from all other senders to the multicast group hut only wants enough bandwidth reserved to carry one audio stream. Thus, it sends a reservation message R1 ( B, no- filter) to S1, where B is the amount of bandwidth needed to forward one audio stream. When S1 receives R1 ( B, no- filter), it first reserves resources over L1 ( in the direction from SI toward Hl), then attaches the following reser-vation state to the path state to indicate the amount of the reservation made over L1. Outgoing links Ll( B) L2 L6 Finally, S1 forwards R1 ( B, no- filter) over all incoming links, in this case L2 and L6. Note that the switch never forwards any RSVP message over the link the message came from. The copy of R1 ( B, no- filter) sent along L6 reaches S2, which reserves B over Lh and for-wards the message to links 5 and 7. When the copy of R1 ( B, no- filter) that was sent along L7 reaches S3, that switch reserves B over L7 and then fonvards R1 ( B, no- filter) over links 3 and 4. When H2 wants to create a reservation, it sends a reservation message, R2 ( B, no- filter), to S1. Upon receipt of R2 ( B, no- filter), S1 first reserves B over L2, chang_ ing th. e p. a th state to: 51 Incoming links L1 L2 L6 Outgoing links Ll( B) LZ( B) L6 S1 then forwards R2 ( B, no- filter) over L1 only, because it has forwarded an identical request over L6 previously. After all the receiving hosts have scnt RSVP reservation messages, an amount B of resources have been reserved over each of the seven links in each of the two directions. Before leaving this example of no- filter reser-vation, consider the tradeoff between keeping extra state information and the possibility of over- reserving resources on certain links. In the above example, we assumed all the path mes-sages had the F- flag off, so no per- source infor-mation is kept at the switches. As a result, if each receiver requested 2B of bandwidth ( is., an amount enough to carry two full audio streams), then 28 would he reserved on every link - even though on L1 ( and similarly on L2, L3, L4, and L5) in the direction away from H1 we need only reserve B, since there is only a single source upstream on the link. In general, a no- filter reservation should indicate how much should be reserved as a function of the number of sources upstream. In this example it would be B units per upstream source. Unfortunately, one cannot know the number of sources upstream without keeping a list of the sourccs. If the F- flag was sct in all the path messages, the switches would have kept track of individual sources and, by paying this extra cost in increased state, only the required resources would have been rcserved along the links. I24 IEEE Communirofionr Mogozine 50h Rnniveirorl Commemomtive leue/ Moy 2002 Not maintaining per- source information can lead to an ovcr- reserving of resources on some network links. However, in those applications involving many data sources with few resources required for each source ( such as in a data- gath-ering application with many sensors), one may still choose to reduce the switch state at the pos-sible expcnse of over- rcscrving resourccs ovcr some links, FILTERED RESERVATIONS Now consider the case where HZ, H3, H4, and H5 are receivers ( i. c., members of the multicast group), and H1, H4, and H5 are sources. All path message have the F- flag set, so each'switch needs to keep a list of sources associated with their previous hops. Assume that S1 has received path messages from all of the sources hut no reservations have yet been made. Thus, Sl's path state contains the following entry: I 51 I - ~. 1 s2 Outgoing- links : LS( S~ C: HI. SI ~ 4.53) ~ L ~ ( s ~ c : H ~~. s5~ . ~[ L5~( S~ C: HI. SI ~ 5 . ~ 5 ) I Outgoing- linkr. LZ( src: Hl. Hl H4.62 H5.52) . L6( rrc: H1.~ 1) 1 ular, we have not described with any specificity the merging algorithm. We havc, The notation L2( src: H1, HI H4, S2 H5, S2) indicates that data from sources H1, H4, and H5 are sent out along outgoing link L2. For each source, HI, S2, and S2 are the previous hop addresses from which data from that source arrives, respectively. H1 is not a receiver, so L1 is not among the outgoing links of. Sl. Now assume that H2 sends a reservation mes- , sage denoted R2 ( B, H4), that is, H2 wants to receive packets only from source H4 and is reserving an amount B, sufficient for one source. The reservation message R2( B, H4) reaches SI via the LZ interface. S I finds that H4 is indeed one of the sources it has heard, and that the packets from H4 come from S2. S1 reserves bandwidth B over L2, and forwards R2 ( B, H4) over L6 to S2. j 53 Outgoing- link ' LB( rrc: Hl. SZ H4. H4) H5.52) L4( rrc: Hl, S2 H5.52 ! L7( src: H4. H4 there is only one source going out L6. It there-fore reserves an amount B over L6 for R5 and then passes the reservation request on to H1. When S3 receives R5( 2B, *), it finds out that there is only one source going out L7 and has a fixed- filter reservation already. S3 does not reserve any more, nor does it further forward [ 8,6,14]. I t provides modules that imitate the actual behavior of the requcstto L4. Su~ oosen ow that H4 terminates both receiv-ing ani sending without transmitting any tear-down messages. As H4 no longer sends path or reservation- refreshes, all H4- rclated state will time out, changing'the outgoing link entries in the varioub switches. 51 LZ( rrc: Hl. HlH5.52) ' L6( src: Hl, Hl) 52 L5( ric: H1.51) L6krr: H5. H5) L7( rrc: Hl. S1 H5, H5) 53 13( rrc: H1,52 H5.52) S1 stops forwarding R2 ( B, H4) from H2 and returns an RSVP error message to H2. S2 for-wards future R5( 2B, *) reservation refreshes to the L6 direction only since there are no more sources in thc L7 direction. For thc sake of simplicity, in the above exam-ple we assumed each data stream requires the same bandwidth to forward. RSVP is designed to handlc cases where cach source may demand different amounts of resources, and each receiv-cr may receive only a subset of the data from each source. In fixed- filter reservations, this requires each source filter be associated with a specific amount of resources. In dynamic- filter reservations, the receiver must receive the same amount of data when " switching channels." lMPLEMENTATlON STATUS This article illustrates how RSVP works at a general level. For the sake of brevity and clarity, Our current simulations and tests deal only with reasonably small networks and small multicast groups. We do not yet understand how RSVP performs when the size of the multicast groups gets very large. IKEE Communirotionr Mogozine * 50h hnivesory Commemorative Iree/ Moy 2002 125 Neither ST nor ST- II provides a robust and efficient solution to the multipoint- to- . multipoint resource reservation problem. They share several of the limitations of the strawman proposal described earlier. The RSVP design effort was initiated to fill . this vacuum. ARPA, linking roughly a dozen academic and industrial research institutions. Preliminary tests have been performed on this implementation, but no systematic performance studies have been done as yet. RELATED WORK In the course of exploring network algorithms that deliver quality of service guarantees, there have been several proposals and prototype implementations of network resource reservation algorithms over the last few years [ 9, 151. How-ever, almost all of these prototypes deal exclu-sively with unicast reservations. The Stream Protocol, ST [ 5], was a pioneer-ing work in multicast reservation protocol design. ST was designed specifically to support voice conferencing and was capable of making both unicast and multicast resource reservations. At the time ST was proposed, there was no work on sophisticated multicast routing, so ST would make resource reservations over a single, duplex distribution tree which was created by blending the paths from unicast routing. This was done with the assumptions that the routes were reversible and the application data traffic would travel in both directions. However, ST requires a centralized access controller to coordinate among all the participants and manage the tree establishment. The successor to ST, ST- I1 [ 2], continues to create its own multicast trees by blending the paths from unicast routing. However, ST- I1 establishes multiple simplex reservations to elimi-nate the access controller. Each data source makes a resource reservation along a multicast tree that is rooted at the source and reaches out to all the receivers. The reservation made along the tree uses a single flowspec, so ST- I1 cannot accommodate heterogeneous receivers. Because each data source makes its reservation indepen-dently, a single pipe is reserved from every source to every receiver in the same multicast applica-tion group. An analysis of ST- I1 implementation and design issues is provided elsewhere [ 16]. Thus, neither ST nor ST- I1 provides a robust and efficient solution to the multipoint- to- multi-point resource reservation problem. They share several of the limitations of the strawman pro-posal described earlier. The RSVP design effort was initiated to fill this vacuum. Recently, how-ever, there have been other proposals to fill this need. Pasquale et al. have proposed a dissemina-tion- oriented approach in their work on multi-media multicast channels [ 17]. They share with us these viewpoints: To efficiently support heterogeneous receivers, each receiver must be able to specify a stream filter for the subset of the data it is interested in receiving. Furthermore, not to waste network resources, the filters from all the receivers should be propagated toward the sender, so the subset of the data in which no one is interested would be stopped at the earliest point along the source propagation tree. However, they only considered single- source applications ( such as cable TV), as opposed to RSVP's functionality of supporting multipoint-to- multipoint applications, and they have mainly focused on the programming interface to appli-cations, as opposed to our interest in designing a protocol that reserves resources inside the net-work and adjusts the reservation to dynamic environmental changes. UNRESOLVED lSSUES While RSVP has been simulated and tested to some extent, we fully expect that further incre-mental design changes will be made as we gain experience with RSVP, both on DARTnet and also through further simulation. Besides these incremental changes, however, several larger design issues remain unresolved, as detailed below. RSVP was designed with minimal expecta-tions of routing. Path states are used to essen-tially invert the routing tables, a function that routing could easily provide if it were so designed. If we were to design new routing algo-rithms, what routing support would we include to support resource reservation algorithms? In this design, we have associated filters with resource reservations. In fact, filters could be applied to flows even without reserved resources. Furthermore, there are filter styles besides the ones described here that might be useful. For remote lectures with several speakers at separate sites, one might want a dynamic filtered reserva-tion where the filter is the same for each receiv-er, as proposed by Jacobson [ 18]. This feature would allow the audience to switch ( in unison) to different speakers with only one set of resources reserved. Thus, one unresolved issue is defining the general service model and interfaces for such filters, where these definitions are not specifically tied to the presence of resource reservations. Our current simulations and tests deal only with reasonably small networks and small multi-cast groups. We do not yet understand how RSVP performs when the size of the multicast groups gets very large. Can one use caching strategies to avoid the router state explosion when S ( the num-ber of senders) and/ or R ( the number of receivers) gets very large? This issue is particularly relevant to the case of cable TV, where every home would want a dynamic reservation but the switches obvi-ously would not want to keep an individual reser-vation state for each home. SUMMARY RSVP's architecture is unique in that: It provides receiver- initiated reservations to accommodate heterogeneity among receivers as well'as dynamic membership changes. It separates the filter from the reservation, thus allowing channel changing behavior. It supports a dynamic and robust multi-point- to- multipoint communication model by taking a soft- state approach in maintain-ing resource reservations. It decouples the reservation and routing functions and thus can run on top of, and take advantage of, any multicast routing protocols. 126 IEEE Communications Magazine 50th Anniversary Commemorative Issue/ May 2002 We have verified the first RSVP design by detailed simulation and a preliminary implemen-tation. Much testing remains to be done in the context of larger- scale simulations, as well as in real prototype networks such as DARTnet. ACKNOWLEDGMENTS We would like to gratefully acknowledge useful conversations with Bob Braden, David Clark, Ron Frederick, Shai Herzog, Sugih Jamin, and Danny Mitzel. REFERENCES [ [ l ] C. Partridge, " A Proposed Flow Specification," Internet I21 C. Topolcic, " Experimental Internet Stream Protocol: Ver-sion 2 ( ST- ll)," Internet RFC 1190, Oct. 1990. [ 31 A. Ballardie, P. Tsuchiya, and J. Crowcroft, " Core Based Trees ( CBT)," Internet Draft, Nov. 1992. [ 41 5. Deering, " Multicast Routing in a Datagram Internet-work," Tech. Report No. STAN- CS- 92- 1415, Stanford Uni-versity, Dec. 1991. I51 1. Forgie, " ST: A Proposed Internet Stream Protocol," Inter-net Experimental Notes IEN- 119, Sept. 1979. [ 61 S. Jamin et a/., " Admission Control Algorithm for Pre-dictive Real- Time Service," Proc. 3rd lnt% Wksp. Net-work and Operating System Support for Digital Audio and Video, Nov. 1992. [ 71 J. M. Hyman, A. A. Lazar, and G. Pacifici, " Joint Scheduling and Admission Control for ATS- based Switching Nodes, Proc. ACM SIGCOMM ' 92, Aug. 1992. RFC- 1363, July, 1992. [ 81 D. D. Clark, 5. Shenker, and L. Zhang, " Supporting Real- Time Applications in an Integrated Services Packet Net-work Architecture and Mechanism," Proc. ACM SIGCOMM ' 92, Aug. 1992. [ 91 D. Ferrari, A. Banerjea, and H. Zhang, " Network Support for Multimedia: A Discussion of the Tenet Approach," Technical Report TR- 92- 072, Computer Science Division, University of California at Berkeley, Nov. 1992. [ lo] S. J. Golestani, " Duration- Limited Statistical Multiplexing of Delay Sensitive Traffic in Packet Networks," Proc. INFO-COM ' 97, 1991. 1111 C. Kalmanek, H. Kanakia, and S. Keshav, " Rate Controlled Servers for Very High- speed Networks," Proc. GlobeCom ' 90. 1990, pp. 300.3.1- 300.3.9.' I121 J. Hyman, A. Lazar, and G. Pacifici, '" Real- Time Scheduling with Quality of Service Constraints," I€€€ JSAC, vol. 9, no. 9, Sept. 1991 ,' pp. 1052- 63. 1131 D. D. Clark, " The Design Philosophy of the DARPA Inter-net Protocols," Proc. ACM SIGCOMM ' 88, Aug. 1988. [ 141 L. Zhang, " A New Architecture for Packet Switching Network Protocols," Technical Report TR- 455, Laborato-ry for Computer Science, Massachusetts Institute of Technology, 1989. [ 151 I. Cidon, A. Segall, " Fast Connection Establishment in High'Speed Networks," Proc. ACM SIGCOMM ' 90. Sept., 1990. 1161 C. Partridge and S. Pink, " An Implementation of the Revised Internet Stream Protocol ( ST- 2)," Internetworking: Research and Experience, vol. 3, no. 1, pp. 27- 54, Mar. 1992. [ I71 J. Pasquale, G. Polyzos, E. Anderson, and V. Kompella, " The Multimedia Multicast Channel," Proc. 3rd Int'I. Wksp. Network and Operating System Support for Digital Audio and Video, Nov. 1992. [ l 81 V. Jacobson, private communication. While RSVP has tested to some extent, we fully expect that further incremental design changes will be made as we gain experience with RSVP, both on DARTnet and also through further simulation. been simulated and . IEEE Communicahons Magazine 50th Anniversary Commemorahve Issue/ May 2002 127
Click tabs to swap between content that is broken into logical sections.


text:
The new LG PTAC Air Conditioners are ultra-quiet. Low decibel levels and an outstanding sound-prevention rating make this your best choice for a quiet environment. High efficiency ratings cap off the line making the choice easy. Add features like standard connections for remote thermostats and front desk controls, Gold Fin technology which protects the unit from the corrosive effects of the outside air extending the life of the PTAC and industry standard size makes the LG PTAC the right choice.
Main FeaturesVentilation Filter: Polymeric mesh filter allows clean, fresh air into the living space. Ideal for Health Care applications.Separate Indoor & Outdoor Motors*: Dual motor configuration allows the lowest sound rating in the industry while also promoting the highest level of energy efficiency.Sensors: 4 Sensors provide highly efficient operation and maximize guest comfort.Pressure control: Protects guests by shutting down the compressor on abnormal high pressure condition.High-Efficiency Rotary Compressor: Energy efficient and maintenance free operation.Power Cord: Included with every unit.Dip Switch Setting: Saves money by control the Lowest & Highest temperature.Freeze Room Protection: Electronic temperature controls constantly monitor and maintain indoor temperature to prevent freezing.R410A Refrigerant: Environmentally Friendly Refrigerant utilized in the LG PTAC.Defrost Control shuts down the indoor fan to prevent cold air from being blown into the room. Also removes frost from outdoor coil when the outdoor temperature is low.Emergency Heat bypasses compressor operation and activates the ceramic or coil heater during periods of extreme cold. Promotes high level of guest comfort. Digital Control Display IncludesTemperature Display on Unit Precise and easy to use. ADA compliant.Cooling, Heating and Fan Modes: One unit for all seasons.Energy Saver Mode Helps to lower energy consumption operational costs and saves money.Auto Restart Automatically restarts to programmed setting when the electricity comes on after a power failure.
Gold Fin™ Anti-CorrosionProtects the unit from the corrosive effects of outside air and extends the operating life of PTAC models. LG's patented process is standard on ALL LG PTAC models.
Ceramic HeaterEven, stable and safe heating platform.
A minimum of 2 items must be added to the cart to be qualified. The qualifying discount amount depends on the brand and the value of your cart and item(s) total. If you qualify for the AppliancesConnection exclusive instant savings discount you will see a green badge below the items in your cart with the amount of savings for shopping with us.

subset: commoncrawl


text:
This is the book lover's community that has been waiting for you. Join us for fun and meet people who share the same love of books that you do. Java Junction is filled with publisher and author groups. Special Interests is filled with hobbies, fun things, cooking tips, recipes, and great things to do. Author's Coffee Corner - Stop by our Author group area and find hundreds of authors who have their Author area with us.
Welcome to our New Authors
Franny Armstrong | Carol Burnside | Sara Walter Ellwood | AC Katt
Writing Seminar - Click here March 10-14, 2014
Advanced Plotting Our Host: Kris Bock
Latte Lounge Events:
- 29 - HeartFelt Promos Spring Chat all day in the Latte Lounge
Coffee Time Event Calendar | Author Events Calendar
Hello, Joyce. Just wanted to drop by and say hello. I am a huge fan of medieval romances. To me, there is nothing better. Have a great day and good luck in your writing career.
Hi Joyce. Lovely to see you at CTR. Your profile picture is so cute.
Mocha Member
Decaf Coffee Member
Cappuccino Member
Forum Mistress


text:
Search Result
Search Tags: cyber crime
Private US firms take major role vs. cyberattacks
Tags: Kevin Mandia , Mandiant , technology , cybersecurity ,
DoD hosting cyber crime conference
The Defense Department is taking submissions for its 12th annual Cyber Crime Conference. The conference is sponsored by DoD's Defense Cyber Crime Center (DC3). Planners expect more than 200 speakers and 20 different track sessions. Participants from agencies, universities and industry are invited to share ways to prevent cyber crime. Submissions for research abstracts are due by July 6th.
Tags: DoD , cybersecurity , Cybersecurity Update ,
Lockheed to provide cyber crime support to DoD
The ceiling value on the contract is $454 million. Most of the work will be located in Linthicum, Md., at at DC3 headquarters.
Tags: Lockheed Martin , DoD Report , cybersecurity , technology , DC3 , Federal Drive , contracting
Cyber Security: Achieving Cyber Resilience
Faced with rapid technological advancements and increasingly sophisticated cyber attacks, organizations must act now to acquire or improve cyber resilience to protect their agencies or departments from theft, fraud and sabotage. Experience has shown that cyber resilience requires a coordinated approach across five areas: policy and compliance; budget; the IT enterprise architecture; acquisitions, and security operations. Determining where to focus first is often difficult. Many organizations begin with a situational assessment of their cyber health within the context of the current environment and their own business and mission imperatives. From there, organizations can quickly prioritize problems -business processes, operational, technological or personnel - and take decisive actions that will enhance cyber resilience and help reduce risk.
Tags: technology , Accenture , cyber , cyber security , IT , DoD , ISS , FAA , DHS , Army , CERT , Steven D. Shirley , Michael F. Brown , Army BG Steven W. Smith , Randy Vickers
FBI uses coordinated, interagency efforts to battle cyber crime
Patrick Carney
Assistant Director, FBI Cyber Crime Division
Oct. 15, 2009
Tags: technology , Federal Security Spotlight , FBI , Patrick Carney , Tom Temin
More than 100 nabbed in global bank hack
More than 100 people have been arrested or charged in the U.S. and the U.K. as part of an alleged global cyber-crime ring, The Wall Street Journal reports.
Tags: Cybersecurity Update , technology , Dorobek Insider , Zeus Trojan , hackers
Cyber Warfare Prevention - Securing Your Software and Applications
Thursday, June 17th
The sophistication of security breaches of federal information systems and reports of improper access to these systems continues to grow at an alarming rate. Clearly, there is concern about and a desire to improve the security of these critical infrastructures. So where and how do we begin to effectively safeguard today's systems from cyber threats and increasing system vulnerabilities? c
Tags: technology , cyber , security , Fortify , FISMA , Robert Lentz , Kevin Carroll , Joseph A. Grace, Jr
Md. college students win cyber defense competition
While the Washington area may be tops when it comes to cyber criminals, our region is also a home to a growing number of cyber defenders-in-training.
Tags: cyber defense , Towson University , Center for Applied Information Technology , Mike O'Leary , Kate Ryan , Maryland
D.C. home to most cyber-criminals
On a per capita basis, the District has the most cyber crooks. Maryland ranks 19th and Virginia 28th.
Tags: Internet Crime Complaint Center , Evan Haning , Colleen Kelleher , identity theft , computer crimes , crime , FBI , cyber-crime , cyber crook
"Identity Theft: The $500 Billion Criminal Enterprise"
Wednesday, November 11th, 2009 at 2:05pm
Identity Theft is a multifaceted problem that has grown to epidemic proportions with the development of the internet and of the on-line economy.
Tags: technology , Booz Allen Hamilton , Booz Allen Distinguished Speaker Series , Kathleen Walter , IRS , Richard Power , CyLab , Carnegie Mellon University , Calivin Sneed , Blue Cross Blue Shield Association , Kennethe Jenkins , US Secret Service , identity theft


text:
Peace is in and retro is back with bright neon colors and peace signs. Our 12' long multicolor peace sign garland is the perfect addition to your 60's, Woodstock and retro party decorations. Each 12' pull out peace sign garland is 5 3/4" wide and sold by the piece. Please order in increments of 1 peace.
Email Newsletter
Sign up for exclusive offers
Recommended Category
Shop By
Shop with confidence, our site is secure
Call Us:1-800-442-9722


text:
Today's Snow Report
Weather Report
Partly cloudy, with a low around 29. Light south southwest wind becoming west southwest 6 to 11 mph after midnight.
Year To Date Totals
YTD Base (inches)
YTD Snowfall (inches)
Logan Canyon - Last Updated: 03/16/2014 11:35 PMBeaver Base Cam - Last Updated: 03/16/2014 11:35 PM
Welcome to,
Beaver Mountain Resort.
Beaver Mountain has 828 skiable acres containing well maintained slopes with northeastern exposure, perfect for catching morning rays. Come explore a variety of terrain, perfect for every ability.
Situated in the gorgeous Wasatch Cache National Forest, Beaver Mountain is located just one mile off Highway 89, 14 miles west of Bear Lake (Garden City). Resort Tip One of the best things about Beaver Mountain is the uncrowded skiing. Besides the obvious advantages of virtually non-existent lift lines, this means fresh snow conditions last longer and the beautiful corduroy stays well maintained. Fresh lines for days! Resort Highlights: Kids love Beaver Mountain and can easily navigate their way around the slopes. Riders get more bang for their buck at Beaver Mountain. Our prices are among the lowest in the intermountain area and no lift lines equals more time spent skiing. Ski and board rental equipment is available on site with a knowledgable staff to assist guests with equipment needs. Beaver Mountain now has a surface conveyor (magic carpet) lift in the beginner area.Address
40000 East Highway 89
Garden City, UT 84028
Get Directions
Anticipated Dates
2013 Anticipated Opening | 2014 Anticipated Closing |
December 20th, 2013 |
April 13th, 2014 |
Adult All Day$45.00 |
Adult Half Day$35.00 |
Junior All Day$35.00 |
Junior Half Day$30.00 |
Senior All Day (65+)$35.00 |
Senior Half Day (65+)$30.00 |
Little Beaver Lift Only$20.00 |
Little Beaver 12 Ride Punch Pass$30.00 |
Doubles1 |
Triples3 |
Surface Lifts1 |
Beginner Terrain35% |
Intermediate Terrain40% |
Advanced Terrain25% |
Average Snowfall400" |
Base Elevation7,200ft |
Summit Elevation8,800ft |
Vertical Drop1,600ft |
Skiable Acres828+ |
Number of Runs48 |
Miles to Major Airport114 mi |


text:
Skip to Main Content
Beta test
our new site.
NLM Technical Bulletin
Study Topics
Full Text View
Tabular View
No Study Results Posted
Related Studies
Pediatric Liver Database
This study is currently recruiting participants.
Verified June 2011
by Medical College of Wisconsin
Study NCT00677625 Information provided by Medical College of Wisconsin
First Received on May 9, 2008. Last Updated on June 21, 2011
History of Changes
Related Studies can be found by searching for the Conditions, Interventions, and Sponsors found in this study:
Conditions listed in this trial
Liver Disease
Liver Transplant
Additional conditions recognized in this trial
Liver Diseases
More general conditions related to this trial
Digestive System Diseases
Sponsors listed in this trial
Medical College of Wisconsin
Back to top of Main Content


text:
Birthday Gifts
Gift Buzz
The Oscars are Hollywood's biggest event, so we've rolled out the red carpet to come up with glamorous gift ideas inspired by the Academy Awards. Some of our gift ideas are based on the $55,000 swag bags the nominees will receive, while others... Read More »
You need that gift now. Heck, you needed it yesterday. But don't give up, because here are our top 10 gift ideas that you can give right now. Sent at the speed of email, these gifts arrive in the most timely manner available. Or, print out... Read More »
Cancerians are known to be compassionate and caring with friends and family members. They can appear hard and insensitive on the outside but on the inside they are little teddy bears which makes them very special! If you live with someone... Read More »
It's National Cake Decorating Day! In the past, the world of cakes was about as vast as the desert is damp. White and chocolate were staples, and maybe, if you were lucky, strawberry or cherry filling added a nice surprise. The only decisions... Read More »


text:
posted a message on The multiplayer bonuses are great atm. I'd suggest doing pub games.. and just running whatever. More drops, more xp.. it's pretty fun too. If you do multiplayer chances are you'll just have to run whatever they run, but some of the better areas in the game are keep depths 2, cathedral 4.. and I like the sewers in a2.Posted in: Diablo III General Discussion
posted a message on Posted in: Diablo III General DiscussionQuote from Bagstone
Quote from mlhaynes4
I honestly think this game would be better if it was being run by the playerbase.
I wholeheartedly disagree. D3 is actually not a bad game at all, it just failed to meet the extremely sky-high expectations that everyone has in Blizzard games. Imagine the same game that is D3 as of now but created by some little kids... do you really think people would rant about the game as much as they do right now?
Quote from maka
Quote from Bagstone
Besides, keep in mind that it's not a question of "franchise" but a question of "game genre". For an RTS game like WC3 or SC2, every new "game" is just a new "map". No one can do any damage by releasing "bad/gamebreaking" stuff.
So, action RPG's don't usually have mods? I think all other ARPG's on the market beg to differ.
Where did I say that ARPGs don't have mods? Please read my statement again, the part after what you highlighted. Sure, many ARPGs allowed modding, but that didn't help at all - just look at TL2. For an RTS game, this is different.
Also, when we talk about "franchise" people might put WoW and WC3 in one basket, which obviously doesn't make much sense within the scope of this thread.
You completely misinterpreted what I said.. I wasn't saying I wish D3 was designed by kids, I love the design of the game.. physics and combat are amazing. What I have a problem with are the features or lack there of that have come since. Basically everything they've added has either come from D2, or from player suggestions. Had it been left in the hands of the players via modding, we would already have TONS more legendaries, probably more classes, better class balance, better skills/rune combos, and the itemization revamp would've already taken place. Hell, go look at the synergies mod for TL2 and imagine that with D3. There are some solid modders out there.. and I'm sure we would be seeing brilliance with 14 months under our belts. -
posted a message on Posted in: Diablo III General DiscussionQuote from Bagstone
What Melt said.
Besides, keep in mind that it's not a question of "franchise" but a question of "game genre". For an RTS game like WC3 or SC2, every new "game" is just a new "map". No one can do any damage by releasing "bad/gamebreaking" stuff.
In WoW, the only thing you can mod is the interface. And the reason why they don't allow anything besides the interface in WoW and why they said "no mod support for D3" is that community argument Melt mentioned. Also, there is no reset button or "new game" like in an RTS.
Not arguing your point, however I can definitely see the pros to Diablo 3 being modable. I honestly think this game would be better if it was being run by the playerbase. Granted, the splitting of the playerbase wouldn't be a good thing.. but neither is 80% of the playerbase quitting because they're very disappointed with the dev team, and lack of continuous content and patches to make the game better. -
posted a message on Maybe I am expecting a little much, and if previous experience with the d3 team should tell me anything it's that I'm always expecting a little much, but if it is taking this long to be patched into the game.. it had better be a monumental change in the game. I'm serious, if we wait this long and just get new proc effects and stat replacement on legendaries I will have to walk away.Posted in: Diablo III General Discussion
posted a message on 29 Max dmgPosted in: US Servers Trading
142 Int
184 Vit
Thanks ahead of time for the help, just need to know what I can expect to get for it.
Pic here -> http://i.imgur.com/MKSvLlu.jpg -
posted a message on Posted in: Diablo III General DiscussionQuote from Kamisei2400
Yeah I´m hoping for a barb nerf and feel the exact same as you playing other classes now. It will cost a lot more to be just as efficient. Though I still enjoy playing barb a bit tooQuote from Vaestmannaeyjar
The updates and patches have been great. My main gripe atm is how much better the barbarian is for farming, playing other characters feels like a grind now. I know some other classes can farm well, but at levels of equipment that are unreachable for me. I do ove my monk but it's far from being as effective as a barb.
To think thta at the very beginning barb was the underpowered class needing huge resists and a shield to survive Inferno 1.0
It's worth noting though that you can get a budget wiz together for
You guys need to get over this, the reason other classes can't farm as efficiently as barbs is because Blizzard has done a terrible job at giving synergy between skills. Mostly, its because resource management is so poor. Why are CM wizards second on the list? Because of mob control and resource management. Blizzard released this game with no deeper thought than the direct design of the skills.. and not how they will work together. You can't blame the players for finding something that works greatly, when there are so few choices on how to play your characters effectively. -
posted a message on Posted in: Diablo III General DiscussionQuote from eldimmy
To clarify, I'm not the owner of the image. I found it on battle.net forums on an itemization discussion, and jesus... it was just too good that I have to share here with you guys, and trust me, AT LEAST the Blues knows about it.
If they show that to jay, I think he would probably resign from his job.
I agree 1000% that the image is just too good.. but if you think Jay would resign for any reason you've lost your mind.
The reason Blizzard went to main stat itemization is so they can release expansions the same way they do with WOW, where all gear is basically rendered useless from the previous. This completely recycles gear, and brings in a whole new influx of RMAH fees from people buying new gear. The itemization is so terrible, and blatantly flawed.. that there is no way they would've chosen this had they not had a damn good reason to use it. I think this is their reason. -
posted a message on All of this has been said a million times overPosted in: Diablo III General Discussion
posted a message on Guys, if you only do runs on certain servers then of course when you get an upswing of loot you're going to think "Aw man, see it worked!".Posted in: Diablo III General Discussion
Placebo effect and all of you are falling for it.
If you really want to test the theory, run on whatever server you get.. and when you get a legendary just tab out and write down the IP address.
If you see a trend from that, thats when you should post. -
posted a message on "You can drive a car with your feet if you want to, that don't make it a good idea"Posted in: Barbarian: Bastion's Keep
- To post a comment, please login or register a new account.


text:
Adirondack church fire an act of "intolerance"
Nov 22, 2006 — Police say a church fire in the Adirondack village of Pottserville last May was an act of religious intolerance. According to the Warren County Sheriff's office, 20-year-old Caleb Uriah Lussier confessed to burning the church. Lussier is a student at the Word of Life Bible Institute in Schroon Lake. Investigators say he believed that the Episcopal church had deviated from the true teachings of the Bible. As Brian Mann reports, Lussier may have been involved in another church fire in his hometown.


text:
Teen Craft: Can-Do Robots
Event occured on Wed, Mar 13 2013, 4:00 pm - 5:00 pm
Teens in grades 6-12 can come to the library and create their own personalized robots out of a tin can. Each robot is unique using a variety of items such as magnets, colored wires, googly eyes and more.
Website: http://www.lansingpl.org


text:
All the latest news and photos of cosmetic tips, trends and make-up advice
Brighten up frosty nights with a bold makeup kit
The skies may be grey but it needn't mean that your makeup tones should follow the weather's colour palette.
There's nothing more exciting than to brighten up a cold, gloomy day than with an explosion...
How to achieve the ultimate red lip look
A red lipstick is undoubtedly the cosmetic equivalent of the Little Black Dress. Every woman needs one, and when you find the perfect fit for you, you'll wonder how you ever did without it.
It's a classic...
Perfect party prep ideas from Kelly Brook, just in time for Christmas
She may have wowed audiences with her burlesque show, Forever Crazy, in London earlier this month, but Kelly Brook is no tease when it comes to sharing her shape-up secrets and best beauty buys.
So with...
Sparkle like Glee's star Lea and get an A-list glow this party season
Only recently this year actress and singer Lea Michele was given the prestige of becoming the beautiful new face of L'Oreal and the young starlet has been looking radiant in the spotlight...
Make the most of your make-up: A guide to the shelf-life of cosmetics
Step into any woman's bathroom or bedroom and the story is usually the same – shelves and drawers filled with cosmetics that have been collected over a long period of time.
Whether it's a well-loved,...
Confessions of an Angel: Erin Heatherton shares devilish tips for looking lingerie-model good
She is the top model and Victoria's Secret Angel whose heavenly body has caught the eye of Oscar de la Renta, Diane von Furstenberg and Tommy Hilfiger.
So when 23-year-old Erin Heatherton offered to...
Make-up tips to achieve Kiera Knightley's purrfect feline flicks
Kiera Knightley celebrated the premiere of her newest movie, Anna Karenina, in Los Angeles on Wednesday night by making a statement with the most purrfect of fierce, feline eye-liner.
Sparkle like the stars of Strictly this Christmas party season
It's the glitziest, most glamorous show on TV. Each week the stars of Strictly Come Dancing are dressed to impress as they take to the dance floor – and for the ladies, that means perfectly...
Prep for a perfect finish with make-up primers
Ever wondered the secret behind flawless red-carpet skin? The trick to creating a flawless look is a smooth, well-prepped canvas and now make-up primers are becoming the new staple item...
Cosmetic queen, Drew Barrymore to launch her first beauty line
Cover Girl star, Drew Barrymore has shown that she is more than just a pretty face, taking on her own beauty project, by creating a new cosmetic line for American retailer, Wal-Mart.
Top beauty blunders: Heavy eyebrows take worst make-up mistake crown
We're all guilty of making a beauty faux pas every now and again, especially if you go back in time through the family photo album.
But what is the most offensive make-up mistake to make?
Ethical makeup: Join Lily Cole with model behaviour
Lily Cole's model behaviour has become infectious this year after the launch of her cruelty-free range of make-up for The Body Shop.
Now more women than ever are becoming concerned over the ethical...
How to do smokey eyes like the 'sexiest woman alive', Mila Kunis
Quickly moving from small star cutie to international knockout Mila Kunis, 29, was recently named by Esquire magazine as the 'sexiest woman alive' thanks to her stunning performances in films such as Black...
Backstage beauty at Paris Fashion Week
Demure but daring, yet again Paris Fashion Week surpasses previous years by delivering classic, polished looks combined with innovative products for a modern edge.
We saw make-up artists swapping...
The perfect work face for the workplace
Make those morning meetings a breeze with bright and fresh make-up tips to keep you looking awake and alert. A great morning routine will ensure you remain fresh-faced throughout the...
Naturally radiant: Create Blake Lively's 'no-makeup' bridal look
Blake Lively kept things simple and intimate for her private September wedding with Ryan Reynolds.
And the gorgeous face of Gucci hit the mark for the perfect bridal face by going au naturel, a source...
Top buns and bare-faced beauty hit New York runways
The Big Apple has brought freshness and fun to the catwalk with its Spring/Summer 2013 collections.
And not just in the world of fashion. A far cry from the deep set smokey eyes and berry lips of this...
Make-up must haves for the Duchess of Cambridge on tour
Since receiving professional lessons from London-based make-up artist Arabella Preston for the royal wedding, the Duchess of Cambridge personally takes care of her beauty regime.
So we're sure Kate...
Make it last with celeb make-up artist Alice Theobald's top tips
Celebrity make-up artist Alice Theobald is often asked how stars such as Kim Kardashian, J-Lo and Jennifer Aniston always manage to keep their make-up flawless.
Even at big events, after eating, drinking...
Dare to go dark à la Jennifer López, Rihanna and Jessica Alba
During the sizzling summer months, bright colours and natural looks are all the rage. But there is always an exception to the rule.
Fashion designers featured luscious dark lipstick in their autumn-winter...