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

Versions: 00                                                            
Internet Draft                                                 S. Berson
Expiration: February 1999                                        USC/ISI
File: draft-berson-rsvp-aggregation-00.txt                    S. Vincent
                                                                 USC/ISI



           Aggregation of Internet Integrated Services State



                             August 7, 1998

Status of Memo

   This document is an Internet-Draft.  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 draft documents 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 "work in progress."

   To learn the current status of any Internet-Draft, please check the
   linebreak "1id-abstracts.txt" listing contained in the Internet-
   Drafts Shadow Directories on ftp.ietf.org (US East Coast),
   nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au
   (Pacific Rim).

Abstract

   The Internet Integrated Services (IIS) architecture[2] has a
   fundamental scaling problem in that per flow state is maintained at
   all routers and end-systems supporting a flow.  This draft examines
   the use of aggregation as a technique to reduce the amount of state
   needed to provide IIS, and describes the modifications to RSVP to
   support aggregation.  In our approach, routers at the edge of a
   region doing aggregation keep detailed IIS state, while in the
   interior of this region, routers keep a greatly reduced amount of
   state.  Packets will be tagged at the edge with scheduling
   information that will be used in place of the detailed IIS state.
   The aggregation scheme described will allow large scale deployment of
   IIS without overloading routers with state and associated processing.






Berson, Vincent        Expiration: February 1998                [Page 1]


Internet Draft              RSVP Aggregation                 August 1998


1. Introduction

   In order to deploy Internet Integrated Services (IIS), additional
   resources are needed in the routers to store state and to process
   packets.  As currently defined [3,2], this state is on a per session
   basis, where a session is a unicast or multicast destination and
   optionally a port.  IIS state is stored at all routers between the
   source(s) and destination(s) of a session.  Thus, widespread use of
   IIS would mean a large amount of state at routers in the core of the
   Internet.  This large amount of state and related processing could
   overwhelm routers, so IIS state models that do not require per-
   session state at all routers need to be explored.

   Several types of per-session state are used with integrated services.
   First, there is scheduling state that consists of the different
   traffic service queues for packet forwarding.  Second, there is
   packet classifier state.  Classifier state is used to assign each
   arriving packet to a packet scheduling queue for forwarding.  Third,
   there is the state for the setup protocol, e.g. state carried in RSVP
   PATH and RESV messages.  Finally, current multicast routing
   algorithms also store state, either per source and session (e.g.
   DVMRP[9], PIM-DM[5]) or per session shared-tree (e.g. CBT[1], PIM-
   SM[5]).  While approaches to aggregation of routing state are similar
   to aggregation of IIS state, they are beyond the scope of this draft.

   Per session state in a router has two detrimental effects.  First,
   additional state consumes memory, and second, additional state
   requires additional CPU cycles to process the state.  Depending on
   the speed with which the memory needs to be accessed, different types
   of memory can be used.  State that is required in order to process
   each packet (e.g. classifier state, scheduling state, and multicast
   routing state) needs to be stored in fast (i.e. cache) memory, while
   other state (e.g. setup protocol state) can be stored in slower
   memory.  Since fast memory is substantially more expensive than slow
   memory, and since accesses to fast memory are on the router fast
   path, our primary goal is to reduce the classifier and scheduler
   state.  Reducing the amount of setup protocol state is an important,
   but secondary goal.

   Any aggregation scheme entails some tradeoffs.  Keeping full
   integrated services state at all routers allows the resources
   dedicated to the flow of packets from each admitted session to be
   isolated from the resources for packets from all other sessions.
   This isolation means that resources reserved and needed for one
   session will be used only on the reserving session.  The disadvantage
   of doing aggregation is the loss of some portion of this flow
   isolation, since with aggregation many flows would share the same
   traffic service class.



Berson, Vincent        Expiration: February 1998                [Page 2]


