Draft RSVP Reservation Aggregation February 1999 Aggregation of RSVP for IP4 and IP6 Reservations draft-baker-rsvp-aggregation-00.txt This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". Comments should be made to the authors and the rsvp@isi.edu list. Abstract A key problem in the design of RSVP version 1 is, as noted in its applicability statement, that it lacks facilities for aggregation of individual reserved sessions into a common class. The use of such aggregation is recommended in the paper by Clark, Shenker, and Zhang in SIGCOMM '92, and required for scalability. This document describes the use of a single RSVP reservation to aggregate other RSVP reservations across a transit routing region, in a manner conceptually similar to the use of Virtual Paths in an ATM network. It proposes a way to dynamically create the aggregate reservation, classify the traffic for which the aggregate reservation applies, determine how much bandwidth is needed to achieve the requirement, and recover the bandwidth when the sub-reservations are no longer required. It also contains recommendations concerning algorithms and policies for predictive reservations. Baker et al Expiration: August 1999 [Page 1] Draft RSVP Reservation Aggregation February 1999 1. Introduction A key problem in the design of RSVP version 1 is, as noted in its applicability statement, that it lacks facilities for aggregation of individual reserved sessions into a common class. The use of such aggregation is recommended in [CSZ], and required for scalability. The problem of aggregation may be addressed in a variety of ways. For example, it may sometimes be sufficient simply to mark reserved traffic with a suitable DSCP (e.g. EF). It may be desirable to install one or more aggregate reservations from ingress to egress of an "aggregation region" (defined below) where each aggregate reservation carries similarly marked packets from a large number of flows. This is to provide high levels of assurance that the end-to-end requirements of reserved flows will be met. Throughout, we will talk about "Aggregator" and "Deaggregator", referring to the routers at the ingress and egress edges of an aggregation region. 1.1. Problem Statement: Aggregation Of Small Reservations The problem of many small reservations has been extensively discussed, and may be summarized in the observation that each reservation requires a non-trivial amount of message exchange, computation, and memory resources in each router along the way. It would be nice to reduce this to a more manageable level where the load is heaviest and aggregation is possible. Aggregation, however, brings its own challenges. In particular, it reduces the level of isolation between individual flows, implying that one flow may suffer delay from the bursts of another. Synchronization of bursts from different flows may occur. However, there is evidence [CSZ] to suggest that aggregation of flows has no negative effect on the mean delay of the flows, and actually leads to a reduction of delay in the "tail" of the delay distribution (e.g. 99% percentile delay) for the flows. These benefits of aggregation to some extent offset the loss of strict isolation. Baker et al Expiration: August 1999 [Page 2] Draft RSVP Reservation Aggregation February 1999 1.2. Proposed Solution The solution we propose involves the aggregation of several individual reservations that cross an "aggregation region" and share common ingress and egress routers into one larger reservation from ingress to egress. We define an "aggregation region" as a contiguous set of systems capable of performing RSVP aggregation (as defined following) along any possible route through this contiguous set. Communication interfaces fall into two categories with respect to an aggregation region; they are "exterior" to an aggregation region, or they are "interior" to it. Routers that have at least one interface in the region fall into three categories with respect to a given RSVP session; they aggregate, they deaggregate, or they are between an aggregator and a deaggregator. In this case, the IP Protocol Number in the individual reservation's PATH and PATH-TEAR messages is changed from RSVP to AGGREGATED-RSVP within the aggregation region, and restored to RSVP at the deaggregator point. These messages are ignored (no state is stored and the message is forwarded as a normal IP datagram) by each router within the aggregation region whenever a reservation follows an interior interface. Since the deaggregating router perceives the previous hop on such messages to be in aggregating router, other RESV and other messages do not require this modification; they are unicast from system to system anyway. The token buckets (SENDER_TSPECs and FLOWSPECS) of these reservations are, however, summed into the corresponding information elements in aggregate PATH and RESV messages. These PATH messages are sent from the aggregator to the deaggregator(s) using RSVP's normal IP Protocol Number. The RESV messages are sent back from the deaggregator to the aggregator, thus establishing an aggregate reservation on behalf of the set of individual flows that use this aggregator and deaggregator. There may be several such reservations between the same two routers, representing different classes of traffic; the reservation is therefore for the traffic marked with a particular DSCP Group. Baker et al Expiration: August 1999 [Page 3] Draft RSVP Reservation Aggregation February 1999 1.3. Definitions We define an "aggregation region" as a set of RSVP-capable routers for which normal RSVP messages arriving on an outside interface of one router would in the set would traverse one or more inside interfaces (of this and/or other routers in the set) before finally traversing an outside interface. Such an RSVP message is said to have crossed the aggreagation region. We define the "ingress" router for this flow as the first router (the one which forwards the message from an ouside interface to an inside interface). The ingress router performs aggregation for this flow. We define the "egress" router for this flow as the last router (the one which forwards the message from an inside interface to an outside interface). The egress router performs deaggregation for this flow. We define an "interior" router for this flow as any router in the aggregation region which receives this message on an inside interface and forwards it to another inside interface. Interior routers neither perform aggregation nor deaggregation for this flow. 1.4. Detailed Aspects of Proposed Solution A number of issues jump to mind in considering this model. 1.4.1. Traffic Classification Within The Aggregation region One of the reasons that RSVP Version 1 did not identify a way to aggregate sessions was that there was not a clear way to classify the aggregate. With the development of the Differentiated Services architecture, this is at least partially resolved; traffic of a particular class can be marked with a given DSCP and so classified. We presume this model. We presume that on each link en route, a queue, WDM color, or similar management component is set aside for all aggregated traffic of the same class, and that sufficient bandwidth is made available to carry the traffic that has been assigned to Baker et al Expiration: August 1999 [Page 4] Draft RSVP Reservation Aggregation February 1999 it. This bandwidth may be adjusted based on the total amount of aggregated reservation traffic assigned to the same class. Since the total offered load of reserved traffic is known based on the Tspecs and Rspecs of the aggregated reservations, it is reasonable to use the Expedited Forwarding PHB [EF] for the aggregate reservations, or two similar local PHBs with differing code points, prioritizing CBR voice over VBR video. However, it may also be desirable to use one or more of the AF classes for aggregated reservations. This allows non- conformant traffic to be nevertheless forwarded as part of the aggregate reservation, but with lower drop precedence. Independent of which PHB is used, care needs to be take in an environment where provisioned Diff-Serv and aggregated RSVP are used in the same network, to ensure that the total offered load for a single PHB is not excessive relative to the link capacity allocated to that PHB. One solution to this is to reserve one of the four AF classes strictly for the aggregated reservation traffic while using other AF classes for provisioned Diff-Serv. Therefore, while a RSVP state per aggregate reservation is maintained inside the aggregation region, a single classification and scheduling state (e.g., a DSCP used for classifying traffic) is maintained per aggregation reservation class (rather than per aggregate reservation) inside the aggregation region. For example, if "cbr-voice" service is represented by the EF DSCP throughout the aggregation region, there may be a reservation for each aggregator/deaggregator pair in each router, but only the EF DSCP need be inspected at each interior interface. 1.4.2. Deaggregator Determination The first question is "How do we know which aggregate reservation a particular flow should aggregate into?" To know that, we must know three items of information: its aggregating router, its deaggregating router, and (assuming DSCPs are used to differentiate among various reservations between the same two routers), the relevant DSCP. The aggregator is trivial: we know that a flow reservation has arrived at an aggregator when its PATH message arrives at a so-configured system from another region. The DSCP is equally easy, or at least it is in concept. Whatever policy would set the DSCP in so doing selects the DSCP for the aggregate Baker et al Expiration: August 1999 [Page 5] Draft RSVP Reservation Aggregation February 1999 reservation. The deaggregator is more involved. If an SPF routing protocol, such as OSPF or IS-IS, is in use, and if it has been extended to advertise information on Deaggregation roles, it can tell us what selection of routers the deaggregator will be chosen from among. However, if that set contains more than one router, it would not tell us which. Also, even if the Link State protocol was extended as mentioned above, multi-area operation is likely to prevent proper advertisement of the Deaggregation attributes and thus deaggregator selection. One method for Deaggregator determination is manual configuration. With this method the network operator would configure the Aggregator and the Deaggregator the necessary information. Another method allows automatic Deaggregator determination and corresponding Aggregator notification. When the RSVP PATH message transits from either an aggregator or an interior interface to a deaggregator interface, the deaggregating router must advise the aggregating router of the correlation between itself and the flow. This has the nice attribute of not being specific to the routing protocol. It also has the property of automatically adjusting to route change. For instance, if because of a topology change, another Deaggregator is now on the shortest path, this method will automatically identify the new Deaggregator and swap to it. 1.4.3. Size of Aggregate Reservations A range of options exist for determining the size of the aggregate reservation, presenting a tradeoff between simplicity and scalability. Simplistically, the size of the aggregate reservation needs to be greater than or equal to the sum of the bandwidth of the connections it aggregates, and its burst capacity must be greater than or equal to the sum of their burst capacities. However, if followed religiously, this leads us to change the bandwidth of the aggregate reservation each time an underlying reservation changes, which loses one of the key benefits of aggregation, the reduction of message processing cost in the aggregation region. We assume, therefore, that there is some policy, not defined in this specification (although sample policies are suggested which have the necessary characteristics). This policy Baker et al Expiration: August 1999 [Page 6] Draft RSVP Reservation Aggregation February 1999 maintains the amount of bandwidth on a given aggregate reservation at an amount greater than or equal to the sum of the bandwidths of its underlying reservations, while changing it but infrequently. This may require some level of trend analysis if there is a significant probability that in the next interval of time the current aggregate reservation will be exhausted, the router must predict the necessary bandwidth and request it. If the router has a significant amount of bandwidth reserved but has very little probability of using it, the policy may be to predict the amount of bandwidth required and release the excess. This policy is likely to benefit from introduction of some hysteresis (i.e. ensure that the trigger condition for reservation size increase is sufficiently different from the trigger condition for reservation size decrease) to avoid oscillation in stable conditions. Clearly, the definition and operation of such policies are as much business issues as they are technical, and are out of the scope of this document. 1.4.4. Intra-domain Routes RSVP directly handles route changes, in that reservations follow the routes that their data follow. This follows from the property that PATH messages contain the same IP source and destination address as the data flow for which a reservation is to be established. However, since we are now making aggregate reservations by sending a PATH message from an ingress to an egress router, the reserved data packets no longer carry the same IP addresses as the relevant PATH message. The issue becomes one of making sure that data packets for reserved flows follow the same path as the PATH message that established Path state for the aggregate reservation. Several approaches are viable. First, the data may be tunneled from aggregator to deaggregator, using technologies such as IP-in-IP tunnels, GRE tunnels, MPLS labeled tunnels, and so on. These each have particular advantages, especially MPLS, which admits traffic engineering. They each also have some cost in link overhead and configuration complexity. If data is not tunneled, then we are depending a characteristic of IP best metric routing , which is that if Baker et al Expiration: August 1999 [Page 7] Draft RSVP Reservation Aggregation February 1999 the route from A to Z includes the path from H to L, and the best metric route was chosen all along the way, then the best metric route was chosen from H to L. Therefore, a path which crosses a given aggregator and deaggregator will of necessity use the best path between them. If this is a single path, the problem is solved. If it is a multi-path route, then we are forced to determine, perhaps by measurement, what proportion of the traffic for a given reservation is passing along each of the paths, and assure ourselves of sufficient bandwidth for the present use. A simple, though inelegant, way of doing this is to reserve the total capacity of the aggregate route down each path. For this reason, we believe it is advantageous to use one of the above-mentioned tunneling mechanisms in cases where multi-path routes may exist. 1.4.5. Inter-domain Routes Again, RSVP responds directly to route changes, in that reservations follow the routes that their data follow. However, in this case, the best-path considerations do not apply, as routing is by a combination of routing policy and shortest AS path rather than simple best metric. In this case, we must presume that a data flow might come in on different aggregator interfaces and leave on different deaggregator interfaces. It is possible that we could identify this occurrence in some central system which sees the reservation information for both of the apparent sessions, but it is not clear that we could determine a priori how much traffic went one way or the other apart from measurement. As a result, we simply note that the problem can occur and needs to be allowed for in the implementation. We recommend that each such flow reservation be summed into each appropriate aggregate reservation, even though this involves over-reservation. 1.4.6. Reservations for Intra-domain Multicast Routing Multicast routing, in this framework, acts much like a superset of multipath unicast routing. It differs in that the information from a given aggregator may divide at some Baker et al Expiration: August 1999 [Page 8] Draft RSVP Reservation Aggregation February 1999 interior router and proceed to more than one deaggregator. For this reason, we recommend that multicast routes use a distinct set of DSCPs, and that a form of shared explicit reservation be used. Since such reservations must be from one source (aggregator) to multiple destinations (deaggregator), and Shared Explicit (SE) reservations traverse one session and many filter specifications, we therefore choose to identify the aggregator in the session object and the deaggregator in the filter object. 1.4.7. Reservations for Inter-domain Multicast Routing to be filled in: Baker et al Expiration: August 1999 [Page 9] Draft RSVP Reservation Aggregation February 1999 2. Elements of Procedure To implement this, we define a number of elements of procedure. 2.1. Receipt of Flow Reservation Path Message By aggregating router The very first event is the arrival of the PATH message for a microflow at an exterior interface of an aggregator. RSVP version 1's standard procedures are followed for this, including consideration of what set of interfaces it needs to be forwarded onto. These interfaces comprise zero or more deaggregator interfaces and zero or more interior interfaces. Service on deaggregator interfaces is handled as defined in RSVP Version 1. Service on interior interfaces is complicated by the fact that the message needs to be included in some number of aggregate reservations, but at this point it is not known which one, because the deaggregator is not known. Therefore, the PATH message is forwarded on the interface using the IP Protocol number RSVP-AGGREGATE, but in every other respect identically to the way it would be sent by RSVP Version 1. 2.2. Handling Of Flow Reservation Path Message By Interior Routers At this point, the message traverses zero or more interior routers, which receive an RSVP-AGGREGATE message on an interior interface and forward it to another interior interface. The Router Alert IP Option alerts them to check internally, but they find that the IP Protocol is RSVP- AGGREGATE and the next hop interface is interior. As such, they simply forward it as a normal IP datagram. 2.3. Receipt of Flow Reservation Path Message By Deaggregating router The PATH message finally arrives at a deaggegating router, which receives it from an interior interface and forwards it to an external interface. Again, the Router Alert IP Option alerts it to intercept the message, but this time the IP Baker et al Expiration: August 1999 [Page 10] Draft RSVP Reservation Aggregation February 1999 Protocol is RSVP-AGGREGATE and the next hop interface is an external interface. At this point, the deaggregating router associates the flow with an aggregate reservation. This selection is done on the basis of policy, and may take into account not only the aggregating router (whose IP Address may be found in the RSVP Hop Object) but other information about the flow. If no such aggregate reservation exists and the router is so configured, it may generate a PATH ERROR with code NEW-AGGREGATE-NEEDED back to the aggregating router. This should not result in any reservation being taken down, but may result in the aggregating router initiating the necessary path message. The message is also changed from IP Protocol RSVP-AGGREGATE back to IP Protocol RSVP, the ADSPEC information accumulated by that aggregate reservation added into this ADSPEC, and the PATH message is forwarded towards its intended destination. 2.4. Initiation of New Aggregate Reservation Path Message By Aggregating router The aggregating router is responsible to include the SENDER_TSPEC information from individual flow reservations in the SENDER_TSPEC being announced to its deaggregating router. It may know that a reservation is associated with a given deaggregator when one of two events occurs: it receives a PATH ERROR message with the error code NEW-AGGREGATE-NEEDED, or when it receives an RESV message from the deaggregator for the flow. The DCLASS object in the message indicates which DSCP the deaggregator believes that the flow belongs in. The identity of the deaggregator itself is to be found in the ERROR SPECIFICATION or the RSVP HOP object. On receipt of either, if no corresponding aggregate reservation exists and the router is configured to do so, it should generate a PATH message for the aggregate reservation. The destination address of the PATH message is the address of the deaggregating router, and the message is sent with IP protocol number RSVP. For multicast, the PATH message could be sent to an "All Deaggregators" multicast address. Shared Explicit signaling could also be used to direct shared multicasts directly to each of the indicated egress points. This latter, while requiring perhaps a few more messages, means that we need Baker et al Expiration: August 1999 [Page 11] Draft RSVP Reservation Aggregation February 1999 neither a set of multicast addresses corresponding to all permutations of possible egress routers, nor a way to handle excess irrelevant messages. 2.5. Handling of Flow Reservation RESV Message by Deaggregating Router Having sent the flow PATH message on toward the destination, the router must now expect to receive an RESV for the session. On receipt, its responsibility is to assure itself that there is sufficient bandwidth reserved to accomplish the task, and if there is, then to forward the RESV to the aggregating router. Note that there is discussion among the authors as to whether the aggregator or the de-aggregator should assure that the aggregate reservation has enough bandwidth to support the individual flow. If there is insufficient bandwidth reserved, it should follow the RSVP Version 1 procedures for a reservation being placed with insufficient bandwidth to support the reservation. It may also immediately attempt to increase the aggregate reservation that is supplying bandwidth. When sufficient bandwidth is available, it may now simply send an RESV message with IP Protocol RSVP to the aggregating router. This message should, in addition to other data, contain the DCLASS object to indicate which DSCP the deaggregating router expects the aggregator to use. It will also add the token bucket from the FLOWSPEC object into its internal understanding of how much of that reservation is in use. 2.6. Initiation of New Aggregate Reservation RESV Message By Deaggregating Router If there is a PATH message for the aggregate reservation but no RESV message, at this point the deaggregating router should create such an RESV and set its initial request to a value not smaller than the requirement of the flow it is supporting. If there is not a PATH message, a deadlock exists; the sender has not created one, meaning that it may have missed the PATH ERROR message intended to trigger the event, or it may have Baker et al Expiration: August 1999 [Page 12] Draft RSVP Reservation Aggregation February 1999 not been configured to create the message. The deaggregator should generate the necessary state with which to respond to such a PATH message, initiate a PATH ERROR message as a retransmission, and quiesce. Once it has the PATH message for the aggregate, the deaggregator sends a normal RESV message toward the aggregator (e.g., to the previous hop), using the AGGREGATED-RSVP session and filter specifications. Since the DSCP is in the SESSION object, the DCLASS is unnecessary. However, the CONFIRM object should be used, to assure that the reservation does indeed arrive and is granted. The de-aggregator may presume any confirmed bandwidth to be available to allocate to the flows it supports. 2.7. Handling of Flow Reservation RESV Message by Interior Routers The RESV is handled in the usual manner, with respect to bandwidth allocation and other aspects. However, since the flow of the reservation differs from that of other session types, it bears explaining. RSVP V1 sessions proceed from a set of senders to a receiver or class of receivers. For this reason, RSVP V1 uses the receiver's address in the SESSION object and places senders in the FILTER SPECIFICATION. This is backwards of that - aggregated RSVP sessions proceed from a single aggregator towards one or more deaggregators. Therefore, the aggregator's IP Address is used in the SESSION object, and the filter-list is essentially a list of receivers. The interior routers, therefore, apply either the FF or SE flow merging rules as appropriate, and in the multicast case forward toward the aggregator the union of the sets of FILTER specifications. 2.8. Handling of Flow Reservation RESV Message by Aggregating Router The RESV message is the final confirmation to the aggregating router that a proportion of a given aggregate's bandwidth has been reserved. At this point, it should assure itself that the flow reservation is associated with an appropriate aggregate, that the aggregator and deaggregator expectations synchronize, Baker et al Expiration: August 1999 [Page 13] Draft RSVP Reservation Aggregation February 1999 and that all things are in place. It should also assure itself that the SENDER_TSPEC from the PATH message has been accumulated into the aggregate PATH message. Under normal circumstances, this is the only way it will be informed of this association. It should now forward the flow's RESV to its previous hop, following RSVP Version 1 rules. 2.9. Removal of Flow Reservation Flow reservations are removed in the usual way via PATH TEAR, RESV TEAR, timeout, or as the result of an error condition. When they are removed, their FLOWSPEC information must also be removed from the allocated portion of the aggregate reservation. This same bandwidth may be re-used for other traffic in the near future. When PATH messages are removed, their SENDER_TSPEC information must also be removed from the aggregate PATH. 2.10. Removal of Aggregate Reservation Should an aggregate reservation go away (presumably due to a configuration change, route change, or policy event), the reservations it supports are no longer active. They must be treated accordingly. 2.11. Handling of Data On Reserved Flow by Aggregating Router Prior to establishment that a given flow is part of a given aggregate, the flow's data should be treated as general best effort traffic by whatever policies prevail for such. Generally, this will mean being given the same throughput behavior as non-essential traffic. However, upon establishing that, the aggregating router is responsible to mark any related traffic with the correct DSCP and forward it in the manner appropriate to traffic on that reservation. This may imply forwarding it to a given IP next hop, or piping it down a given link layer circuit, tunnel, or MPLS label switched path. Baker et al Expiration: August 1999 [Page 14] Draft RSVP Reservation Aggregation February 1999 3. Protocol Elements 3.1. IP Protocol RSVP-AGGREGATE This specification presumes the assignment of a protocol type RSVP-AGGREGATE, whose number is at this point TBD. This is used only on messages which require a router alert (PATH, PATH ERROR, and RESV CONFIRM), and signifies that the message must be treated one way when copied to an interior interface, and another way when copied to en exterior interface. 3.2. Path Error Code A PATH ERROR code NEW-AGGREGATE-NEEDED is presumed. This value does not signify that a terminal error has occurred, but that an action is required of the aggregating router to avoid an error condition in the near future. 3.3. SESSION Object The SESSION object contains two values: the IP Address of the aggregating router, and the DSCP that it will use on the data the reservation contains. This is exactly backwards of RSVP Version 1, and is intended to support shared explicit multicast reservations along a network route branching away from the aggregator. Two types must be designed: one specifying the aggregator by its IP4 Address, and one specifying the aggregator by its IP6 address. o IP4 SESSION object: Class = SESSION, C-Type = RSVP-AGGREGATE-IP4 +-------------+-------------+-------------+-------------+ | IPv4 Aggregator Address (4 bytes) | +-------------+-------------+-------------+-------------+ | /////////// | Flags | ///////// | DSCP | +-------------+-------------+-------------+-------------+ o IP6 SESSION object: Class = SESSION, C-Type = RSVP-AGGREGATE-IP6 +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 Aggregator Address (16 bytes) + | | Baker et al Expiration: August 1999 [Page 15] Draft RSVP Reservation Aggregation February 1999 + + | | +-------------+-------------+-------------+-------------+ | /////////// | Flags | ///////// | DSCP | +-------------+-------------+-------------+-------------+ 3.4. SENDER_TEMPLATE Object The SENDER_TEMPLATE is omitted from PATH messages for aggregate reservations. 3.5. FILTER Object The FILTER object identifies the deaggregating router, or set of deaggregating routers in the event that there are several. o IP4 SESSION object: Class = FILTER, C-Type = RSVP-AGGREGATE-IP4 +-------------+-------------+-------------+-------------+ | IPv4 De-aggregator Address (4 bytes) | +-------------+-------------+-------------+-------------+ o IP6 SESSION object: Class = FILTER, C-Type = RSVP-AGGREGATE-IP6 +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 De-aggregator Address (16 bytes) | | | + + | | +-------------+-------------+-------------+-------------+ 3.6. DCLASS Object The DCLASS object indicates the DSCP that the deaggregator expects the aggregator to use in marking the data. This may be used for coherence checks. o DCLASS object: Class = DCLASS, C-Type = Diff-serv +-------------+-------------+-------------+-------------+ | ////////////////////////////////////// | DSCP | Baker et al Expiration: August 1999 [Page 16] Draft RSVP Reservation Aggregation February 1999 +-------------+-------------+-------------+-------------+ Baker et al Expiration: August 1999 [Page 17] Draft RSVP Reservation Aggregation February 1999 4. Policies and Algorithms For Predictive Management Of Blocks Of Bandwidth The exact policies used in determining how much bandwidth should be allocated to an aggregate reservation at any given time are beyond the scope of this document, and may be proprietary to the service provider in question. However, here we explore some of the issues and suggest approaches. In short, the ideal condition is that the aggregate reservation always has enough to allocate to any flow reservation that requires its support, and never takes too much. Simply stated, but more difficult to achieve. Factors that come into account include significant times in the diurnal cycle: one may find that a large number of people start placing calls at 8:00 AM, even though the hour from 7:00 to 8:00 is dead calm. They also include recent history: if more people have been placing calls recently than have been finishing them, a prediction of the necessary bandwidth a few moments hence may call for more bandwidth than is currently allocated. Likewise, at the end of a busy period, we may find that the trend calls for declining reservation amounts. We would recommend a policy something along this line. At any given time, one should expect that the amount of bandwidth required for the aggregate reservation is the larger of the following: (a) a requirement known a priori, such as from history of the diurnal cycle at a particular week day and time of day, and (b) the trend line over recent history, with 90 or 99% statistical confidence. We would further expect that changes to that aggregate reservation would be made no more often than every few minutes, and ideally perhaps on larger granularity such as fifteen minute intervals or hourly. The finer the granularity, the greater the level of signaling required, while the coarser the granularity, the greater the chance for error, and the need to recover from that error. In general, we expect that the aggregate reservation will not ever add up to exactly the sum of the reservations it supports, but rather will be an integer multiple of some block reservation size, which exceeds that value. Baker et al Expiration: August 1999 [Page 18] Draft RSVP Reservation Aggregation February 1999 5. Security Considerations Numerous security issues pertain to this document; for example, the loss of an aggregate reservation to an aggressor causes many calls to operate unreserved, and the reservation of a great excess of bandwidth may result in a denial of service. However, these issues are not confined to this extension: RSVP itself has them. We believe that the security mechanisms in RSVP address these issues as well. 6. IANA Considerations Beyond allocating an IP Protocol, a PATH ERROR code, and an RSVP Addressing object "type", there are no IANA issues in this document. We do not define an object that will itself require assignment by IANA. 7. Acknowledgments The authors freely acknowledge that published documents and discussion with several people materially contributed to the correct specification of this function. The design derives directly from an internet draft by Roch Guerin [Guerin] and from Steve Berson's drafts on the subject. It is also influenced by the design in the diff-edge draft by Bernet et al [Bernet]. Baker et al Expiration: August 1999 [Page 19] Draft RSVP Reservation Aggregation February 1999 8. References [IP] RFC 791, "Internet Protocol". J. Postel. Sep-01-1981. [HOSTREQ] RFC 1122, "Requirements for Internet hosts - communication layers". R.T. Braden. Oct-01-1989. [FRAMEWORK] Nichols, "Differentiated Services Operational Model and Definitions", 02/11/1998, draft-nichols-dsopdef-00.txt [PRINCIPLES] RFC 1958, "Architectural Principles of the Internet". B. Carpenter. June 1996. [ASSURED] Clark and Wroclawski, "An Approach to Service Allocation in the Internet", 08/04/1997, draft-clark-diff-svc- alloc-00.txt [BROKER] Nichols and Zhang, "A Two-bit Differentiated Services Architecture for the Internet", 12/23/1997, draft- nichols-diff-svc-arch-00.txt {BERSON] Berson and Vincent. Aggregation of Internet Integrated Services State. draft-berson-rsvp-aggregation-00.txt, August 1998 9. Author's Addresses Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, California 93111 Phone: (408) 526-4257 Email: fred@cisco.com Carol Iturralde Cisco Systems 250 Apollo Drive Chelmsford MA,01824 USA Phone: 978-244-8532 Email: cei@cisco.com Baker et al Expiration: August 1999 [Page 20] Draft RSVP Reservation Aggregation February 1999 Francois Le Faucheur Cisco Systems Office: 16 av du Quebec, Villebon-BP 706, 91961 Les Ulis - France Phone: +33.1.6918 6266 Email: flefauch@cisco.com Bruce Davie Cisco Systems 250 Apollo Drive Chelmsford MA,01824 USA Phone: 978-244-8921 Email: bdavie@cisco.com Baker et al Expiration: August 1999 [Page 21]