Internet Engineering Task Force Draft                                      Y. Bernet, Microsoft
  Internet Draft
Expiration:  August 1999                          R. Yavatkar, Intel
  draft-ietf-diffserv-rsvp-01.txt Microsoft
File: draft-ietf-diffserv-rsvp-02.ps                  P. Ford, Microsoft
                                                         F. Baker, Cisco
                                                          L. Zhang, UCLA
                                                       K. Nichols, Cisco Systems
                                              M. Speer, Sun Microsystems

						 November, 1998

	   A Framework for Use
                                                          R. Braden, ISI

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

                           February 26, 1999

Status of this Memo

   This document is an Internet Draft. Internet Drafts 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, areas,
   and its Working Groups. working groups.  Note that other groups may also distribute
   working documents as Internet
  Drafts.

  Internet Drafts Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
  months.  Internet Drafts months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is not appropriate inappropriate to use Internet Internet- Drafts as reference
   material or to cite them other than as a
  "working draft" or "work in progress".
  To view the entire progress."

   The list of current Internet-Drafts, please check
  the "1id-abstracts.txt" listing contained in the Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories on	ftp.is.co.za (Africa), ftp.nordu.net
  (Northern Europe), ftp.nis.garr.it (Southern Europe),	munnari.oz.au
  (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
  (US West Coast).

  A revised version of this draft document will can be submitted 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
  RFC editor as	an Informational RFC problem of
   providing QoS for the Internet Community.
  Discussion end systems.  These approachs must be able
   to coexist and suggestions for improvement are requested. effectively interoperate.  This document will	expire before May 1999.	Distribution of	this
  draft outlines one
   important model for such interoperation, in which diff-serv is unlimited.

			Use Of RSVP with Diffserv	      June, 1998

  1. Abstract

  In used
   by transit networks in the past several years, work 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.

1. Introduction

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

   RSVP enables applica-
  tions applications to signal per-flow QoS requirements to the network.	Intserv	parame-
  ters are used
   network, with explicit admission control.  Int-serv uses RSVP
   signaling to quantify these requirements for 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 purpose int-serv capable
   routers along the path of admis-
  sion control.	However, as work the flow.  These classifiers perform a
   fine-grain or `MF' [10] classification of packets, using on RSVP IP
   addresses and Intserv has proceeded, we
  have recognized the following port numbers for example.

   Some basic limitations, which impede	deploy-
  ment of these	mechanisms limitations to the RSVP/int-serv model have impeded its
   deployment in the Internet at large:

  1) large.

   o    The reliance use of RSVP on per-flow state and per-flow processing raises
        scalability concerns in for large networks.
  2) Today, only

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

   o    Some applications require a form of QoS, but are unable to
  express these	requirements QoS that cannot be expressed
        using the intserv int-serv model.

  At present, the

   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 enter-
  prise enterprise networks.
   This push has led to the development of Differentiated
  services (diff-serv). Services.  In
   contrast to RSVP's the per-flow orientation, orientation of int-serv and RSVP, diff-serv
   networks classify packets to into one of a small number of aggre-
  gated	flows, aggregated
   flows or "classes", based on	the setting of bits set in the TOS field of each
   packet's IP header. Thus, in  This is known as `BA' classification [10].  In
   addition to eliminating the reliance on requirement for per-flow state, diff-serv
   QoS can initially be deployed using	top-down
  provisioning,	with no	requirement for long-term provisioning rather
   than short-term reservations established by end-to-end signaling.

  At the same time however, it is important to assure that the diff-serv
  mechanisms deployed, interoperate effectively	with hosts

   We view int-serv and networks
  that provide per-flow	QoS in response	to end-to-end signaling. This is
  important, diff-serv as	we believe that complementary tools in the coming years, there pursuit
   of end-to-end QoS.  For many applications, the loose or "qualitative"
   QoS provided by diff-serv will be a
  proliferation adequate.  However, some
   applications will require the tight quantitative end-to-end QoS
   assurance provided by int-serv and RSVP. Current examples of
   applications that depend on need tight QoS include IP-telephony, video-on-
   demand, and of hosts	which
  will signal end-to-end on their behalf.

  This draft proposes a	framework various non-multimedia mission-critical applications, and
   such applications may proliferate in which the future. The diff-serv capable
   mechanisms that are deployed must be able to interoperate effectively
   with hosts and networks that provide aggregate per-flow QoS	services, using int-serv
   models.

   There are several different models for coexistence and they co-exist interoperation
   between RSVP/int-serv and	inter-operate diff-serv.  This draft is primarily
   concerned with RSVP/Intserv capable hosts and stub networks, which use end-to-
  end signaling.

  For instance,	in one example of such important model, although Section 5 presents a
   brief look at other models.  Under our model, diff-serv mechanisms
   are used within transit networks and at in the boundaries between them, `core' of the network, while
  either diff-serv or RSVP/Intserv
   RSVP/int-serv mechanisms are used within stub net-
  works	and networks at the boundaries between stub networks and	transit	diff-
  serv networks. Managers of 'edge'.
   From the int-serv viewpoint, the diff-serv transit networks will provision a pool
  of network resources to be available in response to end-to-end signal-
  ing. The remaining resources will be allotted	using traditional 'top-

			Use Of RSVP with Diffserv	      June, 1998

  down'	provisioning methods.

  However, our model does not preclude other possibilities: use	of
  diff-serv mechanisms and top-down provisioning in both stub and tran-
  sit networks to support applications that do not use any explicit sig-
  naling, or use of RSVP signaling for admission control in conjunction
  with diff-serv mechanisms in transit networks. In particular,	the pro-
  posed	framework will allow for a scenario in which RSVP signaling is
  used for dynamic provisioning	and admission control in the diffserv
  region of the	network. In such treated
   as a case, routers in the	diff-serv region
  will continue	use the	DSCP value virtual link connecting int-serv/RSVP capable routers.  This
   model builds upon work in the IP datagram to identify and
  offer	services to flow aggregates. However, some of these services progress on RSVP aggregation [8, 15].

   This model will use dynamic provisioning	and require admission control using
  explicit signaling when a new	flow is	to be added to the aggregate.
  Under	such provide a scenario, one can envision use of RSVP signaling	to com-
  municate the flow specification and desired DSCP (flow aggregate) to
  the routers in the diff-serv region of the network.

  Our framework	allows the that will allow deployment of
   diff-serv networks and
  RSVP/Intserv deployment of RSVP/int-serv networks to
   proceed at their own pace, providing	immedi-
  ate 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]  Ultimately, we want
   RSVP/int-serv and	RSVP aggregation [8].

  Many of diff-serv mechanisms to interact seamlessly.
   Network administrators should be able to determine for their own
   networks the ideas in this document have been previously discussed in degree to which diff-serv capabilities are pushed
   towards the original intserv architecture document [12].

  2. Goals edge of This Draft

  This draft is	based on their networks, or the assumption	that end-to-end	QoS is required degree to support which RSVP/int-
   serv capabilities are pushed towards the needs core 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 pur-
  suit of end-to-end QoS. Each serves Internet.

   Section 2 provides an important purpose in the end-
  to-end QoS enabled network. The primary goal of this draft is	to
  encourage the	continued development overview of each in a manner that does not
  preclude realization our model for interoperation
   between int-serv and diff-serv, and discusses some of the proposed framework. To this end, we will:

  1. List
   assumptions.  Section 3 presents 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 model in more detail, while
   Section 4 discusses its implications for diff-serv.

  Ultimately, we aim to	clearly	define  Finally, Section
   5 briefly lists some other possible models for interoperation.
   Appendix A contains a manner	in which RSVP/Intserv

			Use Of RSVP with Diffserv	      June, 1998

  and diff-serv	mechanisms interact seamlessly.	We expect that by doing
  so, we will enable network administrators to determine the degree to
  which	diff-serv capabilities are pushed towards the edge list of their net-
  works	(or, the degree	to which RSVP/Intserv capabilities are pushed
  towards the core). 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/intserv RSVP/int-serv with diff-serv, the draft currently
   does not address the issues specific to IP multicast flows such as
  merging dissimilar reservations.

  3. Terminology

  The following	terms are used in this draft:

  a. Intserv region (or	intserv	capable	network) - the part flows.  See
   Section 5.

2. Overview of an
  internet the Model

   This section examines the issues in providing tight quantitative
   end-to-end QoS over end-to-end paths that	uses per-flow identification, signaling, includes both int-serv
   networks and admission
  control to deliver per-flow QoS guarantees

  b. Diff-serv region (or diff-serv capable network) - the part	of an
  internet that	provides aggregate QoS services

  c. networks, and introduces our model.

   2.1 Quantitative End-to-End QoS applications - applications for which QoS
  requirements are readily quantifiable, and which rely

      The primary focus of this document on these QoS
  requirements to function properly.

  d. Qualitative end-to-end quantitative QoS.
      Although quantitative QoS applications - applications for which relative
  QoS requirements exist, but are not readily quantifiable.

  e. 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 that
      require additional support.

      Diff-serv is expected to define some form of QoS,
  either qualitative or	quantitative.

  f. Loose QoS - QoS assurances	which are relative, rather than
  absolute, or generally not quantifiable.

  g. Tight QoS - QoS assurances	which are quantifiable,
  though they may or may not provide 100% guarantee.

  h. Top-down (or open-loop) provisioning - traditional	provisioning
  methods well-defined edge-to-edge
      services, which	configure network capacities using heuristics and
  experience, typically	from a console,	with no	explicit knowledge of
  exact	traffic	volumes	or exact paths taken will be formed by concatenation of the affected traffic.

  i. RSVP/Intserv - RSVP is a signaling	protocol. Intserv (in this
  context) is a	model for quantifying traffic `per-hop-
      behaviors' (PHBs [10]) that is useful are being defined for
  admission control purposes. In this document,	we use internal diff-
      serv routers, possibly with some defined shaping and/or policing
      at the terms
  together, ingress.  Our model assumes that it will be possible to discuss map
      the quantitative QoS services defined by int-serv into these
      diff-serv services within the RSVP/Intserv diff-serv network, in contrast order to
      satisfy the end-to-end requirement of a quantitative QoS
      application.

   2.2 Packet Marking

      Within the diff-serv network. However, regions of the two are separable and	much network, traffic is allotted
      service based on the contents of the

			Use Of RSVP with Diffserv	      June, 1998

  following discussion could be	applied	to a model DS-field in which RSVP
  signals using	parameters that	are not	Intserv	specific.

  4. Requirements for the End-to-End QoS Framework An end-to-end IP headers.
      Setting the DS-field is referred to as `marking' the packet.  QoS
  network
      applications must serve be able to effect the requirements of network managers as well as
  those correct marking of both	quantitative and qualitative QoS applications. We con-
  sider	these requirements in the context of the following general
  topology:

	  / 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	inter-
  faces	of the intserv networks	to the diff-serv network. We show boun-
  dary 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:

  4.1 Definition of a Set of Services

  There	must be	a set of useful	end-to-end services available to Quanti-
  tative QoS applications. Routers internal to the diff-serv network are
  assumed to provide a set of 'per-hop-behaviors' (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.

  In addition, there must be a set of end-to-end services available to
  Qualitative QoS applications.	However, the services that these

			Use Of RSVP with Diffserv	      June, 1998

  applications require are generally less demanding. They can be loosely
  provisioned (in a top-down manner) in	the diff-serv regions of the
  network and will likely receive best-effort treatment	in the intserv
  regions of the network.

  In this draft	we focus primarily on the requirements of quantitative
  QoS applications. Although these may generate	only a small fraction of
  all traffic, servicing this traffic may comprise a significant frac-
  tion of the revenues associated with QoS. In addition, while qualita-
  tive QoS applications	can be satisfied by conventional diff-serv
  alone, quantitative QoS applications require additional support.

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

  It must be possible for QoS applications to invoke specific end-to-end
  service levels for their traffic flows. Within the intserv regions of
  the network quantitative QoS applications do so by using RSVP	signal-
  ing to configure classifiers which operate on	IP addresses and port
  numbers. We will refer to such classifiers from here on as 'MF' clas-
  sifiers [10].

  Within the diff-serv regions of the network, traffic is allotted ser-
  vice based on	the contents of	the DS-field in	packet headers.	There-
  fore,	it is necessary	for QoS	applications to	effect the correct mark-
  ing of DS-fields DS-
      fields before their packets	are submitted to the enter a diff-serv network. (This is particularly true for quantitative QoS applications,
  less so for qualitative QoS applications that	need not play as active
  a role in securing specific QoS from the network).  There are
      two gen-
  eral mechanisms choices for doing so:

  1. accomplishing this.

      Host Marking
           Hosts may directly mark DS-fields in the transmitted packets of transmitted
           by QoS applications.
  2. Routers external to the diff-serv network may mark	DS-fields on
  behalf of QoS	applications based on MF classification.

  In the first case,  Such marking will may be done based on host
           configuration or on local communication between QoS
           applications and the host operating system. In

      Int-serv Router Marking
           Routers external to the second	case, marking will be done based diff-serv network may mark DS-fields
           on top-down
  configuration behalf of the marking router's QoS applications, based on MF classifier/marker (by classification.
           The MF classifier might be dynamically configured by RSVP
           signaling between QoS applications, or it might be controlled
           statically by manual configuration or via automated configuration scripts)	or based on
  standard signaling between QoS applications and
           scripts.

      MF classification is expected to be limited to examination of the marking router's
  classifier/marker.

  The following	three requirements argue either	for
      network and transport-layer (port) fields of a packet.  An
      advantage of host based 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
      preferential service to a website's home page (over other, less
      important pages at the site) or for dynamic configuration the case of a router's classifier/marker in
  response to application requests.

  4.2.1	Minimal	Management Burden

			Use Of RSVP with Diffserv	      June, 1998 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, minor; however, this means
      that the granularity of allotting service levels to flows will be sub-optimal.

  4.2.2 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' `granularity' is used here to refer to the degree of	specifi-
  city
      specificity that is available in allotting a specific service
      level to a specific traffic flow.  There are two measures of granularity;	one is
  the
      allotment granularity: 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 packet classification and
      temporal granularity.

      Fine grain QoS system	would allow classification might implement the	follow-
  ing requirement to be	expressed: telephony following
      requirement: "Telephony traffic from user X should
  be is allotted service
      level A, while telephony traffic from user Y
  should be is allotted service
      level B, and web traffic from any user
  should be is allotted service level C.  A coarse
      C."  Coarse grain system would classification might be limited to something of
      the form: all "All traffic from subnet 1.0.0.0
  should receive receives service level
      A, while all traffic from subnet 2.0.0.0
  should receive receives service level B.
      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. flows, with times of the order of seconds or
      less.  A temporally coarse grain coarse-grained system may allow infrequent changes
  only.

  4.2.3	Difficulties in	Identification might have service
      levels set by static provisioning with time frames of Application Flows

  Routers days or
      weeks.

   2.4 Policing

      It may not be able necessary to readily identify specific application flows
  based	on protect the network by policing at various
      points, within the stub network and/or transport layer fields in a packet. at the interface to the
      transit network. For example, consider within the need to give preferential service 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.

      It should be noted that some diff-serv PHBs (e.g., a
  website's home page (over other, less	important pages "billing" PHB
      [14]) may not require any policing at all at any point in the site) or
  the case of encrypted	traffic	flows (IPSEC).

  4.3
      network.

   2.5 Admission Control

  Quantitative

      Under RSVP/int-serv, quantitative QoS applications use RSVP to request
      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 their flows are known to be
  admitted sufficiently
      over-provisioned to intserv regions of satisfy the network. service requirements.  When a
      request is rejected, the	host application 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 and/or inter-
  mediate RSVP capable nodes will only give best-effort	service	to
  traffic on flows that	were not admitted. traffic.  These mechanisms protect traffic on flows that
      were previously admitted.

      In diff-serv regions of the network, admission control is may be
      provided
  implicitly, implicitly by policing at ingress points points, based on
      provisioning. The
  problem with implicit  However, to support end-to-end tight QoS, explicit
      admission control is that it breaks must be applied to the	end-to-

			Use Of RSVP with Diffserv	      June, 1998

  end validity of explicit admission control. Specifically, an applica-
  tion may gain	admission using	RSVP signaling,	even though there is no
  capacity for that application's traffic within virtual hop represented
      by the diff-serv region of
  the transit network. Neither the application,	nor intermediate RSVP capable
  nodes	will be	aware that  An diff-serv service level used
      by the application's int-serv traffic is provisioned for some maximum level of
      traffic.  The admission control function must ensure that this
      limit is not admissible. 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, neither can take	corrective action and all traffic from
  that customer, at the	corresponding service level, may be compromised.
  This failure may admission control must be partially, but not completely alleviated by polic-
  ing based on MF classification 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	diff-serv ingress (rather than
  BA classification [10]).

  End-to-end QoS requires that quantitative QoS	applications and RSVP
  capable intserv nodes	be explicitly informed granularity of individual users.  Policy based admission
      control
  failure in the diff-serv network. This enables them is handled by RSVP-capable policy servers.  These assure
      that int-serv network resources are allotted to take corrective
  action and users according to	avoid overdriving
      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. If the	service
  agreement between the	intserv network, resource and diff-serv regions of the network is
  statically provisioned, then policy-based admission
      control functionality can be
  provided are handled by static configuration of admission	control	in intserv edge
  routers. However, if entities such as bandwidth brokers.  Policy
      decisions made within 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 expli-
  cit admission	control.

  4.4 Policy Support

  End-to-end QoS leads are likely to preferential treatment of certain traffic
  flows	over others. Within diff-serv regions of be at
      the network, policy
  applies on a per-customer basis. granularity of peer networks.  In general, the diff-serv
      network
  makes may make multiple service levels available to a single customer's intserv
      peer int-serv network. In

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 case 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 customer must apply	policy 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 its net-
  work the RSVP/int-serv networks
   interface to assure appropriate allocation the border routers (BR1, BR1) of resources (customer network
  resources as well as the diff-serv network.

   From an economic viewpoint, we may consider that the transit network resources)
   sells service to individual hosts the stub networks, which in turn sell service to end
   systems.  Thus, we may think of the customer's network. This requires that	end-to-end admission
  control be based on policy as	well as	resource availability.

  5. Intserv stub networks as	a Customer customers of Diff-serv

  To meet the above requirements, we envision a	network	that consists
  typically of relatively smaller, intserv capable stub	networks, con-
  nected by larger, diff-serv capable
   transit networks. network.  In this sec-
  tion, the following, we will	describe use the operation term "customer" for
   each of one instantiation the stub networks in Figure 1.

   3.1 Components of such a
  network (see figure 1). The following	assumptions apply:

  5.1.1	Host Capabilities 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 require-
  ments requirements of certain QoS aware QoS-aware applications running
         on the host. A  Typically, a QoS process within the host
         operating system generates RSVP signaling on

			Use Of RSVP with Diffserv	      June, 1998 behalf of the	applications. This
         applications; this process may also	invokes invoke local traffic
         control.
  Host traffic

         Traffic control includes	marking in the host may mark the DS-field in
         transmitted
  packets packets, and shaping it may shape transmitted traffic per token bucket specifica-
  tions. Note that host	traffic	control	is assumed for this specific
  example, but is not a	requirement to
         the requirements of the framework int-serv service in	general. Leaf
  routers use.
         Alternatively, the first-hop router within the intserv int-serv network
         may provide the these traffic control functions.

  5.1.2	Edge Routers

  The edge routers

      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 special proposed in [8]; they do not
         require the routers that straddle 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/Intserv RSVP/int-serv
         region of the network and the diff-serv region of the	network. network within the edge
         routers.  It is helpful to think of these routers an edge router as con-
  sisting
         consisting of two halves; the halves: a standard RSVP half, which
         interfaces to the a stub networks, network, and the a diff-serv half, which
         interfaces to the transit network.  The RSVP half	is at least partially has full RSVP capable; it
         capability.  It is able to pro-
  cess PATH do MF classification, if required,
         and	RESV messages but it is	not necessarily	required able to
  store	full RSVP state	and it is not required police traffic that will be passed to provide MF classifica-
  tion. the
         border router.

         The diff-serv half of the edge router provides the an interface to
         the admis-
  sion control function	for the diff-serv network. We shall network's admission control function, which we
         refer to
  this function	from here on as	the 'DACS' (diff-serv admission	control
  service). as `DSAC' (Diff-Serv Admission Control).

         The	DACS is customer(s) (owner(s) of the stub networks) and the carrier
         owning the transit network will negotiate a process that is likely contract for the
         capacity to (but is not	required
  to) run be provided at least partially, on the routers. each of a number of standard diff-
         serv service levels.  If the service agreement between the stub
         networks and the transit networks is statically pro-
  visioned provisioned,
         then the DACS DSAC can be	as simple as simply based upon a table which that specifies
         capacity at each service level.  If the service agreement is
         dynamic, the DACS DSAC may communicate with counterparts within the
         diff-serv net-
  work network (such as a bandwidth broker [4])	and may	be able in order to
         make	admis-
  sion admission control decisions based on provisioned limits as
         well as the topology and the capacity of the diff-serv network.

  5.1.3	Boundary Routers

  These

         Since the individual int-serv flows are conventional boundary routers. In policed according to
         int-serv rules within the example illustrated,
  they stub network, the edge router needs
         to shape only the aggregate stream, not the individual flows.

      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 neither required neither to
         provide MF classifi-
  cation classification nor must to mark the DS-field (with the
         possible exception of dif-
  ferential differential marking to indicate	out of profile traffic [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 net-
  works. 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

			Use Of RSVP with Diffserv	      June, 1998

  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.

  5.1.4 indicate out-of-
         profile traffic [10, 8]).

      3.1.5 Stub Networks

  The

         A stub networks consist network consists of int-serv capable hosts and some
         number of
  leaf routers.	Leaf  These routers within the	stub networks may or may not reasonably be
  int-serv capable. Since they are relatively small networks, it is rea-
  sonable assumed to assume that they are int-serv
         be RSVP/int-serv capable, but although this is might not
  necessary. 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 identification, per-
         flow classification, signaling, and or admission con-
  trol and, in that case, control and will
         pass RSVP messages (requesting per-flow
  QoS) unhindered.

  5.1.5

      3.1.6 Transit Network

         The transit network is not typically capable of per-flow identifica-
  tion,
         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	perfor-
  mance performance
         (see [8]).  The transit network may include multiple carrier net-
  works.

  5.1.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 depending on the granularity of allotment (temporally
  coarse or temporally fine grained).

  5.1.7	Mapping	from Intserv
         networks.

      3.1.7 Service Type to DS-field

  In our proposal, we use RSVP signaling to provide admission control to
  specific service levels in the diff-serv, as well as the intserv net-
  work. Mapping

         RSVP signaling requests carry an intserv int-serv service type, describ-
  ing the type and a
         set of service they expect quantitative parameters known as a "flowspec"; these
         describe the QoS expected from the intserv int-serv regions of the
         network.  At each hop in an intserv int-serv network, the generic intserv ser-
  vice int-
         serv service requests are interpreted in a form meaningful to
         the specific
  media. link layer medium.  For example, at an ATM hop, a
         VC of the correct type (CBR, ABR

			Use Of RSVP with Diffserv	      June, 1998 or VBR) is established [13].
         At an 802.1 hop, the intserv int-serv service type is mapped to an
         appropriate 802.1p priority level [5].

  Similar mapping is necessary from Intserv Service type to DS-field. At
  the boundary between

         In our model, the intserv entire diff-serv network and plays the role of a diff-serv network, it
  is necessary for edge	devices
         single virtual link layer as far as RSVP/int-serv are
         concerned.  Therefore, the int-serv service request must be
         mapped to map the DS-field when the packets enter the diff-serv
         cloud.  The requested intserv int-serv service must be mapped to a
         diff-serv service level that can reasonably extend the intserv ser-
  vice int-serv
         service type requested by the application.  The edge device router can
         then pro-
  vide 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.

  We assume that one

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

         Default

              In the first scheme (called "default map-
  ping"), we propose a this scheme, there is some standard, well-known mapping
              from intserv int-serv service type to a PHB that will invoke the
              appropriate behavior in the diff-
  serv diffserv network.	The mapping is not necessarily one-to-one.

              To improve the quality of the mapping, it may prove
              necessary to add additional information to an int-serv QoS
              request.  For example,
  controlled-load consider QoS requests for two
              different flows, one interactive voice traffic will 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 a PHB
  having different latency characteristics than	controlled-load	latency
  tolerant traffic.
              diff-serv services.  For this reason reason, we suggest adding a
              qualifier to the
  intserv int-serv service type indicating its
              relative latency tolerance (high or low).  The qualifier
              would be defined as a standard object in
  intserv int-serv
              signaling messages.

         Customer-Specified

              In an	alternate scheme (called "customer-specified mapping"),	we allow
  the devices at this scheme, the edge of the diff-serv region of routers in the network customer (stub)
              networks are allowed to modify the well-known service mapping. Under this approach,  RESV
              messages ori-
  ginating originating at hosts will carry the usual intserv int-
              serv service type (with (perhaps with a qualif-
  ier, qualifier, as described
              above).  When a RESV messages arrive message arrives at the interface
  of the int-serv and diff-serv	regions	(e.g. edge router ER1 in Figure 1,
  where	the traffic
              from which the stub network traffic enters the diff-serv region), region (e.g.,
              router ER1 in Figure 1), the edge device will determine router determines the
              PHB code point that should be used to obtain the
              corresponding diff-serv service level.  This value information
              is appended to the RESV message by the edge device ER1 and is carried to the
              sending host.  When the RESV message arrives at the
              sending host, the sender (or intermediate intserv int-serv
              routers) will mark start marking outgoing packets with the indicated PHBs.

  The
              PHB code point.

         A decision to modify override the well-known service mapping at the
         edge devices will router may be based on edge-device configuration and/or a policy decision at the
  edges.
         decision.  For example, when a reservation request arrives at
         the edge of diff-
  serv network and ingress to a diff-serv network, if enough accepted reservations
         have already been accepted to
  reach reached the pre-negotiated capacity limit at the
         corresponding service
  level, level then the device edge router may decide to
         use a PHB corresponding to a different
  (less	assured?) service level level, based on
         an administratively set administratively-set policy.

  5.2 How

   3.2 Example: Obtaining End-to-End QoS is Obtained

			Use Of RSVP with Diffserv	      June, 1998

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

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

      2.   The PATH message is carried toward the receiving host. host Rx.  In
           the
  sending sender's stub network, standard RSVP processing will be 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. It is
           network, and then processed in the receiving stub network router ER2 according to
           standard RSVP processing rules.

      5. At   When the receiving host, PATH message reaches the receiving host Rx, its QoS
           process generates an RSVP RESV message, indicating interest
           in the offered traffic, traffic at a certain
  intserv 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 receiving 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. At	this point,   In ER1, the RESV message triggers DACS DSAC processing.  The
  DACS DSAC
           compares the resources requested to the resources available
           at the corresponding diff-serv service level, in the diff-serv diff-
           serv enabled transit network.  If the RESV message is
           admitted, the	DACS 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
  will be is rejected and the available
           capacity for the service class
  will remain remains unchanged.

      10.  The RESV message proceeds through the sending sender's stub network.
           RSVP nodes in the sending stub network may reject it.  If it
           is not

			Use Of RSVP with Diffserv	      June, 1998 rejected, it will arrive at the sending host. sender host Tx.

      11.  At the sending host, 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	intserv 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). It

           Tx begins to set the DS-field in the headers of transmitted packets,
           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 end-to-end QoS through a combi-
  nation 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.

  5.3

   3.3 Variations of the Model

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

  5.3.1	Admission Control

  5.3.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	agree-
  ment consists	of a table of capacities available to a	customer's stub
  network, at each diff-serv service level. In this case, DACS func-
  tionality is provided	at the edge routers in the stub	networks. The
  'diff-serv half' of these routers appear to the 'RSVP	half' as a send-
  ing 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.

  5.3.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 pro-
  vided	by coupling the	stub network's admission control with the

			Use Of RSVP with Diffserv	      June, 1998

  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 imple-
  mented at the	edge router (in	the stub network), at the boundary
  router (in the transit network), or at the bandwidth broker for the
  intserv network.

  5.3.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 just
      presented.

      3.3.1 Moving the Boundary

         We have assumed 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 RSVP/int-serv
         network and the diff-serv
  network. For example,	intserv	admission control requests may trigger
  diff-serv admission control requests network lies in the edge routers.
         Alternative models could shift this boundary to bandwidth brokers only when
  some high-water the left or low-water resource	threshold is crossed. Separate
  high-water and low-water thresholds provide hysteresis to prevent
  thrashing.

  5.3.1.4 Roles	of Policy and Resource Based Admission Control

  It is	necessary to provide both resource and policy based admission
  control
         the right in Figure 1.  It could for example, be placed within
         the diff-serv network as well as border routers in the intserv transit network.  In this case, 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
         DSAC would be implemented entirely within the diff-serv network are	likely to
         (and would essentially be at the per-intserv	network	(per-
  customer of bandwidth broker proposed in
         [4]); however, it would require that the diff-serv network) granularity.

  In the intserv network, resource based admission control is handled by
  RSVP enabled border
         routers (and SBMs [2]). Policy based admission control is
  handled by be RSVP capable policy servers. These	assure that intserv
  resources are	allotted to intserv customers according	to policy
  specific to capable.

         Alternative, the intserv network. In addition,	policy servers within boundary could be shifted all the intserv network must also	assure that appropriate	policy is
  applied when diff-serv resources are allotted way to intserv customers.

  5.3.2	Setting the DS-field at	Intermediate Nodes

  In
         end hosts.  This would mean that the example described, hosts 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 signaling and mark within
         the DS-
  byte corresponding lost to signal its needs.  The host would implement per-
         flow policing, the admitted service level. Note that these
  functions can	be separated. DSAC function, and packet marking.

      3.3.2 Service Agreements

         o    Statically-Provisioned Service Agreements

              In the example, the function of RSVP sig-
  naling is to invoke QoS in the intserv network simplest model, service agreements are negotiated
              statically between stub networks and to	provide	end-to-
  end admission	control. The function transit networks.  A
              service agreement consists of marking the DS-field is a table of capacities
              available to
  reduce the need for MF classification a stub network, at routers. (MF	classification each diff-serv service
              level.  In this case, DSAC functionality is required provided at
              the ingress to	a diff-serv network only to determine

			Use Of RSVP with Diffserv	      June, 1998 edge routers in the customer stub networks.  The `diff-serv
              half' of these routers appear to whom the traffic belongs. If an `RSVP half' as a
              sending interface is dedicated
  to with resource limits defined by the customer, no MF classification	need
              service agreement table.  While there may be	done. In this case, any
  MF classification on behalf 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 diff-serv ingress point
              network is	provided
  as completely independent.

         o    Dynamic Service Agreements

              In a more sophisticated model, service to the agreements between
              customer stub networks and goes	beyond policing	requirements).

  It is	possible carrier transit networks are
              more dynamic.  Customers may be able to mark the DS-field at intermediate routers rather
  than at the host and still dynamically
              request changes to	realize	many of the benefits of	our
  approach. service agreement.  In this case, intermediate routers may use a
              statically provisioned edge router cannot provide the RSVP	signal-
  ing to configure an MF classifier and	marker.	Therefore,
              required DSAC functionality.  Instead, DSAC functionality
              must be provided by coupling the confi-
  guration of MF classifiers and markers is dynamic (minimizing stub network's admission
              control with the
  management burden) and full resource and policy based transit network's admission con-
  trol can be applied. control.

              The disadvantages of marking the DS-field two admission control mechanisms meet at intermediate routers
  (instead of the host)	are that full MF classifiers are required at boundary
              between the
  intermediate nodes diff-serv network and that responsibility for traffic separation is
  shifted away from the	host.

  Nonetheless, this approach is	necessary to support those hosts which int-serv network.
              This boundary may be capable of RSVP signaling, but	which are not capable of marking implemented at the DS-field.	In addition, there may be cases	in which edge router (in
              the network
  administrators wish to shift stub network), at the responsibility border router (in the transit
              network), or at the bandwidth broker for traffic separation
  away from the	hosts. In particular, we expect int-serv
              network.

              Note that there coupling int-serv and diff-serv admission
              control does not imply that each int-serv admission
              control request will	continue
  to result in DSAC processing.  Int-serv
              admission control requests may be	a need for top-down provisioned	MF classification, especially
  for qualitative (as opposed to quantitative) QoS applications.

  6. Managing Different	Resource Pools

  We have focused largely on aggregated at the class of applications that use	RSVP to
  explicitly signal per-flow QoS requirements and which	expect end-to-
  end tight QoS	assurances, spanning both
              boundary between the intserv int-serv and diff-serv
  regions of the diff-serv network. We have been referring
              For example, int-serv admission control requests may
              trigger DSAC requests to these applications
  as 'quantitative QoS applications'.

  However, diff-serv networks also bandwidth brokers only when some
              high-water or low-water resource threshold is crossed.
              Separate high-water and low-water thresholds can provide loose QoS
              hysteresis to	applications
  that do not explicitly signal. Network managers can allot qualitative
  QoS applications specific QoS	in prevent thrashing.

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

      3.3.3 Setting the DS-field

         Allowing hosts to set the diff-serv DS-field directly may alarm network
         administrators.  The obvious concern is that hosts may attempt
         to recognize traffic from these applications.	Thus, 'steal' resources.  In fact, hosts may attempt to exceed the clas-
  sification fields are	used as
         negotiated capacity at a form particular service level regardless of implicit signaling.

  Network administrators must therefore	share
         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	network
  resources between three types PHB).

         In summary, the security concerns of traffic:

  a. Quantitative (explicitly signaled)	QoS application	traffic
  b. Qualitative (implicitly signaled) QoS application traffic
  c. All other (best-effort) traffic

			Use Of RSVP with Diffserv	      June, 1998

  Quantitative QoS applications	rely on	explicit admission control for
  their	traffic, marking the DS-field at
         the	edges edge of the diff-serv network.	This traffic may network can be refused admission for a particular	diff-serv service level. However
  - if admitted, the traffic is	assured	tight QoS. Of course, this is
  true only 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 extent that,
         granularity at any ingress point, 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 total	offered
  traffic at each service level	does not exceed task of protecting their transit networks,
         while the resources requested
  through customers are focused on the sum of admission control requests.

  Traffic from qualitative QoS applications is provided	with implicit
  admission control as a result task of shaping and
         policing at ingress points. However,
  implicit admission control does not provide explicit feedback their own traffic to
  applications.	 Therefore, it be in compliance with their
         negotiated token bucket parameters.

         It is difficult also possible to assure that mark the total
  traffic offered DS-field at intermediate
         routers rather than at an	ingress	point will not exceed the provisioned
  capacity for a particular service level. When the traffic exceeds host and still realize many of the
  allowed limit,
         benefits of our approach.  In this case, intermediate routers
         may use the feedback RSVP signaling to configure an MF classifier and
         marker.  Then the applications is indirect in configuration of MF classifiers and markers
         would be dynamic (minimizing the
  form management burden), and full
         resource- and policy-based admission control could be applied.

         The disadvantages of packet loss or through an ECN	CE mark marking the DS-field at intermediate
         routers (instead of the bottleneck.
  Thus, host) are that full MF classifiers are
         required at the intermediate nodes and that responsibility for
         traffic	from qualitative applications separation is offered only loose QoS.

  From shifted away from the network manager's perspective, there host.

         Nonetheless, marking at intermediate routers will be necessary
         to support those hosts which support RSVP signaling but are three pools
         incapable of
  resources in marking the diff-serv network; one for traffic sourced by quanti-
  tative QoS applications, one for traffic sourced by qualitative QoS
  applications and one for best-effort traffic.	These pools must be iso-
  lated	from each other	by DS-field.  In addition, there may be
         cases in which the appropriate configuration of policers and
  classifiers at ingress points network administrators wish to shift the diff-serv network, and by
  appropriate provisioning within the diff-serv	network. To provide pro-
  tection
         responsibility for quantitative QoS traffic in diff-serv regions of separation away from the net-
  work hosts.  In
         particular, we suggest expect that the DS codepoints allotted there will continue to such traffic must
  not overlap the codepoints assigned be a need for
         top-down provisioned MF classification, especially for
         qualitative (as opposed to other traffic (qualitative quantitative) QoS
  and best-effort traffic).

  7. Issues

  7.1 Setting 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 DS-field at Hosts

  The thought implications of allowing hosts this framework for
   diff-serv.

   4.1 Requirements for Diff-Serv

      In order to set use a diff-serv network as described in this draft,
      the DS-field directly, may alarm diff-serv network administrators. The obvious concern is that hosts may	attempt
  to 'steal' resources.	In fact, hosts may attempt to exceed must satisfy the nego-
  tiated capacity at following requirements.

      1.   A diff-serv network must be able to provide standard QoS
           services between its border routers, and such a particular service level	regardless must
           be selectable by specifying a standard code in a (PHB) sub-
           field 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 DS-field of a particular diff-serv PHB).

  In either case, it may sometimes packet.

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

      3.   Diff-serv networks must provide admission control information
           to protect the network int-serv network.  This information can be provided by policing
           a dynamic protocol or, at various points, both within the stub network and/or 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 interface	to
           egress point from the transit diff-serv network.	For example, within the	stub
  network, routers may police

   4.2 End-to-End Integrity of the aggregate traffic coming from DS-field

      Our model assumes that int-serv networks uses a host code point of the
      DS-field in order to ensure that specify the host is not exceeding its traffic limit. This
  assures protection against malicious users or	malfunctioning equipment

			Use Of RSVP with Diffserv	      June, 1998

  and, overall,	ensures desired PHB within the transit
      network.  It also assumes that customers do not use more resources than
  they are entitled to,	at each packets submitted to the transit
      network specifying a certain DS-field will receive a standard
      service	level. If throughout the sending host transit network.  Strictly speaking, this
      does not do dictate that the marking, intermediate and/or boundary routers transit network must	provide
  MF classification, mark and police. If leave the sending host does do DS-field
      field intact.  For example, the
  marking, these routers need only to provide BA classification	and to
  police border router may map a DS-field
      value set by the aggregate host or edge router to ensure that the customer is not exceeding the
  aggregate capacity negotiated	for the	service	level. It should, how-
  ever,	be noted that some PHBs	(e.g., a "billing" PHB [14]) may not
  require any policing at all at any point different value before
      forwarding the data packets.

      However, we see little value in allowing the network.

  Requiring hosts PHB field to mark the DS-field has be
      altered within the effect of moving	respon-
  sibility network.  This is likely to the edge perpetuate local
      and incompatible interpretations of the network, in more ways than one. With this
  approach, boundary field.

   4.3 Policing and Shaping

      We are assuming that border routers will police in aggregate.  As
      a result, the cus-
  tomer customer cannot rely on boundary 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 boundary
      border routers and still allows protection against misbehaving
      hosts/users.

      Ideally, hosts should provide per-flow shaping at their sending inter-
  faces.
      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 polic-
  ing policing (or even re-shaping) at the egress point from
      the customer's net-
  work network unless the policing agreement at the other
      side is known to accommodate the transient bursts that can arise
      from adding the flows.

  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 boundary
  routers

   4.4 Managing Resource Pools

      Network administrators must police, thereby pushing finer grain shaping and policing
  responsibility be able 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 share diff-serv network
      resources between three types of shaping and
  policing their own traffic:

      a. Quantitative (explicitly signaled) QoS application traffic to

      b. Qualitative (implicitly signaled) QoS application traffic

      c. All other (best-effort) traffic

      These pools must be in compliance with their negotiated
  token	bucket parameters.

  7.2 End-to-End Integrity of isolated from each other by the DS-field

  Our proposal assumes that hosts use a	standard coding	for specifying a
  desired PHB in some sub-field appropriate
      configuration of the DS-field. It also assumes that
  packets submitted policers and classifiers at ingress points to the network with	a certain PHB specified, will
  receive a standard service throughout
      diff-serv network, and by appropriate provisioning within the
      diff-serv network. Strictly
  speaking, this does not dictate that the transit network must	leave
  the PHB field	intact.	For example, after a sending host marks	the

			Use Of RSVP with Diffserv	      June, 1998

  packets with PHB  value based	on either the well-known, "default" or
  "customer-specified" mapping,	the boundary router may	re-map it to a
  different value before forwarding  To provide protection for quantitative QoS
      traffic in diff-serv regions of the	data packets. However, network, we see
  little value in allowing suggest that the PHB field
      DS codepoints allotted to be altered within such traffic must not overlap the net-
  work.	This is	likely
      codepoints assigned to perpetuate local other traffic (qualitative QoS and incompatible interpreta-
  tions	of the field.

  7.3 Carrying best-
      effort traffic).