Internet Draft              RSVP Aggregation                 August 1998


   This draft describes how to provide Internet Integrated Services for
   both unicast and multicast traffic with greatly reduced state
   requirements.  We concentrate primarily on Controlled Load type
   service[10], which reserves bandwidth but not delay or jitter, though
   our approach should be more generally applicable (see [7] for a
   related approach).  With our approach, the amount of scheduler state
   is bounded at all nodes for both unicast and multicast traffic.  For
   unicast traffic, full classifier state and setup protocol state are
   stored only at the edges of the network.  In the interior of the
   network, no unicast setup protocol state is stored, and only a
   bounded amount of classifier state is used.  For multicast traffic, a
   minimal amount of additional classifier state and additional setup
   protocol state is used in the network interior.

   We make several assumptions:


   1.   We assume that an explicitly definable region (e.g. one or more
        contiguous autonomous systems), called an "aggregating region",
        will aggregate and will implement supporting mechanisms at its
        boundary points.  We define an "ingress" of an aggregating
        region as a router where a packet for a specific unicast or
        multicast session enters the region, and an "egress" as a router
        where a packet for a specific session leaves the region.  Also,
        we define an "interior router" for a session as any router in
        the aggregating region that is on the data path for the session
        and is not the ingress or egress.

   2.   We assume that the choice to aggregate and the mechanism used to
        do so is an intra-domain issue, not an inter-domain issue and
        therefore there can be variability across regions so long as at
        the boundaries routers continue to pass along adequate messages
        to support the setup protocol upstream and downstream.

   3.   We assume current multicast and unicast routing within the
        aggregating region; but with no other enhancements.

2. Framework

   Since each network service provider will want to make decisions on
   how to provide integrated services based on their provisioning and
   traffic patterns, a brief review is presented of how IIS state is
   used.

   2.1 Integrated services state

      Scheduler classes are the unit of assignment of network resources.
      Scheduler state typically takes the form of different traffic



Berson, Vincent        Expiration: February 1998                [Page 3]


Internet Draft              RSVP Aggregation                 August 1998


      classes.  These traffic classes are assigned different priorities,
      link shares[6], and policing policies to provide a certain level
      of service.  In the basic IIS model, each traffic flow gets its
      own traffic class, meaning that each flow has certain resources
      dedicated to it.  By reducing the number of traffic classes, a
      coarser granularity of resource assignment is done in that several
      flows will be assigned to the same scheduler queue.  A consequence
      of the coarser granularity is that the aggregated traffic gets a
      certain level of resource usage, but it is impossible inside an
      aggregating region to isolate flows in the same traffic class from
      each other.  This lack of isolation can be mitigated by adequate
      provisioning of network resources and by policing at aggregating
      region borders.

      Classifier state is used to assign packets to traffic classes.
      Each arriving packet is classified into a traffic class at each
      node according to state established by the setup protocol.  In the
      complete absense of classifier state, no service differentiation
      is possible.  However a packet can be classified at the ingress,
      and the results of that classification can be encoded in each
      packet.  This reduced classifier state encoded in a packet can be
      as simple as one or more bits segregating different classes of
      traffic, or alternatively, an encapsulation header.  By encoding a
      small amount of classifier state in the packet, only a very simple
      classification is needed at interior routers.

      Finally setup protocol (e.g. RSVP) state is used to do admission
      control, provide policing, allow reclassification, and allow
      merging of reservation messages.  The first two of these issues,
      admission control and policing, are general issues involving both
      unicast and multicast traffic, while the last two,
      reclassification and reservation merging, are only issues with
      multicast traffic.

      2.1.1 General setup protocol state issues

         Setup protocol state is used in admission control.  Setup
         protocol state contains the amount of resources reserved for
         each admitted flow at a router.  Admission control with full
         IIS state involves computing how much network resources are
         already committed to existing reservations and whether there
         are sufficient resources to admit a new flow with certain
         resource requirements.  In the absence of setup protocol state,
         admission control decisions can be made only on the basis of
         the reservation request control message and load measurements
         on the router.  We call this type of admission control
         "measurement based admission control"[8].




Berson, Vincent        Expiration: February 1998                [Page 4]


