RFC 2996

Format of the RSVP DCLASS Object

📅 published November 2000, from ietf

RFC 2996: Format of the RSVP DCLASS Object 🎀

  • Network Working Group
  • Author: Y. Bernet, Microsoft 💖
  • Category: Standards Track 🦋
  • Date: November 2000 🌸
  • Obsoletes / Updates: This one doesn't have an Obsoletes or Updates line, so it doesn't list any. ✨

Status of this Memo ✨

okay so this document is an Internet standards track protocol for the Internet community, and it's asking everyone to talk about it and suggest improvements 🫶 If you want the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 💅

Copyright (C) The Internet Society (2000). All Rights Reserved. 📜

Abstract 🦋

Resource Reservation Protocol (RSVP) signaling can be used to ask for Quality of Service (QoS) and make application traffic's QoS easier to manage, inside a differentiated service (diff-serv or DS) network 🔥 When you use RSVP with DS networks, it's super useful to carry Differentiated Services Code Points (DSCPs) inside RSVP message objects. One example is using RSVP to get packets marked with a particular DSCP upstream of the DS network's ingress point. That means at the sender, or at the egress router of a previous network 🧚

The DCLASS object is what carries DSCPs inside RSVP messages. This document defines the format of the DCLASS object and briefly talks about how it gets used 💜

1. Introduction 💖

This section explains how RSVP [RSVP] signaling and the DCLASS object work together for admission control and applying QoS policy inside a Differentiated Service network [DS] 🎀 It assumes standard RSVP senders and receivers, plus a diff-serv network somewhere along the path between them. At least one RSVP-aware network element lives inside that diff-serv network. This element might be a policy enforcement point (PEP) [RAP], or it might just act as an admission control agent that admits or denies resource requests based on what resources are available 👑 Either way, it deals with RSVP messages coming in from outside the DS network. It accepts resource requests from RSVP-aware senders and receivers, and it passes the DS network's admission control and resource allocation decisions up to the higher-level RSVP. This network element is usually a router, and this document treats it as one. This whole model is described in full in [INTDIFF] 🌸

1.1 Use of the DCLASS Object to Carry Upstream Packet Marking Information ✨

A main use of the DCLASS object is carrying DSCP information between a DS network and upstream nodes that might want to mark packets with DSCP values 💅 Here's the quick version. The sender builds a standard RSVP PATH message and sends it toward the receiver. At some point, that PATH message reaches the DS network. It passes through one or more network elements that are PEPs and/or admission control agents for the diff-serv network. These elements install the appropriate state and forward the PATH message on toward the receiver. If admission control succeeds downstream of the diff-serv network, a RESV message comes back from the direction of the receiver. As that RESV message arrives at the RSVP-enabled PEPs and/or admission control agents, each of those network elements has to decide whether the signaled flow can be admitted to the diff-serv network 🔥

If the network element decides that the request in the PATH and RESV messages is admissible to the diff-serv network, it works out which diff-serv service level (or behavior aggregate) fits the traffic in the RSVP request. Next, it decides whether to mark the arriving data packets for this traffic locally using MF classification, or to ask for the packets to be marked upstream with the appropriate DSCP(s). Upstream marking could happen anywhere before the DS network's ingress point. Two likely candidates are the originating sender and the egress boundary router of some upstream network, whether that network is DS or non-DS 🧚 Where the RSVP request's packets should get marked can be decided by agreement or through a negotiation protocol. Those details are outside the scope of this document.

If the packets for this RSVP request are going to be marked upstream, the RSVP-aware network element has to pass along information about which DSCP(s) to use to the upstream marking point. That information travels in the DCLASS object. To do this, the network element adds a DCLASS object containing one or more DSCPs that match the behavior aggregate to the RESV message. Then the RESV message goes upstream toward the RSVP sender 🦋

If the network element decides the RSVP request is not admissible to the diff-serv network, it sends a RESV error message toward the receiver. No DCLASS is needed in that case 💀

