[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Internet Draft                                      Y. Bernet, Microsoft
Expiration:  August 1999                          R. Yavatkar, Microsoft
File: draft-ietf-diffserv-rsvp-02.ps                  P. Ford, Microsoft
                                                         F. Baker, Cisco
                                                          L. Zhang, UCLA
                                                       K. Nichols, Cisco
                                              M. Speer, Sun Microsystems
                                                          R. Braden, ISI



         Interoperation of RSVP/Int-Serv and Diff-Serv Networks



                           February 26, 1999

Status of Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   linebreak http://www.ietf.org/shadow.html.

Abstract

   Differentiated Services (diff-serv) and RSVP/Integrated Services
   (RSVP/int-serv) provide complementary approaches to the problem of
   providing QoS for Internet end systems.  These approachs must be able
   to coexist and effectively interoperate.  This document outlines one
   important model for such interoperation, in which diff-serv is used
   by transit networks in the core of the Internet while hosts and edge
   networks use RSVP/int-serv.  It also contains a brief discussion of
   some alternative models for interoperation.





Bernet, Ed. et. al      Expiration:  August 1999                [Page 1]


Internet Draft         Use Of RSVP with Diffserv           February 1999


1. Introduction

   Work on QoS-enabled IP networks has led to two distinct approaches:
   the Integrated Services (int-serv) architecture [12] and its
   signaling protocol RSVP [1], and the Differentiated Services (diff-
   serv) architecture [10].

   RSVP enables applications to signal per-flow QoS requirements to the
   network, with explicit admission control.  Int-serv uses RSVP
   signaling to request tight QoS with quantitative parameters.  Int-
   serv also imposes fine-grain policing and scheduling of traffic, to
   ensure that admitted flows receive their service requests in strict
   isolation from each other and from best-effort traffic.  RSVP
   signaling configures packet classifiers in the int-serv capable
   routers along the path of the flow.  These classifiers perform a
   fine-grain or `MF' [10] classification of packets, using on IP
   addresses and port numbers for example.

   Some basic limitations to the RSVP/int-serv model have impeded its
   deployment in the Internet at large.

   o    The use of per-flow state and per-flow processing raises
        scalability concerns for large networks.

   o    Only a small number of hosts currently generate RSVP signaling.
        While this number is expected to grow dramatically, some
        applications may never generate RSVP signaling.

   o    Some applications require a form of QoS that cannot be expressed
        using the int-serv model.

   o    The necessary policy control mechanisms -- access control,
        authentication, and accounting -- are not available.

   The market is pushing for immediate deployment of a QoS solution that
   addresses the needs of the Internet as well as enterprise networks.
   This push led to the development of Differentiated Services.  In
   contrast to the per-flow orientation of int-serv and RSVP, diff-serv
   networks classify packets into one of a small number of aggregated
   flows or "classes", based on bits set in the TOS field of each
   packet's IP header.  This is known as `BA' classification [10].  In
   addition to eliminating the requirement for per-flow state, diff-serv
   QoS can initially be deployed using long-term provisioning rather
   than short-term reservations established by end-to-end signaling.

   We view int-serv and diff-serv as complementary tools in the pursuit
   of end-to-end QoS.  For many applications, the loose or "qualitative"
   QoS provided by diff-serv will be adequate.  However, some



Bernet, Ed. et. al      Expiration:  August 1999                [Page 2]


Internet Draft         Use Of RSVP with Diffserv           February 1999


   applications will require the tight quantitative end-to-end QoS
   assurance provided by int-serv and RSVP. Current examples of
   applications that need tight QoS include IP-telephony, video-on-
   demand, and various non-multimedia mission-critical applications, and
   such applications may proliferate in the future. The diff-serv
   mechanisms that are deployed must be able to interoperate effectively
   with hosts and networks that provide per-flow QoS using int-serv
   models.

   There are several different models for coexistence and interoperation
   between RSVP/int-serv and diff-serv.  This draft is primarily
   concerned with one important model, although Section 5 presents a
   brief look at other models.  Under our model, diff-serv mechanisms
   are used within transit networks in the `core' of the network, while
   RSVP/int-serv mechanisms are used within stub networks at the 'edge'.
   From the int-serv viewpoint, the diff-serv transit network is treated
   as a virtual link connecting int-serv/RSVP capable routers.  This
   model builds upon work in progress on RSVP aggregation [8, 15].

   This model will provide a framework that will allow deployment of
   diff-serv networks and deployment of RSVP/int-serv networks to
   proceed at their own pace, providing immediate incremental benefits
   in areas of the network in which one or the other is deployed and
   additional benefits where both are deployed.  Ultimately, we want
   RSVP/int-serv and diff-serv mechanisms to interact seamlessly.
   Network administrators should be able to determine for their own
   networks the degree to which diff-serv capabilities are pushed
   towards the edge of their networks, or the degree to which RSVP/int-
   serv capabilities are pushed towards the core of the Internet.

   Section 2 provides an overview of our model for interoperation
   between int-serv and diff-serv, and discusses some of the
   assumptions.  Section 3 presents the model in more detail, while
   Section 4 discusses its implications for diff-serv.  Finally, Section
   5 briefly lists some other possible models for interoperation.
   Appendix A contains a list of some important terms used in this
   document.

   Even though one of the goals of this draft is to describe a framework
   for co-existence of RSVP/int-serv with diff-serv, the draft currently
   does not address the issues specific to IP multicast flows.  See
   Section 5.

2. Overview of the Model

   This section examines the issues in providing tight quantitative
   end-to-end QoS over end-to-end paths that includes both int-serv
   networks and diff-serv networks, and introduces our model.



Bernet, Ed. et. al      Expiration:  August 1999                [Page 3]


Internet Draft         Use Of RSVP with Diffserv           February 1999


   2.1 Quantitative End-to-End QoS

      The primary focus of this document on end-to-end quantitative QoS.
      Although quantitative QoS applications may generate only a small
      fraction of all traffic, servicing this traffic may comprise a
      significant fraction of the revenues associated with QoS. In
      addition, while qualitative QoS applications can be satisfied by
      conventional diff-serv alone, quantitative QoS applications
      require additional support.

      Diff-serv is expected to define some well-defined edge-to-edge
      services, which will be formed by concatenation of the `per-hop-
      behaviors' (PHBs [10]) that are being defined for internal diff-
      serv routers, possibly with some defined shaping and/or policing
      at the ingress.  Our model assumes that it will be possible to map
      the quantitative QoS services defined by int-serv into these
      diff-serv services within the diff-serv network, in order to
      satisfy the end-to-end requirement of a quantitative QoS
      application.

   2.2 Packet Marking

      Within the diff-serv regions of the network, traffic is allotted
      service based on the contents of the DS-field in the IP headers.
      Setting the DS-field is referred to as `marking' the packet.  QoS
      applications must be able to effect the correct marking of DS-
      fields before their packets enter a diff-serv network.  There are
      two choices for accomplishing this.

      Host Marking
           Hosts may directly mark DS-fields in the packets transmitted
           by QoS applications.  Such marking may be based on host
           configuration or on local communication between QoS
           applications and the host operating system.

      Int-serv Router Marking
           Routers external to the diff-serv network may mark DS-fields
           on behalf of QoS applications, based on MF classification.
           The MF classifier might be dynamically configured by RSVP
           signaling between QoS applications, or it might be controlled
           statically by manual configuration or automated configuration
           scripts.

      MF classification is expected to be limited to examination of the
      network and transport-layer (port) fields of a packet.  An
      advantage of host marking is that it allows marking to depend upon
      application-specific information that cannot be deduced from MF
      classification.  For example, consider the need to give



Bernet, Ed. et. al      Expiration:  August 1999                [Page 4]


Internet Draft         Use Of RSVP with Diffserv           February 1999


      preferential service to a website's home page (over other, less
      important pages at the site) or the case of encrypted traffic
      flows (IPSEC).

      The information required to express useful mappings of application
      traffic flows to service levels is likely to be quite complex and
      to change frequently.  Thus, manual configuration is likely to
      impose a significant management burden.  If the configuration
      information is very simple and does not change over time, the
      management burden may be relatively minor; however, this means
      that the granularity of allotting service levels to flows will be
      sub-optimal.  These considerations argue for host-based marking or
      for dynamic configuration of a router's classifier/marker in
      response to application requests.

   2.3 Granularity of Allotment

      The term `granularity' is used here to refer to the degree of
      specificity that is available in allotting a specific service
      level to a specific traffic flow.  There are two measures of
      allotment granularity: granularity of packet classification and
      temporal granularity.

      Fine grain classification might implement the following
      requirement: "Telephony traffic from user X is allotted service
      level A, while telephony traffic from user Y is allotted service
      level B, and web traffic from any user is allotted service level
      C."  Coarse grain classification might be limited to something of
      the form: "All traffic from subnet 1.0.0.0 receives service level
      A, while all traffic from subnet 2.0.0.0 receives service level
      B."

      Temporal granularity determines the frequency with which the
      service allotted to a flow may change.  A temporally fine grain
      system would allow immediate changes in allotment of service
      levels to traffic flows, with times of the order of seconds or
      less.  A temporally coarse-grained system might have service
      levels set by static provisioning with time frames of days or
      weeks.

   2.4 Policing

      It may be necessary to protect the network by policing at various
      points, within the stub network and/or at the interface to the
      transit network. For example, within the stub network, first-hop
      routers may police the aggregate traffic coming from a host to
      ensure that the host is not exceeding its traffic limit.




Bernet, Ed. et. al      Expiration:  August 1999                [Page 5]


Internet Draft         Use Of RSVP with Diffserv           February 1999


      It should be noted that some diff-serv PHBs (e.g., a "billing" PHB
      [14]) may not require any policing at all at any point in the
      network.

   2.5 Admission Control

      Under RSVP/int-serv, quantitative QoS applications use RSVP to
      submit QoS requests to explicit admission control at each hop of
      the end-to-end path.  Integrated Services admission control (ISAC)
      may be avoided only on hops that are known to be sufficiently
      over-provisioned to satisfy the service requirements.  When a
      request is rejected, the host application may choose to try again
      with a smaller request or to accept the best-effort service
      available everywhere along the path, or it may simply avoid
      sending traffic.  These mechanisms protect traffic on flows that
      were previously admitted.

      In diff-serv regions of the network, admission control may be
      provided implicitly by policing at ingress points, based on
      provisioning.  However, to support end-to-end tight QoS, explicit
      admission control must be applied to the virtual hop represented
      by the diff-serv transit network.  An diff-serv service level used
      by the int-serv traffic is provisioned for some maximum level of
      traffic.  The admission control function must ensure that this
      limit is not exceeded by the total int-serv traffic submitted for
      this class.

   2.6 Policy Control

      QoS support provides preferential treatment to particular traffic
      flows.  As a result, admission control must be based on policy as
      well as on resource availability.

      In an int-serv network, resource-based admission control is
      handled by RSVP enabled routers (and SBMs [2]), and is typically
      at the granularity of individual users.  Policy based admission
      control is handled by RSVP-capable policy servers.  These assure
      that int-serv network resources are allotted to users according to
      policy specific to the int-serv network.  In addition, policy
      servers within the int-serv network must assure that appropriate
      policy is applied when diff-serv resources are allotted to int-
      serv users.

      In a diff-serv network, resource and policy-based admission
      control are handled by entities such as bandwidth brokers.  Policy
      decisions made within the diff-serv network are likely to be at
      the granularity of peer networks.  In general, the diff-serv
      network may make multiple service levels available to a single



Bernet, Ed. et. al      Expiration:  August 1999                [Page 6]


Internet Draft         Use Of RSVP with Diffserv           February 1999


      peer int-serv network.

3. Description of Model

   We envision an internet that consists of RSVP/int-serv capable stub
   networks interconnected by diff-serv capable transit networks.  The
   simplest example of this model is a diff-serv capable transit network
   and two RSVP/int-serv capable stub networks, as shown in Figure 1.
   The transit network contains a mesh of routers, at least some of
   which are diff-serv capable.  The stub networks contain meshes of
   routers, at least some of which are int-serv capable.


         /  Stub         /  Transit         /  Stub          /  Network      /   Network        /  Network        |            |   |               |   |            |
 |---| |        |---|   |---|       |---|   |---|        | |---|
 |Tx |-|        |ER1|---|BR1|       |BR2|---|ER2|        |-|Rx |
 |---| |        |-- |   |---|       |---|   |---|        | |---|
       |            |   |               |   |            |
         RSVP/    /       diff-serv  /      RSVP/    /
         int-serv/                  /       int-serv/

                 Figure 1: Sample Network Configuration


   In the interest of simplicity, Figure 1 shows a single QoS sender Tx
   on one of the stub networks and a single QoS receiver Rx on the
   other.  The edge routers (ER1, ER2) within the RSVP/int-serv networks
   interface to the border routers (BR1, BR1) of the diff-serv network.

   From an economic viewpoint, we may consider that the transit network
   sells service to the stub networks, which in turn sell service to end
   systems.  Thus, we may think of the stub networks as customers of the
   transit network.  In the following, we use the term "customer" for
   each of the stub networks in Figure 1.

   3.1 Components of the Model

      We now define the major components of the proposed model.

      3.1.1 Hosts

         Both sending and receiving hosts use RSVP to communicate the
         quantitative QoS requirements of QoS-aware applications running
         on the host.  Typically, a QoS process within the host
         operating system generates RSVP signaling on behalf of the
         applications; this process may also invoke local traffic
         control.




Bernet, Ed. et. al      Expiration:  August 1999                [Page 7]


Internet Draft         Use Of RSVP with Diffserv           February 1999


         Traffic control in the host may mark the DS-field in
         transmitted packets, and it may shape transmitted traffic to
         the requirements of the int-serv service in use.
         Alternatively, the first-hop router within the int-serv network
         may provide these traffic control functions.

      3.1.2 End-to-End RSVP Signaling

         We assume that RSVP signaling messages travel end-to-end
         between hosts Tx and Rx to support int-serv reservations in the
         stub networks.  We require that these end-to-end RSVP messages
         be tunneled transparently across the diff-serv transit network.
         Mechanisms for this purpose are proposed in [8]; they do not
         require the routers in the transit network to
         understand/interpret RSVP messages and do not adversely impact
         the transit network.

      3.1.3 Edge Routers

         We choose to place the boundary between the RSVP/int-serv
         region and the diff-serv region of the network within the edge
         routers.  It is helpful to think of an edge router as
         consisting of two halves: a standard RSVP half, which
         interfaces to a stub network, and a diff-serv half, which
         interfaces to the transit network.  The RSVP half has full RSVP
         capability.  It is able to do MF classification, if required,
         and it is able to police traffic that will be passed to the
         border router.

         The diff-serv half of the edge router provides an interface to
         the diff-serv network's admission control function, which we
         refer to as as `DSAC' (Diff-Serv Admission Control).

         The customer(s) (owner(s) of the stub networks) and the carrier
         owning the transit network will negotiate a contract for the
         capacity to be provided at each of a number of standard diff-
         serv service levels.  If the service agreement between the stub
         networks and the transit networks is statically provisioned,
         then the DSAC can be simply based upon a table that specifies
         capacity at each service level.  If the service agreement is
         dynamic, the DSAC may communicate with counterparts within the
         diff-serv network (such as a bandwidth broker [4]) in order to
         make admission control decisions based on provisioned limits as
         well as the topology and the capacity of the diff-serv network.

         Since the individual int-serv flows are policed according to
         int-serv rules within the stub network, the edge router needs
         to shape only the aggregate stream, not the individual flows.



Bernet, Ed. et. al      Expiration:  August 1999                [Page 8]


Internet Draft         Use Of RSVP with Diffserv           February 1999


      3.1.4 Border Routers

         BR1 and BR2 are diff-serv capable border routers, and are not
         required to run RSVP.  They are expected to implement the
         policing function of diff-serv ingress routers, based on the
         results of a BA classifier.  They are required neither to
         provide MF classification nor to mark the DS-field (with the
         possible exception of differential marking to indicate out-of-
         profile traffic [10, 8]).

      3.1.5 Stub Networks

         A stub network consists of int-serv capable hosts and some
         number of routers.  These routers may reasonably be assumed to
         be RSVP/int-serv capable, although this might not be required
         for a small over-provisioned stub network.  If they are not
         int-serv capable, we assume that they are not capable of per-
         flow classification, signaling, or admission control and will
         pass RSVP messages unhindered.

      3.1.6 Transit Network

         The transit network is not typically capable of per-flow
         classification, signaling, and admission control.  It provides
         two or more levels of service based on the DS-field in the
         headers of carried packets (diff-serv capable).  Furthermore,
         the transit network is able to carry RSVP messages
         transparently, with minimal or no impact on its performance
         (see [8]).  The transit network may include multiple carrier
         networks.

      3.1.7 Service Mapping

         RSVP signaling requests carry an int-serv service type and a
         set of quantitative parameters known as a "flowspec"; these
         describe the QoS expected from the int-serv regions of the
         network.  At each hop in an int-serv network, the generic int-
         serv service requests are interpreted in a form meaningful to
         the specific link layer medium.  For example, at an ATM hop, a
         VC of the correct type (CBR, ABR or VBR) is established [13].
         At an 802.1 hop, the int-serv service type is mapped to an
         appropriate 802.1p priority level [5].

         In our model, the entire diff-serv network plays the role of a
         single virtual link layer as far as RSVP/int-serv are
         concerned.  Therefore, the int-serv service request must be
         mapped to the DS-field when the packets enter the diff-serv
         cloud.  The requested int-serv service must be mapped to a



Bernet, Ed. et. al      Expiration:  August 1999                [Page 9]


Internet Draft         Use Of RSVP with Diffserv           February 1999


         diff-serv service level that can reasonably extend the int-serv
         service type requested by the application.  The edge router can
         then provide admission control to the diff-serv network by
         accepting or rejecting the request based on the capacity
         available at the requested diff-serv service level.

         One of two schemes may be used to map int-serv service types to
         diff-serv service levels.

         Default

              In this scheme, there is some standard, well-known mapping
              from int-serv service type to a PHB that will invoke the
              appropriate behavior in the diffserv network.

              To improve the quality of the mapping, it may prove
              necessary to add additional information to an int-serv QoS
              request.  For example, consider QoS requests for two
              different flows, one interactive voice traffic and the
              other latency-tolerant traffic.  They may both have the
              same int-serv parameters (especially using the Controlled
              Load service), but they are likely to map to different
              diff-serv services.  For this reason, we suggest adding a
              qualifier to the int-serv service type indicating its
              relative latency tolerance (high or low).  The qualifier
              would be defined as a standard object in int-serv
              signaling messages.

         Customer-Specified

              In this scheme, the edge routers in the customer (stub)
              networks are allowed to modify the service mapping.  RESV
              messages originating at hosts will carry the usual int-
              serv service type (perhaps with a qualifier, as described
              above).  When a RESV message arrives at the edge router
              from which the traffic enters the diff-serv region (e.g.,
              router ER1 in Figure 1), the edge router determines the
              PHB code point that should be used to obtain the
              corresponding diff-serv service level.  This information
              is appended to the RESV message by ER1 and carried to the
              sending host.  When the RESV message arrives at the
              sending host, the sender (or intermediate int-serv
              routers) start marking outgoing packets with the indicated
              PHB code point.

         A decision to override the well-known service mapping at the
         edge router may be based on configuration and/or a policy
         decision.  For example, when a reservation request arrives at



Bernet, Ed. et. al      Expiration:  August 1999               [Page 10]


Internet Draft         Use Of RSVP with Diffserv           February 1999


         the ingress to a diff-serv network, if accepted reservations
         have already reached the pre-negotiated capacity limit at the
         corresponding service level then the edge router may decide to
         use a PHB corresponding to a different service level, based on
         an administratively-set policy.

   3.2 Example: Obtaining End-to-End QoS

      The following sequence illustrates the process by which an
      application obtains end-to-end QoS.

      1.   The QoS process on the sending host Tx generates an RSVP PATH
           message that describes the traffic offered by the sending
           application.

      2.   The PATH message is carried toward the receiving host Rx.  In
           the sender's stub network, standard RSVP processing is
           applied at RSVP capable nodes (routers, SBMs, etc).

      3.   At the edge router ER1, the PATH message is subjected to
           standard RSVP processing and PATH state is installed in the
           router.  The PATH message is sent onward, to the transit
           network.

      4.   The PATH message is carried transparently through the transit
           network, and then processed in stub router ER2 according to
           standard RSVP processing rules.

      5.   When the PATH message reaches the receiving host Rx, its QoS
           process generates an RSVP RESV message, indicating interest
           in the offered traffic at a certain int-serv service level.

      6.   The RESV message is carried back towards the sending host.
           Consistent with standard RSVP processing, it may be rejected
           at any RSVP node in the receiver's stub network if resources
           are deemed insufficient to carry the traffic requested.

      7.   At ER2, the RESV message is subjected to standard RSVP
           processing.  It may be rejected if resources on the
           downstream interface of ER2 are deemed insufficient to carry
           the resources requested.  If it is not rejected, it will be
           carried transparently through the transit network, arriving
           at ER1.

      8.   In ER1, the RESV message triggers DSAC processing.  The DSAC
           compares the resources requested to the resources available
           at the corresponding diff-serv service level, in the diff-
           serv enabled transit network.  If the RESV message is



Bernet, Ed. et. al      Expiration:  August 1999               [Page 11]


Internet Draft         Use Of RSVP with Diffserv           February 1999


           admitted, the DSAC updates the available capacity for the
           service class, by subtracting the approved resources from the
           available capacity.

      9.   Assuming the available capacity is sufficient, the RESV
           message is admitted and is allowed to continue upstream
           towards the sending host.  If the available capacity is
           insufficient, the RESV message is rejected and the available
           capacity for the service class remains unchanged.

      10.  The RESV message proceeds through the sender's stub network.
           RSVP nodes in the sending stub network may reject it.  If it
           is not rejected, it will arrive at the sender host Tx.

      11.  At Tx, the QoS process receives the RESV message.  It
           interprets receipt of the message as an indication that the
           specified traffic has been admitted for the specified int-
           serv service type (in the RSVP enabled regions of the
           network) and for the corresponding diff-serv service level
           (in the diff-serv enabled regions of the network).

           Tx begins to set the DS-field in the headers of transmitted
           packets to the value which maps to the Intserv service type
           specified in the admitted RESV message.

      In this manner, we obtain end-to-end QoS through a combination of
      networks that support RSVP style reservations and networks that
      support diff-serv style prioritization.  The successful arrival of
      RESV messages at the original sender indicates that admission
      control has succeeded both in the RSVP regions of the network and
      in the diff-serv regions of the network.

   3.3 Variations of the Model

      It is useful to consider some variations of the model just
      presented.

      3.3.1 Moving the Boundary

         We have assumed that the boundary between the RSVP/int-serv
         network and the diff-serv network lies in the edge routers.
         Alternative models could shift this boundary to the left or to
         the right in Figure 1.  It could for example, be placed within
         the border routers in the transit network.  In this case, the
         DSAC would be implemented entirely within the diff-serv network
         (and would essentially be the bandwidth broker proposed in
         [4]); however, it would require that the diff-serv border
         routers be RSVP capable.



Bernet, Ed. et. al      Expiration:  August 1999               [Page 12]


Internet Draft         Use Of RSVP with Diffserv           February 1999


         Alternative, the boundary could be shifted all the way to the
         end hosts.  This would mean that the traffic was using diff-
         serv mechanisms in the stub networks as well as the transit
         network, while the int-serv mechanisms would be only in the
         host.  The QoS-aware application could still use RSVP within
         the lost to signal its needs.  The host would implement per-
         flow policing, the DSAC function, and packet marking.

      3.3.2 Service Agreements

         o    Statically-Provisioned Service Agreements

              In the simplest model, service agreements are negotiated
              statically between stub networks and transit networks.  A
              service agreement consists of a table of capacities
              available to a stub network, at each diff-serv service
              level.  In this case, DSAC functionality is provided at
              the edge routers in the stub networks.  The `diff-serv
              half' of these routers appear to the `RSVP half' as a
              sending interface with resource limits defined by the
              service agreement table.  While there may be bandwidth
              brokers and dynamic provisioning within the transit
              networks, these are not coupled with the int-serv stub
              networks, and admission control in the two regions of the
              network is completely independent.

         o    Dynamic Service Agreements

              In a more sophisticated model, service agreements between
              customer stub networks and carrier transit networks are
              more dynamic.  Customers may be able to dynamically
              request changes to the service agreement.  In this case, a
              statically provisioned edge router cannot provide the
              required DSAC functionality.  Instead, DSAC functionality
              must be provided by coupling the stub network's admission
              control with the transit network's admission control.

              The two admission control mechanisms meet at the boundary
              between the diff-serv network and the int-serv network.
              This boundary may be implemented at the edge router (in
              the stub network), at the border router (in the transit
              network), or at the bandwidth broker for the int-serv
              network.

              Note that coupling int-serv and diff-serv admission
              control does not imply that each int-serv admission
              control request will result in DSAC processing.  Int-serv
              admission control requests may be aggregated at the



Bernet, Ed. et. al      Expiration:  August 1999               [Page 13]


Internet Draft         Use Of RSVP with Diffserv           February 1999


              boundary between the int-serv and the diff-serv network.
              For example, int-serv admission control requests may
              trigger DSAC requests to bandwidth brokers only when some
              high-water or low-water resource threshold is crossed.
              Separate high-water and low-water thresholds can provide
              hysteresis to prevent thrashing.





         %.cm In the latter case, any MF classification on %.cm behalf
         of the diff-serv ingress point is provided as a service to the
         %.cm customer and goes beyond policing requirements).

      3.3.3 Setting the DS-field

         Allowing hosts to set the DS-field directly may alarm network
         administrators.  The obvious concern is that hosts may attempt
         to 'steal' resources.  In fact, hosts may attempt to exceed the
         negotiated capacity at a particular service level regardless of
         whether they invoke this service level directly (by setting the
         DS-byte) or indirectly (by submitting traffic that classifies
         in an intermediate router to a particular diff-serv PHB).

         In summary, the security concerns of marking the DS-field at
         the edge of the network can be dismissed since each carrier
         will have to do some form of policing (per-flow or per-host) at
         their boundary anyway.  Furthermore, this approach reduces the
         granularity at which border routers must police, thereby
         pushing finer grain shaping and policing responsibility to the
         edges of the network, where it scales better.  The carriers are
         thus focused on the task of protecting their transit networks,
         while the customers are focused on the task of shaping and
         policing their own traffic to be in compliance with their
         negotiated token bucket parameters.

         It is also possible to mark the DS-field at intermediate
         routers rather than at the host and still realize many of the
         benefits of our approach.  In this case, intermediate routers
         may use the RSVP signaling to configure an MF classifier and
         marker.  Then the configuration of MF classifiers and markers
         would be dynamic (minimizing the management burden), and full
         resource- and policy-based admission control could be applied.

         The disadvantages of marking the DS-field at intermediate
         routers (instead of the host) are that full MF classifiers are
         required at the intermediate nodes and that responsibility for



