Internet Engineering Task Force                Y. Bernet, Microsoft
Internet Draft                                 R. Yavatkar, Intel
draft-bernet-intdiff-00.txt                    P. Ford, Microsoft
                                               F. Baker, Cisco
                                               L. Zhang, UCLA

                                               March, 1998


       A Framework for End-to-End QoS Combining RSVP/Intserv and
                        Differentiated Services


Status of this 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.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   "working draft" or "work in progress".

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
   munnari.oz.au.

   A revised version of this draft document will be submitted to the
   RFC editor as a Proposed Standard for the Internet Community.
   Discussion and suggestions for improvement are requested.  This
   document will expire before September, 1998. Distribution of this
   draft is unlimited.


. Abstract

   In the past several years, work on QoS enabled networks led to the
   development of the Integrated Services (Intserv) architecture [12]
   and the RSVP signaling protocol [1]. RSVP addresses the needs of
   applications that require QoS, promising per-flow service. As the
   RSVP/Intserv (from here on abbreviated to intserv) work has
   proceeded, we have recognized barriers to the deployment of intserv.
   The reliance of intserv on per-flow state and per-flow processing is
   an impediment to its deployment in the Internet at large, and in
   particular in large carrier networks. Additionally, RSVP signaling
   is supposed to originate from hosts, which as of yet are not RSVP
   enabled in large numbers.

   Recently, attention has shifted to Differentiated services (diff-
   serv). Diff-serv promises to expedite the realization of QoS enabled

                                                                     1

                     Framework for End-to-End QoS          March, 1998


   networks by offering a significantly simpler alternative to intserv,
   which eliminates scalability concerns and which can be implemented
   and managed in large networks, without requiring end-to-end
   deployment. However, unlike intserv, diff-serv focuses on the needs
   of the large network.

   This draft proposes a framework for end-to-end QoS, in which intserv
   and diff-serv are used together to meet the needs of large ISPs who
   manage the transit networks of the Internet, and the users of QoS
   applications and hosts, who are the ISPs' ultimate customers. This
   focus is important, as we believe that in the coming years, there
   will be a proliferation of applications that depend on QoS and of
   hosts which are capable of QoS signaling. We envision the deployment
   of diff-serv capable core networks and intserv capable stub networks
   at the periphery. Our framework allows each to proceed at its 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. This framework builds upon current
   work in the IETF including diff-serv [10] and RSVP aggregation [8].

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

. Goals of This Draft

   This draft is based on the assumption that end-to-end QoS is
   required to support the needs of certain applications. Such
   applications include IP-telephony, video-on-demand and various non-
   multimedia mission-critical applications.

   In our view, intserv and diff-serv are complementary tools in the
   pursuit of end-to-end QoS. Each serves an important purpose in the
   end-to-end QoS enabled network. The primary goal of this draft is to
   encourage the continued development of each in a manner that does
   not preclude realization of the proposed framework. To this end, we
   will:

   1. List the requirements of a network that provides end-to-end QoS.
   2. Present a framework that uses intserv as a customer of diff-serv
   to meet these requirements.
   3. Identify dependencies of intserv on diff-serv.

. Requirements for the End-to-End QoS Framework

   An end-to-end QoS network must serve the requirements of network
   managers as well as those of applications. We consider these
   requirements in the context of the following general topology:







                                                                     2

                     Framework for End-to-End QoS          March, 1998









           / Stub   \       /   Transit    \       /  Stub  \
          / Network  \     /    Network     \     /  Network \
   |---| |        |---|   |---|          |---|   |---|        | |---|
   |Tx |-|        |ER1|---|BR1|          |BR2|---|ER2|        |-|Rx |
   |---| |        |-- |   |---|          |---|   |---|        | |---|
          \          /     \                /     \          /
           \        /       \              /       \        /


                    Figure 1: Sample Network Configuration

   This network consists of a diff-serv capable transit network and two
   intserv capable stub networks. In the interest of simplicity, we
   show a single QoS sender on one of the stub networks and a single
   QoS receiver on the other. We show edge routers (ER1, ER2) at the
   interfaces of the intserv networks to the diff-serv network. We show
   boundary routers (BR1, BR2) at the interfaces of the diff-serv
   network to the intserv networks.

   The transit network contains a mesh of routers, at least some of
   which are diff-serv capable. The stub networks contain a mesh of
   routers, at least some of which are intserv capable.

   We define the following requirements of the framework:

