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

Versions: 00 01                                                         
          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]