Bernet, Ed. et. al      Expiration:  August 1999               [Page 14]


Internet Draft         Use Of RSVP with Diffserv           February 1999


         traffic separation is shifted away from the host.

         Nonetheless, marking at intermediate routers will be necessary
         to support those hosts which support RSVP signaling but are
         incapable of marking the DS-field.  In addition, there may be
         cases in which the network administrators wish to shift the
         responsibility for traffic separation away from the hosts.  In
         particular, we expect that there will continue to be a need for
         top-down provisioned MF classification, especially for
         qualitative (as opposed to quantitative) QoS applications.  See
         Section 5.2.

4. Implications for Diff-Serv

   We have described a framework for end-to-end QoS in which a diff-serv
   network can be included as a segment of an int-serv path.  This
   section discusses some of the implications of this framework for
   diff-serv.

   4.1 Requirements for Diff-Serv

      In order to use a diff-serv network as described in this draft,
      the diff-serv network must satisfy the following requirements.

      1.   A diff-serv network must be able to provide standard QoS
           services between its border routers, and such a service must
           be selectable by specifying a standard code in a (PHB) sub-
           field of the DS-field of a packet.

      2.   There must be appropriate service mappings from int-serv
           services into these diff-serv services.

      3.   Diff-serv networks must provide admission control information
           to the int-serv network.  This information can be provided by
           a dynamic protocol or, at the very least, through static
           service level agreements.

      4.   Diff-serv networks must be able to transparently carry RSVP
           messages, in such a manner that they can be recovered at the
           egress point from the diff-serv network.

   4.2 End-to-End Integrity of the DS-field

      Our model assumes that int-serv networks uses a code point of the
      DS-field in order to specify the desired PHB within the transit
      network.  It also assumes that packets submitted to the transit
      network specifying a certain DS-field will receive a standard
      service throughout the transit network.  Strictly speaking, this