Internet Draft              RSVP Aggregation                 August 1998


         Setup protocol state is also used for traffic policing.
         Policing is done in an IIS network at traffic merge points and
         at traffic split points.  A traffic merge point (see Figure a)
         is where the traffic from two or more sources for the same
         session merge.  For an RSVP shared style reservation, the
         traffic from all the sources needs to be policed to the
         reservation parameters at traffic merge points.  This means
         that though the traffic arriving on links L1 and L2 is within
         the reservation parameters, the sum of the traffic exiting on
         link L3 may exceed the reservation parameters.  In this case,
         policing is needed on link L3.

         Policing is also done at traffic split points (see Figure b).
         A traffic split point is where multicast traffic has multiple
         outgoing interfaces.  Because of RSVP reservation merging and
         because some outgoing interfaces may have differing
         reservations, traffic at a split point needs to be policed on
         each outgoing interface to the proper reserved values for that
         interface.  In the figure, link L5 has a reservation Q1 while
         interface L6 has a reservation Q2.  Policing is needed to make
         the traffic on the outgoing links conform to the link
         reservation.

         [ Figure omitted in .txt version - see .ps version ]

             Figure 1: Traffic split and merge nodes

      2.1.2 Multicast setup protocol state issues

         Setup protocol state is used to allow reclassification of
         packets from reserved to best effort.  This reclassification is
         necessary at traffic flow split points (see Figure b) where
         there are one (or more) outgoing interfaces with reservations
         and one (or more) outgoing interfaces without reservations.  In
         the figure, links L5 and L6 have reservations, while link L7
         has no reservation and is forwarding best effort.  Since data
         packets are marked with their with their service class, the
         packets may need to be remarked at traffic split points.  At
         these points packets forwarded to outgoing interfaces with no
         reservations such as link L7 need to be reclassified as best
         effort.

         Finally, setup protocol state is used to merge reservation
         messages coming from the egresses to the ingress.  With setup
         protocol state for each session, and hop by hop processing of
         reservation messages, each router can limit the number of
         reservation refreshes it sends.  Without setup protocol state,
         each reservation refresh message from each egress would be sent



Berson, Vincent        Expiration: February 1998                [Page 5]


Internet Draft              RSVP Aggregation                 August 1998


         to the ingress, requiring a large amount of processing for any
         large multicast groups.

   2.2 Basic aggregation architecture

      We propose a scheme for unicast traffic with a constant amount of
      scheduler state at all routers, a constant amount of classifier
      state at interior routers, and no setup protocol state at interior
      routers.  For multicast traffic, we propose a scheme with bounded
      scheduler state, and greatly reduced classifier and setup protocol
      state.  In our approach, a fixed number of traffic service classes
      are defined and configured at all routers in an aggregating
      region.  Each traffic service class is subject to admission
      control at the ingress to the region.  Traffic policing (and
      reclassification) is done at the ingress for unicast traffic, and
      at the ingress plus at traffic split points for multicast traffic.
      Since only a fixed number of traffic classes are available, the
      scheduler state at all routers is constant.

      Data packets are classified and "tagged" on entry to the
      aggregating region with some identifier indicating to which
      aggregated traffic class the packet should belong.  This
      identifier can consist of some bits in the packet header (e.g.
      type of service bits) or the packet could be encapsulated.  The
      tag (or encapsulation) encodes the traffic service class that this
      packet will receive across the aggregating region.  Tagging or
      encapsulating each packet bounds the amount of classifier state in
      the interior of the aggregating region.

      Full setup protocol state is stored at the borders of the
      aggregating region, but only a small amount of multicast setup
      protocol state is needed in the interior of the region.  When a
      reservation message arrives at an ingress to the region (from an
      egress), and that reservation passes admission control, then
      packets from the flow associated with the new reservation are
      assigned to one of the configured traffic service classes.

      Admission control will be measurement-based, and, since there is
      no unicast and minimal multicast setup protocol state in the
      interior, admission control will be done at the ingress for a
      session.  But the decision will be based on congestion
      measurements within the aggregating region.  Thus each node in the
      aggregating region, upon receiving an admission control setup
      protocol message, will make a local congestion decision.  This
      local congestion decision will be made on a threshold basis where
      new reservations are not admitted if the existing measured load
      plus the expected additional load from the new flow is greater
      than a (possibly dynamic) threshold.



