DiffServ interconnection classes and practice
draft-geib-tsvwg-diffserv-intercon-00

Abstract

This document proposes a limited set of interconnection QoS PHBs and PHB groups. It further introduces some DiffServ deployment aspects. The proposals made here should be integrated into a revised version of RFC5127.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on May 10, 2013.

Copyright Notice

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

• 1. Introduction
• 1.1. Requirements Language
• 2. Terminology
• 3. An Interconnection class and codepoint scheme
• 4. Consolidation of QoS standards by the interconnection codepoint scheme
• 5. MPLS, Ethernet and IP Precedence for aggregated classes
• 6. QoS class name selection
• 7. Allow for DiffServ extendability on MPLS and Ethernet level
• 8. IANA Considerations
• 9. Security Considerations
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Author's Address

1. Introduction

This draft deals proposes a DiffServ interconnection class and codepoint scheme. At least one party of an interconnection often is a network provider. Aggregated DiffServ classes are often deployed within provider networks. To respect this, this draft also contains concepts and current practice relevant for a revised version of RFC5127 [RFC5127]. Its main purpose is to be considered as an input for the latter task

DiffServ sees deployment in many networks for the time being. As described in the introduction of the draft diffserv problem statement [I-D.polk-tsvwg-diffserv-stds-problem-statement], remarking of packets at domain boundaries is a DiffServ feature. This draft proposes a set of standard QoS classes and codepoints at interconnection points to which and from which locally used classes and codepoints may be mapped. Such a scheme simplifies interconnection negotiations and ensures that class properties remain roughly the same, even if codepoints change.

The proposed Interconnection class and codepoint scheme tries to reflect and consolidate related DiffServ and QoS standardisation efforts outside of the IETF, namely MEF, GSMA and ITU.

IP Precedence has been depricated when DiffServ was standardised. It is common practice today however to copy the DSCPs "IP Precedence Bits" into MPLS TC or Ethernet P-Bits, whenever possible. This is reflected by the DiffServ codepoint definitions of AF and EF. This practice and it's limits deserve to be documented and disussed briefly.

The draft further adds proposals by which philosophy to add or pick aggregated DiffServ classes. The set of available router and traffic management tools to configure and operate DiffServ classes is limited. This should be reflected by class definitions, which may in the end more strongly be related transport properties than application requirements. Please read that "congestion aware" and "not congestion aware" rather then TCP or UDP.

Finally, this draft proposes to leave some MPLS TC codepoint space to allow for future DiffServ extensions like ECN/PCN and domain internal classes (network management traffic is a good example)

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

2. Terminology

