Network Working Group Y. Bernet Request for Comments: 2996 Microsoft Category: Standards Track November 2000 Format of the RSVP DCLASS Object Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.
AbstractResource Reservation Protocol (RSVP) signaling may be used to request Quality of Service (QoS) services and enhance the manageability of application traffic's QoS in a differentiated service (diff-serv or DS) network. When using RSVP with DS networks it is useful to be able to carry 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. This document specifies the format of the DCLASS object and briefly discusses its use. RSVP] signaling and 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 admission control agent for the network, admitting or denying resource requests based on the availability of resources. In either case, this network element interacts with RSVP messages arriving from outside the DS network, accepting resource requests
from RSVP-aware senders and receivers, and conveying the DS network's admission control and resource allocation decisions to the higher- level RSVP. The network element is typically a router and will be considered to be so for the purpose of this document. This model is described fully in [INTDIFF].
towards the receiver. No DCLASS is required. AF], the network may return the DSCPs 001010, 001100, and 001110 corresponding to increasing levels of drop precedence within Class 1 of the AF PHB group. Note that this document makes no statements regarding the significance of the order of the returned DSCPs. Further interpretation of DSCP sets is dependent on the specific service
requested by the host and is beyond the scope of this document. Note that the Class-Num for the DCLASS object is chosen from the space of unknown class objects that should be ignored and forwarded by nodes that do not recognize it. This is to assure maximal backward compatibility. Appendix A for a simple mechanism for configurable resource based admission control.
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. 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. [INTDIFF] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B. and J. Wroclawski, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000. [DS] Blake, S., Carlson, M., Davies, D., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy Based Admission Control", RFC 2753, January 2000. [AF] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
parameters to be used by the router when making an admission control decision for quantitative service requests. Each row in this table has the following form: DSCP : Token bucket profile The first column specifies those DSCPs for which quantitative admission control is applied. The second column specifies the token bucket parameters which represent the total resources available in the diff-serv network to accommodate traffic in the service class specified by the DSCP.
Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.