3.1 Definition of a Set of Services

   There must be a set of useful end-to-end services that can be
   requested by QoS needy applications. Routers internal to the diff-
   serv network are assumed to provide a set of 'per-hop-behaviours'
   (PHBs [10]). We expect that concatenation of certain well-defined
   PHBs will yield certain well-understood services across the diff-
   serv network. We also expect that the intserv regions of the network
   will be able to extend these services such that they can be realized
   in a true end-to-end manner.

3.2 Allotment of Diff-serv Service Levels to Specific Traffic Flows

   It must be possible to allot specific end-to-end service levels to
   specific application traffic flows. Within the intserv regions of
   the network this is achieved by allowing applications to use RSVP to
   configure classifiers which operate on IP addresses and port
   numbers. We will refer to such classifiers from here on as 'MF'
   classifiers [10].

   Within the diff-serv regions of the network, traffic is allotted
   service based on the contents of the DS-byte in packet headers.
   Therefore, it is necessary for QoS needy applications to effect the

                                                                     3

                     Framework for End-to-End QoS          March, 1998


   correct marking of DS-bytes before their packets are submitted to
   the diff-serv network. There are two general mechanisms for doing
   so:

   1. Hosts may directly mark DS-bytes in the transmitted packets of
   QoS needy applications.
   2. Routers external to the diff-serv network may mark DS-bytes on
   behalf of QoS needy applications, based on MF classification.

   In the first case, marking will be done based on host configuration
   or local communication between QoS needy applications and the host
   operating system. In the second case, marking will be done based on
   manual configuration of the marking router's MF classifier/marker or
   standard signaling between QoS needy applications and the marking
   router's classifier/marker.

   The following three requirements argue either for host based marking
   or for dynamic configuration of a router's classifier/marker in
   response to application requests.

3.2.1 Minimal Management Burden

   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.

3.2.2 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 granularity;
   one is the granularity with which an individual flow or a group of
   flows is identified. The other is the frequency at which the service
   allotted to a flow may change. A fine grain QoS system would allow
   the following requirement to be expressed: telephony traffic from
   user X should be allotted service level A, while telephony traffic
   from user Y should be allotted service level B, and web traffic from
   any user should be allotted service level C.  A coarse grain system
   would be limited to something of the form: all traffic from subnet
   1.0.0.0 should receive service level A, while all traffic from
   subnet 2.0.0.0 should receive service level B. A temporally fine
   grain system would allow immediate changes in allotment of service
   levels to traffic flows. A temporally coarse grain system may allow
   infrequent changes only.

3.2.3 Allocation of Service Level to Application Flows

   It must be possible to allot specific service levels to application
   traffic flows. Routers may not be able to readily identify these
   flows based on network and/or transport layer fields in a packet.
                                                                     4

                     Framework for End-to-End QoS          March, 1998



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

3.3 Admission Control

   Applications use RSVP to request that their flows be admitted to
   intserv regions of the network. When a request is rejected, the host
   application may avoid sending traffic and/or intermediate RSVP
   capable nodes will only give best-effort service to traffic on flows
   that were not admitted. These mechanisms protect traffic on flows
   that were admitted.

   In diff-serv regions of the network, admission control is provided
   implicitly, by policing at ingress points. The problem with implicit
   admission control is that it breaks the end-to-end validity of
   explicit admission control. Specifically, an application may gain
   admission using RSVP signaling, even though there is no capacity for
   that application's traffic within the diff-serv region of the
   network. Neither the application, nor intermediate RSVP capable
   nodes will be aware that the application's traffic is not
   admissible. As a result, neither can take corrective action and all
   traffic from that customer, at the corresponding service level, may
   be compromised. This failure may be partially, but not completely
   alleviated by policing based on MF classification at the diff-serv
   ingress (rather than BA classification [10]).

   End-to-end QoS requires that applications and RSVP capable intserv
   nodes be explicitly informed of admission control failure in the
   diff-serv network. This enables them to take corrective action and
   to avoid overdriving the diff-serv network. If the service agreement
   between the intserv and diff-serv regions of the network is
   statically provisioned, then admission control functionality can be
   provided by static configuration of admission control in intserv
   edge routers. However, if the service agreement is dynamically
   variable, then it will be necessary to dynamically propagate current
   diff-serv resource availability to the intserv network for the
   purpose of explicit admission control.