A later version of this draft needs to be clearer on that. The author prefers to talk of QoS classes. PHB or PHB groups are not commonly used, although they are better defined. An issue is, that PHB groups, which e.g. allow to offer two or more different drop levels (PHB's) within one PHB group , hardly saw commercial deployment. This may change with more Ethernet services being offered.

Some rather concept than terminology related real world issues are additional motivations of this activity:

• Abstract class names like "EF" are preferrential over those being close to an application, like "Voice". Unfortunately, non QoS experts can't handle abstract class names. Hence and usually sooner than later, classes are named for applications or groups of them. One consequence however is, that people tend to combine application group class names and SLA parameters and often decide, based on a name and some numbers on a paper, that their application needs separate QoS class.
• Worse than that, but very present in real life, is the class abstraction level which is preferred by those dealing with QoS (as experts or non experts): the DSCPs or the IP precedence. So DSCPs or IP Precedence values are the commodity real life abstractions applied for QoS classes. Most of these persons hav fixed class to codepoint mappings in their minds, which they can't easily adapt on a per customer and interconnection partner basis.

While these issues aren't to be solved by IETF (QoS experts could and should of course teach staff to use proper Diffserv terminology and concepts), a simple QoS interconnection scheme also is helpful in this area. Those dealing with QoS on any level need to understand the interconnection classes and their codepoints, and they are able to deal with the mappings of those to their own networks class and codepoint scheme. Simplicity is important, however.

3. An Interconnection class and codepoint scheme

DiffServ deployments mostly follow loose class specification schemes (often one or two AF PHBs or PHB groups, EF and Best Effort). Especially DSCP assignment for the AF classes varies between deployment, while basic class defeinitions are often similar. This is in line with the DiffServ architecture. This document doesn't propose to change that.

Interconnecting parties usually face the problem of matching classes to be interconnected and then to agree on codepoint mapping. As stated by draft diffserv prolebm statement [I-D.polk-tsvwg-diffserv-stds-problem-statement], remarking is a standard behaviour at interconnection interfaces. This draft propses a set of 4 QoS classes with a set of well defined DSCPs as interconnection codepoint scheme. As the idea is that a sending party remarks DSCPs from internal schemes to the Interconnection codepoints and the receiving party remarks to their internal scheme, the interconnection codepoint scheme fully complies with the DiffServ architecture.

While this may look like an additional step at first, there are obvious benefits: each party sending or receiving traffic has to specify the mapping from or to the interconnection class and codepoint scheme only once. Without it, this is to be negotiated once per interconnection party. Further, end-to-end QoS in terms of traffic being classified for the same class in all passed domains is likely to result if an interconnection codepoint scheme is used, while it is not necessarily resulting from individual per network interconnection negotiations.

The Interconnection scheme is supporting aggregated DiffServ classes, as proposed by RFC 5127 [RFC5127]. Note that draft RFC 4597 update [I-D.polk-tsvwg-rfc4594-update] doesn't expect any network to deploy all possible QoS classes (and proposes to standardise DSCPs for all while maintaining deployment of classes a network specific issue). RFC2597 does not allow to aggregate separate AF classes [RFC2597]. Hence a low number of interconnection classes on aggregated level makes sense, as some codepoint space for carrier internal services and future features like ECN should be left also for aggregatd classes. MPLS and Ethernet only support up to 8 QoS classes. IP over Ethernet and / or MPLS is acommodity in todays operational environments, and inter layer QoS likely will be a commodity too.

4. Consolidation of QoS standards by the interconnection codepoint scheme

The interconnection class and codepoint scheme proposed by Y.1566 also tries to consolidate related DiffServ and QoS standardisation efforts outside of the IETF [Y.1566]. MEF 23.1 specifies 3 aggregated classes, consuming up to 5 bit codepoints (EF, two AF classes and Best Effort) and 8 DSCPs [MEF23.1]. GSMA IR.34 proposes four aggregated DiffServ classes, EF, 2 AF and Best Effort with 7 DSCPs (PHBs) in sum [IR.34]. Consolidation may be reached for EF, one AF class and Best Effort, meaning three aggregated or 5 DSCPs. Consolidation here aims on similar class definitions and DiffServ codepoints in all standards, MEF23.1, GSMA IR.34 and Y.1566. This will again simplify product design and interconnection negotiations for customers and parties following these standards.

5. MPLS, Ethernet and IP Precedence for aggregated classes

IP Precedence has been depricated when DiffServ was standardised. Ethernet and MPLS support 3 bit codepoint fields to differntiate service quality. Mapping of the IP precedence to these 3 Bit fields has been a configuration restriction in the early days of DiffServ. The concept of paying attention to the three most significant bits of a DSCP has however been part of Diffserv from start on (EF's IP Precedence is 5, that of AF4 is 4 and so on). The interconnection class and codepoint scheme respects this in different ways:

• it allows to classify four aggregated classes based on IP precedence.
• It supports a single PHB group (AF3), which may be mapped to up to three different MPLS TC's or Ethernet P-Bits. Note that the author doesn's favour or recommend doing that, but it is possible. The author isn't aware of deployed service offers with 3 different drop levels in a single class.

This is of course no requirement to depricate any DSCP to MPLS TC or Ethernet P-Bit mapping functionality. This functionalities are very important as well.

6. QoS class name selection

This is more of an informational discussion, proposed best practice, and mainly relates to human behviour (including QoS experts) rather than technical issues. Above the human preference for conceivable class names has been mentioned. Network engineers (including the former Diffserv WG authors) recommend to avoid application related QoS class names. Focus should be put on class properties. But these can be irritating again, as just looking at a few SLA numbers doesn't tell the reader, which engineering assumptions resulted in the scheduler configurations of a class. A router produces QoS with a scheduling mechanism, a settable queue depth and optional active queue management (including ECN), and may be a policer. Some kind of resource management may be presendt (also in Diffserv domains). It's beyond the imagination of the author how one would engineer more than half a dozen classes with distinguishable properties with this set of tools.

There's no perfect solution to the problem, as scheduler configurations are not comprehensible to most readers, even if they were communicated (they are operational secrets of course). There are (or should be) engineering assumptions, when designing QoS schedulers. But they closer relate to layer 3 or layer 4 level properties than to specific applications. In general, an application responds to congestion by reducing traffic, or it ignores congestion. Active queue management doesn't help to avoid congestion in the latter case, only resource management does. EF may be a special case. If the EF traffic is not responsive to congestion, and packets are assumed to be short, rather small jitter values can be reached if enginieering ensures that the packet arrival rate never exceeds the transmision rate of that queue (see RFC 3246 [RFC3246]). There's other non congestion-responsive traffic, for which the EF engineering assumptions may not fit. So a second class with EF like properties (but a different engineering) may be present.

Active queue management may be deployed for QoS classes, which are designed to transport traffic responding to congestion by traffic reduction.

The author couldn't yet find conceivable class names. TCP_optimised and especially UDP_optimised are inappropriate, as some UDP based application are or may be expected to become TCP friendly.

7. Allow for DiffServ extendability on MPLS and Ethernet level

Any aggregated Diffserv deployment faces codepoint depletion issues rather soon, if deployed on MPLS or Ethernet. Coding space should be left for new features, like ECN, PCN or Conex. In addition to carrying customer traffic, internal routing and network management traffic may be protected by using a separate class. offering interconnection with up to four classes and 4 - 6 MPLS TC's (or Ethernet P-bits) to that respect is probably at least a fair compromise.

8. IANA Considerations

This memo includes no request to IANA.

9. Security Considerations

This document does not introduce new features, it describes how to use existing ones. The security section of RFC 4597 [RFC4597] applies.

10. References

10.1. Normative References

10.2. Informative References

Author's Address