1.1 Additional Uses of the DCLASS Object 🌈

The DCLASS object is meant to be a general tool for carrying DSCP information in RSVP messages. That could be handy in a bunch of situations. Here's one more example to give you the idea 🫶

In this example, we assume the decision about the right behavior aggregate for an RSVP-mediated traffic flow is made at the DS network egress router (or a related Policy Decision Point). That router figures it out by watching the RSVP PATH and RESV messages and other necessary info 👑 But the actual packet marking has to happen at the ingress of the network. So the DCLASS object can carry the marking info needed between the egress and ingress routers. It's giving teamwork 💖

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 holds the standard RSVP object header, and the Class Num for the DCLASS object is 225 🧚 The Length field tells you the total object length in bytes. After the object header come one or more 32-bit words, and each one holds a DSCP in the six high-order bits of the least significant byte 💜 The Length field in the object header also tells you how many DSCPs are in the object. To be exact, the number of DCLASS objects present is equal to (Length - 4) / 4 🔥

The network can return multiple DSCPs in one DCLASS object so the host can tell apart sub-flows inside a behavior aggregate ✨ For example, with the AF PHB group [AF], the network might return DSCPs 001010, 001100, and 001110. Those match increasing levels of drop precedence within Class 1 of the AF PHB group 🦋 This document makes no statements about whether the order of the returned DSCPs means anything. Any further interpretation of DSCP sets depends on the specific service the host asked for, and that's beyond the scope of this document 🌸

Also note that the Class-Num for the DCLASS object comes from the space of unknown class objects. Nodes that don't recognize it should ignore it and forward it. This is to make sure there's maximal backward compatibility 🫶

3. Admission Control Functionality 👑

From a black-box perspective, admission control and policy functionality boils down to one decision: accept or reject a request. It also determines which DSCPs should be used for the matching traffic 💅 The specific details of admission control are beyond the scope of this document. In general, the admission control decision depends on both resource availability and policies about using resources in the diff-serv network. The admission control decision made by RSVP-aware network elements covers both of those things 🎀

To decide whether the RSVP request is admissible based on resource availability, one or more network elements within the diff-serv network, or at its boundary, need to understand how admitting the request would affect specific diff-serv resources. They also need to know whether those resources are available along the relevant data path through the diff-serv network 🧚

To decide whether the RSVP request is admissible based on policy, the network element may use identity objects that describe users and/or applications included in the request. The router may act as a PEP/PDP and use data from a policy database or directory to help make that call 🌈

See Appendix A for a simple mechanism for configurable resource-based admission control ✨

4. Security Considerations 🔥

Okay, this section is serious, bestie 😭 The DCLASS object carries information that can be used to request enhanced QoS from a DS network. So if someone modifies the object inappropriately, traffic flows could get a higher or lower level of QoS than they should. In particular, if a third party inserts itself between the DS network ingress node and the upstream marker and modifies a DCLASS object, that's a possible denial of service attack. It's sneaky, because the received QoS can be dropped to an unacceptably low level without completely cutting off data flow. That makes the attack harder to detect 💀

Raising the received level of QoS by inappropriately modifying the DCLASS object is less of a worry. That's because it's a subclass of a bigger group of attacks that the system already has to detect 🙈 Protection must already be in place to stop a host from raising its received QoS by simply guessing "good" DSCP's and marking packets to match. If that protection sits at the boundary of the DS network, it will also catch inappropriate marking of arriving packets caused by modified DCLASS objects. But if the protection function and the marking function have both been pushed upstream (maybe to a trusted third party or an intermediate node), then correct transmission of the DCLASS object must be ensured. Otherwise you could get a possible theft of service attack 🚨