5. Other Models

   5.1 RSVP Messages across Transit Networks

  Our proposal presumes	end-to-end and Diff-Serv

      Since RSVP	both was originally designed to support int-serv, we use the
      term "RVSP/int-serv" as	a means	for communica-
  tion between sending host and	receiving host and optionally, for the
  support of true complement to diff-serv.  However,
      RSVP reservations in stub networks (or in intermediate
  networks which and int-serv are interested	in the fine grain separable, and RSVP information).
  Therefore, we	require	that may be used as a
      general-purpose QoS signaling protocol.  For example, RSVP messages might
      be carried transparently
  across the transit networks. In [8], mechanisms are proposed used for doing
  so dynamic provisioning and admission control in	a manner that does not require the routers
      diff-serv region of the network.  Routers in the transit net-
  work diff-serv region
      would continue use the DS-field in the IP header to understand/interpret RSVP messages identify and does not adversely
  impact
      offer services to flow aggregates.

   5.2 Qualitative QoS

      This document has focused largely on the transit network.

  8. Dependencies class of Intserv on	Diff-Serv applications
      that use RSVP to explicitly signal per-flow QoS requirements and
      that expect end-to-end tight QoS assurances.  We have described a framework	for been
      referring to these applications as `quantitative QoS
      applications'.  Suitable end-to-end services must also be
      available to qualitative QoS in which intserv net-
  works	are customers of diff-serv networks. We	believe applications.  The services that the bene-
  fits of this framework
      these applications require are sufficient	to justify generally less demanding.

      Qualitative services can be obtained from the consideration of
  intserv dependencies as diff-serv work proceeds. In particular, we
  wish to draw attention to regions of
      the	following dependencies:

  1. We	expect that we network with loose top-down provisioning.  Network managers
      can invoke a standard end-to-end	(within configure classifiers at the ingress to the diff-serv network) network
      to recognize traffic requiring specific qualitative service by	specifying a standard code in
      levels.  Thus, these classification fields are used as a	(PHB)
  sub-field form of
      implicit signaling.  In the DS-field int-serv portion of a packet	launched into a	diff-serv
  network.

  2. Diff-serv networks	must provide the network,
      qualitative QoS applications can get best-effort service, which
      may be good enough.

      There would be no explicit admission control information for such qualitative
      QoS applications.  Therefore, it is difficult to assure that the intserv network. At
      total traffic offered at an ingress point will not exceed the very least, this is through static
  service level	agreements. Preferably,	this is	through
      provisioned capacity for a dynamic
  protocol. If particular service level.  When the intserv to diff-serv	boundary
      traffic exceeds the allowed limit, there is implemented only indirect feedback
      to the applications, in the
  transit network boundary routers, then this protocol is RSVP.

  3. We	expect that diff-serv networks will transparently carry	RSVP messages
  such	that they form of packet loss or an Congestion
      Experienced mark from Explicit Congestion Notification (ECN).
      Thus, traffic from qualitative applications can be recovered at the egress point from the	diff-serv
  network.

  9. offered only
      loose QoS.

   5.3 Multicasting

      <To be written>

6. Security Considerations

   We are proposing that RSVP signaling be used to obtain resources in
   both the diff-serv and intserv int-serv regions of the	network. Therefore, all
  RSVP security	considerations apply [11]. In addition,	network

			Use Of RSVP with Diffserv	      June, 1998

  administrators are expected to protect network resources by configur-
  ing secure policers at interfaces with untrusted customers.

  10. 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
   [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
   [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 S.,"Aggregating RSVP based QoS
   Requests", Internet Draft, November 1997 1997.

   [9] Clark, D.	and  Wroclawski, J., "An Approach to Service
  [10] Blake, S. and Nichols, K., "Differentiated Kathleen, et al., "Definition of the Differentiated
   Services Operational
  Model Field (DS Field) in the IPv4 and Definitions", Internet Draft, February 1998 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

			Use Of RSVP Controlled-
   Load Service and Guaranteed Service with Diffserv	      June, 1998 ATM", RFC2381, August 1998.

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

  11. Acknowledgments

  Authors thank	the

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

APPENDIX A. Terminology

   The following individuals for their comments terms were used in this draft.

   Int-serv
        The part of an internet that led uses per-flow classification,
        signaling, and admission control to
  improvements 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 the previous version(s) function properly.

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

   QoS  Application that requires some form of this draft: David Oran,
  Andy Veitch, Curtis Villamizer, Walter Weiss, QoS, either qualitative
        or quantitative.

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

   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 Russel white.

  12. experience, typically from a
        console, based upon traffic predictions.

   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

			Use Of RSVP with Diffserv	      June, 1998

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