Subject: Protocol Action: Format of the RSVP DCLASS Object to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 25 Sep 2000 17:03:47 -0400

The IESG has approved the following Internet-Drafts as Proposed
Standard:

 o Format of the RSVP DCLASS Object
	<draft-ietf-issll-dclass-01.txt>

 o Specification of the Null Service Type
	<draft-ietf-issll-nullservice-00.txt>

In the same action, the IESG approved publication of A Framework
For Integrated Services Operation Over Diffserv Networks 
<draft-ietf-issll-diffserv-rsvp-05.txt> as an Informational RFC.  

These documents are the product of the Integrated Services over
Specific Link Layers Working Group.  The IESG contact persons are
Allison Mankin and Scott Bradner.

Technical Summary
 
 The Integrated Services architecture provides a means for the delivery
 of end-to-end QoS to applications over heterogeneous networks. To
 support this end-to-end model, the Intserv architecture must be
 supported over a wide variety of different types of network elements.
 In this context, a network that supports Differentiated Services
 (Diffserv) may be viewed as a network element in the total end-to-end
 path, and a framework may described on this basis for the support of
 particular Integrated Services over Diffserv networks, with RSVP
 playing a key role.

 RSVP signaling may be used to request QoS services and enhance the
 manageability of application traffic's QoS in a differentiated service
 (diffserv or DS) network.  When using RSVP with DS networks it is
 useful to be able to carry Differentiated Services Code Points (DSCPs)
 in RSVP message objects.  One example of this is the use of RSVP to
 arrange for the marking of packets with a particular DSCP upstream
 from the DS network's ingress point, at the sender or at a previous
 network's egress router.  The DCLASS object is used to represent and
 carry DSCPs within RSVP messages.  The "Format of the RSVP DCLASS
 Object" document specifies the format of the DCLASS object and
 discusses its use.

 In the typical RSVP/Intserv model, applications request a specific
 Intserv service type and quantify the resources required for that
 service. For certain applications, the determination of service
 parameters is best left to the discretion of the network
 administrator. For example, Enterprise Resource Planning (ERP)
 applications are often mission critical, and they often require some
 form of prioritized service, but may not be able readily to specify
 their resource requirements. To serve applications of this sort, the
 notion of the 'Null Service' is defined. The Null Service allows
 applications to identify themselves to network QoS policy agents,
 using RSVP signaling, without requiring them to specify their resource
 requirements. QoS policy agents in the network respond by applying
 QoS policies appropriate for the application (as determined by the
 network administrator).  This mode of RSVP usage is particularly
 applicable to networks that combine differentiated service (diffserv)
 QoS mechanisms with RSVP signaling. In this environment, QoS policy
 agents may direct the signaled application's traffic to a particular
 diffserv class of service.

Working Group Summary

 The working group supported publication of these three documents, and
 they also received some discussion by the related WGs, RSVP and Diffserv.

Protocol Quality

 These documents were reviewed for the IESG by Allison Mankin.