3.4 Policy Support

   End-to-end QoS leads to preferential treatment of certain traffic
   flows over others. Within diff-serv regions of the network, policy
   applies on a per-customer basis. In general, the diff-serv network
   makes multiple service levels available to a single customer's
   intserv network. In this case the customer must apply policy within
   its network to assure appropriate allocation of resources (customer
   network resources as well as diff-serv network resources) to
   individual hosts in the customer's network. This requires that end-
   to-end admission control be based on policy as well as resource
   availability.

4.0 Intserv as a Customer of Diff-serv
                                                                     5

                     Framework for End-to-End QoS          March, 1998



   To meet the above requirements, we propose a network that consists
   of relatively small intserv capable stub networks, connected by
   larger, diff-serv capable transit networks. In this section, we will
   describe the operation of one instantiation of such a network (see
   figure 1). The following assumptions apply:

4.0.1 Host Capabilities

   Both sending and receiving hosts use RSVP to communicate QoS
   requirements of certain QoS aware applications running on the host.
   A QoS process within the host operating system generates RSVP
   signaling on behalf of the applications. This process also invokes
   traffic control. Host traffic control includes marking the DS-byte
   in transmitted packets and shaping transmitted traffic per token
   bucket specifications. Note that host traffic control is assumed for
   this specific example, but is not a requirement of the framework in
   general. Leaf routers within the intserv network may provide the
   traffic control functions.

4.0.2 Edge Routers

   The edge routers are special routers that straddle the boundary
   between the RSVP/Intserv region of the network and the diff-serv
   region of the network. It is helpful to think of these routers as
   consisting of two halves; the standard RSVP half, which interfaces
   to the stub networks, and the diff-serv half, which interfaces to
   the transit network.

   The RSVP half is at least partially RSVP capable; it is able to
   process PATH and RESV messages but it is not necessarily required to
   store full RSVP state and it is not required to provide MF
   classification.

   The diff-serv half of the router provides the interface to the
   admission control function for the diff-serv network. We shall refer
   to this function from here on as the 'DACS' (diff-serv admission
   control service). The DACS is a process that is likely to (but is
   not required to) run at least partially, on the routers. If the
   service agreement between the stub networks and the transit networks
   is statically provisioned then the DACS can be as simple as a table
   which specifies capacity at each service level. If the service
   agreement is dynamic, the DACS may communicate with counterparts
   within the diff-serv network (such as a bandwidth broker [4]) and
   may be able to make admission control decisions based on provisioned
   limits as well as the topology and the capacity of the diff-serv
   network.

4.0.3 Boundary Routers

   These are conventional boundary routers. In the example illustrated,
   they 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 may, but are not required, to
                                                                     6

                     Framework for End-to-End QoS          March, 1998


   provide MF classification nor to mark the DS-byte (with the possible
   exception of the in/out bit). [10, 8]

   Note that this example places the boundary between the RSVP/Intserv
   network and the diff-serv network, within the edge routers at the
   stub networks. In general, this boundary could be shifted to the
   left or to the right. It could for example, be placed within the
   boundary routers in the transit network.  In this case, the DACS is
   implemented entirely within the diff-serv network (and is
   essentially, the bandwidth broker proposed in [4]), but the diff-
   serv boundary routers must be RSVP capable.

4.0.4 Stub Networks

   The stub networks consist of RSVP capable hosts and some number of
   leaf routers. Leaf routers within the stub networks may or may not
   be RSVP capable. Since they are relatively small networks, it is
   reasonable to assume that they are RSVP capable, but this is not
   necessary. If they are not RSVP capable, we assume that they will
   pass RSVP messages unhindered.