Bernet, Ed. et. al      Expiration:  August 1999               [Page 15]


Internet Draft         Use Of RSVP with Diffserv           February 1999


      does not dictate that the transit network must leave the DS-field
      field intact.  For example, the border router may map a DS-field
      value set by the host or edge router to a different value before
      forwarding the data packets.

      However, we see little value in allowing the PHB field to be
      altered within the network.  This is likely to perpetuate local
      and incompatible interpretations of the field.

   4.3 Policing and Shaping

      We are assuming that border routers will police in aggregate.  As
      a result, the customer cannot rely on border routers to provide
      traffic isolation between the customer's flows, when policing or
      shaping.  Instead, it is the customer's responsibility to ensure
      that the customer's flows are properly shaped and policed within
      the customer's sending network.  Overall, this approach simplifies
      border routers and still allows protection against misbehaving
      hosts/users.

      Ideally, hosts should provide per-flow shaping at their sending
      interfaces.  However, there is always a chance that the customer's
      traffic will become distorted as it nears the boundary between the
      customer and the carrier.  In this case, the customer should do
      per flow policing (or even re-shaping) at the egress point from
      the customer's network unless the policing agreement at the other
      side is known to accommodate the transient bursts that can arise
      from adding the flows.


   4.4 Managing Resource Pools

      Network administrators must be able to share diff-serv network
      resources between three types of traffic:

      a. Quantitative (explicitly signaled) QoS application traffic

      b. Qualitative (implicitly signaled) QoS application traffic

      c. All other (best-effort) traffic

      These pools must be isolated from each other by the appropriate
      configuration of policers and classifiers at ingress points to the
      diff-serv network, and by appropriate provisioning within the
      diff-serv network.  To provide protection for quantitative QoS
      traffic in diff-serv regions of the network, we suggest that the
      DS codepoints allotted to such traffic must not overlap the
      codepoints assigned to other traffic (qualitative QoS and best-



Bernet, Ed. et. al      Expiration:  August 1999               [Page 16]


Internet Draft         Use Of RSVP with Diffserv           February 1999


      effort traffic).

