[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
          Draft            RSVP Reservation Aggregation        June 1999
                Aggregation of RSVP for IPv4 and IPv6 Reservations
          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
          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
          The list of current Internet-Drafts can be accessed at
          The list of Internet-Draft Shadow Directories can be accessed at
          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 required for
          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: December 1999          [Page 1]

          Draft            RSVP Reservation Aggregation        June 1999
          1.  Introduction
          A key problem in the design of RSVP version 1 [RSVP] 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), thus
          enabling aggregation of scheduling and classification state.
          It may also 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, while at the same
          time enabling reservation state to be aggregated.
          Throughout, we will talk about "Aggregator" and
          "Deaggregator", referring to the routers at the ingress and
          egress edges of an aggregation region. Exactly how a router
          determines whether it should perform the role of aggregator or
          deaggregator is described below.
          We will refer to the individual reserved sessions (the
          sessions we are attempting to aggregate) as "end-to-end"
          reservations ("E2E" for short), and to their respective
          Path/Resv messages as E2E Path/Resv messages. We refer to the
          the larger reservation (that which represents many E2E
          reservations) as an "aggregate" reservation, and its
          respective Path/Resv messages as "aggregate Path/Resv
          1.1.  Problem Statement: Aggregation Of E2E 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
          Baker et al.       Expiration: December 1999          [Page 2]

          Draft            RSVP Reservation Aggregation        June 1999
          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.
          1.2.  Proposed Solution
          The solution we propose involves the aggregation of several
          E2E 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.
          Aggregation depends on being able to hide E2E RSVP messages
          from routers inside the aggregation region. To achieve this
          end, the IP Protocol Number in the E2E reservation's PATH,
          PATH-TEAR, and RESV-CONFIRM messages is changed from RSVP (46)
          to RSVP-E2E-IGNORE (a new value, to be assigned) upon entering
          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 they are
          forwarded to an inside interface. Since the deaggregating
          router perceives the previous hop on such messages to be the
          aggregating router, RESV and other messages do not require
          this modification; they are unicast from system to system
          The token buckets (SENDER_TSPECs and FLOWSPECS) of E2E
          reservations are summed into the corresponding information
          elements in aggregate PATH and RESV messages. Aggregate PATH
          Baker et al.       Expiration: December 1999          [Page 3]

          Draft            RSVP Reservation Aggregation        June 1999
          messages are sent from the aggregator to the deaggregator(s)
          using RSVP's normal IP Protocol Number. Aggregate RESV
          messages are sent back from the deaggregator to the
          aggregator, thus establishing an aggregate reservation on
          behalf of the set of E2E flows that use this aggregator and
          deaggregator. There may be several such aggregate reservations
          between the same two routers, representing different classes
          of traffic; the aggregate reservation is therefore for the
          traffic marked with a particular DSCP Group.
          1.3.  Definitions
          We define an "aggregation region" as a set of RSVP-capable
          routers for which E2E RSVP messages arriving on an outside
          interface of one router 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 E2E RSVP message is said to have crossed the
          aggregation region.
          We define the "aggregating" router for this E2E flow as the
          first router that processes the E2E Path message as it enters
          the aggregation region (i.e., the one which forwards the
          message from an outside interface to an inside interface).
          We define the "deaggregating" router for this E2E flow as the
          last router to process the E2E Path as it leaves the
          aggregation region (i.e., the one which forwards the message
          from an inside interface to an outside interface).
          We define an "interior" router for this E2E 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 perform neither aggregation nor deaggregation
          for this flow.
          1.4.  Detailed Aspects of Proposed Solution
          A number of issues jump to mind in considering this model.
          Baker et al.       Expiration: December 1999          [Page 4]

          Draft            RSVP Reservation Aggregation        June 1999
          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
          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
          it. This bandwidth may be adjusted based on the total amount
          of aggregated reservation traffic assigned to the same class.
          There are numerous options for exactly which Diff-serv PHBs
          might be used for different classes of traffic as it crosses
          the aggregation region. This is the "service mapping" problem
          described in [ISDS], and is applicable to situations broader
          than those described in this document.  Arguments can be made
          for using either EF or one or more AF PHBs for aggregated
          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 does not exceed 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-
          Therefore, while some RSVP reservation 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 aggregate
          reservation class (rather than per aggregate reservation)
          inside the aggregation region. For example, if Guaranteed
          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 inside interface.
          Baker et al.       Expiration: December 1999          [Page 5]

          Draft            RSVP Reservation Aggregation        June 1999
          1.4.2.  Deaggregator Determination
          The first question is "How do we know which aggregate
          reservation a particular E2E flow should aggregate into?" To
          know that, we must know three things: 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 an E2E flow has
          arrived at an aggregator when its PATH message arrives at a
          router on an outside interface and must be forwarded on an
          inside interface.
          The DSCP is equally easy, or at least it is in concept. The
          DSCP is chosen for an aggregate reservation based on locally
          configured policy, perhaps taking into account such factors as
          the intserv service class requested for the flow. (Some
          details in the exact point at which the DSCP can be determined
          are discussed below.)
          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 the set of routers from which the deaggregator will be
          chosen. In principle, if the aggregator and deaggregator are
          in the same area, then the identity of the deaggregator could
          be determined from the link state database. However, this
          approach would not work in multi-area environments or for
          distance vector protocols.
          One method for Deaggregator determination is manual
          configuration. With this method the network operator would
          configure the Aggregator and the Deaggregator with the
          necessary information.
          Another method allows automatic Deaggregator determination and
          corresponding Aggregator notification. When the E2E RSVP PATH
          message transits from an inside interface to an outside
          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 changes. 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.
          Baker et al.       Expiration: December 1999          [Page 6]

          Draft            RSVP Reservation Aggregation        June 1999
          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 E2E reservations 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 E2E reservation
          changes, which loses one of the key benefits of aggregation,
          the reduction of message processing cost in the aggregation
          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
          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 E2E reservations, while
          endeavoring to change it 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
          aggregate reservation size increase is sufficiently different
          from the trigger condition for aggregate 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
          Baker et al.       Expiration: December 1999          [Page 7]

          Draft            RSVP Reservation Aggregation        June 1999
          is to be established. However, since we are now making
          aggregate reservations by sending a PATH message from an
          aggregating to a deaggregating router, the reserved (E2E) data
          packets no longer carry the same IP addresses as the relevant
          (aggregate) 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 allows 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
          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, an aggregate
          path message 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 E2E
          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
          The case of inter-domain routes differs somewhat from the
          intra-domain case just described. Specifically, best-path
          considerations do not apply, as routing is by a combination of
          routing policy and shortest AS path rather than simple best
          In the case of inter-domain routes, data traffic belonging to
          different E2E sessions (but the same aggregate session) may
          Baker et al.       Expiration: December 1999          [Page 8]

          Draft            RSVP Reservation Aggregation        June 1999
          not enter an aggregation region via the same aggregator
          interface, and/or may not leave via the same deaggregator
          interface. 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.
          We simply note that this problem can occur and needs to be
          allowed for in the implementation. We recommend that each such
          e2e reservation be summed into its appropriate aggregate
          reservation, even though this involves over-reservation.
          1.4.6.  Reservations for Multicast Sessions
          Aggregating reservations for multicast sessions is
          significantly more complex than for unicast sessions. The
          first challenge is to construct a multicast tree for
          distribution of the aggregate Path messages which follows the
          same path as will be followed by the data packets for which
          the aggregate reservation is to be made. This is complicated
          by the fact that the path which is followed by a data packet
          may depend on many factors such as its source address, the
          choice of shared trees or source-specific trees, and the
          location of a rendezvous point for the tree.
          Once the problem of distributing aggregate Path messages is
          solved, there are considerable problems in determining the
          correct amount of resources to reserve at each link along the
          multicast tree. Because of the amount of heterogeneity that
          may exist in an aggregate multicast reservation, it appears
          that it would be necessary to retain information about
          individual E2E reservations within the aggregation region to
          allocate resources correctly. Thus, we may end up with a
          complex set of procedures for forming aggregate reservations
          that do not actually reduce the amount of stored state
          significantly for multicast sessions. [BERSON] describes
          possible ways to reduce this state by using measurement-based
          admission control.
          As noted above, there are several aspects to RSVP state, and
          our approach for unicast aggregates all forms of state:
          classification, scheduling, and reservation state. One
          possible approach to multicast is to focus only on aggregation
          of classification and scheduling state, which are arguably the
          most important because of their impact on the fast path. That
          Baker et al.       Expiration: December 1999          [Page 9]

          Draft            RSVP Reservation Aggregation        June 1999
          approach is the one described in the current draft.
          1.4.7.  Multi-level aggregation
          Ideally, an aggregation scheme should be able to accommodate
          recursive aggregation, with aggregate reservations being
          themselves aggregated. Multi-level aggregation can be
          accomplished using the procedures described here and a simple
          extension to the protocol number swapping process.
          We can consider E2E RSVP reservations to be at aggregation
          level 0. When we aggregate these reservations, we produce
          reservations at aggregation level 1. In general, level n
          reservations may be aggregated to form reservations at level
          When an aggregating router receives an E2E Path, it swaps the
          protocol number from RSVP to RSVP-E2E-IGNORE. In addition, it
          should write the aggregation level (1, in this case) in the 2
          byte field that is present (and currently unused) in the
          router alert option. In general, a router which aggregates
          reservations at level n to create reservations at level n+1
          will write the number n+1 in the router alert field. A router
          which deaggregates level n+1 reservations will examine all
          messages with IP protocol number RSVP-E2E-IGNORE but will
          process the message and swap the protocol number back to RSVP
          only in the case where the router alert field carries the
          number n+1. For any other value, the message is forwarded
          unchanged. Interior routers ignore all messages with IP
          protocol number RSVP-E2E-IGNORE.
          1.4.8.  Reliability Issues
          There are a variety of issues that arise in the context of
          aggregation that would benefit from some form of explicit
          acknowledgment mechanism for RSVP messages. For example,  it
          is possible to configure a set of routers such that an E2E
          PATH of protocol type RSVP-E2E-IGNORE would be effectively
          "black-holed", if it never reached a router which was
          appropriately configured to act as a deaggregator. It could
          then travel all the way to its destination where it would
          probably be ignored due to its non-standard protocol number.
          This situation is not easy to detect. The aggregator can be
          sure this problem has not occurred if a Path Error message is
          received from the deaggregator (as described in detail below).
          Baker et al.       Expiration: December 1999         [Page 10]

          Draft            RSVP Reservation Aggregation        June 1999
          It can also be sure there is no problem if an E2E Resv is
          received. However, the fact that neither of these events has
          happened may only mean that no receiver wishes to reserve
          resources for this session, or it may mean that the PATH was
          black-holed. However, if a neighbor-to-neighbor acknowledgment
          mechanism existed, the aggregator would expect to receive an
          acknowledgment from the deaggregator, and would interpret the
          lack of a response as an indication that a problem of
          configuration existed. It could then refrain from aggregating
          this particular session. We note that such a reliability
          mechanism has been proposed for RSVP in [REFRESH] and propose
          that it be used here.
          Baker et al.       Expiration: December 1999         [Page 11]

          Draft            RSVP Reservation Aggregation        June 1999
          2.  Elements of Procedure
          To implement aggregation, we define a number of elements of
          2.1.  Receipt of E2E Path Message By aggregating router
          The very first event is the arrival of the E2E PATH message at
          an outside interface of an aggregator.  Standard RSVP
          procedures [RSVP] are followed for this, including
          consideration of what set of interfaces it needs to be
          forwarded onto. These interfaces comprise zero or more outside
          interfaces and zero or more inside interfaces.
          Service on outside interfaces is handled as defined in [RSVP].
          Service on inside 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 E2E PATH
          message is forwarded on the inside interface(s) using the IP
          Protocol number RSVP-E2E-IGNORE, but in every other respect
          identically to the way it would be sent by an RSVP router that
          was not performing aggregation.
          2.2.  Handling Of E2E Path Message By Interior Routers
          At this point, the e2e Path message traverses zero or more
          interior routers.  Interior routers receive the e2e Path
          message on an inside interface and forward it on another
          inside interface. The Router Alert IP Option alerts interior
          routers to check internally, but they find that the IP
          Protocol is RSVP-E2E-IGNORE and the next hop interface is
          inside. As such, they simply forward it as a normal IP
          2.3.  Receipt of E2E Path Message By Deaggregating router
          The E2E PATH message finally arrives at a deaggregating
          router, which receives it on an inside interface and forwards
          it on an outside interface. Again, the Router Alert IP Option
          alerts it to intercept the message, but this time the IP
          Protocol is RSVP-E2E-IGNORE and the next hop interface is an
          Baker et al.       Expiration: December 1999         [Page 12]

          Draft            RSVP Reservation Aggregation        June 1999
          outside 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 aggregate path
          message, as described in the following section.
          The deaggregating router changes the e2e Path message's IP
          Protocol from RSVP-E2E-IGNORE to IP Protocol RSVP, updates the
          ADSPEC of the e2e Path using information accumulated by the
          aggregate Path ADSPEC (if an aggregate Path has been
          received), and the E2E PATH message is forwarded towards its
          intended destination. To enable correct updating of the
          ADSPEC, a deaggregating router may wait for the arrival of an
          aggregate Path before forwarding the E2E Path.
          2.4.  Initiation of New Aggregate Path Message By Aggregating
          The aggregating router is responsible to include the
          SENDER_TSPEC information from individual E2E Path messages in
          the SENDER_TSPEC of the aggregate Path message it sends to its
          deaggregating router. The aggregating router may know that an
          E2E session 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 from the deaggregator, or
          it receives an E2E RESV message from the deaggregator. In the
          latter case, the RESV contains a DCLASS object [DCLASS]
          indicating which DSCP the deaggregator believes that the E2E
          flow belongs in. In the former case, the aggregator must make
          its own determination of a suitable DSCP based on the
          information in the E2E Path message(s) being aggregated and
          using locally available policy information.  The identity of
          the deaggregator itself is found in either the ERROR
          SPECIFICATION of the Path Error message or the RSVP HOP object
          of the RESV.
          On receipt of either message, if no corresponding aggregate
          Baker et al.       Expiration: December 1999         [Page 13]

          Draft            RSVP Reservation Aggregation        June 1999
          path state exists from the aggregator to the deaggregator for
          a session with the appropriate DSCP, and the aggregator is
          configured to do so, the aggregator should generate an
          aggregate PATH message for the aggregate reservation. The
          destination address of the aggregate PATH message is the
          address of the deaggregating router, and the message is sent
          with IP protocol number RSVP.
          2.5.  Handling of E2E RESV Message by Deaggregating Router
          Having sent the E2E PATH message on toward the destination,
          the deaggregator must now expect to receive an E2E RESV for
          the session. On receipt, its responsibility is to assure
          itself that there is sufficient bandwidth reserved within the
          aggregation region to support the new E2E reservation, and if
          there is, then to forward the E2E RESV to the aggregating
          If there is insufficient bandwidth reserved, it should follow
          the normal RSVP procedures [RSVP] 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 by increasing the size
          of the flowspec that it includes in the aggregate RESV that it
          sends upstream.
          When sufficient bandwidth is available, it may simply send the
          E2E 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. The choice
          of DSCP may be made based on a combination of information in
          the received E2E RESV and local policy. An example policy
          might dictate a certain DSCP for Guaranteed Service and
          another DSCP for Controlled Load. The de-aggregator will also
          add the token bucket from the FLOWSPEC object into its
          internal understanding of how much of that reservation is in
          2.6.  Initiation of New Aggregate RESV Message By
          Deaggregating Router
          Upon receiving an E2E RESV message on an outside interface,
          and having determined the appropriate DSCP for the session,
          the deaggregator looks for corresponding path state for a
          Baker et al.       Expiration: December 1999         [Page 14]

          Draft            RSVP Reservation Aggregation        June 1999
          session with the chosen DSCP.  If aggregate PATH state exists,
          but no aggregate RESV state exists, the deaggregator creates
          an aggregate RESV and sets its initial request to a value not
          smaller than the requirement of the E2E reservation it is
          If no aggregate PATH state exists for the appropriate DSCP,
          this may be because the aggregator has not yet responded to
          the arrival of the E2E RESV sent in the preceding step. To
          avoid deadlock while waiting for a response, it would be
          desirable to use the acknowledgment mechanisms described in
          Once the deaggregator has the aggregate PATH message, then it
          sends an aggregate RESV message toward the aggregator (i.e.,
          to the previous hop), using the AGGREGATED-RSVP session and
          filter specifications. Since the DSCP is in the SESSION
          object, the DCLASS is unnecessary. The message should be
          reliably delivered using the mechanisms in [REFRESH] or,
          alternatively, the CONFIRM object may be used, to assure that
          the aggregate RESV does indeed arrive and is granted. This
          enables the deaggregator to determine that the requested
          bandwidth is available to allocate to the E2E flows it
          2.7.  Handling of Aggregate RESV Message by Interior Routers
          The aggregate RESV message is handled in essentially the same
          way as defined in [RSVP]. The Session object contains the
          address of the deaggregating router (or the group address for
          the session in the case of multicast) and the DSCP that has
          been chosen for the session. The Filterspec object identifies
          the aggregating router. These routers perform admission
          control and resource allocation as usual and send the
          aggregate RESV on towards the aggregator.
          2.8.  Handling of E2E RESV Message by Aggregating Router
          The E2E 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 E2E reservation is associated with an
          appropriate aggregate, that the aggregator and deaggregator
          expectations synchronize, and that all things are in place. In
          particular, it needs to ensure that the DCLASS carried in the
          Baker et al.       Expiration: December 1999         [Page 15]

          Draft            RSVP Reservation Aggregation        June 1999
          E2E RESV matches the DSCP for an aggregate session to that
          deaggregator; if not, it needs to create a new aggregate Path
          for the appropriate DSCP and send it to the deaggregator. It
          should also assure itself that the SENDER_TSPEC from the E2E
          PATH message has been accumulated into the appropriate
          aggregate PATH message. Under normal circumstances, this is
          the only way it will be informed of this association. It
          should now forward the E2E RESV to its previous hop, following
          normal RSVP processing rules [RSVP].
          2.9.  Removal of E2E Reservation
          E2E 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 E2E 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 E2E
          reservations it supports are no longer active. They must be
          treated accordingly.
          2.11.  Handling of Data On Reserved E2E Flow by Aggregating
          Prior to establishment that a given E2E 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
          Baker et al.       Expiration: December 1999         [Page 16]

          Draft            RSVP Reservation Aggregation        June 1999
          2.12.  Procedures for Multicast Sessions
          Because of the difficulties of aggregating multicast sessions
          described above, we focus on the aggregation of scheduling and
          classification state in the multicast case. The main
          difference between the multicast and unicast cases is that
          rather than sending an aggregate Path message to the unicast
          address of a single deaggregating router, in the multicast
          case we send the "aggregate" Path message to the same group
          address as the E2E session. This ensures that the aggregate
          Path message follows the same route as the E2E Path. This
          difference between unicast and multicast is reflected in the
          Session objects defined below. A consequence of this approach
          is that we continue to have reservation state per multicast
          session inside the aggregation region.
          3.  Protocol Elements
          3.1.  IP Protocol RSVP-E2E-IGNORE
          This specification presumes the assignment of a protocol type
          RSVP-E2E-IGNORE, 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 inside interface, and
          another way when copied to an outside 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
          aggregate session destination, and the DSCP that it will use
          on the E2E data the reservation contains. For unicast
          sessions, the session destination address is address of the
          deaggregating router. For multicast sessions, the session
          destination is the multicast address of the E2E session (or
          sessions) being aggregated.  The inclusion of the DSCP in the
          Baker et al.       Expiration: December 1999         [Page 17]

          Draft            RSVP Reservation Aggregation        June 1999
          session allows for multiple sessions toward the same address
          to be distinguished by their DSCP and queued separately. It
          also provides the means for aggregating scheduling and
          classification state. In the case where a session uses a pair
          of PHBs (e.g. AF11 and AF12), the DSCP used should represent
          the numerically smallest PHB (e.g. AF11). This follows the
          same naming convention described in [BRIM].
          Session types are defined for IPv4 and IPv6 addresses.
                o    IP4 SESSION object: Class = SESSION,
                     C-Type = RSVP-AGGREGATE-IP4
                     |              IPv4 Session Address (4 bytes)           |
                     | /////////// |    Flags    |  /////////  |     DSCP    |
                o    IP6 SESSION object: Class = SESSION,
                     C-Type = RSVP-AGGREGATE-IP6
                     |                                                       |
                     +                                                       +
                     |                                                       |
                     +              IPv6 Session Address (16 bytes)          +
                     |                                                       |
                     +                                                       +
                     |                                                       |
                     | /////////// |    Flags    |  /////////  |     DSCP    |
          3.4.  SENDER_TEMPLATE Object
          The SENDER_TEMPLATE  object identifies the aggregating router
          for the aggregate reservation.
                o    IP4 SENDER_TEMPLATE object: Class = SENDER_TEMPLATE,
                     C-Type = RSVP-AGGREGATE-IP4
                     |                IPv4 Aggregator Address (4 bytes)      |
          Baker et al.       Expiration: December 1999         [Page 18]

          Draft            RSVP Reservation Aggregation        June 1999
                o    IP6 SENDER_TEMPLATE object: Class = SENDER_TEMPLATE,
                     C-Type = RSVP-AGGREGATE-IP6
                     |                                                       |
                     +                                                       +
                     |                                                       |
                     +           IPv6 Aggregator Address (16 bytes)          +
                     |                                                       |
                     +                                                       +
                     |                                                       |
          3.5.  FILTER_SPEC Object
          The FILTER_SPEC object identifies the aggregating router for
          the aggregate reservation, and is syntactically identical to
          the SENDER_TEMPLATE object.
          Baker et al.       Expiration: December 1999         [Page 19]

          Draft            RSVP Reservation Aggregation        June 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 resources 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 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,
          (b)  the trend line over recent history, with 90 or 99%
               statistical confidence.
          We 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: December 1999         [Page 20]

          Draft            RSVP Reservation Aggregation        June 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 acknowledge that published documents and
          discussion with several people, notably John Wroclawski, Steve
          Berson, and Andreas Terzis materially contributed to this
          draft. 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] and by the RSVP tunnels draft
          Baker et al.       Expiration: December 1999         [Page 21]

          Draft            RSVP Reservation Aggregation        June 1999
          8.  References
               Clark, D., S. Shenker, and L. Zhang, "Supporting Real-
               Time Applications in an Integrated Services Packet
               Network: Architecture and Mechanism," in Proc.
               SIGCOMM'92, September 1992.
          [IP] RFC 791, "Internet Protocol". J. Postel. Sep-01-1981.
               RFC 1122, "Requirements for Internet hosts -
               communication layers".  R.T. Braden. Oct-01-1989.
               Nichols, "Differentiated Services Operational Model and
               Definitions", 02/11/1998, draft-nichols-dsopdef-00.txt
               RFC 1958, "Architectural Principles of the Internet". B.
               Carpenter.  June 1996.
               Clark and Wroclawski, "An Approach to Service Allocation
               in the Internet", 08/04/1997, draft-clark-diff-svc-
               Nichols and Zhang, "A Two-bit Differentiated Services
               Architecture for the Internet", 12/23/1997, draft-
               Berson and Vincent. "Aggregation of Internet Integrated
               Services State". draft-berson-rsvp-aggregation-00.txt,
               August 1998
               Brim and Carpenter. "Per Hop Behavior Identification
               Codes". draft-brim-diffserv-phbid-00.txt, April 1999.
               Bernet et al. "Integrated Services Operation Over
               Diffserv Networks". draft-ietf-issll-diffserv-rsvp-
               02.txt, June 1999.
          Baker et al.       Expiration: December 1999         [Page 22]

          Draft            RSVP Reservation Aggregation        June 1999
               Guerin, R., Blake, S. and Herzog, S.,"Aggregating RSVP
               based QoS Requests", Internet Draft, draft-guerin-
               aggreg-rsvp-00.txt, November 1997.
               Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin,
               S., "Resource Reservation Protocol (RSVP) Version 1
               Functional Specification", RFC 2205, September 1997.
               Bernet, Y.,  Durham, D., and F. Reichmeyer, "Requirements
               of Diff-serv Boundary Routers", Internet Draft, draft-
               bernet-diffedge-01.txt, November, 1998.
               Berger, L., Gan, D., and G. Swallow, "RSVP Refresh
               Reduction Extensions", Internet Draft, draft-berger-
               rsvp-refresh-reduct-02.txt, May 1999.
               Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang,
               "RSVP Operation Over IP Tunnels", Internet Draft, draft-
               ietf-rsvp-tunnel-04.txt, May 1999.
               Bernet, Y., "Usage and Format of the DCLASS Object With
               RSVP Signaling", Internet Draft, draft-bernet-dclass-
               01.txt, June 1999.
          9.  Authors' 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: December 1999         [Page 23]

          Draft            RSVP Reservation Aggregation        June 1999
               Francois Le Faucheur
               Cisco Systems
               291, rue Albert Caquot
               06560 Valbonne, 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: December 1999         [Page 24]