4.0.5 Transit Network

   The transit network is not RSVP capable. It provides two or more
   levels of service based on the DS-bytes 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.

4.0.6 Carrier/Customer Agreement

   The customer (owner(s) of the leaf networks) and the carrier owning
   the transit network have negotiated a contract for the capacity to
   be provided at each of a number of standard diff-serv service
   levels. The capacity may be statically provisioned. In this case,
   the DACSs are statically configured with the capacity available at
   each service level and reside entirely within the edge routers.
   Alternatively, the capacity may be dynamically variable with a pre-
   negotiated usage fee and/or a pre-negotiated capacity limit. In this
   case, the DACS would be required to communicate with counterparts
   within the diff-serv transit network.

4.0.7 Mapping from Intserv Service Type to DS-Byte

   The current Intserv service types (controlled load and guaranteed)
   may or may not be practical in the diff-serv network. We assume that
   a set of end-to-end services that is practical is defined based on
   concatenation of PHBs (such as proposed in [10]) and that unique
   code points are allocated for each service in the service type field
   of the Intserv flowspec.

   We assume further that there is some standard coding of PHBs in a
   sub-field of the DS-byte.
                                                                     7

                     Framework for End-to-End QoS          March, 1998



   It follows from the previous two assumptions, that there is a
   mapping from intserv service type to a sub-field of the DS-byte.
   Note that there is precedent for the notion of mapping intserv
   service types to per-packet priority values, specifically in the
   mapping of service types to 802.1p described in [5].

4.1 How End-to-End QoS is Obtained

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

   1. The sending host's QoS process generates an RSVP PATH message,
      describing the traffic offered by the sending application.

   2. The PATH message is carried toward the receiving host. In the
   sending stub network, standard RSVP processing will be applied at
   RSVP capable nodes (routers, SBMs, etc).

   3. At 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. It is processed in the receiving stub network according to
   standard RSVP processing rules.

   5. At the receiving host, the QoS process generates an RSVP RESV
   message, indicating interest in the offered traffic, at a certain
   intserv 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 receiving 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. At this point, the RESV message triggers DACS processing. The
   DACS 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 admitted, the DACS 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
   will be rejected.

                                                                     8

                     Framework for End-to-End QoS          March, 1998


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

   11. At the sending host, 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 intserv
   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). It begins to set the DS-byte 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 are able to 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.

4.2 Variations of the Model

   It is useful to consider a number of variations of the model
   presented.

4.2.1 Admission Control

4.2.1.1 Statically Provisioned Service Agreements

   In the simplest model, service agreements are negotiated statically
   between the stub networks and the transit networks. A service
   agreement consists of a table of capacities available to a
   customer's stub network, at each diff-serv service level. In this
   case, DACS 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 intserv stub networks and admission control in the
   two regions of the network is completely independent.

4.2.1.2 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 DACS functionality. Instead, DACS 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 intserv network. This boundary may be

                                                                     9

                     Framework for End-to-End QoS          March, 1998


   implemented at the edge router (in the stub network) or at the
   boundary router (in the transit network).

4.2.1.3 Limiting the Impact of Intserv Admission Control on the Diff-
serv Network

   Note that coupling intserv and diff-serv admission control does not
   imply that each intserv admission control request results in diff-
   serv admission control work. Instead, intserv admission control
   requests are aggregated at the boundary between the intserv and the
   diff-serv network. For example, intserv admission control requests
   may trigger diff-serv admission control requests to bandwidth
   brokers only when some high-water or low-water resource threshold is
   crossed. Separate high-water and low-water thresholds provide
   hysteresis to prevent thrashing.

