RFC 3260

New Terminology and Clarifications for Diffserv

📅 published April 2002, from ietf

RFC 3260: New Terminology and Clarifications for Diffserv 🎀

Okay bestie, so RFC 3260 is titled "New Terminology and Clarifications for Diffserv" 💅 It was written by D. Grossman at Motorola, Inc. in April 2002. It's Category: Informational, which means it's info for the community and not a standard 🌸 It updates RFC 2474, RFC 2475, and RFC 2597. Its title block doesn't list anything it obsoletes.

Status of this Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract 🦋

This memo captures Diffserv working group agreements about new and improved terminology, and it gives some minor technical clarifications. It's meant to update RFC 2474, RFC 2475, and RFC 2597. When RFCs 2474 and 2597 move forward on the standards track, and RFC 2475 gets updated, the revisions in this memo are supposed to get folded in, and then this memo gets obsoleted by the new RFCs 🫶

1. Introduction ✨

Okay so Diffserv has been evolving, and sometimes the team needed new words or needed to sharpen what the standards track RFCs said 🤓 There were also a few minor technical clarifications that needed doing. This memo was made to capture what the group agreed on, instead of reopening the base RFCs and recycling them at proposed standard 🔥 It partly updates RFC 2474, RFC 2475, and RFC 2597. RFC 2598 got obsoleted by RFC 3246, and the clarifications the group agreed on went into that revision 💖

So the Diffserv Architecture [2] uses the term "Service Level Agreement" (SLA) to describe the "service contract... that specifies the forwarding service a customer should receive". The SLA can include traffic conditioning rules that (at least partly) make up a Traffic Conditioning Agreement (TCA). A TCA is "an agreement specifying classifier rules and any corresponding traffic profiles and metering, marking, discarding and/or shaping rules which are to apply...."

Here's the tea ☕ As work moved along in Diffserv (and in the Policy WG [6]), people started to feel that the word "agreement" carried pricing, contractual, and other business stuff, not just technical stuff. There could also be other technical considerations in an agreement, like service availability, that Diffserv doesn't cover at all 😭 So the group decided that SLA and TCA would stand for the broader picture, and that new terms would describe just the bits of service and traffic conditioning that Diffserv actually handles 🧚

  • Service Level Specification (SLS) is a set of parameters and their values which together define the service offered to a traffic stream by a DS domain.
  • Traffic Conditioning Specification (TCS) is a set of parameters and their values which together specify a set of classifier rules and a traffic profile. A TCS is an integral element of an SLS.

Note that the definition of "Traffic stream" is unchanged from RFC 2475 🌈 A traffic stream can be an individual microflow, or a group of microflows (i.e., in a source or destination DS domain), or it can be a BA. So an SLS may apply in the source or destination DS domain to a single microflow or a group of microflows, and it may also apply to a BA in any DS domain 🍓

Also, the definition of a "Service Provisioning Policy" is unchanged from RFC 2475 💜 RFC 2475 defines a "Service Provisioning Policy as "a policy which defines how traffic conditioners are configured on DS boundary nodes and how traffic streams are mapped to DS behavior aggregates to achieve a range of services." According to one definition given in RFC 3198 [6], a policy is "...a set of rules to administer, manage, and control access to network resources". So the relationship between an SLS and a service provisioning policy is this: the policy is, in part, the set of rules that express the parameters and range of values that the SLS may contain 🦋

Further note that this definition is more restrictive than the one in RFC 3198 🙈

3. Usage of PHB Group 🌸

RFC 2475 defines a Per-hop behavior (PHB) group like this:

"a set of one or more PHBs that can only be meaningfully specified and implemented simultaneously, due to a common constraint applying to all PHBs in the set such as a queue servicing or queue management policy. A PHB group provides a service building block that allows a set of related forwarding behaviors to be specified together (e.g., four dropping priorities). A single PHB is a special case of a PHB group."

One standards track PHB Group is defined in RFC 2597 [3], "Assured Forwarding PHB Group" ✨ Assured Forwarding (AF) is a type of forwarding behavior with some assigned level of queuing resources and three drop precedences. An AF PHB Group consists of three PHBs, and uses three Diffserv Codepoints (DSCPs).

RFC 2597 defines twelve DSCPs, corresponding to four independent AF classes 👑 The AF classes are called AF1x, AF2x, AF3x, and AF4x (where 'x' is 1, 2, or 3 to represent drop precedence). Each AF class is one instance of an AF PHB Group.

Now, there's been some confusion, because RFC 2597 seems to say that all four AF classes, with their three drop precedences each, are part of a single PHB Group 🙃 But each AF class operates entirely independently of the others. There's no common constraint among AF classes the way there is among drop precedences within one AF class. So that usage doesn't match RFC 2475. The mismatch is for historical reasons, and it'll get removed in future revisions of the AF specification. The right way to think about it now is that AF is a type of PHB group, and each AF class is an instance of the AF type 💅

Authors of new PHB specifications need to be careful to stick with the RFC 2475 definition of PHB Group 🎀 RFC 2475 doesn't stop new PHB specifications from assigning enough DSCPs to represent multiple independent instances of their PHB Group. But a set of DSCPs like that must not be referred to as a single PHB Group 🚫