Berson, Vincent        Expiration: February 1998                [Page 6]


Internet Draft              RSVP Aggregation                 August 1998


      To implement the local congestion decision, each node keeps an
      estimate of its current load per traffic class.  As an admission
      control message traverses the path between ingress and egress,
      each interior router must admit that reservation.  Each router
      that provisionally admits the reservation should factor the new
      reservation into its currect traffic estimate.  To admit the flow,
      an estimate of the amount of the reserved traffic due to this
      reservation must be made, e.g. based on peak rate specified in the
      admission control message.  If some router does not admit the
      reservation, the admission control message is marked appropriately
      by the rejecting router and the message is forwarded.  When the
      admission control message arrives at the egress, the egress node
      forwards the control message back to the ingress.  The ingress
      checks the message to see if any router rejected the message.  If
      some router rejected the reservation, then the ingress will reject
      the reservation and send a reservation error message.

      In summary, our approach provides for reduction of packet
      scheduler state, packet classifier state, and setup protocol (e.g.
      RSVP) state in the following ways.  A constant amount of packet
      scheduler state at all routers in an aggregating region is
      achieved by using preconfigured traffic service classes.  A
      constant amount of packet classifier state for unicast traffic at
      all interior routers in the aggregating region is accomplished by
      tagging or encapsulating each packet with its traffic service
      class.  No setup protocol state at interior routers for unicast
      traffic is achieved by doing admission control and policing only
      at the edges of the aggregating region.  For multicast traffic,
      only a small amount of RSVP state is stored at routers, while
      classifier state is stored only at traffic split points and only
      on those outgoing interfaces with no reservation.

   2.3 Multicast setup protocol state

      We would like to apply the above approach to multicast traffic to
      eliminate all of the setup protocol state in the network interior.
      However, there are some fundamental differences between unicast
      and multicast traffic that results in additional setup protocol
      state being desirable.  Since traffic with multiple destinations
      is being classified and tagged at the ingress router, a tagged
      multicast packet will receive reserved service everywhere in the
      cloud, including branches for which there are no reservations.
      This all-or-nothing reservation property, caused by tagging at the
      ingress, complicates aggregating state for multicast sessions.
      The complications derive from two features of multicast sessions,
      "heterogeneity" and "dynamic group membership".  Heterogeneity
      refers to the situation where different branches of a multicast
      distribution tree have different reservations, including the case



Berson, Vincent        Expiration: February 1998                [Page 7]


Internet Draft              RSVP Aggregation                 August 1998


      where some branches have no reservation.  Unreserved packets
      receiving reserved service can adversely affect packet flows that
      properly have a reservation.  Without additional state, there is
      no way to determine which packets have a legitimate reservation.

      The other multicast feature causing complications is dynamic group
      membership.  Dynamic group membership means that the members of a
      multicast session can be changing over time by having new
      receivers join, and old receivers leave.  Due to the all-or-
      nothing property, a new best effort receiver joining a multicast
      session with a reservation in place will be receiving reserved
      service.  Admission control will not have been done for that new
      receiver, and so those reserved packets to the new receiver can
      cause congestion for other properly reserved packets.  Thus a best
      effort receiver can disrupt reserved traffic.

      Our approach to aggregation and multicast is to keep some
      additional setup protocol state for multicast sessions but only at
      split nodes.  Since setup protocol state is not on the router fast
      path, this option is reasonable since scheduler state and
      classifier state are still minimized.  Some additional classifier
      state is needed, but only for sessions with heterogeneous
      branches, and only at those nodes with heterogeneous outgoing
      interfaces.  This classifier state can be established dynamically
      from setup protocol state and routing state.  When a node
      discovers that it has heterogeneous outgoing interfaces,
      classifier entries are established on the best effort branches.
      The packets that the classifier matches have the reserved markings
      removed and new markings inserted indicating that the packets are
      to be forwarded as best effort.

   2.4 Policing in the interior

      There is still an issue with state aggregation and shared (e.g.
      RSVP wildcard or shared explicit) style reservations for unicast
      packets at traffic merge points.  At a merge point, the traffic
      entering the node may conform to the reservation, but the traffic
      exiting the node may be non-conforming due to multiple senders.
      With setup protocol state, the traffic would be policed at the
      merge node.  Since there is no unicast setup protocol state in the
      interior of the network, it is impossible to police the traffic of
      an individual flow in the interior.  The traffic will eventually
      be policed at the next ingress, but may interfere with actual
      reserved traffic between the merge point and the egress.  Since
      the traffic will eventually be policed, there is no "free
      bandwidth" for a user trying to exploit this feature.  However
      there is a security problem where a malicious user could tie up
      reserved bandwidth traffic in a transit network.  The simplest



