Internet Engineering Task Force                Y.Bernet,		 Y. Bernet, Microsoft
  Internet Draft				 R. Yavatkar, Intel
  draft-ietf-diffserv-rsvp-01.txt		 P. Ford, Microsoft
						 F. Baker, Cisco
						 L. Zhang, UCLA
						 K. Nichols, Bay Networks Cisco Systems
						 M. Speer, Sun Microsystems


						 November, 1998

	   A Framework for Use of RSVP with Diff-serv Networks

			   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

  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 view the entire list of current Internet-Drafts, please check
  the "1id-abstracts.txt" listing contained in the Internet-Drafts
  Shadow Directories on (Africa),
  (Northern Europe), (Southern Europe),
  (Pacific Rim), (US East Coast), or
  (US West Coast).

  A revised version of this draft document will	be submitted to	the
  RFC editor as	an Informational RFC for the Internet Community.
  Discussion and suggestions for improvement are requested.  This
  document will	expire before December, 1998. May 1999.	Distribution of	this
  draft	is unlimited.

			Use Of RSVP with Diffserv	      June, 1998

  1. 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, as specified, enables applica-
  tions	to signal per-flow requirements	to the network.	Intserv	parame-
  ters are used	to quantify these requirements for the purpose of admis-
  sion control.	However, as work on RSVP and Intserv has proceeded, we
  have recognized the following	basic limitations, which impede	deploy-
  ment of these	mechanisms in the Internet at large:

  1) The reliance of RSVP on per-flow state and	per-flow processing
  raises scalability concerns in large networks.
  2) Today, only a small number	of hosts generate RSVP signaling.
  While	this number is expected	to grow	dramatically, many
  applications may never generate RSVP signaling.
  3) Many applications require a form of QoS, but are unable to
  express these	requirements using the intserv model.

  At present, the market is pushing for	immediate deployment of	a QoS
  solution that	addresses the needs of the Internet as well as enter-
  prise	networks. This push has	led to the development of Differentiated
  services (diff-serv).	In contrast to RSVP's per-flow orientation,
  diff-serv networks classify packets to one of	a small	number of aggre-
  gated	flows, based on	the setting of bits in the TOS field of	each
  packet's IP header. Thus, in addition	to eliminating the reliance on
  per-flow state, diff-serv QoS	can initially be deployed using	top-down
  provisioning,	with no	requirement for end- to-end	end-to-end signaling.

  At the same time however, it is important to assure that the diff-
  serv diff-serv
  mechanisms deployed, interoperate effectively	with hosts and net-
  works networks
  that provide per-flow	QoS in response	to end-to-end signaling. This 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
  will signal end-to-end on their behalf.

  This draft proposes a	framework in which diff-serv capable transit networks
  provide aggregate QoS	services, in support of and they co-exist and	inter-operate
  with RSVP/Intserv capable hosts and stub networks, which use end-to-end end-to-
  end signaling. In

  For instance,	in one example of such a model,	diff-serv mechanisms are
  used within transit networks and at the boundaries between them, while
  either diff-serv or RSVP/Intserv mechanisms are used within stub networks net-
  works	and at the boundaries between stub networks and	transit diff-serv	diff-
  serv networks. Managers of the transit networks will provision a pool
  of network resources to be available in response to end-to-end signaling. signal-
  ing. The remaining resources will be allotted	using traditional 'top-down' '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 a case, routers in the	diff-serv region
  will continue	use the	DSCP value in the IP datagram to identify and
  offer	services to flow aggregates. However, some of these services
  will use dynamic provisioning	and require admission control using
  explicit signaling when a new	flow is	to be added to the aggregate.
  Under	such 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 deployment of diff-serv networks and

                        Use Of RSVP with Diffserv             June, 1998
  RSVP/Intserv networks	to proceed at their own	pace, providing	immedi-
  ate 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].

  2. 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	video-on-demand, and various non- multimedia 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 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.

  Ultimately, we aim to	clearly	define 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 of their net-
  works	(or, the degree	to which RSVP/Intserv capabilities are pushed
  towards the core).

  Even though one of the goals of this draft is	to describe a framework
  for co-existence of RSVP/intserv 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 of an
  internet that	uses per-flow identification, signaling, 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. Quantitative QoS applications - applications for which QoS

                        Use Of RSVP with Diffserv             June, 1998
  requirements are readily quantifiable, and which rely	on these QoS
  requirements to function properly.

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

  e. QoS applications -	applications that require 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 absolute and quantifiable,
  though they may or may not provide 100% guarantee.

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

  i. RSVP/Intserv - RSVP is a signaling	protocol. Intserv (in this
  context) is a	model for quantifying traffic that is useful for
  admission control purposes. In this document,	we use the terms
  together, to discuss the RSVP/Intserv	network, in contrast to	the
  diff-serv network. However, the two are separable and	much of	the

			Use Of RSVP with Diffserv	      June, 1998

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

  4. 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 both	quantitative and qualitative QoS applications. We con-
  sider	these requirements in the context of the following general

	  / 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

                        Use Of RSVP with Diffserv             June, 1998
  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-behaviours' 'per-hop-behaviors' (PHBs	[10]). We expect
  that concatenation of	certain	well-defined PHBs will yield cer-
  tain 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 appli-

			Use Of RSVP with Diffserv	      June, 1998

  applications require are generally less demanding. They can be loosely pro-
  provisioned (in a top-down manner) in	the diff-serv regions of the net-
  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 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 end-to-end
  service levels for their traffic flows. Within the intserv regions of
  the network quantitative QoS applications do so by using RSVP sig-
  naling	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

                        Use Of RSVP with Diffserv             June, 1998

  service ser-
  vice based on	the contents of	the DS-field in	packet headers.
  Therefore,	There-
  fore,	it is necessary	for QoS	applications to	effect the correct
  marking mark-
  ing of DS-fields before their	packets	are submitted to the diff-
  serv diff-serv
  network. (This is particularly true for quantitative QoS applica-
  tions, 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 general gen-
  eral mechanisms for doing so:

  1. Hosts may directly	mark DS-fields in the transmitted packets of
  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, marking will be done based	on host	configuration or
  local	communication between QoS applications and the host operating
  system. In the second	case, marking will be done based on top-down
  configuration	of the marking router's	MF classifier/marker (by manual
  configuration	or via automated configuration scripts)	or based on
  standard signaling between QoS applications and the marking router's

  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.

  4.2.1	Minimal	Management Burden

			Use Of RSVP with Diffserv	      June, 1998

  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.

  4.2.2	Granularity of Allotment

  The term 'granularity' is used here to refer to the degree of	specifi-
  city 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	follow-
  ing 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

                        Use Of RSVP with Diffserv             June, 1998
  should receive service level A, while	all traffic from subnet
  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

  4.2.3	Difficulties in	Identification of Application Flows

  Routers may not be able to readily identify specific application flows
  based	on network and/or transport layer fields in a packet.

  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).

  4.3 Admission	Control

  Quantitative QoS 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 inter-
  mediate 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 based on provisioning. The
  problem with implicit	admission control is that it breaks 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 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 polic-
  ing based on MF classification 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 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

                        Use Of RSVP with Diffserv             June, 1998

  explicit expli-
  cit admission	control.

  4.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 net-
  work 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	end-to-end admission
  control be based on policy as	well as	resource availability.

  5. Intserv as	a Customer 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.	 In this sec-
  tion,	we will	describe the operation of one instantiation of such a
  network (see figure 1). The following	assumptions apply:


  5.1.1	Host Capabilities

  Both sending and receiving hosts use RSVP to communicate QoS require-
  ments	of certain QoS aware applications running on the host. A QoS
  process within the host operating system generates RSVP signaling on

			Use Of RSVP with Diffserv	      June, 1998

  behalf of the	applications. This process also	invokes	traffic	control.
  Host traffic control includes	marking	the DS-field in	transmitted
  packets and shaping transmitted traffic per token bucket specifica-
  tions. 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


  5.1.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 con-
  sisting of two halves; the standard RSVP half, which interfaces to the
  stub networks, and the diff-serv half, which interfaces to the transit

  The RSVP half	is at least partially RSVP capable; it is able to pro-
  cess PATH and	RESV messages but it is	not necessarily	required to
  store	full RSVP state	and it is not required to provide MF classifica-

                        Use Of RSVP with Diffserv             June, 1998

  The diff-serv	half of	the router provides the	interface to the admis-
  sion 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 pro-
  visioned 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 net-
  work (such as	a bandwidth broker [4])	and may	be able	to make	admis-
  sion 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	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, neither required	to provide MF
  classification classifi-
  cation nor to must mark the DS-field (with the possible exception of the in/out bit). dif-
  ferential marking to indicate	out of profile traffic [10, 8] 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. 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 diff-serv boundary	routers
  must be RSVP capable.


  5.1.4	Stub Networks

  The stub networks consist of int-serv	capable	hosts and some number of
  leaf routers.	Leaf routers within the	stub networks may or may not be
  int-serv capable. Since they are relatively small networks, it is rea-
  sonable to assume that they are int-serv capable, but	this is	not
  necessary. If	they are not int-serv capable, we assume that they are
  not capable of per-flow identification, signaling, and admission con-
  trol and, in that case, will pass RSVP messages (requesting per-flow
  QoS) unhindered.


  5.1.5	Transit	Network

  The transit network is not typically capable of per-flow identification, signal-
  ing, identifica-
  tion,	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

                        Use Of RSVP with Diffserv             June, 1998 messages	transparently, with minimal or no impact on its performance	perfor-
  mance	(see [8]). The transit network may include multiple carrier networks.

  5.0.6 net-

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

  5.0.7 network depending on the granularity of allotment (temporally
  coarse or temporally fine grained).

  5.1.7	Mapping	from Intserv 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.	RSVP signaling requests	carry an intserv service type, describ-
  ing the type of service they expect from the intserv regions of the
  network. At each hop in an intserv network, the generic intserv ser-
  vice requests	are interpreted	in a form meaningful to	the specific
  media. 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 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 the intserv network and a diff-serv network, it
  is necessary for edge	devices	to map the requested intserv service to
  a diff-serv service level that can reasonably	extend the intserv service ser-
  vice type requested by the application. The edge device can then provide admis-
  sion pro-
  vide 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 of	two schemes is used to map intserv service types
  to diff-serv service levels. In the first scheme (called "default map-
  ping"), we propose a standard, well-known mapping from intserv service
  type to a PHB	that will invoke the appropriate behavior in the diff-
  serv network.	The mapping is not necessarily one-to-one. For example,
  controlled-load interactive voice traffic will likely	map to a PHB
  having different latency characteristics than	controlled-load	latency
  tolerant traffic. For	this reason we suggest adding a	qualifier to the
  intserv service type indicating its relative latency tolerance (high
  or low). The qualifier would be defined as a standard	object in
  intserv signaling messages.

                        Use Of RSVP with Diffserv             June, 1998

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

  The decision to modify the well-known	mapping	at the edge devices will
  be based on edge-device configuration	and/or policy decision at the

  5.1  For example, when a reservation arrives at the edge of diff-
  serv network and if enough reservations have already been accepted to
  reach	the pre-negotiated capacity limit at the corresponding service
  level, the device may	decide to use a	PHB corresponding to a different
  (less	assured?) service level	based on an administratively set policy.

  5.2 How 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:

  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

                        Use Of RSVP with Diffserv             June, 1998
  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 and the available capacity for the service class
  will remain unchanged.

  10. The RESV message proceeds	through	the sending 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.

  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-field in the	headers
  of transmitted packets, to the value which maps to the Intserv
  service type specified in the	admitted RESV message.

  In this manner, we are able to obtain	end to end QoS through a combi-
  nation of networks that support RSVP style reservations and networks
  that support diff-serv style priortization. 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 Variations of the	Model

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


  5.3.1	Admission Control Statically Provisioned Service Agreements

                        Use Of RSVP with Diffserv             June, 1998

  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. 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 tran-

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

                        Use Of RSVP with Diffserv             June, 1998
  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 [2]). 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.


  5.3.2	Setting	the DS-field 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 sig-
  naling is to invoke QoS in the intserv network and to	provide	end-to-
  end admission	control. The function of marking the DS-field is to
  reduce the need for MF classification	at routers. (MF	classification
  is required at the ingress to	a diff-serv network only to determine

			Use Of RSVP with Diffserv	      June, 1998

  the customer to whom the traffic belongs. If an interface is dedicated
  to the customer, no MF classification	need be	done. In this case, any
  MF classification on behalf of the diff-serv ingress point is	provided
  as a service to the customer and goes	beyond policing	requirements).

  It is	possible to mark the DS-field 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	signal-
  ing to configure an MF classifier and	marker.	Therefore, the confi-
  guration of MF classifiers and markers is dynamic (minimizing	the
  management burden) and full resource and policy based	admission con-
  trol can be applied.

  The disadvantages of marking the DS-field at intermediate routers
  (instead of the host)	are that full MF classifiers are required at the
  intermediate nodes and that responsibility for 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-field.	In addition, there may be cases	in which the network
  administrators wish to shift the responsibility for traffic separation
  away from the	hosts. In particular, we expect	that there will	continue
  to be	a need for top-down provisioned	MF classification, especially
  for qualitative (as opposed to quantitative) QoS applications.

  6. Managing Different	Resource Pools

                        Use Of RSVP with Diffserv             June, 1998

  We have focused largely on the class of applications that use	RSVP to
  explicitly signal per-flow QoS requirements and which	expect end- to- end-to-
  end tight QoS	assurances, spanning both the intserv and diff-serv
  regions of the network. We have been referring to these applications
  as 'quantitative QoS applications'.

  However, diff-serv networks also provide loose QoS to	applications
  that do not explicitly signal. Network managers can allot qualitative
  QoS applications specific QoS	in the diff-serv network. This is
  achieved by configuring classifiers at the ingress to	the diff-serv
  network to recognize traffic from these applications.	Thus, the clas-
  sification fields are	used as	a form of implicit signaling.

  Network administrators must therefore	share diff-serv	network
  resources between three types	of traffic:

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

			Use Of RSVP with Diffserv	      June, 1998

  Quantitative QoS applications	rely on	explicit admission control for
  their	traffic, at the	edges of the diff-serv network.	This traffic may
  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 to the extent that,	at any ingress point, the total	offered
  traffic at each service level	does not exceed	the resources requested
  through the sum of admission control requests.

  Traffic from qualitative QoS applications is provided	with implicit
  admission control as a result	of policing at ingress points. However,
  implicit admission control does not provide explicit feedback	to
  applications.	 Therefore, it is difficult to assure that the total
  traffic offered at an	ingress	point will not exceed the levels provisioned
  capacity for a particular service level. When	the traffic exceeds the
  by policers. limit, the feedback to the applications is indirect in the
  form of packet loss or through an ECN	CE mark	at the bottleneck.
  Thus,	traffic	from qualitative applications is offered only loose QoS.

  From the network manager's perspective, there	are three pools	of
  resources in 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 the appropriate configuration of policers and
  classifiers at ingress points	to the diff-serv network, and by
  appropriate provisioning within the diff- serv diff-serv	network. To provide pro-
  tection for quantitative QoS traffic in diff-serv regions of the net-
  work we suggest that the DS codepoints allotted to such traffic must
  not overlap the codepoints assigned to other traffic (qualitative QoS
  and best-effort traffic).

  7. Issues

  7.1 Setting the DS-field at Hosts

                        Use Of RSVP with Diffserv             June, 1998

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

  In either case, it may sometimes be necessary	to protect the network
  by policing at various points, both within the stub network and/or at
  the inter-
  face interface	to the transit network.	For example, within the	stub
  network, routers may police the aggregate traffic coming from	a host
  to ensure that the host is not exceeding its traffic limit. This
  assures protec-
  tion protection against malicious users or	malfunctioning equipment

			Use Of RSVP with Diffserv	      June, 1998

  and, overall,	ensures	that customers do not use more resources than
  they are enti-
  tled entitled to,	at each	service	level. If the sending host does
  not do the marking, intermediate and/or boundary routers must	provide
  MF classif-
  ication, classification, mark and police. If the sending host does do the
  marking, these routers need only to provide BA classification	and to
  police the aggregate 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 in the network.

  Requiring hosts to mark the DS-field has the effect of moving	respon-
  sibility to the edge of the network, in more ways than one. With this
  approach, boundary routers police in aggregate. As a result, the cus-
  tomer	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 and policed within the customer's	sending	network.
  Overall, this	approach simplifies boundary routers and still allows
  protection against misbehaving hosts/users.

  Ideally, hosts should	provide	per-flow shaping at their sending inter-
  faces. 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 (or even re-shaping) at the egress point from the	customer's net-
  work 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 for form of policing	(per-flow or per-host) 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

                        Use Of RSVP with Diffserv             June, 1998
  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.

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

  Our proposal assumes that hosts use a	standard coding	for specifying a
  desired PHB in some sub-field	of the DS-field. 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.	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 the	data packets. However, we see
  little value in allowing the PHB field to be altered within the network. net-
  work.	This is	likely to perpetuate local and incompatible interpretations interpreta-
  tions	of the field.

  7.3 Carrying RSVP Messages across Transit Networks

  Our proposal presumes	end-to-end RSVP	both as	a means	for communica-
  tion 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 transparently
  across the transit networks. In [8] [8], mechanisms are proposed for doing
  so in	a manner that does not require the routers in the transit net-
  work to understand/interpret RSVP messages and does not adversely
  impact the transit network.

  8. Dependencies of Intserv on	Diff-Serv

  We have described a framework	for end-to-end QoS in which intserv net-
  works	are customers of diff-serv networks. We	believe	that the bene-
  fits 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-field of a packet	launched into a	diff-serv

  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 transparently carry	RSVP messages
  such	that they can be recovered at the egress point from the	diff-serv

                        Use Of RSVP with Diffserv             June, 1998

  9. 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 adminis-

			Use Of RSVP with Diffserv	      June, 1998

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

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

  [9] Clark, D.	and  Wroclawski, J., "An Approach to Service
  [10] Blake, S. and Nichols, K., "Differentiated Services Operational
  Model	and Definitions", Internet Draft, February 1998

                        Use Of RSVP with Diffserv             June, 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

  [13] Garrett,	M. W., and Borden, M., "Interoperation of Controlled-
  Load Service and Guaranteed Service Controlled-Load

			Use Of RSVP with ATM", Internet Draft, March Diffserv	      June, 1998
  [14] Weiss, Walter, "private communication", November	1998.

  11. 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.

  12. Author's Addresses

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

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

  Peter	Ford
  One Microsoft	Way,
  Redmond, WA 98052
  Phone: (425) 703-2032

  Fred Baker
  Cisco	Systems
  519 Lado Drive,
  Santa	Barbara, CA 93111
  Phone: (408) 526-4257

  Lixia	Zhang
  4531G	Boelter	Hall
  Los Angeles, CA  90095
  Phone: +1 310-825-2695

			Use Of RSVP with Diffserv	      June, 1998

  Phone: +1 310-825-2695

  Kathleen Nichols
  Bay Networks
  Cisco	Systems
  Email: Kathleen_Nichols@BayNetworks.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