5. Other Models

   5.1 RSVP and Diff-Serv

      Since RSVP was originally designed to support int-serv, we use the
      term "RVSP/int-serv" as the complement to diff-serv.  However,
      RSVP and int-serv are separable, and RSVP may be used as a
      general-purpose QoS signaling protocol.  For example, RSVP might
      be used for dynamic provisioning and admission control in the
      diff-serv region of the network.  Routers in the diff-serv region
      would continue use the DS-field in the IP header to identify and
      offer services to flow aggregates.

   5.2 Qualitative QoS

      This document has focused largely on the class of applications
      that use RSVP to explicitly signal per-flow QoS requirements and
      that expect end-to-end tight QoS assurances.  We have been
      referring to these applications as `quantitative QoS
      applications'.  Suitable end-to-end services must also be
      available to qualitative QoS applications.  The services that
      these applications require are generally less demanding.

      Qualitative services can be obtained from the diff-serv regions of
      the network with loose top-down provisioning.  Network managers
      can configure classifiers at the ingress to the diff-serv network
      to recognize traffic requiring specific qualitative service
      levels.  Thus, these classification fields are used as a form of
      implicit signaling.  In the int-serv portion of the network,
      qualitative QoS applications can get best-effort service, which
      may be good enough.

      There would be no explicit admission control for such qualitative
      QoS applications.  Therefore, it is difficult to assure that the
      total traffic offered at an ingress point will not exceed the
      provisioned capacity for a particular service level.  When the
      traffic exceeds the allowed limit, there is only indirect feedback
      to the applications, in the form of packet loss or an Congestion
      Experienced mark from Explicit Congestion Notification (ECN).
      Thus, traffic from qualitative applications can be offered only
      loose QoS.

   5.3 Multicasting

      <To be written>




Bernet, Ed. et. al      Expiration:  August 1999               [Page 17]


Internet Draft         Use Of RSVP with Diffserv           February 1999


6. Security Considerations

   We are proposing that RSVP signaling be used to obtain resources in
   both the diff-serv and int-serv regions of the network.  Therefore,
   all RSVP security considerations apply [11].  In addition, network
   administrators are expected to protect network resources by
   configuring secure policers at interfaces with untrusted customers.

7. Acknowledgments

   Authors thank the following individuals for their comments that led
   to improvements to the previous version(s) of this draft: David Oran,
   Andy Veitch, Curtis Villamizer, Walter Weiss, and Russel white.

   Many of the ideas in this document have been previously discussed in
   the original int-serv architecture document [12].

8. References

   [1] Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S.,
   "Resource Reservation Protocol (RSVP) Version 1 Functional
   Specification", RFC 2205, Proposed Standard, September 1997

   [2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and Speer, M.,
   "SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based Admission
   Control Over IEEE 802 Style Networks", Internet Draft, March 1998

   [3] Berson, S. and Vincent, R., "Aggregation of Internet Integrated
   Services State", Internet Draft, December 1997.

   [4] Nichols, K., Jacobson, V. and Zhang, L., "A Two-bit
   Differentiated Services Architecture for the Internet", Internet
   Draft, December 1997.

   [5] Seaman, M., Smith, A. and Crawley, E., "Integrated Services Over
   IEEE 802.1D/802.1p Networks", Internet Draft, June 1997

   [6] Elleson, E. and Blake, S., "A Proposal for the Format and
   Semantics of the TOS Byte and Traffic Class Byte in Ipv4 and Ipv6
   Headers", Internet Draft, November 1997

   [7] Ferguson, P., "Simple Differential Services: IP TOS and
   Precedence, Delay Indication, and Drop Preference", Internet Draft,
   November 1997

   [8] Guerin, R., Blake, S. and Herzog, S.,"Aggregating RSVP based QoS
   Requests", Internet Draft, November 1997.




Bernet, Ed. et. al      Expiration:  August 1999               [Page 18]


Internet Draft         Use Of RSVP with Diffserv           February 1999


   [9] Nichols, Kathleen, et al., "Definition of the Differentiated
   Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474,
   December 1998.

   [10] Blake, S., et al., "An Architecture for Differentiated
   Services." RFC 2475, December 1998.

   [11] Baker, F., "RSVP Cryptographic Authentication", Internet Draft,
   August 1997

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

   [13] Garrett, M. W., and Borden, M., "Interoperation of Controlled-
   Load Service and Guaranteed Service with ATM", RFC2381, August 1998.

   [14] Weiss, Walter, Private communication, November 1998.

   [15] Berson, S. and Vincent, S., "Aggregation of Internet Integrated
   Services State", Internet Draft, August 1998.

APPENDIX A. Terminology

   The following terms were used in this draft.

   Int-serv
        The part of an internet that uses per-flow classification,
        signaling, and admission control to deliver per-flow QoS
        guarantee.


   [Diff-serv region (or diff-serv capable network)] The part of an
        internet that provides aggregate QoS services

   Quantitative
        Application for which QoS requirements are readily quantifiable,
        and which relies on these QoS requirements to function properly.

   Qualitative
        Applications for which relative, but not readily quantifiable,
        QoS requirements exist.

   QoS  Application that requires some form of QoS, either qualitative
        or quantitative.

   LooseQoS assurances that are relative, rather than absolute, or
        generally not quantifiable.




Bernet, Ed. et. al      Expiration:  August 1999               [Page 19]


Internet Draft         Use Of RSVP with Diffserv           February 1999


   TightQoS assurances which are quantifiable, though they may or may
        not provide 100% guarantee.

   Top-down
        Traditional provisioning methods that configure network
        capacities using heuristics and experience, typically from a
        console, based upon traffic predictions.












































Bernet, Ed. et. al      Expiration:  August 1999               [Page 20]


Internet Draft         Use Of RSVP with Diffserv           February 1999


   Author's Addresses

   Yoram Bernet
   Microsoft
   One Microsoft Way,
   Redmond, WA 98052
   Phone: (425) 936-9568
   Email: yoramb@microsoft.com

   Raj Yavatkar
   Intel Corporation, JF3-206
   2111 NE 25th. Avenue,
   Hillsboro, OR 97124
   Phone: (503) 264-9077
   Email: raj.yavatkar@intel.com

   Peter Ford
   Microsoft
   One Microsoft Way,
   Redmond, WA 98052
   Phone: (425) 703-2032
   Email: peterf@microsoft.com

   Fred Baker
   Cisco Systems
   519 Lado Drive,
   Santa Barbara, CA 93111
   Phone: (408) 526-4257
   Email: fred@cisco.com

   Lixia Zhang
   UCLA
   4531G Boelter Hall
   Los Angeles, CA  90095
   Phone: +1 310-825-2695
   Email: lixia@cs.ucla.edu

   Kathleen Nichols
   Cisco Systems
   Email: kmn@cisco.com

   Michael Speer
   Sun Microsystems, Inc
   901 San Antonio Road UMPK15-215
   Palo Alto, CA 94303
   phone: +1 650-786-6368
   Email: speer@Eng.Sun.COM




Bernet, Ed. et. al      Expiration:  August 1999               [Page 21]


Internet Draft         Use Of RSVP with Diffserv           February 1999


   Bob Braden
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695
   phone: 310-822-1511
   Email: braden@isi.edu













































Bernet, Ed. et. al      Expiration:  August 1999               [Page 22]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/