draft-ietf-issll-dclass-00.txt   draft-ietf-issll-dclass-01.txt 
Y.Bernet, Microsoft Internet Draft Y. Bernet, Microsoft
Internet Draft Format of the RSVP DCLASS Object
Document: draft-ietf-issll-dclass-00.txt August, 1999
Usage and Format of the DCLASS Object With RSVP Signaling
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with all
all provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering Task
Task Force (IETF), its areas, and its working groups. Note that Force (IETF), its areas, and its working groups. Note that other groups
other groups may also distribute working documents as Internet- may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet- Drafts as time. It is inappropriate to use Internet- Drafts as reference material
reference material or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet- http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
Draft Shadow Directories can be accessed at Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1998). All Rights Reserved.
1. Abstract 1. Abstract
RSVP signaling may be used to enhance the manageability of RSVP signaling may be used to request QoS services and enhance the
application traffic's QoS in a differentiated service (diff-serv) manageability of application traffic's QoS in a differentiated service
network [intdiff]. In this model, certain network elements within or (diff-serv or DS) network. When using RSVP with DS networks it is
at the edges of the diff-serv network may use RSVP messages to useful to be able to carry carry Differentiated Services Code Points
effect admission control or to apply QoS policy. One mechanism by (DSCPs) in RSVP message objects. One example of this is the use of RSVP
which network elements may apply QoS policy is by causing a DCLASS to arrange for the marking of packets with a particular DSCP upstream
object to be returned to a sending host in an RSVP RESV message. The from the DS network's ingress point, at the sender or at a previous
DCLASS object indicates one or more diff-serv codepoints (DSCPs) network's egress router.
that the sender should include when submitting packets on the
admitted flow, to the diff-serv network. This draft describes the
usage and format of the DCLASS object.
3. Signaling Protocol The DCLASS object is used to represent and carry DSCPs within RSVP
messages. This draft specifies the format of the DCLASS object and
briefly discusses its use.
This section describes the mechanics of using RSVP signaling and the 2. Introduction
DCLASS object for effecting admission control and applying QoS
policy within a diff-serv network. It assumes a standard RSVP sender
bernet expires February, 2000 1 This section describes the mechanics of using RSVP [RSVP] signaling and
draft-ietf-issll-dclass-00.txt August, 1999 the DCLASS object for effecting admission control and applying QoS
policy within a Differentiated Service network [DS]. It assumes
standard RSVP senders and receivers, and a diff-serv network somewhere
in the path between sender and receiver. At least one RSVP aware
network element resides in the diff-serv network. This network element
may be a policy enforcement point (PEP) [RAP] or may simply act as an
and a diff-serv network somewhere in the path between sender and Bernet Expires May, 2000 1
receiver. At least one RSVP aware network element resides in the admission control agent for the network, admitting or denying resource
diff-serv network. This network element may be a policy enforcement requests based on the availability of resources. In either case, this
point (PEP) associated with a PDP, or may simply act as an admission network element interacts with RSVP messages arriving from outside the
control agent, admitting or denying resource requests based DS network, accepting resource requests from RSVP-aware senders and
exclusively on the availability of resources. The network element is receivers, and conveying the DS network's admission control and resource
typically a router and will be considered to be so for the purpose allocation decisions to the higher-level RSVP. The network element is
of this draft. typically a router and will be considered to be so for the purpose of
this draft. This model is described fully in [INTDIFF].
The sender composes a standard RSVP PATH message and sends it 2.1 Use of the DCLASS Object to Carry Upstream Packet Marking Information
towards the receiver on the remote end of the diff-serv network. The
PATH message traverses one or more network elements that are PEPs
and/or admission control agents for the diff-serv network. These
elements install appropriate state and forward the PATH message
towards the receiver. If admission control is successful downstream
of the diff-serv network, then a RESV message will arrive from the
direction of the receiver. As this message arrives at the PEPs
and/or admission control agents that are RSVP enabled, each of these
network elements must make a decision regarding the admissibility of
the signaled flow to the diff-serv network.
If the network element determines that the request represented by A principal usage of the DCLASS object is to carry DSCP information
the PATH and RESV messages is admissible to the diff-serv network, between a DS network and upstream nodes that may wish to mark packets
it must decide which diff-serv service level (or behaviour with DSCP values. Briefly, the sender composes a standard RSVP PATH
aggregate) is appropriate for the traffic represented in the RSVP message and sends it towards the receiver. At some point the PATH
request. It then adds a DCLASS object containing one or more DSCPs message reaches the DS network. The PATH message traverses one or more
corresponding to the behaviour aggregate, to the RESV message. The network elements that are PEPs and/or admission control agents for the
RESV message is then sent upstream towards the RSVP sender. diff-serv network. These elements install appropriate state and forward
the PATH message towards the receiver. If admission control is
successful downstream of the diff-serv network, then a RESV message will
arrive from the direction of the receiver. As this message arrives at
the PEPs and/or admission control agents that are RSVP enabled, each of
these network elements must make a decision regarding the admissibility
of the signaled flow to the diff-serv network.
If the network element determines that the request represented by the
PATH and RESV messages is admissible to the diff-serv network, the
appropriate diff-serv service level (or behaviour aggregate) for the
traffic represented in the RSVP request is determined. Next, a decision
is made to mark arriving data packets for this traffic locally using MF
classification, or to request upstream marking of the packets with the
appropriate DSCP(s). This upstream marking could occur anywhere before
the DS network's ingress point. Two likely candidates are the
originating sender and the egress boundary router of some upstream (DS
or non-DS) network. The decision about where the RSVP request's packets
should be marked can be made by agreement or through a negotiation
protocol; the details are outside the scope of this document.
If the packets for this RSVP request are to be marked upstream,
information about the DSCP(s) to use must be conveyed from the RSVP-
aware network element to the upstream marking point. This information
is conveyed with the DCLASS object. To do this, the network element
adds a DCLASS object containing one or more DSCPs corresponding to the
behaviour aggregate, to the RESV message. The RESV message is then sent
upstream towards the RSVP sender.
If the network element determines that the RSVP request is not If the network element determines that the RSVP request is not
admissible to the diff-serv network, it sends a RESV error message admissible to the diff-serv network, it sends a RESV error message
towards the receiver. No DCLASS is required. towards the receiver. No DCLASS is required.
Note that a network element may terminate RSVP signaling, in which Bernet Expires May, 2000 2
case it effectively provides admission control to all regions of the
network downstream (including the receiver). In this case, no actual
RESV message will arrive from the receiver. Instead, the network
element may act as a proxy, composing the RESV message on behalf of
the downstream nodes.
4. Format of the DCLASS Object 2.1 Additional Uses of the DCLASS Object
bernet expires February, 2000 2 The DCLASS object is intended to be a general tool for conveying DSCP
draft-ietf-issll-dclass-00.txt August, 1999 information in RSVP messages. This may be useful in a number of
situations. We give one further example here as motivation.
The DCLASS object has the following format: In this example, we assume that the decision about the appropriate
behavior aggregate for a RSVP-mediated traffic flow is made at the DS
network egress router (or a related Policy Decision Point) by observing
RSVP PATH and RESV messages and other necessary information. However,
the actual packet marking must be done at the ingress of the network.
The DCLASS object can be used to carry the needed marking information
between egress and ingress routers.
0 1 2 3 3. Format of the DCLASS Object
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The DCLASS object has the following format:
0 | 1 | 2 | 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (>= 8) | C-Num (225) | 1 | | Length (>= 8) | C-Num (225) | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | 1st DSCP | | | Unused | 1st DSCP | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | 2nd DSCP | | | Unused | 2nd DSCP | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | . . . . | | | Unused | . . . . | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first word contains the standard RSVP object header (the Class The first word contains the standard RSVP object header (the Class Num
Num for the DCLASS object is 225). The length field indicates the for the DCLASS object is 225). The length field indicates the total
total object length in bytes. The object header is followed by one object length in bytes. The object header is followed by one or more
or more 32-bit words, each containing a DSCP in the six high-order 32-bit words, each containing a DSCP in the six high-order bits of the
bits of the least significant byte. The length field in the object least significant byte. The length field in the object header indicates
header indicates the number of DSCPs included in the object. the number of DSCPs included in the object. Specifically, the number of
DCLASS objects present is equal to (Length - 4) / 4.
The network may return multiple DSCPs in the DCLASS object in order The network may return multiple DSCPs in the DCLASS object in order to
to enable the host to discriminate sub-flows within a behaviour enable the host to discriminate sub-flows within a behaviour aggregate.
aggregate. For example, in the case of the AF PHB group [AF], the For example, in the case of the AF PHB group [AF], the network may
network may return the DSCPs 001010, 001100, and 001110 return the DSCPs 001010, 001100, and 001110 corresponding to increasing
corresponding to increasing levels of drop precedence within Class 1 levels of drop precedence within Class 1 of the AF PHB group. Note that
of the AF PHB group. Note that this draft makes no statements this draft makes no statements regarding the significance of the order
regarding the significance of the order of the returned DSCPs. of the returned DSCPs. Further interpretation of DSCP sets is dependent
Further interpretation of DSCP sets is dependent on the specific on the specific service requested by the host and is beyond the scope of
service requested by the host and is beyond the scope of this draft. this draft.
Note that the Class-Num for the DCLASS object is chosen from the Note that the Class-Num for the DCLASS object is chosen from the space
space of unknown class objects that should be ignored and forwarded of unknown class objects that should be ignored and forwarded by nodes
by nodes that do not recognize it. This is to assure maximal that do not recognize it. This is to assure maximal backward
backward compatibility. compatibility.
5. Admission Control Functionality Bernet Expires May, 2000 3
From a black-box perspective, admission control and policy 4. Admission Control Functionality
functionality amounts to the decision whether to accept or reject a
request and the determination of the DSCPs that should be used for
the corresponding traffic. The specific details of admission control
are beyond the scope of this document. In general the admission
control decision is based both on resource availability and on
policies regarding the use of resources in the diff-serv network.
The admission control decision made by RSVP aware network elements
represents both considerations.
In order to decide whether the RSVP request is admissible in terms From a black-box perspective, admission control and policy functionality
of resource availability, one or more network elements within or at amounts to the decision whether to accept or reject a request and the
the boundary of the diff-serv network must understand the impact determination of the DSCPs that should be used for the corresponding
that admission would have on specific diff-serv resources, as well traffic. The specific details of admission control are beyond the scope
of this document. In general the admission control decision is based
both on resource availability and on policies regarding the use of
resources in the diff-serv network. The admission control decision made
by RSVP aware network elements represents both considerations.
bernet expires February, 2000 3 In order to decide whether the RSVP request is admissible in terms of
draft-ietf-issll-dclass-00.txt August, 1999 resource availability, one or more network elements within or at the
boundary of the diff-serv network must understand the impact that
admission would have on specific diff-serv resources, as well as the
availability of these resources along the relevant data path in the
diff-serv network.
as the availability of these resources along the relevant data path In order to decide whether the RSVP request is admissible in terms of
in the diff-serv network. policy, the network element may use identity objects describing users
and/or applications that may be included in the request. The router may
act as a PEP/PDP and use data from a policy database or directory to aid
in this decision.
In order to decide whether the RSVP request is admissible in terms See Appendix A for a simple mechanism for configurable resource based
of policy, the network element may use identity objects describing admission control.
users and/or applications that may be included in the request. The
router may act as a PEP/PDP and use data from a policy database or
directory to aid in this decision.
See Appendix A for a simple mechanism for configurable resource 5. Security Considerations
based admission control.
8. Security Considerations The DCLASS object conveys information that can be used to request
enhanced QoS from a DS network, so inappropriate modification of the
object could allow traffic flows to obtain a higher or lower level of
QoS than appropriate. Particularly, modification of a DCLASS object by
a third party inserted between the DS network ingress node and the
upstream marker constitutes a possible denial of service attack. This
attack is subtle because it is possible to reduce the received QoS to an
unacceptably low level without completely cutting off data flow, making
the attack harder to detect.
There are no security considerations beyond those of standard RSVP. The possibility of raising the received level of QoS by inappropriate
modification of the DCLASS object is less significant because it a
subclass of a larger class of attacks that must already be detected by
the system. Protection must already be in place to prevent a host
raising its received level of QoS by simply guessing "good" DSCP's and
marking packets accordingly. If this protection is at the boundary of
the DS network, it will detect inappropriate marking of arriving packets
caused by modified DCLASS objects as well. If, however, the protection
function as well as the marking function has been pushed upstream
(perhaps to a trusted third party or intermediate node), correct
transmission of the DCLASS object must be ensured to prevent a possible
theft of service attack.
9. References Bernet Expires May, 2000 4
Simple observation of the DCLASS object in a RSVP message raises several
issues which may be seen as security concerns. Correlation of observed
DCLASS object values with RSVP requests or MF classification parameters
allows the observer to determine that different flows are receiving
different levels of QoS, which may be knowledge that should be protected
in some environments. Similarly, observation of the DCLASS object can
allow the observer to determine that a single flow's QoS has been
promoted or demoted, which may signal significant events in the life of
that flow's application or user. Finally, observation of the DCLASS
object may reveal information about the internal operations of a DS
network that could be useful to observers interested in
theft-of-services attacks.
6. References
[INTDIFF], Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., [INTDIFF], Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B., "Integrated Services Operation Speer, M., Braden, R., Davie, B., Wroclawski, J., "Integrated Services
[DS] An Architecture for Differentiated Services. S. Blake, D. Black,
M. Carlson, E. Davies, Z. Wang, W. Weiss, RFC 2475, December 1998.
[RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) -
Functional Specification.", IETF RFC 2205, Sep. 1997.
[RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission
Control", IETF <draft-ietf-rap-framework-02.txt>, Jan., 1999.
[AF], Heinanen, J., Baker, F., Weiss, W., Wroclawski, J., "Assured [AF], Heinanen, J., Baker, F., Weiss, W., Wroclawski, J., "Assured
10. Acknowledgments 7. Acknowledgments
Thanks to Fred Baker and Carol Iturralde for reviewing this draft. Thanks to Fred Baker and Carol Iturralde for reviewing this draft.
Thanks to Ramesh Pabbati, Tim Moore, Bruce Davie and Kam Lee for Thanks to Ramesh Pabbati, Tim Moore, Bruce Davie and Kam Lee for input.
input.
11. Author's Addresses 8. Author's Address
Bernet, Yoram Bernet, Yoram
Microsoft Microsoft
One Microsoft Way, One Microsoft Way,
Redmond, WA 98052 Redmond, WA 98052
Phone: (425) 936-9568 Phone: (425) 936-9568
Email: yoramb@microsoft.com Email: yoramb@microsoft.com
Appendix A - Simple Configurable Resource Based Admission Control Appendix A - Simple Configurable Resource Based Admission Control
Routers may use quite sophisticated mechanisms in making the Routers may use quite sophisticated mechanisms in making the admission
admission control decision, including policy considerations, various control decision, including policy considerations, various intra- domain
intra-domain signaling protocols, results of traffic monitoring and signaling protocols, results of traffic monitoring and so on. It is
so on. It is recommended that the following basic functionality be recommended that the following basic functionality be provided to enable
provided to enable simple resource based admission control in the
absence of more sophisticated mechanisms. This functionality can be
used with configurable, standalone routers. It applies to standard
RSVP/Intserv requests. This minimal functionality assumes only a
single DSCP is included in the DCLASS object, but may readily be
extended to support multiple DSCPs.
bernet expires February, 2000 4 Bernet Expires May, 2000 5
draft-ietf-issll-dclass-00.txt August, 1999 simple resource based admission control in the absence of more
sophisticated mechanisms. This functionality can be used with
configurable, standalone routers. It applies to standard RSVP/Intserv
requests. This minimal functionality assumes only a single DSCP is
included in the DCLASS object, but may readily be extended to support
multiple DSCPs.
It must be possible to configure two tables in the router. These are It must be possible to configure two tables in the router. These are
described below. described below.
A.1 Service Type to DSCP Mapping A.1 Service Type to DSCP Mapping
One table provides a mapping from the intserv service-type specified One table provides a mapping from the intserv service-type specified in
in the RSVP request to a DSCP that can be used to obtain a the RSVP request to a DSCP that can be used to obtain a corresponding
corresponding service in the diff-serv network. This table contains service in the diff-serv network. This table contains a row for each
a row for each intserv service type for which a mapping is intserv service type for which a mapping is available. Each row has the
available. Each row has the following format: following format:
Intserv service type : DSCP Intserv service type : DSCP
The table would typically contain at least three rows; one for The table would typically contain at least three rows; one for
Guaranteed service, one for Controlled Load service and one for Guaranteed service, one for Controlled Load service and one for Best-
Best-Effort service. (The best-effort service will typically map to Effort service. (The best-effort service will typically map to DSCP
DSCP 000000, but may be overridden). It should be possible to add 000000, but may be overridden). It should be possible to add rows for
rows for as-yet-undefined service types. as-yet-undefined service types.
This table allows the network administrator to statically configure This table allows the network administrator to statically configure a
a DSCP that the router will return in the DCLASS object for an DSCP that the router will return in the DCLASS object for an admitted
admitted RSVP request. In general, more sophisticated and likely RSVP request. In general, more sophisticated and likely more dynamic
more dynamic mechanisms may be used to determine the DSCP to be mechanisms may be used to determine the DSCP to be returned in the
returned in the DCLASS object. In this case, these mechanisms may DCLASS object. Also, it is likely that a real mapping for some services
override the static table based mapping. would use more than one DSCP, with the DSCP depending on the invocation
parameters of a specific service request. In this case, these
mechanisms may override or replace the static table based mapping
described here.
A.2 Quantitative Resource Availability A.2 Quantitative Resource Availability
Standard intserv requests are quantitative in nature. They include Standard intserv requests are quantitative in nature. They include
token bucket parameters describing the resources required by the token bucket parameters describing the resources required by the traffic
traffic for which admission is requested. The second table enables for which admission is requested. The second table enables the network
the network administrator to statically configure quantitative administrator to statically configure quantitative parameters to be used
parameters to be used by the router when making an admission control by the router when making an admission control decision for quantitative
decision for quantitative service requests. Each row in this table service requests. Each row in this table has the following form:
has the following form:
DSCP : Token bucket profile DSCP : Token bucket profile
The first column specifies those DSCPs for which quantitative The first column specifies those DSCPs for which quantitative admission
admission control is applied. The second column specifies the token control is applied. The second column specifies the token bucket
bucket parameters which represent the total resources available in parameters which represent the total resources available in the
the diff-serv network to accommodate traffic in the service class diff-serv network to accommodate traffic in the service class specified
specified by the DSCP. by the DSCP.
bernet expires February, 2000 5 Bernet Expires May, 2000 6
 End of changes. 51 change blocks. 
170 lines changed or deleted 224 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/