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.