Just observing the DCLASS object in an RSVP message also raises several issues that might be seen as security concerns 👀 Correlating observed DCLASS object values with RSVP requests or MF classification parameters lets an observer figure out that different flows are getting different levels of QoS. In some environments, that's information that should stay protected 🔒 Similarly, watching the DCLASS object can let an observer tell that a single flow's QoS has been promoted or demoted. That could signal big events in the life of that flow's application or user 😳 Finally, observing the DCLASS object may reveal information about the internal operations of a DS network, and observers interested in theft-of-services attacks could find that really useful 🦋

5. References ✨

okay so the references section is where the receipts live, bestie 📚 here's who we're building on:

  • [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. 🍓

6. Acknowledgments 🫶

Big thanks to Fred Baker and Carol Iturralde for reviewing this doc, and to Ramesh Pabbati, Tim Moore, Bruce Davie and Kam Lee for chiming in with input. They're the real MVPs 👑

7. Author's Address 🎀

Here's where you can reach the author, Yoram Bernet:

Yoram Bernet
Microsoft
One Microsoft Way,
Redmond, WA 98052

Phone: (425) 936-9568
EMail: yoramb@microsoft.com

Appendix A - Simple Configurable Resource Based Admission Control 🧚

okay this appendix is giving practical, no-fluff, configurable router energy 💅 Routers can get really fancy when they make admission control decisions, like pulling in policy stuff, all kinds of intra-domain signaling protocols, traffic monitoring results, and so on. But it's recommended that a basic set of functionality be there too, so you can do simple resource based admission control when the sophisticated stuff isn't around. 🌈 This basic version works with configurable, standalone routers and applies to standard RSVP/Intserv requests. It assumes only a single DSCP is in the DCLASS object, but it can be extended to support multiple DSCPs pretty easily ✨

The router has to be able to take two tables. We'll break them down below 🍓

A.1 Service Type to DSCP Mapping 💖

Table one maps the intserv service-type from the RSVP request to a DSCP that gets you a matching service in the diff-serv network. There's one row for each intserv service type that has a mapping, and each row looks like this:

Intserv service type : DSCP

This table will usually have at least three rows: one for Guaranteed service, one for Controlled Load service and one for Best-Effort service. (Best-effort will typically map to DSCP 000000, but you can override it.) It should be possible to add rows for service types that haven't been defined yet, which is giving future-proof queen energy 👑

With this table, the network admin can statically configure which DSCP the router sends back in the DCLASS object for an admitted RSVP request. More sophisticated and probably more dynamic mechanisms can decide the DSCP for the DCLASS object too. Also, a real mapping for some services would likely use more than one DSCP, depending on the invocation parameters of a specific service request. In that case, those mechanisms may override or replace the static table-based mapping described here 🔥

A.2 Quantitative Resource Availability 🦋

Standard intserv requests are quantitative, so they include token bucket parameters that describe the resources the traffic needs for the admission request. The second table lets the network admin statically configure the quantitative parameters the router uses when it makes admission control decisions for quantitative service requests. Each row looks like this:

DSCP : Token bucket profile

The first column names the DSCPs that get quantitative admission control. The second column holds the token bucket parameters for the total resources available in the diff-serv network to fit traffic in the service class that the DSCP names. So basically, the table tells the router how much room is left 🫧

Copyright (C) The Internet Society (2000). All Rights Reserved. 💜

Okay, here's the legal stuff, and it's actually pretty chill. You can copy this document and hand it to others, and you can make derivative works that comment on it, explain it, or help implement it. You can publish and distribute those too, in whole or in part, without any restriction at all. The one condition is that the copyright notice and this paragraph stay on every copy and every derivative work 📜

The document itself can't be modified in any way, though. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when you're developing Internet standards, in which case you have to follow the copyright procedures in the Internet Standards process, or when you need to translate it into languages other than English 🌍

These permissions are perpetual, and the Internet Society or its successors or assigns won't revoke them 🫶

This document and the info in it are provided on an "AS IS" basis. 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. Thank you to them for keeping the lights on ✨

📦 where this page comes from