summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2996.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2996.txt')
-rw-r--r--doc/rfc/rfc2996.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc2996.txt b/doc/rfc/rfc2996.txt
new file mode 100644
index 0000000..3db54f4
--- /dev/null
+++ b/doc/rfc/rfc2996.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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.
+
+Abstract
+
+ Resource 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.
+
+1. Introduction
+
+ This section describes the mechanics of using RSVP [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
+
+
+
+Bernet Standards Track [Page 1]
+
+RFC 2996 Format of the RSVP DCLASS Object November 2000
+
+
+ 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].
+
+1.1 Use of the DCLASS Object to Carry Upstream Packet Marking
+ Information
+
+ A principal usage of the DCLASS object is to carry DSCP information
+ between a DS network and upstream nodes that may wish to mark packets
+ with DSCP values. Briefly, the sender composes a standard RSVP PATH
+ message and sends it towards the receiver. At some point the PATH
+ message reaches the DS 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 the
+ PATH and RESV messages is admissible to the diff-serv network, the
+ appropriate diff-serv service level (or behavior 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 behavior 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
+ admissible to the diff-serv network, it sends a RESV error message
+
+
+
+Bernet Standards Track [Page 2]
+
+RFC 2996 Format of the RSVP DCLASS Object November 2000
+
+
+ towards the receiver. No DCLASS is required.
+
+1.1 Additional Uses of the DCLASS Object
+
+ The DCLASS object is intended to be a general tool for conveying DSCP
+ information in RSVP messages. This may be useful in a number of
+ situations. We give one further example here as motivation.
+
+ 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.
+
+2. Format of the DCLASS Object
+
+ The DCLASS object has the following format:
+
+ 0 | 1 | 2 | 3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length (>= 8) | C-Num (225) | 1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Unused | 1st DSCP | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Unused | 2nd DSCP | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Unused | . . . . | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The first word contains the standard RSVP object header (the Class
+ Num for the DCLASS object is 225). The length field indicates the
+ total object length in bytes. The object header is followed by one
+ or more 32-bit words, each containing a DSCP in the six high-order
+ bits of the least significant byte. The length field in the object
+ header indicates 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
+ to enable the host to discriminate sub-flows within a behavior
+ aggregate. For example, in the case of the AF PHB group [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
+
+
+
+Bernet Standards Track [Page 3]
+
+RFC 2996 Format of the RSVP DCLASS Object November 2000
+
+
+ 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.
+
+3. Admission Control Functionality
+
+ From a black-box perspective, admission control and policy
+ 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 of
+ 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.
+
+ In order to decide whether the RSVP request is admissible in terms of
+ 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.
+
+ See Appendix A for a simple mechanism for configurable resource based
+ admission control.
+
+4. 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.
+
+ The possibility of raising the received level of QoS by inappropriate
+
+
+
+Bernet Standards Track [Page 4]
+
+RFC 2996 Format of the RSVP DCLASS Object November 2000
+
+
+ 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.
+
+5. References
+
+ [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.
+
+
+
+
+
+Bernet Standards Track [Page 5]
+
+RFC 2996 Format of the RSVP DCLASS Object November 2000
+
+
+6. Acknowledgments
+
+ Thanks to Fred Baker and Carol Iturralde for reviewing this document.
+ Thanks to Ramesh Pabbati, Tim Moore, Bruce Davie and Kam Lee for
+ input.
+
+7. Author's Address
+
+ Yoram Bernet
+ Microsoft
+ One Microsoft Way,
+ Redmond, WA 98052
+
+ Phone: (425) 936-9568
+ EMail: yoramb@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bernet Standards Track [Page 6]
+
+RFC 2996 Format of the RSVP DCLASS Object November 2000
+
+
+Appendix A - Simple Configurable Resource Based Admission Control
+
+ Routers may use quite sophisticated mechanisms in making the
+ admission control decision, including policy considerations, various
+ intra-domain signaling protocols, results of traffic monitoring and
+ so on. It is recommended that the following basic functionality be
+ 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.
+
+ It must be possible to configure two tables in the router. These are
+ described below.
+
+A.1 Service Type to DSCP Mapping
+
+ One table provides a mapping from the intserv service-type specified
+ in the RSVP request to a DSCP that can be used to obtain a
+ corresponding service in the diff-serv network. This table contains
+ a row for each intserv service type for which a mapping is available.
+ Each row has the following format:
+
+ Intserv service type : DSCP
+
+ The table would typically contain at least three rows; one for
+ Guaranteed service, one for Controlled Load service and one for Best-
+ Effort service. (The best-effort service will typically map to DSCP
+ 000000, but may be overridden). It should be possible to add rows
+ for as-yet-undefined service types.
+
+ This table allows the network administrator to statically configure a
+ DSCP that the router will return in the DCLASS object for an admitted
+ RSVP request. In general, more sophisticated and likely more dynamic
+ mechanisms may be used to determine the DSCP to be returned in the
+ DCLASS object. Also, it is likely that a real mapping for some
+ services 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
+
+ Standard intserv requests are quantitative in nature. They include
+ token bucket parameters describing the resources required by the
+ traffic for which admission is requested. The second table enables
+ the network administrator to statically configure quantitative
+
+
+
+Bernet Standards Track [Page 7]
+
+RFC 2996 Format of the RSVP DCLASS Object November 2000
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bernet Standards Track [Page 8]
+
+RFC 2996 Format of the RSVP DCLASS Object November 2000
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bernet Standards Track [Page 9]
+