4. Definition of the DS Field 🧚

Diffserv uses six bits of the IPV4 or IPV6 header to carry the Diffserv Codepoint (DSCP), which selects a PHB 💖 RFC 2474 tried to rename the TOS octet of the IPV4 header, and the Traffic Class octet of the IPV6 header, to the DS field. The DS Field has a six bit Diffserv Codepoint and two "currently unused" bits.

It's been pointed out that this causes inconsistencies and ambiguities 😬 Specifically, the "Currently Unused" (CU) bits of the DS Field were never assigned to Diffserv. After RFC 2474 came out, they got assigned for explicit congestion notification, as defined in RFC 3168 [4]. In the current text, a DSCP is either an encoding that selects a PHB, or a sub-field in the DS field that holds that encoding, depending on context 🌈

The present text is also inconsistent with BCP 37, IANA Allocation Guidelines for Values in the Internet Protocol and Related Headers [5]. The IPV4 Type-of-Service (TOS) field and the IPV6 traffic class field are superseded by the 6 bit DS field and a 2 bit CU field. IANA allocates values in the DS field following the IANA considerations section in RFC 2474, as clarified in section 8 of this memo 🍓

The consensus of the DiffServ working group is that BCP 37 correctly restates the structure of the former TOS and traffic class fields 🫶

So for use in future documents, including the next update to RFC 2474, the following definitions should apply:

  • The Differentiated Services Field (DSField) is the six most significant bits of the (former) IPV4 TOS octet or the (former) IPV6 Traffic Class octet.
  • The Differentiated Services Codepoint (DSCP) is a value which is encoded in the DS field, and which each DS Node MUST use to select the PHB which is to be experienced by each packet it forwards.

The two least significant bits of the IPV4 TOS octet and the IPV6 Traffic Class octet are not used by Diffserv 🦋

When RFC 2474 gets updated, it'd be good to consider changing the designation "currently unused (CU)" to "explicit congestion notification (ECN)" and referencing RFC 3168 (or its successor) ✨ The update should also reference BCP 37.

5. Ordered Aggregates and PHB Scheduling Classes 🌸

Okay this part is my fave 😭 Work on Diffserv support by MPLS Label Switched Routers (LSRs) showed the team that Diffserv needed a concept to capture a set of BAs that share a common ordering constraint 🔥 Right now this applies to AF behavior aggregates, because a DS node may not reorder packets of the same microflow if they belong to the same AF class. Without this, an MPLS LSR that's also a DS node couldn't tell apart packets of an AF Behavior Aggregate (BA) by drop precedence and send packets of the same AF class but different drop precedence over different LSPs 💜 So here are the new terms:

  • PHB Scheduling Class: A PHB group for which a common constraint is that ordering of at least those packets belonging to the same microflow must be preserved.
  • Ordered Aggregate (OA): A set of Behavior Aggregates that share an ordering constraint. The set of PHBs that are applied to this set of Behavior Aggregates constitutes a PHB scheduling class. 👑

6. Unknown/Improperly Mapped DSCPs ✨

Okay bestie, this one is a whole drama 💅. Several implementors pointed out that the Diffserv RFCs seemed to contradict each other about what a DS-node should do when it gets a packet with a DSCP it doesn't understand 🙈

RFC 2475 says:

"Ingress nodes must condition all other inbound traffic to ensure
that the DS codepoints are acceptable; packets found to have
unacceptable codepoints must either be discarded or must have
their DS codepoints modified to acceptable values before being
forwarded.  For example, an ingress node receiving traffic from a
domain with which no enhanced service agreement exists may reset
the DS codepoint to the Default PHB codepoint [DSFIELD]."

On the other hand, RFC 2474 says:

"Packets received with an unrecognized codepoint SHOULD be
forwarded as if they were marked for the Default behavior (see
Sec. 4), and their codepoints should not be changed."

RFC 2474 is mainly about DS-interior nodes. But this behavior could also happen in DS-ingress nodes AFTER the traffic conditioning that RFC 2475 requires (and then an unrecognized DSCP would only show up through misconfiguration). 🌸

If a packet arrives with a DSCP that was never explicitly mapped to a particular PHB, it should be treated the same way as a packet marked for Default. The other options were giving it a different PHB, which could mess up provisioned resources, or dropping it. Those are the only options inside the RFC 2474 framework, and neither one was considered desirable. People have talked about a PHB that gets worse service than the default, and that might be a better option 👀 So the imperative was "SHOULD" rather than "SHALL".

The intent of RFC 2475 clearly concerns DS-ingress nodes, or more precisely, the ingress traffic conditioning function. This is another spot where the "SHOULD" in RFC 2474 gives room to do what the group actually meant. Such tortured readings are not desirable 🙃

Therefore, the statement in RFC 2474 will be clarified to indicate that it is not intended to apply at the ingress traffic conditioning function at a DS-ingress node, and cross reference RFC 2475 for that case.