Berson, Vincent        Expiration: February 1998                [Page 8]


Internet Draft              RSVP Aggregation                 August 1998


      solution to this problem is to limit or prohibit unicast shared
      style reservations, which are of limited usefulness.  Other
      approaches involve detection at the egress of abusive behavior,
      and cancelling the offending reservation.

3. RSVP operations/extensions

   In this section we describe how this aggregation scheme would be
   applied to RSVP.  We assume that a measurement based admission
   control algorithm[8] is defined, and we describe how to utilize this
   system to implement aggregation.  The basic issues are gathering the
   measurement data, keeping track of which reservations are new, and
   describing the appropriate data structures.

   3.1 RSVP protocol changes for aggregation

      In order for RSVP to support aggregation of IIS state, two new
      RSVP message types are needed, admission request (ADREQ) and
      admission reply (ADREP).  The ADREQ is used by an ingress to set
      up the reservation across the aggregating region, while the ADREP
      is used by the egress to report that the reservation has succeeded
      or not.

      In addition to new message types, an admission control object
      (ADMISSION), and an admission control status (STATUS) object types
      are needed.  The ADMISSION object and zero or more STATUS objects
      are included as part of a ADREQ or ADREP message.  The ADMISSION
      object contains a common object header, a handle from the ingress
      node, and some flags.  The handle is included by the ingress node
      on initiating aggregated admission control and is used to uniquely
      identify reservation state on the ingress.  The IP address of the
      ingress is stored in an RSVP_HOP object in the ADREQ message.  The
      STATUS object has a common header, an RSVP_HOP, and a load status.
      The RSVP_HOP object contains the IP address of the node supplying
      the load report, while the load status is the measured load from a
      node.

      The format of the ADREQ and ADREP messages are as follows:

      <ADREQ> ::= <Common Header> <FLOWSPEC> <ADMISSION> <RSVP_HOP>
                     <status_report>

      status_report ::= <empty> | <status_report> <STATUS>

      <ADREP> ::= <Common Header> <ADMISSION> <status_report>

      struct {
              Object_header   header;



Berson, Vincent        Expiration: February 1998                [Page 9]


Internet Draft              RSVP Aggregation                 August 1998


              Handle          handle;
              int             flags;
      } ADMISSION;

      #define ADMITTED        1
      #define REJECTED        0

      struct {
              Object_header   header;
              RSVP_HOP        sess;
              Load            load;
      } STATUS;

      #define RSVP_ADREQ      11
      #define RSVP_ADREP      12


   3.2 RSVP behavior - unicast

      Our approach to collecting measurement information for admission
      control is to originate the state collection from the ingress upon
      receiving an RSVP reservation message (RESV).  When an ingress
      receives a new RSVP RESV message (see figure ) and local admission
      control is successful, the ingress initiates aggregated admission
      control by sending an ADREQ message.  The FLOWSPEC from the RESV
      message is used in the ADREQ message, as well as an ADMISSION
      object containing a handle chosen by the ingress.  The basic
      exchange of messages is shown in Figure .  Note that no processing
      is needed in the interior of the aggregating region on the RESV or
      the preceding PATH messages.  But when the ingress receives a new
      RESV message (i.e. a message for which it has no traffic control
      state), the ingress initiates admission control.  For admission
      control, the ingress sends an ADmission REQuest (ADREQ) message
      hop-by-hop through the interior of the aggregating region to the
      egress (known from the previous RSVP hop field in the RESV
      message).  At each hop through the region, the node attempts to
      admit the reservation.  If admission control succeeds at a node,
      the ADREQ message is forwarded with an optional status object to
      the next hop.  If admission control fails at a node, a failure
      status object is appended to the ADREQ message and then the
      message is forwarded.  When the egress receives the ADREQ message,
      an ADREP message is generated and sent back to the ingress
      containing all the status objects.  The ingress checks if any
      interior node appended a failure status object to the message.  If
      there is no rejection information in the ADREP message, then the
      reservation is accepted and the packets for this flow will be
      marked as reserved.  If there is a failure status object in the
      message, the reservation is rejected and a reservation error