4.2.1.4 Roles of Policy and Resource Based Admission Control

   It is necessary to provide both resource and policy based admission
   control in the diff-serv network as well as the intserv network. In
   the diff-serv network, resource and policy based admission control
   are handled by entities such as bandwidth brokers and reflected to
   the intserv network as DACS (or RSVP). Policy decisions made within
   the diff-serv network are likely to be at the per-intserv network
   (per-customer of the diff-serv network) granularity.

   In the intserv network, resource based admission control is handled
   by RSVP enabled routers (and SBMs). Policy based admission control
   is handled by RSVP capable policy servers. These assure that intserv
   resources are allotted to intserv customers according to policy
   specific to the intserv network. In addition, policy servers within
   the intserv network must also assure that appropriate policy is
   applied when diff-serv resources are allotted to intserv customers.

4.2.2 Setting the DS-Byte at Intermediate Nodes

   In the example described, hosts use RSVP signaling and mark the DS-
   byte corresponding to the admitted service level. Note that these
   functions can be separated. In the example, the function of RSVP
   signaling is to invoke QoS in the intserv network and to provide
   end-to-end admission control. The function of marking the DS-byte is
   to eliminate the need for MF classification at routers.

   It is possible to mark the DS-byte at intermediate routers rather
   than at the host and still to 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. Therefore, the
   configuration of MF classifiers and markers is dynamic (minimizing
   the management burden) and full resource and policy based admission
   control can be applied.

   The disadvantages of marking the DS-byte at intermediate routers
   (instead of the host) are that full MF classifiers are required at

                                                                    10

                     Framework for End-to-End QoS          March, 1998


   the intermediate nodes and that responsibility for traffic
   separation is shifted away from the host.

   Nonetheless, this approach is necessary to support those hosts which
   may be capable of RSVP signaling, but which are not capable of
   marking the DS-byte. In addition, there may be cases in which the
   network administrators wish to shift the responsibility for traffic
   separation away from the hosts.

4.2.3 Supporting Various Levels of Host Functionality

   We identify four levels of host functionality, as follows:

   1. Legacy hosts, incapable of any form of QoS signaling.
   2. Hosts capable of RSVP signaling but not of marking DS-bytes.
   3. Hosts capable of marking DS-bytes but not of RSVP signaling.
   4. Hosts capable of both RSVP signaling and marking DS-bytes.

   Hosts providing any of the above levels of functionality can co-
   exist in our model. However, the advantages of the model may not be
   fully realizable with certain combinations. In the following
   paragraph, we consider as an example, the coexistence of legacy
   hosts and of hosts that are capable both of RSVP signaling and of
   marking DS-bytes.

   When legacy hosts are required to coexist with hosts that are
   capable both of RSVP signaling and of marking DS-bytes, stub network
   administrators partition stub network resources between the two
   types of hosts. Legacy hosts rely on a router to mark DS-bytes based
   on the output of a statically configured MF classifier. This router
   could reside within the stub network or alternatively, the edge or
   boundary router could be configured to provide this functionality. A
   policer is also required at this router. The policer is statically
   configured to limit the consumption of diff-serv resources by the
   legacy hosts. The network administrator statically allocates the
   remaining diff-serv resources to the hosts that are capable of RSVP
   signaling by configuring the appropriate limits in the intserv
   enabled region of the stub network.

   We see that support for legacy hosts requires both MF classification
   and marking in intermediate routers as well as static allocation of
   resources by the network administrator. Hosts that are capable of
   marking the DS-byte eliminate the need for intermediate routers to
   provide MF classification. Hosts that are capable of signaling RSVP
   (and which use the result of this signaling to control transmission
   to the network), alleviate the need for static configuration as a
   form of admission control.

4.3 Issues

4.3.1 Setting the DS-Byte at Hosts

   The thought of allowing hosts to set the DS-byte directly, may alarm
   network administrators. The obvious concern is that hosts may

                                                                    11

                     Framework for End-to-End QoS          March, 1998


   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 either case, it may be necessary to protect the network by
   policing at various points, both within the stub network and/or at
   the interface to the transit network. This assures that customers do
   not use more resources than they are entitled to, at each service
   level. If the sending host does not do the marking, intermeidate
   and/or boundary routers must provide MF classification, mark and
   police. If the sending host does do the marking, these routers need
   only to provide BA classification and to police to ensure that the
   customer is not exceeding the aggregate capacity negotiated for the
   service level.

   Requiring hosts to mark the DS-byte has the effect of moving
   responsibility to the edge of the network, in more ways than one.
   With this approach, boundary routers police in aggregate. As a
   result, the customer cannot rely on boundary 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 within the customer's
   sending network.

   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 may chose to
   provide per flow policing (or even re-shaping) at the egress point
   from the customer's network.

   In summary, the security concerns of marking the DS-byte at the edge
   of the network can be dismissed since each carrier will have to
   police at their boundary anyway. Furthermore, this approach reduces
   the granularity at which boundary 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.