There was a similar issue with the first version of Expedited Forwarding (EF) 🦋 RFC 2598 says:

   To protect itself against denial of service attacks, the edge of a
   DS domain MUST strictly police all EF marked packets to a rate
   negotiated with the adjacent upstream domain.  (This rate must be
   <= the EF PHB configured rate.)  Packets in excess of the
   negotiated rate MUST be dropped.  If two adjacent domains have not
   negotiated an EF rate, the downstream domain MUST use 0 as the
   rate (i.e., drop all EF marked packets).

The problem came up with misconfiguration or routing problems. An egress DS-node at the edge of one DS-domain forwards packets to an ingress DS-node at the edge of another DS-domain. These packets are marked with a DSCP that the egress node understands as EF, but the ingress node doesn't recognize it. The statement in RFC 2475 seems to apply to this case. RFC 3246 [7] clarifies this point. 💜

7. No Backward Compatibility With RFC 1349 🎀

At least one implementor was confused about how the DSField, defined in RFC 2474, relates to the TOS bits described in RFC 1349. The RFC 1349 usage was meant to work with OSPF extensions in RFC 1247. Those were never widely deployed, so they were removed through standards action when STD 54, RFC 2328, was published 🥀 The handling of the TOS bits is written as a requirement in RFC 1812 [8], RFC 1122 [9] and RFC 1123 [10]. RFC 2474 says:

"No attempt is made to maintain backwards compatibility with the
"DTR" or TOS bits of the IPv4 TOS octet, as defined in [RFC791].",

RFC 2474 also obsoletes RFC 1349 through IESG action. For completeness, when RFC 2474 is updated, the sentence should read:

"No attempt is made to maintain backwards compatibility with the
"DTR/MBZ" or TOS bits of the IPv4 TOS octet, as defined in
[RFC791] and [RFC1349].  This implies that TOS bit processing as
described in [RFC1812], [RFC1122] and [RFC1123] is also obsoleted
by this memo.  Also see [RFC2780]."

8. IANA Considerations 🍓

IANA asked for clarification on a point in RFC 2474 about registering experimental/local use DSCPs. When RFC 2474 is revised, the following should be added to Section 6:

IANA is requested to maintain a registry of RECOMMENDED DSCP
values assigned by standards action.  EXP/LU values are not to be
registered.

9. Summary of Pending Changes 🧚

The following standards track and informational RFCs are expected to be updated to reflect the agreements in this memo. These updates are intended to happen when each standards track RFC moves to Draft Standard (or if some issue comes up that forces a recycle at Proposed). RFC 2475 is expected to be updated at about the same time as RFC 2474. Those updates will also obsolete this memo ⭐

  • RFC 2474: revise definition of DS field. Clarify that the suggested default forwarding in the event of an unrecognized DSCP is not intended to apply to ingress conditioning in DS-ingress nodes. Clarify effects on RFC 1349 and RFC 1812. Clarify that only RECOMMENDED DSCPs assigned by standards action are to be registered by IANA.
  • RFC 2475: revise definition of DS field. Add SLS and TCS definitions. Update body of document to use SLS and TCS appropriately. Add definitions of PHB scheduling class and ordered aggregate.
  • RFC 2497: revise to reflect understanding that, AF classes are instances of the AF PHB group, and are not collectively a PHB group.

On top of that, RFC 3246 [7] added a reference to RFC 2475 in the security considerations section to cover the case of a DS egress node receiving an unrecognized DSCP which maps to EF in the DS ingress node 💖

10. Security Considerations 🔥

Security considerations are addressed in RFC 2475. Go read that one, it's where the serious stuff lives 🫶

Acknowledgements 💖

This memo captures agreements of the Diffserv working group. Many individuals contributed to the discussions on the Diffserv list and in the meetings. The Diffserv chairs were Brian Carpenter and Kathie Nichols. Among the many who actively participated in these discussions were Lloyd Wood, Juha Heinanen, Grenville Armitage, Scott Brim, Sharam Davari, David Black, Gerard Gastaud, Joel Halpern, John Schnizlein, Francois Le Faucheur, and Fred Baker. Mike Ayers, Mike Heard and Andrea Westerinen provided valuable editorial comments 👑

Normative References 📚

  • [1] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
  • [2] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
  • [3] Heinanen, J., Baker, F., Weiss, W. and J. Wrocklawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
  • [4] Ramakrishnan, K., Floyd, S. and D. Black "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
  • [5] Bradner, S. and V. Paxon, "IANA Allocation Guidelines for Values in the Internet Protocol and Related Headers", BCP 37, RFC2780, March 2000.
  • [6] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
  • [7] Davie, B., Charny, A., Baker, F., Bennett, J.C.R., Benson, K., Le Boudec, J., Chiu, A., Courtney, W., Cavari, S., Firoiu, V., Kalmanek, C., Ramakrishnam, K. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
  • [8] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
  • [9] Braden, R., "Requirements for Internet Hosts -- Communications Layers", STD 3, RFC 1122, October 1989.
  • [10] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.

Author's Address 🌈

Dan Grossman
Motorola, Inc.
20 Cabot Blvd.
Mansfield, MA 02048

EMail: dan@dma.isg.mot.com

Copyright (C) The Internet Society (2002). 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.

📦 where this page comes from