Berson, Vincent        Expiration: February 1998               [Page 10]


Internet Draft              RSVP Aggregation                 August 1998


      message is generated.

      [ Figure omitted in .txt version - see .ps version ]

      Figure 2: Admission control exchange of messages

      Note that if either an ADREQ or an ADREP message is lost, then the
      ingress behaves as a router that lost an RSVP reservation message.
      The ingress will wait until the reservation message is refreshed
      and then send a new ADREQ.

   3.3 RSVP behavior - multicast

      Multicast behavior is more complicated due to the dynamic nature
      of receivers joining and leaving groups and due to the possibility
      that some hosts request reservations while other hosts do not.  In
      figure , there is a sender s1 upstream of router R1 and receivers
      r4 and r5 downstream of routers R4 and R5.  If r4 has a
      reservation for a session and r5 does not, it is important that
      traffic for that session with reserved markings do not travel on
      the R3-R5 link (as the traffic commitments to other sessions over
      that link might be disrupted).  To prevent marked traffic from
      transitting links without a reservation, a "reclassifier" needs to
      be installed on the unreserved link (e.g. R3-R5) to remove the
      reserved traffic bits in the data packets.  With the reserved bits
      removed, the traffic will travel as ordinary best effort.

      [ Figure omitted in .txt version - see .ps version ]

      Figure 3: Internet aggregating region

      In order to reclassify the traffic, RSVP state will be needed at
      traffic split points (such as R3).  The accumulating of RSVP state
      is triggered by the formation of a split point in data traffic.
      When a second (or higher) multicast session join (e.g. over link
      R3-R5) reaches a router (e.g. R3), the router needs to activate
      RSVP state management for that router for that session.  In
      addition, the router needs to establish a reclassifier on the
      newly joined link for the session.

      The next PATH message for this session will be received and
      processed by R3 (and state stored).  If a RESV message is then
      received on R3-R5, an ADREQ message will be sent out the link.
      When an ADREP message is received from the egress (or next
      downstream split point), the reservation is in place.  When the
      reservation is in place on all outgoing links at a node for a
      session, any reclassifiers are removed.  Also, if R3 receives an
      ADREQ from R2 for this session, an ADREP is generated in response.



Berson, Vincent        Expiration: February 1998               [Page 11]


Internet Draft              RSVP Aggregation                 August 1998


      When the penultimate outgoing link is removed from the multicast
      session at a node, the RSVP state accumulation may end, and the
      existing state for this session may be purged.

   3.4 Other approaches

      There are three other possible approaches to aggregated admission
      control that may be useful in certain types of network
      environments, but which have serious limitations in general.  One
      approach is to put the admission control request in RSVP
      reservation messages.  This approach is conceptually simpler than
      the above scheme, but assumes that the reverse route of the data
      (i.e. egress to ingress) through the aggregating region is known.
      There are cases where this holds, most notably in networks using
      link state routing protocols, but in general this is not the case.

      The second approach to collecting admisson control information is
      an RSVP path message which travels on the forward route from data
      ingress to data egress.  When this message is processed at each
      interior node, admission control information is collected.  The
      accumulated admission control information is then included in a
      corresponding RSVP reservation message from egress to ingress.
      The disadvantage with this scheme is that each PATH  message would
      need to be processed by interior routers.  ADREQand ADREP messages
      are only generated on a new reservation.

      The third approach to collecting admission control information is
      by out-of-band communication, e.g. as part of routing protocols.
      In this case, the ingress site can do the admission control based
      on the out-of-band communication.  Further work is needed in this
      area.