4.3.2 In/Out Bits

   Diff-serv proposals call for the DS-byte to be used to indicate a
   PHB, as well as whether a particular packet is 'in' or 'out' of
   profile. In our proposal, we recommend that hosts set at least the
   bits that indicate the PHB. This does not preclude hosts from
   setting the in/out bit as well. For example, hosts with
   sophisticated traffic shaping features may allow applications to
   occasionally burst beyond the negotiated token bucket parameters and
   may apply their own policing by marking excess packets as 'out'.
                                                                    12

                     Framework for End-to-End QoS          March, 1998


   This does not compromise the transit network, since it will be
   policing and may remark the in/out bit.

4.3.3 End-to-End Integrity of the DS-Byte

   Our proposal assumes that hosts use a standard coding for specifying
   a desired PHB in some sub-field of the DS-byte. It also assumes that
   packets submitted to the network with a certain PHB specified, will
   receive a standard service throughout the diff-serv network.
   Strictly speaking, this does not dictate that the transit network
   must leave the PHB field intact. 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.4 Carrying RSVP Messages across Transit Networks

   Our proposal presumes end-to-end RSVP both as a means for
   communication between sending host and receiving host and
   optionally, for the support of true RSVP reservations in stub
   networks (or in intermediate networks which are interested in the
   fine grain RSVP information). Therefore, we require that RSVP
   messages be carried across the transit networks. In [8] mechanisms
   are proposed for doing so in a manner that does not adversely impact
   the transit network.

. Dependencies of Intserv on Diff-Serv

   We have described a framework for end-to-end QoS in which intserv
   networks are customers of diff-serv networks. We believe that the
   benefits of this framework are sufficient to justify the
   consideration of intserv dependencies as diff-serv work proceeds. In
   particular, we wish to draw attention to the following dependencies:

   1. We expect that we can invoke a standard end-to-end (within the
   diff-serv network) service by specifying a standard code in a (PHB)
   sub-field of the DS-byte of a packet launched into a diff-serv
   network.
   2. Diff-serv networks must provide admission control information to
   the intserv network. At the very least, this is through static
   service level agreements. Preferably, this is through a dynamic
   protocol. If the intserv to diff-serv boundary is implemented in the
   transit network boundary routers, then this protocol is RSVP.
   3. We expect that diff-serv networks will carry RSVP messages such
   that they can be recovered at the egress point from the diff-serv
   network.

. Security Considerations

   We are proposing that RSVP signaling be used to obtain resources in
   both the diff-serv and intserv 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.

                                                                    13

                     Framework for End-to-End QoS          March, 1998



. References

   [] 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

   [] 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

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

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

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

   [] 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

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

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

   [] Clark, D. and  Wroclawski, J., "An Approach to Service
   Allocation in the Internet", Internet Draft, July 1997

   [] Blake, S. and Nichols, K., "Differentiated Services Operational
   Model and Definitions", Internet Draft, February 1998

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

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

.  Acknowledgments

. Author's Addresses

   Yoram Bernet
   Microsoft
   One Microsoft Way,
   Redmond, WA 98052
   Phone: (425) 936-9568
                                                                    14

                     Framework for End-to-End QoS          March, 1998


   Email: yoramb@microsoft.com

   Raj Yavatkar
   Intel Corporation, JF3-206
   2111 NE 25th. Avenue,
   Hillsboro, OR 97124
   Phone: (503) 264-9077
   Email: yavatkar@ibeam.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: (310_825-2695
   Email: lixia@cs.ucla.edu

























                                                                    15