4. Reserved traffic congestion

   One last issue is traffic congestion in reserved traffic classes.
   There are two ways that admitted load can cause high levels of
   congestion on a router, (1) measurement based admission control
   failure and (2) link failure.  Measurement based admission control
   failure occurs due to past load not being representative of the
   future.  For example, if many idle reserved sources become very
   active at the same time, some links may become congested.  Link
   failure is caused by a link being declared down and a new set of
   routes are generated.  The traffic that was traversing the failed
   link may now be added to an already heavily loaded link.  In both of
   these cases, links may become overcommitted.

   For small amounts of congestion, reserved traffic can preempt best
   effort traffic, i.e. best effort traffic packets are dropped, but new



Berson, Vincent        Expiration: February 1998               [Page 12]


Internet Draft              RSVP Aggregation                 August 1998


   admission control requests are rejected.  For larger amounts of
   congestion, reserved packets need to be dropped or reservations need
   to be preempted.  For link failure in a per-flow IIS network, the
   setup protocol would typically use reservation preempting (while
   admission control mistakes are expected not to happen).  With
   aggregated IIS state, the point at which the routing changes may not
   have setup protocol state.  Thus a node typically cannot distinguish
   an overload caused by a link failure from one caused by transient
   heavy congestion.  The response is the same for either cause of
   congestion; the ingress nodes in this case will need to preempt
   reservations.

5. Conclusions

   This draft has described a scheme for providing Internet Integrated
   Services with greatly reduced state requirements.  This scheme bounds
   the scheduler state at all routers in an aggregating region.  For
   unicast traffic, the classifier state and setup protocol state is
   stored only at the border routers. For multicast traffic, full
   classifier state is stored at the border routers, while a limited
   amount of additional classifier and additional setup protocol state
   is stored at traffic split points.

6. Acknowledgements

   This draft is the result of discussions with many people particularly
   Bob Braden and Bob Lindell.

REFERENCES

[1] Ballardie, T., Francis, P., and Crowcroft, J., "Core Based Trees
    (CBT): An Architecture for Scalable Inter-Domain Multicast Routing,"
    SIGCOMM '93.

[2] Berson, S., and Vincent, S., "Aggregation of Internet Integrated
    Services State," IWQoS '98.

[3] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S.,
    "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
    Specification," RFC 2205.

[4] Braden, R., Clark, D., and Shenker, S., "Integrated Services in the
    Internet Architecture: an Overview," RFC 1633.

[5] Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Liu, C., and
    Wei, L., "An Architecture for Wide-Area Multicast Routing," SIGCOMM
    '94.




Berson, Vincent        Expiration: February 1998               [Page 13]


Internet Draft              RSVP Aggregation                 August 1998


[6] Floyd, S., and Jacobson, V., "Link-sharing and Resource Management
    Models for Packet Networks," IEEE/ACM Transactions on Networking,
    Vol. 3 No. 4, pp. 365-386, August 1995.

[7] Guerin, R., Blake, S., and Herzog, S., "Aggregating RSVP-based QoS
    Requests," Internet Draft.

[8] Jamin, S., Shenker, S., and Danzig, P., "Comparison of Measurement-
    based Admission Control Algorithms for Controlled-Load Service,"
    Infocomm '97.

[9] Waitzman, D., Partridge, C., and Deering, S., "Distance Vector
    Multicast Routing Protocol," RFC 1075.

[10] Wroclawski, J., "Specification of the Controlled-Load Network
    Element Service," RFC 2211.



Security Considerations

   Security considerations have not been addressed in this draft.

Author's Address

   Steven Berson
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292

   Phone: +1 310 822 1511
   EMail: berson@isi.edu

   Subramaniam Vincent
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292

   Phone: +1 310 822 1511
   EMail: svincent@isi.edu











Berson, Vincent        Expiration: February 1998               [Page 14]